resolving conflicts
Savitha Raghunathan
commit
53f2d23359
|
|
@ -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
|
||||
|
||||
|
|
|
|||
2
Makefile
2
Makefile
|
|
@ -64,7 +64,7 @@ container-image:
|
|||
--build-arg HUGO_VERSION=$(HUGO_VERSION)
|
||||
|
||||
container-build: module-check
|
||||
$(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo
|
||||
$(CONTAINER_RUN) $(CONTAINER_IMAGE) hugo --minify
|
||||
|
||||
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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -41,18 +24,15 @@ aliases:
|
|||
sig-docs-en-owners: # Admins for English content
|
||||
- bradtopol
|
||||
- celestehorgan
|
||||
- daminisatya
|
||||
- jimangel
|
||||
- kbarnard10
|
||||
- kbhawkey
|
||||
- makoscafee
|
||||
- onlydole
|
||||
- Rajakavitha1
|
||||
- savitharaghunathan
|
||||
- sftim
|
||||
- steveperry-53
|
||||
- tengqm
|
||||
- vineethreddy02
|
||||
- xiangpengzhao
|
||||
- zacharysarah
|
||||
- zparnold
|
||||
|
|
@ -65,7 +45,6 @@ aliases:
|
|||
- kbhawkey
|
||||
- makoscafee
|
||||
- onlydole
|
||||
- rajakavitha1
|
||||
- rajeshdeshpande02
|
||||
- sftim
|
||||
- steveperry-53
|
||||
|
|
@ -113,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
|
||||
|
|
@ -127,6 +104,7 @@ aliases:
|
|||
- irvifa
|
||||
- wahyuoi
|
||||
- phanama
|
||||
- danninov
|
||||
sig-docs-it-owners: # Admins for Italian content
|
||||
- fabriziopandini
|
||||
- mattiaperi
|
||||
|
|
|
|||
26
README-ja.md
26
README-ja.md
|
|
@ -1,7 +1,6 @@
|
|||
# Kubernetesのドキュメント
|
||||
|
||||
[](https://travis-ci.org/kubernetes/website)
|
||||
[](https://github.com/kubernetes/website/releases/latest)
|
||||
[](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [](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のドキュメントへの貢献に関する詳細については以下のページをご覧ください:
|
||||
|
||||
|
|
|
|||
256
README-zh.md
256
README-zh.md
|
|
@ -1,74 +1,139 @@
|
|||
# Kubernetes 文档
|
||||
|
||||
<!--
|
||||
# The Kubernetes documentation
|
||||
-->
|
||||
-->
|
||||
|
||||
[](https://travis-ci.org/kubernetes/website)
|
||||
[](https://github.com/kubernetes/website/releases/latest)
|
||||
[](https://app.netlify.com/sites/kubernetes-io-master-staging/deploys) [](https://github.com/kubernetes/website/releases/latest)
|
||||
|
||||
<!--
|
||||
Welcome! This repository houses all of 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/)的内容。
|
||||
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/) 的软件资产。
|
||||
我们非常高兴您想要参与贡献！
|
||||
|
||||
<!--
|
||||
## Running the website locally using Hugo
|
||||
|
||||
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.
|
||||
-->
|
||||
## 在本地使用 Hugo 来运行网站
|
||||
|
||||
请参考 [Hugo 的官方文档](https://gohugo.io/getting-started/installing/)了解 Hugo 的安装指令。
|
||||
请确保安装的是 [`netlify.toml`](netlify.toml#L10) 文件中环境变量 `HUGO_VERSION` 所指定的
|
||||
Hugo 扩展版本。
|
||||
|
||||
<!--
|
||||
Before building the site, clone the Kubernetes website repository:
|
||||
-->
|
||||
在构造网站之前，先克隆 Kubernetes website 仓库：
|
||||
|
||||
```bash
|
||||
git clone https://github.com/kubernetes/website.git
|
||||
cd website
|
||||
git submodule update --init --recursive
|
||||
```
|
||||
|
||||
<!--
|
||||
**Note:** The Kubernetes website deploys the [Docsy Hugo theme](https://github.com/google/docsy#readme).
|
||||
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.
|
||||
|
||||
Update the website theme:
|
||||
-->
|
||||
**注意：** Kubernetes 网站要部署 [Docsy Hugo 主题](https://github.com/google/docsy#readme).
|
||||
如果你还没有更新你本地的 website 仓库，目录 `website/themes/docsy`
|
||||
会是空目录。
|
||||
在本地没有主题副本的情况下，网站无法正常构造。
|
||||
|
||||
使用下面的命令更新网站主题：
|
||||
|
||||
```bash
|
||||
git submodule update --init --recursive --depth 1
|
||||
```
|
||||
|
||||
<!--
|
||||
To build and test the site locally, run:
|
||||
-->
|
||||
若要在本地构造和测试网站，请运行：
|
||||
|
||||
```bash
|
||||
hugo server --buildFuture
|
||||
```
|
||||
|
||||
<!--
|
||||
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.
|
||||
-->
|
||||
上述命令会在端口 1313 上启动本地 Hugo 服务器。
|
||||
启动浏览器，打开 http://localhost:1313 来查看网站。
|
||||
当你对源文件作出修改时，Hugo 会更新网站并强制浏览器执行刷新操作。
|
||||
|
||||
<!--
|
||||
## 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).
|
||||
|
||||
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)
|
||||
-->
|
||||
## 参与 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)
|
||||
|
||||
<!--
|
||||
## 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.
|
||||
|
||||
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
|
||||
评审人所提出的反馈是你的责任*。
|
||||
|
||||
<!--
|
||||
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.
|
||||
-->
|
||||
您可以点击屏幕右上方的 **Fork** 按钮，在您的 GitHub 账户下创建一份本仓库的副本。这个副本叫做 *fork*。您可以对 fork 副本进行任意修改，
|
||||
当准备好把修改提交给我们时，您可以通过创建一个 pull request 来告知我们。
|
||||
|
||||
<!--
|
||||
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.**
|
||||
Also, note that you may end up having more than one Kubernetes reviewer provide you feedback or you may end up getting feedback from a Kubernetes reviewer that is different than the one initially assigned to provide you feedback.
|
||||
Furthermore, in some cases, one of your reviewers might ask for a technical review from a [Kubernetes tech reviewer](https://github.com/kubernetes/website/wiki/Tech-reviewers) when needed.
|
||||
Reviewers will do their best to provide feedback in a timely fashion but response time can vary based on circumstances.
|
||||
-->
|
||||
创建 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
|
||||
技术评审人来执行技术评审。
|
||||
评审人会尽力及时地提供反馈意见，不过具体的响应时间可能会因时而异。
|
||||
|
||||
<!--
|
||||
For more information about contributing to the Kubernetes documentation, see:
|
||||
|
||||
* [Start contributing](https://kubernetes.io/docs/contribute/start/)
|
||||
* [Staging Your Documentation Changes](http://kubernetes.io/docs/contribute/intermediate#view-your-changes-locally)
|
||||
* [Using Page Templates](http://kubernetes.io/docs/contribute/style/page-templates/)
|
||||
* [Documentation Style Guide](http://kubernetes.io/docs/contribute/style/style-guide/)
|
||||
* [Contribute to Kubernetes docs](https://kubernetes.io/docs/contribute/)
|
||||
* [Page Content Types](https://kubernetes.io/docs/contribute/style/page-content-types/)
|
||||
* [Documentation Style Guide](https://kubernetes.io/docs/contribute/style/style-guide/)
|
||||
* [Localizing Kubernetes Documentation](https://kubernetes.io/docs/contribute/localization/)
|
||||
-->
|
||||
-->
|
||||
有关为 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`'s Localizing Kubernetes Documentation
|
||||
-->
|
||||
## `README.md` 的本地化 Kubernetes 文档
|
||||
|
||||
<!--
|
||||
### Korean
|
||||
|
||||
You can reach the maintainers of Korean localization at:
|
||||
|
||||
* June Yi ([GitHub - @gochist](https://github.com/gochist))
|
||||
* [Slack channel](https://kubernetes.slack.com/messages/kubernetes-docs-ko)
|
||||
-->
|
||||
### 中文
|
||||
## 中文本地化
|
||||
|
||||
可以通过以下方式联系中文本地化的维护人员：
|
||||
|
||||
|
|
@ -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)
|
||||
|
||||
<!--
|
||||
## Running the website locally using Docker
|
||||
-->
|
||||
## 在本地使用 docker 运行网站
|
||||
|
||||
<!--
|
||||
The recommended way to run the Kubernetes website locally is to run a specialized [Docker](https://docker.com) image that includes the [Hugo](https://gohugo.io) static website generator.
|
||||
-->
|
||||
在本地运行 Kubernetes 网站的推荐方法是运行包含 [Hugo](https://gohugo.io) 静态网站生成器的专用 [Docker](https://docker.com) 镜像。
|
||||
|
||||
<!--
|
||||
> If you are running on Windows, you'll need a few more tools which you can install with [Chocolatey](https://chocolatey.org). `choco install make`
|
||||
-->
|
||||
> 如果您使用的是 Windows，则需要一些工具，可以使用 [Chocolatey](https://chocolatey.org) 进行安装。`choco install make`
|
||||
|
||||
<!--
|
||||
> If you'd prefer to run the website locally without Docker, see [Running the website locally using Hugo](#running-the-site-locally-using-hugo) below.
|
||||
-->
|
||||
> 如果您更喜欢在没有 Docker 的情况下在本地运行网站，请参阅下面的[使用 Hugo 在本地运行网站](#running-the-site-locally-using-hugo) 章节。
|
||||
|
||||
<!--
|
||||
If you have Docker [up and running](https://www.docker.com/get-started), build the `kubernetes-hugo` Docker image locally:
|
||||
-->
|
||||
如果您已经[安装运行](https://www.docker.com/get-started)了 Docker，使用以下命令在本地构建 `kubernetes-hugo` Docker 镜像：
|
||||
|
||||
```bash
|
||||
make docker-image
|
||||
```
|
||||
|
||||
<!--
|
||||
Once the image has been built, you can run the website locally:
|
||||
-->
|
||||
一旦创建了镜像，您就可以在本地运行网站了：
|
||||
|
||||
```bash
|
||||
make docker-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.
|
||||
-->
|
||||
打开浏览器访问 http://localhost:1313 以查看网站。当您对源文件进行更改时，Hugo 会更新网站并强制刷新浏览器。
|
||||
|
||||
<!--
|
||||
## Running the website locally using Hugo
|
||||
-->
|
||||
## 使用 Hugo 在本地运行网站 {#running-the-site-locally-using-hugo}
|
||||
|
||||
<!--
|
||||
See the [official Hugo documentation](https://gohugo.io/getting-started/installing/) for Hugo installation instructions.
|
||||
Make sure to install the Hugo version specified by the `HUGO_VERSION` environment variable in the [`netlify.toml`](netlify.toml#L9) file.
|
||||
-->
|
||||
有关 Hugo 的安装说明，请参阅 [Hugo 官方文档](https://gohugo.io/getting-started/installing/)。
|
||||
确保安装对应版本的 Hugo，版本号由 [`netlify.toml`](netlify.toml#L9) 文件中的 `HUGO_VERSION` 环境变量指定。
|
||||
|
||||
<!--
|
||||
To run the website locally when you have Hugo installed:
|
||||
-->
|
||||
安装 Hugo 后，在本地运行网站：
|
||||
|
||||
```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.
|
||||
-->
|
||||
这将在 1313 端口上启动本地 Hugo 服务器。打开浏览器访问 http://localhost:1313 查看网站。当您对源文件进行更改时，Hugo 会更新网站并强制刷新浏览器。
|
||||
|
||||
<!--
|
||||
## Community, discussion, contribution, and support
|
||||
-->
|
||||
## 社区、讨论、贡献和支持
|
||||
|
||||
<!--
|
||||
Learn how to engage with the Kubernetes community on the [community page](http://kubernetes.io/community/).
|
||||
-->
|
||||
在[社区页面](http://kubernetes.io/community/)了解如何与 Kubernetes 社区互动。
|
||||
|
||||
<!--
|
||||
You can 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)
|
||||
|
||||
<!--
|
||||
### Code of conduct
|
||||
|
||||
Participation in the Kubernetes community is governed by the [Kubernetes Code of Conduct](code-of-conduct.md).
|
||||
-->
|
||||
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)约束。
|
||||
|
||||
<!--
|
||||
## Thank you!
|
||||
|
||||
Kubernetes thrives on community participation, and we appreciate your contributions to our website and our documentation!
|
||||
-->
|
||||
-->
|
||||
## 感谢！
|
||||
|
||||
Kubernetes 因为社区的参与而蓬勃发展，感谢您对我们网站和文档的贡献！
|
||||
|
|
|
|||
|
|
@ -7,6 +7,8 @@ content_type: tutorial
|
|||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
|
||||
## {{% heading "objectives" %}}
|
||||
|
||||
<!-- lessoncontent -->
|
||||
|
|
|
|||
|
|
@ -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 {
|
||||
|
|
@ -390,4 +390,4 @@ main.content {
|
|||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
}
|
||||
|
|
@ -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;
|
||||
}
|
||||
}
|
||||
|
||||
|
|
|
|||
|
|
@ -153,7 +153,6 @@ css = [
|
|||
"custom-jekyll/tags"
|
||||
]
|
||||
js = [
|
||||
"custom-jekyll/tags",
|
||||
"script"
|
||||
]
|
||||
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -79,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
|
||||
|
|
@ -94,6 +95,25 @@ the rotation and there are two files, one 10MB in size and one empty,
|
|||
{{< /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
|
||||
that do not run in a container. For example:
|
||||
|
||||
* The Kubernetes scheduler and kube-proxy run in a container.
|
||||
* The kubelet and container runtime, for example Docker, do not run in containers.
|
||||
|
||||
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](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).
|
||||
|
||||
Similarly to the container logs, system component logs in the `/var/log`
|
||||
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.
|
||||
|
||||
## Cluster-level logging architectures
|
||||
|
||||
|
|
|
|||
|
|
@ -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" >}}
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -26,7 +26,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/)).
|
||||
|
|
|
|||
|
|
@ -302,7 +302,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
|
||||
|
|
|
|||
|
|
@ -686,7 +686,7 @@ provisioner: kubernetes.io/portworx-volume
|
|||
parameters:
|
||||
repl: "1"
|
||||
snap_interval: "70"
|
||||
io_priority: "high"
|
||||
priority_io: "high"
|
||||
|
||||
```
|
||||
|
||||
|
|
@ -695,7 +695,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
|
||||
|
|
|
|||
|
|
@ -1068,7 +1068,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.
|
||||
|
|
|
|||
|
|
@ -215,8 +215,8 @@ 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 >}}
|
||||
If your job has `restartPolicy = "OnFailure"`, keep in mind that your container running the Job
|
||||
|
|
@ -474,4 +474,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`.
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
@ -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/).
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -17,67 +17,6 @@ client and other tools for some of these tasks.
|
|||
|
||||
<!-- body -->
|
||||
|
||||
## 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.
|
||||
- Consider accepting accurate technical content even if the content meets only some of the docs' [style guidelines](/docs/contribute/style/style-guide/). Open a new issue with the label `good first issue` to address style concerns.
|
||||
- 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 @<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.
|
||||
|
||||
### 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.
|
||||
|
|
@ -108,8 +47,8 @@ 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).
|
||||
|
||||
|
|
@ -245,5 +184,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.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -237,6 +237,9 @@ Build the Kubernetes documentation in your local `<web-base>`.
|
|||
cd <web-base>
|
||||
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/).
|
||||
|
||||
|
|
|
|||
|
|
@ -185,6 +185,10 @@ cd <web-base>
|
|||
make docker-serve
|
||||
```
|
||||
|
||||
{{< note >}}
|
||||
The use of `make docker-serve` is deprecated. Please use `make container-serve` instead.
|
||||
{{< /note >}}
|
||||
|
||||
## Commit the changes
|
||||
|
||||
In `<web-base>` run `git add` and `git commit` to commit the change.
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
||||
|
||||
<!-- body -->
|
||||
|
||||
## 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.
|
||||
|
|
|
|||
|
|
@ -0,0 +1,69 @@
|
|||
---
|
||||
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/).
|
||||
|
||||
<!-- 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.
|
||||
|
||||
### 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%3Ado-not-merge+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?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+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+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?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+-label%3Ado-not-merge+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.
|
||||
|
||||
### 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 >}}
|
||||
|
|
@ -126,9 +126,9 @@ To apply:
|
|||
[OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS) file
|
||||
in the `kubernetes/website` repository.
|
||||
|
||||
{{ note }}
|
||||
{{< note >}}
|
||||
If you aren't sure where to add yourself, add yourself to `sig-docs-en-reviews`.
|
||||
{{ /note }}
|
||||
{{< /note >}}
|
||||
|
||||
2. Assign the PR to one or more SIG-Docs approvers (user names listed under `sig-docs-{language}-owners`).
|
||||
|
||||
|
|
@ -171,7 +171,7 @@ Approvers and SIG Docs leads are the only ones who can merge pull requests into
|
|||
- 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)
|
||||
rotation. See [PR wranglers](/docs/contribute/participating/pr-wranglers/).
|
||||
for more details.
|
||||
|
||||
### Becoming an approver
|
||||
|
|
@ -182,10 +182,14 @@ 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 }}
|
||||
{{< note >}}
|
||||
If you aren't sure where to add yourself, add yourself to `sig-docs-en-owners`.
|
||||
{{ /note }}
|
||||
{{< /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.
|
||||
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/participating/pr-wranglers), a role all approvers take on rotation.
|
||||
|
|
@ -706,8 +706,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}
|
||||
|
|
@ -793,4 +793,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.
|
||||
admission controllers ran in the exact order specified.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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'
|
||||
|
|
|
|||
|
|
@ -126,7 +126,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
|
||||
|
|
|
|||
|
|
@ -756,6 +756,11 @@ quorum read to be served.
|
|||
| resourceVersionMatch=NotOlderThan[^1] | limit="n", continue unset | Invalid | Any | Not older than |
|
||||
|
||||
[^1]: If the server does not honor the `resourceVersionMatch` parameter, it is treated as if it is unset.
|
||||
| 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:
|
||||
|
||||
|
|
|
|||
|
|
@ -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/
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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,8 +66,6 @@ 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](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#network-plugin-requirements) page.
|
||||
|
||||
## Check required ports
|
||||
|
|
|
|||
|
|
@ -23,22 +23,15 @@ 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/).
|
||||
* 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
|
||||
|
|
|
|||
|
|
@ -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!
|
||||
|
|
|
|||
|
|
@ -158,4 +158,4 @@ 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.
|
||||
* `kube-apiserver` version must be between **{{< skew oldestMinorVersion >}}** and **{{< skew latestVersion >}}**, inclusive.
|
||||
|
|
|
|||
|
|
@ -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/)
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
|
|
|||
|
|
@ -316,7 +316,7 @@ 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
|
||||
|
||||
|
|
|
|||
|
|
@ -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,7 +85,9 @@ 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
|
||||
|
||||
|
|
@ -98,7 +99,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
|
||||
|
|
@ -124,7 +125,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
|
||||
|
|
@ -135,11 +136,12 @@ log audit backend using the following [kube-apiserver][kube-apiserver] flags:
|
|||
### 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.
|
||||
|
||||
|
|
@ -202,23 +204,29 @@ By default truncate is disabled in both `webhook` and `log`, a cluster administr
|
|||
|
||||
## 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/),
|
||||
y ou 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
|
||||
|
||||
|
|
@ -291,11 +299,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
|
||||
|
||||
|
|
@ -366,19 +375,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" %}}
|
||||
|
||||
|
|
|
|||
|
|
@ -13,18 +13,15 @@ title: Auditing with Falco
|
|||
[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]
|
||||
- [Standalone Falco](https://falco.org/docs/installation)
|
||||
- [Kubernetes DaemonSet](https://falco.org/docs/installation)
|
||||
- [Falco Helm Chart](https://github.com/falcosecurity/charts/tree/master/falco)
|
||||
|
||||
Once Falco is installed make sure it is configured to expose the Audit webhook. To do so, use the following configuration:
|
||||
|
||||
|
|
@ -41,7 +38,8 @@ This configuration is typically found in the `/etc/falco/falco.yaml` file. If Fa
|
|||
|
||||
#### Configure Kubernetes Audit
|
||||
|
||||
1. Create a [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/) for the [kube-apiserver][kube-apiserver] webhook audit backend.
|
||||
1. Create a [kubeconfig file](/docs/concepts/configuration/organize-cluster-access-kubeconfig/)
|
||||
for the [kube-apiserver](/docs/reference/generated/kube-apiserver/) webhook audit backend.
|
||||
|
||||
cat <<EOF > /etc/kubernetes/audit-webhook-kubeconfig
|
||||
apiVersion: v1
|
||||
|
|
@ -60,7 +58,7 @@ This configuration is typically found in the `/etc/falco/falco.yaml` file. If Fa
|
|||
users: []
|
||||
EOF
|
||||
|
||||
1. Start [kube-apiserver][kube-apiserver] with the following options:
|
||||
1. Start `kube-apiserver` with the following options:
|
||||
|
||||
```shell
|
||||
--audit-policy-file=/etc/kubernetes/audit-policy.yaml --audit-webhook-config-file=/etc/kubernetes/audit-webhook-kubeconfig
|
||||
|
|
@ -68,7 +66,8 @@ This configuration is typically found in the `/etc/falco/falco.yaml` file. If Fa
|
|||
|
||||
#### 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.
|
||||
Rules devoted to Kubernetes Audit Events can be found in [k8s_audit_rules.yaml](https://github.com/falcosecurity/falco/blob/master/rules/k8s_audit_rules.yaml).
|
||||
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.
|
||||
|
||||
|
|
@ -99,23 +98,6 @@ A second class of rules tracks resources being created or destroyed, including:
|
|||
|
||||
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
|
||||
For further details, see [Kubernetes Audit Events](https://falco.org/docs/event-sources/kubernetes-audit) in the Falco documentation.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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 -->
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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)
|
||||
|
|
@ -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_definition 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.
|
||||
|
|
@ -1,7 +1,7 @@
|
|||
---
|
||||
title: Empieza a contribuir
|
||||
slug: start
|
||||
content_template: templates/concept
|
||||
content_type: concept
|
||||
weight: 10
|
||||
card:
|
||||
name: contribute
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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" >}}.
|
||||
|
|
@ -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/).
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -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.
|
||||
|
|
@ -65,7 +65,7 @@ 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.
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
---
|
||||
title: "Monitorización, Logs y Debugging"
|
||||
weight: 80
|
||||
---
|
||||
---
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
||||
|
|
@ -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.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -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:
|
||||
|
||||
|
||||
|
||||
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:
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## {{% 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).
|
||||
|
||||
|
||||
|
|
@ -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.
|
||||
|
||||
|
||||
|
|
@ -1,4 +1,4 @@
|
|||
---
|
||||
title: Gestionar y ejecutar demonios
|
||||
title: Gestionar y ejecutar daemons
|
||||
weight: 45
|
||||
---
|
||||
|
|
@ -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"
|
||||
|
|
@ -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']
|
||||
|
|
@ -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.
|
||||
|
||||
|
|
@ -1,6 +1,6 @@
|
|||
---
|
||||
title: Kelola Sertifikat TLS Pada Klaster
|
||||
content_template: templates/task
|
||||
content_type: task
|
||||
---
|
||||
|
||||
<!-- overview -->
|
||||
|
|
|
|||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: "Aplikasi Stateless"
|
||||
weight: 40
|
||||
---
|
||||
|
||||
|
|
@ -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/).
|
||||
|
||||
|
||||
|
|
@ -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
|
||||
|
|
@ -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
|
||||
|
|
@ -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)のチャンネルで、翻訳が利用できるようになったことを公表する。
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ weight: 40
|
|||
* [데몬셋(DaemonSet)](/ko/docs/concepts/workloads/controllers/daemonset/)
|
||||
* [스테이트풀셋(StatefulSet)](/ko/docs/concepts/workloads/controllers/statefulset/)
|
||||
* [레플리카셋(ReplicaSet)](/ko/docs/concepts/workloads/controllers/replicaset/)
|
||||
* [잡(Job)](/ko/docs/concepts/workloads/controllers/jobs-run-to-completion/)
|
||||
* [잡(Job)](/ko/docs/concepts/workloads/controllers/job/)
|
||||
|
||||
## 쿠버네티스 컨트롤 플레인
|
||||
|
||||
|
|
@ -66,6 +66,5 @@ weight: 40
|
|||
|
||||
|
||||
개념 페이지를 작성하기를 원하면,
|
||||
개념 페이지 유형에 대한 정보가 있는
|
||||
[페이지 컨텐츠 유형](/docs/contribute/style/page-content-types/#concept)을 참조한다.
|
||||
|
||||
개념 페이지 타입에 대한 정보가 있는
|
||||
[페이지 컨텐츠 타입](/docs/contribute/style/page-content-types/#concept)을 참고한다.
|
||||
|
|
|
|||
|
|
@ -63,11 +63,11 @@ 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은 다음 옵션과 함께 시작된다.
|
||||
|
|
@ -75,7 +75,7 @@ kubelet 플래그 `--register-node`는 참(기본값)일 경우, kubelet 은 API
|
|||
- `--kubeconfig` - apiserver에 스스로 인증하기 위한 자격증명에 대한 경로.
|
||||
- `--cloud-provider` - 자신에 대한 메터데이터를 읽기 위해 어떻게 {{< glossary_tooltip text="클라우드 제공자" term_id="cloud-provider" >}}와 소통할지에 대한 방법.
|
||||
- `--register-node` - 자동으로 API 서버에 등록.
|
||||
- `--register-with-taints` - 주어진 {{< glossary_tooltip text="테인트(taint)" term_id="taint" >}} 리스트(콤마로 분리된 `<key>=<value>:<effect>`)를 가진 노드 등록.
|
||||
- `--register-with-taints` - 주어진 {{< glossary_tooltip text="테인트(taint)" term_id="taint" >}} 리스트(콤마로 분리된 `<key>=<value>:<effect>`)를 가진 노드 등록.
|
||||
|
||||
`register-node`가 거짓이면 동작 안 함.
|
||||
- `--node-ip` - 노드의 IP 주소.
|
||||
|
|
@ -180,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` 상태로 있을 때 접근 불가한 노드 상에서
|
||||
동작되고 있는 것을 보게 될 수도 있다. 노드가 영구적으로 클러스터에서 삭제되었는지에
|
||||
대한 여부를 쿠버네티스가 기반 인프라로부터 유추할 수 없는 경우, 노드가 클러스터를 영구적으로
|
||||
탈퇴하게 되면, 클러스터 관리자는 손수 노드 오브젝트를 삭제해야 할 수도 있다.
|
||||
|
|
@ -188,7 +188,7 @@ 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)을 가질 수 있다.
|
||||
|
||||
|
|
@ -197,7 +197,7 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳
|
|||
|
||||
### 용량과 할당가능 {#capacity}
|
||||
|
||||
노드 상에 사용 가능한 리소스를 나타낸다. 리소스에는 CPU, 메모리 그리고
|
||||
노드 상에 사용 가능한 리소스를 나타낸다. 리소스에는 CPU, 메모리 그리고
|
||||
노드 상으로 스케줄 되어질 수 있는 최대 파드 수가 있다.
|
||||
|
||||
용량 블록의 필드는 노드에 있는 리소스의 총량을 나타낸다.
|
||||
|
|
@ -221,18 +221,18 @@ apiserver로부터 삭제되어 그 이름을 사용할 수 있는 결과를 낳
|
|||
노드 컨트롤러는 노드가 생성되어 유지되는 동안 다양한 역할을 한다. 첫째는 등록 시점에
|
||||
(CIDR 할당이 사용토록 설정된 경우) 노드에 CIDR 블럭을 할당하는 것이다.
|
||||
|
||||
두 번째는 노드 컨트롤러의 내부 노드 리스트를 클라우드 제공사업자의
|
||||
사용 가능한 머신 리스트 정보를 근거로 최신상태로 유지하는 것이다. 클라우드 환경에서
|
||||
동작 중일 경우, 노드상태가 불량할 때마다, 노드 컨트롤러는
|
||||
해당 노드용 VM이 여전히 사용 가능한지에 대해 클라우드 제공사업자에게 묻는다. 사용 가능하지 않을 경우,
|
||||
두 번째는 노드 컨트롤러의 내부 노드 리스트를 클라우드 제공사업자의
|
||||
사용 가능한 머신 리스트 정보를 근거로 최신상태로 유지하는 것이다. 클라우드 환경에서
|
||||
동작 중일 경우, 노드상태가 불량할 때마다, 노드 컨트롤러는
|
||||
해당 노드용 VM이 여전히 사용 가능한지에 대해 클라우드 제공사업자에게 묻는다. 사용 가능하지 않을 경우,
|
||||
노드 컨트롤러는 노드 리스트로부터 그 노드를 삭제한다.
|
||||
|
||||
세 번째는 노드의 동작 상태를 모니터링 하는 것이다. 노드 컨트롤러는
|
||||
노드가 접근 불가할 경우 (즉 노드 컨트롤러가 어떠한 사유로 하트비트
|
||||
세 번째는 노드의 동작 상태를 모니터링 하는 것이다. 노드 컨트롤러는
|
||||
노드가 접근 불가할 경우 (즉 노드 컨트롤러가 어떠한 사유로 하트비트
|
||||
수신을 중지하는 경우, 예를 들어 노드 다운과 같은 경우이다.)
|
||||
NodeStatus의 NodeReady 컨디션을 ConditionUnknown으로 업데이트 하는 책임을 지고,
|
||||
노드가 계속 접근 불가할 경우 나중에 노드로부터 (정상적인 종료를 이용하여) 모든 파드를 축출시킨다.
|
||||
(ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고,
|
||||
NodeStatus의 NodeReady 컨디션을 ConditionUnknown으로 업데이트 하는 책임을 지고,
|
||||
노드가 계속 접근 불가할 경우 나중에 노드로부터 (정상적인 종료를 이용하여) 모든 파드를 축출시킨다.
|
||||
(ConditionUnknown을 알리기 시작하는 기본 타임아웃 값은 40초 이고,
|
||||
파드를 축출하기 시작하는 값은 5분이다.) 노드 컨트롤러는
|
||||
매 `--node-monitor-period` 초 마다 각 노드의 상태를 체크한다.
|
||||
|
||||
|
|
@ -260,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` 테인트 상태의
|
||||
|
|
@ -323,7 +323,7 @@ kubelet은 `NodeStatus` 와 리스 오브젝트를 생성하고 업데이트 할
|
|||
|
||||
{{< feature-state state="alpha" for_k8s_version="v1.16" >}}
|
||||
|
||||
`TopologyManager`
|
||||
`TopologyManager`
|
||||
[기능 게이트(feature gate)](/docs/reference/command-line-tools-reference/feature-gates/)를
|
||||
활성화 시켜두면, kubelet이 리소스 할당 결정을 할 때 토폴로지 힌트를 사용할 수 있다.
|
||||
자세한 내용은
|
||||
|
|
|
|||
|
|
@ -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을 환영한다!
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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 백엔드에서 프록시 프로토콜을 사용하도록 설정하는 `*` 값만 허용한다. 향후에는 특정 백엔드에서만 프록시 프로토콜을 설정할 수 있도록 이를 조정할 수 있게 된다.
|
||||
|
|
|
|||
|
|
@ -19,12 +19,12 @@ weight: 10
|
|||
- 단지 자신의 컴퓨터에 쿠버네티스를 테스트를 하는지, 또는 고가용성의 멀티 노드 클러스터를 만들려고 하는지에 따라 니즈에 가장 적절한 배포판을 고르자.
|
||||
- [구글 쿠버네티스 엔진](https://cloud.google.com/kubernetes-engine/)과 같은 **호스팅된 쿠버네티스 클러스터** 를 사용할 것인지, **자신의 클러스터에 호스팅할 것인지**?
|
||||
- 클러스터가 **온프레미스** 인지, 또는 **클라우드(IaaS)** 인지? 쿠버네티스는 하이브리드 클러스터를 직접적으로 지원하지는 않는다. 대신에, 사용자는 여러 클러스터를 구성할 수 있다.
|
||||
- **만약 온프레미스에서 쿠버네티스를 구성한다면**, 어떤 [네트워킹 모델](/docs/concepts/cluster-administration/networking/)이 가장 적합한지 고려한다.
|
||||
- **만약 온프레미스에서 쿠버네티스를 구성한다면**, 어떤 [네트워킹 모델](/ko/docs/concepts/cluster-administration/networking/)이 가장 적합한지 고려한다.
|
||||
- 쿠버네티스 실행을 **"베어메탈" 하드웨어** 또는, **가상 머신 (VMs)** 중 어디에서 할 것 인지?
|
||||
- **단지 클러스터 동작** 만 할 것인지, 아니면 **쿠버네티스 프로젝트 코드의 적극적인 개발** 을 원하는지? 만약 후자의 경우라면,
|
||||
적극적으로 개발된 배포판을 선택한다. 몇몇 배포판은 바이너리 릴리스 밖에 없지만,
|
||||
매우 다양한 선택권을 제공한다.
|
||||
- 스스로 클러스터 구동에 필요한 [구성요소](/docs/admin/cluster-components/)에 익숙해지자.
|
||||
- 스스로 클러스터 구동에 필요한 [구성요소](/ko/docs/concepts/overview/components/)에 익숙해지자.
|
||||
|
||||
참고: 모든 배포판이 적극적으로 유지되는 것은 아니다. 최근 버전의 쿠버네티스로 테스트 된 배포판을 선택하자.
|
||||
|
||||
|
|
@ -38,7 +38,7 @@ weight: 10
|
|||
|
||||
## 클러스터 보안
|
||||
|
||||
* [인증서](/docs/concepts/cluster-administration/certificates/)는 다른 툴 체인을 이용하여 인증서를 생성하는 방법을 설명한다.
|
||||
* [인증서](/ko/docs/concepts/cluster-administration/certificates/)는 다른 툴 체인을 이용하여 인증서를 생성하는 방법을 설명한다.
|
||||
|
||||
* [쿠버네티스 컨테이너 환경](/ko/docs/concepts/containers/container-environment/)은 쿠버네티스 노드에서 Kubelet에 의해 관리되는 컨테이너 환경에 대해 설명한다.
|
||||
|
||||
|
|
@ -63,6 +63,4 @@ weight: 10
|
|||
|
||||
* [DNS 통합](/ko/docs/concepts/services-networking/dns-pod-service/)은 DNS 이름이 쿠버네티스 서비스에 바로 연결되도록 변환하는 방법을 설명한다.
|
||||
|
||||
* [클러스터 활동 로깅과 모니터링](/docs/concepts/cluster-administration/logging/)은 쿠버네티스 로깅이 로깅의 작동 방법과 로깅을 어떻게 구현하는지 설명한다.
|
||||
|
||||
|
||||
* [클러스터 활동 로깅과 모니터링](/ko/docs/concepts/cluster-administration/logging/)은 쿠버네티스 로깅이 로깅의 작동 방법과 로깅을 어떻게 구현하는지 설명한다.
|
||||
|
|
|
|||
|
|
@ -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에 직접 접근하면, 이
|
||||
|
|
@ -168,7 +168,7 @@ spec:
|
|||
파드의 볼륨에서 컨피그맵을 사용하려면 다음을 수행한다.
|
||||
|
||||
1. 컨피그맵을 생성하거나 기존 컨피그맵을 사용한다. 여러 파드가 동일한 컨피그맵을 참조할 수 있다.
|
||||
1. 파드 정의를 수정해서 `.spec.volumes[]` 아래에 볼륨을 추가한다. 볼륨 이름은 원하는 대로 정하고, 컨피그맵 오브젝트를 참조하도록 `.spec.volumes[].configmap.localObjectReference` 필드를 설정한다.
|
||||
1. 파드 정의를 수정해서 `.spec.volumes[]` 아래에 볼륨을 추가한다. 볼륨 이름은 원하는 대로 정하고, 컨피그맵 오브젝트를 참조하도록 `.spec.volumes[].configMap.name` 필드를 설정한다.
|
||||
1. 컨피그맵이 필요한 각 컨테이너에 `.spec.containers[].volumeMounts[]` 를 추가한다. `.spec.containers[].volumeMounts[].readOnly = true` 를 설정하고 컨피그맵이 연결되기를 원하는 곳에 사용하지 않은 디렉터리 이름으로 `.spec.containers[].volumeMounts[].mountPath` 를 지정한다.
|
||||
1. 프로그램이 해당 디렉터리에서 파일을 찾도록 이미지 또는 커맨드 라인을 수정한다. 컨피그맵의 `data` 맵 각 키는 `mountPath` 아래의 파일 이름이 된다.
|
||||
|
||||
|
|
@ -250,4 +250,3 @@ immutable: true
|
|||
* [컨피그맵을 사용하도록 파드 구성하기](/docs/tasks/configure-pod-container/configure-pod-configmap/)를 읽어본다.
|
||||
* 코드를 구성에서 분리하려는 동기를 이해하려면
|
||||
[Twelve-Factor 앱](https://12factor.net/ko/)을 읽어본다.
|
||||
|
||||
|
|
|
|||
|
|
@ -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은 이러한 종류의 스토리지를 사용하여
|
||||
|
|
|
|||
|
|
@ -58,8 +58,8 @@ kubectl config use-context
|
|||
## KUBECONFIG 환경 변수
|
||||
|
||||
`KUBECONFIG` 환경 변수는 kubeconfig 파일 목록을 보유한다.
|
||||
Linux 및 Mac의 경우 이는 콜론(:)으로 구분된 목록이다.
|
||||
Windows는 세미콜론(;)으로 구분한다. `KUBECONFIG` 환경 변수가 필수는 아니다.
|
||||
리눅스 및 Mac의 경우 이는 콜론(:)으로 구분된 목록이다.
|
||||
윈도우는 세미콜론(;)으로 구분한다. `KUBECONFIG` 환경 변수가 필수는 아니다.
|
||||
`KUBECONFIG` 환경 변수가 없으면,
|
||||
`kubectl`은 기본 kubeconfig 파일인 `$HOME/.kube/config`를 사용한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -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/)에서 예시를 확인할 수 있다.
|
||||
|
|
|
|||
|
|
@ -83,7 +83,7 @@ spec:
|
|||
memory: 100Mi
|
||||
```
|
||||
|
||||
어드미션 수행 시에, [어드미션 컨트롤러](https://kubernetes.io/docs/reference/access-authn-authz/admission-controllers/)는
|
||||
어드미션 수행 시에, [어드미션 컨트롤러](/docs/reference/access-authn-authz/admission-controllers/)는
|
||||
런타임클래스에 기술된 `overhead` 를 포함하기 위하여 워크로드의 PodSpec 항목을 갱신한다. 만약 PodSpec이 이미 해당 필드에 정의되어 있으면,
|
||||
파드는 거부된다. 주어진 예제에서, 오직 런타임클래스의 이름만이 정의되어 있기 때문에, 어드미션 컨트롤러는 파드가
|
||||
`overhead` 를 포함하도록 변경한다.
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
```
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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,46 +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) 사용
|
||||
- IAM 역할과 정책을 사용하여 ACR 저장소에 접근을 제어함
|
||||
- IBM 클라우드 컨테이너 레지스트리 사용
|
||||
- IAM 역할 및 정책을 사용하여 IBM 클라우드 컨테이너 레지스트리에 대한 접근 권한 부여
|
||||
- 프라이빗 레지스트리에 대한 인증을 위한 노드 구성
|
||||
- 모든 파드는 구성된 프라이빗 레지스트리를 읽을 수 있음
|
||||
- 클러스터 관리자에 의한 노드 구성 필요
|
||||
|
|
@ -74,139 +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 쿠버네티스 서비스(AKS)를 사용할 때
|
||||
[Azure 컨테이너 레지스트리(ACR)](https://azure.microsoft.com/ko-kr/services/container-registry/)를
|
||||
기본적으로 지원한다.
|
||||
|
||||
AKS 클러스터 서비스 주체(principal)는 ACR 인스턴스에서 `ArcPull` 권한이 있어야 한다. 구성에 대한
|
||||
지침은 [Azure 쿠버네티스 서비스에서 Azure 컨테이너 레지스트리로 인증](https://docs.microsoft.com/ko-kr/azure/aks/cluster-container-registry-integration)을 참조한다. 그런 다음, 전체 ACR 이미지 이름(예: `my_registry.azurecr.io/image:tag`)을 사용한다.
|
||||
|
||||
ACR 관리자 또는 서비스 주체를 사용해서 인증할 수도 있다.
|
||||
어느 경우라도, 인증은 표준 Docker 인증을 통해서 수행된다. 이러한 지침은
|
||||
[azure-cli](https://github.com/azure/azure-cli) 명령줄 도구 사용을 가정한다.
|
||||
|
||||
우선 레지스트리를 생성하고 자격 증명을 만들어야한다. 이에 대한 전체 문서는
|
||||
[Azure 컨테이너 레지스트리 문서](https://docs.microsoft.com/ko-kr/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 >}}
|
||||
|
||||
프라이빗 이미지를 사용하는 파드를 생성하여 검증한다. 예를 들면 다음과 같다.
|
||||
|
||||
|
|
@ -263,11 +186,11 @@ Google 쿠버네티스 엔진에서 동작 중이라면, 이미 각 노드에 Go
|
|||
|
||||
{{< note >}}
|
||||
이 방법은 노드의 구성을 제어할 수 있는 경우에만 적합하다. 이 방법은
|
||||
GCE 및 자동 노드 교체를 수행하는 다른 클라우드 제공자에 대해서는 신뢰성 있게 작동하지
|
||||
않을 것이다.
|
||||
클라우드 제공자가 노드를 관리하고 자동으로 교체한다면 안정적으로
|
||||
작동하지 않을 것이다.
|
||||
{{< /note >}}
|
||||
|
||||
기본적으로, kubelet은 지정된 레지스트리에서 각 이미지를 풀 하려고 할 것이다.
|
||||
기본적으로, kubelet은 지정된 레지스트리에서 각 이미지를 풀 하려고 한다.
|
||||
그러나, 컨테이너의 `imagePullPolicy` 속성이 `IfNotPresent` 또는 `Never`으로 설정되어 있다면,
|
||||
로컬 이미지가 사용된다(우선적으로 또는 배타적으로).
|
||||
|
||||
|
|
@ -281,13 +204,13 @@ GCE 및 자동 노드 교체를 수행하는 다른 클라우드 제공자에
|
|||
### 파드에 ImagePullSecrets 명시
|
||||
|
||||
{{< note >}}
|
||||
이 방법은 현재 Google 쿠버네티스 엔진, GCE 및 노드 생성이 자동화된 모든 클라우드 제공자에게
|
||||
이 방법은 프라이빗 레지스트리의 이미지를 기반으로 컨테이너를 실행하는 데
|
||||
권장된다.
|
||||
{{< /note >}}
|
||||
|
||||
쿠버네티스는 파드에 레지스트리 키를 명시하는 것을 지원한다.
|
||||
쿠버네티스는 파드에 컨테이너 이미지 레지스트리 키를 명시하는 것을 지원한다.
|
||||
|
||||
#### Docker 구성으로 시크릿 생성
|
||||
#### 도커 구성으로 시크릿 생성
|
||||
|
||||
대문자 값을 적절히 대체하여, 다음 커맨드를 실행한다.
|
||||
|
||||
|
|
@ -295,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 >}}
|
||||
파드는 이미지 풀 시크릿을 자신의 네임스페이스에서만 참조할 수 있다.
|
||||
|
|
@ -312,6 +237,8 @@ kubectl create secret docker-registry <name> --docker-server=DOCKER_REGISTRY_SER
|
|||
이제, `imagePullSecrets` 섹션을 파드의 정의에 추가함으로써 해당 시크릿을
|
||||
참조하는 파드를 생성할 수 있다.
|
||||
|
||||
예를 들면 다음과 같다.
|
||||
|
||||
```shell
|
||||
cat <<EOF > pod.yaml
|
||||
apiVersion: v1
|
||||
|
|
@ -337,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. 독점 이미지를 가진 클러스터로, 그 중 일부가 더 엄격한 접근 제어를 필요로 하는 경우.
|
||||
|
|
@ -372,5 +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) 읽어보기
|
||||
|
|
|
|||
|
|
@ -72,7 +72,7 @@ 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)은
|
||||
|
|
@ -97,7 +97,7 @@ spec:
|
|||
|
||||
이것은 Kubelet이 지명된 런타임클래스를 사용하여 해당 파드를 실행하도록 지시할 것이다.
|
||||
만약 지명된 런타임클래스가 없거나, CRI가 상응하는 핸들러를 실행할 수 없는 경우, 파드는
|
||||
`Failed` 터미널 [단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)로 들어간다.
|
||||
`Failed` 터미널 [단계](/ko/docs/concepts/workloads/pods/pod-lifecycle/#파드의-단계-phase)로 들어간다.
|
||||
에러 메시지에 상응하는 [이벤트](/docs/tasks/debug-application-cluster/debug-application-introspection/)를
|
||||
확인한다.
|
||||
|
||||
|
|
@ -106,7 +106,7 @@ spec:
|
|||
|
||||
### CRI 구성 {#cri-configuration}
|
||||
|
||||
CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/docs/setup/production-environment/container-runtimes/)를 확인한다.
|
||||
CRI 런타임 설치에 대한 자세한 내용은 [CRI 설치](/ko/docs/setup/production-environment/container-runtimes/)를 확인한다.
|
||||
|
||||
#### dockershim
|
||||
|
||||
|
|
@ -155,7 +155,7 @@ https://github.com/containerd/cri/blob/master/docs/config.md
|
|||
파드는 거부된다.
|
||||
|
||||
지원되는 노드가 테인트(taint)되어서 다른 런타임클래스 파드가 노드에서 구동되는 것을 막고 있다면,
|
||||
`tolerations`를 런타임클래스에 추가할 수 있다. `nodeSelector`를 사용하면, 어드미션 시
|
||||
`tolerations`를 런타임클래스에 추가할 수 있다. `nodeSelector`를 사용하면, 어드미션 시
|
||||
해당 톨러레이션(toleration)이 파드의 톨러레이션과 병합되어, 실질적으로 각각에 의해 선택된
|
||||
노드의 합집합을 취한다.
|
||||
|
||||
|
|
@ -183,7 +183,5 @@ PodOverhead를 사용하려면, PodOverhead [기능 게이트](/docs/reference/c
|
|||
|
||||
- [런타임클래스 설계](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/) 개념에 대해 읽기
|
||||
- [파드 오버헤드](/ko/docs/concepts/configuration/pod-overhead/) 개념에 대해 읽기
|
||||
- [파드 오버헤드 기능 설계](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/20190226-pod-overhead.md)
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -25,7 +25,7 @@ weight: 10
|
|||
동적 등록을 통해 실행 중인 클러스터에서 커스텀 리소스가 나타나거나 사라질 수 있으며
|
||||
클러스터 관리자는 클러스터 자체와 독립적으로 커스텀 리소스를 업데이트 할 수 있다.
|
||||
커스텀 리소스가 설치되면 사용자는 *파드* 와 같은 빌트인 리소스와 마찬가지로
|
||||
[kubectl](/docs/user-guide/kubectl-overview/)을 사용하여 해당 오브젝트를 생성하고
|
||||
[kubectl](/ko/docs/reference/kubectl/overview/)을 사용하여 해당 오브젝트를 생성하고
|
||||
접근할 수 있다.
|
||||
|
||||
## 커스텀 컨트롤러
|
||||
|
|
@ -234,7 +234,7 @@ CRD는 항상 API 서버의 빌트인 리소스와 동일한 인증, 권한 부
|
|||
|
||||
## 커스텀 리소스에 접근
|
||||
|
||||
쿠버네티스 [클라이언트 라이브러리](/docs/reference/using-api/client-libraries/)를 사용하여 커스텀 리소스에 접근할 수 있다. 모든 클라이언트 라이브러리가 커스텀 리소스를 지원하는 것은 아니다. _Go_ 와 _python_ 클라이언트 라이브러리가 지원한다.
|
||||
쿠버네티스 [클라이언트 라이브러리](/ko/docs/reference/using-api/client-libraries/)를 사용하여 커스텀 리소스에 접근할 수 있다. 모든 클라이언트 라이브러리가 커스텀 리소스를 지원하는 것은 아니다. _Go_ 와 _python_ 클라이언트 라이브러리가 지원한다.
|
||||
|
||||
커스텀 리소스를 추가하면 다음을 사용하여 접근할 수 있다.
|
||||
|
||||
|
|
@ -251,4 +251,3 @@ CRD는 항상 API 서버의 빌트인 리소스와 동일한 인증, 권한 부
|
|||
* [애그리게이션 레이어(aggregation layer)로 쿠버네티스 API 확장](/ko/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/)하는 방법에 대해 배우기.
|
||||
|
||||
* [커스텀리소스데피니션으로 쿠버네티스 API 확장](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)하는 방법에 대해 배우기.
|
||||
|
||||
|
|
|
|||
|
|
@ -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` 로 알려진다.)
|
||||
|
||||
|
|
@ -228,9 +228,7 @@ pluginapi.Device{ID: "25102017", Health: pluginapi.Healthy, Topology:&pluginapi.
|
|||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* 장치 플러그인을 사용한 [GPU 리소스 스케줄링](/docs/tasks/manage-gpus/scheduling-gpus/)에 대해 알아보기
|
||||
* 장치 플러그인을 사용한 [GPU 리소스 스케줄링](/ko/docs/tasks/manage-gpus/scheduling-gpus/)에 대해 알아보기
|
||||
* 노드에서의 [확장 리소스 알리기](/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/)에 대해 알아보기
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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/)에 대해 알아보기
|
||||
|
|
|
|||
|
|
@ -1,8 +1,11 @@
|
|||
---
|
||||
title: 쿠버네티스 컴포넌트
|
||||
content_type: concept
|
||||
description: >
|
||||
쿠버네티스 클러스터는 컴퓨터 집합인 노드 컴포넌트와 컨트롤 플레인
|
||||
컴포넌트로 구성된다.
|
||||
weight: 20
|
||||
card:
|
||||
card:
|
||||
name: concepts
|
||||
weight: 20
|
||||
---
|
||||
|
|
@ -96,7 +99,7 @@ kube-controller-manager와 마찬가지로 cloud-controller-manager는 논리적
|
|||
애드온에 대한 네임스페이스 리소스는 `kube-system` 네임스페이스에 속한다.
|
||||
|
||||
선택된 일부 애드온은 아래에 설명하였고, 사용 가능한 전체 확장 애드온 리스트는
|
||||
[애드온](/docs/concepts/cluster-administration/addons/)을 참조한다.
|
||||
[애드온](/ko/docs/concepts/cluster-administration/addons/)을 참조한다.
|
||||
|
||||
### DNS
|
||||
|
||||
|
|
@ -117,7 +120,7 @@ kube-controller-manager와 마찬가지로 cloud-controller-manager는 논리적
|
|||
|
||||
### 클러스터-레벨 로깅
|
||||
|
||||
[클러스터-레벨 로깅](/docs/concepts/cluster-administration/logging/) 메커니즘은
|
||||
[클러스터-레벨 로깅](/ko/docs/concepts/cluster-administration/logging/) 메커니즘은
|
||||
검색/열람 인터페이스와 함께 중앙 로그 저장소에 컨테이너 로그를 저장하는 책임을 진다.
|
||||
|
||||
|
||||
|
|
@ -127,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/) 읽기
|
||||
|
||||
|
|
|
|||
|
|
@ -2,6 +2,9 @@
|
|||
title: 쿠버네티스 API
|
||||
content_type: concept
|
||||
weight: 30
|
||||
description: >
|
||||
쿠버네티스 API를 사용하면 쿠버네티스 오브젝트들의 상태를 쿼리하고 조작할 수 있다.
|
||||
쿠버네티스 컨트롤 플레인의 핵심은 API 서버와 그것이 노출하는 HTTP API이다. 사용자와 클러스터의 다른 부분 및 모든 외부 컴포넌트는 API 서버를 통해 서로 통신한다.
|
||||
card:
|
||||
name: concepts
|
||||
weight: 30
|
||||
|
|
|
|||
|
|
@ -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/) 준비가 되었는가?
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,7 @@
|
|||
---
|
||||
title: "쿠버네티스 오브젝트로 작업하기"
|
||||
weight: 40
|
||||
description: >
|
||||
쿠버네티스 오브젝트는 쿠버네티스 시스템의 영구 엔티티이다. 쿠버네티스는 이러한 엔티티들을 사용하여 클러스터의 상태를 나타낸다.
|
||||
쿠버네티스 오브젝트 모델과 쿠버네티스 오브젝트를 사용하는 방법에 대해 학습한다.
|
||||
---
|
||||
|
|
|
|||
|
|
@ -51,13 +51,13 @@ weight: 50
|
|||
* 경량 롤아웃 도구 메타데이터. 예: 구성 또는 체크포인트
|
||||
|
||||
* 책임자의 전화번호 또는 호출기 번호, 또는 팀 웹 사이트 같은
|
||||
해당 정보를 찾을 수 있는 디렉토리 진입점.
|
||||
해당 정보를 찾을 수 있는 디렉터리 진입점.
|
||||
|
||||
* 행동을 수정하거나 비표준 기능을 수행하기 위한
|
||||
최종 사용자의 지시 사항.
|
||||
|
||||
어노테이션을 사용하는 대신, 이 유형의 정보를
|
||||
외부 데이터베이스 또는 디렉토리에 저장할 수 있지만, 이는 배포, 관리, 인트로스펙션(introspection) 등을 위한
|
||||
외부 데이터베이스 또는 디렉터리에 저장할 수 있지만, 이는 배포, 관리, 인트로스펙션(introspection) 등을 위한
|
||||
공유 클라이언트 라이브러리와 도구 생성을
|
||||
훨씬 더 어렵게 만들 수 있다.
|
||||
|
||||
|
|
|
|||
|
|
@ -9,7 +9,7 @@ _필드 셀렉터_ 는 한 개 이상의 리소스 필드 값에 따라 [쿠버
|
|||
* `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
|
||||
|
|
|
|||
|
|
@ -87,7 +87,7 @@ API는 현재 _일치성 기준_ 과 _집합성 기준_ 이라는 두 종류의
|
|||
문서화해야 한다.
|
||||
|
||||
{{< note >}}
|
||||
레플리카 셋과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충하는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다.
|
||||
레플리카셋(ReplicaSet)과 같은 일부 API 유형에서 두 인스턴스의 레이블 셀렉터는 네임스페이스 내에서 겹치지 않아야 한다. 그렇지 않으면 컨트롤러는 상충하는 명령으로 보고, 얼마나 많은 복제본이 필요한지 알 수 없다.
|
||||
{{< /note >}}
|
||||
|
||||
{{< caution >}}
|
||||
|
|
|
|||
|
|
@ -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)에 대해 더 배우기.
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -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,7 +118,7 @@ kubectl replace -f nginx.yaml
|
|||
|
||||
선언형 오브젝트 구성에 비해 단점은 다음과 같다.
|
||||
|
||||
- 명령형 오브젝트 구성은 디렉토리가 아닌, 파일에 대해 가장 효과가 있다.
|
||||
- 명령형 오브젝트 구성은 디렉터리가 아닌, 파일에 대해 가장 효과가 있다.
|
||||
- 활성 오브젝트에 대한 업데이트는 구성 파일에 반영되어야 한다. 그렇지 않으면 다음 교체 중에 손실된다.
|
||||
|
||||
## 선언형 오브젝트 구성
|
||||
|
|
@ -133,19 +127,19 @@ kubectl replace -f nginx.yaml
|
|||
구성 파일을 대상으로 작동시키지만, 사용자는 파일에서 수행 할
|
||||
작업을 정의하지 않는다. 생성, 업데이트, 그리고 삭제 작업은
|
||||
`kubectl`에 의해 오브젝트 마다 자동으로 감지된다. 이를 통해 다른 오브젝트에 대해
|
||||
다른 조작이 필요할 수 있는 디렉토리에서 작업할 수 있다.
|
||||
다른 조작이 필요할 수 있는 디렉터리에서 작업할 수 있다.
|
||||
|
||||
{{< note >}}
|
||||
선언형 오브젝트 구성은 변경 사항이 오브젝트 구성 파일에
|
||||
다시 병합되지 않더라도 다른 작성자가 작성한 변경 사항을 유지한다.
|
||||
선언형 오브젝트 구성은 변경 사항이 오브젝트 구성 파일에
|
||||
다시 병합되지 않더라도 다른 작성자가 작성한 변경 사항을 유지한다.
|
||||
이것은 전체 오브젝트 구성 변경을 위한 `replace` API를
|
||||
사용하는 대신, `patch` API를 사용하여 인지되는 차이만
|
||||
사용하는 대신, `patch` API를 사용하여 인지되는 차이만
|
||||
작성하기 때문에 가능하다.
|
||||
{{< /note >}}
|
||||
|
||||
### 예시
|
||||
|
||||
`configs` 디렉토리 내 모든 오브젝트 구성 파일을 처리하고 활성 오브젝트를
|
||||
`configs` 디렉터리 내 모든 오브젝트 구성 파일을 처리하고 활성 오브젝트를
|
||||
생성 또는 패치한다. 먼저 어떠한 변경이 이루어지게 될지 알아보기 위해 `diff`
|
||||
하고 나서 적용할 수 있다.
|
||||
|
||||
|
|
@ -154,7 +148,7 @@ kubectl diff -f configs/
|
|||
kubectl apply -f configs/
|
||||
```
|
||||
|
||||
재귀적으로 디렉토리를 처리한다.
|
||||
재귀적으로 디렉터리를 처리한다.
|
||||
|
||||
```sh
|
||||
kubectl diff -R -f configs/
|
||||
|
|
@ -166,7 +160,7 @@ kubectl apply -R -f configs/
|
|||
명령형 오브젝트 구성에 비해 장점은 다음과 같다.
|
||||
|
||||
- 활성 오브젝트에 직접 작성된 변경 사항은 구성 파일로 다시 병합되지 않더라도 유지된다.
|
||||
- 선언형 오브젝트 구성은 디렉토리에서의 작업 및 오브젝트 별 작업 유형(생성, 패치, 삭제)의 자동 감지에 더 나은 지원을 제공한다.
|
||||
- 선언형 오브젝트 구성은 디렉터리에서의 작업 및 오브젝트 별 작업 유형(생성, 패치, 삭제)의 자동 감지에 더 나은 지원을 제공한다.
|
||||
|
||||
명령형 오브젝트 구성에 비해 단점은 다음과 같다.
|
||||
|
||||
|
|
@ -185,5 +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" >}}/)
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -61,11 +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/).
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -455,7 +455,7 @@ allowedHostPaths:
|
|||
(다른 컨테이너들에 있는 데이터를 읽고, 시스템 서비스의 자격 증명을 어뷰징(abusing)하는 등)할
|
||||
수 있도록 만드는 다양한 방법이 있다. 예를 들면, Kubelet과 같다.
|
||||
|
||||
쓰기 가능한 hostPath 디렉토리 볼륨을 사용하면, 컨테이너가 `pathPrefix` 외부의
|
||||
쓰기 가능한 hostPath 디렉터리 볼륨을 사용하면, 컨테이너가 `pathPrefix` 외부의
|
||||
호스트 파일시스템에 대한 통행을 허용하는 방식으로 컨테이너의 파일시스템 쓰기(write)를 허용한다.
|
||||
쿠버네티스 1.11 이상 버전에서 사용 가능한 `readOnly: true`는 지정된 `pathPrefix`에 대한
|
||||
접근을 효과적으로 제한하기 위해 **모든** `allowedHostPaths`에서 사용해야 한다.
|
||||
|
|
@ -592,7 +592,7 @@ spec:
|
|||
### AppArmor
|
||||
|
||||
파드시큐리티폴리시의 어노테이션을 통해 제어된다. [AppArmor
|
||||
문서](/docs/tutorials/clusters/apparmor/#podsecuritypolicy-annotations)를 참고하길 바란다.
|
||||
문서](/ko/docs/tutorials/clusters/apparmor/#podsecuritypolicy-annotations)를 참고하길 바란다.
|
||||
|
||||
### Seccomp
|
||||
|
||||
|
|
@ -636,4 +636,3 @@ spec:
|
|||
폴리시 권장 사항에 대해서는 [파드 보안 표준](/docs/concepts/security/pod-security-standards/)을 참조한다.
|
||||
|
||||
API 세부 정보는 [파드 시큐리티 폴리시 레퍼런스](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 참조한다.
|
||||
|
||||
|
|
|
|||
|
|
@ -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-서브도메인-이름)이어야 한다.
|
||||
|
|
@ -75,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`을 모두 지정하는 것은 의미가 없다. 따라서 확장된
|
||||
|
|
@ -197,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` 필드를 사용하여 파드의 우선 순위에 따라 파드의 시스템 리소스 사용을
|
||||
제어할 수 있다.
|
||||
|
||||
|
|
@ -600,4 +600,3 @@ plugins:
|
|||
|
||||
|
||||
자세한 내용은 [리소스쿼터 디자인 문서](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.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는 원하거나 필요에 따라 자체 스케줄링 컴포넌트를
|
||||
|
|
|
|||
|
|
@ -171,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)
|
||||
|
|
|
|||
|
|
@ -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)이다.
|
||||
컴퓨팅 접근 방식을 강화하며, 소프트웨어 시스템의 보안을 위한 모범 사례로
|
||||
널리 알려져 있다.
|
||||
{{< /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,43 +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/)에 대한 조언을 읽고 따른다.
|
||||
|
||||
### 클러스터 _내_ 컴포넌트(애플리케이션)
|
||||
### 클러스터 내 컴포넌트(애플리케이션) {#cluster-applications}
|
||||
|
||||
애플리케이션의 공격 영역에 따라, 보안의 특정 측면에
|
||||
중점을 둘 수 있다. 예를 들어, 다른 리소스 체인에 중요한 서비스(서비스 A)와
|
||||
리소스 소진 공격에 취약한 별도의 작업 부하(서비스 B)를 실행하는 경우,
|
||||
리소스 제한을 설정하지 않은 서비스 B에 의해
|
||||
서비스 A 또한 손상시킬 위험이 있다. 다음은 쿠버네티스에서
|
||||
실행 중인 워크로드를 보호할 때 고려해야 할 사항에 대한 링크 표이다.
|
||||
서비스 B의 리소스를 제한하지 않으면
|
||||
서비스 A가 손상될 위험이 높다. 다음은 쿠버네티스에서
|
||||
실행되는 워크로드를 보호하기 위한 보안 문제 및 권장 사항이 나와 있는 표이다.
|
||||
|
||||
워크로드 보안에서 고려할 영역 | 추천 |
|
||||
------------------------------ | ------------ |
|
||||
|
|
@ -112,51 +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/)
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
@ -57,43 +58,44 @@ fe00::2 ip6-allrouters
|
|||
기본적으로, `hosts` 파일은 `localhost`와 자기 자신의 호스트네임과 같은 IPv4와 IPv6
|
||||
상용구들만 포함하고 있다.
|
||||
|
||||
## HostAliases를 사용하여 추가 항목들 추가하기
|
||||
## hostAliases를 사용하여 추가 항목들 추가하기
|
||||
|
||||
기본 상용구 이외에, `foo.local`, `bar.local`이 `127.0.0.1`로,
|
||||
`foo.remote`, `bar.remote`가 `10.1.2.3`로 해석될 수 있도록
|
||||
추가 항목들을 `hosts` 파일에 추가할 수 있으며,
|
||||
이는 `.spec.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
|
||||
|
|
@ -110,14 +112,16 @@ fe00::2 ip6-allrouters
|
|||
|
||||
가장 마지막에 추가 항목들이 정의되어 있는 것을 확인할 수 있다.
|
||||
|
||||
## 왜 Kubelet이 호스트 파일을 관리하는가?
|
||||
## 왜 Kubelet이 호스트 파일을 관리하는가? {#why-does-kubelet-manage-the-hosts-file}
|
||||
|
||||
컨테이너가 이미 시작되고 난 후 도커가 파일을
|
||||
[수정](https://github.com/moby/moby/issues/17190)하는 것을 방지하기 위해
|
||||
Kubelet은 파드의 각 컨테이너의 `hosts` 파일을
|
||||
[관리](https://github.com/kubernetes/kubernetes/issues/14633)한다.
|
||||
|
||||
호스트 파일이 관리된다는 특성으로 인해, 컨테이너 재시작이나 파드 리스케줄 이벤트로
|
||||
`hosts` 파일이 Kubelet에 의해 다시 마운트될 때마다 사용자가 작성한 모든 내용이
|
||||
덮어 쓰인다. 따라서, 호스트 파일의 내용을
|
||||
직접 바꾸는 것은 권장하지 않는다.
|
||||
{{< caution >}}
|
||||
컨테이너 내부의 호스트 파일을 수동으로 변경하면 안된다.
|
||||
|
||||
호스트 파일을 수동으로 변경하면,
|
||||
컨테이너가 종료되면 변경 사항이 손실된다.
|
||||
{{< /caution >}}
|
||||
|
|
|
|||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue