diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index 76bf2cd73a..df9f571313 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -179,6 +179,7 @@ aliases: - tanjunchen - tengqm - xichengliudui + - ydFu # zhangxiaoyu-zidif sig-docs-pt-owners: # Admins for Portuguese content - edsoncelio @@ -249,7 +250,6 @@ aliases: - cpanato # SIG Technical Lead - jeremyrickard # SIG Technical Lead - justaugustus # SIG Chair - - LappleApple # SIG Program Manager - puerco # SIG Technical Lead - saschagrunert # SIG Chair release-engineering-approvers: diff --git a/README-zh.md b/README-zh.md index 700777d7a1..00a7ef1a24 100644 --- a/README-zh.md +++ b/README-zh.md @@ -13,7 +13,14 @@ This repository contains the assets required to build the [Kubernetes website an 我们非常高兴您想要参与贡献！ +- [为文档做贡献](#为文档做贡献) +- [README.md 本地化](#readmemd-本地化) + + @@ -46,7 +53,7 @@ Before you start, install the dependencies. Clone the repository and navigate to --> 开始前，先安装这些依赖。克隆本仓库并进入对应目录： -``` +```bash git clone https://github.com/kubernetes/website.git cd website ``` @@ -57,7 +64,7 @@ The Kubernetes website uses the [Docsy Hugo theme](https://github.com/google/doc Kubernetes 网站使用的是 [Docsy Hugo 主题](https://github.com/google/docsy#readme)。 即使你打算在容器中运行网站，我们也强烈建议你通过运行以下命令来引入子模块和其他开发依赖项： -``` +```bash # pull in the Docsy submodule git submodule update --init --recursive --depth 1 ``` @@ -72,15 +79,23 @@ To build the site in a container, run the following to build the container image 要在容器中构建网站，请通过以下命令来构建容器镜像并运行： -``` +```bash make container-image make container-serve ``` -启动浏览器，打开 http://localhost:1313 来查看网站。 +如果您看到错误，这可能意味着 hugo 容器没有足够的可用计算资源。 +要解决这个问题，请增加机器（[MacOSX](https://docs.docker.com/docker-for-mac/#resources) +和 [Windows](https://docs.docker.com/docker-for-windows/#resources)）上 +Docker 允许的 CPU 和内存使用量。 + + +启动浏览器，打开 来查看网站。 当你对源文件作出修改时，Hugo 会更新网站并强制浏览器执行刷新操作。 上述命令会在端口 1313 上启动本地 Hugo 服务器。 -启动浏览器，打开 http://localhost:1313 来查看网站。 +启动浏览器，打开 来查看网站。 当你对源文件作出修改时，Hugo 会更新网站并强制浏览器执行刷新操作。 + +## 构建 API 参考页面 + + +位于 `content/en/docs/reference/kubernetes-api` 的 API 参考页面是根据 Swagger 规范构建的，使用 。 + +要更新新 Kubernetes 版本的参考页面，请执行以下步骤： + + +1. 拉取 `api-ref-generator` 子模块： + + ```bash + git submodule update --init --recursive --depth 1 + ``` + + +2. 更新 Swagger 规范： + + ```bash + curl 'https://raw.githubusercontent.com/kubernetes/kubernetes/master/api/openapi-spec/swagger.json' > api-ref-assets/api/swagger.json + ``` + + +3. 在 `api-ref-assets/config/` 中，调整文件 `toc.yaml` 和 `fields.yaml` 以反映新版本的变化。 + + +4. 接下来，构建页面： + + ```bash + make api-reference + ``` + + + 您可以通过从容器映像创建和提供站点来在本地测试结果： + + ```bash + make container-image + make container-serve + ``` + + + 在 Web 浏览器中，打开 查看 API 参考。 + + +5. 当所有新的更改都反映到配置文件 `toc.yaml` 和 `fields.yaml` 中时，使用新生成的 API 参考页面创建一个 Pull Request。 + ## 故障排除 @@ -135,18 +216,24 @@ If you run `make serve` on macOS and receive the following error: 如果在 macOS 上运行 `make serve` 收到以下错误： -``` +```bash ERROR 2020/08/01 19:09:18 Error: listen tcp 127.0.0.1:1313: socket: too many open files make: *** [serve] Error 1 ``` + 试着查看一下当前打开文件数的限制： `launchctl limit maxfiles` -然后运行以下命令（参考https://gist.github.com/tombigel/d503800a282fcadbee14b537735d202c）： + +然后运行以下命令（参考 ）： -``` +```shell #!/bin/sh # These are the original gist links, linking to my gists now. @@ -165,6 +252,9 @@ sudo chown root:wheel /Library/LaunchDaemons/limit.maxproc.plist sudo launchctl load -w /Library/LaunchDaemons/limit.maxfiles.plist ``` + 这适用于 Catalina 和 Mojave macOS。 # 参与 SIG Docs 工作 @@ -184,20 +275,21 @@ You can also reach the maintainers of this project at: 你也可以通过以下渠道联系本项目的维护人员： -- [Slack](https://kubernetes.slack.com/messages/sig-docs) [加入Slack](https://slack.k8s.io/) +- [Slack](https://kubernetes.slack.com/messages/sig-docs) + - [获得此 Slack 的邀请](https://slack.k8s.io/) - [邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) # 为文档做贡献 你也可以点击屏幕右上方区域的 **Fork** 按钮，在你自己的 GitHub -账号下创建本仓库的拷贝。此拷贝被称作 *fork*。 +账号下创建本仓库的拷贝。此拷贝被称作 _fork_。 你可以在自己的拷贝中任意地修改文档，并在你已准备好将所作修改提交给我们时， 在你自己的拷贝下创建一个拉取请求（Pull Request），以便让我们知道。 @@ -208,7 +300,7 @@ Once your pull request is created, a Kubernetes reviewer will take responsibilit 还要提醒的一点，有时可能会有不止一个 Kubernetes 评审人为你提供反馈意见。 有时候，某个评审人的意见和另一个最初被指派的评审人的意见不同。 @@ -220,17 +312,65 @@ Furthermore, in some cases, one of your reviewers might ask for a technical revi 有关为 Kubernetes 文档做出贡献的更多信息，请参阅： -* [贡献 Kubernetes 文档](https://kubernetes.io/docs/contribute/) -* [页面内容类型](https://kubernetes.io/docs/contribute/style/page-content-types/) -* [文档风格指南](https://kubernetes.io/docs/contribute/style/style-guide/) -* [本地化 Kubernetes 文档](https://kubernetes.io/docs/contribute/localization/) +- [贡献 Kubernetes 文档](https://kubernetes.io/docs/contribute/) +- [页面内容类型](https://kubernetes.io/docs/contribute/style/page-content-types/) +- [文档风格指南](https://kubernetes.io/docs/contribute/style/style-guide/) +- [本地化 Kubernetes 文档](https://kubernetes.io/docs/contribute/localization/) + + +### 新贡献者大使 + + +如果您在贡献时需要帮助，[新贡献者大使](https://kubernetes.io/docs/contribute/advanced/#serve-as-a-new-contributor-ambassador)是一个很好的联系人。 +这些是 SIG Docs 批准者，其职责包括指导新贡献者并帮助他们完成最初的几个拉取请求。 +联系新贡献者大使的最佳地点是 [Kubernetes Slack](https://slack.k8s.io/)。 +SIG Docs 的当前新贡献者大使： + + +| 姓名 | Slack | GitHub | +| -------------------------- | -------------------------- | -------------------------- | +| Arsh Sharma | @arsh | @RinkiyaKeDad | + + +## `README.md` 本地化 + + +| 语言 | 语言 | +| -------------------------- | -------------------------- | +| [中文](README-zh.md) | [韩语](README-ko.md) | +| [法语](README-fr.md) | [波兰语](README-pl.md) | +| [德语](README-de.md) | [葡萄牙语](README-pt.md) | +| [印地语](README-hi.md) | [俄语](README-ru.md) | +| [印尼语](README-id.md) | [西班牙语](README-es.md) | +| [意大利语](README-it.md) | [乌克兰语](README-uk.md) | +| [日语](README-ja.md) | [越南语](README-vi.md) | # 中文本地化 @@ -241,19 +381,19 @@ For more information about contributing to the Kubernetes documentation, see: * [Slack channel](https://kubernetes.slack.com/messages/kubernetes-docs-zh) -# 行为准则 +## 行为准则 参与 Kubernetes 社区受 [CNCF 行为准则](https://github.com/cncf/foundation/blob/master/code-of-conduct.md) 约束。 -# 感谢！ +## 感谢你 Kubernetes 因为社区的参与而蓬勃发展，感谢您对我们网站和文档的贡献！ diff --git a/assets/scss/_custom.scss b/assets/scss/_custom.scss index 1ebe8c81fa..db0263d991 100644 --- a/assets/scss/_custom.scss +++ b/assets/scss/_custom.scss @@ -634,12 +634,12 @@ body.td-documentation { a { color: inherit; - border-bottom: 1px solid #fff; + text-decoration: underline; } a:hover { color: inherit; - border-bottom: none; + text-decoration: initial; } } @@ -648,6 +648,9 @@ body.td-documentation { } #announcement { + // default background is blue; overrides are possible + color: #fff; + .announcement-main { margin-left: auto; margin-right: auto; @@ -660,9 +663,8 @@ body.td-documentation { } - /* always white */ h1, h2, h3, h4, h5, h6, p * { - color: #ffffff; + color: inherit; /* defaults to white */ background: transparent; img.event-logo { diff --git a/config.toml b/config.toml index 6ad3ac39f3..e302128f42 100644 --- a/config.toml +++ b/config.toml @@ -122,7 +122,7 @@ id = "UA-00000000-0" [params] copyright_k8s = "The Kubernetes Authors" -copyright_linux = "Copyright © 2020 The Linux Foundation ®." +copyright_linux = "Copyright © 2020 The Linux Foundation ®." # privacy_policy = "https://policies.google.com/privacy" @@ -155,10 +155,10 @@ githubWebsiteRaw = "raw.githubusercontent.com/kubernetes/website" # GitHub repository link for editing a page and opening issues. github_repo = "https://github.com/kubernetes/website" -#Searching +# Searching k8s_search = true -#The following search parameters are specific to Docsy's implementation. Kubernetes implementes its own search-related partials and scripts. +# The following search parameters are specific to Docsy's implementation. Kubernetes implementes its own search-related partials and scripts. # Google Custom Search Engine ID. Remove or comment out to disable search. #gcs_engine_id = "011737558837375720776:fsdu1nryfng" @@ -221,11 +221,11 @@ sidebar_menu_compact = false sidebar_menu_foldable = true # https://github.com/gohugoio/hugo/issues/8918#issuecomment-903314696 sidebar_cache_limit = 1 -# Set to true to disable breadcrumb navigation. +# Set to true to disable breadcrumb navigation. breadcrumb_disable = false -# Set to true to hide the sidebar search box (the top nav search box will still be displayed if search is enabled) +# Set to true to hide the sidebar search box (the top nav search box will still be displayed if search is enabled) sidebar_search_disable = false -# Set to false if you don't want to display a logo (/assets/icons/logo.svg) in the top nav bar +# Set to false if you don't want to display a logo (/assets/icons/logo.svg) in the top nav bar navbar_logo = true # Set to true to disable the About link in the site footer footer_about_disable = false @@ -246,50 +246,50 @@ no = 'Sorry to hear that. Please ` markers along with indentation are used to ensure that splitting at a +klog header at the start of a line is reliable and the resulting output is human-readable: + +``` +I1126 10:31:50.378204 121736 structured_logging.go:59] "using InfoS" longData=< + {Name:long Data:Multiple + lines + with quite a bit + of text. internal:0} + > +I1126 10:31:50.378228 121736 structured_logging.go:60] "using InfoS with\nthe message across multiple lines" int=1 stringData=< + long: Multiple + lines + with quite a bit + of text. + > str="another value" +``` + +Note that the log message itself is printed with quoting. It is meant to be a +fixed string that identifies a log entry, so newlines should be avoided there. + +Before Kubernetes 1.24, some log calls in kube-scheduler still used `klog.Info` +for multi-line strings to avoid the unreadable output. Now all log calls have +been updated to support structured logging. + +## Contextual logging + +[Contextual logging](https://github.com/kubernetes/enhancements/blob/master/keps/sig-instrumentation/3077-contextual-logging/README.md) +is based on the [go-logr API](https://github.com/go-logr/logr#a-minimal-logging-api-for-go). The key +idea is that libraries are passed a logger instance by their caller and use +that for logging instead of accessing a global logger. The binary decides about +the logging implementation, not the libraries. The go-logr API is designed +around structured logging and supports attaching additional information to a +logger. + +This enables additional use cases: + +- The caller can attach additional information to a logger: + - [`WithName`](https://pkg.go.dev/github.com/go-logr/logr#Logger.WithName) adds a prefix + - [`WithValues`](https://pkg.go.dev/github.com/go-logr/logr#Logger.WithValues) adds key/value pairs + + When passing this extended logger into a function and a function uses it + instead of the global logger, the additional information is + then included in all log entries, without having to modify the code that + generates the log entries. This is useful in highly parallel applications + where it can become hard to identify all log entries for a certain operation + because the output from different operations gets interleaved. + +- When running unit tests, log output can be associated with the current test. + Then when a test fails, only the log output of the failed test gets shown + by `go test`. That output can also be more verbose by default because it + will not get shown for successful tests. Tests can be run in parallel + without interleaving their output. + +One of the design decisions for contextual logging was to allow attaching a +logger as value to a `context.Context`. Since the logger encapsulates all +aspects of the intended logging for the call, it is *part* of the context and +not just *using* it. A practical advantage is that many APIs already have a +`ctx` parameter or adding one has additional advantages, like being able to get +rid of `context.TODO()` calls inside the functions. + +Another decision was to not break compatibility with klog v2: + +- Libraries that use the traditional klog logging calls in a binary that has + set up contextual logging will work and log through the logging backend + chosen by the binary. However, such log output will not include the + additional information and will not work well in unit tests, so libraries + should be modified to support contextual logging. The [migration guide](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/migration-to-structured-logging.md) + for structured logging has been extended to also cover contextual logging. + +- When a library supports contextual logging and retrieves a logger from its + context, it will still work in a binary that does not initialize contextual + logging because it will get a logger that logs through klog. + +In Kubernetes 1.24, contextual logging is a new alpha feature with +`ContextualLogging` as feature gate. When disabled (the default), the new klog +API calls for contextual logging (see below) become no-ops to avoid performance +or functional regressions. + +No Kubernetes component has been converted yet. An [example program](https://github.com/kubernetes/kubernetes/blob/v1.24.0-beta.0/staging/src/k8s.io/component-base/logs/example/cmd/logger.go) +in the Kubernetes repository demonstrates how to enable contextual logging in a +binary and how the output depends on the binary's parameters: + +```console +$ cd $GOPATH/src/k8s.io/kubernetes/staging/src/k8s.io/component-base/logs/example/cmd/ +$ go run . --help +... + --feature-gates mapStringBool A set of key=value pairs that describe feature gates for alpha/experimental features. Options are: + AllAlpha=true|false (ALPHA - default=false) + AllBeta=true|false (BETA - default=false) + ContextualLogging=true|false (ALPHA - default=false) +$ go run . --feature-gates ContextualLogging=true +... +I0404 18:00:02.916429 451895 logger.go:94] "example/myname: runtime" foo="bar" duration="1m0s" +I0404 18:00:02.916447 451895 logger.go:95] "example: another runtime" foo="bar" duration="1m0s" +``` + +The `example` prefix and `foo="bar"` were added by the caller of the function +which logs the `runtime` message and `duration="1m0s"` value. + +The sample code for klog includes an +[example](https://github.com/kubernetes/klog/blob/v2.60.1/ktesting/example/example_test.go) +for a unit test with per-test output. + +## klog enhancements + +### Contextual logging API + +The following calls manage the lookup of a logger: + +[`FromContext`](https://pkg.go.dev/k8s.io/klog/v2#FromContext) +: from a `context` parameter, with fallback to the global logger + +[`Background`](https://pkg.go.dev/k8s.io/klog/v2#Background) +: the global fallback, with no intention to support contextual logging + +[`TODO`](https://pkg.go.dev/k8s.io/klog/v2#TODO) +: the global fallback, but only as a temporary solution until the function gets extended to accept + a logger through its parameters + +[`SetLoggerWithOptions`](https://pkg.go.dev/k8s.io/klog/v2#SetLoggerWithOptions) +: changes the fallback logger; when called with [`ContextualLogger(true)`](https://pkg.go.dev/k8s.io/klog/v2#ContextualLogger), + the logger is ready to be called directly, in which case logging will be done + without going through klog + +To support the feature gate mechanism in Kubernetes, klog has wrapper calls for +the corresponding go-logr calls and a global boolean controlling their behavior: + +- [`LoggerWithName`](https://pkg.go.dev/k8s.io/klog/v2#LoggerWithName) +- [`LoggerWithValues`](https://pkg.go.dev/k8s.io/klog/v2#LoggerWithValues) +- [`NewContext`](https://pkg.go.dev/k8s.io/klog/v2#NewContext) +- [`EnableContextualLogging`](https://pkg.go.dev/k8s.io/klog/v2#EnableContextualLogging) + +Usage of those functions in Kubernetes code is enforced with a linter +check. The klog default for contextual logging is to enable the functionality +because it is considered stable in klog. It is only in Kubernetes binaries +where that default gets overridden and (in some binaries) controlled via the +`--feature-gate` parameter. + +### ktesting logger + +The new [ktesting](https://pkg.go.dev/k8s.io/klog/v2@v2.60.1/ktesting) package +implements logging through `testing.T` using klog's text output format. It has +a [single API call](https://pkg.go.dev/k8s.io/klog/v2@v2.60.1/ktesting#NewTestContext) for +instrumenting a test case and [support for command line flags](https://pkg.go.dev/k8s.io/klog/v2@v2.60.1/ktesting/init). + +### klogr + +[`klog/klogr`](https://pkg.go.dev/k8s.io/klog/v2@v2.60.1/klogr) continues to be +supported and it's default behavior is unchanged: it formats structured log +entries using its own, custom format and prints the result via klog. + +However, this usage is discouraged because that format is neither +machine-readable (in contrast to real JSON output as produced by zapr, the +go-logr implementation used by Kubernetes) nor human-friendly (in contrast to +the klog text format). + +Instead, a klogr instance should be created with +[`WithFormat(FormatKlog)`](https://pkg.go.dev/k8s.io/klog/v2@v2.60.1/klogr#WithFormat) +which chooses the klog text format. A simpler construction method with the same +result is the new +[`klog.NewKlogr`](https://pkg.go.dev/k8s.io/klog/v2#NewKlogr). That is the +logger that klog returns as fallback when nothing else is configured. + +### Reusable output test + +A lot of go-logr implementations have very similar unit tests where they check +the result of certain log calls. If a developer didn't know about certain +caveats like for example a `String` function that panics when called, then it +is likely that both the handling of such caveats and the unit test are missing. + +[`klog.test`](https://pkg.go.dev/k8s.io/klog/v2@v2.60.1/test) is a reusable set +of test cases that can be applied to a go-logr implementation. + +### Output flushing + +klog used to start a goroutine unconditionally during `init` which flushed +buffered data at a hard-coded interval. Now that goroutine is only started on +demand (i.e. when writing to files with buffering) and can be controlled with +[`StopFlushDaemon`](https://pkg.go.dev/k8s.io/klog/v2#StopFlushDaemon) and +[`StartFlushDaemon`](https://pkg.go.dev/k8s.io/klog/v2#StartFlushDaemon). + +When a go-logr implementation buffers data, flushing that data can be +integrated into [`klog.Flush`](https://pkg.go.dev/k8s.io/klog/v2#Flush) by +registering the logger with the +[`FlushLogger`](https://pkg.go.dev/k8s.io/klog/v2#FlushLogger) option. + +### Various other changes + +For a description of all other enhancements see in the [release notes](https://github.com/kubernetes/klog/releases). + +## logcheck + +Originally designed as a linter for structured log calls, the + [`logcheck`](https://github.com/kubernetes/klog/tree/788efcdee1e9be0bfbe5b076343d447314f2377e/hack/tools/logcheck) +tool has been enhanced to support also contextual logging and traditional klog +log calls. These enhanced checks already found bugs in Kubernetes, like calling +`klog.Info` instead of `klog.Infof` with a format string and parameters. + +It can be included as a plugin in a `golangci-lint` invocation, which is how +[Kubernetes uses it now](https://github.com/kubernetes/kubernetes/commit/17e3c555c5115f8c9176bae10ba45baa04d23a7b), +or get invoked stand-alone. + +We are in the process of [moving the tool](https://github.com/kubernetes/klog/issues/312) into a new repository because it isn't +really related to klog and its releases should be tracked and tagged properly. + +## Next steps + +The [Structured Logging WG](https://github.com/kubernetes/community/tree/master/wg-structured-logging) +is always looking for new contributors. The migration +away from C-style logging is now going to target structured, contextual logging +in one step to reduce the overall code churn and number of PRs. Changing log +calls is good first contribution to Kubernetes and an opportunity to get to +know code in various different areas. diff --git a/content/en/blog/_posts/2022-05-27-maxunavailable-for-statefulset.md b/content/en/blog/_posts/2022-05-27-maxunavailable-for-statefulset.md new file mode 100644 index 0000000000..aa6257eb3e --- /dev/null +++ b/content/en/blog/_posts/2022-05-27-maxunavailable-for-statefulset.md @@ -0,0 +1,148 @@ +--- +layout: blog +title: 'Kubernetes 1.24: Maximum Unavailable Replicas for StatefulSet' +date: 2022-05-27 +slug: maxunavailable-for-statefulset +--- + +**Author:** Mayank Kumar (Salesforce) + +Kubernetes [StatefulSets](/docs/concepts/workloads/controllers/statefulset/), since their introduction in +1.5 and becoming stable in 1.9, have been widely used to run stateful applications. They provide stable pod identity, persistent +per pod storage and ordered graceful deployment, scaling and rolling updates. You can think of StatefulSet as the atomic building +block for running complex stateful applications. As the use of Kubernetes has grown, so has the number of scenarios requiring +StatefulSets. Many of these scenarios, require faster rolling updates than the currently supported one-pod-at-a-time updates, in the +case where you're using the `OrderedReady` Pod management policy for a StatefulSet. + + +Here are some examples: + +- I am using a StatefulSet to orchestrate a multi-instance, cache based application where the size of the cache is large. The cache + starts cold and requires some siginificant amount of time before the container can start. There could be more initial startup tasks + that are required. A RollingUpdate on this StatefulSet would take a lot of time before the application is fully updated. If the + StatefulSet supported updating more than one pod at a time, it would result in a much faster update. + +- My stateful application is composed of leaders and followers or one writer and multiple readers. I have multiple readers or + followers and my application can tolerate multiple pods going down at the same time. I want to update this application more than + one pod at a time so that i get the new updates rolled out quickly, especially if the number of instances of my application are + large. Note that my application still requires unique identity per pod. + + +In order to support such scenarios, Kubernetes 1.24 includes a new alpha feature to help. Before you can use the new feature you must +enable the `MaxUnavailableStatefulSet` feature flag. Once you enable that, you can specify a new field called `maxUnavailable`, part +of the `spec` for a StatefulSet. For example: + +``` +apiVersion: apps/v1 +kind: StatefulSet +metadata: + name: web + namespace: default +spec: + podManagementPolicy: OrderedReady # you must set OrderedReady + replicas: 5 + selector: + matchLabels: + app: nginx + template: + metadata: + labels: + app: nginx + spec: + containers: + - image: k8s.gcr.io/nginx-slim:0.8 + imagePullPolicy: IfNotPresent + name: nginx + updateStrategy: + rollingUpdate: + maxUnavailable: 2 # this is the new alpha field, whose default value is 1 + partition: 0 + type: RollingUpdate +``` + +If you enable the new feature and you don't specify a value for `maxUnavailable` in a StatefulSet, Kubernetes applies a default +`maxUnavailable: 1`. This matches the behavior you would see if you don't enable the new feature. + +I'll run through a scenario based on that example manifest to demonstrate how this feature works. I will deploy a StatefulSet that +has 5 replicas, with `maxUnavailable` set to 2 and `partition` set to 0. + +I can trigger a rolling update by changing the image to `k8s.gcr.io/nginx-slim:0.9`. Once I initiate the rolling update, I can +watch the pods update 2 at a time as the current value of maxUnavailable is 2. The below output shows a span of time and is not +complete. The maxUnavailable can be an absolute number (for example, 2) or a percentage of desired Pods (for example, 10%). The +absolute number is calculated from percentage by rounding down. +``` +kubectl get pods --watch +``` + +``` +NAME READY STATUS RESTARTS AGE +web-0 1/1 Running 0 85s +web-1 1/1 Running 0 2m6s +web-2 1/1 Running 0 106s +web-3 1/1 Running 0 2m47s +web-4 1/1 Running 0 2m27s +web-4 1/1 Terminating 0 5m43s ----> start terminating 4 +web-3 1/1 Terminating 0 6m3s ----> start terminating 3 +web-3 0/1 Terminating 0 6m7s +web-3 0/1 Pending 0 0s +web-3 0/1 Pending 0 0s +web-4 0/1 Terminating 0 5m48s +web-4 0/1 Terminating 0 5m48s +web-3 0/1 ContainerCreating 0 2s +web-3 1/1 Running 0 2s +web-4 0/1 Pending 0 0s +web-4 0/1 Pending 0 0s +web-4 0/1 ContainerCreating 0 0s +web-4 1/1 Running 0 1s +web-2 1/1 Terminating 0 5m46s ----> start terminating 2 (only after both 4 and 3 are running) +web-1 1/1 Terminating 0 6m6s ----> start terminating 1 +web-2 0/1 Terminating 0 5m47s +web-1 0/1 Terminating 0 6m7s +web-1 0/1 Pending 0 0s +web-1 0/1 Pending 0 0s +web-1 0/1 ContainerCreating 0 1s +web-1 1/1 Running 0 2s +web-2 0/1 Pending 0 0s +web-2 0/1 Pending 0 0s +web-2 0/1 ContainerCreating 0 0s +web-2 1/1 Running 0 1s +web-0 1/1 Terminating 0 6m6s ----> start terminating 0 (only after 2 and 1 are running) +web-0 0/1 Terminating 0 6m7s +web-0 0/1 Pending 0 0s +web-0 0/1 Pending 0 0s +web-0 0/1 ContainerCreating 0 0s +web-0 1/1 Running 0 1s +``` +Note that as soon as the rolling update starts, both 4 and 3 (the two highest ordinal pods) start terminating at the same time. Pods +with ordinal 4 and 3 may become ready at their own pace. As soon as both pods 4 and 3 are ready, pods 2 and 1 start terminating at the +same time. When pods 2 and 1 are both running and ready, pod 0 starts terminating. + +In Kubernetes, updates to StatefulSets follow a strict ordering when updating Pods. In this example, the update starts at replica 4, then +replica 3, then replica 2, and so on, one pod at a time. When going one pod at a time, its not possible for 3 to be running and ready +before 4. When `maxUnavailable` is more than 1 (in the example scenario I set `maxUnavailable` to 2), it is possible that replica 3 becomes +ready and running before replica 4 is ready—and that is ok. If you're a developer and you set `maxUnavailable` to more than 1, you should +know that this outcome is possible and you must ensure that your application is able to handle such ordering issues that occur +if any. When you set `maxUnavailable` greater than 1, the ordering is guaranteed in between each batch of pods being updated. That guarantee +means that pods in update batch 2 (replicas 2 and 1) cannot start updating until the pods from batch 0 (replicas 4 and 3) are ready. + +Although Kubernetes refers to these as _replicas_, your stateful application may have a different view and each pod of the StatefulSet may +be holding completely different data than other pods. The important thing here is that updates to StatefulSets happen in batches, and you can +now have a batch size larger than 1 (as an alpha feature). + +Also note, that the above behavior is with `podManagementPolicy: OrderedReady`. If you defined a StatefulSet as `podManagementPolicy: Parallel`, +not only `maxUnavailable` number of replicas are terminated at the same time; `maxUnavailable` number of replicas start in `ContainerCreating` +phase at the same time as well. This is called bursting. + +So, now you may have a lot of questions about:- +- What is the behavior when you set `podManagementPolicy: Parallel`? +- What is the behavior when `partition` to a value other than `0`? + +It might be better to try and see it for yourself. This is an alpha feature, and the Kubernetes contributors are looking for feedback on this feature. Did +this help you achieve your stateful scenarios Did you find a bug or do you think the behavior as implemented is not intuitive or can +break applications or catch them by surprise? Please [open an issue](https://github.com/kubernetes/kubernetes/issues) to let us know. + +## Further reading and next steps {#next-steps} +- [Maximum unavailable Pods](/docs/concepts/workloads/controllers/statefulset/#maximum-unavailable-pods) +- [KEP for MaxUnavailable for StatefulSet](https://github.com/kubernetes/enhancements/tree/master/keps/sig-apps/961-maxunavailable-for-statefulset) +- [Implementation](https://github.com/kubernetes/kubernetes/pull/82162/files) +- [Enhancement Tracking Issue](https://github.com/kubernetes/enhancements/issues/961) diff --git a/content/en/docs/concepts/configuration/secret.md b/content/en/docs/concepts/configuration/secret.md index d9611439a4..f83372532f 100644 --- a/content/en/docs/concepts/configuration/secret.md +++ b/content/en/docs/concepts/configuration/secret.md @@ -247,6 +247,8 @@ You can still [manually create](/docs/tasks/configure-pod-container/configure-se a service account token Secret; for example, if you need a token that never expires. However, using the [TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) subresource to obtain a token to access the API is recommended instead. +You can use the [`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-) +command to obtain a token from the `TokenRequest` API. {{< /note >}} #### Projection of Secret keys to specific paths @@ -886,15 +888,30 @@ In this case, `0` means you have created an empty Secret. ### Service account token Secrets A `kubernetes.io/service-account-token` type of Secret is used to store a -token that identifies a +token credential that identifies a {{< glossary_tooltip text="service account" term_id="service-account" >}}. + +Since 1.22, this type of Secret is no longer used to mount credentials into Pods, +and obtaining tokens via the [TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) +API is recommended instead of using service account token Secret objects. +Tokens obtained from the `TokenRequest` API are more secure than ones stored in Secret objects, +because they have a bounded lifetime and are not readable by other API clients. +You can use the [`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-) +command to obtain a token from the `TokenRequest` API. + +You should only create a service account token Secret object +if you can't use the `TokenRequest` API to obtain a token, +and the security exposure of persisting a non-expiring token credential +in a readable API object is acceptable to you. + When using this Secret type, you need to ensure that the `kubernetes.io/service-account.name` annotation is set to an existing -service account name. A Kubernetes -{{< glossary_tooltip text="controller" term_id="controller" >}} fills in some -other fields such as the `kubernetes.io/service-account.uid` annotation, and the -`token` key in the `data` field, which is set to contain an authentication -token. +service account name. If you are creating both the ServiceAccount and +the Secret objects, you should create the ServiceAccount object first. + +After the Secret is created, a Kubernetes {{< glossary_tooltip text="controller" term_id="controller" >}} +fills in some other fields such as the `kubernetes.io/service-account.uid` annotation, and the +`token` key in the `data` field, which is populated with an authentication token. The following example configuration declares a service account token Secret: @@ -911,20 +928,14 @@ data: extra: YmFyCg== ``` -When creating a `Pod`, Kubernetes automatically finds or creates a service account -Secret and then automatically modifies your Pod to use this Secret. The service account -token Secret contains credentials for accessing the Kubernetes API. - -The automatic creation and use of API credentials can be disabled or -overridden if desired. However, if all you need to do is securely access the -API server, this is the recommended workflow. +After creating the Secret, wait for Kubernetes to populate the `token` key in the `data` field. See the [ServiceAccount](/docs/tasks/configure-pod-container/configure-service-account/) documentation for more information on how service accounts work. You can also check the `automountServiceAccountToken` field and the `serviceAccountName` field of the [`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) -for information on referencing service account from Pods. +for information on referencing service account credentials from within Pods. ### Docker config Secrets @@ -982,7 +993,7 @@ kubectl create secret docker-registry secret-tiger-docker \ ``` That command creates a Secret of type `kubernetes.io/dockerconfigjson`. -If you dump the `.data.dockercfgjson` field from that new Secret and then +If you dump the `.data.dockerconfigjson` field from that new Secret and then decode it from base64: ```shell @@ -1291,7 +1302,7 @@ on that node. - When deploying applications that interact with the Secret API, you should limit access using [authorization policies](/docs/reference/access-authn-authz/authorization/) such as - [RBAC]( /docs/reference/access-authn-authz/rbac/). + [RBAC](/docs/reference/access-authn-authz/rbac/). - In the Kubernetes API, `watch` and `list` requests for Secrets within a namespace are extremely powerful capabilities. Avoid granting this access where feasible, since listing Secrets allows the clients to inspect the values of every Secret in that @@ -1310,7 +1321,7 @@ have access to run a Pod that then exposes the Secret. - When deploying applications that interact with the Secret API, you should limit access using [authorization policies](/docs/reference/access-authn-authz/authorization/) such as - [RBAC]( /docs/reference/access-authn-authz/rbac/). + [RBAC](/docs/reference/access-authn-authz/rbac/). - In the API server, objects (including Secrets) are persisted into {{< glossary_tooltip term_id="etcd" >}}; therefore: - only allow cluster admistrators to access etcd (this includes read-only access); diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md index dc3940d5e9..647111b375 100644 --- a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md +++ b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md @@ -14,6 +14,8 @@ weight: 10 Kubernetes {{< skew currentVersion >}} supports [Container Network Interface](https://github.com/containernetworking/cni) (CNI) plugins for cluster networking. You must use a CNI plugin that is compatible with your cluster and that suits your needs. Different plugins are available (both open- and closed- source) in the wider Kubernetes ecosystem. +A CNI plugin is required to implement the [Kubernetes network model](/docs/concepts/services-networking/#the-kubernetes-network-model). + You must use a CNI plugin that is compatible with the [v0.4.0](https://github.com/containernetworking/cni/blob/spec-v0.4.0/SPEC.md) or later releases of the CNI specification. The Kubernetes project recommends using a plugin that is @@ -24,26 +26,37 @@ CNI specification (plugins can be compatible with multiple spec versions). ## Installation -A CNI plugin is required to implement the [Kubernetes network model](/docs/concepts/services-networking/#the-kubernetes-network-model). The CRI manages its own CNI plugins. There are two Kubelet command line parameters to keep in mind when using plugins: +A Container Runtime, in the networking context, is a daemon on a node configured to provide CRI Services for kubelet. In particular, the Container Runtime must be configured to load the CNI plugins required to implement the Kubernetes network model. -* `cni-bin-dir`: Kubelet probes this directory for plugins on startup -* `network-plugin`: The network plugin to use from `cni-bin-dir`. It must match the name reported by a plugin probed from the plugin directory. For CNI plugins, this is `cni`. +{{< note >}} +Prior to Kubernetes 1.24, the CNI plugins could also be managed by the kubelet using the `cni-bin-dir` and `network-plugin` command-line parameters. +These command-line parameters were removed in Kubernetes 1.24, with management of the CNI no longer in scope for kubelet. + +See [Troubleshooting CNI plugin-related errors](/docs/tasks/administer-cluster/migrating-from-dockershim/troubleshooting-cni-plugin-related-errors/) +if you are facing issues following the removal of dockershim. +{{< /note >}} + +For specific information about how a Container Runtime manages the CNI plugins, see the documentation for that Container Runtime, for example: +- [containerd](https://github.com/containerd/containerd/blob/main/script/setup/install-cni) +- [CRI-O](https://github.com/cri-o/cri-o/blob/main/contrib/cni/README.md) + +For specific information about how to install and manage a CNI plugin, see the documentation for that plugin or [networking provider](/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model). ## Network Plugin Requirements -Besides providing the [`NetworkPlugin` interface](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go) to configure and clean up pod networking, the plugin may also need specific support for kube-proxy. The iptables proxy obviously depends on iptables, and the plugin may need to ensure that container traffic is made available to iptables. For example, if the plugin connects containers to a Linux bridge, the plugin must set the `net/bridge/bridge-nf-call-iptables` sysctl to `1` to ensure that the iptables proxy functions correctly. If the plugin does not use a Linux bridge (but instead something like Open vSwitch or some other mechanism) it should ensure container traffic is appropriately routed for the proxy. +For plugin developers and users who regularly build or deploy Kubernetes, the plugin may also need specific configuration to support kube-proxy. +The iptables proxy depends on iptables, and the plugin may need to ensure that container traffic is made available to iptables. +For example, if the plugin connects containers to a Linux bridge, the plugin must set the `net/bridge/bridge-nf-call-iptables` sysctl to `1` to ensure that the iptables proxy functions correctly. +If the plugin does not use a Linux bridge, but uses something like Open vSwitch or some other mechanism instead, it should ensure container traffic is appropriately routed for the proxy. -By default if no kubelet network plugin is specified, the `noop` plugin is used, which sets `net/bridge/bridge-nf-call-iptables=1` to ensure simple configurations (like Docker with a bridge) work correctly with the iptables proxy. +By default, if no kubelet network plugin is specified, the `noop` plugin is used, which sets `net/bridge/bridge-nf-call-iptables=1` to ensure simple configurations (like Docker with a bridge) work correctly with the iptables proxy. -### CNI +### Loopback CNI -The CNI plugin is selected by passing Kubelet the `--network-plugin=cni` command-line option. Kubelet reads a file from `--cni-conf-dir` (default `/etc/cni/net.d`) and uses the CNI configuration from that file to set up each pod's network. The CNI configuration file must match the [CNI specification](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration), and any required CNI plugins referenced by the configuration must be present in `--cni-bin-dir` (default `/opt/cni/bin`). +In addition to the CNI plugin installed on the nodes for implementing the Kubernetes network model, Kubernetes also requires the container runtimes to provide a loopback interface `lo`, which is used for each sandbox (pod sandboxes, vm sandboxes, ...). +Implementing the loopback interface can be accomplished by re-using the [CNI loopback plugin.](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go) or by developing your own code to achieve this (see [this example from CRI-O](https://github.com/cri-o/ocicni/blob/release-1.24/pkg/ocicni/util_linux.go#L91)). -If there are multiple CNI configuration files in the directory, the kubelet uses the configuration file that comes first by name in lexicographic order. - -In addition to the CNI plugin specified by the configuration file, Kubernetes requires the standard CNI [`lo`](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go) plugin, at minimum version 0.2.0 - -#### Support hostPort +### Support hostPort The CNI networking plugin supports `hostPort`. You can use the official [portmap](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap) plugin offered by the CNI plugin team or use your own plugin with portMapping functionality. @@ -80,7 +93,7 @@ For example: } ``` -#### Support traffic shaping +### Support traffic shaping **Experimental Feature** @@ -132,8 +145,4 @@ metadata: ... ``` -## Usage Summary - -* `--network-plugin=cni` specifies that we use the `cni` network plugin with actual CNI plugin binaries located in `--cni-bin-dir` (default `/opt/cni/bin`) and CNI plugin configuration located in `--cni-conf-dir` (default `/etc/cni/net.d`). - ## {{% heading "whatsnext" %}} diff --git a/content/en/docs/concepts/extend-kubernetes/operator.md b/content/en/docs/concepts/extend-kubernetes/operator.md index 96a17ada96..3c2fc9890d 100644 --- a/content/en/docs/concepts/extend-kubernetes/operator.md +++ b/content/en/docs/concepts/extend-kubernetes/operator.md @@ -111,6 +111,7 @@ Operator. {{% thirdparty-content %}} * [Charmed Operator Framework](https://juju.is/) +* [Java Operator SDK](https://github.com/java-operator-sdk/java-operator-sdk) * [Kopf](https://github.com/nolar/kopf) (Kubernetes Operator Pythonic Framework) * [kubebuilder](https://book.kubebuilder.io/) * [KubeOps](https://buehler.github.io/dotnet-operator-sdk/) (.NET operator SDK) diff --git a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md index 067e3d60ed..b5a786620b 100644 --- a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -302,9 +302,8 @@ the Pod onto a node that is in the same zone as one or more Pods with the label `topology.kubernetes.io/zone=R` label if there are other nodes in the same zone currently running Pods with the `Security=S2` Pod label. -See the -[design doc](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) -for many more examples of Pod affinity and anti-affinity. +To get yourself more familiar with the examples of Pod affinity and anti-affinity, +refer to the [design proposal](https://github.com/kubernetes/design-proposals-archive/blob/main/scheduling/podaffinity.md). You can use the `In`, `NotIn`, `Exists` and `DoesNotExist` values in the `operator` field for Pod affinity and anti-affinity. diff --git a/content/en/docs/concepts/security/pod-security-standards.md b/content/en/docs/concepts/security/pod-security-standards.md index 393468ac74..b42f7f3acb 100644 --- a/content/en/docs/concepts/security/pod-security-standards.md +++ b/content/en/docs/concepts/security/pod-security-standards.md @@ -29,10 +29,9 @@ This guide outlines the requirements of each policy. **The _Privileged_ policy is purposely-open, and entirely unrestricted.** This type of policy is typically aimed at system- and infrastructure-level workloads managed by privileged, trusted users. -The Privileged policy is defined by an absence of restrictions. For allow-by-default enforcement -mechanisms (such as gatekeeper), the Privileged policy may be an absence of applied constraints -rather than an instantiated profile. In contrast, for a deny-by-default mechanism (such as Pod -Security Policy) the Privileged policy should enable all controls (disable all restrictions). +The Privileged policy is defined by an absence of restrictions. Allow-by-default +mechanisms (such as gatekeeper) may be Privileged by default. In contrast, for a deny-by-default mechanism (such as Pod +Security Policy) the Privileged policy should disable all restrictions. ### Baseline @@ -458,6 +457,16 @@ of individual policies are not defined here. - {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}} - {{< example file="policy/restricted-psp.yaml" >}}Restricted{{< /example >}} +### Alternatives + +{{% thirdparty-content %}} + +Other alternatives for enforcing policies are being developed in the Kubernetes ecosystem, such as: +- [Kubewarden](https://github.com/kubewarden) +- [Kyverno](https://kyverno.io/policies/pod-security/) +- [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) + + ## FAQ ### Why isn't there a profile between privileged and baseline? @@ -481,14 +490,6 @@ as well as other related parameters outside the Security Context. As of July 202 [Pod Security Policies](/docs/concepts/security/pod-security-policy/) are deprecated in favor of the built-in [Pod Security Admission Controller](/docs/concepts/security/pod-security-admission/). -{{% thirdparty-content %}} - -Other alternatives for enforcing security profiles are being developed in the Kubernetes -ecosystem, such as: -- [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper). -- [Kubewarden](https://github.com/kubewarden). -- [Kyverno](https://kyverno.io/policies/pod-security/). - ### What profiles should I apply to my Windows Pods? Windows in Kubernetes has some limitations and differentiators from standard Linux-based diff --git a/content/en/docs/concepts/security/rbac-good-practices.md b/content/en/docs/concepts/security/rbac-good-practices.md index 2434b13f75..7361c3a163 100644 --- a/content/en/docs/concepts/security/rbac-good-practices.md +++ b/content/en/docs/concepts/security/rbac-good-practices.md @@ -37,13 +37,14 @@ some general rules that can be applied are : can avoid accidental modification of cluster resources. - Avoid adding users to the `system:masters` group. Any user who is a member of this group bypasses all RBAC rights checks and will always have unrestricted superuser access, which cannot be - revoked by removing Role Bindings or Cluster Role Bindings. As an aside, if a cluster is + revoked by removing RoleBindings or ClusterRoleBindings. As an aside, if a cluster is using an authorization webhook, membership of this group also bypasses that webhook (requests from users who are members of that group are never sent to the webhook) ### Minimize distribution of privileged tokens -Ideally, pods shouldn't be assigned service accounts granted powerful permissions (listed [here](#Kubernetes-RBAC---Privilege-Escalation-Risks)). +Ideally, pods shouldn't be assigned service accounts that have been granted powerful permissions (for example, any of the rights listed under +[privilege escalation risks](#privilege-escalation-risks)). In cases where a workload requires powerful permissions, consider the following practices: - Limit the number of nodes running powerful pods. Ensure that any DaemonSets you run @@ -82,7 +83,7 @@ Within Kubernetes RBAC there are a number of privileges which, if granted, can a to escalate their privileges in the cluster or affect systems outside the cluster. This section is intended to provide visibility of the areas where cluster operators -should take care, to ensure that they do not inadvertantly allow for more access to clusters than intended. +should take care, to ensure that they do not inadvertently allow for more access to clusters than intended. ### Listing secrets @@ -172,4 +173,7 @@ specifically relevant in multi-tenant clusters if semi-trusted or untrusted user are allowed limited access to a system. One option for mitigation of this issue would be to use [resource quotas](/docs/concepts/policy/resource-quotas/#object-count-quota) -to limit the quantity of objects which can be created. \ No newline at end of file +to limit the quantity of objects which can be created. + +## {{% heading "whatsnext" %}} +* To learn more about RBAC, see the [RBAC documentation](/docs/reference/access-authn-authz/rbac/). diff --git a/content/en/docs/concepts/security/windows-security.md b/content/en/docs/concepts/security/windows-security.md index 1341f38c59..2126bdddaa 100644 --- a/content/en/docs/concepts/security/windows-security.md +++ b/content/en/docs/concepts/security/windows-security.md @@ -51,5 +51,5 @@ Windows containers can also run as Active Directory identities by utilizing [Gro Linux-specific pod security context mechanisms (such as SELinux, AppArmor, Seccomp, or custom POSIX capabilities) are not supported on Windows nodes. -Privileged containers are [not supported](#compatibility-v1-pod-spec-containers-securitycontext) on Windows. +Privileged containers are [not supported](/docs/concepts/windows/intro/#compatibility-v1-pod-spec-containers-securitycontext) on Windows. Instead [HostProcess containers](/docs/tasks/configure-pod-container/create-hostprocess-pod) can be used on Windows to perform many of the tasks performed by privileged containers on Linux. diff --git a/content/en/docs/concepts/services-networking/_index.md b/content/en/docs/concepts/services-networking/_index.md index ab1b784658..b4f7861075 100644 --- a/content/en/docs/concepts/services-networking/_index.md +++ b/content/en/docs/concepts/services-networking/_index.md @@ -7,26 +7,25 @@ description: > ## The Kubernetes network model -Every [`Pod`](/docs/concepts/workloads/pods/) gets its own IP address. +Every [`Pod`](/docs/concepts/workloads/pods/) in a cluster gets its own unique cluster-wide IP address. This means you do not need to explicitly create links between `Pods` and you almost never need to deal with mapping container ports to host ports. This creates a clean, backwards-compatible model where `Pods` can be treated much like VMs or physical hosts from the perspectives of port allocation, -naming, service discovery, [load balancing](/docs/concepts/services-networking/ingress/#load-balancing), application configuration, -and migration. +naming, service discovery, [load balancing](/docs/concepts/services-networking/ingress/#load-balancing), +application configuration, and migration. Kubernetes imposes the following fundamental requirements on any networking implementation (barring any intentional network segmentation policies): - * pods on a [node](/docs/concepts/architecture/nodes/) can communicate with all pods on all nodes without NAT + * pods can communicate with all other pods on any other [node](/docs/concepts/architecture/nodes/) + without NAT * agents on a node (e.g. system daemons, kubelet) can communicate with all pods on that node Note: For those platforms that support `Pods` running in the host network (e.g. -Linux): - - * pods in the host network of a node can communicate with all pods on all - nodes without NAT +Linux), when pods are attached to the host network of a node they can still communicate +with all pods on all nodes without NAT. This model is not only less complex overall, but it is principally compatible with the desire for Kubernetes to enable low-friction porting of apps from VMs diff --git a/content/en/docs/concepts/services-networking/dns-pod-service.md b/content/en/docs/concepts/services-networking/dns-pod-service.md index 9ca11a3457..939269f8ec 100644 --- a/content/en/docs/concepts/services-networking/dns-pod-service.md +++ b/content/en/docs/concepts/services-networking/dns-pod-service.md @@ -8,8 +8,8 @@ weight: 20 --- -Kubernetes creates DNS records for services and pods. You can contact -services with consistent DNS names instead of IP addresses. +Kubernetes creates DNS records for Services and Pods. You can contact +Services with consistent DNS names instead of IP addresses. @@ -25,20 +25,20 @@ Pod's own namespace and the cluster's default domain. ### Namespaces of Services -A DNS query may return different results based on the namespace of the pod making -it. DNS queries that don't specify a namespace are limited to the pod's -namespace. Access services in other namespaces by specifying it in the DNS query. +A DNS query may return different results based on the namespace of the Pod making +it. DNS queries that don't specify a namespace are limited to the Pod's +namespace. Access Services in other namespaces by specifying it in the DNS query. -For example, consider a pod in a `test` namespace. A `data` service is in +For example, consider a Pod in a `test` namespace. A `data` Service is in the `prod` namespace. -A query for `data` returns no results, because it uses the pod's `test` namespace. +A query for `data` returns no results, because it uses the Pod's `test` namespace. A query for `data.prod` returns the intended result, because it specifies the namespace. -DNS queries may be expanded using the pod's `/etc/resolv.conf`. Kubelet -sets this file for each pod. For example, a query for just `data` may be +DNS queries may be expanded using the Pod's `/etc/resolv.conf`. Kubelet +sets this file for each Pod. For example, a query for just `data` may be expanded to `data.test.svc.cluster.local`. The values of the `search` option are used to expand queries. To learn more about DNS queries, see [the `resolv.conf` manual page.](https://www.man7.org/linux/man-pages/man5/resolv.conf.5.html) @@ -49,7 +49,7 @@ search .svc.cluster.local svc.cluster.local cluster.local options ndots:5 ``` -In summary, a pod in the _test_ namespace can successfully resolve either +In summary, a Pod in the _test_ namespace can successfully resolve either `data.prod` or `data.prod.svc.cluster.local`. ### DNS Records @@ -70,14 +70,14 @@ For more up-to-date specification, see ### A/AAAA records "Normal" (not headless) Services are assigned a DNS A or AAAA record, -depending on the IP family of the service, for a name of the form +depending on the IP family of the Service, for a name of the form `my-svc.my-namespace.svc.cluster-domain.example`. This resolves to the cluster IP of the Service. "Headless" (without a cluster IP) Services are also assigned a DNS A or AAAA record, -depending on the IP family of the service, for a name of the form +depending on the IP family of the Service, for a name of the form `my-svc.my-namespace.svc.cluster-domain.example`. Unlike normal -Services, this resolves to the set of IPs of the pods selected by the Service. +Services, this resolves to the set of IPs of the Pods selected by the Service. Clients are expected to consume the set or else use standard round-robin selection from the set. @@ -87,36 +87,36 @@ SRV Records are created for named ports that are part of normal or [Headless Services](/docs/concepts/services-networking/service/#headless-services). For each named port, the SRV record would have the form `_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`. -For a regular service, this resolves to the port number and the domain name: +For a regular Service, this resolves to the port number and the domain name: `my-svc.my-namespace.svc.cluster-domain.example`. -For a headless service, this resolves to multiple answers, one for each pod -that is backing the service, and contains the port number and the domain name of the pod +For a headless Service, this resolves to multiple answers, one for each Pod +that is backing the Service, and contains the port number and the domain name of the Pod of the form `auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example`. ## Pods ### A/AAAA records -In general a pod has the following DNS resolution: +In general a Pod has the following DNS resolution: `pod-ip-address.my-namespace.pod.cluster-domain.example`. -For example, if a pod in the `default` namespace has the IP address 172.17.0.3, +For example, if a Pod in the `default` namespace has the IP address 172.17.0.3, and the domain name for your cluster is `cluster.local`, then the Pod has a DNS name: `172-17-0-3.default.pod.cluster.local`. -Any pods exposed by a Service have the following DNS resolution available: +Any Pods exposed by a Service have the following DNS resolution available: `pod-ip-address.service-name.my-namespace.svc.cluster-domain.example`. ### Pod's hostname and subdomain fields -Currently when a pod is created, its hostname is the Pod's `metadata.name` value. +Currently when a Pod is created, its hostname is the Pod's `metadata.name` value. The Pod spec has an optional `hostname` field, which can be used to specify the Pod's hostname. When specified, it takes precedence over the Pod's name to be -the hostname of the pod. For example, given a Pod with `hostname` set to +the hostname of the Pod. For example, given a Pod with `hostname` set to "`my-host`", the Pod will have its hostname set to "`my-host`". The Pod spec also has an optional `subdomain` field which can be used to specify @@ -173,14 +173,14 @@ spec: name: busybox ``` -If there exists a headless service in the same namespace as the pod and with +If there exists a headless Service in the same namespace as the Pod and with the same name as the subdomain, the cluster's DNS Server also returns an A or AAAA record for the Pod's fully qualified hostname. For example, given a Pod with the hostname set to "`busybox-1`" and the subdomain set to "`default-subdomain`", and a headless Service named "`default-subdomain`" in -the same namespace, the pod will see its own FQDN as +the same namespace, the Pod will see its own FQDN as "`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`". DNS serves an -A or AAAA record at that name, pointing to the Pod's IP. Both pods "`busybox1`" and +A or AAAA record at that name, pointing to the Pod's IP. Both Pods "`busybox1`" and "`busybox2`" can have their distinct A or AAAA records. The Endpoints object can specify the `hostname` for any endpoint addresses, @@ -189,7 +189,7 @@ along with its IP. {{< note >}} Because A or AAAA records are not created for Pod names, `hostname` is required for the Pod's A or AAAA record to be created. A Pod with no `hostname` but with `subdomain` will only create the -A or AAAA record for the headless service (`default-subdomain.my-namespace.svc.cluster-domain.example`), +A or AAAA record for the headless Service (`default-subdomain.my-namespace.svc.cluster-domain.example`), pointing to the Pod's IP address. Also, Pod needs to become ready in order to have a record unless `publishNotReadyAddresses=True` is set on the Service. {{< /note >}} @@ -205,17 +205,17 @@ When you set `setHostnameAsFQDN: true` in the Pod spec, the kubelet writes the P {{< note >}} In Linux, the hostname field of the kernel (the `nodename` field of `struct utsname`) is limited to 64 characters. -If a Pod enables this feature and its FQDN is longer than 64 character, it will fail to start. The Pod will remain in `Pending` status (`ContainerCreating` as seen by `kubectl`) generating error events, such as Failed to construct FQDN from pod hostname and cluster domain, FQDN `long-FQDN` is too long (64 characters is the max, 70 characters requested). One way of improving user experience for this scenario is to create an [admission webhook controller](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) to control FQDN size when users create top level objects, for example, Deployment. +If a Pod enables this feature and its FQDN is longer than 64 character, it will fail to start. The Pod will remain in `Pending` status (`ContainerCreating` as seen by `kubectl`) generating error events, such as Failed to construct FQDN from Pod hostname and cluster domain, FQDN `long-FQDN` is too long (64 characters is the max, 70 characters requested). One way of improving user experience for this scenario is to create an [admission webhook controller](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) to control FQDN size when users create top level objects, for example, Deployment. {{< /note >}} ### Pod's DNS Policy -DNS policies can be set on a per-pod basis. Currently Kubernetes supports the -following pod-specific DNS policies. These policies are specified in the +DNS policies can be set on a per-Pod basis. Currently Kubernetes supports the +following Pod-specific DNS policies. These policies are specified in the `dnsPolicy` field of a Pod Spec. - "`Default`": The Pod inherits the name resolution configuration from the node - that the pods run on. + that the Pods run on. See [related discussion](/docs/tasks/administer-cluster/dns-custom-nameservers) for more details. - "`ClusterFirst`": Any DNS query that does not match the configured cluster @@ -226,6 +226,7 @@ following pod-specific DNS policies. These policies are specified in the for details on how DNS queries are handled in those cases. - "`ClusterFirstWithHostNet`": For Pods running with hostNetwork, you should explicitly set its DNS policy "`ClusterFirstWithHostNet`". + - Note: This is not supported on Windows. See [below](#dns-windows) for details - "`None`": It allows a Pod to ignore DNS settings from the Kubernetes environment. All DNS settings are supposed to be provided using the `dnsConfig` field in the Pod Spec. @@ -306,7 +307,7 @@ For IPv6 setup, search path and name server should be setup like this: kubectl exec -it dns-example -- cat /etc/resolv.conf ``` The output is similar to this: -```shell +``` nameserver fd00:79:30::a search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example options ndots:5 @@ -323,8 +324,25 @@ If the feature gate `ExpandedDNSConfig` is enabled for the kube-apiserver and the kubelet, it is allowed for Kubernetes to have at most 32 search domains and a list of search domains of up to 2048 characters. -## {{% heading "whatsnext" %}} +## DNS resolution on Windows nodes {#dns-windows} +- ClusterFirstWithHostNet is not supported for Pods that run on Windows nodes. + Windows treats all names with a `.` as a FQDN and skips FQDN resolution. +- On Windows, there are multiple DNS resolvers that can be used. As these come with + slightly different behaviors, using the + [`Resolve-DNSName`](https://docs.microsoft.com/powershell/module/dnsclient/resolve-dnsname) + powershell cmdlet for name query resolutions is recommended. +- On Linux, you have a DNS suffix list, which is used after resolution of a name as fully + qualified has failed. + On Windows, you can only have 1 DNS suffix, which is the DNS suffix associated with that + Pod's namespace (example: `mydns.svc.cluster.local`). Windows can resolve FQDNs, Services, + or network name which can be resolved with this single suffix. For example, a Pod spawned + in the `default` namespace, will have the DNS suffix `default.svc.cluster.local`. + Inside a Windows Pod, you can resolve both `kubernetes.default.svc.cluster.local` + and `kubernetes`, but not the partially qualified names (`kubernetes.default` or + `kubernetes.default.svc`). + +## {{% heading "whatsnext" %}} For guidance on administering DNS configurations, check [Configure DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers/) diff --git a/content/en/docs/concepts/services-networking/dual-stack.md b/content/en/docs/concepts/services-networking/dual-stack.md index a120df4392..5561f03d6b 100644 --- a/content/en/docs/concepts/services-networking/dual-stack.md +++ b/content/en/docs/concepts/services-networking/dual-stack.md @@ -239,6 +239,21 @@ If you want to enable egress traffic in order to reach off-cluster destinations Ensure your {{< glossary_tooltip text="CNI" term_id="cni" >}} provider supports IPv6. {{< /note >}} +## Windows support + +Kubernetes on Windows does not support single-stack "IPv6-only" networking. However, +dual-stack IPv4/IPv6 networking for pods and nodes with single-family services +is supported. + +You can use IPv4/IPv6 dual-stack networking with `l2bridge` networks. + +{{< note >}} +Overlay (VXLAN) networks on Windows **do not** support dual-stack networking. +{{< /note >}} + +You can read more about the different network modes for Windows within the +[Networking on Windows](/docs/concepts/services-networking/windows-networking#network-modes) topic. + ## {{% heading "whatsnext" %}} diff --git a/content/en/docs/concepts/services-networking/ingress.md b/content/en/docs/concepts/services-networking/ingress.md index da3ad5c6b4..aebcc800c6 100644 --- a/content/en/docs/concepts/services-networking/ingress.md +++ b/content/en/docs/concepts/services-networking/ingress.md @@ -30,23 +30,8 @@ For clarity, this guide defines the following terms: Traffic routing is controlled by rules defined on the Ingress resource. Here is a simple example where an Ingress sends all its traffic to one Service: -{{< mermaid >}} -graph LR; - client([client])-. Ingress-managed
load balancer .->ingress[Ingress]; - ingress-->|routing rule|service[Service]; - subgraph cluster - ingress; - service-->pod1[Pod]; - service-->pod2[Pod]; - end - classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; - classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; - classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; - class ingress,service,pod1,pod2 k8s; - class client plain; - class cluster cluster; -{{}} +{{< figure src="/docs/images/ingress.svg" alt="ingress-diagram" class="diagram-large" caption="Figure. Ingress" link="https://mermaid.live/edit#pako:eNqNkstuwyAQRX8F4U0r2VHqPlSRKqt0UamLqlnaWWAYJygYLB59KMm_Fxcix-qmGwbuXA7DwAEzzQETXKutof0Ovb4vaoUQkwKUu6pi3FwXM_QSHGBt0VFFt8DRU2OWSGrKUUMlVQwMmhVLEV1Vcm9-aUksiuXRaO_CEhkv4WjBfAgG1TrGaLa-iaUw6a0DcwGI-WgOsF7zm-pN881fvRx1UDzeiFq7ghb1kgqFWiElyTjnuXVG74FkbdumefEpuNuRu_4rZ1pqQ7L5fL6YQPaPNiFuywcG9_-ihNyUkm6YSONWkjVNM8WUIyaeOJLO3clTB_KhL8NQDmVe-OJjxgZM5FhFiiFTK5zjDkxHBQ9_4zB4a-x20EGNSZhyaKmXrg7f5hSsvufUwTMXThtMWiot5Jh6p9ffimHijIezaSVoeN0uiqcfMJvf7w" >}} An Ingress may be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name-based virtual hosting. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers) is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic. @@ -398,25 +383,8 @@ A fanout configuration routes traffic from a single IP address to more than one based on the HTTP URI being requested. An Ingress allows you to keep the number of load balancers down to a minimum. For example, a setup like: -{{< mermaid >}} -graph LR; - client([client])-. Ingress-managed
load balancer .->ingress[Ingress, 178.91.123.132]; - ingress-->|/foo|service1[Service service1:4200]; - ingress-->|/bar|service2[Service service2:8080]; - subgraph cluster - ingress; - service1-->pod1[Pod]; - service1-->pod2[Pod]; - service2-->pod3[Pod]; - service2-->pod4[Pod]; - end - classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; - classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; - classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; - class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s; - class client plain; - class cluster cluster; -{{}} +{{< figure src="/docs/images/ingressFanOut.svg" alt="ingress-fanout-diagram" class="diagram-large" caption="Figure. Ingress Fan Out" link="https://mermaid.live/edit#pako:eNqNUslOwzAQ_RXLvYCUhMQpUFzUUzkgcUBwbHpw4klr4diR7bCo8O8k2FFbFomLPZq3jP00O1xpDpjijWHtFt09zAuFUCUFKHey8vf6NE7QrdoYsDZumGIb4Oi6NAskNeOoZJKpCgxK4oXwrFVgRyi7nCVXWZKRPMlysv5yD6Q4Xryf1Vq_WzDPooJs9egLNDbolKTpT03JzKgh3zWEztJZ0Niu9L-qZGcdmAMfj4cxvWmreba613z9C0B-AMQD-V_AdA-A4j5QZu0SatRKJhSqhZR0wjmPrDP6CeikrutQxy-Cuy2dtq9RpaU2dJKm6fzI5Glmg0VOLio4_5dLjx27hFSC015KJ2VZHtuQvY2fuHcaE43G0MaCREOow_FV5cMxHZ5-oPX75UM5avuXhXuOI9yAaZjg_aLuBl6B3RYaKDDtSw4166QrcKE-emrXcubghgunDaY1kxYizDqnH99UhakzHYykpWD9hjS--fEJoIELqQ" >}} + would require an Ingress such as: @@ -460,25 +428,7 @@ you are using, you may need to create a default-http-backend Name-based virtual hosts support routing HTTP traffic to multiple host names at the same IP address. -{{< mermaid >}} -graph LR; - client([client])-. Ingress-managed
load balancer .->ingress[Ingress, 178.91.123.132]; - ingress-->|Host: foo.bar.com|service1[Service service1:80]; - ingress-->|Host: bar.foo.com|service2[Service service2:80]; - subgraph cluster - ingress; - service1-->pod1[Pod]; - service1-->pod2[Pod]; - service2-->pod3[Pod]; - service2-->pod4[Pod]; - end - classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; - classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; - classDef cluster fill:#fff,stroke:#bbb,stroke-width:2px,color:#326ce5; - class ingress,service1,service2,pod1,pod2,pod3,pod4 k8s; - class client plain; - class cluster cluster; -{{}} +{{< figure src="/docs/images/ingressNameBased.svg" alt="ingress-namebase-diagram" class="diagram-large" caption="Figure. Ingress Name Based Virtual hosting" link="https://mermaid.live/edit#pako:eNqNkl9PwyAUxb8KYS-atM1Kp05m9qSJJj4Y97jugcLtRqTQAPVPdN_dVlq3qUt8gZt7zvkBN7xjbgRgiteW1Rt0_zjLNUJcSdD-ZBn21WmcoDu9tuBcXDHN1iDQVWHnSBkmUMEU0xwsSuK5DK5l745QejFNLtMkJVmSZmT1Re9NcTz_uDXOU1QakxTMJtxUHw7ss-SQLhehQEODTsdH4l20Q-zFyc84-Y67pghv5apxHuweMuj9eS2_NiJdPhix-kMgvwQShOyYMNkJoEUYM3PuGkpUKyY1KqVSdCSEiJy35gnoqCzLvo5fpPAbOqlfI26UsXQ0Ho9nB5CnqesRGTnncPYvSqsdUvqp9KRdlI6KojjEkB0mnLgjDRONhqENBYm6oXbLV5V1y6S7-l42_LowlIN2uFm_twqOcAW2YlK0H_i9c-bYb6CCHNO2FFCyRvkc53rbWptaMA83QnpjMS2ZchBh1nizeNMcU28bGEzXkrV_pArN7Sc0rBTu" >}} The following Ingress tells the backing load balancer to route requests based on diff --git a/content/en/docs/concepts/services-networking/network-policies.md b/content/en/docs/concepts/services-networking/network-policies.md index dc4e2b76ca..63eaebc3c5 100644 --- a/content/en/docs/concepts/services-networking/network-policies.md +++ b/content/en/docs/concepts/services-networking/network-policies.md @@ -54,7 +54,7 @@ POSTing this to the API server for your cluster will have no effect unless your __Mandatory Fields__: As with all other Kubernetes config, a NetworkPolicy needs `apiVersion`, `kind`, and `metadata` fields. For general information about working with config files, see -[Configure Containers Using a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/), +[Configure a Pod to Use a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/), and [Object Management](/docs/concepts/overview/working-with-objects/object-management). __spec__: NetworkPolicy [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) has all the information needed to define a particular network policy in the given namespace. diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index c1c68e40ea..3ca1bc8a26 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -192,6 +192,7 @@ where it's running, by adding an Endpoints object manually: apiVersion: v1 kind: Endpoints metadata: + # the name here should match the name of the Service name: my-service subsets: - addresses: @@ -203,6 +204,10 @@ subsets: The name of the Endpoints object must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). +When you create an [Endpoints](docs/reference/kubernetes-api/service-resources/endpoints-v1/) +object for a Service, you set the name of the new object to be the same as that +of the Service. + {{< note >}} The endpoint IPs _must not_ be: loopback (127.0.0.0/8 for IPv4, ::1/128 for IPv6), or link-local (169.254.0.0/16 and 224.0.0.0/24 for IPv4, fe80::/64 for IPv6). @@ -394,6 +399,10 @@ You can also set the maximum session sticky time by setting `service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` appropriately. (the default value is 10800, which works out to be 3 hours). +{{< note >}} +On Windows, setting the maximum session sticky time for Services is not supported. +{{< /note >}} + ## Multi-Port Services For some Services, you need to expose more than one port. diff --git a/content/en/docs/concepts/services-networking/windows-networking.md b/content/en/docs/concepts/services-networking/windows-networking.md new file mode 100644 index 0000000000..6aa79f0a03 --- /dev/null +++ b/content/en/docs/concepts/services-networking/windows-networking.md @@ -0,0 +1,164 @@ +--- +reviewers: +- aravindhp +- jayunit100 +- jsturtevant +- marosset +title: Networking on Windows +content_type: concept +weight: 75 +--- + + + +Kubernetes supports running nodes on either Linux or Windows. You can mix both kinds of node +within a single cluster. +This page provides an overview to networking specific to the Windows operating system. + + +## Container networking on Windows {#networking} + +Networking for Windows containers is exposed through +[CNI plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). +Windows containers function similarly to virtual machines in regards to +networking. Each container has a virtual network adapter (vNIC) which is connected +to a Hyper-V virtual switch (vSwitch). The Host Networking Service (HNS) and the +Host Compute Service (HCS) work together to create containers and attach container +vNICs to networks. HCS is responsible for the management of containers whereas HNS +is responsible for the management of networking resources such as: + +* Virtual networks (including creation of vSwitches) +* Endpoints / vNICs +* Namespaces +* Policies including packet encapsulations, load-balancing rules, ACLs, and NAT rules. + +The Windows HNS and vSwitch implement namespacing and can +create virtual NICs as needed for a pod or container. However, many configurations such +as DNS, routes, and metrics are stored in the Windows registry database rather than as +files inside `/etc`, which is how Linux stores those configurations. The Windows registry for the container +is separate from that of the host, so concepts like mapping `/etc/resolv.conf` from +the host into a container don't have the same effect they would on Linux. These must +be configured using Windows APIs run in the context of that container. Therefore +CNI implementations need to call the HNS instead of relying on file mappings to pass +network details into the pod or container. + +## Network modes + +Windows supports five different networking drivers/modes: L2bridge, L2tunnel, +Overlay (Beta), Transparent, and NAT. In a heterogeneous cluster with Windows and Linux +worker nodes, you need to select a networking solution that is compatible on both +Windows and Linux. The following table lists the out-of-tree plugins are supported on Windows, +with recommendations on when to use each CNI: + +| Network Driver | Description | Container Packet Modifications | Network Plugins | Network Plugin Characteristics | +| -------------- | ----------- | ------------------------------ | --------------- | ------------------------------ | +| L2bridge | Containers are attached to an external vSwitch. Containers are attached to the underlay network, although the physical network doesn't need to learn the container MACs because they are rewritten on ingress/egress. | MAC is rewritten to host MAC, IP may be rewritten to host IP using HNS OutboundNAT policy. | [win-bridge](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-bridge), [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md), Flannel host-gateway uses win-bridge | win-bridge uses L2bridge network mode, connects containers to the underlay of hosts, offering best performance. Requires user-defined routes (UDR) for inter-node connectivity. | +| L2Tunnel | This is a special case of l2bridge, but only used on Azure. All packets are sent to the virtualization host where SDN policy is applied. | MAC rewritten, IP visible on the underlay network | [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) | Azure-CNI allows integration of containers with Azure vNET, and allows them to leverage the set of capabilities that [Azure Virtual Network provides](https://azure.microsoft.com/en-us/services/virtual-network/). For example, securely connect to Azure services or use Azure NSGs. See [azure-cni for some examples](https://docs.microsoft.com/azure/aks/concepts-network#azure-cni-advanced-networking) | +| Overlay | Containers are given a vNIC connected to an external vSwitch. Each overlay network gets its own IP subnet, defined by a custom IP prefix.The overlay network driver uses VXLAN encapsulation. | Encapsulated with an outer header. | [win-overlay](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-overlay), Flannel VXLAN (uses win-overlay) | win-overlay should be used when virtual container networks are desired to be isolated from underlay of hosts (e.g. for security reasons). Allows for IPs to be re-used for different overlay networks (which have different VNID tags) if you are restricted on IPs in your datacenter. This option requires [KB4489899](https://support.microsoft.com/help/4489899) on Windows Server 2019. | +| Transparent (special use case for [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)) | Requires an external vSwitch. Containers are attached to an external vSwitch which enables intra-pod communication via logical networks (logical switches and routers). | Packet is encapsulated either via [GENEVE](https://datatracker.ietf.org/doc/draft-gross-geneve/) or [STT](https://datatracker.ietf.org/doc/draft-davie-stt/) tunneling to reach pods which are not on the same host.
Packets are forwarded or dropped via the tunnel metadata information supplied by the ovn network controller.
NAT is done for north-south communication. | [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) | [Deploy via ansible](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib). Distributed ACLs can be applied via Kubernetes policies. IPAM support. Load-balancing can be achieved without kube-proxy. NATing is done without using iptables/netsh. | +| NAT (*not used in Kubernetes*) | Containers are given a vNIC connected to an internal vSwitch. DNS/DHCP is provided using an internal component called [WinNAT](https://techcommunity.microsoft.com/t5/virtualization/windows-nat-winnat-capabilities-and-limitations/ba-p/382303) | MAC and IP is rewritten to host MAC/IP. | [nat](https://github.com/Microsoft/windows-container-networking/tree/master/plugins/nat) | Included here for completeness | + +As outlined above, the [Flannel](https://github.com/coreos/flannel) +[CNI plugin](https://github.com/flannel-io/cni-plugin) +is also [supported](https://github.com/flannel-io/cni-plugin#windows-support-experimental) on Windows via the +[VXLAN network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) (**Beta support** ; delegates to win-overlay) +and [host-gateway network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) (stable support; delegates to win-bridge). + +This plugin supports delegating to one of the reference CNI plugins (win-overlay, +win-bridge), to work in conjunction with Flannel daemon on Windows (Flanneld) for +automatic node subnet lease assignment and HNS network creation. This plugin reads +in its own configuration file (cni.conf), and aggregates it with the environment +variables from the FlannelD generated subnet.env file. It then delegates to one of +the reference CNI plugins for network plumbing, and sends the correct configuration +containing the node-assigned subnet to the IPAM plugin (for example: `host-local`). + +For Node, Pod, and Service objects, the following network flows are supported for +TCP/UDP traffic: + +* Pod → Pod (IP) +* Pod → Pod (Name) +* Pod → Service (Cluster IP) +* Pod → Service (PQDN, but only if there are no ".") +* Pod → Service (FQDN) +* Pod → external (IP) +* Pod → external (DNS) +* Node → Pod +* Pod → Node + +## IP address management (IPAM) {#ipam} + +The following IPAM options are supported on Windows: + +* [host-local](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/host-local) +* [azure-vnet-ipam](https://github.com/Azure/azure-container-networking/blob/master/docs/ipam.md) (for azure-cni only) +* [Windows Server IPAM](https://docs.microsoft.com/windows-server/networking/technologies/ipam/ipam-top) (fallback option if no IPAM is set) + +## Load balancing and Services + +A Kubernetes {{< glossary_tooltip text="Service" term_id="service" >}} is an abstraction +that defines a logical set of Pods and a means to access them over a network. +In a cluster that includes Windows nodes, you can use the following types of Service: + +* `NodePort` +* `ClusterIP` +* `LoadBalancer` +* `ExternalName` + +Windows container networking differs in some important ways from Linux networking. +The [Microsoft documentation for Windows Container Networking](https://docs.microsoft.com/en-us/virtualization/windowscontainers/container-networking/architecture) +provides additional details and background. + +On Windows, you can use the following settings to configure Services and load +balancing behavior: + +{{< table caption="Windows Service Settings" >}} +| Feature | Description | Minimum Supported Windows OS build | How to enable | +| ------- | ----------- | -------------------------- | ------------- | +| Session affinity | Ensures that connections from a particular client are passed to the same Pod each time. | Windows Server 2022 | Set `service.spec.sessionAffinity` to "ClientIP" | +| Direct Server Return (DSR) | Load balancing mode where the IP address fixups and the LBNAT occurs at the container vSwitch port directly; service traffic arrives with the source IP set as the originating pod IP. | Windows Server 2019 | Set the following flags in kube-proxy: `--feature-gates="WinDSR=true" --enable-dsr=true` | +| Preserve-Destination | Skips DNAT of service traffic, thereby preserving the virtual IP of the target service in packets reaching the backend Pod. Also disables node-node forwarding. | Windows Server, version 1903 | Set `"preserve-destination": "true"` in service annotations and enable DSR in kube-proxy. | +| IPv4/IPv6 dual-stack networking | Native IPv4-to-IPv4 in parallel with IPv6-to-IPv6 communications to, from, and within a cluster | Windows Server 2019 | See [IPv4/IPv6 dual-stack](#ipv4ipv6-dual-stack) | +| Client IP preservation | Ensures that source IP of incoming ingress traffic gets preserved. Also disables node-node forwarding. | Windows Server 2019 | Set `service.spec.externalTrafficPolicy` to "Local" and enable DSR in kube-proxy | +{{< /table >}} + +{{< warning >}} +There are known issue with NodePort Services on overlay networking, if the destination node is running Windows Server 2022. +To avoid the issue entirely, you can configure the service with `externalTrafficPolicy: Local`. + +There are known issues with Pod to Pod connectivity on l2bridge network on Windows Server 2022 with KB5005619 or higher installed. +To workaround the issue and restore Pod to Pod connectivity, you can disable the WinDSR feature in kube-proxy. + +These issues require OS fixes. +Please follow https://github.com/microsoft/Windows-Containers/issues/204 for updates. +{{< /warning >}} + +## Limitations + +The following networking functionality is _not_ supported on Windows nodes: + +* Host networking mode +* Local NodePort access from the node itself (works for other nodes or external clients) +* More than 64 backend pods (or unique destination addresses) for a single Service +* IPv6 communication between Windows pods connected to overlay networks +* Local Traffic Policy in non-DSR mode +* Outbound communication using the ICMP protocol via the `win-overlay`, `win-bridge`, or using the Azure-CNI plugin.\ + Specifically, the Windows data plane ([VFP](https://www.microsoft.com/research/project/azure-virtual-filtering-platform/)) + doesn't support ICMP packet transpositions, and this means: + * ICMP packets directed to destinations within the same network (such as pod to pod communication via ping) + work as expected; + * TCP/UDP packets work as expected; + * ICMP packets directed to pass through a remote network (e.g. pod to external internet communication via ping) + cannot be transposed and thus will not be routed back to their source; + * Since TCP/UDP packets can still be transposed, you can substitute `ping ` with + `curl ` when debugging connectivity with the outside world. + +Other limitations: + +* Windows reference network plugins win-bridge and win-overlay do not implement + [CNI spec](https://github.com/containernetworking/cni/blob/master/SPEC.md) v0.4.0, + due to a missing `CHECK` implementation. +* The Flannel VXLAN CNI plugin has the following limitations on Windows: + * Node-pod connectivity is only possible for local pods with Flannel v0.12.0 (or higher). + * Flannel is restricted to using VNI 4096 and UDP port 4789. See the official + [Flannel VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) + backend docs for more details on these parameters. diff --git a/content/en/docs/concepts/storage/persistent-volumes.md b/content/en/docs/concepts/storage/persistent-volumes.md index 16f0b8ed3b..074fe9f759 100644 --- a/content/en/docs/concepts/storage/persistent-volumes.md +++ b/content/en/docs/concepts/storage/persistent-volumes.md @@ -540,6 +540,15 @@ In the CLI, the access modes are abbreviated to: * RWX - ReadWriteMany * RWOP - ReadWriteOncePod +{{< note >}} +Kubernetes uses volume access modes to match PersistentVolumeClaims and PersistentVolumes. +In some cases, the volume access modes also constrain where the PersistentVolume can be mounted. +Volume access modes do **not** enforce write protection once the storage has been mounted. +Even if the access modes are specified as ReadWriteOnce, ReadOnlyMany, or ReadWriteMany, they don't set any constraints on the volume. +For example, even if a PersistentVolume is created as ReadOnlyMany, it is no guarantee that it will be read-only. +If the access modes are specified as ReadWriteOncePod, the volume is constrained and can be mounted on only a single Pod. +{{< /note >}} + > __Important!__ A volume can only be mounted using one access mode at a time, even if it supports many. For example, a GCEPersistentDisk can be mounted as ReadWriteOnce by a single node or ReadOnlyMany by many nodes, but not at the same time. diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md index cc9a9565eb..796dd26dd3 100644 --- a/content/en/docs/concepts/storage/volumes.md +++ b/content/en/docs/concepts/storage/volumes.md @@ -64,7 +64,9 @@ a different volume. Kubernetes supports several types of volumes. -### awsElasticBlockStore {#awselasticblockstore} +### awsElasticBlockStore (deprecated) {#awselasticblockstore} + +{{< feature-state for_k8s_version="v1.17" state="deprecated" >}} An `awsElasticBlockStore` volume mounts an Amazon Web Services (AWS) [EBS volume](https://aws.amazon.com/ebs/) into your pod. Unlike @@ -135,7 +137,9 @@ beta features must be enabled. To disable the `awsElasticBlockStore` storage plugin from being loaded by the controller manager and the kubelet, set the `InTreePluginAWSUnregister` flag to `true`. -### azureDisk {#azuredisk} +### azureDisk (deprecated) {#azuredisk} + +{{< feature-state for_k8s_version="v1.19" state="deprecated" >}} The `azureDisk` volume type mounts a Microsoft Azure [Data Disk](https://docs.microsoft.com/en-us/azure/aks/csi-storage-drivers) into a pod. @@ -158,7 +162,9 @@ must be installed on the cluster and the `CSIMigration` feature must be enabled. To disable the `azureDisk` storage plugin from being loaded by the controller manager and the kubelet, set the `InTreePluginAzureDiskUnregister` flag to `true`. -### azureFile {#azurefile} +### azureFile (deprecated) {#azurefile} + +{{< feature-state for_k8s_version="v1.21" state="deprecated" >}} The `azureFile` volume type mounts a Microsoft Azure File volume (SMB 2.1 and 3.0) into a pod. @@ -201,7 +207,9 @@ You must have your own Ceph server running with the share exported before you ca See the [CephFS example](https://github.com/kubernetes/examples/tree/master/volumes/cephfs/) for more details. -### cinder +### cinder (deprecated) {#cinder} + +{{< feature-state for_k8s_version="v1.18" state="deprecated" >}} {{< note >}} Kubernetes must be configured with the OpenStack cloud provider. @@ -390,7 +398,9 @@ You must have your own Flocker installation running before you can use it. See the [Flocker example](https://github.com/kubernetes/examples/tree/master/staging/volumes/flocker) for more details. -### gcePersistentDisk +### gcePersistentDisk (deprecated) {#gcepersistentdisk} + +{{< feature-state for_k8s_version="v1.17" state="deprecated" >}} A `gcePersistentDisk` volume mounts a Google Compute Engine (GCE) [persistent disk](https://cloud.google.com/compute/docs/disks) (PD) into your Pod. @@ -1240,6 +1250,20 @@ for more information. For more information on how to develop a CSI driver, refer to the [kubernetes-csi documentation](https://kubernetes-csi.github.io/docs/) +#### Windows CSI proxy + +{{< feature-state for_k8s_version="v1.22" state="stable" >}} + +CSI node plugins need to perform various privileged +operations like scanning of disk devices and mounting of file systems. These operations +differ for each host operating system. For Linux worker nodes, containerized CSI node +node plugins are typically deployed as privileged containers. For Windows worker nodes, +privileged operations for containerized CSI node plugins is supported using +[csi-proxy](https://github.com/kubernetes-csi/csi-proxy), a community-managed, +stand-alone binary that needs to be pre-installed on each Windows node. + +For more details, refer to the deployment guide of the CSI plugin you wish to deploy. + #### Migrating to CSI drivers from in-tree plugins {{< feature-state for_k8s_version="v1.17" state="beta" >}} @@ -1256,6 +1280,14 @@ provisioning/delete, attach/detach, mount/unmount and resizing of volumes. In-tree plugins that support `CSIMigration` and have a corresponding CSI driver implemented are listed in [Types of Volumes](#volume-types). +The following in-tree plugins support persistent storage on Windows nodes: + +* [`awsElasticBlockStore`](#awselasticblockstore) +* [`azureDisk`](#azuredisk) +* [`azureFile`](#azurefile) +* [`gcePersistentDisk`](#gcepersistentdisk) +* [`vsphereVolume`](#vspherevolume) + ### flexVolume {{< feature-state for_k8s_version="v1.23" state="deprecated" >}} @@ -1267,6 +1299,12 @@ volume plugin path on each node and in some cases the control plane nodes as wel Pods interact with FlexVolume drivers through the `flexVolume` in-tree volume plugin. For more details, see the FlexVolume [README](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md#readme) document. +The following FlexVolume [plugins](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows), +deployed as PowerShell scripts on the host, support Windows nodes: + +* [SMB](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~smb.cmd) +* [iSCSI](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~iscsi.cmd) + {{< note >}} FlexVolume is deprecated. Using an out-of-tree CSI driver is the recommended way to integrate external storage with Kubernetes. diff --git a/content/en/docs/concepts/storage/windows-storage.md b/content/en/docs/concepts/storage/windows-storage.md new file mode 100644 index 0000000000..b8f40177ca --- /dev/null +++ b/content/en/docs/concepts/storage/windows-storage.md @@ -0,0 +1,71 @@ +--- +reviewers: +- jingxu97 +- mauriciopoppe +- jayunit100 +- jsturtevant +- marosset +- aravindhp +title: Windows Storage +content_type: concept +--- + + + +This page provides an storage overview specific to the Windows operating system. + + + +## Persistent storage {#storage} + +Windows has a layered filesystem driver to mount container layers and create a copy +filesystem based on NTFS. All file paths in the container are resolved only within +the context of that container. + +* With Docker, volume mounts can only target a directory in the container, and not + an individual file. This limitation does not apply to containerd. +* Volume mounts cannot project files or directories back to the host filesystem. +* Read-only filesystems are not supported because write access is always required + for the Windows registry and SAM database. However, read-only volumes are supported. +* Volume user-masks and permissions are not available. Because the SAM is not shared + between the host & container, there's no mapping between them. All permissions are + resolved within the context of the container. + +As a result, the following storage functionality is not supported on Windows nodes: + +* Volume subpath mounts: only the entire volume can be mounted in a Windows container +* Subpath volume mounting for Secrets +* Host mount projection +* Read-only root filesystem (mapped volumes still support `readOnly`) +* Block device mapping +* Memory as the storage medium (for example, `emptyDir.medium` set to `Memory`) +* File system features like uid/gid; per-user Linux filesystem permissions +* Setting [secret permissions with DefaultMode](/docs/concepts/configuration/secret/#secret-files-permissions) (due to UID/GID dependency) +* NFS based storage/volume support +* Expanding the mounted volume (resizefs) + +Kubernetes {{< glossary_tooltip text="volumes" term_id="volume" >}} enable complex +applications, with data persistence and Pod volume sharing requirements, to be deployed +on Kubernetes. Management of persistent volumes associated with a specific storage +back-end or protocol includes actions such as provisioning/de-provisioning/resizing +of volumes, attaching/detaching a volume to/from a Kubernetes node and +mounting/dismounting a volume to/from individual containers in a pod that needs to +persist data. + +Volume management components are shipped as Kubernetes volume +[plugin](/docs/concepts/storage/volumes/#types-of-volumes). +The following broad classes of Kubernetes volume plugins are supported on Windows: + +* [`FlexVolume plugins`](/docs/concepts/storage/volumes/#flexVolume) + * Please note that FlexVolumes have been deprecated as of 1.23 +* [`CSI Plugins`](/docs/concepts/storage/volumes/#csi) + +##### In-tree volume plugins + +The following in-tree plugins support persistent storage on Windows nodes: + +* [`awsElasticBlockStore`](/docs/concepts/storage/volumes/#awselasticblockstore) +* [`azureDisk`](/docs/concepts/storage/volumes/#azuredisk) +* [`azureFile`](/docs/concepts/storage/volumes/#azurefile) +* [`gcePersistentDisk`](/docs/concepts/storage/volumes/#gcepersistentdisk) +* [`vsphereVolume`](/docs/concepts/storage/volumes/#vspherevolume) diff --git a/content/en/docs/setup/production-environment/windows/_index.md b/content/en/docs/concepts/windows/_index.md similarity index 100% rename from content/en/docs/setup/production-environment/windows/_index.md rename to content/en/docs/concepts/windows/_index.md diff --git a/content/en/docs/concepts/windows/intro.md b/content/en/docs/concepts/windows/intro.md new file mode 100644 index 0000000000..a737d54e3b --- /dev/null +++ b/content/en/docs/concepts/windows/intro.md @@ -0,0 +1,384 @@ +--- +reviewers: +- jayunit100 +- jsturtevant +- marosset +- perithompson +title: Windows containers in Kubernetes +content_type: concept +weight: 65 +--- + + + +Windows applications constitute a large portion of the services and applications that +run in many organizations. [Windows containers](https://aka.ms/windowscontainers) +provide a way to encapsulate processes and package dependencies, making it easier +to use DevOps practices and follow cloud native patterns for Windows applications. + +Organizations with investments in Windows-based applications and Linux-based +applications don't have to look for separate orchestrators to manage their workloads, +leading to increased operational efficiencies across their deployments, regardless +of operating system. + + + +## Windows nodes in Kubernetes + +To enable the orchestration of Windows containers in Kubernetes, include Windows nodes +in your existing Linux cluster. Scheduling Windows containers in +{{< glossary_tooltip text="Pods" term_id="pod" >}} on Kubernetes is similar to +scheduling Linux-based containers. + +In order to run Windows containers, your Kubernetes cluster must include +multiple operating systems. +While you can only run the {{< glossary_tooltip text="control plane" term_id="control-plane" >}} on Linux, +you can deploy worker nodes running either Windows or Linux. + +Windows {{< glossary_tooltip text="nodes" term_id="node" >}} are +[supported](#windows-os-version-support) provided that the operating system is +Windows Server 2019. + +This document uses the term *Windows containers* to mean Windows containers with +process isolation. Kubernetes does not support running Windows containers with +[Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container). + +## Compatibility and limitations {#limitations} + +Some node features are only available if you use a specific +[container runtime](#container-runtime); others are not available on Windows nodes, +including: + +* HugePages: not supported for Windows containers +* Privileged containers: not supported for Windows containers +* TerminationGracePeriod: requires containerD + +Not all features of shared namespaces are supported. See [API compatibility](#api) +for more details. + +See [Windows OS version compatibility](#windows-os-version-support) for details on +the Windows versions that Kubernetes is tested against. + +From an API and kubectl perspective, Windows containers behave in much the same +way as Linux-based containers. However, there are some notable differences in key +functionality which are outlined in this section. + +### Comparison with Linux {#compatibility-linux-similarities} + +Key Kubernetes elements work the same way in Windows as they do in Linux. This +section refers to several key workload abstractions and how they map to Windows. + +* [Pods](/docs/concepts/workloads/pods/) + + A Pod is the basic building block of Kubernetes–the smallest and simplest unit in + the Kubernetes object model that you create or deploy. You may not deploy Windows and + Linux containers in the same Pod. All containers in a Pod are scheduled onto a single + Node where each Node represents a specific platform and architecture. The following + Pod capabilities, properties and events are supported with Windows containers: + + * Single or multiple containers per Pod with process isolation and volume sharing + * Pod `status` fields + * Readiness and Liveness probes + * postStart & preStop container lifecycle hooks + * ConfigMap, Secrets: as environment variables or volumes + * `emptyDir` volumes + * Named pipe host mounts + * Resource limits + * OS field: + + The `.spec.os.name` field should be set to `windows` to indicate that the current Pod uses Windows containers. + The `IdentifyPodOS` feature gate needs to be enabled for this field to be recognized. + + {{< note >}} + Starting from 1.24, the `IdentifyPodOS` feature gate is in Beta stage and defaults to be enabled. + {{< /note >}} + + If the `IdentifyPodOS` feature gate is enabled and you set the `.spec.os.name` field to `windows`, + you must not set the following fields in the `.spec` of that Pod: + + * `spec.hostPID` + * `spec.hostIPC` + * `spec.securityContext.seLinuxOptions` + * `spec.securityContext.seccompProfile` + * `spec.securityContext.fsGroup` + * `spec.securityContext.fsGroupChangePolicy` + * `spec.securityContext.sysctls` + * `spec.shareProcessNamespace` + * `spec.securityContext.runAsUser` + * `spec.securityContext.runAsGroup` + * `spec.securityContext.supplementalGroups` + * `spec.containers[*].securityContext.seLinuxOptions` + * `spec.containers[*].securityContext.seccompProfile` + * `spec.containers[*].securityContext.capabilities` + * `spec.containers[*].securityContext.readOnlyRootFilesystem` + * `spec.containers[*].securityContext.privileged` + * `spec.containers[*].securityContext.allowPrivilegeEscalation` + * `spec.containers[*].securityContext.procMount` + * `spec.containers[*].securityContext.runAsUser` + * `spec.containers[*].securityContext.runAsGroup` + + In the above list, wildcards (`*`) indicate all elements in a list. + For example, `spec.containers[*].securityContext` refers to the SecurityContext object + for all containers. If any of these fields is specified, the Pod will + not be admited by the API server. + +* [Workload resources](/docs/concepts/workloads/controllers/) including: + * ReplicaSet + * Deployment + * StatefulSet + * DaemonSet + * Job + * CronJob + * ReplicationController +* {{< glossary_tooltip text="Services" term_id="service" >}} + See [Load balancing and Services](#load-balancing-and-services) for more details. + +Pods, workload resources, and Services are critical elements to managing Windows +workloads on Kubernetes. However, on their own they are not enough to enable +the proper lifecycle management of Windows workloads in a dynamic cloud native +environment. Kubernetes also supports: + +* `kubectl exec` +* Pod and container metrics +* {{< glossary_tooltip text="Horizontal pod autoscaling" term_id="horizontal-pod-autoscaler" >}} +* {{< glossary_tooltip text="Resource quotas" term_id="resource-quota" >}} +* Scheduler preemption + +### Command line options for the kubelet {#kubelet-compatibility} + +Some kubelet command line options behave differently on Windows, as described below: + +* The `--windows-priorityclass` lets you set the scheduling priority of the kubelet process + (see [CPU resource management](/docs/concepts/configuration/windows-resource-management/#resource-management-cpu)) +* The `--kubelet-reserve`, `--system-reserve` , and `--eviction-hard` flags update + [NodeAllocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) +* Eviction by using `--enforce-node-allocable` is not implemented +* Eviction by using `--eviction-hard` and `--eviction-soft` are not implemented +* A kubelet running on a Windows node does not have memory + restrictions. `--kubelet-reserve` and `--system-reserve` do not set limits on + kubelet or processes running on the host. This means kubelet or a process on the host + could cause memory resource starvation outside the node-allocatable and scheduler. +* The `MemoryPressure` Condition is not implemented +* The kubelet does not take OOM eviction actions + +### API compatibility {#api} + +There are subtle differences in the way the Kubernetes APIs work for Windows due to the OS +and container runtime. Some workload properties were designed for Linux, and fail to run on Windows. + +At a high level, these OS concepts are different: + +* Identity - Linux uses userID (UID) and groupID (GID) which + are represented as integer types. User and group names + are not canonical - they are just an alias in `/etc/groups` + or `/etc/passwd` back to UID+GID. Windows uses a larger binary + [security identifier](https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/security-identifiers) (SID) + which is stored in the Windows Security Access Manager (SAM) database. This + database is not shared between the host and containers, or between containers. +* File permissions - Windows uses an access control list based on (SIDs), whereas + POSIX systems such as Linux use a bitmask based on object permissions and UID+GID, + plus _optional_ access control lists. +* File paths - the convention on Windows is to use `\` instead of `/`. The Go IO + libraries typically accept both and just make it work, but when you're setting a + path or command line that's interpreted inside a container, `\` may be needed. +* Signals - Windows interactive apps handle termination differently, and can + implement one or more of these: + * A UI thread handles well-defined messages including `WM_CLOSE`. + * Console apps handle Ctrl-C or Ctrl-break using a Control Handler. + * Services register a Service Control Handler function that can accept + `SERVICE_CONTROL_STOP` control codes. + +Container exit codes follow the same convention where 0 is success, and nonzero is failure. +The specific error codes may differ across Windows and Linux. However, exit codes +passed from the Kubernetes components (kubelet, kube-proxy) are unchanged. + +##### Field compatibility for container specifications {#compatibility-v1-pod-spec-containers} + +The following list documents differences between how Pod container specifications +work between Windows and Linux: + +* Huge pages are not implemented in the Windows container + runtime, and are not available. They require [asserting a user + privilege](https://docs.microsoft.com/en-us/windows/desktop/Memory/large-page-support) + that's not configurable for containers. +* `requests.cpu` and `requests.memory` - requests are subtracted + from node available resources, so they can be used to avoid overprovisioning a + node. However, they cannot be used to guarantee resources in an overprovisioned + node. They should be applied to all containers as a best practice if the operator + wants to avoid overprovisioning entirely. +* `securityContext.allowPrivilegeEscalation` - + not possible on Windows; none of the capabilities are hooked up +* `securityContext.capabilities` - + POSIX capabilities are not implemented on Windows +* `securityContext.privileged` - + Windows doesn't support privileged containers +* `securityContext.procMount` - + Windows doesn't have a `/proc` filesystem +* `securityContext.readOnlyRootFilesystem` - + not possible on Windows; write access is required for registry & system + processes to run inside the container +* `securityContext.runAsGroup` - + not possible on Windows as there is no GID support +* `securityContext.runAsNonRoot` - + this setting will prevent containers from running as `ContainerAdministrator` + which is the closest equivalent to a root user on Windows. +* `securityContext.runAsUser` - + use [`runAsUserName`](/docs/tasks/configure-pod-container/configure-runasusername) + instead +* `securityContext.seLinuxOptions` - + not possible on Windows as SELinux is Linux-specific +* `terminationMessagePath` - + this has some limitations in that Windows doesn't support mapping single files. The + default value is `/dev/termination-log`, which does work because it does not + exist on Windows by default. + +##### Field compatibility for Pod specifications {#compatibility-v1-pod} + +The following list documents differences between how Pod specifications work between Windows and Linux: + +* `hostIPC` and `hostpid` - host namespace sharing is not possible on Windows +* `hostNetwork` - There is no Windows OS support to share the host network +* `dnsPolicy` - setting the Pod `dnsPolicy` to `ClusterFirstWithHostNet` is + not supported on Windows because host networking is not provided. Pods always + run with a container network. +* `podSecurityContext` (see below) +* `shareProcessNamespace` - this is a beta feature, and depends on Linux namespaces + which are not implemented on Windows. Windows cannot share process namespaces or + the container's root filesystem. Only the network can be shared. +* `terminationGracePeriodSeconds` - this is not fully implemented in Docker on Windows, + see the [GitHub issue](https://github.com/moby/moby/issues/25982). + The behavior today is that the ENTRYPOINT process is sent CTRL_SHUTDOWN_EVENT, + then Windows waits 5 seconds by default, and finally shuts down + all processes using the normal Windows shutdown behavior. The 5 + second default is actually in the Windows registry + [inside the container](https://github.com/moby/moby/issues/25982#issuecomment-426441183), + so it can be overridden when the container is built. +* `volumeDevices` - this is a beta feature, and is not implemented on Windows. + Windows cannot attach raw block devices to pods. +* `volumes` + * If you define an `emptyDir` volume, you cannot set its volume source to `memory`. +* You cannot enable `mountPropagation` for volume mounts as this is not + supported on Windows. + +##### Field compatibility for Pod security context {#compatibility-v1-pod-spec-containers-securitycontext} + +None of the Pod [`securityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context) fields work on Windows. + +### Node problem detector + +The node problem detector (see +[Monitor Node Health](/docs/tasks/debug/debug-cluster/monitor-node-health/)) +is not compatible with Windows. + +### Pause container + +In a Kubernetes Pod, an infrastructure or “pause” container is first created +to host the container. In Linux, the cgroups and namespaces that make up a pod +need a process to maintain their continued existence; the pause process provides +this. Containers that belong to the same pod, including infrastructure and worker +containers, share a common network endpoint (same IPv4 and / or IPv6 address, same +network port spaces). Kubernetes uses pause containers to allow for worker containers +crashing or restarting without losing any of the networking configuration. + +Kubernetes maintains a multi-architecture image that includes support for Windows. +For Kubernetes v{{< skew currentVersion >}} the recommended pause image is `k8s.gcr.io/pause:3.6`. +The [source code](https://github.com/kubernetes/kubernetes/tree/master/build/pause) +is available on GitHub. + +Microsoft maintains a different multi-architecture image, with Linux and Windows +amd64 support, that you can find as `mcr.microsoft.com/oss/kubernetes/pause:3.6`. +This image is built from the same source as the Kubernetes maintained image but +all of the Windows binaries are [authenticode signed](https://docs.microsoft.com/en-us/windows-hardware/drivers/install/authenticode) by Microsoft. +The Kubernetes project recommends using the Microsoft maintained image if you are +deploying to a production or production-like environment that requires signed +binaries. + +### Container runtimes {#container-runtime} + +You need to install a +{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} +into each node in the cluster so that Pods can run there. + +The following container runtimes work with Windows: + +{{% thirdparty-content %}} + +#### cri-containerd + +{{< feature-state for_k8s_version="v1.20" state="stable" >}} + +You can use {{< glossary_tooltip term_id="containerd" text="ContainerD" >}} 1.4.0+ +as the container runtime for Kubernetes nodes that run Windows. + +Learn how to [install ContainerD on a Windows node](/docs/setup/production-environment/container-runtimes/#install-containerd). + +{{< note >}} +There is a [known limitation](/docs/tasks/configure-pod-container/configure-gmsa/#gmsa-limitations) +when using GMSA with containerd to access Windows network shares, which requires a +kernel patch. +{{< /note >}} + +#### Mirantis Container Runtime {#mcr} + +[Mirantis Container Runtime](https://docs.mirantis.com/mcr/20.10/overview.html) (MCR) is available as a container runtime for all Windows Server 2019 and later versions. + +See [Install MCR on Windows Servers](https://docs.mirantis.com/mcr/20.10/install/mcr-windows.html) for more information. + +## Windows OS version compatibility {#windows-os-version-support} + +On Windows nodes, strict compatibility rules apply where the host OS version must +match the container base image OS version. Only Windows containers with a container +operating system of Windows Server 2019 are fully supported. + +For Kubernetes v{{< skew currentVersion >}}, operating system compatibility for Windows nodes (and Pods) +is as follows: + +Windows Server LTSC release +: Windows Server 2019 +: Windows Server 2022 + +Windows Server SAC release +: Windows Server version 20H2 + +The Kubernetes [version-skew policy](/docs/setup/release/version-skew-policy/) also applies. + +## Getting help and troubleshooting {#troubleshooting} + +Your main source of help for troubleshooting your Kubernetes cluster should start +with the [Troubleshooting](/docs/tasks/debug/) +page. + +Some additional, Windows-specific troubleshooting help is included +in this section. Logs are an important element of troubleshooting +issues in Kubernetes. Make sure to include them any time you seek +troubleshooting assistance from other contributors. Follow the +instructions in the +SIG Windows [contributing guide on gathering logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs). + +### Reporting issues and feature requests + +If you have what looks like a bug, or you would like to +make a feature request, please follow the [SIG Windows contributing guide](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#reporting-issues-and-feature-requests) to create a new issue. +You should first search the list of issues in case it was +reported previously and comment with your experience on the issue and add additional +logs. SIG-Windows Slack is also a great avenue to get some initial support and +troubleshooting ideas prior to creating a ticket. + +## {{% heading "whatsnext" %}} + +### Deployment tools + +The kubeadm tool helps you to deploy a Kubernetes cluster, providing the control +plane to manage the cluster it, and nodes to run your workloads. +[Adding Windows nodes](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/) +explains how to deploy Windows nodes to your cluster using kubeadm. + +The Kubernetes [cluster API](https://cluster-api.sigs.k8s.io/) project also provides means to automate deployment of Windows nodes. + +### Windows distribution channels + +For a detailed explanation of Windows distribution channels see the [Microsoft documentation](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19). + +Information on the different Windows Server servicing channels +including their support models can be found at +[Windows Server servicing channels](https://docs.microsoft.com/en-us/windows-server/get-started/servicing-channels-comparison). diff --git a/content/en/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/en/docs/concepts/windows/user-guide.md similarity index 79% rename from content/en/docs/setup/production-environment/windows/user-guide-windows-containers.md rename to content/en/docs/concepts/windows/user-guide.md index 7177a4aa05..450a1bb5e0 100644 --- a/content/en/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/en/docs/concepts/windows/user-guide.md @@ -3,7 +3,6 @@ reviewers: - jayunit100 - jsturtevant - marosset -- perithompson title: Guide for scheduling Windows containers in Kubernetes content_type: concept weight: 75 @@ -11,31 +10,29 @@ weight: 75 -Windows applications constitute a large portion of the services and applications that run in many organizations. -This guide walks you through the steps to configure and deploy a Windows container in Kubernetes. - - +Windows applications constitute a large portion of the services and applications that run in many organizations. +This guide walks you through the steps to configure and deploy Windows containers in Kubernetes. ## Objectives * Configure an example deployment to run Windows containers on the Windows node -* (Optional) Configure an Active Directory Identity for your Pod using Group Managed Service Accounts (GMSA) +* Highlight Windows specific funcationality in Kubernetes ## Before you begin -* Create a Kubernetes cluster that includes a +* Create a Kubernetes cluster that includes a control plane and a [worker node running Windows Server](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/) -* It is important to note that creating and deploying services and workloads on Kubernetes -behaves in much the same way for Linux and Windows containers. -[Kubectl commands](/docs/reference/kubectl/) to interface with the cluster are identical. +* It is important to note that creating and deploying services and workloads on Kubernetes +behaves in much the same way for Linux and Windows containers. +[Kubectl commands](/docs/reference/kubectl/) to interface with the cluster are identical. The example in the section below is provided to jumpstart your experience with Windows containers. ## Getting Started: Deploying a Windows container -To deploy a Windows container on Kubernetes, you must first create an example application. -The example YAML file below creates a simple webserver application. +The example YAML file below deploys a simple webserver application running inside a Windows container. + Create a service spec named `win-webserver.yaml` with the contents below: ```yaml @@ -83,8 +80,8 @@ spec: ``` {{< note >}} -Port mapping is also supported, but for simplicity in this example -the container port 80 is exposed directly to the service. +Port mapping is also supported, but for simplicity this example exposes +port 80 of the container directly to the Service. {{< /note >}} 1. Check that all nodes are healthy: @@ -104,20 +101,19 @@ the container port 80 is exposed directly to the service. 1. Check that the deployment succeeded. To verify: - * Two containers per pod on the Windows node, use `docker ps` - * Two pods listed from the Linux control plane node, use `kubectl get pods` - * Node-to-pod communication across the network, `curl` port 80 of your pod IPs from the Linux control plane node + * Two pods listed from the Linux control plane node, use `kubectl get pods` + * Node-to-pod communication across the network, `curl` port 80 of your pod IPs from the Linux control plane node to check for a web server response - * Pod-to-pod communication, ping between pods (and across hosts, if you have more than one Windows node) + * Pod-to-pod communication, ping between pods (and across hosts, if you have more than one Windows node) using docker exec or kubectl exec - * Service-to-pod communication, `curl` the virtual service IP (seen under `kubectl get services`) + * Service-to-pod communication, `curl` the virtual service IP (seen under `kubectl get services`) from the Linux control plane node and from individual pods * Service discovery, `curl` the service name with the Kubernetes [default DNS suffix](/docs/concepts/services-networking/dns-pod-service/#services) * Inbound connectivity, `curl` the NodePort from the Linux control plane node or machines outside of the cluster * Outbound connectivity, `curl` external IPs from inside the pod using kubectl exec {{< note >}} -Windows container hosts are not able to access the IP of services scheduled on them due to current platform limitations of the Windows networking stack. +Windows container hosts are not able to access the IP of services scheduled on them due to current platform limitations of the Windows networking stack. Only Windows pods are able to access service IPs. {{< /note >}} @@ -125,43 +121,43 @@ Only Windows pods are able to access service IPs. ### Capturing logs from workloads -Logs are an important element of observability; they enable users to gain insights -into the operational aspect of workloads and are a key ingredient to troubleshooting issues. -Because Windows containers and workloads inside Windows containers behave differently from Linux containers, -users had a hard time collecting logs, limiting operational visibility. -Windows workloads for example are usually configured to log to ETW (Event Tracing for Windows) -or push entries to the application event log. -[LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor), an open source tool by Microsoft, -is the recommended way to monitor configured log sources inside a Windows container. -LogMonitor supports monitoring event logs, ETW providers, and custom application logs, +Logs are an important element of observability; they enable users to gain insights +into the operational aspect of workloads and are a key ingredient to troubleshooting issues. +Because Windows containers and workloads inside Windows containers behave differently from Linux containers, +users had a hard time collecting logs, limiting operational visibility. +Windows workloads for example are usually configured to log to ETW (Event Tracing for Windows) +or push entries to the application event log. +[LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor), an open source tool by Microsoft, +is the recommended way to monitor configured log sources inside a Windows container. +LogMonitor supports monitoring event logs, ETW providers, and custom application logs, piping them to STDOUT for consumption by `kubectl logs `. -Follow the instructions in the LogMonitor GitHub page to copy its binaries and configuration files +Follow the instructions in the LogMonitor GitHub page to copy its binaries and configuration files to all your containers and add the necessary entrypoints for LogMonitor to push your logs to STDOUT. -## Using configurable Container usernames +## Configuring container user -Starting with Kubernetes v1.16, Windows containers can be configured to run their entrypoints and processes -with different usernames than the image defaults. -The way this is achieved is a bit different from the way it is done for Linux containers. +### Using configurable Container usernames + +Windows containers can be configured to run their entrypoints and processes +with different usernames than the image defaults. Learn more about it [here](/docs/tasks/configure-pod-container/configure-runasusername/). -## Managing Workload Identity with Group Managed Service Accounts +### Managing Workload Identity with Group Managed Service Accounts -Starting with Kubernetes v1.14, Windows container workloads can be configured to use Group Managed Service Accounts (GMSA). -Group Managed Service Accounts are a specific type of Active Directory account that provides automatic password management, -simplified service principal name (SPN) management, and the ability to delegate the management to other administrators across multiple servers. -Containers configured with a GMSA can access external Active Directory Domain resources while carrying the identity configured with the GMSA. +Windows container workloads can be configured to use Group Managed Service Accounts (GMSA). +Group Managed Service Accounts are a specific type of Active Directory account that provide automatic password management, +simplified service principal name (SPN) management, and the ability to delegate the management to other administrators across multiple servers. +Containers configured with a GMSA can access external Active Directory Domain resources while carrying the identity configured with the GMSA. Learn more about configuring and using GMSA for Windows containers [here](/docs/tasks/configure-pod-container/configure-gmsa/). ## Taints and Tolerations -Users today need to use some combination of taints and node selectors in order to -keep Linux and Windows workloads on their respective OS-specific nodes. -This likely imposes a burden only on Windows users. The recommended approach is outlined below, +Users need to use some combination of taints and node selectors in order to +schedule Linux and Windows workloads to their respective OS-specific nodes. +The recommended approach is outlined below, with one of its main goals being that this approach should not break compatibility for existing Linux workloads. - If the `IdentifyPodOS` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled, you can (and should) set `.spec.os.name` for a Pod to indicate the operating system that the containers in that Pod are designed for. For Pods that run Linux containers, set @@ -184,26 +180,26 @@ so taints and tolerations and node selectors are still required ### Ensuring OS-specific workloads land on the appropriate container host -Users can ensure Windows containers can be scheduled on the appropriate host using Taints and Tolerations. +Users can ensure Windows containers can be scheduled on the appropriate host using Taints and Tolerations. All Kubernetes nodes today have the following default labels: * kubernetes.io/os = [windows|linux] * kubernetes.io/arch = [amd64|arm64|...] -If a Pod specification does not specify a nodeSelector like `"kubernetes.io/os": windows`, -it is possible the Pod can be scheduled on any host, Windows or Linux. -This can be problematic since a Windows container can only run on Windows and a Linux container can only run on Linux. +If a Pod specification does not specify a nodeSelector like `"kubernetes.io/os": windows`, +it is possible the Pod can be scheduled on any host, Windows or Linux. +This can be problematic since a Windows container can only run on Windows and a Linux container can only run on Linux. The best practice is to use a nodeSelector. -However, we understand that in many cases users have a pre-existing large number of deployments for Linux containers, -as well as an ecosystem of off-the-shelf configurations, such as community Helm charts, and programmatic Pod generation cases, such as with Operators. -In those situations, you may be hesitant to make the configuration change to add nodeSelectors. -The alternative is to use Taints. Because the kubelet can set Taints during registration, +However, we understand that in many cases users have a pre-existing large number of deployments for Linux containers, +as well as an ecosystem of off-the-shelf configurations, such as community Helm charts, and programmatic Pod generation cases, such as with Operators. +In those situations, you may be hesitant to make the configuration change to add nodeSelectors. +The alternative is to use Taints. Because the kubelet can set Taints during registration, it could easily be modified to automatically add a taint when running on Windows only. For example: `--register-with-taints='os=windows:NoSchedule'` -By adding a taint to all Windows nodes, nothing will be scheduled on them (that includes existing Linux Pods). +By adding a taint to all Windows nodes, nothing will be scheduled on them (that includes existing Linux Pods). In order for a Windows Pod to be scheduled on a Windows node, it would need both the nodeSelector and the appropriate matching toleration to choose Windows. @@ -223,26 +219,24 @@ tolerations: The Windows Server version used by each pod must match that of the node. If you want to use multiple Windows Server versions in the same cluster, then you should set additional node labels and nodeSelectors. -Kubernetes 1.17 automatically adds a new label `node.kubernetes.io/windows-build` to simplify this. +Kubernetes 1.17 automatically adds a new label `node.kubernetes.io/windows-build` to simplify this. If you're running an older version, then it's recommended to add this label manually to Windows nodes. -This label reflects the Windows major, minor, and build number that need to match for compatibility. +This label reflects the Windows major, minor, and build number that need to match for compatibility. Here are values used today for each Windows Server version. | Product Name | Build Number(s) | |--------------------------------------|------------------------| | Windows Server 2019 | 10.0.17763 | -| Windows Server version 1809 | 10.0.17763 | -| Windows Server version 1903 | 10.0.18362 | - +| Windows Server, Version 20H2 | 10.0.19042 | +| Windows Server 2022 | 10.0.20348 | ### Simplifying with RuntimeClass -[RuntimeClass] can be used to simplify the process of using taints and tolerations. +[RuntimeClass] can be used to simplify the process of using taints and tolerations. A cluster administrator can create a `RuntimeClass` object which is used to encapsulate these taints and tolerations. - -1. Save this file to `runtimeClasses.yml`. It includes the appropriate `nodeSelector` +1. Save this file to `runtimeClasses.yml`. It includes the appropriate `nodeSelector` for the Windows OS, architecture, and version. ```yaml @@ -313,7 +307,4 @@ spec: app: iis-2019 ``` - - - [RuntimeClass]: https://kubernetes.io/docs/concepts/containers/runtime-class/ diff --git a/content/en/docs/concepts/workloads/controllers/job.md b/content/en/docs/concepts/workloads/controllers/job.md index 74a232831a..cda286947b 100644 --- a/content/en/docs/concepts/workloads/controllers/job.md +++ b/content/en/docs/concepts/workloads/controllers/job.md @@ -119,7 +119,7 @@ kubectl logs $pods The output is similar to this: -```shell +``` 3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901 ``` diff --git a/content/en/docs/concepts/workloads/controllers/replicaset.md b/content/en/docs/concepts/workloads/controllers/replicaset.md index 8024e6246a..29df406dcb 100644 --- a/content/en/docs/concepts/workloads/controllers/replicaset.md +++ b/content/en/docs/concepts/workloads/controllers/replicaset.md @@ -78,7 +78,7 @@ kubectl describe rs/frontend And you will see output similar to: -```shell +``` Name: frontend Namespace: default Selector: tier=frontend @@ -130,7 +130,7 @@ kubectl get pods frontend-b2zdv -o yaml The output will look similar to this, with the frontend ReplicaSet's info set in the metadata's ownerReferences field: -```shell +```yaml apiVersion: v1 kind: Pod metadata: @@ -181,7 +181,7 @@ kubectl get pods The output shows that the new Pods are either already terminated, or in the process of being terminated: -```shell +``` NAME READY STATUS RESTARTS AGE frontend-b2zdv 1/1 Running 0 10m frontend-vcmts 1/1 Running 0 10m @@ -210,7 +210,7 @@ kubectl get pods ``` Will reveal in its output: -```shell +``` NAME READY STATUS RESTARTS AGE frontend-hmmj2 1/1 Running 0 9s pod1 1/1 Running 0 36s diff --git a/content/en/docs/contribute/_index.md b/content/en/docs/contribute/_index.md index 61a4e0a118..8627e8dd93 100644 --- a/content/en/docs/contribute/_index.md +++ b/content/en/docs/contribute/_index.md @@ -18,8 +18,15 @@ card: {{< note >}} To learn more about contributing to Kubernetes in general, see the [contributor documentation](https://www.kubernetes.dev/docs/). + +You can also read the +{{< glossary_tooltip text="CNCF" term_id="cncf" >}} +[page](https://contribute.cncf.io/contributors/projects/#kubernetes) +about contributing to Kubernetes. {{< /note >}} +--- + This website is maintained by [Kubernetes SIG Docs](/docs/contribute/#get-involved-with-sig-docs). Kubernetes documentation contributors: diff --git a/content/en/docs/contribute/participate/pr-wranglers.md b/content/en/docs/contribute/participate/pr-wranglers.md index 865af35805..42c1d2b32b 100644 --- a/content/en/docs/contribute/participate/pr-wranglers.md +++ b/content/en/docs/contribute/participate/pr-wranglers.md @@ -100,4 +100,4 @@ In late 2021, SIG Docs introduced the PR Wrangler Shadow Program. The program wa - Others can reach out on the [#sig-docs Slack channel](https://kubernetes.slack.com/messages/sig-docs) for requesting to shadow an assigned PR Wrangler for a specific week. Feel free to reach out to Brad Topol (`@bradtopol`) or one of the [SIG Docs co-chairs/leads](https://github.com/kubernetes/community/tree/master/sig-docs#leadership). -- Once you've signed up to shadow a PR Wrangler, introduce yourself to the PR Wrangler on the [Kubernetes Slack](slack.k8s.io). \ No newline at end of file +- Once you've signed up to shadow a PR Wrangler, introduce yourself to the PR Wrangler on the [Kubernetes Slack](https://slack.k8s.io). diff --git a/content/en/docs/home/supported-doc-versions.md b/content/en/docs/home/supported-doc-versions.md index b955f95f56..fd3559a4d3 100644 --- a/content/en/docs/home/supported-doc-versions.md +++ b/content/en/docs/home/supported-doc-versions.md @@ -10,3 +10,8 @@ card: This website contains documentation for the current version of Kubernetes and the four previous versions of Kubernetes. + +The availability of documentation for a Kubernetes version is separate from whether +that release is currently supported. +Read [Support period](/releases/patch-releases/#support-period) to learn about +which versions of Kubernetes are officially supported, and for how long. \ No newline at end of file diff --git a/content/en/docs/images/ingress.svg b/content/en/docs/images/ingress.svg new file mode 100644 index 0000000000..450a0aae9b --- /dev/null +++ b/content/en/docs/images/ingress.svg @@ -0,0 +1 @@ +
cluster
Ingress-managed
load balancer
routing rule
Ingress
Pod
Service
Pod
client
 \ No newline at end of file diff --git a/content/en/docs/images/ingressFanOut.svg b/content/en/docs/images/ingressFanOut.svg new file mode 100644 index 0000000000..a6bf202635 --- /dev/null +++ b/content/en/docs/images/ingressFanOut.svg @@ -0,0 +1 @@ +
cluster
Ingress-managed
load balancer
/foo
/bar
Ingress, 178.91.123.132
Pod
Service service1:4200
Pod
Pod
Service service2:8080
Pod
client
 \ No newline at end of file diff --git a/content/en/docs/images/ingressNameBased.svg b/content/en/docs/images/ingressNameBased.svg new file mode 100644 index 0000000000..7e1d7be98c --- /dev/null +++ b/content/en/docs/images/ingressNameBased.svg @@ -0,0 +1 @@ +
cluster
Ingress-managed
load balancer
Host: foo.bar.com
Host: bar.foo.com
Ingress, 178.91.123.132
Pod
Service service1:80
Pod
Pod
Service service2:80
Pod
client
 \ No newline at end of file diff --git a/content/en/docs/images/tutor-service-nodePort-fig01.svg b/content/en/docs/images/tutor-service-nodePort-fig01.svg new file mode 100644 index 0000000000..bb4d866f85 --- /dev/null +++ b/content/en/docs/images/tutor-service-nodePort-fig01.svg @@ -0,0 +1 @@ +
SNAT
SNAT
client
Node 2
Node 1
Endpoint
 \ No newline at end of file diff --git a/content/en/docs/images/tutor-service-nodePort-fig02.svg b/content/en/docs/images/tutor-service-nodePort-fig02.svg new file mode 100644 index 0000000000..1a891575e5 --- /dev/null +++ b/content/en/docs/images/tutor-service-nodePort-fig02.svg @@ -0,0 +1 @@ +
client
Node 1
Node 2
endpoint
 \ No newline at end of file diff --git a/content/en/docs/reference/_index.md b/content/en/docs/reference/_index.md index c4e217af2a..403b84f7c2 100644 --- a/content/en/docs/reference/_index.md +++ b/content/en/docs/reference/_index.md @@ -77,6 +77,7 @@ operator to use or manage a cluster. * [kube-apiserver configuration (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/) * [kube-apiserver configuration (v1)](/docs/reference/config-api/apiserver-config.v1/) * [kube-apiserver encryption (v1)](/docs/reference/config-api/apiserver-encryption.v1/) +* [kube-apiserver event rate limit (v1alpha1)](/docs/reference/config-api/apiserver-eventratelimit.v1/) * [kubelet configuration (v1alpha1)](/docs/reference/config-api/kubelet-config.v1alpha1/) and [kubelet configuration (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/) * [kubelet credential providers (v1alpha1)](/docs/reference/config-api/kubelet-credentialprovider.v1alpha1/) @@ -88,6 +89,7 @@ operator to use or manage a cluster. * [Client authentication API (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/) and [Client authentication API (v1)](/docs/reference/config-api/client-authentication.v1/) * [WebhookAdmission configuration (v1)](/docs/reference/config-api/apiserver-webhookadmission.v1/) +* [ImagePolicy API (v1alpha1)](/docs/reference/config-api/imagepolicy.v1alpha1/) ## Config API for kubeadm diff --git a/content/en/docs/reference/access-authn-authz/admission-controllers.md b/content/en/docs/reference/access-authn-authz/admission-controllers.md index abc3ee9681..f03b04f8e3 100644 --- a/content/en/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md @@ -94,7 +94,7 @@ kube-apiserver -h | grep enable-admission-plugins In the current version, the default ones are: ```shell -CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, LimitRanger, MutatingAdmissionWebhook, NamespaceLifecycle, PersistentVolumeClaimResize, Priority, ResourceQuota, RuntimeClass, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook +CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, LimitRanger, MutatingAdmissionWebhook, NamespaceLifecycle, PersistentVolumeClaimResize, PodSecurity, Priority, ResourceQuota, RuntimeClass, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook ``` ## What does each admission controller do? @@ -139,7 +139,7 @@ requests with the `spec.signerName` requested on the CertificateSigningRequest r See [Certificate Signing Requests](/docs/reference/access-authn-authz/certificate-signing-requests/) for more information on the permissions required to perform different actions on CertificateSigningRequest resources. -### CertificateSubjectRestrictions {#certificatesubjectrestrictions} +### CertificateSubjectRestriction {#certificatesubjectrestriction} This admission controller observes creation of CertificateSigningRequest resources that have a `spec.signerName` of `kubernetes.io/kube-apiserver-client`. It rejects any request that specifies a 'group' (or 'organization attribute') @@ -232,12 +232,10 @@ of it. This admission controller mitigates the problem where the API server gets flooded by event requests. The cluster admin can specify event rate limits by: - * Enabling the `EventRateLimit` admission controller; - * Referencing an `EventRateLimit` configuration file from the file provided to the API - server's command line flag `--admission-control-config-file`: +* Enabling the `EventRateLimit` admission controller; +* Referencing an `EventRateLimit` configuration file from the file provided to the API + server's command line flag `--admission-control-config-file`: -{{< tabs name="eventratelimit_example" >}} -{{% tab name="apiserver.config.k8s.io/v1" %}} ```yaml apiVersion: apiserver.config.k8s.io/v1 kind: AdmissionConfiguration @@ -246,19 +244,6 @@ plugins: path: eventconfig.yaml ... ``` -{{% /tab %}} -{{% tab name="apiserver.k8s.io/v1alpha1" %}} -```yaml -# Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1 -apiVersion: apiserver.k8s.io/v1alpha1 -kind: AdmissionConfiguration -plugins: -- name: EventRateLimit - path: eventconfig.yaml -... -``` -{{% /tab %}} -{{< /tabs >}} There are four types of limits that can be specified in the configuration: @@ -283,7 +268,7 @@ limits: burst: 50 ``` -See the [EventRateLimit proposal](https://git.k8s.io/community/contributors/design-proposals/api-machinery/admission_control_event_rate_limit.md) +See the [EventRateLimit Config API (v1alpha1)](/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/) for more details. ### ExtendedResourceToleration {#extendedresourcetoleration} @@ -319,8 +304,6 @@ imagePolicy: Reference the ImagePolicyWebhook configuration file from the file provided to the API server's command line flag `--admission-control-config-file`: -{{< tabs name="imagepolicywebhook_example1" >}} -{{% tab name="apiserver.config.k8s.io/v1" %}} ```yaml apiVersion: apiserver.config.k8s.io/v1 kind: AdmissionConfiguration @@ -329,24 +312,9 @@ plugins: path: imagepolicyconfig.yaml ... ``` -{{% /tab %}} -{{% tab name="apiserver.k8s.io/v1alpha1" %}} -```yaml -# Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1 -apiVersion: apiserver.k8s.io/v1alpha1 -kind: AdmissionConfiguration -plugins: -- name: ImagePolicyWebhook - path: imagepolicyconfig.yaml -... -``` -{{% /tab %}} -{{< /tabs >}} Alternatively, you can embed the configuration directly in the file: -{{< tabs name="imagepolicywebhook_example2" >}} -{{% tab name="apiserver.config.k8s.io/v1" %}} ```yaml apiVersion: apiserver.config.k8s.io/v1 kind: AdmissionConfiguration @@ -360,31 +328,14 @@ plugins: retryBackoff: 500 defaultAllow: true ``` -{{% /tab %}} -{{% tab name="apiserver.k8s.io/v1alpha1" %}} -```yaml -# Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1 -apiVersion: apiserver.k8s.io/v1alpha1 -kind: AdmissionConfiguration -plugins: -- name: ImagePolicyWebhook - configuration: - imagePolicy: - kubeConfigFile: - allowTTL: 50 - denyTTL: 50 - retryBackoff: 500 - defaultAllow: true -``` -{{% /tab %}} -{{< /tabs >}} The ImagePolicyWebhook config file must reference a [kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) formatted file which sets up the connection to the backend. It is required that the backend communicate over TLS. -The kubeconfig file's cluster field must point to the remote service, and the user field must contain the returned authorizer. +The kubeconfig file's `cluster` field must point to the remote service, and the `user` field +must contain the returned authorizer. ```yaml # clusters refers to the remote service. @@ -405,11 +356,21 @@ users: For additional HTTP configuration, refer to the [kubeconfig](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) documentation. -#### Request Payloads +#### Request payloads -When faced with an admission decision, the API Server POSTs a JSON serialized `imagepolicy.k8s.io/v1alpha1` `ImageReview` object describing the action. This object contains fields describing the containers being admitted, as well as any pod annotations that match `*.image-policy.k8s.io/*`. +When faced with an admission decision, the API Server POSTs a JSON serialized +`imagepolicy.k8s.io/v1alpha1` `ImageReview` object describing the action. +This object contains fields describing the containers being admitted, as well as +any pod annotations that match `*.image-policy.k8s.io/*`. -Note that webhook API objects are subject to the same versioning compatibility rules as other Kubernetes API objects. Implementers should be aware of looser compatibility promises for alpha objects and check the "apiVersion" field of the request to ensure correct deserialization. Additionally, the API Server must enable the imagepolicy.k8s.io/v1alpha1 API extensions group (`--runtime-config=imagepolicy.k8s.io/v1alpha1=true`). +{{ note }} +The webhook API objects are subject to the same versioning compatibility rules +as other Kubernetes API objects. Implementers should be aware of looser compatibility +promises for alpha objects and check the `apiVersion` field of the request to +ensure correct deserialization. +Additionally, the API Server must enable the `imagepolicy.k8s.io/v1alpha1` API extensions +group (`--runtime-config=imagepolicy.k8s.io/v1alpha1=true`). +{{ /note }} An example request body: @@ -434,7 +395,9 @@ An example request body: } ``` -The remote service is expected to fill the `ImageReviewStatus` field of the request and respond to either allow or disallow access. The response body's "spec" field is ignored and may be omitted. A permissive response would return: +The remote service is expected to fill the `ImageReviewStatus` field of the request and +respond to either allow or disallow access. The response body's `spec` field is ignored and +may be omitted. A permissive response would return: ```json { @@ -459,19 +422,23 @@ To disallow access, the service would return: } ``` -For further documentation refer to the `imagepolicy.v1alpha1` API objects and `plugin/pkg/admission/imagepolicy/admission.go`. +For further documentation refer to the +[`imagepolicy.v1alpha1` API](/docs/reference/config-api/imagepolicy.v1alpha1/). #### Extending with Annotations -All annotations on a Pod that match `*.image-policy.k8s.io/*` are sent to the webhook. Sending annotations allows users who are aware of the image policy backend to send extra information to it, and for different backends implementations to accept different information. +All annotations on a Pod that match `*.image-policy.k8s.io/*` are sent to the webhook. +Sending annotations allows users who are aware of the image policy backend to +send extra information to it, and for different backends implementations to +accept different information. Examples of information you might put here are: - * request to "break glass" to override a policy, in case of emergency. - * a ticket number from a ticket system that documents the break-glass request - * provide a hint to the policy server as to the imageID of the image being provided, to save it a lookup +* request to "break glass" to override a policy, in case of emergency. +* a ticket number from a ticket system that documents the break-glass request +* provide a hint to the policy server as to the imageID of the image being provided, to save it a lookup -In any case, the annotations are provided by the user and are not validated by Kubernetes in any way. In the future, if an annotation is determined to be widely useful, it may be promoted to a named field of `ImageReviewSpec`. +In any case, the annotations are provided by the user and are not validated by Kubernetes in any way. ### LimitPodHardAntiAffinityTopology {#limitpodhardantiaffinitytopology} @@ -480,14 +447,16 @@ This admission controller denies any pod that defines `AntiAffinity` topology ke ### LimitRanger {#limitranger} -This admission controller will observe the incoming request and ensure that it does not violate any of the constraints -enumerated in the `LimitRange` object in a `Namespace`. If you are using `LimitRange` objects in -your Kubernetes deployment, you MUST use this admission controller to enforce those constraints. LimitRanger can also -be used to apply default resource requests to Pods that don't specify any; currently, the default LimitRanger -applies a 0.1 CPU requirement to all Pods in the `default` namespace. +This admission controller will observe the incoming request and ensure that it does not violate +any of the constraints enumerated in the `LimitRange` object in a `Namespace`. If you are using +`LimitRange` objects in your Kubernetes deployment, you MUST use this admission controller to +enforce those constraints. LimitRanger can also be used to apply default resource requests to Pods +that don't specify any; currently, the default LimitRanger applies a 0.1 CPU requirement to all +Pods in the `default` namespace. -See the [limitRange design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) -and the [example of Limit Range](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) for more details. +See the [LimitRange API reference](/docs/reference/kubernetes-api/policy-resources/limit-range-v1/) +and the [example of LimitRange](/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) +for more details. ### MutatingAdmissionWebhook {#mutatingadmissionwebhook} @@ -502,21 +471,20 @@ webhooks or validating admission controllers will permit the request to finish. If you disable the MutatingAdmissionWebhook, you must also disable the `MutatingWebhookConfiguration` object in the `admissionregistration.k8s.io/v1` -group/version via the `--runtime-config` flag (both are on by default in -versions >= 1.9). +group/version via the `--runtime-config` flag, both are on by default. #### Use caution when authoring and installing mutating webhooks - * Users may be confused when the objects they try to create are different from - what they get back. - * Built in control loops may break when the objects they try to create are - different when read back. - * Setting originally unset fields is less likely to cause problems than - overwriting fields set in the original request. Avoid doing the latter. - * Future changes to control loops for built-in resources or third-party resources - may break webhooks that work well today. Even when the webhook installation API - is finalized, not all possible webhook behaviors will be guaranteed to be supported - indefinitely. +* Users may be confused when the objects they try to create are different from + what they get back. +* Built in control loops may break when the objects they try to create are + different when read back. + * Setting originally unset fields is less likely to cause problems than + overwriting fields set in the original request. Avoid doing the latter. +* Future changes to control loops for built-in resources or third-party resources + may break webhooks that work well today. Even when the webhook installation API + is finalized, not all possible webhook behaviors will be guaranteed to be supported + indefinitely. ### NamespaceAutoProvision {#namespaceautoprovision} @@ -533,26 +501,28 @@ If the namespace referenced from a request doesn't exist, the request is rejecte ### NamespaceLifecycle {#namespacelifecycle} -This admission controller enforces that a `Namespace` that is undergoing termination cannot have new objects created in it, -and ensures that requests in a non-existent `Namespace` are rejected. This admission controller also prevents deletion of -three system reserved namespaces `default`, `kube-system`, `kube-public`. +This admission controller enforces that a `Namespace` that is undergoing termination cannot have +new objects created in it, and ensures that requests in a non-existent `Namespace` are rejected. +This admission controller also prevents deletion of three system reserved namespaces `default`, +`kube-system`, `kube-public`. -A `Namespace` deletion kicks off a sequence of operations that remove all objects (pods, services, etc.) in that -namespace. In order to enforce integrity of that process, we strongly recommend running this admission controller. +A `Namespace` deletion kicks off a sequence of operations that remove all objects (pods, services, +etc.) in that namespace. In order to enforce integrity of that process, we strongly recommend +running this admission controller. ### NodeRestriction {#noderestriction} This admission controller limits the `Node` and `Pod` objects a kubelet can modify. In order to be limited by this admission controller, kubelets must use credentials in the `system:nodes` group, with a username in the form `system:node:`. Such kubelets will only be allowed to modify their own `Node` API object, and only modify `Pod` API objects that are bound to their node. -In Kubernetes 1.11+, kubelets are not allowed to update or remove taints from their `Node` API object. +kubelets are not allowed to update or remove taints from their `Node` API object. -In Kubernetes 1.13+, the `NodeRestriction` admission plugin prevents kubelets from deleting their `Node` API object, +The `NodeRestriction` admission plugin prevents kubelets from deleting their `Node` API object, and enforces kubelet modification of labels under the `kubernetes.io/` or `k8s.io/` prefixes as follows: * **Prevents** kubelets from adding/removing/updating labels with a `node-restriction.kubernetes.io/` prefix. -This label prefix is reserved for administrators to label their `Node` objects for workload isolation purposes, -and kubelets will not be allowed to modify labels with that prefix. + This label prefix is reserved for administrators to label their `Node` objects for workload isolation purposes, + and kubelets will not be allowed to modify labels with that prefix. * **Allows** kubelets to add/remove/update these labels and label prefixes: * `kubernetes.io/hostname` * `kubernetes.io/arch` @@ -566,9 +536,11 @@ and kubelets will not be allowed to modify labels with that prefix. * `kubelet.kubernetes.io/`-prefixed labels * `node.kubernetes.io/`-prefixed labels -Use of any other labels under the `kubernetes.io` or `k8s.io` prefixes by kubelets is reserved, and may be disallowed or allowed by the `NodeRestriction` admission plugin in the future. +Use of any other labels under the `kubernetes.io` or `k8s.io` prefixes by kubelets is reserved, +and may be disallowed or allowed by the `NodeRestriction` admission plugin in the future. -Future versions may add additional restrictions to ensure kubelets have the minimal set of permissions required to operate correctly. +Future versions may add additional restrictions to ensure kubelets have the minimal set of +permissions required to operate correctly. ### OwnerReferencesPermissionEnforcement {#ownerreferencespermissionenforcement} @@ -582,7 +554,8 @@ subresource of the referenced *owner* can change it. {{< feature-state for_k8s_version="v1.24" state="stable" >}} -This admission controller implements additional validations for checking incoming `PersistentVolumeClaim` resize requests. +This admission controller implements additional validations for checking incoming +`PersistentVolumeClaim` resize requests. Enabling the `PersistentVolumeClaimResize` admission controller is recommended. This admission controller prevents resizing of all claims by default unless a claim's `StorageClass` @@ -624,9 +597,10 @@ Starting from 1.11, this admission controller is disabled by default. {{< feature-state for_k8s_version="v1.5" state="alpha" >}} -This admission controller defaults and limits what node selectors may be used within a namespace by reading a namespace annotation and a global configuration. +This admission controller defaults and limits what node selectors may be used within a namespace +by reading a namespace annotation and a global configuration. -#### Configuration File Format +#### Configuration file format `PodNodeSelector` uses a configuration file to set options for the behavior of the backend. Note that the configuration file format will move to a versioned file in a future release. @@ -639,10 +613,9 @@ podNodeSelectorPluginConfig: namespace2: name-of-node-selector ``` -Reference the `PodNodeSelector` configuration file from the file provided to the API server's command line flag `--admission-control-config-file`: +Reference the `PodNodeSelector` configuration file from the file provided to the API server's +command line flag `--admission-control-config-file`: -{{< tabs name="podnodeselector_example1" >}} -{{% tab name="apiserver.config.k8s.io/v1" %}} ```yaml apiVersion: apiserver.config.k8s.io/v1 kind: AdmissionConfiguration @@ -651,23 +624,11 @@ plugins: path: podnodeselector.yaml ... ``` -{{% /tab %}} -{{% tab name="apiserver.k8s.io/v1alpha1" %}} -```yaml -# Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1 -apiVersion: apiserver.k8s.io/v1alpha1 -kind: AdmissionConfiguration -plugins: -- name: PodNodeSelector - path: podnodeselector.yaml -... -``` -{{% /tab %}} -{{< /tabs >}} #### Configuration Annotation Format -`PodNodeSelector` uses the annotation key `scheduler.alpha.kubernetes.io/node-selector` to assign node selectors to namespaces. +`PodNodeSelector` uses the annotation key `scheduler.alpha.kubernetes.io/node-selector` to assign +node selectors to namespaces. ```yaml apiVersion: v1 @@ -682,13 +643,14 @@ metadata: This admission controller has the following behavior: -1. If the `Namespace` has an annotation with a key `scheduler.alpha.kubernetes.io/node-selector`, use its value as the -node selector. -2. If the namespace lacks such an annotation, use the `clusterDefaultNodeSelector` defined in the `PodNodeSelector` -plugin configuration file as the node selector. -3. Evaluate the pod's node selector against the namespace node selector for conflicts. Conflicts result in rejection. -4. Evaluate the pod's node selector against the namespace-specific allowed selector defined the plugin configuration file. -Conflicts result in rejection. +1. If the `Namespace` has an annotation with a key `scheduler.alpha.kubernetes.io/node-selector`, + use its value as the node selector. +2. If the namespace lacks such an annotation, use the `clusterDefaultNodeSelector` defined in the + `PodNodeSelector` plugin configuration file as the node selector. +3. Evaluate the pod's node selector against the namespace node selector for conflicts. Conflicts + result in rejection. +4. Evaluate the pod's node selector against the namespace-specific allowed selector defined the + plugin configuration file. Conflicts result in rejection. {{< note >}} PodNodeSelector allows forcing pods to run on specifically labeled nodes. Also see the PodTolerationRestriction @@ -721,7 +683,8 @@ for more information. {{< feature-state for_k8s_version="v1.7" state="alpha" >}} -The PodTolerationRestriction admission controller verifies any conflict between tolerations of a pod and the tolerations of its namespace. +The PodTolerationRestriction admission controller verifies any conflict between tolerations of a +pod and the tolerations of its namespace. It rejects the pod request if there is a conflict. It then merges the tolerations annotated on the namespace into the tolerations of the pod. The resulting tolerations are checked against a list of allowed tolerations annotated to the namespace. @@ -748,16 +711,18 @@ metadata: ### Priority {#priority} -The priority admission controller uses the `priorityClassName` field and populates the integer value of the priority. +The priority admission controller uses the `priorityClassName` field and populates the integer +value of the priority. If the priority class is not found, the Pod is rejected. ### ResourceQuota {#resourcequota} -This admission controller will observe the incoming request and ensure that it does not violate any of the constraints -enumerated in the `ResourceQuota` object in a `Namespace`. If you are using `ResourceQuota` -objects in your Kubernetes deployment, you MUST use this admission controller to enforce quota constraints. +This admission controller will observe the incoming request and ensure that it does not violate +any of the constraints enumerated in the `ResourceQuota` object in a `Namespace`. If you are +using `ResourceQuota` objects in your Kubernetes deployment, you MUST use this admission +controller to enforce quota constraints. -See the [resourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) +See the [ResourceQuota API reference](/docs/reference/kubernetes-api/policy-resources/resource-quota-v1/) and the [example of Resource Quota](/docs/concepts/policy/resource-quotas/) for more details. ### RuntimeClass {#runtimeclass} @@ -793,14 +758,15 @@ pod privileges. This admission controller implements automation for [serviceAccounts](/docs/tasks/configure-pod-container/configure-service-account/). -We strongly recommend using this admission controller if you intend to make use of Kubernetes `ServiceAccount` objects. +We strongly recommend using this admission controller if you intend to make use of Kubernetes +`ServiceAccount` objects. ### StorageObjectInUseProtection The `StorageObjectInUseProtection` plugin adds the `kubernetes.io/pvc-protection` or `kubernetes.io/pv-protection` finalizers to newly created Persistent Volume Claims (PVCs) or Persistent Volumes (PV). In case a user deletes a PVC or PV the PVC or PV is not removed until the finalizer is removed -from the PVC or PV by PVC or PV Protection Controller. +from the PVC or PV by PVC or PV Protection Controller. Refer to the [Storage Object in Use Protection](/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection) for more detailed information. @@ -809,7 +775,10 @@ for more detailed information. {{< feature-state for_k8s_version="v1.17" state="stable" >}} -This admission controller {{< glossary_tooltip text="taints" term_id="taint" >}} newly created Nodes as `NotReady` and `NoSchedule`. That tainting avoids a race condition that could cause Pods to be scheduled on new Nodes before their taints were updated to accurately reflect their reported conditions. +This admission controller {{< glossary_tooltip text="taints" term_id="taint" >}} newly created +Nodes as `NotReady` and `NoSchedule`. That tainting avoids a race condition that could cause Pods +to be scheduled on new Nodes before their taints were updated to accurately reflect their reported +conditions. ### ValidatingAdmissionWebhook {#validatingadmissionwebhook} diff --git a/content/en/docs/reference/access-authn-authz/bootstrap-tokens.md b/content/en/docs/reference/access-authn-authz/bootstrap-tokens.md index 7e743be63d..b8a7faa946 100644 --- a/content/en/docs/reference/access-authn-authz/bootstrap-tokens.md +++ b/content/en/docs/reference/access-authn-authz/bootstrap-tokens.md @@ -70,7 +70,7 @@ controller on the controller manager. Each valid token is backed by a secret in the `kube-system` namespace. You can find the full design doc -[here](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md). +[here](https://github.com/kubernetes/design-proposals-archive/blob/main/cluster-lifecycle/bootstrap-discovery.md). Here is what the secret looks like. diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet.md b/content/en/docs/reference/command-line-tools-reference/kubelet.md index 555414a6eb..b10e1b7057 100644 --- a/content/en/docs/reference/command-line-tools-reference/kubelet.md +++ b/content/en/docs/reference/command-line-tools-reference/kubelet.md @@ -44,70 +44,70 @@ kubelet [flags] --add-dir-header -If true, adds the file directory to the header of the log messages (DEPRECATED: will be removed in a future release, see https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components) +If true, adds the file directory to the header of the log messages (DEPRECATED: will be removed in a future release, see here.) --address string     Default: 0.0.0.0 -The IP address for the Kubelet to serve on (set to 0.0.0.0 or :: for listening in all interfaces and IP families) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +The IP address for the Kubelet to serve on (set to 0.0.0.0 or :: for listening in all interfaces and IP families) (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --allowed-unsafe-sysctls strings -Comma-separated whitelist of unsafe sysctls or unsafe sysctl patterns (ending in *). Use these at your own risk. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Comma-separated whitelist of unsafe sysctls or unsafe sysctl patterns (ending in *). Use these at your own risk. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --alsologtostderr -Log to standard error as well as files (DEPRECATED: will be removed in a future release, see https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components) +Log to standard error as well as files (DEPRECATED: will be removed in a future release, see here.) --anonymous-auth     Default: true -Enables anonymous requests to the Kubelet server. Requests that are not rejected by another authentication method are treated as anonymous requests. Anonymous requests have a username of system:anonymous, and a group name of system:unauthenticated. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Enables anonymous requests to the Kubelet server. Requests that are not rejected by another authentication method are treated as anonymous requests. Anonymous requests have a username of system:anonymous, and a group name of system:unauthenticated. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --authentication-token-webhook -Use the TokenReview API to determine authentication for bearer tokens. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Use the TokenReview API to determine authentication for bearer tokens. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --authentication-token-webhook-cache-ttl duration     Default: 2m0s -The duration to cache responses from the webhook token authenticator. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +The duration to cache responses from the webhook token authenticator. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --authorization-mode string     Default: AlwaysAllow -Authorization mode for Kubelet server. Valid options are AlwaysAllow or Webhook. Webhook mode uses the SubjectAccessReview API to determine authorization. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Authorization mode for Kubelet server. Valid options are AlwaysAllow or Webhook. Webhook mode uses the SubjectAccessReview API to determine authorization. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --authorization-webhook-cache-authorized-ttl duration     Default: 5m0s -The duration to cache 'authorized' responses from the webhook authorizer. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +The duration to cache 'authorized' responses from the webhook authorizer. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --authorization-webhook-cache-unauthorized-ttl duration     Default: 30s -The duration to cache 'unauthorized' responses from the webhook authorizer. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +The duration to cache 'unauthorized' responses from the webhook authorizer. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -135,28 +135,28 @@ kubelet [flags] --cgroup-driver string     Default: cgroupfs -Driver that the kubelet uses to manipulate cgroups on the host. Possible values: cgroupfs, systemd. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.)/td> +Driver that the kubelet uses to manipulate cgroups on the host. Possible values: cgroupfs, systemd. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --cgroup-root string     Default: '' -Optional root cgroup to use for pods. This is handled by the container runtime on a best effort basis. Default: '', which means use the container runtime default. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Optional root cgroup to use for pods. This is handled by the container runtime on a best effort basis. Default: '', which means use the container runtime default. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --cgroups-per-qos     Default: true -Enable creation of QoS cgroup hierarchy, if true top level QoS and pod cgroups are created. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Enable creation of QoS cgroup hierarchy, if true top level QoS and pod cgroups are created. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --client-ca-file string -If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +If set, any request presenting a client certificate signed by one of the authorities in the client-ca-file is authenticated with an identity corresponding to the CommonName of the client certificate. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -177,14 +177,14 @@ kubelet [flags] --cluster-dns strings -Comma-separated list of DNS server IP address. This value is used for containers DNS server in case of Pods with "dnsPolicy=ClusterFirst".
Note: all DNS servers appearing in the list MUST serve the same set of records otherwise name resolution within the cluster may not work correctly. There is no guarantee as to which DNS server may be contacted for name resolution. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Comma-separated list of DNS server IP address. This value is used for containers DNS server in case of Pods with "dnsPolicy=ClusterFirst".
Note: all DNS servers appearing in the list MUST serve the same set of records otherwise name resolution within the cluster may not work correctly. There is no guarantee as to which DNS server may be contacted for name resolution. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --cluster-domain string -Domain for this cluster. If set, kubelet will configure all containers to search this domain in addition to the host's search domains (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Domain for this cluster. If set, kubelet will configure all containers to search this domain in addition to the host's search domains (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -219,14 +219,14 @@ kubelet [flags] --container-log-max-files int32     Default: 5 -<Warning: Beta feature> Set the maximum number of container log files that can be present for a container. The number must be >= 2. This flag can only be used with --container-runtime=remote. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +<Warning: Beta feature> Set the maximum number of container log files that can be present for a container. The number must be >= 2. This flag can only be used with --container-runtime=remote. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --container-log-max-size string     Default: 10Mi -<Warning: Beta feature> Set the maximum size (e.g. 10Mi) of container log file before it is rotated. This flag can only be used with --container-runtime=remote. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +<Warning: Beta feature> Set the maximum size (e.g. 10Mi) of container log file before it is rotated. This flag can only be used with --container-runtime=remote. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -248,42 +248,42 @@ kubelet [flags] --contention-profiling -Enable lock contention profiling, if profiling is enabled (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Enable lock contention profiling, if profiling is enabled (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --cpu-cfs-quota     Default: true -Enable CPU CFS quota enforcement for containers that specify CPU limits (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Enable CPU CFS quota enforcement for containers that specify CPU limits (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --cpu-cfs-quota-period duration     Default: 100ms -Sets CPU CFS quota period value, cpu.cfs_period_us, defaults to Linux Kernel default. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Sets CPU CFS quota period value, cpu.cfs_period_us, defaults to Linux Kernel default. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --cpu-manager-policy string     Default: none -CPU Manager policy to use. Possible values: none, static. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +CPU Manager policy to use. Possible values: none, static. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --cpu-manager-policy-options mapStringString -Comma-separated list of options to fine-tune the behavior of the selected CPU Manager policy. If not supplied, keep the default behaviour. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Comma-separated list of options to fine-tune the behavior of the selected CPU Manager policy. If not supplied, keep the default behaviour. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --cpu-manager-reconcile-period duration     Default: 10s -<Warning: Alpha feature> CPU Manager reconciliation period. Examples: 10s, or 1m. If not supplied, defaults to node status update frequency. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +<Warning: Alpha feature> CPU Manager reconciliation period. Examples: 10s, or 1m. If not supplied, defaults to node status update frequency. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -304,84 +304,84 @@ kubelet [flags] --enable-controller-attach-detach     Default: true -Enables the Attach/Detach controller to manage attachment/detachment of volumes scheduled to this node, and disables kubelet from executing any attach/detach operations. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Enables the Attach/Detach controller to manage attachment/detachment of volumes scheduled to this node, and disables kubelet from executing any attach/detach operations. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --enable-debugging-handlers     Default: true -Enables server endpoints for log collection and local running of containers and commands. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Enables server endpoints for log collection and local running of containers and commands. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --enable-server     Default: true -Enable the Kubelet's server. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Enable the Kubelet's server. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --enforce-node-allocatable strings     Default: pods -A comma separated list of levels of node allocatable enforcement to be enforced by kubelet. Acceptable options are none, pods, system-reserved, and kube-reserved. If the latter two options are specified, --system-reserved-cgroup and --kube-reserved-cgroup must also be set, respectively. If none is specified, no additional options should be set. See https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/ for more details. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +A comma separated list of levels of node allocatable enforcement to be enforced by kubelet. Acceptable options are none, pods, system-reserved, and kube-reserved. If the latter two options are specified, --system-reserved-cgroup and --kube-reserved-cgroup must also be set, respectively. If none is specified, no additional options should be set. See here for more details. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --event-burst int32     Default: 10 -Maximum size of a bursty event records, temporarily allows event records to burst to this number, while still not exceeding --event-qps. The number must be >= 0. If 0 will use default burst (10). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Maximum size of a bursty event records, temporarily allows event records to burst to this number, while still not exceeding --event-qps. The number must be >= 0. If 0 will use default burst (10). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --event-qps int32     Default: 5 -QPS to limit event creations. The number must be >= 0. If 0 will use default QPS (5). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +QPS to limit event creations. The number must be >= 0. If 0 will use default QPS (5). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --eviction-hard mapStringString     Default: imagefs.available<15%,memory.available<100Mi,nodefs.available<10% -A set of eviction thresholds (e.g. memory.available<1Gi) that if met would trigger a pod eviction. On a Linux node, the default value also includes nodefs.inodesFree<5%. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +A set of eviction thresholds (e.g. memory.available<1Gi) that if met would trigger a pod eviction. On a Linux node, the default value also includes nodefs.inodesFree<5%. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --eviction-max-pod-grace-period int32 - Maximum allowed grace period (in seconds) to use when terminating pods in response to a soft eviction threshold being met. If negative, defer to pod specified value. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) + Maximum allowed grace period (in seconds) to use when terminating pods in response to a soft eviction threshold being met. If negative, defer to pod specified value. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --eviction-minimum-reclaim mapStringString -A set of minimum reclaims (e.g. imagefs.available=2Gi) that describes the minimum amount of resource the kubelet will reclaim when performing a pod eviction if that resource is under pressure. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +A set of minimum reclaims (e.g. imagefs.available=2Gi) that describes the minimum amount of resource the kubelet will reclaim when performing a pod eviction if that resource is under pressure. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --eviction-pressure-transition-period duration     Default: 5m0s -Duration for which the kubelet has to wait before transitioning out of an eviction pressure condition. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Duration for which the kubelet has to wait before transitioning out of an eviction pressure condition. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --eviction-soft mapStringString -A set of eviction thresholds (e.g. memory.available<1.5Gi) that if met over a corresponding grace period would trigger a pod eviction. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +A set of eviction thresholds (e.g. memory.available<1.5Gi) that if met over a corresponding grace period would trigger a pod eviction. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --eviction-soft-grace-period mapStringString -A set of eviction grace periods (e.g. memory.available=1m30s) that correspond to how long a soft eviction threshold must hold before triggering a pod eviction. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +A set of eviction grace periods (e.g. memory.available=1m30s) that correspond to how long a soft eviction threshold must hold before triggering a pod eviction. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -395,7 +395,7 @@ kubelet [flags] --experimental-allocatable-ignore-eviction     Default: false -When set to true, hard eviction thresholds will be ignored while calculating node allocatable. See https://kubernetes.io/docs/tasks/administer-cluster/reserve-compute-resources/ for more details. (DEPRECATED: will be removed in 1.24 or later) +When set to true, hard eviction thresholds will be ignored while calculating node allocatable. See here for more details. (DEPRECATED: will be removed in 1.24 or later) @@ -409,14 +409,14 @@ kubelet [flags] --experimental-kernel-memcg-notification -Use kernelMemcgNotification configuration, this flag will be removed in 1.24 or later. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Use kernelMemcgNotification configuration, this flag will be removed in 1.24 or later. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --experimental-log-sanitization bool -[Experimental] When enabled, prevents logging of fields tagged as sensitive (passwords, keys, tokens). Runtime log sanitization may introduce significant computation overhead and therefore should not be enabled in production. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +[Experimental] When enabled, prevents logging of fields tagged as sensitive (passwords, keys, tokens). Runtime log sanitization may introduce significant computation overhead and therefore should not be enabled in production. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -430,7 +430,7 @@ kubelet [flags] --fail-swap-on     Default: true -Makes the Kubelet fail to start if swap is enabled on the node. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Makes the Kubelet fail to start if swap is enabled on the node. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -548,35 +548,35 @@ WinDSR=true|false (ALPHA - default=false)
WinOverlay=true|false (BETA - default=true)
WindowsHostProcessContainers=true|false (BETA - default=true)
csiMigrationRBD=true|false (ALPHA - default=false)
-(DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +(DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --file-check-frequency duration     Default: 20s -Duration between checking config files for new data. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Duration between checking config files for new data. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --hairpin-mode string     Default: promiscuous-bridge -How should the kubelet setup hairpin NAT. This allows endpoints of a Service to load balance back to themselves if they should try to access their own Service. Valid values are promiscuous-bridge, hairpin-veth and none. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +How should the kubelet setup hairpin NAT. This allows endpoints of a Service to load balance back to themselves if they should try to access their own Service. Valid values are promiscuous-bridge, hairpin-veth and none. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --healthz-bind-address string     Default: 127.0.0.1 -The IP address for the healthz server to serve on (set to 0.0.0.0 or :: for listening in all interfaces and IP families). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +The IP address for the healthz server to serve on (set to 0.0.0.0 or :: for listening in all interfaces and IP families). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --healthz-port int32     Default: 10248 -The port of the localhost healthz endpoint (set to 0 to disable). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +The port of the localhost healthz endpoint (set to 0 to disable). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -597,7 +597,7 @@ csiMigrationRBD=true|false (ALPHA - default=false)
--http-check-frequency duration     Default: 20s -Duration between checking HTTP for new data. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Duration between checking HTTP for new data. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -618,14 +618,14 @@ csiMigrationRBD=true|false (ALPHA - default=false)
--image-gc-high-threshold int32     Default: 85 -The percent of disk usage after which image garbage collection is always run. Values must be within the range [0, 100], To disable image garbage collection, set to 100. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +The percent of disk usage after which image garbage collection is always run. Values must be within the range [0, 100], To disable image garbage collection, set to 100. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --image-gc-low-threshold int32     Default: 80 -The percent of disk usage before which image garbage collection is never run. Lowest disk usage to garbage collect to. Values must be within the range [0, 100] and should not be larger than that of --image-gc-high-threshold. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +The percent of disk usage before which image garbage collection is never run. Lowest disk usage to garbage collect to. Values must be within the range [0, 100] and should not be larger than that of --image-gc-high-threshold. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -646,14 +646,14 @@ csiMigrationRBD=true|false (ALPHA - default=false)
--iptables-drop-bit int32     Default: 15 -The bit of the fwmark space to mark packets for dropping. Must be within the range [0, 31]. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +The bit of the fwmark space to mark packets for dropping. Must be within the range [0, 31]. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --iptables-masquerade-bit int32     Default: 14 -The bit of the fwmark space to mark packets for SNAT. Must be within the range [0, 31]. Please match this parameter with corresponding parameter in kube-proxy. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +The bit of the fwmark space to mark packets for SNAT. Must be within the range [0, 31]. Please match this parameter with corresponding parameter in kube-proxy. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -667,42 +667,42 @@ csiMigrationRBD=true|false (ALPHA - default=false)
--kernel-memcg-notification -If enabled, the kubelet will integrate with the kernel memcg notification to determine if memory eviction thresholds are crossed rather than polling. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +If enabled, the kubelet will integrate with the kernel memcg notification to determine if memory eviction thresholds are crossed rather than polling. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --kube-api-burst int32     Default: 10 -Burst to use while talking with kubernetes API server. The number must be >= 0. If 0 will use default burst (10). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Burst to use while talking with kubernetes API server. The number must be >= 0. If 0 will use default burst (10). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --kube-api-content-type string     Default: application/vnd.kubernetes.protobuf -Content type of requests sent to apiserver. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Content type of requests sent to apiserver. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --kube-api-qps int32     Default: 5 -QPS to use while talking with kubernetes API server. The number must be >= 0. If 0 will use default QPS (5). Doesn't cover events and node heartbeat apis which rate limiting is controlled by a different set of flags. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +QPS to use while talking with kubernetes API server. The number must be >= 0. If 0 will use default QPS (5). Doesn't cover events and node heartbeat apis which rate limiting is controlled by a different set of flags. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --kube-reserved mapStringString     Default: <None> -A set of <resource name>=<resource quantity> (e.g. cpu=200m,memory=500Mi,ephemeral-storage=1Gi,pid='100') pairs that describe resources reserved for kubernetes system components. Currently cpu, memory and local ephemeral-storage for root file system are supported. See http://kubernetes.io/docs/user-guide/compute-resources for more detail. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +A set of <resource name>=<resource quantity> (e.g. cpu=200m,memory=500Mi,ephemeral-storage=1Gi,pid='100') pairs that describe resources reserved for kubernetes system components. Currently cpu, memory and local ephemeral-storage for root file system are supported. See here for more detail. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --kube-reserved-cgroup string     Default: '' -Absolute name of the top level cgroup that is used to manage kubernetes components for which compute resources were reserved via --kube-reserved flag. Ex. /kube-reserved. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Absolute name of the top level cgroup that is used to manage kubernetes components for which compute resources were reserved via --kube-reserved flag. Ex. /kube-reserved. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -716,7 +716,7 @@ csiMigrationRBD=true|false (ALPHA - default=false)
--kubelet-cgroups string -Optional absolute name of cgroups to create and run the Kubelet in. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Optional absolute name of cgroups to create and run the Kubelet in. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -730,28 +730,28 @@ csiMigrationRBD=true|false (ALPHA - default=false)
--log-backtrace-at <A string of format 'file:line'>     Default: ":0" -When logging hits line :, emit a stack trace. (DEPRECATED: will be removed in a future release, see https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components) +When logging hits line :, emit a stack trace. (DEPRECATED: will be removed in a future release, see here.) --log-dir string -If non-empty, write log files in this directory. (DEPRECATED: will be removed in a future release, see https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components) +If non-empty, write log files in this directory. (DEPRECATED: will be removed in a future release, see here.) --log-file string -If non-empty, use this log file. (DEPRECATED: will be removed in a future release, see https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components) +If non-empty, use this log file. (DEPRECATED: will be removed in a future release, see here.) --log-file-max-size uint     Default: 1800 -Defines the maximum size a log file can grow to. Unit is megabytes. If the value is 0, the maximum file size is unlimited. (DEPRECATED: will be removed in a future release, see https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components) +Defines the maximum size a log file can grow to. Unit is megabytes. If the value is 0, the maximum file size is unlimited. (DEPRECATED: will be removed in a future release, see here.) @@ -765,49 +765,49 @@ csiMigrationRBD=true|false (ALPHA - default=false)
--log-json-info-buffer-size string     Default: '0' -[Experimental] In JSON format with split output streams, the info messages can be buffered for a while to increase performance. The default value of zero bytes disables buffering. The size can be specified as number of bytes (512), multiples of 1000 (1K), multiples of 1024 (2Ki), or powers of those (3M, 4G, 5Mi, 6Gi). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +[Experimental] In JSON format with split output streams, the info messages can be buffered for a while to increase performance. The default value of zero bytes disables buffering. The size can be specified as number of bytes (512), multiples of 1000 (1K), multiples of 1024 (2Ki), or powers of those (3M, 4G, 5Mi, 6Gi). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --log-json-split-stream -[Experimental] In JSON format, write error messages to stderr and info messages to stdout. The default is to write a single stream to stdout. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +[Experimental] In JSON format, write error messages to stderr and info messages to stdout. The default is to write a single stream to stdout. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --logging-format string     Default: text -Sets the log format. Permitted formats: text, json.
Non-default formats don't honor these flags: --add-dir-header, --alsologtostderr, --log-backtrace-at, --log-dir, --log-file, --log-file-max-size, --logtostderr, --skip_headers, --skip_log_headers, --stderrthreshold, --log-flush-frequency.
Non-default choices are currently alpha and subject to change without warning. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Sets the log format. Permitted formats: text, json.
Non-default formats don't honor these flags: --add-dir-header, --alsologtostderr, --log-backtrace-at, --log-dir, --log-file, --log-file-max-size, --logtostderr, --skip_headers, --skip_log_headers, --stderrthreshold, --log-flush-frequency.
Non-default choices are currently alpha and subject to change without warning. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --logtostderr     Default: true -log to standard error instead of files. (DEPRECATED: will be removed in a future release, see https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components) +log to standard error instead of files. (DEPRECATED: will be removed in a future release, see here.) --make-iptables-util-chains     Default: true -If true, kubelet will ensure iptables utility rules are present on host. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +If true, kubelet will ensure iptables utility rules are present on host. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --manifest-url string -URL for accessing additional Pod specifications to run (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +URL for accessing additional Pod specifications to run (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --manifest-url-header string -Comma-separated list of HTTP headers to use when accessing the URL provided to --manifest-url. Multiple headers with the same name will be added in the same order provided. This flag can be repeatedly invoked. For example: --manifest-url-header 'a:hello,b:again,c:world' --manifest-url-header 'b:beautiful' (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Comma-separated list of HTTP headers to use when accessing the URL provided to --manifest-url. Multiple headers with the same name will be added in the same order provided. This flag can be repeatedly invoked. For example: --manifest-url-header 'a:hello,b:again,c:world' --manifest-url-header 'b:beautiful' (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -821,14 +821,14 @@ csiMigrationRBD=true|false (ALPHA - default=false)
--max-open-files int     Default: 1000000 -Number of files that can be opened by Kubelet process. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Number of files that can be opened by Kubelet process. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --max-pods int32     Default: 110 -Number of Pods that can run on this Kubelet. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Number of Pods that can run on this Kubelet. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -849,7 +849,7 @@ csiMigrationRBD=true|false (ALPHA - default=false)
--memory-manager-policy string     Default: None -Memory Manager policy to use. Possible values: 'None', 'Static'. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Memory Manager policy to use. Possible values: 'None', 'Static'. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -863,7 +863,7 @@ csiMigrationRBD=true|false (ALPHA - default=false)
--minimum-image-ttl-duration duration     Default: 2m0s -Minimum age for an unused image before it is garbage collected. Examples: '300ms', '10s' or '2h45m'. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Minimum age for an unused image before it is garbage collected. Examples: '300ms', '10s' or '2h45m'. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -898,14 +898,14 @@ csiMigrationRBD=true|false (ALPHA - default=false)
--node-status-max-images int32     Default: 50 -The maximum number of images to report in node.status.images. If -1 is specified, no cap will be applied. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +The maximum number of images to report in node.status.images. If -1 is specified, no cap will be applied. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --node-status-update-frequency duration     Default: 10s -Specifies how often kubelet posts node status to master. Note: be cautious when changing the constant, it must work with nodeMonitorGracePeriod in Node controller. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Specifies how often kubelet posts node status to master. Note: be cautious when changing the constant, it must work with nodeMonitorGracePeriod in Node controller. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -919,21 +919,21 @@ csiMigrationRBD=true|false (ALPHA - default=false)
--one-output -If true, only write logs to their native severity level (vs also writing to each lower severity level). (DEPRECATED: will be removed in a future release, see https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components) +If true, only write logs to their native severity level (vs also writing to each lower severity level). (DEPRECATED: will be removed in a future release, see here.) --oom-score-adj int32     Default: -999 -The oom-score-adj value for kubelet process. Values must be within the range [-1000, 1000]. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +The oom-score-adj value for kubelet process. Values must be within the range [-1000, 1000]. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --pod-cidr string -The CIDR to use for pod IP addresses, only used in standalone mode. In cluster mode, this is obtained from the master. For IPv6, the maximum number of IP's allocated is 65536 (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +The CIDR to use for pod IP addresses, only used in standalone mode. In cluster mode, this is obtained from the master. For IPv6, the maximum number of IP's allocated is 65536 (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -947,56 +947,56 @@ csiMigrationRBD=true|false (ALPHA - default=false)
--pod-manifest-path string -Path to the directory containing static pod files to run, or the path to a single static pod file. Files starting with dots will be ignored. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Path to the directory containing static pod files to run, or the path to a single static pod file. Files starting with dots will be ignored. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --pod-max-pids int     Default: -1 -Set the maximum number of processes per pod. If -1, the kubelet defaults to the node allocatable PID capacity. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Set the maximum number of processes per pod. If -1, the kubelet defaults to the node allocatable PID capacity. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --pods-per-core int32 -Number of Pods per core that can run on this kubelet. The total number of pods on this kubelet cannot exceed --max-pods, so --max-pods will be used if this calculation results in a larger number of pods allowed on the kubelet. A value of 0 disables this limit. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Number of Pods per core that can run on this kubelet. The total number of pods on this kubelet cannot exceed --max-pods, so --max-pods will be used if this calculation results in a larger number of pods allowed on the kubelet. A value of 0 disables this limit. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --port int32     Default: 10250 -The port for the kubelet to serve on. (DEPRECATED: This parameter should be set via the config file specified by the kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +The port for the kubelet to serve on. (DEPRECATED: This parameter should be set via the config file specified by the kubelet's --config flag. See kubelet-config-file for more information.) --protect-kernel-defaults - Default kubelet behaviour for kernel tuning. If set, kubelet errors if any of kernel tunables is different than kubelet defaults. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) + Default kubelet behaviour for kernel tuning. If set, kubelet errors if any of kernel tunables is different than kubelet defaults. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --provider-id string -Unique identifier for identifying the node in a machine database, i.e cloud provider. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Unique identifier for identifying the node in a machine database, i.e cloud provider. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --qos-reserved mapStringString -<Warning: Alpha feature> A set of <resource name>=<percentage> (e.g. memory=50%) pairs that describe how pod resource requests are reserved at the QoS level. Currently only memory is supported. Requires the QOSReserved feature gate to be enabled. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +<Warning: Alpha feature> A set of <resource name>=<percentage> (e.g. memory=50%) pairs that describe how pod resource requests are reserved at the QoS level. Currently only memory is supported. Requires the QOSReserved feature gate to be enabled. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --read-only-port int32     Default: 10255 -The read-only port for the kubelet to serve on with no authentication/authorization (set to 0 to disable). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +The read-only port for the kubelet to serve on with no authentication/authorization (set to 0 to disable). (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -1010,7 +1010,7 @@ csiMigrationRBD=true|false (ALPHA - default=false)
--register-node     Default: true -Register the node with the API server. If --kubeconfig is not provided, this flag is irrelevant, as the Kubelet won't have an API server to register with. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Register the node with the API server. If --kubeconfig is not provided, this flag is irrelevant, as the Kubelet won't have an API server to register with. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -1024,42 +1024,42 @@ csiMigrationRBD=true|false (ALPHA - default=false)
--register-with-taints mapStringString -Register the node with the given list of taints (comma separated <key>=<value>:<effect>). No-op if --register-node is false. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Register the node with the given list of taints (comma separated <key>=<value>:<effect>). No-op if --register-node is false. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --registry-burst int32     Default: 10 -Maximum size of a bursty pulls, temporarily allows pulls to burst to this number, while still not exceeding --registry-qps. Only used if --registry-qps is greater than 0. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Maximum size of a bursty pulls, temporarily allows pulls to burst to this number, while still not exceeding --registry-qps. Only used if --registry-qps is greater than 0. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --registry-qps int32     Default: 5 -If > 0, limit registry pull QPS to this value. If 0, unlimited. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +If > 0, limit registry pull QPS to this value. If 0, unlimited. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --reserved-cpus string -A comma-separated list of CPUs or CPU ranges that are reserved for system and kubernetes usage. This specific list will supersede cpu counts in --system-reserved and --kube-reserved. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +A comma-separated list of CPUs or CPU ranges that are reserved for system and kubernetes usage. This specific list will supersede cpu counts in --system-reserved and --kube-reserved. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --reserved-memory string -A comma-separated list of memory reservations for NUMA nodes. (e.g. --reserved-memory 0:memory=1Gi,hugepages-1M=2Gi --reserved-memory 1:memory=2Gi). The total sum for each memory type should be equal to the sum of --kube-reserved, --system-reserved and --eviction-threshold. See https://kubernetes.io/docs/tasks/administer-cluster/memory-manager/#reserved-memory-flag for more details. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +A comma-separated list of memory reservations for NUMA nodes. (e.g. --reserved-memory 0:memory=1Gi,hugepages-1M=2Gi --reserved-memory 1:memory=2Gi). The total sum for each memory type should be equal to the sum of --kube-reserved, --system-reserved and --eviction-threshold. See here for more details. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --resolv-conf string     Default: /etc/resolv.conf -Resolver configuration file used as the basis for the container DNS resolution configuration. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Resolver configuration file used as the basis for the container DNS resolution configuration. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -1073,21 +1073,21 @@ csiMigrationRBD=true|false (ALPHA - default=false)
--rotate-certificates -<Warning: Beta feature> Auto rotate the kubelet client certificates by requesting new certificates from the kube-apiserver when the certificate expiration approaches. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +<Warning: Beta feature> Auto rotate the kubelet client certificates by requesting new certificates from the kube-apiserver when the certificate expiration approaches. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --rotate-server-certificates -Auto-request and rotate the kubelet serving certificates by requesting new certificates from the kube-apiserver when the certificate expiration approaches. Requires the RotateKubeletServerCertificate feature gate to be enabled, and approval of the submitted CertificateSigningRequest objects. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Auto-request and rotate the kubelet serving certificates by requesting new certificates from the kube-apiserver when the certificate expiration approaches. Requires the RotateKubeletServerCertificate feature gate to be enabled, and approval of the submitted CertificateSigningRequest objects. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --runonce -If true, exit after spawning pods from local manifests or remote urls. Exclusive with --enable-server (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +If true, exit after spawning pods from local manifests or remote urls. Exclusive with --enable-server (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -1101,7 +1101,7 @@ csiMigrationRBD=true|false (ALPHA - default=false)
--runtime-request-timeout duration     Default: 2m0s -Timeout of all runtime requests except long running request - pull, logs, exec and attach. When timeout exceeded, kubelet will cancel the request, throw out an error and retry later. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Timeout of all runtime requests except long running request - pull, logs, exec and attach. When timeout exceeded, kubelet will cancel the request, throw out an error and retry later. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -1115,70 +1115,70 @@ csiMigrationRBD=true|false (ALPHA - default=false)
--serialize-image-pulls     Default: true -Pull images one at a time. We recommend *not* changing the default value on nodes that run docker daemon with version < 1.9 or an aufs storage backend. Issue #10959 has more details. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Pull images one at a time. We recommend *not* changing the default value on nodes that run docker daemon with version < 1.9 or an aufs storage backend. Issue #10959 has more details. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --skip-headers -If true, avoid header prefixes in the log messages. (DEPRECATED: will be removed in a future release, see https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components) +If true, avoid header prefixes in the log messages. (DEPRECATED: will be removed in a future release, see here.) --skip-log-headers -If true, avoid headers when opening log files. (DEPRECATED: will be removed in a future release, see https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components) +If true, avoid headers when opening log files. (DEPRECATED: will be removed in a future release, see here.) --stderrthreshold int     Default: 2 -logs at or above this threshold go to stderr. (DEPRECATED: will be removed in a future release, see https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components) +logs at or above this threshold go to stderr. (DEPRECATED: will be removed in a future release, see here.) --streaming-connection-idle-timeout duration     Default: 4h0m0s -Maximum time a streaming connection can be idle before the connection is automatically closed. 0 indicates no timeout. Example: 5m. Note: All connections to the kubelet server have a maximum duration of 4 hours. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Maximum time a streaming connection can be idle before the connection is automatically closed. 0 indicates no timeout. Example: 5m. Note: All connections to the kubelet server have a maximum duration of 4 hours. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --sync-frequency duration     Default: 1m0s -Max period between synchronizing running containers and config. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Max period between synchronizing running containers and config. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --system-cgroups string -Optional absolute name of cgroups in which to place all non-kernel processes that are not already inside a cgroup under '/'. Empty for no container. Rolling back the flag requires a reboot. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Optional absolute name of cgroups in which to place all non-kernel processes that are not already inside a cgroup under '/'. Empty for no container. Rolling back the flag requires a reboot. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --system-reserved mapStringString     Default: <none> -A set of <resource name>=<resource quantity> (e.g. cpu=200m,memory=500Mi,ephemeral-storage=1Gi,pid='100') pairs that describe resources reserved for non-kubernetes components. Currently only cpu and memory are supported. See http://kubernetes.io/docs/user-guide/compute-resources for more detail. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +A set of <resource name>=<resource quantity> (e.g. cpu=200m,memory=500Mi,ephemeral-storage=1Gi,pid='100') pairs that describe resources reserved for non-kubernetes components. Currently only cpu and memory are supported. See here for more detail. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --system-reserved-cgroup string     Default: '' -Absolute name of the top level cgroup that is used to manage non-kubernetes components for which compute resources were reserved via --system-reserved flag. Ex. /system-reserved. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Absolute name of the top level cgroup that is used to manage non-kubernetes components for which compute resources were reserved via --system-reserved flag. Ex. /system-reserved. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --tls-cert-file string -File containing x509 Certificate used for serving HTTPS (with intermediate certs, if any, concatenated after server cert). If --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to the directory passed to --cert-dir. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +File containing x509 Certificate used for serving HTTPS (with intermediate certs, if any, concatenated after server cert). If --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to the directory passed to --cert-dir. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -1190,21 +1190,21 @@ Preferred values: TLS_AES_128_GCM_SHA256, TLS_AES_256_GCM_SHA384, TLS_CHACHA20_POLY1305_SHA256, TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305, TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_128_GCM_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_RSA_WITH_AES_256_GCM_SHA384
Insecure values: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_RC4_128_SHA. -(DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +(DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --tls-min-version string -Minimum TLS version supported. Possible values: VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Minimum TLS version supported. Possible values: VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --tls-private-key-file string -File containing x509 private key matching --tls-cert-file. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +File containing x509 private key matching --tls-cert-file. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -1212,14 +1212,14 @@ TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_E --topology-manager-policy string     Default: 'none' -Topology Manager policy to use. Possible values: 'none', 'best-effort', 'restricted', 'single-numa-node'. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Topology Manager policy to use. Possible values: 'none', 'best-effort', 'restricted', 'single-numa-node'. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --topology-manager-scope string     Default: container -Scope to which topology hints applied. Topology Manager collects hints from Hint Providers and applies them to defined scope to ensure the pod admission. Possible values: 'container', 'pod'. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Scope to which topology hints applied. Topology Manager collects hints from Hint Providers and applies them to defined scope to ensure the pod admission. Possible values: 'container', 'pod'. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) @@ -1247,14 +1247,14 @@ TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_E --volume-plugin-dir string     Default: /usr/libexec/kubernetes/kubelet-plugins/volume/exec/ -The full path of the directory in which to search for additional third party volume plugins. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +The full path of the directory in which to search for additional third party volume plugins. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) --volume-stats-agg-period duration     Default: 1m0s -Specifies interval for kubelet to calculate and cache the volume disk usage for all pods and volumes. To disable volume calculations, set to 0. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See https://kubernetes.io/docs/tasks/administer-cluster/kubelet-config-file/ for more information.) +Specifies interval for kubelet to calculate and cache the volume disk usage for all pods and volumes. To disable volume calculations, set to 0. (DEPRECATED: This parameter should be set via the config file specified by the Kubelet's --config flag. See kubelet-config-file for more information.) diff --git a/content/en/docs/reference/config-api/apiserver-eventratelimit.v1alpha1.md b/content/en/docs/reference/config-api/apiserver-eventratelimit.v1alpha1.md new file mode 100644 index 0000000000..32b6aeb191 --- /dev/null +++ b/content/en/docs/reference/config-api/apiserver-eventratelimit.v1alpha1.md @@ -0,0 +1,121 @@ +--- +title: Event Rate Limit Configuration (v1alpha1) +content_type: tool-reference +package: evenratelimit.admission.k8s.io/v1alpha1 +auto_generated: true +--- + + +## Resource Types + + +- [Configuration](#evenratelimit-admission-k8s-io-v1alpha1-Configuration) + + + +## `Configuration` {#evenratelimit-admission-k8s-io-v1alpha1-Configuration} + + + +

Configuration provides configuration for the EventRateLimit admission +controller.

+ + + + + + + + + + + + + + +
FieldDescription
apiVersion
string		evenratelimit.admission.k8s.io/v1alpha1
kind
string		Configuration
limits [Required]
+[]Limit +		 +

limits are the limits to place on event queries received. +Limits can be placed on events received server-wide, per namespace, +per user, and per source+object. +At least one limit is required.

+
+ +## `Limit` {#evenratelimit-admission-k8s-io-v1alpha1-Limit} + + +**Appears in:** + +- [Configuration](#evenratelimit-admission-k8s-io-v1alpha1-Configuration) + + +

Limit is the configuration for a particular limit type

+ + + + + + + + + + + + + + + + + + + + +
FieldDescription
type [Required]
+LimitType +		 +

type is the type of limit to which this configuration applies

+
qps [Required]
+int32 +		 +

qps is the number of event queries per second that are allowed for this +type of limit. The qps and burst fields are used together to determine if +a particular event query is accepted. The qps determines how many queries +are accepted once the burst amount of queries has been exhausted.

+
burst [Required]
+int32 +		 +

burst is the burst number of event queries that are allowed for this type +of limit. The qps and burst fields are used together to determine if a +particular event query is accepted. The burst determines the maximum size +of the allowance granted for a particular bucket. For example, if the burst +is 10 and the qps is 3, then the admission control will accept 10 queries +before blocking any queries. Every second, 3 more queries will be allowed. +If some of that allowance is not used, then it will roll over to the next +second, until the maximum allowance of 10 is reached.

+
cacheSize
+int32 +		 +

cacheSize is the size of the LRU cache for this type of limit. If a bucket +is evicted from the cache, then the allowance for that bucket is reset. If +more queries are later received for an evicted bucket, then that bucket +will re-enter the cache with a clean slate, giving that bucket a full +allowance of burst queries.

+

The default cache size is 4096.

+

If limitType is 'server', then cacheSize is ignored.

+
+ +## `LimitType` {#evenratelimit-admission-k8s-io-v1alpha1-LimitType} + +(Alias of `string`) + +**Appears in:** + +- [Limit](#evenratelimit-admission-k8s-io-v1alpha1-Limit) + + +

LimitType is the type of the limit (e.g., per-namespace)

+ + + + diff --git a/content/en/docs/reference/config-api/imagepolicy.v1alpha1.md b/content/en/docs/reference/config-api/imagepolicy.v1alpha1.md new file mode 100644 index 0000000000..f420623559 --- /dev/null +++ b/content/en/docs/reference/config-api/imagepolicy.v1alpha1.md @@ -0,0 +1,168 @@ +--- +title: Image Policy API (v1alpha1) +content_type: tool-reference +package: imagepolicy.k8s.io/v1alpha1 +auto_generated: true +--- + + +## Resource Types + + +- [ImageReview](#imagepolicy-k8s-io-v1alpha1-ImageReview) + + + +## `ImageReview` {#imagepolicy-k8s-io-v1alpha1-ImageReview} + + + +

ImageReview checks if the set of images in a pod are allowed.

+ + + + + + + + + + + + + + + + + + + + +
FieldDescription
apiVersion
string		imagepolicy.k8s.io/v1alpha1
kind
string		ImageReview
metadata
+meta/v1.ObjectMeta +		 +

Standard object's metadata. +More info: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

+Refer to the Kubernetes API documentation for the fields of the metadata field.
spec [Required]
+ImageReviewSpec +		 +

Spec holds information about the pod being evaluated

+
status
+ImageReviewStatus +		 +

Status is filled in by the backend and indicates whether the pod should be allowed.

+
+ +## `ImageReviewContainerSpec` {#imagepolicy-k8s-io-v1alpha1-ImageReviewContainerSpec} + + +**Appears in:** + +- [ImageReviewSpec](#imagepolicy-k8s-io-v1alpha1-ImageReviewSpec) + + +

ImageReviewContainerSpec is a description of a container within the pod creation request.

+ + + + + + + + + + + +
FieldDescription
image
+string +		 +

This can be in the form image:tag or image@SHA:012345679abcdef.

+
+ +## `ImageReviewSpec` {#imagepolicy-k8s-io-v1alpha1-ImageReviewSpec} + + +**Appears in:** + +- [ImageReview](#imagepolicy-k8s-io-v1alpha1-ImageReview) + + +

ImageReviewSpec is a description of the pod creation request.

+ + + + + + + + + + + + + + + + + +
FieldDescription
containers
+[]ImageReviewContainerSpec +		 +

Containers is a list of a subset of the information in each container of the Pod being created.

+
annotations
+map[string]string +		 +

Annotations is a list of key-value pairs extracted from the Pod's annotations. +It only includes keys which match the pattern *.image-policy.k8s.io/*. +It is up to each webhook backend to determine how to interpret these annotations, if at all.

+
namespace
+string +		 +

Namespace is the namespace the pod is being created in.

+
+ +## `ImageReviewStatus` {#imagepolicy-k8s-io-v1alpha1-ImageReviewStatus} + + +**Appears in:** + +- [ImageReview](#imagepolicy-k8s-io-v1alpha1-ImageReview) + + +

ImageReviewStatus is the result of the review for the pod creation request.

+ + + + + + + + + + + + + + + + + +
FieldDescription
allowed [Required]
+bool +		 +

Allowed indicates that all images were allowed to be run.

+
reason
+string +		 +

Reason should be empty unless Allowed is false in which case it +may contain a short description of what is wrong. Kubernetes +may truncate excessively long errors when displaying to the user.

+
auditAnnotations
+map[string]string +		 +

AuditAnnotations will be added to the attributes object of the +admission controller request using 'AddAnnotation'. The keys should +be prefix-less (i.e., the admission controller will add an +appropriate prefix).

+
+ \ No newline at end of file diff --git a/content/en/docs/reference/config-api/kubeadm-config.v1beta2.md b/content/en/docs/reference/config-api/kubeadm-config.v1beta2.md index 5d75df5b53..377ac021b6 100644 --- a/content/en/docs/reference/config-api/kubeadm-config.v1beta2.md +++ b/content/en/docs/reference/config-api/kubeadm-config.v1beta2.md @@ -143,7 +143,7 @@ configuration types to be used during a kubeadm init run.

criSocket: "/var/run/dockershim.sock" taints: - key: "kubeadmNode" - value: "master" + value: "someValue" effect: "NoSchedule" kubeletExtraArgs: v: 4 @@ -876,7 +876,9 @@ cluster information.

tlsBootstrapToken is a token used for TLS bootstrapping. -If bootstrapToken is set, this field is defaulted to .bootstrapToken.token, but can be overridden. If file is set, this field must be set in case the KubeConfigFile does not +If bootstrapToken is set, this field is defaulted to .bootstrapToken.token, +but can be overridden. +If file is set, this field must be set in case the KubeConfigFile does not contain any other authentication information.

@@ -1267,7 +1269,7 @@ Defaults to the hostname of the node if not provided.

string -

criSocket is used to retrieve container runtime information. This information will +

criSocket is used to retrieve container runtime information. This information will be annotated to the Node API object, for later re-use.

@@ -1276,9 +1278,9 @@ be annotated to the Node API object, for later re-use.

taints specifies the taints the Node API object should be registered with. -If this field is unset, i.e. nil, in the kubeadm init process it will be defaulted to -'node-role.kubernetes.io/master=""'. If you don't want to taint your control-plane node, -set this field to an empty list, i.e. taints: [] in the YAML file. This field is +If this field is unset, i.e. nil, in the kubeadm init process it will be defaulted with +a control-plane taint for control-plane nodes. If you don't want to taint your control-plane +node, set this field to an empty list, i.e. taints: [], in the YAML file. This field is solely used for Node registration.

diff --git a/content/en/docs/reference/config-api/kubeadm-config.v1beta3.md b/content/en/docs/reference/config-api/kubeadm-config.v1beta3.md index ca7ef7c287..75fc7c1ecf 100644 --- a/content/en/docs/reference/config-api/kubeadm-config.v1beta3.md +++ b/content/en/docs/reference/config-api/kubeadm-config.v1beta3.md @@ -152,7 +152,7 @@ configuration types to be used during a kubeadm init run.

 criSocket: "/var/run/dockershim.sock" taints: - key: "kubeadmNode" - value: "master" + value: "someValue" effect: "NoSchedule" kubeletExtraArgs: v: 4 @@ -1160,9 +1160,9 @@ This information will be annotated to the Node API object, for later re-use

tains specifies the taints the Node API object should be registered with. -If this field is unset, i.e. nil, in the kubeadm init process it will be defaulted to -taints: ["node-role.kubernetes.io/master:""]. -If you don't want to taint your control-plane node, set this field to an empty slice, +If this field is unset, i.e. nil, in the kubeadm init process it will be defaulted +with a control-plane taint for control-plane nodes. +If you don't want to taint your control-plane node, set this field to an empty list, i.e. taints: [] in the YAML file. This field is solely used for Node registration.

diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md index e1711ea542..3412175285 100644 --- a/content/en/docs/reference/kubectl/cheatsheet.md +++ b/content/en/docs/reference/kubectl/cheatsheet.md @@ -280,7 +280,7 @@ kubectl patch deployment valid-deployment --type json -p='[{"op": "remove", " # Add a new element to a positional array kubectl patch sa default --type='json' -p='[{"op": "add", "path": "/secrets/1", "value": {"name": "whatever" } }]' -# Update a deployment's replicas count by patching it's scale subresource +# Update a deployment's replica count by patching its scale subresource kubectl patch deployment nginx-deployment --subresource='scale' --type='merge' -p '{"spec":{"replicas":2}}' ``` diff --git a/content/en/docs/reference/labels-annotations-taints/_index.md b/content/en/docs/reference/labels-annotations-taints/_index.md index e68cb668d3..6622c63941 100644 --- a/content/en/docs/reference/labels-annotations-taints/_index.md +++ b/content/en/docs/reference/labels-annotations-taints/_index.md @@ -334,6 +334,24 @@ Used on: Service Kubernetes uses this label to differentiate multiple Services. Used currently for `ELB`(Elastic Load Balancer) only. +### kubernetes.io/service-account.name + +Example: `kubernetes.io/service-account.name: "sa-name"` + +Used on: Secret + +This annotation records the {{< glossary_tooltip term_id="name" text="name">}} of the +ServiceAccount that the token (stored in the Secret of type `kubernetes.io/service-account-token`) represents. + +### kubernetes.io/service-account.uid + +Example: `kubernetes.io/service-account.uid: da68f9c6-9d26-11e7-b84e-002dc52800da` + +Used on: Secret + +This annotation records the {{< glossary_tooltip term_id="uid" text="unique ID" >}} of the +ServiceAccount that the token (stored in the Secret of type `kubernetes.io/service-account-token`) represents. + ### endpointslice.kubernetes.io/managed-by {#endpointslicekubernetesiomanaged-by} Example: `endpointslice.kubernetes.io/managed-by="controller"` diff --git a/content/en/docs/reference/using-api/deprecation-guide.md b/content/en/docs/reference/using-api/deprecation-guide.md index b72b60fb5a..d448344504 100644 --- a/content/en/docs/reference/using-api/deprecation-guide.md +++ b/content/en/docs/reference/using-api/deprecation-guide.md @@ -110,8 +110,10 @@ The **policy/v1beta1** API version of PodDisruptionBudget will no longer be serv PodSecurityPolicy in the **policy/v1beta1** API version will no longer be served in v1.25, and the PodSecurityPolicy admission controller will be removed. -PodSecurityPolicy replacements are still under discussion, but current use can be migrated to -[3rd-party admission webhooks](/docs/reference/access-authn-authz/extensible-admission-controllers/) now. +Migrate to [Pod Security Admission](/docs/concepts/security/pod-security-admission/) +or a [3rd party admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/). +For a migration guide, see [Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller](/docs/tasks/configure-pod-container/migrate-from-psp/). +For more information on the deprecation, see [PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/). #### RuntimeClass {#runtimeclass-v125} diff --git a/content/en/docs/reference/using-api/server-side-apply.md b/content/en/docs/reference/using-api/server-side-apply.md index 6b932278dc..e9f951a76a 100644 --- a/content/en/docs/reference/using-api/server-side-apply.md +++ b/content/en/docs/reference/using-api/server-side-apply.md @@ -125,7 +125,8 @@ this occurs, the applier has 3 options to resolve the conflicts: * **Overwrite value, become sole manager:** If overwriting the value was intentional (or if the applier is an automated process like a controller) the - applier should set the `force` query parameter to true and make the request + applier should set the `force` query parameter to true (in kubectl, it can be done by + using the `--force-conflicts` flag with the apply command) and make the request again. This forces the operation to succeed, changes the value of the field, and removes the field from all other managers' entries in managedFields. diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md index 6f9b174631..e373de5dbf 100644 --- a/content/en/docs/setup/production-environment/container-runtimes.md +++ b/content/en/docs/setup/production-environment/container-runtimes.md @@ -167,15 +167,12 @@ using the (deprecated) v1alpha2 API instead. {{% thirdparty-content %}} - ### containerd This section outlines the necessary steps to use containerd as CRI runtime. Use the following commands to install Containerd on your system: - - Follow the instructions for [getting started with containerd](https://github.com/containerd/containerd/blob/main/docs/getting-started.md). Return to this step once you've created a valid configuration file, `config.toml`. {{< tabs name="Finding your config.toml file" >}} @@ -200,6 +197,14 @@ To use the `systemd` cgroup driver in `/etc/containerd/config.toml` with `runc`, [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] SystemdCgroup = true ``` +{{< note >}} +If you installed containerd from a package (for example, RPM or `.deb`), you may find +that the CRI integration plugin is disabled by default. + +You need CRI support enabled to use containerd with Kubernetes. Make sure that `cri` +is not included in the`disabled_plugins` list within `/etc/containerd/config.toml`; +if you made changes to that file, also restart `containerd`. +{{< /note >}} If you apply this change, make sure to restart containerd: @@ -208,7 +213,7 @@ sudo systemctl restart containerd ``` When using kubeadm, manually configure the -[cgroup driver for kubelet](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/#configure-cgroup-driver-used-by-kubelet-on-control-plane-node). +[cgroup driver for kubelet](/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver/#configuring-the-kubelet-cgroup-driver). ### CRI-O diff --git a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md b/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md deleted file mode 100644 index 687d544c91..0000000000 --- a/content/en/docs/setup/production-environment/windows/intro-windows-in-kubernetes.md +++ /dev/null @@ -1,917 +0,0 @@ ---- -reviewers: -- jayunit100 -- jsturtevant -- marosset -- perithompson -title: Windows containers in Kubernetes -content_type: concept -weight: 65 ---- - - - -Windows applications constitute a large portion of the services and applications that -run in many organizations. [Windows containers](https://aka.ms/windowscontainers) -provide a way to encapsulate processes and package dependencies, making it easier -to use DevOps practices and follow cloud native patterns for Windows applications. - -Organizations with investments in Windows-based applications and Linux-based -applications don't have to look for separate orchestrators to manage their workloads, -leading to increased operational efficiencies across their deployments, regardless -of operating system. - - - -## Windows nodes in Kubernetes - -To enable the orchestration of Windows containers in Kubernetes, include Windows nodes -in your existing Linux cluster. Scheduling Windows containers in -{{< glossary_tooltip text="Pods" term_id="pod" >}} on Kubernetes is similar to -scheduling Linux-based containers. - -In order to run Windows containers, your Kubernetes cluster must include -multiple operating systems. -While you can only run the {{< glossary_tooltip text="control plane" term_id="control-plane" >}} on Linux, you can deploy worker nodes running either Windows or Linux depending on your workload needs. - -Windows {{< glossary_tooltip text="nodes" term_id="node" >}} are -[supported](#windows-os-version-support) provided that the operating system is -Windows Server 2019. - -This document uses the term *Windows containers* to mean Windows containers with -process isolation. Kubernetes does not support running Windows containers with -[Hyper-V isolation](https://docs.microsoft.com/en-us/virtualization/windowscontainers/manage-containers/hyperv-container). - -## Compatibility and limitations {#limitations} - -Some node features are only available if you use a specific -[container runtime](#container-runtime); others are not available on Windows nodes, -including: - -* HugePages: not supported for Windows containers -* Privileged containers: not supported for Windows containers -* TerminationGracePeriod: requires containerD - -Not all features of shared namespaces are supported. See [API compatibility](#api) -for more details. - -See [Windows OS version compatibility](#windows-os-version-support) for details on -the Windows versions that Kubernetes is tested against. - -From an API and kubectl perspective, Windows containers behave in much the same -way as Linux-based containers. However, there are some notable differences in key -functionality which are outlined in this section. - -### Comparison with Linux {#compatibility-linux-similarities} - -Key Kubernetes elements work the same way in Windows as they do in Linux. This -section refers to several key workload enablers and how they map to Windows. - -* [Pods](/docs/concepts/workloads/pods/) - - A Pod is the basic building block of Kubernetes–the smallest and simplest unit in - the Kubernetes object model that you create or deploy. You may not deploy Windows and - Linux containers in the same Pod. All containers in a Pod are scheduled onto a single - Node where each Node represents a specific platform and architecture. The following - Pod capabilities, properties and events are supported with Windows containers: - - * Single or multiple containers per Pod with process isolation and volume sharing - * Pod `status` fields - * Readiness and Liveness probes - * postStart & preStop container lifecycle events - * ConfigMap, Secrets: as environment variables or volumes - * `emptyDir` volumes - * Named pipe host mounts - * Resource limits - * OS field: - - The `.spec.os.name` field should be set to `windows` to indicate that the current Pod uses Windows containers. - The `IdentifyPodOS` feature gate needs to be enabled for this field to be recognized and used by control plane - components and kubelet. - - {{< note >}} - Starting from 1.24, the `IdentifyPodOS` feature gate is in Beta stage and defaults to be enabled. - {{< /note >}} - - If the `IdentifyPodOS` feature gate is enabled and you set the `.spec.os.name` field to `windows`, - you must not set the following fields in the `.spec` of that Pod: - - * `spec.hostPID` - * `spec.hostIPC` - * `spec.securityContext.seLinuxOptions` - * `spec.securityContext.seccompProfile` - * `spec.securityContext.fsGroup` - * `spec.securityContext.fsGroupChangePolicy` - * `spec.securityContext.sysctls` - * `spec.shareProcessNamespace` - * `spec.securityContext.runAsUser` - * `spec.securityContext.runAsGroup` - * `spec.securityContext.supplementalGroups` - * `spec.containers[*].securityContext.seLinuxOptions` - * `spec.containers[*].securityContext.seccompProfile` - * `spec.containers[*].securityContext.capabilities` - * `spec.containers[*].securityContext.readOnlyRootFilesystem` - * `spec.containers[*].securityContext.privileged` - * `spec.containers[*].securityContext.allowPrivilegeEscalation` - * `spec.containers[*].securityContext.procMount` - * `spec.containers[*].securityContext.runAsUser` - * `spec.containers[*].securityContext.runAsGroup` - - In the above list, wildcards (`*`) indicate all elements in a list. - For example, `spec.containers[*].securityContext` refers to the SecurityContext object - for all containers. If any of these fields is specified, the Pod will - not be admited by the API server. - -* [Workload resources](/docs/concepts/workloads/controllers/) including: - * ReplicaSet - * Deployments - * StatefulSets - * DaemonSet - * Job - * CronJob - * ReplicationController -* {{< glossary_tooltip text="Services" term_id="service" >}} - See [Load balancing and Services](#load-balancing-and-services) for more details. - -Pods, workload resources, and Services are critical elements to managing Windows -workloads on Kubernetes. However, on their own they are not enough to enable -the proper lifecycle management of Windows workloads in a dynamic cloud native -environment. Kubernetes also supports: - -* `kubectl exec` -* Pod and container metrics -* {{< glossary_tooltip text="Horizontal pod autoscaling" term_id="horizontal-pod-autoscaler" >}} -* {{< glossary_tooltip text="Resource quotas" term_id="resource-quota" >}} -* Scheduler preemption - - -### Networking on Windows nodes {#compatibility-networking} - -Networking for Windows containers is exposed through -[CNI plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/). -Windows containers function similarly to virtual machines in regards to -networking. Each container has a virtual network adapter (vNIC) which is connected -to a Hyper-V virtual switch (vSwitch). The Host Networking Service (HNS) and the -Host Compute Service (HCS) work together to create containers and attach container -vNICs to networks. HCS is responsible for the management of containers whereas HNS -is responsible for the management of networking resources such as: - -* Virtual networks (including creation of vSwitches) -* Endpoints / vNICs -* Namespaces -* Policies including packet encapsulations, load-balancing rules, ACLs, and NAT rules. - -#### Container networking {#networking} - -The Windows HNS and vSwitch implement namespacing and can -create virtual NICs as needed for a pod or container. However, many configurations such -as DNS, routes, and metrics are stored in the Windows registry database rather than as -files inside `/etc`, which is how Linux stores those configurations. The Windows registry for the container -is separate from that of the host, so concepts like mapping `/etc/resolv.conf` from -the host into a container don't have the same effect they would on Linux. These must -be configured using Windows APIs run in the context of that container. Therefore -CNI implementations need to call the HNS instead of relying on file mappings to pass -network details into the pod or container. - -The following networking functionality is _not_ supported on Windows nodes: - -* Host networking mode -* Local NodePort access from the node itself (works for other nodes or external clients) -* More than 64 backend pods (or unique destination addresses) for a single Service -* IPv6 communication between Windows pods connected to overlay networks -* Local Traffic Policy in non-DSR mode -* Outbound communication using the ICMP protocol via the `win-overlay`, `win-bridge`, or using the Azure-CNI plugin.\ - Specifically, the Windows data plane ([VFP](https://www.microsoft.com/en-us/research/project/azure-virtual-filtering-platform/)) doesn't support ICMP packet transpositions, and this means: - * ICMP packets directed to destinations within the same network (such as pod to pod communication via ping) work as expected and without any limitations; - * TCP/UDP packets work as expected and without any limitations; - * ICMP packets directed to pass through a remote network (e.g. pod to external internet communication via ping) cannot be transposed and thus will not be routed back to their source; - * Since TCP/UDP packets can still be transposed, you can substitute `ping ` with `curl ` to get some debugging insight into connectivity with the outside world. - -Overlay networking support in kube-proxy is a beta feature. In addition, it requires -[KB4482887](https://support.microsoft.com/en-us/help/4482887/windows-10-update-kb4482887) -to be installed on Windows Server 2019. - -#### Network modes - -Windows supports five different networking drivers/modes: L2bridge, L2tunnel, -Overlay (beta), Transparent, and NAT. In a heterogeneous cluster with Windows and Linux -worker nodes, you need to select a networking solution that is compatible on both -Windows and Linux. The following out-of-tree plugins are supported on Windows, -with recommendations on when to use each CNI: - -| Network Driver | Description | Container Packet Modifications | Network Plugins | Network Plugin Characteristics | -| -------------- | ----------- | ------------------------------ | --------------- | ------------------------------ | -| L2bridge | Containers are attached to an external vSwitch. Containers are attached to the underlay network, although the physical network doesn't need to learn the container MACs because they are rewritten on ingress/egress. | MAC is rewritten to host MAC, IP may be rewritten to host IP using HNS OutboundNAT policy. | [win-bridge](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-bridge), [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md), Flannel host-gateway uses win-bridge | win-bridge uses L2bridge network mode, connects containers to the underlay of hosts, offering best performance. Requires user-defined routes (UDR) for inter-node connectivity. | -| L2Tunnel | This is a special case of l2bridge, but only used on Azure. All packets are sent to the virtualization host where SDN policy is applied. | MAC rewritten, IP visible on the underlay network | [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) | Azure-CNI allows integration of containers with Azure vNET, and allows them to leverage the set of capabilities that [Azure Virtual Network provides](https://azure.microsoft.com/en-us/services/virtual-network/). For example, securely connect to Azure services or use Azure NSGs. See [azure-cni for some examples](https://docs.microsoft.com/en-us/azure/aks/concepts-network#azure-cni-advanced-networking) | -| Overlay (Overlay networking for Windows in Kubernetes is in *alpha* stage) | Containers are given a vNIC connected to an external vSwitch. Each overlay network gets its own IP subnet, defined by a custom IP prefix.The overlay network driver uses VXLAN encapsulation. | Encapsulated with an outer header. | [win-overlay](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-overlay), Flannel VXLAN (uses win-overlay) | win-overlay should be used when virtual container networks are desired to be isolated from underlay of hosts (e.g. for security reasons). Allows for IPs to be re-used for different overlay networks (which have different VNID tags) if you are restricted on IPs in your datacenter. This option requires [KB4489899](https://support.microsoft.com/help/4489899) on Windows Server 2019. | -| Transparent (special use case for [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)) | Requires an external vSwitch. Containers are attached to an external vSwitch which enables intra-pod communication via logical networks (logical switches and routers). | Packet is encapsulated either via [GENEVE](https://datatracker.ietf.org/doc/draft-gross-geneve/) or [STT](https://datatracker.ietf.org/doc/draft-davie-stt/) tunneling to reach pods which are not on the same host.
Packets are forwarded or dropped via the tunnel metadata information supplied by the ovn network controller.
NAT is done for north-south communication. | [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) | [Deploy via ansible](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib). Distributed ACLs can be applied via Kubernetes policies. IPAM support. Load-balancing can be achieved without kube-proxy. NATing is done without using iptables/netsh. | -| NAT (*not used in Kubernetes*) | Containers are given a vNIC connected to an internal vSwitch. DNS/DHCP is provided using an internal component called [WinNAT](https://techcommunity.microsoft.com/t5/virtualization/windows-nat-winnat-capabilities-and-limitations/ba-p/382303) | MAC and IP is rewritten to host MAC/IP. | [nat](https://github.com/Microsoft/windows-container-networking/tree/master/plugins/nat) | Included here for completeness | - -As outlined above, the [Flannel](https://github.com/coreos/flannel) -CNI [meta plugin](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel) -is also [supported](https://github.com/containernetworking/plugins/tree/master/plugins/meta/flannel#windows-support-experimental) on Windows via the -[VXLAN network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) (**alpha support** ; delegates to win-overlay) -and [host-gateway network backend](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw) (stable support; delegates to win-bridge). - -This plugin supports delegating to one of the reference CNI plugins (win-overlay, -win-bridge), to work in conjunction with Flannel daemon on Windows (Flanneld) for -automatic node subnet lease assignment and HNS network creation. This plugin reads -in its own configuration file (cni.conf), and aggregates it with the environment -variables from the FlannelD generated subnet.env file. It then delegates to one of -the reference CNI plugins for network plumbing, and sends the correct configuration -containing the node-assigned subnet to the IPAM plugin (for example: `host-local`). - -For Node, Pod, and Service objects, the following network flows are supported for -TCP/UDP traffic: - -* Pod → Pod (IP) -* Pod → Pod (Name) -* Pod → Service (Cluster IP) -* Pod → Service (PQDN, but only if there are no ".") -* Pod → Service (FQDN) -* Pod → external (IP) -* Pod → external (DNS) -* Node → Pod -* Pod → Node - -#### CNI plugin limitations - -* Windows reference network plugins win-bridge and win-overlay do not implement - [CNI spec](https://github.com/containernetworking/cni/blob/master/SPEC.md) v0.4.0, - due to a missing `CHECK` implementation. -* The Flannel VXLAN CNI plugin has the following limitations on Windows: - -1. Node-pod connectivity isn't possible by design. It's only possible for local pods with Flannel v0.12.0 (or higher). -2. Flannel is restricted to using VNI 4096 and UDP port 4789. See the official - [Flannel VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) - backend docs for more details on these parameters. - -#### IP address management (IPAM) {#ipam} - -The following IPAM options are supported on Windows: - -* [host-local](https://github.com/containernetworking/plugins/tree/master/plugins/ipam/host-local) -* HNS IPAM (Inbox platform IPAM, this is a fallback when no IPAM is set) -* [azure-vnet-ipam](https://github.com/Azure/azure-container-networking/blob/master/docs/ipam.md) (for azure-cni only) - -#### Load balancing and Services - -A Kubernetes {{< glossary_tooltip text="Service" term_id="service" >}} is an abstraction -that defines a logical set of Pods and a means to access them over a network. -In a cluster that includes Windows nodes, you can use the following types of Service: - - * `NodePort` - * `ClusterIP` - * `LoadBalancer` - * `ExternalName` - -{{< warning >}} -There are known issue with NodePort services on overlay networking, if the target destination node is running Windows Server 2022. -To avoid the issue entirely, you can configure the service with `externalTrafficPolicy: Local`. - -There are known issues with pod to pod connectivity on l2bridge network on Windows Server 2022 with KB5005619 or higher installed. -To workaround the issue and restore pod-pod connectivity, you can disable the WinDSR feature in kube-proxy. - -These issues require OS fixes. -Please follow https://github.com/microsoft/Windows-Containers/issues/204 for updates. -{{< /warning >}} - -Windows container networking differs in some important ways from Linux networking. -The [Microsoft documentation for Windows Container Networking](https://docs.microsoft.com/en-us/virtualization/windowscontainers/container-networking/architecture) provides -additional details and background. - -On Windows, you can use the following settings to configure Services and load -balancing behavior: - -{{< table caption="Windows Service Settings" >}} -| Feature | Description | Supported Kubernetes version | Supported Windows OS build | How to enable | -| ------- | ----------- | ----------------------------- | -------------------------- | ------------- | -| Session affinity | Ensures that connections from a particular client are passed to the same Pod each time. | v1.20+ | [Windows Server vNext Insider Preview Build 19551](https://blogs.windows.com/windowsexperience/2020/01/28/announcing-windows-server-vnext-insider-preview-build-19551/) (or higher) | Set `service.spec.sessionAffinity` to "ClientIP" | -| Direct Server Return (DSR) | Load balancing mode where the IP address fixups and the LBNAT occurs at the container vSwitch port directly; service traffic arrives with the source IP set as the originating pod IP. | v1.20+ | Windows Server 2019 | Set the following flags in kube-proxy: `--feature-gates="WinDSR=true" --enable-dsr=true` | -| Preserve-Destination | Skips DNAT of service traffic, thereby preserving the virtual IP of the target service in packets reaching the backend Pod. Also disables node-node forwarding. | v1.20+ | Windows Server, version 1903 (or higher) | Set `"preserve-destination": "true"` in service annotations and enable DSR in kube-proxy. | -| IPv4/IPv6 dual-stack networking | Native IPv4-to-IPv4 in parallel with IPv6-to-IPv6 communications to, from, and within a cluster | v1.19+ | Windows Server, version 2019 | See [IPv4/IPv6 dual-stack](#ipv4ipv6-dual-stack) | -| Client IP preservation | Ensures that source IP of incoming ingress traffic gets preserved. Also disables node-node forwarding. | v1.20+ | Windows Server, version 2019 | Set `service.spec.externalTrafficPolicy` to "Local" and enable DSR in kube-proxy | -{{< /table >}} - -##### Session affinity - -Setting the maximum session sticky time for Windows services using -`service.spec.sessionAffinityConfig.clientIP.timeoutSeconds` is not supported. - -#### DNS {#dns-limitations} - -* ClusterFirstWithHostNet is not supported for DNS. Windows treats all names with a - `.` as a FQDN and skips FQDN resolution -* On Linux, you have a DNS suffix list, which is used when trying to resolve PQDNs. On - Windows, you can only have 1 DNS suffix, which is the DNS suffix associated with that - pod's namespace (mydns.svc.cluster.local for example). Windows can resolve FQDNs - and services or names resolvable with just that suffix. For example, a pod spawned - in the default namespace, will have the DNS suffix **default.svc.cluster.local**. - Inside a Windows pod, you can resolve both **kubernetes.default.svc.cluster.local** - and **kubernetes**, but not the in-betweens, like **kubernetes.default** or - **kubernetes.default.svc**. -* On Windows, there are multiple DNS resolvers that can be used. As these come with - slightly different behaviors, using the `Resolve-DNSName` utility for name query - resolutions is recommended. - -#### IPv6 networking - -Kubernetes on Windows does not support single-stack "IPv6-only" networking. However, -dual-stack IPv4/IPv6 networking for pods and nodes with single-family services -is supported. - -You can use IPv4/IPv6 dual-stack networking with `l2bridge` networks. See [configure IPv4/IPv6 dual stack](/docs/concepts/services-networking/dual-stack#configure-ipv4-ipv6-dual-stack) for more details. - -{{< note >}} -Overlay (VXLAN) networks on Windows do not support dual-stack networking. -{{< /note >}} - -### Persistent storage {#compatibility-storage} - -Windows has a layered filesystem driver to mount container layers and create a copy -filesystem based on NTFS. All file paths in the container are resolved only within -the context of that container. - -* With Docker, volume mounts can only target a directory in the container, and not - an individual file. This limitation does not exist with CRI-containerD runtime. -* Volume mounts cannot project files or directories back to the host filesystem. -* Read-only filesystems are not supported because write access is always required - for the Windows registry and SAM database. However, read-only volumes are supported. -* Volume user-masks and permissions are not available. Because the SAM is not shared - between the host & container, there's no mapping between them. All permissions are - resolved within the context of the container. - -As a result, the following storage functionality is not supported on Windows nodes: - -* Volume subpath mounts: only the entire volume can be mounted in a Windows container -* Subpath volume mounting for Secrets -* Host mount projection -* Read-only root filesystem (mapped volumes still support `readOnly`) -* Block device mapping -* Memory as the storage medium (for example, `emptyDir.medium` set to `Memory`) -* File system features like uid/gid; per-user Linux filesystem permissions -* DefaultMode (due to UID/GID dependency) -* NFS based storage/volume support -* Expanding the mounted volume (resizefs) - -Kubernetes {{< glossary_tooltip text="volumes" term_id="volume" >}} enable complex -applications, with data persistence and Pod volume sharing requirements, to be deployed -on Kubernetes. Management of persistent volumes associated with a specific storage -back-end or protocol includes actions such as provisioning/de-provisioning/resizing -of volumes, attaching/detaching a volume to/from a Kubernetes node and -mounting/dismounting a volume to/from individual containers in a pod that needs to -persist data. - -The code implementing these volume management actions for a specific storage back-end -or protocol is shipped in the form of a Kubernetes volume -[plugin](/docs/concepts/storage/volumes/#types-of-volumes). -The following broad classes of Kubernetes volume plugins are supported on Windows: - -##### In-tree volume plugins - -Code associated with in-tree volume plugins ship as part of the core Kubernetes code -base. Deployment of in-tree volume plugins do not require installation of additional -scripts or deployment of separate containerized plugin components. These plugins can -handle provisioning/de-provisioning and resizing of volumes in the storage backend, -attaching/detaching of volumes to/from a Kubernetes node and mounting/dismounting a -volume to/from individual containers in a pod. The following in-tree plugins support -persistent storage on Windows nodes: - -* [`awsElasticBlockStore`](/docs/concepts/storage/volumes/#awselasticblockstore) -* [`azureDisk`](/docs/concepts/storage/volumes/#azuredisk) -* [`azureFile`](/docs/concepts/storage/volumes/#azurefile) -* [`gcePersistentDisk`](/docs/concepts/storage/volumes/#gcepersistentdisk) -* [`vsphereVolume`](/docs/concepts/storage/volumes/#vspherevolume) - -#### FlexVolume plugins - -Code associated with [FlexVolume](/docs/concepts/storage/volumes/#flexVolume) -plugins ship as out-of-tree scripts or binaries that need to be deployed directly -on the host. FlexVolume plugins handle attaching/detaching of volumes to/from a -Kubernetes node and mounting/dismounting a volume to/from individual containers -in a pod. Provisioning/De-provisioning of persistent volumes associated -with FlexVolume plugins may be handled through an external provisioner that -is typically separate from the FlexVolume plugins. The following FlexVolume -[plugins](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows), -deployed as PowerShell scripts on the host, support Windows nodes: - -* [SMB](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~smb.cmd) -* [iSCSI](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~iscsi.cmd) - -#### CSI plugins - -{{< feature-state for_k8s_version="v1.19" state="beta" >}} - -Code associated with {{< glossary_tooltip text="CSI" term_id="csi" >}} plugins ship -as out-of-tree scripts and binaries that are typically distributed as container -images and deployed using standard Kubernetes constructs like DaemonSets and -StatefulSets. -CSI plugins handle a wide range of volume management actions in Kubernetes: -provisioning/de-provisioning/resizing of volumes, attaching/detaching of volumes -to/from a Kubernetes node and mounting/dismounting a volume to/from individual -containers in a pod, backup/restore of persistent data using snapshots and cloning. -CSI plugins typically consist of node plugins (that run on each node as a DaemonSet) -and controller plugins. - -CSI node plugins (especially those associated with persistent volumes exposed as -either block devices or over a shared file-system) need to perform various privileged -operations like scanning of disk devices, mounting of file systems, etc. These -operations differ for each host operating system. For Linux worker nodes, containerized -CSI node plugins are typically deployed as privileged containers. For Windows worker -nodes, privileged operations for containerized CSI node plugins is supported using -[csi-proxy](https://github.com/kubernetes-csi/csi-proxy), a community-managed, -stand-alone binary that needs to be pre-installed on each Windows node. - -For more details, refer to the deployment guide of the CSI plugin you wish to deploy. - -### Command line options for the kubelet {#kubelet-compatibility} - -The behavior of some kubelet command line options behave differently on Windows, as described below: - -* The `--windows-priorityclass` lets you set the scheduling priority of the kubelet process (see [CPU resource management](/docs/concepts/configuration/windows-resource-management/#resource-management-cpu)) -* The `--kubelet-reserve`, `--system-reserve` , and `--eviction-hard` flags update [NodeAllocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) -* Eviction by using `--enforce-node-allocable` is not implemented -* Eviction by using `--eviction-hard` and `--eviction-soft` are not implemented -* A kubelet running on a Windows node does not have memory - restrictions. `--kubelet-reserve` and `--system-reserve` do not set limits on - kubelet or processes running on the host. This means kubelet or a process on the host - could cause memory resource starvation outside the node-allocatable and scheduler. -* The `MemoryPressure` Condition is not implemented -* The kubelet does not take OOM eviction actions - -### API compatibility {#api} - -There are no differences in how most of the Kubernetes APIs work for Windows. The -subtleties around what's different come down to differences in the OS and container -runtime. In certain situations, some properties on workload resources were designed -under the assumption that they would be implemented on Linux, and fail to run on Windows. - -At a high level, these OS concepts are different: - -* Identity - Linux uses userID (UID) and groupID (GID) which - are represented as integer types. User and group names - are not canonical - they are just an alias in `/etc/groups` - or `/etc/passwd` back to UID+GID. Windows uses a larger binary - [security identifier](https://docs.microsoft.com/en-us/windows/security/identity-protection/access-control/security-identifiers) (SID) - which is stored in the Windows Security Access Manager (SAM) database. This - database is not shared between the host and containers, or between containers. -* File permissions - Windows uses an access control list based on (SIDs), whereas - POSIX systems such as Linux use a bitmask based on object permissions and UID+GID, - plus _optional_ access control lists. -* File paths - the convention on Windows is to use `\` instead of `/`. The Go IO - libraries typically accept both and just make it work, but when you're setting a - path or command line that's interpreted inside a container, `\` may be needed. -* Signals - Windows interactive apps handle termination differently, and can - implement one or more of these: - * A UI thread handles well-defined messages including `WM_CLOSE`. - * Console apps handle Ctrl-C or Ctrl-break using a Control Handler. - * Services register a Service Control Handler function that can accept - `SERVICE_CONTROL_STOP` control codes. - -Container exit codes follow the same convention where 0 is success, and nonzero is failure. -The specific error codes may differ across Windows and Linux. However, exit codes -passed from the Kubernetes components (kubelet, kube-proxy) are unchanged. - -##### Field compatibility for container specifications {#compatibility-v1-pod-spec-containers} - -The following list documents differences between how Pod container specifications -work between Windows and Linux: - -* Huge pages are not implemented in the Windows container - runtime, and are not available. They require [asserting a user - privilege](https://docs.microsoft.com/en-us/windows/desktop/Memory/large-page-support) - that's not configurable for containers. -* `requests.cpu` and `requests.memory` - requests are subtracted - from node available resources, so they can be used to avoid overprovisioning a - node. However, they cannot be used to guarantee resources in an overprovisioned - node. They should be applied to all containers as a best practice if the operator - wants to avoid overprovisioning entirely. -* `securityContext.allowPrivilegeEscalation` - - not possible on Windows; none of the capabilities are hooked up -* `securityContext.capabilities` - - POSIX capabilities are not implemented on Windows -* `securityContext.privileged` - - Windows doesn't support privileged containers -* `securityContext.procMount` - - Windows doesn't have a `/proc` filesystem -* `securityContext.readOnlyRootFilesystem` - - not possible on Windows; write access is required for registry & system - processes to run inside the container -* `securityContext.runAsGroup` - - not possible on Windows as there is no GID support -* `securityContext.runAsNonRoot` - - this setting will prevent containers from running as `ContainerAdministrator` - which is the closest equivalent to a root user on Windows. -* `securityContext.runAsUser` - - use [`runAsUserName`](/docs/tasks/configure-pod-container/configure-runasusername) - instead -* `securityContext.seLinuxOptions` - - not possible on Windows as SELinux is Linux-specific -* `terminationMessagePath` - - this has some limitations in that Windows doesn't support mapping single files. The - default value is `/dev/termination-log`, which does work because it does not - exist on Windows by default. - -##### Field compatibility for Pod specifications {#compatibility-v1-pod} - -The following list documents differences between how Pod specifications work between Windows and Linux: - -* `hostIPC` and `hostpid` - host namespace sharing is not possible on Windows -* `hostNetwork` - There is no Windows OS support to share the host network -* `dnsPolicy` - setting the Pod `dnsPolicy` to `ClusterFirstWithHostNet` is - not supported on Windows because host networking is not provided. Pods always - run with a container network. -* `podSecurityContext` (see below) -* `shareProcessNamespace` - this is a beta feature, and depends on Linux namespaces - which are not implemented on Windows. Windows cannot share process namespaces or - the container's root filesystem. Only the network can be shared. -* `terminationGracePeriodSeconds` - this is not fully implemented in Docker on Windows, - see the [GitHub issue](https://github.com/moby/moby/issues/25982). - The behavior today is that the ENTRYPOINT process is sent CTRL_SHUTDOWN_EVENT, - then Windows waits 5 seconds by default, and finally shuts down - all processes using the normal Windows shutdown behavior. The 5 - second default is actually in the Windows registry - [inside the container](https://github.com/moby/moby/issues/25982#issuecomment-426441183), - so it can be overridden when the container is built. -* `volumeDevices` - this is a beta feature, and is not implemented on Windows. - Windows cannot attach raw block devices to pods. -* `volumes` - * If you define an `emptyDir` volume, you cannot set its volume source to `memory`. -* You cannot enable `mountPropagation` for volume mounts as this is not - supported on Windows. - -##### Field compatibility for Pod security context {#compatibility-v1-pod-spec-containers-securitycontext} - -None of the Pod [`securityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context) fields work on Windows. - -### Node problem detector - -The node problem detector (see -[Monitor Node Health](/docs/tasks/debug/debug-cluster/monitor-node-health/)) -is not compatible with Windows. - -### Pause container - -In a Kubernetes Pod, an infrastructure or “pause” container is first created -to host the container. In Linux, the cgroups and namespaces that make up a pod -need a process to maintain their continued existence; the pause process provides -this. Containers that belong to the same pod, including infrastructure and worker -containers, share a common network endpoint (same IPv4 and / or IPv6 address, same -network port spaces). Kubernetes uses pause containers to allow for worker containers -crashing or restarting without losing any of the networking configuration. - -Kubernetes maintains a multi-architecture image that includes support for Windows. -For Kubernetes v{{< skew currentVersion >}} the recommended pause image is `k8s.gcr.io/pause:3.6`. -The [source code](https://github.com/kubernetes/kubernetes/tree/master/build/pause) -is available on GitHub. - -Microsoft maintains a different multi-architecture image, with Linux and Windows -amd64 support, that you can find as `mcr.microsoft.com/oss/kubernetes/pause:3.6`. -This image is built from the same source as the Kubernetes maintained image but -all of the Windows binaries are [authenticode signed](https://docs.microsoft.com/en-us/windows-hardware/drivers/install/authenticode) by Microsoft. -The Kubernetes project recommends using the Microsoft maintained image if you are -deploying to a production or production-like environment that requires signed -binaries. - -### Container runtimes {#container-runtime} - -You need to install a -{{< glossary_tooltip text="container runtime" term_id="container-runtime" >}} -into each node in the cluster so that Pods can run there. - -The following container runtimes work with Windows: - -{{% thirdparty-content %}} - -#### cri-containerd - -{{< feature-state for_k8s_version="v1.20" state="stable" >}} - -You can use {{< glossary_tooltip term_id="containerd" text="ContainerD" >}} 1.4.0+ -as the container runtime for Kubernetes nodes that run Windows. - -Learn how to [install ContainerD on a Windows node](/docs/setup/production-environment/container-runtimes/#install-containerd). - -{{< note >}} -There is a [known limitation](/docs/tasks/configure-pod-container/configure-gmsa/#gmsa-limitations) -when using GMSA with containerd to access Windows network shares, which requires a -kernel patch. -{{< /note >}} - -#### Mirantis Container Runtime {#mcr} - -[Mirantis Container Runtime](https://docs.mirantis.com/mcr/20.10/overview.html) (MCR) is available as a container runtime for all Windows Server 2019 and later versions. - -See [Install MCR on Windows Servers](https://docs.mirantis.com/mcr/20.10/install/mcr-windows.html) for more information. - -## Windows OS version compatibility {#windows-os-version-support} - -On Windows nodes, strict compatibility rules apply where the host OS version must -match the container base image OS version. Only Windows containers with a container -operating system of Windows Server 2019 are fully supported. - -For Kubernetes v{{< skew currentVersion >}}, operating system compatibility for Windows nodes (and Pods) -is as follows: - -Windows Server LTSC release -: Windows Server 2019 -: Windows Server 2022 - -Windows Server SAC release -: Windows Server version 20H2 - -The Kubernetes [version-skew policy](/docs/setup/release/version-skew-policy/) also applies. - -## Getting help and troubleshooting {#troubleshooting} - -Your main source of help for troubleshooting your Kubernetes cluster should start -with the [Troubleshooting](/docs/tasks/debug/) -page. - -Some additional, Windows-specific troubleshooting help is included -in this section. Logs are an important element of troubleshooting -issues in Kubernetes. Make sure to include them any time you seek -troubleshooting assistance from other contributors. Follow the -instructions in the -SIG Windows [contributing guide on gathering logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs). - -### Node-level troubleshooting {#troubleshooting-node} - -1. How do I know `start.ps1` completed successfully? - - You should see kubelet, kube-proxy, and (if you chose Flannel as your networking - solution) flanneld host-agent processes running on your node, with running logs - being displayed in separate PowerShell windows. In addition to this, your Windows - node should be listed as "Ready" in your Kubernetes cluster. - -1. Can I configure the Kubernetes node processes to run in the background as services? - - The kubelet and kube-proxy are already configured to run as native Windows Services, - offering resiliency by re-starting the services automatically in the event of - failure (for example a process crash). You have two options for configuring these - node components as services. - - 1. As native Windows Services - - You can run the kubelet and kube-proxy as native Windows Services using `sc.exe`. - - ```powershell - # Create the services for kubelet and kube-proxy in two separate commands - sc.exe create binPath= " --service " - - # Please note that if the arguments contain spaces, they must be escaped. - sc.exe create kubelet binPath= "C:\kubelet.exe --service --hostname-override 'minion' " - - # Start the services - Start-Service kubelet - Start-Service kube-proxy - - # Stop the service - Stop-Service kubelet (-Force) - Stop-Service kube-proxy (-Force) - - # Query the service status - Get-Service kubelet - Get-Service kube-proxy - ``` - - 1. Using `nssm.exe` - - You can also always use alternative service managers like - [nssm.exe](https://nssm.cc/) to run these processes (flanneld, - kubelet & kube-proxy) in the background for you. You can use this - [sample script](https://github.com/Microsoft/SDN/tree/master/Kubernetes/flannel/register-svc.ps1), - leveraging nssm.exe to register kubelet, kube-proxy, and flanneld.exe to run - as Windows services in the background. - - ```powershell - register-svc.ps1 -NetworkMode -ManagementIP -ClusterCIDR -KubeDnsServiceIP -LogDir - - # NetworkMode = The network mode l2bridge (flannel host-gw, also the default value) or overlay (flannel vxlan) chosen as a network solution - # ManagementIP = The IP address assigned to the Windows node. You can use ipconfig to find this - # ClusterCIDR = The cluster subnet range. (Default value 10.244.0.0/16) - # KubeDnsServiceIP = The Kubernetes DNS service IP (Default value 10.96.0.10) - # LogDir = The directory where kubelet and kube-proxy logs are redirected into their respective output files (Default value C:\k) - ``` - - If the above referenced script is not suitable, you can manually configure - `nssm.exe` using the following examples. - - ```powershell - # Register flanneld.exe - nssm install flanneld C:\flannel\flanneld.exe - nssm set flanneld AppParameters --kubeconfig-file=c:\k\config --iface= --ip-masq=1 --kube-subnet-mgr=1 - nssm set flanneld AppEnvironmentExtra NODE_NAME= - nssm set flanneld AppDirectory C:\flannel - nssm start flanneld - - # Register kubelet.exe - # Microsoft releases the pause infrastructure container at mcr.microsoft.com/oss/kubernetes/pause:3.6 - nssm install kubelet C:\k\kubelet.exe - nssm set kubelet AppParameters --hostname-override= --v=6 --pod-infra-container-image=mcr.microsoft.com/oss/kubernetes/pause:3.6 --resolv-conf="" --allow-privileged=true --enable-debugging-handlers --cluster-dns= --cluster-domain=cluster.local --kubeconfig=c:\k\config --hairpin-mode=promiscuous-bridge --image-pull-progress-deadline=20m --cgroups-per-qos=false --log-dir= --logtostderr=false --enforce-node-allocatable="" --network-plugin=cni --cni-bin-dir=c:\k\cni --cni-conf-dir=c:\k\cni\config - nssm set kubelet AppDirectory C:\k - nssm start kubelet - - # Register kube-proxy.exe (l2bridge / host-gw) - nssm install kube-proxy C:\k\kube-proxy.exe - nssm set kube-proxy AppDirectory c:\k - nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --hostname-override=--kubeconfig=c:\k\config --enable-dsr=false --log-dir= --logtostderr=false - nssm.exe set kube-proxy AppEnvironmentExtra KUBE_NETWORK=cbr0 - nssm set kube-proxy DependOnService kubelet - nssm start kube-proxy - - # Register kube-proxy.exe (overlay / vxlan) - nssm install kube-proxy C:\k\kube-proxy.exe - nssm set kube-proxy AppDirectory c:\k - nssm set kube-proxy AppParameters --v=4 --proxy-mode=kernelspace --feature-gates="WinOverlay=true" --hostname-override= --kubeconfig=c:\k\config --network-name=vxlan0 --source-vip= --enable-dsr=false --log-dir= --logtostderr=false - nssm set kube-proxy DependOnService kubelet - nssm start kube-proxy - ``` - - For initial troubleshooting, you can use the following flags in [nssm.exe](https://nssm.cc/) to redirect stdout and stderr to a output file: - - ```powershell - nssm set AppStdout C:\k\mysvc.log - nssm set AppStderr C:\k\mysvc.log - ``` - - For additional details, see [NSSM - the Non-Sucking Service Manager](https://nssm.cc/usage). - -1. My Pods are stuck at "Container Creating" or restarting over and over - - Check that your pause image is compatible with your OS version. The - [instructions](https://docs.microsoft.com/en-us/virtualization/windowscontainers/kubernetes/deploying-resources) - assume that both the OS and the containers are version 1803. If you have a later - version of Windows, such as an Insider build, you need to adjust the images - accordingly. See [Pause container](#pause-container) for more details. - -### Network troubleshooting {#troubleshooting-network} - -1. My Windows Pods do not have network connectivity - - If you are using virtual machines, ensure that MAC spoofing is **enabled** on all - the VM network adapter(s). - -1. My Windows Pods cannot ping external resources - - Windows Pods do not have outbound rules programmed for the ICMP protocol. However, - TCP/UDP is supported. When trying to demonstrate connectivity to resources - outside of the cluster, substitute `ping ` with corresponding - `curl ` commands. - - If you are still facing problems, most likely your network configuration in - [cni.conf](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf) - deserves some extra attention. You can always edit this static file. The - configuration update will apply to any new Kubernetes resources. - - One of the Kubernetes networking requirements - (see [Kubernetes model](/docs/concepts/cluster-administration/networking/)) is - for cluster communication to occur without - NAT internally. To honor this requirement, there is an - [ExceptionList](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf#L20) - for all the communication where you do not want outbound NAT to occur. However, - this also means that you need to exclude the external IP you are trying to query - from the `ExceptionList`. Only then will the traffic originating from your Windows - pods be SNAT'ed correctly to receive a response from the outside world. In this - regard, your `ExceptionList` in `cni.conf` should look as follows: - - ```conf - "ExceptionList": [ - "10.244.0.0/16", # Cluster subnet - "10.96.0.0/12", # Service subnet - "10.127.130.0/24" # Management (host) subnet - ] - ``` - -1. My Windows node cannot access `NodePort` type Services - - Local NodePort access from the node itself fails. This is a known - limitation. NodePort access works from other nodes or external clients. - -1. vNICs and HNS endpoints of containers are being deleted - - This issue can be caused when the `hostname-override` parameter is not passed to - [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/). To resolve - it, users need to pass the hostname to kube-proxy as follows: - - ```powershell - C:\k\kube-proxy.exe --hostname-override=$(hostname) - ``` - -1. With flannel, my nodes are having issues after rejoining a cluster - - Whenever a previously deleted node is being re-joined to the cluster, flannelD - tries to assign a new pod subnet to the node. Users should remove the old pod - subnet configuration files in the following paths: - - ```powershell - Remove-Item C:\k\SourceVip.json - Remove-Item C:\k\SourceVipRequest.json - ``` - -1. After launching `start.ps1`, flanneld is stuck in "Waiting for the Network to be created" - - There are numerous reports of this [issue](https://github.com/coreos/flannel/issues/1066); most likely it is a timing issue for when the management IP of the flannel network is set. A workaround is to relaunch `start.ps1` or relaunch it manually as follows: - - ```powershell - [Environment]::SetEnvironmentVariable("NODE_NAME", "") - C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface= --ip-masq=1 --kube-subnet-mgr=1 - ``` - -1. My Windows Pods cannot launch because of missing `/run/flannel/subnet.env` - - This indicates that Flannel didn't launch correctly. You can either try - to restart `flanneld.exe` or you can copy the files over manually from - `/run/flannel/subnet.env` on the Kubernetes master to `C:\run\flannel\subnet.env` - on the Windows worker node and modify the `FLANNEL_SUBNET` row to a different - number. For example, if node subnet 10.244.4.1/24 is desired: - - ```env - FLANNEL_NETWORK=10.244.0.0/16 - FLANNEL_SUBNET=10.244.4.1/24 - FLANNEL_MTU=1500 - FLANNEL_IPMASQ=true - ``` - -1. My Windows node cannot access my services using the service IP - - This is a known limitation of the networking stack on Windows. However, Windows Pods can access the Service IP. - -1. No network adapter is found when starting the kubelet - - The Windows networking stack needs a virtual adapter for Kubernetes networking to work. If the following commands return no results (in an admin shell), virtual network creation — a necessary prerequisite for the kubelet to work — has failed: - - ```powershell - Get-HnsNetwork | ? Name -ieq "cbr0" - Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*" - ``` - - Often it is worthwhile to modify the [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L7) parameter of the start.ps1 script, in cases where the host's network adapter isn't "Ethernet". Otherwise, consult the output of the `start-kubelet.ps1` script to see if there are errors during virtual network creation. - -1. DNS resolution is not properly working - - Check the DNS limitations for Windows in this [section](#dns-limitations). - -1. `kubectl port-forward` fails with "unable to do port forwarding: wincat not found" - - This was implemented in Kubernetes 1.15 by including `wincat.exe` in the pause infrastructure container `mcr.microsoft.com/oss/kubernetes/pause:3.6`. Be sure to use a supported version of Kubernetes. - If you would like to build your own pause infrastructure container be sure to include [wincat](https://github.com/kubernetes/kubernetes/tree/master/build/pause/windows/wincat). - -1. My Kubernetes installation is failing because my Windows Server node is behind a proxy - - If you are behind a proxy, the following PowerShell environment variables must be defined: - - ```PowerShell - [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine) - [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine) - ``` - -### Further investigation - -If these steps don't resolve your problem, you can get help running Windows containers on Windows nodes in Kubernetes through: - -* StackOverflow [Windows Server Container](https://stackoverflow.com/questions/tagged/windows-server-container) topic -* Kubernetes Official Forum [discuss.kubernetes.io](https://discuss.kubernetes.io/) -* Kubernetes Slack [#SIG-Windows Channel](https://kubernetes.slack.com/messages/sig-windows) - -### Reporting issues and feature requests - -If you have what looks like a bug, or you would like to -make a feature request, please use the -[GitHub issue tracking system](https://github.com/kubernetes/kubernetes/issues). -You can open issues on -[GitHub](https://github.com/kubernetes/kubernetes/issues/new/choose) and assign -them to SIG-Windows. You should first search the list of issues in case it was -reported previously and comment with your experience on the issue and add additional -logs. SIG-Windows Slack is also a great avenue to get some initial support and -troubleshooting ideas prior to creating a ticket. - -If filing a bug, please include detailed information about how to reproduce the problem, such as: - -* Kubernetes version: output from `kubectl version` -* Environment details: Cloud provider, OS distro, networking choice and configuration, and Docker version -* Detailed steps to reproduce the problem -* [Relevant logs](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs) - -It helps if you tag the issue as **sig/windows**, by commenting on the issue with `/sig windows`. This helps to bring -the issue to a SIG Windows member's attention - - -## {{% heading "whatsnext" %}} - -### Deployment tools - -The kubeadm tool helps you to deploy a Kubernetes cluster, providing the control -plane to manage the cluster it, and nodes to run your workloads. -[Adding Windows nodes](/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/) -explains how to deploy Windows nodes to your cluster using kubeadm. - -The Kubernetes [cluster API](https://cluster-api.sigs.k8s.io/) project also provides means to automate deployment of Windows nodes. - -### Windows distribution channels - -For a detailed explanation of Windows distribution channels see the [Microsoft documentation](https://docs.microsoft.com/en-us/windows-server/get-started-19/servicing-channels-19). - -Information on the different Windows Server servicing channels -including their support models can be found at -[Windows Server servicing channels](https://docs.microsoft.com/en-us/windows-server/get-started/servicing-channels-comparison). diff --git a/content/en/docs/tasks/access-application-cluster/access-cluster-services.md b/content/en/docs/tasks/access-application-cluster/access-cluster-services.md index 262071094c..456662692e 100644 --- a/content/en/docs/tasks/access-application-cluster/access-cluster-services.md +++ b/content/en/docs/tasks/access-application-cluster/access-cluster-services.md @@ -64,17 +64,17 @@ kubectl cluster-info The output is similar to this: ``` -Kubernetes master is running at https://104.197.5.247 -elasticsearch-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy -kibana-logging is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kibana-logging/proxy -kube-dns is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/kube-dns/proxy -grafana is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy -heapster is running at https://104.197.5.247/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy +Kubernetes master is running at https://192.0.2.1 +elasticsearch-logging is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy +kibana-logging is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/kibana-logging/proxy +kube-dns is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/kube-dns/proxy +grafana is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/monitoring-grafana/proxy +heapster is running at https://192.0.2.1/api/v1/namespaces/kube-system/services/monitoring-heapster/proxy ``` This shows the proxy-verb URL for accessing each service. For example, this cluster has cluster-level logging enabled (using Elasticsearch), which can be reached -at `https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` if suitable credentials are passed, or through a kubectl proxy at, for example: +at `https://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/` if suitable credentials are passed, or through a kubectl proxy at, for example: `http://localhost:8080/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/`. {{< note >}} @@ -104,13 +104,13 @@ The supported formats for the `` segment of the URL are: * To access the Elasticsearch service endpoint `_search?q=user:kimchy`, you would use: ``` - http://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy + http://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_search?q=user:kimchy ``` * To access the Elasticsearch cluster health information `_cluster/health?pretty=true`, you would use: ``` - https://104.197.5.247/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true + https://192.0.2.1/api/v1/namespaces/kube-system/services/elasticsearch-logging/proxy/_cluster/health?pretty=true ``` The health information is similar to this: @@ -133,7 +133,7 @@ The supported formats for the `` segment of the URL are: * To access the *https* Elasticsearch service health information `_cluster/health?pretty=true`, you would use: ``` - https://104.197.5.247/api/v1/namespaces/kube-system/services/https:elasticsearch-logging/proxy/_cluster/health?pretty=true + https://192.0.2.1/api/v1/namespaces/kube-system/services/https:elasticsearch-logging:/proxy/_cluster/health?pretty=true ``` #### Using web browsers to access services running on the cluster diff --git a/content/en/docs/tasks/access-application-cluster/access-cluster.md b/content/en/docs/tasks/access-application-cluster/access-cluster.md index aae96d3e96..f20fe407e8 100644 --- a/content/en/docs/tasks/access-application-cluster/access-cluster.md +++ b/content/en/docs/tasks/access-application-cluster/access-cluster.md @@ -233,7 +233,7 @@ There are several different proxies you may encounter when using Kubernetes: - locates apiserver - adds authentication headers -1. The [apiserver proxy](#discovering-builtin-services): +1. The [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster-services/#discovering-builtin-services): - is a bastion built into the apiserver - connects a user outside of the cluster to cluster IPs which otherwise might not be reachable diff --git a/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md b/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md index 8b79d7042f..fe8beeacad 100644 --- a/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md +++ b/content/en/docs/tasks/access-application-cluster/configure-access-multiple-clusters.md @@ -115,7 +115,7 @@ kubectl config --kubeconfig=config-demo view The output shows the two clusters, two users, and three contexts: -```shell +```yaml apiVersion: v1 clusters: - cluster: diff --git a/content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md b/content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md index ba8f7b1244..3b2648f943 100644 --- a/content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md +++ b/content/en/docs/tasks/access-application-cluster/port-forward-access-application-cluster.md @@ -11,180 +11,169 @@ This page shows how to use `kubectl port-forward` to connect to a MongoDB server running in a Kubernetes cluster. This type of connection can be useful for database debugging. - - - ## {{% heading "prerequisites" %}} - * {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} - * Install [MongoDB Shell](https://www.mongodb.com/try/download/shell). - - - ## Creating MongoDB deployment and service 1. Create a Deployment that runs MongoDB: - ```shell - kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-deployment.yaml - ``` + ```shell + kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-deployment.yaml + ``` - The output of a successful command verifies that the deployment was created: + The output of a successful command verifies that the deployment was created: - ``` - deployment.apps/mongo created - ``` + ``` + deployment.apps/mongo created + ``` - View the pod status to check that it is ready: + View the pod status to check that it is ready: - ```shell - kubectl get pods - ``` + ```shell + kubectl get pods + ``` - The output displays the pod created: + The output displays the pod created: - ``` - NAME READY STATUS RESTARTS AGE - mongo-75f59d57f4-4nd6q 1/1 Running 0 2m4s - ``` + ``` + NAME READY STATUS RESTARTS AGE + mongo-75f59d57f4-4nd6q 1/1 Running 0 2m4s + ``` - View the Deployment's status: + View the Deployment's status: - ```shell - kubectl get deployment - ``` + ```shell + kubectl get deployment + ``` - The output displays that the Deployment was created: + The output displays that the Deployment was created: - ``` - NAME READY UP-TO-DATE AVAILABLE AGE - mongo 1/1 1 1 2m21s - ``` + ``` + NAME READY UP-TO-DATE AVAILABLE AGE + mongo 1/1 1 1 2m21s + ``` - The Deployment automatically manages a ReplicaSet. - View the ReplicaSet status using: + The Deployment automatically manages a ReplicaSet. + View the ReplicaSet status using: - ```shell - kubectl get replicaset - ``` + ```shell + kubectl get replicaset + ``` - The output displays that the ReplicaSet was created: - - ``` - NAME DESIRED CURRENT READY AGE - mongo-75f59d57f4 1 1 1 3m12s - ``` + The output displays that the ReplicaSet was created: + ``` + NAME DESIRED CURRENT READY AGE + mongo-75f59d57f4 1 1 1 3m12s + ``` 2. Create a Service to expose MongoDB on the network: - ```shell - kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-service.yaml - ``` + ```shell + kubectl apply -f https://k8s.io/examples/application/mongodb/mongo-service.yaml + ``` - The output of a successful command verifies that the Service was created: + The output of a successful command verifies that the Service was created: - ``` - service/mongo created - ``` + ``` + service/mongo created + ``` - Check the Service created: + Check the Service created: - ```shell - kubectl get service mongo - ``` + ```shell + kubectl get service mongo + ``` - The output displays the service created: + The output displays the service created: - ``` - NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE - mongo ClusterIP 10.96.41.183 27017/TCP 11s - ``` + ``` + NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE + mongo ClusterIP 10.96.41.183 27017/TCP 11s + ``` 3. Verify that the MongoDB server is running in the Pod, and listening on port 27017: - ```shell - # Change mongo-75f59d57f4-4nd6q to the name of the Pod - kubectl get pod mongo-75f59d57f4-4nd6q --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}' - ``` + ```shell + # Change mongo-75f59d57f4-4nd6q to the name of the Pod + kubectl get pod mongo-75f59d57f4-4nd6q --template='{{(index (index .spec.containers 0).ports 0).containerPort}}{{"\n"}}' + ``` - The output displays the port for MongoDB in that Pod: + The output displays the port for MongoDB in that Pod: - ``` - 27017 - ``` + ``` + 27017 + ``` - (this is the TCP port allocated to MongoDB on the internet). + 27017 is the TCP port allocated to MongoDB on the internet. ## Forward a local port to a port on the Pod -1. `kubectl port-forward` allows using resource name, such as a pod name, to select a matching pod to port forward to. +1. `kubectl port-forward` allows using resource name, such as a pod name, to select a matching pod to port forward to. - ```shell - # Change mongo-75f59d57f4-4nd6q to the name of the Pod - kubectl port-forward mongo-75f59d57f4-4nd6q 28015:27017 - ``` + ```shell + # Change mongo-75f59d57f4-4nd6q to the name of the Pod + kubectl port-forward mongo-75f59d57f4-4nd6q 28015:27017 + ``` - which is the same as + which is the same as - ```shell - kubectl port-forward pods/mongo-75f59d57f4-4nd6q 28015:27017 - ``` + ```shell + kubectl port-forward pods/mongo-75f59d57f4-4nd6q 28015:27017 + ``` - or + or - ```shell - kubectl port-forward deployment/mongo 28015:27017 - ``` + ```shell + kubectl port-forward deployment/mongo 28015:27017 + ``` - or + or - ```shell - kubectl port-forward replicaset/mongo-75f59d57f4 28015:27017 - ``` + ```shell + kubectl port-forward replicaset/mongo-75f59d57f4 28015:27017 + ``` - or + or - ```shell - kubectl port-forward service/mongo 28015:27017 - ``` + ```shell + kubectl port-forward service/mongo 28015:27017 + ``` - Any of the above commands works. The output is similar to this: + Any of the above commands works. The output is similar to this: - ``` - Forwarding from 127.0.0.1:28015 -> 27017 - Forwarding from [::1]:28015 -> 27017 - ``` + ``` + Forwarding from 127.0.0.1:28015 -> 27017 + Forwarding from [::1]:28015 -> 27017 + ``` -{{< note >}} + {{< note >}} + `kubectl port-forward` does not return. To continue with the exercises, you will need to open another terminal. + {{< /note >}} -`kubectl port-forward` does not return. To continue with the exercises, you will need to open another terminal. +2. Start the MongoDB command line interface: -{{< /note >}} + ```shell + mongosh --port 28015 + ``` -2. Start the MongoDB command line interface: +3. At the MongoDB command line prompt, enter the `ping` command: - ```shell - mongosh --port 28015 - ``` + ``` + db.runCommand( { ping: 1 } ) + ``` -3. At the MongoDB command line prompt, enter the `ping` command: + A successful ping request returns: - ``` - db.runCommand( { ping: 1 } ) - ``` - - A successful ping request returns: - - ``` - { ok: 1 } - ``` + ``` + { ok: 1 } + ``` ### Optionally let _kubectl_ choose the local port {#let-kubectl-choose-local-port} @@ -204,7 +193,6 @@ Forwarding from 127.0.0.1:63753 -> 27017 Forwarding from [::1]:63753 -> 27017 ``` - ## Discussion @@ -219,9 +207,7 @@ The support for UDP protocol is tracked in [issue 47862](https://github.com/kubernetes/kubernetes/issues/47862). {{< /note >}} - - - ## {{% heading "whatsnext" %}} Learn more about [kubectl port-forward](/docs/reference/generated/kubectl/kubectl-commands/#port-forward). + diff --git a/content/en/docs/tasks/administer-cluster/certificates.md b/content/en/docs/tasks/administer-cluster/certificates.md index 2338b0cdc7..44effe9340 100644 --- a/content/en/docs/tasks/administer-cluster/certificates.md +++ b/content/en/docs/tasks/administer-cluster/certificates.md @@ -1,5 +1,5 @@ --- -title: Certificates +title: Generate Certificates Manually content_type: task weight: 20 --- diff --git a/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md b/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md index bf5ddd8f5f..be77074dc1 100644 --- a/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md +++ b/content/en/docs/tasks/administer-cluster/configure-upgrade-etcd.md @@ -150,7 +150,7 @@ access to clients with the certificate `k8sclient.cert`. Once etcd is configured correctly, only clients with valid certificates can access it. To give Kubernetes API servers the access, configure them with the -flags `--etcd-certfile=k8sclient.cert`,`--etcd-keyfile=k8sclient.key` and +flags `--etcd-certfile=k8sclient.cert`, `--etcd-keyfile=k8sclient.key` and `--etcd-cafile=ca.cert`. {{< note >}} @@ -319,7 +319,7 @@ employed to recover the data of a failed cluster. Before starting the restore operation, a snapshot file must be present. It can either be a snapshot file from a previous backup operation, or from a remaining -[data directory]( https://etcd.io/docs/current/op-guide/configuration/#--data-dir). +[data directory](https://etcd.io/docs/current/op-guide/configuration/#--data-dir). Here is an example: ```shell diff --git a/content/en/docs/tasks/administer-cluster/encrypt-data.md b/content/en/docs/tasks/administer-cluster/encrypt-data.md index c48f9ee2da..d510caff81 100644 --- a/content/en/docs/tasks/administer-cluster/encrypt-data.md +++ b/content/en/docs/tasks/administer-cluster/encrypt-data.md @@ -88,8 +88,8 @@ Name | Encryption | Strength | Speed | Key Length | Other Considerations `identity` | None | N/A | N/A | N/A | Resources written as-is without encryption. When set as the first provider, the resource will be decrypted as new values are written. `secretbox` | XSalsa20 and Poly1305 | Strong | Faster | 32-byte | A newer standard and may not be considered acceptable in environments that require high levels of review. `aesgcm` | AES-GCM with random nonce | Must be rotated every 200k writes | Fastest | 16, 24, or 32-byte | Is not recommended for use except when an automated key rotation scheme is implemented. -`aescbc` | AES-CBC with PKCS#7 padding | Weak | Fast | 32-byte | Not recommended due to CBC's vulnerability to padding oracle attacks. -`kms` | Uses envelope encryption scheme: Data is encrypted by data encryption keys (DEKs) using AES-CBC with PKCS#7 padding, DEKs are encrypted by key encryption keys (KEKs) according to configuration in Key Management Service (KMS) | Strongest | Fast | 32-bytes | The recommended choice for using a third party tool for key management. Simplifies key rotation, with a new DEK generated for each encryption, and KEK rotation controlled by the user. [Configure the KMS provider](/docs/tasks/administer-cluster/kms-provider/) +`aescbc` | AES-CBC with [PKCS#7](https://datatracker.ietf.org/doc/html/rfc2315) padding | Weak | Fast | 32-byte | Not recommended due to CBC's vulnerability to padding oracle attacks. +`kms` | Uses envelope encryption scheme: Data is encrypted by data encryption keys (DEKs) using AES-CBC with [PKCS#7](https://datatracker.ietf.org/doc/html/rfc2315) padding, DEKs are encrypted by key encryption keys (KEKs) according to configuration in Key Management Service (KMS) | Strongest | Fast | 32-bytes | The recommended choice for using a third party tool for key management. Simplifies key rotation, with a new DEK generated for each encryption, and KEK rotation controlled by the user. [Configure the KMS provider](/docs/tasks/administer-cluster/kms-provider/) Each provider supports multiple keys - the keys are tried in order for decryption, and if the provider is the first provider, the first key is used for encryption. diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md index 8040e1185f..e366f136bc 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -29,7 +29,7 @@ The upgrade workflow at high level is the following: ## {{% heading "prerequisites" %}} -- Make sure you read the [release notes]({{< latest-release-notes >}}) carefully. +- Make sure you read the [release notes](https://git.k8s.io/kubernetes/CHANGELOG) carefully. - The cluster should use a static control plane and etcd pods or external etcd. - Make sure to back up any important components, such as app-level state stored in a database. `kubeadm upgrade` does not touch your workloads, only components internal to Kubernetes, but backups are always a best practice. diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md index 6c52dea6e1..e0255eb2bd 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace.md @@ -27,7 +27,7 @@ in the namespace. You must have access to create namespaces in your cluster. -Your cluster must have at least 1.0 CPU available for use to run the task examples. +Each node in your cluster must have at least 1.0 CPU available for Pods. See [meaning of CPU](/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu) to learn what Kubernetes means by “1 CPU”. @@ -45,7 +45,7 @@ kubectl create namespace constraints-cpu-example ## Create a LimitRange and a Pod -Here's an example manifest for a LimitRange: +Here's a manifest for an example {{< glossary_tooltip text="LimitRange" term_id="limitrange" >}}: {{< codenew file="admin/resource/cpu-constraints.yaml" >}} @@ -96,7 +96,7 @@ on these resources, the two values must be the same. Here's a manifest for a Pod that has one container. The container manifest specifies a CPU request of 500 millicpu and a CPU limit of 800 millicpu. These satisfy the -minimum and maximum CPU constraints imposed by the LimitRange. +minimum and maximum CPU constraints imposed by the LimitRange for this namespace. {{< codenew file="admin/resource/cpu-constraints-pod.yaml" >}} @@ -214,7 +214,10 @@ applied the [default CPU request and limit](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) from the LimitRange for this namespace. -At this point, your Pod might be running or it might not be running. Recall that a prerequisite for this task is that your cluster must have at least 1 CPU available for use. If each of your Nodes has only 1 CPU, then there might not be enough allocatable CPU on any Node to accommodate a request of 800 millicpu. If you happen to be using Nodes with 2 CPU, then you probably have enough CPU to accommodate the 800 millicpu request. +At this point, your Pod may or may not be running. Recall that a prerequisite for +this task is that your Nodes must have at least 1 CPU available for use. If each of your Nodes has only 1 CPU, +then there might not be enough allocatable CPU on any Node to accommodate a request of 800 millicpu. +If you happen to be using Nodes with 2 CPU, then you probably have enough CPU to accommodate the 800 millicpu request. Delete your Pod: diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md index 3efd899075..9d2d707cb0 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace.md @@ -11,8 +11,9 @@ description: >- This page shows how to set minimum and maximum values for memory used by containers -running in a namespace. You specify minimum and maximum memory values in a -[LimitRange](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#limitrange-v1-core) +running in a {{< glossary_tooltip text="namespace" term_id="namespace" >}}. +You specify minimum and maximum memory values in a +[LimitRange](/docs/reference/kubernetes-api/policy-resources/limit-range-v1/) object. If a Pod does not meet the constraints imposed by the LimitRange, it cannot be created in the namespace. @@ -76,8 +77,8 @@ file for the LimitRange, they were created automatically. Now whenever you define a Pod within the constraints-mem-example namespace, Kubernetes performs these steps: -* If any container in that Pod does not specify its own memory request and limit, assign -the default memory request and limit to that container. +* If any container in that Pod does not specify its own memory request and limit, +the control plane assigns the default memory request and limit to that container. * Verify that every container in that Pod requests at least 500 MiB of memory. diff --git a/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md b/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md index 025277127d..1013800e44 100644 --- a/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md +++ b/content/en/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md @@ -172,7 +172,7 @@ resources: If your namespace has a memory {{< glossary_tooltip text="resource quota" term_id="resource-quota" >}} configured, it is helpful to have a default value in place for memory limit. -Here are two of the restrictions that a resource quota imposes on a namespace: +Here are three of the restrictions that a resource quota imposes on a namespace: * For every Pod that runs in the namespace, the Pod and each of its containers must have a memory limit. (If you specify a memory limit for every container in a Pod, Kubernetes can infer the Pod-level memory diff --git a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md index f54be498d4..d4a915914b 100644 --- a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md +++ b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md @@ -16,7 +16,7 @@ installations. Our [Dockershim Removal FAQ](/blog/2022/02/17/dockershim-faq/) is to understand the problem better. Dockershim was removed from Kubernetes with the release of v1.24. -If you use Docker via dockershim as your container runtime, and wish to upgrade to v1.24, +If you use Docker Engine via dockershim as your container runtime, and wish to upgrade to v1.24, it is recommended that you either migrate to another runtime or find an alternative means to obtain Docker Engine support. Check out [container runtimes](/docs/setup/production-environment/container-runtimes/) section to know your options. Make sure to diff --git a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd.md b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd.md index b4074a1385..3d79e5d4f7 100644 --- a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd.md +++ b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd.md @@ -44,7 +44,7 @@ for detailed steps to install containerd. 1. Install the `containerd.io` package from the official Docker repositories. Instructions for setting up the Docker repository for your respective Linux distribution and installing the `containerd.io` package can be found at - [Install Docker Engine](https://docs.docker.com/engine/install/#server). + [Getting started with containerd](https://github.com/containerd/containerd/blob/main/docs/getting-started.md). 1. Configure containerd: diff --git a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md index dbfe02d9e6..c4247f085a 100644 --- a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md +++ b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use.md @@ -41,7 +41,7 @@ node-2 Ready v1.16.15 docker://19.3.1 node-3 Ready v1.16.15 docker://19.3.1 ``` If your runtime shows as Docker Engine, you still might not be affected by the -removal of dockershim in Kubernetes 1.24. [Check the runtime +removal of dockershim in Kubernetes v1.24. [Check the runtime endpoint](#which-endpoint) to see if you use dockershim. If you don't use dockershim, you aren't affected. @@ -64,7 +64,7 @@ The container runtime talks to the kubelet over a Unix socket using the [CRI protocol](/docs/concepts/architecture/cri/), which is based on the gRPC framework. The kubelet acts as a client, and the runtime acts as the server. In some cases, you might find it useful to know which socket your nodes use. For -example, with the removal of dockershim in Kubernetes 1.24 and later, you might +example, with the removal of dockershim in Kubernetes v1.24 and later, you might want to know whether you use Docker Engine with dockershim. {{}} @@ -93,6 +93,7 @@ nodes. name to find out which runtime you use. For example, `unix:///run/containerd/containerd.sock` is the containerd endpoint. -If you use Docker Engine with the dockershim, [migrate to a different runtime](/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/), -or, if you want to continue using Docker Engine in v1.24 and later, migrate to a +If you want to change the Container Runtime on a Node from Docker Engine to containerd, +you can find out more information on [migrating from Docker Engine to containerd](/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/), +or, if you want to continue using Docker Engine in Kubernetes v1.24 and later, migrate to a CRI-compatible adapter like [`cri-dockerd`](https://github.com/Mirantis/cri-dockerd). \ No newline at end of file diff --git a/content/en/docs/tasks/administer-cluster/quota-api-object.md b/content/en/docs/tasks/administer-cluster/quota-api-object.md index 11592d2152..ad38f102d4 100644 --- a/content/en/docs/tasks/administer-cluster/quota-api-object.md +++ b/content/en/docs/tasks/administer-cluster/quota-api-object.md @@ -89,7 +89,7 @@ kubectl get persistentvolumeclaims --namespace=quota-object-example The output shows that the PersistentVolumeClaim exists and has status Pending: -```shell +``` NAME STATUS pvc-quota-demo Pending ``` diff --git a/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md b/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md index 82a501e5d4..e1effd8f05 100644 --- a/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md +++ b/content/en/docs/tasks/administer-cluster/reconfigure-kubelet.md @@ -29,7 +29,7 @@ Please find documentation on this feature in [earlier versions of documentation] There is no recommended replacement for this feature that works generically across various Kubernetes distributions. If you are using managed Kubernetes version, please consult with the vendor hosting Kubernetes for the best -practices for customizing your Kubernetes. If you are using KubeAdm, refer to +practices for customizing your Kubernetes. If you are using `kubeadm`, refer to [Configuring each kubelet in your cluster using kubeadm](/docs/setup/production-environment/tools/kubeadm/kubelet-integration/). In order to migrate off the Dynamic Kubelet Configuration feature, the diff --git a/content/en/docs/tasks/administer-cluster/topology-manager.md b/content/en/docs/tasks/administer-cluster/topology-manager.md index e8d2e7c19d..4002537f0c 100644 --- a/content/en/docs/tasks/administer-cluster/topology-manager.md +++ b/content/en/docs/tasks/administer-cluster/topology-manager.md @@ -20,7 +20,7 @@ An increasing number of systems leverage a combination of CPUs and hardware acce In order to extract the best performance, optimizations related to CPU isolation, memory and device locality are required. However, in Kubernetes, these optimizations are handled by a disjoint set of components. -_Topology Manager_ is a Kubelet component that aims to co-ordinate the set of components that are responsible for these optimizations. +_Topology Manager_ is a Kubelet component that aims to coordinate the set of components that are responsible for these optimizations. @@ -267,4 +267,4 @@ Using this information the Topology Manager calculates the optimal hint for the ### Known Limitations 1. The maximum number of NUMA nodes that Topology Manager allows is 8. With more than 8 NUMA nodes there will be a state explosion when trying to enumerate the possible NUMA affinities and generating their hints. -2. The scheduler is not topology-aware, so it is possible to be scheduled on a node and then fail on the node due to the Topology Manager. \ No newline at end of file +2. The scheduler is not topology-aware, so it is possible to be scheduled on a node and then fail on the node due to the Topology Manager. diff --git a/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md b/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md index 137571d8e8..d923d6356c 100644 --- a/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md +++ b/content/en/docs/tasks/configure-pod-container/assign-memory-resource.md @@ -171,7 +171,7 @@ kubectl get pod memory-demo-2 --output=yaml --namespace=mem-example The output shows that the Container was killed because it is out of memory (OOM): -```shell +```yaml lastState: terminated: containerID: 65183c1877aaec2e8427bc95609cc52677a454b56fcb24340dbd22917c23b10f @@ -278,7 +278,7 @@ kubectl describe pod memory-demo-3 --namespace=mem-example The output shows that the Container cannot be scheduled because of insufficient memory on the Nodes: -```shell +``` Events: ... Reason Message ------ ------- @@ -291,8 +291,8 @@ The memory resource is measured in bytes. You can express memory as a plain inte fixed-point integer with one of these suffixes: E, P, T, G, M, K, Ei, Pi, Ti, Gi, Mi, Ki. For example, the following represent approximately the same value: -```shell -128974848, 129e6, 129M , 123Mi +``` +128974848, 129e6, 129M, 123Mi ``` Delete your Pod: diff --git a/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md b/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md index 62b334e068..8dc36c5e39 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md +++ b/content/en/docs/tasks/configure-pod-container/configure-pod-configmap.md @@ -10,7 +10,7 @@ card: Many applications rely on configuration which is used during either application initialization or runtime. Most of the times there is a requirement to adjust values assigned to configuration parameters. -ConfigMaps is the kubernetes way to inject application pods with configuration data. +ConfigMaps is the kubernetes way to inject application pods with configuration data. ConfigMaps allow you to decouple configuration artifacts from image content to keep containerized applications portable. This page provides a series of usage examples demonstrating how to create ConfigMaps and configure Pods using data stored in ConfigMaps. @@ -461,35 +461,35 @@ configmap/special-config-2-c92b5mmcf2 created ### Define a container environment variable with data from a single ConfigMap -1. Define an environment variable as a key-value pair in a ConfigMap: +1. Define an environment variable as a key-value pair in a ConfigMap: - ```shell - kubectl create configmap special-config --from-literal=special.how=very - ``` + ```shell + kubectl create configmap special-config --from-literal=special.how=very + ``` -2. Assign the `special.how` value defined in the ConfigMap to the `SPECIAL_LEVEL_KEY` environment variable in the Pod specification. +2. Assign the `special.how` value defined in the ConfigMap to the `SPECIAL_LEVEL_KEY` environment variable in the Pod specification. {{< codenew file="pods/pod-single-configmap-env-variable.yaml" >}} Create the Pod: - ```shell - kubectl create -f https://kubernetes.io/examples/pods/pod-single-configmap-env-variable.yaml - ``` + ```shell + kubectl create -f https://kubernetes.io/examples/pods/pod-single-configmap-env-variable.yaml + ``` Now, the Pod's output includes environment variable `SPECIAL_LEVEL_KEY=very`. ### Define container environment variables with data from multiple ConfigMaps - * As with the previous example, create the ConfigMaps first. +* As with the previous example, create the ConfigMaps first. - {{< codenew file="configmap/configmaps.yaml" >}} + {{< codenew file="configmap/configmaps.yaml" >}} - Create the ConfigMap: + Create the ConfigMap: - ```shell - kubectl create -f https://kubernetes.io/examples/configmap/configmaps.yaml - ``` + ```shell + kubectl create -f https://kubernetes.io/examples/configmap/configmaps.yaml + ``` * Define the environment variables in the Pod specification. @@ -497,9 +497,9 @@ configmap/special-config-2-c92b5mmcf2 created Create the Pod: - ```shell - kubectl create -f https://kubernetes.io/examples/pods/pod-multiple-configmap-env-variable.yaml - ``` + ```shell + kubectl create -f https://kubernetes.io/examples/pods/pod-multiple-configmap-env-variable.yaml + ``` Now, the Pod's output includes environment variables `SPECIAL_LEVEL_KEY=very` and `LOG_LEVEL=INFO`. @@ -515,21 +515,21 @@ This functionality is available in Kubernetes v1.6 and later. Create the ConfigMap: - ```shell - kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml - ``` + ```shell + kubectl create -f https://kubernetes.io/examples/configmap/configmap-multikeys.yaml + ``` * Use `envFrom` to define all of the ConfigMap's data as container environment variables. The key from the ConfigMap becomes the environment variable name in the Pod. - {{< codenew file="pods/pod-configmap-envFrom.yaml" >}} + {{< codenew file="pods/pod-configmap-envFrom.yaml" >}} - Create the Pod: + Create the Pod: - ```shell - kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-envFrom.yaml - ``` + ```shell + kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-envFrom.yaml + ``` - Now, the Pod's output includes environment variables `SPECIAL_LEVEL=very` and `SPECIAL_TYPE=charm`. + Now, the Pod's output includes environment variables `SPECIAL_LEVEL=very` and `SPECIAL_TYPE=charm`. ## Use ConfigMap-defined environment variables in Pod commands @@ -548,7 +548,7 @@ kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-env-var-valu produces the following output in the `test-container` container: -```shell +``` very charm ``` @@ -582,7 +582,7 @@ kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume.yaml When the pod runs, the command `ls /etc/config/` produces the output below: -```shell +``` SPECIAL_LEVEL SPECIAL_TYPE ``` @@ -610,7 +610,7 @@ kubectl create -f https://kubernetes.io/examples/pods/pod-configmap-volume-speci When the pod runs, the command `cat /etc/config/keys` produces the output below: -```shell +``` very ``` @@ -680,15 +680,15 @@ data: - If you use `envFrom` to define environment variables from ConfigMaps, keys that are considered invalid will be skipped. The pod will be allowed to start, but the invalid names will be recorded in the event log (`InvalidVariableNames`). The log message lists each skipped key. For example: - ```shell - kubectl get events - ``` + ```shell + kubectl get events + ``` - The output is similar to this: - ``` - LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE - 0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames {kubelet, 127.0.0.1} Keys [1badkey, 2alsobad] from the EnvFrom configMap default/myconfig were skipped since they are considered invalid environment variable names. - ``` + The output is similar to this: + ``` + LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE + 0s 0s 1 dapi-test-pod Pod Warning InvalidEnvironmentVariableNames {kubelet, 127.0.0.1} Keys [1badkey, 2alsobad] from the EnvFrom configMap default/myconfig were skipped since they are considered invalid environment variable names. + ``` - ConfigMaps reside in a specific {{< glossary_tooltip term_id="namespace" >}}. A ConfigMap can only be referenced by pods residing in the same namespace. @@ -699,4 +699,3 @@ data: ## {{% heading "whatsnext" %}} * Follow a real world example of [Configuring Redis using a ConfigMap](/docs/tutorials/configuration/configure-redis-using-configmap/). - diff --git a/content/en/docs/tasks/configure-pod-container/configure-runasusername.md b/content/en/docs/tasks/configure-pod-container/configure-runasusername.md index 9ddcac270f..58028f9c89 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-runasusername.md +++ b/content/en/docs/tasks/configure-pod-container/configure-runasusername.md @@ -57,7 +57,7 @@ echo $env:USERNAME The output should be: -```shell +``` ContainerUser ``` @@ -97,7 +97,7 @@ echo $env:USERNAME The output should be: -```shell +``` ContainerAdministrator ``` @@ -120,7 +120,7 @@ For more information about these limtations, check [here](https://support.micros ## {{% heading "whatsnext" %}} -* [Guide for scheduling Windows containers in Kubernetes](/docs/setup/production-environment/windows/user-guide-windows-containers/) -* [Managing Workload Identity with Group Managed Service Accounts (GMSA)](/docs/setup/production-environment/windows/user-guide-windows-containers/#managing-workload-identity-with-group-managed-service-accounts) +* [Guide for scheduling Windows containers in Kubernetes](/docs/concepts/windows/user-guide/) +* [Managing Workload Identity with Group Managed Service Accounts (GMSA)](/docs/concepts/windows/user-guide/#managing-workload-identity-with-group-managed-service-accounts) * [Configure GMSA for Windows pods and containers](/docs/tasks/configure-pod-container/configure-gmsa/) diff --git a/content/en/docs/tasks/debug/debug-cluster/local-debugging.md b/content/en/docs/tasks/debug/debug-cluster/local-debugging.md index f556deaa39..1d97a4134d 100644 --- a/content/en/docs/tasks/debug/debug-cluster/local-debugging.md +++ b/content/en/docs/tasks/debug/debug-cluster/local-debugging.md @@ -24,7 +24,7 @@ This document describes using `telepresence` to develop and debug services runni ## Connecting your local machine to a remote Kubernetes cluster -After installing `telepresence`, run `telepresence connect` to launch it's Daemon and connect your local workstation to the cluster. +After installing `telepresence`, run `telepresence connect` to launch its Daemon and connect your local workstation to the cluster. ``` $ telepresence connect diff --git a/content/en/docs/tasks/debug/debug-cluster/windows.md b/content/en/docs/tasks/debug/debug-cluster/windows.md new file mode 100644 index 0000000000..ccd6cf4434 --- /dev/null +++ b/content/en/docs/tasks/debug/debug-cluster/windows.md @@ -0,0 +1,170 @@ +--- +reviewers: +- aravindhp +- jayunit100 +- jsturtevant +- marosset +title: Windows debugging tips +content_type: concept +--- + + + + + +## Node-level troubleshooting {#troubleshooting-node} + +1. My Pods are stuck at "Container Creating" or restarting over and over + + Ensure that your pause image is compatible with your Windows OS version. + See [Pause container](/docs/setup/production-environment/windows/intro-windows-in-kubernetes#pause-container) + to see the latest / recommended pause image and/or get more information. + + {{< note >}} + If using containerd as your container runtime the pause image is specified in the + `plugins.plugins.cri.sandbox_image` field of the of config.toml configration file. + {{< /note >}} + +1. My pods show status as `ErrImgPull` or `ImagePullBackOff` + + Ensure that your Pod is getting scheduled to a [compatable](https://docs.microsoft.com/virtualization/windowscontainers/deploy-containers/version-compatibility) Windows Node. + + More information on how to specify a compatable node for your Pod can be found in [this guide](/docs/setup/production-environment/windows/user-guide-windows-containers/#ensuring-os-specific-workloads-land-on-the-appropriate-container-host). + +## Network troubleshooting {#troubleshooting-network} + +1. My Windows Pods do not have network connectivity + + If you are using virtual machines, ensure that MAC spoofing is **enabled** on all + the VM network adapter(s). + +1. My Windows Pods cannot ping external resources + + Windows Pods do not have outbound rules programmed for the ICMP protocol. However, + TCP/UDP is supported. When trying to demonstrate connectivity to resources + outside of the cluster, substitute `ping ` with corresponding + `curl ` commands. + + If you are still facing problems, most likely your network configuration in + [cni.conf](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf) + deserves some extra attention. You can always edit this static file. The + configuration update will apply to any new Kubernetes resources. + + One of the Kubernetes networking requirements + (see [Kubernetes model](/docs/concepts/cluster-administration/networking/)) is + for cluster communication to occur without + NAT internally. To honor this requirement, there is an + [ExceptionList](https://github.com/Microsoft/SDN/blob/master/Kubernetes/flannel/l2bridge/cni/config/cni.conf#L20) + for all the communication where you do not want outbound NAT to occur. However, + this also means that you need to exclude the external IP you are trying to query + from the `ExceptionList`. Only then will the traffic originating from your Windows + pods be SNAT'ed correctly to receive a response from the outside world. In this + regard, your `ExceptionList` in `cni.conf` should look as follows: + + ```conf + "ExceptionList": [ + "10.244.0.0/16", # Cluster subnet + "10.96.0.0/12", # Service subnet + "10.127.130.0/24" # Management (host) subnet + ] + ``` + +1. My Windows node cannot access `NodePort` type Services + + Local NodePort access from the node itself fails. This is a known + limitation. NodePort access works from other nodes or external clients. + +1. vNICs and HNS endpoints of containers are being deleted + + This issue can be caused when the `hostname-override` parameter is not passed to + [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/). To resolve + it, users need to pass the hostname to kube-proxy as follows: + + ```powershell + C:\k\kube-proxy.exe --hostname-override=$(hostname) + ``` + +1. My Windows node cannot access my services using the service IP + + This is a known limitation of the networking stack on Windows. However, Windows Pods can access the Service IP. + +1. No network adapter is found when starting the kubelet + + The Windows networking stack needs a virtual adapter for Kubernetes networking to work. + If the following commands return no results (in an admin shell), + virtual network creation — a necessary prerequisite for the kubelet to work — has failed: + + ```powershell + Get-HnsNetwork | ? Name -ieq "cbr0" + Get-NetAdapter | ? Name -Like "vEthernet (Ethernet*" + ``` + + Often it is worthwhile to modify the [InterfaceName](https://github.com/microsoft/SDN/blob/master/Kubernetes/flannel/start.ps1#L7) parameter of the `start.ps1` script, + in cases where the host's network adapter isn't "Ethernet". + Otherwise, consult the output of the `start-kubelet.ps1` script to see if there are errors during virtual network creation. + +1. DNS resolution is not properly working + + Check the DNS limitations for Windows in this [section](#dns-limitations). + +1. `kubectl port-forward` fails with "unable to do port forwarding: wincat not found" + + This was implemented in Kubernetes 1.15 by including `wincat.exe` in the pause infrastructure container `mcr.microsoft.com/oss/kubernetes/pause:3.6`. + Be sure to use a supported version of Kubernetes. + If you would like to build your own pause infrastructure container be sure to include [wincat](https://github.com/kubernetes/kubernetes/tree/master/build/pause/windows/wincat). + +1. My Kubernetes installation is failing because my Windows Server node is behind a proxy + + If you are behind a proxy, the following PowerShell environment variables must be defined: + + ```PowerShell + [Environment]::SetEnvironmentVariable("HTTP_PROXY", "http://proxy.example.com:80/", [EnvironmentVariableTarget]::Machine) + [Environment]::SetEnvironmentVariable("HTTPS_PROXY", "http://proxy.example.com:443/", [EnvironmentVariableTarget]::Machine) + ``` + +### Flannel troubleshooting + +1. With Flannel, my nodes are having issues after rejoining a cluster + + Whenever a previously deleted node is being re-joined to the cluster, flannelD + tries to assign a new pod subnet to the node. Users should remove the old pod + subnet configuration files in the following paths: + + ```powershell + Remove-Item C:\k\SourceVip.json + Remove-Item C:\k\SourceVipRequest.json + ``` + +1. Flanneld is stuck in "Waiting for the Network to be created" + + There are numerous reports of this [issue](https://github.com/coreos/flannel/issues/1066); + most likely it is a timing issue for when the management IP of the flannel network is set. + A workaround is to relaunch `start.ps1` or relaunch it manually as follows: + + ```powershell + [Environment]::SetEnvironmentVariable("NODE_NAME", "") + C:\flannel\flanneld.exe --kubeconfig-file=c:\k\config --iface= --ip-masq=1 --kube-subnet-mgr=1 + ``` + +1. My Windows Pods cannot launch because of missing `/run/flannel/subnet.env` + + This indicates that Flannel didn't launch correctly. You can either try + to restart `flanneld.exe` or you can copy the files over manually from + `/run/flannel/subnet.env` on the Kubernetes master to `C:\run\flannel\subnet.env` + on the Windows worker node and modify the `FLANNEL_SUBNET` row to a different + number. For example, if node subnet 10.244.4.1/24 is desired: + + ```env + FLANNEL_NETWORK=10.244.0.0/16 + FLANNEL_SUBNET=10.244.4.1/24 + FLANNEL_MTU=1500 + FLANNEL_IPMASQ=true + ``` + +### Further investigation + +If these steps don't resolve your problem, you can get help running Windows containers on Windows nodes in Kubernetes through: + +* StackOverflow [Windows Server Container](https://stackoverflow.com/questions/tagged/windows-server-container) topic +* Kubernetes Official Forum [discuss.kubernetes.io](https://discuss.kubernetes.io/) +* Kubernetes Slack [#SIG-Windows Channel](https://kubernetes.slack.com/messages/sig-windows) \ No newline at end of file diff --git a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md index fdcc276a45..6857f1a4d5 100644 --- a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md +++ b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md @@ -444,7 +444,7 @@ spec: served: true # One and only one version must be marked as the storage version. storage: true - # Each version can define it's own schema when there is no top-level + # Each version can define its own schema when there is no top-level # schema is defined. schema: openAPIV3Schema: @@ -512,7 +512,7 @@ spec: served: true # One and only one version must be marked as the storage version. storage: true - # Each version can define it's own schema when there is no top-level + # Each version can define its own schema when there is no top-level # schema is defined. schema: openAPIV3Schema: diff --git a/content/en/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md b/content/en/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md index d50b3e91a5..fb6085980b 100644 --- a/content/en/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md +++ b/content/en/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information.md @@ -69,7 +69,7 @@ kubectl logs kubernetes-downwardapi-volume-example The output shows the contents of the `labels` file and the `annotations` file: -```shell +``` cluster="test-cluster1" rack="rack-22" zone="us-est-coast" @@ -155,7 +155,7 @@ file for a Pod that has one Container: {{< codenew file="pods/inject/dapi-volume-resources.yaml" >}} In the configuration file, you can see that the Pod has a -[`downwardAPI` volume](/concepts/storage/volumes/#downwardapi), +[`downwardAPI` volume](/docs/concepts/storage/volumes/#downwardapi), and the Container mounts the volume at `/etc/podinfo`. Look at the `items` array under `downwardAPI`. Each element of the array is a diff --git a/content/en/docs/tasks/manage-daemon/update-daemon-set.md b/content/en/docs/tasks/manage-daemon/update-daemon-set.md index e435f392fe..d6d6b68f19 100644 --- a/content/en/docs/tasks/manage-daemon/update-daemon-set.md +++ b/content/en/docs/tasks/manage-daemon/update-daemon-set.md @@ -79,7 +79,7 @@ kubectl apply -f https://k8s.io/examples/controllers/fluentd-daemonset.yaml --dr The output from both commands should be: -```shell +``` RollingUpdate ``` diff --git a/content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md b/content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md index 7b38703c74..ad2fc41173 100644 --- a/content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md +++ b/content/en/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch.md @@ -82,7 +82,7 @@ kubectl get deployment patch-demo --output yaml The output shows that the PodSpec in the Deployment has two Containers: -```shell +```yaml containers: - image: redis imagePullPolicy: Always @@ -309,7 +309,7 @@ kubectl patch deployment retainkeys-demo --type merge --patch-file patch-file-no In the output, you can see that it is not possible to set `type` as `Recreate` when a value is defined for `spec.strategy.rollingUpdate`: -```shell +``` The Deployment "retainkeys-demo" is invalid: spec.strategy.rollingUpdate: Forbidden: may not be specified when strategy `type` is 'Recreate' ``` @@ -341,7 +341,7 @@ kubectl get deployment retainkeys-demo --output yaml The output shows that the strategy object in the Deployment does not contain the `rollingUpdate` key anymore: -```shell +```yaml spec: strategy: type: Recreate diff --git a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md index e9a446287c..1f655ea535 100644 --- a/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md +++ b/content/en/docs/tasks/run-application/horizontal-pod-autoscale.md @@ -400,7 +400,7 @@ scaling in that direction. ### Stabilization window The stabilization window is used to restrict the [flapping](#flapping) of -replicas count when the metrics used for scaling keep fluctuating. The autoscaling algorithm +replica count when the metrics used for scaling keep fluctuating. The autoscaling algorithm uses this window to infer a previous desired state and avoid unwanted changes to workload scale. diff --git a/content/en/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive.html b/content/en/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive.html index bb926a1d19..fd3db09a42 100644 --- a/content/en/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive.html +++ b/content/en/docs/tutorials/configuration/configure-java-microservice/configure-java-microservice-interactive.html @@ -11,7 +11,7 @@ weight: 20 - +{{< katacoda-tutorial >}}
diff --git a/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md b/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md index ec6edb9cc7..d95e752208 100644 --- a/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md +++ b/content/en/docs/tutorials/configuration/configure-redis-using-configmap.md @@ -8,7 +8,7 @@ content_type: tutorial -This page provides a real world example of how to configure Redis using a ConfigMap and builds upon the [Configure Containers Using a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) task. +This page provides a real world example of how to configure Redis using a ConfigMap and builds upon the [Configure a Pod to Use a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) task. @@ -27,7 +27,7 @@ This page provides a real world example of how to configure Redis using a Config {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} * The example shown on this page works with `kubectl` 1.14 and above. -* Understand [Configure Containers Using a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/). +* Understand [Configure a Pod to Use a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/). @@ -78,7 +78,7 @@ kubectl get pod/redis configmap/example-redis-config You should see the following output: -```shell +``` NAME READY STATUS RESTARTS AGE pod/redis 1/1 Running 0 8s diff --git a/content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html b/content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html index 5301c6b7a1..2649ce4f94 100644 --- a/content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html +++ b/content/en/docs/tutorials/kubernetes-basics/create-cluster/cluster-interactive.html @@ -11,7 +11,7 @@ weight: 20 - +{{< katacoda-tutorial >}}
diff --git a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html index 915304f912..d8a525a6d5 100644 --- a/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html +++ b/content/en/docs/tutorials/kubernetes-basics/deploy-app/deploy-interactive.html @@ -11,7 +11,7 @@ weight: 20 - +{{< katacoda-tutorial >}}
diff --git a/content/en/docs/tutorials/kubernetes-basics/explore/explore-interactive.html b/content/en/docs/tutorials/kubernetes-basics/explore/explore-interactive.html index ad79ec5d7f..82b5f4bb33 100644 --- a/content/en/docs/tutorials/kubernetes-basics/explore/explore-interactive.html +++ b/content/en/docs/tutorials/kubernetes-basics/explore/explore-interactive.html @@ -11,7 +11,7 @@ weight: 20 - +{{< katacoda-tutorial >}}
diff --git a/content/en/docs/tutorials/kubernetes-basics/expose/expose-interactive.html b/content/en/docs/tutorials/kubernetes-basics/expose/expose-interactive.html index 2b5d3aa365..ce5eeb455f 100644 --- a/content/en/docs/tutorials/kubernetes-basics/expose/expose-interactive.html +++ b/content/en/docs/tutorials/kubernetes-basics/expose/expose-interactive.html @@ -11,7 +11,7 @@ weight: 20 - +{{< katacoda-tutorial >}}
diff --git a/content/en/docs/tutorials/kubernetes-basics/scale/scale-interactive.html b/content/en/docs/tutorials/kubernetes-basics/scale/scale-interactive.html index 3fedf79782..ad01e64c02 100644 --- a/content/en/docs/tutorials/kubernetes-basics/scale/scale-interactive.html +++ b/content/en/docs/tutorials/kubernetes-basics/scale/scale-interactive.html @@ -11,7 +11,7 @@ weight: 20 - +{{< katacoda-tutorial >}}
diff --git a/content/en/docs/tutorials/kubernetes-basics/update/update-interactive.html b/content/en/docs/tutorials/kubernetes-basics/update/update-interactive.html index 2e70d61d74..99184ddb3e 100644 --- a/content/en/docs/tutorials/kubernetes-basics/update/update-interactive.html +++ b/content/en/docs/tutorials/kubernetes-basics/update/update-interactive.html @@ -11,7 +11,7 @@ weight: 20 - +{{< katacoda-tutorial >}}
diff --git a/content/en/docs/tutorials/services/source-ip.md b/content/en/docs/tutorials/services/source-ip.md index bb9a622c98..9eab7538d4 100644 --- a/content/en/docs/tutorials/services/source-ip.md +++ b/content/en/docs/tutorials/services/source-ip.md @@ -206,19 +206,8 @@ Note that these are not the correct client IPs, they're cluster internal IPs. Th Visually: -{{< mermaid >}} -graph LR; - client(client)-->node2[Node 2]; - node2-->client; - node2-. SNAT .->node1[Node 1]; - node1-. SNAT .->node2; - node1-->endpoint(Endpoint); +{{< figure src="/docs/images/tutor-service-nodePort-fig01.svg" alt="source IP nodeport figure 01" class="diagram-large" caption="Figure. Source IP Type=NodePort using SNAT" link="https://mermaid.live/edit#pako:eNqNkV9rwyAUxb-K3LysYEqS_WFYKAzat9GHdW9zDxKvi9RoMIZtlH732ZjSbE970cu5v3s86hFqJxEYfHjRNeT5ZcUtIbXRaMNN2hZ5vrYRqt52cSXV-4iMSuwkZiYtyX739EqWaahMQ-V1qPxDVLNOvkYrO6fj2dupWMR2iiT6foOKdEZoS5Q2hmVSStoH7w7IMqXUVOefWoaG3XVftHbGeZYVRbH6ZXJ47CeL2-qhxvt_ucTe1SUlpuMN6CX12XeGpLdJiaMMFFr0rdAyvvfxjHEIDbbIgcVSohKDCRy4PUV06KQIuJU6OA9MCdMjBTEEt_-2NbDgB7xAGy3i97VJPP0ABRmcqg" >}} - classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; - classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; - class node1,node2,endpoint k8s; - class client plain; -{{}} To avoid this, Kubernetes has a feature to [preserve the client source IP](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip). @@ -262,20 +251,8 @@ This is what happens: Visually: -{{< mermaid >}} -graph TD; - client --> node1[Node 1]; - client(client) --x node2[Node 2]; - node1 --> endpoint(endpoint); - endpoint --> node1; - - classDef plain fill:#ddd,stroke:#fff,stroke-width:4px,color:#000; - classDef k8s fill:#326ce5,stroke:#fff,stroke-width:4px,color:#fff; - class node1,node2,endpoint k8s; - class client plain; -{{}} - +{{< figure src="/docs/images/tutor-service-nodePort-fig02.svg" alt="source IP nodeport figure 02" class="diagram-large" caption="Figure. Source IP Type=NodePort preserves client source IP address" link="" >}} ## Source IP for Services with `Type=LoadBalancer` diff --git a/content/en/releases/patch-releases.md b/content/en/releases/patch-releases.md index 144e74676b..d0f56d19c3 100644 --- a/content/en/releases/patch-releases.md +++ b/content/en/releases/patch-releases.md @@ -78,10 +78,10 @@ releases may also occur in between these. | Monthly Patch Release | Cherry Pick Deadline | Target date | | --------------------- | -------------------- | ----------- | -| May 2022 | 2022-05-20 | 2022-05-24 | | June 2022 | 2022-06-10 | 2022-06-15 | | July 2022 | 2022-07-08 | 2022-07-13 | -| August 2022 | 2022-08-12 | 2022-08-16 | +| August 2022 | 2022-08-12 | 2022-08-17 | +| September 2022 | 2022-09-09 | 2022-09-14 | ## Detailed Release History for Active Branches @@ -93,6 +93,7 @@ End of Life for **1.24** is **2023-09-29** | PATCH RELEASE | CHERRY PICK DEADLINE | TARGET DATE | NOTE | |---------------|----------------------|-------------|------| +| 1.24.2 | 2022-06-10 | 2022-06-15 | | | 1.24.1 | 2022-05-20 | 2022-05-24 | | ### 1.23 @@ -103,11 +104,12 @@ End of Life for **1.23** is **2023-02-28**. | Patch Release | Cherry Pick Deadline | Target Date | Note | |---------------|----------------------|-------------|------| +| 1.23.8 | 2022-06-10 | 2022-06-15 | | | 1.23.7 | 2022-05-20 | 2022-05-24 | | | 1.23.6 | 2022-04-08 | 2022-04-13 | | | 1.23.5 | 2022-03-11 | 2022-03-16 | | | 1.23.4 | 2022-02-11 | 2022-02-16 | | -| 1.23.3 | 2022-01-24 | 2022-01-25 | [Out-of-Band Release](https://groups.google.com/u/2/a/kubernetes.io/g/dev/c/Xl1sm-CItaY) | +| 1.23.3 | 2022-01-24 | 2022-01-25 | [Out-of-Band Release](https://groups.google.com/a/kubernetes.io/g/dev/c/Xl1sm-CItaY) | | 1.23.2 | 2022-01-14 | 2022-01-19 | | | 1.23.1 | 2021-12-14 | 2021-12-16 | | @@ -119,6 +121,7 @@ End of Life for **1.22** is **2022-10-28** | Patch Release | Cherry Pick Deadline | Target Date | Note | |---------------|----------------------|-------------|------| +| 1.22.11 | 2022-06-10 | 2022-06-15 | | | 1.22.10 | 2022-05-20 | 2022-05-24 | | | 1.22.9 | 2022-04-08 | 2022-04-13 | | | 1.22.8 | 2022-03-11 | 2022-03-16 | | @@ -137,20 +140,21 @@ End of Life for **1.22** is **2022-10-28** End of Life for **1.21** is **2022-06-28** | Patch Release | Cherry Pick Deadline | Target Date | Note | -| ------------- | -------------------- | ----------- | ---------------------------------------------------------------------- | -| 1.21.13 | 2022-05-20 | 2022-05-24 | | -| 1.21.12 | 2022-04-08 | 2022-04-13 | | -| 1.21.11 | 2022-03-11 | 2022-03-16 | | -| 1.21.10 | 2022-02-11 | 2022-02-16 | | -| 1.21.9 | 2022-01-14 | 2022-01-19 | | -| 1.21.8 | 2021-12-10 | 2021-12-15 | | -| 1.21.7 | 2021-11-12 | 2021-11-17 | | -| 1.21.6 | 2021-10-22 | 2021-10-27 | | -| 1.21.5 | 2021-09-10 | 2021-09-15 | | -| 1.21.4 | 2021-08-07 | 2021-08-11 | | -| 1.21.3 | 2021-07-10 | 2021-07-14 | | -| 1.21.2 | 2021-06-12 | 2021-06-16 | | -| 1.21.1 | 2021-05-07 | 2021-05-12 | [Regression](https://groups.google.com/g/kubernetes-dev/c/KuF8s2zueFs) | +| ------------- | -------------------- | ----------- | ------------------------------------------------------------------------ | +| 1.21.14 | 2022-06-10 | 2022-06-15 | If there is any critical issues to be released otherwise will be skipped | +| 1.21.13 | 2022-05-20 | 2022-05-24 | | +| 1.21.12 | 2022-04-08 | 2022-04-13 | | +| 1.21.11 | 2022-03-11 | 2022-03-16 | | +| 1.21.10 | 2022-02-11 | 2022-02-16 | | +| 1.21.9 | 2022-01-14 | 2022-01-19 | | +| 1.21.8 | 2021-12-10 | 2021-12-15 | | +| 1.21.7 | 2021-11-12 | 2021-11-17 | | +| 1.21.6 | 2021-10-22 | 2021-10-27 | | +| 1.21.5 | 2021-09-10 | 2021-09-15 | | +| 1.21.4 | 2021-08-07 | 2021-08-11 | | +| 1.21.3 | 2021-07-10 | 2021-07-14 | | +| 1.21.2 | 2021-06-12 | 2021-06-16 | | +| 1.21.1 | 2021-05-07 | 2021-05-12 | [Regression](https://groups.google.com/g/kubernetes-dev/c/KuF8s2zueFs) | ## Non-Active Branch History diff --git a/content/en/releases/version-skew-policy.md b/content/en/releases/version-skew-policy.md index 87f6cf2c62..f59ab71ad8 100644 --- a/content/en/releases/version-skew-policy.md +++ b/content/en/releases/version-skew-policy.md @@ -26,7 +26,7 @@ For more information, see [Kubernetes Release Versioning](https://github.com/kub The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). Kubernetes 1.19 and newer receive approximately 1 year of patch support. Kubernetes 1.18 and older received approximately 9 months of patch support. Applicable fixes, including security fixes, may be backported to those three release branches, depending on severity and feasibility. -Patch releases are cut from those branches at a [regular cadence](https://git.k8s.io/sig-release/releases/patch-releases.md#cadence), plus additional urgent releases, when required. +Patch releases are cut from those branches at a [regular cadence](https://kubernetes.io/releases/patch-releases/#cadence), plus additional urgent releases, when required. The [Release Managers](/releases/release-managers/) group owns this decision. diff --git a/content/es/docs/concepts/workloads/pods/init-containers.md b/content/es/docs/concepts/workloads/pods/init-containers.md index fad0220899..fafb6ae2f6 100644 --- a/content/es/docs/concepts/workloads/pods/init-containers.md +++ b/content/es/docs/concepts/workloads/pods/init-containers.md @@ -338,4 +338,4 @@ Kubernetes, consulta la documentación de la versión que estás utilizando. ## {{% heading "whatsnext" %}} * Lee acerca de [creando un Pod que tiene un contenedor de inicialización](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container) -* Aprende cómo [depurar contenedores de inicialización](/docs/tasks/debug-application-cluster/debug-init-containers/) +* Aprende cómo [depurar contenedores de inicialización](/docs/tasks/debug/debug-application/debug-init-containers/) diff --git a/content/fr/docs/concepts/workloads/pods/init-containers.md b/content/fr/docs/concepts/workloads/pods/init-containers.md index fb4b6f3270..2af4306b0b 100644 --- a/content/fr/docs/concepts/workloads/pods/init-containers.md +++ b/content/fr/docs/concepts/workloads/pods/init-containers.md @@ -325,6 +325,6 @@ redémarrage du conteneur d'application. * Lire à propos de la [création d'un Pod ayant un init container](/docs/tasks/configure-pod-container/configure-pod-initialization/#creating-a-pod-that-has-an-init-container) -* Apprendre à [debugger les init containers](/docs/tasks/debug-application-cluster/debug-init-containers/) +* Apprendre à [debugger les init containers](/docs/tasks/debug/debug-application/debug-init-containers/) diff --git a/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 5902ca926d..2aa904144f 100644 --- a/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/fr/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -37,7 +37,7 @@ Le champ `periodSeconds` spécifie que le Kubelet doit effectuer un check de liv Au démarrage, le conteneur exécute cette commande : ```shell -/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600" +/bin/sh -c "touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600" ``` Pour les 30 premières secondes de la vie du conteneur, il y a un fichier `/tmp/healthy`. diff --git a/content/fr/examples/pods/probe/exec-liveness.yaml b/content/fr/examples/pods/probe/exec-liveness.yaml index 07bf75f85c..6a9c9b3213 100644 --- a/content/fr/examples/pods/probe/exec-liveness.yaml +++ b/content/fr/examples/pods/probe/exec-liveness.yaml @@ -11,7 +11,7 @@ spec: args: - /bin/sh - -c - - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 + - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600 livenessProbe: exec: command: diff --git a/content/id/docs/concepts/workloads/pods/disruptions.md b/content/id/docs/concepts/workloads/pods/disruptions.md index 7a09eed3a5..f466bc6300 100644 --- a/content/id/docs/concepts/workloads/pods/disruptions.md +++ b/content/id/docs/concepts/workloads/pods/disruptions.md @@ -67,7 +67,7 @@ Kubernetes menawarkan fitur-fitur untuk membantu menjalankan aplikasi-aplikasi d Pemilik aplikasi dapat membuat objek `PodDisruptionBudget` (PDB) untuk setiap aplikasi. Sebuah PDB membatasi jumlah Pod yang boleh mati secara bersamaan pada aplikasi yang direplikasi dikarenakan disrupsi yang disengaja. Misalnya, sebuah aplikasi yang bekerja secara _quorum_ mau memastikan bahwa jumlah replika yang berjalan tidak jatuh ke bawah yang dibutuhkan untuk membentuk sebuah _quorum_. Contoh lainnya, sebuah _front-end_ web mungkin perlu memastikan bahwa jumlah replika yang melayani trafik tidak pernah turun ke total persentase yang telah ditentukan. -Administrator klaster dan penyedia layanan Kubernetes sebaiknya menggunakan alat-alat yang menghormati PDB dengan cara berkomunikasi dengan [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api) dari pada menghapus Pod atau Deployment secara langsung. Contohnya adalah perintah `kubectl drain` dan skrip pembaruan Kubernets-on-GCE (`cluster/gce/upgrade.sh`) +Administrator klaster dan penyedia layanan Kubernetes sebaiknya menggunakan alat-alat yang menghormati PDB dengan cara berkomunikasi dengan [Eviction API](/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api) dari pada menghapus Pod atau Deployment secara langsung. Contohnya adalah perintah `kubectl drain` dan skrip pembaruan Kubernetes-on-GCE (`cluster/gce/upgrade.sh`) Saat seorang administrator klaster ingin melakukan _drain_ terhadap sebuah node, ia akan menggunakan perintah `kubectl drain`. Alat tersebut mencoba untuk "mengusir" semua Pod di node tersebut. Permintaan untuk mengusir Pod tersebut mungkin ditolak untuk sementara, dan alat tersebut akan mencoba ulang permintaannya secara periodik hingga semua Pod dihapus, atau hingga batas waktu yang ditentukan telah dicapai. diff --git a/content/id/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/id/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 934f6178cd..96b08d1aca 100644 --- a/content/id/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/id/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -59,7 +59,7 @@ kode selain 0, maka kubelet akan mematikan Container dan mengulangnya kembali. Saat dimulai, Container akan menjalankan perintah berikut: ```shell -/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600" +/bin/sh -c "touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600" ``` Container memiliki berkas `/tmp/healthy` pada saat 30 detik pertama setelah dijalankan. diff --git a/content/id/docs/tutorials/kubernetes-basics/explore/explore-intro.html b/content/id/docs/tutorials/kubernetes-basics/explore/explore-intro.html index a6381b3275..1b3b494b1a 100644 --- a/content/id/docs/tutorials/kubernetes-basics/explore/explore-intro.html +++ b/content/id/docs/tutorials/kubernetes-basics/explore/explore-intro.html @@ -76,9 +76,9 @@ weight: 10

Node

Sebuah Pod selalu berjalan dalam sebuah Node. Node merupakan sebuah mesin pekerja (worker) di Kubernetes dan mungkin merupakan mesin virtual ataupun fisik, tergantung dari klaster. Tiap Node dikelola oleh control plane. Satu Node dapat memiliki beberapa Pod, dan control plane Kubernetes yang otomatis menangani penjadwalan pod seluruh Node-Node dalam klaster. Penjadwalan otomatis oleh control plane memperhitungkan tersedianya sumber daya tiap Node.

-

Tiap Node Kuberbetes menjalankan setidaknya:

+

Tiap Node Kubernetes menjalankan setidaknya:

    -
  • Kubelet, satu proses yang bertanggung jawab untuk berkomunikasi antara control plane Kuberneter dan Node; ini juga mengelola Pod-Pod dan kontainer-kontainer yang berjalan di sebuah mesin.
    • +
  • Kubelet, satu proses yang bertanggung jawab untuk berkomunikasi antara control plane Kubernetes dan Node; ini juga mengelola Pod-Pod dan kontainer-kontainer yang berjalan di sebuah mesin.
  • Satu container runtime, seperti Docker, bertanggung jawab untuk menarik image kontainer dari register, membuka kontainer, dan menjalankan aplikasi.
diff --git a/content/id/examples/pods/probe/exec-liveness.yaml b/content/id/examples/pods/probe/exec-liveness.yaml index 07bf75f85c..6a9c9b3213 100644 --- a/content/id/examples/pods/probe/exec-liveness.yaml +++ b/content/id/examples/pods/probe/exec-liveness.yaml @@ -11,7 +11,7 @@ spec: args: - /bin/sh - -c - - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 + - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600 livenessProbe: exec: command: diff --git a/content/ja/docs/concepts/scheduling-eviction/api-eviction.md b/content/ja/docs/concepts/scheduling-eviction/api-eviction.md new file mode 100644 index 0000000000..5092c96b19 --- /dev/null +++ b/content/ja/docs/concepts/scheduling-eviction/api-eviction.md @@ -0,0 +1,92 @@ +--- +title: APIを起点とした退避 +content_type: concept +weight: 70 +--- + +{{< glossary_definition term_id="api-eviction" length="short" >}}
+ +Eviction APIを直接呼び出すか、`kubectl drain`コマンドのように{{}}のクライアントを使って退避を要求することが可能です。これにより、`Eviction`オブジェクトを作成し、APIサーバーにPodを終了させます。 + +APIを起点とした退避は[`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/)と[`terminationGracePeriodSeconds`](/ja/docs/concepts/workloads/pods/pod-lifecycle#pod-termination)の設定を優先します。 + +APIを使用してPodのEvictionオブジェクトを作成することは、Podに対してポリシー制御された[`DELETE`操作](/docs/reference/kubernetes-api/workload-resources/pod-v1/#delete-delete-a-pod)を実行することに似ています。 + +## Eviction APIの実行 {#calling-the-eviction-api} + +Kubernetes APIへアクセスして`Eviction`オブジェクトを作るために[Kubernetesのプログラミング言語のクライアント](/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api)を使用できます。 +そのためには、次の例のようなデータをPOSTすることで操作を試みることができます。 + +{{< tabs name="Eviction_example" >}} +{{% tab name="policy/v1" %}} +{{< note >}} +`policy/v1`においてEvictionはv1.22以上で利用可能です。それ以前のリリースでは、`policy/v1beta1`を使用してください。 +{{< /note >}} + +```json +{ + "apiVersion": "policy/v1", + "kind": "Eviction", + "metadata": { + "name": "quux", + "namespace": "default" + } +} +``` +{{% /tab %}} +{{% tab name="policy/v1beta1" %}} +{{< note >}} +v1.22で非推奨となり、`policy/v1`が採用されました。 +{{< /note >}} + +```json +{ + "apiVersion": "policy/v1beta1", + "kind": "Eviction", + "metadata": { + "name": "quux", + "namespace": "default" + } +} +``` +{{% /tab %}} +{{< /tabs >}} + +また、以下の例のように`curl`や`wget`を使ってAPIにアクセスすることで、操作を試みることもできます。 + +```bash +curl -v -H 'Content-type: application/json' https://your-cluster-api-endpoint.example/api/v1/namespaces/default/pods/quux/eviction -d @eviction.json +``` + +## APIを起点とした退避の仕組み {#how-api-initiated-eviction-works} + +APIを使用して退去を要求した場合、APIサーバーはアドミッションチェックを行い、以下のいずれかを返します。 + +* `200 OK`:この場合、退去が許可されると`Eviction`サブリソースが作成され、PodのURLに`DELETE`リクエストを送るのと同じように、Podが削除されます。 +* `429 Too Many Requests`:{{}}の設定により、現在退去が許可されていないことを示します。しばらく時間を空けてみてください。また、APIのレート制限のため、このようなレスポンスが表示されることもあります。 +* `500 Internal Server Error`:複数のPodDisruptionBudgetが同じPodを参照している場合など、設定に誤りがあり退去が許可されないことを示します。 + +退去させたいPodがPodDisruptionBudgetを持つワークロードの一部でない場合、APIサーバーは常に`200 OK`を返して退去を許可します。 + +APIサーバーが退去を許可した場合、以下の流れでPodが削除されます。 + +1. APIサーバーの`Pod`リソースの削除タイムスタンプが更新され、APIサーバーは`Pod`リソースが終了したと見なします。また`Pod`リソースは、設定された猶予期間が設けられます。 +1. ローカルのPodが動作しているNodeの{{}}は、`Pod`リソースが終了するようにマークされていることに気付き、Podの適切なシャットダウンを開始します。 +1. kubeletがPodをシャットダウンしている間、コントロールプレーンは{{}}オブジェクトからPodを削除します。その結果、コントローラーはPodを有効なオブジェクトと見なさないようになります。 +1. Podの猶予期間が終了すると、kubeletはローカルPodを強制的に終了します。 +1. kubeletはAPIサーバーに`Pod`リソースを削除するように指示します。 +1. APIサーバーは`Pod`リソースを削除します。 + +## トラブルシューティング {#troubleshooting-stuck-evictions} + +場合によっては、アプリケーションが壊れた状態になり、対処しない限りEviction APIが`429`または`500`レスポンスを返すだけとなることがあります。例えば、ReplicaSetがアプリケーション用のPodを作成しても、新しいPodが`Ready`状態にならない場合などです。また、最後に退去したPodの終了猶予期間が長い場合にも、この事象が見られます。 + +退去が進まない場合は、以下の解決策を試してみてください。 + +* 問題を引き起こしている自動化された操作を中止または一時停止し、操作を再開する前に、スタックしているアプリケーションを調査を行ってください。 +* しばらく待ってから、Eviction APIを使用する代わりに、クラスターのコントロールプレーンから直接Podを削除してください。 + +## {{% heading "whatsnext" %}} +* [Pod Disruption Budget](/docs/tasks/run-application/configure-pdb/)でアプリケーションを保護する方法について学ぶ +* [Node不足による退避](/docs/concepts/scheduling-eviction/node-pressure-eviction/)について学ぶ +* [Podの優先度とプリエンプション](/docs/concepts/scheduling-eviction/pod-priority-preemption/)について学ぶ diff --git a/content/ja/docs/concepts/workloads/pods/ephemeral-containers.md b/content/ja/docs/concepts/workloads/pods/ephemeral-containers.md index beb92b3b88..b99d193308 100644 --- a/content/ja/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/ja/docs/concepts/workloads/pods/ephemeral-containers.md @@ -42,7 +42,7 @@ weight: 80 エフェメラルコンテナを利用する場合には、他のコンテナ内のプロセスにアクセスできるように、[プロセス名前空間の共有](/ja/docs/tasks/configure-pod-container/share-process-namespace/)を有効にすると便利です。 -エフェメラルコンテナを利用してトラブルシューティングを行う例については、[デバッグ用のエフェメラルコンテナを使用してデバッグする](/docs/tasks/debug-application-cluster/debug-running-pod/#ephemeral-container)を参照してください。 +エフェメラルコンテナを利用してトラブルシューティングを行う例については、[デバッグ用のエフェメラルコンテナを使用してデバッグする](/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container)を参照してください。 ## Ephemeral containers API diff --git a/content/ja/docs/reference/glossary/api-eviction.md b/content/ja/docs/reference/glossary/api-eviction.md new file mode 100644 index 0000000000..25677032b9 --- /dev/null +++ b/content/ja/docs/reference/glossary/api-eviction.md @@ -0,0 +1,23 @@ +--- +title: APIを起点とした退避 +id: api-eviction +date: 2021-04-27 +full_link: /ja/docs/concepts/scheduling-eviction/api-eviction/ +short_description: > + APIを起点とした退避は、Eviction　APIを使用してEvictionオブジェクトを作成し、Podの正常終了を起動させるプロセスです。 +aka: +tags: +- operation +--- +APIを起点とした退避は、[Eviction API](/docs/reference/generated/kubernetes-api/{{}}/#create-eviction-pod-v1-core)を使用して退避オブジェクトを作成し、Podの正常終了を起動させるプロセスです。 + + + + +`kubectl drain`コマンドのようなkube-apiserverのクライアントを使用し、Eviction APIを直接呼び出すことで、退避を要求することができます。`Eviction`オブジェクトが生成された時、APIサーバーは対象のPodを終了させます。 + +APIを起点とした退避は[`PodDisruptionBudgets`](/docs/tasks/run-application/configure-pdb/)と[`terminationGracePeriodSeconds`](/ja/docs/concepts/workloads/pods/pod-lifecycle#pod-termination)の設定を優先します。 + +APIを起点とした退避は、[Node不足による退避](/docs/concepts/scheduling-eviction/eviction/#kubelet-eviction)とは異なります。 + +* 詳しくは[APIを起点とした退避](/ja/docs/concepts/scheduling-eviction/api-eviction/)をご覧ください。 diff --git a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index 08e48b9fa7..2ac539bf06 100644 --- a/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ja/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -51,7 +51,7 @@ Probeの動作としては、kubeletは`cat /tmp/healthy`を対象のコンテ このコンテナは、起動すると次のコマンドを実行します: ```shell -/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600" +/bin/sh -c "touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600" ``` コンテナが起動してから初めの30秒間は`/tmp/healthy`ファイルがコンテナ内に存在します。 diff --git a/content/ja/examples/pods/probe/exec-liveness.yaml b/content/ja/examples/pods/probe/exec-liveness.yaml index 07bf75f85c..6a9c9b3213 100644 --- a/content/ja/examples/pods/probe/exec-liveness.yaml +++ b/content/ja/examples/pods/probe/exec-liveness.yaml @@ -11,7 +11,7 @@ spec: args: - /bin/sh - -c - - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 + - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600 livenessProbe: exec: command: diff --git a/content/pt-br/docs/concepts/policy/_index.md b/content/pt-br/docs/concepts/policy/_index.md new file mode 100644 index 0000000000..1b5e70aa9b --- /dev/null +++ b/content/pt-br/docs/concepts/policy/_index.md @@ -0,0 +1,6 @@ +--- +title: "Políticas" +weight: 90 +description: > + Políticas que você pode configurar e que afetam grupos de recursos. +--- diff --git a/content/pt-br/docs/concepts/storage/_index.md b/content/pt-br/docs/concepts/storage/_index.md new file mode 100644 index 0000000000..41cfbb3507 --- /dev/null +++ b/content/pt-br/docs/concepts/storage/_index.md @@ -0,0 +1,8 @@ +--- +title: "Armazenamento" +weight: 70 +description: > + Formas de fornecer armazenamento temporário e de longa duração a Pods em seu + cluster. +--- + diff --git a/content/pt-br/docs/reference/glossary/applications.md b/content/pt-br/docs/reference/glossary/applications.md new file mode 100644 index 0000000000..a00ca0ec6c --- /dev/null +++ b/content/pt-br/docs/reference/glossary/applications.md @@ -0,0 +1,12 @@ +--- +title: Aplicações +id: applications +date: 2019-05-12 +full_link: +short_description: > + A camada onde vários aplicativos em contêiner são executados. +aka: +tags: +- fundamental +--- + A camada onde vários aplicativos em contêiner são executados. diff --git a/content/pt-br/docs/reference/glossary/certificate.md b/content/pt-br/docs/reference/glossary/certificate.md new file mode 100644 index 0000000000..d43ead1f32 --- /dev/null +++ b/content/pt-br/docs/reference/glossary/certificate.md @@ -0,0 +1,17 @@ +--- +title: Certificado +id: certificate +date: 2018-04-12 +full_link: /docs/tasks/tls/managing-tls-in-a-cluster/ +short_description: > + Um arquivo criptograficamente seguro usado para validar o acesso ao cluster Kubernetes. + +aka: +tags: +- security +--- + Um arquivo criptograficamente seguro usado para validar o acesso ao cluster Kubernetes. + + + +Os certificados permitem que aplicativos dentro de um cluster Kubernetes acessem a API do Kubernetes com segurança. Os certificados validam que os clientes têm permissão para acessar a API. \ No newline at end of file diff --git a/content/pt-br/docs/reference/glossary/cluster-architect.md b/content/pt-br/docs/reference/glossary/cluster-architect.md new file mode 100644 index 0000000000..3aeb95e084 --- /dev/null +++ b/content/pt-br/docs/reference/glossary/cluster-architect.md @@ -0,0 +1,17 @@ +--- +title: Arquiteto de Cluster +id: cluster-architect +date: 2018-04-12 +full_link: +short_description: > + Uma pessoa que projeta infraestrutura que envolve um ou mais clusters Kubernetes. + +aka: +tags: +- user-type +--- + Uma pessoa que projeta infraestrutura que envolve um ou mais clusters Kubernetes. + + + +Os arquitetos de clusters estão preocupados com as melhores práticas para sistemas distribuídos, por exemplo: alta disponibilidade e segurança. \ No newline at end of file diff --git a/content/pt-br/docs/reference/glossary/data-plane.md b/content/pt-br/docs/reference/glossary/data-plane.md new file mode 100644 index 0000000000..2e7c9946f9 --- /dev/null +++ b/content/pt-br/docs/reference/glossary/data-plane.md @@ -0,0 +1,13 @@ +--- +title: Plano de Dados +id: data-plane +date: 2019-05-12 +full_link: +short_description: > + A camada que fornece capacidade, tais como CPU, memória, rede e armazenamento, para que os contêineres possam ser executados e conectados a uma rede. + +aka: +tags: +- fundamental +--- + A camada que fornece capacidade, tais como CPU, memória, rede e armazenamento, para que os contêineres possam ser executados e conectados a uma rede. diff --git a/content/pt-br/docs/setup/production-environment/turnkey-solutions.md b/content/pt-br/docs/setup/production-environment/turnkey-solutions.md new file mode 100644 index 0000000000..d60a54a754 --- /dev/null +++ b/content/pt-br/docs/setup/production-environment/turnkey-solutions.md @@ -0,0 +1,12 @@ +--- +title: Soluções de Nuvem Prontas para uso +content_type: concept +weight: 30 +--- + + +Essa página fornece uma lista de provedores de soluções certificadas do Kubernetes. Na página de cada provedor, você pode aprender como instalar e configurar clusters prontos para produção. + + + +{{< cncf-landscape helpers=true category="certified-kubernetes-hosted" >}} diff --git a/content/ru/docs/contribute/advanced.md b/content/ru/docs/contribute/advanced.md index bb4ff9a35f..7ee4af13cf 100644 --- a/content/ru/docs/contribute/advanced.md +++ b/content/ru/docs/contribute/advanced.md @@ -63,7 +63,7 @@ weight: 30 {{< note >}} -Бот [`fejta-bot`](https://github.com/fejta-bot) автоматически помечает заявки как устаревшие после 90 дней отсутствия активности, а затем закрывает их после ещё 30 дней простоя, когда они становятся тухлыми. Дежурные по PR должны закрывать заявки после 14-30 дней бездействия. +Бот [`k8s-ci-robot`](https://github.com/k8s-ci-robot) автоматически помечает заявки как устаревшие после 90 дней отсутствия активности, а затем закрывает их после ещё 30 дней простоя, когда они становятся тухлыми. Дежурные по PR должны закрывать заявки после 14-30 дней бездействия. {{< /note >}} diff --git a/content/ru/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md b/content/ru/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md index c55819902a..fd99c78cd6 100644 --- a/content/ru/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md +++ b/content/ru/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes.md @@ -59,7 +59,7 @@ kubelet исполняет команду `cat /tmp/healthy` в целевом Когда контейнер запускается, он исполняет команду ```shell -/bin/sh -c "touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600" +/bin/sh -c "touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600" ``` Для первых 30 секунд жизни контейнера существует файл `/tmp/healthy`. diff --git a/content/ru/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html b/content/ru/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html index 502beb23bd..738d2b0bc6 100644 --- a/content/ru/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html +++ b/content/ru/docs/tutorials/kubernetes-basics/deploy-app/deploy-intro.html @@ -28,7 +28,7 @@ weight: 10

Развёртывания Kubernetes

-

Как только вы запустили кластер Kubernetes, вы можете развернуть свои контейнеризированные приложения в него. Для этого вам нужно создать конфигурацию развёртывания (Deployment) в Kubernetes. Развёртывание сообщает Kubernetes, как создавать и обновлять экземпляры вашего приложения. После создания развёртывания ведущий узел Kubernetes планирует запустить экземпляры приложения на отдельных узлах в кластере.

+

Как только вы запустили кластер Kubernetes, вы можете развернуть на нём свои контейнеризированные приложения. Для этого вам нужно создать конфигурацию развёртывания (Deployment) в Kubernetes. Развёртывание сообщает Kubernetes, как создавать и обновлять экземпляры вашего приложения. После создания развёртывания ведущий узел Kubernetes планирует запустить экземпляры приложения на отдельных узлах в кластере.

Когда экземпляры приложения были созданы, контроллер развёртывания Kubernetes непрерывно отслеживает их. Если узел, на котором размещен экземпляр, вышёл из строя или был удалён, контроллер развёртывания вместо этого экземпляра использует экземпляр на другом узле в кластере. Этот процесс представляет собой механизм самовосстановления, обеспечивающий работу кластера в случае возникновения аппаратных неисправностей либо технических работ. diff --git a/content/ru/examples/pods/probe/exec-liveness.yaml b/content/ru/examples/pods/probe/exec-liveness.yaml index 07bf75f85c..6a9c9b3213 100644 --- a/content/ru/examples/pods/probe/exec-liveness.yaml +++ b/content/ru/examples/pods/probe/exec-liveness.yaml @@ -11,7 +11,7 @@ spec: args: - /bin/sh - -c - - touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600 + - touch /tmp/healthy; sleep 30; rm -f /tmp/healthy; sleep 600 livenessProbe: exec: command: diff --git a/content/zh/blog/_posts/2016-02-00-Kubernetes-Community-Meeting-Notes.md b/content/zh/blog/_posts/2016-02-00-Kubernetes-Community-Meeting-Notes.md index a9e0f10e4e..7c6544d2ad 100644 --- a/content/zh/blog/_posts/2016-02-00-Kubernetes-Community-Meeting-Notes.md +++ b/content/zh/blog/_posts/2016-02-00-Kubernetes-Community-Meeting-Notes.md @@ -4,17 +4,15 @@ date: 2016-02-09 slug: kubernetes-community-meeting-notes --- -#### 2月4日 - rkt演示（祝贺 1.0 版本， CoreOS！）， eBay 将 k8s 放在 Openstack 上并认为 Openstack 在 k8s， SIG 和片状测试激增方面取得了进展。 +#### 2 月 4 日 - rkt 演示（祝贺 1.0 版本，CoreOS！），eBay 将 k8s 放在 Openstack 上并认为 Openstack 在 k8s，SIG 和片状测试激增方面取得了进展。 * 书记员：Rob Hirschfeld -* 演示视频（20分钟）：CoreOS rkt + Kubernetes[Shaya Potter] - * 期待在未来几个月内看到与rkt和k8s的整合（“rkt-netes”）。 还没有集成到 v1.2版本中。 +* 演示视频（20 分钟）：CoreOS rkt + Kubernetes [Shaya Potter] + * 期待在未来几个月内看到与rkt和k8s的整合（“rkt-netes”）。 还没有集成到 v1.2 版本中。 * Shaya 做了一个演示（8分钟的会议视频参考） - * rkt的CLI显示了旋转容器 + * rkt 的 CLI 显示了旋转容器 * [注意：音频在点数上是乱码] * 关于 k8s&rkt 整合的讨论 - * 下周 rkt 社区同步：https://groups.google.com/forum/#!topic/rkt-dev/FlwZVIEJGbY + * 下周 rkt 社区同步： https://groups.google.com/forum/#!topic/rkt-dev/FlwZVIEJGbY * Dawn Chen: * 将 rkt 与 kubernetes 集成的其余问题：1）cadivsor 2） DNS 3）与日志记录相关的错误 * 但是需要在 e2e 测试套件上做更多的工作 @@ -103,13 +101,16 @@ Kubernetes 贡献社区在每周四 10:00 PT 开会,通过视频会议讨论项 -要参与 Kubernetes 社区，请考虑加入我们的[Slack 频道][2]，查看 GitHub上的 [Kubernetes 项目][3]，或加入[Kubernetes-dev Google 小组][4]。如果你真的很兴奋，你可以完成上述所有工作并加入我们的下一次社区对话-2016年2月11日。请将您自己或您想要了解的主题添加到[议程][5]并通过加入[此组][6]来获取日历邀请。 +要参与 Kubernetes 社区，请考虑加入我们的 [Slack 频道][2]，查看 GitHub 上的 +[Kubernetes 项目][3]，或加入 [Kubernetes-dev Google 小组][4]。 +如果你真的很兴奋，你可以完成上述所有工作并加入我们的下一次社区对话 - 2016 年 2 月 11 日。 +请将你自己或你想要了解的主题添加到[议程][5]并通过加入[此组][6]来获取日历邀请。 "https://youtu.be/IScpP8Cj0hw?list=PL69nYSiGNLP1pkHsbPjzAewvMgGUpkCnJ" [1]: https://github.com/kubernetes/kubernetes/pull/19714 -[2]: http://slack.k8s.io/ +[2]: https://slack.k8s.io/ [3]: https://github.com/kubernetes/ [4]: https://groups.google.com/forum/#!forum/kubernetes-dev [5]: https://docs.google.com/document/d/1VQDIAB0OqiSjIHI8AWMvSdceWhnz56jNpZrLs6o7NJY/edit# diff --git a/content/zh/blog/_posts/2018-08-02-dynamically-expand-volume-csi.md b/content/zh/blog/_posts/2018-08-02-dynamically-expand-volume-csi.md index 755239e9eb..690935b5a0 100644 --- a/content/zh/blog/_posts/2018-08-02-dynamically-expand-volume-csi.md +++ b/content/zh/blog/_posts/2018-08-02-dynamically-expand-volume-csi.md @@ -5,11 +5,9 @@ date: 2018-08-02 --- -更多详细信息，请访问：https://github.com/container-storage-interface/spec/blob/master/spec.md +更多详细信息，请访问： https://github.com/container-storage-interface/spec/blob/master/spec.md -通过提供拓扑感知动态卷供应功能，具有持久卷的多区域集群体验在 Kubernetes 1.12 中得到了改进。此功能使得 Kubernetes 在动态供应卷时能做出明智的决策，方法是从调度器获得为 Pod 提供数据卷的最佳位置。在多区域集群环境，这意味着数据卷能够在满足你的 Pod 运行需要的合适的区域被供应，从而允许您跨故障域轻松部署和扩展有状态工作负载，从而提供高可用性和容错能力。 +通过提供拓扑感知动态卷供应功能，具有持久卷的多区域集群体验在 Kubernetes 1.12 +中得到了改进。此功能使得 Kubernetes 在动态供应卷时能做出明智的决策，方法是从调度器获得为 +Pod 提供数据卷的最佳位置。在多区域集群环境，这意味着数据卷能够在满足你的 Pod +运行需要的合适的区域被供应，从而允许你跨故障域轻松部署和扩展有状态工作负载，从而提供高可用性和容错能力。 -在此功能被提供之前，在多区域集群中使用区域化的持久磁盘（例如 AWS ElasticBlockStore，Azure Disk，GCE PersistentDisk）运行有状态工作负载存在许多挑战。动态供应独立于 Pod 调度处理，这意味着只要您创建了一个 PersistentVolumeClaim（PVC），一个卷就会被供应。这也意味着供应者不知道哪些 Pod 正在使用该卷，也不清楚任何可能影响调度的 Pod 约束。 +在此功能被提供之前，在多区域集群中使用区域化的持久磁盘（例如 AWS ElasticBlockStore、 +Azure Disk、GCE PersistentDisk）运行有状态工作负载存在许多挑战。动态供应独立于 Pod +调度处理，这意味着只要你创建了一个 PersistentVolumeClaim（PVC），一个卷就会被供应。 +这也意味着供应者不知道哪些 Pod 正在使用该卷，也不清楚任何可能影响调度的 Pod 约束。 * AWS EBS * Azure Disk -* GCE PD （包括 Regional PD） +* GCE PD（包括 Regional PD） * CSI（alpha） - 目前只有 GCE PD CSI 驱动实现了拓扑支持 虽然最初支持的插件集都是基于区域的，但我们设计此功能时遵循 Kubernetes 跨环境可移植性的原则。 拓扑规范是通用的，并使用类似于基于标签的规范，如 Pod nodeSelectors 和 nodeAffinity。 -该机制允许您定义自己的拓扑边界，例如内部部署集群中的机架，而无需修改调度程序以了解这些自定义拓扑。 +该机制允许你定义自己的拓扑边界，例如内部部署集群中的机架，而无需修改调度程序以了解这些自定义拓扑。 此外，拓扑信息是从 Pod 规范中抽象出来的，因此 Pod 不需要了解底层存储系统的拓扑特征。 -这意味着您可以在多个集群、环境和存储系统中使用相同的 Pod 规范。 +这意味着你可以在多个集群、环境和存储系统中使用相同的 Pod 规范。 -要启用此功能，您需要做的就是创建一个将 `volumeBindingMode` 设置为 `WaitForFirstConsumer` 的 StorageClass： +要启用此功能，你需要做的就是创建一个将 `volumeBindingMode` 设置为 `WaitForFirstConsumer` 的 StorageClass： ``` kind: StorageClass @@ -210,7 +214,7 @@ spec: -之后，您可以看到根据 Pod 设置的策略在区域中配置卷： +之后，你可以看到根据 Pod 设置的策略在区域中配置卷： ``` $ kubectl get pv -o=jsonpath='{range .items[*]}{.spec.claimRef.name}{"\t"}{.metadata.labels.failure\-domain\.beta\.kubernetes\.io/zone}{"\n"}{end}' @@ -228,12 +232,13 @@ logs-web-1 us-central1-a -有关拓扑感知动态供应功能的官方文档可在此处获取：https://kubernetes.io/docs/concepts/storage/storage-classes/#volume-binding-mode +有关拓扑感知动态供应功能的官方文档可在此处获取： +https://kubernetes.io/docs/concepts/storage/storage-classes/#volume-binding-mode -有关 CSI 驱动程序的文档，请访问：https://kubernetes-csi.github.io/docs/ +有关 CSI 驱动程序的文档，请访问： https://kubernetes-csi.github.io/docs/ -如果您对此功能有反馈意见或有兴趣参与设计和开发，请加入 [Kubernetes 存储特别兴趣小组](https://github.com/kubernetes/community/tree/master/sig-storage)（SIG）。我们正在快速成长，并始终欢迎新的贡献者。 +如果你对此功能有反馈意见或有兴趣参与设计和开发，请加入 +[Kubernetes 存储特别兴趣小组](https://github.com/kubernetes/community/tree/master/sig-storage)（SIG）。 +我们正在快速成长，并始终欢迎新的贡献者。 -特别感谢帮助推出此功能的所有贡献者，包括 Cheng Xing ([verult](https://github.com/verult))、Chuqiang Li ([lichuqiang](https://github.com/lichuqiang))、David Zhu ([davidz627](https://github.com/davidz627))、Deep Debroy ([ddebroy](https://github.com/ddebroy))、Jan Šafránek ([jsafrane](https://github.com/jsafrane))、Jordan Liggitt ([liggitt](https://github.com/liggitt))、Michelle Au ([msau42](https://github.com/msau42))、Pengfei Ni ([feiskyer](https://github.com/feiskyer))、Saad Ali ([saad-ali](https://github.com/saad-ali))、Tim Hockin ([thockin](https://github.com/thockin))，以及 Yecheng Fu ([cofyc](https://github.com/cofyc))。 +特别感谢帮助推出此功能的所有贡献者，包括 Cheng Xing ([verult](https://github.com/verult))、 +Chuqiang Li ([lichuqiang](https://github.com/lichuqiang))、David Zhu ([davidz627](https://github.com/davidz627))、 +Deep Debroy ([ddebroy](https://github.com/ddebroy))、Jan Šafránek ([jsafrane](https://github.com/jsafrane))、 +Jordan Liggitt ([liggitt](https://github.com/liggitt))、Michelle Au ([msau42](https://github.com/msau42))、 +Pengfei Ni ([feiskyer](https://github.com/feiskyer))、Saad Ali ([saad-ali](https://github.com/saad-ali))、 +Tim Hockin ([thockin](https://github.com/thockin))，以及 Yecheng Fu ([cofyc](https://github.com/cofyc))。 diff --git a/content/zh/blog/_posts/2020-03-25-kubernetes-1.18-release-announcement.md b/content/zh/blog/_posts/2020-03-25-kubernetes-1.18-release-announcement.md index b191daab33..b263469049 100644 --- a/content/zh/blog/_posts/2020-03-25-kubernetes-1.18-release-announcement.md +++ b/content/zh/blog/_posts/2020-03-25-kubernetes-1.18-release-announcement.md @@ -14,16 +14,21 @@ evergreen: true -我们很高兴宣布 Kubernetes 1.18 版本的交付，这是我们 2020 年的第一版！ Kubernetes 1.18 包含 38 个增强功能：15 项增强功能已转为稳定版，11 项增强功能处于 beta 阶段，12 项增强功能处于 alpha 阶段。 +我们很高兴宣布 Kubernetes 1.18 版本的交付，这是我们 2020 年的第一版！Kubernetes +1.18 包含 38 个增强功能：15 项增强功能已转为稳定版，11 项增强功能处于 beta +阶段，12 项增强功能处于 alpha 阶段。 -Kubernetes 1.18 是一个近乎 “完美” 的版本。 为了改善 beta 和稳定的特性，已进行了大量工作，以确保用户获得更好的体验。 我们在增强现有功能的同时也增加了令人兴奋的新特性，这些有望进一步增强用户体验。 +Kubernetes 1.18 是一个近乎 “完美” 的版本。为了改善 beta 和稳定的特性，已进行了大量工作， +以确保用户获得更好的体验。我们在增强现有功能的同时也增加了令人兴奋的新特性，这些有望进一步增强用户体验。 + -对 alpha，beta 和稳定版进行几乎同等程度的增强是一项伟大的成就。 它展现了社区在提高 Kubernetes 的可靠性以及继续扩展其现有功能方面所做的巨大努力。 +对 alpha、beta 和稳定版进行几乎同等程度的增强是一项伟大的成就。它展现了社区在提高 +Kubernetes 的可靠性以及继续扩展其现有功能方面所做的巨大努力。 -Kubernetes 在 1.18 版中的 Beta 阶段功能 [拓扑管理器特性](https://github.com/nolancon/website/blob/f4200307260ea3234540ef13ed80de325e1a7267/content/en/docs/tasks/administer-cluster/topology-manager.md) 启用 CPU 和设备（例如 SR-IOV VF）的 NUMA 对齐，这将使您的工作负载在针对低延迟而优化的环境中运行。在引入拓扑管理器之前，CPU 和设备管理器将做出彼此独立的资源分配决策。 这可能会导致在多处理器系统上非预期的资源分配结果，从而导致对延迟敏感的应用程序的性能下降。 +Kubernetes 在 1.18 版中的 Beta 阶段功能[拓扑管理器特性](https://github.com/nolancon/website/blob/f4200307260ea3234540ef13ed80de325e1a7267/content/en/docs/tasks/administer-cluster/topology-manager.md)启用 +CPU 和设备（例如 SR-IOV VF）的 NUMA 对齐，这将使你的工作负载在针对低延迟而优化的环境中运行。 +在引入拓扑管理器之前，CPU 和设备管理器将做出彼此独立的资源分配决策。 +这可能会导致在多处理器系统上非预期的资源分配结果，从而导致对延迟敏感的应用程序的性能下降。 -### Serverside Apply 推出Beta 2 +### Serverside Apply 推出 Beta 2 -Serverside Apply 在1.16 中进入 Beta 阶段，但现在在 1.18 中进入了第二个 Beta 阶段。 这个新版本将跟踪和管理所有新 Kubernetes 对象的字段更改，从而使您知道什么更改了资源以及何时发生了更改。 +Serverside Apply 在1.16 中进入 Beta 阶段，但现在在 1.18 中进入了第二个 Beta 阶段。 +这个新版本将跟踪和管理所有新 Kubernetes 对象的字段更改，从而使你知道什么更改了资源以及何时发生了更改。 -在 Kubernetes 1.18 中，Ingress 有两个重要的补充：一个新的 `pathType` 字段和一个新的 `IngressClass` 资源。`pathType` 字段允许指定路径的匹配方式。 除了默认的`ImplementationSpecific`类型外，还有新的 `Exact`和`Prefix` 路径类型。 +在 Kubernetes 1.18 中，Ingress 有两个重要的补充：一个新的 `pathType` 字段和一个新的 +`IngressClass` 资源。`pathType` 字段允许指定路径的匹配方式。除了默认的 +`ImplementationSpecific` 类型外，还有新的 `Exact` 和 `Prefix` 路径类型。 -`IngressClass` 资源用于描述 Kubernetes 集群中 Ingress 的类型。 Ingress 对象可以通过在Ingress 资源类型上使用新的`ingressClassName` 字段来指定与它们关联的类。 这个新的资源和字段替换了不再建议使用的 `kubernetes.io/ingress.class` 注解。 +`IngressClass` 资源用于描述 Kubernetes 集群中 Ingress 的类型。Ingress 对象可以通过在 +Ingress 资源类型上使用新的 `ingressClassName` 字段来指定与它们关联的类。 +这个新的资源和字段替换了不再建议使用的 `kubernetes.io/ingress.class` 注解。 -SIG-CLI 一直在争论着调试工具的必要性。随着 [临时容器](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/) 的发展，我们如何使用基于 `kubectl exec` 的工具来支持开发人员的必要性变得越来越明显。 [`kubectl alpha debug` 命令](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md) 的增加，（由于是 alpha 阶段，非常欢迎您反馈意见），使开发人员可以轻松地在集群中调试 Pod。我们认为这个功能的价值非常高。 此命令允许创建一个临时容器，该容器在要尝试检查的 Pod 旁边运行，并且还附加到控制台以进行交互式故障排除。 +SIG-CLI 一直在争论着调试工具的必要性。随着[临时容器](https://kubernetes.io/docs/concepts/workloads/pods/ephemeral-containers/)的发展， +我们如何使用基于 `kubectl exec` 的工具来支持开发人员的必要性变得越来越明显。 +[`kubectl alpha debug` 命令](https://github.com/kubernetes/enhancements/blob/master/keps/sig-cli/20190805-kubectl-debug.md)的增加， +（由于是 alpha 阶段，非常欢迎你反馈意见），使开发人员可以轻松地在集群中调试 Pod。 +我们认为这个功能的价值非常高。此命令允许创建一个临时容器，该容器在要尝试检查的 +Pod 旁边运行，并且还附加到控制台以进行交互式故障排除。 -用于 Windows 的 CSI 代理的 Alpha 版本随 Kubernetes 1.18 一起发布。 CSI 代理通过允许Windows 中的容器执行特权存储操作来启用 Windows 上的 CSI 驱动程序。 +用于 Windows 的 CSI 代理的 Alpha 版本随 Kubernetes 1.18 一起发布。CSI 代理通过允许 +Windows 中的容器执行特权存储操作来启用 Windows 上的 CSI 驱动程序。 -在我们的 [发布文档](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.18.md)中查看 Kubernetes 1.18 发行版的完整详细信息。 +在我们的[发布文档](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.18.md)中查看 +Kubernetes 1.18 发行版的完整详细信息。 -Kubernetes 1.18 可以在 [GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.18.0) 上下载。 要开始使用Kubernetes，请查看这些 [交互教程](https://kubernetes.io/docs/tutorials/) 或通过[kind](https://kind.sigs.k8s.io/) 使用 Docker 容器运行本地 kubernetes 集群。您还可以使用[kubeadm](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/)轻松安装 1.18。 +Kubernetes 1.18 可以在 [GitHub](https://github.com/kubernetes/kubernetes/releases/tag/v1.18.0) +上下载。要开始使用 Kubernetes，请查看这些[交互教程](https://kubernetes.io/docs/tutorials/)或通过 +[kind](https://kind.sigs.k8s.io/) 使用 Docker 容器运行本地 kubernetes 集群。你还可以使用 +[kubeadm](https://kubernetes.io/docs/setup/independent/create-cluster-kubeadm/) 轻松安装 1.18。 -通过数百位贡献了技术和非技术内容的个人的努力，使本次发行成为可能。 特别感谢由 Searchable AI 的网站可靠性工程师 Jorge Alarcon Ochoa 领导的[发布团队](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.18/release_team.md)。 34 位发布团队成员协调了发布的各个方面，从文档到测试、验证和功能完整性。 +通过数百位贡献了技术和非技术内容的个人的努力，使本次发行成为可能。 +特别感谢由 Searchable AI 的网站可靠性工程师 Jorge Alarcon Ochoa +领导的[发布团队](https://github.com/kubernetes/sig-release/blob/master/releases/release-1.18/release_team.md)。 +34 位发布团队成员协调了发布的各个方面，从文档到测试、验证和功能完整性。 -随着 Kubernetes 社区的发展壮大，我们的发布过程很好地展示了开源软件开发中的协作。 Kubernetes 继续快速获取新用户。 这种增长创造了一个积极的反馈回路，其中有更多的贡献者提交了代码，从而创建了更加活跃的生态系统。 迄今为止，Kubernetes 已有 [40,000 独立贡献者](https://k8s.devstats.cncf.io/d/24/overall-project-statistics?orgId=1) 和一个超过3000人的活跃社区。 +随着 Kubernetes 社区的发展壮大，我们的发布过程很好地展示了开源软件开发中的协作。 +Kubernetes 继续快速获取新用户。这种增长创造了一个积极的反馈回路， +其中有更多的贡献者提交了代码，从而创建了更加活跃的生态系统。迄今为止，Kubernetes 已有 +[40,000 独立贡献者](https://k8s.devstats.cncf.io/d/24/overall-project-statistics?orgId=1)和一个超过 3000 人的活跃社区。 -LHC 是世界上最大，功能最强大的粒子加速器。它是由来自世界各地成千上万科学家合作的结果，所有这些合作都是为了促进科学的发展。以类似的方式，Kubernetes 已经成为一个聚集了来自数百个组织的数千名贡献者–所有人都朝着在各个方面改善云计算的相同目标努力的项目！ 发布名称“ A Bit Quarky” 的意思是提醒我们，非常规的想法可以带来巨大的变化，对开放性保持开放态度将有助于我们进行创新。 +LHC 是世界上最大，功能最强大的粒子加速器。它是由来自世界各地成千上万科学家合作的结果， +所有这些合作都是为了促进科学的发展。以类似的方式，Kubernetes +已经成为一个聚集了来自数百个组织的数千名贡献者–所有人都朝着在各个方面改善云计算的相同目标努力的项目！ +发布名称 “A Bit Quarky” 的意思是提醒我们，非常规的想法可以带来巨大的变化，对开放性保持开放态度将有助于我们进行创新。 -Maru Lango 是目前居住在墨西哥城的设计师。她的专长是产品设计，她还喜欢使用 CSS + JS 进行品牌、插图和视觉实验，为技术和设计社区的多样性做贡献。您可能会在大多数社交媒体上以 @marulango 的身份找到她，或查看她的网站： https://marulango.com +Maru Lango 是目前居住在墨西哥城的设计师。她的专长是产品设计，她还喜欢使用 CSS + JS +进行品牌、插图和视觉实验，为技术和设计社区的多样性做贡献。你可能会在大多数社交媒体上以 +@marulango 的身份找到她，或查看她的网站： https://marulango.com -- 爱立信正在使用 Kubernetes 和其他云原生技术来交付[高标准的 5G 网络](https://www.cncf.io/case-study/ericsson/)，这可以在 CI/CD 上节省多达 90％ 的支出。 -- Zendesk 正在使用 Kubernetes [运行其现有应用程序的约 70％](https://www.cncf.io/case-study/zendesk/)。它还正在使所构建的所有新应用都可以在 Kubernetes 上运行，从而节省时间、提高灵活性并加快其应用程序开发的速度。 -- LifeMiles 因迁移到 Kubernetes 而[降低了 50% 的基础设施开支](https://www.cncf.io/case-study/lifemiles/)。Kubernetes 还使他们可以将其可用资源容量增加一倍。 +- 爱立信正在使用 Kubernetes 和其他云原生技术来交付[高标准的 5G 网络](https://www.cncf.io/case-study/ericsson/)， + 这可以在 CI/CD 上节省多达 90％ 的支出。 +- Zendesk 正在使用 Kubernetes [运行其现有应用程序的约 70％](https://www.cncf.io/case-study/zendesk/)。 + 它还正在使所构建的所有新应用都可以在 Kubernetes 上运行，从而节省时间、提高灵活性并加快其应用程序开发的速度。 +- LifeMiles 因迁移到 Kubernetes 而[降低了 50% 的基础设施开支](https://www.cncf.io/case-study/lifemiles/)。 + Kubernetes 还使他们可以将其可用资源容量增加一倍。 -- CNCF发布了[年度调查](https://www.cncf.io/blog/2020/03/04/2019-cncf-survey-results-are-here-deployments-are-growing-in-size-and-speed-as-cloud-native-adoption-becomes-mainstream/) 的结果，表明 Kubernetes 在生产中的使用正在飞速增长。调查发现，有78％的受访者在生产中使用Kubernetes，而去年这一比例为 58％。 -- CNCF 举办的 “Kubernetes入门” 课程有[超过 100,000 人注册](https://www.cncf.io/announcement/2020/01/28/cloud-native-computing-foundation-announces-introduction-to-kubernetes-course-surpasses-100000-registrations/)。 +- CNCF 发布了[年度调查](https://www.cncf.io/blog/2020/03/04/2019-cncf-survey-results-are-here-deployments-are-growing-in-size-and-speed-as-cloud-native-adoption-becomes-mainstream/)的结果， + 表明 Kubernetes 在生产中的使用正在飞速增长。调查发现，有 78％ 的受访者在生产中使用 Kubernetes，而去年这一比例为 58％。 +- CNCF 举办的 “Kubernetes 入门” 课程有[超过 100,000 人注册](https://www.cncf.io/announcement/2020/01/28/cloud-native-computing-foundation-announces-introduction-to-kubernetes-course-surpasses-100000-registrations/)。 -CNCF 继续完善 DevStats。这是一个雄心勃勃的项目，旨在对项目中的无数贡献数据进行可视化展示。[K8s DevStats](https://k8s.devstats.cncf.io/d/12/dashboards?orgId=1) 展示了主要公司贡献者的贡献细目，以及一系列令人印象深刻的预定义的报告，涉及从贡献者个人的各方面到 PR 生命周期的各个方面。 +CNCF 继续完善 DevStats。这是一个雄心勃勃的项目，旨在对项目中的无数贡献数据进行可视化展示。 +[K8s DevStats](https://k8s.devstats.cncf.io/d/12/dashboards?orgId=1) 展示了主要公司贡献者的贡献细目， +以及一系列令人印象深刻的预定义的报告，涉及从贡献者个人的各方面到 PR 生命周期的各个方面。 -在过去的一个季度中，641 家不同的公司和超过 6,409 个个人为 Kubernetes 作出贡献。 [查看 DevStats](https://k8s.devstats.cncf.io/d/11/companies-contributing-in-repository-groups?orgId=1&var-period=m&var-repogroup_name=All) 以了解有关 Kubernetes 项目和社区发展速度的信息。 +在过去的一个季度中，641 家不同的公司和超过 6,409 个个人为 Kubernetes 作出贡献。 +[查看 DevStats](https://k8s.devstats.cncf.io/d/11/companies-contributing-in-repository-groups?orgId=1&var-period=m&var-repogroup_name=All) +以了解有关 Kubernetes 项目和社区发展速度的信息。 -Kubecon + CloudNativeCon EU 2020 已经推迟 - 有关最新信息，请查看[新型肺炎发布页面](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/attend/novel-coronavirus-update/)。 +Kubecon + CloudNativeCon EU 2020 已经推迟 - 有关最新信息， +请查看[新型肺炎发布页面](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/attend/novel-coronavirus-update/)。 -在 2020 年 4 月 23 日，和 Kubernetes 1.18 版本团队一起了解此版本的主要功能，包括 kubectl debug、拓扑管理器、Ingress 毕业为 V1 版本以及 client-go。 在此处注册：https://www.cncf.io/webinars/kubernetes-1-18/ 。 +在 2020 年 4 月 23 日，和 Kubernetes 1.18 版本团队一起了解此版本的主要功能， +包括 kubectl debug、拓扑管理器、Ingress 毕业为 V1 版本以及 client-go。 +在此处注册： https://www.cncf.io/webinars/kubernetes-1-18/ 。 -参与 Kubernetes 的最简单方法是加入众多与您的兴趣相关的 [特别兴趣小组](https://github.com/kubernetes/community/blob/master/sig-list.md) (SIGs) 之一。 您有什么想向 Kubernetes 社区发布的内容吗？ 参与我们的每周 [社区会议](https://github.com/kubernetes/community/tree/master/communication)，并通过以下渠道分享您的声音。 感谢您一直以来的反馈和支持。 +参与 Kubernetes 的最简单方法是加入众多与你的兴趣相关的[特别兴趣小组](https://github.com/kubernetes/community/blob/master/sig-list.md)（SIGs）之一。 +你有什么想向 Kubernetes 社区发布的内容吗？参与我们的每周[社区会议](https://github.com/kubernetes/community/tree/master/communication)， +并通过以下渠道分享你的声音。感谢你一直以来的反馈和支持。 Dockershim 向来都是一个临时解决方案（因此得名：shim）。 你可以进一步阅读 -[移除 Kubernetes 增强方案 Dockershim][drkep] +[移除 Dockershim 这一 Kubernetes 增强方案][drkep] 以了解相关的社区讨论和计划。 +### 从 Kubernetes 中移除后我还能使用 dockershim 吗？ {#can-i-still-use-dockershim-after-it-is-removed-from-kubernetes} + + +更新：Mirantis 和 Docker [已承诺][mirantis]在 dockershim 从 Kubernetes +中删除后对其进行维护。 + +[mirantis]: https://www.mirantis.com/blog/mirantis-to-take-over-support-of-kubernetes-dockershim-2/ + + @@ -163,11 +178,11 @@ related projects follow a similar pattern as well, demonstrating the stability a usability of other container runtimes. As an example, OpenShift 4.x has been using the [CRI-O] runtime in production since June 2019. --> -此外，[kind](https://kind.sigs.k8s.io/) 项目使用 containerd 已经有年头了， +此外，[kind] 项目使用 containerd 已经有年头了， 并且在这个场景中，稳定性还明显得到提升。 Kind 和 containerd 每天都会做多次协调，以验证对 Kubernetes 代码库的所有更改。 其他相关项目也遵循同样的模式，从而展示了其他容器运行时的稳定性和可用性。 -例如，OpenShift 4.x 从 2019 年 6 月以来，就一直在生产环境中使用 [CRI-O](https://cri-o.io/) 运行时。 +例如，OpenShift 4.x 从 2019 年 6 月以来，就一直在生产环境中使用 [CRI-O] 运行时。 @@ -300,7 +320,7 @@ Kubernetes documentation on [Container Runtimes] -### 我还有问题怎么办？{#what-if-I-have-more-question} +### 我还有问题怎么办？{#what-if-I-have-more-questions} 如果你使用了一个有供应商支持的 Kubernetes 发行版，你可以咨询供应商他们产品的升级计划。 -对于最终用户的问题，请把问题发到我们的最终用户社区的论坛：https://discuss.kubernetes.io/。 +对于最终用户的问题，请把问题发到我们的最终用户社区的[论坛](https://discuss.kubernetes.io/)。 -**本文是针对2020年末发布的[弃用 Dockershim 的常见问题](/zh/blog/2020/12/02/dockershim-faq/)的博客更新。** +**本文是针对 2020 年末发布的[弃用 Dockershim 的常见问题](/zh/blog/2020/12/02/dockershim-faq/)的博客更新。 +本文包括 Kubernetes v1.24 版本的更新。** + +--- +本文介绍了一些关于从 Kubernetes 中移除 _dockershim_ 的常见问题。 +该移除最初是作为 Kubernetes v1.20 +版本的一部分[宣布](/zh/blog/2020/12/08/kubernetes-1-20-release-announcement/)的。 +Kubernetes 在 [v1.24 版](/releases/#release-v1-24)移除了 dockershim。 + + -本文回顾了自 Kubernetes v1.20 版本[宣布](/zh/blog/2020/12/08/kubernetes-1-20-release-announcement/)弃用 -Dockershim 以来所引发的一些常见问题。关于弃用细节以及这些细节背后的含义，请参考博文 +关于细节请参考博文 [别慌: Kubernetes 和 Docker](/zh/blog/2020/12/02/dont-panic-kubernetes-and-docker/)。 -你还可以查阅：[检查弃用 Dockershim 对你的影响](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/)这篇文章， -以确定弃用 dockershim 会对你或你的组织带来多大的影响。 +要确定移除 dockershim 是否会对你或你的组织的影响，可以查阅： +[检查弃用 Dockershim 对你的影响](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/) +这篇文章。 -随着 Kubernetes 1.24 版本的发布迫在眉睫，我们一直在努力尝试使其能够平稳升级顺利过渡。 +在 Kubernetes 1.24 发布之前的几个月和几天里，Kubernetes +贡献者努力试图让这个过渡顺利进行。 -- 我们已经写了一篇博文，详细说明了我们的[承诺和后续操作](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/)。 -- 我们我们相信可以无障碍的迁移到其他[容器运行时](/zh/docs/setup/production-environment/container-runtimes/#container-runtimes)。 -- 我们撰写了 [dockershim 迁移指南](/docs/tasks/administer-cluster/migrating-from-dockershim/)供你参考。 -- 我们还创建了一个页面来列出[有关 dockershim 移除和使用 CRI 兼容运行时的文章](/zh/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/)。 +- 一篇详细说明[承诺和后续操作](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/)的博文。 +- 检查是否存在迁移到其他 [容器运行时](/zh/docs/setup/production-environment/container-runtimes/#container-runtimes) 的主要障碍。 +- 添加 [从 dockershim 迁移](/docs/tasks/administer-cluster/migrating-from-dockershim/)的指南。 +- 创建了一个[有关 dockershim 移除和使用 CRI 兼容运行时的列表](/zh/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/)。 该列表包括一些已经提到的文档，还涵盖了选定的外部资源（包括供应商指南）。 -### 为什么会从 Kubernetes 中移除 dockershim ？ +### 为什么会从 Kubernetes 中移除 dockershim ？ {#why-was-the-dockershim-removed-from-kubernetes} 此外，在较新的 CRI 运行时中实现了与 dockershim 不兼容的功能，例如 cgroups v2 和用户命名空间。 -取消对 dockershim 的支持将加速这些领域的发展。 +从 Kubernetes 中移除 dockershim 允许在这些领域进行进一步的开发。 + + +### Docker 和容器一样吗？ {#are-docker-and-containers-the-same-thing} + + +Docker 普及了 Linux 容器模式，并在开发底层技术方面发挥了重要作用，但是 Linux +中的容器已经存在了很长时间，容器生态系统已经发展到比 Docker 广泛得多。 +OCI 和 CRI 等标准帮助许多工具在我们的生态系统中发展壮大，其中一些替代了 Docker +的某些方面，而另一些则增强了现有功能。 + + +### 我现有的容器镜像是否仍然有效？ {#will-my-existing-container-images-still-work} + + +是的，从 `docker build` 生成的镜像将适用于所有 CRI 实现， +现有的所有镜像仍将完全相同。 + + +#### 私有镜像呢？ {#what-about-private-images} + + +当然可以，所有 CRI 运行时都支持在 Kubernetes 中使用的相同的 pull secrets +配置，无论是通过 PodSpec 还是 ServiceAccount。 -### 在 Kubernetes 1.23 版本中还可以使用 Docker Engine 吗？ +### 在 Kubernetes 1.23 版本中还可以使用 Docker Engine 吗？ {#can-i-still-use-docker-engine-in-kubernetes-1-23} 可以使用，在 1.20 版本中唯一的改动是，如果使用 Docker Engine， 在 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 启动时会打印一个警告日志。 -你将在 1.23 版本及以前版本看到此警告。dockershim 将在 Kubernetes 1.24 版本中移除 。 +你将在 1.23 版本及以前版本看到此警告，dockershim 已在 Kubernetes 1.24 版本中移除 。 -### 什么时候移除 dockershim ？ +如果你运行的是 Kubernetes v1.24 或更高版本，请参阅 +[我仍然可以使用 Docker Engine 作为我的容器运行时吗？](#can-i-still-use-docker-engine-as-my-container-runtime) +（如果你使用任何支持 dockershim 的版本，可以随时切换离开；从版本 v1.24 +开始，因为 Kubernetes 不再包含 dockershim，你**必须**切换）。 -考虑到此变更带来的影响，我们使用了一个加长的废弃时间表。 -dockershim 计划在 Kubernetes v1.24 中进行移除， -参见 [Kubernetes 移除 Dockershim 增强方案](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2221-remove-dockershim)。 -Kubernetes 项目将与供应商和其他生态系统组织密切合作，以确保平稳过渡，并将依据事态的发展评估后续事项。 +### 我应该用哪个 CRI 实现？ {#which-cri-implementation-should-i-use} -### 我还可以使用 Docker Engine 作为我的容器运行时吗？ +这是一个复杂的问题，依赖于许多因素。 +如果你正在使用 Docker Engine，迁移到 containerd +应该是一个相对容易地转换，并将获得更好的性能和更少的开销。 +然而，我们鼓励你探索 [CNCF landscape] 提供的所有选项，做出更适合你的选择。 + +[CNCF landscape]: https://landscape.cncf.io/card-mode?category=container-runtime&grouping=category + + +#### 我还可以使用 Docker Engine 作为我的容器运行时吗？ {#can-i-still-use-docker-engine-as-my-container-runtime} -### 我现有的容器镜像还能正常工作吗？ +你可以安装 `cri-dockerd` 并使用它将 kubelet 连接到 Docker Engine。 +阅读[将 Docker Engine 节点从 dockershim 迁移到 cri-dockerd](/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd/) +以了解更多信息。 - -当然可以，`docker build` 创建的镜像适用于任何 CRI 实现。 -所有你的现有镜像将和往常一样工作。 - - -### 私有镜像呢？ - - -当然可以。所有 CRI 运行时均支持在 Kubernetes 中相同的拉取（pull）Secret 配置， -无论是通过 PodSpec 还是 ServiceAccount。 - - -### Docker 和容器是一回事吗？ - - -Docker 普及了 Linux 容器模式，并在开发底层技术方面发挥了重要作用， -但是 Linux 中的容器已经存在了很长时间。容器的生态相比于 Docker 具有更宽广的领域。 -OCI 和 CRI 等标准帮助许多工具在我们的生态系统中发展壮大， -其中一些替代了 Docker 的某些方面，而另一些则增强了现有功能。 -### 现在是否有在生产系统中使用其他运行时的例子？ +### 现在是否有在生产系统中使用其他运行时的例子？ {#are-there-examples-of-folks-using-other-runtimes-in-production-today} -### 人们总在谈论 OCI，它是什么？ +### 人们总在谈论 OCI，它是什么？ {#people-keep-referencing-oci-what-is-that} -### 我应该用哪个 CRI 实现？ - - -这是一个复杂的问题，依赖于许多因素。 -如果你正在使用 Docker，迁移到 containerd 应该是一个相对容易地转换，并将获得更好的性能和更少的开销。 -然而，我们鼓励你探索 [CNCF landscape](https://landscape.cncf.io/card-mode?category=container-runtime&grouping=category) -提供的所有选项，做出更适合你的选择。 -### 当切换 CRI 实现时，应该注意什么？ +### 当切换 CRI 实现时，应该注意什么？ {#what-should-i-look-out-for-when-changing-cri-implementations} - 日志配置 - 运行时的资源限制 -- 调用 docker 或通过其控制套接字使用 docker 的节点配置脚本 -- 需要访问 docker 命令或控制套接字的 kubectl 插件 +- 调用 docker 或通过其控制套接字使用 Docker Engine 的节点配置脚本 +- 需要 `docker` 命令或 Docker Engine 控制套接字的 `kubectl` 插件 - 需要直接访问 Docker Engine 的 Kubernetes 工具（例如：已弃用的 'kube-imagepuller' 工具） - `registry-mirrors` 和不安全注册表等功能的配置 - 保障 Docker Engine 可用、且运行在 Kubernetes 之外的脚本或守护进程（例如：监视或安全代理） @@ -304,7 +324,7 @@ common things to consider when migrating are: @@ -314,8 +334,9 @@ runtime where possible. 另外还有一个需要关注的点，那就是当创建镜像时，系统维护或嵌入容器方面的任务将无法工作。 @@ -345,15 +366,15 @@ Kubernetes documentation on [Container Runtimes]. -### 我还有其他问题怎么办？ +### 我还有其他问题怎么办？ {#what-if-i-have-more-questions} 如果你使用了供应商支持的 Kubernetes 发行版，你可以咨询供应商他们产品的升级计划。 -对于最终用户的问题，请把问题发到我们的最终用户社区的论坛：https://discuss.kubernetes.io/。 +对于最终用户的问题，请把问题发到我们的最终用户社区的[论坛](https://discuss.kubernetes.io/)。 -### 是否有任何工具可以帮助我找到正在使用的 dockershim +### 是否有任何工具可以帮助我找到正在使用的 dockershim？ {#is-there-any-tooling-that-can-help-me-find-dockershim-in-use} 是的！ [Docker Socket 检测器 (DDS)][dds] 是一个 kubectl 插件， 你可以安装它用于检查你的集群。 DDS 可以检测运行中的 Kubernetes -工作负载是否将 Docker 引擎套接字 (`docker.sock`) 作为卷挂载。 +工作负载是否将 Docker Engine 套接字 (`docker.sock`) 作为卷挂载。 在 DDS 项目的 [README][dds] 中查找更多详细信息和使用方法。 [dds]: https://github.com/aws-containers/kubectl-detector-for-docker-socket @@ -391,7 +412,7 @@ Find more details and usage patterns in the DDS project's [README][dds]. -### 我可以加入吗？ +### 我可以加入吗？ {#can-i-have-a-hug} + + +**作者:** Kat Cosgrove + + + +早在 2020 年 12 月，Kubernetes 就宣布[弃用 Dockershim](/zh/blog/2020/12/02/dont-panic-kubernetes-and-docker/)。 +在 Kubernetes 中，dockershim 是一个软件 shim， +它允许你将整个 Docker 引擎用作 Kubernetes 中的容器运行时。 +在即将发布的 v1.24 版本中，我们将移除 Dockershim - +在宣布弃用之后到彻底移除这段时间内，我们至少预留了一年的时间继续支持此功能， +这符合相关的[项目策略](/zh/docs/reference/using-api/deprecation-policy/)。 +如果你是集群操作员，则该指南包含你在此版本中需要了解的实际情况。 +另外还包括你需要做些什么来确保你的集群不会崩溃！ + + +## 首先，这对你有影响吗？ + + +如果你正在管理自己的集群或不确定此删除是否会影响到你， +请保持安全状态并[检查你对 Docker Engine 是否有依赖](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/)。 +请注意，使用 Docker Desktop 构建应用程序容器并不算是集群对 Docker 有依赖。 +Docker 创建的容器镜像符合 [Open Container Initiative (OCI)](https://opencontainers.org/) 规范， +而 OCI 是 Linux 基金会的一种治理架构，负责围绕容器格式和运行时定义行业标准。 +这些镜像可以在 Kubernetes 支持的任何容器运行时上正常工作。 + + +如果你使用的是云服务提供商管理的 Kubernetes 服务， +并且你确定没有更改过容器运行时，那么你可能不需要做任何事情。 +Amazon EKS、Azure AKS 和 Google GKE 现在都默认使用 containerd， +但如果你的集群中有任何自定义的节点，你要确保它们不需要被更新。 +要检查节点的运行时，请参考[查明节点上所使用的容器运行时](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/)。 + + +无论你是在管理自己的集群还是使用云服务提供商管理的 Kubernetes 服务， +你可能都需要[迁移依赖 Docker Engine 的遥测或安全代理](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/)。 + + +## 我对 Docker 有依赖。现在该怎么办？ + + +如果你的 Kubernetes 集群对 Docker Engine 有依赖， +并且你打算升级到 Kubernetes v1.24 版本（出于安全和类似原因，你最终应该这样做）， +你需要将容器运行时从 Docker Engine 更改为其他方式或使用 [cri-dockerd](https://github.com/Mirantis/cri-dockerd)。 +由于 [containerd](https://containerd.io/) 是一个已经毕业的 CNCF 项目， +并且是 Docker 本身的运行时，因此用它作为容器运行时的替代方式是一个安全的选择。 +幸运的是，Kubernetes 项目已经以 containerd 为例， +提供了[更改节点容器运行时](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/)的过程文档。 +切换到其它支持的运行时的操作指令与此类似。 + + +## 我想升级 Kubernetes，并且我需要保持与 Docker 作为运行时的兼容性。我有哪些选择？ + + +别担心，你不会被冷落，也不必冒着安全风险继续使用旧版本的 Kubernetes。 +Mirantis 和 Docker 已经联合发布并正在维护 dockershim 的替代品。 +这种替代品称为 [cri-dockerd](https://github.com/Mirantis/cri-dockerd)。 +如果你确实需要保持与 Docker 作为运行时的兼容性，请按照项目文档中的说明安装 cri-dockerd。 + + +## 这样就可以了吗？ + + + +是的。只要你深入了解此版本所做的变更和你自己集群的详细信息， +并确保与你的开发团队进行清晰的沟通，它的不确定性就会降到最低。 +你可能需要对集群、应用程序代码或脚本进行一些更改，但所有这些要求都已经有说明指导。 +从使用 Docker Engine 作为运行时，切换到使用[其他任何一种支持的容器运行时](/zh/docs/setup/production-environment/container-runtimes/)， +这意味着移除了中间层的组件，因为 dockershim 的作用是访问 Docker 本身使用的容器运行时。 +从实际角度长远来看，这种移除对你和 Kubernetes 维护者都更有好处。 + + +如果你仍有疑问，请先查看[弃用 Dockershim 的常见问题](/zh/blog/2022/02/17/dockershim-faq/)。 diff --git a/content/zh/blog/_posts/2022-05-18-prevent-unauthorised-volume-mode-conversion.md b/content/zh/blog/_posts/2022-05-18-prevent-unauthorised-volume-mode-conversion.md new file mode 100644 index 0000000000..15e86f5e5d --- /dev/null +++ b/content/zh/blog/_posts/2022-05-18-prevent-unauthorised-volume-mode-conversion.md @@ -0,0 +1,203 @@ +--- +layout: blog +title: 'Kubernetes 1.24: 防止未经授权的卷模式转换' +date: 2022-05-18 +slug: prevent-unauthorised-volume-mode-conversion-alpha +--- + + + + +**作者：** Raunak Pradip Shah (Mirantis) + + +Kubernetes v1.24 引入了一个新的 alpha 级特性，可以防止未经授权的用户修改基于 Kubernetes +集群中已有的 [`VolumeSnapshot`](/zh/docs/concepts/storage/volume-snapshots/) +创建的 [`PersistentVolumeClaim`](/zh/docs/concepts/storage/persistent-volumes/) 的卷模式。 + + +### 问题 + + +[卷模式](/zh/docs/concepts/storage/persistent-volumes/#volume-mode)确定卷是格式化为文件系统还是显示为原始块设备。 + + +用户可以使用自 Kubernetes v1.20 以来就稳定的 `VolumeSnapshot` 功能， +基于 Kubernetes 集群中的已有的 `VolumeSnapshot` 创建一个 `PersistentVolumeClaim` (简称 PVC )。 +PVC 规约包括一个 `dataSource` 字段，它可以指向一个已有的 `VolumeSnapshot` 实例。 +查阅[基于卷快照创建 PVC](/zh/docs/concepts/storage/persistent-volumes/#create-persistent-volume-claim-from-volume-snapshot) +获取更多详细信息。 + + +当使用上述功能时，没有逻辑来验证快照所在的原始卷的模式是否与新创建的卷的模式匹配。 + + +这引起了一个安全漏洞，允许恶意用户潜在地利用主机操作系统中的未知漏洞。 + + +为了提高效率，许多流行的存储备份供应商在备份操作过程中转换卷模式， +这使得 Kubernetes 无法完全阻止该操作，并在区分受信任用户和恶意用户方面带来挑战。 + + +### 防止未经授权的用户转换卷模式 + + +在这种情况下，授权用户是指有权对 `VolumeSnapshotContents`（集群级资源）执行 `Update` +或 `Patch` 操作的用户。集群管理员只能向受信任的用户或应用程序（如备份供应商）提供这些权限。 + + +如果在 `snapshot-controller`、`snapshot-validation-webhook` 和 +`external-provisioner` 中[启用](https://kubernetes-csi.github.io/docs/)了这个 alpha +特性，则基于 `VolumeSnapshot` 创建 PVC 时，将不允许未经授权的用户修改其卷模式。 + + +如要转换卷模式，授权用户必须执行以下操作： + + +1. 确定要用作给定命名空间中新创建 PVC 的数据源的 `VolumeSnapshot`。 +2. 确定绑定到上面 `VolumeSnapshot` 的 `VolumeSnapshotContent`。 + + ``` + kubectl get volumesnapshot -n + ``` + +3. 给 `VolumeSnapshotContent` 添加 + [`snapshot.storage.kubernetes.io/allowVolumeModeChange`](/zh/docs/reference/labels-annotations-taints/#snapshot-storage-kubernetes-io-allowvolumemodechange) + 注解。 + + +4. 此注解可通过软件添加或由授权用户手动添加。`VolumeSnapshotContent` 注解必须类似于以下清单片段： + + ```yaml + kind: VolumeSnapshotContent + metadata: + annotations: + - snapshot.storage.kubernetes.io/allowVolumeModeChange: "true" + ... + ``` + +**注意**：对于预先制备的 `VolumeSnapshotContents`，你必须采取额外的步骤设置 `spec.sourceVolumeMode` +字段为 `Filesystem` 或 `Block`，这取决于快照所在卷的模式。 + + +如下为一个示例： + +```yaml + apiVersion: snapshot.storage.k8s.io/v1 + kind: VolumeSnapshotContent + metadata: + annotations: + - snapshot.storage.kubernetes.io/allowVolumeModeChange: "true" + name: new-snapshot-content-test + spec: + deletionPolicy: Delete + driver: hostpath.csi.k8s.io + source: + snapshotHandle: 7bdd0de3-aaeb-11e8-9aae-0242ac110002 + sourceVolumeMode: Filesystem + volumeSnapshotRef: + name: new-snapshot-test + namespace: default +``` + + +对于在备份或恢复操作期间需要转换卷模式的所有 `VolumeSnapshotContents`，重复步骤 1 到 3。 + + +如果 `VolumeSnapshotContent` 对象上存在上面步骤 4 中显示的注解，Kubernetes 将不会阻止转换卷模式。 +用户在尝试将注解添加到任何 `VolumeSnapshotContent` 之前，应该记住这一点。 + + +### 接下来 + + +[启用此特性](https://kubernetes-csi.github.io/docs/)并让我们知道你的想法! + + +我们希望此功能不会中断现有工作流程，同时防止恶意用户利用集群中的安全漏洞。 + + +若有任何问题，请在 #sig-storage slack 频道中创建一个会话， +或在 CSI 外部快照存储[仓库](https://github.com/kubernetes-csi/external-snapshotter)中报告一个 issue。 \ No newline at end of file diff --git a/content/zh/blog/_posts/2022-05-23-service-ip-dynamic-and-static-allocation.md b/content/zh/blog/_posts/2022-05-23-service-ip-dynamic-and-static-allocation.md new file mode 100644 index 0000000000..fccad6cc3d --- /dev/null +++ b/content/zh/blog/_posts/2022-05-23-service-ip-dynamic-and-static-allocation.md @@ -0,0 +1,268 @@ +--- +layout: blog +title: "Kubernetes 1.24: 避免为 Services 分配 IP 地址时发生冲突" +date: 2022-05-23 +slug: service-ip-dynamic-and-static-allocation +--- + + + +**作者：** Antonio Ojea (Red Hat) + + +在 Kubernetes 中，[Services](/zh/docs/concepts/services-networking/service/) +是一种抽象，用来暴露运行在一组 Pod 上的应用。 +Service 可以有一个集群范围的虚拟 IP 地址（使用 `type: ClusterIP` 的 Service）。 +客户端可以使用该虚拟 IP 地址进行连接， Kubernetes 为对该 Service 的访问流量提供负载均衡，以访问不同的后端 Pod。 + + +## Service ClusterIP 是如何分配的？ + + +Service `ClusterIP` 有如下分配方式： + + +**动态** +：群集的控制平面会自动从配置的 IP 范围内为 `type:ClusterIP` 的 Service 选择一个空闲 IP 地址。 + + +**静态** +：你可以指定一个来自 Service 配置的 IP 范围内的 IP 地址。 + + +在整个集群中，每个 Service 的 `ClusterIP` 必须是唯一的。 +尝试创建一个已经被分配了的 `ClusterIP` 的 Service 将会返回错误。 + + +## 为什么需要预留 Service Cluster IP？ + + +有时，你可能希望让 Service 运行在众所周知的 IP 地址上，以便集群中的其他组件和用户可以使用它们。 + + +最好的例子是集群的 DNS Service。一些 Kubernetes 安装程序将 Service IP 范围中的第 10 个地址分配给 DNS Service。 +假设你配置集群 Service IP 范围是 10.96.0.0/16，并且希望 DNS Service IP 为 10.96.0.10， +那么你必须创建一个如下所示的 Service： + +```yaml +apiVersion: v1 +kind: Service +metadata: + labels: + k8s-app: kube-dns + kubernetes.io/cluster-service: "true" + kubernetes.io/name: CoreDNS + name: kube-dns + namespace: kube-system +spec: + clusterIP: 10.96.0.10 + ports: + - name: dns + port: 53 + protocol: UDP + targetPort: 53 + - name: dns-tcp + port: 53 + protocol: TCP + targetPort: 53 + selector: + k8s-app: kube-dns + type: ClusterIP +``` + + +但正如我之前解释的，IP 地址 10.96.0.10 没有被保留； +如果其他 Service 在动态分配之前创建或与动态分配并行创建，则它们有可能分配此 IP 地址， +因此，你将无法创建 DNS Service，因为它将因冲突错误而失败。 + + +## 如何避免 Service ClusterIP 冲突？ {#avoid-ClusterIP-conflict} + + +在 Kubernetes 1.24 中，你可以启用一个新的特性门控 `ServiceIPStaticSubrange`。 +启用此特性允许你为 Service 使用不同的 IP 分配策略，减少冲突的风险。 + + +`ClusterIP` 范围将根据公式 `min(max(16, cidrSize / 16), 256)` 进行划分， +该公式可描述为 “在不小于 16 且不大于 256 之间有一个步进量（Graduated Step）”。 + + +分配默认使用上半段地址，当上半段地址耗尽后，将使用下半段地址范围。 +这将允许用户使用下半段地址中静态分配的地址并且降低冲突的风险。 + + +举例： + + +#### Service IP CIDR 地址段： 10.96.0.0/24 + + +地址段大小：28 - 2 = 254 +地址段偏移：`min(max(16,256/16),256)` = `min(16,256)` = 16 +静态地址段起点：10.96.0.1 +静态地址段终点：10.96.0.16 +地址范围终点：10.96.0.254 + + +{{< mermaid >}} +pie showData +title 10.96.0.0/24 +"静态" : 16 +"动态" : 238 +{{< /mermaid >}} + + +#### Service IP CIDR 地址段： 10.96.0.0/20 + + +地址段大小：212 - 2 = 4094 +地址段偏移：`min(max(16,4094/16),256)` = `min(256,256)` = 256 +静态地址段起点：10.96.0.1 +静态地址段终点：10.96.1.0 +地址范围终点：10.96.15.254 + + +{{< mermaid >}} +pie showData +title 10.96.0.0/20 +"静态" : 256 +"动态" : 3838 +{{< /mermaid >}} + + +#### Service IP CIDR 地址段： 10.96.0.0/16 + + +地址段大小：216 - 2 = 65534 +地址段偏移：`min(max(16,65536/16),256)` = `min(4096,256)` = 256 +静态地址段起点：10.96.0.1 +静态地址段终点：10.96.1.0 +地址范围终点：10.96.255.254 + + +{{< mermaid >}} +pie showData +title 10.96.0.0/16 +"静态" : 256 +"动态" : 65278 +{{< /mermaid >}} + + +## 加入 SIG Network + + +当前 SIG-Network 在 GitHub 上的 [KEPs](https://github.com/orgs/kubernetes/projects/10) 和 +[issues](https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+is%3Aissue+label%3Asig%2Fnetwork) +表明了该 SIG 的重点领域。 + + +[SIG Network 会议](https://github.com/kubernetes/community/tree/master/sig-network)是一个友好、热情的场所， +你可以与社区联系并分享你的想法。期待你的回音！ diff --git a/content/zh/case-studies/wikimedia/index.html b/content/zh/case-studies/wikimedia/index.html index ab6452bfc3..8800c5f19e 100644 --- a/content/zh/case-studies/wikimedia/index.html +++ b/content/zh/case-studies/wikimedia/index.html @@ -1,118 +1,148 @@ --- title: 案例研究：Wikimedia - -class: gridPage +case_study_styles: true cid: caseStudies + +new_case_study_styles: true +heading_title_text: Wikimedia +use_gradient_overlay: true +subheading: > + 利用 Kubernetes 构建工具提升世界的维基 +case_study_details: + - 公司: Wikimedia + - 地点: 加州旧金山 --- + -

-
-
- -

利用 Kubernetes 构建工具提升世界的维基

-

- -非营利的 Wikimedia 基金会运营着一些世界上最大的合作编辑参考项目，包括 Wikipedia。为了帮助用户维护和使用 wiki，它运行 Wikimedia 工具实验室，这是一个托管环境，为社区开发人员工作的工具和机器人，以帮助编辑和其他志愿者做他们的工作，包括减少破坏。Wikimedia 工具实验室周围的社区在近10年前开始形成。 -

-
- Wikimedia -

- -“ Wikimedia 工具实验室对于确保世界各地的 wiki 尽可能工作至关重要。因为它有机地生长了近10年，它已成为一个极具挑战性的环境，难以维持。它就像一个大的泥球，你真的看不透它。借助 Kubernetes，可以简化环境，使开发人员能够更轻松地构建使 wiki 运行得更好的工具。” -

- -

— Yuvi Panda, Wikimedia 基金会和 Wikimedia 工具实验室的运维工程师

-
-
-
-
+ +

非营利的 Wikimedia 基金会运营着一些世界上最大的合作编辑参考项目，包括 Wikipedia。为了帮助用户维护和使用 wiki，它运行 Wikimedia 工具实验室，这是一个托管环境，为社区开发人员工作的工具和机器人，以帮助编辑和其他志愿者做他们的工作，包括减少破坏。Wikimedia 工具实验室周围的社区在近 10 年前开始形成。

-
-
-
-
-

挑战：

-
    - -
  • 简化复杂、难以管理的基础架构
    • - -
  • 允许开发人员使用现有技术继续编写工具和机器人
    • -
-
-
- -

为什么要使用 Kubernetes

-
    - -
  • Wikimedia 工具实验室之所以选择 Kubernetes，是因为它可以模仿现有的工作流程，同时降低复杂性。
    • -
-
-
- -

解决方案：

-
    - -
  • 将旧系统和复杂的基础设施迁移到库贝内特斯
    • -
-
-
- -

结果：

-
    - -
  • 占 Web 流量 40% 以上的 Web 工具的 20% 现在都在 Kubernetes 上运行
    • - -
  • 一个 25 节点集群可跟上每个新 Kubernetes 版本
    • - -
  • 由于 Kubernetes 数千行旧代码被删除
    • -
-
-
-
-
+ -

使用 Kubernetes 提供维护 wiki 的工具

-

- - Wikimedia 工具实验室由四名半付费员工和两名志愿者管理。基础架构无法使开发人员轻松或直观地构建机器人和其他工具，使 wiki 更易于工作。Yuvi说，“它非常混乱。我们有很多的 Perl 和 Bash 缠绕在上面。一切都是超级脆弱。” -

-

- - 为了解决这个问题，Wikimedia 工具实验室将其部分基础设施迁移到了 Kubernetes，为最终迁移整个系统做准备。Yuvi 说，Kubernetes 大大简化了维护。目标是允许创建机器人和其他工具的开发人员使用他们想要的任何开发方法，但使 Wikimedia 工具实验室更容易维护托管和共享它们所需的基础结构。 -

-

- - “借助 Kubernetes，我能够删除大量我们定制的代码，这使得所有内容更易于维护。我们的用户代码也以比以前更稳定的方式运行，” Yuvi 说。 -

-
- - +Wikimedia +
+
+"Wikimedia Tool Labs is vital for making sure wikis all around the world work as well as they possibly can. Because it's grown organically for almost 10 years, it has become an extremely challenging environment and difficult to maintain. It's like a big ball of mud — you really can't see through it. With Kubernetes, we're simplifying the environment and making it easier for developers to build the tools that make wikis run better." +{{< /case-studies/quote >}} +--> +{{< case-studies/quote author="Yuvi Panda, Wikimedia 基金会和 Wikimedia 工具实验室的运维工程师">}} -
-
-
- -

简化基础架构让 wiki 更好地运行

-

- - Wikimedia 工具实验室在最初的 Kubernetes 部署中取得了巨大成功。旧代码正在被简化和消除，使开发人员不必改变他们编写工具和机器人的方式，这些工具和机器人的运行方式比过去更稳定。付费员工和志愿者能够更好地解决问题。 -

-

- - 将来，随着更完整的迁移到 Kubernetes，Wikimedia 工具实验室希望使托管和维护帮助在世界各地运行 wiki 的机器人和工具变得更加容易。该工具实验室已经托管了来自 800 名志愿者的大约 1300 个工具和机器人，每天提交更多工具和机器人。占 Web 流量 60% 以上的 20% 的工具实验室 Web 工具现在运行在 Kubernetes 上。该工具实验室有一个 25 节点群集，可跟上每个新的 Kubernetes 版本。许多现有的 Web 工具正在迁移到 Kubernetes。 -

-

- - “我们的目标是确保世界各地的人们能够尽可能轻松地分享知识。Kubernetes 通过让世界各地的 wiki 更容易拥有蓬勃发展所需的工具，从而帮助到您，” Yuvi 说。 -

-
-
-
+Wikimedia +
+
+“Wikimedia 工具实验室对于确保世界各地的 wiki 尽可能正常运行至关重要。因为它有机地生长了近 10 年，所以它已成为一个极具挑战性且难以维护的环境。它就像一个大的泥球，你真的看不透它。借助 Kubernetes，我们正在简化环境并让开发人员更容易构建出使 wiki 更好运行的工具。” +{{< /case-studies/quote >}} + + +

挑战

+ + +
    +
  • 简化复杂、难以管理的基础架构
    • +
  • 允许开发人员使用现有技术继续编写工具和机器人
    • +
+ + +

为什么要使用 Kubernetes

+ +
    + +
  • Wikimedia 工具实验室之所以选择 Kubernetes，是因为它可以模仿现有的工作流程，同时降低复杂性。
    • +
+ + +

解决方案

+ +
    + +
  • 将旧系统和复杂的基础设施迁移到 Kubernetes
    • +
+ + +

结果

+ + +
    +
  • 现在占 Web 流量 40% 以上的 20% Web 工具都在 Kubernetes 上运行
    • +
  • 一个 25 节点集群可跟上每个新 Kubernetes 版本
    • +
  • 多亏了 Kubernetes，数千行旧代码可被删除
    • +
+ + +

使用 Kubernetes 提供维护 wiki 的工具

+ + +

Wikimedia 工具实验室由四个半带薪员工和两名志愿者管理。基础架构无法使开发人员轻松或直观地构建机器人和其他工具，使 wiki 更易于工作。Yuvi 说，“它非常混乱，我们有很多的 Perl 和 Bash 缠绕在上面，一切都是超级脆弱。”

+ + +

为了解决这个问题，Wikimedia 工具实验室将其部分基础设施迁移到了 Kubernetes，为最终迁移整个系统做准备。Yuvi 说，Kubernetes 大大简化了维护。目标是允许创建机器人和其他工具的开发人员使用他们想要的任何开发方法，但使 Wikimedia 工具实验室更容易维护托管和共享它们所需的基础结构。

+ + +

Yuvi 说：“借助 Kubernetes，我能够删除大量我们定制的代码，这使得所有内容更易于维护，我们的用户代码也以比以前更稳定的方式运行。”

+ + +

简化基础架构让 wiki 更好地运行

+ + +

Wikimedia 工具实验室在最初的 Kubernetes 部署中取得了巨大成功。旧代码正在被简化和消除，使开发人员不必改变他们编写工具和机器人的方式，这些工具和机器人的运行方式比过去更稳定。带薪员工和志愿者能够更好地解决问题。

+ + +

将来，随着更完整的迁移到 Kubernetes，Wikimedia 工具实验室希望更轻松地托管和维护有助于在世界各地运行 wiki 的机器人和工具。该工具实验室已经拥有来自 800 名志愿者的大约 1300 个工具和机器人，而且每天提交量会更多。占 Web 流量 60% 以上的工具实验室的 Web 工具中有 20% 现在运行在 Kubernetes 上。工具实验室有一个 25 节点的集群，可以跟上每个新的 Kubernetes 版本。许多现有的 Web 工具正在迁移到 Kubernetes。

+ + +

Yuvi 说：“我们的目标是确保世界各地的人们能够尽可能轻松地分享知识，Kubernetes 帮助实现了这一点，它让世界各地的 wiki 更容易拥有蓬勃发展所需的工具。”

diff --git a/content/zh/case-studies/wikimedia/wikimedia_featured.svg b/content/zh/case-studies/wikimedia/wikimedia_featured.svg new file mode 100644 index 0000000000..5fa786aaa5 --- /dev/null +++ b/content/zh/case-studies/wikimedia/wikimedia_featured.svg @@ -0,0 +1 @@ +kubernetes.io-logos2 \ No newline at end of file diff --git a/content/zh/community/code-of-conduct.md b/content/zh/community/code-of-conduct.md index 98d8156770..e5942dc439 100644 --- a/content/zh/community/code-of-conduct.md +++ b/content/zh/community/code-of-conduct.md @@ -24,7 +24,7 @@ Kubernetes 遵循 CNCF 行为规范。 CNCF 社区规范文本如下链接 commit 0ce4694。 -如果您发现这个 CNCF 社区规范文本已经过时，请 +如果你发现这个 CNCF 社区规范文本已经过时，请 提交 issue。

@@ -35,7 +35,7 @@ the [Kubernetes Code of Conduct Committee](https://github.com/kubernetes/communi Your anonymity will be protected. --> 如果你在活动、会议、Slack 或是其它场合发现有任何违反行为规范的行为，请联系[Kubernetes 行为规范委员会](https://github.com/kubernetes/community/tree/master/committee-code-of-conduct)。 -我们会确保您的匿名性。 +我们会确保你的匿名性。

diff --git a/content/zh/community/static/cncf-code-of-conduct.md b/content/zh/community/static/cncf-code-of-conduct.md index 0c63979e3e..dde18750ea 100644 --- a/content/zh/community/static/cncf-code-of-conduct.md +++ b/content/zh/community/static/cncf-code-of-conduct.md @@ -4,9 +4,11 @@ ### 贡献者行为准则 -作为这个项目的贡献者和维护者，为了建立一个开放和受欢迎的社区，我们保证尊重所有通过报告问题、发布功能请求、更新文档、提交拉取请求或补丁以及其他活动做出贡献的人员。 +作为这个项目的贡献者和维护者，为了建立一个开放和受欢迎的社区， +我们保证尊重所有通过报告问题、发布功能请求、更新文档、提交拉取请求或补丁以及其他活动做出贡献的人员。 -我们致力于让参与此项目的每个人都不受骚扰，无论其经验水平、性别、性别认同和表达、性取向、残疾、个人外貌、体型、人种、种族、年龄、宗教或国籍等。 +我们致力于让参与此项目的每个人都不受骚扰， +无论其经验水平、性别、性别认同和表达、性取向、残疾、个人外貌、体型、人种、种族、年龄、宗教或国籍等。 不可接受的参与者行为包括： @@ -17,14 +19,21 @@ - 未经明确许可，发布他人的私人信息，比如地址或电子邮箱 - 其他不道德或不专业的行为 -项目维护者有权利和责任删除、编辑或拒绝评论、提交、代码、维基编辑、问题和其他不符合本行为准则的贡献。通过采用本行为准则，项目维护者承诺将这些原则公平且一致地应用到这个项目管理的各个方面。不遵守或不执行行为准则的项目维护者可能被永久地从项目团队中移除。 +项目维护者有权利和责任删除、编辑或拒绝评论、提交、代码、维基编辑、问题和其他不符合本行为准则的贡献。 +通过采用本行为准则，项目维护者承诺将这些原则公平且一致地应用到这个项目管理的各个方面。 +不遵守或不执行行为准则的项目维护者可能被永久地从项目团队中移除。 当个人代表项目或其社区时，本行为准则适用于项目空间和公共空间。 -如需举报侮辱、骚扰或其他不可接受的行为，您可发送邮件至 联系 [Kubernetes行为守则委员会](https://github.com/kubernetes/community/tree/master/committee-code-of-conduct)。其他事务请联系CNCF项目维护专员，或发送邮件至 联系我们的调解员Mishi Choudhary。 +如需举报侮辱、骚扰或其他不可接受的行为， +你可发送邮件至 联系 +[Kubernetes行为守则委员会](https://github.com/kubernetes/community/tree/master/committee-code-of-conduct)。 +其他事务请联系CNCF项目维护专员，或发送邮件至 联系我们的调解员Mishi Choudhary。 -本行为准则改编自《贡献者契约》（ https://contributor-covenant.org ）1.2.0 版本，可在 https://contributor-covenant.org/version/1/2/0/ 查看。 +本行为准则改编自《贡献者契约》（ https://contributor-covenant.org ）1.2.0 版本， +可在 https://contributor-covenant.org/version/1/2/0/ 查看。 ### CNCF 活动行为准则 -云原生计算基金会（CNCF）活动受 Linux 基金会《[行为准则](https://events.linuxfoundation.org/code-of-conduct/)》管辖，该行为准则可在活动页面获得。其旨在与上述政策兼容，且包括更多关于事件回应的细节。 \ No newline at end of file +云原生计算基金会（CNCF）活动受 Linux 基金会《[行为准则](https://events.linuxfoundation.org/code-of-conduct/)》管辖， +该行为准则可在活动页面获得。其旨在与上述政策兼容，且包括更多关于事件回应的细节。 \ No newline at end of file diff --git a/content/zh/docs/concepts/cluster-administration/networking.md b/content/zh/docs/concepts/cluster-administration/networking.md index a75e68666f..4bfae1a551 100644 --- a/content/zh/docs/concepts/cluster-administration/networking.md +++ b/content/zh/docs/concepts/cluster-administration/networking.md @@ -1,10 +1,15 @@ --- -reviewers: -- thockin title: 集群网络系统 content_type: concept weight: 50 --- + @@ -62,7 +67,7 @@ as an introduction to various technologies and serves as a jumping-off point. The following networking options are sorted alphabetically - the order does not imply any preferential status. --> -## 如何实现 Kubernetes 的网络模型 +## 如何实现 Kubernetes 的网络模型 {#how-to-implement-the-kubernetes-networking-model} 有很多种方式可以实现这种网络模型，本文档并不是对各种实现技术的详细研究， 但是希望可以作为对各种技术的详细介绍，并且成为你研究的起点。 @@ -105,7 +110,7 @@ Using this CNI plugin allows Kubernetes pods to have the same IP address inside Additionally, the CNI can be run alongside [Calico for network policy enforcement](https://docs.aws.amazon.com/eks/latest/userguide/calico.html). The AWS VPC CNI project is open source with [documentation on GitHub](https://github.com/aws/amazon-vpc-cni-k8s). --> -### Kubernetes 的 AWS VPC CNI +### Kubernetes 的 AWS VPC CNI {#aws-vpc-cni-for-kubernetes} [AWS VPC CNI](https://github.com/aws/amazon-vpc-cni-k8s) 为 Kubernetes 集群提供了集成的 AWS 虚拟私有云（VPC）网络。该 CNI 插件提供了高吞吐量和可用性，低延迟以及最小的网络抖动。 @@ -113,7 +118,7 @@ AWS 虚拟私有云（VPC）网络。该 CNI 插件提供了高吞吐量和可 这包括使用 VPC 流日志、VPC 路由策略和安全组进行网络流量隔离的功能。 使用该 CNI 插件，可使 Kubernetes Pod 拥有与在 VPC 网络上相同的 IP 地址。 -CNI 将 AWS 弹性网络接口（ENI）分配给每个 Kubernetes 节点，并将每个 ENI 的辅助 IP 范围用于该节点上的 Pod 。 +CNI 将 AWS 弹性网络接口（ENI）分配给每个 Kubernetes 节点，并将每个 ENI 的辅助 IP 范围用于该节点上的 Pod。 CNI 包含用于 ENI 和 IP 地址的预分配的控件，以便加快 Pod 的启动时间，并且能够支持多达 2000 个节点的大型集群。 此外，CNI 可以与 @@ -121,20 +126,20 @@ CNI 包含用于 ENI 和 IP 地址的预分配的控件，以便加快 Pod 的 AWS VPC CNI 项目是开源的，请查看 [GitHub 上的文档](https://github.com/aws/amazon-vpc-cni-k8s)。 -### Kubernetes 的 Azure CNI +### Kubernetes 的 Azure CNI {#azure-cni-for-kubernetes} [Azure CNI](https://docs.microsoft.com/en-us/azure/virtual-network/container-networking-overview) 是一个[开源插件](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md)， 将 Kubernetes Pods 和 Azure 虚拟网络（也称为 VNet）集成在一起，可提供与 VM 相当的网络性能。 -Pod 可以通过 Express Route 或者 站点到站点的 VPN 来连接到对等的 VNet ， +Pod 可以通过 Express Route 或者 站点到站点的 VPN 来连接到对等的 VNet， 也可以从这些网络来直接访问 Pod。Pod 可以访问受服务端点或者受保护链接的 Azure 服务，比如存储和 SQL。 你可以使用 VNet 安全策略和路由来筛选 Pod 流量。 -该插件通过利用在 Kubernetes 节点的网络接口上预分配的辅助 IP 池将 VNet 分配给 Pod 。 +该插件通过利用在 Kubernetes 节点的网络接口上预分配的辅助 IP 池将 VNet 分配给 Pod。 Azure CNI 可以在 [Azure Kubernetes Service (AKS)](https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni) 中获得。 @@ -142,7 +147,7 @@ Azure CNI 可以在 ### Calico @@ -150,7 +155,8 @@ Azure CNI 可以在 用于基于容器、虚拟机和本地主机的工作负载。 Calico 支持多个数据面，包括：纯 Linux eBPF 的数据面、标准的 Linux 联网数据面 以及 Windows HNS 数据面。Calico 在提供完整的联网堆栈的同时，还可与 -[云驱动 CNIs](https://docs.projectcalico.org/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations) 联合使用，以保证网络策略实施。 +[云驱动 CNIs](https://projectcalico.docs.tigera.io/networking/determine-best-networking#calico-compatible-cni-plugins-and-cloud-provider-integrations) +联合使用，以保证网络策略实施。 -### 华为的 CNI-Genie +### 华为的 CNI-Genie {#cni-genie-from-huawei} [CNI-Genie](https://github.com/cni-genie/CNI-Genie) 是一个 CNI 插件， 可以让 Kubernetes 在运行时使用不同的[网络模型](#the-kubernetes-network-model)的 [实现同时被访问](https://github.com/cni-genie/CNI-Genie/blob/master/docs/multiple-cni-plugins/README.md#what-cni-genie-feature-1-multiple-cni-plugins-enables)。 这包括以 [CNI 插件](https://github.com/containernetworking/cni#3rd-party-plugins)运行的任何实现，比如 -[Flannel](https://github.com/coreos/flannel#flannel)、 +[Flannel](https://github.com/flannel-io/flannel#flannel)、 [Calico](https://projectcalico.docs.tigera.io/about/about-calico/)、 [Weave-net](https://www.weave.works/oss/net/)。 @@ -240,13 +246,11 @@ Kubernetes, using the [fd.io](https://fd.io/) data plane. ### Contiv-VPP [Contiv-VPP](https://contivpp.io/) 是用于 Kubernetes 的用户空间、面向性能的网络插件，使用 [fd.io](https://fd.io/) 数据平面。 - -### Contrail/Tungsten Fabric - [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/) 是基于 [Tungsten Fabric](https://tungsten.io) 的，真正开放的多云网络虚拟化和策略管理平台。 Contrail 和 Tungsten Fabric 与各种编排系统集成在一起，例如 Kubernetes、OpenShift、OpenStack 和 Mesos， @@ -298,7 +302,7 @@ Kubernetes 所需要的覆盖网络。已经有许多人报告了使用 Flannel ### Hybridnet [Hybridnet](https://github.com/alibaba/hybridnet) 是一个为混合云设计的开源 CNI 插件， -它为一个或多个集群中的容器提供覆盖和底层网络。 Overlay 和 underlay 容器可以在同一个节点上运行， +它为一个或多个集群中的容器提供覆盖和底层网络。Overlay 和 underlay 容器可以在同一个节点上运行， 并具有集群范围的双向网络连接。 ### L2 networks and linux bridging -如果你具有一个“哑”的L2网络，例如“裸机”环境中的简单交换机，则应该能够执行与上述 GCE 设置类似的操作。 +如果你具有一个“哑”的 L2 网络，例如“裸机”环境中的简单交换机，则应该能够执行与上述 GCE 设置类似的操作。 请注意，这些说明仅是非常简单的尝试过-似乎可行，但尚未经过全面测试。 -如果您使用此技术并完善了流程，请告诉我们。 +如果你使用此技术并完善了流程，请告诉我们。 -根据 Lars Kellogg-Stedman 的这份非常不错的“Linux 网桥设备” +根据 Lars Kellogg-Stedman 的这份非常不错的 “Linux 网桥设备” [使用说明](https://blog.oddbit.com/2014/08/11/four-ways-to-connect-a-docker/)来进行操作。 +### OVN4NFV-K8s-Plugin（基于 OVN 的 CNI 控制器和插件） {#ovn4nfv-k8s-plugin-ovn-based-cni-controller-plugin} + +[OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) 是基于 OVN 的 +CNI 控制器插件，提供基于云原生的服务功能链 (SFC)、多个 OVN +覆盖网络、动态子网创建、虚拟网络的动态创建、VLAN Provider 网络、Direct Provider +网络且可与其他多网络插件组合，非常适合多集群网络中基于边缘的云原生工作负载。 + -### OVN (开放式虚拟网络) +### OVN（开放式虚拟网络） {#ovn-open-virtual-networking} OVN 是一个由 Open vSwitch 社区开发的开源的网络虚拟化解决方案。 它允许创建逻辑交换器、逻辑路由、状态 ACL、负载均衡等等来建立不同的虚拟网络拓扑。 -该项目有一个特定的Kubernetes插件和文档 [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes)。 +该项目在 [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) +提供特定的 Kubernetes 插件和文档。 -### Weaveworks 的 Weave Net +### Weaveworks 的 Weave Net {#weave-net-from-weaveworks} -[Weave Net](https://www.weave.works/oss/net/) 是 Kubernetes 及其 -托管应用程序的弹性且易于使用的网络系统。 +[Weave Net](https://www.weave.works/oss/net/) 为 Kubernetes +及其托管应用提供的、弹性且易用的网络系统。 Weave Net 可以作为 [CNI 插件](https://www.weave.works/docs/net/latest/cni-plugin/) 运行或者独立运行。 在这两种运行方式里，都不需要任何配置或额外的代码即可运行，并且在两种情况下， 网络都为每个 Pod 提供一个 IP 地址 -- 这是 Kubernetes 的标准配置。 @@ -456,9 +473,8 @@ Weave Net 可以作为 [CNI 插件](https://www.weave.works/docs/net/latest/cni- -网络模型的早期设计、运行原理以及未来的一些计划，都在 -[联网设计文档](https://git.k8s.io/community/contributors/design-proposals/network/networking.md) -里有更详细的描述。 +网络模型的早期设计、运行原理以及未来的一些计划， +都在[联网设计文档](https://git.k8s.io/community/contributors/design-proposals/network/networking.md)里有更详细的描述。 diff --git a/content/zh/docs/concepts/configuration/secret.md b/content/zh/docs/concepts/configuration/secret.md index 917d318703..897def8bb4 100644 --- a/content/zh/docs/concepts/configuration/secret.md +++ b/content/zh/docs/concepts/configuration/secret.md @@ -35,12 +35,12 @@ Secret 是一种包含少量敏感信息例如密码、令牌或密钥的对象 这样的信息可能会被放在 {{< glossary_tooltip term_id="pod" >}} 规约中或者镜像中。 使用 Secret 意味着你不需要在应用程序代码中包含机密数据。 - -默认情况下，Kubernetes Secret 未加密地存储在 API 服务器的底层数据存储（etcd）中。 +默认情况下，Kubernetes Secret 未加密地存储在 API 服务器的底层数据存储（etcd）中。 任何拥有 API 访问权限的人都可以检索或修改 Secret，任何有权访问 etcd 的人也可以。 此外，任何有权限在命名空间中创建 Pod 的人都可以使用该访问权限读取该命名空间中的任何 Secret； 这包括间接访问，例如创建 Deployment 的能力。 @@ -75,7 +75,7 @@ In order to safely use Secrets, take at least the following steps: 为了安全地使用 Secret，请至少执行以下步骤： 1. 为 Secret [启用静态加密](/zh/docs/tasks/administer-cluster/encrypt-data/)； -1. 启用或配置 [RBAC 规则](/zh/docs/reference/access-authn-authz/authorization/)来限制读取和写入 +1. [启用或配置 RBAC 规则](/zh/docs/reference/access-authn-authz/authorization/)来限制读取和写入 Secret 的数据（包括通过间接方式）。需要注意的是，被准许创建 Pod 的人也隐式地被授权获取 Secret 内容。 1. 在适当的情况下，还可以使用 RBAC 等机制来限制允许哪些主体创建新 Secret 或替换现有 Secret。 @@ -258,6 +258,10 @@ You can edit an existing Secret using kubectl: kubectl edit secrets mysecret ``` + 这一命令会启动你的默认编辑器，允许你更新 `data` 字段中存放的 base64 编码的 Secret 值； 例如： @@ -456,7 +460,7 @@ subresource to obtain a token to access the API is recommended instead. You can also control the paths within the volume where Secret keys are projected. You can use the `.spec.volumes[].secret.items` field to change the target path of each key: --> -#### 将 Secret 键投射到特定目录 +#### 将 Secret 键投射到特定目录 {#projection-of-secret-keys-to-specific-paths} 你也可以控制 Secret 键所投射到的卷中的路径。 你可以使用 `.spec.volumes[].secret.items` 字段来更改每个主键的目标路径： @@ -517,7 +521,7 @@ You can also set a default mode for the entire Secret volume and override per ke For example, you can specify a default mode like this: --> -#### Secret 文件的访问权限 +#### Secret 文件的访问权限 {#secret-files-permissions} 你可以为某个 Secret 主键设置 POSIX 文件访问权限位。 如果你不指定访问权限，默认会使用 `0644`。 @@ -782,7 +786,7 @@ of the secret data. This is the result of commands executed inside the container from the example above: --> -#### 通过环境变量使用 Secret 值 +#### 通过环境变量使用 Secret 值 {#consuming-secret-values-from-environment-variables} 在通过环境变量来使用 Secret 的容器中，Secret 主键展现为普通的环境变量。 这些变量的取值是 Secret 数据的 Base64 解码值。 @@ -862,7 +866,7 @@ You can use an `imagePullSecrets` to pass a secret that contains a Docker (or ot password to the kubelet. The kubelet uses this information to pull a private image on behalf of your Pod. See the [PodSpec API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) for more information about the `imagePullSecrets` field. --> -#### 使用 imagePullSecrets +#### 使用 imagePullSecrets {#using-imagepullsecrets-1} `imagePullSecrets` 字段是一个列表，包含对同一名字空间中 Secret 的引用。 你可以使用 `imagePullSecrets` 将包含 Docker（或其他）镜像仓库密码的 Secret @@ -876,7 +880,7 @@ See the [PodSpec API](/docs/reference/generated/kubernetes-api/{{< param "versio You can learn how to specify `imagePullSecrets` from the [container images](/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) documentation. --> -##### 手动设定 imagePullSecret +##### 手动设定 imagePullSecret {#manually-specifying-an-imagepullsecret} 你可以通过阅读[容器镜像](/zh/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) 文档了解如何设置 `imagePullSecrets`。 @@ -891,7 +895,7 @@ field set to that of the service account. See [Add ImagePullSecrets to a service account](/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account) for a detailed explanation of that process. --> -##### 设置 imagePullSecrets 为自动挂载 +##### 设置 imagePullSecrets 为自动挂载 {#arranging-for-imagepullsecrets-to-be-automatically-attached} 你可以手动创建 `imagePullSecret`，并在一个 ServiceAccount 中引用它。 对使用该 ServiceAccount 创建的所有 Pod，或者默认使用该 ServiceAccount 创建的 Pod @@ -919,7 +923,7 @@ Create a secret --> ## 使用场景 {#use-case} -### 使用场景：作为容器环境变量 +### 使用场景：作为容器环境变量 {#use-case-as-container-environment-variables} 创建 Secret： @@ -970,7 +974,7 @@ spec: Create a Secret containing some SSH keys: --> -### 使用场景：带 SSH 密钥的 Pod +### 使用场景：带 SSH 密钥的 Pod {#use-case-pod-with-ssh-keys} 创建包含一些 SSH 密钥的 Secret： @@ -1061,7 +1065,7 @@ credentials. You can create a `kustomization.yaml` with a `secretGenerator` field or run `kubectl create secret`. --> -### 使用场景：带有生产、测试环境凭据的 Pod +### 使用场景：带有生产、测试环境凭据的 Pod {#use-case-pods-with-prod-test-credentials} 这一示例所展示的一个 Pod 会使用包含生产环境凭据的 Secret，另一个 Pod 使用包含测试环境凭据的 Secret。 @@ -1247,7 +1251,7 @@ You can make your data "hidden" by defining a key that begins with a dot. This key represents a dotfile or "hidden" file. For example, when the following secret is mounted into a volume, `secret-volume`: --> -### 使用场景：在 Secret 卷中带句点的文件 +### 使用场景：在 Secret 卷中带句点的文件 {#use-case-dotfiles-in-a-secret-volume} 通过定义以句点（`.`）开头的主键，你可以“隐藏”你的数据。 这些主键代表的是以句点开头的文件或“隐藏”文件。 @@ -1308,7 +1312,7 @@ logic, and then sign some messages with an HMAC. Because it has complex application logic, there might be an unnoticed remote file reading exploit in the server, which could expose the private key to an attacker. --> -### 使用场景：仅对 Pod 中一个容器可见的 Secret +### 使用场景：仅对 Pod 中一个容器可见的 Secret {#use-case-secret-visible-to-one-container-in-a-pod} 考虑一个需要处理 HTTP 请求，执行某些复杂的业务逻辑，之后使用 HMAC 来对某些消息进行签名的程序。因为这一程序的应用逻辑很复杂， @@ -1341,7 +1345,7 @@ the [Secret](/docs/reference/kubernetes-api/config-and-storage-resources/secret- resource, or certain equivalent `kubectl` command line flags (if available). The Secret type is used to facilitate programmatic handling of the Secret data. -Kubernetes provides several builtin types for some common usage scenarios. +Kubernetes provides several built-in types for some common usage scenarios. These types vary in terms of the validations performed and the constraints Kubernetes imposes on them. --> @@ -1355,10 +1359,10 @@ Kubernetes 提供若干种内置的类型，用于一些常见的使用场景。 针对这些类型，Kubernetes 所执行的合法性检查操作以及对其所实施的限制各不相同。 通过为 Secret 对象的 `type` 字段设置一个非空的字符串值，你也可以定义并使用自己 -Secret 类型。如果 `type` 值为空字符串，则被视为 `Opaque` 类型。 +Secret 类型（如果 `type` 值为空字符串，则被视为 `Opaque` 类型）。 Kubernetes 并不对类型的名称作任何限制。不过，如果你要使用内置类型之一， @@ -1433,13 +1437,13 @@ empty-secret Opaque 0 2m6s `DATA` 列显示 Secret 中保存的数据条目个数。 -在这个例子种，`0` 意味着我们刚刚创建了一个空的 Secret。 +在这个例子种，`0` 意味着你刚刚创建了一个空的 Secret。 -Kubernetes 在创建 Pod 时会自动创建一个服务账号 Secret 并自动修改你的 Pod +Kubernetes 在创建 Pod 时会自动寻找或创建一个服务账号 Secret 并自动修改你的 Pod 以使用该 Secret。该服务账号令牌 Secret 中包含了访问 Kubernetes API 所需要的凭据。 @@ -1511,10 +1515,10 @@ Kubernetes 在创建 Pod 时会自动创建一个服务账号 Secret 并自动 参考 [ServiceAccount](/zh/docs/tasks/configure-pod-container/configure-service-account/) @@ -1527,12 +1531,11 @@ for information on referencing service account from Pods. ### Docker config Secrets You can use one of the following `type` values to create a Secret to -store the credentials for accessing a Docker registry for images. +store the credentials for accessing a container image registry: --> ### Docker 配置 Secret {#docker-config-secrets} -你可以使用下面两种 `type` 值之一来创建 Secret，用以存放访问 Docker 仓库 -来下载镜像的凭据。 +你可以使用下面两种 `type` 值之一来创建 Secret，用以存放用于访问容器鏡像倉庫的凭据： - `kubernetes.io/dockercfg` - `kubernetes.io/dockerconfigjson` @@ -1550,7 +1553,7 @@ Secret 的 `data` 字段中包含名为 `.dockercfg` 的主键，其对应键值 编码的某 `~/.dockercfg` 文件的内容。 当你使用清单文件来创建这两类 Secret 时，API 服务器会检查 `data` 字段中是否 存在所期望的主键，并且验证其中所提供的键值是否是合法的 JSON 数据。 不过，API 服务器不会检查 JSON 数据本身是否是一个合法的 Docker 配置文件内容。 + +当你没有 Docker 配置文件，或者你想使用 `kubectl` 创建一个 Secret +来访问容器倉庫时，你可以这样做： + ```shell kubectl create secret docker-registry secret-tiger-docker \ --docker-email=tiger@acme.example \ --docker-username=tiger \ - --docker-password=pass113 \ + --docker-password=pass1234 \ --docker-server=my-registry.example:5000 ``` 上面的命令创建一个类型为 `kubernetes.io/dockerconfigjson` 的 Secret。 如果你对 `.data.dockerconfigjson` 内容进行转储并执行 base64 解码： +```shell +kubectl get secret secret-tiger-docker -o jsonpath='{.data.*}' | base64 -d +``` + + +那么输出等价于这个 JSON 文档（这也是一个有效的 Docker 配置文件）： + ```json { "auths": { "my-registry.example:5000": { "username": "tiger", - "password": "pass113", - "email": "tiger@acme.com", - "auth": "dGlnZXI6cGFzczExMw==" + "password": "pass1234", + "email": "tiger@acme.example", + "auth": "dGlnZXI6cGFzczEyMzQ=" } } } @@ -1642,15 +1659,15 @@ Anyone who can read that Secret can learn the registry access bearer token. The `kubernetes.io/basic-auth` type is provided for storing credentials needed for basic authentication. When using this Secret type, the `data` field of the -Secret must contain the following two keys: +Secret must contain one of the following two keys: -- `username`: the user name for authentication; -- `password`: the password or token for authentication. +- `username`: the user name for authentication +- `password`: the password or token for authentication --> ### 基本身份认证 Secret {#basic-authentication-secret} `kubernetes.io/basic-auth` 类型用来存放用于基本身份认证所需的凭据信息。 -使用这种 Secret 类型时，Secret 的 `data` 字段必须包含以下两个键： +使用这种 Secret 类型时，Secret 的 `data` 字段必须包含以下两个键之一： - `username`: 用于身份认证的用户名； - `password`: 用于身份认证的密码或令牌。 @@ -1660,11 +1677,11 @@ Both values for the above two keys are base64 encoded strings. You can, of course, provide the clear text content using the `stringData` for Secret creation. -The following YAML is an example config for a basic authentication Secret: +The following manifest is an example of a basic authentication Secret: --> 以上两个键的键值都是 base64 编码的字符串。 当然你也可以在创建 Secret 时使用 `stringData` 字段来提供明文形式的内容。 -下面的 YAML 是基本身份认证 Secret 的一个示例清单： +以下清单是基本身份验证 Secret 的示例： ```yaml apiVersion: v1 @@ -1673,13 +1690,13 @@ metadata: name: secret-basic-auth type: kubernetes.io/basic-auth stringData: - username: admin # kubernetes.io/basic-auth 类型的必需字段 + username: admin # kubernetes.io/basic-auth 类型的必需字段 password: t0p-Secret # kubernetes.io/basic-auth 类型的必需字段 ``` ### 启动引导令牌 Secret {#bootstrap-token-secrets} @@ -1890,11 +1907,11 @@ data: ``` -## Secret 的信息安全问题 +## Secret 的信息安全问题 {#information-security-for-secrets} 尽管 ConfigMap 和 Secret 的工作方式类似，但 Kubernetes 对 Secret 有一些额外的保护。 @@ -2096,7 +2113,7 @@ on that node. variable configuration so that the other containers do not have access to that Secret. --> -### 针对开发人员的安全性建议 +### 针对开发人员的安全性建议 {#security-recommendations-for-developers} - 应用在从环境变量或卷中读取了机密信息内容之后仍要对其进行保护。例如， 你的应用应该避免用明文的方式将 Secret 数据写入日志，或者将其传递给不可信的第三方。 @@ -2117,7 +2134,7 @@ on that node. - When deploying applications that interact with the Secret API, you should limit access using [authorization policies](/docs/reference/access-authn-authz/authorization/) such as - [RBAC]( /docs/reference/access-authn-authz/rbac/). + [RBAC](/docs/reference/access-authn-authz/rbac/). --> - 部署与 Secret API 交互的应用时，你应该使用 [RBAC](/zh/docs/reference/access-authn-authz/rbac/) 这类[鉴权策略](/zh/docs/reference/access-authn-authz/authorization/)来限制访问。 @@ -2134,7 +2151,7 @@ on that node. -### 针对集群管理员的安全性建议 +### 针对集群管理员的安全性建议 {#security-recommendations-for-cluster-administrators} {{< caution >}} - 保留（使用 Kubernetes API）对集群中所有 Secret 对象执行 `watch` 或 `list` 操作的能力， 这样只有特权级最高、系统级别的组件能够执行这类操作。 @@ -2185,9 +2202,9 @@ Pod 来访问 Secret 的内容。 ## {{% heading "whatsnext" %}} - 学习如何[使用 `kubectl` 管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl/) diff --git a/content/zh/docs/concepts/configuration/windows-resource-management.md b/content/zh/docs/concepts/configuration/windows-resource-management.md new file mode 100644 index 0000000000..1a7d765e59 --- /dev/null +++ b/content/zh/docs/concepts/configuration/windows-resource-management.md @@ -0,0 +1,135 @@ +--- +title: Windows 节点的资源管理 +content_type: concept +weight: 75 +--- + + + +本页概述了 Linux 和 Windows 在资源管理方式上的区别。 + + + +在 Linux 节点上，{{< glossary_tooltip text="cgroup" term_id="cgroup" >}} 用作资源控制的 Pod 边界。 +在这个边界内创建容器以便于隔离网络、进程和文件系统。 +Linux cgroup API 可用于收集 CPU、I/O 和内存使用统计数据。 + +与此相反，Windows 中每个容器对应一个[**作业对象**](https://docs.microsoft.com/zh-cn/windows/win32/procthread/job-objects)， +与系统命名空间过滤器一起使用，将所有进程包含在一个容器中，提供与主机的逻辑隔离。 +（作业对象是一种 Windows 进程隔离机制，不同于 Kubernetes 提及的 {{< glossary_tooltip term_id="job" text="Job" >}})。 + +如果没有命名空间过滤，就无法运行 Windows 容器。 +这意味着在主机环境中无法让系统特权生效，因此特权容器在 Windows 上不可用。 +容器不能使用来自主机的标识，因为安全帐户管理器（Security Account Manager，SAM）是独立的。 + + +## 内存预留 {#resource-management-memory} + +Windows 不像 Linux 一样提供杀手（killer）机制，杀死内存不足的进程。 +Windows 始终将所有用户态内存分配视为虚拟内存，并强制使用页面文件（pagefile）。 + +Windows 节点不会为容器中运行的进程过量使用内存。 +最终结果是 Windows 不会像 Linux 那样达到内存不足的情况，Windows 将进程页面放到磁盘， +不会因为内存不足（OOM）而终止进程。 +如果内存配置过量且所有物理内存都已耗尽，则换页性能就会降低。 + + +你可以使用 kubelet 的 `--kubelet-reserve` 和/或 `--system-reserve` +参数设定工作负载的内存使用边界；这些参数负责表示节点上（容器外）的内存用量，并会减少 +[节点可分配（NodeAllocatable）](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)内存量。 +在你部署工作负载时，会对容器设置资源限制值。 +这个限制值也会从 `NodeAllocatable` 中减去，并防止调度器在节点已满时增加更多 Pod。 + + +{{< note >}} +当你为 Windows 容器设置内存资源限制时，你应设置一个内存限制但不指定内存请求， +或将请求值设为等于限制值。 +{{< /note >}} + +在 Windows 上，避免过量配置的良好做法是为 kubelet 配置至少 2GiB 的系统预留内存， +以满足 Windows、Kubernetes 和容器运行时开销。 + + +## CPU 预留 {#resource-management-cpu} + +为了满足操作系统、容器运行时和 kubelet 等 Kubernetes 主机进程的 CPU 使用量， +你可以（且应该）从 CPU 总量中预留一定百分比。 +你应该根据节点上可用的 CPU 核数来确定这个 CPU 预留量。 +要决定预留的 CPU 百分比，需确定每个节点的最大 Pod 密度， +并监控节点上运行的系统服务的 CPU 使用量，然后选择一个满足工作负载需求的值。 + + +你可以使用 kubelet 的 `--kubelet-reserve` 和/或 `--system-reserve` +参数设定工作负载的 CPU 使用边界，以统计节点上（容器外）的 CPU 使用量。 +这会减少 `NodeAllocatable`。 +然后集群范围的调度器在决定放置 Pod 时会考虑这个预留量。 + +在 Windows 上，kubelet 支持使用命令行标志来设置 kubelet 进程的优先级：`--windows-priorityclass`。 +与 Windows 主机上运行的其他进程相比，此标志允许 kubelet 进程获取更多的 CPU 时间片。 +有关允许值及其含义的更多信息，请访问 [Windows 优先级类](https://docs.microsoft.com/zh-cn/windows/win32/procthread/scheduling-priorities#priority-class)。 +为了确保运行的 Pod 不会耗尽 kubelet 的 CPU 时钟周期， +要将此标志设置为 `ABOVE_NORMAL_PRIORITY_CLASS` 或更高。 diff --git a/content/zh/docs/concepts/overview/what-is-kubernetes.md b/content/zh/docs/concepts/overview/what-is-kubernetes.md index e28baf718f..3afe5cef85 100644 --- a/content/zh/docs/concepts/overview/what-is-kubernetes.md +++ b/content/zh/docs/concepts/overview/what-is-kubernetes.md @@ -45,7 +45,7 @@ Google 在 2014 年开源了 Kubernetes 项目。Kubernetes 建立在 ## Going back in time Let's take a look at why Kubernetes is so useful by going back in time. --> -## 时光回溯 +## 时光回溯 {#going-back-in-time} 让我们回顾一下为何 Kubernetes 能够裨益四方。 @@ -61,11 +61,11 @@ Early on, organizations ran applications on physical servers. There was no way t --> **传统部署时代：** -早期，各个组织机构在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界，这会导致资源分配问题。 +早期，各个组织机构在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源限制，这会导致资源分配问题。 例如，如果在物理服务器上运行多个应用程序，则可能会出现一个应用程序占用大部分资源的情况， 结果可能导致其他应用程序的性能下降。 -一种解决方案是在不同的物理服务器上运行每个应用程序，但是由于资源利用不足而无法扩展， -并且维护许多物理服务器的成本很高。 +一种解决方案是在不同的物理服务器上运行每个应用程序，但是当资源利用率不高时，这种方法可扩展性较差， +而且维护许多物理服务器的成本很高。 **虚拟化部署时代：** -作为解决方案，引入了虚拟化。虚拟化技术允许你在单个物理服务器的 CPU 上运行多个虚拟机（VM）。 -虚拟化允许应用程序在 VM 之间隔离，并提供一定程度的安全，因为一个应用程序的信息 -不能被另一应用程序随意访问。 +因此，虚拟化技术被引入了。虚拟化技术允许你在单个物理服务器的 CPU 上运行多个虚拟机（VM）。 +虚拟化允许应用程序在 VM 之间隔离，并提供一定程度的安全性， +因为一个应用程序的信息不能被另一应用程序随意访问。 -虚拟化技术能够更好地利用物理服务器上的资源，并且因为可轻松地添加或更新应用程序 +虚拟化技术能够更好地利用物理服务器上的资源，并且因为可轻松地添加或更新应用程序， 而可以实现更好的可伸缩性，降低硬件成本等等。 每个 VM 是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。 @@ -93,7 +93,7 @@ Containers are similar to VMs, but they have relaxed isolation properties to sha --> **容器部署时代：** -容器类似于 VM，但是它们具有被放宽的隔离属性，可以在应用程序之间共享操作系统（OS）。 +容器类似于 VM，但是它们具有更宽松的隔离属性，可以在应用程序之间共享操作系统（OS）。 因此，容器被认为是轻量级的。容器与 VM 类似，具有自己的文件系统、CPU、内存、进程空间等。 由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植。 @@ -115,8 +115,8 @@ Containers are becoming popular because they have many benefits. Some of the con * Resource utilization: high efficiency and density. --> * 敏捷应用程序的创建和部署：与使用 VM 镜像相比，提高了容器镜像创建的简便性和效率。 -* 持续开发、集成和部署：通过快速简单的回滚（由于镜像不可变性），支持可靠且频繁的 - 容器镜像构建和部署。 +* 持续开发、集成和部署：通过快速简单的回滚（由于镜像不可变性）， + 支持可靠且频繁的容器镜像构建和部署。 * 关注开发与运维的分离：在构建/发布时而不是在部署时创建应用程序容器镜像， 从而将应用程序与基础架构分离。 * 可观察性：不仅可以显示操作系统级别的信息和指标，还可以显示应用程序的运行状况和其他指标信号。 @@ -133,18 +133,18 @@ Containers are becoming popular because they have many benefits. Some of the con -## 为什么需要 Kubernetes，它能做什么? +## 为什么需要 Kubernetes，它能做什么？ {#why-you-need-kubernetes-and-what-can-it-do} -容器是打包和运行应用程序的好方式。在生产环境中，你需要管理运行应用程序的容器，并确保不会停机。 -例如，如果一个容器发生故障，则需要启动另一个容器。如果系统处理此行为，会不会更容易？ +容器是打包和运行应用程序的好方式。在生产环境中，你需要管理运行着应用程序的容器，并确保不会停机。 +例如，如果一个容器发生故障，则需要启动另一个容器。如果此行为交由给系统处理，是不是会更容易一些？ -这就是 Kubernetes 来解决这些问题的方法！ +这就是 Kubernetes 要来做的事情！ Kubernetes 为你提供了一个可弹性运行分布式系统的框架。 Kubernetes 会满足你的扩展要求、故障转移、部署模式等。 例如，Kubernetes 可以轻松管理系统的 Canary 部署。 @@ -160,7 +160,8 @@ Kubernetes can expose a container using the DNS name or using their own IP addre --> * **服务发现和负载均衡** - Kubernetes 可以使用 DNS 名称或自己的 IP 地址公开容器，如果进入容器的流量很大， + Kubernetes 可以使用 DNS 名称或自己的 IP 地址来公开容器。 + 如果进入容器的流量很大， Kubernetes 可以负载均衡并分配网络流量，从而使部署稳定。 * **自动部署和回滚** - 你可以使用 Kubernetes 描述已部署容器的所需状态，它可以以受控的速率将实际状态 - 更改为期望状态。例如，你可以自动化 Kubernetes 来为你的部署创建新容器， + 你可以使用 Kubernetes 描述已部署容器的所需状态， + 它可以以受控的速率将实际状态更改为期望状态。 + 例如，你可以自动化 Kubernetes 来为你的部署创建新容器， 删除现有容器并将它们的所有资源用于新容器。 * **自我修复** - Kubernetes 重新启动失败的容器、替换容器、杀死不响应用户定义的 - 运行状况检查的容器，并且在准备好服务之前不将其通告给客户端。 + Kubernetes 将重新启动失败的容器、替换容器、杀死不响应用户定义的运行状况检查的容器， + 并且在准备好服务之前不将其通告给客户端。 -## Kubernetes 不是什么 +## Kubernetes 不是什么 {#what-kubernetes-is-not} * 不要求日志记录、监视或警报解决方案。 它提供了一些集成作为概念证明，并提供了收集和导出指标的机制。 -* 不提供或不要求配置语言/系统（例如 jsonnet），它提供了声明性 API， +* 不提供也不要求配置语言、系统（例如 jsonnet），它提供了声明性 API， 该声明性 API 可以由任意形式的声明性规范所构成。 * 不提供也不采用任何全面的机器配置、维护、管理或自我修复系统。 * 此外，Kubernetes 不仅仅是一个编排系统，实际上它消除了编排的需要。 @@ -267,4 +269,4 @@ Kubernetes： * Ready to [Get Started](/docs/setup/)? --> * 查阅 [Kubernetes 组件](/zh/docs/concepts/overview/components/) -* 开始 [Kubernetes 入门](/zh/docs/setup/)？ +* 开始 [Kubernetes 的建置](/zh/docs/setup/) 吧！ diff --git a/content/zh/docs/concepts/overview/working-with-objects/common-labels.md b/content/zh/docs/concepts/overview/working-with-objects/common-labels.md index 2fbf964b27..629c3ca7da 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/common-labels.md +++ b/content/zh/docs/concepts/overview/working-with-objects/common-labels.md @@ -15,7 +15,8 @@ You can visualize and manage Kubernetes objects with more tools than kubectl and the dashboard. A common set of labels allows tools to work interoperably, describing objects in a common manner that all tools can understand. --> -除了 kubectl 和 dashboard 之外，您可以使用其他工具来可视化和管理 Kubernetes 对象。一组通用的标签可以让多个工具之间相互操作，用所有工具都能理解的通用方式描述对象。 +除了 kubectl 和 dashboard 之外，你可以使用其他工具来可视化和管理 Kubernetes 对象。 +一组通用的标签可以让多个工具之间相互操作，用所有工具都能理解的通用方式描述对象。 -使用 MySQL `StatefulSet` 和 `Service`，您会注意到有关 MySQL 和 Wordpress 的信息，包括更广泛的应用程序。 +使用 MySQL `StatefulSet` 和 `Service`，你会注意到有关 MySQL 和 Wordpress 的信息，包括更广泛的应用程序。 diff --git a/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md index 03722ea469..1e02d72fdd 100644 --- a/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -272,7 +272,7 @@ onto nodes labeled with `dedicated=groupName`. 然后给这组用户的 Pod 添加一个相对应的 toleration（通过编写一个自定义的 [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)，很容易就能做到）。 拥有上述容忍度的 Pod 就能够被分配到上述专用节点，同时也能够被分配到集群中的其它节点。 - 如果你希望这些 Pod 只能被分配到上述专用节点，那么您还需要给这些专用节点另外添加一个和上述 + 如果你希望这些 Pod 只能被分配到上述专用节点，那么你还需要给这些专用节点另外添加一个和上述 污点类似的 label （例如：`dedicated=groupName`），同时 还要在上述准入控制器中给 Pod 增加节点亲和性要求上述 Pod 只能被分配到添加了 `dedicated=groupName` 标签的节点上。 diff --git a/content/zh/docs/concepts/security/overview.md b/content/zh/docs/concepts/security/overview.md index 29cc2a06a2..9a9e9845a7 100644 --- a/content/zh/docs/concepts/security/overview.md +++ b/content/zh/docs/concepts/security/overview.md @@ -5,6 +5,15 @@ description: > content_type: concept weight: 1 --- + -## 云原生安全的 4 个 C +## 云原生安全的 4 个 C {#the-4c-s-of-cloud-native-security} 你可以分层去考虑安全性，云原生安全的 4 个 C 分别是云（Cloud）、集群（Cluster）、容器（Container）和代码（Code）。 @@ -53,7 +62,10 @@ security at the Code level. 云原生安全模型的每一层都是基于下一个最外层，代码层受益于强大的基础安全层（云、集群、容器）。 你无法通过在代码层解决安全问题来为基础层中糟糕的安全标准提供保护。 -## 云 + +## 云 {#cloud} -### 云提供商安全性 +### 云提供商安全性 {#cloud-provider-security} 如果你是在你自己的硬件或者其他不同的云提供商上运行 Kubernetes 集群， 请查阅相关文档来获取最好的安全实践。 @@ -137,7 +149,7 @@ There are two areas of concern for securing Kubernetes: * Securing the cluster components that are configurable * Securing the applications which run in the cluster --> -## 集群 +## 集群 {#cluster} 保护 Kubernetes 有两个方面需要注意： @@ -205,7 +217,7 @@ Image Signing and Enforcement | Sign container images to maintain a system of tr Disallow privileged users | When constructing containers, consult your documentation for how to create users inside of the containers that have the least level of operating system privilege necessary in order to carry out the goal of the container. Use container runtime with stronger isolation | Select [container runtime classes](/docs/concepts/containers/runtime-class/) that provide stronger isolation --> -## 容器 +## 容器 {#container} 容器安全性不在本指南的探讨范围内。下面是一些探索此主题的建议和连接： @@ -222,7 +234,7 @@ Application code is one of the primary attack surfaces over which you have the m While securing application code is outside of the Kubernetes security topic, here are recommendations to protect application code: --> -## 代码 +## 代码 {#code} 应用程序代码是你最能够控制的主要攻击面之一，虽然保护应用程序代码不在 Kubernetes 安全主题范围内，但以下是保护应用程序代码的建议： @@ -241,7 +253,7 @@ Dynamic probing attacks | There are a few automated tools that you can run again {{< /table >}} --> -### 代码安全性 +### 代码安全性 {#code-security} {{< table caption="代码安全" >}} @@ -250,7 +262,7 @@ Dynamic probing attacks | There are a few automated tools that you can run again 仅通过 TLS 访问 | 如果你的代码需要通过 TCP 通信，请提前与客户端执行 TLS 握手。除少数情况外，请加密传输中的所有内容。更进一步，加密服务之间的网络流量是一个好主意。这可以通过被称为双向 TLS 或 [mTLS](https://en.wikipedia.org/wiki/Mutual_authentication) 的过程来完成，该过程对两个证书持有服务之间的通信执行双向验证。 | 限制通信端口范围 | 此建议可能有点不言自明，但是在任何可能的情况下，你都只应公开服务上对于通信或度量收集绝对必要的端口。| 第三方依赖性安全 | 最好定期扫描应用程序的第三方库以了解已知的安全漏洞。每种编程语言都有一个自动执行此检查的工具。 | -静态代码分析 | 大多数语言都提供给了一种方法，来分析代码段中是否存在潜在的不安全的编码实践。只要有可能，你都应该使用自动工具执行检查，该工具可以扫描代码库以查找常见的安全错误，一些工具可以在以下连接中找到：https://owasp.org/www-community/Source_Code_Analysis_Tools | +静态代码分析 | 大多数语言都提供给了一种方法，来分析代码段中是否存在潜在的不安全的编码实践。只要有可能，你都应该使用自动工具执行检查，该工具可以扫描代码库以查找常见的安全错误，一些工具可以在以下连接中找到： https://owasp.org/www-community/Source_Code_Analysis_Tools | 动态探测攻击 | 你可以对服务运行一些自动化工具，来尝试一些众所周知的服务攻击。这些攻击包括 SQL 注入、CSRF 和 XSS。[OWASP Zed Attack](https://owasp.org/www-project-zap/) 代理工具是最受欢迎的动态分析工具之一。 | {{< /table >}} diff --git a/content/zh/docs/concepts/security/pod-security-admission.md b/content/zh/docs/concepts/security/pod-security-admission.md index 87fddd9ddb..54ae5436a0 100644 --- a/content/zh/docs/concepts/security/pod-security-admission.md +++ b/content/zh/docs/concepts/security/pod-security-admission.md @@ -33,7 +33,7 @@ Kubernetes [Pod 安全性标准（Security Standards）](/zh/docs/concepts/secur 为 Pod 定义不同的隔离级别。这些标准能够让你以一种清晰、一致的方式定义如何限制 Pod 行为。 -## 启用 `PodSecurity` 准入插件 {#enabling-the-podsecurity-admission-plugin} +## {{% heading "prerequisites" %}} -在 v1.23 中，`PodSecurity` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) -是一项 Beta 功能特性，默认被启用。 +要使用此机制，你的集群必须强制执行 Pod 安全准入。 -在 v1.22 中，`PodSecurity` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) -是一项 Alpha 功能特性，必须在 `kube-apiserver` 上启用才能使用内置的准入插件。 - -```shell ---feature-gates="...,PodSecurity=true" -``` +### 内置 Pod 安全准入强制执行 -## 替代方案：安装 `PodSecurity` 准入 Webhook {#webhook} +在 Kubernetes v{{< skew currentVersion >}} 中，`PodSecurity` +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)是一项 Beta 特性， +默认被启用。你必须启用此功能门控。如果你运行的是不同版本的 Kubernetes，请查阅该版本的文档。 -对于无法应用内置 `PodSecurity` 准入插件的环境，无论是因为集群版本低于 v1.22， -或者 `PodSecurity` 特性无法被启用，都可以使用 Beta 版本的 -[验证性准入 Webhook](https://git.k8s.io/pod-security-admission/webhook)。 -来使用 `PodSecurity` 准入逻辑。 + + + +### 替代方案：安装 `PodSecurity` 准入 Webhook {#webhook} + +`PodSecurity` 准入逻辑也可用作[验证性准入 Webhook](https://git.k8s.io/pod-security-admission/webhook)。 +该实现也是 Beta 版本。 +对于无法启用内置 `PodSecurity` 准入插件的环境，你可以改为通过验证准入 Webhook 启用该逻辑。 + diff --git a/content/zh/docs/concepts/security/windows-security.md b/content/zh/docs/concepts/security/windows-security.md new file mode 100644 index 0000000000..6636d676cd --- /dev/null +++ b/content/zh/docs/concepts/security/windows-security.md @@ -0,0 +1,109 @@ +--- +title: Windows 节点的安全性 +content_type: concept +weight: 75 +--- + + + + + +本篇介绍特定于 Windows 操作系统的安全注意事项和最佳实践。 + + + + +## 保护节点上的 Secret 数据 + + +在 Windows 上，来自 Secret 的数据以明文形式写入节点的本地存储 +（与在 Linux 上使用 tmpfs / 内存中文件系统不同）。 +作为集群操作员，你应该采取以下两项额外措施： + + +1. 使用文件 ACL 来保护 Secret 的文件位置。 +2. 使用 [BitLocker](https://docs.microsoft.com/windows/security/information-protection/bitlocker/bitlocker-how-to-deploy-on-windows-server) + 进行卷级加密。 + + +## 容器用户 + + +可以为 Windows Pod 或容器指定 [RunAsUsername](/zh/docs/tasks/configure-pod-container/configure-runasusername) +以作为特定用户执行容器进程。这大致相当于 [RunAsUser](/zh/docs/concepts/policy/pod-security-policy/#users-and-groups)。 + + +Windows 容器提供两个默认用户帐户，ContainerUser 和 ContainerAdministrator。 +在微软的 Windows 容器安全文档 +[何时使用 ContainerAdmin 和 ContainerUser 用户帐户](https://docs.microsoft.com/zh-cn/virtualization/windowscontainers/manage-containers/container-security#when-to-use-containeradmin-and-containeruser-user-accounts) +中介绍了这两个用户帐户之间的区别。 + + +在容器构建过程中，可以将本地用户添加到容器镜像中。 + +{{< note >}} + +* 基于 [Nano Server](https://hub.docker.com/_/microsoft-windows-nanoserver) 的镜像默认以 `ContainerUser` 运行 +* 基于 [Server Core](https://hub.docker.com/_/microsoft-windows-servercore) 的镜像默认以 `ContainerAdministrator` 运行 +{{< /note >}} + + +Windows 容器还可以通过使用[组管理的服务账号](/zh/docs/tasks/configure-pod-container/configure-gmsa/)作为 +Active Directory 身份运行。 + + +## Pod 级安全隔离 + + +Windows 节点不支持特定于 Linux 的 Pod 安全上下文机制（例如 SELinux、AppArmor、Seccomp 或自定义 POSIX 权能字）。 + + +Windows 上[不支持](/zh/docs/concepts/windows/intro/#compatibility-v1-pod-spec-containers-securitycontext)特权容器。 +然而，可以在 Windows 上使用 [HostProcess 容器](/zh/docs/tasks/configure-pod-container/create-hostprocess-pod)来执行 +Linux 上特权容器执行的许多任务。 \ No newline at end of file diff --git a/content/zh/docs/concepts/services-networking/dns-pod-service.md b/content/zh/docs/concepts/services-networking/dns-pod-service.md index 2b9dfeb36f..66b0381d9c 100644 --- a/content/zh/docs/concepts/services-networking/dns-pod-service.md +++ b/content/zh/docs/concepts/services-networking/dns-pod-service.md @@ -37,27 +37,27 @@ Kubernetes DNS 在集群上调度 DNS Pod 和服务，并配置 kubelet 以告 集群中定义的每个 Service （包括 DNS 服务器自身）都被赋予一个 DNS 名称。 默认情况下，客户端 Pod 的 DNS 搜索列表会包含 Pod 自身的名字空间和集群 的默认域。 ### Service 的名字空间 @@ -73,11 +73,11 @@ Pod 查询 `data` 时没有返回结果，因为使用的是 Pod 的名字空间 Pod 查询 `data.prod` 时则会返回预期的结果，因为查询中指定了名字空间。 DNS 查询可以使用 Pod 中的 `/etc/resolv.conf` 展开。kubelet 会为每个 Pod 生成此文件。例如，对 `data` 的查询可能被展开为 `data.test.svc.cluster.local`。 @@ -91,7 +91,7 @@ options ndots:5 ``` 概括起来，名字空间 `test` 中的 Pod 可以成功地解析 `data.prod` 或者 @@ -127,12 +127,14 @@ For more up-to-date specification, see ### A/AAAA records -"Normal" (not headless) Services are assigned a DNS A or AAAA record for a name of the -form `my-svc.my-namespace.svc.cluster-domain.example`. This resolves to the cluster IP +"Normal" (not headless) Services are assigned a DNS A or AAAA record, +depending on the IP family of the service, for a name of the form +`my-svc.my-namespace.svc.cluster-domain.example`. This resolves to the cluster IP of the Service. -"Headless" (without a cluster IP) Services are also assigned a DNS A record for -a name of the form `my-svc.my-namespace.svc.cluster-domain.example`. Unlike normal +"Headless" (without a cluster IP) Services are also assigned a DNS A or AAAA record, +depending on the IP family of the service, for a name of the form +`my-svc.my-namespace.svc.cluster-domain.example`. Unlike normal Services, this resolves to the set of IPs of the pods selected by the Service. Clients are expected to consume the set or else use standard round-robin selection from the set. @@ -314,9 +316,9 @@ along with its IP. Endpoints 对象可以为任何端点地址及其 IP 指定 `hostname`。 @@ -341,12 +343,13 @@ record unless `publishNotReadyAddresses=True` is set on the Service. {{< feature-state for_k8s_version="v1.22" state="stable" >}} -**前置条件**：`SetHostnameAsFQDN` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) -必须在 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}} -上启用。 +当 Pod 配置为具有全限定域名 (FQDN) 时，其主机名是短主机名。 + 例如，如果你有一个具有完全限定域名 `busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example` 的 Pod， + 则默认情况下，该 Pod 内的 `hostname` 命令返回 `busybox-1`，而 `hostname --fqdn` 命令返回 FQDN。 当你在 Pod 规约中设置了 `setHostnameAsFQDN: true` 时，kubelet 会将 Pod 的全限定域名（FQDN）作为该 Pod 的主机名记录到 Pod 所在名字空间。 @@ -392,10 +395,11 @@ following pod-specific DNS policies. These policies are specified in the for details on how DNS queries are handled in those cases. - "`ClusterFirstWithHostNet`": For Pods running with hostNetwork, you should explicitly set its DNS policy "`ClusterFirstWithHostNet`". + - Note: This is not supported on Windows. See [below](#dns-windows) for details - "`None`": It allows a Pod to ignore DNS settings from the Kubernetes environment. All DNS settings are supposed to be provided using the `dnsConfig` field in the Pod Spec. - See [Pod's DNS config](#pod-s-dns-config) subsection below. + See [Pod's DNS config](#pod-dns-config) subsection below. --> ### Pod 的 DNS 策略 {#pod-s-dns-policy} @@ -411,6 +415,7 @@ DNS 策略可以逐个 Pod 来设定。目前 Kubernetes 支持以下特定 Pod 了解在这些场景中如何处理 DNS 查询的信息。 - "`ClusterFirstWithHostNet`"：对于以 hostNetwork 方式运行的 Pod，应显式设置其 DNS 策略 "`ClusterFirstWithHostNet`"。 + - 注意：这在 Windows 上不支持。 有关详细信息，请参见[下文](#dns-windows)。 - "`None`": 此设置允许 Pod 忽略 Kubernetes 环境中的 DNS 设置。Pod 会使用其 `dnsConfig` 字段 所提供的 DNS 设置。 参见 [Pod 的 DNS 配置](#pod-dns-config)节。 @@ -450,7 +455,7 @@ spec: ``` -输出类似于 - +输出类似于： ``` nameserver fd00:79:30::a search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example @@ -565,6 +569,41 @@ a list of search domains of up to 2048 characters. 如果启用 kube-apiserver 和 kubelet 的特性门控 `ExpandedDNSConfig`，Kubernetes 将可以有最多 32 个 搜索域以及一个最多 2048 个字符的搜索域列表。 + +## Windows 节点上的 DNS 解析 {#dns-windows} + +- 在 Windows 节点上运行的 Pod 不支持 ClusterFirstWithHostNet。 + Windows 将所有带有 `.` 的名称视为全限定域名（FQDN）并跳过全限定域名（FQDN）解析。 +- 在 Windows 上，可以使用的 DNS 解析器有很多。 + 由于这些解析器彼此之间会有轻微的行为差别，建议使用 + [`Resolve-DNSName`](https://docs.microsoft.com/powershell/module/dnsclient/resolve-dnsname) + powershell cmdlet 进行名称查询解析。 +- 在 Linux 上，有一个 DNS 后缀列表，当解析全名失败时可以使用。 + 在 Windows 上，你只能有一个 DNS 后缀， + 即与该 Pod 的命名空间相关联的 DNS 后缀（例如：`mydns.svc.cluster.local`）。 + Windows 可以解析全限定域名（FQDN），和使用了该 DNS 后缀的服务名称或者网络名称。 + 例如，在 `default` 命名空间中生成一个 Pod，该 Pod 会获得的 DNS 后缀为 `default.svc.cluster.local`。 + 在 Windows 的 Pod 中，你可以解析 `kubernetes.default.svc.cluster.local` 和 `kubernetes`， + 但是不能解析部分限定名称（`kubernetes.default` 和 `kubernetes.default.svc`）。 + ## {{% heading "whatsnext" %}} * Kubernetes 1.20 版本或更高版本，有关更早 Kubernetes 版本的使用双栈服务的信息， 请参考对应版本的 Kubernetes 文档。 @@ -91,7 +91,10 @@ The following prerequisites are needed in order to utilize IPv4/IPv6 dual-stack --> ## 配置 IPv4/IPv6 双协议栈 - + +如果配置 IPv4/IPv6 双栈，请分配双栈集群网络： - `["IPv4"]` - `["IPv6"]` @@ -224,14 +226,13 @@ These examples demonstrate the behavior of various dual-stack Service configurat - 1. 此服务规约中没有显式设定 `.spec.ipFamilyPolicy`。当你创建此服务时，Kubernetes 从所配置的第一个 `service-cluster-ip-range` 种为服务分配一个集群IP，并设置 `.spec.ipFamilyPolicy` 为 `SingleStack`。 （[无选择算符的服务](/zh/docs/concepts/services-networking/service/#services-without-selectors) 和[无头服务](/zh/docs/concepts/services-networking/service/#headless-services)的行为方式 与此相同。） - + {{< codenew file="service/networking/dual-stack-default-svc.yaml" >}} 下面示例演示了在服务已经存在的集群上新启用双栈时的默认行为。 （将现有集群升级到 1.21 或者更高版本会启用双协议栈支持。） @@ -296,7 +297,7 @@ These examples demonstrate the default behavior when dual-stack is newly enabled ```shell kubectl get svc my-service -o yaml ``` - + ```yaml apiVersion: v1 kind: Service @@ -341,7 +342,7 @@ These examples demonstrate the default behavior when dual-stack is newly enabled ```shell kubectl get svc my-service -o yaml ``` - + ```yaml apiVersion: v1 kind: Service @@ -361,7 +362,7 @@ These examples demonstrate the default behavior when dual-stack is newly enabled protocol: TCP targetPort: 80 selector: - app: MyApp + app: MyApp ``` +## Windows 支持 + +Windows 上的 Kubernetes 不支持单栈“仅 IPv6” 网络。 然而， +对于 Pod 和节点而言，仅支持单栈形式服务的双栈 IPv4/IPv6 网络是被支持的。 + +你可以使用 `l2bridge` 网络来实现 IPv4/IPv6 双栈联网。 + +{{< note >}} +Windows 上的 Overlay (VXLAN) 网络**不**支持双栈网络。 +{{< /note >}} + +关于 Windows 的不同网络模式，你可以进一步阅读 +[Windows 上的网络](/zh/docs/concepts/services-networking/windows-networking#network-modes)。 + ## {{% heading "whatsnext" %}} * [验证 IPv4/IPv6 双协议栈](/zh/docs/tasks/network/validate-dual-stack)网络 * [使用 kubeadm 启用双协议栈网络](/zh/docs/setup/production-environment/tools/kubeadm/dual-stack-support/) diff --git a/content/zh/docs/concepts/services-networking/endpoint-slices.md b/content/zh/docs/concepts/services-networking/endpoint-slices.md index 447caae39c..05f808a1a9 100644 --- a/content/zh/docs/concepts/services-networking/endpoint-slices.md +++ b/content/zh/docs/concepts/services-networking/endpoint-slices.md @@ -52,11 +52,11 @@ significant amounts of network traffic and processing when Endpoints changed. EndpointSlices help you mitigate those issues as well as provide an extensible platform for additional features such as topological routing. --> -由于任一服务的所有网络端点都保存在同一个 Endpoints 资源中，这类资源可能变得 -非常巨大，而这一变化会影响到 Kubernetes 组件（比如主控组件）的性能，并 -在 Endpoints 变化时产生大量的网络流量和额外的处理。 -EndpointSlice 能够帮助你缓解这一问题，还能为一些诸如拓扑路由这类的额外 -功能提供一个可扩展的平台。 +由于任一 Service 的所有网络端点都保存在同一个 Endpoints 资源中， +这类资源可能变得非常巨大，而这一变化会影响到 Kubernetes +组件（比如主控组件）的性能，并在 Endpoints 变化时产生大量的网络流量和额外的处理。 +EndpointSlice 能够帮助你缓解这一问题， +还能为一些诸如拓扑路由这类的额外功能提供一个可扩展的平台。 -在 v1 API 中，逐个端点设置的 `topology` 实际上被去除，以鼓励使用专用 -的字段 `nodeName` 和 `zone`。 +在 v1 API 中，逐个端点设置的 `topology` 实际上被去除， +以鼓励使用专用的字段 `nodeName` 和 `zone`。 -对 `EndpointSlice` 对象的 `endpoint` 字段设置任意的拓扑结构信息这一操作已被 -废弃，不再被 v1 API 所支持。取而代之的是 v1 API 所支持的 `nodeName` 和 `zone` +对 `EndpointSlice` 对象的 `endpoint` 字段设置任意的拓扑结构信息这一操作已被废弃， +不再被 v1 API 所支持。取而代之的是 v1 API 所支持的 `nodeName` 和 `zone` 这些独立的字段。这些字段可以在不同的 API 版本之间自动完成转译。 -例如，v1beta1 API 中 `topology` 字段的 `topology.kubernetes.io/zone` 取值可以 -在 v1 API 中通过 `zone` 字段访问。 +例如，v1beta1 API 中 `topology` 字段的 `topology.kubernetes.io/zone` +取值可以在 v1 API 中通过 `zone` 字段访问。 {{< /note >}} ### 属主关系 {#ownership} -在大多数场合下，EndpointSlice 都由某个 Service 所有，（因为）该端点切片正是 -为该服务跟踪记录其端点。这一属主关系是通过为每个 EndpointSlice 设置一个 -属主（owner）引用，同时设置 `kubernetes.io/service-name` 标签来标明的， -目的是方便查找隶属于某服务的所有 EndpointSlice。 +在大多数场合下，EndpointSlice 都由某个 Service 所有， +（因为）该端点切片正是为该服务跟踪记录其端点。这一属主关系是通过为每个 EndpointSlice +设置一个属主（owner）引用，同时设置 `kubernetes.io/service-name` 标签来标明的， +目的是方便查找隶属于某 Service 的所有 EndpointSlice。 ### EndpointSlice 镜像 {#endpointslice-mirroring} -在某些场合，应用会创建定制的 Endpoints 资源。为了保证这些应用不需要并发 -的更改 Endpoints 和 EndpointSlice 资源，集群的控制面将大多数 Endpoints +在某些场合，应用会创建定制的 Endpoints 资源。为了保证这些应用不需要并发的更改 +Endpoints 和 EndpointSlice 资源，集群的控制面将大多数 Endpoints 映射到对应的 EndpointSlice 之上。 -控制面尝试尽量将 EndpointSlice 填满，不过不会主动地在若干 EndpointSlice 之间 -执行再平衡操作。这里的逻辑也是相对直接的： +控制面尝试尽量将 EndpointSlice 填满，不过不会主动地在若干 EndpointSlice +之间执行再平衡操作。这里的逻辑也是相对直接的： -1. 列举所有现有的 EndpointSlices，移除那些不再需要的端点并更新那些已经 - 变化的端点。 +1. 列举所有现有的 EndpointSlices，移除那些不再需要的端点并更新那些已经变化的端点。 2. 列举所有在第一步中被更改过的 EndpointSlices，用新增加的端点将其填满。 3. 如果还有新的端点未被添加进去，尝试将这些端点添加到之前未更改的切片中， 或者创建新切片。 @@ -403,11 +402,11 @@ this approach will create a new EndpointSlice instead of filling up the 2 existing EndpointSlices. In other words, a single EndpointSlice creation is preferrable to multiple EndpointSlice updates. --> -这里比较重要的是，与在 EndpointSlice 之间完成最佳的分布相比，第三步中更看重 -限制 EndpointSlice 更新的操作次数。例如，如果有 10 个端点待添加，有两个 -EndpointSlice 中各有 5 个空位，上述方法会创建一个新的 EndpointSlice 而不是 -将现有的两个 EndpointSlice 都填满。换言之，与执行多个 EndpointSlice 更新操作 -相比较，方法会优先考虑执行一个 EndpointSlice 创建操作。 +这里比较重要的是，与在 EndpointSlice 之间完成最佳的分布相比，第三步中更看重限制 +EndpointSlice 更新的操作次数。例如，如果有 10 个端点待添加，有两个 EndpointSlice +中各有 5 个空位，上述方法会创建一个新的 EndpointSlice 而不是将现有的两个 +EndpointSlice 都填满。换言之，与执行多个 EndpointSlice 更新操作相比较， +方法会优先考虑执行一个 EndpointSlice 创建操作。 -由于 kube-proxy 在每个节点上运行并监视 EndpointSlice 状态，EndpointSlice 的 -每次变更都变得相对代价较高，因为这些状态变化要传递到集群中每个节点上。 -这一方法尝试限制要发送到所有节点上的变更消息个数，即使这样做可能会导致有 -多个 EndpointSlice 没有被填满。 +由于 kube-proxy 在每个节点上运行并监视 EndpointSlice 状态，EndpointSlice +的每次变更都变得相对代价较高，因为这些状态变化要传递到集群中每个节点上。 +这一方法尝试限制要发送到所有节点上的变更消息个数，即使这样做可能会导致有多个 +EndpointSlice 没有被填满。 -在实践中，上面这种并非最理想的分布是很少出现的。大多数被 EndpointSlice 控制器 -处理的变更都是足够小的，可以添加到某已有 EndpointSlice 中去的。并且，假使无法 -添加到已有的切片中，不管怎样都会快就会需要一个新的 EndpointSlice 对象。 -Deployment 的滚动更新为重新为 EndpointSlice 打包提供了一个自然的机会，所有 -Pod 及其对应的端点在这一期间都会被替换掉。 +在实践中，上面这种并非最理想的分布是很少出现的。大多数被 EndpointSlice +控制器处理的变更都是足够小的，可以添加到某已有 EndpointSlice 中去的。 +并且，假使无法添加到已有的切片中，不管怎样都会快就会需要一个新的 +EndpointSlice 对象。Deployment 的滚动更新为重新为 EndpointSlice +打包提供了一个自然的机会，所有 Pod 及其对应的端点在这一期间都会被替换掉。 -* 阅读[使用服务连接应用](/zh/docs/concepts/services-networking/connect-applications-service/) +* 阅读[使用 Service 连接到应用](/zh/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/zh/docs/concepts/services-networking/ingress-controllers.md b/content/zh/docs/concepts/services-networking/ingress-controllers.md index a85e073404..06a4c948bd 100644 --- a/content/zh/docs/concepts/services-networking/ingress-controllers.md +++ b/content/zh/docs/concepts/services-networking/ingress-controllers.md @@ -158,8 +158,9 @@ You mark an IngressClass as default by setting the [`ingressclass.kubernetes.io/ Ideally, all ingress controllers should fulfill this specification, but the various ingress controllers operate slightly differently. --> -如果你不为 Ingress 指定一个 IngressClass，并且你的集群中只有一个 IngressClass 被标记为了集群默认，那么 -Kubernetes 会[应用](/zh/docs/concepts/services-networking/ingress/#default-ingress-class)此默认 +如果你不为 Ingress 指定 IngressClass，并且你的集群中只有一个 IngressClass 被标记为默认，那么 +Kubernetes 会将此集群的默认 IngressClass +[应用](/zh/docs/concepts/services-networking/ingress/#default-ingress-class)到 Ingress 上。 IngressClass。 你可以通过将 [`ingressclass.kubernetes.io/is-default-class` 注解](/zh/docs/reference/labels-annotations-taints/#ingressclass-kubernetes-io-is-default-class) diff --git a/content/zh/docs/concepts/services-networking/network-policies.md b/content/zh/docs/concepts/services-networking/network-policies.md index c1d0fa6de0..ef2884c281 100644 --- a/content/zh/docs/concepts/services-networking/network-policies.md +++ b/content/zh/docs/concepts/services-networking/network-policies.md @@ -13,7 +13,7 @@ weight: 50 如果你希望在 IP 地址或端口层面（OSI 第 3 层或第 4 层）控制网络流量， 则你可以考虑为集群中特定应用使用 Kubernetes 网络策略（NetworkPolicy）。 @@ -21,6 +21,7 @@ NetworkPolicy 是一种以应用为中心的结构，允许你设置如何允许 {{< glossary_tooltip text="Pod" term_id="pod">}} 与网络上的各类网络“实体” （我们这里使用实体以避免过度使用诸如“端点”和“服务”这类常用术语， 这些术语在 Kubernetes 中有特定含义）通信。 +NetworkPolicies 适用于一端或两端与 Pod 的连接，与其他连接无关。 -## Pod 隔离的两种类型 +## Pod 隔离的两种类型 {#the-two-sorts-of-pod-isolation} Pod 有两种隔离: 出口的隔离和入口的隔离。它们涉及到可以建立哪些连接。 这里的“隔离”不是绝对的，而是意味着“有一些限制”。 @@ -90,7 +91,7 @@ By default, a pod is non-isolated for ingress; all inbound connections are allow 默认情况下，一个 Pod 对入口是非隔离的，即所有入站连接都是被允许的。如果有任何的 NetworkPolicy 选择该 Pod 并在其 `policyTypes` 中包含 “Ingress”，则该 Pod 被隔离入口， -我们称这种策略适用于该 Pod 的入口。 当一个 Pod 的入口被隔离时，唯一允许进入该 Pod +我们称这种策略适用于该 Pod 的入口。当一个 Pod 的入口被隔离时，唯一允许进入该 Pod 的连接是来自该 Pod 节点的连接和适用于入口的 Pod 的某个 NetworkPolicy 的 `ingress` 列表所允许的连接。这些 `ingress` 列表的效果是相加的。 @@ -134,7 +135,7 @@ POSTing this to the API server for your cluster will have no effect unless your __Mandatory Fields__: As with all other Kubernetes config, a NetworkPolicy needs `apiVersion`, `kind`, and `metadata` fields. For general information about working with config files, see -[Configure Containers Using a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/), +[Configure a Pod to Use a ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/), and [Object Management](/docs/concepts/overview/working-with-objects/object-management). __spec__: NetworkPolicy [spec](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) has all the information needed to define a particular network policy in the given namespace. @@ -143,7 +144,7 @@ __podSelector__: Each NetworkPolicy includes a `podSelector` which selects the g --> __必需字段__：与所有其他的 Kubernetes 配置一样，NetworkPolicy 需要 `apiVersion`、 `kind` 和 `metadata` 字段。关于配置文件操作的一般信息，请参考 -[使用 ConfigMap 配置容器](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/), +[配置 Pod 以使用 ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/), 和[对象管理](/zh/docs/concepts/overview/working-with-objects/object-management)。 __spec__：NetworkPolicy [规约](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) @@ -169,7 +170,7 @@ __policyTypes__: 每个 NetworkPolicy 都包含一个 `policyTypes` 列表，其 __ingress__: 每个 NetworkPolicy 可包含一个 `ingress` 规则的白名单列表。 每个规则都允许同时匹配 `from` 和 `ports` 部分的流量。示例策略中包含一条 -简单的规则： 它匹配某个特定端口，来自三个来源中的一个，第一个通过 `ipBlock` +简单的规则：它匹配某个特定端口，来自三个来源中的一个，第一个通过 `ipBlock` 指定，第二个通过 `namespaceSelector` 指定，第三个通过 `podSelector` 指定。 __egress__: 每个 NetworkPolicy 可包含一个 `egress` 规则的白名单列表。 @@ -180,7 +181,7 @@ __egress__: 每个 NetworkPolicy 可包含一个 `egress` 规则的白名单列 So, the example NetworkPolicy: 1. isolates "role=db" pods in the "default" namespace for both ingress and egress traffic (if they weren't already isolated) -2. (Ingress rules) allows connections to all pods in the “default” namespace with the label “role=db” on TCP port 6379 from: +2. (Ingress rules) allows connections to all pods in the "default" namespace with the label "role=db" on TCP port 6379 from: * any pod in the "default" namespace with the label "role=frontend" * any pod in a namespace with the label "project=myproject" @@ -227,7 +228,7 @@ Pod，应将其允许作为入站流量来源或出站流量目的地。 __namespaceSelector__：此选择器将选择特定的名字空间，应将所有 Pod 用作其 入站流量来源或出站流量目的地。 -__namespaceSelector__ *和* __podSelector__： 一个指定 `namespaceSelector` +__namespaceSelector__ *和* __podSelector__：一个指定 `namespaceSelector` 和 `podSelector` 的 `to`/`from` 条目选择特定名字空间中的特定 Pod。 注意使用正确的 YAML 语法；下面的策略： @@ -316,40 +317,47 @@ in that namespace. -### 默认拒绝所有入站流量 +### 默认拒绝所有入站流量 {#default-deny-all-ingress-traffic} + 你可以通过创建选择所有容器但不允许任何进入这些容器的入站流量的 NetworkPolicy 来为名字空间创建 “default” 隔离策略。 {{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}} -这样可以确保即使容器没有选择其他任何 NetworkPolicy，也仍然可以被隔离。 -此策略不会更改默认的出口隔离行为。 +这确保即使没有被任何其他 NetworkPolicy 选择的 Pod 仍将被隔离以进行入口。 +此策略不影响任何 Pod 的出口隔离。 -### 默认允许所有入站流量 +### 允许所有入站流量 {#allow-all-ingress-traffic} -如果要允许所有流量进入某个名字空间中的所有 Pod（即使添加了导致某些 Pod 被视为 -“隔离”的策略），则可以创建一个策略来明确允许该名字空间中的所有流量。 + +如果你想允许一个命名空间中所有 Pod 的所有入站连接，你可以创建一个明确允许的策略。 {{< codenew file="service/networking/network-policy-allow-all-ingress.yaml" >}} + +有了这个策略，任何额外的策略都不会导致到这些 Pod 的任何入站连接被拒绝。 +此策略对任何 Pod 的出口隔离没有影响。 + -### 默认拒绝所有出站流量 +### 默认拒绝所有出站流量 {#default-deny-all-egress-traffic} 你可以通过创建选择所有容器但不允许来自这些容器的任何出站流量的 NetworkPolicy 来为名字空间创建 “default” 隔离策略。 @@ -358,29 +366,36 @@ You can create a "default" egress isolation policy for a namespace by creating a 此策略可以确保即使没有被其他任何 NetworkPolicy 选择的 Pod 也不会被允许流出流量。 -此策略不会更改默认的入站流量隔离行为。 +此策略不会更改任何 Pod 的入站流量隔离行为。 -### 默认允许所有出站流量 +### 允许所有出站流量 {#allow-all-egress-traffic} -如果要允许来自名字空间中所有 Pod 的所有流量（即使添加了导致某些 Pod 被视为“隔离”的策略）， -则可以创建一个策略，该策略明确允许该名字空间中的所有出站流量。 + +如果要允许来自命名空间中所有 Pod 的所有连接， +则可以创建一个明确允许来自该命名空间中 Pod 的所有出站连接的策略。 {{< codenew file="service/networking/network-policy-allow-all-egress.yaml" >}} + +有了这个策略，任何额外的策略都不会导致来自这些 Pod 的任何出站连接被拒绝。 +此策略对进入任何 Pod 的隔离没有影响。 + -### 默认拒绝所有入口和所有出站流量 +### 默认拒绝所有入站和所有出站流量 {#default-deny-all-ingress-and-all-egress-traffic} 你可以为名字空间创建“默认”策略，以通过在该名字空间中创建以下 NetworkPolicy 来阻止所有入站和出站流量。 @@ -396,7 +411,7 @@ This ensures that even pods that aren't selected by any other NetworkPolicy will -## SCTP 支持 +## SCTP 支持 {#sctp-support} {{< feature-state for_k8s_version="v1.20" state="stable" >}} @@ -465,7 +480,10 @@ port is between the range 32000 and 32768. -## 通过网络策略（至少目前还）无法完成的工作 +## 通过网络策略（至少目前还）无法完成的工作 {#what-you-can-t-do-with-network-policies-at-least-not-yet} 到 Kubernetes {{< skew latestVersion >}} 为止，NetworkPolicy API 还不支持以下功能，不过 你可能可以使用操作系统组件（如 SELinux、OpenVSwitch、IPTables 等等） diff --git a/content/zh/docs/concepts/services-networking/service.md b/content/zh/docs/concepts/services-networking/service.md index 3d2db97c3c..be64669d1c 100644 --- a/content/zh/docs/concepts/services-networking/service.md +++ b/content/zh/docs/concepts/services-networking/service.md @@ -39,7 +39,7 @@ Kubernetes 为 Pods 提供自己的 IP 地址，并为一组 Pod 提供相同的 ## Motivation Kubernetes {{< glossary_tooltip term_id="pod" text="Pods" >}} are created and destroyed -to match the state of your cluster. Pods are nonpermanent resources. +to match the desired state of your cluster. Pods are nonpermanent resources. If you use a {{< glossary_tooltip term_id="deployment" >}} to run your app, it can create and destroy Pods dynamically. @@ -57,7 +57,7 @@ Enter _Services_. ## 动机 -创建和销毁 Kubernetes {{< glossary_tooltip term_id="pod" text="Pod" >}} 以匹配集群状态。 +创建和销毁 Kubernetes {{< glossary_tooltip term_id="pod" text="Pod" >}} 以匹配集群的期望状态。 Pod 是非永久性资源。 如果你使用 {{< glossary_tooltip term_id="deployment">}} 来运行你的应用程序，则它可以动态创建和销毁 Pod。 @@ -189,13 +189,55 @@ field. +Pod 中的端口定义是有名字的，你可以在 Service 的 `targetPort` 属性中引用这些名称。 +例如，我们可以通过以下方式将 Service 的 `targetPort` 绑定到 Pod 端口： +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: nginx + labels: + app.kubernetes.io/name: proxy +spec: + containers: + - name: nginx + image: nginx:11.14.2 + ports: + - containerPort: 80 + name: http-web-svc + +--- +apiVersion: v1 +kind: Service +metadata: + name: nginx-service +spec: + selector: + app.kubernetes.io/name: proxy + ports: + - name: name-of-service-port + protocol: TCP + port: 80 + targetPort: http-web-svc +``` + + +即使 Service 中使用同一配置名称混合使用多个 Pod，各 Pod 通过不同的端口号支持相同的网络协议， +此功能也可以使用。这为 Service 的部署和演化提供了很大的灵活性。 +例如，你可以在新版本中更改 Pod 中后端软件公开的端口号，而不会破坏客户端。 + + + -Pod 中的端口定义是有名字的，你可以在服务的 `targetPort` 属性中引用这些名称。 -即使服务中使用单个配置的名称混合使用 Pod，并且通过不同的端口号提供相同的网络协议，此功能也可以使用。 -这为部署和发展服务提供了很大的灵活性。 -例如，你可以更改 Pods 在新版本的后端软件中公开的端口号，而不会破坏客户端。 + 服务的默认协议是 TCP；你还可以使用任何其他[受支持的协议](#protocol-support)。 @@ -216,9 +255,9 @@ Pod 中的端口定义是有名字的，你可以在服务的 `targetPort` 属 ### 没有选择算符的 Service {#services-without-selectors} -服务最常见的是抽象化对 Kubernetes Pod 的访问，但是它们也可以抽象化其他种类的后端。 -实例: +由于选择器的存在，服务最常见的用法是为 Kubernetes Pod 的访问提供抽象， +但是当与相应的 Endpoints 对象一起使用且没有选择器时， +服务也可以为其他类型的后端提供抽象，包括在集群外运行的后端。 +例如： * 希望在生产环境中使用外部的数据库集群，但测试环境使用自己的数据库。 * 希望服务指向另一个 {{< glossary_tooltip term_id="namespace" >}} 中或其它集群中的服务。 @@ -590,6 +631,14 @@ You can also set the maximum session sticky time by setting 来设置最大会话停留时间。 （默认值为 10800 秒，即 3 小时）。 + +{{< note >}} +在 Windows 上，不支持为服务设置最大会话停留时间。 +{{< /note >}} + + @@ -751,11 +800,7 @@ Kubernetes 支持两种基本的服务发现模式 —— 环境变量和 DNS。 ### Environment variables When a Pod is run on a Node, the kubelet adds a set of environment variables -for each active Service. It supports both [Docker links -compatible](https://docs.docker.com/userguide/dockerlinks/) variables (see -[makeLinkVariables](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L49)) -and simpler `{SVCNAME}_SERVICE_HOST` and `{SVCNAME}_SERVICE_PORT` variables, -where the Service name is upper-cased and dashes are converted to underscores. +for each active Service. It adds `{SVCNAME}_SERVICE_HOST` and `{SVCNAME}_SERVICE_PORT` variables, where the Service name is upper-cased and dashes are converted to underscores. It also supports variables (see [makeLinkVariables](https://github.com/kubernetes/kubernetes/blob/dd2d12f6dc0e654c15d5db57a5f9f6ba61192726/pkg/kubelet/envvars/envvars.go#L72)) that are compatible with Docker Engine's "_[legacy container links](https://docs.docker.com/network/links/)_" feature. For example, the Service `redis-master` which exposes TCP port 6379 and has been allocated cluster IP address 10.0.0.11, produces the following environment @@ -764,10 +809,10 @@ variables: ### 环境变量 {#environment-variables} 当 Pod 运行在 `Node` 上，kubelet 会为每个活跃的 Service 添加一组环境变量。 -它同时支持 [Docker links兼容](https://docs.docker.com/userguide/dockerlinks/) 变量 -（查看 [makeLinkVariables](https://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L49)）、 -简单的 `{SVCNAME}_SERVICE_HOST` 和 `{SVCNAME}_SERVICE_PORT` 变量。 +kubelet 为 Pod 添加环境变量 `{SVCNAME}_SERVICE_HOST` 和 `{SVCNAME}_SERVICE_PORT`。 这里 Service 的名称需大写，横线被转换成下划线。 +它还支持与 Docker Engine 的 "_[legacy container links](https://docs.docker.com/network/links/)_" 特性兼容的变量 +（参阅 [makeLinkVariables](https://github.com/kubernetes/kubernetes/blob/dd2d12f6dc0e654c15d5db57a5f9f6ba61192726/pkg/kubelet/envvars/envvars.go#L72)) 。 举个例子，一个名称为 `redis-master` 的 Service 暴露了 TCP 端口 6379， 同时给它分配了 Cluster IP 地址 10.0.0.11，这个 Service 生成了如下环境变量： @@ -1145,13 +1190,15 @@ securityGroupName。 #### 混合协议类型的负载均衡器 @@ -1160,14 +1207,16 @@ If the feature gate `MixedProtocolLBService` is enabled for the kube-apiserver i 默认情况下，对于 LoadBalancer 类型的服务，当定义了多个端口时，所有 端口必须具有相同的协议，并且该协议必须是受云提供商支持的协议。 -如果为 kube-apiserver 启用了 `MixedProtocolLBService` 特性门控， -则当定义了多个端口时，允许使用不同的协议。 +当服务中定义了多个端口时，特性门控 `MixedProtocolLBService`（在 kube-apiserver 1.24 版本默认为启用）允许 +LoadBalancer 类型的服务使用不同的协议。 {{< note >}} 可用于 LoadBalancer 类型服务的协议集仍然由云提供商决定。 +如果云提供商不支持混合协议，他们将只提供单一协议。 {{< /note >}} ### 禁用负载均衡器节点端口分配 {#load-balancer-nodeport-allocation} -{{< feature-state for_k8s_version="v1.20" state="alpha" >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} -从 v1.20 版本开始， 你可以通过设置 `spec.allocateLoadBalancerNodePorts` 为 `false` +你可以通过设置 `spec.allocateLoadBalancerNodePorts` 为 `false` 对类型为 LoadBalancer 的服务禁用节点端口分配。 这仅适用于直接将流量路由到 Pod 而不是使用节点端口的负载均衡器实现。 默认情况下，`spec.allocateLoadBalancerNodePorts` 为 `true`， LoadBalancer 类型的服务继续分配节点端口。 如果现有服务已被分配节点端口，将参数 `spec.allocateLoadBalancerNodePorts` -设置为 `false` 时，这些服务上已分配置的节点端口不会被自动释放。 +设置为 `false` 时，这些服务上已分配置的节点端口**不会**被自动释放。 你必须显式地在每个服务端口中删除 `nodePorts` 项以释放对应端口。 -你必须启用 `ServiceLBNodePortControl` 特性门控才能使用该字段。 #### 设置负载均衡器实现的类别 {#load-balancer-class} -{{< feature-state for_k8s_version="v1.22" state="beta" >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} `spec.loadBalancerClass` 允许你不使用云提供商的默认负载均衡器实现，转而使用指定的负载均衡器实现。 -这个特性从 v1.21 版本开始可以使用，你在 v1.21 版本中使用这个字段必须启用 `ServiceLoadBalancerClass` -特性门控，这个特性门控从 v1.22 版本及以后默认打开。 默认情况下，`.spec.loadBalancerClass` 的取值是 `nil`，如果集群使用 `--cloud-provider` 配置了云提供商， `LoadBalancer` 类型服务会使用云提供商的默认负载均衡器实现。 如果设置了 `.spec.loadBalancerClass`，则假定存在某个与所指定的类相匹配的 @@ -1972,7 +2017,8 @@ someone else's choice. That is an isolation failure. In order to allow you to choose a port number for your Services, we must ensure that no two Services can collide. Kubernetes does that by allocating each -Service its own IP address. +Service its own IP address from within the `service-cluster-ip-range` +CIDR range that is configured for the API server. To ensure each Service receives a unique IP, an internal allocator atomically updates a global allocation map in {{< glossary_tooltip term_id="etcd" >}} @@ -1992,8 +2038,9 @@ Kubernetes 最主要的哲学之一，是用户不应该暴露那些能够导致 对于 Service 资源的设计，这意味着如果用户的选择有可能与他人冲突，那就不要让用户自行选择端口号。 这是一个隔离性的失败。 -为了使用户能够为他们的 Service 选择一个端口号，我们必须确保不能有2个 Service 发生冲突。 -Kubernetes 通过为每个 Service 分配它们自己的 IP 地址来实现。 +为了使用户能够为他们的 Service 选择一个端口号，我们必须确保不能有 2 个 Service 发生冲突。 +Kubernetes 通过在为 API 服务器配置的 `service-cluster-ip-range` CIDR +范围内为每个服务分配自己的 IP 地址来实现。 为了保证每个 Service 被分配到一个唯一的 IP，需要一个内部的分配器能够原子地更新 {{< glossary_tooltip term_id="etcd" >}} 中的一个全局分配映射表， @@ -2006,6 +2053,42 @@ Kubernetes 通过为每个 Service 分配它们自己的 IP 地址来实现。 同时 Kubernetes 会通过控制器检查不合理的分配（如管理员干预导致的） 以及清理已被分配但不再被任何 Service 使用的 IP 地址。 + +#### `type: ClusterIP` 服务的 IP 地址范围 {#service-ip-static-sub-range} + +{{< feature-state for_k8s_version="v1.24" state="alpha" >}} +但是，这种 `ClusterIP` 分配策略存在一个问题，因为用户还可以[为服务选择自己的地址](#choosing-your-own-ip-address)。 +如果内部分配器为另一个服务选择相同的 IP 地址，这可能会导致冲突。 + + +如果启用 `ServiceIPStaticSubrange`[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， +分配策略根据配置的 `service-cluster-ip-range` 的大小，使用以下公式 +`min(max(16, cidrSize / 16), 256)` 进行划分，该公式可描述为 +“在不小于 16 且不大于 256 之间有一个步进量（Graduated Step）”，将 +`ClusterIP` 范围分成两段。动态 IP 分配将优先从上半段地址中选择， +从而降低与下半段地址分配的 IP 冲突的风险。 +这允许用户将 `service-cluster-ip-range` 的下半段地址用于他们的服务， +与所分配的静态 IP 的冲突风险非常低。 + +### PersistentVolume 删除保护 finalizer {#persistentvolume-deletion-protection-finalizer} +{{< feature-state for_k8s_version="v1.23" state="alpha" >}} + +可以在 PersistentVolume 上添加终结器（Finalizers），以确保只有在删除对应的存储后才删除具有 +`Delete` 回收策略的 PersistentVolume。 + + +新引入的 `kubernetes.io/pv-controller` 和 `external-provisioner.volume.kubernetes.io/finalizer` +终结器仅会被添加到动态制备的卷上。 + +终结器 `kubernetes.io/pv-controller` 会被添加到树内插件卷上。 +下面是一个例子： + +```shell +kubectl describe pv pvc-74a498d6-3929-47e8-8c02-078c1ece4d78 +Name: pvc-74a498d6-3929-47e8-8c02-078c1ece4d78 +Labels: +Annotations: kubernetes.io/createdby: vsphere-volume-dynamic-provisioner + pv.kubernetes.io/bound-by-controller: yes + pv.kubernetes.io/provisioned-by: kubernetes.io/vsphere-volume +Finalizers: [kubernetes.io/pv-protection kubernetes.io/pv-controller] +StorageClass: vcp-sc +Status: Bound +Claim: default/vcp-pvc-1 +Reclaim Policy: Delete +Access Modes: RWO +VolumeMode: Filesystem +Capacity: 1Gi +Node Affinity: +Message: +Source: + Type: vSphereVolume (a Persistent Disk resource in vSphere) + VolumePath: [vsanDatastore] d49c4a62-166f-ce12-c464-020077ba5d46/kubernetes-dynamic-pvc-74a498d6-3929-47e8-8c02-078c1ece4d78.vmdk + FSType: ext4 + StoragePolicyName: vSAN Default Storage Policy +Events: +``` + + +终结器 `external-provisioner.volume.kubernetes.io/finalizer` 会被添加到 CSI 卷上。下面是一个例子： + +```shell +Name: pvc-2f0bab97-85a8-4552-8044-eb8be45cf48d +Labels: +Annotations: pv.kubernetes.io/provisioned-by: csi.vsphere.vmware.com +Finalizers: [kubernetes.io/pv-protection external-provisioner.volume.kubernetes.io/finalizer] +StorageClass: fast +Status: Bound +Claim: demo-app/nginx-logs +Reclaim Policy: Delete +Access Modes: RWO +VolumeMode: Filesystem +Capacity: 200Mi +Node Affinity: +Message: +Source: + Type: CSI (a Container Storage Interface (CSI) volume source) + Driver: csi.vsphere.vmware.com + FSType: ext4 + VolumeHandle: 44830fa8-79b4-406b-8b58-621ba25353fd + ReadOnly: false + VolumeAttributes: storage.kubernetes.io/csiProvisionerIdentity=1648442357185-8081-csi.vsphere.vmware.com + type=vSphere CNS Block Volume +Events: +``` + + +为特定的树内卷插件启用 `CSIMigration` 特性将删除 `kubernetes.io/pv-controller` 终结器， +同时添加 `external-provisioner.volume.kubernetes.io/finalizer` 终结器。 +同样，禁用 `CSIMigration` 将删除 `external-provisioner.volume.kubernetes.io/finalizer` 终结器， +同时添加 `kubernetes.io/pv-controller` 终结器。 + #### 重设使用中 PVC 申领的大小 {#resizing-an-in-use-persistentvolumevlaim} -{{< feature-state for_k8s_version="v1.15" state="beta" >}} - - -{{< note >}} -Kubernetes 从 1.15 版本开始将调整使用中 PVC 申领大小这一能力作为 Beta -特性支持；该特性在 1.11 版本以来处于 Alpha 阶段。 -`ExpandInUsePersistentVolumes` 特性必须被启用；在很多集群上，与此类似的 -Beta 阶段的特性是自动启用的。 -可参考[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) -文档了解更多信息。 -{{< /note >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} {{< note >}} Kubernetes 从 1.23 版本开始将允许用户恢复失败的 PVC 扩展这一能力作为 -alpha 特性支持。 `RecoverVolumeExpansionFailure` 必须被启用以允许使用此功能。 +alpha 特性支持。 `RecoverVolumeExpansionFailure` 必须被启用以允许使用此特性。 可参考[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) 文档了解更多信息。 {{< /note >}} -如果集群中的特性门控 `ExpandPersistentVolumes` 和 `RecoverVolumeExpansionFailure` -都已启用，在 PVC 的扩展发生失败时，你可以使用比先前请求的值更小的尺寸来重试扩展。 +如果集群中的特性门控 `RecoverVolumeExpansionFailure` +已启用，在 PVC 的扩展发生失败时，你可以使用比先前请求的值更小的尺寸来重试扩展。 要使用一个更小的尺寸尝试请求新的扩展，请编辑该 PVC 的 `.spec.resources` 并选择 一个比你之前所尝试的值更小的值。 如果由于容量限制而无法成功扩展至更高的值，这将很有用。 @@ -1411,10 +1490,7 @@ spec: ## Volume populators and data sources -Kubernetes supports custom volume populators; this alpha feature was introduced -in Kubernetes 1.18. Kubernetes 1.22 reimplemented the mechanism with a redesigned API. -Check that you are reading the version of the Kubernetes documentation that matches your -cluster. {{% version-check %}} +Kubernetes supports custom volume populators. To use custom volume populators, you must enable the `AnyVolumeDataSource` [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) for the kube-apiserver and kube-controller-manager. @@ -1428,13 +1504,11 @@ gate enabled, use of the `dataSourceRef` is preferred over `dataSource`. ## 卷填充器（Populator）与数据源 {#volume-populators-and-data-sources} -{{< feature-state for_k8s_version="v1.22" state="alpha" >}} +{{< feature-state for_k8s_version="v1.24" state="beta" >}} {{< note >}} -Kubernetes 支持自定义的卷填充器；Kubernetes 1.18 版本引入了这个 alpha 特性。 -Kubernetes 1.22 使用重新设计的 API 重新实现了该机制。 -确认你正在阅读与你的集群版本一致的 Kubernetes 文档。{{% version-check %}} -要使用自定义的卷填充器，你必须为 kube-apiserver 和 kube-controller-manager 启用 `AnyVolumeDataSource` +Kubernetes 支持自定义的卷填充器；要使用自定义的卷填充器，你必须为 +kube-apiserver 和 kube-controller-manager 启用 `AnyVolumeDataSource` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 {{< /note >}} @@ -1630,7 +1704,7 @@ Volume snapshot feature was added to support CSI Volume Plugins only. For detail To enable support for restoring a volume from a volume snapshot data source, enable the `VolumeSnapshotDataSource` feature gate on the apiserver and controller-manager. --> -卷快照（Volume Snapshot）功能的添加仅是为了支持 CSI 卷插件。 +卷快照（Volume Snapshot）特性的添加仅是为了支持 CSI 卷插件。 有关细节可参阅[卷快照](/zh/docs/concepts/storage/volume-snapshots/)文档。 要启用从卷快照数据源恢复数据卷的支持，可在 API 服务器和控制器管理器上启用 diff --git a/content/zh/docs/concepts/storage/volumes.md b/content/zh/docs/concepts/storage/volumes.md index 2d92dbf79c..f70172c0a2 100644 --- a/content/zh/docs/concepts/storage/volumes.md +++ b/content/zh/docs/concepts/storage/volumes.md @@ -256,22 +256,21 @@ For more details, see the [`azureDisk` volume plugin](https://github.com/kuberne --> #### azureDisk 的 CSI 迁移 {#azuredisk-csi-migration} -{{< feature-state for_k8s_version="v1.19" state="beta" >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} -启用 `azureDisk` 的 `CSIMigration` 功能后，所有插件操作从现有的树内插件重定向到 +启用 `azureDisk` 的 `CSIMigration` 特性后，所有插件操作从现有的树内插件重定向到 `disk.csi.azure.com` 容器存储接口（CSI）驱动程序。 -为了使用此功能，必须在集群中安装 +为了使用此特性，必须在集群中安装 [Azure 磁盘 CSI 驱动程序](https://github.com/kubernetes-sigs/azuredisk-csi-driver)， -并且 `CSIMigration` 和 `CSIMigrationAzureDisk` 功能必须被启用。 +并且 `CSIMigration` 特性必须被启用。 -启用 `azureFile` 的 `CSIMigration` 功能后，所有插件操作将从现有的树内插件重定向到 -`file.csi.azure.com` 容器存储接口（CSI）驱动程序。要使用此功能，必须在集群中安装 +启用 `azureFile` 的 `CSIMigration` 特性后，所有插件操作将从现有的树内插件重定向到 +`file.csi.azure.com` 容器存储接口（CSI）驱动程序。要使用此特性，必须在集群中安装 [Azure 文件 CSI 驱动程序](https://github.com/kubernetes-sigs/azurefile-csi-driver)， 并且 `CSIMigration` 和 `CSIMigrationAzureFile` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) 必须被启用。 Azure 文件 CSI 驱动尚不支持为同一卷设置不同的 fsgroup。 -如果 AzureFile CSI 迁移被启用，用不同的 fsgroup 来使用同一卷也是不被支持的。 +如果 `CSIMigrationAzureFile` 特性被启用，用不同的 fsgroup 来使用同一卷也是不被支持的。 #### OpenStack CSI 迁移 -{{< feature-state for_k8s_version="v1.21" state="beta" >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} -Cinder 的 `CSIMigration` 功能在 Kubernetes 1.21 版本中是默认被启用的。 +自 Kubernetes 1.21 版本起，Cinder 的 `CSIMigration` 特性是默认被启用的。 此特性会将插件的所有操作从现有的树内插件重定向到 `cinder.csi.openstack.org` 容器存储接口（CSI）驱动程序。 -为了使用此功能，必须在集群中安装 +为了使用此特性，必须在集群中安装 [OpenStack Cinder CSI 驱动程序](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md)， 你可以通过设置 `CSIMigrationOpenStack` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) 为 `false` 来禁止 Cinder CSI 迁移。 -如果你禁用了 `CSIMigrationOpenStack` 功能特性，则树内的 Cinder 卷插件 -会负责 Cinder 卷存储管理的方方面面。 + + +要禁止控制器管理器和 kubelet 加载树内 Cinder 插件，你可以启用 +`InTreePluginOpenStackUnregister` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 ### configMap @@ -783,8 +785,8 @@ within the same region. In order to use this feature, the volume must be provisi as a PersistentVolume; referencing the volume directly from a Pod is not supported. --> [区域持久盘](https://cloud.google.com/compute/docs/disks/#repds) -功能允许你创建能在同一区域的两个可用区中使用的持久盘。 -要使用这个功能，必须以持久卷（PersistentVolume）的方式提供卷；直接从 +特性允许你创建能在同一区域的两个可用区中使用的持久盘。 +要使用这个特性，必须以持久卷（PersistentVolume）的方式提供卷；直接从 Pod 引用这种卷是不可以的。 -启用 GCE PD 的 `CSIMigration` 功能后，所有插件操作将从现有的树内插件重定向到 +启用 GCE PD 的 `CSIMigration` 特性后，所有插件操作将从现有的树内插件重定向到 `pd.csi.storage.gke.io` 容器存储接口（ CSI ）驱动程序。 -为了使用此功能，必须在集群中上安装 +为了使用此特性，必须在集群中上安装 [GCE PD CSI驱动程序](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver)， -并且 `CSIMigration` 和 `CSIMigrationGCE` Beta 功能必须被启用。 +并且 `CSIMigration` 和 `CSIMigrationGCE` Beta 特性必须被启用。 -启用 RBD 的 `CSIMigration` 功能后，所有插件操作从现有的树内插件重定向到 +启用 RBD 的 `CSIMigration` 特性后，所有插件操作从现有的树内插件重定向到 `rbd.csi.ceph.com` {{}} 驱动程序。 -要使用该功能，必须在集群内安装 +要使用该特性，必须在集群内安装 [Ceph CSI 驱动](https://github.com/ceph/ceph-csi)，并启用 `CSIMigration` 和 `csiMigrationRBD` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 @@ -1601,15 +1603,13 @@ For more information about StorageOS, dynamic provisioning, and PersistentVolume 关于 StorageOS 的进一步信息、动态供应和持久卷申领等等，请参考 [StorageOS 示例](https://github.com/kubernetes/examples/blob/master/volumes/storageos)。 -### vsphereVolume {#vspherevolume} +### vsphereVolume（弃用） {#vspherevolume} {{< note >}} -你必须配置 Kubernetes 的 vSphere 云驱动。云驱动的配置方法请参考 -[vSphere 使用指南](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/)。 +建议你改用 vSphere CSI 树外驱动程序。 {{< /note >}} -{{< caution >}} -在挂载到 Pod 之前，你必须用下列方式之一创建 VMDK。 -{{< /caution >}} - - -#### 创建 VMDK 卷 {#creating-vmdk-volume} - -选择下列方式之一创建 VMDK。 - -{{< tabs name="tabs_volumes" >}} -{{% tab name="使用 vmkfstools 创建" %}} - -首先 ssh 到 ESX，然后使用下面的命令来创建 VMDK： - -```shell -vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk -``` -{{% /tab %}} -{{% tab name="使用 vmware-vdiskmanager 创建" %}} - -使用下面的命令创建 VMDK： - -```shell -vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk -``` -{{% /tab %}} - -{{< /tabs >}} - - - -#### vSphere VMDK 配置示例 {#vsphere-vmdk-configuration} - -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: test-vmdk -spec: - containers: - - image: k8s.gcr.io/test-webserver - name: test-container - volumeMounts: - - mountPath: /test-vmdk - name: test-volume - volumes: - - name: test-volume - # 此 VMDK 卷必须已经存在 - vsphereVolume: - volumePath: "[DatastoreName] volumes/myDisk" - fsType: ext4 -``` - @@ -1710,10 +1648,26 @@ must be installed on the cluster and the `CSIMigration` and `CSIMigrationvSphere [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 -此特性还要求 vSphere vCenter/ESXi 的版本至少为 7.0u1，且 HW 版本至少为 -VM version 15。 +你可以在 VMware 的文档页面 +[迁移树内 vSphere 卷插件到 vSphere 容器存储插件](https://docs.vmware.com/en/VMware-vSphere-Container-Storage-Plug-in/2.0/vmware-vsphere-csp-getting-started/GUID-968D421F-D464-4E22-8127-6CB9FF54423F.html) +中找到有关如何迁移的其他建议。 + +为了迁移到树外 CSI 驱动程序，Kubernetes v{{< skew currentVersion >}} +要求你使用 vSphere 7.0u2 或更高版本。 +如果你正在运行 v{{< skew currentVersion >}} 以外的 Kubernetes 版本， +请查阅该 Kubernetes 版本的文档。 +如果你正在运行 Kubernetes v{{< skew currentVersion >}} 和旧版本的 vSphere， +请考虑至少升级到 vSphere 7.0u2。 {{< note >}} -Kubernetes 1.23 中加入了 Portworx 的 `CSIMigration` 功能，但默认不会启用，因为该功能仍处于 alpha 阶段。 -该功能会将所有的插件操作从现有的树内插件重定向到 +Kubernetes 1.23 中加入了 Portworx 的 `CSIMigration` 特性，但默认不会启用，因为该特性仍处于 alpha 阶段。 +该特性会将所有的插件操作从现有的树内插件重定向到 `pxd.portworx.com` 容器存储接口（Container Storage Interface, CSI）驱动程序。 集群中必须安装 [Portworx CSI 驱动](https://docs.portworx.com/portworx-install-with-kubernetes/storage-operations/csi/)。 -要启用此功能，请在 kube-controller-manager 和 kubelet 中设置 `CSIMigrationPortworx=true`。 +要启用此特性，请在 kube-controller-manager 和 kubelet 中设置 `CSIMigrationPortworx=true`。 -启用 `CSIMigration` 功能后，针对现有树内插件的操作会被重定向到相应的 CSI 插件（应已安装和配置）。 +启用 `CSIMigration` 特性后，针对现有树内插件的操作会被重定向到相应的 CSI 插件（应已安装和配置）。 因此，操作员在过渡到取代树内插件的 CSI 驱动时，无需对现有存储类、PV 或 PVC（指树内插件）进行任何配置更改。 -所支持的操作和功能包括：配备（Provisioning）/删除、挂接（Attach）/解挂（Detach）、 +所支持的操作和特性包括：配备（Provisioning）/删除、挂接（Attach）/解挂（Detach）、 挂载（Mount）/卸载（Unmount）和调整卷大小。 上面的[卷类型](#volume-types)节列出了支持 `CSIMigration` 并已实现相应 CSI diff --git a/content/zh/docs/concepts/windows/_index.md b/content/zh/docs/concepts/windows/_index.md new file mode 100644 index 0000000000..a78ddcfe75 --- /dev/null +++ b/content/zh/docs/concepts/windows/_index.md @@ -0,0 +1,8 @@ +--- +title: "Kubernetes 中的 Windows" +weight: 50 +--- + diff --git a/content/zh/docs/concepts/workloads/controllers/cron-jobs.md b/content/zh/docs/concepts/workloads/controllers/cron-jobs.md index e31fa8edc3..e52908f51e 100644 --- a/content/zh/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/zh/docs/concepts/workloads/controllers/cron-jobs.md @@ -86,6 +86,7 @@ in time within that interval when the job should start. --> ## CronJob + CronJob 用于执行周期性的动作，例如备份、报告生成等。 这些任务中的每一个都应该配置为周期性重复的（例如：每天/每周/每月一次）； 你可以定义任务开始执行的时间间隔。 @@ -150,6 +151,69 @@ To generate CronJob schedule expressions, you can also use web tools like [cront --> 要生成 CronJob 时间表表达式，你还可以使用 [crontab.guru](https://crontab.guru/) 之类的 Web 工具。 + + +## 时区 {#time-zones} +对于没有指定时区的 CronJob，kube-controller-manager 基于本地时区解释排期表（Schedule）。 + +{{< feature-state for_k8s_version="v1.24" state="alpha" >}} + +如果启用了 `CronJobTimeZone` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， +你可以为 CronJob 指定一个时区（如果你没有启用该特性门控，或者你使用的是不支持试验性时区功能的 +Kubernetes 版本，集群中所有 CronJob 的时区都是未指定的）。 + +启用该特性后，你可以将 `spec.timeZone` +设置为有效[时区](https://zh.wikipedia.org/zh-hant/%E6%97%B6%E5%8C%BA%E4%BF%A1%E6%81%AF%E6%95%B0%E6%8D%AE%E5%BA%93s)名称。 +例如，设置 `spec.timeZone: "Etc/UTC"` 指示 Kubernetes 采用 UTC 来解释排期表。 + +Go 标准库中的时区数据库包含在二进制文件中，并用作备用数据库，以防系统上没有可用的外部数据库。 + + + +## 时区 {#time-zones} +对于没有指定时区的 CronJob，kube-controller-manager 会根据其本地时区来解释其排期表（schedule）。 + +{{< feature-state for_k8s_version="v1.24" state="alpha" >}} + + +如果启用 `CronJobTimeZone` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， +你可以为 CronJob 指定时区（如果你不启用该特性门控，或者如果你使用的 Kubernetes 版本不支持实验中的时区特性， +则集群中的所有 CronJob 都属于未指定时区）。 + + +当你启用该特性时，你可以将 `spec.timeZone` 设置为有效的[时区](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones)名称。 +例如，设置 `spec.timeZone: "Etc/UTC"` 表示 Kubernetes +使用协调世界时（Coordinated Universal Time）进行解释排期表。 + +Go 标准库中的时区数据库包含在二进制文件中，并用作备用数据库，以防系统上没有外部数据库可用。 -`ScheduleDaemonSetPods` 允许您使用默认调度器而不是 DaemonSet 控制器来调度 DaemonSets， +`ScheduleDaemonSetPods` 允许你使用默认调度器而不是 DaemonSet 控制器来调度 DaemonSets， 方法是将 `NodeAffinity` 条件而不是 `.spec.nodeName` 条件添加到 DaemonSet Pods。 默认调度器接下来将 Pod 绑定到目标主机。 如果 DaemonSet Pod 的节点亲和性配置已存在，则被替换 @@ -352,7 +352,7 @@ them according to its `updateStrategy`. You can [perform a rolling update](/docs/tasks/manage-daemon/update-daemon-set/) on a DaemonSet. --> -您可以删除一个 DaemonSet。如果使用 `kubectl` 并指定 `--cascade=orphan` 选项， +你可以删除一个 DaemonSet。如果使用 `kubectl` 并指定 `--cascade=orphan` 选项， 则 Pod 将被保留在节点上。接下来如果创建使用相同选择算符的新 DaemonSet， 新的 DaemonSet 会收养已有的 Pod。 如果有 Pod 需要被替换，DaemonSet 会根据其 `updateStrategy` 来替换。 diff --git a/content/zh/docs/concepts/workloads/controllers/job.md b/content/zh/docs/concepts/workloads/controllers/job.md index 0a1c6b484d..0c90de9c31 100644 --- a/content/zh/docs/concepts/workloads/controllers/job.md +++ b/content/zh/docs/concepts/workloads/controllers/job.md @@ -33,6 +33,9 @@ The Job object will start a new Pod if the first Pod fails or is deleted (for ex due to a node hardware failure or a node reboot). You can also use a Job to run multiple Pods in parallel. + +If you want to run a Job (either a single task, or several in parallel) on a schedule, +see [CronJob](/docs/concepts/workloads/controllers/cron-jobs/). --> Job 会创建一个或者多个 Pods，并将继续重试 Pods 的执行，直到指定数量的 Pods 成功终止。 随着 Pods 成功结束，Job 跟踪记录成功完成的 Pods 个数。 @@ -46,7 +49,11 @@ Job 会创建一个或者多个 Pods，并将继续重试 Pods 的执行，直 你也可以使用 Job 以并行的方式运行多个 Pod。 +如果你想按某种排期表（Schedule）运行 Job（单个任务或多个并行任务），请参阅 +[CronJob](/docs/concepts/workloads/controllers/cron-jobs/)。 + + + 你可以使用下面的命令来运行此示例： ```shell kubectl apply -f https://kubernetes.io/examples/controllers/job.yaml ``` - + + 输出类似于： ``` job.batch/pi created ``` - + 使用 `kubectl` 来检查 Job 的状态： ```shell kubectl describe jobs/pi ``` - + + 输出类似于： ``` @@ -131,7 +148,10 @@ To list all the Pods that belong to a Job in a machine readable form, you can us pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}') echo $pods ``` - + + 输出类似于： ``` @@ -139,7 +159,7 @@ pi-5rwd7 ``` + 输出类似于： ``` 3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632788659361533818279682303019520353018529689957736225994138912497217752834791315155748572424541506959508295331168617278558890750983817546374649393192550604009277016711390098488240128583616035637076601047101819429555961989467678374494482553797747268471040475346462080466842590694912933136770289891521047521620569660240580381501935112533824300355876402474964732639141992726042699227967823547816360093417216412199245863150302861829745557067498385054945885869269956909272107975093029553211653449872027559602364806654991198818347977535663698074265425278625518184175746728909777727938000816470600161452491921732172147723501414419735685481613611573525521334757418494684385233239073941433345477624168625189835694855620992192221842725502542568876717904946016534668049886272327917860857843838279679766814541009538837863609506800642251252051173929848960841284886269456042419652850222106611863067442786220391949450471237137869609563643719172874677646575739624138908658326459958133904780275901 ``` + -## 编写 Job 规约 +## 编写 Job 规约 {#writing-a-job-spec} 与 Kubernetes 中其他资源的配置类似，Job 也需要 `apiVersion`、`kind` 和 `metadata` 字段。 Job 的名字必须是合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 -Job 配置还需要一个[`.spec` 节](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。 +Job 配置还需要一个 [`.spec` 节](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。 -### Pod 模版 +### Pod 模版 {#pod-template} Job 的 `.spec` 中只有 `.spec.template` 是必需的字段。 @@ -195,7 +218,7 @@ Job 的 `.spec` 中只有 `.spec.template` 是必需的字段。 完全相同，只是其中不再需要 `apiVersion` 或 `kind` 字段。 除了作为 Pod 所必需的字段之外，Job 中的 Pod 模版必需设置合适的标签 -（参见[Pod 选择算符](#pod-selector)）和合适的重启策略。 +（参见 [Pod 选择算符](#pod-selector)）和合适的重启策略。 Job 中 Pod 的 [`RestartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 只能设置为 `Never` 或 `OnFailure` 之一。 @@ -219,6 +242,7 @@ There are three main types of task suitable to run as a Job: ### Job 的并行执行 {#parallel-jobs} 适合以 Job 形式来运行的任务主要有三种： + -## 处理 Pod 和容器失效 +## 处理 Pod 和容器失效 {#handling-pod-and-container-failures} Pod 中的容器可能因为多种不同原因失效，例如因为其中的进程退出时返回值非零， 或者容器因为超出内存约束而被杀死等等。 @@ -430,7 +454,7 @@ exponential back-off delay (10s, 20s, 40s ...) capped at six minutes. The back-off count is reset when a Job's Pod is deleted or successful without any other Pods for the Job failing around that time. --> -### Pod 回退失效策略 +### Pod 回退失效策略 {#pod-backoff-failure-policy} 在有些情形下，你可能希望 Job 在经历若干次重试之后直接进入失败状态，因为这很 可能意味着遇到了配置错误。 @@ -463,7 +487,7 @@ allows you to still view the logs of completed pods to check for errors, warning The job object also remains after it is completed so that you can view its status. It is up to the user to delete old jobs after noting their status. Delete the job with `kubectl` (e.g. `kubectl delete jobs/pi` or `kubectl delete -f ./job.yaml`). When you delete the job using `kubectl`, all the pods it created are deleted too. --> -## Job 终止与清理 +## Job 终止与清理 {#clean-up-finished-jobs-automatically} Job 完成时不会再创建新的 Pod，不过已有的 Pod [通常](#pod-backoff-failure-policy)也不会被删除。 保留这些 Pod 使得你可以查看已完成的 Pod 的日志输出，以便检查错误、警告 @@ -732,7 +756,7 @@ Job 被创建时，Job 控制器会马上开始执行 Pod 创建操作以满足 不过你可能想要暂时挂起 Job 执行，或启动处于挂起状态的job， 并拥有一个自定义控制器以后再决定什么时候开始。 - + + 输出类似于： ```yaml @@ -999,7 +1026,7 @@ the selector that the system normally generates for you automatically. 它们也会被名为 `new` 的 Job 所控制。 你需要在新 Job 中设置 `manualSelector: true`，因为你并未使用系统通常自动为你 -生成的选择算符。 +生成的选择算符。 ```yaml kind: Job @@ -1025,29 +1052,31 @@ mismatch. ### 使用 Finalizer 追踪 Job {#job-tracking-with-finalizers} {{< feature-state for_k8s_version="v1.23" state="beta" >}} {{< note >}} + 要使用该行为，你必须为 [API 服务器](/zh/docs/reference/command-line-tools-reference/kube-apiserver/) 和[控制器管理器](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) 启用 `JobTrackingWithFinalizers` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 默认是启用的。 + 启用后，控制面基于下述行为追踪新的 Job。在启用该特性之前创建的 Job 不受影响。 作为用户，你会看到的唯一区别是控制面对 Job 完成情况的跟踪更加准确。 {{< /note >}} @@ -1117,7 +1146,7 @@ Job 会重新创建新的 Pod 来替代已终止的 Pod。 -### 单个 Job 启动控制器 Pod +### 单个 Job 启动控制器 Pod {#single-job-starts-controller-pod} 另一种模式是用唯一的 Job 来创建 Pod，而该 Pod 负责启动其他 Pod，因此扮演了一种 后启动 Pod 的控制器的角色。 diff --git a/content/zh/docs/concepts/workloads/controllers/replicaset.md b/content/zh/docs/concepts/workloads/controllers/replicaset.md index ca92f8378e..0d64bce6c4 100644 --- a/content/zh/docs/concepts/workloads/controllers/replicaset.md +++ b/content/zh/docs/concepts/workloads/controllers/replicaset.md @@ -56,10 +56,11 @@ ReplicaSet 所获得的 Pod 都在其 ownerReferences 字段中包含了属主 R ReplicaSet 使用其选择算符来辨识要获得的 Pod 集合。如果某个 Pod 没有 -OwnerReference 或者其 OwnerReference 不是一个 +OwnerReference 或者其 OwnerReference 不是一个 {{< glossary_tooltip text="控制器" term_id="controller" >}}，且其匹配到 某 ReplicaSet 的选择算符，则该 Pod 立即被此 ReplicaSet 获得。 @@ -68,14 +69,14 @@ OwnerReference 或者其 OwnerReference 不是一个 A ReplicaSet ensures that a specified number of pod replicas are running at any given time. However, a Deployment is a higher-level concept that manages ReplicaSets and -provides declarative updates to pods along with a lot of other useful features. +provides declarative updates to Pods along with a lot of other useful features. Therefore, we recommend using Deployments instead of directly using ReplicaSets, unless you require custom update orchestration or don't require updates at all. This actually means that you may never need to manipulate ReplicaSet objects: use a Deployment instead, and define your application in the spec section. --> -## 何时使用 ReplicaSet +## 何时使用 ReplicaSet {#when-to-use-a-replicaset} ReplicaSet 确保任何时间都有指定数量的 Pod 副本在运行。 然而，Deployment 是一个更高级的概念，它管理 ReplicaSet，并向 Pod @@ -89,16 +90,16 @@ Deployment，并在 spec 部分定义你的应用。 -## 示例 +## 示例 {#example} {{< codenew file="controllers/frontend.yaml" >}} 将此清单保存到 `frontend.yaml` 中，并将其提交到 Kubernetes 集群， -应该就能创建 yaml 文件所定义的 ReplicaSet 及其管理的 Pod。 +就能创建 yaml 文件所定义的 ReplicaSet 及其管理的 Pod。 ```shell @@ -139,25 +140,25 @@ And you will see output similar to: 你会看到类似如下的输出： ``` -Name: frontend -Namespace: default -Selector: tier=frontend -Labels: app=guestbook - tier=frontend +Name: frontend +Namespace: default +Selector: tier=frontend +Labels: app=guestbook + tier=frontend Annotations: kubectl.kubernetes.io/last-applied-configuration: {"apiVersion":"apps/v1","kind":"ReplicaSet","metadata":{"annotations":{},"labels":{"app":"guestbook","tier":"frontend"},"name":"frontend",... -Replicas: 3 current / 3 desired -Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed +Replicas: 3 current / 3 desired +Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed Pod Template: - Labels: tier=frontend + Labels: tier=frontend Containers: php-redis: - Image: gcr.io/google_samples/gb-frontend:v3 + Image: gcr.io/google_samples/gb-frontend:v3 Port: Host Port: Environment: - Mounts: - Volumes: + Mounts: + Volumes: Events: Type Reason Age From Message ---- ------ ---- ---- ------- @@ -226,22 +227,15 @@ metadata: -## 非模板 Pod 的获得 +## 非模板 Pod 的获得 {#non-template-pod-acquisitions} 尽管你完全可以直接创建裸的 Pods，强烈建议你确保这些裸的 Pods 并不包含可能与你 的某个 ReplicaSet 的选择算符相匹配的标签。原因在于 ReplicaSet 并不仅限于拥有 @@ -288,7 +282,7 @@ The output shows that the new Pods are either already terminated, or in the proc --> 输出显示新的 Pods 或者已经被终止，或者处于终止过程中： -```shell +``` NAME READY STATUS RESTARTS AGE frontend-b2zdv 1/1 Running 0 10m frontend-vcmts 1/1 Running 0 10m @@ -339,10 +333,13 @@ pod1 1/1 Running 0 36s pod2 1/1 Running 0 36s ``` + 采用这种方式，一个 ReplicaSet 中可以包含异质的 Pods 集合。 -## 编写 ReplicaSet 的 spec +## 编写 ReplicaSet 的清单 {#writing-a-replicaset-manifest} 与所有其他 Kubernetes API 对象一样，ReplicaSet 也需要 `apiVersion`、`kind`、和 `metadata` 字段。 对于 ReplicaSets 而言，其 `kind` 始终是 ReplicaSet。 @@ -360,7 +357,8 @@ A ReplicaSet also needs a [`.spec` section](https://git.k8s.io/community/contrib ReplicaSet 对象的名称必须是合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 -ReplicaSet 也需要 [`.spec`](https://git.k8s.io/community/contributors/devel/api-conventions.md#spec-and-status) +ReplicaSet 也需要 +[`.spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status) 部分。 -### Pod 模版 +### Pod 模版 {#pod-template} -`.spec.template` 是一个[Pod 模版](/zh/docs/concepts/workloads/pods/#pod-templates)， +`.spec.template` 是一个 [Pod 模版](/zh/docs/concepts/workloads/pods/#pod-templates)， 要求设置标签。在 `frontend.yaml` 示例中，我们指定了标签 `tier: frontend`。 注意不要将标签与其他控制器的选择算符重叠，否则那些控制器会尝试收养此 Pod。 @@ -415,7 +413,7 @@ matchLabels: -对于设置了相同的 `.spec.selector`，但 +对于设置了相同的 `.spec.selector`，但 `.spec.template.metadata.labels` 和 `.spec.template.spec` 字段不同的 两个 ReplicaSet 而言，每个 ReplicaSet 都会忽略被另一个 ReplicaSet 所 创建的 Pods。 @@ -434,7 +432,7 @@ If you do not specify `.spec.replicas`, then it defaults to 1. 你可以通过设置 `.spec.replicas` 来指定要同时运行的 Pod 个数。 ReplicaSet 创建、删除 Pods 以与此值匹配。 -如果你没有指定 `.spec.replicas`, 那么默认值为 1。 +如果你没有指定 `.spec.replicas`，那么默认值为 1。 -## 使用 ReplicaSets +## 使用 ReplicaSets {#working-with-replicasets} -### 删除 ReplicaSet 和它的 Pod +### 删除 ReplicaSet 和它的 Pod {#deleting-a-replicaset-and-its-pods} 要删除 ReplicaSet 和它的所有 Pod，使用 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 命令。 默认情况下，[垃圾收集器](/zh/docs/concepts/workloads/controllers/garbage-collection/) 自动删除所有依赖的 Pod。 -当使用 REST API 或 `client-go` 库时，你必须在删除选项中将 `propagationPolicy` +当使用 REST API 或 `client-go` 库时，你必须在 `-d` 选项中将 `propagationPolicy` 设置为 `Background` 或 `Foreground`。例如： ```shell kubectl proxy --port=8080 curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/frontend' \ - -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \ - -H "Content-Type: application/json" + -d '{"kind":"DeleteOptions","apiVersion":"v1","propagationPolicy":"Foreground"}' \ + -H "Content-Type: application/json" ``` -### 只删除 ReplicaSet +### 只删除 ReplicaSet {#deleting-just-a-replicaset} 你可以只删除 ReplicaSet 而不影响它的 Pods，方法是使用 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) @@ -489,8 +489,8 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron @@ -502,16 +502,15 @@ To update Pods to a new spec in a controlled way, use a 资源，因为 ReplicaSet 并不直接支持滚动更新。 -### 将 Pod 从 ReplicaSet 中隔离 +### 将 Pod 从 ReplicaSet 中隔离 {#isolating-pods-from-a-replicaset} -可以通过改变标签来从 ReplicaSet 的目标集中移除 Pod。 +可以通过改变标签来从 ReplicaSet 中移除 Pod。 这种技术可以用来从服务中去除 Pod，以便进行排错、数据恢复等。 以这种方式移除的 Pod 将被自动替换（假设副本的数量没有改变）。 @@ -519,9 +518,9 @@ from service for debugging, data recovery, etc. Pods that are removed in this wa ### Scaling a ReplicaSet A ReplicaSet can be easily scaled up or down by simply updating the `.spec.replicas` field. The ReplicaSet controller -ensures that a desired number of pods with a matching label selector are available and operational. +ensures that a desired number of Pods with a matching label selector are available and operational. --> -### 缩放 RepliaSet +### 缩放 RepliaSet {#scaling-a-replicaset} 通过更新 `.spec.replicas` 字段，ReplicaSet 可以被轻松的进行缩放。ReplicaSet 控制器能确保匹配标签选择器的数量的 Pod 是可用的和可操作的。 @@ -551,7 +550,7 @@ prioritize scaling down pods based on the following general algorithm: [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) 被启用时，创建时间是按整数幂级来分组的）。 -如果以上比较结果都相同，则随机选择。 +如果以上比较结果都相同，则随机选择。 - 此机制实施时仅是尽力而为，并不能对 Pod 的删除顺序作出任何保证； - 用户应避免频繁更新注解值，例如根据某观测度量值来更新此注解值是应该避免的。 - 这样做会在 API 服务器上产生大量的 Pod 更新操作。 + 这样做会在 API 服务器上产生大量的 Pod 更新操作。 {{< /note >}} -#### 使用场景示例 +#### 使用场景示例 {#example-use-case} 同一应用的不同 Pods 可能其利用率是不同的。在对应用执行缩容操作时，可能 希望移除利用率较低的 Pods。为了避免频繁更新 Pods，应用应该在执行缩容 @@ -623,14 +622,14 @@ the down scaling; for example, the driver pod of a Spark deployment. 是可以起作用的。 -### ReplicaSet 作为水平的 Pod 自动缩放器目标 +### ReplicaSet 作为水平的 Pod 自动缩放器目标 {#replicaset-as-a-horizontal-pod-autoscaler-target} ReplicaSet 也可以作为 [水平的 Pod 缩放器 (HPA)](/zh/docs/tasks/run-application/horizontal-pod-autoscale/) @@ -642,7 +641,7 @@ ReplicaSet 也可以作为 将这个列表保存到 `hpa-rs.yaml` 并提交到 Kubernetes 集群，就能创建它所定义的 HPA，进而就能根据复制的 Pod 的 CPU 利用率对目标 ReplicaSet进行自动缩放。 @@ -655,7 +654,7 @@ kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml Alternatively, you can use the `kubectl autoscale` command to accomplish the same (and it's easier!) --> -或者，可以使用 `kubectl autoscale` 命令完成相同的操作。 (而且它更简单！) +或者，可以使用 `kubectl autoscale` 命令完成相同的操作。（而且它更简单！） ```shell kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50 @@ -664,7 +663,7 @@ kubectl autoscale rs frontend --max=10 --min=3 --cpu-percent=50 -## ReplicaSet 的替代方案 +## ReplicaSet 的替代方案 {#alternatives-to-replicaset} -### Deployment （推荐） +### Deployment（推荐） {#deployment-recommended} [`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/) 是一个 可以拥有 ReplicaSet 并使用声明式方式在服务器端完成对 Pods 滚动更新的对象。 @@ -689,7 +688,7 @@ As such, it is recommended to use Deployments when you want ReplicaSets. Unlike the case where a user directly created Pods, a ReplicaSet replaces Pods that are deleted or terminated for any reason, such as in the case of node failure or disruptive node maintenance, such as a kernel upgrade. For this reason, we recommend that you use a ReplicaSet even if your application requires only a single Pod. Think of it similarly to a process supervisor, only it supervises multiple Pods across multiple nodes instead of individual processes on a single node. A ReplicaSet delegates local container restarts to some agent on the node (for example, Kubelet or Docker). --> -### 裸 Pod +### 裸 Pod {#bare-pods} 与用户直接创建 Pod 的情况不同，ReplicaSet 会替换那些由于某些原因被删除或被终止的 Pod，例如在节点故障或破坏性的节点维护（如内核升级）的情况下。 @@ -713,9 +712,9 @@ Use a [`Job`](/docs/concepts/workloads/controllers/job/) instead of a ReplicaSet ### DaemonSet @@ -756,6 +755,8 @@ ReplicaSet 是 [ReplicationController](/zh/docs/concepts/workloads/controllers/r * 了解 [Pods](/zh/docs/concepts/workloads/pods)。 * 了解 [Deployments](/zh/docs/concepts/workloads/controllers/deployment/)。 * [使用 Deployment 运行一个无状态应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)，它依赖于 ReplicaSet。 -* `ReplicaSet` 是 Kubernetes REST API 中的顶级资源。阅读 {{< api-reference page="workload-resources/replica-set-v1" >}} - 对象定义理解关于该资源的 API。 -* 阅读[Pod 干扰预算（Disruption Budget）](/zh/docs/concepts/workloads/pods/disruptions/)，了解如何在干扰下运行高度可用的应用。 +* `ReplicaSet` 是 Kubernetes REST API 中的顶级资源。阅读 + {{< api-reference page="workload-resources/replica-set-v1" >}} + 对象定义理解关于该资源的 API。 +* 阅读 [Pod 干扰预算（Disruption Budget）](/zh/docs/concepts/workloads/pods/disruptions/)， + 了解如何在干扰下运行高度可用的应用。 diff --git a/content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md index 0d02b7a04b..352ddaf83d 100644 --- a/content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -94,7 +94,7 @@ returns a successful API response. 请注意，在创建 Job 或已经执行结束后，仍可以修改其 TTL 周期，例如 Job 的 `.spec.ttlSecondsAfterFinished` 字段。 -但是一旦 Job 变为可被删除状态（当其 TTL 已过期时），即使您通过 API 增加其 TTL +但是一旦 Job 变为可被删除状态（当其 TTL 已过期时），即使你通过 API 增加其 TTL 时长得到了成功的响应，系统也不保证 Job 将被保留。 -{{< feature-state for_k8s_version="v1.19" state="stable" >}} - - - **maxSkew** 描述 Pod 分布不均的程度。这是给定拓扑类型中任意两个拓扑域中 匹配的 pod 之间的最大允许差值。它必须大于零。取决于 `whenUnsatisfiable` 的 取值，其语义会有不同。 - 当 `whenUnsatisfiable` 等于 "DoNotSchedule" 时，`maxSkew` 是目标拓扑域 - 中匹配的 Pod 数与全局最小值之间可存在的差异。 + 中匹配的 Pod 数与全局最小值（一个拓扑域中与标签选择器匹配的 Pod 的最小数量。例如，如果你有 + 3 个区域，分别具有 0 个、2 个 和 3 个匹配的 Pod，则全局最小值为 0。）之间可存在的差异。 - 当 `whenUnsatisfiable` 等于 "ScheduleAnyway" 时，调度器会更为偏向能够降低 偏差值的拓扑域。 + + +- **minDomains** 表示符合条件的域的最小数量。域是拓扑的一个特定实例。 + 符合条件的域是其节点与节点选择器匹配的域。 + + - 指定的 `minDomains` 的值必须大于 0。 + - 当符合条件的、拓扑键匹配的域的数量小于 `minDomains` 时，Pod 拓扑分布将“全局最小值”（global minimum） 设为 + 0，然后进行 `skew` 计算。“全局最小值”是一个符合条件的域中匹配 Pods 的最小数量， + 如果符合条件的域的数量小于 `minDomains`，则全局最小值为零。 + - 当符合条件的拓扑键匹配域的个数等于或大于 `minDomains` 时，该值对调度没有影响。 + - 当 `minDomains` 为 nil 时，约束的行为等于 `minDomains` 为 1。 + - 当 `minDomains` 不为 nil 时，`whenUnsatisfiable` 的值必须为 "`DoNotSchedule`" 。 + + {{< note >}} + + `minDomains` 字段是在 1.24 版本中新增的 alpha 字段。你必须启用 + `MinDomainsInPodToplogySpread` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)才能使用它。 + {{< /note >}} + + - **topologyKey** 是节点标签的键。如果两个节点使用此键标记并且具有相同的标签值， 则调度器会将这两个节点视为处于同一拓扑域中。调度器试图在每个拓扑域中放置数量 均衡的 Pod。 + - **whenUnsatisfiable** 指示如果 Pod 不满足分布约束时如何处理： - `DoNotSchedule`（默认）告诉调度器不要调度。 - `ScheduleAnyway` 告诉调度器仍然继续调度，只是根据如何能将偏差最小化来对 节点进行排序。 + - **labelSelector** 用于查找匹配的 pod。匹配此标签的 Pod 将被统计，以确定相应 拓扑域中 Pod 的数量。 有关详细信息，请参考[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)。 @@ -511,16 +553,12 @@ profiles: {{< note >}} -默认调度约束所生成的评分可能与 -[`SelectorSpread` 插件](/zh/docs/reference/scheduling/config/#scheduling-plugins) -所生成的评分有冲突。 -建议你在为 `PodTopologySpread` 设置默认约束是禁用调度方案中的该插件。 +[`SelectorSpread` 插件](/zh/docs/reference/scheduling/config/#scheduling-plugins)默认是被禁用的。 +建议使用 `PodTopologySpread` 来实现类似的行为。 {{< /note >}} #### 内部默认约束 {#internal-default-constraints} -{{< feature-state for_k8s_version="v1.20" state="beta" >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} -当你使用了默认启用的 `DefaultPodTopologySpread` 特性门控时，原来的 -`SelectorSpread` 插件会被禁用。 -kube-scheduler 会使用下面的默认拓扑约束作为 `PodTopologySpread` 插件的 -配置： +如果你没有为 Pod 拓扑分布配置任何集群级别的默认约束， +kube-scheduler 的行为就像你指定了以下默认拓扑约束一样： ```yaml defaultConstraints: @@ -553,9 +587,9 @@ defaultConstraints: -此外，原来用于提供等同行为的 `SelectorSpread` 插件也会被禁用。 +此外，原来用于提供等同行为的 `SelectorSpread` 插件默认被禁用。 {{< note >}} {{< note >}} 要了解有关为 Kubernetes 做出贡献的更多信息，请参阅 [贡献者文档](https://www.kubernetes.dev/docs/)。 -{{< /note >}} + +你还可以阅读 +{{< glossary_tooltip text="CNCF" term_id="cncf" >}} +关于为 Kubernetes 做贡献的[页面](https://contribute.cncf.io/contributors/projects/#kubernetes)。 - 此页面描述如何为其他语言的文档提供 [本地化](https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/)版本。 - -## 为现有的本地化做出贡献 +## 为现有的本地化做出贡献 {#contribute-to-an-existing-localization} 你可以帮助添加或改进现有本地化的内容。在 [Kubernetes Slack](https://slack.k8s.io/) 中， 你能找到每个本地化的频道。还有一个通用的 @@ -44,7 +44,7 @@ You can help add or improve content to an existing localization. In [Kubernetes 你可以在这里打个招呼。 {{< note >}} - -### 找到两个字母的语言代码 +### 找到两个字母的语言代码 {#find-your-two-letter-language-code} 首先，有关本地化的两个字母的语言代码，请参考 [ISO 639-1 标准](https://www.loc.gov/standards/iso639-2/php/code_list.php)。 @@ -85,9 +85,12 @@ git clone https://github.com//website cd website ``` + 网站内容目录包括每种语言的子目录。你想要助力的本地化位于 `content/` 中。 - -## 开始新的本地化 +## 开始新的本地化 {#start-a-new-localization} 如果你希望将 Kubernetes 文档本地化为一种新语言，你需要执行以下操作。 @@ -137,7 +140,7 @@ it's up to you to translate it and keep existing localized content current. 所有本地化团队都必须能够自我维持。 Kubernetes 网站很乐意托管你的作品，但要由你来翻译它并使现有的本地化内容保持最新。 - -### 找到社区 +### 找到社区 {#find-community} 让 Kubernetes SIG Docs 知道你有兴趣创建本地化！ 加入 [SIG Docs Slack 频道](https://kubernetes.slack.com/messages/sig-docs) 和 [SIG Docs Localizations Slack 频道](https://kubernetes.slack.com/messages/sig-docs-localizations)。 其他本地化团队很乐意帮助你入门并回答你的任何问题。 - -### 加入到 Kubernetes GitHub 组织 +### 加入到 Kubernetes GitHub 组织 {#join-the-kubernetes-github-organization} 提交本地化 PR 后，你可以成为 Kubernetes GitHub 组织的成员。 团队中的每个人都需要在 `kubernetes/org` 仓库中创建自己的 [组织成员申请](https://github.com/kubernetes/org/issues/new/choose)。 - ### 在 GitHub 中添加你的本地化团队 {#add-your-localization-team-in-github} @@ -217,24 +221,24 @@ The `@kubernetes/sig-docs-**-reviews` team automates review assignment for new P `@kubernetes/sig-docs-**-owners` 成员可以批准更改对应本地化目录 `/content/**/` 中内容的 PR，并仅限这类 PR。 -`@kubernetes/sig-docs-**-reviews` 团队被自动分派新 PR 的审阅任务。 +对于每个本地化，`@kubernetes/sig-docs-**-reviews` 团队被自动分派新 PR 的审阅任务。 - `@kubernetes/website-maintainers` 成员可以创建新的本地化分支来协调翻译工作。 `@kubernetes/website-milestone-maintainers` 成员可以使用 `/milestone` [Prow 命令](https://prow.k8s.io/command-help)为 issues 或 PR 设定里程碑。 - - ### 配置工作流程 {#configure-the-workflow} @@ -246,16 +250,14 @@ For an example of adding a label, see the PR for adding the [Italian language la 你还可以在 `kubernetes/community` 仓库中为你的本地化创建一个 Slack 频道。 有关添加 Slack 频道的示例，请参见[为印尼语和葡萄牙语添加频道](https://github.com/kubernetes/community/pull/3605)的 PR。 - -## 最低要求内容 {#minimum-required-content} - -### 修改站点配置 +### 修改站点配置 {#configure-the-workflow} Kubernetes 网站使用 Hugo 作为其 Web 框架。网站的 Hugo 配置位于 [`config.toml`](https://github.com/kubernetes/website/tree/main/config.toml)文件中。 @@ -275,7 +277,7 @@ weight = 8 ``` `languageName` 的值将列在语言选择栏中。 将 `languageName` 赋值为“本地脚本中的语言名称（拉丁脚本中的语言名称）”。 @@ -284,21 +286,21 @@ The value for `languageName` will be listed in language selection bar. Assign "l 将 `languageNameLatinScript` 赋值为“拉丁脚本中的语言名称”。 例如，`languageNameLatinScript ="Korean"`。 - 为你的语言块分配一个 `weight` 参数时，找到权重最高的语言块并将其加 1。 有关 Hugo 多语言支持的更多信息，请参阅"[多语言模式](https://gohugo.io/content-management/multilingual/)"。 - -### 添加一个新的本地化目录 +### 添加一个新的本地化目录 {#add-a-new-localization-directory} 将特定语言的子目录添加到仓库中的 [`content`](https://github.com/kubernetes/website/tree/main/content) 文件夹下。 @@ -308,7 +310,7 @@ Add a language-specific subdirectory to the [`content`](https://github.com/kuber mkdir content/de ``` - -### 本地化社区行为准则 +### 本地化社区行为准则 {#localize-the-community-code-of-conduct} 在 [`cncf/foundation`](https://github.com/cncf/foundation/tree/master/code-of-conduct-languages) 仓库提交 PR，添加你所用语言版本的行为准则。 --> - -### 设置 OWNERS 文件 +### 设置 OWNERS 文件 {#setting-up-the-owners-files} 要设置每个对本地化做出贡献用户的角色，请在特定于语言的子目录内创建一个 `OWNERS` 文件，其中： @@ -362,10 +364,10 @@ To set the roles of each user contributing to the localization, create an `OWNER - **labels**: 可以自动应用于 PR 的 GitHub 标签列表，在本例中为 [配置工作流程](#configure-the-workflow)中创建的语言标签。 - 有关 `OWNERS` 文件的更多信息，请访问[go.k8s.io/owners](https://go.k8s.io/owners)。 @@ -386,12 +388,12 @@ approvers: labels: - language/es -``` +``` - 添加了特定语言的 OWNERS 文件之后，使用新的 Kubernetes 本地化团队、 `sig-docs-**-owners` 和 `sig-docs-**-reviews` 列表更新 @@ -421,7 +423,7 @@ For each team, add the list of GitHub users requested in [Add your localization - remyleone ``` - -### 添加本地化的 README 文件 +### 添加本地化的 README 文件 {#add-a-localized-readme-file} 为了指导其他本地化贡献者，请在 [k/website](https://github.com/kubernetes/website/) 的根目录添加一个新的 [`README-**.md`](https://help.github.com/articles/about-readmes/)， @@ -461,14 +463,14 @@ Provide guidance to localization contributors in the localized `README-**.md` fi - 本地化项目的联系人 - 任何特定于本地化的信息 - 创建本地化的 README 文件后，请在英语版文件 `README.md` 中添加指向该文件的链接， 并给出英文形式的联系信息。你可以提供 GitHub ID、电子邮件地址、 [Slack 频道](https://slack.com/)或其他联系方式。你还必须提供指向本地化的社区行为准则的链接。 - -### 启动你的新本地化 +### 启动你的新本地化 {#add-a-localized-readme-file} 一旦本地化满足工作流程和最小输出的要求，SIG Docs 将： @@ -484,20 +486,25 @@ Once a localization meets requirements for workflow and minimum output, SIG Docs - 通过[云原生计算基金会](https://www.cncf.io/about/)（CNCF）渠道， 包括 [Kubernetes 博客](https://kubernetes.io/blog/)，来宣传本地化的可用性。 - ## 翻译文档 {#translating-content} 本地化*所有* Kubernetes 文档是一项艰巨的任务。从小做起，循序渐进。 + +### 最低要求内容 {#minimum-required-content} + 所有本地化至少必须包括： - 翻译后的文档必须保存在自己的 `content/**/` 子目录中，否则将遵循与英文源相同的 URL 路径。 例如，要准备将 [Kubernetes 基础](/zh/docs/tutorials/kubernetes-basics/) 教程翻译为德语， @@ -525,24 +533,24 @@ mkdir -p content/de/docs/tutorials cp content/en/docs/tutorials/kubernetes-basics.md content/de/docs/tutorials/kubernetes-basics.md ``` - 翻译工具可以加快翻译过程。例如，某些编辑器提供了用于快速翻译文本的插件。 - {{< caution >}} -机器生成的翻译不能达到最低质量标准，需要进行大量人工审查才能达到该标准。 +机器生成的翻译本身是不够的，本地化需要广泛的人工审核才能满足最低质量标准。 {{< /caution >}} - 为了确保语法和含义的准确性，本地化团队的成员应在发布之前仔细检查所有由机器生成的翻译。 - -### 源文件 +### 源文件 {#source-files} 本地化必须基于本地化团队所针对的特定发行版本中的英文文件。 每个本地化团队可以决定要针对哪个发行版本，在下文中称作目标版本（target version）。） @@ -580,27 +588,27 @@ The `master` branch holds content for the current release `{{< latest-version >} 发行团队会在下一个发行版本 v{{< skew nextMinorVersion >}} 出现之前创建 `{{< release-branch >}}` 分支。 - ### i18n/ 中的网站字符串 {#site-strings-in-i18n} 本地化必须在新的语言特定文件中包含 -[`data/i18n/en/en.toml`](https://github.com/kubernetes/website/blob/master/i18n/en.toml) +[`data/i18n/en/en.toml`](https://github.com/kubernetes/website/blob/main/data/i18n/en/en.toml) 的内容。以德语为例：`data/i18n/de/de.toml`。 -将新的本地化文件添加到 `i18n/`。例如德语 (`de`)： +将新的本地化文件和目录添加到 `data/i18n/`。例如德语 (`de`)： ```bash mkdir -p data/i18n/de cp data/i18n/en/en.toml data/i18n/de/de.toml ``` - 本地化网站字符串允许你自定义网站范围的文本和特性：例如，每个页面页脚中的合法版权文本。 - -### 特定语言的样式指南和词汇表 +### 特定语言的样式指南和词汇表 {#language-specific-style-guide-and-glossary} 一些语言团队有自己的特定语言样式指南和词汇表。 例如，请参见[中文本地化指南](/zh/docs/contribute/localization_zh/)。 @@ -637,23 +645,23 @@ Per CNCF policy, the localization teams must upload their meetings to the SIG Do --> -### 特定语言的 Zoom 会议 +### 特定语言的 Zoom 会议 {#language-specific-zoom-meetings} -如果本地化项目需要单独的会议时间， -请联系 SIG Docs 联合主席或技术主管以创建新的重复 Zoom 会议和日历邀请。 +如果本地化项目需要单独的会议时间， +请联系 SIG Docs 联合主席或技术主管以创建新的重复 Zoom 会议和日历邀请。 仅当团队维持在足够大的规模并需要单独的会议时才需要这样做。 根据 CNCF 政策，本地化团队必须将他们的会议上传到 SIG Docs YouTube 播放列表。 SIG Docs 联合主席或技术主管可以帮助完成该过程，直到 SIG Docs 实现自动化。 - ### 分支策略 {#branching-strategy} @@ -662,10 +670,10 @@ To collaborate on a localization branch: 在本地化分支上协作需要： - 2. 个人贡献者基于本地化分支创建新的特性分支 @@ -703,13 +711,13 @@ To collaborate on a localization branch: 4. 批准人会定期发起并批准新的 PR，将本地化分支合并到其源分支。 在批准 PR 之前，请确保先 squash commits。 - 根据需要重复步骤 1-4，直到完成本地化工作。例如，随后的德语本地化分支将是： `dev-1.12-de.2`、`dev-1.12-de.3`，等等。 - +--> 在团队每个里程碑的开始时段，创建一个 issue 来比较先前的本地化分支 和当前的本地化分支之间的上游变化很有帮助。 现在有两个脚本用来比较上游的变化。 @@ -751,13 +759,13 @@ While only approvers can open a new localization branch and merge pull requests, 虽然只有批准人才能创建新的本地化分支并合并 PR，任何人都可以 为新的本地化分支提交一个拉取请求（PR）。不需要特殊权限。 - 有关基于派生或直接从仓库开展工作的更多信息，请参见 ["派生和克隆"](#fork-and-clone-the-repo)。 - diff --git a/content/zh/docs/contribute/participate/pr-wranglers.md b/content/zh/docs/contribute/participate/pr-wranglers.md index d9af8cc1d3..20230e4d3b 100644 --- a/content/zh/docs/contribute/participate/pr-wranglers.md +++ b/content/zh/docs/contribute/participate/pr-wranglers.md @@ -11,11 +11,11 @@ weight: 20 -SIG Docs 的[批准人（Approvers）](/zh/docs/contribute/participate/roles-and-responsibilites/#approvers)们每周轮流负责 +SIG Docs 的[批准人（Approvers）](/zh/docs/contribute/participate/roles-and-responsibilities/#approvers)们每周轮流负责 [管理仓库的 PR](https://github.com/kubernetes/website/wiki/PR-Wranglers)。 本节介绍 PR 管理者的职责。关于如何提供较好的评审意见， @@ -206,7 +206,7 @@ In late 2021, SIG Docs introduced the PR Wrangler Shadow Program. The program wa - Others can reach out on the [#sig-docs Slack channel](https://kubernetes.slack.com/messages/sig-docs) for requesting to shadow an assigned PR Wrangler for a specific week. Feel free to reach out to Brad Topol (`@bradtopol`) or one of the [SIG Docs co-chairs/leads](https://github.com/kubernetes/community/tree/master/sig-docs#leadership). -- Once you've signed up to shadow a PR Wrangler, introduce yourself to the PR Wrangler on the [Kubernetes Slack](slack.k8s.io). +- Once you've signed up to shadow a PR Wrangler, introduce yourself to the PR Wrangler on the [Kubernetes Slack](https://slack.k8s.io). --> ### 成为一名影子 @@ -221,4 +221,4 @@ In late 2021, SIG Docs introduced the PR Wrangler Shadow Program. The program wa [SIG Docs 联席主席/主管](https://github.com/kubernetes/community/tree/master/sig-docs#leadership)。 - 注册成为一名 PR 管理者的影子时， - 请你在 [Kubernetes Slack](slack.k8s.io) 向这名 PR 管理者做一次自我介绍。 + 请你在 [Kubernetes Slack](https://slack.k8s.io) 向这名 PR 管理者做一次自我介绍。 diff --git a/content/zh/docs/contribute/style/content-guide.md b/content/zh/docs/contribute/style/content-guide.md index 1f787a1b93..91e9d0ee96 100644 --- a/content/zh/docs/contribute/style/content-guide.md +++ b/content/zh/docs/contribute/style/content-guide.md @@ -15,19 +15,19 @@ weight: 10 本页包含 Kubernetes 文档的一些指南。 -如果你不清楚哪些事情是可以做的，请加入到 -[Kubernetes Slack](http://slack.k8s.io/) 的 `#sig-docs` 频道提问！ -你可以在 http://slack.k8s.io 注册到 Kubernetes Slack。 +如果你不清楚哪些事情是可以做的，请加入到 +[Kubernetes Slack](https://slack.k8s.io/) 的 `#sig-docs` 频道提问！ +你可以在 https://slack.k8s.io 注册到 Kubernetes Slack。 关于为 Kubernetes 文档创建新内容的更多信息，可参考 [样式指南](/zh/docs/contribute/style/style-guide)。 @@ -42,7 +42,7 @@ Source for the Kubernetes website, including the docs, resides in the Located in the `kubernetes/website/content//docs` folder, the majority of Kubernetes documentation is specific to the [Kubernetes -project](https://github.com/kubernetes/kubernetes). +project](https://github.com/kubernetes/kubernetes). ## What's allowed @@ -72,12 +72,12 @@ Kubernetes 网站（包括其文档）源代码位于 ### Third party content Kubernetes documentation includes applied examples of projects in the Kubernetes project—projects that live in the [kubernetes](https://github.com/kubernetes) and -[kubernetes-sigs](https://github.com/kubernetes-sigs) GitHub organizations. +[kubernetes-sigs](https://github.com/kubernetes-sigs) GitHub organizations. -Links to active content in the Kubernetes project are always allowed. +Links to active content in the Kubernetes project are always allowed. -Kubernetes requires some third party content to function. Examples include container runtimes (containerd, CRI-O, Docker), -[networking policy](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (CNI plugins), [Ingress controllers](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/), and [logging](https://kubernetes.io/docs/concepts/cluster-administration/logging/). +Kubernetes requires some third party content to function. Examples include container runtimes (containerd, CRI-O, Docker), +[networking policy](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) (CNI plugins), [Ingress controllers](/docs/concepts/services-networking/ingress-controllers/), and [logging](/docs/concepts/cluster-administration/logging/). Docs can link to third-party open source software (OSS) outside the Kubernetes project only if it's necessary for Kubernetes to function. --> @@ -94,7 +94,7 @@ Kubernetes 需要某些第三方内容才能正常工作。例如 容器运行时（containerd、CRI-O、Docker）， [联网策略](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) （CNI 插件），[Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers/) -以及[日志](https://kubernetes.io/zh/docs/concepts/cluster-administration/logging/)等。 +以及[日志](/zh/docs/concepts/cluster-administration/logging/)等。 只有对应的第三方开源软件（OSS）是运行 Kubernetes 所必需的，才可以在文档中包含 指向这些 Kubernetes 项目之外的软件的链接。 @@ -109,7 +109,8 @@ Dual-sourced content requires double the effort (or more!) to maintain and grows stale more quickly. {{< note >}} -If you're a maintainer for a Kubernetes project and need help hosting your own docs, + +If you're a maintainer for a Kubernetes project and need help hosting your own docs, ask for help in [#sig-docs on Kubernetes Slack](https://kubernetes.slack.com/messages/C1J0BPD2M/). {{< /note >}} --> @@ -128,15 +129,13 @@ ask for help in [#sig-docs on Kubernetes Slack](https://kubernetes.slack.com/mes ### 更多信息 {#more-information} -如果你对允许出现的内容有疑问，请加入到 [Kubernetes Slack](http://slack.k8s.io/) +如果你对允许出现的内容有疑问，请加入到 [Kubernetes Slack](https://slack.k8s.io/) 的 `#sig-docs` 频道提问！ ## {{% heading "whatsnext" %}} * 阅读[样式指南](/zh/docs/contribute/style/style-guide)。 - - diff --git a/content/zh/docs/doc-contributor-tools/linkchecker/README.md b/content/zh/docs/doc-contributor-tools/linkchecker/README.md index 86d1c81683..6f31aed3ab 100644 --- a/content/zh/docs/doc-contributor-tools/linkchecker/README.md +++ b/content/zh/docs/doc-contributor-tools/linkchecker/README.md @@ -1,24 +1,26 @@ - # 内置链接检查工具 - -你可以使用 [htmltest](https://github.com/wjdp/htmltest) 来检查 [`/content/en/`](https://git.k8s.io/website/content/en/) 下面的失效链接。这在重构章节内容、移动页面或者重命名文件或页眉时非常有用。 +你可以使用 [htmltest](https://github.com/wjdp/htmltest) 来检查 +[`/content/en/`](https://git.k8s.io/website/content/en/) 下面的失效链接。 +这在重构章节内容、移动页面或者重命名文件或页眉时非常有用。 - ## 工作原理 - `htmltest` 会扫描 kubernetes website 仓库构建生成的 HTML 文件。通过执行 `make` 命令进行了下列操作： - ## 哪些链接不会检查 - -该链接检查器扫描生成的 HTML 文件，而非原始的 Markdown. 该 htmltest 工具依赖于一个配置文件，[`.htmltest.yml`](https://git.k8s.io/website/.htmltest.yml)，来决定检查哪些内容。 +该链接检查器扫描生成的 HTML 文件，而非原始的 Markdown. 该 htmltest 工具依赖于配置文件 +[`.htmltest.yml`](https://git.k8s.io/website/.htmltest.yml)，来决定检查哪些内容。 该链接检查器扫描以下内容： - 该链接检查器不会扫描以下内容： - - 包含在顶部和侧边导航栏的链接，以及页脚链接或者页面的 `` 部分中的链接，例如 CSS 样式表、脚本以及元信息的链接。 -- 顶级页面及其子页面，例如： `/training`, `/community`, `/case-studies/adidas` +- 顶级页面及其子页面，例如：`/training`、`/community`、`/case-studies/adidas` - 博客文章 -- API 参考文档，例如：https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/ +- API 参考文档，例如： https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/ - 本地化内容 - ## 先决条件以及安装说明 - 必须安装： * [Docker](https://docs.docker.com/get-docker/) * [make](https://www.gnu.org/software/make/) - - ## 运行链接检查器 - 运行链接检查器需要： - ## 理解输出的内容 - 如果链接检查器发现了失效链接，则输出内容类似如下： @@ -125,7 +128,7 @@ tasks/access-kubernetes-api/custom-resources/index.html hash does not exist --- tasks/access-kubernetes-api/custom-resources/index.html --> #preserving-unknown-fields ``` - 这是一系列失效链接。该日志附带了每个页面下的失效链接。 -在这部分输出中，包含失效链接的文件是 `tasks/access-kubernetes-api/custom-resources.md`. +在这部分输出中，包含失效链接的文件是 `tasks/access-kubernetes-api/custom-resources.md`。 -该工具给出了一个理由：`hash does not exist`. 在大部分情况下，你可以忽略这个。 +该工具给出了一个理由：`hash does not exist`，在大部分情况下，你可以忽略这个。 -目标链接是 `#preserving-unknown-fields`. +目标链接是 `#preserving-unknown-fields`。 修复这个问题的一种方式是： - 运行 htmltest 来验证失效链接是否已修复。 \ No newline at end of file diff --git a/content/zh/docs/reference/_index.md b/content/zh/docs/reference/_index.md index 1f3a9dcd93..af2a04118b 100644 --- a/content/zh/docs/reference/_index.md +++ b/content/zh/docs/reference/_index.md @@ -137,6 +137,7 @@ operator to use or manage a cluster. * [kube-apiserver configuration (v1alpha1)](/docs/reference/config-api/apiserver-config.v1alpha1/) * [kube-apiserver configuration (v1)](/docs/reference/config-api/apiserver-config.v1/) * [kube-apiserver encryption (v1)](/docs/reference/config-api/apiserver-encryption.v1/) +* [kube-apiserver event rate limit (v1alpha1)](/docs/reference/config-api/apiserver-eventratelimit.v1/) * [kubelet configuration (v1alpha1)](/docs/reference/config-api/kubelet-config.v1alpha1/) and [kubelet configuration (v1beta1)](/docs/reference/config-api/kubelet-config.v1beta1/) * [kubelet credential providers (v1alpha1)](/docs/reference/config-api/kubelet-credentialprovider.v1alpha1/) @@ -148,6 +149,7 @@ operator to use or manage a cluster. * [Client authentication API (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/) and [Client authentication API (v1)](/docs/reference/config-api/client-authentication.v1/) * [WebhookAdmission configuration (v1)](/docs/reference/config-api/apiserver-webhookadmission.v1/) +* [ImagePolicy API (v1alpha1)](/docs/reference/config-api/imagepolicy.v1alpha1/) --> ## 配置 API @@ -158,6 +160,7 @@ operator to use or manage a cluster. * [kube-apiserver 配置 (v1alpha1)](/zh/docs/reference/config-api/apiserver-config.v1alpha1/) * [kube-apiserver 配置 (v1)](/zh/docs/reference/config-api/apiserver-config.v1/) * [kube-apiserver 加密 (v1)](/zh/docs/reference/config-api/apiserver-encryption.v1/) +* [kube-apiserver 事件速率限制 (v1alpha1)](/zh/docs/reference/config-api/apiserver-eventratelimit.v1/) * [kubelet 配置 (v1alpha1)](/zh/docs/reference/config-api/kubelet-config.v1alpha1/) 和 [kubelet 配置 (v1beta1)](/zh/docs/reference/config-api/kubelet-config.v1beta1/) * [kubelet 凭据驱动 (v1alpha1)](/zh/docs/reference/config-api/kubelet-credentialprovider.v1alpha1/) @@ -169,6 +172,7 @@ operator to use or manage a cluster. * [客户端认证 API (v1beta1)](/zh/docs/reference/config-api/client-authentication.v1beta1/) 和 [客户端认证 API (v1)](/zh/docs/reference/config-api/client-authentication.v1/) * [WebhookAdmission 配置 (v1)](/zh/docs/reference/config-api/apiserver-webhookadmission.v1/) +* [ImagePolicy API (v1alpha1)](/zh/docs/reference/config-api/imagepolicy.v1alpha1/) -此页面概述了准入控制器。 +此页面提供准入控制器（Admission Controllers）的概述。 -## 什么是准入控制插件？ +## 什么是准入控制插件？ {#what-are-they} 准入控制器是一段代码，它会在请求通过认证和授权之后、对象被持久化之前拦截到达 API 服务器的请求。控制器由下面的[列表](#what-does-each-admission-controller-do)组成， -并编译进 `kube-apiserver` 二进制文件，并且只能由集群管理员配置。 +并编译进 `kube-apiserver` 可执行文件，并且只能由集群管理员配置。 在该列表中，有两个特殊的控制器：MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。 它们根据 API 中的配置，分别执行变更和验证 [准入控制 webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。 @@ -64,14 +64,14 @@ If any of the controllers in either phase reject the request, the entire request is rejected immediately and an error is returned to the end-user. --> 准入控制器可以执行 “验证（Validating）” 和/或 “变更（Mutating）” 操作。 -变更（mutating）控制器可以根据被其接受的请求修改相关对象；验证（validating）控制器则不行。 +变更（mutating）控制器可以根据被其接受的请求更改相关对象；验证（validating）控制器则不行。 准入控制器限制创建、删除、修改对象或连接到代理的请求，不限制读取对象的请求。 准入控制过程分为两个阶段。第一阶段，运行变更准入控制器。第二阶段，运行验证准入控制器。 再次提醒，某些控制器既是变更准入控制器又是验证准入控制器。 -如果任何一个阶段的任何控制器拒绝了该请求，则整个请求将立即被拒绝，并向终端用户返回一个错误。 +如果两个阶段之一的任何一个控制器拒绝了某请求，则整个请求将立即被拒绝，并向最终用户返回错误。 -最后，除了对对象进行变更外，准入控制器还可以有其它作用：将相关资源作为请求处理的一部分进行变更。 -增加使用配额就是一个典型的示例，说明了这样做的必要性。 +最后，除了对对象进行变更外，准入控制器还可能有其它副作用：将相关资源作为请求处理的一部分进行变更。 +增加配额用量就是一个典型的示例，说明了这样做的必要性。 此类用法都需要相应的回收或回调过程，因为任一准入控制器都无法确定某个请求能否通过所有其它准入控制器。 -## 为什么需要准入控制器？ +## 为什么需要准入控制器？ {#why-do-i-need-them} Kubernetes 的许多高级功能都要求启用一个准入控制器，以便正确地支持该特性。 -因此，没有正确配置准入控制器的 Kubernetes API 服务器是不完整的，它无法支持你期望的所有特性。 +因此，没有正确配置准入控制器的 Kubernetes API 服务器是不完整的，它无法支持你所期望的所有特性。 -## 如何启用一个准入控制器？ +## 如何启用一个准入控制器？ {how-do-i-turn-on-an-admission-controller} -Kubernetes API 服务器的 `enable-admission-plugins` 标志接受一个用于在集群修改对象之前 -调用的（以逗号分隔的）准入控制插件顺序列表。 +Kubernetes API 服务器的 `enable-admission-plugins` 标志接受一个（以逗号分隔的）准入控制插件列表， +这些插件会在集群修改对象之前被调用。 -例如，下面的命令就启用了 `NamespaceLifecycle` 和 `LimitRanger` 准入控制插件： +例如，下面的命令启用 `NamespaceLifecycle` 和 `LimitRanger` 准入控制插件： ```shell kube-apiserver --enable-admission-plugins=NamespaceLifecycle,LimitRanger ... @@ -128,7 +128,7 @@ have to modify the systemd unit file if the API server is deployed as a systemd service, you may modify the manifest file for the API server if Kubernetes is deployed in a self-hosted way. --> -根据你 Kubernetes 集群的部署方式以及 API 服务器的启动方式的不同，你可能需要以不同的方式应用设置。 +根据你 Kubernetes 集群的部署方式以及 API 服务器的启动方式，你可能需要以不同的方式应用设置。 例如，如果将 API 服务器部署为 systemd 服务，你可能需要修改 systemd 单元文件； 如果以自托管方式部署 Kubernetes，你可能需要修改 API 服务器的清单文件。 {{< /note >}} @@ -138,7 +138,7 @@ in a self-hosted way. The Kubernetes API server flag `disable-admission-plugins` takes a comma-delimited list of admission control plugins to be disabled, even if they are in the list of plugins enabled by default. --> -## 怎么关闭准入控制器？ +## 怎么关闭准入控制器？ {#how-do-i-turn-off-an-admission-controller} Kubernetes API 服务器的 `disable-admission-plugins` 标志，会将传入的（以逗号分隔的） 准入控制插件列表禁用，即使是默认启用的插件也会被禁用。 @@ -152,9 +152,9 @@ kube-apiserver --disable-admission-plugins=PodNodeSelector,AlwaysDeny ... To see which admission plugins are enabled: --> -## 哪些插件是默认启用的？ +## 哪些插件是默认启用的？ {#which-plugins-are-enabled-by-default} -下面的命令可以查看哪些插件是默认启用的： +要查看哪些插件是被启用的： ```shell kube-apiserver -h | grep enable-admission-plugins @@ -164,26 +164,25 @@ kube-apiserver -h | grep enable-admission-plugins In the current version, the default ones are: --> -在目前版本中，它们是： +在目前版本中，默认启用的插件有： -```shell -CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, LimitRanger, MutatingAdmissionWebhook, NamespaceLifecycle, PersistentVolumeClaimResize, Priority, ResourceQuota, RuntimeClass, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook +``` +CertificateApproval, CertificateSigning, CertificateSubjectRestriction, DefaultIngressClass, DefaultStorageClass, DefaultTolerationSeconds, LimitRanger, MutatingAdmissionWebhook, NamespaceLifecycle, PersistentVolumeClaimResize, PodSecurity, Priority, ResourceQuota, RuntimeClass, ServiceAccount, StorageObjectInUseProtection, TaintNodesByCondition, ValidatingAdmissionWebhook ``` -## 每个准入控制器的作用是什么？ +## 每个准入控制器的作用是什么？ {#what-does-each-admission-controller-do} -### AlwaysAdmit {#alwaysadmit} +### AlwaysAdmit {#alwaysadmit} {{< feature-state for_k8s_version="v1.13" state="deprecated" >}} -该准入控制器会允许所有的 pod 接入集群。已废弃，因为它的行为根本就和没有准入控制器一样。 + +该准入控制器允许所有的 Pod 进入集群。此插件已被弃用，因其行为与没有准入控制器一样。 ### AlwaysDeny {#alwaysdeny} @@ -192,7 +191,7 @@ This admission controller allows all pods into the cluster. It is deprecated bec -拒绝所有的请求。由于它没有实际意义，已废弃。 +拒绝所有的请求。由于它没有实际意义，已被弃用。 ### AlwaysPullImages {#alwayspullimages} @@ -205,58 +204,58 @@ scheduled onto the right node), without any authorization check against the imag is enabled, images are always pulled prior to starting containers, which means valid credentials are required. --> -该准入控制器会修改每一个新创建的 Pod 的镜像拉取策略为 Always 。 +该准入控制器会修改每个新创建的 Pod，将其镜像拉取策略设置为 Always。 这在多租户集群中是有用的，这样用户就可以放心，他们的私有镜像只能被那些有凭证的人使用。 -如果没有这个准入控制器，一旦镜像被拉取到节点上，任何用户的 Pod 都可以通过已了解到的镜像 -的名称（假设 Pod 被调度到正确的节点上）来使用它，而不需要对镜像进行任何授权检查。 -当启用这个准入控制器时，总是在启动容器之前拉取镜像，这意味着需要有效的凭证。 +如果没有这个准入控制器，一旦镜像被拉取到节点上，任何用户的 Pod 都可以通过已了解到的镜像的名称 +（假设 Pod 被调度到正确的节点上）来使用它，而不需要对镜像进行任何鉴权检查。 +启用这个准入控制器之后，启动容器之前必须拉取镜像，这意味着需要有效的凭证。 -### CertificateApproval +### CertificateApproval {#certificateapproval} - -此准入控制器获取“审批” CertificateSigningRequest 资源的请求并执行额外的授权检查， -以确保审批请求的用户有权限审批 `spec.signerName` 请求 CertificateSigningRequest 资源的证书请求。 +此准入控制器获取“审批” CertificateSigningRequest 资源的请求并执行额外的鉴权检查， +以确保针对设置了 `spec.signerName` 的 CertificateSigningRequest 资源而言， +审批请求的用户有权限对证书请求执行 `approve` 操作。 +有关对 CertificateSigningRequest 资源执行不同操作所需权限的详细信息， +请参阅[证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/)。 -有关对证书签名请求资源执行不同操作所需权限的详细信息， -请参阅[证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/) - -### CertificateSigning +### CertificateSigning {#certificatesigning} -此准入控制器获取 CertificateSigningRequest 资源的 `status.certificate` 字段更新请求并执行额外的授权检查， -以确保签发证书的用户有权限为 `spec.signerName` 请求 CertificateSigningRequest 资源的证书请求`签发`证书。 +此准入控制器监视对 CertificateSigningRequest 资源的 `status.certificate` 字段的更新请求， +并执行额外的鉴权检查，以确保针对设置了 `spec.signerName` 的 CertificateSigningRequest 资源而言， +签发证书的用户有权限对证书请求执行 `sign` 操作。 -有关对证书签名请求资源执行不同操作所需权限的详细信息， -请参阅[证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/) +有关对 CertificateSigningRequest 资源执行不同操作所需权限的详细信息， +请参阅[证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/)。 -### CertificateSubjectRestrictions +### CertificateSubjectRestrictions {#certificatesubjectrestrictions} -此准入控制器获取具有 `kubernetes.io/kube-apiserver-client` 的 `spec.signerName` 的 -CertificateSigningRequest 资源创建请求， -它拒绝任何包含了 `system:masters` 一个“组”（或者“组织”）的请求。 +此准入控制器监视 `spec.signerName` 被设置为 `kubernetes.io/kube-apiserver-client` 的 +CertificateSigningRequest 资源创建请求，并拒绝所有将 “group”（或 “organization attribute”） +设置为 `system:masters` 的请求。 ### DefaultIngressClass {#defaultingressclass} @@ -266,8 +265,8 @@ ingress class and automatically adds a default ingress class to them. This way, request any special ingress class do not need to care about them at all and they will get the default one. --> -该准入控制器监测没有请求任何特定 Ingress 类的 `Ingress` 对象的创建，并自动向其添加默认 Ingress 类。 -这样，没有任何特殊 Ingress 类需求的用户根本不需要关心它们，它们将获得默认 Ingress 类。 +该准入控制器监测没有请求任何特定 Ingress 类的 `Ingress` 对象创建请求，并自动向其添加默认 Ingress 类。 +这样，没有任何特殊 Ingress 类需求的用户根本不需要关心它们，他们将被设置为默认 Ingress 类。 -当未配置默认 Ingress 类时，此准入控制器不执行任何操作。如果将多个 Ingress 类标记为默认 Ingress 类， -它将拒绝任何创建 `Ingress` 的操作，并显示错误。 -要修复此错误，管理员必须重新检查其 `IngressClass` 对象，并仅将其中一个标记为默认（通过注解 -"ingressclass.kubernetes.io/is-default-class"）。 -此准入控制器会忽略所有 `Ingress` 更新操作，仅响应创建操作。 +当未配置默认 Ingress 类时，此准入控制器不执行任何操作。如果有多个 Ingress 类被标记为默认 Ingress 类， +此控制器将拒绝所有创建 `Ingress` 的操作，并返回错误信息。 +要修复此错误，管理员必须重新检查其 `IngressClass` 对象，并仅将其中一个标记为默认 +（通过注解 "ingressclass.kubernetes.io/is-default-class"）。 +此准入控制器会忽略所有 `Ingress` 更新操作，仅处理创建操作。 关于 Ingress 类以及如何将 Ingress 类标记为默认的更多信息，请参见 -[ingress](/zh/docs/concepts/services-networking/ingress/)。 +[Ingress](/zh/docs/concepts/services-networking/ingress/) 页面。 ### DefaultStorageClass {#defaultstorageclass} @@ -297,9 +296,9 @@ and automatically adds a default storage class to them. This way, users that do not request any special storage class do not need to care about them at all and they will get the default one. --> -该准入控制器监测没有请求任何特定存储类的 `PersistentVolumeClaim` 对象的创建， +此准入控制器监测没有请求任何特定存储类的 `PersistentVolumeClaim` 对象的创建请求， 并自动向其添加默认存储类。 -这样，没有任何特殊存储类需求的用户根本不需要关心它们，它们将获得默认存储类。 +这样，没有任何特殊存储类需求的用户根本不需要关心它们，它们将被设置为使用默认存储类。 当未配置默认存储类时，此准入控制器不执行任何操作。如果将多个存储类标记为默认存储类， -它将拒绝任何创建 `PersistentVolumeClaim` 的操作，并显示错误。 -要修复此错误，管理员必须重新访问其 `StorageClass` 对象，并仅将其中一个标记为默认。 -此准入控制器会忽略所有 `PersistentVolumeClaim` 更新操作，仅响应创建操作。 +此控制器将拒绝所有创建 `PersistentVolumeClaim` 的请求，并返回错误信息。 +要修复此错误，管理员必须重新检查其 `StorageClass` 对象，并仅将其中一个标记为默认。 +此准入控制器会忽略所有 `PersistentVolumeClaim` 更新操作，仅处理创建操作。 -关于持久化卷和存储类，以及如何将存储类标记为默认，请参见 -[持久化卷](/zh/docs/concepts/storage/persistent-volumes/)。 +关于持久卷申领和存储类，以及如何将存储类标记为默认，请参见[持久卷](/zh/docs/concepts/storage/persistent-volumes/)页面。 ### DefaultTolerationSeconds {#defaulttolerationseconds} -该准入控制器基于 k8s-apiserver 输入参数 `default-not-ready-toleration-seconds` 和 +此准入控制器基于 k8s-apiserver 的输入参数 `default-not-ready-toleration-seconds` 和 `default-unreachable-toleration-seconds` 为 Pod 设置默认的容忍度，以容忍 `notready:NoExecute` 和 -`unreachable:NoExecute` 污点。 +`unreachable:NoExecute` 污点 （如果 Pod 尚未容忍 `node.kubernetes.io/not-ready：NoExecute` 和 -`node.kubernetes.io/unreachable：NoExecute` 污点的话） -`default-not-ready-toleration-seconds` 和 `default-unreachable-toleration-seconds` 的默认值是 5 分钟。 +`node.kubernetes.io/unreachable：NoExecute` 污点的话）。 +`default-not-ready-toleration-seconds` 和 `default-unreachable-toleration-seconds` +的默认值是 5 分钟。 ### DenyEscalatingExec {#denyescalatingexec} @@ -345,9 +344,9 @@ This admission controller will deny exec and attach commands to pods that run wi allow host access. This includes pods that run as privileged, have access to the host IPC namespace, and have access to the host PID namespace. --> -该准入控制器将拒绝在由于拥有升级特权，而具备访问宿主机能力的 Pod 中执行 exec 和 -attach 命令。这包括在特权模式运行的 Pod，可以访问主机 IPC 名字空间的 Pod， -和访问主机 PID 名字空间的 Pod 。 +此准入控制器将拒绝在由于拥有提级特权而具备访问宿主机能力的 Pod 中执行 exec 和 +attach 命令。这类 Pod 包括在特权模式运行的 Pod、可以访问主机 IPC 名字空间的 Pod、 +和访问主机 PID 名字空间的 Pod。 -DenyExecOnPrivileged 准入插件已被废弃。 +DenyEscalatingExec 准入插件已被弃用。 建议使用基于策略的准入插件（例如 [PodSecurityPolicy](#podsecuritypolicy) 和自定义准入插件）， -该插件可以针对特定用户或名字空间，还可以防止创建权限过高的 Pod。 +这类插件可以针对特定用户或名字空间，还可以防止创建权限过高的 Pod。 ### DenyExecOnPrivileged {#denyexeconprivileged} @@ -368,14 +367,14 @@ DenyExecOnPrivileged 准入插件已被废弃。 -如果一个 pod 拥有一个特权容器，该准入控制器将拦截所有在该 pod 中执行 exec 命令的请求。 +如果一个 Pod 中存在特权容器，该准入控制器将拦截所有在该 Pod 中执行 exec 命令的请求。 此功能已合并至 [DenyEscalatingExec](#denyescalatingexec)。 -而 DenyExecOnPrivileged 准入插件已被废弃。 +而 DenyExecOnPrivileged 准入插件已被弃用。 建议使用基于策略的准入插件（例如 [PodSecurityPolicy](#podsecuritypolicy) 和自定义准入插件）， -该插件可以针对特定用户或名字空间，还可以防止创建权限过高的 Pod。 +这类插件可以针对特定用户或名字空间，还可以防止创建权限过高的 Pod。 -### DenyServiceExternalIPs +### DenyServiceExternalIPs {#denyserviceexternalips} -该准入控制器拒绝 `Service` 字段 `externalIPs` 的所有新规使用。 此功能非常强大（允许网络流量拦截）， -并且无法很好地受策略控制。 启用后，群集用户将无法创建使用 `externalIPs` 的新服务，也无法在现有 -`Service` 对象上向 `externalIPs` 添加新值。 `externalIPs` 的现有使用不受影响，用户可以从现有 -`Service` 对象上的 `externalIPs` 中删除值。 +此准入控制器拒绝新的 `Service` 中使用字段 `externalIPs`。 +此功能非常强大（允许网络流量拦截），并且无法很好地受策略控制。 +启用后，集群用户将无法创建使用 `externalIPs` 的新 `Service`，也无法在现有 +`Service` 对象上为 `externalIPs` 添加新值。 +`externalIPs` 的现有使用不受影响，用户可以在现有 `Service` 对象上从 +`externalIPs` 中删除值。 -大多数用户根本不需要此功能，集群管理员应考虑将其禁用。 -确实需要使用此功能的集群应考虑使用一些自定义策略来管理其的使用。 +大多数用户根本不需要此特性，集群管理员应考虑将其禁用。 +确实需要使用此特性的集群应考虑使用一些自定义策略来管理 `externalIPs` 的使用。 ### EventRateLimit {#eventratelimit} @@ -416,45 +417,30 @@ of it. This admission controller mitigates the problem where the API server gets flooded by event requests. The cluster admin can specify event rate limits by: --> -该准入控制器缓解了事件请求淹没 API 服务器的问题。集群管理员可以通过以下方式指定事件速率限制： +此准入控制器缓解了事件请求淹没 API 服务器的问题。集群管理员可以通过以下方式指定事件速率限制： * 启用 `EventRateLimit` 准入控制器； -* 从文件中引用 `EventRateLimit` 配置文件，并提供给 API 服务器命令的 - `--admission-control-config-file` 标志： +* 在通过 API 服务器的命令行标志 `--admission-control-config-file` 设置的文件中， + 引用 `EventRateLimit` 配置文件： -{{< tabs name="eventratelimit_example" >}} -{{% tab name="apiserver.config.k8s.io/v1" %}} -```yaml -apiVersion: apiserver.config.k8s.io/v1 -kind: AdmissionConfiguration -plugins: -- name: EventRateLimit - path: eventconfig.yaml -... -``` -{{% /tab %}} -{{% tab name="apiserver.k8s.io/v1alpha1" %}} -```yaml -# Deprecated in v1.17 in favor of apiserver.config.k8s.io/v1 -apiVersion: apiserver.k8s.io/v1alpha1 -kind: AdmissionConfiguration -plugins: -- name: EventRateLimit - path: eventconfig.yaml -... -``` -{{% /tab %}} -{{< /tabs >}} + ```yaml + apiVersion: apiserver.config.k8s.io/v1 + kind: AdmissionConfiguration + plugins: + - name: EventRateLimit + path: eventconfig.yaml + ... + ``` -可以在配置中指定四种类型的限制： +可以在配置中指定的限制有四种类型： * `Server`: API 服务器收到的所有事件请求共享一个桶。 -* `Namespace`: 每个名字空间都有一个专用的桶。 -* `User`: 给每个用户都分配一个桶。 -* `SourceAndObject`: 根据事件的源和涉及对象的每种组合分配桶。 +* `Namespace`: 每个名字空间都对应一个专用的桶。 +* `User`: 为每个用户分配一个桶。 +* `SourceAndObject`: 根据事件的来源和涉及对象的各种组合分配桶。 -下面是一个配置示例 `eventconfig.yaml`： +下面是一个针对此配置的 `eventconfig.yaml` 示例： ```yaml apiVersion: eventratelimit.admission.k8s.io/v1alpha1 kind: Configuration limits: -- type: Namespace - qps: 50 - burst: 100 - cacheSize: 2000 -- type: User - qps: 10 - burst: 50 + - type: Namespace + qps: 50 + burst: 100 + cacheSize: 2000 + - type: User + qps: 10 + burst: 50 ``` 详情请参见 -[事件速率限制提案](https://git.k8s.io/community/contributors/design-proposals/api-machinery/admission_control_event_rate_limit.md)。 +[EventRateLimit 配置 API 文档（v1alpha1）](/zh/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/)。 ### ExtendedResourceToleration {#extendedresourcetoleration} @@ -503,30 +489,29 @@ name as the key. This admission controller, if enabled, automatically adds tolerations for such taints to pods requesting extended resources, so users don't have to manually add these tolerations. --> -该插件有助于创建可扩展资源的专用节点。 -如果运营商想创建可扩展资源的专用节点（如 GPU、FPGA 等）， -那他们应该以扩展资源名称作为键名， +此插件有助于创建带有扩展资源的专用节点。 +如果运维人员想要创建带有扩展资源（如 GPU、FPGA 等）的专用节点，他们应该以扩展资源名称作为键名， [为节点设置污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。 -如果启用了该准入控制器，会将此类污点的容忍自动添加到请求扩展资源的 Pod 中， -用户不必再手动添加这些容忍。 +如果启用了此准入控制器，会将此类污点的容忍度自动添加到请求扩展资源的 Pod 中， +用户不必再手动添加这些容忍度。 ### ImagePolicyWebhook {#imagepolicywebhook} -ImagePolicyWebhook 准入控制器允许使用一个后端的 webhook 做出准入决策。 +ImagePolicyWebhook 准入控制器允许使用后端 Webhook 做出准入决策。 -#### 配置文件格式 +#### 配置文件格式 {#configuration-file-format} -ImagePolicyWebhook 使用配置文件来为后端行为设置配置选项。该文件可以是 JSON 或 YAML， +ImagePolicyWebhook 使用配置文件来为后端行为设置选项。该文件可以是 JSON 或 YAML， 并具有以下格式: ```yaml @@ -545,11 +530,9 @@ imagePolicy: -从文件中引用 ImagePolicyWebhook 的配置文件，并将其提供给 API 服务器命令标志 -`--admission-control-config-file`： +在通过命令行标志 `--admission-control-config-file` 为 API 服务器提供的文件中， +引用 ImagePolicyWebhook 配置文件： -{{< tabs name="imagepolicywebhook_example1" >}} -{{% tab name="apiserver.config.k8s.io/v1" %}} ```yaml apiVersion: apiserver.config.k8s.io/v1 kind: AdmissionConfiguration @@ -558,27 +541,12 @@ plugins: path: imagepolicyconfig.yaml ... ``` -{{% /tab %}} -{{% tab name="apiserver.k8s.io/v1alpha1" %}} -```yaml -# v1.17 中已废弃以鼓励使用 apiserver.config.k8s.io/v1 -apiVersion: apiserver.k8s.io/v1alpha1 -kind: AdmissionConfiguration -plugins: -- name: ImagePolicyWebhook - path: imagepolicyconfig.yaml -... -``` -{{% /tab %}} -{{< /tabs >}} -或者，你也可以直接将配置嵌入到文件中： +或者，你也可以直接将配置嵌入到该文件中： -{{< tabs name="imagepolicywebhook_example2" >}} -{{% tab name="apiserver.config.k8s.io/v1" %}} ```yaml apiVersion: apiserver.config.k8s.io/v1 kind: AdmissionConfiguration @@ -592,24 +560,6 @@ plugins: retryBackoff: 500 defaultAllow: true ``` -{{% /tab %}} -{{% tab name="apiserver.k8s.io/v1alpha1" %}} -```yaml -# v1.17 中已废弃以鼓励使用 apiserver.config.k8s.io/v1 -apiVersion: apiserver.k8s.io/v1alpha1 -kind: AdmissionConfiguration -plugins: -- name: ImagePolicyWebhook - configuration: - imagePolicy: - kubeConfigFile: - allowTTL: 50 - denyTTL: 50 - retryBackoff: 500 - defaultAllow: true -``` -{{% /tab %}} -{{< /tabs >}} ImagePolicyWebhook 的配置文件必须引用 [kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) -格式的文件；该文件设置了到后端的连接参数。 -要求后端使用 TLS 进行通信。 +格式的文件；该文件用来设置与后端的连接。要求后端使用 TLS 进行通信。 -kubeconfig 文件的 cluster 字段需要指向远端服务，user 字段需要包含已返回的授权者。 +kubeconfig 文件的 `clusters` 字段需要指向远端服务，`users` 字段需要包含已返回的授权者。 #### 请求载荷 当面对一个准入决策时，API 服务器发送一个描述操作的 JSON 序列化的 `imagepolicy.k8s.io/v1alpha1` `ImageReview` 对象。 -该对象包含描述被审核容器的字段，以及所有匹配 `*.image-policy.k8s.io/*` 的 -Pod 注解。 +该对象包含描述被准入容器的字段，以及与 `*.image-policy.k8s.io/*` 匹配的所有 Pod 注解。 +{{ note }} 注意，Webhook API 对象与其他 Kubernetes API 对象一样受制于相同的版本控制兼容性规则。 -实现者应该知道对 alpha 对象的更宽松的兼容性，并检查请求的 "apiVersion" 字段， +实现者应该知道对 alpha 对象兼容性是相对宽松的，并检查请求的 "apiVersion" 字段， 以确保正确的反序列化。 此外，API 服务器必须启用 `imagepolicy.k8s.io/v1alpha1` API 扩展组 （`--runtime-config=imagepolicy.k8s.io/v1alpha1=true`）。 +{{ /note }} 远程服务将填充请求的 `ImageReviewStatus` 字段，并返回允许或不允许访问的响应。 -响应体的 "spec" 字段会被忽略，并且可以省略。一个允许访问应答会返回： +响应体的 `spec` 字段会被忽略，并且可以被省略。一个允许访问应答会返回： ```json { @@ -750,22 +711,25 @@ To disallow access, the service would return: ``` -更多的文档，请参阅 `imagepolicy.v1alpha1` API 对象和 -`plugin/pkg/admission/imagepolicy/admission.go`。 +更多的文档，请参阅 [`imagepolicy.v1alpha1` API](/zh/docs/reference/config-api/imagepolicy.v1alpha1/)。 -#### 使用注解进行扩展 +#### 使用注解进行扩展 {#extending-with-annotations} 一个 Pod 中匹配 `*.image-policy.k8s.io/*` 的注解都会被发送给 Webhook。 -这样做使得了解后端镜像策略的用户可以向它发送额外的信息，并为不同的后端实现 -接收不同的信息。 +这样做使得了解后端镜像策略的用户可以向它发送额外的信息， +并让不同的后端实现接收不同的信息。 -* 在紧急情况下，请求 "break glass" 覆盖一个策略。 -* 从一个记录了 break-glass 的请求的 ticket 系统得到的一个 ticket 号码。 -* 向策略服务器提供一个提示，用于提供镜像的 imageID，以方便它进行查找。 +* 在紧急情况下，请求破例覆盖某个策略。 +* 从一个记录了破例的请求的工单（Ticket）系统得到的一个工单号码。 +* 向策略服务器提供提示信息，用于提供镜像的 imageID，以方便它进行查找。 在任何情况下，注解都是由用户提供的，并不会被 Kubernetes 以任何方式进行验证。 -在将来，如果一个注解确定将被广泛使用，它可能会被提升为 ImageReviewSpec 的一个命名字段。 -### LimitPodHardAntiAffinityTopology {#limitpodhardantiaffinitytopology} +### LimitPodHardAntiAffinityTopology {#limitpodhardantiaffinitytopology} -该准入控制器拒绝（定义了 `AntiAffinity` 拓扑键的）任何 Pod -（`requiredDuringSchedulingRequiredDuringExecution` 中的 -`kubernetes.io/hostname` 除外）。 +此准入控制器拒绝定义了 `AntiAffinity` 拓扑键的任何 Pod +（`requiredDuringSchedulingRequiredDuringExecution` 中的 `kubernetes.io/hostname` 除外）。 ### LimitRanger {#limitranger} -该准入控制器会观察传入的请求，并确保它不会违反 `Namespace` 中 `LimitRange` -对象枚举的任何约束。 -如果你在 Kubernetes 部署中使用了 `LimitRange` 对象，则必须使用此准入控制器来 -执行这些约束。 -LimitRanger 还可以用于将默认资源请求应用到没有指定任何内容的 Pod； -当前，默认的 LimitRanger 对 `default` 名字空间中的所有 Pod 都应用了 -0.1 CPU 的需求。 +此准入控制器会监测传入的请求，并确保请求不会违反 `Namespace` 中 `LimitRange` 对象所设置的任何约束。 +如果你在 Kubernetes 部署中使用了 `LimitRange` 对象，则必须使用此准入控制器来执行这些约束。 +LimitRanger 还可以用于将默认资源请求应用到没有设定资源约束的 Pod； +当前，默认的 LimitRanger 对 `default` 名字空间中的所有 Pod 都设置 0.1 CPU 的需求。 请查看 -[limitRange 设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) -和 [LimitRange 例子](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/) -以了解更多细节。 +[limitRange API 文档](/zh/docs/reference/kubernetes-api/policy-resources/limit-range-v1/)和 +[LimitRange 例子](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)以了解更多细节。 -### MutatingAdmissionWebhook {#mutatingadmissionwebhook} +### MutatingAdmissionWebhook {#mutatingadmissionwebhook} -该准入控制器调用任何与请求匹配的变更 Webhook。匹配的 Webhook 将被串行调用。 -每一个 Webhook 都可以根据需要修改对象。 +此准入控制器调用任何与请求匹配的变更（Mutating） Webhook。匹配的 Webhook 将被顺序调用。 +每一个 Webhook 都可以自由修改对象。 `MutatingAdmissionWebhook`，顾名思义，仅在变更阶段运行。 @@ -841,42 +801,41 @@ If a webhook called by this has side effects (for example, decrementing quota) i *must* have a reconciliation system, as it is not guaranteed that subsequent webhooks or validating admission controllers will permit the request to finish. --> -如果由此准入控制器调用的 Webhook 有副作用（如降低配额）， -则它 *必须* 具有协调系统，因为不能保证后续的 Webhook 和验证准入控制器都会允许完成请求。 +如果由此准入控制器调用的 Webhook 有副作用（如：减少配额）， +则它 **必须** 具有协调系统，因为不能保证后续的 Webhook 和验证准入控制器都会允许完成请求。 如果你禁用了 MutatingAdmissionWebhook，那么还必须使用 `--runtime-config` 标志禁止 -`admissionregistration.k8s.io/v1` 组/版本中的 `MutatingWebhookConfiguration` -对象（版本 >=1.9 时，这两个对象都是默认启用的）。 +`admissionregistration.k8s.io/v1` 组/版本中的 `MutatingWebhookConfiguration`， +二者都是默认启用的。 -#### 谨慎编写和安装变更 webhook +#### 谨慎编写和安装变更 webhook {#use-caution-when-authoring-and-installing-mutating-webhooks} * 当用户尝试创建的对象与返回的对象不同时，用户可能会感到困惑。 -* 当它们回读的对象与尝试创建的对象不同，内建的控制环可能会出问题。 +* 当他们读回的对象与尝试创建的对象不同，内建的控制回路可能会出问题。 * 与覆盖原始请求中设置的字段相比，使用原始请求未设置的字段会引起问题的可能性较小。 - 应尽量避免前面那种方式。 -* 内建资源和第三方资源的控制回路未来可能会受到破坏性的更改，使现在运行良好的 Webhook - 无法再正常运行。即使完成了 Webhook API 安装，也不代表会为该 webhook 提供无限期的支持。 + 应尽量避免覆盖原始请求中的字段设置。 +* 内建资源和第三方资源的控制回路未来可能会出现破坏性的变更，使现在运行良好的 Webhook + 无法再正常运行。即使完成了 Webhook API 安装，也不代表该 Webhook 会被提供无限期的支持。 ### NamespaceAutoProvision {#namespaceautoprovision} @@ -887,9 +846,9 @@ It creates a namespace if it cannot be found. This admission controller is useful in deployments that do not want to restrict creation of a namespace prior to its usage. --> -该准入控制器会检查名字空间资源上的所有传入请求，并检查所引用的名字空间是否确实存在。 -如果找不到，它将创建一个名字空间。 -此准入控制器对于不想要求名字空间必须先创建后使用的集群部署中很有用。 +此准入控制器会检查针对名字空间域资源的所有传入请求，并检查所引用的名字空间是否确实存在。 +如果找不到所引用的名字空间，控制器将创建一个名字空间。 +此准入控制器对于不想要求名字空间必须先创建后使用的集群部署很有用。 ### NamespaceExists {#namespaceexists} @@ -897,26 +856,28 @@ a namespace prior to its usage. This admission controller checks all requests on namespaced resources other than `Namespace` itself. If the namespace referenced from a request doesn't exist, the request is rejected. --> -该准入控制器检查除 `Namespace` 以外的名字空间作用域资源上的所有请求。 +此准入控制器检查针对名字空间作用域的资源（除 `Namespace` 自身）的所有请求。 如果请求引用的名字空间不存在，则拒绝该请求。 ### NamespaceLifecycle {#namespacelifecycle} -该准入控制器禁止在一个正在被终止的 `Namespace` 中创建新对象，并确保 -使用不存在的 `Namespace` 的请求被拒绝。 +该准入控制器禁止在一个正在被终止的 `Namespace` 中创建新对象，并确保针对不存在的 +`Namespace` 的请求被拒绝。 该准入控制器还会禁止删除三个系统保留的名字空间，即 `default`、 `kube-system` 和 `kube-public`。 -删除 `Namespace` 会触发删除该名字空间中所有对象（Pod、Service 等）的一系列操作。 +`Namespace` 的删除操作会触发一系列删除该名字空间中所有对象（Pod、Service 等）的操作。 为了确保这个过程的完整性，我们强烈建议启用这个准入控制器。 ### NodeRestriction {#noderestriction} @@ -926,51 +887,52 @@ This admission controller limits the `Node` and `Pod` objects a kubelet can modi kubelets must use credentials in the `system:nodes` group, with a username in the form `system:node:`. Such kubelets will only be allowed to modify their own `Node` API object, and only modify `Pod` API objects that are bound to their node. --> -该准入控制器限制了 kubelet 可以修改的 `Node` 和 `Pod` 对象。 +该准入控制器限制了某 kubelet 可以修改的 `Node` 和 `Pod` 对象。 为了受到这个准入控制器的限制，kubelet 必须使用在 `system:nodes` 组中的凭证， 并使用 `system:node:` 形式的用户名。 -这样，kubelet 只可修改自己的 `Node` API 对象，只能修改绑定到节点本身的 Pod 对象。 +这样，kubelet 只可修改自己的 `Node` API 对象，只能修改绑定到自身节点的 Pod 对象。 -在 Kubernetes 1.11+ 的版本中，不允许 kubelet 从 `Node` API 对象中更新或删除污点。 +不允许 kubelet 更新或删除 `Node` API 对象的污点。 -在 Kubernetes 1.13+ 的版本中，`NodeRestriction` 准入插件可防止 kubelet 删除 -`Node` API 对象，并对 `kubernetes.io/` 或 `k8s.io/` 前缀标签的 kubelet -强制进行如下修改： +`NodeRestriction` 准入插件可防止 kubelet 删除其 `Node` API 对象， +并对前缀为 `kubernetes.io/` 或 `k8s.io/` 的标签的修改对 kubelet 作如下限制： -* **防止** kubelet 添加/删除/更新带有 `node-restriction.kubernetes.io/` 前缀的标签。 - 保留此前缀的标签，供管理员用来标记 Node 对象以隔离工作负载，并且不允许 kubelet +* **禁止** kubelet 添加、删除或更新前缀为 `node-restriction.kubernetes.io/` 的标签。 + 这类前缀的标签时保留给管理员的，用以为 `Node` 对象设置标签以隔离工作负载，而不允许 kubelet 修改带有该前缀的标签。 -* **允许** kubelet 添加/删除/更新这些和这些前缀的标签： +* **允许** kubelet 添加、删除、更新以下标签： * `kubernetes.io/hostname` * `kubernetes.io/arch` * `kubernetes.io/os` * `beta.kubernetes.io/instance-type` * `node.kubernetes.io/instance-type` * `failure-domain.beta.kubernetes.io/region` （已弃用） - * `failure-domain.beta.kubernetes.io/zone` (已弃用） + * `failure-domain.beta.kubernetes.io/zone` （已弃用） * `topology.kubernetes.io/region` * `topology.kubernetes.io/zone` - * `kubelet.kubernetes.io/`-prefixed labels - * `node.kubernetes.io/`-prefixed labels + * `kubelet.kubernetes.io/` 为前缀的标签 + * `node.kubernetes.io/` 为前缀的标签 -kubelet 保留 `kubernetes.io` 或 `k8s.io` 前缀的所有标签，并且将来可能会被 +以 `kubernetes.io` 或 `k8s.io` 为前缀的所有其他标签都限制 kubelet 使用，并且将来可能会被 `NodeRestriction` 准入插件允许或禁止。 将来的版本可能会增加其他限制，以确保 kubelet 具有正常运行所需的最小权限集。 @@ -984,39 +946,32 @@ This admission controller also protects the access to `metadata.ownerReferences[ of an object, so that only users with "update" permission to the `finalizers` subresource of the referenced *owner* can change it. --> -该准入控制器保护对 `metadata.ownerReferences` 对象的访问，以便只有对该对象具有 -“删除” 权限的用户才能对其进行更改。 +此准入控制器保护对对象的 `metadata.ownerReferences` 的访问，以便只有对该对象具有 +“delete” 权限的用户才能对其进行更改。 该准入控制器还保护对 `metadata.ownerReferences[x].blockOwnerDeletion` 对象的访问， -以便只有对所引用的 **属主（owner）** 的 `finalizers` 子资源具有 “更新” +以便只有对所引用的 **属主（owner）** 的 `finalizers` 子资源具有 “update” 权限的用户才能对其进行更改。 ### PersistentVolumeClaimResize {#persistentvolumeclaimresize} - -该准入控制器检查传入的 `PersistentVolumeClaim` 调整大小请求，对其执行额外的验证操作。 - -{{< note >}} - -对调整卷大小的支持是一种 Beta 特性。作为集群管理员，你必须确保特性门控 `ExpandPersistentVolumes` -设置为 `true` 才能启用调整大小。 -{{< /note >}} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} +此准入控制器检查传入的 `PersistentVolumeClaim` 调整大小请求，对其执行额外的验证检查操作。 + + -启用 `ExpandPersistentVolumes` 特性门控之后，建议将 `PersistentVolumeClaimResize` -准入控制器也启用。除非 PVC 的 `StorageClass` 明确地将 `allowVolumeExpansion` 设置为 -`true` 来显式启用调整大小。否则，默认情况下该准入控制器会阻止所有对 PVC 大小的调整。 +建议启用 `PersistentVolumeClaimResize` 准入控制器。除非 PVC 的 `StorageClass` 明确地将 +`allowVolumeExpansion` 设置为 `true` 来显式启用调整大小。 +否则，默认情况下该准入控制器会阻止所有对 PVC 大小的调整。 例如：由以下 `StorageClass` 创建的所有 `PersistentVolumeClaim` 都支持卷容量扩充： @@ -1038,7 +993,7 @@ allowVolumeExpansion: true For more information about persistent volume claims, see [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims). --> 关于持久化卷申领的更多信息，请参见 -[PersistentVolumeClaims](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。 +[PersistentVolumeClaim](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。 ### PersistentVolumeLabel {#persistentvolumelabel} @@ -1052,15 +1007,15 @@ region and/or zone. If the admission controller doesn't support automatic labelling your PersistentVolumes, you may need to add the labels manually to prevent pods from mounting volumes from a different zone. PersistentVolumeLabel is DEPRECATED and labeling persistent volumes has been taken over by -[cloud controller manager](/docs/tasks/administer-cluster/running-cloud-controller/). +the {{< glossary_tooltip text="cloud-controller-manager" term_id="cloud-controller-manager" >}}. Starting from 1.11, this admission controller is disabled by default. --> -该准入控制器会自动将区（region）或区域（zone）标签附加到由云提供商（如 GCE、AWS） -定义的 PersistentVolume。这有助于确保 Pod 和 PersistentVolume 位于相同的区或区域。 +此准入控制器会自动将由云提供商（如 GCE、AWS）定义的区（region）或区域（zone） +标签附加到 PersistentVolume 上。这有助于确保 Pod 和 PersistentVolume 位于相同的区或区域。 如果准入控制器不支持为 PersistentVolumes 自动添加标签，那你可能需要手动添加标签， 以防止 Pod 挂载其他区域的卷。 -PersistentVolumeLabel 已被废弃，标记持久卷已由 -[云管理控制器](/zh/docs/tasks/administer-cluster/running-cloud-controller/)接管。 +PersistentVolumeLabel 已被弃用，为持久卷添加标签的操作已由 +{{< glossary_tooltip text="云管理控制器" term_id="cloud-controller-manager" >}}接管。 从 1.11 开始，默认情况下禁用此准入控制器。 ### PodNodeSelector {#podnodeselector} @@ -1068,70 +1023,56 @@ PersistentVolumeLabel 已被废弃，标记持久卷已由 {{< feature-state for_k8s_version="v1.5" state="alpha" >}} -该准入控制器通过读取名字空间注解和全局配置，来为名字空间中可以使用的节点选择器 -设置默认值并实施限制。 +此准入控制器通过读取名字空间注解和全局配置，来为名字空间中可以使用的节点选择器设置默认值并实施限制。 -#### 配置文件格式 +#### 配置文件格式 {#configuration-file-format-podnodeselector} -`PodNodeSelector` 使用配置文件来设置后端行为的选项。 -请注意，配置文件格式将在将来某个版本中改为版本化文件。 +`PodNodeSelector` 使用配置文件来设置后端行为的选项。请注意，配置文件格式将在将来某个版本中改为版本化文件。 该文件可以是 JSON 或 YAML，格式如下： ```yaml podNodeSelectorPluginConfig: - clusterDefaultNodeSelector: name-of-node-selector - namespace1: name-of-node-selector - namespace2: name-of-node-selector + clusterDefaultNodeSelector: name-of-node-selector + namespace1: name-of-node-selector + namespace2: name-of-node-selector ``` -基于提供给 API 服务器命令行标志 `--admission-control-config-file` 的文件名， -从文件中引用 `PodNodeSelector` 配置文件： +通过 API 服务器命令行标志 `--admission-control-config-file` 为 API 服务器提供的文件中， +需要引用 `PodNodeSelector` 配置文件： -{{< tabs name="podnodeselector_example1" >}} -{{% tab name="apiserver.config.k8s.io/v1" %}} ```yaml apiVersion: apiserver.config.k8s.io/v1 kind: AdmissionConfiguration plugins: -- name: PodNodeSelector - path: podnodeselector.yaml + - name: PodNodeSelector + path: podnodeselector.yaml ... ``` -{{% /tab %}} -{{% tab name="apiserver.k8s.io/v1alpha1" %}} -```yaml -# 在 v1.17 中废弃，以鼓励使用 apiserver.config.k8s.io/v1 -apiVersion: apiserver.k8s.io/v1alpha1 -kind: AdmissionConfiguration -plugins: -- name: PodNodeSelector - path: podnodeselector.yaml -... -``` -{{% /tab %}} -{{< /tabs >}} -#### 配置注解格式 +#### 配置注解格式 {#configuration-annotation-format} -`PodNodeSelector` 使用键为 `scheduler.alpha.kubernetes.io/node-selector` 的注解 -为名字空间设置节点选择算符。 +`PodNodeSelector` 使用键为 `scheduler.alpha.kubernetes.io/node-selector` +的注解为名字空间设置节点选择算符。 ```yaml apiVersion: v1 @@ -1144,28 +1085,30 @@ metadata: -#### 内部行为 +#### 内部行为 {#internal-behavior} -该准入控制器行为如下： +此准入控制器行为如下： 1. 如果 `Namespace` 的注解带有键 `scheduler.alpha.kubernetes.io/node-selector`， 则将其值用作节点选择算符。 2. 如果名字空间缺少此类注解，则使用 `PodNodeSelector` 插件配置文件中定义的 `clusterDefaultNodeSelector` 作为节点选择算符。 -3. 评估 Pod 节点选择算符和名字空间节点选择算符是否存在冲突。存在冲突将导致拒绝。 +3. 评估 Pod 节点选择算符和名字空间节点选择算符是否存在冲突。存在冲突将拒绝 Pod。 4. 评估 Pod 节点选择算符和特定于名字空间的被允许的选择算符所定义的插件配置文件是否存在冲突。 - 存在冲突将导致拒绝。 + 存在冲突将导致拒绝 Pod。 {{< note >}} -这是下节已被废弃的 [PodSecurityPolicy](#podsecuritypolicy) 准入控制器的替代品。 -此准入控制器负责在创建和修改 Pod 时根据请求的安全上下文和 +这是下节所讨论的已被废弃的 [PodSecurityPolicy](#podsecuritypolicy) 准入控制器的替代品。 +此准入控制器负责在创建和修改 Pod 时，根据请求的安全上下文和 [Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/) 来确定是否可以执行请求。 @@ -1212,31 +1155,33 @@ See also the [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/) d for more information. --> 查看 [Pod 安全策略文档](/zh/docs/concepts/security/pod-security-policy/) -了解更多细节。 +进一步了解其间细节。 ### PodTolerationRestriction {#podtolerationrestriction} {{< feature-state for_k8s_version="v1.7" state="alpha" >}} -准入控制器 PodTolerationRestriction 检查 Pod 的容忍度与其名字空间的容忍度之间 -是否存在冲突。如果存在冲突，则拒绝 Pod 请求。 -然后，它将名字空间的容忍度合并到 Pod 的容忍度中，之后根据名字空间的容忍度 -白名单检查所得到的容忍度结果。如果检查成功，则将接受 Pod 请求，否则拒绝该请求。 +准入控制器 PodTolerationRestriction 检查 Pod 的容忍度与其名字空间的容忍度之间是否存在冲突。 +如果存在冲突，则拒绝 Pod 请求。 +控制器接下来会将名字空间的容忍度合并到 Pod 的容忍度中， +根据名字空间的容忍度白名单检查所得到的容忍度结果。 +如果检查成功，则将接受 Pod 请求，否则拒绝该请求。 -如果 Pod 的名字空间没有任何关联的默认容忍度或容忍度白名单，则使用集群级别的 -默认容忍度或容忍度白名单（如果有的话）。 +如果 Pod 的名字空间没有任何关联的默认容忍度或容忍度白名单， +则使用集群级别的默认容忍度或容忍度白名单（如果有的话）。 -名字空间的容忍度通过注解健 `scheduler.alpha.kubernetes.io/defaultTolerations` +名字空间的容忍度通过注解键 `scheduler.alpha.kubernetes.io/defaultTolerations` 来设置。可接受的容忍度可以通过 `scheduler.alpha.kubernetes.io/tolerationsWhitelist` 注解键来添加。 @@ -1263,7 +1208,9 @@ metadata: ### 优先级 {#priority} @@ -1273,21 +1220,22 @@ The priority admission controller uses the `priorityClassName` field and populat ### ResourceQuota {#resourcequota} -该准入控制器会监测传入的请求，并确保它不违反任何一个 `Namespace` 中的 `ResourceQuota` -对象中枚举出来的约束。 -如果你在 Kubernetes 部署中使用了 `ResourceQuota`，你必须使用这个准入控制器来强制 -执行配额限制。 +此准入控制器会监测传入的请求，并确保它不违反任何一个 `Namespace` 中的 `ResourceQuota` +对象中列举的约束。如果你在 Kubernetes 部署中使用了 `ResourceQuota`， +则必须使用这个准入控制器来强制执行配额限制。 -请查看 -[resourceQuota 设计文档](https://git.k8s.io/community/contributors/design-proposals/admission_control_resource_quota.md)和 [Resource Quota 例子](/zh/docs/concepts/policy/resource-quotas/) -了解更多细节。 +请参阅 +[resourceQuota API 参考](/zh/docs/reference/kubernetes-api/policy-resources/resource-quota-v1/) +和 [Resource Quota 例子](/zh/docs/concepts/policy/resource-quotas/)了解更多细节。 ### RuntimeClass {#runtimeclass} -+{{< feature-state for_k8s_version="v1.20" state="stable" >}} +{{< feature-state for_k8s_version="v1.20" state="stable" >}} -如果你开启 `PodOverhead` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/), -并且通过 [Pod 开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/) -配置来定义一个 RuntimeClass，这个准入控制器会检查新的 Pod。 -当启用的时候，这个准入控制器会拒绝任何 overhead 字段已经设置的 Pod。 +如果你所定义的 RuntimeClass 包含 [Pod 开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/)， +这个准入控制器会检查新的 Pod。被启用后，此准入控制器会拒绝所有已经设置了 overhead 字段的 Pod 创建请求。 对于配置了 RuntimeClass 并在其 `.spec` 中选定 RuntimeClass 的 Pod， 此准入控制器会根据相应 RuntimeClass 中定义的值为 Pod 设置 `.spec.overhead`。 -{{< note >}} -Pod 的 `.spec.overhead` 字段和 RuntimeClass 的 `.overhead` 字段均为处于 beta 版本。 -如果你未启用 `PodOverhead` 特性门控，则所有 Pod 均被视为未设置 `.spec.overhead`。 -{{< /note >}} - 详情请参见 [Pod 开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/)。 ### SecurityContextDeny {#securitycontextdeny} @@ -1340,14 +1280,13 @@ then you could use this admission controller to restrict the set of values a sec See [Pod Security Standards](/docs/concepts/security/pod-security-standards/) for more context on restricting pod privileges. --> -该准入控制器将拒绝任何试图设置特定提升 +此准入控制器将拒绝任何试图设置特定提升 [SecurityContext](/zh/docs/tasks/configure-pod-container/security-context/) -字段的 Pod，正如任务 -[为 Pod 或 Container 配置安全上下文](/zh/docs/tasks/configure-pod-container/security-context/) -中所展示的那样。 -如果集群没有使用 [Pod 安全性准入](/zh/docs/concepts/security/pod-security-admission/)、 -[PodSecurityPolicies](/zh/docs/concepts/security/pod-security-policy/)， -也没有任何外部执行机制，那么你可以使用此准入控制器来限制安全上下文所能获取的值集。 +中某些字段的 Pod，正如任务[为 Pod 或 Container 配置安全上下文](/zh/docs/tasks/configure-pod-container/security-context/) +中所展示的那样。如果集群没有使用 +[Pod 安全性准入](/zh/docs/concepts/security/pod-security-admission/)、 +[PodSecurityPolicy](/zh/docs/concepts/security/pod-security-policy/)， +也没有任何外部强制机制，那么你可以使用此准入控制器来限制安全上下文所能获取的值集。 有关限制 Pod 权限的更多内容，请参阅 [Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)。 @@ -1357,14 +1296,15 @@ pod privileges. 此准入控制器实现了 [ServiceAccount](/zh/docs/tasks/configure-pod-container/configure-service-account/) 的自动化。 如果你打算使用 Kubernetes 的 ServiceAccount 对象，我们强烈建议你使用这个准入控制器。 -### StorageObjectInUseProtection +### StorageObjectInUseProtection {#storageobjectinuseprotection} `StorageObjectInUseProtection` 插件将 `kubernetes.io/pvc-protection` 或 -`kubernetes.io/pv-protection` finalizers 添加到新创建的持久化卷声明（PVC） -或持久化卷（PV）中。 -如果用户尝试删除 PVC/PV，除非 PVC/PV 的保护控制器移除 finalizers，否则 -PVC/PV 不会被删除。 -有关更多详细信息，请参考 +`kubernetes.io/pv-protection` finalizers 添加到新创建的持久卷申领（PVC） +或持久卷（PV）中。如果用户尝试删除 PVC/PV，除非 PVC/PV 的保护控制器移除 finalizers， +否则 PVC/PV 不会被删除。有关更多详细信息，请参考 [保护使用中的存储对象](/zh/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection)。 -### TaintNodesByCondition {#taintnodesbycondition} +### TaintNodesByCondition {#taintnodesbycondition} {{< feature-state for_k8s_version="v1.17" state="stable" >}} -该准入控制器为新创建的节点添加 `NotReady` 和 `NoSchedule` -{{< glossary_tooltip text="污点" term_id="taint" >}}。 -这些污点能够避免一些竞态条件的发生，这类静态条件可能导致 Pod 在更新节点污点以准确 -反映其所报告状况之前，就被调度到新节点上。 +该准入控制器为新创建的节点添加 `NotReady` 和 `NoSchedule` {{< glossary_tooltip text="污点" term_id="taint" >}}。 +这些污点能够避免一些竞态条件的发生，而这类竞态条件可能导致 Pod +在更新节点污点以准确反映其所报告状况之前，就被调度到新节点上。 ### ValidatingAdmissionWebhook {#validatingadmissionwebhook} @@ -1403,18 +1343,18 @@ webhooks are called in parallel; if any of them rejects the request, the request fails. This admission controller only runs in the validation phase; the webhooks it calls may not mutate the object, as opposed to the webhooks called by the `MutatingAdmissionWebhook` admission controller. --> -该准入控制器调用与请求匹配的所有验证 Webhook。 +此准入控制器调用与请求匹配的所有验证性 Webhook。 匹配的 Webhook 将被并行调用。如果其中任何一个拒绝请求，则整个请求将失败。 -该准入控制器仅在验证（Validating）阶段运行；与 `MutatingAdmissionWebhook` 准入控制器 -所调用的 Webhook 相反，它调用的 Webhook 应该不会使对象出现变更。 +该准入控制器仅在验证（Validating）阶段运行；与 `MutatingAdmissionWebhook` +准入控制器所调用的 Webhook 相反，它调用的 Webhook 不可以变更对象。 -如果以此方式调用的 Webhook 有其它作用（如，降低配额），则它必须具有协调机制。 -这是因为无法保证后续的 Webhook 或其他有效的准入控制器都允许请求完成。 +如果以此方式调用的 Webhook 有其它副作用（如：减少配额），则它必须具有协调机制。 +这是因为无法保证后续的 Webhook 或其他验证性准入控制器都允许请求完成。 如果你禁用了 ValidatingAdmissionWebhook，还必须通过 `--runtime-config` 标志来禁用 -`admissionregistration.k8s.io/v1` 组/版本中的 `ValidatingWebhookConfiguration` -对象（默认情况下在 1.9 版和更高版本中均处于启用状态）。 - +`admissionregistration.k8s.io/v1` 组/版本中的 `ValidatingWebhookConfiguration` +对象（默认情况下在 v1.9 和更高版本中均处于启用状态）。 ## 有推荐的准入控制器吗？ @@ -1439,10 +1382,3 @@ Yes. The recommended admission controllers are enabled by default (shown [here]( 因此，你无需显式指定它们。 你可以使用 `--enable-admission-plugins` 标志（ **顺序不重要** ）来启用默认设置以外的其他准入控制器。 -{{< note >}} - -`--admission-control` 在 1.10 中已废弃，由 `--enable-admission-plugins` 取代。 -{{< /note >}} - diff --git a/content/zh/docs/reference/access-authn-authz/rbac.md b/content/zh/docs/reference/access-authn-authz/rbac.md index 454d81f86a..3602504cb7 100644 --- a/content/zh/docs/reference/access-authn-authz/rbac.md +++ b/content/zh/docs/reference/access-authn-authz/rbac.md @@ -1,6 +1,7 @@ --- title: 使用 RBAC 鉴权 content_type: concept +aliases: [/zh/rbac/] weight: 70 --- @@ -11,6 +12,7 @@ reviewers: - liggitt title: Using RBAC Authorization content_type: concept +aliases: [/rbac/] weight: 70 --> @@ -25,7 +27,7 @@ network resources based on the roles of individual users within your organizatio RBAC 鉴权机制使用 `rbac.authorization.k8s.io` @@ -34,12 +36,17 @@ RBAC 鉴权机制使用 `rbac.authorization.k8s.io` 要启用 RBAC，在启动 {{< glossary_tooltip text="API 服务器" term_id="kube-apiserver" >}} 时将 `--authorization-mode` 参数设置为一个逗号分隔的列表并确保其中包含 `RBAC`。 + ```shell kube-apiserver --authorization-mode=Example,RBAC --<其他选项> --<其他选项> ``` @@ -123,11 +130,24 @@ ClusterRole 有若干用法。你可以用它来： Here's an example Role in the "default" namespace that can be used to grant read access to {{< glossary_tooltip text="pods" term_id="pod" >}}: --> -#### Role 示例 +#### Role 示例 {#role-example} 下面是一个位于 "default" 名字空间的 Role 的示例，可用来授予对 {{< glossary_tooltip text="pods" term_id="pod" >}} 的读访问权限： + ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: Role @@ -144,16 +164,16 @@ rules: #### ClusterRole example A ClusterRole can be used to grant the same permissions as a Role. -Because they are cluster-scoped, you can also use them to grant access to: +Because ClusterRoles are cluster-scoped, you can also use them to grant access to: * cluster-scoped resources (like {{< glossary_tooltip text="nodes" term_id="node" >}}) * non-resource endpoints (like `/healthz`) * namespaced resources (like Pods), across all namespaces For example: you can use a ClusterRole to allow a particular user to run - `kubectl get pods -all-namespaces` + `kubectl get pods --all-namespaces` --> -### ClusterRole 示例 +### ClusterRole 示例 {#clusterrole-example} ClusterRole 可以和 Role 相同完成授权。 因为 ClusterRole 属于集群范围，所以它也可以为以下资源授予访问权限： @@ -173,6 +193,22 @@ or across all namespaces (depending on how it is [bound](#rolebinding-and-cluste {{< glossary_tooltip text="Secret" term_id="secret" >}} 授予读访问权限， 或者跨名字空间的访问权限（取决于该角色是如何[绑定](#rolebinding-and-clusterrolebinding)的）： + ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole @@ -181,7 +217,7 @@ metadata: name: secret-reader rules: - apiGroups: [""] - # 在 HTTP 层面，用来访问 Secret 对象的资源的名称为 "secrets" + # 在 HTTP 层面，用来访问 Secret 资源的名称为 "secrets" resources: ["secrets"] verbs: ["get", "watch", "list"] ``` @@ -236,9 +272,31 @@ This allows "jane" to read pods in the "default" namespace. 下面的例子中的 RoleBinding 将 "pod-reader" Role 授予在 "default" 名字空间中的用户 "jane"。 这样，用户 "jane" 就具有了读取 "default" 名字空间中 pods 的权限。 + ```yaml apiVersion: rbac.authorization.k8s.io/v1 # 此角色绑定允许 "jane" 读取 "default" 名字空间中的 Pods +# 你需要在该命名空间中有一个名为 “pod-reader” 的 Role kind: RoleBinding metadata: name: read-pods @@ -251,7 +309,7 @@ subjects: roleRef: # "roleRef" 指定与某 Role 或 ClusterRole 的绑定关系 kind: Role # 此字段必须是 Role 或 ClusterRole - name: pod-reader # 此字段必须与你要绑定的 Role 或 ClusterRole 的名称匹配 + name: pod-reader # 此字段必须与你要绑定的 Role 或 ClusterRole 的名称匹配 apiGroup: rbac.authorization.k8s.io ``` @@ -273,6 +331,28 @@ RoleBinding 所在名字空间的资源。这种引用使得你可以跨整个 区分大小写）只能访问 "development" 名字空间中的 Secrets 对象，因为 RoleBinding 所在的名字空间（由其 metadata 决定）是 "development"。 + ```yaml apiVersion: rbac.authorization.k8s.io/v1 # 此角色绑定使得用户 "dave" 能够读取 "development" 名字空间中的 Secrets @@ -306,6 +386,23 @@ secrets in any namespace. 下面的 ClusterRoleBinding 允许 "manager" 组内的所有用户访问任何名字空间中的 Secrets。 + ```yaml apiVersion: rbac.authorization.k8s.io/v1 # 此集群角色绑定允许 “manager” 组中的任何人访问任何名字空间中的 secrets @@ -337,20 +434,24 @@ There are two reasons for this restriction: 这种限制有两个主要原因： +1. 将 `roleRef` 设置为不可以改变，这使得可以为用户授予对现有绑定对象的 `update` 权限， + 这样可以让他们管理主体列表，同时不能更改被授予这些主体的角色。 + 1. 针对不同角色的绑定是完全不一样的绑定。要求通过删除/重建绑定来更改 `roleRef`, 这样可以确保要赋予绑定的所有主体会被授予新的角色（而不是在允许或者不小心修改 了 `roleRef` 的情况下导致所有现有主体未经验证即被授予新角色对应的权限）。 -1. 将 `roleRef` 设置为不可以改变，这使得可以为用户授予对现有绑定对象的 `update` 权限， - 这样可以让他们管理主体列表，同时不能更改被授予这些主体的角色。 +### 对资源的引用 {#referring-to-resources} + -### 对资源的引用 {#referring-to-resources} - 在 Kubernetes API 中，大多数资源都是使用对象名称的字符串表示来呈现与访问的。 例如，对于 Pod 应使用 "pods"。 RBAC 使用对应 API 端点的 URL 中呈现的名字来引用资源。 @@ -415,6 +517,7 @@ Here is an example that restricts its subject to only `get` or `update` a 下面的例子中限制可以 "get" 和 "update" 一个名为 `my-configmap` 的 {{< glossary_tooltip term_id="ConfigMap" >}}： + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: Role +metadata: + namespace: default + name: configmap-updater +rules: +- apiGroups: [""] + # 在 HTTP 层面，用来访问 ConfigMap 资源的名称为 "configmaps" resources: ["configmaps"] resourceNames: ["my-configmap"] verbs: ["update", "get"] @@ -465,6 +584,19 @@ Here is an example aggregated ClusterRole: 下面是一个聚合 ClusterRole 的示例： + ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole @@ -488,6 +620,22 @@ ClusterRole labeled `rbac.example.com/aggregate-to-monitoring: true`. 下面的例子中，通过创建一个标签同样为 `rbac.example.com/aggregate-to-monitoring: true` 的 ClusterRole，新的规则可被添加到 "monitoring" ClusterRole 中。 + ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole @@ -513,7 +661,7 @@ For example: the following ClusterRoles let the "admin" and "edit" default roles named CronTab, whereas the "view" role can perform only read actions on CronTab resources. You can assume that CronTab objects are named `"crontabs"` in URLs as seen by the API server. --> -默认的[面向用户的角色](#default-roles-and-role-bindings) 使用 ClusterRole 聚合。 +默认的[面向用户的角色](#default-roles-and-role-bindings)使用 ClusterRole 聚合。 这使得作为集群管理员的你可以为扩展默认规则，包括为定制资源设置规则， 比如通过 CustomResourceDefinitions 或聚合 API 服务器提供的定制资源。 @@ -521,6 +669,34 @@ You can assume that CronTab objects are named `"crontabs"` in URLs as seen by th "view" 角色对 CronTab 资源拥有读操作权限。 你可以假定 CronTab 对象在 API 服务器所看到的 URL 中被命名为 `"crontabs"`。 + ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole @@ -549,7 +725,7 @@ rules: ``` +```yaml +rules: +- apiGroups: [""] + # 在 HTTP 层面，用来访问 Pod 资源的名称为 "pods" resources: ["pods"] verbs: ["get", "list", "watch"] ``` @@ -576,12 +763,25 @@ rules: Allow reading/writing Deployments (at the HTTP level: objects with `"deployments"` in the resource part of their URL) in the `"apps"` API groups: --> -允许读/写在 `"apps"` API 组中的 Deployment（在 HTTP 层面，对应 -URL 中资源部分为 "deployments"）： +允许在 `"apps"` API 组中读/写 Deployment（在 HTTP 层面，对应 URL +中资源部分为 `"deployments"`）： + +```yaml +rules: +- apiGroups: ["apps"] + # + # 在 HTTP 层面，用来访问 Deployment 资源的名称为 "deployments" resources: ["deployments"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] ``` @@ -590,15 +790,33 @@ rules: Allow reading Pods in the core API group, as well as reading or writing Job resources in the `"batch"` API group: --> -允许读取核心 API 组中的 "pods" 和读/写 `"batch"` API 组中的 -"jobs"： +允许读取核心 API 组中的 Pod 和读/写 `"batch"` API 组中的 Job 资源： + +```yaml +rules: +- apiGroups: [""] + # 在 HTTP 层面，用来访问 Pod 资源的名称为 "pods" + resources: ["pods"] + verbs: ["get", "list", "watch"] +- apiGroups: ["batch"] + # 在 HTTP 层面，用来访问 Job 资源的名称为 "jobs" resources: ["jobs"] verbs: ["get", "list", "watch", "create", "update", "patch", "delete"] ``` @@ -610,9 +828,22 @@ RoleBinding to limit to a single ConfigMap in a single namespace): 允许读取名称为 "my-config" 的 ConfigMap（需要通过 RoleBinding 绑定以 限制为某名字空间中特定的 ConfigMap）： + +```yaml +rules: +- apiGroups: [""] + # 在 HTTP 层面，用来访问 ConfigMap 资源的名称为 "configmaps" resources: ["configmaps"] resourceNames: ["my-config"] verbs: ["get"] @@ -623,12 +854,24 @@ Allow reading the resource `"nodes"` in the core group (because a Node is cluster-scoped, this must be in a ClusterRole bound with a ClusterRoleBinding to be effective): --> -允许读取在核心组中的 "nodes" 资源（因为 `Node` 是集群作用域的，所以需要 +允许读取在核心组中的 `"nodes"` 资源（因为 `Node` 是集群作用域的，所以需要 ClusterRole 绑定到 ClusterRoleBinding 才生效）： + +```yaml +rules: +- apiGroups: [""] + # 在 HTTP 层面，用来访问 Node 资源的名称为 "nodes" resources: ["nodes"] verbs: ["get", "list", "watch"] ``` @@ -641,14 +884,21 @@ to be effective): 允许针对非资源端点 `/healthz` 和其子路径上发起 GET 和 POST 请求 （必须在 ClusterRole 绑定 ClusterRoleBinding 才生效）： + +```yaml +rules: +- nonResourceURLs: ["/healthz", "/healthz/*"] # nonResourceURL 中的 '*' 是一个全局通配符 + verbs: ["get", "post"] ``` ### 对主体的引用 {#referring-to-subjects} -RoleBinding 或者 ClusterRoleBinding 可绑定角色到某 *主体（Subject）*上。 +RoleBinding 或者 ClusterRoleBinding 可绑定角色到某 **主体（Subject）** 上。 主体可以是组，用户或者 {{< glossary_tooltip text="服务账户" term_id="service-account" >}}。 @@ -692,8 +942,8 @@ In Kubernetes, Authenticator modules provide group information. Groups, like users, are represented as strings, and that string has no format requirements, other than that the prefix `system:` is reserved. -[Service Accounts](/docs/tasks/configure-pod-container/configure-service-account/) have usernames with the `system:serviceaccount:` prefix and belong -to groups with the `system:serviceaccounts:` prefix. +[ServiceAccounts](/docs/tasks/configure-pod-container/configure-service-account/) have names prefixed +with `system:serviceaccount:`, and belong to groups that have names prefixed with `system:serviceaccounts:`. --> 在 Kubernetes 中，鉴权模块提供用户组信息。 与用户名一样，用户组名也用字符串来表示，而且对该字符串没有格式要求， @@ -713,7 +963,7 @@ to groups with the `system:serviceaccounts:` prefix. {{< /note >}} -## 默认 Roles 和 Role Bindings +## 默认 Roles 和 Role Bindings {#default-roles-and-role-bindings} API 服务器创建一组默认的 ClusterRole 和 ClusterRoleBinding 对象。 这其中许多是以 `system:` 为前缀的，用以标识对应资源是直接由集群控制面管理的。 @@ -844,7 +1094,7 @@ Modifications to these resources can result in non-functional clusters. --> 在修改名称包含 `system:` 前缀的 ClusterRole 和 ClusterRoleBinding 时要格外小心。 -对这些资源的更改可能导致集群无法继续工作。 +对这些资源的更改可能导致集群无法正常运作。 {{< /caution >}} ### API 发现角色 {#discovery-roles} 无论是经过身份验证的还是未经过身份验证的用户，默认的角色绑定都授权他们读取被认为 -是可安全地公开访问的 API（ 包括 CustomResourceDefinitions）。 +是可安全地公开访问的 API（包括 CustomResourceDefinitions）。 如果要禁用匿名的未经过身份验证的用户访问，请在 API 服务器配置中中添加 `--anonymous-auth=false` 的配置选项。 @@ -900,19 +1150,17 @@ If you edit that ClusterRole, your changes will be overwritten on API server res via [auto-reconciliation](#auto-reconciliation). To avoid that overwriting, either do not manually edit the role, or disable auto-reconciliation. --> -如果你编辑该 ClusterRole，你所作的变更会被 API 服务器在重启时自动覆盖，这是通过 -[自动协商](#auto-reconciliation)机制完成的。要避免这类覆盖操作， +如果你编辑该 ClusterRole，你所作的变更会被 API 服务器在重启时自动覆盖， +这是通过[自动协商](#auto-reconciliation)机制完成的。要避免这类覆盖操作， 要么不要手动编辑这些角色，要么禁止自动协商机制。 {{< /note >}} - - + + - - @@ -1003,7 +1251,7 @@ metadata: ```
-Kubernetes RBAC API 发现角色 -Kubernetes RBAC API 发现角色
system:authenticated 组 - -允许用户以只读的方式去访问他们自己的基本信息。在 1.14 版本之前，这个角色在默认情况下也绑定在 system:unauthenticated 上。 +允许用户以只读的方式去访问他们自己的基本信息。在 v1.14 版本之前，这个角色在默认情况下也绑定在 system:unauthenticated 上。
system:discovery system:authenticated 组 - 允许以只读方式访问 API 发现端点，这些端点用来发现和协商 API 级别。 -在 1.14 版本之前，这个角色在默认情况下绑定在 system:unauthenticated 上。 +在 v1.14 版本之前，这个角色在默认情况下绑定在 system:unauthenticated 上。
system:public-info-viewer system:authenticated 和 system:unauthenticated 组 - -允许对集群的非敏感信息进行只读访问，它是在 1.14 版本中引入的。 +允许对集群的非敏感信息进行只读访问，它是在 v1.14 版本中引入的。
- + - @@ -57,77 +93,47 @@ Default: true--> @@ -136,17 +142,10 @@ Default: "20s" @@ -156,16 +155,10 @@ Default: "" @@ -177,15 +170,10 @@ Default: nil

address 是 kubelet 提供服务所用的 IP 地址（设置为 0.0.0.0 使用所有网络接口提供服务）。

-

当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑可能干扰与 kubelet 服务器交互的组件。

默认值："0.0.0.0"

@@ -197,15 +185,10 @@ Default: "0.0.0.0"

port 是 kubelet 用来提供服务所使用的端口号。 这一端口号必须介于 1 到 65535 之间，包含 1 和 65535。

-

当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑可能干扰与 kubelet 服务器交互的组件。

默认值：10250

@@ -218,16 +201,11 @@ Default: 10250 no authentication/authorization. The port number must be between 1 and 65535, inclusive. Setting this field to 0 disables the read-only service. -If DynamicKubeletConfig (deprecated; default off) is on, when -dynamically updating this field, consider that -it may disrupt components that interact with the Kubelet server. Default: 0 (disabled) -->

readOnlyPort 是 kubelet 用来提供服务所使用的只读端口号。 此端口上的服务不支持身份认证或鉴权。这一端口号必须介于 1 到 65535 之间， 包含 1 和 65535。将此字段设置为 0 会禁用只读服务。

-

当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑可能干扰与 kubelet 服务器交互的组件。

默认值：0（禁用）

@@ -241,17 +219,12 @@ if any, concatenated after server cert). If tlsCertFile and tlsPrivateKeyFile are not provided, a self-signed certificate and key are generated for the public address and saved to the directory passed to the Kubelet's --cert-dir flag. -If DynamicKubeletConfig (deprecated; default off) is on, when -dynamically updating this field, consider that -it may disrupt components that interact with the Kubelet server. Default:"quot; -->

tlsCertFile是包含 HTTPS 所需要的 x509 证书的文件 （如果有 CA 证书，会串接到服务器证书之后）。如果tlsCertFile 和tlsPrivateKeyFile都没有设置，则系统会为节点的公开地址生成自签名的证书和私钥， 并将其保存到 kubelet --cert-dir参数所指定的目录下。

-

当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑可能干扰与 kubelet 服务器交互的组件。

默认值：""

@@ -261,15 +234,10 @@ Default:"quot; @@ -280,15 +248,10 @@ Default: "" @@ -299,15 +262,10 @@ Default: nil @@ -319,17 +277,10 @@ Default: ""

rotateCertificates用来启用客户端证书轮换。kubelet 会调用 certificates.k8s.io API 来请求新的证书。需要有一个批复人批准证书签名请求。

-

当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑禁用此行为时可能导致 kubelet 无法在当前证书过期时向 -API 服务器执行身份认证。

默认值：false @@ -343,20 +294,12 @@ signing a serving certificate, the Kubelet will request a certificate from the 'certificates.k8s.io' API. This requires an approver to approve the certificate signing requests (CSR). The RotateKubeletServerCertificate feature must be enabled when setting this field. -If DynamicKubeletConfig (deprecated; default off) is on, when -dynamically updating this field, consider that -disabling it will stop the renewal of Kubelet server certificates, which can -disrupt components that interact with the Kubelet server in the long term, -due to certificate expiration. Default: false -->

serverTLSBootstrap用来启用服务器证书引导。系统不再使用自签名的服务证书， kubelet 会调用certificates.k8s.io API 来请求证书。 需要有一个批复人来批准证书签名请求（CSR）。 设置此字段时，RotateKubeletServerCertificate特性必须被启用。

-

当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑禁用此特性会导致 kubelet 的服务器证书无法被续约， -长期上这会干扰到与 kubelet 服务器交互的组件，因为证书会过期。

默认值：false

@@ -366,26 +309,21 @@ kubelet 会调用certificates.k8s.io API 来请求证书。 @@ -395,24 +333,19 @@ Defaults: @@ -424,16 +357,10 @@ Defaults:

registryPullQPS是每秒钟可以执行的镜像仓库拉取操作限值。 此值必须不能为负数。将其设置为 0 表示没有限值。

-

当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑这类更新可能会因为镜像拉取所产生的流量变化而导致集群可扩缩能力问题。

默认值：5 @@ -446,17 +373,11 @@ Default: 5 pulls to burst to this number, while still not exceeding registryPullQPS. The value must not be a negative number. Only used if registryPullQPS is greater than 0. -If DynamicKubeletConfig (deprecated; default off) is on, when -dynamically updating this field, consider that -it may impact scalability by changing the amount of traffic produced -by image pulls. Default: 10 -->

registryBurst是突发性镜像拉取的上限值，允许镜像拉取临时上升到所指定数量， 不过仍然不超过registryPullQPS所设置的约束。此值必须是非负值。 只有registryPullQPS参数值大于 0 时才会使用此设置。

-

当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑可能因为镜像拉取所造成的流量变化，导致集群可扩缩能力受影响。

默认值：10

@@ -467,16 +388,10 @@ Default: 10 @@ -485,21 +400,16 @@ Default: 5 int32 @@ -511,16 +421,11 @@ Default: 10

enableDebuggingHandlers启用服务器上用来访问日志、 在本地运行容器和命令的端点，包括exec、attach、 logs和portforward等功能。

-

当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑禁用此能力可能干扰到与 kubelet 服务器交互的组件。

默认值：true

@@ -529,16 +434,12 @@ Default: true bool @@ -547,17 +448,13 @@ Default: false int32 @@ -566,15 +463,11 @@ Default: 10248 string @@ -585,15 +478,10 @@ Default: "127.0.0.1" @@ -605,14 +493,10 @@ Default: -999

clusterDomain是集群的 DNS 域名。如果设置了此字段，kubelet 会配置所有容器，使之在搜索主机的搜索域的同时也搜索这里指定的 DNS 域。

-

DynamicKubeletConfig （已弃用，默认为关闭）： -不建议动态更新此字段，因为这一设置值要与整个集群中的其他组件保持一致。

默认值：""

@@ -624,43 +508,30 @@ Default: ""

clusterDNS是集群 DNS 服务器的 IP 地址的列表。 如果设置了，kubelet 将会配置所有容器使用这里的 IP 地址而不是宿主系统上的 DNS 服务器来完成 DNS 解析。 -

当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑变更仅会对更新后创建的 Pod 起作用。建议在更改此字段之前腾空节点。

默认值：nil

@@ -769,19 +618,12 @@ image garbage collection is always run. The percent is calculated by dividing this field value by 100, so this field must be between 0 and 100, inclusive. When specified, the value must be greater than imageGCLowThresholdPercent. -If DynamicKubeletConfig (deprecated; default off) is on, when -dynamically updating this field, consider that -it may trigger or delay garbage collection, and may change the image overhead -on the node. Default: 85 -->

imageGCHighThresholdPercent所给的是镜像的磁盘用量百分数， 一旦镜像用量超过此阈值，则镜像垃圾收集会一直运行。百分比是用这里的值除以 100 得到的，所以此字段取值必须介于 0 和 100 之间，包括 0 和 100。如果设置了此字段， 则取值必须大于imageGCLowThresholdPercent取值。

-

当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑这种变更可能触发垃圾收集或者延迟垃圾收集， -并且可能影响节点上镜像的额外开销。

默认值：85

@@ -795,37 +637,25 @@ image garbage collection is never run. Lowest disk usage to garbage collect to. The percent is calculated by dividing this field value by 100, so the field value must be between 0 and 100, inclusive. When specified, the value must be less than imageGCHighThresholdPercent. -If DynamicKubeletConfig (deprecated; default off) is on, when -dynamically updating this field, consider that -it may trigger or delay garbage collection, and may change the image overhead -on the node. Default: 80 -->

imageGCLowThresholdPercent所给的是镜像的磁盘用量百分数， 镜像用量低于此阈值时不会执行镜像垃圾收集操作。垃圾收集操作也将此作为最低磁盘用量边界。 百分比是用这里的值除以 100 得到的，所以此字段取值必须介于 0 和 100 之间，包括 0 和 100。 如果设置了此字段，则取值必须小于imageGCHighThresholdPercent取值。

-

当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑这种变更可能触发垃圾收集或者延迟垃圾收集， -并且可能影响节点上镜像的额外开销。

默认值：80

@@ -835,13 +665,9 @@ Default: "1m" @@ -854,15 +680,11 @@ Default: "" all non-kernel processes that are not already in a container. Empty for no container. Rolling back the flag requires a reboot. The cgroupRoot must be specified if this field is not empty. -Dynamic Kubelet Config (deprecated): This field should not be updated without a full node -reboot. It is safest to keep this value the same as the local config. Default: "&qout; -->

systemCgroups是用来放置那些未被容器化的、非内核的进程的控制组 (CGroup）的绝对名称。设置为空字符串表示没有这类容器。回滚此字段设置需要重启节点。 当此字段非空时，必须设置cgroupRoot字段。

-

DynamicKubeletConfig （已弃用）： -更新此字段时需要对整个节点执行重启。最安全的做法是确保此值与本地配置相同。

默认值：""

@@ -873,15 +695,9 @@ Default: "&qout; @@ -892,15 +708,11 @@ Default: ""

cgroupsPerQOS用来启用基于 QoS 的控制组（CGroup）层次结构： 顶层的控制组用于不同 QoS 类，所有Burstable和BestEffort Pod 都会被放置到对应的顶级 QoS 控制组下。

-

DynamicKubeletConfig （已弃用）： -更新此字段时需要对整个节点执行重启。最安全的做法是确保此值与本地配置相同。

默认值：true

@@ -911,14 +723,10 @@ Default: true @@ -929,14 +737,10 @@ Default: "cgroupfs" @@ -947,36 +751,26 @@ Default: "None" @@ -987,14 +781,10 @@ Default: "10s" @@ -1016,8 +806,6 @@ resources; of CPU and device resources.

Policies other than "none" require the TopologyManager feature gate to be enabled. -Dynamic Kubelet Config (deprecated): This field should not be updated without a full node -reboot. It is safest to keep this value the same as the local config. Default: "none"

-->

topologyManagerPolicy是要使用的拓扑管理器策略名称。合法值包括：

@@ -1028,8 +816,6 @@ Default: "none"

  • single-numa-node：kubelet 仅允许在 CPU 和设备资源上对齐到同一 NUMA 节点的 Pod。

    • 如果策略不是 "none"，则要求启用TopologyManager特性门控。

    -

    DynamicKubeletConfig （已弃用）： -更新此字段时需要对整个节点执行重启。最安全的做法是确保此值与本地配置相同。

    默认值："none"

    @@ -1068,34 +854,25 @@ the minimum percentage of a resource reserved for exclusive use by the guaranteed QoS tier. Currently supported resources: "memory" Requires the QOSReserved feature gate to be enabled. -Dynamic Kubelet Config (deprecated): This field should not be updated without a full node -reboot. It is safest to keep this value the same as the local config. Default: nil -->

    qosReserved是一组从资源名称到百分比值的映射，用来为Guaranteed QoS 类型的负载预留供其独占使用的资源百分比。目前支持的资源为："memory"。 需要启用QOSReserved特性门控。

    -

    DynamicKubeletConfig （已弃用）： -更新此字段时需要对整个节点执行重启。最安全的做法是确保此值与本地配置相同。

    默认值：nil

    @@ -1123,15 +900,10 @@ themselves if they should try to access their own Service. Values:

    一般而言，用户必须设置--hairpin-mode=hairpin-veth才能实现发夹模式的网络地址转译 （NAT），因为混杂模式的网桥要求存在一个名为cbr0的容器网桥。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑取决于网络插件，可能需要重启节点。

    默认值："promiscuous-bridge"

    @@ -1142,20 +914,9 @@ Default: "promiscuous-bridge" @@ -1166,15 +927,10 @@ Default: 110 @@ -1184,14 +940,9 @@ Default: "" @@ -1202,17 +953,11 @@ Default: -1 @@ -1238,37 +983,25 @@ Default: false @@ -1280,16 +1013,11 @@ Default: "100ms"

    nodeStatusMaxImages限制Node.status.images中报告的镜像数量。 此值必须大于 -2。

    注意：如果设置为 -1，则不会对镜像数量做限制；如果设置为 0，则不会返回任何镜像。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑节点状态中可能报告不同的数值。

    默认值：50

    @@ -1300,14 +1028,9 @@ Default: 50 @@ -1317,18 +1040,9 @@ Default: 1000000 @@ -1338,15 +1052,9 @@ Default: "application/vnd.kubernetes.protobuf" @@ -1357,16 +1065,10 @@ Default: 5 @@ -1379,16 +1081,11 @@ Default: 10 at a time. We recommend ∗not∗ changing the default value on nodes that run docker daemon with version < 1.9 or an Aufs storage backend. Issue #10959 has more details. -If DynamicKubeletConfig (deprecated; default off) is on, when -dynamically updating this field, consider that -it may impact the performance of image pulls. Default: true -->

    serializeImagePulls被启用时会通知 kubelet 每次仅拉取一个镜像。 我们建议不要在所运行的 docker 守护进程版本低于 1.9、使用 aufs 存储后端的节点上更改默认值。详细信息可参见 Issue #10959。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑这可能会影响镜像拉取的性能。

    默认值：true

    @@ -1400,26 +1097,21 @@ Default: true

    evictionHard是一个映射，是从信号名称到定义硬性驱逐阈值的映射。 例如：{"memory.available": "300Mi"}。 如果希望显式地禁用，可以在任意资源上将其阈值设置为 0% 或 100%。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑这可能会触发或延迟 Pod 驱逐操作。

    默认值：

    -  memory.available:  "100Mi"
-  nodefs.available:  "10%"
-  nodefs.inodesFree: "5%"
-  imagefs.available: "15%"
+   memory.available:  "100Mi"
+   nodefs.available:  "10%"
+   nodefs.inodesFree: "5%"
+   imagefs.available: "15%"
    @@ -1430,17 +1122,10 @@ Default: @@ -1451,34 +1136,24 @@ Default: nil @@ -1493,10 +1168,6 @@ effectively caps the Pod's terminationGracePeriodSeconds value during soft evict Note: Due to issue #64530, the behavior has a bug where this value currently just overrides the grace period during soft eviction, which can increase the grace period from what is set on the Pod. This bug will be fixed in a future release. -If DynamicKubeletConfig (deprecated; default off) is on, when -dynamically updating this field, consider that -lowering it decreases the amount of time Pods will have to gracefully clean -up before being killed during a soft eviction. Default: 0 -->

    evictionMaxPodGracePeriod是指达到软性逐出阈值而引起 Pod 终止时， @@ -1505,9 +1176,6 @@ Pod 可以获得的terminationGracePeriodSeconds。

    注意：由于 Issue #64530 的原因，系统中存在一个缺陷，即此处所设置的值会在软性逐出时覆盖 Pod 的宽限期设置，从而有可能增加 Pod 上原本设置的宽限期限时长。 这个缺陷会在未来版本中修复。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑缩短此宽限期限值会导致软性逐出期间 Pod -在被杀死之前用来体面地完成清理工作可用的时间。

    默认值：0

    @@ -1520,16 +1188,11 @@ Pod 的宽限期设置，从而有可能增加 Pod 上原本设置的宽限期 which describe the minimum amount of a given resource the kubelet will reclaim when performing a pod eviction while that resource is under pressure. For example: {"imagefs.available": "2Gi"}. -If DynamicKubeletConfig (deprecated; default off) is on, when -dynamically updating this field, consider that -it may change how well eviction can manage resource pressure. Default: nil -->

    evictionMinimumReclaim是一个映射，定义信号名称与最小回收量数值之间的关系。 最小回收量指的是资源压力较大而执行 Pod 驱逐操作时，kubelet 对给定资源的最小回收量。 例如：{"imagefs.available": "2Gi"}。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑这可能会改变驱逐操作应对资源压力的效果。

    默认值：nil

    @@ -1541,20 +1204,10 @@ Default: nil

    podsPerCore设置的是每个核上 Pod 个数上限。此值不能超过maxPods。 所设值必须是非负整数。如果设置为 0，则意味着对 Pod 个数没有限制。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑变更可能导致 kubelet 重启时 Pod 无法被准入， -还可能导致Node.status.capacity.pods所报告的数值发生变化， -进而影响到将来的调度决策。增大此值也会降低性能，因为在同一个处理器核上需要运行更多的 Pod。

    默认值：0

    @@ -1566,24 +1219,15 @@ Default: 0

    enableControllerAttachDetach用来允许 Attach/Detach 控制器管理调度到本节点的卷的挂接（attachment）和解除挂接（detachement）， 并且禁止 kubelet 执行任何 attach/detach 操作。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑在运行中的节点上更改由哪个组件来负责卷管理时， -这一变更可能导致节点在被更新前尚未腾空时卷无法被解除挂接。 -如果 kubelet 尚未更新volumes.kubernetes.io/controller-managed-attach-detach -注解时 Pod 已经被调度到了该节点，节点上的卷也会无法解除挂接。 -一般而言，最安全的做法是将此字段设置为与本地配置相同的值。

    +

    注意：kubelet 不支持挂接 CSI 卷和解除挂接， +因此对于该用例，此选项必须为 true。

    默认值：true

    @@ -1595,18 +1239,11 @@ Default: true

    protectKernelDefaults设置为true时，会令 kubelet 在发现内核参数与预期不符时出错退出。若此字段设置为false，则 kubelet 会尝试更改内核参数以满足其预期。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑启用此设置会在内核参数与 kubelet 预期不匹配时导致 -kubelet 进入崩溃循环（Crash-Loop）状态。

    默认值：false

    @@ -1619,18 +1256,12 @@ kubelet 进入崩溃循环（Crash-Loop）状态。

    are present on host. These rules will serve as utility rules for various components, e.g. kube-proxy. The rules will be created based on iptablesMasqueradeBit and iptablesDropBit. -If DynamicKubeletConfig (deprecated; default off) is on, when -dynamically updating this field, consider that -disabling it will prevent the Kubelet from healing locally misconfigured iptables rules. Default: true -->

    makeIPTablesUtilChains设置为true时，相当于允许 kubelet 确保一组 iptables 规则存在于宿主机上。这些规则会为不同的组件（例如 kube-proxy） 提供工具性质的规则。它们是基于iptablesMasqueradeBit和iptablesDropBit 来创建的。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑禁用此行为会导致 kubelet 无法在本地 iptables -规则出错时实现自愈。

    默认值：true

    @@ -1643,18 +1274,11 @@ Default: true Values must be within the range [0, 31]. Must be different from other mark bits. Warning: Please match the value of the corresponding parameter in kube-proxy. TODO: clean up IPTablesMasqueradeBit in kube-proxy. -If DynamicKubeletConfig (deprecated; default off) is on, when -dynamically updating this field, consider that -it needs to be coordinated with other components, like kube-proxy, and the update -will only be effective if MakeIPTablesUtilChains is enabled. Default: 14 -->

    iptablesMasqueradeBit是 iptables fwmark 空间中用来为 SNAT 作标记的位。此值必须介于[0, 31]区间，必须与其他标记位不同。

    警告：请确保此值设置与 kube-proxy 中对应的参数设置取值相同。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑此处的变更要与其他组件（如 kube-proxy）相应的变更协调一致。 -只有当makeIPTablesUtilChains能力被启用时，这里的更新才会起作用。

    默认值：14

    @@ -1665,17 +1289,10 @@ Default: 14 @@ -1686,22 +1303,12 @@ Default: 15 @@ -1711,14 +1318,9 @@ Default: nil @@ -1739,15 +1341,10 @@ Default: true @@ -1758,14 +1355,9 @@ Default: "10Mi" @@ -1803,20 +1395,11 @@ managers are running. Valid values include:

    pairs that describe resources reserved for non-kubernetes components. Currently only cpu and memory are supported. See http://kubernetes.io/docs/user-guide/compute-resources for more detail. -If DynamicKubeletConfig (deprecated; default off) is on, when -dynamically updating this field, consider that -it may not be possible to increase the reserved resources, because this -requires resizing cgroups. Always look for a NodeAllocatableEnforced event -after updating this field to ensure that the update was successful. Default: nil -->

    systemReserved是一组资源名称=资源数量对， 用来描述为非 Kubernetes 组件预留的资源（例如：'cpu=200m,memory=150G'）。

    目前仅支持 CPU 和内存。更多细节可参见 http://kubernetes.io/zh/docs/user-guide/compute-resources。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑增加预留资源也许是不可能的，因为需要改变控制组大小。 -在更改了此字段之后，应该总是关注NodeAllocatableEnforced事件， -以确保更新是成功的。

    默认值：Nil

    @@ -1830,21 +1413,12 @@ that describe resources reserved for kubernetes system components. Currently cpu, memory and local storage for root file system are supported. See https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ for more details. -If DynamicKubeletConfig (deprecated; default off) is on, when -dynamically updating this field, consider that -it may not be possible to increase the reserved resources, because this -requires resizing cgroups. Always look for a NodeAllocatableEnforced event -after updating this field to ensure that the update was successful. Default: nil -->

    kubeReserved是一组资源名称=资源数量对， 用来描述为 Kubernetes 系统组件预留的资源（例如：'cpu=200m,memory=150G'）。 目前支持 CPU、内存和根文件系统的本地存储。 更多细节可参见 https://kubernetes.io/zh/docs/concepts/configuration/manage-resources-containers/。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑增加预留资源也许是不可能的，因为需要改变控制组大小。 -在更改了此字段之后，应该总是关注NodeAllocatableEnforced事件， -以确保更新是成功的。

    默认值：Nil

    @@ -1893,18 +1467,14 @@ Default: "" @@ -1916,18 +1486,14 @@ Default: "" @@ -1945,13 +1511,6 @@ When kube-reserved is in the list, kubeReservedCgroup must be speci This field is supported only when cgroupsPerQOS is set to true. Refer to Node Allocatable for more information. -If DynamicKubeletConfig (deprecated; default off) is on, when -dynamically updating this field, consider that -removing enforcements may reduce the stability of the node. Alternatively, adding -enforcements may reduce the stability of components which were using more than -the reserved amount of resources; for example, enforcing kube-reserved may cause -Kubelets to OOM if it uses more than the reserved resources, and enforcing system-reserved -may cause system daemons to OOM if they use more than the reserved resources. Default: ["pods"] -->

    此标志设置 kubelet 需要执行的各类节点可分配资源策略。此字段接受一组选项列表。 @@ -1963,11 +1522,6 @@ Default: ["pods"]

    这个字段只有在cgroupsPerQOS被设置为true才被支持。

    参阅Node Allocatable 了解进一步的信息。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑去掉此机制可能会降低节点稳定性。 -反之，添加此机制可能会降低原来使用资源超出预留量的组件的稳定性。 -例如，实施 kube-reserved 在 kubelet 使用资源超出预留量时可能导致 kubelet 发生 OOM， -而实施 system-reserved 机制可能导致使用资源超出预留量的系统守护进程发生 OOM。

    默认值：["pods"]

    @@ -1996,14 +1550,9 @@ Default: [] @@ -2014,15 +1563,10 @@ Default: "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/" @@ -2034,15 +1578,10 @@ Default: "quot;

    kernelMemcgNotification字段如果被设置了，会告知 kubelet 集成内核的 memcg 通知机制来确定是否超出内存逐出阈值，而不是使用轮询机制来判定。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑这样做可能影响到 kubelet 与内核的交互方式。

    默认值：false

    @@ -2078,7 +1617,7 @@ Default: true
    system:masters 组 - 允许超级用户在平台上的任何资源上执行所有操作。 当在 ClusterRoleBinding 中使用时，可以授权对集群中以及所有名字空间中的全部资源进行完全控制。 -当在 RoleBinding 中使用时，可以授权控制 RoleBinding 所在名字空间中的所有资源，包括名字空间本身。 +当在 RoleBinding 中使用时，可以授权控制角色绑定所在名字空间中的所有资源，包括名字空间本身。
    admin 无 - 无 - 无 - @@ -1102,7 +1350,7 @@ It does not allow viewing roles or rolebindings. This role does not allow viewing Secrets, since reading the contents of Secrets enables access to ServiceAccount credentials in the namespace, which would allow API access as any ServiceAccount -in the namespace (a form of privilege escalation). +in the namespace (a form of privilege escalation). --> 此角色不允许查看 Secrets，因为读取 Secret 的内容意味着可以访问名字空间中 ServiceAccount 的凭据信息，进而允许利用名字空间中任何 ServiceAccount 的 @@ -1118,7 +1366,7 @@ ServiceAccount 的凭据信息，进而允许利用名字空间中任何 Service ### 核心组件角色 {#core-component-roles} - + - - - @@ -1187,17 +1435,17 @@ Allows access to resources required by the kubelet, including read access to --> 允许访问 kubelet 所需要的资源，包括对所有 Secret 的读操作和对所有 Pod 状态对象的写操作。 - -你应该使用 Node 鉴权组件 和 -NodeRestriction 准入插件 -而不是 system:node 角色。同时基于 kubelet 上调度执行的 Pod 来授权 +你应该使用 Node 鉴权组件和 +NodeRestriction 准入插件而不是 +system:node 角色。同时基于 kubelet 上调度执行的 Pod 来授权 kubelet 对 API 的访问。 - system:node 角色的意义仅是为了与从 v1.8 之前版本升级而来的集群兼容。 @@ -1220,13 +1468,13 @@ The system:node role only exists for compatibility with Kubernetes clus ### 其他组件角色 {#other-component-roles}
    system:kube-scheduler 用户 - 允许访问 {{< glossary_tooltip term_id="kube-scheduler" text="scheduler" >}} @@ -1148,8 +1396,8 @@ Allows access to the resources required by the {{< glossary_tooltip term_id="kub
    system:volume-scheduler system:kube-scheduler 用户 @@ -1161,23 +1409,23 @@ Allows access to the volume resources required by the kube-scheduler component.
    system:kube-controller-manager system:kube-controller-manager 用户 - 允许访问{{< glossary_tooltip term_id="kube-controller-manager" text="控制器管理器" >}} 组件所需要的资源。 -各个控制回路所需要的权限在控制器角色 详述。 +各个控制回路所需要的权限在控制器角色详述。
    system:node 无
    - + - @@ -1236,12 +1484,12 @@ The system:node role only exists for compatibility with Kubernetes clus - - - @@ -1273,36 +1521,34 @@ Role for the Heapster compo - + - + - - + - - - +动态卷驱动 +所需要的资源。 + - @@ -97,7 +97,7 @@ The map from metric-label to value allow-list of this label. The key's format is -如果为 true, 将允许特权容器。[默认值=false] +如果为 true，将允许特权容器。[默认值=false] @@ -131,8 +131,8 @@ of these audiences. If the --service-account-issuer flag is configured and this flag is not, this field defaults to a single element list containing the issuer URL. --> -API 的标识符。 -服务帐户令牌验证者将验证针对 API 使用的令牌是否已绑定到这些受众中的至少一个。 +API 的标识符。 +服务帐户令牌验证者将验证针对 API 使用的令牌是否已绑定到这些受众中的至少一个。 如果配置了 --service-account-issuer 标志，但未配置此标志， 则此字段默认为包含发布者 URL 的单个元素列表。 @@ -799,7 +799,7 @@ CORS 允许的来源清单，以逗号分隔。 -对污点 NotReady:NoExecute 的容忍时长（以秒计）。 +对污点 NotReady:NoExecute 的容忍时长（以秒计）。 默认情况下这一容忍度会被添加到尚未具有此容忍度的每个 pod 中。 @@ -833,7 +833,7 @@ that do not have a default watch size set. - + @@ -1847,7 +1847,7 @@ open before timing it out. This is the default request timeout for requests but may be overridden by flags such as --min-request-timeout for specific types of requests. --> -可选字段，指示处理程序在超时之前必须保持打开请求的持续时间。 +可选字段，指示处理程序在超时之前必须保持打开请求的持续时间。 这是请求的默认请求超时，但对于特定类型的请求，可能会被 --min-request-timeout等标志覆盖。 @@ -2004,9 +2004,9 @@ and all are used to determine which issuers are accepted. 颁发者将在已办法令牌的 "iss" 声明中检查此标识符。 此值为字符串或 URI。 如果根据 OpenID Discovery 1.0 规范检查此选项不是有效的 URI，则即使特性门控设置为 true， -ServiceAccountIssuerDiscovery 功能也将保持禁用状态。 -强烈建议该值符合 OpenID 规范：https://openid.net/specs/openid-connect-discovery-1_0.html。 -实践中，这意味着 service-account-issuer 取值必须是 HTTPS URL。 +ServiceAccountIssuerDiscovery 功能也将保持禁用状态。 +强烈建议该值符合 OpenID 规范： https://openid.net/specs/openid-connect-discovery-1_0.html 。 +实践中，这意味着 service-account-issuer 取值必须是 HTTPS URL。 还强烈建议此 URL 能够在 {service-account-issuer}/.well-known/openid-configuration 处提供 OpenID 发现文档。 当此值被多次指定时，第一次的值用于生成令牌，所有的值用于确定接受哪些发行人。 @@ -2209,7 +2209,7 @@ List of directives for HSTS, comma separated. If this list is empty, then HSTS d --> 为 HSTS 所设置的指令列表，用逗号分隔。 如果此列表为空，则不会添加 HSTS 指令。 -例如： 'max-age=31536000,includeSubDomains,preload' +例如：'max-age=31536000,includeSubDomains,preload'

    @@ -2280,7 +2280,7 @@ File containing the default x509 private key matching --tls-cert-file.     - + - - - - - - - @@ -73,7 +61,7 @@ Should CIDRs for Pods be allocated and set on the cloud provider. - + - - - - - - - @@ -232,7 +208,7 @@ Path to the file containing Azure container registry configuration information. - + + + + + + + + @@ -676,7 +665,7 @@ Interval between starting controller managers. - + - - - - - - - @@ -822,19 +799,6 @@ The length of endpoint slice updates batching period. Processing of pod changes - - - - - - - @@ -864,96 +828,99 @@ APIServerIdentity=true|false (ALPHA - default=false)
    APIServerTracing=true|false (ALPHA - default=false)
    AllAlpha=true|false (ALPHA - default=false)
    AllBeta=true|false (BETA - default=false)
    -AnyVolumeDataSource=true|false (ALPHA - default=false)
    +AnyVolumeDataSource=true|false (BETA - default=true)
    AppArmor=true|false (BETA - default=true)
    CPUManager=true|false (BETA - default=true)
    -CPUManagerPolicyOptions=true|false (ALPHA - default=false)
    +CPUManagerPolicyAlphaOptions=true|false (ALPHA - default=false)
    +CPUManagerPolicyBetaOptions=true|false (BETA - default=true)
    +CPUManagerPolicyOptions=true|false (BETA - default=true)
    CSIInlineVolume=true|false (BETA - default=true)
    CSIMigration=true|false (BETA - default=true)
    -CSIMigrationAWS=true|false (BETA - default=false)
    -CSIMigrationAzureDisk=true|false (BETA - default=false)
    -CSIMigrationAzureFile=true|false (BETA - default=false)
    -CSIMigrationGCE=true|false (BETA - default=false)
    -CSIMigrationOpenStack=true|false (BETA - default=true)
    +CSIMigrationAWS=true|false (BETA - default=true)
    +CSIMigrationAzureFile=true|false (BETA - default=true)
    +CSIMigrationGCE=true|false (BETA - default=true)
    +CSIMigrationPortworx=true|false (ALPHA - default=false)
    +CSIMigrationRBD=true|false (ALPHA - default=false)
    CSIMigrationvSphere=true|false (BETA - default=false)
    -CSIStorageCapacity=true|false (BETA - default=true)
    -CSIVolumeFSGroupPolicy=true|false (BETA - default=true)
    CSIVolumeHealth=true|false (ALPHA - default=false)
    -CSRDuration=true|false (BETA - default=true)
    -ConfigurableFSGroupPolicy=true|false (BETA - default=true)
    -ControllerManagerLeaderMigration=true|false (BETA - default=true)
    +ContextualLogging=true|false (ALPHA - default=false)
    +CronJobTimeZone=true|false (ALPHA - default=false)
    CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)
    +CustomResourceValidationExpressions=true|false (ALPHA - default=false)
    DaemonSetUpdateSurge=true|false (BETA - default=true)
    -DefaultPodTopologySpread=true|false (BETA - default=true)
    -DelegateFSGroupToCSIDriver=true|false (ALPHA - default=false)
    +DelegateFSGroupToCSIDriver=true|false (BETA - default=true)
    DevicePlugins=true|false (BETA - default=true)
    DisableAcceleratorUsageMetrics=true|false (BETA - default=true)
    DisableCloudProviders=true|false (ALPHA - default=false)
    -DownwardAPIHugePages=true|false (BETA - default=false)
    -EfficientWatchResumption=true|false (BETA - default=true)
    +DisableKubeletCloudCredentialProviders=true|false (ALPHA - default=false)
    +DownwardAPIHugePages=true|false (BETA - default=true)
    EndpointSliceTerminatingCondition=true|false (BETA - default=true)
    -EphemeralContainers=true|false (ALPHA - default=false)
    -ExpandCSIVolumes=true|false (BETA - default=true)
    -ExpandInUsePersistentVolumes=true|false (BETA - default=true)
    -ExpandPersistentVolumes=true|false (BETA - default=true)
    +EphemeralContainers=true|false (BETA - default=true)
    ExpandedDNSConfig=true|false (ALPHA - default=false)
    ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
    -GenericEphemeralVolume=true|false (BETA - default=true)
    +GRPCContainerProbe=true|false (BETA - default=true)
    GracefulNodeShutdown=true|false (BETA - default=true)
    +GracefulNodeShutdownBasedOnPodPriority=true|false (BETA - default=true)
    HPAContainerMetrics=true|false (ALPHA - default=false)
    HPAScaleToZero=true|false (ALPHA - default=false)
    -IPv6DualStack=true|false (BETA - default=true)
    +HonorPVReclaimPolicy=true|false (ALPHA - default=false)
    +IdentifyPodOS=true|false (BETA - default=true)
    InTreePluginAWSUnregister=true|false (ALPHA - default=false)
    InTreePluginAzureDiskUnregister=true|false (ALPHA - default=false)
    InTreePluginAzureFileUnregister=true|false (ALPHA - default=false)
    InTreePluginGCEUnregister=true|false (ALPHA - default=false)
    InTreePluginOpenStackUnregister=true|false (ALPHA - default=false)
    +InTreePluginPortworxUnregister=true|false (ALPHA - default=false)
    +InTreePluginRBDUnregister=true|false (ALPHA - default=false)
    InTreePluginvSphereUnregister=true|false (ALPHA - default=false)
    -IndexedJob=true|false (BETA - default=true)
    -IngressClassNamespacedParams=true|false (BETA - default=true)
    -JobTrackingWithFinalizers=true|false (ALPHA - default=false)
    -KubeletCredentialProviders=true|false (ALPHA - default=false)
    +JobMutableNodeSchedulingDirectives=true|false (BETA - default=true)
    +JobReadyPods=true|false (BETA - default=true)
    +JobTrackingWithFinalizers=true|false (BETA - default=false)
    +KubeletCredentialProviders=true|false (BETA - default=true)
    KubeletInUserNamespace=true|false (ALPHA - default=false)
    KubeletPodResources=true|false (BETA - default=true)
    -KubeletPodResourcesGetAllocatable=true|false (ALPHA - default=false)
    +KubeletPodResourcesGetAllocatable=true|false (BETA - default=true)
    +LegacyServiceAccountTokenNoAutoGeneration=true|false (BETA - default=true)
    LocalStorageCapacityIsolation=true|false (BETA - default=true)
    LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)
    LogarithmicScaleDown=true|false (BETA - default=true)
    +MaxUnavailableStatefulSet=true|false (ALPHA - default=false)
    MemoryManager=true|false (BETA - default=true)
    MemoryQoS=true|false (ALPHA - default=false)
    -MixedProtocolLBService=true|false (ALPHA - default=false)
    +MinDomainsInPodTopologySpread=true|false (ALPHA - default=false)
    +MixedProtocolLBService=true|false (BETA - default=true)
    NetworkPolicyEndPort=true|false (BETA - default=true)
    +NetworkPolicyStatus=true|false (ALPHA - default=false)
    +NodeOutOfServiceVolumeDetach=true|false (ALPHA - default=false)
    NodeSwap=true|false (ALPHA - default=false)
    -NonPreemptingPriority=true|false (BETA - default=true)
    -PodAffinityNamespaceSelector=true|false (BETA - default=true)
    +OpenAPIEnums=true|false (BETA - default=true)
    +OpenAPIV3=true|false (BETA - default=true)
    +PodAndContainerStatsFromCRI=true|false (ALPHA - default=false)
    PodDeletionCost=true|false (BETA - default=true)
    -PodOverhead=true|false (BETA - default=true)
    -PodSecurity=true|false (ALPHA - default=false)
    -PreferNominatedNode=true|false (BETA - default=true)
    +PodSecurity=true|false (BETA - default=true)
    ProbeTerminationGracePeriod=true|false (BETA - default=false)
    ProcMountType=true|false (ALPHA - default=false)
    ProxyTerminatingEndpoints=true|false (ALPHA - default=false)
    QOSReserved=true|false (ALPHA - default=false)
    ReadWriteOncePod=true|false (ALPHA - default=false)
    +RecoverVolumeExpansionFailure=true|false (ALPHA - default=false)
    RemainingItemCount=true|false (BETA - default=true)
    -RemoveSelfLink=true|false (BETA - default=true)
    RotateKubeletServerCertificate=true|false (BETA - default=true)
    SeccompDefault=true|false (ALPHA - default=false)
    +ServerSideFieldValidation=true|false (ALPHA - default=false)
    +ServiceIPStaticSubrange=true|false (ALPHA - default=false)
    ServiceInternalTrafficPolicy=true|false (BETA - default=true)
    -ServiceLBNodePortControl=true|false (BETA - default=true)
    -ServiceLoadBalancerClass=true|false (BETA - default=true)
    SizeMemoryBackedVolumes=true|false (BETA - default=true)
    -StatefulSetMinReadySeconds=true|false (ALPHA - default=false)
    +StatefulSetAutoDeletePVC=true|false (ALPHA - default=false)
    +StatefulSetMinReadySeconds=true|false (BETA - default=true)
    StorageVersionAPI=true|false (ALPHA - default=false)
    StorageVersionHash=true|false (BETA - default=true)
    -SuspendJob=true|false (BETA - default=true)
    -TTLAfterFinished=true|false (BETA - default=true)
    -TopologyAwareHints=true|false (ALPHA - default=false)
    +TopologyAwareHints=true|false (BETA - default=true)
    TopologyManager=true|false (BETA - default=true)
    VolumeCapacityPriority=true|false (ALPHA - default=false)
    WinDSR=true|false (ALPHA - default=false)
    WinOverlay=true|false (BETA - default=true)
    -WindowsHostProcessContainers=true|false (ALPHA - default=false) +WindowsHostProcessContainers=true|false (BETA - default=true) --> 一组 key=value 对，用来描述测试性/试验性功能的特性门控（Feature Gate）。可选项有： APIListChunking=true|false (BETA - 默认值=true)
    @@ -963,96 +930,99 @@ APIServerIdentity=true|false (ALPHA - 默认值=false)
    APIServerTracing=true|false (ALPHA - 默认值=false)
    AllAlpha=true|false (ALPHA - 默认值=false)
    AllBeta=true|false (BETA - 默认值=false)
    -AnyVolumeDataSource=true|false (ALPHA - 默认值=false)
    +AnyVolumeDataSource=true|false (BETA - 默认值=true)
    AppArmor=true|false (BETA - 默认值=true)
    CPUManager=true|false (BETA - 默认值=true)
    -CPUManagerPolicyOptions=true|false (ALPHA - 默认值=false)
    +CPUManagerPolicyAlphaOptions=true|false (ALPHA - 默认值=false)
    +CPUManagerPolicyBetaOptions=true|false (BETA - 默认值=true)
    +CPUManagerPolicyOptions=true|false (BETA - 默认值=true)
    CSIInlineVolume=true|false (BETA - 默认值=true)
    CSIMigration=true|false (BETA - 默认值=true)
    -CSIMigrationAWS=true|false (BETA - 默认值=false)
    -CSIMigrationAzureDisk=true|false (BETA - 默认值=false)
    -CSIMigrationAzureFile=true|false (BETA - 默认值=false)
    -CSIMigrationGCE=true|false (BETA - 默认值=false)
    -CSIMigrationOpenStack=true|false (BETA - 默认值=true)
    +CSIMigrationAWS=true|false (BETA - 默认值=true)
    +CSIMigrationAzureFile=true|false (BETA - 默认值=true)
    +CSIMigrationGCE=true|false (BETA - 默认值=true)
    +CSIMigrationPortworx=true|false (ALPHA - 默认值=false)
    +CSIMigrationRBD=true|false (ALPHA - 默认值=false)
    CSIMigrationvSphere=true|false (BETA - 默认值=false)
    -CSIStorageCapacity=true|false (BETA - 默认值=true)
    -CSIVolumeFSGroupPolicy=true|false (BETA - 默认值=true)
    CSIVolumeHealth=true|false (ALPHA - 默认值=false)
    -CSRDuration=true|false (BETA - 默认值=true)
    -ConfigurableFSGroupPolicy=true|false (BETA - 默认值=true)
    -ControllerManagerLeaderMigration=true|false (BETA - 默认值=true)
    +ContextualLogging=true|false (ALPHA - 默认值=false)
    +CronJobTimeZone=true|false (ALPHA - 默认值=false)
    CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值=false)
    +CustomResourceValidationExpressions=true|false (ALPHA - 默认值=false)
    DaemonSetUpdateSurge=true|false (BETA - 默认值=true)
    -默认值PodTopologySpread=true|false (BETA - 默认值=true)
    -DelegateFSGroupToCSIDriver=true|false (ALPHA - 默认值=false)
    +DelegateFSGroupToCSIDriver=true|false (BETA - 默认值=true)
    DevicePlugins=true|false (BETA - 默认值=true)
    DisableAcceleratorUsageMetrics=true|false (BETA - 默认值=true)
    DisableCloudProviders=true|false (ALPHA - 默认值=false)
    -DownwardAPIHugePages=true|false (BETA - 默认值=false)
    -EfficientWatchResumption=true|false (BETA - 默认值=true)
    +DisableKubeletCloudCredentialProviders=true|false (ALPHA - 默认值=false)
    +DownwardAPIHugePages=true|false (BETA - 默认值=true)
    EndpointSliceTerminatingCondition=true|false (BETA - 默认值=true)
    -EphemeralContainers=true|false (ALPHA - 默认值=false)
    -ExpandCSIVolumes=true|false (BETA - 默认值=true)
    -ExpandInUsePersistentVolumes=true|false (BETA - 默认值=true)
    -ExpandPersistentVolumes=true|false (BETA - 默认值=true)
    +EphemeralContainers=true|false (BETA - 默认值=true)
    ExpandedDNSConfig=true|false (ALPHA - 默认值=false)
    -ExperimentalHostUserNamespace默认值ing=true|false (BETA - 默认值=false)
    -GenericEphemeralVolume=true|false (BETA - 默认值=true)
    +ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 默认值=false)
    +GRPCContainerProbe=true|false (BETA - 默认值=true)
    GracefulNodeShutdown=true|false (BETA - 默认值=true)
    +GracefulNodeShutdownBasedOnPodPriority=true|false (BETA - 默认值=true)
    HPAContainerMetrics=true|false (ALPHA - 默认值=false)
    HPAScaleToZero=true|false (ALPHA - 默认值=false)
    -IPv6DualStack=true|false (BETA - 默认值=true)
    +HonorPVReclaimPolicy=true|false (ALPHA - 默认值=false)
    +IdentifyPodOS=true|false (BETA - 默认值=true)
    InTreePluginAWSUnregister=true|false (ALPHA - 默认值=false)
    InTreePluginAzureDiskUnregister=true|false (ALPHA - 默认值=false)
    InTreePluginAzureFileUnregister=true|false (ALPHA - 默认值=false)
    InTreePluginGCEUnregister=true|false (ALPHA - 默认值=false)
    InTreePluginOpenStackUnregister=true|false (ALPHA - 默认值=false)
    +InTreePluginPortworxUnregister=true|false (ALPHA - 默认值=false)
    +InTreePluginRBDUnregister=true|false (ALPHA - 默认值=false)
    InTreePluginvSphereUnregister=true|false (ALPHA - 默认值=false)
    -IndexedJob=true|false (BETA - 默认值=true)
    -IngressClassNamespacedParams=true|false (BETA - 默认值=true)
    -JobTrackingWithFinalizers=true|false (ALPHA - 默认值=false)
    -KubeletCredentialProviders=true|false (ALPHA - 默认值=false)
    +JobMutableNodeSchedulingDirectives=true|false (BETA - 默认值=true)
    +JobReadyPods=true|false (BETA - 默认值=true)
    +JobTrackingWithFinalizers=true|false (BETA - 默认值=false)
    +KubeletCredentialProviders=true|false (BETA - 默认值=true)
    KubeletInUserNamespace=true|false (ALPHA - 默认值=false)
    KubeletPodResources=true|false (BETA - 默认值=true)
    -KubeletPodResourcesGetAllocatable=true|false (ALPHA - 默认值=false)
    +KubeletPodResourcesGetAllocatable=true|false (BETA - 默认值=true)
    +LegacyServiceAccountTokenNoAutoGeneration=true|false (BETA - 默认值=true)
    LocalStorageCapacityIsolation=true|false (BETA - 默认值=true)
    LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值=false)
    LogarithmicScaleDown=true|false (BETA - 默认值=true)
    +MaxUnavailableStatefulSet=true|false (ALPHA - 默认值=false)
    MemoryManager=true|false (BETA - 默认值=true)
    MemoryQoS=true|false (ALPHA - 默认值=false)
    -MixedProtocolLBService=true|false (ALPHA - 默认值=false)
    +MinDomainsInPodTopologySpread=true|false (ALPHA - 默认值=false)
    +MixedProtocolLBService=true|false (BETA - 默认值=true)
    NetworkPolicyEndPort=true|false (BETA - 默认值=true)
    +NetworkPolicyStatus=true|false (ALPHA - 默认值=false)
    +NodeOutOfServiceVolumeDetach=true|false (ALPHA - 默认值=false)
    NodeSwap=true|false (ALPHA - 默认值=false)
    -NonPreemptingPriority=true|false (BETA - 默认值=true)
    -PodAffinityNamespaceSelector=true|false (BETA - 默认值=true)
    +OpenAPIEnums=true|false (BETA - 默认值=true)
    +OpenAPIV3=true|false (BETA - 默认值=true)
    +PodAndContainerStatsFromCRI=true|false (ALPHA - 默认值=false)
    PodDeletionCost=true|false (BETA - 默认值=true)
    -PodOverhead=true|false (BETA - 默认值=true)
    -PodSecurity=true|false (ALPHA - 默认值=false)
    -PreferNominatedNode=true|false (BETA - 默认值=true)
    +PodSecurity=true|false (BETA - 默认值=true)
    ProbeTerminationGracePeriod=true|false (BETA - 默认值=false)
    ProcMountType=true|false (ALPHA - 默认值=false)
    ProxyTerminatingEndpoints=true|false (ALPHA - 默认值=false)
    QOSReserved=true|false (ALPHA - 默认值=false)
    ReadWriteOncePod=true|false (ALPHA - 默认值=false)
    +RecoverVolumeExpansionFailure=true|false (ALPHA - 默认值=false)
    RemainingItemCount=true|false (BETA - 默认值=true)
    -RemoveSelfLink=true|false (BETA - 默认值=true)
    RotateKubeletServerCertificate=true|false (BETA - 默认值=true)
    -Seccomp默认值=true|false (ALPHA - 默认值=false)
    +SeccompDefault=true|false (ALPHA - 默认值=false)
    +ServerSideFieldValidation=true|false (ALPHA - 默认值=false)
    +ServiceIPStaticSubrange=true|false (ALPHA - 默认值=false)
    ServiceInternalTrafficPolicy=true|false (BETA - 默认值=true)
    -ServiceLBNodePortControl=true|false (BETA - 默认值=true)
    -ServiceLoadBalancerClass=true|false (BETA - 默认值=true)
    SizeMemoryBackedVolumes=true|false (BETA - 默认值=true)
    -StatefulSetMinReadySeconds=true|false (ALPHA - 默认值=false)
    +StatefulSetAutoDeletePVC=true|false (ALPHA - 默认值=false)
    +StatefulSetMinReadySeconds=true|false (BETA - 默认值=true)
    StorageVersionAPI=true|false (ALPHA - 默认值=false)
    StorageVersionHash=true|false (BETA - 默认值=true)
    -SuspendJob=true|false (BETA - 默认值=true)
    -TTLAfterFinished=true|false (BETA - 默认值=true)
    -TopologyAwareHints=true|false (ALPHA - 默认值=false)
    +TopologyAwareHints=true|false (BETA - 默认值=true)
    TopologyManager=true|false (BETA - 默认值=true)
    VolumeCapacityPriority=true|false (ALPHA - 默认值=false)
    WinDSR=true|false (ALPHA - 默认值=false)
    WinOverlay=true|false (BETA - 默认值=true)
    -WindowsHostProcessContainers=true|false (ALPHA - 默认值=false) +WindowsHostProcessContainers=true|false (BETA - 默认值=true)

    @@ -1181,7 +1151,7 @@ Content type of requests sent to apiserver.     - + @@ -1326,56 +1296,6 @@ Path to the config file for controller leader migration, or empty to use the val

    - -     - - - - - - - - - - - - - - - - - - - - - - - - - - - @@ -1394,31 +1314,19 @@ Maximum number of seconds between log flushes - - - - - - - @@ -1492,10 +1400,10 @@ EndpointSlice 更改的处理将延迟此持续时间， @@ -1548,7 +1456,7 @@ Mask size for IPv6 node cidr in dual-stack cluster. Default is 64. - + - - - - - - - @@ -1637,7 +1533,7 @@ If true, SO_REUSEADDR will be used when binding the port. This allows binding to If true, SO_REUSEPORT will be used when binding the port, which allows more than one instance to bind on the same address and port. [default=false] --> 如果为 true，则在绑定端口时将使用 SO_REUSEPORT， -这允许多个实例在同一地址和端口上进行绑定。 +这允许多个实例在同一地址和端口上进行绑定。[默认值=false]。 @@ -1722,7 +1618,7 @@ The file path to a pod definition used as a template for HostPath persistent vol @@ -1759,7 +1655,8 @@ The period for syncing persistent volumes and persistent volume claims - - - - - - - - - - - - - - - - - - - - - @@ -1992,11 +1853,11 @@ File containing the default x509 Certificate for HTTPS. (CA cert, if any, concat @@ -2026,12 +1887,12 @@ File containing the default x509 private key matching --tls-cert-file. - + - + diff --git a/content/zh/docs/reference/command-line-tools-reference/kube-proxy.md b/content/zh/docs/reference/command-line-tools-reference/kube-proxy.md index 0eff062d25..2cb541d830 100644 --- a/content/zh/docs/reference/command-line-tools-reference/kube-proxy.md +++ b/content/zh/docs/reference/command-line-tools-reference/kube-proxy.md @@ -53,30 +53,6 @@ kube-proxy [flags] - - - - - - - - - - - - - - @@ -96,10 +72,11 @@ Path to the file containing Azure container registry configuration information. @@ -142,17 +119,44 @@ If true cleanup iptables and ipvs rules and exit. + + + + + + + + + + + + + + @@ -238,13 +242,42 @@ Idle timeout for established TCP connections (0 to leave as-is) + + + + + + + + + + + + + + @@ -264,96 +297,100 @@ APIServerIdentity=true|false (ALPHA - default=false)
    APIServerTracing=true|false (ALPHA - default=false)
    AllAlpha=true|false (ALPHA - default=false)
    AllBeta=true|false (BETA - default=false)
    -AnyVolumeDataSource=true|false (ALPHA - default=false)
    +AnyVolumeDataSource=true|false (BETA - default=true)
    AppArmor=true|false (BETA - default=true)
    CPUManager=true|false (BETA - default=true)
    -CPUManagerPolicyOptions=true|false (ALPHA - default=false)
    +CPUManagerPolicyAlphaOptions=true|false (ALPHA - default=false)
    +CPUManagerPolicyBetaOptions=true|false (BETA - default=true)
    +CPUManagerPolicyOptions=true|false (BETA - default=true)
    CSIInlineVolume=true|false (BETA - default=true)
    CSIMigration=true|false (BETA - default=true)
    -CSIMigrationAWS=true|false (BETA - default=false)
    -CSIMigrationAzureDisk=true|false (BETA - default=false)
    -CSIMigrationAzureFile=true|false (BETA - default=false)
    -CSIMigrationGCE=true|false (BETA - default=false)
    -CSIMigrationOpenStack=true|false (BETA - default=true)
    +CSIMigrationAWS=true|false (BETA - default=true)
    +CSIMigrationAzureFile=true|false (BETA - default=true)
    +CSIMigrationGCE=true|false (BETA - default=true)
    +CSIMigrationPortworx=true|false (ALPHA - default=false)
    +CSIMigrationRBD=true|false (ALPHA - default=false)
    CSIMigrationvSphere=true|false (BETA - default=false)
    -CSIStorageCapacity=true|false (BETA - default=true)
    -CSIVolumeFSGroupPolicy=true|false (BETA - default=true)
    CSIVolumeHealth=true|false (ALPHA - default=false)
    -CSRDuration=true|false (BETA - default=true)
    -ConfigurableFSGroupPolicy=true|false (BETA - default=true)
    -ControllerManagerLeaderMigration=true|false (BETA - default=true)
    +ContextualLogging=true|false (ALPHA - default=false)
    +CronJobTimeZone=true|false (ALPHA - default=false)
    CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)
    +CustomResourceValidationExpressions=true|false (ALPHA - default=false)
    DaemonSetUpdateSurge=true|false (BETA - default=true)
    -DefaultPodTopologySpread=true|false (BETA - default=true)
    -DelegateFSGroupToCSIDriver=true|false (ALPHA - default=false)
    +DelegateFSGroupToCSIDriver=true|false (BETA - default=true)
    DevicePlugins=true|false (BETA - default=true)
    DisableAcceleratorUsageMetrics=true|false (BETA - default=true)
    DisableCloudProviders=true|false (ALPHA - default=false)
    -DownwardAPIHugePages=true|false (BETA - default=false)
    -EfficientWatchResumption=true|false (BETA - default=true)
    +DisableKubeletCloudCredentialProviders=true|false (ALPHA - default=false)
    +DownwardAPIHugePages=true|false (BETA - default=true)
    EndpointSliceTerminatingCondition=true|false (BETA - default=true)
    -EphemeralContainers=true|false (ALPHA - default=false)
    -ExpandCSIVolumes=true|false (BETA - default=true)
    -ExpandInUsePersistentVolumes=true|false (BETA - default=true)
    -ExpandPersistentVolumes=true|false (BETA - default=true)
    +EphemeralContainers=true|false (BETA - default=true)
    ExpandedDNSConfig=true|false (ALPHA - default=false)
    ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
    -GenericEphemeralVolume=true|false (BETA - default=true)
    +GRPCContainerProbe=true|false (BETA - default=true)
    GracefulNodeShutdown=true|false (BETA - default=true)
    +GracefulNodeShutdownBasedOnPodPriority=true|false (BETA - default=true)
    HPAContainerMetrics=true|false (ALPHA - default=false)
    HPAScaleToZero=true|false (ALPHA - default=false)
    -IPv6DualStack=true|false (BETA - default=true)
    +HonorPVReclaimPolicy=true|false (ALPHA - default=false)
    +IdentifyPodOS=true|false (BETA - default=true)
    InTreePluginAWSUnregister=true|false (ALPHA - default=false)
    InTreePluginAzureDiskUnregister=true|false (ALPHA - default=false)
    InTreePluginAzureFileUnregister=true|false (ALPHA - default=false)
    InTreePluginGCEUnregister=true|false (ALPHA - default=false)
    InTreePluginOpenStackUnregister=true|false (ALPHA - default=false)
    +InTreePluginPortworxUnregister=true|false (ALPHA - default=false)
    +InTreePluginRBDUnregister=true|false (ALPHA - default=false)
    InTreePluginvSphereUnregister=true|false (ALPHA - default=false)
    -IndexedJob=true|false (BETA - default=true)
    -IngressClassNamespacedParams=true|false (BETA - default=true)
    -JobTrackingWithFinalizers=true|false (ALPHA - default=false)
    -KubeletCredentialProviders=true|false (ALPHA - default=false)
    +JobMutableNodeSchedulingDirectives=true|false (BETA - default=true)
    +JobReadyPods=true|false (BETA - default=true)
    +JobTrackingWithFinalizers=true|false (BETA - default=false)
    +KubeletCredentialProviders=true|false (BETA - default=true)
    KubeletInUserNamespace=true|false (ALPHA - default=false)
    KubeletPodResources=true|false (BETA - default=true)
    -KubeletPodResourcesGetAllocatable=true|false (ALPHA - default=false)
    +KubeletPodResourcesGetAllocatable=true|false (BETA - default=true)
    +LegacyServiceAccountTokenNoAutoGeneration=true|false (BETA - default=true)
    LocalStorageCapacityIsolation=true|false (BETA - default=true)
    LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)
    LogarithmicScaleDown=true|false (BETA - default=true)
    +MaxUnavailableStatefulSet=true|false (ALPHA - default=false)
    MemoryManager=true|false (BETA - default=true)
    MemoryQoS=true|false (ALPHA - default=false)
    -MixedProtocolLBService=true|false (ALPHA - default=false)
    +MinDomainsInPodTopologySpread=true|false (ALPHA - default=false)
    +MixedProtocolLBService=true|false (BETA - default=true)
    NetworkPolicyEndPort=true|false (BETA - default=true)
    +NetworkPolicyStatus=true|false (ALPHA - default=false)
    +NodeOutOfServiceVolumeDetach=true|false (ALPHA - default=false)
    NodeSwap=true|false (ALPHA - default=false)
    -NonPreemptingPriority=true|false (BETA - default=true)
    -PodAffinityNamespaceSelector=true|false (BETA - default=true)
    +OpenAPIEnums=true|false (BETA - default=true)
    +OpenAPIV3=true|false (BETA - default=true)
    +PodAndContainerStatsFromCRI=true|false (ALPHA - default=false)
    PodDeletionCost=true|false (BETA - default=true)
    -PodOverhead=true|false (BETA - default=true)
    -PodSecurity=true|false (ALPHA - default=false)
    -PreferNominatedNode=true|false (BETA - default=true)
    +PodSecurity=true|false (BETA - default=true)
    ProbeTerminationGracePeriod=true|false (BETA - default=false)
    ProcMountType=true|false (ALPHA - default=false)
    ProxyTerminatingEndpoints=true|false (ALPHA - default=false)
    QOSReserved=true|false (ALPHA - default=false)
    ReadWriteOncePod=true|false (ALPHA - default=false)
    +RecoverVolumeExpansionFailure=true|false (ALPHA - default=false)
    RemainingItemCount=true|false (BETA - default=true)
    -RemoveSelfLink=true|false (BETA - default=true)
    RotateKubeletServerCertificate=true|false (BETA - default=true)
    SeccompDefault=true|false (ALPHA - default=false)
    +ServerSideFieldValidation=true|false (ALPHA - default=false)
    +ServiceIPStaticSubrange=true|false (ALPHA - default=false)
    ServiceInternalTrafficPolicy=true|false (BETA - default=true)
    -ServiceLBNodePortControl=true|false (BETA - default=true)
    -ServiceLoadBalancerClass=true|false (BETA - default=true)
    1 SizeMemoryBackedVolumes=true|false (BETA - default=true)
    -StatefulSetMinReadySeconds=true|false (ALPHA - default=false)
    +StatefulSetAutoDeletePVC=true|false (ALPHA - default=false)
    +StatefulSetMinReadySeconds=true|false (BETA - default=true)
    StorageVersionAPI=true|false (ALPHA - default=false)
    StorageVersionHash=true|false (BETA - default=true)
    -SuspendJob=true|false (BETA - default=true)
    -TTLAfterFinished=true|false (BETA - default=true)
    -TopologyAwareHints=true|false (ALPHA - default=false)
    +TopologyAwareHints=true|false (BETA - default=true)
    TopologyManager=true|false (BETA - default=true)
    VolumeCapacityPriority=true|false (ALPHA - default=false)
    WinDSR=true|false (ALPHA - default=false)
    WinOverlay=true|false (BETA - default=true)
    -WindowsHostProcessContainers=true|false (ALPHA - default=false) +WindowsHostProcessContainers=true|false (BETA - default=true) +This parameter is ignored if a config file is specified by --config. --> 一组键=值（key=value）对，描述了 alpha/experimental 的特征。可选项有： APIListChunking=true|false (BETA - 默认值=true)
    @@ -363,96 +400,100 @@ APIServerIdentity=true|false (ALPHA - 默认值=false)
    APIServerTracing=true|false (ALPHA - 默认值=false)
    AllAlpha=true|false (ALPHA - 默认值=false)
    AllBeta=true|false (BETA - 默认值=false)
    -AnyVolumeDataSource=true|false (ALPHA - 默认值=false)
    +AnyVolumeDataSource=true|false (BETA - 默认值=true)
    AppArmor=true|false (BETA - 默认值=true)
    CPUManager=true|false (BETA - 默认值=true)
    -CPUManagerPolicyOptions=true|false (ALPHA - 默认值=false)
    +CPUManagerPolicyAlphaOptions=true|false (ALPHA - 默认值=false)
    +CPUManagerPolicyBetaOptions=true|false (BETA - 默认值=true)
    +CPUManagerPolicyOptions=true|false (BETA - 默认值=true)
    CSIInlineVolume=true|false (BETA - 默认值=true)
    CSIMigration=true|false (BETA - 默认值=true)
    -CSIMigrationAWS=true|false (BETA - 默认值=false)
    -CSIMigrationAzureDisk=true|false (BETA - 默认值=false)
    -CSIMigrationAzureFile=true|false (BETA - 默认值=false)
    -CSIMigrationGCE=true|false (BETA - 默认值=false)
    -CSIMigrationOpenStack=true|false (BETA - 默认值=true)
    +CSIMigrationAWS=true|false (BETA - 默认值=true)
    +CSIMigrationAzureFile=true|false (BETA - 默认值=true)
    +CSIMigrationGCE=true|false (BETA - 默认值=true)
    +CSIMigrationPortworx=true|false (ALPHA - 默认值=false)
    +CSIMigrationRBD=true|false (ALPHA - 默认值=false)
    CSIMigrationvSphere=true|false (BETA - 默认值=false)
    -CSIStorageCapacity=true|false (BETA - 默认值=true)
    -CSIVolumeFSGroupPolicy=true|false (BETA - 默认值=true)
    CSIVolumeHealth=true|false (ALPHA - 默认值=false)
    -CSRDuration=true|false (BETA - 默认值=true)
    -ConfigurableFSGroupPolicy=true|false (BETA - 默认值=true)
    -ControllerManagerLeaderMigration=true|false (BETA - 默认值=true)
    +ContextualLogging=true|false (ALPHA - 默认值=false)
    +CronJobTimeZone=true|false (ALPHA - 默认值=false)
    CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值=false)
    +CustomResourceValidationExpressions=true|false (ALPHA - 默认值=false)
    DaemonSetUpdateSurge=true|false (BETA - 默认值=true)
    -DefaultPodTopologySpread=true|false (BETA - 默认值=true)
    -DelegateFSGroupToCSIDriver=true|false (ALPHA - 默认值=false)
    +DelegateFSGroupToCSIDriver=true|false (BETA - 默认值=true)
    DevicePlugins=true|false (BETA - 默认值=true)
    DisableAcceleratorUsageMetrics=true|false (BETA - 默认值=true)
    DisableCloudProviders=true|false (ALPHA - 默认值=false)
    -DownwardAPIHugePages=true|false (BETA - 默认值=false)
    -EfficientWatchResumption=true|false (BETA - 默认值=true)
    +DisableKubeletCloudCredentialProviders=true|false (ALPHA - 默认值=false)
    +DownwardAPIHugePages=true|false (BETA - 默认值=true)
    EndpointSliceTerminatingCondition=true|false (BETA - 默认值=true)
    -EphemeralContainers=true|false (ALPHA - 默认值=false)
    -ExpandCSIVolumes=true|false (BETA - 默认值=true)
    -ExpandInUsePersistentVolumes=true|false (BETA - 默认值=true)
    -ExpandPersistentVolumes=true|false (BETA - 默认值=true)
    +EphemeralContainers=true|false (BETA - 默认值=true)
    ExpandedDNSConfig=true|false (ALPHA - 默认值=false)
    ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 默认值=false)
    -GenericEphemeralVolume=true|false (BETA - 默认值=true)
    +GRPCContainerProbe=true|false (BETA - 默认值=true)
    GracefulNodeShutdown=true|false (BETA - 默认值=true)
    +GracefulNodeShutdownBasedOnPodPriority=true|false (BETA - 默认值=true)
    HPAContainerMetrics=true|false (ALPHA - 默认值=false)
    HPAScaleToZero=true|false (ALPHA - 默认值=false)
    -IPv6DualStack=true|false (BETA - 默认值=true)
    +HonorPVReclaimPolicy=true|false (ALPHA - 默认值=false)
    +IdentifyPodOS=true|false (BETA - 默认值=true)
    InTreePluginAWSUnregister=true|false (ALPHA - 默认值=false)
    InTreePluginAzureDiskUnregister=true|false (ALPHA - 默认值=false)
    InTreePluginAzureFileUnregister=true|false (ALPHA - 默认值=false)
    InTreePluginGCEUnregister=true|false (ALPHA - 默认值=false)
    InTreePluginOpenStackUnregister=true|false (ALPHA - 默认值=false)
    +InTreePluginPortworxUnregister=true|false (ALPHA - 默认值=false)
    +InTreePluginRBDUnregister=true|false (ALPHA - 默认值=false)
    InTreePluginvSphereUnregister=true|false (ALPHA - 默认值=false)
    -IndexedJob=true|false (BETA - 默认值=true)
    -IngressClassNamespacedParams=true|false (BETA - 默认值=true)
    -JobTrackingWithFinalizers=true|false (ALPHA - 默认值=false)
    -KubeletCredentialProviders=true|false (ALPHA - 默认值=false)
    +JobMutableNodeSchedulingDirectives=true|false (BETA - 默认值=true)
    +JobReadyPods=true|false (BETA - 默认值=true)
    +JobTrackingWithFinalizers=true|false (BETA - 默认值=false)
    +KubeletCredentialProviders=true|false (BETA - 默认值=true)
    KubeletInUserNamespace=true|false (ALPHA - 默认值=false)
    KubeletPodResources=true|false (BETA - 默认值=true)
    -KubeletPodResourcesGetAllocatable=true|false (ALPHA - 默认值=false)
    +KubeletPodResourcesGetAllocatable=true|false (BETA - 默认值=true)
    +LegacyServiceAccountTokenNoAutoGeneration=true|false (BETA - 默认值=true)
    LocalStorageCapacityIsolation=true|false (BETA - 默认值=true)
    LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值=false)
    LogarithmicScaleDown=true|false (BETA - 默认值=true)
    +MaxUnavailableStatefulSet=true|false (ALPHA - 默认值=false)
    MemoryManager=true|false (BETA - 默认值=true)
    MemoryQoS=true|false (ALPHA - 默认值=false)
    -MixedProtocolLBService=true|false (ALPHA - 默认值=false)
    +MinDomainsInPodTopologySpread=true|false (ALPHA - 默认值=false)
    +MixedProtocolLBService=true|false (BETA - 默认值=true)
    NetworkPolicyEndPort=true|false (BETA - 默认值=true)
    +NetworkPolicyStatus=true|false (ALPHA - 默认值=false)
    +NodeOutOfServiceVolumeDetach=true|false (ALPHA - 默认值=false)
    NodeSwap=true|false (ALPHA - 默认值=false)
    -NonPreemptingPriority=true|false (BETA - 默认值=true)
    -PodAffinityNamespaceSelector=true|false (BETA - 默认值=true)
    +OpenAPIEnums=true|false (BETA - 默认值=true)
    +OpenAPIV3=true|false (BETA - 默认值=true)
    +PodAndContainerStatsFromCRI=true|false (ALPHA - 默认值=false)
    PodDeletionCost=true|false (BETA - 默认值=true)
    -PodOverhead=true|false (BETA - 默认值=true)
    -PodSecurity=true|false (ALPHA - 默认值=false)
    -PreferNominatedNode=true|false (BETA - 默认值=true)
    +PodSecurity=true|false (BETA - 默认值=true)
    ProbeTerminationGracePeriod=true|false (BETA - 默认值=false)
    ProcMountType=true|false (ALPHA - 默认值=false)
    ProxyTerminatingEndpoints=true|false (ALPHA - 默认值=false)
    QOSReserved=true|false (ALPHA - 默认值=false)
    ReadWriteOncePod=true|false (ALPHA - 默认值=false)
    +RecoverVolumeExpansionFailure=true|false (ALPHA - 默认值=false)
    RemainingItemCount=true|false (BETA - 默认值=true)
    -RemoveSelfLink=true|false (BETA - 默认值=true)
    RotateKubeletServerCertificate=true|false (BETA - 默认值=true)
    SeccompDefault=true|false (ALPHA - 默认值=false)
    +ServerSideFieldValidation=true|false (ALPHA - 默认值=false)
    +ServiceIPStaticSubrange=true|false (ALPHA - 默认值=false)
    ServiceInternalTrafficPolicy=true|false (BETA - 默认值=true)
    -ServiceLBNodePortControl=true|false (BETA - 默认值=true)
    -ServiceLoadBalancerClass=true|false (BETA - 默认值=true)
    SizeMemoryBackedVolumes=true|false (BETA - 默认值=true)
    -StatefulSetMinReadySeconds=true|false (ALPHA - 默认值=false)
    +StatefulSetAutoDeletePVC=true|false (ALPHA - 默认值=false)
    +StatefulSetMinReadySeconds=true|false (BETA - 默认值=true)
    StorageVersionAPI=true|false (ALPHA - 默认值=false)
    StorageVersionHash=true|false (BETA - 默认值=true)
    -SuspendJob=true|false (BETA - 默认值=true)
    -TTLAfterFinished=true|false (BETA - 默认值=true)
    -TopologyAwareHints=true|false (ALPHA - 默认值=false)
    +TopologyAwareHints=true|false (BETA - 默认值=true)
    TopologyManager=true|false (BETA - 默认值=true)
    VolumeCapacityPriority=true|false (ALPHA - 默认值=false)
    WinDSR=true|false (ALPHA - 默认值=false)
    WinOverlay=true|false (BETA - 默认值=true)
    -WindowsHostProcessContainers=true|false (ALPHA - 默认值=false) +WindowsHostProcessContainers=true|false (BETA - 默认值=true) +如果配置文件由 --config 指定，则忽略此参数。

    @@ -463,13 +504,12 @@ WindowsHostProcessContainers=true|false (ALPHA - 默认值=false)     @@ -698,71 +738,6 @@ Path to kubeconfig file with authorization information (the master location is s - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - @@ -776,6 +751,19 @@ Comma-separated list of files to check for machine-id. Use the first one that ex

    +     + + + + + + @@ -809,13 +797,12 @@ Kubernetes API 服务器的地址（覆盖 kubeconfig 中的相关值）。 @@ -826,66 +813,84 @@ metrics 服务器要使用的 IP 地址和端口 - - - - - - - + + + + + + + + + + + + + + - + @@ -911,53 +916,18 @@ Range of host ports (beginPort-endPort, single port or beginPort+offset, inclusi - - - - - - - - - - - - - - - - - - - - - @@ -972,18 +942,6 @@ How long an idle UDP connection will be kept open (e.g. '250ms', '2s'). Must be - - - - - - - @@ -997,19 +955,6 @@ Print version information and quit - - - - - - - diff --git a/content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md b/content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md index dbb9eb3cfa..28fb4f2a61 100644 --- a/content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md +++ b/content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md @@ -2,7 +2,6 @@ title: kube-scheduler content_type: tool-reference weight: 30 -auto_generated: true --- Kubernetes 调度器是一个控制面进程，负责将 Pods 指派到节点上。 调度器基于约束和可用资源为调度队列中每个 Pod 确定其可合法放置的节点。 调度器之后对所有合法的节点进行排序，将 Pod 绑定到一个合适的节点。 在同一个集群中可以使用多个不同的调度器；kube-scheduler 是其参考实现。 -参阅[调度](/zh/docs/concepts/scheduling-eviction/) -以获得关于调度和 kube-scheduler 组件的更多信息。 +参阅[调度](/zh/docs/concepts/scheduling-eviction/)以获得关于调度和 +kube-scheduler 组件的更多信息。 ``` kube-scheduler [flags] @@ -44,71 +43,23 @@ kube-scheduler [flags] - - - - - - - - - - - - - - - - - - +默认值：[] - - - - - - - @@ -168,7 +119,7 @@ If true, failures to look up missing authentication configuration from the clust -在授权过程中跳过的 HTTP 路径列表，即在不联系 'core' kubernetes 服务器的情况下被授权的 HTTP 路径。 +在授权过程中跳过的 HTTP 路径列表，即在不联系 “core” kubernetes 服务器的情况下被授权的 HTTP 路径。 @@ -194,7 +145,7 @@ Kubernetes 核心服务器的 kubeconfig 文件。这是可选的。 -缓存来自 Webhook 授权者的 'authorized' 响应的持续时间。 +缓存来自 Webhook 授权者的 “authorized” 响应的持续时间。 @@ -206,7 +157,7 @@ The duration to cache 'authorized' responses from the webhook authorizer. -缓存来自 Webhook 授权者的 'unauthorized' 响应的持续时间。 +缓存来自 Webhook 授权者的 “unauthorized” 响应的持续时间。 @@ -232,7 +183,7 @@ The IP address on which to listen for the --secure-port port. The associated int --> 监听 --secure-port 端口的 IP 地址。 集群的其余部分以及 CLI/ Web 客户端必须可以访问关联的接口。 -如果为空，将使用所有接口（0.0.0.0 表示使用所有 IPv4 接口，"::" 表示使用所有 IPv6 接口）。 +如果为空，将使用所有接口（0.0.0.0 表示使用所有 IPv4 接口，“::” 表示使用所有 IPv6 接口）。 如果为空或未指定地址 (0.0.0.0 或 ::)，所有接口将被使用。 @@ -269,22 +220,14 @@ If set, any request presenting a client certificate signed by one of the authori - + - - - - - - @@ -334,213 +264,204 @@ APIListChunking=true|false (BETA - default=true)
    APIPriorityAndFairness=true|false (BETA - default=true)
    APIResponseCompression=true|false (BETA - default=true)
    APIServerIdentity=true|false (ALPHA - default=false)
    +APIServerTracing=true|false (ALPHA - default=false)
    AllAlpha=true|false (ALPHA - default=false)
    AllBeta=true|false (BETA - default=false)
    -AnyVolumeDataSource=true|false (ALPHA - default=false)
    +AnyVolumeDataSource=true|false (BETA - default=true)
    AppArmor=true|false (BETA - default=true)
    -BalanceAttachedNodeVolumes=true|false (ALPHA - default=false)
    -BoundServiceAccountTokenVolume=true|false (BETA - default=true)
    CPUManager=true|false (BETA - default=true)
    +CPUManagerPolicyAlphaOptions=true|false (ALPHA - default=false)
    +CPUManagerPolicyBetaOptions=true|false (BETA - default=true)
    +CPUManagerPolicyOptions=true|false (BETA - default=true)
    CSIInlineVolume=true|false (BETA - default=true)
    CSIMigration=true|false (BETA - default=true)
    CSIMigrationAWS=true|false (BETA - default=false)
    -CSIMigrationAzureDisk=true|false (BETA - default=false)
    CSIMigrationAzureFile=true|false (BETA - default=false)
    -CSIMigrationGCE=true|false (BETA - default=false)
    -CSIMigrationOpenStack=true|false (BETA - default=true)
    +CSIMigrationGCE=true|false (BETA - default=true)
    +CSIMigrationPortworx=true|false (ALPHA - default=false)
    +CSIMigrationRBD=true|false (ALPHA - default=false)
    CSIMigrationvSphere=true|false (BETA - default=false)
    -CSIMigrationvSphereComplete=true|false (BETA - default=false)
    -CSIServiceAccountToken=true|false (BETA - default=true)
    -CSIStorageCapacity=true|false (BETA - default=true)
    -CSIVolumeFSGroupPolicy=true|false (BETA - default=true)
    CSIVolumeHealth=true|false (ALPHA - default=false)
    -ConfigurableFSGroupPolicy=true|false (BETA - default=true)
    -ControllerManagerLeaderMigration=true|false (ALPHA - default=false)
    -CronJobControllerV2=true|false (BETA - default=true)
    +ContextualLogging=true|false (ALPHA - default=false)
    +CronJobTimeZone=true|false (ALPHA - default=false)
    CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)
    -DaemonSetUpdateSurge=true|false (ALPHA - default=false)
    -DefaultPodTopologySpread=true|false (BETA - default=true)
    +CustomResourceValidationExpressions=true|false (ALPHA - default=false)
    +DaemonSetUpdateSurge=true|false (BETA - default=true)
    +DelegateFSGroupToCSIDriver=true|false (BETA - default=true)
    DevicePlugins=true|false (BETA - default=true)
    DisableAcceleratorUsageMetrics=true|false (BETA - default=true)
    -DownwardAPIHugePages=true|false (BETA - default=false)
    -DynamicKubeletConfig=true|false (BETA - default=true)
    -EfficientWatchResumption=true|false (BETA - default=true)
    -EndpointSliceProxying=true|false (BETA - default=true)
    -EndpointSliceTerminatingCondition=true|false (ALPHA - default=false)
    -EphemeralContainers=true|false (ALPHA - default=false)
    -ExpandCSIVolumes=true|false (BETA - default=true)
    -ExpandInUsePersistentVolumes=true|false (BETA - default=true)
    -ExpandPersistentVolumes=true|false (BETA - default=true)
    +DisableCloudProviders=true|false (ALPHA - default=false)
    +DisableKubeletCloudCredentialProviders=true|false (ALPHA - default=false)
    +DownwardAPIHugePages=true|false (BETA - default=true)
    +EndpointSliceTerminatingCondition=true|false (BETA - default=true)
    +EphemeralContainers=true|false (BETA - default=true)
    +ExpandedDNSConfig=true|false (ALPHA - default=false)
    ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
    -GenericEphemeralVolume=true|false (BETA - default=true)
    +GRPCContainerProbe=true|false (BETA - default=true)
    GracefulNodeShutdown=true|false (BETA - default=true)
    +GracefulNodeShutdownBasedOnPodPriority=true|false (BETA - default=true)
    HPAContainerMetrics=true|false (ALPHA - default=false)
    HPAScaleToZero=true|false (ALPHA - default=false)
    -HugePageStorageMediumSize=true|false (BETA - default=true)
    -IPv6DualStack=true|false (BETA - default=true)
    +HonorPVReclaimPolicy=true|false (ALPHA - default=false)
    +IdentifyPodOS=true|false (BETA - default=true)
    InTreePluginAWSUnregister=true|false (ALPHA - default=false)
    InTreePluginAzureDiskUnregister=true|false (ALPHA - default=false)
    InTreePluginAzureFileUnregister=true|false (ALPHA - default=false)
    InTreePluginGCEUnregister=true|false (ALPHA - default=false)
    InTreePluginOpenStackUnregister=true|false (ALPHA - default=false)
    +InTreePluginPortworxUnregister=true|false (ALPHA - default=false)
    +InTreePluginRBDUnregister=true|false (ALPHA - default=false)
    InTreePluginvSphereUnregister=true|false (ALPHA - default=false)
    -IndexedJob=true|false (ALPHA - default=false)
    -IngressClassNamespacedParams=true|false (ALPHA - default=false)
    -KubeletCredentialProviders=true|false (ALPHA - default=false)
    +obMutableNodeSchedulingDirectives=true|false (BETA - default=true)
    +JobReadyPods=true|false (BETA - default=true)
    +JobTrackingWithFinalizers=true|false (BETA - default=false)
    +KubeletCredentialProviders=true|false (BETA - default=true)
    +KubeletInUserNamespace=true|false (ALPHA - default=false)
    KubeletPodResources=true|false (BETA - default=true)
    -KubeletPodResourcesGetAllocatable=true|false (ALPHA - default=false)
    +KubeletPodResourcesGetAllocatable=true|false (BETA - default=true)
    +LegacyServiceAccountTokenNoAutoGeneration=true|false (BETA - default=true)
    LocalStorageCapacityIsolation=true|false (BETA - default=true)
    LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)
    -LogarithmicScaleDown=true|false (ALPHA - default=false)
    -MemoryManager=true|false (ALPHA - default=false)
    -MixedProtocolLBService=true|false (ALPHA - default=false)
    -NamespaceDefaultLabelName=true|false (BETA - default=true)
    -NetworkPolicyEndPort=true|false (ALPHA - default=false)
    -NonPreemptingPriority=true|false (BETA - default=true)
    -PodAffinityNamespaceSelector=true|false (ALPHA - default=false)
    -PodDeletionCost=true|false (ALPHA - default=false)
    -PodOverhead=true|false (BETA - default=true)
    -PreferNominatedNode=true|false (ALPHA - default=false)
    -ProbeTerminationGracePeriod=true|false (ALPHA - default=false)
    +LogarithmicScaleDown=true|false (BETA - default=true)
    +MaxUnavailableStatefulSet=true|false (ALPHA - default=false)
    +MemoryManager=true|false (BETA - default=true)
    +MemoryQoS=true|false (ALPHA - default=false)
    +MinDomainsInPodTopologySpread=true|false (ALPHA - default=false)
    +MixedProtocolLBService=true|false (BETA - default=true)
    +NetworkPolicyEndPort=true|false (BETA - default=true)
    +NetworkPolicyStatus=true|false (ALPHA - default=false)
    +NodeOutOfServiceVolumeDetach=true|false (ALPHA - default=false)
    +NodeSwap=true|false (ALPHA - default=false)
    +OpenAPIEnums=true|false (BETA - default=true)
    +OpenAPIV3=true|false (BETA - default=true)
    +PodAndContainerStatsFromCRI=true|false (ALPHA - default=false)
    +PodDeletionCost=true|false (BETA - default=true)
    +PodSecurity=true|false (BETA - default=true)
    +ProbeTerminationGracePeriod=true|false (BETA - default=false)
    ProcMountType=true|false (ALPHA - default=false)
    +ProxyTerminatingEndpoints=true|false (ALPHA - default=false)
    QOSReserved=true|false (ALPHA - default=false)
    +ReadWriteOncePod=true|false (ALPHA - default=false)
    +RecoverVolumeExpansionFailure=true|false (ALPHA - default=false)
    RemainingItemCount=true|false (BETA - default=true)
    -RemoveSelfLink=true|false (BETA - default=true)
    RotateKubeletServerCertificate=true|false (BETA - default=true)
    -ServerSideApply=true|false (BETA - default=true)
    -ServiceInternalTrafficPolicy=true|false (ALPHA - default=false)
    -ServiceLBNodePortControl=true|false (ALPHA - default=false)
    -ServiceLoadBalancerClass=true|false (ALPHA - default=false)
    -ServiceTopology=true|false (ALPHA - default=false)
    -SetHostnameAsFQDN=true|false (BETA - default=true)
    -SizeMemoryBackedVolumes=true|false (ALPHA - default=false)
    +SeccompDefault=true|false (ALPHA - default=false)
    +ServerSideFieldValidation=true|false (ALPHA - default=false)
    +ServiceIPStaticSubrange=true|false (ALPHA - default=false)
    +ServiceInternalTrafficPolicy=true|false (BETA - default=true)
    +SizeMemoryBackedVolumes=true|false (BETA - default=true)
    +StatefulSetAutoDeletePVC=true|false (ALPHA - default=false)
    +StatefulSetMinReadySeconds=true|false (BETA - default=true)
    StorageVersionAPI=true|false (ALPHA - default=false)
    StorageVersionHash=true|false (BETA - default=true)
    -SuspendJob=true|false (ALPHA - default=false)
    -TTLAfterFinished=true|false (BETA - default=true)
    -TopologyAwareHints=true|false (ALPHA - default=false)
    +TopologyAwareHints=true|false (BETA - default=true)
    TopologyManager=true|false (BETA - default=true)
    -ValidateProxyRedirects=true|false (BETA - default=true)
    VolumeCapacityPriority=true|false (ALPHA - default=false)
    -WarningHeaders=true|false (BETA - default=true)
    WinDSR=true|false (ALPHA - default=false)
    WinOverlay=true|false (BETA - default=true)
    -WindowsEndpointSliceProxying=true|false (BETA - default=true) +WindowsHostProcessContainers=true|false (BETA - default=true) --> 一组 key=value 对，描述了 alpha/experimental 特征开关。选项包括：
    -A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:
    -APIListChunking=true|false (BETA - 默认值=true)
    -APIPriorityAndFairness=true|false (BETA - 默认值=true)
    -APIResponseCompression=true|false (BETA - 默认值=true)
    -APIServerIdentity=true|false (ALPHA - 默认值=false)
    -AllAlpha=true|false (ALPHA - 默认值=false)
    -AllBeta=true|false (BETA - 默认值=false)
    -AnyVolumeDataSource=true|false (ALPHA - 默认值=false)
    -AppArmor=true|false (BETA - 默认值=true)
    -BalanceAttachedNodeVolumes=true|false (ALPHA - 默认值=false)
    -BoundServiceAccountTokenVolume=true|false (BETA - 默认值=true)
    -CPUManager=true|false (BETA - 默认值=true)
    -CSIInlineVolume=true|false (BETA - 默认值=true)
    -CSIMigration=true|false (BETA - 默认值=true)
    -CSIMigrationAWS=true|false (BETA - 默认值=false)
    -CSIMigrationAzureDisk=true|false (BETA - 默认值=false)
    -CSIMigrationAzureFile=true|false (BETA - 默认值=false)
    -CSIMigrationGCE=true|false (BETA - 默认值=false)
    -CSIMigrationOpenStack=true|false (BETA - 默认值=true)
    -CSIMigrationvSphere=true|false (BETA - 默认值=false)
    -CSIMigrationvSphereComplete=true|false (BETA - 默认值=false)
    -CSIServiceAccountToken=true|false (BETA - 默认值=true)
    -CSIStorageCapacity=true|false (BETA - 默认值=true)
    -CSIVolumeFSGroupPolicy=true|false (BETA - 默认值=true)
    -CSIVolumeHealth=true|false (ALPHA - 默认值=false)
    -ConfigurableFSGroupPolicy=true|false (BETA - 默认值=true)
    -ControllerManagerLeaderMigration=true|false (ALPHA - 默认值=false)
    -CronJobControllerV2=true|false (BETA - 默认值=true)
    -CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值=false)
    -DaemonSetUpdateSurge=true|false (ALPHA - 默认值=false)
    -DefaultPodTopologySpread=true|false (BETA - 默认值=true)
    -DevicePlugins=true|false (BETA - 默认值=true)
    -DisableAcceleratorUsageMetrics=true|false (BETA - 默认值=true)
    -DownwardAPIHugePages=true|false (BETA - 默认值=false)
    -DynamicKubeletConfig=true|false (BETA - 默认值=true)
    -EfficientWatchResumption=true|false (BETA - 默认值=true)
    -EndpointSliceProxying=true|false (BETA - 默认值=true)
    -EndpointSliceTerminatingCondition=true|false (ALPHA - 默认值=false)
    -EphemeralContainers=true|false (ALPHA - 默认值=false)
    -ExpandCSIVolumes=true|false (BETA - 默认值=true)
    -ExpandInUsePersistentVolumes=true|false (BETA - 默认值=true)
    -ExpandPersistentVolumes=true|false (BETA - 默认值=true)
    -ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 默认值=false)
    -GenericEphemeralVolume=true|false (BETA - 默认值=true)
    -GracefulNodeShutdown=true|false (BETA - 默认值=true)
    -HPAContainerMetrics=true|false (ALPHA - 默认值=false)
    -HPAScaleToZero=true|false (ALPHA - 默认值=false)
    -HugePageStorageMediumSize=true|false (BETA - 默认值=true)
    -IPv6DualStack=true|false (BETA - 默认值=true)
    -InTreePluginAWSUnregister=true|false (ALPHA - 默认值=false)
    -InTreePluginAzureDiskUnregister=true|false (ALPHA - 默认值=false)
    -InTreePluginAzureFileUnregister=true|false (ALPHA - 默认值=false)
    -InTreePluginGCEUnregister=true|false (ALPHA - 默认值=false)
    -InTreePluginOpenStackUnregister=true|false (ALPHA - 默认值=false)
    -InTreePluginvSphereUnregister=true|false (ALPHA - 默认值=false)
    -IndexedJob=true|false (ALPHA - 默认值=false)
    -IngressClassNamespacedParams=true|false (ALPHA - 默认值=false)
    -KubeletCredentialProviders=true|false (ALPHA - 默认值=false)
    -KubeletPodResources=true|false (BETA - 默认值=true)
    -KubeletPodResourcesGetAllocatable=true|false (ALPHA - 默认值=false)
    -LocalStorageCapacityIsolation=true|false (BETA - 默认值=true)
    -LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值=false)
    -LogarithmicScaleDown=true|false (ALPHA - 默认值=false)
    -MemoryManager=true|false (ALPHA - 默认值=false)
    -MixedProtocolLBService=true|false (ALPHA - 默认值=false)
    -NamespaceDefaultLabelName=true|false (BETA - 默认值=true)
    -NetworkPolicyEndPort=true|false (ALPHA - 默认值=false)
    -NonPreemptingPriority=true|false (BETA - 默认值=true)
    -PodAffinityNamespaceSelector=true|false (ALPHA - 默认值=false)
    -PodDeletionCost=true|false (ALPHA - 默认值=false)
    -PodOverhead=true|false (BETA - 默认值=true)
    -PreferNominatedNode=true|false (ALPHA - 默认值=false)
    -ProbeTerminationGracePeriod=true|false (ALPHA - 默认值=false)
    -ProcMountType=true|false (ALPHA - 默认值=false)
    -QOSReserved=true|false (ALPHA - 默认值=false)
    -RemainingItemCount=true|false (BETA - 默认值=true)
    -RemoveSelfLink=true|false (BETA - 默认值=true)
    -RotateKubeletServerCertificate=true|false (BETA - 默认值=true)
    -ServerSideApply=true|false (BETA - 默认值=true)
    -ServiceInternalTrafficPolicy=true|false (ALPHA - 默认值=false)
    -ServiceLBNodePortControl=true|false (ALPHA - 默认值=false)
    -ServiceLoadBalancerClass=true|false (ALPHA - 默认值=false)
    -ServiceTopology=true|false (ALPHA - 默认值=false)
    -SetHostnameAsFQDN=true|false (BETA - 默认值=true)
    -SizeMemoryBackedVolumes=true|false (ALPHA - 默认值=false)
    -StorageVersionAPI=true|false (ALPHA - 默认值=false)
    -StorageVersionHash=true|false (BETA - 默认值=true)
    -SuspendJob=true|false (ALPHA - 默认值=false)
    -TTLAfterFinished=true|false (BETA - 默认值=true)
    -TopologyAwareHints=true|false (ALPHA - 默认值=false)
    -TopologyManager=true|false (BETA - 默认值=true)
    -ValidateProxyRedirects=true|false (BETA - 默认值=true)
    -VolumeCapacityPriority=true|false (ALPHA - 默认值=false)
    -WarningHeaders=true|false (BETA - 默认值=true)
    -WinDSR=true|false (ALPHA - 默认值=false)
    -WinOverlay=true|false (BETA - 默认值=true)
    -WindowsEndpointSliceProxying=true|false (BETA - 默认值=true) - -     - - - - - - @@ -595,7 +516,7 @@ DEPRECATED: content type of requests sent to apiserver. This parameter is ignore - + @@ -736,55 +656,6 @@ DEPRECATED: define the namespace of the lock object. Will be removed in favor of - - - - - - - - - - - - - - - - - - - - - - - - - - - @@ -804,19 +675,19 @@ Maximum number of seconds between log flushes @@ -845,18 +716,6 @@ Kubernetes API 服务器的地址（覆盖 kubeconfig 中的任何值）。 - - - - - - - @@ -868,7 +727,7 @@ If true, SO_REUSEADDR will be used when binding the port. This allows binding to 如果为 true，在绑定端口时将使用 SO_REUSEADDR。 这将允许同时绑定诸如 0.0.0.0 这类通配符 IP和特定 IP， 并且它避免等待内核释放处于 TIME_WAIT 状态的套接字。 -默认值： false +默认值：false @@ -881,69 +740,30 @@ If true, SO_REUSEADDR will be used when binding the port. This allows binding to If true, SO_REUSEPORT will be used when binding the port, which allows more than one instance to bind on the same address and port. [default=false] --> 如果此标志为 true，在绑定端口时会使用 SO_REUSEPORT，从而允许不止一个 -实例绑定到同一地址和端口。 +实例绑定到同一地址和端口。 默认值：false - + + - - - - - - - - - - - - - - - - - - - - - - + +默认值："x-remote-extra-" +默认值："x-remote-group" +默认值："x-remote-user" - - - - - - - @@ -1065,41 +870,6 @@ The previous version for which you want to show hidden metrics. Only the previou - - - - - - - - - - - - - - - - - - - - @@ -1109,7 +879,7 @@ logs at or above this threshold go to stderr -包含默认的 HTTPS x509 证书的文件。（CA证书（如果有）在服务器证书之后并置）。 +包含默认的 HTTPS x509 证书的文件。（如果有 CA 证书，在服务器证书之后并置）。 如果启用了 HTTPS 服务，并且未提供 --tls-cert-file 和 --tls-private-key-file，则会为公共地址生成一个自签名证书和密钥， 并将其保存到 --cert-dir 指定的目录中。 @@ -1174,20 +944,7 @@ A pair of x509 certificate and private key file paths, optionally suffixed with 如果未提供域名匹配模式，则提取证书名称。 非通配符匹配优先于通配符匹配，显式域名匹配优先于提取而来的名称。 若有多个密钥/证书对，可多次使用 --tls-sni-cert-key。 -例子: "example.crt,example.key" 或者 "foo.crt,foo.key:*.foo.com,foo.com"。 - - - - - - - - @@ -1216,14 +973,14 @@ Print version information and quit - + @@ -1235,7 +992,7 @@ comma-separated list of pattern=N settings for file-filtered logging -如果已设置，将配置值写入此文件并退出。 +如果设置此参数，将配置值写入此文件并退出。 @@ -1244,5 +1001,3 @@ If set, write the configuration values to this file and exit. - - diff --git a/content/zh/docs/reference/config-api/kubeadm-config.v1beta2.md b/content/zh/docs/reference/config-api/kubeadm-config.v1beta2.md index f34da9f473..bc37e362a7 100644 --- a/content/zh/docs/reference/config-api/kubeadm-config.v1beta2.md +++ b/content/zh/docs/reference/config-api/kubeadm-config.v1beta2.md @@ -292,7 +292,7 @@ https://godoc.org/k8s.io/kubelet/config/v1beta1#KubeletConfiguration。

    criSocket: "/var/run/dockershim.sock" taints: - key: "kubeadmNode" - value: "master" + value: "someValue" effect: "NoSchedule" kubeletExtraArgs: v: 4 @@ -1274,9 +1274,10 @@ cluster information.

    tlsBootstrapToken 是 TLS 启动引导过程中使用的令牌。 如果设置了 bootstrapToken，则此字段默认值为 .bootstrapToken.token， @@ -1783,29 +1784,28 @@ Defaults to the hostname of the node if not provided.

     @@ -58,9 +56,9 @@ FormatOptions 包含为不同类型日志格式提供的选项。 - [FormatOptions](#FormatOptions) -JSONOptions 包含用于 "json" 日志格式的选项。 +JSONOptions 包含用于 "json" 日志格式的选项。
    默认 ClusterRole 默认 ClusterRoleBinding
    system:auth-delegator无 - @@ -1251,8 +1499,8 @@ This is commonly used by add-on API servers for unified authentication and autho
    system:heapster无 @@ -1264,8 +1512,8 @@ Role for the Heapster compo
    system:kube-aggregator无
    system:kube-dns -在 kube-system 名字空间中的 kube-dns 服务账户在 kube-system 名字空间中的 kube-dns 服务账户 为 kube-dns 组件定义的角色。 -为 kube-dns 组件定义的角色。
    system:kubelet-api-admin无 - 允许 kubelet API 的完全访问权限。
    system:node-bootstrapper无 - @@ -1313,12 +1559,12 @@ Allows access to the resources required to perform
    system:node-problem-detector无 - 为 node-problem-detector 组件定义的角色。 @@ -1326,30 +1572,30 @@ Role for the node-
    system:persistent-volume-provisioner无 - 允许访问大部分 -动态卷驱动 - -所需要的资源。
    system:monitoringsystem:monitoring 组 @@ -1368,10 +1614,10 @@ Allows read access to control-plane monitoring endpoints The Kubernetes {{< glossary_tooltip term_id="kube-controller-manager" text="controller manager" >}} runs {{< glossary_tooltip term_id="controller" text="controllers" >}} that are built in to the Kubernetes control plane. -When invoked with `-use-service-account-credentials`, kube-controller-manager starts each controller +When invoked with `--use-service-account-credentials`, kube-controller-manager starts each controller using a separate service account. Corresponding roles exist for each built-in controller, prefixed with `system:controller:`. -If the controller manager is not started with `-use-service-account-credentials`, it runs all control loops +If the controller manager is not started with `--use-service-account-credentials`, it runs all control loops using its own credential, which must be granted all the relevant roles. These roles include: --> @@ -1379,12 +1625,12 @@ These roles include: Kubernetes {{< glossary_tooltip term_id="kube-controller-manager" text="控制器管理器" >}} 运行内建于 Kubernetes 控制面的{{< glossary_tooltip term_id="controller" text="控制器" >}}。 -当使用 `--use-service-account-credentials` 参数启动时, kube-controller-manager +当使用 `--use-service-account-credentials` 参数启动时，kube-controller-manager 使用单独的服务账户来启动每个控制器。 每个内置控制器都有相应的、前缀为 `system:controller:` 的角色。 如果控制管理器启动时未设置 `--use-service-account-credentials`， 它使用自己的身份凭据来运行所有的控制器，该身份必须被授予所有相关的角色。 -这些角色包括: +这些角色包括： * `system:controller:attachdetach-controller` * `system:controller:certificate-controller` @@ -1415,12 +1661,12 @@ Kubernetes {{< glossary_tooltip term_id="kube-controller-manager" text="控制 * `system:controller:ttl-controller` -## 初始化与预防权限提升 +## 初始化与预防权限提升 {#privilege-escalation-prevention-and-bootstrapping} RBAC API 会阻止用户通过编辑角色或者角色绑定来提升权限。 由于这一点是在 API 级别实现的，所以在 RBAC 鉴权组件未启用的状态下依然可以正常工作。 @@ -1434,7 +1680,7 @@ You can only create/update a role if at least one of the following things is tru (cluster-wide for a ClusterRole, within the same namespace or cluster-wide for a Role). 2. You are granted explicit permission to perform the `escalate` verb on the `roles` or `clusterroles` resource in the `rbac.authorization.k8s.io` API group. --> -### 对角色创建或更新的限制 +### 对角色创建或更新的限制 {#restrictions-on-role-creation-or-update} 只有在符合下列条件之一的情况下，你才能创建/更新角色: @@ -1470,7 +1716,7 @@ You can only create/update a role binding if you already have all the permission For example, if `user-1` does not have the ability to list Secrets cluster-wide, they cannot create a ClusterRoleBinding to a role that grants that permission. To allow a user to create/update role bindings: --> -### 对角色绑定创建或更新的限制 +### 对角色绑定创建或更新的限制 {#restrictions-on-role-binding-creation-or-update} 只有你已经具有了所引用的角色中包含的全部权限时，或者你被授权在所引用的角色上执行 `bind` 动词时，你才可以创建或更新角色绑定。这里的权限与角色绑定的作用域相同。 @@ -1495,6 +1741,37 @@ For example, this ClusterRole and RoleBinding would allow `user-1` to grant othe 例如，下面的 ClusterRole 和 RoleBinding 将允许用户 `user-1` 把名字空间 `user-1-namespace` 中的 `admin`、`edit` 和 `view` 角色赋予其他用户： + ```yaml apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRole @@ -1529,33 +1806,32 @@ subjects: When bootstrapping the first roles and role bindings, it is necessary for the initial user to grant permissions they do not yet have. To bootstrap initial roles and role bindings: -* Use a credential with the `system:masters` group, which is bound to the `cluster-admin` super-user role by the default bindings. -* If your API server runs with the insecure port enabled (`-insecure-port`), you can also make API calls via that port, which does not enforce authentication or authorization. +* Use a credential with the "system:masters" group, which is bound to the "cluster-admin" super-user role by the default bindings. +* If your API server runs with the insecure port enabled (`--insecure-port`), you can also make API calls via that port, which does not enforce authentication or authorization. --> 当启动引导第一个角色和角色绑定时，需要为初始用户授予他们尚未拥有的权限。 对初始角色和角色绑定进行初始化时需要： * 使用用户组为 `system:masters` 的凭据，该用户组由默认绑定关联到 `cluster-admin` 这个超级用户角色。 -* 如果你的 API 服务器启动时启用了不安全端口（使用 `--insecure-port`）, 你也可以通过 - 该端口调用 API ，这样的操作会绕过身份验证或鉴权。 +* 如果你的 API 服务器启动时启用了不安全端口（使用 `--insecure-port`），你也可以通过 + 该端口调用 API，这样的操作会绕过身份验证或鉴权。 +## 一些命令行工具 {#command-line-utilities} ### `kubectl create role` -Creates a `Role` object defining permissions within a single namespace. Examples: + -## 一些命令行工具 - -### `kubectl create role` - 创建 Role 对象，定义在某一名字空间中的权限。例如: -* 创建名称为 "pod-reader" 的 Role 对象，允许用户对 Pods 执行 `get`、`watch` 和 `list` 操作： +* 创建名称为 “pod-reader” 的 Role 对象，允许用户对 Pods 执行 `get`、`watch` 和 `list` 操作： ```shell kubectl create role pod-reader --verb=get --verb=list --verb=watch --resource=pods @@ -1564,16 +1840,16 @@ Creates a `Role` object defining permissions within a single namespace. Examples -* 创建名称为 "pod-reader" 的 Role 对象并指定 `resourceNames`： +* 创建名称为 “pod-reader” 的 Role 对象并指定 `resourceNames`： ```shell kubectl create role pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod ``` -* 创建名为 "foo" 的 Role 对象并指定 `apiGroups`： +* 创建名为 “foo” 的 Role 对象并指定 `apiGroups`： ```shell kubectl create role foo --verb=get,list,watch --resource=replicasets.apps @@ -1582,7 +1858,7 @@ Creates a `Role` object defining permissions within a single namespace. Examples -* 创建名为 "foo" 的 Role 对象并指定子资源权限: +* 创建名为 “foo” 的 Role 对象并指定子资源权限: ```shell kubectl create role foo --verb=get,list,watch --resource=pods,pods/status @@ -1591,7 +1867,7 @@ Creates a `Role` object defining permissions within a single namespace. Examples -* 创建名为 "my-component-lease-holder" 的 Role 对象，使其具有对特定名称的 +* 创建名为 “my-component-lease-holder” 的 Role 对象，使其具有对特定名称的 资源执行 get/update 的权限： ```shell @@ -1607,7 +1883,7 @@ Creates a ClusterRole. Examples: --> 创建 ClusterRole 对象。例如： -* 创建名称为 "pod-reader" 的 ClusterRole`对象，允许用户对 Pods 对象执行 `get`、 +* 创建名称为 “pod-reader” 的 ClusterRole 对象，允许用户对 Pods 对象执行 `get`、 `watch` 和 `list` 操作： ```shell @@ -1617,7 +1893,7 @@ Creates a ClusterRole. Examples: -* 创建名为 "pod-reader" 的 ClusterRole 对象并指定 `resourceNames`： +* 创建名为 “pod-reader” 的 ClusterRole 对象并指定 `resourceNames`： ```shell kubectl create clusterrole pod-reader --verb=get --resource=pods --resource-name=readablepod --resource-name=anotherpod @@ -1626,7 +1902,7 @@ Creates a ClusterRole. Examples: -* 创建名为 "foo" 的 ClusterRole 对象并指定 `apiGroups`： +* 创建名为 “foo” 的 ClusterRole 对象并指定 `apiGroups`： ```shell kubectl create clusterrole foo --verb=get,list,watch --resource=replicasets.apps @@ -1635,7 +1911,7 @@ Creates a ClusterRole. Examples: -* 创建名为 "foo" 的 ClusterRole 对象并指定子资源: +* 创建名为 “foo” 的 ClusterRole 对象并指定子资源: ```shell kubectl create clusterrole foo --verb=get,list,watch --resource=pods,pods/status @@ -1644,7 +1920,7 @@ Creates a ClusterRole. Examples: -* 创建名为 "foo" 的 ClusterRole 对象并指定 `nonResourceURL`： +* 创建名为 “foo” 的 ClusterRole 对象并指定 `nonResourceURL`： ```shell kubectl create clusterrole "foo" --verb=get --non-resource-url=/logs/* @@ -1653,7 +1929,7 @@ Creates a ClusterRole. Examples: -* 创建名为 "monitoring" 的 ClusterRole 对象并指定 `aggregationRule`： +* 创建名为 “monitoring” 的 ClusterRole 对象并指定 `aggregationRule`： ```shell kubectl create clusterrole monitoring --aggregation-rule="rbac.example.com/aggregate-to-monitoring=true" @@ -1668,7 +1944,7 @@ Grants a Role or ClusterRole within a specific namespace. Examples: --> 在特定的名字空间中对 `Role` 或 `ClusterRole` 授权。例如： -* 在名字空间 "acme" 中，将名为 `admin` 的 ClusterRole 中的权限授予名称 "bob" 的用户: +* 在名字空间 “acme” 中，将名为 `admin` 的 ClusterRole 中的权限授予名称 “bob” 的用户: ```shell kubectl create rolebinding bob-admin-binding --clusterrole=admin --user=bob --namespace=acme @@ -1677,7 +1953,7 @@ Grants a Role or ClusterRole within a specific namespace. Examples: -* 在名字空间 "acme" 中，将名为 `view` 的 ClusterRole 中的权限授予名字空间 "acme" +* 在名字空间 “acme” 中，将名为 `view` 的 ClusterRole 中的权限授予名字空间 “acme” 中名为 `myapp` 的服务账户： ```shell @@ -1687,8 +1963,8 @@ Grants a Role or ClusterRole within a specific namespace. Examples: -* 在名字空间 "acme" 中，将名为 `view` 的 ClusterRole 对象中的权限授予名字空间 - "myappnamespace" 中名称为 `myapp` 的服务账户： +* 在名字空间 “acme” 中，将名为 `view` 的 ClusterRole 对象中的权限授予名字空间 + “myappnamespace” 中名称为 `myapp` 的服务账户： ```shell kubectl create rolebinding myappnamespace-myapp-view-binding --clusterrole=view --serviceaccount=myappnamespace:myapp --namespace=acme @@ -1704,7 +1980,7 @@ Grants a ClusterRole across the entire cluster (all namespaces). Examples: 在整个集群（所有名字空间）中用 ClusterRole 授权。例如： * 在整个集群范围，将名为 `cluster-admin` 的 ClusterRole 中定义的权限授予名为 - "root" 用户： + “root” 用户： ```shell kubectl create clusterrolebinding root-cluster-admin-binding --clusterrole=cluster-admin --user=root @@ -1714,7 +1990,7 @@ Grants a ClusterRole across the entire cluster (all namespaces). Examples: * Across the entire cluster, grant the permissions in the "system:node-proxier" ClusterRole to a user named "system:kube-proxy": --> * 在整个集群范围内，将名为 `system:node-proxier` 的 ClusterRole 的权限授予名为 - "system:kube-proxy" 的用户： + “system:kube-proxy” 的用户： ```shell kubectl create clusterrolebinding kube-proxy-binding --clusterrole=system:node-proxier --user=system:kube-proxy @@ -1723,8 +1999,8 @@ Grants a ClusterRole across the entire cluster (all namespaces). Examples: -* 在整个集群范围内，将名为 `view` 的 ClusterRole 中定义的权限授予 "acme" 名字空间中 - 名为 "myapp" 的服务账户： +* 在整个集群范围内，将名为 `view` 的 ClusterRole 中定义的权限授予 “acme” 名字空间中 + 名为 “myapp” 的服务账户： ```shell kubectl create clusterrolebinding myapp-view-binding --clusterrole=view --serviceaccount=acme:myapp @@ -1762,7 +2038,7 @@ Examples: * 测试应用 RBAC 对象的清单文件，显示将要进行的更改： ```shell - kubectl auth reconcile -f my-rbac-rules.yaml --dry-run + kubectl auth reconcile -f my-rbac-rules.yaml --dry-run=client ``` -* 应用 RBAC 对象的清单文件, 删除角色中的额外权限和绑定中的其他主体： +* 应用 RBAC 对象的清单文件，删除角色中的额外权限和绑定中的其他主体： ```shell kubectl auth reconcile -f my-rbac-rules.yaml --remove-extra-subjects --remove-extra-permissions ``` -查看 CLI 帮助获取详细的用法。 - - ## 服务账户权限 {#service-account-permissions} @@ -1805,9 +2077,9 @@ Broader grants can give unnecessary (and potentially escalating) API access to s 但是不会对 `kube-system` 名字空间之外的服务账户授予权限。 （除了授予所有已认证用户的发现权限） -这使得你可以根据需要向特定服务账户授予特定权限。 +这使得你可以根据需要向特定 ServiceAccount 授予特定权限。 细粒度的角色绑定可带来更好的安全性，但需要更多精力管理。 -粗粒度的授权可能导致服务账户被授予不必要的 API 访问权限（甚至导致潜在的权限提升）， +粗粒度的授权可能导致 ServiceAccount 被授予不必要的 API 访问权限（甚至导致潜在的权限提升）， 但更易于管理。 这要求应用在其 Pod 规约中指定 `serviceAccountName`， - 并额外创建服务账户（包括通过 API、应用程序清单、`kubectl create serviceaccount` 等）。 + 并额外创建服务账户（包括通过 API、应用程序清单、`kubectl create serviceaccount` 等）。 - 例如，在名字空间 "my-namespace" 中授予服务账户 "my-sa" 只读权限： + 例如，在名字空间 “my-namespace” 中授予服务账户 “my-sa” 只读权限： ```shell kubectl create rolebinding my-sa-view \ @@ -1840,7 +2112,7 @@ In order from most secure to least secure, the approaches are: -2. 将角色授予某名字空间中的 "default" 服务账户 +2. 将角色授予某名字空间中的 “default” 服务账户 - 如果某应用没有指定 `serviceAccountName`，那么它将使用 "default" 服务账户。 + 如果某应用没有指定 `serviceAccountName`，那么它将使用 “default” 服务账户。 {{< note >}} "default" 服务账户所具有的权限会被授予给名字空间中所有未指定 @@ -1874,20 +2146,20 @@ In order from most secure to least secure, the approaches are: To allow those add-ons to run with super-user access, grant cluster-admin permissions to the "default" service account in the `kube-system` namespace. - {{< note >}} + {{< caution >}} Enabling this means the `kube-system` namespace contains Secrets - that grant super-user access to the API. - {{< /note >}} + that grant super-user access to your cluster's API. + {{< /caution >}} --> - 许多[插件组件](/zh/docs/concepts/cluster-administration/addons/) 在 `kube-system` - 名字空间以 "default" 服务账户运行。 + 许多[插件组件](/zh/docs/concepts/cluster-administration/addons/)在 `kube-system` + 名字空间以 “default” 服务账户运行。 要允许这些插件组件以超级用户权限运行，需要将集群的 `cluster-admin` 权限授予 - `kube-system` 名字空间中的 "default" 服务账户。 + `kube-system` 名字空间中的 “default” 服务账户。 - {{< note >}} - 启用这一配置意味着在 `kube-system` 名字空间中包含以超级用户账号来访问 API + {{< caution >}} + 启用这一配置意味着在 `kube-system` 名字空间中包含以超级用户账号来访问集群 API 的 Secrets。 - {{< /note >}} + {{< /caution >}} ```shell kubectl create clusterrolebinding add-on-cluster-admin \ @@ -1907,7 +2179,7 @@ In order from most secure to least secure, the approaches are: 如果你想要名字空间中所有应用都具有某角色，无论它们使用的什么服务账户， 可以将角色授予该名字空间的服务账户组。 - 例如，在名字空间 "my-namespace" 中的只读权限授予该名字空间中的所有服务账户： + 例如，在名字空间 “my-namespace” 中的只读权限授予该名字空间中的所有服务账户： ```shell kubectl create rolebinding serviceaccounts-view \ @@ -1949,7 +2221,7 @@ In order from most secure to least secure, the approaches are: --> 5. 授予超级用户访问权限给集群范围内的所有服务帐户（强烈不鼓励） - 如果你不关心如何区分权限，你可以将超级用户访问权限授予所有服务账户。 + 如果你不在乎如何区分权限，你可以将超级用户访问权限授予所有服务账户。 {{< warning >}} 这样做会允许所有应用都对你的集群拥有完全的访问权限，并将允许所有能够读取 @@ -1978,19 +2250,16 @@ guidance for restricting this access in existing clusters. If you want new clusters to retain this level of access in the aggregated roles, you can create the following ClusterRole: - -{{< codenew file="access/endpoints-aggregated.yaml" >}} --> ## Endpoints 写权限 {#write-access-for-endpoints} 在 Kubernetes v1.22 之前版本创建的集群里， -"edit" 和 "admin" 聚合角色包含对 Endpoints 的写权限。 +“edit” 和 “admin” 聚合角色包含对 Endpoints 的写权限。 作为 [CVE-2021-25740](https://github.com/kubernetes/kubernetes/issues/103675) 的缓解措施， 此访问权限不包含在 Kubernetes 1.22 以及更高版本集群的聚合角色里。 升级到 Kubernetes v1.22 版本的现有集群不会包括此变化。 -[CVE 公告](https://github.com/kubernetes/kubernetes/issues/103675) -包含了在现有集群里限制此访问权限的指引。 +[CVE 公告](https://github.com/kubernetes/kubernetes/issues/103675)包含了在现有集群里限制此访问权限的指引。 如果你希望在新集群的聚合角色里保留此访问权限，你可以创建下面的 ClusterRole： @@ -2010,7 +2279,7 @@ and controllers, but grant *no permissions* to service accounts outside the `kub While far more secure, this can be disruptive to existing workloads expecting to automatically receive API permissions. Here are two approaches for managing this transition: --> -## 从 ABAC 升级 +## 从 ABAC 升级 {#upgrading-from-abac} 原来运行较老版本 Kubernetes 的集群通常会使用限制宽松的 ABAC 策略， 包括授予所有服务帐户全权访问 API 的能力。 @@ -2023,19 +2292,19 @@ Here are two approaches for managing this transition: 这里有两种方法来完成这种转换: ### 并行鉴权 {#parallel-authorizers} -同时运行 RBAC 和 ABAC 鉴权模式, 并指定包含 +同时运行 RBAC 和 ABAC 鉴权模式，并指定包含 [现有的 ABAC 策略](/zh/docs/reference/access-authn-authz/abac/#policy-file-format) 的策略文件： ```shell ---authorization-mode=RBAC,ABAC --authorization-policy-file=mypolicy.json +--authorization-mode=...,RBAC,ABAC --authorization-policy-file=mypolicy.json ``` -如果 API 服务器启动时，RBAC 组件的日志级别为 5 或更高（`--vmodule=rbac*=5` 或 `--v=5`）， -你可以在 API 服务器的日志中看到 RBAC 的细节 （前缀 `RBAC:`） +如果 kube-apiserver 启动时，RBAC 组件的日志级别为 5 或更高（`--vmodule=rbac*=5` 或 `--v=5`）， +你可以在 API 服务器的日志中看到 RBAC 拒绝的细节（前缀 `RBAC`） 你可以使用这些信息来确定需要将哪些角色授予哪些用户、组或服务帐户。 -一旦你[将角色授予服务账户](#service-account-permissions) ，工作负载运行时 -在服务器日志中没有出现 RBAC 拒绝消息，就可以删除 ABAC 鉴权器。 +一旦你[将角色授予服务账户](#service-account-permissions)且工作负载运行时， +服务器日志中没有出现 RBAC 拒绝消息，就可以删除 ABAC 鉴权器。 ### 宽松的 RBAC 权限 {#permissive-rbac-permissions} -你可以使用 RBAC 角色绑定在多个场合使用宽松的策略。 +你可以使用 RBAC 角色绑定复制宽松的 ABAC 策略。 {{< warning >}} 在你完成到 RBAC 的迁移后，应该调整集群的访问控制，确保相关的策略满足你的信息安全需求。 - diff --git a/content/zh/docs/reference/access-authn-authz/webhook.md b/content/zh/docs/reference/access-authn-authz/webhook.md index 0ef1e6a18d..29032a7353 100644 --- a/content/zh/docs/reference/access-authn-authz/webhook.md +++ b/content/zh/docs/reference/access-authn-authz/webhook.md @@ -1,15 +1,9 @@ --- -reviewers: -- erictune -- lavalamp -- deads2k -- liggitt title: Webhook 模式 content_type: concept weight: 95 --- @@ -38,7 +31,7 @@ service when determining user privileges. -## 配置文件格式 +## 配置文件格式 {#configuration-file-format} -配置文件的格式使用 [kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)。在文件中，"users" 代表着 API 服务器的 webhook，而 "cluster" 代表着远程服务。 +配置文件的格式使用 [kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/)。 +在该文件中，“users” 代表着 API 服务器的 webhook，而 “cluster” 代表着远程服务。 -## 请求载荷 +## 请求载荷 {#request-payloads} -在做认证决策时，API 服务器会 POST 一个 JSON 序列化的 `authorization.k8s.io/v1beta1` `SubjectAccessReview` 对象来描述这个动作。这个对象包含了描述用户请求的字段，同时也包含了需要被访问资源或请求特征的具体信息。 +在做认证决策时，API 服务器会 POST 一个 JSON 序列化的 `authorization.k8s.io/v1beta1` `SubjectAccessReview` +对象来描述这个动作。这个对象包含了描述用户请求的字段，同时也包含了需要被访问资源或请求特征的具体信息。 -需要注意的是 webhook API 对象与其他 Kubernetes API 对象一样都同样都服从[版本兼容规则](/zh/docs/concepts/overview/kubernetes-api/)。实施人员应该了解 beta 对象的更宽松的兼容性承诺，同时确认请求的 "apiVersion" 字段能被正确地反序列化。此外，API 服务器还必须启用 `authorization.k8s.io/v1beta1` API 扩展组 (`--runtime-config=authorization.k8s.io/v1beta1=true`)。 +需要注意的是 webhook API 对象与其他 Kubernetes API 对象一样都同样都遵从[版本兼容规则](/zh/docs/concepts/overview/kubernetes-api/)。 +实施人员应该了解 beta 对象的更宽松的兼容性承诺，同时确认请求的 "apiVersion" 字段能被正确地反序列化。 +此外，API 服务器还必须启用 `authorization.k8s.io/v1beta1` API 扩展组 (`--runtime-config=authorization.k8s.io/v1beta1=true`)。 期待远程服务填充请求的 `status` 字段并响应允许或禁止访问。响应主体的 `spec` 字段被忽略，可以省略。允许的响应将返回: + ```json { "apiVersion": "authorization.k8s.io/v1beta1", @@ -195,7 +193,8 @@ authorizers are configured, they are given a chance to allow the request. If there are no other authorizers, or none of them allow the request, the request is forbidden. The webhook would return: --> -在大多数情况下，第一种方法是首选方法，它指示授权 webhook 不允许或对请求"无意见"，但是，如果配置了其他授权者，则可以给他们机会允许请求。如果没有其他授权者，或者没有一个授权者，则该请求被禁止。webhook 将返回: +在大多数情况下，第一种方法是首选方法，它指示授权 webhook 不允许或对请求 “无意见”。 +但是，如果配置了其他授权者，则可以给他们机会允许请求。如果没有其他授权者，或者没有一个授权者，则该请求被禁止。webhook 将返回： ```json { @@ -214,7 +213,7 @@ configured authorizers. This should only be used by webhooks that have detailed knowledge of the full authorizer configuration of the cluster. The webhook would return: --> -第二种方法立即拒绝其他配置的授权者进行短路评估。仅应由对集群的完整授权者配置有详细了解的 webhook 使用。webhook 将返回: +第二种方法立即拒绝其他配置的授权者进行短路评估。仅应由对集群的完整授权者配置有详细了解的 webhook 使用。webhook 将返回： ```json { @@ -252,16 +251,16 @@ Access to non-resource paths are sent as: ``` -非资源类的路径包括：`/api`, `/apis`, `/metrics`, `/resetMetrics`, -`/logs`, `/debug`, `/healthz`, `/swagger-ui/`, `/swaggerapi/`, `/ui`, 和 -`/version`。客户端需要访问 `/api`, `/api/*`, `/apis`, `/apis/*`, 和 `/version` 以便 +非资源类的路径包括：`/api`、`/apis`、`/metrics`、`/logs`、`/debug`、 +`/healthz`、`/livez`、`/openapi/v2`、`/readyz`、和 `/version`。 +客户端需要访问 `/api`、`/api/*`、`/apis`、`/apis/*` 和 `/version` 以便 能发现服务器上有什么资源和版本。对于其他非资源类的路径访问在没有 REST API 访问限制的情况下拒绝。 - `CSIVolumeFSGroupPolicy`：允许 CSIDrivers 使用 `fsGroupPolicy` 字段. 该字段能控制由 CSIDriver 创建的卷在挂载这些卷时是否支持卷所有权和权限修改。 @@ -1003,10 +1044,13 @@ Each feature gate is designed for enabling/disabling a specific feature: - `ConfigurableFSGroupPolicy`：在 Pod 中挂载卷时，允许用户为 fsGroup 配置卷访问权限和属主变更策略。请参见 [为 Pod 配置卷访问权限和属主变更策略](/zh/docs/tasks/configure-pod-container/security-context/#configure-volume-permission-and-ownership-change-policy-for-pods)。 +- `ContextualLogging`：当你启用这个特性门控，支持日志上下文记录的 Kubernetes + 组件会为日志输出添加额外的详细内容。 - `ControllerManagerLeaderMigration`：为 `kube-controller-manager` 和 `cloud-controller-manager` 开启领导者迁移功能。 - `CronJobControllerV2`：使用 {{< glossary_tooltip text="CronJob" term_id="cronjob" >}} 控制器的一种替代实现。否则，系统会选择同一控制器的 v1 版本。 +- `CronJobTimeZone`：允许在 [CronJobs](/zh/docs/concepts/workloads/controllers/cron-jobs/) 中使用 `timeZone` 可选字段。 -- `DynamicKubeletConfig`：启用 kubelet 的动态配置。请参阅 - [重新配置 kubelet](/zh/docs/tasks/administer-cluster/reconfigure-kubelet/)。 +- `DynamicKubeletConfig`：启用 kubelet 的动态配置。 + 除偏差策略场景外，不再支持该功能。该特性门控在 kubelet 1.24 版本中已被移除。 + 请参阅[重新配置 kubelet](/zh/docs/tasks/administer-cluster/reconfigure-kubelet/)。 - `DynamicProvisioningScheduling`：扩展默认调度器以了解卷拓扑并处理 PV 配置。 此特性已在 v1.12 中完全被 `VolumeScheduling` 特性取代。 - `DynamicVolumeProvisioning`：启用持久化卷到 Pod @@ -1221,6 +1267,9 @@ Each feature gate is designed for enabling/disabling a specific feature: when shutting down a node gracefully. - `GRPCContainerProbe`: Enables the gRPC probe method for {Liveness,Readiness,Startup}Probe. See [Configure Liveness, Readiness and Startup Probes](/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe). - `HonorPVReclaimPolicy`: Honor persistent volume reclaim policy when it is `Delete` irrespective of PV-PVC deletion ordering. +For more details, check the + [PersistentVolume deletion protection finalizer](/docs/concepts/storage/persistent-volumes/#persistentvolume-deletion-protection-finalizer) + documentation. --> - `GracefulNodeShutdownBasedOnPodPriority`：允许 kubelet 在体面终止节点时检查 Pod 的优先级。 @@ -1228,6 +1277,7 @@ Each feature gate is designed for enabling/disabling a specific feature: 参阅[配置活跃态、就绪态和启动探针](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)。 - `HonorPVReclaimPolicy`：无论 PV 和 PVC 的删除顺序如何，当持久卷申领的策略为 `Delete` 时，确保这种策略得到处理。 + 更多详细信息，请参阅 [PersistentVolume 删除保护 finalizer](/zh/docs/concepts/storage/persistent-volumes/#persistentvolume-deletion-protection-finalizer)文档。 - `KubeletPodResources`：启用 kubelet 上 Pod 资源 GRPC 端点。更多详细信息， 请参见[支持设备监控](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/compute-device-assignment.md)。 @@ -1370,6 +1422,8 @@ Each feature gate is designed for enabling/disabling a specific feature: - `LegacyNodeRoleBehavior`：禁用此门控时，服务负载均衡器中和节点干扰中的原先行为会忽略 `node-role.kubernetes.io/master` 标签，使用 `NodeDisruptionExclusion` 和 `ServiceNodeExclusion` 对应特性所提供的标签。 +- `LegacyServiceAccountTokenNoAutoGeneration`：停止基于 Secret 的自动生成 + [服务账号令牌](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens). - `LogarithmicScaleDown`：启用 Pod 的半随机（semi-random）选择，控制器将根据 Pod 时间戳的对数桶按比例缩小去驱逐 Pod。 -- `MemoryManager`: 允许基于 NUMA 拓扑为容器设置内存亲和性。 -- `MemoryQoS`: 使用 cgroup v2 内存控制器在 pod / 容器上启用内存保护和使用限制。 +- `MaxUnavailableStatefulSet`：启用为 StatefulSet + 的[滚动更新策略](/zh/docs/concepts/workloads/controllers/statefulset/#rolling-updates)设置 + `maxUnavailable` 字段。该字段指定更新过程中不可用 Pod 个数的上限。 +- `MemoryManager`：允许基于 NUMA 拓扑为容器设置内存亲和性。 +- `MemoryQoS`：使用 cgroup v2 内存控制器在 pod / 容器上启用内存保护和使用限制。 +- `MinDomainsInPodTopologySpread`：启用 Pod 的 `minDomains` + [拓扑分布约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/). - `MixedProtocolLBService`：允许在同一 `LoadBalancer` 类型的 Service 实例中使用不同的协议。 - `MountContainers`：允许使用主机上的工具容器作为卷挂载程序。 +- `NodeOutOfServiceVolumeDetach`：当使用 `node.kubernetes.io/out-of-service` + 污点将节点标记为停止服务时，节点上不能容忍这个污点的 Pod 将被强制删除， + 并且该在节点上被终止的 Pod 将立即进行卷分离操作。 - `NodeSwap`: 启用 kubelet 为节点上的 Kubernetes 工作负载分配交换内存的能力。 必须将 `KubeletConfiguration.failSwapOn` 设置为 false 的情况下才能使用。 更多详细信息，请参见[交换内存](/zh/docs/concepts/architecture/nodes/#swap-memory)。 @@ -1524,8 +1600,10 @@ Each feature gate is designed for enabling/disabling a specific feature: - `RemainingItemCount`: Allow the API servers to show a count of remaining items in the response to a [chunking list request](/docs/reference/using-api/api-concepts/#retrieving-large-results-sets-in-chunks). -- `RemoveSelfLink`: Deprecates and removes `selfLink` from ObjectMeta and - ListMeta. +- `RemoveSelfLink`: Sets the `.metadata.selfLink` field to blank (empty string) for all + objects and collections. This field has been deprecated since the Kubernetes v1.16 + release. When this feature is enabled, the `.metadata.selfLink` field remains part of + the Kubernetes API, but is always unset. - `RequestManagement`: Enables managing request concurrency with prioritization and fairness at each API server. Deprecated by `APIPriorityAndFairness` since 1.17. --> @@ -1535,7 +1613,9 @@ Each feature gate is designed for enabling/disabling a specific feature: - `RemainingItemCount`：允许 API 服务器在 [分块列表请求](/zh/docs/reference/using-api/api-concepts/#retrieving-large-results-sets-in-chunks) 的响应中显示剩余条目的个数。 -- `RemoveSelfLink`：将 ObjectMeta 和 ListMeta 中的 `selfLink` 字段废弃并删除。 +- `RemoveSelfLink`：将所有对象和集合的 `.metadata.selfLink` 字段设置为空（空字符串）。 + 该字段自 Kubernetes v1.16 版本以来已被弃用。 + 启用此功能后，`.metadata.selfLink` 字段仍然是 Kubernetes API 的一部分，但始终未设置。 - `RequestManagement`：允许在每个 API 服务器上通过优先级和公平性管理请求并发性。 自 1.17 以来已被 `APIPriorityAndFairness` 替代。 - `ServiceLoadBalancerClass`: 为服务启用 `loadBalancerClass` 字段。 有关更多信息，请参见[指定负载均衡器实现类](/zh/docs/concepts/services-networking/service/#load-balancer-class)。 @@ -1636,6 +1722,9 @@ Each feature gate is designed for enabling/disabling a specific feature: 标签，则可以排除该节点。 - `ServiceTopology`：启用服务拓扑可以让一个服务基于集群的节点拓扑进行流量路由。 有关更多详细信息，请参见[服务拓扑](/zh/docs/concepts/services-networking/service-topology/)。 +- `ServiceIPStaticSubrange`：启用服务 ClusterIP 分配策略，从而细分 ClusterIP 范围。 + 动态分配的 ClusterIP 地址将优先从较高范围分配，以低冲突风险允许用户从较低范围分配静态 ClusterIP。 + 更多详细信息请参阅[避免冲突](/zh/docs/concepts/services-networking/service/#avoiding-collisions) * Kubernetes 的[弃用策略](/zh/docs/reference/using-api/deprecation-policy/) 介绍了项目针对已移除特性和组件的处理方法。 - +* 从 Kubernetes 1.24 开始，默认不启用新的 beta API。 + 启用 beta 功能时，还需要启用所有关联的 API 资源。 + 例如：要启用一个特定资源，如 `storage.k8s.io/v1beta1/csistoragecapacities`， + 请设置 `--runtime-config=storage.k8s.io/v1beta1/csistoragecapacities`。 + 有关命令行标志的更多详细信息，请参阅 [API 版本控制](/zh/docs/reference/using-api/#api-versioning)。 diff --git a/content/zh/docs/reference/command-line-tools-reference/kube-apiserver.md b/content/zh/docs/reference/command-line-tools-reference/kube-apiserver.md index ec1b496b42..26bef87ba7 100644 --- a/content/zh/docs/reference/command-line-tools-reference/kube-apiserver.md +++ b/content/zh/docs/reference/command-line-tools-reference/kube-apiserver.md @@ -84,7 +84,7 @@ the host's default interface will be used. The map from metric-label to value allow-list of this label. The key's format is <MetricName>,<LabelName>. The value's format is <allowed_value>,<allowed_value>...e.g. metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'. --> 允许使用的指标标签到指标值的映射列表。键的格式为 <MetricName>,<LabelName>. -值的格式为 <allowed_value>,<allowed_value>...。 +值的格式为 <allowed_value>,<allowed_value>...。 例如：metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'。

    --delete-collection-workers int     默认值： 1--delete-collection-workers int     默认值：1
    @@ -1363,10 +1363,10 @@ Max is .02 (1/50 requests); .001 (1/1000) is a recommended starting point. --> 为防止 HTTP/2 客户端卡在单个 API 服务器上，可启用随机关闭连接（GOAWAY）。 客户端的其他运行中请求将不会受到影响，并且客户端将重新连接， -可能会在再次通过负载平衡器后登陆到其他 API 服务器上。 -此参数设置将发送 GOAWAY 的请求的比例。 -具有单个 API 服务器或不使用负载平衡器的群集不应启用此功能。 -最小值为0（关闭），最大值为 .02（1/50 请求）； 建议使用 .001（1/1000）。 +可能会在再次通过负载平衡器后登陆到其他 API 服务器上。 +此参数设置将发送 GOAWAY 的请求的比例。 +具有单个 API 服务器或不使用负载平衡器的集群不应启用此功能。 +最小值为0（关闭），最大值为 .02（1/50 请求）；建议使用 .001（1/1000）。
    --tls-sni-cert-key string     默认值： []--tls-sni-cert-key string     默认值：[]
    diff --git a/content/zh/docs/reference/command-line-tools-reference/kube-controller-manager.md b/content/zh/docs/reference/command-line-tools-reference/kube-controller-manager.md index 4580ad21ca..69d31090b9 100644 --- a/content/zh/docs/reference/command-line-tools-reference/kube-controller-manager.md +++ b/content/zh/docs/reference/command-line-tools-reference/kube-controller-manager.md @@ -48,18 +48,6 @@ kube-controller-manager [flags]
    --add-dir-header
    - -若为 true，将文件目录添加到日志消息的头部。 -
    --allocate-node-cidrs
    --allow-metric-labels stringToString     默认值：""--allow-metric-labels stringToString     默认值：[]

    @@ -89,18 +77,6 @@ metric2,label='v1,v2,v3'。

    --alsologtostderr
    - -在向文件输出日志的同时，也将日志写到标准输出。 -
    --attach-detach-reconcile-sync-period duration     默认值：1m0s
    --bind-address ip     默认值：0.0.0.0--bind-address string     默认值：0.0.0.0
    @@ -511,6 +487,19 @@ The number of endpoint syncing operations that will be done concurrently. Larger
    --concurrent-ephemeralvolume-syncs int32     默认值：5
    + +可以并发执行的 EphemeralVolume 同步操作个数。数值越大意味着更快的 EphemeralVolume 更新操作， +同时也意味着更大的 CPU （和网络）压力。 +
    --concurrent-gc-syncs int32     默认值：20
    --controllers strings     默认值：[*]--controllers strings     默认值：*
    @@ -690,18 +679,6 @@ A list of controllers to enable. '*' enables all on-by-default controllers, 'foo 默认禁用的控制器有：bootstrapsigner 和 tokencleaner。
    --deployment-controller-sync-period duration     默认值：30s
    - -Deployment 资源的同步周期。 -
    --disable-attach-detach-reconcile-sync
    --experimental-logging-sanitization
    - -[试验性功能] 当启用此标志时，被标记为敏感的字段（密码、密钥、令牌）不会被日志输出。
    -运行时的日志清理操作可能会引入相当程度的计算开销，因此不应在生产环境中启用。 -
    --external-cloud-volume-plugin string
    --kube-api-qps float32     默认值：20--kube-api-qps float     默认值：20
    @@ -1267,10 +1237,10 @@ The interval between attempts by the acting master to renew a leadership slot be
    -在领导者选举期间用于锁定的资源对象的类型。 支持的选项为 "endpoints"、 -"configmaps"、"leases"、"endpointsleases" 和 "configmapsleases"。 +在领导者选举期间用于锁定的资源对象的类型。 支持的选项为 +"leases"、"endpointsleases" 和 "configmapsleases"。
    --log-backtrace-at traceLocation     默认值：:0
    - -当执行到 file:N 所给的文件和代码行时，日志机制会生成一个调用栈快照。 -
    --log-dir string
    - -此标志为非空字符串时，日志文件会写入到所给的目录中。 -
    --log-file string
    - -此标志为非空字符串时，意味着日志会写入到所给的文件中。 -
    --log-file-max-size uint     默认值：1800
    - -定义日志文件大小的上限。单位是兆字节（MB）。 -若此值为 0，则不对日志文件尺寸进行约束。 -
    --log-flush-frequency duration     默认值：5s
    -设置日志格式。允许的格式："text"。 +设置日志格式。允许的格式："text"。
    非默认格式不支持以下标志：--add-dir-header、 ---alsologtostderr》、--log-backtrace-at、 +--alsologtostderr、--log-backtrace-at、 --log-dir、--log-file、--log-file-max-size、 --logtostderr、--one-output、--skip-headers、 --skip-log-headers、--stderrthreshold、 ---vmodule、--log-flush-frequency。 +--vmodule。
    当前非默认选项为 Alpha 阶段，如有更改，恕不另行通知。
    --logtostderr     默认值：true
    - -将日志写出到标准错误输出（stderr）而不是写入到日志文件。 -
    --master string
    EndpointSliceMirroring 控制器将添加到 EndpointSlice 的最大端点数。 -每个分片的端点越多，端点分片越少，但资源越大。 +每个分片的端点越多，端点分片越少，但资源越大。默认为 100。
    --node-eviction-rate float32     默认值：0.1--node-eviction-rate float     默认值：0.1
    @@ -1601,29 +1509,17 @@ Amount of time which we allow starting Node to be unresponsive before marking it
    --one-output
    - -如果此标志为 true，则仅将日志写入其自身的严重性级别（而不是同时写入更低的严重性级别中）。 -
    --permit-address-sharing

    如果此标志为 true，则在绑定端口时使用 SO_REUSEADDR。 这就意味着可以同时绑定到 0.0.0.0 和特定的 IP 地址， -并且避免等待内核释放处于 TIME_WAITE 状态的套接字。 +并且避免等待内核释放处于 TIME_WAITE 状态的套接字。[默认值=false]。

    对 NFS 卷执行回收利用时，用作模版的 Pod 定义文件所在路径。
    +List of client certificate common names to allow to provide usernames in headers specified by --requestheader-username-headers. If empty, any client certificate validated by the authorities in --requestheader-client-ca-file is allowed. +--> 标志值是客户端证书中的 Common Names 列表。其中所列的名称可以通过 --requestheader-username-headers 所设置的 HTTP 头部来提供用户名。 如果此标志值为空表，则被 --requestheader-client-ca-file @@ -1921,42 +1818,6 @@ The previous version for which you want to show hidden metrics. Only the previou
    --skip-headers
    - -若此标志为 true，则在日志消息中避免写入头部前缀信息。 -
    --skip-log-headers
    - -若此标志为 true，则在写入日志文件时避免写入头部信息。 -
    --stderrthreshold severity     默认值：2
    - -等于或大于此阈值的日志信息会被写入到标准错误输出（stderr）。 -
    --terminated-pod-gc-threshold int32     默认值：12500
    供服务器使用的加密包的逗号分隔列表。若忽略此标志，则使用 Go 语言默认的加密包。
    -可选值包括：TLS_AES_128_GCM_SHA256、TLS_AES_256_GCM_SHA384、TLS_CHACHA20_POLY1305_SHA256、TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA、TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256、TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA、TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384、TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305、TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256、TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256、TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384、TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305、TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256、TLS_RSA_WITH_3DES_EDE_CBC_SHA、TLS_RSA_WITH_AES_128_CBC_SHA、TLS_RSA_WITH_AES_128_GCM_SHA256、TLS_RSA_WITH_AES_256_CBC_SHA、TLS_RSA_WITH_AES_256_GCM_SHA384. -
    不安全的值: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256、TLS_ECDHE_ECDSA_WITH_RC4_128_SHA、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256、TLS_ECDHE_RSA_WITH_RC4_128_SHA、TLS_RSA_WITH_AES_128_CBC_SHA256、TLS_RSA_WITH_RC4_128_SHA +可选值包括：TLS_AES_128_GCM_SHA256、TLS_AES_256_GCM_SHA384、TLS_CHACHA20_POLY1305_SHA256、TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA、TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256、TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA、TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384、TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305、TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256、TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384、TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305、TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256、TLS_RSA_WITH_AES_128_CBC_SHA、TLS_RSA_WITH_AES_128_GCM_SHA256、TLS_RSA_WITH_AES_256_CBC_SHA、TLS_RSA_WITH_AES_256_GCM_SHA384。 +
    不安全的值: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256、TLS_ECDHE_ECDSA_WITH_RC4_128_SHA、TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA、TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256、TLS_ECDHE_RSA_WITH_RC4_128_SHA、TLS_RSA_WITH_3DES_EDE_CBC_SHA、TLS_RSA_WITH_AES_128_CBC_SHA256、TLS_RSA_WITH_RC4_128_SHA。
    --tls-sni-cert-key namedCertKey     默认值：[]--tls-sni-cert-key string
    X509 证书和私钥文件路径的耦对。作为可选项，可以添加域名模式的列表， 其中每个域名模式都是可以带通配片段前缀的全限定域名（FQDN）。 @@ -2092,14 +1953,14 @@ Print version information and quit
    --vmodule <逗号分隔的 'pattern=N' 配置值>--vmodule pattern=N,...
    -由逗号分隔的列表，每一项都是 pattern=N 格式，用来执行根据文件过滤的日志行为。 +由逗号分隔的列表，每一项都是 pattern=N 格式，用来执行根据文件过滤的日志行为（仅适用于 text 日志格式）。
    --add-dir-header

    - -若此标志为 true，则将文件目录添加到日志消息的头部。 -

    --alsologtostderr

    - -将日志输出到文件时也输出到标准错误输出（stderr）。 -

    --azure-container-registry-config string

    代理服务器要使用的 IP 地址（设置为 '0.0.0.0' 表示要使用所有 IPv4 接口； 设置为 '::' 表示使用所有 IPv6 接口）。 +如果配置文件由 --config 指定，则忽略此参数。

    --cloud-provider-gce-l7lb-src-cidrs cidrs     默认值：130.211.0.0/22,35.191.0.0/16
    + +此值表示，在 GCE 防火墙中打开 CIDRs 用于 L7 LB 流量代理 & 健康检查。 +
    --cloud-provider-gce-lb-src-cidrs cidrs     默认值：130.211.0.0/22,209.85.152.0/22,209.85.204.0/22,35.191.0.0/16
    + +此值表示，在 GCE 防火墙中打开 CIDRs 用于 L4 LB 流量代理 & 健康检查。 +
    --cluster-cidr string

    集群中 Pod 的 CIDR 范围。配置后，将从该范围之外发送到服务集群 IP -的流量被伪装，从 Pod 发送到外部 LoadBalancer IP 的流量将被重定向 -到相应的集群 IP。 +的流量被伪装，从 Pod 发送到外部 LoadBalancer IP +的流量将被重定向到相应的集群 IP。 +对于双协议栈集群，接受一个逗号分隔的列表， +每个 IP 协议族（IPv4 和 IPv6）至少包含一个 CIDR。 +如果配置文件由 --config 指定，则忽略此参数。

    --default-not-ready-toleration-seconds int     默认值：300
    + +对污点 NotReady:NoExecute 的容忍时长（以秒计）。 +默认情况下这一容忍度会被添加到尚未具有此容忍度的每个 pod 中。 +
    --default-unreachable-toleration-seconds int     默认值：300
    + +对污点 Unreachable:NoExecute 的容忍时长（以秒计） +默认情况下这一容忍度会被添加到尚未具有此容忍度的每个 pod 中。 +
    --detect-local-mode LocalMode

    - + 用于检测本地流量的模式。 +如果配置文件由 --config 指定，则忽略此参数。

    服务健康状态检查的 IP 地址和端口（设置为 '0.0.0.0:10256' 表示使用所有 IPv4 接口，设置为 '[::]:10256' 表示使用所有 IPv6 接口）； 设置为空则禁用。 +如果配置文件由 --config 指定，则忽略此参数。

    --log-backtrace-at <形式为 'file:N' 的字符串>     Default: :0

    - -当日志逻辑执行到文件 file 的第 N 行时，输出调用堆栈跟踪。 -

    --log-dir string

    - -若此标志费控，则将日志文件写入到此标志所给的目录下。 -

    -
    --log-file string

    - -若此标志非空，则该字符串作为日志文件名。 -

    --log-file-max-size uint     默认值：1800

    - -定义日志文件可增长到的最大尺寸。单位是兆字节（MB）。 -如果此值为 0，则最大文件大小无限制。 -

    --log-flush-frequency duration     默认值：5s -
    - -两次日志刷新之间的最大秒数。 -
    --machine-id-file string     默认值："/etc/machine-id,/var/lib/dbus/machine-id"
    --machine_id_file string     默认值："/etc/machine-id,/var/lib/dbus/machine-id"

    + +用来检查 Machine-ID 的文件列表，用逗号分隔。 +使用找到的第一个文件。 +

    --masquerade-all

    metrics 服务器要使用的 IP 地址和端口 （设置为 '0.0.0.0:10249' 则使用所有 IPv4 接口，设置为 '[::]:10249' 则使用所有 IPv6 接口） 设置为空则禁用。 +如果配置文件由 --config 指定，则忽略此参数。

    一个字符串值，指定用于 NodePort 服务的地址。 值可以是有效的 IP 块（例如 1.2.3.0/24, 1.2.3.4/32）。 默认的空字符串切片（[]）表示使用所有本地地址。 +如果配置文件由 --config 指定，则忽略此参数。

    --one-output

    - -若此标志为 true，则仅将日志写入到其原本的严重性级别之下 -（而不是将其写入到所有更低严重性级别中）。 -

    --oom-score-adj int32     默认值：-999

    kube-proxy 进程中的 oom-score-adj 值，必须在 [-1000,1000] 范围内。 +如果配置文件由 --config 指定，则忽略此参数。

    --pod-bridge-interface string
    + +集群中的一个桥接接口名称。 +Kube-proxy 将来自与该值匹配的桥接接口的流量视为本地流量。 +如果 DetectLocalMode 设置为 BridgeInterface，则应设置该参数。 +
    --pod-interface-name-prefix string
    + +集群中的一个接口前缀。 +Kube-proxy 将来自与给定前缀匹配的接口的流量视为本地流量。 +如果 DetectLocalMode 设置为 InterfaceNamePrefix，则应设置该参数。 +
    --profiling

    如果为 true，则通过 Web 接口 /debug/pprof 启用性能分析。 +如果配置文件由 --config 指定，则忽略此参数。

    --proxy-mode string--proxy-mode ProxyMode

    -使用哪种代理模式：'userspace'（较旧）或 'iptables'（较快）或 'ipvs'。 -如果为空，使用最佳可用代理（当前为 iptables）。 -如果选择了 iptables 代理（无论是否为显式设置），但系统的内核或 -iptables 版本较低，总是会回退到 userspace 代理。 +使用哪种代理模式：'iptables'（仅 Linux）、'ipvs'（仅 Linux）、'kernelspace'（仅 Linux） +或者 'userspace'（Linux/Windows, 已弃用）。 +Linux 系统上的默认值是 'iptables'，Windows 系统上的默认值是 'userspace'。 +如果配置文件由 --config 指定，则忽略此参数。

    要显示隐藏指标的先前版本。 仅先前的次要版本有意义，不允许其他值。 格式为 <major>.<minor> ，例如：'1.16'。 这种格式的目的是确保你有机会注意到下一个发行版是否隐藏了其他指标， 而不是在之后将其永久删除时感到惊讶。 +如果配置文件由 --config 指定，则忽略此参数。

    --skip-headers

    - -若此标志为 true，则避免在日志消息中包含头部前缀。 -

    --skip-log-headers

    - -如果此标志为 true，则避免在打开日志文件时使用头部。 -

    --stderrthreshold int     默认值：2

    - -如果日志消息处于或者高于此阈值所设置的级别，则将其输出到标准错误输出（stderr）。 -

    --udp-timeout duration     默认值：250ms
    -v, --v int

    - -用来设置日志详细程度的数值。 -

    --version version[=true]
    --vmodule <逗号分隔的 'pattern=N' 设置’>

    - -用逗号分隔的列表，其中每一项为 'pattern=N' 格式。 -用来支持基于文件过滤的日志机制。 -

    --write-config-to string
    --add-dir-header
    - -如果为 true，则将文件目录添加到日志消息的头部 -
    --address string     默认值："0.0.0.0"
    - -已弃用： 要监听 --port 端口的 IP 地址（将其设置为 0.0.0.0 或者 :: 用于监听所有接口和 IP族）。 -请参阅 --bind-address。 -如果在 --config 中指定了一个配置文件，这个参数将被忽略。 -
    --algorithm-provider string
    - -已弃用： 要使用的调度算法驱动，此标志设置组件配置框架的默认插件。 -可选值：ClusterAutoscalerProvider | DefaultProvider -
    --allow-metric-labels stringToString      -默认值： []
    -这个键值映射表设置 度量标签 所允许设置的值。 +这个键值映射表设置度量标签所允许设置的值。 其中键的格式是 <MetricName>,<LabelName>。 值的格式是 <allowed_value>,<allowed_value>。 例如：metric1,label1='v1,v2,v3', metric1,label2='v1,v2,v3' metric2,label1='v1,v2,v3'。
    --alsologtostderr
    - -日志记录到标准错误以及文件 -
    --authentication-kubeconfig string
    -配置文件的路径。以下标志会覆盖此文件中的值：
    ---algorithm-provider
    ---policy-config-file
    ---policy-configmap
    ---policy-configmap-namespace +配置文件的路径。
    --contention-profiling     默认值: true--contention-profiling     默认值：true
    @@ -309,19 +252,6 @@ This flag provides an escape hatch for misbehaving metrics. You must provide the
    --experimental-logging-sanitization
    - -[试验性功能] 当启用此标志时，标记为敏感的字段（密码、密钥、令牌）等不会被日志 -输出。
    -运行时的日志清理操作可能引入相当程度的计算开销，因此不应在生产环境中启用。 -
    --feature-gates <逗号分隔的 'key=True|False' 对>
    --hard-pod-affinity-symmetric-weight int32     默认值：1
    - -已弃用: RequiredDuringScheduling 亲和性是不对称的，但是存在与每个 -RequiredDuringScheduling 关联性规则相对应的隐式 PreferredDuringScheduling 关联性规则。 ---hard-pod-affinity-symmetric-weight 代表隐式 PreferredDuringScheduling -关联性规则的权重。权重必须在 0-100 范围内。 -如果 --config 指定了一个配置文件，那么这个参数将被忽略。 +APIListChunking=true|false (BETA - 默认值为 true)
    +APIPriorityAndFairness=true|false (BETA - 默认值为 true)
    +APIResponseCompression=true|false (BETA - 默认值为 true)
    +APIServerIdentity=true|false (ALPHA - 默认值为 false)
    +APIServerTracing=true|false (ALPHA - 默认值为 false)
    +AllAlpha=true|false (ALPHA - 默认值为 false)
    +AllBeta=true|false (BETA - 默认值为 false)
    +AnyVolumeDataSource=true|false (BETA - 默认值为 true)
    +AppArmor=true|false (BETA - 默认值为 true)
    +CPUManager=true|false (BETA - 默认值为 true)
    +CPUManagerPolicyAlphaOptions=true|false (ALPHA - 默认值为 false)
    +CPUManagerPolicyBetaOptions=true|false (BETA - 默认值为 true)
    +CPUManagerPolicyOptions=true|false (BETA - 默认值为 true)
    +CSIInlineVolume=true|false (BETA - 默认值为 true)
    +CSIMigration=true|false (BETA - 默认值为 true)
    +CSIMigrationAWS=true|false (BETA - 默认值为 false)
    +CSIMigrationAzureFile=true|false (BETA - 默认值为 false)
    +CSIMigrationGCE=true|false (BETA - 默认值为 true)
    +CSIMigrationPortworx=true|false (ALPHA - 默认值为 false)
    +CSIMigrationRBD=true|false (ALPHA - 默认值为 false)
    +CSIMigrationvSphere=true|false (BETA - 默认值为 false)
    +CSIVolumeHealth=true|false (ALPHA - 默认值为 false)
    +ContextualLogging=true|false (ALPHA - 默认值为 false)
    +CronJobTimeZone=true|false (ALPHA - 默认值为 false)
    +CustomCPUCFSQuotaPeriod=true|false (ALPHA - 默认值为 false)
    +CustomResourceValidationExpressions=true|false (ALPHA - 默认值为 false)
    +DaemonSetUpdateSurge=true|false (BETA - 默认值为 true)
    +DelegateFSGroupToCSIDriver=true|false (BETA - 默认值为 true)
    +DevicePlugins=true|false (BETA - 默认值为 true)
    +DisableAcceleratorUsageMetrics=true|false (BETA - 默认值为 true)
    +DisableCloudProviders=true|false (ALPHA - 默认值为 false)
    +DisableKubeletCloudCredentialProviders=true|false (ALPHA - 默认值为 false)
    +DownwardAPIHugePages=true|false (BETA - 默认值为 true)
    +EndpointSliceTerminatingCondition=true|false (BETA - 默认值为 true)
    +EphemeralContainers=true|false (BETA - 默认值为 true)
    +ExpandedDNSConfig=true|false (ALPHA - 默认值为 false)
    +ExperimentalHostUserNamespaceDefaulting=true|false (BETA - 默认值为 false)
    +GRPCContainerProbe=true|false (BETA - 默认值为 true)
    +GracefulNodeShutdown=true|false (BETA - 默认值为 true)
    +GracefulNodeShutdownBasedOnPodPriority=true|false (BETA - 默认值为 true)
    +HPAContainerMetrics=true|false (ALPHA - 默认值为 false)
    +HPAScaleToZero=true|false (ALPHA - 默认值为 false)
    +HonorPVReclaimPolicy=true|false (ALPHA - 默认值为 false)
    +IdentifyPodOS=true|false (BETA - 默认值为 true)
    +InTreePluginAWSUnregister=true|false (ALPHA - 默认值为 false)
    +InTreePluginAzureDiskUnregister=true|false (ALPHA - 默认值为 false)
    +InTreePluginAzureFileUnregister=true|false (ALPHA - 默认值为 false)
    +InTreePluginGCEUnregister=true|false (ALPHA - 默认值为 false)
    +InTreePluginOpenStackUnregister=true|false (ALPHA - 默认值为 false)
    +InTreePluginPortworxUnregister=true|false (ALPHA - 默认值为 false)
    +InTreePluginRBDUnregister=true|false (ALPHA - 默认值为 false)
    +InTreePluginvSphereUnregister=true|false (ALPHA - 默认值为 false)
    +obMutableNodeSchedulingDirectives=true|false (BETA - 默认值为 true)
    +JobReadyPods=true|false (BETA - 默认值为 true)
    +JobTrackingWithFinalizers=true|false (BETA - 默认值为 false)
    +KubeletCredentialProviders=true|false (BETA - 默认值为 true)
    +KubeletInUserNamespace=true|false (ALPHA - 默认值为 false)
    +KubeletPodResources=true|false (BETA - 默认值为 true)
    +KubeletPodResourcesGetAllocatable=true|false (BETA - 默认值为 true)
    +LegacyServiceAccountTokenNoAutoGeneration=true|false (BETA - 默认值为 true)
    +LocalStorageCapacityIsolation=true|false (BETA - 默认值为 true)
    +LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - 默认值为 false)
    +LogarithmicScaleDown=true|false (BETA - 默认值为 true)
    +MaxUnavailableStatefulSet=true|false (ALPHA - 默认值为 false)
    +MemoryManager=true|false (BETA - 默认值为 true)
    +MemoryQoS=true|false (ALPHA - 默认值为 false)
    +MinDomainsInPodTopologySpread=true|false (ALPHA - 默认值为 false)
    +MixedProtocolLBService=true|false (BETA - 默认值为 true)
    +NetworkPolicyEndPort=true|false (BETA - 默认值为 true)
    +NetworkPolicyStatus=true|false (ALPHA - 默认值为 false)
    +NodeOutOfServiceVolumeDetach=true|false (ALPHA - 默认值为 false)
    +NodeSwap=true|false (ALPHA - 默认值为 false)
    +OpenAPIEnums=true|false (BETA - 默认值为 true)
    +OpenAPIV3=true|false (BETA - 默认值为 true)
    +PodAndContainerStatsFromCRI=true|false (ALPHA - 默认值为 false)
    +PodDeletionCost=true|false (BETA - 默认值为 true)
    +PodSecurity=true|false (BETA - 默认值为 true)
    +ProbeTerminationGracePeriod=true|false (BETA - 默认值为 false)
    +ProcMountType=true|false (ALPHA - 默认值为 false)
    +ProxyTerminatingEndpoints=true|false (ALPHA - 默认值为 false)
    +QOSReserved=true|false (ALPHA - 默认值为 false)
    +ReadWriteOncePod=true|false (ALPHA - 默认值为 false)
    +RecoverVolumeExpansionFailure=true|false (ALPHA - 默认值为 false)
    +RemainingItemCount=true|false (BETA - 默认值为 true)
    +RotateKubeletServerCertificate=true|false (BETA - 默认值为 true)
    +SeccompDefault=true|false (ALPHA - 默认值为 false)
    +ServerSideFieldValidation=true|false (ALPHA - 默认值为 false)
    +ServiceIPStaticSubrange=true|false (ALPHA - 默认值为 false)
    +ServiceInternalTrafficPolicy=true|false (BETA - 默认值为 true)
    +SizeMemoryBackedVolumes=true|false (BETA - 默认值为 true)
    +StatefulSetAutoDeletePVC=true|false (ALPHA - 默认值为 false)
    +StatefulSetMinReadySeconds=true|false (BETA - 默认值为 true)
    +StorageVersionAPI=true|false (ALPHA - 默认值为 false)
    +StorageVersionHash=true|false (BETA - 默认值为 true)
    +TopologyAwareHints=true|false (BETA - 默认值为 true)
    +TopologyManager=true|false (BETA - 默认值为 true)
    +VolumeCapacityPriority=true|false (ALPHA - 默认值为 false)
    +WinDSR=true|false (ALPHA - 默认值为 false)
    +WinOverlay=true|false (BETA - 默认值为 true)
    +WindowsHostProcessContainers=true|false (BETA - 默认值为 true)
    --kube-api-qps float32     默认值：50--kube-api-qps float     默认值：50
    @@ -666,10 +587,9 @@ The interval between attempts by the acting master to renew a leadership slot be
    -在领导者选举期间用于锁定的资源对象的类型。支持的选项是 `endpoints`、 -`configmaps`、`leases`、`endpointleases` 和 `configmapsleases`。 +在领导者选举期间用于锁定的资源对象的类型。支持的选项有 `leases`、`endpointleases` 和 `configmapsleases`。
    --log-backtrace-at <a string in the form 'file:N'>      -默认值: 0
    - -当记录命中行文件 file 的第 N 行时输出堆栈跟踪。 -
    --log-dir string
    - -如果为非空，则在此目录中写入日志文件。 -
    --log-file string
    - -如果为非空，则使用此文件作为日志文件。 -
    --log-file-max-size uint     默认值：1800
    - -定义日志文件可以增长到的最大值。单位为兆字节。 -如果值为 0，则最大文件大小为无限制。 -
    --log-flush-frequency duration     默认值：5s
    -设置日志格式。可选格式：“json”，“text”。
    +设置日志格式。可选格式：“text”。
    采用非默认格式时，以下标识不会生效： --add-dir-header, --alsologtostderr, --log-backtrace-at, --log-dir, --log-file, --log-file-max-size, --logtostderr, --one-output, --skip-headers, --skip-log-headers, ---stderrthreshold, --vmodule, --log-flush-frequency.
    +--stderrthreshold, --vmodule.
    非默认选项目前处于 Alpha 阶段，有可能会出现变更且无事先警告。
    --one-output
    - -若此标志为 true，则日志仅写入其自身的严重性级别，而不会写入所有较低严重性级别。 -
    --permit-address-sharing
    --policy-config-file string--pod-max-in-unschedulable-pods-duration duration     默认值：5m0s
    -已弃用：包含调度器策略配置的文件。 -当策略 ConfigMap 为提供时，或者 --use-legacy-policy-config=true 时使用此文件。 -注意：当此标志与插件配置一起使用时，调度器会失败。 +已弃用：Pod 可以在 unschedulablePods 中停留的最长时间。 +如果 Pod 在 unschedulablePods 中停留的时间超过此值，则该 pod 将被从 +unschedulablePods 移动到 backoffQ 或 activeQ。 +此标志已弃用，将在 1.2 中删除。 +
    --policy-configmap string
    - -已弃用: 包含调度器策略配置的 ConfigMap 对象的名称。 -如果 --use-legacy-policy-config=false，则它必须在调度器初始化之前存在于 -系统命名空间中。配置数据必须对应 'data' 映射中键名为 'policy.cfg' 的元素的值。 -注意：如果与插件配置一起使用，调度器会失败。 -
    --policy-configmap-namespace string     默认值："kube-system"
    - -已弃用: 策略 ConfigMap 所在的名字空间。如果未提供或为空，则将使用 kube-system 名字空间。 -注意：如果与插件配置一起使用，调度器会失败。 -
    --port int     默认值：10251
    - -已弃用： 在没有身份验证和鉴权的情况下不安全地为 HTTP 服务的端口。 -如果为 0，则根本不提供 HTTP。请参见 --secure-port。 -如果 --config 指定了一个配置文件，这个参数将被忽略。 -
    --profiling     默认值： true--profiling     默认值：true
    @@ -986,7 +806,7 @@ Root certificate bundle to use to verify client certificates on incoming request
    --requestheader-extra-headers-prefix strings      -默认值: "x-remote-extra-"
    @@ -999,7 +819,7 @@ List of request header prefixes to inspect. X-Remote-Extra- is suggested.
    --requestheader-group-headers strings      -默认值: "x-remote-group"
    @@ -1012,7 +832,7 @@ List of request headers to inspect for groups. X-Remote-Group is suggested.
    --requestheader-username-headers strings      -默认值: "x-remote-user"
    @@ -1023,21 +843,6 @@ List of request headers to inspect for usernames. X-Remote-User is common.
    --scheduler-name string      -默认值："default-scheduler"
    - -已弃用: 调度器名称，用于根据 Pod 的 “spec.schedulerName” 选择此 -调度器将处理的 Pod。 -如果 --config 指定了一个配置文件，那么这个参数将被忽略 -
    --secure-port int     默认值：10259
    --skip-headers
    - -如果为 true，日志消息中不再写入头部前缀。 -
    --skip-log-headers
    - -如果为 true，则在打开日志文件时忽略其头部。 -
    --stderrthreshold int     默认值：2
    - -达到或超过此阈值的日志会被写入到标准错误输出。 -
    --tls-cert-file string
    --use-legacy-policy-config
    - -已弃用：设置为 true 时，调度程序将忽略策略 ConfigMap 并使用策略配置文件。 -注意：当此标志与插件配置一起使用时，调度器会失败。 +例如: "example.crt,example.key" 或者 "foo.crt,foo.key:*.foo.com,foo.com"。
    --vmodule <逗号分隔的 ‘模式=N’ 配置列表>--vmodule pattern=N,...
    -以逗号分隔的 ‘模式=N’ 设置列表，用于文件过滤的日志记录。 +以逗号分隔的 “pattern=N” 设置列表，用于文件过滤的日志记录（仅适用于文本日志格式）。

    criSocket 用来读取容器运行时的信息。 -此信息会被以注解的方式添加到 Node API 对象至上，用于后续用途。

    +此信息会被以注解的方式添加到 Node API 对象之上，用于后续用途。
    taints [必需]
    []core/v1.Taint     		- +If this field is unset, i.e. nil, in the kubeadm init process it will be defaulted with +a control-plane taint for control-plane nodes. If you don't want to taint your control-plane +node, set this field to an empty list, i.e. taints: [], in the YAML file. This field is +solely used for Node registration.

    +-->

    tains 设定 Node API 对象被注册时要附带的污点。 -若未设置此字段（即字段值为 null）, 在 kubeadm init 期间，节点与控制面之间的通信。 -默认值为污点默认设置为 taints: ['node-role.kubernetes.io/master:""']。 -如果你不希望为控制面节点设置污点，可以在 YAML 中将此字段设置为空的列表，即 -taints: []。 此字段仅用在 Node 注册期间。

    +若未设置此字段（即字段值为 null），在 kubeadm init 期间，默认为控制平面节点添加控制平面污点。 +如果你不想污染你的控制平面节点，可以将此字段设置为空列表（即 YAML 文件中的 taints: []）， +这个字段只用于节点注册。
    kubeletExtraArgs [必需]
    diff --git a/content/zh/docs/reference/config-api/kubeadm-config.v1beta3.md b/content/zh/docs/reference/config-api/kubeadm-config.v1beta3.md index 2a53c835db..ef491a424e 100644 --- a/content/zh/docs/reference/config-api/kubeadm-config.v1beta3.md +++ b/content/zh/docs/reference/config-api/kubeadm-config.v1beta3.md @@ -313,7 +313,7 @@ https://godoc.org/k8s.io/kubelet/config/v1beta1#KubeletConfiguration。

    criSocket: "/var/run/dockershim.sock" taints: - key: "kubeadmNode" - value: "master" + value: "someValue" effect: "NoSchedule" kubeletExtraArgs: v: 4 @@ -1655,15 +1655,17 @@ This information will be annotated to the Node API object, for later re-use[]core/v1.Taint     		- +

    tains 设定 Node API 对象被注册时要附带的污点。 -若未设置此字段（即字段值为 null）, 在 kubeadm init 期间，节点与控制面之间的通信。默认值为污点默认设置为 taints: ["node-role.kubernetes.io/master:""]。 -如果你不希望为控制面节点设置污点，可以在 YAML 中将此字段设置为空的列表，即 -taints: []。 此字段仅用在 Node 注册期间。

    +若未设置此字段（即字段值为 null），在 kubeadm init 期间，默认为控制平面节点添加控制平面污点。 +如果你不想污染你的控制平面节点，可以将此字段设置为空列表（即 YAML 文件中的 taints: []）， +这个字段只用于节点注册。
    kubeletExtraArgs
    diff --git a/content/zh/docs/reference/config-api/kubelet-config.v1alpha1.md b/content/zh/docs/reference/config-api/kubelet-config.v1alpha1.md index ad7e4908f4..9a62ac5ec6 100644 --- a/content/zh/docs/reference/config-api/kubelet-config.v1alpha1.md +++ b/content/zh/docs/reference/config-api/kubelet-config.v1alpha1.md @@ -26,8 +26,6 @@ auto_generated: true --> **出现在：** -- [LoggingConfiguration](#LoggingConfiguration) - @@ -41,8 +39,8 @@ FormatOptions 包含为不同类型日志格式提供的选项。 JSONOptions     		- - [试验特性] json 中包含 "json" 日志格式的选项。 + + [试验特性] json 中包含 "json" 日志格式的选项。
    @@ -104,8 +102,6 @@ using split streams. The default is zero, which disables buffering.--> --> **出现在：** -- [LoggingConfiguration](#LoggingConfiguration) - ## 资源类型 +- [CredentialProviderConfig](#kubelet-config-k8s-io-v1beta1-CredentialProviderConfig) - [KubeletConfiguration](#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) - [SerializedNodeConfigSource](#kubelet-config-k8s-io-v1beta1-SerializedNodeConfigSource) +## `CredentialProviderConfig` {#kubelet-config-k8s-io-v1beta1-CredentialProviderConfig} + + +CredentialProviderConfig 包含有关每个 exec 凭据提供者的配置信息。 +Kubelet 从磁盘上读取这些配置信息，并根据 CredentialProvider 类型启用各个提供者。 + +
    字段描述
    + + + + + + + + + + + +
    字段描述
    apiVersion
    string    		kubelet.config.k8s.io/v1beta1
    kind
    string    		CredentialProviderConfig
    providers [必需]
    +[]CredentialProvider +    		 + +

    + providers 是一组凭据提供者插件，这些插件会被 kubelet 启用。 + 多个提供者可以匹配到同一镜像上，这时，来自所有提供者的凭据信息都会返回给 kubelet。 + 如果针对同一镜像调用了多个提供者，则结果会被组合起来。如果提供者返回的认证主键有重复， + 列表中先出现的提供者所返回的值将被使用。 +

    +
    + ## `KubeletConfiguration` {#kubelet-config-k8s-io-v1beta1-KubeletConfiguration}

    enableServer 会启用 kubelet 的安全服务器。

    注意：kubelet 的不安全端口由 readOnlyPort 选项控制。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑可能会影响到与 kubelet 服务器交互的组件。

    默认值：true
    +Default: ""-->

    staticPodPath 是指向要运行的本地（静态）Pod 的目录， 或者指向某个静态 Pod 文件的路径。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑新路径下所给的静态 Pod 集合可能与 kubelet -启动时所看到的集合不同，而这一差别可能会扰乱节点状态。

    -

    默认值：""

    +

    默认值：""
    syncFrequency
    -meta/v1.Duration +meta/v1.Duration     		+Default: "1m"-->

    syncFrequency 是对运行中的容器和配置进行同步的最长周期。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑缩短这一同步周期可能会带来负面的性能影响， -尤其当节点上 Pod 个数增加时。相反，增加此周期长度时可能会导致 ConfigMap、 -Secret 这类资源未被及时更新。

    -

    默认值："1m"

    +

    默认值："1m"
    fileCheckFrequency
    -meta/v1.Duration +meta/v1.Duration     		+Default: "20s"-->

    fileCheckFrequency 是对配置文件中新数据进行检查的时间间隔值。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑缩短此时长会导致 kubelet 更为频繁地重新加载其静态 Pod 配置， -而这会带来负面的性能影响。

    -

    默认值："20s"

    +

    默认值："20s"
    httpCheckFrequency
    -meta/v1.Duration +meta/v1.Duration

    httpCheckFrequency 是对 HTTP 服务器上新数据进行检查的时间间隔值。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑缩短此时长会导致 kubelet 更为频繁地轮询 -staticPodURL，而这会带来负面的性能影响。

    -

    默认值："20s"

    +

    默认值："20s"

    staticPodURL 是访问要运行的静态 Pod 的 URL 地址。 -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，新的 URL 上包含的静态 Pod 集合可能与 kubelet -初始启动时看到的不同，而这种差异可能会扰乱节点状态。

    -

    默认值：""

    +

    默认值：""

    staticPodURLHeader是一个由字符串组成的映射表，其中包含的 HTTP 头部信息用于访问podURL。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，要考虑可能导致无法从staticPodURL -读取最新的静态 Pod 集合。

    默认值：nil

    tlsPrivateKeyFile是一个包含与tlsCertFile 证书匹配的 X509 私钥的文件。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑可能干扰与 kubelet 服务器交互的组件。

    默认值：""

    tlsCipherSuites是一个字符串列表，其中包含服务器所接受的加密包名称。 列表中的每个值来自于tls包中定义的常数（https://golang.org/pkg/crypto/tls/#pkg-constants）。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑可能干扰到与 kubelet 服务器交互的组件。

    默认值：nil

    tlsMinVersion给出所支持的最小 TLS 版本。 字段取值来自于tls包中的常数定义（https://golang.org/pkg/crypto/tls/#pkg-constants）。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑可能干扰到与 kubelet 服务器交互的组件。

    默认值：""

    authorization设置发送给 kubelet 服务器的请求是如何进行身份认证的。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑可能干扰与 kubelet 服务器交互的组件。

    默认值：

    
   anonymous:
     enabled: false
   webhook:
     enabled: true
-    cacheTTL: "2m"
+    cacheTTL: "2m"

    authorization设置发送给 kubelet 服务器的请求是如何进行鉴权的。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑可能会干扰到与 kubelet 服务器交互的组件。

    默认值：

    
   mode: Webhook
   webhook:
-    cacheAuthorizedTTL: "5m"
-    cacheUnauthorizedTTL: "30s"
+    cacheAuthorizedTTL: "5m"
+    cacheUnauthorizedTTL: "30s"

    eventRecordQPS设置每秒钟可创建的事件个数上限。如果此值为 0， 则表示没有限制。此值不能设置为负数。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑可能因为生成事件所造成的流量变化，导致集群可扩缩能力受影响。

    默认值：5
    -

    eventBurst是突发性事件创建的上限值，允许事件创建临时上升到所指定数量， 不过仍然不超过eventRecordQPS所设置的约束。此值必须是非负值， -且只有eventRecordQPS大于 0 时才会使用此设置。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑可能因为事件创建所造成的流量变化，导致集群可扩缩能力受影响。

    +且只有eventRecordQPS > 0 时才会使用此设置。

    默认值：10
    -

    enableContentionProfiling用于启用锁竞争性能分析， 仅用于enableDebuggingHandlers为true的场合。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑启用此分析可能隐含着一定的性能影响。

    默认值：false

    -

    healthzPort是本地主机上提供healthz端点的端口 （设置值为 0 时表示禁止）。合法值介于 1 和 65535 之间。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑可能干扰到监控 kubelet 健康状况的组件。

    默认值：10248
    -

    healthzBindAddress是healthz服务器用来提供服务的 IP 地址。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑可能影响到监测 kubelet 健康状况的组件。

    默认值："127.0.0.1"

    oomScoreAdj 是为 kubelet 进程设置的oom-score-adj值。 所设置的取值要在 [-1000, 1000] 范围之内。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑可能影响到内存压力较大时节点的稳定性。

    默认值：-999
    streamingConnectionIdleTimeout
    -meta/v1.Duration +meta/v1.Duration

    streamingConnectionIdleTimeout设置流式连接在被自动关闭之前可以空闲的最长时间。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑可能影响到依赖于通过与 kubelet -服务器间流式连接来接受非频繁更新事件的组件。

    默认值："4h"
    nodeStatusUpdateFrequency
    -meta/v1.Duration +meta/v1.Duration

    nodeStatusUpdateFrequency是 kubelet 计算节点状态的频率。 如果未启用节点租约特性，这一字段设置的也是 kubelet 向控制面投递节点状态的频率。

    注意：如果节点租约特性未被启用，更改此参数设置时要非常小心， 所设置的参数值必须与节点控制器的nodeMonitorGracePeriod协同。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑变更可能影响节点的可扩缩性。还要注意节点控制器的 -nodeMonitorGracePeriod必须设置为N∗nodeStatusUpdateFrequency， -其中N是节点控制器标记节点不健康之前执行重试的次数。

    默认值："10s"
    nodeStatusReportFrequency
    -meta/v1.Duration +meta/v1.Duration

    nodeLeaseDurationSeconds是 kubelet 会在其对应的 Lease 对象上设置的时长值。 @@ -735,27 +592,19 @@ Default: 40

    如果租约过期，则节点可被视作不健康。根据 KEP-0009 约定，目前的租约每 10 秒钟续约一次。 在将来，租约的续约时间间隔可能会根据租约的时长来设置。

    此字段的取值必须大于零。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑缩短租约期限可能降低节点对那些暂时导致 kubelet -无法续约的问题的容忍度（例如，时延很短的网络问题）。

    默认值：40
    imageMinimumGCAge
    -meta/v1.Duration +meta/v1.Duration

    imageMinimumGCAge是对未使用镜像进行垃圾搜集之前允许其存在的时长。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑这种变更可能触发垃圾收集或者延迟垃圾收集， -并且可能影响节点上镜像的额外开销。

    默认值："2m"
    volumeStatsAggPeriod
    -meta/v1.Duration +meta/v1.Duration

    volumeStatsAggPeriod是计算和缓存所有 Pod 磁盘用量的频率。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑缩短此周期长度可能产生性能影响。

    默认值："1m"

    kubeletCgroups是用来隔离 kubelet 的控制组（CGroup）的绝对名称。

    -

    DynamicKubeletConfig （已弃用）： -更新此字段时需要对整个节点执行重启。最安全的做法是确保此值与本地配置相同。

    默认值：""

    cgroupRoot是用来运行 Pod 的控制组 (CGroup）。 容器运行时会尽可能处理此字段的设置值。

    -

    DynamicKubeletConfig （已弃用）： -更新此字段时需要对整个节点执行重启。最安全的做法是确保此值与本地配置相同。

    -

    默认值：""

    cgroupDriver是 kubelet 用来操控宿主系统上控制组 (CGroup） 的驱动程序（cgroupfs 或 systemd）。

    -

    DynamicKubeletConfig （已弃用）： -更新此字段时需要对整个节点执行重启。最安全的做法是确保此值与本地配置相同。

    默认值："cgroupfs"

    cpuManagerPolicy是要使用的策略名称。需要启用CPUManager 特性门控。

    -

    DynamicKubeletConfig （已弃用）： -更新此字段时需要对整个节点执行重启。最安全的做法是确保此值与本地配置相同。

    默认值："None"

    cpuManagerPolicyOptions是一组key=value键值映射， 容许通过额外的选项来精细调整 CPU 管理器策略的行为。需要CPUManager和 CPUManagerPolicyOptions两个特性门控都被启用。

    -

    DynamicKubeletConfig （已弃用）： -更新此字段时需要对整个节点执行重启。最安全的做法是确保此值与本地配置相同。

    默认值：nil
    cpuManagerReconcilePeriod
    -meta/v1.Duration +meta/v1.Duration

    cpuManagerReconcilePeriod是 CPU 管理器的协调周期时长。 需要启用CPUManager特性门控。

    -

    DynamicKubeletConfig （已弃用）： -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑缩短周期时长可能带来的性能影响。

    默认值："10s"

    memoryManagerPolicy是内存管理器要使用的策略的名称。 要求启用MemoryManager特性门控。

    -

    DynamicKubeletConfig （已弃用）： -更新此字段时需要对整个节点执行重启。最安全的做法是确保此值与本地配置相同。

    默认值："none"
    runtimeRequestTimeout
    -meta/v1.Duration +meta/v1.Duration

    runtimeRequestTimeout用来设置除长期运行的请求（pull、 logs、exec和attach）之外所有运行时请求的超时时长。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑可能干扰与 kubelet 服务器交互的组件。

    默认值："2m"

    maxPods是此 kubelet 上课运行的 Pod 个数上限。此值必须为非负整数。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑变更可能导致 kubelet 重启时 Pod 无法被准入， -而且可能改变Node.status.capacity[v1.ResourcePods]中报告的数值， -从而影响将来的调度决策。增大此个数值也可能会降低性能，因为会有更多的 Pod -塞到同一节点运行。

    默认值：110

    podCIDR是用来设置 Pod IP 地址的 CIDR 值，仅用于独立部署模式。 运行于集群模式时，这一数值会从控制面获得。

    -

    DynamicKubeletConfig （已弃用）： -此字段应该总是设置为默认的空字符串值。并且仅用来设置独立运行的 kubelet， -因为这种 kubelet 模式下无法利用动态 kubelet 配置能力。

    默认值：""

    podPidsLimit是每个 Pod 中可使用的 PID 个数上限。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑减小此值可能会导致变更后无法创建容器进程。

    默认值：-1

    resolvConf是一个域名解析配置文件，用作容器 DNS 解析配置的基础。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑变更仅会对更新完成后所创建的 Pod 起作用。 -建议在变更此字段之前先腾空节点。如果此值设置为空字符串，则会覆盖 DNS 解析的默认配置， +

    如果此值设置为空字符串，则会覆盖 DNS 解析的默认配置， 本质上相当于禁用了 DNS 查询。

    默认值："/etc/resolv.conf"

    cpuCFSQuota允许为设置了 CPU 限制的容器实施 CPU CFS 配额约束。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑禁止此功能可能会降低节点稳定性。

    默认值：true
    cpuCFSQuotaPeriod
    -meta/v1.Duration +meta/v1.Duration

    cpuCFSQuotaPeriod设置 CPU CFS 配额周期值，cpu.cfs_period_us。 此值需要介于 1 微秒和 1 秒之间，包含 1 微秒和 1 秒。 此功能要求启用CustomCPUCFSQuotaPeriod特性门控被启用。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑为容器所设置的限制值可能导致cpu.cfs_period_us -设置发生变化。这一变化会在节点被重新配置时触发容器重启。

    默认值："100ms"

    maxOpenFiles是 kubelet 进程可以打开的文件个数。此值必须不能为负数。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑可能影响到 kubelet 与节点文件系统间交互的能力。

    默认值：1000000

    contentType是向 API 服务器发送请求时使用的内容类型。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑这样做可能影响 kubelet 与 API 服务器通信的能力。 -如果 kubelet 因为此字段的变更而失去与 API 服务器间的连接， -则之前所作的变更无法通过动态 kubelet 配置来实现回退。

    默认值："application/vnd.kubernetes.protobuf"

    kubeAPIQPS设置与 Kubernetes API 服务器通信时要使用的 QPS（每秒查询数）。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑这可能因为 kubelet 与 API 服务器之间流量的变化而影响集群扩缩能力。

    默认值：5

    kubeAPIBurst设置与 Kubernetes API 服务器通信时突发的流量级别。 此字段取值不可以是负数。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑这可能因为 kubelet 与 API 服务器之间流量的变化而影响集群扩缩能力。

    默认值：10

    evictionSoft是一个映射，是从信号名称到定义软性驱逐阈值的映射。 例如：{"memory.available": "300Mi"}。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑这可能会触发或延迟 Pod 驱逐操作， -并且可能造成节点所报告的可分配资源数量发生变化。

    默认值：nil

    evictionSoftGracePeriod是一个映射，是从信号名称到每个软性驱逐信号的宽限期限。 例如：{"memory.available": "30s"}。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑这可能会触发或延迟 Pod 驱逐操作。

    默认值：nil
    evictionPressureTransitionPeriod
    -meta/v1.Duration +meta/v1.Duration

    evictionPressureTransitionPeriod设置 kubelet 离开驱逐压力状况之前必须要等待的时长。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑减少此字段值可能会在节点过量分配时降低节点稳定性。

    默认值："5m"

    iptablesDropBit是 iptables fwmark 空间中用来标记丢弃包的数据位。 此值必须介于[0, 31]区间，必须与其他标记位不同。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑此处的变更要与其他组件（如 kube-proxy）相应的变更协调一致。 -只有当makeIPTablesUtilChains能力被启用时，这里的更新才会起作用。

    默认值：15

    featureGates是一个从功能特性名称到布尔值的映射，用来启用或禁用实验性的功能。 此字段可逐条更改文件 "k8s.io/kubernetes/pkg/features/kube_features.go" 中所给的内置默认值。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑你所启用或禁止的功能特性的文档。 -尽管我们鼓励功能特性的开发人员使动态启用或禁用功能特性成为可能， -某些变更可能要求重新启动节点，某些特性可能要求在从启用到禁用切换时作出精细的协调。

    默认值：nil

    failSwapOn通知 kubelet 在节点上启用交换分区时拒绝启动。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑缩短此周期长度可能产生性能影响。

    默认值：true

    containerLogMaxSize是定义容器日志文件被轮转之前可以到达的最大尺寸。 例如："5Mi" 或 "256Ki"。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑可能会触发日志轮转。

    默认值："10Mi"

    containerLogMaxFiles设置每个容器可以存在的日志文件个数上限。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑降低此值可能导致日志文件被删除。

    默认值："5"

    systemReservedCgroup帮助 kubelet 识别用来为 OS 系统级守护进程实施 systemReserved计算资源预留时使用的顶级控制组（CGroup）。 -参考[Node Allocatable](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md) +参考 Node Allocatable 以了解详细信息。

    -

    DynamicKubeletConfig（已弃用）： -此字段更新时需要整个节点重启。最安全的做法是保持此值与本地配置相同。

    默认值：""

    kubeReservedCgroup 帮助 kubelet 识别用来为 Kubernetes 节点系统级守护进程实施 kubeReserved计算资源预留时使用的顶级控制组（CGroup）。 -参阅Node Allocatable +参阅 Node Allocatable 了解进一步的信息。

    -

    DynamicKubeletConfig（已弃用）： -此字段更新时需要整个节点重启。最安全的做法是保持此值与本地配置相同。

    默认值：""

    volumePluginDir是用来搜索其他第三方卷插件的目录的路径。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑更改volumePluginDir可能干扰使用第三方卷插件的负载。

    默认值："/usr/libexec/kubernetes/kubelet-plugins/volume/exec/"

    providerID字段被设置时，指定的是一个外部提供者（即云驱动）实例的唯一 ID， 该提供者可用来唯一性地标识特定节点。

    -

    当 DynamicKubeletConfig （已弃用，默认为关闭）被启用时， -如果动态更新了此字段，请考虑可能影响到 kubelet 与云驱动之间进行交互的能力。

    默认值：""
    shutdownGracePeriod
    -meta/v1.Duration +meta/v1.Duration     		+list when the node is shutting down. +For example, to allow critical pods 10s to shutdown, priority>=10000 pods 20s to +shutdown, and all remaining pods 30s to shutdown. +-->

    shutdownGracePeriodByPodPriority设置基于 Pod 相关的优先级类值而确定的体面关闭时间。当 kubelet 收到关闭请求的时候，kubelet 会针对节点上运行的所有 Pod 发起关闭操作，这些关闭操作会根据 Pod 的优先级确定其宽限期限， @@ -2140,6 +1683,15 @@ list when the node is shutting down.-->

  • priority: 0 shutdownGracePeriodSeconds: 30
    • +

    在退出之前，kubelet 要等待的时间上限为节点上所有优先级类的 shutdownGracePeriodSeconds的最大值。 当所有 Pod 都退出或者到达其宽限期限时，kubelet 会释放关闭防护锁。 @@ -2314,6 +1866,202 @@ SerializedNodeConfigSource 允许对 `v1.NodeConfigSource` 执行序列化操作

    +## `CredentialProvider` {#kubelet-config-k8s-io-v1beta1-CredentialProvider} + + +**出现在：** + +- [CredentialProviderConfig](#kubelet-config-k8s-io-v1beta1-CredentialProviderConfig) + + +CredentialProvider 代表的是要被 kubelet 调用的一个 exec 插件。 +这一插件只会在所拉取的镜像与该插件所处理的镜像匹配时才会被调用（参见 matchImages）。 + + + + + + + + + + + + + + + + + + + + + + + + +
    字段描述
    name [必需]
    +string +    		 + +

    + name 是凭据提供者的名称（必需）。此名称必须与 kubelet + 所看到的提供者可执行文件的名称匹配。可执行文件必须位于 kubelet 的 + bin 目录（通过 --image-credential-provider-bin-dir 设置）下。 +

    +
    matchImages [必需]
    +[]string +    		 + +

    matchImages 是一个必须设置的字符串列表，用来匹配镜像以便确定是否要调用此提供者。 +如果字符串之一与 kubelet 所请求的镜像匹配，则此插件会被调用并给予提供凭证的机会。 +镜像应该包含镜像库域名和 URL 路径。

    + +

    matchImages 中的每个条目都是一个模式字符串，其中可以包含端口号和路径。 +域名部分可以包含统配符，但端口或路径部分不可以。通配符可以用作子域名，例如 +'*.k8s.io' 或 'k8s.*.io'，以及顶级域名，如 'k8s.*'。

    +

    对类似 'app*.k8s.io' 这类部分子域名的匹配也是支持的。 +每个通配符只能用来匹配一个子域名段，所以 '*.io' 不会匹配 '*.k8s.io'。

    + +

    镜像与 matchImages 之间存在匹配时，以下条件都要满足：

    +
      + +
    • 二者均包含相同个数的域名部分，并且每个域名部分都对应匹配；
      • +
    • matchImages 条目中的 URL 路径部分必须是目标镜像的 URL 路径的前缀；
      • +
    • 如果 matchImages 条目中包含端口号，则端口号也必须与镜像端口号匹配。
      • +
    + +

    matchImages 的一些示例如下：

    +
      +
    • 123456789.dkr.ecr.us-east-1.amazonaws.com
      • +
    • *.azurecr.io
      • +
    • gcr.io
      • +
    • ..registry.io
      • +
    • registry.io:8080/path
      • +
    +
    defaultCacheDuration [必需]
    +meta/v1.Duration +    		 + +

    + defaultCacheDuration 是插件在内存中缓存凭据的默认时长， + 在插件响应中没有给出缓存时长时，使用这里设置的值。此字段是必需的。 +

    +
    apiVersion [必需]
    +string +    		 + +

    + 要求 exec 插件 CredentialProviderRequest 请求的输入版本。 + 所返回的 CredentialProviderResponse 必须使用与输入相同的编码版本。当前支持的值有： +

    +
      +
    • credentialprovider.kubelet.k8s.io/v1beta1
      • +
    +
    args
    +[]string +    		 + +

    在执行插件可执行文件时要传递给命令的参数。

    +
    env
    +[]ExecEnvVar +    		 + +

    + env 定义要提供给插件进程的额外的环境变量。 + 这些环境变量会与主机上的其他环境变量以及 client-go 所使用的环境变量组合起来， + 一起传递给插件。 +

    +
    + +## `ExecEnvVar` {#kubelet-config-k8s-io-v1beta1-ExecEnvVar} + + +**出现在：** + +- [CredentialProvider](#kubelet-config-k8s-io-v1beta1-CredentialProvider) + + +ExecEnvVar 用来在执行基于 exec 的凭据插件时设置环境变量。 + + + + + + + + + + + + +
    字段描述
    name [必需]
    +string +    		 + + + 无描述 + +
    value [必需]
    +string +    		 + + + 无描述 + +
    + + ## `KubeletAnonymousAuthentication` {#kubelet-config-k8s-io-v1beta1-KubeletAnonymousAuthentication} @@ -2491,7 +2239,7 @@ API 来提供持有者令牌身份认证。

    cacheAuthorizedTTL
    -meta/v1.Duration +meta/v1.Duration cacheUnauthorizedTTL
    -meta/v1.Duration +meta/v1.Duration flushFrequency [必需]
    -time.Duration +time.Duration

    - - 对日志进行清洗的最大间隔秒数。如果所选的日志后端在写入日志消息时不提供缓存， -则此配置会被忽略。 + + 对日志进行清洗的最大间隔纳秒数（例如，1s = 1000000000）。 + 如果所选的日志后端在写入日志消息时不提供缓存，则此配置会被忽略。

    @@ -2827,19 +2578,6 @@ Only supported for "text" log format.--> -sanitization [必需]
    -bool - - -

    - - [试验功能] 当启用此选项时，被标记为敏感的字段（密码、秘钥、令牌）不会被日志记录。 -运行时日志过滤功能可能会引入非常大的计算开销，因此在生产环境中不应启用。 -

    - - - options [必需]
    FormatOptions diff --git a/content/zh/docs/reference/glossary/aggregation-layer.md b/content/zh/docs/reference/glossary/aggregation-layer.md index 9ad14962cf..0d16d12aed 100644 --- a/content/zh/docs/reference/glossary/aggregation-layer.md +++ b/content/zh/docs/reference/glossary/aggregation-layer.md @@ -4,7 +4,7 @@ id: aggregation-layer date: 2018-10-08 full_link: /zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/ short_description: > - 聚合层允许您在自己的集群上安装额外的 Kubernetes 风格的 API。 + 聚合层允许你在自己的集群上安装额外的 Kubernetes 风格的 API。 aka: tags: @@ -36,7 +36,7 @@ tags: The aggregation layer lets you install additional Kubernetes-style APIs in your cluster. --> -聚合层允许您在自己的集群上安装额外的 Kubernetes 风格的 API。 +聚合层允许你在自己的集群上安装额外的 Kubernetes 风格的 API。 @@ -45,4 +45,5 @@ tags: When you've configured the {{< glossary_tooltip text="Kubernetes API Server" term_id="kube-apiserver" >}} to [support additional APIs](/docs/tasks/extend-kubernetes/configure-aggregation-layer/), you can add `APIService` objects to "claim" a URL path in the Kubernetes API. --> -当您配置了 {{< glossary_tooltip text="Kubernetes API Server" term_id="kube-apiserver" >}} 来 [支持额外的 API](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/)，您就可以在 Kubernetes API 中增加 `APIService` 对象来 "申领（Claim）" 一个 URL 路径。 +当你配置了 {{< glossary_tooltip text="Kubernetes API Server" term_id="kube-apiserver" >}} 来 [支持额外的 API](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/)， +你就可以在 Kubernetes API 中增加 `APIService` 对象来 "申领（Claim）" 一个 URL 路径。 diff --git a/content/zh/docs/reference/glossary/app-container.md b/content/zh/docs/reference/glossary/app-container.md index 3773e1c1b8..3980937a9d 100644 --- a/content/zh/docs/reference/glossary/app-container.md +++ b/content/zh/docs/reference/glossary/app-container.md @@ -42,6 +42,6 @@ once the application container has started. If a pod doesn't have any init containers configured, all the containers in that pod are app containers. --> -初始化容器使您可以分离对于{{< glossary_tooltip text="工作负载" term_id="workload" >}} +初始化容器使你可以分离对于{{< glossary_tooltip text="工作负载" term_id="workload" >}} 整体而言很重要的初始化细节，并且一旦应用容器启动，它不需要继续运行。 如果 pod 没有配置任何初始化容器，则该 pod 中的所有容器都是应用程序容器。 \ No newline at end of file diff --git a/content/zh/docs/reference/glossary/configmap.md b/content/zh/docs/reference/glossary/configmap.md index be80c84f61..cc22e9de56 100644 --- a/content/zh/docs/reference/glossary/configmap.md +++ b/content/zh/docs/reference/glossary/configmap.md @@ -41,4 +41,4 @@ environment variables, command-line arguments, or as configuration files in a A ConfigMap allows you to decouple environment-specific configuration from your {{< glossary_tooltip text="container images" term_id="image" >}}, so that your applications are easily portable. --> -ConfigMap 将您的环境配置信息和 {{< glossary_tooltip text="容器镜像" term_id="image" >}} 解耦，便于应用配置的修改。 +ConfigMap 将你的环境配置信息和 {{< glossary_tooltip text="容器镜像" term_id="image" >}} 解耦，便于应用配置的修改。 diff --git a/content/zh/docs/reference/glossary/customresourcedefinition.md b/content/zh/docs/reference/glossary/customresourcedefinition.md index ee0548e78d..c29e02d8c5 100644 --- a/content/zh/docs/reference/glossary/customresourcedefinition.md +++ b/content/zh/docs/reference/glossary/customresourcedefinition.md @@ -4,7 +4,7 @@ id: CustomResourceDefinition date: 2018-04-12 full_link: /zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/ short_description: > - 通过定制化的代码给您的 Kubernetes API 服务器增加资源对象，而无需编译完整的定制 API 服务器。 + 通过定制化的代码给你的 Kubernetes API 服务器增加资源对象，而无需编译完整的定制 API 服务器。 aka: tags: @@ -33,7 +33,7 @@ tags: Custom code that defines a resource to add to your Kubernetes API server without building a complete custom server. --> - 通过定制化的代码给您的 Kubernetes API 服务器增加资源对象，而无需编译完整的定制 API 服务器。 + 通过定制化的代码给你的 Kubernetes API 服务器增加资源对象，而无需编译完整的定制 API 服务器。 @@ -41,5 +41,6 @@ tags: Custom Resource Definitions let you extend the Kubernetes API for your environment if the publicly supported API resources can't meet your needs. --> -当 Kubernetes 公开支持的 API 资源不能满足您的需要时，定制资源对象（Custom Resource Definitions）让您可以在您的环境上扩展 Kubernetes API。 +当 Kubernetes 公开支持的 API 资源不能满足你的需要时， +定制资源对象（Custom Resource Definitions）让你可以在你的环境上扩展 Kubernetes API。 diff --git a/content/zh/docs/reference/glossary/disruption.md b/content/zh/docs/reference/glossary/disruption.md index 2b59797a39..6cfc0a1809 100644 --- a/content/zh/docs/reference/glossary/disruption.md +++ b/content/zh/docs/reference/glossary/disruption.md @@ -41,7 +41,7 @@ Kubernetes terms that an _involuntary disruption_. See [Disruptions](/docs/concepts/workloads/pods/disruptions/) for more information. --> -如果您作为一个集群操作人员，销毁了一个从属于某个应用的 Pod, Kubernetes 视之为 _自愿干扰（Voluntary Disruption）_。如果由于节点故障 -或者影响更大区域故障的断电导致 Pod 离线，kubernetes 视之为 _非愿干扰（Involuntary Disruption）_。 +如果你作为一个集群操作人员，销毁了一个从属于某个应用的 Pod, Kubernetes 视之为**自愿干扰（Voluntary Disruption）**。 +如果由于节点故障 或者影响更大区域故障的断电导致 Pod 离线，kubernetes 视之为**非愿干扰（Involuntary Disruption）**。 更多信息请查阅[Disruptions](/zh/docs/concepts/workloads/pods/disruptions/) \ No newline at end of file diff --git a/content/zh/docs/reference/glossary/dockershim.md b/content/zh/docs/reference/glossary/dockershim.md new file mode 100644 index 0000000000..22570a4b17 --- /dev/null +++ b/content/zh/docs/reference/glossary/dockershim.md @@ -0,0 +1,40 @@ +--- +title: Dockershim +id: dockershim +date: 2022-04-15 +full_link: /zh/dockershim +short_description: > + dockershim 是 Kubernetes v1.23 及之前版本中的一个组件，Kubernetes 系统组件通过它与 Docker Engine 通信。 + +aka: +tags: +- fundamental +--- + + + + + +dockershim 是 Kubernetes v1.23 及之前版本中的一个组件。 +Kubernetes 系统组件通过它与 {{< glossary_tooltip text="Docker Engine" term_id="docker" >}} 通信。 + + + +从 Kubernetes v1.24 开始，dockershim 已从 Kubernetes 中移除. +想了解更多信息，可参考[移除 Dockershim 的常见问题](/zh/dockershim)。 \ No newline at end of file diff --git a/content/zh/docs/reference/glossary/ephemeral-container.md b/content/zh/docs/reference/glossary/ephemeral-container.md index d937404797..a317bbfb10 100644 --- a/content/zh/docs/reference/glossary/ephemeral-container.md +++ b/content/zh/docs/reference/glossary/ephemeral-container.md @@ -4,12 +4,12 @@ id: ephemeral-container date: 2019-08-26 full_link: /zh/docs/concepts/workloads/pods/ephemeral-containers/ short_description: > - 您可以在 Pod 中临时运行的一种容器类型 + 你可以在 Pod 中临时运行的一种容器类型 aka: tags: - fundamental --- - 您可以在 {{< glossary_tooltip term_id="pod" >}} 中临时运行的一种 {{< glossary_tooltip term_id="container" >}} 类型。 + 你可以在 {{< glossary_tooltip term_id="pod" >}} 中临时运行的一种 {{< glossary_tooltip term_id="container" >}} 类型。 -您的 Kubernetes 集群的 etcd 数据库通常需要有个备份计划。 +你的 Kubernetes 集群的 etcd 数据库通常需要有个备份计划。 diff --git a/content/zh/docs/reference/glossary/kops.md b/content/zh/docs/reference/glossary/kops.md index d3241b763e..1719e2a8a6 100644 --- a/content/zh/docs/reference/glossary/kops.md +++ b/content/zh/docs/reference/glossary/kops.md @@ -56,7 +56,7 @@ Support for using kops with GCE and VMware vSphere are in alpha. * The ability to directly provision, or to generate Terraform manifests --> -`kops` 为您的集群提供了： +`kops` 为你的集群提供了： * 全自动化安装 * 基于 DNS 的集群标识 @@ -69,4 +69,5 @@ Support for using kops with GCE and VMware vSphere are in alpha. You can also build your own cluster using {{< glossary_tooltip term_id="kubeadm" >}} as a building block. `kops` builds on the kubeadm work. --> -您也可以将自己的集群作为一个构造块，使用 {{< glossary_tooltip term_id="kubeadm" >}} 构造集群。`kops` 是建立在 kubeadm 之上的。 +你也可以将自己的集群作为一个构造块，使用 {{< glossary_tooltip term_id="kubeadm" >}} 构造集群。 +`kops` 是建立在 kubeadm 之上的。 diff --git a/content/zh/docs/reference/glossary/logging.md b/content/zh/docs/reference/glossary/logging.md index 8a88fe527e..64d8dbd0ac 100644 --- a/content/zh/docs/reference/glossary/logging.md +++ b/content/zh/docs/reference/glossary/logging.md @@ -36,4 +36,4 @@ tags: Application and systems logs can help you understand what is happening inside your cluster. The logs are particularly useful for debugging problems and monitoring cluster activity. --> -应用程序和系统日志可以帮助您了解集群内部发生的情况。日志对于调试问题和监视集群活动非常有用。 \ No newline at end of file +应用程序和系统日志可以帮助你了解集群内部发生的情况。日志对于调试问题和监视集群活动非常有用。 \ No newline at end of file diff --git a/content/zh/docs/reference/glossary/network-policy.md b/content/zh/docs/reference/glossary/network-policy.md index 10cc5f6b64..864b6760d9 100644 --- a/content/zh/docs/reference/glossary/network-policy.md +++ b/content/zh/docs/reference/glossary/network-policy.md @@ -41,4 +41,7 @@ tags: Network Policies help you declaratively configure which Pods are allowed to connect to each other, which namespaces are allowed to communicate, and more specifically which port numbers to enforce each policy on. `NetworkPolicy` resources use labels to select Pods and define rules which specify what traffic is allowed to the selected Pods. Network Policies are implemented by a supported network plugin provided by a network provider. Be aware that creating a network resource without a controller to implement it will have no effect. --> -网络策略帮助您声明式地配置允许哪些 Pod 之间接、哪些命名空间之间允许进行通信，并具体配置了哪些端口号来执行各个策略。`NetworkPolicy` 资源使用标签来选择 Pod，并定义了所选 Pod 可以接受什么样的流量。网络策略由网络提供商提供的并被 Kubernetes 支持的网络插件实现。请注意，当没有控制器实现网络资源时，创建网络资源将不会生效。 +网络策略帮助你声明式地配置允许哪些 Pod 之间、哪些命名空间之间允许进行通信， +并具体配置了哪些端口号来执行各个策略。`NetworkPolicy` 资源使用标签来选择 Pod， +并定义了所选 Pod 可以接受什么样的流量。网络策略由网络提供商提供的并被 Kubernetes 支持的网络插件实现。 +请注意，当没有控制器实现网络资源时，创建网络资源将不会生效。 diff --git a/content/zh/docs/reference/glossary/pod.md b/content/zh/docs/reference/glossary/pod.md index 873ec90e62..eee257a43d 100644 --- a/content/zh/docs/reference/glossary/pod.md +++ b/content/zh/docs/reference/glossary/pod.md @@ -4,7 +4,7 @@ id: pod date: 2018-04-12 full_link: /docs/concepts/workloads/pods/pod-overview/ short_description: > - Pod 表示您的集群上一组正在运行的容器。 + Pod 表示你的集群上一组正在运行的容器。 aka: tags: diff --git a/content/zh/docs/reference/glossary/volume-plugin.md b/content/zh/docs/reference/glossary/volume-plugin.md index b04b8d8fbc..1071b04390 100644 --- a/content/zh/docs/reference/glossary/volume-plugin.md +++ b/content/zh/docs/reference/glossary/volume-plugin.md @@ -40,7 +40,7 @@ tags: A Volume Plugin lets you attach and mount storage volumes for use by a {{< glossary_tooltip text="Pod" term_id="pod" >}}. Volume plugins can be _in tree_ or _out of tree_. _In tree_ plugins are part of the Kubernetes code repository and follow its release cycle. _Out of tree_ plugins are developed independently. --> -卷插件让您能给 {{< glossary_tooltip text="Pod" term_id="pod" >}} 附加和挂载存储卷。 +卷插件让你能给 {{< glossary_tooltip text="Pod" term_id="pod" >}} 附加和挂载存储卷。 卷插件既可以是 _in tree_ 也可以是 _out of tree_ 。_in tree_ 插件是 Kubernetes 代码库的一部分， 并遵循其发布周期。而 _Out of tree_ 插件则是独立开发的。 diff --git a/content/zh/docs/reference/issues-security/issues.md b/content/zh/docs/reference/issues-security/issues.md index 23a015a519..0cad3c4329 100644 --- a/content/zh/docs/reference/issues-security/issues.md +++ b/content/zh/docs/reference/issues-security/issues.md @@ -1,6 +1,7 @@ --- title: Kubernetes 问题追踪 weight: 10 +aliases: [/zh/cve/, /zh/cves/] --- -与安全性相关的公告请发送到 +与安全性相关的公告将发送到 [kubernetes-security-announce@googlegroups.com](https://groups.google.com/forum/#!forum/kubernetes-security-announce) 邮件列表。 diff --git a/content/zh/docs/reference/issues-security/security.md b/content/zh/docs/reference/issues-security/security.md index 3124098682..a6698022b7 100644 --- a/content/zh/docs/reference/issues-security/security.md +++ b/content/zh/docs/reference/issues-security/security.md @@ -1,5 +1,6 @@ --- title: Kubernetes 安全和信息披露 +aliases: [/zh/security/] content_type: concept weight: 20 --- @@ -27,7 +28,7 @@ This page describes Kubernetes security and disclosure information. -## 安全公告 +## 安全公告 {#security-announcements} -## 报告一个漏洞 +## 报告一个漏洞 {#report-a-vulnerability} 我们非常感谢向 Kubernetes 开源社区报告漏洞的安全研究人员和用户。 所有的报告都由社区志愿者进行彻底调查。 -如需报告，请连同安全细节以及预期的[所有 Kubernetes bug 报告](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE/bug-report.md) -详细信息电子邮件到[security@kubernetes.io](mailto:security@kubernetes.io)列表。 +如需报告，请将你的漏洞提交给 [Kubernetes 漏洞赏金计划](https://hackerone.com/kubernetes)。 +这样做可以使得社区能够在标准化的响应时间内对漏洞进行分类和处理。 你还可以通过电子邮件向私有 [security@kubernetes.io](mailto:security@kubernetes.io) 列表发送电子邮件，邮件中应该包含 [所有 Kubernetes 错误报告](https://github.com/kubernetes/kubernetes/blob/master/.github/ISSUE_TEMPLATE/bug-report.yaml) 所需的详细信息。 + @@ -68,45 +69,45 @@ GPG 密钥加密你的发往邮件列表的邮件。揭示问题时不需要使 -### 我应该在什么时候报告漏洞？ +### 我应该在什么时候报告漏洞？ {#when-should-i-report-a-vulnerability} - 你认为在 Kubernetes 中发现了一个潜在的安全漏洞 - 你不确定漏洞如何影响 Kubernetes - 你认为你在 Kubernetes 依赖的另一个项目中发现了一个漏洞 -- 对于具有漏洞报告和披露流程的项目，请直接在该项目处报告 + - 对于具有漏洞报告和披露流程的项目，请直接在该项目处报告 -### 我什么时候不应该报告漏洞？ +### 我什么时候不应该报告漏洞？ {#when-should-i-not-report-a-vulnerability} -- 你需要帮助调整 Kubernetes 组件的安全性 -- 你需要帮助应用与安全相关的更新 +- 你需要调整 Kubernetes 组件安全性的帮助 +- 你需要应用与安全相关更新的帮助 - 你的问题与安全无关 -## 安全漏洞响应 +## 安全漏洞响应 {#security-vulnerability-response} -每个报告在 3 个工作日内由安全响应委员会成员确认和分析。这将启动[安全发布过程](https://git.k8s.io/sig-release/security-release-process-documentation/security-release-process.md#disclosures)。 +每个报告在 3 个工作日内由安全响应委员会成员确认和分析，这将启动[安全发布过程](https://git.k8s.io/sig-release/security-release-process-documentation/security-release-process.md#disclosures)。 与安全响应委员会共享的任何漏洞信息都保留在 Kubernetes 项目中，除非有必要修复该问题，否则不会传播到其他项目。 @@ -118,7 +119,7 @@ As the security issue moves from triage, to identified fix, to release planning -## 公开披露时间 +## 公开披露时间 {#public-disclosure-timing} -信息披露的时间范围从即时（尤其是已经公开的）到几周。作为一个基本的约定，我们希望报告日期到披露日期的间隔是 7 天。在设置披露日期时，Kubernetes 产品安全团队拥有最终决定权。 - +信息披露的时间范围从即时（尤其是已经公开的）到几周不等。 +对于具有直接缓解措施的漏洞，我们希望报告日期到披露日期的间隔是 7 天。 +在设置披露日期方面，Kubernetes 安全响应委员会拥有最终决定权。 diff --git a/content/zh/docs/reference/kubectl/_index.md b/content/zh/docs/reference/kubectl/_index.md index 5c679220a6..38659b2e8d 100644 --- a/content/zh/docs/reference/kubectl/_index.md +++ b/content/zh/docs/reference/kubectl/_index.md @@ -1,4 +1,1085 @@ --- -title: "kubectl" +title: 命令行工具 (kubectl) +content_type: reference weight: 60 +no_list: true +card: + name: reference + weight: 20 --- + + + +{{< glossary_definition prepend="Kubernetes 提供" term_id="kubectl" length="short" >}} + + +这个工具叫做 `kubectl`。 + + +`针对配置信息，`kubectl` 在 `$HOME/.kube` 目录中查找一个名为 `config` 的配置文件。 +你可以通过设置 `KUBECONFIG` 环境变量或设置 +[`--kubeconfig`](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +参数来指定其它 [kubeconfig](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 文件。 + + +本文概述了 `kubectl` 语法和命令操作描述，并提供了常见的示例。 +有关每个命令的详细信息，包括所有受支持的参数和子命令， +请参阅 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 参考文档。 + + +有关安装说明，请参见[安装 kubectl](/zh/docs/tasks/tools/#kubectl)； +如需快速指南，请参见[备忘单](/zh/docs/reference/kubectl/cheatsheet/)。 +如果你更习惯使用 `docker` 命令行工具， +[Docker 用户的 `kubectl`](/zh/docs/reference/kubectl/docker-cli-to-kubectl/) +介绍了一些 Kubernetes 的等价命令。 + + + +## 语法 + +使用以下语法从终端窗口运行 `kubectl` 命令： + +```shell +kubectl [command] [TYPE] [NAME] [flags] +``` + + +其中 `command`、`TYPE`、`NAME` 和 `flags` 分别是： + + +* `command`：指定要对一个或多个资源执行的操作，例如 `create`、`get`、`describe`、`delete`。 + +* `TYPE`：指定[资源类型](#resource-types)。资源类型不区分大小写， + 可以指定单数、复数或缩写形式。例如，以下命令输出相同的结果： + + ```shell + kubectl get pod pod1 + kubectl get pods pod1 + kubectl get po pod1 + ``` + + +* `NAME`：指定资源的名称。名称区分大小写。 + 如果省略名称，则显示所有资源的详细信息。例如：`kubectl get pods`。 + + 在对多个资源执行操作时，你可以按类型和名称指定每个资源，或指定一个或多个文件： + + + * 要按类型和名称指定资源： + + * 要对所有类型相同的资源进行分组，请执行以下操作：`TYPE1 name1 name2 name<#>`。
    + 例子：`kubectl get pod example-pod1 example-pod2` + + * 分别指定多个资源类型：`TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`。
    + 例子：`kubectl get pod/example-pod1 replicationcontroller/example-rc1` + + * 用一个或多个文件指定资源：`-f file1 -f file2 -f file<#>` + + * [使用 YAML 而不是 JSON](/zh/docs/concepts/configuration/overview/#general-configuration-tips)， + 因为 YAML 对用户更友好, 特别是对于配置文件。
    + 例子：`kubectl get -f ./pod.yaml` + + +* `flags`： 指定可选的参数。例如，可以使用 `-s` 或 `--server` 参数指定 + Kubernetes API 服务器的地址和端口。 + + +{{< caution >}} +从命令行指定的参数会覆盖默认值和任何相应的环境变量。 +{{< /caution >}} + + +如果你需要帮助，在终端窗口中运行 `kubectl help`。 + + +## 集群内身份验证和命名空间覆盖 + + +默认情况下，`kubectl` 命令首先确定它是否在 Pod 中运行，从而被视为在集群中运行。 +它首先检查 `KUBERNETES_SERVICE_HOST` 和 `KUBERNETES_SERVICE_PORT` 环境变量以及 +`/var/run/secrets/kubernetes.io/serviceaccount/token` 中是否存在服务帐户令牌文件。 +如果三个条件都被满足，则假定在集群内进行身份验证。 + + +为保持向后兼容性，如果在集群内身份验证期间设置了 `POD_NAMESPACE` +环境变量，它将覆盖服务帐户令牌中的默认命名空间。 +任何依赖默认命名空间的清单或工具都会受到影响。 + + +**`POD_NAMESPACE` 环境变量** + + +如果设置了 `POD_NAMESPACE` 环境变量，对命名空间资源的 CLI 操作对象将使用该变量值作为默认值。 +例如，如果该变量设置为 `seattle`，`kubectl get pods` 将返回 `seattle` 命名空间中的 Pod。 +这是因为 Pod 是一个命名空间资源，且命令中没有提供命名空间。 + + +直接使用 `--namespace ` 会覆盖此行为。 + + +**kubectl 如何处理 ServiceAccount 令牌** + + +假设： +* 有 Kubernetes 服务帐户令牌文件挂载在 + `/var/run/secrets/kubernetes.io/serviceaccount/token` 上，并且 +* 设置了 `KUBERNETES_SERVICE_HOST` 环境变量，并且 +* 设置了 `KUBERNETES_SERVICE_PORT` 环境变量，并且 +* 你没有在 kubectl 命令行上明确指定命名空间。 + + +然后 kubectl 假定它正在你的集群中运行。 +kubectl 工具查找该 ServiceAccount 的命名空间 +（该命名空间与 Pod 的命名空间相同）并针对该命名空间进行操作。 +这与集群外运行的情况不同； +当 kubectl 在集群外运行并且你没有指定命名空间时， +kubectl 命令会针对 `default` 命名空间进行操作。 + + +## 操作 + + +下表包含所有 kubectl 操作的简短描述和普通语法： + + +操作 | 语法 | 描述 +-------------------- | -------------------- | -------------------- +`alpha` | `kubectl alpha SUBCOMMAND [flags]` | 列出与 alpha 特性对应的可用命令，这些特性在 Kubernetes 集群中默认情况下是不启用的。 +`annotate` | kubectl annotate (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | 添加或更新一个或多个资源的注解。 +`api-resources` | `kubectl api-resources [flags]` | 列出可用的 API 资源。 +`api-versions` | `kubectl api-versions [flags]` | 列出可用的 API 版本。 + +`apply` | `kubectl apply -f FILENAME [flags]`| 从文件或 stdin 对资源应用配置更改。 +`attach` | `kubectl attach POD -c CONTAINER [-i] [-t] [flags]` | 挂接到正在运行的容器，查看输出流或与容器（stdin）交互。 +`auth` | `kubectl auth [flags] [options]` | 检查授权。 +`autoscale` | kubectl autoscale (-f FILENAME | TYPE NAME | TYPE/NAME) [--min=MINPODS] --max=MAXPODS [--cpu-percent=CPU] [flags] | 自动扩缩由副本控制器管理的一组 pod。 +`certificate` | `kubectl certificate SUBCOMMAND [options]` | 修改证书资源。 +`cluster-info` | `kubectl cluster-info [flags]` | 显示有关集群中主服务器和服务的端口信息。 +`completion` | `kubectl completion SHELL [options]` | 为指定的 Shell（Bash 或 Zsh）输出 Shell 补齐代码。 +`config` | `kubectl config SUBCOMMAND [flags]` | 修改 kubeconfig 文件。有关详细信息，请参阅各个子命令。 + +`convert` | `kubectl convert -f FILENAME [options]` | 在不同的 API 版本之间转换配置文件。配置文件可以是 YAML 或 JSON 格式。注意 - 需要安装 `kubectl-convert` 插件。 +`cordon` | `kubectl cordon NODE [options]` | 将节点标记为不可调度。 +`cp` | `kubectl cp [options]` | 从容器复制文件、目录或将文件、目录复制到容器。 +`create` | `kubectl create -f FILENAME [flags]` | 从文件或 stdin 创建一个或多个资源。 +`delete` | kubectl delete (-f FILENAME | TYPE [NAME | /NAME | -l label | --all]) [flags] | 基于文件、标准输入或通过指定标签选择器、名称、资源选择器或资源本身，删除资源。 +`describe` | kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | /NAME | -l label]) [flags] | 显示一个或多个资源的详细状态。 +`diff` | `kubectl diff -f FILENAME [flags]`| 在当前起作用的配置和文件或标准输之间作对比 (**BETA**) + +`drain` | `kubectl drain NODE [options]` | 腾空节点以准备维护。 +`edit` | kubectl edit (-f FILENAME | TYPE NAME | TYPE/NAME) [flags] | 使用默认编辑器编辑和更新服务器上一个或多个资源的定义。 +`exec` | `kubectl exec POD [-c CONTAINER] [-i] [-t] [flags] [-- COMMAND [args...]]` | 对 Pod 中的容器执行命令。 +`explain` | `kubectl explain [--recursive=false] [flags]` | 获取多种资源的文档。例如 Pod、Node、Service 等。 +`expose` | kubectl expose (-f FILENAME | TYPE NAME | TYPE/NAME) [--port=port] [--protocol=TCP|UDP] [--target-port=number-or-name] [--name=name] [--external-ip=external-ip-of-service] [--type=type] [flags] | 将副本控制器、服务或 Pod 作为新的 Kubernetes 服务暴露。 +`get` | kubectl get (-f FILENAME | TYPE [NAME | /NAME | -l label]) [--watch] [--sort-by=FIELD] [[-o | --output]=OUTPUT_FORMAT] [flags] | 列出一个或多个资源。 +`kustomize` | kubectl kustomize [flags] [options]` | 列出从 kustomization.yaml 文件中的指令生成的一组 API 资源。参数必须是包含文件的目录的路径，或者是 git 存储库 URL，其路径后缀相对于存储库根目录指定了相同的路径。 + +`label` | kubectl label (-f FILENAME | TYPE NAME | TYPE/NAME) KEY_1=VAL_1 ... KEY_N=VAL_N [--overwrite] [--all] [--resource-version=version] [flags] | 添加或更新一个或多个资源的标签。 +`logs` | `kubectl logs POD [-c CONTAINER] [--follow] [flags]` | 打印 Pod 中容器的日志。 +`options` | `kubectl options` | 全局命令行选项列表，这些选项适用于所有命令。 +`patch` | kubectl patch (-f FILENAME | TYPE NAME | TYPE/NAME) --patch PATCH [flags] | 使用策略合并流程更新资源的一个或多个字段。 +`plugin` | `kubectl plugin [flags] [options]` | 提供用于与插件交互的实用程序。 +`port-forward` | `kubectl port-forward POD [LOCAL_PORT:]REMOTE_PORT [...[LOCAL_PORT_N:]REMOTE_PORT_N] [flags]` | 将一个或多个本地端口转发到一个 Pod。 +`proxy` | `kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--api-prefix=prefix] [flags]` | 运行访问 Kubernetes API 服务器的代理。 +`replace` | `kubectl replace -f FILENAME` | 基于文件或标准输入替换资源。 +`rollout` | `kubectl rollout SUBCOMMAND [options]` | 管理资源的上线。有效的资源类型包括：Deployment、 DaemonSet 和 StatefulSet。 +`run` | kubectl run NAME --image=image [--env="key=value"] [--port=port] [--dry-run=server | client | none] [--overrides=inline-json] [flags] | 在集群上运行指定的镜像。 + +`scale` | kubectl scale (-f FILENAME | TYPE NAME | TYPE/NAME) --replicas=COUNT [--resource-version=version] [--current-replicas=count] [flags] | 更新指定副本控制器的大小。 +`set` | `kubectl set SUBCOMMAND [options]` | 配置应用资源。 +`taint` | `kubectl taint NODE NAME KEY_1=VAL_1:TAINT_EFFECT_1 ... KEY_N=VAL_N:TAINT_EFFECT_N [options]` | 更新一个或多个节点上的污点。 +`top` | `kubectl top [flags] [options]` | 显示资源（CPU、内存、存储）的使用情况。 +`uncordon` | `kubectl uncordon NODE [options]` | 将节点标记为可调度。 +`version` | `kubectl version [--client] [flags]` | 显示运行在客户端和服务器上的 Kubernetes 版本。 +`wait` | kubectl wait ([-f FILENAME] | resource.group/resource.name | resource.group [(-l label | --all)]) [--for=delete|--for condition=available] [options] | 实验特性：等待一种或多种资源的特定状况。 + + +了解更多有关命令操作的信息， +请参阅 [kubectl](/zh/docs/reference/kubectl/kubectl/) 参考文档。 + + +## 资源类型 + + +下表列出所有受支持的资源类型及其缩写别名。 + + +(以下输出可以通过 `kubectl api-resources` 获取，内容以 Kubernetes 1.19.1 版本为准。) + + +| 资源名 | 缩写名 | API 分组 | 按命名空间 | 资源类型 | +|---|---|---|---|---| +| `bindings` | | | true | Binding | +| `componentstatuses` | `cs` | | false | ComponentStatus | +| `configmaps` | `cm` | | true | ConfigMap | +| `endpoints` | `ep` | | true | Endpoints | +| `events` | `ev` | | true | Event | +| `limitranges` | `limits` | | true | LimitRange | +| `namespaces` | `ns` | | false | Namespace | +| `nodes` | `no` | | false | Node | +| `persistentvolumeclaims` | `pvc` | | true | PersistentVolumeClaim | +| `persistentvolumes` | `pv` | | false | PersistentVolume | +| `pods` | `po` | | true | Pod | +| `podtemplates` | | | true | PodTemplate | +| `replicationcontrollers` | `rc` | | true | ReplicationController | +| `resourcequotas` | `quota` | | true | ResourceQuota | +| `secrets` | | | true | Secret | +| `serviceaccounts` | `sa` | | true | ServiceAccount | +| `services` | `svc` | | true | Service | +| `mutatingwebhookconfigurations` | | admissionregistration.k8s.io | false | MutatingWebhookConfiguration | +| `validatingwebhookconfigurations` | | admissionregistration.k8s.io | false | ValidatingWebhookConfiguration | +| `customresourcedefinitions` | `crd,crds` | apiextensions.k8s.io | false | CustomResourceDefinition | +| `apiservices` | | apiregistration.k8s.io | false | APIService | +| `controllerrevisions` | | apps | true | ControllerRevision | +| `daemonsets` | `ds` | apps | true | DaemonSet | +| `deployments` | `deploy` | apps | true | Deployment | +| `replicasets` | `rs` | apps | true | ReplicaSet | +| `statefulsets` | `sts` | apps | true | StatefulSet | +| `tokenreviews` | | authentication.k8s.io | false | TokenReview | +| `localsubjectaccessreviews` | | authorization.k8s.io | true | LocalSubjectAccessReview | +| `selfsubjectaccessreviews` | | authorization.k8s.io | false | SelfSubjectAccessReview | +| `selfsubjectrulesreviews` | | authorization.k8s.io | false | SelfSubjectRulesReview | +| `subjectaccessreviews` | | authorization.k8s.io | false | SubjectAccessReview | +| `horizontalpodautoscalers` | `hpa` | autoscaling | true | HorizontalPodAutoscaler | +| `cronjobs` | `cj` | batch | true | CronJob | +| `jobs` | | batch | true | Job | +| `certificatesigningrequests` | `csr` | certificates.k8s.io | false | CertificateSigningRequest | +| `leases` | | coordination.k8s.io | true | Lease | +| `endpointslices` | | discovery.k8s.io | true | EndpointSlice | +| `events` | `ev` | events.k8s.io | true | Event | +| `ingresses` | `ing` | extensions | true | Ingress | +| `flowschemas` | | flowcontrol.apiserver.k8s.io | false | FlowSchema | +| `prioritylevelconfigurations` | | flowcontrol.apiserver.k8s.io | false | PriorityLevelConfiguration | +| `ingressclasses` | | networking.k8s.io | false | IngressClass | +| `ingresses` | `ing` | networking.k8s.io | true | Ingress | +| `networkpolicies` | `netpol` | networking.k8s.io | true | NetworkPolicy | +| `runtimeclasses` | | node.k8s.io | false | RuntimeClass | +| `poddisruptionbudgets` | `pdb` | policy | true | PodDisruptionBudget | +| `podsecuritypolicies` | `psp` | policy | false | PodSecurityPolicy | +| `clusterrolebindings` | | rbac.authorization.k8s.io | false | ClusterRoleBinding | +| `clusterroles` | | rbac.authorization.k8s.io | false | ClusterRole | +| `rolebindings` | | rbac.authorization.k8s.io | true | RoleBinding | +| `roles` | | rbac.authorization.k8s.io | true | Role | +| `priorityclasses` | `pc` | scheduling.k8s.io | false | PriorityClass | +| `csidrivers` | | storage.k8s.io | false | CSIDriver | +| `csinodes` | | storage.k8s.io | false | CSINode | +| `storageclasses` | `sc` | storage.k8s.io | false | StorageClass | +| `volumeattachments` | | storage.k8s.io | false | VolumeAttachment | + + + +## 输出选项 + + +有关如何格式化或排序某些命令的输出的信息，请参阅以下章节。有关哪些命令支持不同输出选项的详细信息， +请参阅 [kubectl](/zh/docs/reference/kubectl/kubectl/) 参考文档。 + + +### 格式化输出 + + +所有 `kubectl` 命令的默认输出格式都是人类可读的纯文本格式。要以特定格式在终端窗口输出详细信息， +可以将 `-o` 或 `--output` 参数添加到受支持的 `kubectl` 命令中。 + + +#### 语法 + +```shell +kubectl [command] [TYPE] [NAME] -o +``` + + +取决于具体的 `kubectl` 操作，支持的输出格式如下： + + +输出格式 | 描述 +--------------| ----------- +`-o custom-columns=` | 使用逗号分隔的[自定义列](#custom-columns)列表打印表。 +`-o custom-columns-file=` | 使用 `` 文件中的[自定义列](#custom-columns)模板打印表。 +`-o json` | 输出 JSON 格式的 API 对象 +`-o jsonpath=