diff --git a/Makefile b/Makefile index 57fca6e2d1..e0569404d6 100644 --- a/Makefile +++ b/Makefile @@ -71,6 +71,9 @@ container-image: ## Build a container image for the preview of the website --tag $(CONTAINER_IMAGE) \ --build-arg HUGO_VERSION=$(HUGO_VERSION) +container-push: container-image ## Push container image for the preview of the website + $(CONTAINER_ENGINE) push $(CONTAINER_IMAGE) + container-build: module-check $(CONTAINER_RUN) --read-only --mount type=tmpfs,destination=/tmp,tmpfs-mode=01777 $(CONTAINER_IMAGE) sh -c "npm ci && hugo --minify --environment development" diff --git a/OWNERS_ALIASES b/OWNERS_ALIASES index 76bf2cd73a..591ec8f9c9 100644 --- a/OWNERS_ALIASES +++ b/OWNERS_ALIASES @@ -24,6 +24,7 @@ aliases: - jimangel - jlbutler - kbhawkey + - kcmartin - natalisucks - onlydole - pi-victor @@ -179,6 +180,7 @@ aliases: - tanjunchen - tengqm - xichengliudui + - ydFu # zhangxiaoyu-zidif sig-docs-pt-owners: # Admins for Portuguese content - edsoncelio @@ -249,7 +251,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/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/cloudbuild.yaml b/cloudbuild.yaml index 5039818482..542d58016c 100644 --- a/cloudbuild.yaml +++ b/cloudbuild.yaml @@ -9,17 +9,20 @@ options: steps: # It's fine to bump the tag to a recent version, as needed - name: "gcr.io/k8s-staging-test-infra/gcb-docker-gcloud:v20210917-12df099d55" - entrypoint: make + entrypoint: 'bash' env: - DOCKER_CLI_EXPERIMENTAL=enabled - TAG=$_GIT_TAG - BASE_REF=$_PULL_BASE_REF args: - - container-image + - -c + - | + gcloud auth configure-docker \ + && make container-push substitutions: # _GIT_TAG will be filled with a git-based tag for the image, of the form vYYYYMMDD-hash, and # can be used as a substitution _GIT_TAG: "12345" # _PULL_BASE_REF will contain the ref that was pushed to to trigger this build - - # a branch like 'master' or 'release-0.2', or a tag like 'v0.2'. - _PULL_BASE_REF: "master" + # a branch like 'main' or 'release-0.2', or a tag like 'v0.2'. + _PULL_BASE_REF: "main" diff --git a/config.toml b/config.toml index 6ad3ac39f3..19c7da4e6c 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 8 - 2 = 254 -Band Offset: `min(max(16,256/16),256)` = `min(16,256)` = 16 +Band Offset: `min(max(16, 256/16), 256)` = `min(16, 256)` = 16 Static band start: 10.96.0.1 Static band end: 10.96.0.16 Range end: 10.96.0.254 @@ -101,7 +101,7 @@ pie showData #### Service IP CIDR block: 10.96.0.0/20 Range Size: 212 - 2 = 4094 -Band Offset: `min(max(16,256/16),256)` = `min(256,256)` = 256 +Band Offset: `min(max(16, 4096/16), 256)` = `min(256, 256)` = 256 Static band start: 10.96.0.1 Static band end: 10.96.1.0 Range end: 10.96.15.254 @@ -116,7 +116,7 @@ pie showData #### Service IP CIDR block: 10.96.0.0/16 Range Size: 216 - 2 = 65534 -Band Offset: `min(max(16,65536/16),256)` = `min(4096,256)` = 256 +Band Offset: `min(max(16, 65536/16), 256)` = `min(4096, 256)` = 256 Static band start: 10.96.0.1 Static band ends: 10.96.1.0 Range end: 10.96.255.254 diff --git a/content/en/blog/_posts/2022-05-25-contextual-logging/index.md b/content/en/blog/_posts/2022-05-25-contextual-logging/index.md new file mode 100644 index 0000000000..2d5ef5c4c7 --- /dev/null +++ b/content/en/blog/_posts/2022-05-25-contextual-logging/index.md @@ -0,0 +1,251 @@ +--- +layout: blog +title: "Contextual Logging in Kubernetes 1.24" +date: 2022-05-25 +slug: contextual-logging +canonicalUrl: https://kubernetes.dev/blog/2022/05/25/contextual-logging/ +--- + + **Authors:** Patrick Ohly (Intel) + +The [Structured Logging Working +Group](https://github.com/kubernetes/community/blob/master/wg-structured-logging/README.md) +has added new capabilities to the logging infrastructure in Kubernetes +1.24. This blog post explains how developers can take advantage of those to +make log output more useful and how they can get involved with improving Kubernetes. + +## Structured logging + +The goal of [structured +logging](https://github.com/kubernetes/enhancements/blob/master/keps/sig-instrumentation/1602-structured-logging/README.md) +is to replace C-style formatting and the resulting opaque log strings with log +entries that have a well-defined syntax for storing message and parameters +separately, for example as a JSON struct. + +When using the traditional klog text output format for structured log calls, +strings were originally printed with `\n` escape sequences, except when +embedded inside a struct. For structs, log entries could still span multiple +lines, with no clean way to split the log stream into individual entries: + +``` +I1112 14:06:35.783529 328441 structured_logging.go:51] "using InfoS" longData={Name:long Data:Multiple +lines +with quite a bit +of text. internal:0} +I1112 14:06:35.783549 328441 structured_logging.go:52] "using InfoS with\nthe message across multiple lines" int=1 stringData="long: Multiple\nlines\nwith quite a bit\nof text." str="another value" +``` + +Now, the `<` and `>` 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/blog/_posts/2022-06-01-annual-report-2021.md b/content/en/blog/_posts/2022-06-01-annual-report-2021.md new file mode 100644 index 0000000000..e0a4130357 --- /dev/null +++ b/content/en/blog/_posts/2022-06-01-annual-report-2021.md @@ -0,0 +1,19 @@ +--- +layout: blog +title: "Annual Report Summary 2021" +date: 2022-06-01 +slug: annual-report-summary-2021 +--- + +**Author:** Paris Pittman (Steering Committee) + +Last year, we published our first [Annual Report Summary](/blog/2021/06/28/announcing-kubernetes-community-group-annual-reports/) for 2020 and it's already time for our second edition! + +[2021 Annual Report Summary](https://www.cncf.io/reports/kubernetes-annual-report-2021/) + +This summary reflects the work that has been done in 2021 and the initiatives on deck for the rest of 2022. Please forward to organizations and indidviduals participating in upstream activities, planning cloud native strategies, and/or those looking to help out. To find a specific community group's complete report, go to the [kubernetes/community repo](https://github.com/kubernetes/community) under the groups folder. Example: [sig-api-machinery/annual-report-2021.md](https://github.com/kubernetes/community/blob/master/sig-api-machinery/annual-report-2021.md) + +You’ll see that this report summary is a growth area in itself. It takes us roughly 6 months to prepare and execute, which isn’t helpful or valuable to anyone as a fast moving project with short and long term needs. How can we make this better? Provide your feedback here: https://github.com/kubernetes/steering/issues/242 + +Reference: +[Annual Report Documentation](https://github.com/kubernetes/community/blob/master/committee-steering/governance/annual-reports.md) diff --git a/content/en/docs/concepts/architecture/control-plane-node-communication.md b/content/en/docs/concepts/architecture/control-plane-node-communication.md index a4814aab4b..e2004f146c 100644 --- a/content/en/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/en/docs/concepts/architecture/control-plane-node-communication.md @@ -21,7 +21,7 @@ This document catalogs the communication paths between the control plane (apiser Kubernetes has a "hub-and-spoke" API pattern. All API usage from nodes (or the pods they run) terminates at the apiserver. None of the other control plane components are designed to expose remote services. The apiserver is configured to listen for remote connections on a secure HTTPS port (typically 443) with one or more forms of client [authentication](/docs/reference/access-authn-authz/authentication/) enabled. One or more forms of [authorization](/docs/reference/access-authn-authz/authorization/) should be enabled, especially if [anonymous requests](/docs/reference/access-authn-authz/authentication/#anonymous-requests) or [service account tokens](/docs/reference/access-authn-authz/authentication/#service-account-tokens) are allowed. -Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. A good approach is that the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates. +Nodes should be provisioned with the public root certificate for the cluster such that they can connect securely to the apiserver along with valid client credentials. A good approach is that the client credentials provided to the kubelet are in the form of a client certificate. See [kubelet TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) for automated provisioning of kubelet client certificates. Pods that wish to connect to the apiserver can do so securely by leveraging a service account so that Kubernetes will automatically inject the public root certificate and a valid bearer token into the pod when it is instantiated. The `kubernetes` service (in `default` namespace) is configured with a virtual IP address that is redirected (via kube-proxy) to the HTTPS endpoint on the apiserver. @@ -49,7 +49,7 @@ To verify this connection, use the `--kubelet-certificate-authority` flag to pro If that is not possible, use [SSH tunneling](#ssh-tunnels) between the apiserver and kubelet if required to avoid connecting over an untrusted or public network. -Finally, [Kubelet authentication and/or authorization](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) should be enabled to secure the kubelet API. +Finally, [Kubelet authentication and/or authorization](/docs/reference/access-authn-authz/kubelet-authn-authz/) should be enabled to secure the kubelet API. ### apiserver to nodes, pods, and services diff --git a/content/en/docs/concepts/architecture/nodes.md b/content/en/docs/concepts/architecture/nodes.md index 39d229a897..2321fc6474 100644 --- a/content/en/docs/concepts/architecture/nodes.md +++ b/content/en/docs/concepts/architecture/nodes.md @@ -458,7 +458,7 @@ Message: Pod was terminated in response to imminent node shutdown. {{< feature-state state="alpha" for_k8s_version="v1.24" >}} -A node shutdown action may not be detected by kubelet's Node Shutdown Mananger, +A node shutdown action may not be detected by kubelet's Node Shutdown Manager, either because the command does not trigger the inhibitor locks mechanism used by kubelet or because of a user error, i.e., the ShutdownGracePeriod and ShutdownGracePeriodCriticalPods are not configured properly. Please refer to above @@ -654,7 +654,7 @@ see [KEP-2400](https://github.com/kubernetes/enhancements/issues/2400) and its * Learn about the [components](/docs/concepts/overview/components/#node-components) that make up a node. * Read the [API definition for Node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core). -* Read the [Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) +* Read the [Node](https://git.k8s.io/design-proposals-archive/architecture/architecture.md#the-kubernetes-node) section of the architecture design document. * Read about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/). diff --git a/content/en/docs/concepts/cluster-administration/_index.md b/content/en/docs/concepts/cluster-administration/_index.md index 7e5827a6f7..ace5297b33 100644 --- a/content/en/docs/concepts/cluster-administration/_index.md +++ b/content/en/docs/concepts/cluster-administration/_index.md @@ -63,8 +63,8 @@ Before choosing a guide, here are some considerations: ### Securing the kubelet * [Control Plane-Node communication](/docs/concepts/architecture/control-plane-node-communication/) - * [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) - * [Kubelet authentication/authorization](/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) + * [TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) + * [Kubelet authentication/authorization](/docs/reference/acess-authn-authz/kubelet-authn-authz/) ## Optional Cluster Services diff --git a/content/en/docs/concepts/cluster-administration/addons.md b/content/en/docs/concepts/cluster-administration/addons.md index 20626f2ff4..5f7df077c9 100644 --- a/content/en/docs/concepts/cluster-administration/addons.md +++ b/content/en/docs/concepts/cluster-administration/addons.md @@ -18,19 +18,19 @@ This page lists some of the available add-ons and links to their respective inst * [ACI](https://www.github.com/noironetworks/aci-containers) provides integrated container networking and network security with Cisco ACI. * [Antrea](https://antrea.io/) operates at Layer 3/4 to provide networking and security services for Kubernetes, leveraging Open vSwitch as the networking data plane. * [Calico](https://docs.projectcalico.org/latest/introduction/) is a networking and network policy provider. Calico supports a flexible set of networking options so you can choose the most efficient option for your situation, including non-overlay and overlay networks, with or without BGP. Calico uses the same engine to enforce network policy for hosts, pods, and (if using Istio & Envoy) applications at the service mesh layer. -* [Canal](https://github.com/tigera/canal/tree/master/k8s-install) unites Flannel and Calico, providing networking and network policy. +* [Canal](https://projectcalico.docs.tigera.io/getting-started/kubernetes/flannel/flannel) unites Flannel and Calico, providing networking and network policy. * [Cilium](https://github.com/cilium/cilium) is a L3 network and network policy plugin that can enforce HTTP/API/L7 policies transparently. Both routing and overlay/encapsulation mode are supported, and it can work on top of other CNI plugins. -* [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) enables Kubernetes to seamlessly connect to a choice of CNI plugins, such as Calico, Canal, Flannel, Romana, or Weave. +* [CNI-Genie](https://github.com/cni-genie/CNI-Genie) enables Kubernetes to seamlessly connect to a choice of CNI plugins, such as Calico, Canal, Flannel, or Weave. * [Contiv](https://contivpp.io/) provides configurable networking (native L3 using BGP, overlay using vxlan, classic L2, and Cisco-SDN/ACI) for various use cases and a rich policy framework. Contiv project is fully [open sourced](https://github.com/contiv). The [installer](https://github.com/contiv/install) provides both kubeadm and non-kubeadm based installation options. * [Contrail](https://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/), based on [Tungsten Fabric](https://tungsten.io), is an open source, multi-cloud network virtualization and policy management platform. Contrail and Tungsten Fabric are integrated with orchestration systems such as Kubernetes, OpenShift, OpenStack and Mesos, and provide isolation modes for virtual machines, containers/pods and bare metal workloads. * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) is an overlay network provider that can be used with Kubernetes. * [Knitter](https://github.com/ZTE/Knitter/) is a plugin to support multiple network interfaces in a Kubernetes pod. -* Multus is a Multi plugin for multiple network support in Kubernetes to support all CNI plugins (e.g. Calico, Cilium, Contiv, Flannel), in addition to SRIOV, DPDK, OVS-DPDK and VPP based workloads in Kubernetes. +* [Multus](https://github.com/k8snetworkplumbingwg/multus-cni) is a Multi plugin for multiple network support in Kubernetes to support all CNI plugins (e.g. Calico, Cilium, Contiv, Flannel), in addition to SRIOV, DPDK, OVS-DPDK and VPP based workloads in Kubernetes. * [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) is a networking provider for Kubernetes based on [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/), a virtual networking implementation that came out of the Open vSwitch (OVS) project. OVN-Kubernetes provides an overlay based networking implementation for Kubernetes, including an OVS based implementation of load balancing and network policy. -* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) is OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC), Multiple OVN overlay networking, dynamic subnet creation, dynamic creation of virtual networks, VLAN Provider network, Direct provider network and pluggable with other Multi-network plugins, ideal for edge based cloud native workloads in Multi-cluster networking -* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) provides integration between VMware NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift. +* [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) is OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC), Multiple OVN overlay networking, dynamic subnet creation, dynamic creation of virtual networks, VLAN Provider network, Direct provider network and pluggable with other Multi-network plugins, ideal for edge based cloud native workloads in Multi-cluster networking. +* [NSX-T](https://docs.vmware.com/en/VMware-NSX-T-Data-Center/index.html) Container Plug-in (NCP) provides integration between VMware NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift. * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) is an SDN platform that provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring. -* **Romana** is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize). +* [Romana](https://github.com/romana) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy](/docs/concepts/services-networking/network-policies/) API. * [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database. ## Service Discovery diff --git a/content/en/docs/concepts/cluster-administration/flow-control.md b/content/en/docs/concepts/cluster-administration/flow-control.md index 7f5e476020..dffad13318 100644 --- a/content/en/docs/concepts/cluster-administration/flow-control.md +++ b/content/en/docs/concepts/cluster-administration/flow-control.md @@ -174,7 +174,7 @@ to balance progress between request flows. The queuing configuration allows tuning the fair queuing algorithm for a priority level. Details of the algorithm can be read in the -[enhancement proposal](#whats-next), but in short: +[enhancement proposal](#what-s-next), but in short: * Increasing `queues` reduces the rate of collisions between different flows, at the cost of increased memory usage. A value of 1 here effectively disables the diff --git a/content/en/docs/concepts/cluster-administration/networking.md b/content/en/docs/concepts/cluster-administration/networking.md index 9fed36c2fd..b780ef15ca 100644 --- a/content/en/docs/concepts/cluster-administration/networking.md +++ b/content/en/docs/concepts/cluster-administration/networking.md @@ -203,4 +203,4 @@ to run, and in both cases, the network provides one IP address per pod - as is s The early design of the networking model and its rationale, and some future plans are described in more detail in the -[networking design document](https://git.k8s.io/community/contributors/design-proposals/network/networking.md). +[networking design document](https://git.k8s.io/design-proposals-archive/network/networking.md). 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/configuration/windows-resource-management.md b/content/en/docs/concepts/configuration/windows-resource-management.md index 6593caa5fb..955fea194a 100644 --- a/content/en/docs/concepts/configuration/windows-resource-management.md +++ b/content/en/docs/concepts/configuration/windows-resource-management.md @@ -32,52 +32,48 @@ host, and thus privileged containers are not available on Windows. Containers cannot assume an identity from the host because the Security Account Manager (SAM) is separate. -## Memory reservations {#resource-management-memory} +## Memory management {#resource-management-memory} Windows does not have an out-of-memory process killer as Linux does. Windows always treats all user-mode memory allocations as virtual, and pagefiles are mandatory. -Windows nodes do not overcommit memory for processes running in containers. The +Windows nodes do not overcommit memory for processes. The net effect is that Windows won't reach out of memory conditions the same way Linux does, and processes page to disk instead of being subject to out of memory (OOM) termination. If memory is over-provisioned and all physical memory is exhausted, then paging can slow down performance. -You can place bounds on memory use for workloads using the kubelet -parameters `--kubelet-reserve` and/or `--system-reserve`; these account -for memory usage on the node (outside of containers), and reduce -[NodeAllocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable). -As you deploy workloads, set resource limits on containers. This also subtracts from -`NodeAllocatable` and prevents the scheduler from adding more pods once a node is full. +## CPU management {#resource-management-cpu} -{{< note >}} -When you set memory resource limits for Windows containers, you should either set a -limit and leave the memory request unspecified, or set the request equal to the limit. -{{< /note >}} +Windows can limit the amount of CPU time allocated for different processes but cannot +guarantee a minimum amount of CPU time. -On Windows, good practice to avoid over-provisioning is to configure the kubelet -with a system reserved memory of at least 2GiB to account for Windows, Kubernetes -and container runtime overheads. - -## CPU reservations {#resource-management-cpu} - -To account for CPU use by the operating system, the container runtime, and by -Kubernetes host processes such as the kubelet, you can (and should) reserve a -percentage of total CPU. You should determine this CPU reservation taking account of -to the number of CPU cores available on the node. To decide on the CPU percentage to -reserve, identify the maximum pod density for each node and monitor the CPU usage of -the system services running there, then choose a value that meets your workload needs. - -You can place bounds on CPU usage for workloads using the -kubelet parameters `--kubelet-reserve` and/or `--system-reserve` to -account for CPU usage on the node (outside of containers). -This reduces `NodeAllocatable`. -The cluster-wide scheduler then takes this reservation into account when determining -pod placement. - -On Windows, the kubelet supports a command-line flag to set the priority of the +On Windows, the kubelet supports a command-line flag to set the +[scheduling priority](https://docs.microsoft.com/windows/win32/procthread/scheduling-priorities) of the kubelet process: `--windows-priorityclass`. This flag allows the kubelet process to get more CPU time slices when compared to other processes running on the Windows host. More information on the allowable values and their meaning is available at [Windows Priority Classes](https://docs.microsoft.com/en-us/windows/win32/procthread/scheduling-priorities#priority-class). To ensure that running Pods do not starve the kubelet of CPU cycles, set this flag to `ABOVE_NORMAL_PRIORITY_CLASS` or above. + +## Resource reservation {#resource-reservation} + +To account for memory and CPU used by the operating system, the container runtime, and by +Kubernetes host processes such as the kubelet, you can (and should) reserve +memory and CPU resources with the `--kube-reserved` and/or `--system-reserved` kubelet flags. +On Windows these values are only used to calculate the node's +[allocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) resources. + +{{< caution >}} +As you deploy workloads, set resource memory and CPU limits on containers. +This also subtracts from `NodeAllocatable` and helps the cluster-wide scheduler in determining which pods to place on which nodes. + +Scheduling pods without limits may over-provision the Windows nodes and in extreme +cases can cause the nodes to become unhealthy. +{{< /caution >}} + +On Windows, a good practice is to reserve at least 2GiB of memory. + +To determine how much CPU to reserve, +identify the maximum pod density for each node and monitor the CPU usage of +the system services running there, then choose a value that meets your workload needs. diff --git a/content/en/docs/concepts/extend-kubernetes/_index.md b/content/en/docs/concepts/extend-kubernetes/_index.md index 3cf3eb1f7a..c50010a39f 100644 --- a/content/en/docs/concepts/extend-kubernetes/_index.md +++ b/content/en/docs/concepts/extend-kubernetes/_index.md @@ -160,7 +160,7 @@ After a request is authorized, if it is a write operation, it also goes through ### Storage Plugins -[Flex Volumes](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/flexvolume-deployment.md +[Flex Volumes](https://git.k8s.io/design-proposals-archive/storage/flexvolume-deployment.md ) allow users to mount volume types without built-in support by having the Kubelet call a Binary Plugin to mount the volume. @@ -191,7 +191,7 @@ This is a significant undertaking, and almost all Kubernetes users find they do not need to modify the scheduler. The scheduler also supports a -[webhook](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/scheduler_extender.md) +[webhook](https://git.k8s.io/design-proposals-archive/scheduling/scheduler_extender.md) that permits a webhook backend (scheduler extension) to filter and prioritize the nodes chosen for a pod. diff --git a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index 6785dccdac..6f265f57f3 100644 --- a/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/en/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -8,7 +8,7 @@ weight: 20 {{< feature-state for_k8s_version="v1.10" state="beta" >}} -Kubernetes provides a [device plugin framework](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/resource-management/device-plugin.md) +Kubernetes provides a [device plugin framework](https://git.k8s.io/design-proposals-archive/resource-management/device-plugin.md) that you can use to advertise system hardware resources to the {{< glossary_tooltip term_id="kubelet" >}}. 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..133814e98a 100644 --- a/content/en/docs/concepts/extend-kubernetes/operator.md +++ b/content/en/docs/concepts/extend-kubernetes/operator.md @@ -111,7 +111,9 @@ 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) +* [kube-rs](https://kube.rs/) (Rust) * [kubebuilder](https://book.kubebuilder.io/) * [KubeOps](https://buehler.github.io/dotnet-operator-sdk/) (.NET operator SDK) * [KUDO](https://kudo.dev/) (Kubernetes Universal Declarative Operator) diff --git a/content/en/docs/concepts/overview/kubernetes-api.md b/content/en/docs/concepts/overview/kubernetes-api.md index 3c0bba3adb..b72d1aab1f 100644 --- a/content/en/docs/concepts/overview/kubernetes-api.md +++ b/content/en/docs/concepts/overview/kubernetes-api.md @@ -76,7 +76,7 @@ request headers as follows: Kubernetes implements an alternative Protobuf based serialization format that is primarily intended for intra-cluster communication. For more information -about this format, see the [Kubernetes Protobuf serialization](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/protobuf.md) design proposal and the +about this format, see the [Kubernetes Protobuf serialization](https://git.k8s.io/design-proposals-archive/api-machinery/protobuf.md) design proposal and the Interface Definition Language (IDL) files for each schema located in the Go packages that define the API objects. diff --git a/content/en/docs/concepts/overview/working-with-objects/names.md b/content/en/docs/concepts/overview/working-with-objects/names.md index 9bafb1584c..7b6b380e35 100644 --- a/content/en/docs/concepts/overview/working-with-objects/names.md +++ b/content/en/docs/concepts/overview/working-with-objects/names.md @@ -100,4 +100,4 @@ UUIDs are standardized as ISO/IEC 9834-8 and as ITU-T X.667. ## {{% heading "whatsnext" %}} * Read about [labels](/docs/concepts/overview/working-with-objects/labels/) in Kubernetes. -* See the [Identifiers and Names in Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) design document. +* See the [Identifiers and Names in Kubernetes](https://git.k8s.io/design-proposals-archive/architecture/identifiers.md) design document. diff --git a/content/en/docs/concepts/policy/limit-range.md b/content/en/docs/concepts/policy/limit-range.md index 8158b78437..f5a7e66cac 100644 --- a/content/en/docs/concepts/policy/limit-range.md +++ b/content/en/docs/concepts/policy/limit-range.md @@ -53,7 +53,7 @@ Neither contention nor changes to a LimitRange will affect already created resou ## {{% heading "whatsnext" %}} -Refer to the [LimitRanger design document](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_limit_range.md) for more information. +Refer to the [LimitRanger design document](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_limit_range.md) for more information. For examples on using limits, see: diff --git a/content/en/docs/concepts/policy/resource-quotas.md b/content/en/docs/concepts/policy/resource-quotas.md index 0e88ca3433..8d9490b828 100644 --- a/content/en/docs/concepts/policy/resource-quotas.md +++ b/content/en/docs/concepts/policy/resource-quotas.md @@ -22,8 +22,7 @@ be consumed by resources in that namespace. Resource quotas work like this: -- Different teams work in different namespaces. Currently this is voluntary, but - support for making this mandatory via ACLs is planned. +- Different teams work in different namespaces. This can be enforced with [RBAC](/docs/reference/access-authn-authz/rbac/). - The administrator creates one ResourceQuota for each namespace. @@ -698,7 +697,7 @@ and it is to be created in a namespace other than `kube-system`. ## {{% heading "whatsnext" %}} -- See [ResourceQuota design doc](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) for more information. +- See [ResourceQuota design doc](https://git.k8s.io/design-proposals-archive/resource-management/admission_control_resource_quota.md) for more information. - See a [detailed example for how to use resource quota](/docs/tasks/administer-cluster/quota-api-object/). -- Read [Quota support for priority class design doc](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md). +- Read [Quota support for priority class design doc](https://git.k8s.io/design-proposals-archive/scheduling/pod-priority-resourcequota.md). - See [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765) 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..8d3cc1831c 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://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md). You can use the `In`, `NotIn`, `Exists` and `DoesNotExist` values in the `operator` field for Pod affinity and anti-affinity. @@ -472,8 +471,8 @@ The above Pod will only run on the node `kube-01`. ## {{% heading "whatsnext" %}} * Read more about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/) . -* Read the design docs for [node affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md) - and for [inter-pod affinity/anti-affinity](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md). +* Read the design docs for [node affinity](https://git.k8s.io/design-proposals-archive/scheduling/nodeaffinity.md) + and for [inter-pod affinity/anti-affinity](https://git.k8s.io/design-proposals-archive/scheduling/podaffinity.md). * Learn about how the [topology manager](/docs/tasks/administer-cluster/topology-manager/) takes part in node-level resource allocation decisions. * Learn how to use [nodeSelector](/docs/tasks/configure-pod-container/assign-pods-nodes/). diff --git a/content/en/docs/concepts/scheduling-eviction/pod-overhead.md b/content/en/docs/concepts/scheduling-eviction/pod-overhead.md index 72b160653e..2610ea80ad 100644 --- a/content/en/docs/concepts/scheduling-eviction/pod-overhead.md +++ b/content/en/docs/concepts/scheduling-eviction/pod-overhead.md @@ -97,7 +97,7 @@ The output is: map[cpu:250m memory:120Mi] ``` -If a ResourceQuota is defined, the sum of container requests as well as the +If a [ResourceQuota](/docs/concepts/policy/resource-quotas/) is defined, the sum of container requests as well as the `overhead` field are counted. When the kube-scheduler is deciding which node should run a new Pod, the scheduler considers that Pod's diff --git a/content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md index a81d9904ac..951d3f273d 100644 --- a/content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md +++ b/content/en/docs/concepts/scheduling-eviction/resource-bin-packing.md @@ -3,70 +3,100 @@ reviewers: - bsalamat - k82cn - ahg-g -title: Resource Bin Packing for Extended Resources +title: Resource Bin Packing content_type: concept weight: 80 --- -{{< feature-state for_k8s_version="v1.16" state="alpha" >}} - -The kube-scheduler can be configured to enable bin packing of resources along -with extended resources using `RequestedToCapacityRatioResourceAllocation` -priority function. Priority functions can be used to fine-tune the -kube-scheduler as per custom needs. +In the [scheduling-plugin](/docs/reference/scheduling/config/#scheduling-plugins) `NodeResourcesFit` of kube-scheduler, there are two +scoring strategies that support the bin packing of resources: `MostAllocated` and `RequestedToCapacityRatio`. -## Enabling Bin Packing using RequestedToCapacityRatioResourceAllocation +## Enabling bin packing using MostAllocated strategy +The `MostAllocated` strategy scores the nodes based on the utilization of resources, favoring the ones with higher allocation. +For each resource type, you can set a weight to modify its influence in the node score. -Kubernetes allows the users to specify the resources along with weights for +To set the `MostAllocated` strategy for the `NodeResourcesFit` plugin, use a +[scheduler configuration](/docs/reference/scheduling/config) similar to the following: + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta3 +kind: KubeSchedulerConfiguration +profiles: +- pluginConfig: + - args: + scoringStrategy: + resources: + - name: cpu + weight: 1 + - name: memory + weight: 1 + - name: intel.com/foo + weight: 3 + - name: intel.com/bar + weight: 3 + type: MostAllocated + name: NodeResourcesFit +``` + +To learn more about other parameters and their default configuration, see the API documentation for +[`NodeResourcesFitArgs`](/docs/reference/config-api/kube-scheduler-config.v1beta3/#kubescheduler-config-k8s-io-v1beta3-NodeResourcesFitArgs). + +## Enabling bin packing using RequestedToCapacityRatio + +The `RequestedToCapacityRatio` strategy allows the users to specify the resources along with weights for each resource to score nodes based on the request to capacity ratio. This allows users to bin pack extended resources by using appropriate parameters -and improves the utilization of scarce resources in large clusters. The -behavior of the `RequestedToCapacityRatioResourceAllocation` priority function -can be controlled by a configuration option called `RequestedToCapacityRatioArgs`. -This argument consists of two parameters `shape` and `resources`. The `shape` +to improve the utilization of scarce resources in large clusters. It favors nodes according to a +configured function of the allocated resources. The behavior of the `RequestedToCapacityRatio` in +the `NodeResourcesFit` score function can be controlled by the +[scoringStrategy](/docs/reference/config-api/kube-scheduler-config.v1beta3/#kubescheduler-config-k8s-io-v1beta3-ScoringStrategy) field. +Within the `scoringStrategy` field, you can configure two parameters: `requestedToCapacityRatioParam` and +`resources`. The `shape` in `requestedToCapacityRatioParam` parameter allows the user to tune the function as least requested or most requested based on `utilization` and `score` values. The `resources` parameter consists of `name` of the resource to be considered during scoring and `weight` specify the weight of each resource. Below is an example configuration that sets -`requestedToCapacityRatioArguments` to bin packing behavior for extended -resources `intel.com/foo` and `intel.com/bar`. +the bin packing behavior for extended resources `intel.com/foo` and `intel.com/bar` +using the `requestedToCapacityRatio` field. ```yaml apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: -# ... - pluginConfig: - - name: RequestedToCapacityRatio - args: - shape: - - utilization: 0 - score: 10 - - utilization: 100 - score: 0 - resources: - - name: intel.com/foo - weight: 3 - - name: intel.com/bar - weight: 5 +- pluginConfig: + - args: + scoringStrategy: + resources: + - name: intel.com/foo + weight: 3 + - name: intel.com/bar + weight: 3 + requestedToCapacityRatioParam: + shape: + - utilization: 0 + score: 0 + - utilization: 100 + score: 10 + type: RequestedToCapacityRatio + name: NodeResourcesFit ``` Referencing the `KubeSchedulerConfiguration` file with the kube-scheduler flag `--config=/path/to/config/file` will pass the configuration to the scheduler. -**This feature is disabled by default** +To learn more about other parameters and their default configuration, see the API documentation for +[`NodeResourcesFitArgs`](/docs/reference/config-api/kube-scheduler-config.v1beta3/#kubescheduler-config-k8s-io-v1beta3-NodeResourcesFitArgs). -### Tuning the Priority Function +### Tuning the score function -`shape` is used to specify the behavior of the -`RequestedToCapacityRatioPriority` function. +`shape` is used to specify the behavior of the `RequestedToCapacityRatio` function. ```yaml shape: 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..921d69e8fb 100644 --- a/content/en/docs/concepts/services-networking/dual-stack.md +++ b/content/en/docs/concepts/services-networking/dual-stack.md @@ -1,16 +1,15 @@ --- -reviewers: -- lachie83 -- khenidak -- aramase -- bridgetkromhout title: IPv4/IPv6 dual-stack feature: title: IPv4/IPv6 dual-stack description: > Allocation of IPv4 and IPv6 addresses to Pods and Services - content_type: concept +reviewers: + - lachie83 + - khenidak + - aramase + - bridgetkromhout weight: 70 --- @@ -18,11 +17,11 @@ weight: 70 {{< feature-state for_k8s_version="v1.23" state="stable" >}} -IPv4/IPv6 dual-stack networking enables the allocation of both IPv4 and IPv6 addresses to {{< glossary_tooltip text="Pods" term_id="pod" >}} and {{< glossary_tooltip text="Services" term_id="service" >}}. - -IPv4/IPv6 dual-stack networking is enabled by default for your Kubernetes cluster starting in 1.21, allowing the simultaneous assignment of both IPv4 and IPv6 addresses. - +IPv4/IPv6 dual-stack networking enables the allocation of both IPv4 and IPv6 addresses to +{{< glossary_tooltip text="Pods" term_id="pod" >}} and {{< glossary_tooltip text="Services" term_id="service" >}}. +IPv4/IPv6 dual-stack networking is enabled by default for your Kubernetes cluster starting in +1.21, allowing the simultaneous assignment of both IPv4 and IPv6 addresses. @@ -30,68 +29,78 @@ IPv4/IPv6 dual-stack networking is enabled by default for your Kubernetes cluste IPv4/IPv6 dual-stack on your Kubernetes cluster provides the following features: - * Dual-stack Pod networking (a single IPv4 and IPv6 address assignment per Pod) - * IPv4 and IPv6 enabled Services - * Pod off-cluster egress routing (eg. the Internet) via both IPv4 and IPv6 interfaces +* Dual-stack Pod networking (a single IPv4 and IPv6 address assignment per Pod) +* IPv4 and IPv6 enabled Services +* Pod off-cluster egress routing (eg. the Internet) via both IPv4 and IPv6 interfaces ## Prerequisites The following prerequisites are needed in order to utilize IPv4/IPv6 dual-stack Kubernetes clusters: - * Kubernetes 1.20 or later - For information about using dual-stack services with earlier - Kubernetes versions, refer to the documentation for that version - of Kubernetes. - * Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide Kubernetes nodes with routable IPv4/IPv6 network interfaces) - * A [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) that supports dual-stack networking. +* Kubernetes 1.20 or later + + For information about using dual-stack services with earlier + Kubernetes versions, refer to the documentation for that version + of Kubernetes. + +* Provider support for dual-stack networking (Cloud provider or otherwise must be able to provide + Kubernetes nodes with routable IPv4/IPv6 network interfaces) +* A [network plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) that + supports dual-stack networking. ## Configure IPv4/IPv6 dual-stack To configure IPv4/IPv6 dual-stack, set dual-stack cluster network assignments: - * kube-apiserver: - * `--service-cluster-ip-range=,` - * kube-controller-manager: - * `--cluster-cidr=,` - * `--service-cluster-ip-range=,` - * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` defaults to /24 for IPv4 and /64 for IPv6 - * kube-proxy: - * `--cluster-cidr=,` - * kubelet: - * when there is no `--cloud-provider` the administrator can pass a comma-separated pair - of IP addresses via `--node-ip` to manually configure dual-stack `.status.addresses` - for that Node. - If a Pod runs on that node in HostNetwork mode, the Pod reports these IP addresses in its - `.status.podIPs` field. - All `podIPs` in a node match the IP family preference defined by the - `.status.addresses` field for that Node. +* kube-apiserver: + * `--service-cluster-ip-range=,` +* kube-controller-manager: + * `--cluster-cidr=,` + * `--service-cluster-ip-range=,` + * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` defaults to /24 for IPv4 and /64 for IPv6 +* kube-proxy: + * `--cluster-cidr=,` +* kubelet: + * when there is no `--cloud-provider` the administrator can pass a comma-separated pair of IP + addresses via `--node-ip` to manually configure dual-stack `.status.addresses` for that Node. + If a Pod runs on that node in HostNetwork mode, the Pod reports these IP addresses in its + `.status.podIPs` field. + All `podIPs` in a node match the IP family preference defined by the `.status.addresses` + field for that Node. {{< note >}} An example of an IPv4 CIDR: `10.244.0.0/16` (though you would supply your own address range) -An example of an IPv6 CIDR: `fdXY:IJKL:MNOP:15::/64` (this shows the format but is not a valid address - see [RFC 4193](https://tools.ietf.org/html/rfc4193)) - +An example of an IPv6 CIDR: `fdXY:IJKL:MNOP:15::/64` (this shows the format but is not a valid +address - see [RFC 4193](https://tools.ietf.org/html/rfc4193)) {{< /note >}} ## Services You can create {{< glossary_tooltip text="Services" term_id="service" >}} which can use IPv4, IPv6, or both. -The address family of a Service defaults to the address family of the first service cluster IP range (configured via the `--service-cluster-ip-range` flag to the kube-apiserver). +The address family of a Service defaults to the address family of the first service cluster IP +range (configured via the `--service-cluster-ip-range` flag to the kube-apiserver). When you define a Service you can optionally configure it as dual stack. To specify the behavior you want, you set the `.spec.ipFamilyPolicy` field to one of the following values: -* `SingleStack`: Single-stack service. The control plane allocates a cluster IP for the Service, using the first configured service cluster IP range. +* `SingleStack`: Single-stack service. The control plane allocates a cluster IP for the Service, + using the first configured service cluster IP range. * `PreferDualStack`: * Allocates IPv4 and IPv6 cluster IPs for the Service. * `RequireDualStack`: Allocates Service `.spec.ClusterIPs` from both IPv4 and IPv6 address ranges. - * Selects the `.spec.ClusterIP` from the list of `.spec.ClusterIPs` based on the address family of the first element in the `.spec.ipFamilies` array. + * Selects the `.spec.ClusterIP` from the list of `.spec.ClusterIPs` based on the address family + of the first element in the `.spec.ipFamilies` array. -If you would like to define which IP family to use for single stack or define the order of IP families for dual-stack, you can choose the address families by setting an optional field, `.spec.ipFamilies`, on the Service. +If you would like to define which IP family to use for single stack or define the order of IP +families for dual-stack, you can choose the address families by setting an optional field, +`.spec.ipFamilies`, on the Service. {{< note >}} -The `.spec.ipFamilies` field is immutable because the `.spec.ClusterIP` cannot be reallocated on a Service that already exists. If you want to change `.spec.ipFamilies`, delete and recreate the Service. +The `.spec.ipFamilies` field is immutable because the `.spec.ClusterIP` cannot be reallocated on a +Service that already exists. If you want to change `.spec.ipFamilies`, delete and recreate the +Service. {{< /note >}} You can set `.spec.ipFamilies` to any of the following array values: @@ -109,139 +118,197 @@ These examples demonstrate the behavior of various dual-stack Service configurat #### Dual-stack options on new Services -1. This Service specification does not explicitly define `.spec.ipFamilyPolicy`. When you create this Service, Kubernetes assigns a cluster IP for the Service from the first configured `service-cluster-ip-range` and sets the `.spec.ipFamilyPolicy` to `SingleStack`. ([Services without selectors](/docs/concepts/services-networking/service/#services-without-selectors) and [headless Services](/docs/concepts/services-networking/service/#headless-services) with selectors will behave in this same way.) +1. This Service specification does not explicitly define `.spec.ipFamilyPolicy`. When you create + this Service, Kubernetes assigns a cluster IP for the Service from the first configured + `service-cluster-ip-range` and sets the `.spec.ipFamilyPolicy` to `SingleStack`. ([Services + without selectors](/docs/concepts/services-networking/service/#services-without-selectors) and + [headless Services](/docs/concepts/services-networking/service/#headless-services) with selectors + will behave in this same way.) -{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}} + {{< codenew file="service/networking/dual-stack-default-svc.yaml" >}} -1. This Service specification explicitly defines `PreferDualStack` in `.spec.ipFamilyPolicy`. When you create this Service on a dual-stack cluster, Kubernetes assigns both IPv4 and IPv6 addresses for the service. The control plane updates the `.spec` for the Service to record the IP address assignments. The field `.spec.ClusterIPs` is the primary field, and contains both assigned IP addresses; `.spec.ClusterIP` is a secondary field with its value calculated from `.spec.ClusterIPs`. +1. This Service specification explicitly defines `PreferDualStack` in `.spec.ipFamilyPolicy`. When + you create this Service on a dual-stack cluster, Kubernetes assigns both IPv4 and IPv6 + addresses for the service. The control plane updates the `.spec` for the Service to record the IP + address assignments. The field `.spec.ClusterIPs` is the primary field, and contains both assigned + IP addresses; `.spec.ClusterIP` is a secondary field with its value calculated from + `.spec.ClusterIPs`. - * For the `.spec.ClusterIP` field, the control plane records the IP address that is from the same address family as the first service cluster IP range. - * On a single-stack cluster, the `.spec.ClusterIPs` and `.spec.ClusterIP` fields both only list one address. - * On a cluster with dual-stack enabled, specifying `RequireDualStack` in `.spec.ipFamilyPolicy` behaves the same as `PreferDualStack`. + * For the `.spec.ClusterIP` field, the control plane records the IP address that is from the + same address family as the first service cluster IP range. + * On a single-stack cluster, the `.spec.ClusterIPs` and `.spec.ClusterIP` fields both only list + one address. + * On a cluster with dual-stack enabled, specifying `RequireDualStack` in `.spec.ipFamilyPolicy` + behaves the same as `PreferDualStack`. -{{< codenew file="service/networking/dual-stack-preferred-svc.yaml" >}} + {{< codenew file="service/networking/dual-stack-preferred-svc.yaml" >}} -1. This Service specification explicitly defines `IPv6` and `IPv4` in `.spec.ipFamilies` as well as defining `PreferDualStack` in `.spec.ipFamilyPolicy`. When Kubernetes assigns an IPv6 and IPv4 address in `.spec.ClusterIPs`, `.spec.ClusterIP` is set to the IPv6 address because that is the first element in the `.spec.ClusterIPs` array, overriding the default. +1. This Service specification explicitly defines `IPv6` and `IPv4` in `.spec.ipFamilies` as well + as defining `PreferDualStack` in `.spec.ipFamilyPolicy`. When Kubernetes assigns an IPv6 and + IPv4 address in `.spec.ClusterIPs`, `.spec.ClusterIP` is set to the IPv6 address because that is + the first element in the `.spec.ClusterIPs` array, overriding the default. -{{< codenew file="service/networking/dual-stack-preferred-ipfamilies-svc.yaml" >}} + {{< codenew file="service/networking/dual-stack-preferred-ipfamilies-svc.yaml" >}} #### Dual-stack defaults on existing Services -These examples demonstrate the default behavior when dual-stack is newly enabled on a cluster where Services already exist. (Upgrading an existing cluster to 1.21 or beyond will enable dual-stack.) +These examples demonstrate the default behavior when dual-stack is newly enabled on a cluster +where Services already exist. (Upgrading an existing cluster to 1.21 or beyond will enable +dual-stack.) -1. When dual-stack is enabled on a cluster, existing Services (whether `IPv4` or `IPv6`) are configured by the control plane to set `.spec.ipFamilyPolicy` to `SingleStack` and set `.spec.ipFamilies` to the address family of the existing Service. The existing Service cluster IP will be stored in `.spec.ClusterIPs`. +1. When dual-stack is enabled on a cluster, existing Services (whether `IPv4` or `IPv6`) are + configured by the control plane to set `.spec.ipFamilyPolicy` to `SingleStack` and set + `.spec.ipFamilies` to the address family of the existing Service. The existing Service cluster IP + will be stored in `.spec.ClusterIPs`. -{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}} + {{< codenew file="service/networking/dual-stack-default-svc.yaml" >}} You can validate this behavior by using kubectl to inspect an existing service. -```shell -kubectl get svc my-service -o yaml -``` + ```shell + kubectl get svc my-service -o yaml + ``` -```yaml -apiVersion: v1 -kind: Service -metadata: - labels: - app: MyApp - name: my-service -spec: - clusterIP: 10.0.197.123 - clusterIPs: - - 10.0.197.123 - ipFamilies: - - IPv4 - ipFamilyPolicy: SingleStack - ports: - - port: 80 - protocol: TCP - targetPort: 80 - selector: - app: MyApp - type: ClusterIP -status: - loadBalancer: {} -``` + ```yaml + apiVersion: v1 + kind: Service + metadata: + labels: + app: MyApp + name: my-service + spec: + clusterIP: 10.0.197.123 + clusterIPs: + - 10.0.197.123 + ipFamilies: + - IPv4 + ipFamilyPolicy: SingleStack + ports: + - port: 80 + protocol: TCP + targetPort: 80 + selector: + app: MyApp + type: ClusterIP + status: + loadBalancer: {} + ``` -1. When dual-stack is enabled on a cluster, existing [headless Services](/docs/concepts/services-networking/service/#headless-services) with selectors are configured by the control plane to set `.spec.ipFamilyPolicy` to `SingleStack` and set `.spec.ipFamilies` to the address family of the first service cluster IP range (configured via the `--service-cluster-ip-range` flag to the kube-apiserver) even though `.spec.ClusterIP` is set to `None`. +1. When dual-stack is enabled on a cluster, existing + [headless Services](/docs/concepts/services-networking/service/#headless-services) with selectors are + configured by the control plane to set `.spec.ipFamilyPolicy` to `SingleStack` and set + `.spec.ipFamilies` to the address family of the first service cluster IP range (configured via the + `--service-cluster-ip-range` flag to the kube-apiserver) even though `.spec.ClusterIP` is set to + `None`. -{{< codenew file="service/networking/dual-stack-default-svc.yaml" >}} + {{< codenew file="service/networking/dual-stack-default-svc.yaml" >}} You can validate this behavior by using kubectl to inspect an existing headless service with selectors. -```shell -kubectl get svc my-service -o yaml -``` + ```shell + kubectl get svc my-service -o yaml + ``` -```yaml -apiVersion: v1 -kind: Service -metadata: - labels: - app: MyApp - name: my-service -spec: - clusterIP: None - clusterIPs: - - None - ipFamilies: - - IPv4 - ipFamilyPolicy: SingleStack - ports: - - port: 80 - protocol: TCP - targetPort: 80 - selector: - app: MyApp -``` + ```yaml + apiVersion: v1 + kind: Service + metadata: + labels: + app: MyApp + name: my-service + spec: + clusterIP: None + clusterIPs: + - None + ipFamilies: + - IPv4 + ipFamilyPolicy: SingleStack + ports: + - port: 80 + protocol: TCP + targetPort: 80 + selector: + app: MyApp + ``` #### Switching Services between single-stack and dual-stack Services can be changed from single-stack to dual-stack and from dual-stack to single-stack. -1. To change a Service from single-stack to dual-stack, change `.spec.ipFamilyPolicy` from `SingleStack` to `PreferDualStack` or `RequireDualStack` as desired. When you change this Service from single-stack to dual-stack, Kubernetes assigns the missing address family so that the Service now has IPv4 and IPv6 addresses. +1. To change a Service from single-stack to dual-stack, change `.spec.ipFamilyPolicy` from + `SingleStack` to `PreferDualStack` or `RequireDualStack` as desired. When you change this + Service from single-stack to dual-stack, Kubernetes assigns the missing address family so that the + Service now has IPv4 and IPv6 addresses. Edit the Service specification updating the `.spec.ipFamilyPolicy` from `SingleStack` to `PreferDualStack`. -Before: -```yaml -spec: - ipFamilyPolicy: SingleStack -``` -After: -```yaml -spec: - ipFamilyPolicy: PreferDualStack -``` + Before: -1. To change a Service from dual-stack to single-stack, change `.spec.ipFamilyPolicy` from `PreferDualStack` or `RequireDualStack` to `SingleStack`. When you change this Service from dual-stack to single-stack, Kubernetes retains only the first element in the `.spec.ClusterIPs` array, and sets `.spec.ClusterIP` to that IP address and sets `.spec.ipFamilies` to the address family of `.spec.ClusterIPs`. + ```yaml + spec: + ipFamilyPolicy: SingleStack + ``` + + After: + + ```yaml + spec: + ipFamilyPolicy: PreferDualStack + ``` + +1. To change a Service from dual-stack to single-stack, change `.spec.ipFamilyPolicy` from + `PreferDualStack` or `RequireDualStack` to `SingleStack`. When you change this Service from + dual-stack to single-stack, Kubernetes retains only the first element in the `.spec.ClusterIPs` + array, and sets `.spec.ClusterIP` to that IP address and sets `.spec.ipFamilies` to the address + family of `.spec.ClusterIPs`. ### Headless Services without selector -For [Headless Services without selectors](/docs/concepts/services-networking/service/#without-selectors) and without `.spec.ipFamilyPolicy` explicitly set, the `.spec.ipFamilyPolicy` field defaults to `RequireDualStack`. +For [Headless Services without selectors](/docs/concepts/services-networking/service/#without-selectors) +and without `.spec.ipFamilyPolicy` explicitly set, the `.spec.ipFamilyPolicy` field defaults to +`RequireDualStack`. ### Service type LoadBalancer To provision a dual-stack load balancer for your Service: - * Set the `.spec.type` field to `LoadBalancer` - * Set `.spec.ipFamilyPolicy` field to `PreferDualStack` or `RequireDualStack` + +* Set the `.spec.type` field to `LoadBalancer` +* Set `.spec.ipFamilyPolicy` field to `PreferDualStack` or `RequireDualStack` {{< note >}} -To use a dual-stack `LoadBalancer` type Service, your cloud provider must support IPv4 and IPv6 load balancers. +To use a dual-stack `LoadBalancer` type Service, your cloud provider must support IPv4 and IPv6 +load balancers. {{< /note >}} ## Egress traffic -If you want to enable egress traffic in order to reach off-cluster destinations (eg. the public Internet) from a Pod that uses non-publicly routable IPv6 addresses, you need to enable the Pod to use a publicly routed IPv6 address via a mechanism such as transparent proxying or IP masquerading. The [ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent) project supports IP masquerading on dual-stack clusters. +If you want to enable egress traffic in order to reach off-cluster destinations (eg. the public +Internet) from a Pod that uses non-publicly routable IPv6 addresses, you need to enable the Pod to +use a publicly routed IPv6 address via a mechanism such as transparent proxying or IP +masquerading. The [ip-masq-agent](https://github.com/kubernetes-sigs/ip-masq-agent) project +supports IP masquerading on dual-stack clusters. {{< note >}} 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" %}} - * [Validate IPv4/IPv6 dual-stack](/docs/tasks/network/validate-dual-stack) networking -* [Enable dual-stack networking using kubeadm -](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/) +* [Enable dual-stack networking using kubeadm](/docs/setup/production-environment/tools/kubeadm/dual-stack-support/) + 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-traffic-policy.md b/content/en/docs/concepts/services-networking/service-traffic-policy.md index b7a367a4b7..b9abe34b3f 100644 --- a/content/en/docs/concepts/services-networking/service-traffic-policy.md +++ b/content/en/docs/concepts/services-networking/service-traffic-policy.md @@ -60,12 +60,6 @@ considered. When the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `ServiceInternalTrafficPolicy` is enabled, `spec.internalTrafficPolicy` defaults to "Cluster". -## Constraints - -* Service Internal Traffic Policy is not used when `externalTrafficPolicy` is set - to `Local` on a Service. It is possible to use both features in the same cluster - on different Services, just not on the same Service. - ## {{% heading "whatsnext" %}} * Read about [Topology Aware Hints](/docs/concepts/services-networking/topology-aware-hints) diff --git a/content/en/docs/concepts/services-networking/service.md b/content/en/docs/concepts/services-networking/service.md index dc59d4f84e..3ca1bc8a26 100644 --- a/content/en/docs/concepts/services-networking/service.md +++ b/content/en/docs/concepts/services-networking/service.md @@ -122,7 +122,7 @@ metadata: spec: containers: - name: nginx - image: nginx:11.14.2 + image: nginx:stable ports: - containerPort: 80 name: http-web-svc @@ -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..66aa8f7f8a 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. @@ -673,7 +682,7 @@ Claims use [the same convention as volumes](#volume-mode) to indicate the consum ### Resources -Claims, like Pods, can request specific quantities of a resource. In this case, the request is for storage. The same [resource model](https://git.k8s.io/community/contributors/design-proposals/scheduling/resources.md) applies to both volumes and claims. +Claims, like Pods, can request specific quantities of a resource. In this case, the request is for storage. The same [resource model](https://git.k8s.io/design-proposals-archive/scheduling/resources.md) applies to both volumes and claims. ### Selector @@ -1012,7 +1021,7 @@ and need persistent storage, it is recommended that you use the following patter * Learn more about [Creating a PersistentVolume](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). * Learn more about [Creating a PersistentVolumeClaim](/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim). -* Read the [Persistent Storage design document](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md). +* Read the [Persistent Storage design document](https://git.k8s.io/design-proposals-archive/storage/persistent-storage.md). ### API references {#reference} diff --git a/content/en/docs/concepts/storage/projected-volumes.md b/content/en/docs/concepts/storage/projected-volumes.md index ed7c31db14..df67132cf5 100644 --- a/content/en/docs/concepts/storage/projected-volumes.md +++ b/content/en/docs/concepts/storage/projected-volumes.md @@ -26,7 +26,7 @@ Currently, the following types of volume sources can be projected: * [`serviceAccountToken`](#serviceaccounttoken) All sources are required to be in the same namespace as the Pod. For more details, -see the [all-in-one volume](https://github.com/kubernetes/design-proposals-archive/blob/main/node/all-in-one-volume.md) design document. +see the [all-in-one volume](https://git.k8s.io/design-proposals-archive/node/all-in-one-volume.md) design document. ### Example configuration with a secret, a downwardAPI, and a configMap {#example-configuration-secret-downwardapi-configmap} diff --git a/content/en/docs/concepts/storage/storage-classes.md b/content/en/docs/concepts/storage/storage-classes.md index 53ee88a2e7..8fda0b2ff3 100644 --- a/content/en/docs/concepts/storage/storage-classes.md +++ b/content/en/docs/concepts/storage/storage-classes.md @@ -87,7 +87,7 @@ for provisioning PVs. This field must be specified. You are not restricted to specifying the "internal" provisioners listed here (whose names are prefixed with "kubernetes.io" and shipped alongside Kubernetes). You can also run and specify external provisioners, -which are independent programs that follow a [specification](https://github.com/kubernetes/design-proposals-archive/blob/main/storage/volume-provisioning.md) +which are independent programs that follow a [specification](https://git.k8s.io/design-proposals-archive/storage/volume-provisioning.md) defined by Kubernetes. Authors of external provisioners have full discretion over where their code lives, how the provisioner is shipped, how it needs to be run, what volume plugin it uses (including Flex), etc. The repository diff --git a/content/en/docs/concepts/storage/volumes.md b/content/en/docs/concepts/storage/volumes.md index cc9a9565eb..739773cfbe 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. @@ -1146,7 +1156,7 @@ to the [volume plugin FAQ](https://github.com/kubernetes/community/blob/master/s (CSI) defines a standard interface for container orchestration systems (like Kubernetes) to expose arbitrary storage systems to their container workloads. -Please read the [CSI design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md) for more information. +Please read the [CSI design proposal](https://git.k8s.io/design-proposals-archive/storage/container-storage-interface.md) for more information. {{< note >}} Support for CSI spec versions 0.2 and 0.3 are deprecated in Kubernetes @@ -1166,8 +1176,8 @@ CSI driver. A `csi` volume can be used in a Pod in three different ways: * through a reference to a [PersistentVolumeClaim](#persistentvolumeclaim) -* with a [generic ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volume) -* with a [CSI ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume) +* with a [generic ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volumes) +* with a [CSI ephemeral volume](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes) if the driver supports that (beta feature) The following fields are available to storage administrators to configure a CSI @@ -1234,12 +1244,26 @@ You can set up your You can directly configure CSI volumes within the Pod specification. Volumes specified in this way are ephemeral and do not persist across pod restarts. See [Ephemeral -Volumes](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume) +Volumes](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volumes) 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..91e9412759 --- /dev/null +++ b/content/en/docs/concepts/windows/intro.md @@ -0,0 +1,387 @@ +--- +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. + [HostProcess Containers](/docs/tasks/configure-pod-container/create-hostprocess-pod/) offer similar functionality. +* 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, liveness, and startup 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. + +* `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 `--kube-reserved`, `--system-reserved` , 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 +* When running on a Windows node the kubelet does not have memory or CPU + restrictions. `--kube-reserved` and `--system-reserved` only subtract from `NodeAllocatable` + and do not guarantee resource provided for workloads. + See [Resource Management for Windows nodes](/docs/concepts/configuration/windows-resource-management/#resource-reservation) + for more information. +* 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/)) +has preliminary support for Windows. +For more information, visit the project's [GitHub page](https://github.com/kubernetes/node-problem-detector#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 %}} + +### 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 channel on the Kubernetes Slack is also a great avenue to get some initial support and +troubleshooting ideas prior to creating a ticket. + +## 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..470a5e5024 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 @@ -387,7 +387,7 @@ As such, it is recommended to use Deployments when you want ReplicaSets. ### Bare Pods -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). +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 such as Kubelet. ### Job diff --git a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index 34ca33d6b1..fe50cf7e2d 100644 --- a/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/en/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -64,6 +64,7 @@ metadata: spec: topologySpreadConstraints: - maxSkew: + minDomains: topologyKey: whenUnsatisfiable: labelSelector: @@ -143,7 +144,7 @@ If we want an incoming Pod to be evenly spread with existing Pods across zones, `topologyKey: zone` implies the even distribution will only be applied to the nodes which have label pair "zone:<any value>" present. `whenUnsatisfiable: DoNotSchedule` tells the scheduler to let it stay pending if the incoming Pod can't satisfy the constraint. -If the scheduler placed this incoming Pod into "zoneA", the Pods distribution would become [3, 1], hence the actual skew is 2 (3 - 1) - which violates `maxSkew: 1`. In this example, the incoming Pod can only be placed onto "zoneB": +If the scheduler placed this incoming Pod into "zoneA", the Pods distribution would become [3, 1], hence the actual skew is 2 (3 - 1) - which violates `maxSkew: 1`. In this example, the incoming Pod can only be placed into "zoneB": {{}} graph BT @@ -188,7 +189,7 @@ graph BT You can tweak the Pod spec to meet various kinds of requirements: -- Change `maxSkew` to a bigger value like "2" so that the incoming Pod can be placed onto "zoneA" as well. +- Change `maxSkew` to a bigger value like "2" so that the incoming Pod can be placed into "zoneA" as well. - Change `topologyKey` to "node" so as to distribute the Pods evenly across nodes instead of zones. In the above example, if `maxSkew` remains "1", the incoming Pod can only be placed onto "node4". - Change `whenUnsatisfiable: DoNotSchedule` to `whenUnsatisfiable: ScheduleAnyway` to ensure the incoming Pod to be always schedulable (suppose other scheduling APIs are satisfied). However, it's preferred to be placed onto the topology domain which has fewer matching Pods. (Be aware that this preferability is jointly normalized with other internal scheduling priorities like resource usage ratio, etc.) @@ -219,7 +220,7 @@ You can use 2 TopologySpreadConstraints to control the Pods spreading on both zo {{< codenew file="pods/topology-spread-constraints/two-constraints.yaml" >}} -In this case, to match the first constraint, the incoming Pod can only be placed onto "zoneB"; while in terms of the second constraint, the incoming Pod can only be placed onto "node4". Then the results of 2 constraints are ANDed, so the only viable option is to place on "node4". +In this case, to match the first constraint, the incoming Pod can only be placed into "zoneB"; while in terms of the second constraint, the incoming Pod can only be placed onto "node4". Then the results of 2 constraints are ANDed, so the only viable option is to place on "node4". Multiple constraints can lead to conflicts. Suppose you have a 3-node cluster across 2 zones: @@ -242,7 +243,7 @@ graph BT class zoneA,zoneB cluster; {{< /mermaid >}} -If you apply "two-constraints.yaml" to this cluster, you will notice "mypod" stays in `Pending` state. This is because: to satisfy the first constraint, "mypod" can only be put to "zoneB"; while in terms of the second constraint, "mypod" can only put to "node2". Then a joint result of "zoneB" and "node2" returns nothing. +If you apply "two-constraints.yaml" to this cluster, you will notice "mypod" stays in `Pending` state. This is because: to satisfy the first constraint, "mypod" can only placed into "zoneB"; while in terms of the second constraint, "mypod" can only be placed onto "node2". Then a joint result of "zoneB" and "node2" returns nothing. To overcome this situation, you can either increase the `maxSkew` or modify one of the constraints to use `whenUnsatisfiable: ScheduleAnyway`. @@ -286,7 +287,7 @@ class n5 k8s; class zoneC cluster; {{< /mermaid >}} -and you know that "zoneC" must be excluded. In this case, you can compose the yaml as below, so that "mypod" will be placed onto "zoneB" instead of "zoneC". Similarly `spec.nodeSelector` is also respected. +and you know that "zoneC" must be excluded. In this case, you can compose the yaml as below, so that "mypod" will be placed into "zoneB" instead of "zoneC". Similarly `spec.nodeSelector` is also respected. {{< codenew file="pods/topology-spread-constraints/one-constraint-with-nodeaffinity.yaml" >}} @@ -301,9 +302,9 @@ There are some implicit conventions worth noting here: - The scheduler will bypass the nodes without `topologySpreadConstraints[*].topologyKey` present. This implies that: 1. the Pods located on those nodes do not impact `maxSkew` calculation - in the above example, suppose "node1" does not have label "zone", then the 2 Pods will be disregarded, hence the incoming Pod will be scheduled into "zoneA". - 2. the incoming Pod has no chances to be scheduled onto this kind of nodes - in the above example, suppose a "node5" carrying label `{zone-typo: zoneC}` joins the cluster, it will be bypassed due to the absence of label key "zone". + 2. the incoming Pod has no chances to be scheduled onto such nodes - in the above example, suppose a "node5" carrying label `{zone-typo: zoneC}` joins the cluster, it will be bypassed due to the absence of label key "zone". -- Be aware of what will happen if the incomingPod's `topologySpreadConstraints[*].labelSelector` doesn't match its own labels. In the above example, if we remove the incoming Pod's labels, it can still be placed onto "zoneB" since the constraints are still satisfied. However, after the placement, the degree of imbalance of the cluster remains unchanged - it's still zoneA having 2 Pods which hold label {foo:bar}, and zoneB having 1 Pod which holds label {foo:bar}. So if this is not what you expect, we recommend the workload's `topologySpreadConstraints[*].labelSelector` to match its own labels. +- Be aware of what will happen if the incoming Pod's `topologySpreadConstraints[*].labelSelector` doesn't match its own labels. In the above example, if we remove the incoming Pod's labels, it can still be placed into "zoneB" since the constraints are still satisfied. However, after the placement, the degree of imbalance of the cluster remains unchanged - it's still zoneA having 2 Pods which hold label {foo:bar}, and zoneB having 1 Pod which holds label {foo:bar}. So if this is not what you expect, we recommend the workload's `topologySpreadConstraints[*].labelSelector` to match its own labels. ### Cluster-level default constraints 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..ee553c64d6 100644 --- a/content/en/docs/contribute/participate/pr-wranglers.md +++ b/content/en/docs/contribute/participate/pr-wranglers.md @@ -84,7 +84,7 @@ To close a pull request, leave a `/close` comment on the PR. {{< note >}} -The [`fejta-bot`](https://github.com/fejta-bot) bot marks issues as stale after 90 days of inactivity. After 30 more days it marks issues as rotten and closes them. PR wranglers should close issues after 14-30 days of inactivity. +The [`k8s-triage-robot`](https://github.com/k8s-triage-robot) bot marks issues as stale after 90 days of inactivity. After 30 more days it marks issues as rotten and closes them. PR wranglers should close issues after 14-30 days of inactivity. {{< /note >}} @@ -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..0ebd59c406 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 @@ -97,6 +99,6 @@ operator to use or manage a cluster. ## Design Docs An archive of the design docs for Kubernetes functionality. Good starting points are -[Kubernetes Architecture](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) and -[Kubernetes Design Overview](https://git.k8s.io/community/contributors/design-proposals). +[Kubernetes Architecture](https://git.k8s.io/design-proposals-archive/architecture/architecture.md) and +[Kubernetes Design Overview](https://git.k8s.io/design-proposals-archive). diff --git a/content/en/docs/reference/access-authn-authz/_index.md b/content/en/docs/reference/access-authn-authz/_index.md index 86d06488a8..3677f79c57 100644 --- a/content/en/docs/reference/access-authn-authz/_index.md +++ b/content/en/docs/reference/access-authn-authz/_index.md @@ -24,3 +24,5 @@ Reference documentation: - Service accounts - [Developer guide](/docs/tasks/configure-pod-container/configure-service-account/) - [Administration](/docs/reference/access-authn-authz/service-accounts-admin/) +- [Kubelet Authentication & Authorization](/docs/reference/access-authn-authz/kubelet-authn-authz/) + - including kubelet [TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) 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 e37059784c..f03b04f8e3 100644 --- a/content/en/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/en/docs/reference/access-authn-authz/admission-controllers.md @@ -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') @@ -356,19 +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/*`. -Note that webhook API objects are subject to the same versioning compatibility rules +{{ 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 +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: @@ -420,8 +422,8 @@ 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 @@ -432,9 +434,9 @@ 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. @@ -469,8 +471,7 @@ 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 @@ -599,7 +600,7 @@ Starting from 1.11, this admission controller is disabled by default. 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. @@ -649,9 +650,7 @@ This admission controller has the following behavior: 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. + plugin configuration file. Conflicts result in rejection. {{< note >}} PodNodeSelector allows forcing pods to run on specifically labeled nodes. Also see the PodTolerationRestriction @@ -767,7 +766,7 @@ We strongly recommend using this admission controller if you intend to make use 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. 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..74367d50c9 100644 --- a/content/en/docs/reference/access-authn-authz/bootstrap-tokens.md +++ b/content/en/docs/reference/access-authn-authz/bootstrap-tokens.md @@ -15,7 +15,7 @@ creating new clusters or joining new nodes to an existing cluster. It was built to support [kubeadm](/docs/reference/setup-tools/kubeadm/), but can be used in other contexts for users that wish to start clusters without `kubeadm`. It is also built to work, via RBAC policy, with the -[Kubelet TLS Bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) system. +[Kubelet TLS Bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) system. @@ -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://git.k8s.io/design-proposals-archive/cluster-lifecycle/bootstrap-discovery.md). Here is what the secret looks like. diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md b/content/en/docs/reference/access-authn-authz/kubelet-authn-authz.md similarity index 100% rename from content/en/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md rename to content/en/docs/reference/access-authn-authz/kubelet-authn-authz.md diff --git a/content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md b/content/en/docs/reference/access-authn-authz/kubelet-tls-bootstrapping.md similarity index 100% rename from content/en/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md rename to content/en/docs/reference/access-authn-authz/kubelet-tls-bootstrapping.md diff --git a/content/en/docs/reference/access-authn-authz/node.md b/content/en/docs/reference/access-authn-authz/node.md index 6e7c538eb0..bc9863219f 100644 --- a/content/en/docs/reference/access-authn-authz/node.md +++ b/content/en/docs/reference/access-authn-authz/node.md @@ -43,7 +43,7 @@ have the minimal set of permissions required to operate correctly. In order to be authorized by the Node authorizer, kubelets must use a credential that identifies them as being in the `system:nodes` group, with a username of `system:node:`. This group and user name format match the identity created for each kubelet as part of -[kubelet TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/). +[kubelet TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/). The value of `` **must** match precisely the name of the node as registered by the kubelet. By default, this is the host name as provided by `hostname`, or overridden via the [kubelet option](/docs/reference/command-line-tools-reference/kubelet/) `--hostname-override`. However, when using the `--cloud-provider` kubelet option, the specific hostname may be determined by the cloud provider, ignoring the local `hostname` and the `--hostname-override` option. For specifics about how the kubelet determines the hostname, see the [kubelet options reference](/docs/reference/command-line-tools-reference/kubelet/). diff --git a/content/en/docs/reference/access-authn-authz/psp-to-pod-security-standards.md b/content/en/docs/reference/access-authn-authz/psp-to-pod-security-standards.md index 468579f982..6c820a6e99 100644 --- a/content/en/docs/reference/access-authn-authz/psp-to-pod-security-standards.md +++ b/content/en/docs/reference/access-authn-authz/psp-to-pod-security-standards.md @@ -17,7 +17,7 @@ For each applicable parameter, the allowed values for the [Baseline](/docs/concepts/security/pod-security-standards/#baseline) and [Restricted](/docs/concepts/security/pod-security-standards/#restricted) profiles are listed. Anything outside the allowed values for those profiles would fall under the -[Privileged](/docs/concepts/security/pod-security-standards/#priveleged) profile. "No opinion" +[Privileged](/docs/concepts/security/pod-security-standards/#privileged) profile. "No opinion" means all values are allowed under all Pod Security Standards. For a step-by-step migration guide, see diff --git a/content/en/docs/reference/access-authn-authz/rbac.md b/content/en/docs/reference/access-authn-authz/rbac.md index 57a074a29a..d085251e43 100644 --- a/content/en/docs/reference/access-authn-authz/rbac.md +++ b/content/en/docs/reference/access-authn-authz/rbac.md @@ -798,7 +798,7 @@ This is commonly used by add-on API servers for unified authentication and autho system:node-bootstrapper None Allows access to the resources required to perform -kubelet TLS bootstrapping. +kubelet TLS bootstrapping. system:node-problem-detector diff --git a/content/en/docs/reference/command-line-tools-reference/feature-gates.md b/content/en/docs/reference/command-line-tools-reference/feature-gates.md index 8eb23b3a47..9d1e67b3c0 100644 --- a/content/en/docs/reference/command-line-tools-reference/feature-gates.md +++ b/content/en/docs/reference/command-line-tools-reference/feature-gates.md @@ -761,7 +761,7 @@ Each feature gate is designed for enabling/disabling a specific feature: Requires Portworx CSI driver to be installed and configured in the cluster. - `CSINodeInfo`: Enable all logic related to the CSINodeInfo API object in `csi.storage.k8s.io`. - `CSIPersistentVolume`: Enable discovering and mounting volumes provisioned through a - [CSI (Container Storage Interface)](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md) + [CSI (Container Storage Interface)](https://git.k8s.io/design-proposals-archive/storage/container-storage-interface.md) compatible volume plugin. - `CSIServiceAccountToken`: Enable CSI drivers to receive the pods' service account token that they mount volumes for. See @@ -1086,10 +1086,10 @@ Each feature gate is designed for enabling/disabling a specific feature: [Bound Service Account Tokens](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md) for more details. - `RotateKubeletClientCertificate`: Enable the rotation of the client TLS certificate on the kubelet. - See [kubelet configuration](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration) + See [kubelet configuration](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#kubelet-configuration) for more details. - `RotateKubeletServerCertificate`: Enable the rotation of the server TLS certificate on the kubelet. - See [kubelet configuration](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration) + See [kubelet configuration](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#kubelet-configuration) for more details. - `RunAsGroup`: Enable control over the primary group ID set on the init processes of containers. diff --git a/content/en/docs/reference/command-line-tools-reference/kube-proxy.md b/content/en/docs/reference/command-line-tools-reference/kube-proxy.md index d391dfc46b..34ced450e0 100644 --- a/content/en/docs/reference/command-line-tools-reference/kube-proxy.md +++ b/content/en/docs/reference/command-line-tools-reference/kube-proxy.md @@ -43,10 +43,17 @@ kube-proxy [flags] ---azure-container-registry-config string +--add_dir_header -

Path to the file containing Azure container registry configuration information.

+

If true, adds the file directory to the header of the log messages

+ + + +--alsologtostderr + + +

log to standard error as well as files

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

If true kube-proxy will treat failure to bind to a port as fatal and exit

- ---boot-id-file string     Default: "/proc/sys/kernel/random/boot_id" - - -

Comma-separated list of files to check for boot-id. Use the first one that exists.

- - --boot_id_file string     Default: "/proc/sys/kernel/random/boot_id" @@ -84,20 +84,6 @@ kube-proxy [flags]

If true cleanup iptables and ipvs rules and exit.

- ---cloud-provider-gce-l7lb-src-cidrs cidrs     Default: 130.211.0.0/22,35.191.0.0/16 - - -

CIDRs opened in GCE firewall for L7 LB traffic proxy & health checks

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

CIDRs opened in GCE firewall for L4 LB traffic proxy & health checks

- - --cluster-cidr string @@ -147,20 +133,6 @@ kube-proxy [flags]

Idle timeout for established TCP connections (0 to leave as-is)

- ---default-not-ready-toleration-seconds int     Default: 300 - - -

Indicates the tolerationSeconds of the toleration for notReady:NoExecute that is added by default to every pod that does not already have such a toleration.

- - - ---default-unreachable-toleration-seconds int     Default: 300 - - -

Indicates the tolerationSeconds of the toleration for unreachable:NoExecute that is added by default to every pod that does not already have such a toleration.

- - --detect-local-mode LocalMode @@ -172,7 +144,7 @@ kube-proxy [flags] --feature-gates <comma-separated 'key=True|False' pairs> -

A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:
APIListChunking=true|false (BETA - default=true)
APIPriorityAndFairness=true|false (BETA - default=true)
APIResponseCompression=true|false (BETA - default=true)
APIServerIdentity=true|false (ALPHA - default=false)
APIServerTracing=true|false (ALPHA - default=false)
AllAlpha=true|false (ALPHA - default=false)
AllBeta=true|false (BETA - default=false)
AnyVolumeDataSource=true|false (BETA - default=true)
AppArmor=true|false (BETA - default=true)
CPUManager=true|false (BETA - default=true)
CPUManagerPolicyAlphaOptions=true|false (ALPHA - default=false)
CPUManagerPolicyBetaOptions=true|false (BETA - default=true)
CPUManagerPolicyOptions=true|false (BETA - default=true)
CSIInlineVolume=true|false (BETA - default=true)
CSIMigration=true|false (BETA - default=true)
CSIMigrationAWS=true|false (BETA - default=true)
CSIMigrationAzureFile=true|false (BETA - default=true)
CSIMigrationGCE=true|false (BETA - default=true)
CSIMigrationPortworx=true|false (ALPHA - default=false)
CSIMigrationRBD=true|false (ALPHA - default=false)
CSIMigrationvSphere=true|false (BETA - default=false)
CSIVolumeHealth=true|false (ALPHA - default=false)
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)
DelegateFSGroupToCSIDriver=true|false (BETA - default=true)
DevicePlugins=true|false (BETA - default=true)
DisableAcceleratorUsageMetrics=true|false (BETA - default=true)
DisableCloudProviders=true|false (ALPHA - default=false)
DisableKubeletCloudCredentialProviders=true|false (ALPHA - default=false)
DownwardAPIHugePages=true|false (BETA - default=true)
EndpointSliceTerminatingCondition=true|false (BETA - default=true)
EphemeralContainers=true|false (BETA - default=true)
ExpandedDNSConfig=true|false (ALPHA - default=false)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
GRPCContainerProbe=true|false (BETA - default=true)
GracefulNodeShutdown=true|false (BETA - default=true)
GracefulNodeShutdownBasedOnPodPriority=true|false (BETA - default=true)
HPAContainerMetrics=true|false (ALPHA - default=false)
HPAScaleToZero=true|false (ALPHA - default=false)
HonorPVReclaimPolicy=true|false (ALPHA - default=false)
IdentifyPodOS=true|false (BETA - default=true)
InTreePluginAWSUnregister=true|false (ALPHA - default=false)
InTreePluginAzureDiskUnregister=true|false (ALPHA - default=false)
InTreePluginAzureFileUnregister=true|false (ALPHA - default=false)
InTreePluginGCEUnregister=true|false (ALPHA - default=false)
InTreePluginOpenStackUnregister=true|false (ALPHA - default=false)
InTreePluginPortworxUnregister=true|false (ALPHA - default=false)
InTreePluginRBDUnregister=true|false (ALPHA - default=false)
InTreePluginvSphereUnregister=true|false (ALPHA - default=false)
JobMutableNodeSchedulingDirectives=true|false (BETA - default=true)
JobReadyPods=true|false (BETA - default=true)
JobTrackingWithFinalizers=true|false (BETA - default=false)
KubeletCredentialProviders=true|false (BETA - default=true)
KubeletInUserNamespace=true|false (ALPHA - default=false)
KubeletPodResources=true|false (BETA - default=true)
KubeletPodResourcesGetAllocatable=true|false (BETA - default=true)
LegacyServiceAccountTokenNoAutoGeneration=true|false (BETA - default=true)
LocalStorageCapacityIsolation=true|false (BETA - default=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)
LogarithmicScaleDown=true|false (BETA - default=true)
MaxUnavailableStatefulSet=true|false (ALPHA - default=false)
MemoryManager=true|false (BETA - default=true)
MemoryQoS=true|false (ALPHA - default=false)
MinDomainsInPodTopologySpread=true|false (ALPHA - default=false)
MixedProtocolLBService=true|false (BETA - default=true)
NetworkPolicyEndPort=true|false (BETA - default=true)
NetworkPolicyStatus=true|false (ALPHA - default=false)
NodeOutOfServiceVolumeDetach=true|false (ALPHA - default=false)
NodeSwap=true|false (ALPHA - default=false)
OpenAPIEnums=true|false (BETA - default=true)
OpenAPIV3=true|false (BETA - default=true)
PodAndContainerStatsFromCRI=true|false (ALPHA - default=false)
PodDeletionCost=true|false (BETA - default=true)
PodSecurity=true|false (BETA - default=true)
ProbeTerminationGracePeriod=true|false (BETA - default=false)
ProcMountType=true|false (ALPHA - default=false)
ProxyTerminatingEndpoints=true|false (ALPHA - default=false)
QOSReserved=true|false (ALPHA - default=false)
ReadWriteOncePod=true|false (ALPHA - default=false)
RecoverVolumeExpansionFailure=true|false (ALPHA - default=false)
RemainingItemCount=true|false (BETA - default=true)
RotateKubeletServerCertificate=true|false (BETA - default=true)
SeccompDefault=true|false (ALPHA - default=false)
ServerSideFieldValidation=true|false (ALPHA - default=false)
ServiceIPStaticSubrange=true|false (ALPHA - default=false)
ServiceInternalTrafficPolicy=true|false (BETA - default=true)
SizeMemoryBackedVolumes=true|false (BETA - default=true)
StatefulSetAutoDeletePVC=true|false (ALPHA - default=false)
StatefulSetMinReadySeconds=true|false (BETA - default=true)
StorageVersionAPI=true|false (ALPHA - default=false)
StorageVersionHash=true|false (BETA - default=true)
TopologyAwareHints=true|false (BETA - default=true)
TopologyManager=true|false (BETA - default=true)
VolumeCapacityPriority=true|false (ALPHA - default=false)
WinDSR=true|false (ALPHA - default=false)
WinOverlay=true|false (BETA - default=true)
WindowsHostProcessContainers=true|false (BETA - default=true)This parameter is ignored if a config file is specified by --config.

+

A set of key=value pairs that describe feature gates for alpha/experimental features. Options are:
APIListChunking=true|false (BETA - default=true)
APIPriorityAndFairness=true|false (BETA - default=true)
APIResponseCompression=true|false (BETA - default=true)
APIServerIdentity=true|false (ALPHA - default=false)
APIServerTracing=true|false (ALPHA - default=false)
AllAlpha=true|false (ALPHA - default=false)
AllBeta=true|false (BETA - default=false)
AnyVolumeDataSource=true|false (BETA - default=true)
AppArmor=true|false (BETA - default=true)
CPUManager=true|false (BETA - default=true)
CPUManagerPolicyAlphaOptions=true|false (ALPHA - default=false)
CPUManagerPolicyBetaOptions=true|false (BETA - default=true)
CPUManagerPolicyOptions=true|false (BETA - default=true)
CSIInlineVolume=true|false (BETA - default=true)
CSIMigration=true|false (BETA - default=true)
CSIMigrationAWS=true|false (BETA - default=true)
CSIMigrationAzureFile=true|false (BETA - default=true)
CSIMigrationGCE=true|false (BETA - default=true)
CSIMigrationPortworx=true|false (ALPHA - default=false)
CSIMigrationRBD=true|false (ALPHA - default=false)
CSIMigrationvSphere=true|false (BETA - default=false)
CSIVolumeHealth=true|false (ALPHA - default=false)
CronJobTimeZone=true|false (ALPHA - default=false)
CustomCPUCFSQuotaPeriod=true|false (ALPHA - default=false)
CustomResourceValidationExpressions=true|false (ALPHA - default=false)
DaemonSetUpdateSurge=true|false (BETA - default=true)
DelegateFSGroupToCSIDriver=true|false (BETA - default=true)
DevicePlugins=true|false (BETA - default=true)
DisableAcceleratorUsageMetrics=true|false (BETA - default=true)
DisableCloudProviders=true|false (ALPHA - default=false)
DisableKubeletCloudCredentialProviders=true|false (ALPHA - default=false)
DownwardAPIHugePages=true|false (BETA - default=true)
EndpointSliceTerminatingCondition=true|false (BETA - default=true)
EphemeralContainers=true|false (BETA - default=true)
ExpandedDNSConfig=true|false (ALPHA - default=false)
ExperimentalHostUserNamespaceDefaulting=true|false (BETA - default=false)
GRPCContainerProbe=true|false (BETA - default=true)
GracefulNodeShutdown=true|false (BETA - default=true)
GracefulNodeShutdownBasedOnPodPriority=true|false (BETA - default=true)
HPAContainerMetrics=true|false (ALPHA - default=false)
HPAScaleToZero=true|false (ALPHA - default=false)
HonorPVReclaimPolicy=true|false (ALPHA - default=false)
IdentifyPodOS=true|false (BETA - default=true)
InTreePluginAWSUnregister=true|false (ALPHA - default=false)
InTreePluginAzureDiskUnregister=true|false (ALPHA - default=false)
InTreePluginAzureFileUnregister=true|false (ALPHA - default=false)
InTreePluginGCEUnregister=true|false (ALPHA - default=false)
InTreePluginOpenStackUnregister=true|false (ALPHA - default=false)
InTreePluginPortworxUnregister=true|false (ALPHA - default=false)
InTreePluginRBDUnregister=true|false (ALPHA - default=false)
InTreePluginvSphereUnregister=true|false (ALPHA - default=false)
JobMutableNodeSchedulingDirectives=true|false (BETA - default=true)
JobReadyPods=true|false (BETA - default=true)
JobTrackingWithFinalizers=true|false (BETA - default=false)
KubeletCredentialProviders=true|false (BETA - default=true)
KubeletInUserNamespace=true|false (ALPHA - default=false)
KubeletPodResources=true|false (BETA - default=true)
KubeletPodResourcesGetAllocatable=true|false (BETA - default=true)
LegacyServiceAccountTokenNoAutoGeneration=true|false (BETA - default=true)
LocalStorageCapacityIsolation=true|false (BETA - default=true)
LocalStorageCapacityIsolationFSQuotaMonitoring=true|false (ALPHA - default=false)
LogarithmicScaleDown=true|false (BETA - default=true)
MaxUnavailableStatefulSet=true|false (ALPHA - default=false)
MemoryManager=true|false (BETA - default=true)
MemoryQoS=true|false (ALPHA - default=false)
MinDomainsInPodTopologySpread=true|false (ALPHA - default=false)
MixedProtocolLBService=true|false (BETA - default=true)
NetworkPolicyEndPort=true|false (BETA - default=true)
NetworkPolicyStatus=true|false (ALPHA - default=false)
NodeOutOfServiceVolumeDetach=true|false (ALPHA - default=false)
NodeSwap=true|false (ALPHA - default=false)
OpenAPIEnums=true|false (BETA - default=true)
OpenAPIV3=true|false (BETA - default=true)
PodAndContainerStatsFromCRI=true|false (ALPHA - default=false)
PodDeletionCost=true|false (BETA - default=true)
PodSecurity=true|false (BETA - default=true)
ProbeTerminationGracePeriod=true|false (BETA - default=false)
ProcMountType=true|false (ALPHA - default=false)
ProxyTerminatingEndpoints=true|false (ALPHA - default=false)
QOSReserved=true|false (ALPHA - default=false)
ReadWriteOncePod=true|false (ALPHA - default=false)
RecoverVolumeExpansionFailure=true|false (ALPHA - default=false)
RemainingItemCount=true|false (BETA - default=true)
RotateKubeletServerCertificate=true|false (BETA - default=true)
SeccompDefault=true|false (ALPHA - default=false)
ServerSideFieldValidation=true|false (ALPHA - default=false)
ServiceIPStaticSubrange=true|false (ALPHA - default=false)
ServiceInternalTrafficPolicy=true|false (BETA - default=true)
SizeMemoryBackedVolumes=true|false (BETA - default=true)
StatefulSetAutoDeletePVC=true|false (ALPHA - default=false)
StatefulSetMinReadySeconds=true|false (BETA - default=true)
StorageVersionAPI=true|false (ALPHA - default=false)
StorageVersionHash=true|false (BETA - default=true)
TopologyAwareHints=true|false (BETA - default=true)
TopologyManager=true|false (BETA - default=true)
VolumeCapacityPriority=true|false (ALPHA - default=false)
WinDSR=true|false (ALPHA - default=false)
WinOverlay=true|false (BETA - default=true)
WindowsHostProcessContainers=true|false (BETA - default=true)This parameter is ignored if a config file is specified by --config.

@@ -302,10 +274,38 @@ kube-proxy [flags] ---machine-id-file string     Default: "/etc/machine-id,/var/lib/dbus/machine-id" +--log_backtrace_at <a string in the form 'file:N'>     Default: :0 -

Comma-separated list of files to check for machine-id. Use the first one that exists.

+

when logging hits line file:N, emit a stack trace

+ + + +--log_dir string + + +

If non-empty, write log files in this directory

+ + + +--log_file string + + +

If non-empty, use this log file

+ + + +--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.

+ + + +--logtostderr     Default: true + + +

log to standard error instead of files

@@ -343,6 +343,13 @@ kube-proxy [flags]

A string slice of values which specify the addresses to use for NodePorts. Values may be valid IP blocks (e.g. 1.2.3.0/24, 1.2.3.4/32). The default empty string slice ([]) means to use all local addresses. This parameter is ignored if a config file is specified by --config.

+ +--one_output + + +

If true, only write logs to their native severity level (vs also writing to each lower severity level)

+ + --oom-score-adj int32     Default: -999 @@ -392,6 +399,27 @@ kube-proxy [flags]

The previous version for which you want to show hidden metrics. Only the previous minor version is meaningful, other values will not be allowed. The format is <major>.<minor>, e.g.: '1.16'. The purpose of this format is make sure you have the opportunity to notice if the next release hides additional metrics, rather than being surprised when they are permanently removed in the release after that.This parameter is ignored if a config file is specified by --config.

+ +--skip_headers + + +

If true, avoid header prefixes in the log messages

+ + + +--skip_log_headers + + +

If true, avoid headers when opening log files

+ + + +--stderrthreshold int     Default: 2 + + +

logs at or above this threshold go to stderr

+ + --udp-timeout duration     Default: 250ms @@ -399,6 +427,13 @@ kube-proxy [flags]

How long an idle UDP connection will be kept open (e.g. '250ms', '2s'). Must be greater than 0. Only applicable for proxy-mode=userspace

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

number for the log level verbosity

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

Print version information and quit

+ +--vmodule <comma-separated 'pattern=N' settings> + + +

comma-separated list of pattern=N settings for file-filtered logging

+ + --write-config-to string 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 index 32b6aeb191..2189c4910d 100644 --- a/content/en/docs/reference/config-api/apiserver-eventratelimit.v1alpha1.md +++ b/content/en/docs/reference/config-api/apiserver-eventratelimit.v1alpha1.md @@ -1,7 +1,7 @@ --- title: Event Rate Limit Configuration (v1alpha1) content_type: tool-reference -package: evenratelimit.admission.k8s.io/v1alpha1 +package: eventratelimit.admission.k8s.io/v1alpha1 auto_generated: true --- @@ -9,11 +9,11 @@ auto_generated: true ## Resource Types -- [Configuration](#evenratelimit-admission-k8s-io-v1alpha1-Configuration) +- [Configuration](#eventratelimit-admission-k8s-io-v1alpha1-Configuration) -## `Configuration` {#evenratelimit-admission-k8s-io-v1alpha1-Configuration} +## `Configuration` {#eventratelimit-admission-k8s-io-v1alpha1-Configuration} @@ -25,12 +25,12 @@ controller.

FieldDescription -apiVersion
stringevenratelimit.admission.k8s.io/v1alpha1 +apiVersion
stringeventratelimit.admission.k8s.io/v1alpha1 kind
stringConfiguration limits [Required]
-[]Limit +[]Limit

limits are the limits to place on event queries received. @@ -42,12 +42,12 @@ At least one limit is required.

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

Limit is the configuration for a particular limit type

@@ -59,7 +59,7 @@ At least one limit is required.

type [Required]
-LimitType +LimitType

type is the type of limit to which this configuration applies

@@ -105,17 +105,17 @@ allowance of burst queries.

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

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

- + \ No newline at end of file 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/config-api/kubelet-config.v1beta1.md b/content/en/docs/reference/config-api/kubelet-config.v1beta1.md index ed68500044..42755470cb 100644 --- a/content/en/docs/reference/config-api/kubelet-config.v1beta1.md +++ b/content/en/docs/reference/config-api/kubelet-config.v1beta1.md @@ -943,7 +943,7 @@ Default: ""

systemReservedCgroup helps the kubelet identify absolute name of top level CGroup used to enforce systemReserved compute resource reservation for OS system daemons. -Refer to Node Allocatable +Refer to Node Allocatable doc for more information. Default: ""

@@ -954,7 +954,7 @@ Default: ""

kubeReservedCgroup helps the kubelet identify absolute name of top level CGroup used to enforce KubeReserved compute resource reservation for Kubernetes node system daemons. -Refer to Node Allocatable +Refer to Node Allocatable doc for more information. Default: ""

@@ -970,7 +970,7 @@ If none is specified, no other options may be specified. When system-reserved is in the list, systemReservedCgroup must be specified. When kube-reserved is in the list, kubeReservedCgroup must be specified. This field is supported only when cgroupsPerQOS is set to true. -Refer to Node Allocatable +Refer to Node Allocatable for more information. Default: ["pods"]

diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md index e1711ea542..3f96fd6e4c 100644 --- a/content/en/docs/reference/kubectl/cheatsheet.md +++ b/content/en/docs/reference/kubectl/cheatsheet.md @@ -30,7 +30,7 @@ You can also use a shorthand alias for `kubectl` that also works with completion ```bash alias k=kubectl -complete -F __start_kubectl k +complete -o default -F __start_kubectl k ``` ### ZSH @@ -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/kubernetes-api/workload-resources/pod-v1.md b/content/en/docs/reference/kubernetes-api/workload-resources/pod-v1.md index dbcc8f889e..d26dfdbaf9 100644 --- a/content/en/docs/reference/kubernetes-api/workload-resources/pod-v1.md +++ b/content/en/docs/reference/kubernetes-api/workload-resources/pod-v1.md @@ -1879,7 +1879,7 @@ PodStatus represents information about the status of a pod. Status may trail the - **qosClass** (string) - The Quality of Service (QOS) classification assigned to the pod based on resource requirements See PodQOSClass type for available QOS classes More info: https://git.k8s.io/community/contributors/design-proposals/node/resource-qos.md + The Quality of Service (QOS) classification assigned to the pod based on resource requirements See PodQOSClass type for available QOS classes More info: https://git.k8s.io/design-proposals-archive/node/resource-qos.md diff --git a/content/en/docs/reference/ports-and-protocols.md b/content/en/docs/reference/ports-and-protocols.md index 91d6cba8e7..8ca5bc0774 100644 --- a/content/en/docs/reference/ports-and-protocols.md +++ b/content/en/docs/reference/ports-and-protocols.md @@ -7,7 +7,7 @@ weight: 50 When running Kubernetes in an environment with strict network boundaries, such as on-premises datacenter with physical network firewalls or Virtual Networks in Public Cloud, it is useful to be aware of the ports and protocols -used by Kubernetes components +used by Kubernetes components. ## Control plane diff --git a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md index 74428b9148..4a9e125379 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md +++ b/content/en/docs/reference/setup-tools/kubeadm/implementation-details.md @@ -219,7 +219,7 @@ Other API server flags that are set unconditionally are: - `--insecure-port=0` to avoid insecure connections to the api server - `--enable-bootstrap-token-auth=true` to enable the `BootstrapTokenAuthenticator` authentication module. - See [TLS Bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for more details + See [TLS Bootstrapping](/docs/reference/access-authn-authn/kubelet-tls-bootstrapping/) for more details - `--allow-privileged` to `true` (required e.g. by kube proxy) - `--requestheader-client-ca-file` to `front-proxy-ca.crt` - `--enable-admission-plugins` to: @@ -266,7 +266,7 @@ The static Pod manifest for the controller manager is affected by following para Other flags that are set unconditionally are: - `--controllers` enabling all the default controllers plus `BootstrapSigner` and `TokenCleaner` controllers for TLS bootstrap. - See [TLS Bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) for more details + See [TLS Bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) for more details - `--use-service-account-credentials` to `true` - Flags for using certificates generated in previous steps: - `--root-ca-file` to `ca.crt` @@ -329,7 +329,7 @@ Please note that: ### Configure TLS-Bootstrapping for node joining Kubeadm uses [Authenticating with Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) for joining new nodes to an -existing cluster; for more details see also [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md). +existing cluster; for more details see also [design proposal](https://git.k8s.io/design-proposals-archive/cluster-lifecycle/bootstrap-discovery.md). `kubeadm init` ensures that everything is properly configured for this process, and this includes following steps as well as setting API server and controller flags as already described in previous paragraphs. @@ -420,7 +420,7 @@ Similarly to `kubeadm init`, also `kubeadm join` internal workflow consists of a This is split into discovery (having the Node trust the Kubernetes Master) and TLS bootstrap (having the Kubernetes Master trust the Node). -see [Authenticating with Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) or the corresponding [design proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md). +see [Authenticating with Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) or the corresponding [design proposal](https://git.k8s.io/design-proposals-archive/cluster-lifecycle/bootstrap-discovery.md). ### Preflight checks diff --git a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md index fc87e796c2..2abccfd8b6 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md +++ b/content/en/docs/reference/setup-tools/kubeadm/kubeadm-init.md @@ -52,7 +52,7 @@ following steps: 1. Makes all the necessary configurations for allowing node joining with the [Bootstrap Tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) and - [TLS Bootstrap](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) + [TLS Bootstrap](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) mechanism: - Write a ConfigMap for making available all the information required diff --git a/content/en/docs/reference/using-api/_index.md b/content/en/docs/reference/using-api/_index.md index 5e335fb191..6592deb3c7 100644 --- a/content/en/docs/reference/using-api/_index.md +++ b/content/en/docs/reference/using-api/_index.md @@ -39,7 +39,7 @@ The JSON and Protobuf serialization schemas follow the same guidelines for schema changes. The following descriptions cover both formats. The API versioning and software versioning are indirectly related. -The [API and release versioning proposal](https://git.k8s.io/community/contributors/design-proposals/release/versioning.md) +The [API and release versioning proposal](https://git.k8s.io/design-proposals-archive/release/versioning.md) describes the relationship between API versioning and software versioning. Different API versions indicate different levels of stability and support. You @@ -83,7 +83,7 @@ Here's a summary of each level: ## API groups -[API groups](https://git.k8s.io/community/contributors/design-proposals/api-machinery/api-group.md) +[API groups](https://git.k8s.io/design-proposals-archive/api-machinery/api-group.md) make it easier to extend the Kubernetes API. The API group is specified in a REST path and in the `apiVersion` field of a serialized object. @@ -124,4 +124,4 @@ Kubernetes stores its serialized state in terms of the API resources by writing - Learn more about [API conventions](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#api-conventions) - Read the design documentation for - [aggregator](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/api-machinery/aggregated-api-servers.md) + [aggregator](https://git.k8s.io/design-proposals-archive/api-machinery/aggregated-api-servers.md) diff --git a/content/en/docs/reference/using-api/api-concepts.md b/content/en/docs/reference/using-api/api-concepts.md index 2e4fb85df2..1a722acffd 100644 --- a/content/en/docs/reference/using-api/api-concepts.md +++ b/content/en/docs/reference/using-api/api-concepts.md @@ -15,8 +15,8 @@ primary resources via the standard HTTP verbs (POST, PUT, PATCH, DELETE, GET). For some resources, the API includes additional subresources that allow -fine grained authorization (such as a separating viewing details for a Pod from -retrieving its logs), and can accept and serve those resources in different +fine grained authorization (such as separate views for Pod details and +log retrievals), and can accept and serve those resources in different representations for convenience or efficiency. Kubernetes supports efficient change notifications on resources via *watches*. 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/best-practices/certificates.md b/content/en/docs/setup/best-practices/certificates.md index 6d6d576c39..23e4ac8df7 100644 --- a/content/en/docs/setup/best-practices/certificates.md +++ b/content/en/docs/setup/best-practices/certificates.md @@ -22,7 +22,7 @@ This page explains the certificates that your cluster requires. Kubernetes requires PKI for the following operations: * Client certificates for the kubelet to authenticate to the API server -* Kubelet [server certificates](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#client-and-serving-certificates) +* Kubelet [server certificates](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#client-and-serving-certificates) for the API server to talk to the kubelets * Server certificate for the API server endpoint * Client certificates for administrators of the cluster to authenticate to the API server 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/tools/kubeadm/create-cluster-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md index d7897dfec5..697dbdd673 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm.md @@ -603,7 +603,7 @@ Workarounds: kubeadm deb/rpm packages and binaries are built for amd64, arm (32-bit), arm64, ppc64le, and s390x following the [multi-platform -proposal](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/multi-platform.md). +proposal](https://git.k8s.io/design-proposals-archive/multi-platform.md). Multiplatform container images for the control plane and addons are also supported since v1.12. diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md index 0573fb942e..c5abcde425 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md @@ -45,7 +45,7 @@ The general approach is to generate all certs on one node and only distribute the *necessary* files to the other nodes. {{< note >}} -kubeadm contains all the necessary crytographic machinery to generate +kubeadm contains all the necessary cryptographic machinery to generate the certificates described below; no other cryptographic tooling is required for this example. {{< /note >}} 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..0c3d05d62f 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 @@ -22,7 +22,8 @@ It does not mean that there is a file named `kubeconfig`. {{< warning >}} -Only use kubeconfig files from trusted sources. Using a specially-crafted kubeconfig file could result in malicious code execution or file exposure. +Only use kubeconfig files from trusted sources. Using a specially-crafted kubeconfig +file could result in malicious code execution or file exposure. If you must use an untrusted kubeconfig file, inspect it carefully first, much as you would a shell script. {{< /warning>}} @@ -50,7 +51,7 @@ to the scratch cluster requires authentication by username and password. Create a directory named `config-exercise`. In your `config-exercise` directory, create a file named `config-demo` with this content: -```shell +```yaml apiVersion: v1 kind: Config preferences: {} @@ -115,7 +116,7 @@ kubectl config --kubeconfig=config-demo view The output shows the two clusters, two users, and three contexts: -```shell +```yaml apiVersion: v1 clusters: - cluster: @@ -271,7 +272,7 @@ For example: ### Linux ```shell -export KUBECONFIG_SAVED=$KUBECONFIG +export KUBECONFIG_SAVED="$KUBECONFIG" ``` ### Windows PowerShell @@ -290,7 +291,7 @@ Temporarily append two paths to your `KUBECONFIG` environment variable. For exam ### Linux ```shell -export KUBECONFIG=$KUBECONFIG:config-demo:config-demo-2 +export KUBECONFIG="${KUBECONFIG}:config-demo:config-demo-2" ``` ### Windows PowerShell @@ -356,7 +357,7 @@ For example: ### Linux ```shell -export KUBECONFIG=$KUBECONFIG:$HOME/.kube/config +export KUBECONFIG="${KUBECONFIG}:${HOME}/.kube/config" ``` ### Windows Powershell @@ -379,7 +380,7 @@ Return your `KUBECONFIG` environment variable to its original value. For example ### Linux ```shell -export KUBECONFIG=$KUBECONFIG_SAVED +export KUBECONFIG="$KUBECONFIG_SAVED" ``` ### Windows PowerShell 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/configure-cgroup-driver.md b/content/en/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md index d9df7fb38c..97fa2bc352 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md @@ -68,9 +68,7 @@ and passing it to the local node kubelet. ## Using the `cgroupfs` driver -As this guide explains using the `cgroupfs` driver with kubeadm is not recommended. - -To continue using `cgroupfs` and to prevent `kubeadm upgrade` from modifying the +To use `cgroupfs` and to prevent `kubeadm upgrade` from modifying the `KubeletConfiguration` cgroup driver on existing setups, you must be explicit about its value. This applies to a case where you do not wish future versions of kubeadm to apply the `systemd` driver by default. diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md index 696a69ba82..f846f3c32d 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-certs.md @@ -276,7 +276,7 @@ By default, these serving certificate will expire after one year. Kubeadm sets t `KubeletConfiguration` field `rotateCertificates` to `true`, which means that close to expiration a new set of CSRs for the serving certificates will be created and must be approved to complete the rotation. To understand more see -[Certificate Rotation](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#certificate-rotation). +[Certificate Rotation](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#certificate-rotation). If you are looking for a solution for automatic approval of these CSRs it is recommended that you contact your cloud provider and ask if they have a CSR signer that verifies 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..783b107927 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. @@ -79,83 +79,87 @@ Pick a control plane node that you wish to upgrade first. It must have the `/etc **For the first control plane node** -- Upgrade kubeadm: +- Upgrade kubeadm: -{{< tabs name="k8s_install_kubeadm_first_cp" >}} -{{% tab name="Ubuntu, Debian or HypriotOS" %}} - # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version - apt-mark unhold kubeadm && \ - apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \ - apt-mark hold kubeadm -{{% /tab %}} -{{% tab name="CentOS, RHEL or Fedora" %}} - # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version - yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes -{{% /tab %}} -{{< /tabs >}} -
+ {{< tabs name="k8s_install_kubeadm_first_cp" >}} + {{% tab name="Ubuntu, Debian or HypriotOS" %}} + ```shell + # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version + apt-mark unhold kubeadm && \ + apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \ + apt-mark hold kubeadm + ``` + {{% /tab %}} + {{% tab name="CentOS, RHEL or Fedora" %}} + ```shell + # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version + yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes + ``` + {{% /tab %}} + {{< /tabs >}} +
-- Verify that the download works and has the expected version: +- Verify that the download works and has the expected version: - ```shell - kubeadm version - ``` + ```shell + kubeadm version + ``` -- Verify the upgrade plan: +- Verify the upgrade plan: - ```shell - kubeadm upgrade plan - ``` + ```shell + kubeadm upgrade plan + ``` - This command checks that your cluster can be upgraded, and fetches the versions you can upgrade to. - It also shows a table with the component config version states. + This command checks that your cluster can be upgraded, and fetches the versions you can upgrade to. + It also shows a table with the component config version states. -{{< note >}} -`kubeadm upgrade` also automatically renews the certificates that it manages on this node. -To opt-out of certificate renewal the flag `--certificate-renewal=false` can be used. -For more information see the [certificate management guide](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs). -{{}} + {{< note >}} + `kubeadm upgrade` also automatically renews the certificates that it manages on this node. + To opt-out of certificate renewal the flag `--certificate-renewal=false` can be used. + For more information see the [certificate management guide](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs). + {{}} + + {{< note >}} + If `kubeadm upgrade plan` shows any component configs that require manual upgrade, users must provide + a config file with replacement configs to `kubeadm upgrade apply` via the `--config` command line flag. + Failing to do so will cause `kubeadm upgrade apply` to exit with an error and not perform an upgrade. + {{}} -{{< note >}} -If `kubeadm upgrade plan` shows any component configs that require manual upgrade, users must provide -a config file with replacement configs to `kubeadm upgrade apply` via the `--config` command line flag. -Failing to do so will cause `kubeadm upgrade apply` to exit with an error and not perform an upgrade. -{{}} +- Choose a version to upgrade to, and run the appropriate command. For example: -- Choose a version to upgrade to, and run the appropriate command. For example: + ```shell + # replace x with the patch version you picked for this upgrade + sudo kubeadm upgrade apply v{{< skew currentVersion >}}.x + ``` - ```shell - # replace x with the patch version you picked for this upgrade - sudo kubeadm upgrade apply v{{< skew currentVersion >}}.x - ``` + Once the command finishes you should see: - Once the command finishes you should see: + ``` + [upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew currentVersion >}}.x". Enjoy! - ``` - [upgrade/successful] SUCCESS! Your cluster was upgraded to "v{{< skew currentVersion >}}.x". Enjoy! + [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so. + ``` - [upgrade/kubelet] Now that your control plane is upgraded, please proceed with upgrading your kubelets if you haven't already done so. - ``` +- Manually upgrade your CNI provider plugin. -- Manually upgrade your CNI provider plugin. + Your Container Network Interface (CNI) provider may have its own upgrade instructions to follow. + Check the [addons](/docs/concepts/cluster-administration/addons/) page to + find your CNI provider and see whether additional upgrade steps are required. - Your Container Network Interface (CNI) provider may have its own upgrade instructions to follow. - Check the [addons](/docs/concepts/cluster-administration/addons/) page to - find your CNI provider and see whether additional upgrade steps are required. - - This step is not required on additional control plane nodes if the CNI provider runs as a DaemonSet. + This step is not required on additional control plane nodes if the CNI provider runs as a DaemonSet. **For the other control plane nodes** Same as the first control plane node but use: -``` +```shell sudo kubeadm upgrade node ``` instead of: -``` +```shell sudo kubeadm upgrade apply ``` @@ -163,46 +167,50 @@ Also calling `kubeadm upgrade plan` and upgrading the CNI provider plugin is no ### Drain the node -- Prepare the node for maintenance by marking it unschedulable and evicting the workloads: +- Prepare the node for maintenance by marking it unschedulable and evicting the workloads: - ```shell - # replace with the name of your node you are draining - kubectl drain --ignore-daemonsets - ``` + ```shell + # replace with the name of your node you are draining + kubectl drain --ignore-daemonsets + ``` ### Upgrade kubelet and kubectl -- Upgrade the kubelet and kubectl: +- Upgrade the kubelet and kubectl: -{{< tabs name="k8s_install_kubelet" >}} -{{% tab name="Ubuntu, Debian or HypriotOS" %}} - # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version - apt-mark unhold kubelet kubectl && \ - apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \ - apt-mark hold kubelet kubectl -{{% /tab %}} -{{% tab name="CentOS, RHEL or Fedora" %}} - # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version - yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes -{{% /tab %}} -{{< /tabs >}} -
+ {{< tabs name="k8s_install_kubelet" >}} + {{% tab name="Ubuntu, Debian or HypriotOS" %}} + ```shell + # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version + apt-mark unhold kubelet kubectl && \ + apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \ + apt-mark hold kubelet kubectl + ``` + {{% /tab %}} + {{% tab name="CentOS, RHEL or Fedora" %}} + ```shell + # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version + yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes + ``` + {{% /tab %}} + {{< /tabs >}} +
-- Restart the kubelet: +- Restart the kubelet: - ```shell - sudo systemctl daemon-reload - sudo systemctl restart kubelet - ``` + ```shell + sudo systemctl daemon-reload + sudo systemctl restart kubelet + ``` ### Uncordon the node -- Bring the node back online by marking it schedulable: +- Bring the node back online by marking it schedulable: - ```shell - # replace with the name of your node - kubectl uncordon - ``` + ```shell + # replace with the name of your node + kubectl uncordon + ``` ## Upgrade worker nodes @@ -211,76 +219,83 @@ without compromising the minimum required capacity for running your workloads. ### Upgrade kubeadm -- Upgrade kubeadm: +- Upgrade kubeadm: -{{< tabs name="k8s_install_kubeadm_worker_nodes" >}} -{{% tab name="Ubuntu, Debian or HypriotOS" %}} - # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version - apt-mark unhold kubeadm && \ - apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \ - apt-mark hold kubeadm -{{% /tab %}} -{{% tab name="CentOS, RHEL or Fedora" %}} - # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version - yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes -{{% /tab %}} -{{< /tabs >}} + {{< tabs name="k8s_install_kubeadm_worker_nodes" >}} + {{% tab name="Ubuntu, Debian or HypriotOS" %}} + ```shell + # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version + apt-mark unhold kubeadm && \ + apt-get update && apt-get install -y kubeadm={{< skew currentVersion >}}.x-00 && \ + apt-mark hold kubeadm + ``` + {{% /tab %}} + {{% tab name="CentOS, RHEL or Fedora" %}} + ```shell + # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version + yum install -y kubeadm-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes + ``` + {{% /tab %}} + {{< /tabs >}} ### Call "kubeadm upgrade" -- For worker nodes this upgrades the local kubelet configuration: +- For worker nodes this upgrades the local kubelet configuration: - ```shell - sudo kubeadm upgrade node - ``` + ```shell + sudo kubeadm upgrade node + ``` ### Drain the node -- Prepare the node for maintenance by marking it unschedulable and evicting the workloads: +- Prepare the node for maintenance by marking it unschedulable and evicting the workloads: - ```shell - # replace with the name of your node you are draining - kubectl drain --ignore-daemonsets - ``` + ```shell + # replace with the name of your node you are draining + kubectl drain --ignore-daemonsets + ``` ### Upgrade kubelet and kubectl -- Upgrade the kubelet and kubectl: +- Upgrade the kubelet and kubectl: -{{< tabs name="k8s_kubelet_and_kubectl" >}} -{{% tab name="Ubuntu, Debian or HypriotOS" %}} - # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version - apt-mark unhold kubelet kubectl && \ - apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \ - apt-mark hold kubelet kubectl -{{% /tab %}} -{{% tab name="CentOS, RHEL or Fedora" %}} - # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version - yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes -{{% /tab %}} -{{< /tabs >}} -
+ {{< tabs name="k8s_kubelet_and_kubectl" >}} + {{% tab name="Ubuntu, Debian or HypriotOS" %}} + ```shell + # replace x in {{< skew currentVersion >}}.x-00 with the latest patch version + apt-mark unhold kubelet kubectl && \ + apt-get update && apt-get install -y kubelet={{< skew currentVersion >}}.x-00 kubectl={{< skew currentVersion >}}.x-00 && \ + apt-mark hold kubelet kubectl + {{% /tab %}} + {{% tab name="CentOS, RHEL or Fedora" %}} + ```shell + # replace x in {{< skew currentVersion >}}.x-0 with the latest patch version + yum install -y kubelet-{{< skew currentVersion >}}.x-0 kubectl-{{< skew currentVersion >}}.x-0 --disableexcludes=kubernetes + ``` + {{% /tab %}} + {{< /tabs >}} +
-- Restart the kubelet: +- Restart the kubelet: - ```shell - sudo systemctl daemon-reload - sudo systemctl restart kubelet - ``` + ```shell + sudo systemctl daemon-reload + sudo systemctl restart kubelet + ``` ### Uncordon the node -- Bring the node back online by marking it schedulable: +- Bring the node back online by marking it schedulable: - ```shell - # replace with the name of your node - kubectl uncordon - ``` + ```shell + # replace with the name of your node + kubectl uncordon + ``` ## Verify the status of the cluster -After the kubelet is upgraded on all nodes verify that all nodes are available again by running the following command -from anywhere kubectl can access the cluster: +After the kubelet is upgraded on all nodes verify that all nodes are available again by running +the following command from anywhere kubectl can access the cluster: ```shell kubectl get nodes @@ -296,6 +311,7 @@ This command is idempotent and eventually makes sure that the actual state is th To recover from a bad state, you can also run `kubeadm upgrade apply --force` without changing the version that your cluster is running. During upgrade kubeadm writes the following backup folders under `/etc/kubernetes/tmp`: + - `kubeadm-backup-etcd--
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/expose/expose-intro.html b/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html index 1996859e2e..b362669c05 100644 --- a/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/en/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -66,7 +66,7 @@ weight: 10
-

A Service routes traffic across a set of Pods. Services are the abstraction that allow pods to die and replicate in Kubernetes without impacting your application. Discovery and routing among dependent Pods (such as the frontend and backend components in an application) is handled by Kubernetes Services.

+

A Service routes traffic across a set of Pods. Services are the abstraction that allows pods to die and replicate in Kubernetes without impacting your application. Discovery and routing among dependent Pods (such as the frontend and backend components in an application) are handled by Kubernetes Services.

Services match a set of Pods using labels and selectors, a grouping primitive that allows logical operation on objects in Kubernetes. Labels are key/value pairs attached to objects and can be used in any number of ways:

  • Designate objects for development, test, and production
    • 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/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md b/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md index e5f32633e3..d3c426d789 100644 --- a/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md +++ b/content/en/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume.md @@ -16,7 +16,7 @@ This tutorial shows you how to deploy a WordPress site and a MySQL database usin A [PersistentVolume](/docs/concepts/storage/persistent-volumes/) (PV) is a piece of storage in the cluster that has been manually provisioned by an administrator, or dynamically provisioned by Kubernetes using a [StorageClass](/docs/concepts/storage/storage-classes). A [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) (PVC) is a request for storage by a user that can be fulfilled by a PV. PersistentVolumes and PersistentVolumeClaims are independent from Pod lifecycles and preserve data through restarting, rescheduling, and even deleting Pods. {{< warning >}} -This deployment is not suitable for production use cases, as it uses single instance WordPress and MySQL Pods. Consider using [WordPress Helm Chart](https://github.com/kubernetes/charts/tree/master/stable/wordpress) to deploy WordPress in production. +This deployment is not suitable for production use cases, as it uses single instance WordPress and MySQL Pods. Consider using [WordPress Helm Chart](https://github.com/bitnami/charts/tree/master/bitnami/wordpress) to deploy WordPress in production. {{< /warning >}} {{< note >}} diff --git a/content/en/examples/application/mysql/mysql-configmap.yaml b/content/en/examples/application/mysql/mysql-configmap.yaml index 6aa5bfe4e5..519334bc82 100644 --- a/content/en/examples/application/mysql/mysql-configmap.yaml +++ b/content/en/examples/application/mysql/mysql-configmap.yaml @@ -9,10 +9,8 @@ data: # Apply this config only on the primary. [mysqld] log-bin - datadir=/var/lib/mysql/mysql replica.cnf: | # Apply this config only on replicas. [mysqld] super-read-only - datadir=/var/lib/mysql/mysql 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/release.md b/content/en/releases/release.md index 5542b41202..177fb4f8cd 100644 --- a/content/en/releases/release.md +++ b/content/en/releases/release.md @@ -124,7 +124,7 @@ The general labeling process should be consistent across artifact types. referring to a release MAJOR.MINOR `vX.Y` version. See also - [release versioning](/contributors/design-proposals/release/versioning.md). + [release versioning](https://git.k8s.io/design-proposals-archive/release/versioning.md). - _release branch_: Git branch `release-X.Y` created for the `vX.Y` milestone. diff --git a/content/en/releases/version-skew-policy.md b/content/en/releases/version-skew-policy.md index 87f6cf2c62..8188a19549 100644 --- a/content/en/releases/version-skew-policy.md +++ b/content/en/releases/version-skew-policy.md @@ -21,12 +21,12 @@ Specific cluster deployment tools may place additional restrictions on version s ## Supported versions Kubernetes versions are expressed as **x.y.z**, where **x** is the major version, **y** is the minor version, and **z** is the patch version, following [Semantic Versioning](https://semver.org/) terminology. -For more information, see [Kubernetes Release Versioning](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/release/versioning.md#kubernetes-release-versioning). +For more information, see [Kubernetes Release Versioning](https://git.k8s.io/design-proposals-archive/release/versioning.md#kubernetes-release-versioning). The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew latestVersion >}}, {{< skew prevMinorVersion >}}, {{< skew oldestMinorVersion >}}). 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/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/tasks/configure-pod-container/static-pod.md b/content/id/docs/tasks/configure-pod-container/static-pod.md index 6088b458db..b13c95608b 100644 --- a/content/id/docs/tasks/configure-pod-container/static-pod.md +++ b/content/id/docs/tasks/configure-pod-container/static-pod.md @@ -33,7 +33,7 @@ sebuah {{< glossary_tooltip text="DaemonSet" term_id="daemonset" >}}. {{< include "task-tutorial-prereqs.md" >}} {{< version-check >}} -Laman ini mengasumsikan kamu menggunakan {{< glossary_tooltip term_id="docker" >}} +Laman ini mengasumsikan kamu menggunakan {{< glossary_tooltip term_id="cri-o" >}} untuk menjalankan Pod, dan Node kamu berjalan menggunakan sistem operasi Fedora. Instruksi untuk distribusi lain atau instalasi Kubernetes mungkin berbeda. @@ -90,23 +90,23 @@ Sebagai contoh, ini cara untuk memulai server web sederhana sebagai Pod statis: 3. Atur kubelet pada Node untuk menggunakan direktori ini dengan menjalankannya menggunakan argumen `--pod-manifest-path=/etc/kubelet.d/`. Pada Fedora, ubah berkas `/etc/kubernetes/kubelet` dengan menambahkan baris berikut: - ``` - KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/" - ``` - atau tambahkan _field_ `staticPodPath: ` pada [berkas konfigurasi kubelet](/docs/tasks/administer-cluster/kubelet-config-file). + ``` + KUBELET_ARGS="--cluster-dns=10.254.0.10 --cluster-domain=kube.local --pod-manifest-path=/etc/kubelet.d/" + ``` + atau tambahkan _field_ `staticPodPath: ` pada [berkas konfigurasi kubelet](/docs/tasks/administer-cluster/kubelet-config-file). 4. Jalankan ulang kubelet. Pada Fedora, kamu dapat menjalankan: - ```shell - # Jalankan perintah berikut pada Node tempat kubelet berjalan - systemctl restart kubelet - ``` + ```shell + # Jalankan perintah berikut pada Node tempat kubelet berjalan + systemctl restart kubelet + ``` ### Manifes Pod statis pada Web {#konfigurasi-melalui-http} Berkas yang ditentukan pada argumen `--manifest-url=` akan diunduh oleh kubelet secara berkala dan kubelet akan menginterpretasinya sebagai sebuah berkas JSON/YAML yang berisikan definisi Pod. -Mirip dengan cara kerja [manifes pada _filesystem_](##konfigurasi-melalui-berkas-sistem), +Mirip dengan cara kerja [manifes pada _filesystem_](#konfigurasi-melalui-berkas-sistem), kubelet akan mengambil manifes berdasarkan jadwal. Jika ada perubahan pada daftar Pod statis, maka kubelet akan menerapkannya. @@ -153,12 +153,12 @@ akan dijalankan. Kamu dapat melihat Container yang berjalan (termasuk Pod statis) dengan menjalankan (pada Node): ```shell # Jalankan perintah ini pada Node tempat kubelet berjalan -docker ps +crictl ps ``` Keluarannya kira-kira seperti berikut: -``` +```console CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES f6d05272b57e nginx:latest "nginx" 8 minutes ago Up 8 minutes k8s_web.6f802af4_static-web-fk-node1_default_67e24ed9466ba55986d120c867395f3c_378e5f3c ``` @@ -169,8 +169,8 @@ Kamu dapat melihat Pod _mirror_ tersebut pada API server: kubectl get pods ``` ``` -NAME READY STATUS RESTARTS AGE -static-web-my-node1 1/1 Running 0 2m +NAME READY STATUS RESTARTS AGE +static-web 1/1 Running 0 2m ``` {{< note >}} @@ -189,18 +189,18 @@ Kamu dapat mencoba untuk menggunakan kubelet untuk menghapus Pod _mirror_ terseb namun kubelet tidak akan menghapus Pod statis: ```shell -kubectl delete pod static-web-my-node1 +kubectl delete pod static-web ``` ``` -pod "static-web-my-node1" deleted +pod "static-web" deleted ``` Kamu akan melihat bahwa Pod tersebut tetap berjalan: ```shell kubectl get pods ``` ``` -NAME READY STATUS RESTARTS AGE -static-web-my-node1 1/1 Running 0 12s +NAME READY STATUS RESTARTS AGE +static-web 1/1 Running 0 4s ``` Kembali ke Node tempat kubelet berjalan, kamu dapat mencoba menghentikan Container @@ -210,13 +210,13 @@ secara otomatis: ```shell # Jalankan perintah ini pada Node tempat kubelet berjalan -docker stop f6d05272b57e # ganti dengan ID pada Container-mu +crictl stop 129fd7d382018 # ganti dengan ID pada Container-mu sleep 20 -docker ps +crictl ps ``` -``` -CONTAINER ID IMAGE COMMAND CREATED ... -5b920cbaf8b1 nginx:latest "nginx -g 'daemon of 2 seconds ago ... +```console +CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID +89db4553e1eeb docker.io/library/nginx@sha256:... 19 seconds ago Running web 1 34533c6729106 ``` ## Penambahan dan pengurangan secara dinamis pada Pod statis @@ -231,13 +231,13 @@ Pod sesuai dengan penambahan/pengurangan berkas pada direktori tersebut. # mv /etc/kubelet.d/static-web.yaml /tmp sleep 20 -docker ps +crictl ps # Kamu mendapatkan bahwa tidak ada Container nginx yang berjalan mv /tmp/static-web.yaml /etc/kubelet.d/ sleep 20 -docker ps +crictl ps ``` -``` -CONTAINER ID IMAGE COMMAND CREATED ... -e7a62e3427f1 nginx:latest "nginx -g 'daemon of 27 seconds ago +```console +CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID +f427638871c35 docker.io/library/nginx@sha256:... 19 seconds ago Running web 1 34533c6729106 ``` 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/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/administer-cluster/manage-resources/memory-default-namespace.md b/content/ja/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md new file mode 100644 index 0000000000..8266904358 --- /dev/null +++ b/content/ja/docs/tasks/administer-cluster/manage-resources/memory-default-namespace.md @@ -0,0 +1,197 @@ +--- +title: ネームスペースのデフォルトのメモリー要求と制限を設定する +content_type: task +weight: 10 +description: >- + ネームスペースのデフォルトのメモリーリソース制限を定義して、そのネームスペース内のすべての新しいPodにメモリーリソース制限が設定されるようにします。 +--- + + + +このページでは、{{< glossary_tooltip text="ネームスペース" term_id="namespace" >}}のデフォルトのメモリー要求と制限を設定する方法を説明します。 + +Kubernetesクラスターはネームスペースに分割することができます。デフォルトのメモリー[制限](/ja/docs/concepts/configuration/manage-resources-containers/#requests-and-limits)を持つネームスペースがあり、独自のメモリー制限を指定しないコンテナでPodを作成しようとすると、{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}はそのコンテナにデフォルトのメモリー制限を割り当てます。 + +Kubernetesは、このトピックで後ほど説明する特定の条件下で、デフォルトのメモリー要求を割り当てます。 + + + +## {{% heading "prerequisites" %}} + + +{{< include "task-tutorial-prereqs.md" >}} + +クラスターにネームスペースを作成するには、アクセス権が必要です。 + +クラスターの各ノードには、最低でも2GiBのメモリーが必要です。 + + + + + +## ネームスペースの作成 + +この演習で作成したリソースがクラスターの他の部分から分離されるように、ネームスペースを作成します。 + +```shell +kubectl create namespace default-mem-example +``` + +## LimitRangeとPodの作成 + +以下は、{{< glossary_tooltip text="LimitRange" term_id="limitrange" >}}のマニフェストの例です。このマニフェストでは、デフォルトのメモリー要求とデフォルトのメモリー制限を指定しています。 + +{{< codenew file="admin/resource/memory-defaults.yaml" >}} + +default-mem-exampleネームスペースにLimitRangeを作成します: + +```shell +kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults.yaml --namespace=default-mem-example +``` + +default-mem-exampleネームスペースでPodを作成し、そのPod内のコンテナがメモリー要求とメモリー制限の値を独自に指定しない場合、{{< glossary_tooltip text="コントロールプレーン" term_id="control-plane" >}}はデフォルト値のメモリー要求256MiBとメモリー制限512MiBを適用します。 + +以下は、コンテナを1つ持つPodのマニフェストの例です。コンテナは、メモリー要求とメモリー制限を指定していません。 + +{{< codenew file="admin/resource/memory-defaults-pod.yaml" >}} + +Podを作成します: + +```shell +kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults-pod.yaml --namespace=default-mem-example +``` + +Podの詳細情報を表示します: + +```shell +kubectl get pod default-mem-demo --output=yaml --namespace=default-mem-example +``` + +この出力は、Podのコンテナのメモリー要求が256MiBで、メモリー制限が512MiBであることを示しています。 +これらはLimitRangeで指定されたデフォルト値です。 + +```shell +containers: +- image: nginx + imagePullPolicy: Always + name: default-mem-demo-ctr + resources: + limits: + memory: 512Mi + requests: + memory: 256Mi +``` + +Podを削除します: + +```shell +kubectl delete pod default-mem-demo --namespace=default-mem-example +``` + +## コンテナの制限を指定し、要求を指定しない場合 + +以下は1つのコンテナを持つPodのマニフェストです。コンテナはメモリー制限を指定しますが、メモリー要求は指定しません。 + +{{< codenew file="admin/resource/memory-defaults-pod-2.yaml" >}} + +Podを作成します: + + +```shell +kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults-pod-2.yaml --namespace=default-mem-example +``` + +Podの詳細情報を表示します: + +```shell +kubectl get pod default-mem-demo-2 --output=yaml --namespace=default-mem-example +``` + +この出力は、コンテナのメモリー要求がそのメモリー制限に一致するように設定されていることを示しています。 +コンテナにはデフォルトのメモリー要求値である256Miが割り当てられていないことに注意してください。 + +``` +resources: + limits: + memory: 1Gi + requests: + memory: 1Gi +``` + +## コンテナの要求を指定し、制限を指定しない場合 + +1つのコンテナを持つPodのマニフェストです。コンテナはメモリー要求を指定しますが、メモリー制限は指定しません。 + +{{< codenew file="admin/resource/memory-defaults-pod-3.yaml" >}} + +Podを作成します: + +```shell +kubectl apply -f https://k8s.io/examples/admin/resource/memory-defaults-pod-3.yaml --namespace=default-mem-example +``` + +Podの詳細情報を表示します: + +```shell +kubectl get pod default-mem-demo-3 --output=yaml --namespace=default-mem-example +``` + +この出力は、コンテナのメモリー要求が、コンテナのマニフェストで指定された値に設定されていることを示しています。 +コンテナは512MiB以下のメモリーを使用するように制限されていて、これはネームスペースのデフォルトのメモリー制限と一致します。 + +``` +resources: + limits: + memory: 512Mi + requests: + memory: 128Mi +``` + +## デフォルトのメモリー制限と要求の動機 + +ネームスペースにメモリー{{< glossary_tooltip text="リソースクォータ" term_id="resource-quota" >}}が設定されている場合、メモリー制限のデフォルト値を設定しておくと便利です。 + +以下はリソースクォータがネームスペースに課す制限のうちの2つです。 + +* ネームスペースで実行されるすべてのPodについて、Podとその各コンテナにメモリー制限を設ける必要があります(Pod内のすべてのコンテナに対してメモリー制限を指定すると、Kubernetesはそのコンテナの制限を合計することでPodレベルのメモリー制限を推測することができます)。 +* メモリー制限は、当該Podがスケジュールされているノードのリソース予約を適用します。ネームスペース内のすべてのPodに対して予約されるメモリーの総量は、指定された制限を超えてはなりません。 +* また、ネームスペース内のすべてのPodが実際に使用するメモリーの総量も、指定された制限を超えてはなりません。 + +LimitRangeの追加時: + +コンテナを含む、そのネームスペース内のいずれかのPodが独自のメモリー制限を指定していない場合、コントロールプレーンはそのコンテナにデフォルトのメモリー制限を適用し、メモリーのResourceQuotaによって制限されているネームスペース内でPodを実行できるようにします。 + +## クリーンアップ + +ネームスペースを削除します: + +```shell +kubectl delete namespace default-mem-example +``` + + + +## {{% heading "whatsnext" %}} + + +### クラスター管理者向け + +* [Configure Default CPU Requests and Limits for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/) + +* [Namespaceに対する最小および最大メモリー制約の構成](ja/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/) + +* [Configure Minimum and Maximum CPU Constraints for a Namespace](/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/) + +* [Configure Memory and CPU Quotas for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/) + +* [Configure a Pod Quota for a Namespace](/docs/tasks/administer-cluster/manage-resources/quota-pod-namespace/) + +* [Configure Quotas for API Objects](/docs/tasks/administer-cluster/quota-api-object/) + +### アプリケーション開発者向け + +* [コンテナおよびPodへのメモリーリソースの割り当て](ja/docs/tasks/configure-pod-container/assign-memory-resource/) + +* [コンテナおよびPodへのCPUリソースの割り当て](ja/docs/tasks/configure-pod-container/assign-cpu-resource/) + +* [PodにQuality of Serviceを設定する](ja/docs/tasks/configure-pod-container/quality-service-pod/) 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/admin/resource/cpu-constraints-pod-3.yaml b/content/ja/examples/admin/resource/cpu-constraints-pod-3.yaml deleted file mode 100644 index 896d98ec2f..0000000000 --- a/content/ja/examples/admin/resource/cpu-constraints-pod-3.yaml +++ /dev/null @@ -1,13 +0,0 @@ -apiVersion: v1 -kind: Pod -metadata: - name: constraints-cpu-demo-4 -spec: - containers: - - name: constraints-cpu-demo-4-ctr - image: nginx - resources: - limits: - cpu: "800m" - requests: - cpu: "100m" 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/blog/_posts/2022-02-17-updated-dockershim-faq.md b/content/pt-br/blog/_posts/2022-02-17-updated-dockershim-faq.md index f783edfa43..77e1ce0e6f 100644 --- a/content/pt-br/blog/_posts/2022-02-17-updated-dockershim-faq.md +++ b/content/pt-br/blog/_posts/2022-02-17-updated-dockershim-faq.md @@ -170,7 +170,7 @@ contêiner assim que possível. Outro aspecto a ser observado é que ferramentas para manutenção do sistema ou execuções dentro de um contêiner no momento da criação de imagens podem não funcionar mais. Para o primeiro, a ferramenta [`crictl`][cr] pode ser utilizada como um substituto natural (veja -[migrando do docker cli para o crictl](https://kubernetes.io/docs/tasks/debug-application-cluster/crictl/#mapping-from-docker-cli-to-crictl)) +[migrando do docker cli para o crictl](https://kubernetes.io/docs/tasks/debug/debug-cluster/crictl/#mapping-from-docker-cli-to-crictl)) e para o último, você pode usar novas opções de construções de contêiner, como [img], [buildah], [kaniko], ou [buildkit-cli-for-kubectl] que não requerem Docker. diff --git a/content/pt-br/docs/concepts/cluster-administration/addons.md b/content/pt-br/docs/concepts/cluster-administration/addons.md index f3a00ae26d..73551e9e65 100644 --- a/content/pt-br/docs/concepts/cluster-administration/addons.md +++ b/content/pt-br/docs/concepts/cluster-administration/addons.md @@ -21,7 +21,7 @@ Esta página lista alguns dos complementos disponíveis e links com suas respect * [Canal](https://github.com/tigera/canal/tree/master/k8s-install) une Flannel e Calico, fornecendo rede e política de rede. * [Cilium](https://github.com/cilium/cilium) é um plug-in de rede de camada 3 e de políticas de rede que pode aplicar políticas HTTP/API/camada 7 de forma transparente. Tanto o modo de roteamento quanto o de sobreposição/encapsulamento são suportados. Este plug-in também consegue operar no topo de outros plug-ins CNI. * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) permite que o Kubernetes se conecte facilmente a uma variedade de plug-ins CNI, como Calico, Canal, Flannel, Romana ou Weave. -* [Contiv](http://contiv.github.io) oferece serviços de rede configuráveis para diferentes casos de uso (camada 3 nativa usando BGP, _overlay_ (sobreposição) usando vxlan, camada 2 clássica e Cisco-SDN/ACI) e também um _framework_ rico de políticas de rede. O projeto Contiv é totalmente [open source](http://github.com/contiv). O [instalador](http://github.com/contiv/install) fornece opções de instalação com ou sem kubeadm. +* [Contiv](https://contivpp.io/) oferece serviços de rede configuráveis para diferentes casos de uso (camada 3 nativa usando BGP, _overlay_ (sobreposição) usando vxlan, camada 2 clássica e Cisco-SDN/ACI) e também um _framework_ rico de políticas de rede. O projeto Contiv é totalmente [open source](http://github.com/contiv). O [instalador](http://github.com/contiv/install) fornece opções de instalação com ou sem kubeadm. * [Contrail](http://www.juniper.net/us/en/products-services/sdn/contrail/contrail-networking/) é uma plataforma open source baseada no [Tungsten Fabric](https://tungsten.io) que oferece virtualização de rede multi-nuvem e gerenciamento de políticas de rede. O Contrail e o Tungsten Fabric são integrados a sistemas de orquestração de contêineres, como Kubernetes, OpenShift, OpenStack e Mesos, e fornecem modos de isolamento para cargas de trabalho executando em máquinas virtuais, contêineres/pods e servidores físicos. * [Flannel](https://github.com/flannel-io/flannel#deploying-flannel-manually) é um provedor de redes _overlay_ (sobrepostas) que pode ser usado com o Kubernetes. * [Knitter](https://github.com/ZTE/Knitter/) é um plug-in para suporte de múltiplas interfaces de rede em Pods do Kubernetes. @@ -30,7 +30,7 @@ Esta página lista alguns dos complementos disponíveis e links com suas respect * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) é uma plataforma de rede definida por software que fornece serviços de rede baseados em políticas entre os Pods do Kubernetes e os ambientes não-Kubernetes, com visibilidade e monitoramento de segurança. * [OVN-Kubernetes](https://github.com/ovn-org/ovn-kubernetes/) é um provedor de rede para o Kubernetes baseado no [OVN (Open Virtual Network)](https://github.com/ovn-org/ovn/), uma implementação de redes virtuais que surgiu através do projeto Open vSwitch (OVS). O OVN-Kubernetes fornece uma implementação de rede baseada em _overlay_ (sobreposição) para o Kubernetes, incluindo uma implementação baseada em OVS para serviços de balanceamento de carga e políticas de rede. * [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) é um plug-in controlador CNI baseado no OVN (Open Virtual Network) que fornece serviços de rede _cloud native_, como _Service Function Chaining_ (SFC), redes _overlay_ (sobrepostas) OVN múltiplas, criação dinâmica de subredes, criação dinâmica de redes virtuais, provedor de rede VLAN e provedor de rede direto, e é plugável a outros plug-ins multi-rede. Ideal para cargas de trabalho que utilizam computação de borda _cloud native_ em redes multi-cluster. -* [Romana](http://romana.io) é uma solução de rede de camada 3 para redes de pods que também suporta a [API NetworkPolicy](/docs/concepts/services-networking/network-policies/). Detalhes da instalação do complemento Kubeadm disponíveis [aqui](https://github.com/romana/romana/tree/master/containerize). +* [Romana](https://github.com/romana/romana) é uma solução de rede de camada 3 para redes de pods que também suporta a [API NetworkPolicy](/pt-br/docs/concepts/services-networking/network-policies/). Detalhes da instalação do complemento Kubeadm disponíveis [aqui](https://github.com/romana/romana/tree/master/containerize). * [Weave Net](https://www.weave.works/docs/net/latest/kube-addon/) fornece rede e política de rede, funciona em ambos os lados de uma partição de rede e não requer um banco de dados externo. ## Descoberta de Serviço 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/concepts/storage/volumes.md b/content/pt-br/docs/concepts/storage/volumes.md new file mode 100644 index 0000000000..d2c42b832e --- /dev/null +++ b/content/pt-br/docs/concepts/storage/volumes.md @@ -0,0 +1,978 @@ +--- +reviewers: +- jsafrane +- saad-ali +- thockin +- msau42 +title: Volumes +content_type: conceito +weight: 10 +--- + + + +Os arquivos em disco em um contêiner são efêmeros, o que apresenta alguns problemas para +aplicações não triviais quando executadas em contêineres. Um problema é a perda de arquivos +quando um contêiner quebra. O kubelet reinicia o contêiner, mas em um estado limpo. Um segundo +problema ocorre ao compartilhar arquivos entre contêineres que são executados juntos em +um `Pod`. A abstração de {{< glossary_tooltip text="volume" term_id="volume" >}} +do Kubernetes resolve ambos os problemas. Sugere-se familiaridade com [Pods](/docs/concepts/workloads/pods/) . + + +## Contexto + +Docker tem um conceito de [volumes](https://docs.docker.com/storage/), embora seja um pouco mais +simples e menos gerenciado. Um volume Docker é um diretório em disco ou em outro contêiner. +O Docker oferece drivers de volume, mas a funcionalidade é um pouco limitada. + +O Kubernetes suporta muitos tipos de volumes. Um {{< glossary_tooltip term_id="pod" text="Pod" >}} é capaz de utilizar qualquer quantidade de tipos de volumes simultaneamente. Os tipos de volume efêmeros têm a mesma vida útil do pod, mas os volumes persistentes existem além da vida útil de um pod. Quando um pod deixa de existir, o Kubernetes destrói volumes efêmeros; no entanto, o Kubernetes não destrói volumes persistentes. Para qualquer tipo de volume em um determinado pod, os dados são preservados entre as reinicializações do contêiner. + +Em sua essência, um volume é um diretório, eventualmente com alguns dados dentro dele, que é acessível aos contêineres de um Pod. Como esse diretório vem a ser, o meio que o suporta e o conteúdo do mesmo são determinados pelo tipo particular de volume utilizado. + +Para utilizar um volume, especifique os volumes que serão disponibilizados para o Pod em `.spec.volumes` e declare onde montar esses volumes dentro dos contêineres em `.spec.containers[*].volumeMounts`. Um processo em um contêiner enxerga uma visualização do sistema de arquivos composta pelo do conteúdo inicial da {{< glossary_tooltip text="imagem do contêiner" term_id="image" >}} mais os volumes (se definidos) montados dentro do contêiner. O processo enxerga um sistema de arquivos raiz que inicialmente corresponde ao conteúdo da imagem do contêiner. Qualquer gravação dentro dessa hierarquia do sistema de arquivos, se permitida, afetará o que esse processo enxerga quando ele executa um acesso subsequente ao sistema de arquivos. Os volumes são montados nos [caminhos especificados](#using-subpath) dentro da imagem. Para cada contêiner definido em um Pod, você deve especificar independentemente onde montar cada volume utilizado pelo contêiner. + +Volumes não podem ser montados dentro de outros volumes (mas você pode consultar [Utilizando subPath](#using-subpath) para um mecanismo relacionado). Além disso, um volume não pode conter um link físico para qualquer outro dado em um volume diferente. + +## Tipos de Volumes {#volume-types} + +Kubernetes suporta vários tipos de volumes. + +### awsElasticBlockStore {#awselasticblockstore} + +Um volume `awsElasticBlockStore` monta um [volume EBS](https://aws.amazon.com/ebs/) da Amazon Web Services (AWS) em seu pod. Ao contrário do `emptyDir`que é apagado quando um pod é removido, o conteúdo de um volume EBS é preservado e o volume é desmontado. Isto significa que um volume EBS pode ser previamente populado com dados e que os dados podem ser compartilhados entre Pods. + +{{< note >}} +Você precisa criar um volume EBS usando `aws ec2 create-volume` ou pela API da AWS antes que você consiga utilizá-lo. +{{< /note >}} + +Existem algumas restrições ao utilizar um volume `awsElasticBlockStore`: + +* Os nós nos quais os Pods estão sendo executados devem ser instâncias AWS EC2 +* Estas instâncias devem estar na mesma região e na mesma zona de disponibilidade que o volume EBS +* O EBS suporta montar um volume em apenas uma única instância EC2 + +#### Criando um volume AWS EBS + +Antes de poder utilizar um volume EBS com um pod, precisa criá-lo. + +```shell +aws ec2 create-volume --availability-zone=eu-west-1a --size=10 --volume-type=gp2 +``` + +Certifique-se de que a zona corresponde à mesma zona em que criou o cluster. Verifique se o tamanho e o tipo de volume EBS são adequados para a sua utilização. + +#### Exemplo de configuração do AWS EBS + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-ebs +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-ebs + name: test-volume + volumes: + - name: test-volume + # Esse volume AWS EBS já deve existir. + awsElasticBlockStore: + volumeID: "" + fsType: ext4 +``` + +Se o volume EBS estiver particionado, é possível informar o campo opcional `partition: ""` para especificar em que partição deve ser montado. + +#### Migração de CSI do AWS EBS + +{{< feature-state for_k8s_version="v1.17" state="beta" >}} + +Quando o recurso `CSIMigration` para `awsElasticBlockStore` está habilitado, todas as operações de plugin do tipo in-tree são redirecionadas para o driver Cointainer Storage Interface (CSI) `ebs.csi.aws.com`. Para usar esse recurso, o [driver CSI AWS EBS](https://github.com/kubernetes-sigs/aws-ebs-csi-driver) deve estar instalado no cluster e os recursos beta `CSIMigration` e `CSIMigrationAWS` devem estar ativados. + +#### Migração CSI AWS EBS concluída + +{{< feature-state for_k8s_version="v1.17" state="alpha" >}} + +Para desabilitar o carregamento do plugin de armazenamento `awsElasticBlockStore` pelo gerenciador de controladores e pelo kubelet, defina a flag `InTreePluginAWSUnregister` como `true`. + +### azureDisk {#azuredisk} + +O tipo de volume `azureDisk` monta um [Disco de Dados](https://docs.microsoft.com/en-us/azure/aks/csi-storage-drivers) Microsoft Azure em um pod. + +Para obter mais detalhes, consulte [plugin de volume `azureDisk`](https://github.com/kubernetes/examples/tree/master/staging/volumes/azure_disk/README.md). + +#### Migração de CSI do azureDisk + +{{< feature-state for_k8s_version="v1.19" state="beta" >}} + +Quando o recurso `CSIMigration` para `azureDisk` está habilitado, todas as operações de plugin do tipo in-tree são redirecionadas para o Driver de Cointêiner Storage Interface (CSI) `disk.csi.azure.com`. Para utilizar este recurso, o [Driver CSI Azure Disk](https://github.com/kubernetes-sigs/azuredisk-csi-driver) deve estar instalado no cluster e os recursos `CSIMigration` e `CSIMigrationAzureDisk` devem estar ativados. + +#### Migração CSI azureDisk concluída + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +Para desabilitar o carregamento do plugin de armazenamento `azureDisk` pelo gerenciador de controladores e pelo kubelet, defina a flag `InTreePluginAzureDiskUnregister` como `true`. + +### azureFile {#azurefile} + +O tipo de volume `azureFile` monta um volume de arquivo Microsoft Azure (SMB 2.1 e 3.0) em um pod. + +Para obter mais detalhes, consulte [plugin de volume `azureFile`](https://github.com/kubernetes/examples/tree/master/staging/volumes/azure_file/README.md). + +#### Migração de CSI azureFile + +{{< feature-state for_k8s_version="v1.21" state="beta" >}} + +Quando o recurso `CSIMigration` para `azureFile` está habilitado, todas as operações de plugin do tipo in-tree são redirecionadas para o Driver de Cointainer Storage Interface (CSI) `file.csi.azure.com`. Para utilizar este recurso, o [Driver CSI do Azure Disk](https://github.com/kubernetes-sigs/azurefile-csi-driver) deve estar instalado no cluster e as [feature gates](/docs/reference/command-line-tools-reference/feature-gates/) `CSIMigration` e `CSIMigrationAzureFile` devem estar habilitadas. + +O driver de CSI do Azure File não oferece suporte ao uso do mesmo volume por fsgroups diferentes, se a migração de CSI Azurefile estiver habilitada, o uso do mesmo volume por fsgroups diferentes não será suportado. + +#### Migração do CSI azureFile concluída + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +Para desabilitar o carregamento do plugin de armazenamento `azureFile` pelo gerenciador de controladores e pelo kubelet, defina a flag `InTreePluginAzureFileUnregister` como `true`. + +### cephfs + +Um volume `cephfs` permite que um volume CephFS existente seja montado no seu Pod. Ao contrário do `emptyDir` que é apagado quando um pod é removido, o conteúdo de um volume `cephfs` é preservado e o volume é simplesmente desmontado. Isto significa que um volume `cephfs` pode ser previamente populado com dados e que os dados podem ser compartilhados entre os Pods. O volume `cephfs` pode ser montado por vários gravadores simultaneamente. + +{{< note >}} Você deve ter seu próprio servidor Ceph funcionando com o compartilhamento acessível antes de poder utilizá-lo. {{< /note >}} + +Consulte o [ exemplo CephFS](https://github.com/kubernetes/examples/tree/master/volumes/cephfs/) para mais detalhes. + +### cinder + +{{< note >}} O Kubernetes deve ser configurado com o provedor de nuvem OpenStack. {{< /note >}} + +O tipo de volume `cinder` é utilizado para montar o volume do OpenStack Cinder no seu pod. + +#### Exemplo de configuração de volume Cinder + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-cinder +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-cinder-container + volumeMounts: + - mountPath: /test-cinder + name: test-volume + volumes: + - name: test-volume + # Esse volume OpenStack já deve existir. + cinder: + volumeID: "" + fsType: ext4 +``` + +#### Migração de CSI OpenStack + +{{< feature-state for_k8s_version="v1.21" state="beta" >}} + +O recurso `CSIMigration` para o Cinder é ativado por padrão no Kubernetes 1.21. Ele redireciona todas as operações de plugin do tipo in-tree para o Driver de Cointainer Storage Interface (CSI) `cinder.csi.openstack.org`. O [Driver CSI OpenStack Cinder](https://github.com/kubernetes/cloud-provider-openstack/blob/master/docs/cinder-csi-plugin/using-cinder-csi-plugin.md) tem de estar instalado no cluster. Você pode desativar a migração Cinder CSI para o seu cluster definindo a [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `CSIMigrationOpenStack` como `false`. Se você desativar o recurso `CSIMigrationOpenStack`, o plugin de volume in-tree do Cinder assume a responsabilidade por todos os aspectos do gerenciamento de armazenamento de volume do Cinder. + +### configMap + +Um [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) oferece uma forma de injetar dados de configuração em Pods. Os dados armazenados em um ConfigMap podem ser referenciados em um volume de tipo `configMap` e depois consumidos por aplicações conteinerizadas executadas em um pod. + +Ao referenciar um ConfigMap, você informa o nome do ConfigMap no volume. Pode personalizar o caminho utilizado para uma entrada específica no ConfigMap. A seguinte configuração mostra como montar o `log-config` do ConfigMap em um Pod chamado `configmap-pod`: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: configmap-pod +spec: + containers: + - name: test + image: busybox:1.28 + volumeMounts: + - name: config-vol + mountPath: /etc/config + volumes: + - name: config-vol + configMap: + name: log-config + items: + - key: log_level + path: log_level +``` + +O ConfigMap `log-config` é montado como um volume e todos os conteúdos armazenados em sua entrada `log_level` são montados no Pod através do caminho `/etc/config/log_level`. Observe que esse caminho é derivado do volume `mountPath`e do `path` configurado com `log_level`. + +{{< note >}} + +* É preciso criar um [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) antes de usá-lo. + +* Um contêiner que utiliza ConfigMap através de um ponto de montagem com a propriedade [`subPath`](#using-subpath) não receberá atualizações deste ConfigMap. + +* Os dados de texto são expostos como arquivos utilizando a codificação de caracteres UTF-8. Para outras codificações de caracteres, use `binaryData`. {{< /note >}} + +### downwardAPI {#downwardapi} + +Um volume `downwardAPI` disponibiliza dados da downward API para as aplicações. Ele monta um diretório e grava os dados solicitados em arquivos de texto sem formatação. + +{{< note >}} Um contêiner que utiliza downward API através de um ponto de montagem com a propriedade [`subPath`](#using-subpath) não receberá atualizações desta downward API. {{< /note >}} + +Consulte [o exemplo de downward API](/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) para obter mais detalhes. + +### emptyDir {#emptydir} + +Um volume `emptyDir` é criado pela primeira vez quando um Pod é atribuído a um nó e existe enquanto esse Pod estiver sendo executado nesse nó. Como o nome diz, o volume `emptyDir` está inicialmente vazio. Todos os contêineres no Pod podem ler e gravar os mesmos arquivos no volume `emptyDir`, embora esse volume possa ser montado no mesmo caminho ou em caminhos diferentes em cada contêiner. Quando um Pod é removido de um nó por qualquer motivo, os dados no `emptyDir` são eliminados permanentemente. + +{{< note >}} A falha de um contêiner *não* remove um Pod de um nó. Os dados em um volume `emptyDir` são mantidos em caso de falha do contêiner. {{< /note >}} + +Alguns usos para um `emptyDir` são: + +* espaço temporário, como para uma merge sort baseado em disco +* ponto de verificação de um processamento longo para recuperação de falhas +* manter arquivos que um contêiner gerenciador de conteúdo busca enquanto um contêiner de webserver entrega os dados + +Dependendo do seu ambiente, os volumes `emptyDir` são armazenados em qualquer mídia que componha o nó, como disco ou SSD, ou armazenamento de rede. No entanto, se você definir o campo `emptyDir.medium` como `"Memory"`, o Kubernetes monta um tmpfs (sistema de arquivos com suporte de RAM) para você. Embora o tmpfs seja muito rápido, tenha em atenção que, ao contrário dos discos, o tmpfs é limpo na reinicialização do nó e quaisquer arquivos que grave consomem o limite de memória do seu contêiner. + +{{< note >}} Se a [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `SizeMemoryBackedVolumes` estiver habilitada, é possível especificar um tamanho para volumes mantidos em memória. Se nenhum tamanho for especificado, os volumes mantidos em memória são dimensionados para 50% da memória em um host Linux. {{< /note>}} + +#### Exemplo de configuração emptyDir + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pd +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /cache + name: cache-volume + volumes: + - name: cache-volume + emptyDir: {} +``` + +### fc (fibre channel) {#fc} + +Um tipo de volume `fc` permite que um volume de armazenamento de fibre channel existente seja montado em um Pod. Você pode especificar um ou vários WWNs usando o parâmetro `targetWWNs` em sua configuração de volume. Se forem especificados vários WWNs, o targetWWNs espera que esses WWNs sejam de conexões multipath. + +{{< note >}} Para que os hosts Kubernetes possam acessá-los, é necessário configurar o zoneamento FC SAN para alocar e mascarar essas LUNs (volumes) para os WWNs de destino. {{< /note >}} + +Consulte [o exemplo de fibre channel](https://github.com/kubernetes/examples/tree/master/staging/volumes/fibre_channel) para obter mais detalhes. + +### flocker (descontinuado) {#flocker} + +[Flocker](https://github.com/ClusterHQ/flocker) é um gerenciador de volumes de dados de contêineres em cluster de código aberto. O Flocker oferece gerenciamento e orquestração de volumes de dados suportados por uma variedade de backends de armazenamento. + +Um volume `flocker` permite que um conjunto de dados Flocker seja montado em um Pod. Se o conjunto de dados ainda não existir no Flocker, ele precisará ser criado primeiro com o CLI do Flocker ou usando a API do Flocker. Se o conjunto de dados já existir, ele será anexado pelo Flocker ao nó que o pod está escalonado. Isto significa que os dados podem ser compartilhados entre os Pods, conforme necessário. + +{{< note >}} Antes de poder utilizá-lo, é necessário ter a sua própria instalação do Flocker em execução. {{< /note >}} + +Consulte [exemplo do Flocker](https://github.com/kubernetes/examples/tree/master/staging/volumes/flocker) para obter mais detalhes. + +### gcePersistentDisk + +Um volume `gcePersistentDisk` monta um [disco persistente](https://cloud.google.com/compute/docs/disks) (PD) do Google Compute Engine (GCE) no seu Pod. Ao contrário do `emptyDir` que é apagado quando um pod é removido, o conteúdo de um PD é preservado e o volume é simplesmente desmontado. Isto significa que um PD pode ser previamente populado com dados e que os dados podem ser compartilhados entre os Pods. + +{{< note >}} Você dever criar um PD utilizando `gcloud`, ou via GCE API ou via UI antes de poder utilizá-lo. {{< /note >}} + +Existem algumas restrições ao utilizar um `gcePersistentDisk`: + +* Os nós nos quais os Pods estão sendo executados devem ser VMs GCE +* Essas VMs precisam estar no mesmo projeto e zona GCE que o disco persistente + +Uma característica do disco persistente GCE é o acesso simultâneo somente leitura a um disco persistente. Um volume `gcePersistentDisk` permite que vários consumidores montem simultaneamente um disco persistente como somente leitura. Isto significa que é possível alimentar previamente um PD com o seu conjunto de dados e, em seguida, disponibilizá-lo em paralelo a quantos Pods necessitar. Infelizmente, os PDs só podem ser montados por um único consumidor no modo de leitura e escrita. Não são permitidos gravadores simultâneos. + +O uso de um disco persistente GCE com um Pod controlado por um ReplicaSet falhará, a menos que o PD seja somente leitura ou a contagem de réplica seja 0 ou 1. + +#### Criando um disco persistente GCE {#gce-create-persistent-disk} + +Antes de poder utilizar um disco persistente GCE com um Pod, é necessário criá-lo. + +```shell +gcloud compute disks create --size=500GB --zone=us-central1-a my-data-disk +``` + +#### Exemplo de configuração de disco persistente GCE + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pd +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-pd + name: test-volume + volumes: + - name: test-volume + # Esse Disco Persistente (PD) GCE já deve existir. + gcePersistentDisk: + pdName: my-data-disk + fsType: ext4 +``` + +#### Discos persistentes regionais + +O recurso de [Discos persistentes regionais](https://cloud.google.com/compute/docs/disks/#repds) permite a criação de discos persistentes que estão disponíveis em duas zonas dentro da mesma região. Para usar esse recurso, o volume deve ser provisionado como PersistentVolume; referenciar o volume diretamente a partir de um pod não é uma configuração suportada. + +#### Provisionar manualmente um PersistentVolume PD Regional + +O provisionamento dinâmico é possível usando [uma StorageClass para GCE PD](/docs/concepts/storage/storage-classes/#gce). Antes de criar um PersistentVolume, você deve criar o disco persistente: + +```shell +gcloud compute disks create --size=500GB my-data-disk + --region us-central1 + --replica-zones us-central1-a,us-central1-b +``` + +#### Exemplo de configuração de disco persistente regional + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: test-volume +spec: + capacity: + storage: 400Gi + accessModes: + - ReadWriteOnce + gcePersistentDisk: + pdName: my-data-disk + fsType: ext4 + nodeAffinity: + required: + nodeSelectorTerms: + - matchExpressions: + # failure-domain.beta.kubernetes.io/zone deve ser usado para versões anteriores à 1.21 + - key: topology.kubernetes.io/zone + operator: In + values: + - us-central1-a + - us-central1-b +``` + +#### Migração do CSI GCE + +{{< feature-state for_k8s_version="v1.17" state="beta" >}} + +Quando o recurso `CSIMigration` para o GCE PD é habilitado, todas as operações de plugin do plugin in-tree existente são redirecionadas para o Driver de Cointainer Storage Interface (CSI) `pd.csi.storage.gke.io`. Para utilizar este recurso, o [Driver CSI GCE PD](https://github.com/kubernetes-sigs/gcp-compute-persistent-disk-csi-driver) deve ser instalado no cluster e os recursos beta `CSIMigration` e `CSIMigrationGCE` devem estar habilitados. + +#### Migração de CSI GCE concluída + +{{< feature-state for_k8s_version="v1.21" state="alpha" >}} + +Para desabilitar o carregamento do plugin de armazenamento `gcePersistentDisk` pelo gerenciador de controladores e pelo kubelet, defina a flag `InTreePluginGCEUnregister` como `true`. + +### gitRepo (descontinuado) {#gitrepo} + +{{< warning >}}O tipo de volume `gitRepo` foi descontinuado. Para provisionar um contêiner com um repositório git , monte um [EmptyDir](#emptydir) em um InitContainer que clone o repositório usando git, depois monte [o EmptyDir](#emptydir) no contêiner do Pod. {{< /warning >}} + +Um volume `gitRepo` é um exemplo de um plugin de volume. Este plugin monta um diretório vazio e clona um repositório git neste diretório para que seu Pod utilize. + +Aqui está um exemplo de um volume `gitRepo`: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: server +spec: + containers: + - image: nginx + name: nginx + volumeMounts: + - mountPath: /mypath + name: git-volume + volumes: + - name: git-volume + gitRepo: + repository: "git@somewhere:me/my-git-repository.git" + revision: "22f1d8406d464b0c0874075539c1f2e96c253775" +``` + +### glusterfs + +Um volume `glusterfs` permite que um volume [Glusterfs](https://www.gluster.org) (um sistema de arquivos em rede de código aberto) seja montado no seu Pod. Ao contrário do `emptyDir` que é apagado quando um Pod é removido, o conteúdo de um volume `glusterfs` é preservado e o volume é simplesmente desmontado. Isto significa que um volume glusterfs pode ser previamente populado com dados e que os dados podem ser compartilhados entre Pods. O GlusterFS pode ser montado para escrita por vários pods simultaneamente. + +{{< note >}} Para poder utilizá-lo, é necessário ter a sua própria instalação do GlusterFS em execução. {{< /note >}} + +Consulte o [exemplo do GlusterFS](https://github.com/kubernetes/examples/tree/master/volumes/glusterfs) para obter mais detalhes. + +### hostPath {#hostpath} + +{{< warning >}} Os volumes HostPath apresentam muitos riscos de segurança e é uma prática recomendada evitar o uso de HostPaths quando possível. Quando um volume HostPath precisa ser usado, ele deve ser definido com escopo apenas para o arquivo ou diretório necessário e montado como ReadOnly. + +Se você restringir o acesso do HostPath a diretórios específicos através da AdmissionPolicy, a propriedade `volumeMounts` DEVE obrigatoriamente usar pontos de montagem `readOnly` para que a política seja eficaz. {{< /warning >}} + +Um volume `hostPath` monta um arquivo ou diretório do sistema de arquivos do nó do host em seu Pod. Isto não é algo de que a maioria dos Pods irá precisar, mas oferece uma poderosa alternativa de escape para algumas aplicações. + +Por exemplo, alguns usos para um `hostPath` são: + +* Executar um contêiner que necessita de acesso aos documentos internos do Docker; utilizar um `hostPath` apontando para `/var/lib/docker` +* Executando o cAdvisor em um contêiner; use um `hostPath` apontando para `/sys` +* Permitir que um Pod especifique se um dado `hostPath` deve existir antes de o Pod ser executado, se deve ser criado e como deve existir + +Além da propriedade obrigatória `path` , você pode opcionalmente definir um `type` para um volume `hostPath`. + +Os valores suportados para o campo `type` são: + +| Valor| Comportamento| +|:----------|:----------| +| | A string vazia (padrão) é para compatibilidade com versões anteriores, o que significa que nenhuma verificação será executada antes de montar o volume hostPath.| +| `DirectoryOrCreate`| Se nada existir no caminho indicado, um diretório vazio será criado lá, conforme necessário, com permissão definida para 0755, tendo o mesmo grupo e propriedade com a Kubelet.| +| `Directory`| Um diretório deve existir no caminho indicado| +| `FileOrCreate`| Se não houver nada no caminho indicado, um arquivo vazio será criado lá, conforme necessário, com permissão definida para 0644, tendo o mesmo grupo e propriedade com Kubelet.| +| `File`| Um arquivo deve existir no caminho indicado| +| `Socket`| Um socket UNIX deve existir no caminho indicado| +| `CharDevice`| Deve existir um dispositivo de caracteres no caminho indicado| +| `BlockDevice`| Deve existir um dispositivo de bloco no caminho indicado| + +Tenha cuidado ao utilizar este tipo de volume, porque: + +* Os HostPaths podem expor as credenciais privilegiadas do sistema (como para o Kubelet) ou APIs privilegiadas (como o container runtime socket), que podem ser usadas para o explorar vulnerabilidades de escape do contêiner ou para atacar outras partes do cluster. +* Os Pods com configuração idêntica (como criado a partir de um PodTemplate) podem se comportar de forma diferente em nós diferentes devido a arquivos diferentes nos nós +* Os arquivos ou diretórios criados nos hosts subjacentes são graváveis apenas pelo root. Você precisa executar seu processo como root em um [contêiner privilegiado](/docs/tasks/configure-pod-container/security-context/) ou modificar as permissões de arquivo no host para poder gravar em um volume `hostPath` + +#### Exemplo de configuração do hostPath + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-pd +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /test-pd + name: test-volume + volumes: + - name: test-volume + hostPath: + # localização do diretório no host + path: /data + # este campo é opcional + type: Directory +``` + +{{< caution >}} O modo `FileOrCreate` não cria o diretório onde ficará arquivo. Se o caminho de diretório do arquivo montado não existir, o pod não será iniciado. Para garantir que esse modo funcione, você pode tentar montar diretórios e arquivos separadamente, como mostrado em [configuração `FileOrCreate`](#hostpath-fileorcreate-example). {{< /caution >}} + +#### Exemplo de configuração FileOrCreate do hostPath {#hostpath-fileorcreate-example} + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-webserver +spec: + containers: + - name: test-webserver + image: k8s.gcr.io/test-webserver:latest + volumeMounts: + - mountPath: /var/local/aaa + name: mydir + - mountPath: /var/local/aaa/1.txt + name: myfile + volumes: + - name: mydir + hostPath: + # Certifique-se de que o diretório foi criado. + path: /var/local/aaa + type: DirectoryOrCreate + - name: myfile + hostPath: + path: /var/local/aaa/1.txt + type: FileOrCreate +``` + +### iscsi + +Um volume `iscsi` permite que um volume iSCSI (SCSI sobre IP) existente seja montado no seu Pod. Ao contrário do `emptyDir` que é apagado quando um Pod é removido, o conteúdo de um volume `iscsi` é preservado e o volume é simplesmente desmontado. Isto significa que um volume iscsi pode ser previamente populado com dados e que os dados podem ser compartilhados entre os Pods. + +{{< note >}} Você deve ter seu próprio servidor iSCSI rodando com o volume criado antes de poder utilizá-lo. {{< /note >}} + +Uma característica do iSCSI é que ele pode ser montado como somente leitura por vários consumidores simultaneamente. Isto significa que um volume pode ser previamente populado com seu conjunto de dados e, em seguida, ser disponibilizado em paralelo para tantos Pods quanto necessitar. Infelizmente, os volumes iSCSI só podem ser montados por um único consumidor no modo de leitura-escrita. Não são permitidos gravadores simultâneos. + +Consulte o [exemplo iSCSI](https://github.com/kubernetes/examples/tree/master/volumes/iscsi) para obter mais detalhes. + +### local + +Um volume `local` representa um dispositivo de armazenamento local montado, como um disco, partição ou diretório. + +Os volumes locais só podem ser usados como um PersistentVolume criado estaticamente. O provisionamento dinâmico não é suportado. + +Em comparação com volumes `hostPath`, os volumes `local` são usados de forma durável e portátil, sem escalonamento manual dos Pods para os nós. O sistema está ciente das restrições de nós do volume, observando a afinidade do nó com o PersistentVolume. + +No entanto, os volumes `local` estão sujeitos à disponibilidade do nó que o comporta e não são adequados para todas as aplicações. Se um nó não está íntegro, então o volume `local` torna-se inacessível pelo pod. O pod que utiliza este volume não consegue ser executado. Os aplicativos que usam volumes `local` devem ser capazes de tolerar essa disponibilidade reduzida, bem como uma possível perda de dados, dependendo das caraterísticas de durabilidade do disco subjacente. + +O exemplo a seguir mostra um PersistentVolume usando um volume `local` e `nodeAffinity`: + +```yaml +apiVersion: v1 +kind: PersistentVolume +metadata: + name: example-pv +spec: + capacity: + storage: 100Gi + volumeMode: Filesystem + accessModes: + - ReadWriteOnce + persistentVolumeReclaimPolicy: Delete + storageClassName: local-storage + local: + path: /mnt/disks/ssd1 + nodeAffinity: + required: + nodeSelectorTerms: + - matchExpressions: + - key: kubernetes.io/hostname + operator: In + values: + - example-node +``` + +É preciso definir a propriedade `nodeAffinity` do PersistentVolume ao utilizar volumes `local`. O escalonador do Kubernetes usa o PersistentVolume `nodeAffinity` para escalonar esses pods para o nó correto. + +A propriedade `volumeMode` do PersistentVolume pode ser definida como "Block" (ao invés do valor padrão "Filesystem") para expor o volume local como um dispositivo de bloco bruto. + +Ao usar volumes locais, é recomendável criar uma StorageClass com a propriedade `volumeBindingMode` definida como `WaitForFirstConsumer`. Para obter mais detalhes, consulte o exemplo local [StorageClass](/docs/concepts/storage/storage-classes/#local). A postergação da vinculação do volume garante que a decisão de vinculação da PersistentVolumeClaim também será avaliada com quaisquer outras restrições de nós que o Pod possa ter, tais como requisitos de recursos de nós, seletores de nós, afinidade do Pod e anti afinidade do Pod. + +Um provisionador estático externo pode ser executado separadamente para uma melhor gestão do ciclo de vida do volume local. Observe que este provisionador ainda não suporta o provisionamento dinâmico. Para um exemplo sobre como executar um provisionador local externo, veja o [manual do usuário do provisionador local do volume](https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner). + +{{< note >}} O PersistentVolume local exige que o usuário faça limpeza e remoção manual se o provisionador estático externo não for utilizado para gerenciar o ciclo de vida do volume. {{< /note >}} + +### nfs + +Um volume `nfs` permite que um compartilhamento NFS (Network File System) existente seja montado em um Pod. Ao contrário do `emptyDir` que é apagado quando um Pod é removido, o conteúdo de um volume `nfs` é preservado e o volume é simplesmente desmontado. Isto significa que um volume NFS pode ser previamente populado com dados e que os dados podem ser compartilhados entre os Pods. O NFS pode ser montado por vários gravadores simultaneamente. + +{{< note >}} Você deve ter seu próprio servidor NFS rodando com o compartilhamento acessível antes de poder utilizá-lo. {{< /note >}} + +Consulte o [exemplo NFS](https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs) para obter mais detalhes. + +### persistentVolumeClaim {#persistentvolumeclaim} + +Um volume `persistentVolumeClaim` é usado para montar um [PersistentVolume](/pt-br/docs/concepts/storage/persistent-volumes/) em um Pod. PersistentVolumeClaims são uma forma de os usuários "solicitarem" armazenamento durável (como um GCE PersistentDisk ou um volume iSCSI) sem conhecerem os detalhes do ambiente de nuvem em particular. + +Consulte as informações sobre [PersistentVolumes](/pt-br/docs/concepts/storage/persistent-volumes/) para obter mais detalhes. + +### portworxVolume {#portworxvolume} + +Um `portworxVolume` é uma camada de armazenamento em bloco extensível que funciona hiperconvergente com Kubernetes. O [Portworx](https://portworx.com/use-case/kubernetes-storage/) tira as impressões digitais de um armazenamento em um servidor, organiza com base nas capacidades e agrega capacidade em múltiplos servidores. Portworx funciona em máquinas virtuais ou em nós Linux bare-metal. + +Um `portworxVolume` pode ser criado dinamicamente através do Kubernetes ou também pode ser previamente provisionado e referenciado dentro de um Pod. Aqui está um exemplo de um Pod referenciando um volume Portworx pré-provisionado: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: test-portworx-volume-pod +spec: + containers: + - image: k8s.gcr.io/test-webserver + name: test-container + volumeMounts: + - mountPath: /mnt + name: pxvol + volumes: + - name: pxvol + # Este volume Portworx já deve existir. + portworxVolume: + volumeID: "pxvol" + fsType: "" +``` + +{{< note >}} Certifique-se de ter um PortworxVolume com o nome `pxvol` antes de usá-lo no Pod. {{< /note >}} + +Para obter mais detalhes, consulte os exemplos de [volume Portworx](https://github.com/kubernetes/examples/tree/master/staging/volumes/portworx/README.md) . + +### projetado + +Um volume projetado mapeia várias fontes de volume existentes dentro do mesmo diretório. Para obter mais detalhes, consulte [Volumes projetados](/docs/concepts/storage/projected-volumes/). + +### quobyte (descontinuado) {#quobyte} + +Um Volume `quobyte` permite que um volume [Quobyte](https://www.quobyte.com) existente seja montado no seu Pod. + +{{< note >}} Você deve ter seu próprio Quobyte configurado e funcionando com os volumes criados antes de poder utilizá-lo. {{< /note >}} + +Quobyte oferece suporte para o {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}}. CSI é o plugin recomendado para usar volumes Quobyte dentro de Kubernetes. O projeto GitHub da Quobyte tem [instruções](https://github.com/quobyte/quobyte-csi#quobyte-csi) para implantar o Quobyte usando o CSI, acompanhado de exemplos. + +### rbd + +Um volume `rbd` permite que um volume [Rados Block Device](https://docs.ceph.com/en/latest/rbd/) (RBD) seja montado em seu Pod. Ao contrário do `emptyDir` que é apagado quando um pod é removido, o conteúdo de um volume `rbd` é preservado e o volume é desmontado. Isto significa que um volume RBD pode ser previamente populado com dados e que os dados podem ser compartilhados entre os Pods. + +{{< note >}} Você deve ter uma instalação Ceph em funcionamento antes de poder usar o RBD. {{< /note >}} + +Uma caraterística do RBD é que ele pode ser montado como somente leitura por vários consumidores simultaneamente. Isto significa que um volume pode ser previamente populado com seu conjunto de dados e, em seguida, ser disponibilizado em paralelo para tantos pods quanto necessitar. Infelizmente, os volumes RBD só podem ser montados por um único consumidor no modo de leitura-escrita. Não são permitidos gravadores simultâneos. + +Consulte o [exemplo RBD](https://github.com/kubernetes/examples/tree/master/volumes/rbd) para obter mais detalhes. + +#### Migração de CSI RBD {#rbd-csi-migration} + +{{< feature-state for_k8s_version="v1.23" state="alpha" >}} + +Quando o recurso `CSIMigration` do `RBD` está ativado, redireciona todas as operações do plugin in-tree existente para o driver {{< glossary_tooltip text="CSI" term_id="csi" >}} `rbd.csi.ceph.com`. Para utilizar este recurso, o [driver Ceph CSI](https://github.com/ceph/ceph-csi) deve estar instalado no cluster e as [feature gates](/docs/reference/command-line-tools-reference/feature-gates/) `CSIMigration` e `csiMigrationRBD` devem estar habilitadas. + +{{< note >}} + +Como operador do cluster Kubernetes que administra o armazenamento, aqui estão os pré-requisitos que você deve atender antes de tentar a migração para o driver CSI RBD: + +* Você deve instalar o driver Ceph CSI (`rbd.csi.ceph.com`), v3.5.0 ou superior, no cluster Kubernetes. +* Considerando que o campo `clusterID` é um parâmetro necessário para o driver CSI e sua operação , mas o campo in-tree StorageClass tem o parâmetro obrigatório `monitors`, um administrador de armazenamento Kubernetes precisa criar um clusterID baseado no hash dos monitores (ex.:`#echo -n '' | md5sum`) no mapa de configuração do CSI e manter os monitores sob esta configuração de clusterID. +* Além disso, se o valor de `adminId` no Storageclass in-tree for diferente de `admin`, o `adminSecretName` mencionado no Storageclass in-tree tem que ser corrigido com o valor base64 do valor do parâmetro `adminId`, caso contrário esta etapa pode ser ignorada. {{< /note >}} + +### secret + +Um volume `secret` é usado para passar informações sensíveis, tais como senhas, para Pods. Você pode armazenar segredos na API Kubernetes e montá-los como arquivos para serem usados por pods sem necessidade de vinculação direta ao Kubernetes. Volumes `secret` são mantidos pelo tmpfs (um sistema de arquivos com baseado em memória RAM) para que nunca sejam gravados em armazenamento não volátil. + +{{< note >}}Você deve criar um Secret na API Kubernetes antes de poder utilizá-lo. {{< /note >}} + +{{< note >}} Um contêiner que utiliza um Secret como ponto de montagem para a propriedade [`subPath`](#using-subpath) não receberá atualizações deste Secret. {{< /note >}} + +Para obter mais detalhes, consulte [Configurando Secrets](/pt-br/docs/concepts/configuration/secret/). + +### storageOS (descontinuado) {#storageos} + +Um volume `storageos` permite que um volume [StorageOS](https://www.storageos.com) existente seja montado em seu Pod. + +O StorageOS funciona como um contêiner dentro de seu ambiente Kubernetes, tornando o armazenamento local ou anexado acessível a partir de qualquer nó dentro do cluster Kubernetes. Os dados podem ser replicados para a proteção contra falhas do nó. O provisionamento e a compressão podem melhorar a utilização e reduzir os custos. + +Em sua essência, o StorageOS fornece armazenamento em bloco para containers, acessível a partir de um sistema de arquivo. + +O Conteiner StorageOS requer Linux de 64 bits e não possui dependências adicionais. Uma licença para desenvolvedores está disponível gratuitamente. + +{{< caution >}} Você deve executar o container StorageOS em cada nó que deseja acessar os volumes do StorageOS ou que contribuirá com a capacidade de armazenamento para o pool. Para obter instruções de instalação, consulte a [documentação do StorageOS](https://docs.storageos.com). {{< /caution >}} + +O exemplo a seguir é uma configuração do Pod com StorageOS: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + labels: + name: redis + role: master + name: test-storageos-redis +spec: + containers: + - name: master + image: kubernetes/redis:v1 + env: + - name: MASTER + value: "true" + ports: + - containerPort: 6379 + volumeMounts: + - mountPath: /redis-master-data + name: redis-data + volumes: + - name: redis-data + storageos: + # O volume `redis-vol01` já deve existir dentro do StorageOS no namespace `default`. + volumeName: redis-vol01 + fsType: ext4 +``` + +Para obter mais informações sobre StorageOS, provisionamento dinâmico e PersistentVolumeClaims, consulte os [exemplos do StorageOS](https://github.com/kubernetes/examples/blob/master/volumes/storageos). + +### vsphereVolume {#vspherevolume} + +{{< note >}} Você deve configurar o Kubernetes vSphere Cloud Provider. Para obter informações sobre a configuração do cloudprovider, consulte o [Guia Introdutório do vSphere](https://vmware.github.io/vsphere-storage-for-kubernetes/documentation/). {{< /note >}} + +Um `vsphereVolume` é usado para montar um volume VMDK do vSphere em seu Pod. O conteúdo de um volume é preservado quando é desmontado. Ele suporta sistemas de armazenamento de dados tanto do tipo VMFS quanto do tipo VSAN. + +{{< note >}} Você deve criar o volume do VMDK vSphere usando um dos métodos a seguir antes de usar com um Pod. {{< /note >}} + +#### Criar um volume VMDK {#creating-vmdk-volume} + +Escolha um dos seguintes métodos para criar um VMDK. + +{{< tabs name="tabs_volumes" >}} +{{% tab name="Criar usando vmkfstools" %}} +Primeiro acesse o ESX via ssh, depois use o seguinte comando para criar um VMDK: + +```shell +vmkfstools -c 2G /vmfs/volumes/DatastoreName/volumes/myDisk.vmdk +``` + +{{% /tab %}} +{{% tab name="Criar usando vmware-vdiskmanager" %}} +Utilize o seguinte comando para criar um VMDK: + +```shell +vmware-vdiskmanager -c -t 0 -s 40GB -a lsilogic myDisk.vmdk +``` + +{{% /tab %}} + +{{< /tabs >}} + +#### Exemplo de configuração do VMDK no vSphere {#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 + # This VMDK volume must already exist. + vsphereVolume: + volumePath: "[DatastoreName] volumes/myDisk" + fsType: ext4 +``` + +Para obter mais informações, consulte os exemplos de [volume do vSphere](https://github.com/kubernetes/examples/tree/master/staging/volumes/vsphere) . + +#### Migração de CSI vSphere {#vsphere-csi-migration} + +{{< feature-state for_k8s_version="v1.19" state="beta" >}} + +Quando o recurso `CSIMigration` do `vsphereVolume` está ativado, redireciona todas as operações do plugin in-tree existente para o driver {{< glossary_tooltip text="CSI" term_id="csi" >}} `csi.vsphere.vmware.com`. Para usar esse recurso, o [driver CSI do vSphere](https://github.com/kubernetes-sigs/vsphere-csi-driver) deve estar instalado no cluster e as [feature gates](/docs/reference/command-line-tools-reference/feature-gates/) `CSIMigration` e `CSIMigrationvSphere` devem estar habilitadas. + +Isso também requer que a versão mínima do vSphere vCenter/ESXi seja 7.0u1 e a versão mínima do hardware seja a VM versão 15. + +{{< note >}} Os seguintes parâmetros da StorageClass do plugin integrado `vsphereVolume` não são suportados pelo driver CSI do vSphere: + +* `diskformat` +* `hostfailurestotolerate` +* `forceprovisioning` +* `cachereservation` +* `diskstripes` +* `objectspacereservation` +* `iopslimit` + +Os volumes existentes criados usando esses parâmetros serão migrados para o driver CSI do vSphere, mas novos volumes criados pelo driver de CSI do vSphere não estarão respeitando esses parâmetros. {{< /note >}} + +#### Migração do CSI do vSphere foi concluída {#vsphere-csi-migration-complete} + +{{< feature-state for_k8s_version="v1.19" state="beta" >}} + +Para desativar o carregamento do plugin de armazenamento `vsphereVolume` pelo gerenciador de controladores e pelo kubelet, defina a flag `InTreePluginvSphereUnregister` como `true`. Você precisa instalar o driver `csi.vsphere.vmware.com` {{< glossary_tooltip text="CSI" term_id="csi" >}} em todos os nós de processamento. + +#### Migração de driver CSI do Portworx + +{{< feature-state for_k8s_version="v1.23" state="alpha" >}} + +O recurso `CSIMigration` para Portworx foi adicionado, mas desativado por padrão no Kubernetes 1.23 visto que está no estado alfa. Ele redireciona todas as operações de plugin do tipo in-tree para o Driver de Cointainer Storage Interface (CSI) `pxd.portworx.com`. [O driver CSI Portworx](https://docs.portworx.com/portworx-install-with-kubernetes/storage-operations/csi/) deve ser instalado no cluster. Para ativar o recurso, defina `CSIMigrationPortworx=true` no kube-controller-manager e no kubelet. + +## Utilizando subPath {#using-subpath} + +Às vezes, é útil compartilhar um volume para múltiplos usos em um único pod. A propriedade `volumeMounts.subPath` especifica um sub caminho dentro do volume referenciado em vez de sua raiz. + +O exemplo a seguir mostra como configurar um Pod com um ambiente LAMP (Linux, Apache, MySQL e PHP) usando um único volume compartilhado. Esta exemplo de configuração `subPath` não é recomendada para uso em produção. + +O código e os ativos da aplicação PHP mapeiam para a pasta do volume `html` e o banco de dados MySQL é armazenado na pasta do volume `mysql` . Por exemplo: + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: my-lamp-site +spec: + containers: + - name: mysql + image: mysql + env: + - name: MYSQL_ROOT_PASSWORD + value: "rootpasswd" + volumeMounts: + - mountPath: /var/lib/mysql + name: site-data + subPath: mysql + - name: php + image: php:7.0-apache + volumeMounts: + - mountPath: /var/www/html + name: site-data + subPath: html + volumes: + - name: site-data + persistentVolumeClaim: + claimName: my-lamp-site-data +``` + +### Usando subPath com variáveis de ambiente expandidas {#using-subpath-expanded-environment} + +{{< feature-state for_k8s_version="v1.17" state="stable" >}} + +Use o campo `subPathExpr` para construir nomes de diretório `subPath` a partir de variáveis de ambiente da downward API. As propriedades `subPath` e `subPathExpr` são mutuamente exclusivas. + +Neste exemplo, um `Pod` usa `subPathExpr` para criar um diretório `pod1` dentro do volume `hostPath` `/var/log/pods`. O volume `hostPath`recebe o nome `Pod` do `downwardAPI`. O diretório `/var/log/pods/pod1` do host é montado em `/logs` no contêiner. + +```yaml +apiVersion: v1 +kind: Pod +metadata: + name: pod1 +spec: + containers: + - name: container1 + env: + - name: POD_NAME + valueFrom: + fieldRef: + apiVersion: v1 + fieldPath: metadata.name + image: busybox:1.28 + command: [ "sh", "-c", "while [ true ]; do echo 'Hello'; sleep 10; done | tee -a /logs/hello.txt" ] + volumeMounts: + - name: workdir1 + mountPath: /logs + # A expansão de variáveis usa parênteses (não chaves). + subPathExpr: $(POD_NAME) + restartPolicy: Never + volumes: + - name: workdir1 + hostPath: + path: /var/log/pods +``` + +## Recursos + +A mídia de armazenamento(como Disco ou SSD) de um volume `emptyDir` é determinada por meio do sistema de arquivos que mantém o diretório raiz do kubelet (normalmente `/var/lib/kubelet`). Não há limite para quanto espaço um volume `emptyDir` ou `hostPath` podem consumir, e não há isolamento entre contêineres ou entre pods. + +Para saber mais sobre como solicitar espaço usando uma especificação de recursos, consulte [como gerenciar recursos](/pt-br/docs/concepts/configuration/manage-resources-containers/). + +## Plugins de volume out-of-tree + +Os plugins de volume out-of-tree incluem o {{< glossary_tooltip text="Container Storage Interface" term_id="csi" >}} (CSI) e também o FlexVolume (que foi descontinuado). Esses plugins permitem que os fornecedores de armazenamento criem plugins de armazenamento personalizados sem adicionar seu código-fonte do plugin ao repositório Kubernetes. + +Anteriormente, todos os plugins de volume eram "in-tree". Os plugins "in-tree" eram construídos, vinculados, compilados e distribuídos com o código principal dos binários do Kubernetes. Isto significava que a adição de um novo sistema de armazenamento ao Kubernetes (um plugin de volume) exigia uma validação do código no repositório central de código Kubernetes. + +Tanto o CSI quanto o FlexVolume permitem que os plugins de volume sejam desenvolvidos independentemente da base de código Kubernetes e implantados (instalados) nos clusters Kubernetes como extensões. + +Para fornecedores de armazenamento que procuram criar um plugin de volume out-of-tree, consulte as [Perguntas mais frequentes sobre plugins de volume](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md). + +### csi + +O [Cointainer Storage Interface](https://github.com/container-storage-interface/spec/blob/master/spec.md) (CSI) define uma interface padrão para sistemas de orquestração de contêineres (como Kubernetes) para expor sistemas de armazenamento arbitrários a suas cargas de trabalho de contêiner. + +Leia a [proposta de design CSI](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/storage/container-storage-interface.md) para obter mais informações. + +{{< note >}} O suporte para as versões 0.2 e 0.3 da especificação CSI foi descontinuado no Kubernetes v1.13 e será removido em uma versão futura. {{< /note >}} + +{{< note >}} Os controladores CSI podem não ser compatíveis em todas as versões do Kubernetes. Consulte a documentação específica do driver CSI para ver as etapas de implantação suportadas para cada versão do Kubernetes e uma matriz de compatibilidade. {{< /note >}} + +Uma vez que um driver de volume compatível com CSI seja implantado em um cluster Kubernetes, os usuários podem usar o tipo de volume `csi` para anexar ou montar os volumes expostos pelo driver CSI. + +Um volume `csi` pode ser utilizado em um Pod de três formas diferentes: + +* Através de uma referência a [PersistentVolumeClaim](#persistentvolumeclaim) +* com um [volume efêmero genérico](/docs/concepts/storage/ephemeral-volumes/#generic-ephemeral-volume) (recurso alfa) +* com [volume efêmero de CSI](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume) se o driver suportar esse (recurso beta) + +Os seguintes campos estão disponíveis para administradores de armazenamento configurarem um volume persistente de CSI: + +* `driver`: Um valor do tipo string que especifica o nome do driver de volume a ser usado. Este valor deve corresponder ao valor retornado no `GetPluginInfoResponse` pelo driver CSI, conforme definido na [especificação CSI](https://github.com/container-storage-interface/spec/blob/master/spec.md#getplugininfo). Ele é usado pelo Kubernetes para identificar qual driver CSI chamar, e pelos componentes do driver CSI para identificar quais objetos PV pertencem ao driver CSI. +* `volumeHandle`: Um valor do tipo string que identifica exclusivamente o volume. Este valor deve corresponder ao valor retornado no campo `volume.id` em `CreateVolumeResponse` pelo driver CSI, conforme definido na [especificação CSI](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume). O valor é passado como `volume_id` em todas as chamadas para o driver de volume CSI quando se faz referência ao volume. +* `readOnly`: Um valor booleano opcional que indica se o volume deve ser "ControllerPublished" (anexado) como somente leitura. O valor padrão é false. Este valor é passado para o driver CSI através do campo `readonly` em `ControllerPublishVolumeRequest`. +* `fsType`: Se o `VolumeMode` do PV for `Filesystem` então este campo pode ser usado para especificar o sistema de arquivos que deve ser usado para montar o volume. Se o volume não tiver sido formatado e a formatação for suportada, este valor será utilizado para formatar o volume. Este valor é passado para o driver CSI através do campo `VolumeCapability` nas propriedades `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest` e `NodePublishVolumeRequest`. +* `volumeAttributes`: Um mapa de valores do tipo string para string que especifica propriedades estáticas de um volume. Este mapa deve corresponder ao mapa retornado no campo `volume.attributes` do `CreateVolumeResponse` pelo driver CSI, conforme definido na [especificação CSI](https://github.com/container-storage-interface/spec/blob/master/spec.md#createvolume). O mapa é passado para o driver CSI através do campo `volume_context` nas propriedades `ControllerPublishVolumeRequest`, `NodeStageVolumeRequest`, e `NodePublishVolumeRequest`. +* `controllerPublishSecretRef`: Uma referência ao objeto Secret que contém informações confidenciais para passar ao driver CSI para completar as chamadas CSI `ControllerPublishVolume` e `ControllerUnpublishVolume`. Este campo é opcional e pode estar vazio se não for necessário nenhum segredo. Se o Secret contiver mais de um segredo, todos os segredos serão passados. +* `nodeStageSecretRef`: Uma referência ao objeto Secret que contém informações confidenciais para passar ao driver de CSI para completar a chamada de CSI do `NodeStageVolume`. Este campo é opcional e pode estar vazio se não for necessário nenhum segredo. Se o Secret contiver mais de um segredo, todos os segredos serão passados. +* `nodePublishSecretRef`: Uma referência ao objeto Secret que contém informações confidenciais para passar ao driver de CSI para completar a chamada de CSI do `NodePublishVolume`. Este campo é opcional e pode estar vazio se não for necessário nenhum segredo. Se o objeto Secret contiver mais de um segredo, todos os segredos serão passados. + +#### Suporte CSI para volume de bloco bruto + +{{< feature-state for_k8s_version="v1.18" state="stable" >}} + +Os fornecedores com drivers CSI externos podem implementar o suporte de volume de blocos brutos nas cargas de trabalho Kubernetes. + +Você pode configurar o [PersistentVolume/PersistentVolumeClaim com suporte de volume de bloco bruto](/pt-br/docs/concepts/storage/persistent-volumes/#suporte-a-volume-de-bloco-bruto) , como habitualmente, sem quaisquer alterações específicas de CSI. + +#### Volumes efêmeros de CSI + +{{< feature-state for_k8s_version="v1.16" state="beta" >}} + +É possível configurar diretamente volumes CSI dentro da especificação do Pod. Os volumes especificados desta forma são efêmeros e não persistem nas reinicializações do pod. Consulte [Volumes efêmeros](/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume) para obter mais informações. + +Para obter mais informações sobre como desenvolver um driver CSI, consulte a [documentação kubernetes-csi](https://kubernetes-csi.github.io/docs/) + +#### Migrando para drivers CSI a partir de plugins in-tree + +{{< feature-state for_k8s_version="v1.17" state="beta" >}} + +Quando o recurso `CSIMigration` está habilitado, direciona operações relacionadas a plugins in-tree existentes para plugins CSI correspondentes (que devem ser instalados e configurados). Como resultado, os operadores não precisam fazer nenhuma alteração de configuração para Storage Classes, PersistentVolumes ou PersistentVolumeClaims existentes (referindo-se aos plugins in-tree) quando a transição para um driver CSI que substitui um plugin in-tree. + +As operações e características que são suportadas incluem: provisionamento/exclusão, anexação/remoção, montargem/desmontagem e redimensionamento de volumes. + +Plugins in-tree que suportam `CSIMigration` e têm um driver CSI correspondente implementado são listados [em tipos de volumes](#volume-types). + +### flexVolume + +{{< feature-state for_k8s_version="v1.23" state="deprecated" >}} + +O FlexVolume é uma interface de plugin out-of-tree que usa um modelo baseado em execução para fazer interface com drivers de armazenamento. Os binários do driver FlexVolume devem ser instalados em um caminho de plugin de volume predefinido em cada nó e, em alguns casos, também nos nós da camada de gerenciamento. + +Os Pods interagem com os drivers do FlexVolume através do plugin de volume in-tree `flexVolume`. Para obter mais detalhes, consulte o documento [README](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md#readme) do FlexVolume. + +{{< note >}} O FlexVolume foi descontinuado. Usar um driver CSI out-of-tree é a maneira recomendada de integrar o armazenamento externo com Kubernetes. + +Os mantenedores do driver FlexVolume devem implementar um driver CSI e ajudar a migrar usuários de drivers FlexVolume para CSI. Os usuários do FlexVolume devem mover suas cargas de trabalho para usar o driver CSI equivalente. {{< /note >}} + +## Propagação de montagem + +A propagação de montagem permite compartilhar volumes montados por um contêiner para outros contêineres no mesmo pod, ou mesmo para outros pods no mesmo nó. + +A propagação de montagem de um volume é controlada pelo campo `mountPropagation` na propriedade `Container.volumeMounts`. Os seus valores são: + +* `None` - Este volume de montagem não receberá do host nenhuma montagem posterior que seja montada para este volume ou qualquer um de seus subdiretórios. De forma semelhante, nenhum ponto de montagem criado pelo contêiner será visível no host. Este é o modo padrão. + + Este modo é igual à propagação de montagem `private` conforme descrito na [documentação do kernel Linux](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) + +* `HostToContainer` - Este volume de montagem receberá todas as montagens posteriores que forem montadas para este volume ou qualquer um de seus subdiretórios. + + Em outras palavras, se o host montar qualquer coisa dentro do volume de montagem, o container o visualizará montado ali. + + Da mesma forma, se qualquer Pod com propagação de montagem `Bidirectional` para o mesmo volume montar qualquer coisa lá, o contêiner com propagação de montagem `HostToContainer` o reconhecerá. + + Este modo é igual à propagação de montagem `rslave` conforme descrito na [documentação do kernel Linux](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) + +* `Bidirectional` - Esta montagem de volume se comporta da mesma forma que a montagem de volume `HostToContainer`. Além disso, todas as montagens de volume criadas pelo contêiner serão propagadas de volta ao host e a todos os contêineres de todas os pods que utilizam o mesmo volume. + + Um caso de uso típico para este modo é um Pod com um driver FlexVolume ou CSI ou um Pod que precisa montar algo no host utilizando um volume `hostPath`. + + Este modo é igual à propagação de montagem `rshared` conforme descrito na [documentação do kernel Linux](https://www.kernel.org/doc/Documentation/filesystems/sharedsubtree.txt) + + {{< warning >}} A propagação de montagem `Bidirectional` pode ser perigosa. Ela pode danificar o sistema operacional do host e, portanto, ela só é permitida em contêineres privilegiados. A familiaridade com o comportamento do kernel Linux é fortemente recomendada. Além disso, quaisquer montagens de volume criadas por contêineres em pods devem ser destruídas ( desmontadas) pelos contêineres ao final. {{< /warning >}} + +### Configuração + +Antes que a propagação da montagem possa funcionar corretamente em algumas distribuições (CoreOS, RedHat/Centos, Ubuntu), o compartilhamento de montagem deve ser configurado corretamente no Docker como mostrado abaixo. + +Edite seu arquivo de serviços `systemd` do Docker. Configure a propriedade `MountFlags` da seguinte forma: + +```shell +MountFlags=shared +``` + +Ou, se a propriedade `MountFlags=slave`existir, remova-a. Em seguida, reinicie o daemon Docker: + +```shell +sudo systemctl daemon-reload +sudo systemctl restart docker +``` + +## {{% heading "whatsnext" %}} + +Siga um exemplo de [implantação do WordPress e MySQL com volumes persistentes](/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/). diff --git a/content/pt-br/docs/reference/glossary/application-developer.md b/content/pt-br/docs/reference/glossary/application-developer.md new file mode 100644 index 0000000000..037a9413ad --- /dev/null +++ b/content/pt-br/docs/reference/glossary/application-developer.md @@ -0,0 +1,17 @@ +--- +title: Desenvolvedor de Aplicativos +id: application-developer +date: 2018-04-12 +full_link: +short_description: > + Uma pessoa que escreve um aplicativo que é executado em um cluster Kubernetes. + +aka: +tags: +- user-type +--- + Uma pessoa que escreve um aplicativo que é executado em um cluster Kubernetes. + + + +Um desenvolvedor de aplicativos se concentra em uma parte da aplicação. O seu foco pode variar significativamente em tamanho. 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/cidr.md b/content/pt-br/docs/reference/glossary/cidr.md new file mode 100644 index 0000000000..3073e6560c --- /dev/null +++ b/content/pt-br/docs/reference/glossary/cidr.md @@ -0,0 +1,17 @@ +--- +title: CIDR +id: cidr +date: 2019-11-12 +full_link: +short_description: > + CIDR é uma notação para descrever blocos de endereços IP e é muito usada em várias configurações de rede. + +aka: +tags: +- networking +--- +CIDR (em inglês - Classless Inter-Domain Routing) é uma notação para descrever blocos de endereços IP e é muito usada em várias configurações de rede. + + + +No contexto do Kubernetes, cada {{< glossary_tooltip text="Nó" term_id="node" >}} recebe um intervalo de endereços IP através do endereço inicial e uma máscara de sub-rede usando CIDR. Isso permite que os Nodes atribuam a cada {{< glossary_tooltip text="Pod" term_id="pod" >}} um endereço IP exclusivo. Embora originalmente seja um conceito para IPv4, o CIDR também foi expandido para incluir IPv6. \ No newline at end of file diff --git a/content/pt-br/docs/reference/glossary/cla.md b/content/pt-br/docs/reference/glossary/cla.md new file mode 100644 index 0000000000..5a282a9606 --- /dev/null +++ b/content/pt-br/docs/reference/glossary/cla.md @@ -0,0 +1,17 @@ +--- +title: CLA (Contrato de Licença de Colaborador) +id: cla +date: 2018-04-12 +full_link: https://github.com/kubernetes/community/blob/master/CLA.md +short_description: > + Termos sob os quais um colaborador concede uma licença a um projeto de código aberto por suas contribuições. + +aka: +tags: +- community +--- + Termos sob os quais um {{< glossary_tooltip text="colaborador" term_id="contributor" >}} concede uma licença a um projeto de código aberto por suas contribuições. + + + +Os CLAs ajudam a resolver disputas legais envolvendo material contribuído e propriedade intelectual. 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/reference/glossary/reviewer.md b/content/pt-br/docs/reference/glossary/reviewer.md new file mode 100644 index 0000000000..ff367087ee --- /dev/null +++ b/content/pt-br/docs/reference/glossary/reviewer.md @@ -0,0 +1,17 @@ +--- +title: Revisor +id: reviewer +date: 2018-04-12 +full_link: +short_description: > + Uma pessoa que revisa o código quanto à qualidade e correção em alguma parte do projeto. + +aka: +tags: +- community +--- + Uma pessoa que revisa o código quanto à qualidade e correção em alguma parte do projeto. + + + +Os revisores têm conhecimento sobre o código base e os princípios de engenharia de software. O estado do revisor é atribuído a uma parte do código. \ No newline at end of file diff --git a/content/pt-br/docs/reference/glossary/volume-plugin.md b/content/pt-br/docs/reference/glossary/volume-plugin.md new file mode 100644 index 0000000000..1936fdf3f2 --- /dev/null +++ b/content/pt-br/docs/reference/glossary/volume-plugin.md @@ -0,0 +1,18 @@ +--- +title: Plugin de Volume +id: volumeplugin +date: 2018-04-12 +full_link: +short_description: > + Um plugin de volume permite a integração do armazenamento dentro de um Pod. + +aka: +tags: +- core-object +- storage +--- + Um plugin de volume permite a integração do armazenamento dentro de um {{< glossary_tooltip text="Pod" term_id="pod" >}}. + + + +Um plugin de volume permite anexar e montar volumes de armazenamento para uso por um {{< glossary_tooltip text="Pod" term_id="pod" >}}. Os plugins de volume podem estar _dentro_ ou _fora da árvore_. _Na árvore_, os plugins fazem parte do repositório de código Kubernetes e seguem seu ciclo de lançamento. Os plugins _fora da árvore_ são desenvolvidos de forma independente. \ No newline at end of file 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/concepts/architecture/garbage-collection.md b/content/ru/docs/concepts/architecture/garbage-collection.md index e94da8fc62..5c7a83c392 100644 --- a/content/ru/docs/concepts/architecture/garbage-collection.md +++ b/content/ru/docs/concepts/architecture/garbage-collection.md @@ -12,7 +12,7 @@ weight: 50 * [Объекты без ссылок на владельца Objects](#owners-dependents) * [Не используемые контейнеры и образы контейнеров](#containers-images) * [Dynamically provisioned PersistentVolumes with a StorageClass reclaim policy of Delete](/docs/concepts/storage/persistent-volumes/#delete) - * [Устаревшие или просроченные запросы подписания сертификатов (CSR)](/reference/access-authn-authz/certificate-signing-requests/#request-signing-process) + * [Устаревшие или просроченные запросы подписания сертификатов (CSR)](/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process) * {{}} удалено в следующих сценариях: * В облаке, когда кластер использует [диспетчер облачных контроллеров](/docs/concepts/architecture/cloud-controller/) * Локально когда кластер использует дополнение, аналогичное диспетчер облачных контроллеров 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/setup/learning-environment/minikube.md b/content/ru/docs/setup/learning-environment/minikube.md index 500d171abe..fea7e14252 100644 --- a/content/ru/docs/setup/learning-environment/minikube.md +++ b/content/ru/docs/setup/learning-environment/minikube.md @@ -525,6 +525,4 @@ Minikube использует [libmachine](https://github.com/docker/machine/tre ## Сообщество -Помощь, вопросы и комментарии приветствуются и поощряются! Разработчики Minikube проводят время на [Slack](https://kubernetes.slack.com) в канале #minikube (получить приглашение можно [здесь](http://slack.kubernetes.io/)). У нас также есть [список рассылки kubernetes-dev на Google Groups](https://groups.google.com/forum/#!forum/kubernetes-dev). Если вы отправляете сообщение в список, пожалуйста, начните вашу тему с "minikube: ". - - +Помощь, вопросы и комментарии приветствуются и поощряются! Разработчики Minikube проводят время на [Slack](https://kubernetes.slack.com) в канале #minikube (получить приглашение можно [здесь](http://slack.kubernetes.io/)). У нас также есть [список рассылки dev@kubernetes на Google Groups](https://groups.google.com/a/kubernetes.io/g/dev/). Если вы отправляете сообщение в список, пожалуйста, начните вашу тему с "minikube: ". 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/OWNERS b/content/zh-cn/OWNERS similarity index 100% rename from content/zh/OWNERS rename to content/zh-cn/OWNERS diff --git a/content/zh/_common-resources/images/blocks.svg b/content/zh-cn/_common-resources/images/blocks.svg similarity index 100% rename from content/zh/_common-resources/images/blocks.svg rename to content/zh-cn/_common-resources/images/blocks.svg diff --git a/content/zh/_common-resources/images/flower.svg b/content/zh-cn/_common-resources/images/flower.svg similarity index 100% rename from content/zh/_common-resources/images/flower.svg rename to content/zh-cn/_common-resources/images/flower.svg diff --git a/content/zh/_common-resources/images/kub_video_banner_homepage.jpg b/content/zh-cn/_common-resources/images/kub_video_banner_homepage.jpg similarity index 100% rename from content/zh/_common-resources/images/kub_video_banner_homepage.jpg rename to content/zh-cn/_common-resources/images/kub_video_banner_homepage.jpg diff --git a/content/zh/_common-resources/images/scalable.svg b/content/zh-cn/_common-resources/images/scalable.svg similarity index 100% rename from content/zh/_common-resources/images/scalable.svg rename to content/zh-cn/_common-resources/images/scalable.svg diff --git a/content/zh/_common-resources/images/suitcase.svg b/content/zh-cn/_common-resources/images/suitcase.svg similarity index 100% rename from content/zh/_common-resources/images/suitcase.svg rename to content/zh-cn/_common-resources/images/suitcase.svg diff --git a/content/zh/_common-resources/index.md b/content/zh-cn/_common-resources/index.md similarity index 100% rename from content/zh/_common-resources/index.md rename to content/zh-cn/_common-resources/index.md diff --git a/content/zh/_index.html b/content/zh-cn/_index.html similarity index 100% rename from content/zh/_index.html rename to content/zh-cn/_index.html diff --git a/content/zh/blog/_index.md b/content/zh-cn/blog/_index.md similarity index 100% rename from content/zh/blog/_index.md rename to content/zh-cn/blog/_index.md diff --git a/content/zh/blog/_posts/2015-03-00-Kubernetes-Gathering-Videos.md b/content/zh-cn/blog/_posts/2015-03-00-Kubernetes-Gathering-Videos.md similarity index 100% rename from content/zh/blog/_posts/2015-03-00-Kubernetes-Gathering-Videos.md rename to content/zh-cn/blog/_posts/2015-03-00-Kubernetes-Gathering-Videos.md diff --git a/content/zh/blog/_posts/2015-03-00-Weekly-Kubernetes-Community-Hangout.md b/content/zh-cn/blog/_posts/2015-03-00-Weekly-Kubernetes-Community-Hangout.md similarity index 100% rename from content/zh/blog/_posts/2015-03-00-Weekly-Kubernetes-Community-Hangout.md rename to content/zh-cn/blog/_posts/2015-03-00-Weekly-Kubernetes-Community-Hangout.md diff --git a/content/zh/blog/_posts/2015-03-00-Welcome-To-Kubernetes-Blog.md b/content/zh-cn/blog/_posts/2015-03-00-Welcome-To-Kubernetes-Blog.md similarity index 100% rename from content/zh/blog/_posts/2015-03-00-Welcome-To-Kubernetes-Blog.md rename to content/zh-cn/blog/_posts/2015-03-00-Welcome-To-Kubernetes-Blog.md diff --git a/content/zh/blog/_posts/2015-04-00-Borg-Predecessor-To-Kubernetes.md b/content/zh-cn/blog/_posts/2015-04-00-Borg-Predecessor-To-Kubernetes.md similarity index 100% rename from content/zh/blog/_posts/2015-04-00-Borg-Predecessor-To-Kubernetes.md rename to content/zh-cn/blog/_posts/2015-04-00-Borg-Predecessor-To-Kubernetes.md diff --git a/content/zh/blog/_posts/2015-04-00-Kubernetes-Release-0150.md b/content/zh-cn/blog/_posts/2015-04-00-Kubernetes-Release-0150.md similarity index 100% rename from content/zh/blog/_posts/2015-04-00-Kubernetes-Release-0150.md rename to content/zh-cn/blog/_posts/2015-04-00-Kubernetes-Release-0150.md diff --git a/content/zh/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout.md b/content/zh-cn/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout.md similarity index 100% rename from content/zh/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout.md rename to content/zh-cn/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout.md diff --git a/content/zh/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout_17.md b/content/zh-cn/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout_17.md similarity index 100% rename from content/zh/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout_17.md rename to content/zh-cn/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout_17.md diff --git a/content/zh/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout_29.md b/content/zh-cn/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout_29.md similarity index 100% rename from content/zh/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout_29.md rename to content/zh-cn/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout_29.md diff --git a/content/zh/blog/_posts/2015-05-00-Appc-Support-For-Kubernetes-Through-Rkt.md b/content/zh-cn/blog/_posts/2015-05-00-Appc-Support-For-Kubernetes-Through-Rkt.md similarity index 100% rename from content/zh/blog/_posts/2015-05-00-Appc-Support-For-Kubernetes-Through-Rkt.md rename to content/zh-cn/blog/_posts/2015-05-00-Appc-Support-For-Kubernetes-Through-Rkt.md diff --git a/content/zh/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md b/content/zh-cn/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md similarity index 100% rename from content/zh/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md rename to content/zh-cn/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md diff --git a/content/zh/blog/_posts/2015-05-00-Weekly-Kubernetes-Community-Hangout.md b/content/zh-cn/blog/_posts/2015-05-00-Weekly-Kubernetes-Community-Hangout.md similarity index 100% rename from content/zh/blog/_posts/2015-05-00-Weekly-Kubernetes-Community-Hangout.md rename to content/zh-cn/blog/_posts/2015-05-00-Weekly-Kubernetes-Community-Hangout.md diff --git a/content/zh/blog/_posts/2015-06-00-Slides-Cluster-Management-With.md b/content/zh-cn/blog/_posts/2015-06-00-Slides-Cluster-Management-With.md similarity index 100% rename from content/zh/blog/_posts/2015-06-00-Slides-Cluster-Management-With.md rename to content/zh-cn/blog/_posts/2015-06-00-Slides-Cluster-Management-With.md diff --git a/content/zh/blog/_posts/2015-07-00-Announcing-First-Kubernetes-Enterprise.md b/content/zh-cn/blog/_posts/2015-07-00-Announcing-First-Kubernetes-Enterprise.md similarity index 100% rename from content/zh/blog/_posts/2015-07-00-Announcing-First-Kubernetes-Enterprise.md rename to content/zh-cn/blog/_posts/2015-07-00-Announcing-First-Kubernetes-Enterprise.md diff --git a/content/zh/blog/_posts/2015-08-00-Weekly-Kubernetes-Community-Hangout.md b/content/zh-cn/blog/_posts/2015-08-00-Weekly-Kubernetes-Community-Hangout.md similarity index 100% rename from content/zh/blog/_posts/2015-08-00-Weekly-Kubernetes-Community-Hangout.md rename to content/zh-cn/blog/_posts/2015-08-00-Weekly-Kubernetes-Community-Hangout.md diff --git a/content/zh/blog/_posts/2015-11-00-Kubernetes-1-1-Performance-Upgrades-Improved-Tooling-And-A-Growing-Community.md b/content/zh-cn/blog/_posts/2015-11-00-Kubernetes-1-1-Performance-Upgrades-Improved-Tooling-And-A-Growing-Community.md similarity index 100% rename from content/zh/blog/_posts/2015-11-00-Kubernetes-1-1-Performance-Upgrades-Improved-Tooling-And-A-Growing-Community.md rename to content/zh-cn/blog/_posts/2015-11-00-Kubernetes-1-1-Performance-Upgrades-Improved-Tooling-And-A-Growing-Community.md diff --git a/content/zh/blog/_posts/2015-12-00-Managing-Kubernetes-Pods-Services-And-Replication-Controllers-With-Puppet.md b/content/zh-cn/blog/_posts/2015-12-00-Managing-Kubernetes-Pods-Services-And-Replication-Controllers-With-Puppet.md similarity index 100% rename from content/zh/blog/_posts/2015-12-00-Managing-Kubernetes-Pods-Services-And-Replication-Controllers-With-Puppet.md rename to content/zh-cn/blog/_posts/2015-12-00-Managing-Kubernetes-Pods-Services-And-Replication-Controllers-With-Puppet.md diff --git a/content/zh/blog/_posts/2016-01-00-Kubernetes-Community-Meeting-Notes.md b/content/zh-cn/blog/_posts/2016-01-00-Kubernetes-Community-Meeting-Notes.md similarity index 100% rename from content/zh/blog/_posts/2016-01-00-Kubernetes-Community-Meeting-Notes.md rename to content/zh-cn/blog/_posts/2016-01-00-Kubernetes-Community-Meeting-Notes.md diff --git a/content/zh/blog/_posts/2016-01-00-Simple-Leader-Election-With-Kubernetes.md b/content/zh-cn/blog/_posts/2016-01-00-Simple-Leader-Election-With-Kubernetes.md similarity index 100% rename from content/zh/blog/_posts/2016-01-00-Simple-Leader-Election-With-Kubernetes.md rename to content/zh-cn/blog/_posts/2016-01-00-Simple-Leader-Election-With-Kubernetes.md diff --git a/content/zh/blog/_posts/2016-01-00-Why-Kubernetes-Doesnt-Use-Libnetwork.md b/content/zh-cn/blog/_posts/2016-01-00-Why-Kubernetes-Doesnt-Use-Libnetwork.md similarity index 100% rename from content/zh/blog/_posts/2016-01-00-Why-Kubernetes-Doesnt-Use-Libnetwork.md rename to content/zh-cn/blog/_posts/2016-01-00-Why-Kubernetes-Doesnt-Use-Libnetwork.md diff --git a/content/zh/blog/_posts/2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md b/content/zh-cn/blog/_posts/2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md similarity index 100% rename from content/zh/blog/_posts/2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md rename to content/zh-cn/blog/_posts/2016-02-00-Kubecon-Eu-2016-Kubernetes-Community-In.md diff --git a/content/zh/blog/_posts/2016-02-00-Kubernetes-Community-Meeting-Notes.md b/content/zh-cn/blog/_posts/2016-02-00-Kubernetes-Community-Meeting-Notes.md similarity index 87% rename from content/zh/blog/_posts/2016-02-00-Kubernetes-Community-Meeting-Notes.md rename to content/zh-cn/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-cn/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/2016-02-00-State-Of-Container-World-January-2016.md b/content/zh-cn/blog/_posts/2016-02-00-State-Of-Container-World-January-2016.md similarity index 100% rename from content/zh/blog/_posts/2016-02-00-State-Of-Container-World-January-2016.md rename to content/zh-cn/blog/_posts/2016-02-00-State-Of-Container-World-January-2016.md diff --git a/content/zh/blog/_posts/2016-02-00-kubernetes-community-meeting-notes_23.md b/content/zh-cn/blog/_posts/2016-02-00-kubernetes-community-meeting-notes_23.md similarity index 100% rename from content/zh/blog/_posts/2016-02-00-kubernetes-community-meeting-notes_23.md rename to content/zh-cn/blog/_posts/2016-02-00-kubernetes-community-meeting-notes_23.md diff --git a/content/zh/blog/_posts/2016-04-00-Adding-Support-For-Kubernetes-In-Rancher.md b/content/zh-cn/blog/_posts/2016-04-00-Adding-Support-For-Kubernetes-In-Rancher.md similarity index 100% rename from content/zh/blog/_posts/2016-04-00-Adding-Support-For-Kubernetes-In-Rancher.md rename to content/zh-cn/blog/_posts/2016-04-00-Adding-Support-For-Kubernetes-In-Rancher.md diff --git a/content/zh/blog/_posts/2016-04-00-Kubernetes-Network-Policy-APIs.md b/content/zh-cn/blog/_posts/2016-04-00-Kubernetes-Network-Policy-APIs.md similarity index 100% rename from content/zh/blog/_posts/2016-04-00-Kubernetes-Network-Policy-APIs.md rename to content/zh-cn/blog/_posts/2016-04-00-Kubernetes-Network-Policy-APIs.md diff --git a/content/zh/blog/_posts/2016-04-00-Sig-Clusterops-Promote-Operability-And-Interoperability-Of-K8S-Clusters.md b/content/zh-cn/blog/_posts/2016-04-00-Sig-Clusterops-Promote-Operability-And-Interoperability-Of-K8S-Clusters.md similarity index 100% rename from content/zh/blog/_posts/2016-04-00-Sig-Clusterops-Promote-Operability-And-Interoperability-Of-K8S-Clusters.md rename to content/zh-cn/blog/_posts/2016-04-00-Sig-Clusterops-Promote-Operability-And-Interoperability-Of-K8S-Clusters.md diff --git a/content/zh/blog/_posts/2016-05-00-Coreosfest2016-Kubernetes-Community.md b/content/zh-cn/blog/_posts/2016-05-00-Coreosfest2016-Kubernetes-Community.md similarity index 100% rename from content/zh/blog/_posts/2016-05-00-Coreosfest2016-Kubernetes-Community.md rename to content/zh-cn/blog/_posts/2016-05-00-Coreosfest2016-Kubernetes-Community.md diff --git a/content/zh/blog/_posts/2016-07-00-Bringing-End-To-End-Kubernetes-Testing-To-Azure-2.md b/content/zh-cn/blog/_posts/2016-07-00-Bringing-End-To-End-Kubernetes-Testing-To-Azure-2.md similarity index 100% rename from content/zh/blog/_posts/2016-07-00-Bringing-End-To-End-Kubernetes-Testing-To-Azure-2.md rename to content/zh-cn/blog/_posts/2016-07-00-Bringing-End-To-End-Kubernetes-Testing-To-Azure-2.md diff --git a/content/zh/blog/_posts/2016-07-00-Citrix-Netscaler-And-Kubernetes.md b/content/zh-cn/blog/_posts/2016-07-00-Citrix-Netscaler-And-Kubernetes.md similarity index 100% rename from content/zh/blog/_posts/2016-07-00-Citrix-Netscaler-And-Kubernetes.md rename to content/zh-cn/blog/_posts/2016-07-00-Citrix-Netscaler-And-Kubernetes.md diff --git a/content/zh/blog/_posts/2016-07-00-Dashboard-Web-Interface-For-Kubernetes.md b/content/zh-cn/blog/_posts/2016-07-00-Dashboard-Web-Interface-For-Kubernetes.md similarity index 100% rename from content/zh/blog/_posts/2016-07-00-Dashboard-Web-Interface-For-Kubernetes.md rename to content/zh-cn/blog/_posts/2016-07-00-Dashboard-Web-Interface-For-Kubernetes.md diff --git a/content/zh/blog/_posts/2016-07-00-Oh-The-Places-You-Will-Go.md b/content/zh-cn/blog/_posts/2016-07-00-Oh-The-Places-You-Will-Go.md similarity index 100% rename from content/zh/blog/_posts/2016-07-00-Oh-The-Places-You-Will-Go.md rename to content/zh-cn/blog/_posts/2016-07-00-Oh-The-Places-You-Will-Go.md diff --git a/content/zh/blog/_posts/2016-07-00-stateful-applications-in-containers-kubernetes.md b/content/zh-cn/blog/_posts/2016-07-00-stateful-applications-in-containers-kubernetes.md similarity index 100% rename from content/zh/blog/_posts/2016-07-00-stateful-applications-in-containers-kubernetes.md rename to content/zh-cn/blog/_posts/2016-07-00-stateful-applications-in-containers-kubernetes.md diff --git a/content/zh-cn/blog/_posts/2016-08-00-Sig-Apps-Running-Apps-In-Kubernetes.md b/content/zh-cn/blog/_posts/2016-08-00-Sig-Apps-Running-Apps-In-Kubernetes.md new file mode 100644 index 0000000000..10934bd066 --- /dev/null +++ b/content/zh-cn/blog/_posts/2016-08-00-Sig-Apps-Running-Apps-In-Kubernetes.md @@ -0,0 +1,105 @@ +--- +layout: blog +title: 'SIG Apps: 为 Kubernetes 构建应用并在 Kubernetes 中进行运维' +date: 2016-08-16 +slug: sig-apps-running-apps-in-kubernetes +--- + + + + +**编者注**：这篇文章由 Kubernetes SIG-Apps 团队撰写，分享他们如何关注在 Kubernetes +中运行应用的开发者和 devops 经验。 + +Kubernetes 是容器化应用程序的出色管理者。因此，[众多](https://kubernetes.io/blog/2016/02/sharethis-kubernetes-in-production) +[公司](https://blog.box.com/blog/kubernetes-box-microservices-maximum-velocity/) +[已经](http://techblog.yahoo.co.jp/infrastructure/os_n_k8s/) +[开始](http://www.nextplatform.com/2015/11/12/inside-ebays-shift-to-kubernetes-and-containers-atop-openstack/) 在 Kubernetes 中运行应用程序。 + +Kubernetes 特殊兴趣小组 ([SIGs](https://github.com/kubernetes/community/blob/master/README.md#special-interest-groups-sig)) +自 1.0 版本开始就一直致力于支持开发者和运营商社区。围绕网络、存储、扩展和其他运营领域组织的人员。 + +随着 Kubernetes 的兴起，对工具、最佳实践以及围绕构建和运营云原生应用程序的讨论的需求也随之增加。为了满足这一需求， +Kubernetes [SIG Apps](https://github.com/kubernetes/community/tree/master/sig-apps) 应运而生。 + +SIG Apps 为公司和个人提供以下支持： + + + +- 查看和分享正在构建的、为应用操作人员赋能的工具的演示 +- 了解和讨论应用运营人员的需求 +- 组织各方努力改善体验 + + + +自从 SIG Apps 成立以来，我们已经进行了项目演示，例如 [KubeFuse](https://github.com/opencredo/kubefuse)、 +[KPM](https://github.com/kubespray/kpm)，和 [StackSmith](https://stacksmith.bitnami.com/)。 +我们还对那些负责 Kubernetes 中应用运维的人进行了调查。 + +从调查结果中，我们学到了很多东西，包括： + + + +- 81% 的受访者希望采用某种形式的自动扩缩 +- 为了存储秘密信息，47% 的受访者使用内置 Secret。目前这些资料并未实现静态加密。 + （如果你需要关于加密的帮助，请参见[问题](https://github.com/kubernetes/kubernetes/issues/10439)。) +- 响应最多的问题与第三方工具和调试有关 +- 对于管理应用程序的第三方工具，没有明确的赢家。有各种各样的做法 +- 总体上对缺乏有用文件有较多抱怨。（请在[此处](https://github.com/kubernetes/kubernetes.github.io)帮助提交文档。） +- 数据量很大。很多回答是可选的，所以我们很惊讶所有候选人的所有问题中有 935 个都被填写了。 + 如果你想亲自查看数据，可以[在线](https://docs.google.com/spreadsheets/d/15SUL7QTpR4Flrp5eJ5TR8A5ZAFwbchfX2QL4MEoJFQ8/edit?usp=sharing)查看。 + + + +就应用运维而言，仍然有很多东西需要解决和共享。如果你对运行应用程序有看法或者有改善体验的工具， +或者只是想潜伏并了解状况，请加入我们。 + + + +- 在 SIG-Apps [Slack 频道](https://kubernetes.slack.com/messages/sig-apps)与我们聊天 +- 发送邮件到 SIG-Apps [邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-apps) +- 参加我们的公开会议：太平洋时间每周三上午 9 点，[详情点击此处](https://github.com/kubernetes/community/blob/master/sig-apps/README.md#meeting) + + +_--Matt Farina ，Hewlett Packard Enterprise 首席工程师_ \ No newline at end of file diff --git a/content/zh/blog/_posts/2016-08-00-Stateful-Applications-Using-Kubernetes-Datera.md b/content/zh-cn/blog/_posts/2016-08-00-Stateful-Applications-Using-Kubernetes-Datera.md similarity index 100% rename from content/zh/blog/_posts/2016-08-00-Stateful-Applications-Using-Kubernetes-Datera.md rename to content/zh-cn/blog/_posts/2016-08-00-Stateful-Applications-Using-Kubernetes-Datera.md diff --git a/content/zh/blog/_posts/2017-10-00-Five-Days-Of-Kubernetes-18.md b/content/zh-cn/blog/_posts/2017-10-00-Five-Days-Of-Kubernetes-18.md similarity index 100% rename from content/zh/blog/_posts/2017-10-00-Five-Days-Of-Kubernetes-18.md rename to content/zh-cn/blog/_posts/2017-10-00-Five-Days-Of-Kubernetes-18.md diff --git a/content/zh/blog/_posts/2017-10-00-Kubernetes-Community-Steering-Committee-Election-Results.md b/content/zh-cn/blog/_posts/2017-10-00-Kubernetes-Community-Steering-Committee-Election-Results.md similarity index 100% rename from content/zh/blog/_posts/2017-10-00-Kubernetes-Community-Steering-Committee-Election-Results.md rename to content/zh-cn/blog/_posts/2017-10-00-Kubernetes-Community-Steering-Committee-Election-Results.md diff --git a/content/zh/blog/_posts/2017-11-00-Autoscaling-In-Kubernetes.md b/content/zh-cn/blog/_posts/2017-11-00-Autoscaling-In-Kubernetes.md similarity index 100% rename from content/zh/blog/_posts/2017-11-00-Autoscaling-In-Kubernetes.md rename to content/zh-cn/blog/_posts/2017-11-00-Autoscaling-In-Kubernetes.md diff --git a/content/zh/blog/_posts/2018-01-00-Kubernetes-V19-Beta-Windows-Support.md b/content/zh-cn/blog/_posts/2018-01-00-Kubernetes-V19-Beta-Windows-Support.md similarity index 100% rename from content/zh/blog/_posts/2018-01-00-Kubernetes-V19-Beta-Windows-Support.md rename to content/zh-cn/blog/_posts/2018-01-00-Kubernetes-V19-Beta-Windows-Support.md diff --git a/content/zh/blog/_posts/2018-03-00-Principles-Of-Container-App-Design.md b/content/zh-cn/blog/_posts/2018-03-00-Principles-Of-Container-App-Design.md similarity index 100% rename from content/zh/blog/_posts/2018-03-00-Principles-Of-Container-App-Design.md rename to content/zh-cn/blog/_posts/2018-03-00-Principles-Of-Container-App-Design.md diff --git a/content/zh/blog/_posts/2018-04-25-open-source-charts-2017.md b/content/zh-cn/blog/_posts/2018-04-25-open-source-charts-2017.md similarity index 100% rename from content/zh/blog/_posts/2018-04-25-open-source-charts-2017.md rename to content/zh-cn/blog/_posts/2018-04-25-open-source-charts-2017.md diff --git a/content/zh/blog/_posts/2018-05-01-developing-on-kubernetes.md b/content/zh-cn/blog/_posts/2018-05-01-developing-on-kubernetes.md similarity index 100% rename from content/zh/blog/_posts/2018-05-01-developing-on-kubernetes.md rename to content/zh-cn/blog/_posts/2018-05-01-developing-on-kubernetes.md diff --git a/content/zh/blog/_posts/2018-05-30-say-hello-to-discuss-kubernetes.md b/content/zh-cn/blog/_posts/2018-05-30-say-hello-to-discuss-kubernetes.md similarity index 100% rename from content/zh/blog/_posts/2018-05-30-say-hello-to-discuss-kubernetes.md rename to content/zh-cn/blog/_posts/2018-05-30-say-hello-to-discuss-kubernetes.md diff --git a/content/zh/blog/_posts/2018-06-06-4-years-of-k8s.md b/content/zh-cn/blog/_posts/2018-06-06-4-years-of-k8s.md similarity index 100% rename from content/zh/blog/_posts/2018-06-06-4-years-of-k8s.md rename to content/zh-cn/blog/_posts/2018-06-06-4-years-of-k8s.md diff --git a/content/zh/blog/_posts/2018-06-07-dynamic-ingress-kubernetes.md b/content/zh-cn/blog/_posts/2018-06-07-dynamic-ingress-kubernetes.md similarity index 100% rename from content/zh/blog/_posts/2018-06-07-dynamic-ingress-kubernetes.md rename to content/zh-cn/blog/_posts/2018-06-07-dynamic-ingress-kubernetes.md diff --git a/content/zh/blog/_posts/2018-06-28-Airflow-Kubernetes-Operator.md b/content/zh-cn/blog/_posts/2018-06-28-Airflow-Kubernetes-Operator.md similarity index 100% rename from content/zh/blog/_posts/2018-06-28-Airflow-Kubernetes-Operator.md rename to content/zh-cn/blog/_posts/2018-06-28-Airflow-Kubernetes-Operator.md diff --git a/content/zh/blog/_posts/2018-07-09-IPVS-In-Cluster-Load-Balancing.md b/content/zh-cn/blog/_posts/2018-07-09-IPVS-In-Cluster-Load-Balancing.md similarity index 100% rename from content/zh/blog/_posts/2018-07-09-IPVS-In-Cluster-Load-Balancing.md rename to content/zh-cn/blog/_posts/2018-07-09-IPVS-In-Cluster-Load-Balancing.md diff --git a/content/zh/blog/_posts/2018-07-10-coredns-ga.md b/content/zh-cn/blog/_posts/2018-07-10-coredns-ga.md similarity index 100% rename from content/zh/blog/_posts/2018-07-10-coredns-ga.md rename to content/zh-cn/blog/_posts/2018-07-10-coredns-ga.md diff --git a/content/zh/blog/_posts/2018-07-11-dynamic-kubelet-configuration.md b/content/zh-cn/blog/_posts/2018-07-11-dynamic-kubelet-configuration.md similarity index 100% rename from content/zh/blog/_posts/2018-07-11-dynamic-kubelet-configuration.md rename to content/zh-cn/blog/_posts/2018-07-11-dynamic-kubelet-configuration.md diff --git a/content/zh/blog/_posts/2018-08-02-dynamically-expand-volume-csi.md b/content/zh-cn/blog/_posts/2018-08-02-dynamically-expand-volume-csi.md similarity index 99% rename from content/zh/blog/_posts/2018-08-02-dynamically-expand-volume-csi.md rename to content/zh-cn/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-cn/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/2018-10-15-steering-election-results.md b/content/zh-cn/blog/_posts/2018-10-15-steering-election-results.md similarity index 100% rename from content/zh/blog/_posts/2018-10-15-steering-election-results.md rename to content/zh-cn/blog/_posts/2018-10-15-steering-election-results.md diff --git a/content/zh/blog/_posts/2018-10-16-kubernetes-2018-north-american-contributor-summit.md b/content/zh-cn/blog/_posts/2018-10-16-kubernetes-2018-north-american-contributor-summit.md similarity index 100% rename from content/zh/blog/_posts/2018-10-16-kubernetes-2018-north-american-contributor-summit.md rename to content/zh-cn/blog/_posts/2018-10-16-kubernetes-2018-north-american-contributor-summit.md diff --git a/content/zh/blog/_posts/2018-11-08-kubernetes-docs-update-i18n.md b/content/zh-cn/blog/_posts/2018-11-08-kubernetes-docs-update-i18n.md similarity index 100% rename from content/zh/blog/_posts/2018-11-08-kubernetes-docs-update-i18n.md rename to content/zh-cn/blog/_posts/2018-11-08-kubernetes-docs-update-i18n.md diff --git a/content/zh/blog/_posts/2018-12-05-new-contributor-shanghai.md b/content/zh-cn/blog/_posts/2018-12-05-new-contributor-shanghai.md similarity index 100% rename from content/zh/blog/_posts/2018-12-05-new-contributor-shanghai.md rename to content/zh-cn/blog/_posts/2018-12-05-new-contributor-shanghai.md diff --git a/content/zh/blog/_posts/2019-03-07-raw-block-volume-support-to-beta.md b/content/zh-cn/blog/_posts/2019-03-07-raw-block-volume-support-to-beta.md similarity index 100% rename from content/zh/blog/_posts/2019-03-07-raw-block-volume-support-to-beta.md rename to content/zh-cn/blog/_posts/2019-03-07-raw-block-volume-support-to-beta.md diff --git a/content/zh/blog/_posts/2019-03-28-PID-Limiting.md b/content/zh-cn/blog/_posts/2019-03-28-PID-Limiting.md similarity index 100% rename from content/zh/blog/_posts/2019-03-28-PID-Limiting.md rename to content/zh-cn/blog/_posts/2019-03-28-PID-Limiting.md diff --git a/content/zh/blog/_posts/2019-04-26-latest-on-localization.md b/content/zh-cn/blog/_posts/2019-04-26-latest-on-localization.md similarity index 100% rename from content/zh/blog/_posts/2019-04-26-latest-on-localization.md rename to content/zh-cn/blog/_posts/2019-04-26-latest-on-localization.md diff --git a/content/zh/blog/_posts/2019-05-14-expanding-our-contributor-workshops.md b/content/zh-cn/blog/_posts/2019-05-14-expanding-our-contributor-workshops.md similarity index 100% rename from content/zh/blog/_posts/2019-05-14-expanding-our-contributor-workshops.md rename to content/zh-cn/blog/_posts/2019-05-14-expanding-our-contributor-workshops.md diff --git a/content/zh/blog/_posts/2019-06-12-contributor-summit-shanghai.md b/content/zh-cn/blog/_posts/2019-06-12-contributor-summit-shanghai.md similarity index 100% rename from content/zh/blog/_posts/2019-06-12-contributor-summit-shanghai.md rename to content/zh-cn/blog/_posts/2019-06-12-contributor-summit-shanghai.md diff --git a/content/zh/blog/_posts/2019-08-06-OPA-Gatekeeper-Policy-and-Governance-for-Kubernetes.md b/content/zh-cn/blog/_posts/2019-08-06-OPA-Gatekeeper-Policy-and-Governance-for-Kubernetes.md similarity index 100% rename from content/zh/blog/_posts/2019-08-06-OPA-Gatekeeper-Policy-and-Governance-for-Kubernetes.md rename to content/zh-cn/blog/_posts/2019-08-06-OPA-Gatekeeper-Policy-and-Governance-for-Kubernetes.md diff --git a/content/zh/blog/_posts/2019-09-24-san-diego-contributor-summit.md b/content/zh-cn/blog/_posts/2019-09-24-san-diego-contributor-summit.md similarity index 100% rename from content/zh/blog/_posts/2019-09-24-san-diego-contributor-summit.md rename to content/zh-cn/blog/_posts/2019-09-24-san-diego-contributor-summit.md diff --git a/content/zh/blog/_posts/2019-10-03-2019-Steering-Committee-Election-Results.md b/content/zh-cn/blog/_posts/2019-10-03-2019-Steering-Committee-Election-Results.md similarity index 100% rename from content/zh/blog/_posts/2019-10-03-2019-Steering-Committee-Election-Results.md rename to content/zh-cn/blog/_posts/2019-10-03-2019-Steering-Committee-Election-Results.md diff --git a/content/zh/blog/_posts/2019-10-10-contributor-summit-san-diego-schedule.md b/content/zh-cn/blog/_posts/2019-10-10-contributor-summit-san-diego-schedule.md similarity index 100% rename from content/zh/blog/_posts/2019-10-10-contributor-summit-san-diego-schedule.md rename to content/zh-cn/blog/_posts/2019-10-10-contributor-summit-san-diego-schedule.md diff --git a/content/zh/blog/_posts/2019-10-29-2019-sig-docs-survey.md b/content/zh-cn/blog/_posts/2019-10-29-2019-sig-docs-survey.md similarity index 100% rename from content/zh/blog/_posts/2019-10-29-2019-sig-docs-survey.md rename to content/zh-cn/blog/_posts/2019-10-29-2019-sig-docs-survey.md diff --git a/content/zh/blog/_posts/2019-11-05-kubernetes-with-microk8s.md b/content/zh-cn/blog/_posts/2019-11-05-kubernetes-with-microk8s.md similarity index 100% rename from content/zh/blog/_posts/2019-11-05-kubernetes-with-microk8s.md rename to content/zh-cn/blog/_posts/2019-11-05-kubernetes-with-microk8s.md diff --git a/content/zh/blog/_posts/2019-11-26-cloud-native-java-controller-sdk.md b/content/zh-cn/blog/_posts/2019-11-26-cloud-native-java-controller-sdk.md similarity index 100% rename from content/zh/blog/_posts/2019-11-26-cloud-native-java-controller-sdk.md rename to content/zh-cn/blog/_posts/2019-11-26-cloud-native-java-controller-sdk.md diff --git a/content/zh/blog/_posts/2019-12-09-kubernetes-1.17-release-announcement.md b/content/zh-cn/blog/_posts/2019-12-09-kubernetes-1.17-release-announcement.md similarity index 100% rename from content/zh/blog/_posts/2019-12-09-kubernetes-1.17-release-announcement.md rename to content/zh-cn/blog/_posts/2019-12-09-kubernetes-1.17-release-announcement.md diff --git a/content/zh/blog/_posts/2020-01-15-Kubernetes-on-MIPS.md b/content/zh-cn/blog/_posts/2020-01-15-Kubernetes-on-MIPS.md similarity index 100% rename from content/zh/blog/_posts/2020-01-15-Kubernetes-on-MIPS.md rename to content/zh-cn/blog/_posts/2020-01-15-Kubernetes-on-MIPS.md diff --git a/content/zh/blog/_posts/2020-03-25-kubernetes-1.18-release-announcement.md b/content/zh-cn/blog/_posts/2020-03-25-kubernetes-1.18-release-announcement.md similarity index 70% rename from content/zh/blog/_posts/2020-03-25-kubernetes-1.18-release-announcement.md rename to content/zh-cn/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-cn/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)， +并通过以下渠道分享你的声音。感谢你一直以来的反馈和支持。 卷填充器功能现在已经经历两个发行版本并进入 Beta 阶段！ -在 Kubernetes v1.24 中 `AnyVolumeDataSouce` 特性门控默认被启用。 +在 Kubernetes v1.24 中 `AnyVolumeDataSource` 特性门控默认被启用。 这意味着用户可以指定任何自定义资源作为 PVC 的数据源。 -[之前的一篇博客](/blog/2021/08/30-volume-populators-alpha/)详细介绍了卷填充器功能的工作原理。 +[之前的一篇博客](/blog/2021/08/30/volume-populators-redesigned/)详细介绍了卷填充器功能的工作原理。 简而言之，集群管理员可以在集群中安装 CRD 和相关的填充器控制器， 任何可以创建 CR 实例的用户都可以利用填充器创建预填充卷。 diff --git a/content/zh-cn/blog/_posts/2022-05-18-prevent-unauthorised-volume-mode-conversion.md b/content/zh-cn/blog/_posts/2022-05-18-prevent-unauthorised-volume-mode-conversion.md new file mode 100644 index 0000000000..15e86f5e5d --- /dev/null +++ b/content/zh-cn/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-cn/blog/_posts/2022-05-23-service-ip-dynamic-and-static-allocation.md b/content/zh-cn/blog/_posts/2022-05-23-service-ip-dynamic-and-static-allocation.md new file mode 100644 index 0000000000..fccad6cc3d --- /dev/null +++ b/content/zh-cn/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-cn/blog/_posts/2022-05-27-maxunavailable-for-statefulset.md b/content/zh-cn/blog/_posts/2022-05-27-maxunavailable-for-statefulset.md new file mode 100644 index 0000000000..4752273dad --- /dev/null +++ b/content/zh-cn/blog/_posts/2022-05-27-maxunavailable-for-statefulset.md @@ -0,0 +1,239 @@ +--- +layout: blog +title: 'Kubernetes 1.24: StatefulSet 的最大不可用副本数' +date: 2022-05-27 +slug: maxunavailable-for-statefulset +--- + +**作者：** Mayank Kumar (Salesforce) + + +Kubernetes [StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/)， +自 1.5 版本中引入并在 1.9 版本中变得稳定以来，已被广泛用于运行有状态应用。它提供固定的 Pod 身份标识、 +每个 Pod 的持久存储以及 Pod 的有序部署、扩缩容和滚动更新功能。你可以将 StatefulSet +视为运行复杂有状态应用程序的原子构建块。随着 Kubernetes 的使用增多，需要 StatefulSet 的场景也越来越多。 +当 StatefulSet 的 Pod 管理策略为 `OrderedReady` 时，其中许多场景需要比当前所支持的一次一个 Pod +的更新更快的滚动更新。 + + +这里有些例子： + +- 我使用 StatefulSet 来编排一个基于缓存的多实例应用程序，其中缓存的规格很大。 + 缓存冷启动，需要相当长的时间才能启动容器。所需要的初始启动任务有很多。在应用程序完全更新之前， + 此 StatefulSet 上的 RollingUpdate 将花费大量时间。如果 StatefulSet 支持一次更新多个 Pod， + 那么更新速度会快得多。 + + +- 我的有状态应用程序由 leader 和 follower 或者一个 writer 和多个 reader 组成。 + 我有多个 reader 或 follower，并且我的应用程序可以容忍多个 Pod 同时出现故障。 + 我想一次更新这个应用程序的多个 Pod，特别是当我的应用程序实例数量很多时，这样我就能快速推出新的更新。 + 注意，我的应用程序仍然需要每个 Pod 具有唯一标识。 + + +为了支持这样的场景，Kubernetes 1.24 提供了一个新的 alpha 特性。在使用新特性之前，必须启用 +`MaxUnavailableStatefulSet` 特性标志。一旦启用，就可以指定一个名为 `maxUnavailable` 的新字段， +这是 StatefulSet `spec` 的一部分。例如： + +``` +apiVersion: apps/v1 +kind: StatefulSet +metadata: + name: web + namespace: default +spec: + podManagementPolicy: OrderedReady # 你必须设为 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 # 这是 alpha 特性的字段，默认值是 1 + partition: 0 + type: RollingUpdate +``` + + +如果你启用了新特性，但没有在 StatefulSet 中指定 `maxUnavailable` 的值，Kubernetes +会默认设置 `maxUnavailable: 1`。这与你不启用新特性时看到的行为是一致的。 + + +我将基于该示例清单做场景演练，以演示此特性是如何工作的。我将部署一个有 5 个副本的 StatefulSet， +`maxUnavailable` 设置为 2 并将 `partition` 设置为 0。 + + +我可以通过将镜像更改为 `k8s.gcr.io/nginx-slim:0.9` 来触发滚动更新。一旦开始滚动更新， +就可以看到一次更新 2 个 Pod，因为 `maxUnavailable` 的当前值是 2。 +下面的输出显示了一个时间段内的结果，但并不是完整过程。`maxUnavailable` 可以是绝对数值（例如 2）或所需 Pod +的百分比（例如 10%），绝对数是通过百分比计算结果进行四舍五入得出的。 + +``` +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 +``` + +注意，滚动更新一开始，4 和 3（两个最高序号的 Pod）同时开始进入 `Terminating` 状态。 +Pod 4 和 3 会按照自身节奏进行更新。一旦 Pod 4 和 3 更新完毕后，Pod 2 和 1 会同时进入 +`Terminating` 状态。当 Pod 2 和 1 都准备完毕处于 `Running` 状态时，Pod 0 开始进入 `Terminating` 状态 + + +在 Kubernetes 中，StatefulSet 更新 Pod 时遵循严格的顺序。在此示例中，更新从副本 4 开始， +然后是副本 3，然后是副本 2，以此类推，一次更新一个 Pod。当一次只更新一个 Pod 时， +副本 3 不可能在副本 4 之前准备好进入 `Running` 状态。当 `maxUnavailable` 值 +大于 1 时（在示例场景中我设置 `maxUnavailable` 值为 2），副本 3 可能在副本 4 之前准备好并运行， +这是没问题的。如果你是开发人员并且设置 `maxUnavailable` 值大于 1，你应该知道可能出现这种情况， +并且如果有这种情况的话，你必须确保你的应用程序能够处理发生的此类顺序问题。当你设置 `maxUnavailable` +值大于 1 时，更新 Pod 的批次之间会保证顺序。该保证意味着在批次 0（副本 4 和 3）中的 Pod +准备好之前，更新批次 2（副本 2 和 1）中的 Pod 无法开始更新。 + + +尽管 Kubernetes 将这些称为**副本**，但你的有状态应用程序可能不这样理解，StatefulSet 的每个 +Pod 可能持有与其他 Pod 完全不同的数据。重要的是，StatefulSet 的更新是分批进行的， +你现在让批次大小大于 1（作为 alpha 特性）。 + + +还要注意，上面的行为采用的 Pod 管理策略是 `podManagementPolicy: OrderedReady`。 +如果你的 StatefulSet 的 Pod 管理策略是 `podManagementPolicy: Parallel`， +那么不仅是 `maxUnavailable` 数量的副本同时被终止，还会导致 `maxUnavailable` 数量的副本同时在 +`ContainerCreating` 阶段。这就是所谓的突发（Bursting）。 + + +因此，现在你可能有很多关于以下方面的问题： +- 当设置 `podManagementPolicy:Parallel` 时，会产生什么行为？ +- 将 `partition` 设置为非 `0` 值时会发生什么？ + + +自己试试看可能会更好。这是一个 alpha 特性，Kubernetes 贡献者正在寻找有关此特性的反馈。 +这是否有助于你实现有状态的场景？你是否发现了一个 bug，或者你认为实现的行为不直观易懂， +或者它可能会破坏应用程序或让他们感到吃惊？请[登记一个 issue](https://github.com/kubernetes/kubernetes/issues) +告知我们。 + + +## 进一步阅读和后续步骤 {#next-steps} +- [最多不可用 Pod 数](/zh/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) +- [代码实现](https://github.com/kubernetes/kubernetes/pull/82162/files) +- [增强跟踪 Issue](https://github.com/kubernetes/enhancements/issues/961) \ No newline at end of file diff --git a/content/zh/case-studies/_index.html b/content/zh-cn/case-studies/_index.html similarity index 100% rename from content/zh/case-studies/_index.html rename to content/zh-cn/case-studies/_index.html diff --git a/content/zh/case-studies/adform/adform_featured_logo.png b/content/zh-cn/case-studies/adform/adform_featured_logo.png similarity index 100% rename from content/zh/case-studies/adform/adform_featured_logo.png rename to content/zh-cn/case-studies/adform/adform_featured_logo.png diff --git a/content/zh/case-studies/adform/index.html b/content/zh-cn/case-studies/adform/index.html similarity index 100% rename from content/zh/case-studies/adform/index.html rename to content/zh-cn/case-studies/adform/index.html diff --git a/content/zh/case-studies/adidas/adidas-featured.svg b/content/zh-cn/case-studies/adidas/adidas-featured.svg similarity index 100% rename from content/zh/case-studies/adidas/adidas-featured.svg rename to content/zh-cn/case-studies/adidas/adidas-featured.svg diff --git a/content/zh/case-studies/adidas/index.html b/content/zh-cn/case-studies/adidas/index.html similarity index 100% rename from content/zh/case-studies/adidas/index.html rename to content/zh-cn/case-studies/adidas/index.html diff --git a/content/zh/case-studies/amadeus/amadeus_featured.png b/content/zh-cn/case-studies/amadeus/amadeus_featured.png similarity index 100% rename from content/zh/case-studies/amadeus/amadeus_featured.png rename to content/zh-cn/case-studies/amadeus/amadeus_featured.png diff --git a/content/zh/case-studies/amadeus/amadeus_logo.png b/content/zh-cn/case-studies/amadeus/amadeus_logo.png similarity index 100% rename from content/zh/case-studies/amadeus/amadeus_logo.png rename to content/zh-cn/case-studies/amadeus/amadeus_logo.png diff --git a/content/zh/case-studies/amadeus/index.html b/content/zh-cn/case-studies/amadeus/index.html similarity index 100% rename from content/zh/case-studies/amadeus/index.html rename to content/zh-cn/case-studies/amadeus/index.html diff --git a/content/zh/case-studies/ancestry/ancestry_featured.png b/content/zh-cn/case-studies/ancestry/ancestry_featured.png similarity index 100% rename from content/zh/case-studies/ancestry/ancestry_featured.png rename to content/zh-cn/case-studies/ancestry/ancestry_featured.png diff --git a/content/zh/case-studies/ancestry/ancestry_logo.png b/content/zh-cn/case-studies/ancestry/ancestry_logo.png similarity index 100% rename from content/zh/case-studies/ancestry/ancestry_logo.png rename to content/zh-cn/case-studies/ancestry/ancestry_logo.png diff --git a/content/zh/case-studies/ancestry/index.html b/content/zh-cn/case-studies/ancestry/index.html similarity index 100% rename from content/zh/case-studies/ancestry/index.html rename to content/zh-cn/case-studies/ancestry/index.html diff --git a/content/zh/case-studies/ant-financial/ant-financial_featured_logo.png b/content/zh-cn/case-studies/ant-financial/ant-financial_featured_logo.png similarity index 100% rename from content/zh/case-studies/ant-financial/ant-financial_featured_logo.png rename to content/zh-cn/case-studies/ant-financial/ant-financial_featured_logo.png diff --git a/content/zh/case-studies/ant-financial/index.html b/content/zh-cn/case-studies/ant-financial/index.html similarity index 100% rename from content/zh/case-studies/ant-financial/index.html rename to content/zh-cn/case-studies/ant-financial/index.html diff --git a/content/zh/case-studies/appdirect/appdirect_featured_logo.png b/content/zh-cn/case-studies/appdirect/appdirect_featured_logo.png similarity index 100% rename from content/zh/case-studies/appdirect/appdirect_featured_logo.png rename to content/zh-cn/case-studies/appdirect/appdirect_featured_logo.png diff --git a/content/zh/case-studies/appdirect/index.html b/content/zh-cn/case-studies/appdirect/index.html similarity index 100% rename from content/zh/case-studies/appdirect/index.html rename to content/zh-cn/case-studies/appdirect/index.html diff --git a/content/zh/case-studies/babylon/babylon_featured_logo.png b/content/zh-cn/case-studies/babylon/babylon_featured_logo.png similarity index 100% rename from content/zh/case-studies/babylon/babylon_featured_logo.png rename to content/zh-cn/case-studies/babylon/babylon_featured_logo.png diff --git a/content/zh/case-studies/babylon/babylon_featured_logo.svg b/content/zh-cn/case-studies/babylon/babylon_featured_logo.svg similarity index 100% rename from content/zh/case-studies/babylon/babylon_featured_logo.svg rename to content/zh-cn/case-studies/babylon/babylon_featured_logo.svg diff --git a/content/zh/case-studies/babylon/index.html b/content/zh-cn/case-studies/babylon/index.html similarity index 100% rename from content/zh/case-studies/babylon/index.html rename to content/zh-cn/case-studies/babylon/index.html diff --git a/content/zh/case-studies/blablacar/blablacar_featured.png b/content/zh-cn/case-studies/blablacar/blablacar_featured.png similarity index 100% rename from content/zh/case-studies/blablacar/blablacar_featured.png rename to content/zh-cn/case-studies/blablacar/blablacar_featured.png diff --git a/content/zh/case-studies/blablacar/blablacar_logo.png b/content/zh-cn/case-studies/blablacar/blablacar_logo.png similarity index 100% rename from content/zh/case-studies/blablacar/blablacar_logo.png rename to content/zh-cn/case-studies/blablacar/blablacar_logo.png diff --git a/content/zh/case-studies/blablacar/index.html b/content/zh-cn/case-studies/blablacar/index.html similarity index 100% rename from content/zh/case-studies/blablacar/index.html rename to content/zh-cn/case-studies/blablacar/index.html diff --git a/content/zh/case-studies/blackrock/blackrock_featured.png b/content/zh-cn/case-studies/blackrock/blackrock_featured.png similarity index 100% rename from content/zh/case-studies/blackrock/blackrock_featured.png rename to content/zh-cn/case-studies/blackrock/blackrock_featured.png diff --git a/content/zh/case-studies/blackrock/blackrock_logo.png b/content/zh-cn/case-studies/blackrock/blackrock_logo.png similarity index 100% rename from content/zh/case-studies/blackrock/blackrock_logo.png rename to content/zh-cn/case-studies/blackrock/blackrock_logo.png diff --git a/content/zh/case-studies/blackrock/index.html b/content/zh-cn/case-studies/blackrock/index.html similarity index 100% rename from content/zh/case-studies/blackrock/index.html rename to content/zh-cn/case-studies/blackrock/index.html diff --git a/content/zh/case-studies/booking-com/booking.com_featured_logo.png b/content/zh-cn/case-studies/booking-com/booking.com_featured_logo.png similarity index 100% rename from content/zh/case-studies/booking-com/booking.com_featured_logo.png rename to content/zh-cn/case-studies/booking-com/booking.com_featured_logo.png diff --git a/content/zh/case-studies/booking-com/booking.com_featured_logo.svg b/content/zh-cn/case-studies/booking-com/booking.com_featured_logo.svg similarity index 100% rename from content/zh/case-studies/booking-com/booking.com_featured_logo.svg rename to content/zh-cn/case-studies/booking-com/booking.com_featured_logo.svg diff --git a/content/zh/case-studies/booking-com/index.html b/content/zh-cn/case-studies/booking-com/index.html similarity index 100% rename from content/zh/case-studies/booking-com/index.html rename to content/zh-cn/case-studies/booking-com/index.html diff --git a/content/zh/case-studies/booz-allen/booz-allen-featured-logo.svg b/content/zh-cn/case-studies/booz-allen/booz-allen-featured-logo.svg similarity index 100% rename from content/zh/case-studies/booz-allen/booz-allen-featured-logo.svg rename to content/zh-cn/case-studies/booz-allen/booz-allen-featured-logo.svg diff --git a/content/zh/case-studies/booz-allen/booz-allen_featured_logo.png b/content/zh-cn/case-studies/booz-allen/booz-allen_featured_logo.png similarity index 100% rename from content/zh/case-studies/booz-allen/booz-allen_featured_logo.png rename to content/zh-cn/case-studies/booz-allen/booz-allen_featured_logo.png diff --git a/content/zh/case-studies/booz-allen/index.html b/content/zh-cn/case-studies/booz-allen/index.html similarity index 100% rename from content/zh/case-studies/booz-allen/index.html rename to content/zh-cn/case-studies/booz-allen/index.html diff --git a/content/zh/case-studies/bose/bose_featured_logo.png b/content/zh-cn/case-studies/bose/bose_featured_logo.png similarity index 100% rename from content/zh/case-studies/bose/bose_featured_logo.png rename to content/zh-cn/case-studies/bose/bose_featured_logo.png diff --git a/content/zh/case-studies/bose/index.html b/content/zh-cn/case-studies/bose/index.html similarity index 100% rename from content/zh/case-studies/bose/index.html rename to content/zh-cn/case-studies/bose/index.html diff --git a/content/zh/case-studies/box/box_featured.png b/content/zh-cn/case-studies/box/box_featured.png similarity index 100% rename from content/zh/case-studies/box/box_featured.png rename to content/zh-cn/case-studies/box/box_featured.png diff --git a/content/zh/case-studies/box/box_logo.png b/content/zh-cn/case-studies/box/box_logo.png similarity index 100% rename from content/zh/case-studies/box/box_logo.png rename to content/zh-cn/case-studies/box/box_logo.png diff --git a/content/zh/case-studies/box/box_small.png b/content/zh-cn/case-studies/box/box_small.png similarity index 100% rename from content/zh/case-studies/box/box_small.png rename to content/zh-cn/case-studies/box/box_small.png diff --git a/content/zh/case-studies/box/index.html b/content/zh-cn/case-studies/box/index.html similarity index 100% rename from content/zh/case-studies/box/index.html rename to content/zh-cn/case-studies/box/index.html diff --git a/content/zh/case-studies/box/video.png b/content/zh-cn/case-studies/box/video.png similarity index 100% rename from content/zh/case-studies/box/video.png rename to content/zh-cn/case-studies/box/video.png diff --git a/content/zh/case-studies/buffer/buffer_featured.png b/content/zh-cn/case-studies/buffer/buffer_featured.png similarity index 100% rename from content/zh/case-studies/buffer/buffer_featured.png rename to content/zh-cn/case-studies/buffer/buffer_featured.png diff --git a/content/zh/case-studies/buffer/buffer_logo.png b/content/zh-cn/case-studies/buffer/buffer_logo.png similarity index 100% rename from content/zh/case-studies/buffer/buffer_logo.png rename to content/zh-cn/case-studies/buffer/buffer_logo.png diff --git a/content/zh/case-studies/buffer/index.html b/content/zh-cn/case-studies/buffer/index.html similarity index 100% rename from content/zh/case-studies/buffer/index.html rename to content/zh-cn/case-studies/buffer/index.html diff --git a/content/zh/case-studies/capital-one/capitalone_featured_logo.png b/content/zh-cn/case-studies/capital-one/capitalone_featured_logo.png similarity index 100% rename from content/zh/case-studies/capital-one/capitalone_featured_logo.png rename to content/zh-cn/case-studies/capital-one/capitalone_featured_logo.png diff --git a/content/zh/case-studies/capital-one/index.html b/content/zh-cn/case-studies/capital-one/index.html similarity index 100% rename from content/zh/case-studies/capital-one/index.html rename to content/zh-cn/case-studies/capital-one/index.html diff --git a/content/zh/case-studies/cern/cern_featured_logo.png b/content/zh-cn/case-studies/cern/cern_featured_logo.png similarity index 100% rename from content/zh/case-studies/cern/cern_featured_logo.png rename to content/zh-cn/case-studies/cern/cern_featured_logo.png diff --git a/content/zh/case-studies/cern/index.html b/content/zh-cn/case-studies/cern/index.html similarity index 100% rename from content/zh/case-studies/cern/index.html rename to content/zh-cn/case-studies/cern/index.html diff --git a/content/zh/case-studies/chinaunicom/chinaunicom_featured_logo.png b/content/zh-cn/case-studies/chinaunicom/chinaunicom_featured_logo.png similarity index 100% rename from content/zh/case-studies/chinaunicom/chinaunicom_featured_logo.png rename to content/zh-cn/case-studies/chinaunicom/chinaunicom_featured_logo.png diff --git a/content/zh/case-studies/chinaunicom/index.html b/content/zh-cn/case-studies/chinaunicom/index.html similarity index 100% rename from content/zh/case-studies/chinaunicom/index.html rename to content/zh-cn/case-studies/chinaunicom/index.html diff --git a/content/zh/case-studies/city-of-montreal/city-of-montreal_featured_logo.png b/content/zh-cn/case-studies/city-of-montreal/city-of-montreal_featured_logo.png similarity index 100% rename from content/zh/case-studies/city-of-montreal/city-of-montreal_featured_logo.png rename to content/zh-cn/case-studies/city-of-montreal/city-of-montreal_featured_logo.png diff --git a/content/zh/case-studies/city-of-montreal/index.html b/content/zh-cn/case-studies/city-of-montreal/index.html similarity index 100% rename from content/zh/case-studies/city-of-montreal/index.html rename to content/zh-cn/case-studies/city-of-montreal/index.html diff --git a/content/zh/case-studies/crowdfire/crowdfire_featured_logo.png b/content/zh-cn/case-studies/crowdfire/crowdfire_featured_logo.png similarity index 100% rename from content/zh/case-studies/crowdfire/crowdfire_featured_logo.png rename to content/zh-cn/case-studies/crowdfire/crowdfire_featured_logo.png diff --git a/content/zh/case-studies/crowdfire/index.html b/content/zh-cn/case-studies/crowdfire/index.html similarity index 100% rename from content/zh/case-studies/crowdfire/index.html rename to content/zh-cn/case-studies/crowdfire/index.html diff --git a/content/zh/case-studies/denso/denso_featured_logo.svg b/content/zh-cn/case-studies/denso/denso_featured_logo.svg similarity index 100% rename from content/zh/case-studies/denso/denso_featured_logo.svg rename to content/zh-cn/case-studies/denso/denso_featured_logo.svg diff --git a/content/zh/case-studies/denso/index.html b/content/zh-cn/case-studies/denso/index.html similarity index 100% rename from content/zh/case-studies/denso/index.html rename to content/zh-cn/case-studies/denso/index.html diff --git a/content/zh/case-studies/golfnow/golfnow_featured.png b/content/zh-cn/case-studies/golfnow/golfnow_featured.png similarity index 100% rename from content/zh/case-studies/golfnow/golfnow_featured.png rename to content/zh-cn/case-studies/golfnow/golfnow_featured.png diff --git a/content/zh/case-studies/golfnow/golfnow_logo.png b/content/zh-cn/case-studies/golfnow/golfnow_logo.png similarity index 100% rename from content/zh/case-studies/golfnow/golfnow_logo.png rename to content/zh-cn/case-studies/golfnow/golfnow_logo.png diff --git a/content/zh/case-studies/golfnow/index.html b/content/zh-cn/case-studies/golfnow/index.html similarity index 100% rename from content/zh/case-studies/golfnow/index.html rename to content/zh-cn/case-studies/golfnow/index.html diff --git a/content/zh/case-studies/haufegroup/haufegroup_featured.png b/content/zh-cn/case-studies/haufegroup/haufegroup_featured.png similarity index 100% rename from content/zh/case-studies/haufegroup/haufegroup_featured.png rename to content/zh-cn/case-studies/haufegroup/haufegroup_featured.png diff --git a/content/zh/case-studies/haufegroup/haufegroup_logo.png b/content/zh-cn/case-studies/haufegroup/haufegroup_logo.png similarity index 100% rename from content/zh/case-studies/haufegroup/haufegroup_logo.png rename to content/zh-cn/case-studies/haufegroup/haufegroup_logo.png diff --git a/content/zh/case-studies/haufegroup/index.html b/content/zh-cn/case-studies/haufegroup/index.html similarity index 100% rename from content/zh/case-studies/haufegroup/index.html rename to content/zh-cn/case-studies/haufegroup/index.html diff --git a/content/zh/case-studies/huawei/huawei_featured.png b/content/zh-cn/case-studies/huawei/huawei_featured.png similarity index 100% rename from content/zh/case-studies/huawei/huawei_featured.png rename to content/zh-cn/case-studies/huawei/huawei_featured.png diff --git a/content/zh/case-studies/huawei/huawei_logo.png b/content/zh-cn/case-studies/huawei/huawei_logo.png similarity index 100% rename from content/zh/case-studies/huawei/huawei_logo.png rename to content/zh-cn/case-studies/huawei/huawei_logo.png diff --git a/content/zh/case-studies/huawei/index.html b/content/zh-cn/case-studies/huawei/index.html similarity index 100% rename from content/zh/case-studies/huawei/index.html rename to content/zh-cn/case-studies/huawei/index.html diff --git a/content/zh/case-studies/ibm/ibm_featured_logo.png b/content/zh-cn/case-studies/ibm/ibm_featured_logo.png similarity index 100% rename from content/zh/case-studies/ibm/ibm_featured_logo.png rename to content/zh-cn/case-studies/ibm/ibm_featured_logo.png diff --git a/content/zh/case-studies/ibm/ibm_featured_logo.svg b/content/zh-cn/case-studies/ibm/ibm_featured_logo.svg similarity index 100% rename from content/zh/case-studies/ibm/ibm_featured_logo.svg rename to content/zh-cn/case-studies/ibm/ibm_featured_logo.svg diff --git a/content/zh/case-studies/ibm/index.html b/content/zh-cn/case-studies/ibm/index.html similarity index 100% rename from content/zh/case-studies/ibm/index.html rename to content/zh-cn/case-studies/ibm/index.html diff --git a/content/zh/case-studies/ing/index.html b/content/zh-cn/case-studies/ing/index.html similarity index 100% rename from content/zh/case-studies/ing/index.html rename to content/zh-cn/case-studies/ing/index.html diff --git a/content/zh/case-studies/ing/ing_featured_logo.png b/content/zh-cn/case-studies/ing/ing_featured_logo.png similarity index 100% rename from content/zh/case-studies/ing/ing_featured_logo.png rename to content/zh-cn/case-studies/ing/ing_featured_logo.png diff --git a/content/zh/case-studies/ing/ing_featured_logo.svg b/content/zh-cn/case-studies/ing/ing_featured_logo.svg similarity index 100% rename from content/zh/case-studies/ing/ing_featured_logo.svg rename to content/zh-cn/case-studies/ing/ing_featured_logo.svg diff --git a/content/zh/case-studies/jd-com/index.html b/content/zh-cn/case-studies/jd-com/index.html similarity index 100% rename from content/zh/case-studies/jd-com/index.html rename to content/zh-cn/case-studies/jd-com/index.html diff --git a/content/zh/case-studies/jd-com/jd-com_featured_logo.png b/content/zh-cn/case-studies/jd-com/jd-com_featured_logo.png similarity index 100% rename from content/zh/case-studies/jd-com/jd-com_featured_logo.png rename to content/zh-cn/case-studies/jd-com/jd-com_featured_logo.png diff --git a/content/zh/case-studies/jd-com/jd.com_featured_logo.svg b/content/zh-cn/case-studies/jd-com/jd.com_featured_logo.svg similarity index 100% rename from content/zh/case-studies/jd-com/jd.com_featured_logo.svg rename to content/zh-cn/case-studies/jd-com/jd.com_featured_logo.svg diff --git a/content/zh/case-studies/naic/naic_featured_logo.png b/content/zh-cn/case-studies/naic/naic_featured_logo.png similarity index 100% rename from content/zh/case-studies/naic/naic_featured_logo.png rename to content/zh-cn/case-studies/naic/naic_featured_logo.png diff --git a/content/zh/case-studies/nav/nav_featured_logo.png b/content/zh-cn/case-studies/nav/nav_featured_logo.png similarity index 100% rename from content/zh/case-studies/nav/nav_featured_logo.png rename to content/zh-cn/case-studies/nav/nav_featured_logo.png diff --git a/content/zh/case-studies/nerdalize/nerdalize_featured_logo.png b/content/zh-cn/case-studies/nerdalize/nerdalize_featured_logo.png similarity index 100% rename from content/zh/case-studies/nerdalize/nerdalize_featured_logo.png rename to content/zh-cn/case-studies/nerdalize/nerdalize_featured_logo.png diff --git a/content/zh/case-studies/netease/index.html b/content/zh-cn/case-studies/netease/index.html similarity index 100% rename from content/zh/case-studies/netease/index.html rename to content/zh-cn/case-studies/netease/index.html diff --git a/content/zh/case-studies/netease/netease_featured_logo.png b/content/zh-cn/case-studies/netease/netease_featured_logo.png similarity index 100% rename from content/zh/case-studies/netease/netease_featured_logo.png rename to content/zh-cn/case-studies/netease/netease_featured_logo.png diff --git a/content/zh/case-studies/newyorktimes/newyorktimes_featured.png b/content/zh-cn/case-studies/newyorktimes/newyorktimes_featured.png similarity index 100% rename from content/zh/case-studies/newyorktimes/newyorktimes_featured.png rename to content/zh-cn/case-studies/newyorktimes/newyorktimes_featured.png diff --git a/content/zh/case-studies/newyorktimes/newyorktimes_logo.png b/content/zh-cn/case-studies/newyorktimes/newyorktimes_logo.png similarity index 100% rename from content/zh/case-studies/newyorktimes/newyorktimes_logo.png rename to content/zh-cn/case-studies/newyorktimes/newyorktimes_logo.png diff --git a/content/zh/case-studies/nokia/nokia_featured_logo.png b/content/zh-cn/case-studies/nokia/nokia_featured_logo.png similarity index 100% rename from content/zh/case-studies/nokia/nokia_featured_logo.png rename to content/zh-cn/case-studies/nokia/nokia_featured_logo.png diff --git a/content/zh/case-studies/nordstrom/index.html b/content/zh-cn/case-studies/nordstrom/index.html similarity index 100% rename from content/zh/case-studies/nordstrom/index.html rename to content/zh-cn/case-studies/nordstrom/index.html diff --git a/content/zh/case-studies/nordstrom/nordstrom_featured_logo.png b/content/zh-cn/case-studies/nordstrom/nordstrom_featured_logo.png similarity index 100% rename from content/zh/case-studies/nordstrom/nordstrom_featured_logo.png rename to content/zh-cn/case-studies/nordstrom/nordstrom_featured_logo.png diff --git a/content/zh/case-studies/northwestern-mutual/northwestern_featured_logo.png b/content/zh-cn/case-studies/northwestern-mutual/northwestern_featured_logo.png similarity index 100% rename from content/zh/case-studies/northwestern-mutual/northwestern_featured_logo.png rename to content/zh-cn/case-studies/northwestern-mutual/northwestern_featured_logo.png diff --git a/content/zh/case-studies/ocado/ocado_featured_logo.png b/content/zh-cn/case-studies/ocado/ocado_featured_logo.png similarity index 100% rename from content/zh/case-studies/ocado/ocado_featured_logo.png rename to content/zh-cn/case-studies/ocado/ocado_featured_logo.png diff --git a/content/zh/case-studies/openAI/openai_featured.png b/content/zh-cn/case-studies/openAI/openai_featured.png similarity index 100% rename from content/zh/case-studies/openAI/openai_featured.png rename to content/zh-cn/case-studies/openAI/openai_featured.png diff --git a/content/zh/case-studies/openAI/openai_logo.png b/content/zh-cn/case-studies/openAI/openai_logo.png similarity index 100% rename from content/zh/case-studies/openAI/openai_logo.png rename to content/zh-cn/case-studies/openAI/openai_logo.png diff --git a/content/zh/case-studies/peardeck/peardeck_featured.png b/content/zh-cn/case-studies/peardeck/peardeck_featured.png similarity index 100% rename from content/zh/case-studies/peardeck/peardeck_featured.png rename to content/zh-cn/case-studies/peardeck/peardeck_featured.png diff --git a/content/zh/case-studies/peardeck/peardeck_logo.png b/content/zh-cn/case-studies/peardeck/peardeck_logo.png similarity index 100% rename from content/zh/case-studies/peardeck/peardeck_logo.png rename to content/zh-cn/case-studies/peardeck/peardeck_logo.png diff --git a/content/zh/case-studies/pearson/pearson_featured.png b/content/zh-cn/case-studies/pearson/pearson_featured.png similarity index 100% rename from content/zh/case-studies/pearson/pearson_featured.png rename to content/zh-cn/case-studies/pearson/pearson_featured.png diff --git a/content/zh/case-studies/pearson/pearson_logo.png b/content/zh-cn/case-studies/pearson/pearson_logo.png similarity index 100% rename from content/zh/case-studies/pearson/pearson_logo.png rename to content/zh-cn/case-studies/pearson/pearson_logo.png diff --git a/content/zh/case-studies/pingcap/pingcap_featured_logo.png b/content/zh-cn/case-studies/pingcap/pingcap_featured_logo.png similarity index 100% rename from content/zh/case-studies/pingcap/pingcap_featured_logo.png rename to content/zh-cn/case-studies/pingcap/pingcap_featured_logo.png diff --git a/content/zh/case-studies/pinterest/pinterest_feature.png b/content/zh-cn/case-studies/pinterest/pinterest_feature.png similarity index 100% rename from content/zh/case-studies/pinterest/pinterest_feature.png rename to content/zh-cn/case-studies/pinterest/pinterest_feature.png diff --git a/content/zh/case-studies/pinterest/pinterest_logo.png b/content/zh-cn/case-studies/pinterest/pinterest_logo.png similarity index 100% rename from content/zh/case-studies/pinterest/pinterest_logo.png rename to content/zh-cn/case-studies/pinterest/pinterest_logo.png diff --git a/content/zh/case-studies/prowise/prowise_featured_logo.png b/content/zh-cn/case-studies/prowise/prowise_featured_logo.png similarity index 100% rename from content/zh/case-studies/prowise/prowise_featured_logo.png rename to content/zh-cn/case-studies/prowise/prowise_featured_logo.png diff --git a/content/zh/case-studies/ricardo-ch/ricardo-ch_featured_logo.png b/content/zh-cn/case-studies/ricardo-ch/ricardo-ch_featured_logo.png similarity index 100% rename from content/zh/case-studies/ricardo-ch/ricardo-ch_featured_logo.png rename to content/zh-cn/case-studies/ricardo-ch/ricardo-ch_featured_logo.png diff --git a/content/zh/case-studies/slamtec/slamtec_featured_logo.png b/content/zh-cn/case-studies/slamtec/slamtec_featured_logo.png similarity index 100% rename from content/zh/case-studies/slamtec/slamtec_featured_logo.png rename to content/zh-cn/case-studies/slamtec/slamtec_featured_logo.png diff --git a/content/zh/case-studies/slingtv/slingtv_featured_logo.png b/content/zh-cn/case-studies/slingtv/slingtv_featured_logo.png similarity index 100% rename from content/zh/case-studies/slingtv/slingtv_featured_logo.png rename to content/zh-cn/case-studies/slingtv/slingtv_featured_logo.png diff --git a/content/zh/case-studies/sos/sos_featured_logo.png b/content/zh-cn/case-studies/sos/sos_featured_logo.png similarity index 100% rename from content/zh/case-studies/sos/sos_featured_logo.png rename to content/zh-cn/case-studies/sos/sos_featured_logo.png diff --git a/content/zh/case-studies/spotify/spotify_featured_logo.png b/content/zh-cn/case-studies/spotify/spotify_featured_logo.png similarity index 100% rename from content/zh/case-studies/spotify/spotify_featured_logo.png rename to content/zh-cn/case-studies/spotify/spotify_featured_logo.png diff --git a/content/zh/case-studies/squarespace/index.html b/content/zh-cn/case-studies/squarespace/index.html similarity index 100% rename from content/zh/case-studies/squarespace/index.html rename to content/zh-cn/case-studies/squarespace/index.html diff --git a/content/zh/case-studies/squarespace/squarespace_featured_logo.png b/content/zh-cn/case-studies/squarespace/squarespace_featured_logo.png similarity index 100% rename from content/zh/case-studies/squarespace/squarespace_featured_logo.png rename to content/zh-cn/case-studies/squarespace/squarespace_featured_logo.png diff --git a/content/zh/case-studies/squarespace/squarespace_featured_logo.svg b/content/zh-cn/case-studies/squarespace/squarespace_featured_logo.svg similarity index 100% rename from content/zh/case-studies/squarespace/squarespace_featured_logo.svg rename to content/zh-cn/case-studies/squarespace/squarespace_featured_logo.svg diff --git a/content/zh/case-studies/thredup/thredup_featured_logo.png b/content/zh-cn/case-studies/thredup/thredup_featured_logo.png similarity index 100% rename from content/zh/case-studies/thredup/thredup_featured_logo.png rename to content/zh-cn/case-studies/thredup/thredup_featured_logo.png diff --git a/content/zh/case-studies/vsco/vsco_featured_logo.png b/content/zh-cn/case-studies/vsco/vsco_featured_logo.png similarity index 100% rename from content/zh/case-studies/vsco/vsco_featured_logo.png rename to content/zh-cn/case-studies/vsco/vsco_featured_logo.png diff --git a/content/zh-cn/case-studies/wikimedia/index.html b/content/zh-cn/case-studies/wikimedia/index.html new file mode 100644 index 0000000000..8800c5f19e --- /dev/null +++ b/content/zh-cn/case-studies/wikimedia/index.html @@ -0,0 +1,148 @@ +--- +title: 案例研究：Wikimedia +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 + - 地点: 加州旧金山 +--- + + + +

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

    + + +{{< case-studies/quote author="Yuvi Panda, Wikimedia 基金会和 Wikimedia 工具实验室的运维工程师">}} + +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.png b/content/zh-cn/case-studies/wikimedia/wikimedia_featured.png similarity index 100% rename from content/zh/case-studies/wikimedia/wikimedia_featured.png rename to content/zh-cn/case-studies/wikimedia/wikimedia_featured.png diff --git a/content/zh-cn/case-studies/wikimedia/wikimedia_featured.svg b/content/zh-cn/case-studies/wikimedia/wikimedia_featured.svg new file mode 100644 index 0000000000..5fa786aaa5 --- /dev/null +++ b/content/zh-cn/case-studies/wikimedia/wikimedia_featured.svg @@ -0,0 +1 @@ +kubernetes.io-logos2 \ No newline at end of file diff --git a/content/zh/case-studies/wikimedia/wikimedia_logo.png b/content/zh-cn/case-studies/wikimedia/wikimedia_logo.png similarity index 100% rename from content/zh/case-studies/wikimedia/wikimedia_logo.png rename to content/zh-cn/case-studies/wikimedia/wikimedia_logo.png diff --git a/content/zh/case-studies/wink/index.html b/content/zh-cn/case-studies/wink/index.html similarity index 100% rename from content/zh/case-studies/wink/index.html rename to content/zh-cn/case-studies/wink/index.html diff --git a/content/zh/case-studies/wink/wink_featured.png b/content/zh-cn/case-studies/wink/wink_featured.png similarity index 100% rename from content/zh/case-studies/wink/wink_featured.png rename to content/zh-cn/case-studies/wink/wink_featured.png diff --git a/content/zh/case-studies/wink/wink_logo.png b/content/zh-cn/case-studies/wink/wink_logo.png similarity index 100% rename from content/zh/case-studies/wink/wink_logo.png rename to content/zh-cn/case-studies/wink/wink_logo.png diff --git a/content/zh/case-studies/woorank/woorank_featured_logo.png b/content/zh-cn/case-studies/woorank/woorank_featured_logo.png similarity index 100% rename from content/zh/case-studies/woorank/woorank_featured_logo.png rename to content/zh-cn/case-studies/woorank/woorank_featured_logo.png diff --git a/content/zh/case-studies/workiva/index.html b/content/zh-cn/case-studies/workiva/index.html similarity index 100% rename from content/zh/case-studies/workiva/index.html rename to content/zh-cn/case-studies/workiva/index.html diff --git a/content/zh/case-studies/workiva/workiva_featured_logo.png b/content/zh-cn/case-studies/workiva/workiva_featured_logo.png similarity index 100% rename from content/zh/case-studies/workiva/workiva_featured_logo.png rename to content/zh-cn/case-studies/workiva/workiva_featured_logo.png diff --git a/content/zh/case-studies/yahoo-japan/index.html b/content/zh-cn/case-studies/yahoo-japan/index.html similarity index 100% rename from content/zh/case-studies/yahoo-japan/index.html rename to content/zh-cn/case-studies/yahoo-japan/index.html diff --git a/content/zh/case-studies/yahoo-japan/yahooJapan_logo.png b/content/zh-cn/case-studies/yahoo-japan/yahooJapan_logo.png similarity index 100% rename from content/zh/case-studies/yahoo-japan/yahooJapan_logo.png rename to content/zh-cn/case-studies/yahoo-japan/yahooJapan_logo.png diff --git a/content/zh/case-studies/ygrene/index.html b/content/zh-cn/case-studies/ygrene/index.html similarity index 100% rename from content/zh/case-studies/ygrene/index.html rename to content/zh-cn/case-studies/ygrene/index.html diff --git a/content/zh/case-studies/ygrene/ygrene_featured_logo.png b/content/zh-cn/case-studies/ygrene/ygrene_featured_logo.png similarity index 100% rename from content/zh/case-studies/ygrene/ygrene_featured_logo.png rename to content/zh-cn/case-studies/ygrene/ygrene_featured_logo.png diff --git a/content/zh/case-studies/zalando/index.html b/content/zh-cn/case-studies/zalando/index.html similarity index 100% rename from content/zh/case-studies/zalando/index.html rename to content/zh-cn/case-studies/zalando/index.html diff --git a/content/zh/case-studies/zalando/zalando_feature_logo.png b/content/zh-cn/case-studies/zalando/zalando_feature_logo.png similarity index 100% rename from content/zh/case-studies/zalando/zalando_feature_logo.png rename to content/zh-cn/case-studies/zalando/zalando_feature_logo.png diff --git a/content/zh/community/_index.html b/content/zh-cn/community/_index.html similarity index 100% rename from content/zh/community/_index.html rename to content/zh-cn/community/_index.html diff --git a/content/zh/community/code-of-conduct.md b/content/zh-cn/community/code-of-conduct.md similarity index 100% rename from content/zh/community/code-of-conduct.md rename to content/zh-cn/community/code-of-conduct.md diff --git a/content/zh/community/static/README.md b/content/zh-cn/community/static/README.md similarity index 100% rename from content/zh/community/static/README.md rename to content/zh-cn/community/static/README.md diff --git a/content/zh/community/static/cncf-code-of-conduct.md b/content/zh-cn/community/static/cncf-code-of-conduct.md similarity index 100% rename from content/zh/community/static/cncf-code-of-conduct.md rename to content/zh-cn/community/static/cncf-code-of-conduct.md diff --git a/content/zh/docs/_index.md b/content/zh-cn/docs/_index.md similarity index 100% rename from content/zh/docs/_index.md rename to content/zh-cn/docs/_index.md diff --git a/content/zh/docs/concepts/_index.md b/content/zh-cn/docs/concepts/_index.md similarity index 100% rename from content/zh/docs/concepts/_index.md rename to content/zh-cn/docs/concepts/_index.md diff --git a/content/zh/docs/concepts/architecture/_index.md b/content/zh-cn/docs/concepts/architecture/_index.md similarity index 100% rename from content/zh/docs/concepts/architecture/_index.md rename to content/zh-cn/docs/concepts/architecture/_index.md diff --git a/content/zh/docs/concepts/architecture/cloud-controller.md b/content/zh-cn/docs/concepts/architecture/cloud-controller.md similarity index 100% rename from content/zh/docs/concepts/architecture/cloud-controller.md rename to content/zh-cn/docs/concepts/architecture/cloud-controller.md diff --git a/content/zh/docs/concepts/architecture/control-plane-node-communication.md b/content/zh-cn/docs/concepts/architecture/control-plane-node-communication.md similarity index 86% rename from content/zh/docs/concepts/architecture/control-plane-node-communication.md rename to content/zh-cn/docs/concepts/architecture/control-plane-node-communication.md index 8cf742e272..8a92d69f2e 100644 --- a/content/zh/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/zh-cn/docs/concepts/architecture/control-plane-node-communication.md @@ -24,7 +24,7 @@ This document catalogs the communication paths between the control plane (apiser ## 节点到控制面 @@ -39,11 +39,11 @@ API 服务器被配置为在一个安全的 HTTPS 端口（通常为 443）上 或[服务账号令牌](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。 应该使用集群的公共根证书开通节点，这样它们就能够基于有效的客户端凭据安全地连接 API 服务器。 一种好的方法是以客户端证书的形式将客户端凭据提供给 kubelet。 -请查看 [kubelet TLS 启动引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) +请查看 [kubelet TLS 启动引导](/zh/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) 以了解如何自动提供 kubelet 客户端证书。 为了对这个连接进行认证，使用 `--kubelet-certificate-authority` 标志给 API 服务器提供一个根证书包，用于 kubelet 的服务证书。 @@ -114,13 +114,13 @@ Finally, [Kubelet authentication and/or authorization](/docs/reference/command-l kubelet 之间使用 [SSH 隧道](#ssh-tunnels)。 最后，应该启用 -[kubelet 用户认证和/或鉴权](/zh/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) +[kubelet 用户认证和/或鉴权](/zh/docs/reference/access-authn-authz/kubelet-authn-authz/) 来保护 kubelet API。 ### API 服务器到节点、Pod 和服务 @@ -136,7 +136,7 @@ The connections from the apiserver to a node, pod, or service default to plain H Kubernetes supports SSH tunnels to protect the control plane to nodes communication paths. In this configuration, the apiserver initiates an SSH tunnel to each node in the cluster (connecting to the ssh server listening on port 22) and passes all traffic destined for a kubelet, node, pod, or service through the tunnel. This tunnel ensures that the traffic is not exposed outside of the network in which the nodes are running. -SSH tunnels are currently deprecated so you shouldn't opt to use them unless you know what you are doing. The Konnectivity service is a replacement for this communication channel. +SSH tunnels are currently deprecated, so you shouldn't opt to use them unless you know what you are doing. The Konnectivity service is a replacement for this communication channel. --> ### SSH 隧道 {#ssh-tunnels} diff --git a/content/zh/docs/concepts/architecture/controller.md b/content/zh-cn/docs/concepts/architecture/controller.md similarity index 100% rename from content/zh/docs/concepts/architecture/controller.md rename to content/zh-cn/docs/concepts/architecture/controller.md diff --git a/content/zh/docs/concepts/architecture/cri.md b/content/zh-cn/docs/concepts/architecture/cri.md similarity index 100% rename from content/zh/docs/concepts/architecture/cri.md rename to content/zh-cn/docs/concepts/architecture/cri.md diff --git a/content/zh/docs/concepts/architecture/garbage-collection.md b/content/zh-cn/docs/concepts/architecture/garbage-collection.md similarity index 100% rename from content/zh/docs/concepts/architecture/garbage-collection.md rename to content/zh-cn/docs/concepts/architecture/garbage-collection.md diff --git a/content/zh/docs/concepts/architecture/nodes.md b/content/zh-cn/docs/concepts/architecture/nodes.md similarity index 100% rename from content/zh/docs/concepts/architecture/nodes.md rename to content/zh-cn/docs/concepts/architecture/nodes.md diff --git a/content/zh/docs/concepts/cluster-administration/_index.md b/content/zh-cn/docs/concepts/cluster-administration/_index.md similarity index 96% rename from content/zh/docs/concepts/cluster-administration/_index.md rename to content/zh-cn/docs/concepts/cluster-administration/_index.md index e1e929cfa6..d37c50dcad 100644 --- a/content/zh/docs/concepts/cluster-administration/_index.md +++ b/content/zh-cn/docs/concepts/cluster-administration/_index.md @@ -123,14 +123,14 @@ Before choosing a guide, here are some considerations: ### Securing the kubelet * [Master-Node communication](/docs/concepts/architecture/master-node-communication/) -* [TLS bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) +* [TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) * [Kubelet authentication/authorization](/docs/admin/kubelet-authentication-authorization/) --> ### 保护 kubelet {#securing-the-kubelet} * [主控节点通信](/zh/docs/concepts/architecture/control-plane-node-communication/) -* [TLS 引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) -* [Kubelet 认证/授权](/zh/docs/reference/command-line-tools-reference/kubelet-authentication-authorization/) +* [TLS 引导](/zh/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) +* [Kubelet 认证/授权](/zh/docs/reference/access-authn-authz/kubelet-authn-authz/) ## 网络和网络策略 @@ -54,7 +54,7 @@ Add-ons 扩展了 Kubernetes 的功能。 * [Cilium](https://github.com/cilium/cilium) 是一个 L3 网络和网络策略插件，能够透明的实施 HTTP/API/L7 策略。 同时支持路由（routing）和覆盖/封装（overlay/encapsulation）模式。 * [CNI-Genie](https://github.com/Huawei-PaaS/CNI-Genie) 使 Kubernetes 无缝连接到一种 CNI 插件， - 例如：Flannel、Calico、Canal、Romana 或者 Weave。 + 例如：Flannel、Calico、Canal 或者 Weave。 * [Contiv](https://contivpp.io/) 为各种用例和丰富的策略框架提供可配置的网络 （使用 BGP 的本机 L3、使用 vxlan 的覆盖、标准 L2 和 Cisco-SDN/ACI）。 Contiv 项目完全[开源](https://github.com/contiv)。 @@ -84,9 +84,8 @@ Add-ons 扩展了 Kubernetes 的功能。 CaaS / PaaS 平台（例如关键容器服务（PKS）和 OpenShift）之间的集成。 * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) 是一个 SDN 平台，可在 Kubernetes Pods 和非 Kubernetes 环境之间提供基于策略的联网，并具有可视化和安全监控。 -* Romana 是一个 pod 网络的第三层解决方案，并支持 - [NetworkPolicy API](/zh/docs/concepts/services-networking/network-policies/)。 - Kubeadm add-on 安装细节可以在[这里](https://github.com/romana/romana/tree/master/containerize)找到。 +* [Romana](https://github.com/romana) 是一个 Pod 网络的第三层解决方案，并支持 + [NetworkPolicy](/zh-cn/docs/concepts/services-networking/network-policies/) API。 * [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) 提供在网络分组两端参与工作的网络和网络策略，并且不需要额外的数据库。 @@ -129,7 +128,7 @@ Add-ons 扩展了 Kubernetes 的功能。 运行虚拟机的 add-ons。通常运行在裸机集群上。 * [节点问题检测器](https://github.com/kubernetes/node-problem-detector) 在 Linux 节点上运行， 并将系统问题报告为[事件](/docs/reference/kubernetes-api/cluster-resources/event-v1/) - 或[节点状况](/zh/docs/concepts/architecture/nodes/#condition)。 + 或[节点状况](/zh-cn/docs/concepts/architecture/nodes/#condition)。 @@ -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/cluster-administration/proxies.md b/content/zh-cn/docs/concepts/cluster-administration/proxies.md similarity index 100% rename from content/zh/docs/concepts/cluster-administration/proxies.md rename to content/zh-cn/docs/concepts/cluster-administration/proxies.md diff --git a/content/zh/docs/concepts/cluster-administration/system-logs.md b/content/zh-cn/docs/concepts/cluster-administration/system-logs.md similarity index 100% rename from content/zh/docs/concepts/cluster-administration/system-logs.md rename to content/zh-cn/docs/concepts/cluster-administration/system-logs.md diff --git a/content/zh/docs/concepts/cluster-administration/system-metrics.md b/content/zh-cn/docs/concepts/cluster-administration/system-metrics.md similarity index 100% rename from content/zh/docs/concepts/cluster-administration/system-metrics.md rename to content/zh-cn/docs/concepts/cluster-administration/system-metrics.md diff --git a/content/zh/docs/concepts/cluster-administration/system-traces.md b/content/zh-cn/docs/concepts/cluster-administration/system-traces.md similarity index 100% rename from content/zh/docs/concepts/cluster-administration/system-traces.md rename to content/zh-cn/docs/concepts/cluster-administration/system-traces.md diff --git a/content/zh/docs/concepts/configuration/_index.md b/content/zh-cn/docs/concepts/configuration/_index.md similarity index 100% rename from content/zh/docs/concepts/configuration/_index.md rename to content/zh-cn/docs/concepts/configuration/_index.md diff --git a/content/zh/docs/concepts/configuration/configmap.md b/content/zh-cn/docs/concepts/configuration/configmap.md similarity index 100% rename from content/zh/docs/concepts/configuration/configmap.md rename to content/zh-cn/docs/concepts/configuration/configmap.md diff --git a/content/zh/docs/concepts/configuration/manage-resources-containers.md b/content/zh-cn/docs/concepts/configuration/manage-resources-containers.md similarity index 100% rename from content/zh/docs/concepts/configuration/manage-resources-containers.md rename to content/zh-cn/docs/concepts/configuration/manage-resources-containers.md diff --git a/content/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig.md similarity index 100% rename from content/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig.md rename to content/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig.md diff --git a/content/zh/docs/concepts/configuration/overview.md b/content/zh-cn/docs/concepts/configuration/overview.md similarity index 100% rename from content/zh/docs/concepts/configuration/overview.md rename to content/zh-cn/docs/concepts/configuration/overview.md diff --git a/content/zh/docs/concepts/configuration/secret.md b/content/zh-cn/docs/concepts/configuration/secret.md similarity index 91% rename from content/zh/docs/concepts/configuration/secret.md rename to content/zh-cn/docs/concepts/configuration/secret.md index 917d318703..c4dc8fb7fe 100644 --- a/content/zh/docs/concepts/configuration/secret.md +++ b/content/zh-cn/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 值； 例如： @@ -443,11 +447,15 @@ 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. --> 你仍然可以[手动创建](/zh/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token) 服务账号令牌。例如，当你需要一个永远都不过期的令牌时。 不过，仍然建议使用 [TokenRequest](/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) 子资源来获得访问 API 服务器的令牌。 +你可以使用 [`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-) +命令调用 `TokenRequest` API 获得令牌。 {{< /note >}} -#### 将 Secret 键投射到特定目录 +#### 将 Secret 键投射到特定目录 {#projection-of-secret-keys-to-specific-paths} 你也可以控制 Secret 键所投射到的卷中的路径。 你可以使用 `.spec.volumes[].secret.items` 字段来更改每个主键的目标路径： @@ -517,7 +525,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 +790,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 +870,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 +884,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 +899,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 +927,7 @@ Create a secret --> ## 使用场景 {#use-case} -### 使用场景：作为容器环境变量 +### 使用场景：作为容器环境变量 {#use-case-as-container-environment-variables} 创建 Secret： @@ -970,7 +978,7 @@ spec: Create a Secret containing some SSH keys: --> -### 使用场景：带 SSH 密钥的 Pod +### 使用场景：带 SSH 密钥的 Pod {#use-case-pod-with-ssh-keys} 创建包含一些 SSH 密钥的 Secret： @@ -1061,7 +1069,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 +1255,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 +1316,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 +1349,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 +1363,10 @@ Kubernetes 提供若干种内置的类型，用于一些常见的使用场景。 针对这些类型，Kubernetes 所执行的合法性检查操作以及对其所实施的限制各不相同。 通过为 Secret 对象的 `type` 字段设置一个非空的字符串值，你也可以定义并使用自己 -Secret 类型。如果 `type` 值为空字符串，则被视为 `Opaque` 类型。 +Secret 类型（如果 `type` 值为空字符串，则被视为 `Opaque` 类型）。 Kubernetes 并不对类型的名称作任何限制。不过，如果你要使用内置类型之一， @@ -1433,35 +1441,70 @@ empty-secret Opaque 0 2m6s `DATA` 列显示 Secret 中保存的数据条目个数。 -在这个例子种，`0` 意味着我们刚刚创建了一个空的 Secret。 +在这个例子种，`0` 意味着你刚刚创建了一个空的 Secret。 ### 服务账号令牌 Secret {#service-account-token-secrets} -类型为 `kubernetes.io/service-account-token` 的 Secret 用来存放标识某 -{{< glossary_tooltip text="服务账号" term_id="service-account" >}}的令牌。 +类型为 `kubernetes.io/service-account-token` 的 Secret +用来存放标识某{{< glossary_tooltip text="服务账号" term_id="service-account" >}}的令牌凭据。 + + +从 v1.22 开始，这种类型的 Secret 不再被用来向 Pod 中加载凭据数据， +建议通过 [TokenRequest](/zh-cn/docs/reference/kubernetes-api/authentication-resources/token-request-v1/) +API 来获得令牌，而不是使用服务账号令牌 Secret 对象。 +通过 `TokenRequest` API 获得的令牌比保存在 Secret 对象中的令牌更加安全， +因为这些令牌有着被限定的生命期，并且不会被其他 API 客户端读取。 +你可以使用 [`kubectl create token`](/docs/reference/generated/kubectl/kubectl-commands#-em-token-em-) +命令调用 `TokenRequest` API 获得令牌。 + + +只有在你无法使用 `TokenRequest` API 来获取令牌， +并且你能够接受因为将永不过期的令牌凭据写入到可读取的 API 对象而带来的安全风险时， +才应该创建服务账号令牌 Secret 对象。 + + 使用这种 Secret 类型时，你需要确保对象的注解 `kubernetes.io/service-account-name` -被设置为某个已有的服务账号名称。某个 Kubernetes -{{< glossary_tooltip text="控制器" term_id="controller" >}}会填写 Secret -的其它字段，例如 `kubernetes.io/service-account.uid` 注解以及 `data` 字段中的 +被设置为某个已有的服务账号名称。 +如果你同时负责 ServiceAccount 和 Secret 对象的创建，应该先创建 ServiceAccount 对象。 + + +当 Secret 对象被创建之后，某个 Kubernetes{{< glossary_tooltip text="控制器" term_id="controller" >}}会填写 +Secret 的其它字段，例如 `kubernetes.io/service-account.uid` 注解以及 `data` 字段中的 `token` 键值，使之包含实际的令牌内容。 下面的配置实例声明了一个服务账号令牌 Secret： @@ -1494,45 +1537,33 @@ data: ``` -Kubernetes 在创建 Pod 时会自动创建一个服务账号 Secret 并自动修改你的 Pod -以使用该 Secret。该服务账号令牌 Secret 中包含了访问 Kubernetes API -所需要的凭据。 - -如果需要，可以禁止或者重载这种自动创建并使用 API 凭据的操作。 -不过，如果你仅仅是希望能够安全地访问 API 服务器，这是建议的工作方式。 +创建了 Secret 之后，等待 Kubernetes 在 `data` 字段中填充 `token` 主键。 参考 [ServiceAccount](/zh/docs/tasks/configure-pod-container/configure-service-account/) 文档了解服务账号的工作原理。你也可以查看 [`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) 资源中的 `automountServiceAccountToken` 和 `serviceAccountName` 字段文档， -进一步了解从 Pod 中引用服务账号。 +进一步了解从 Pod 中引用服务账号凭据。 ### Docker 配置 Secret {#docker-config-secrets} -你可以使用下面两种 `type` 值之一来创建 Secret，用以存放访问 Docker 仓库 -来下载镜像的凭据。 +你可以使用下面两种 `type` 值之一来创建 Secret，用以存放用于访问容器鏡像倉庫的凭据： - `kubernetes.io/dockercfg` - `kubernetes.io/dockerconfigjson` @@ -1550,7 +1581,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 +1687,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 +1705,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 +1718,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 +1935,11 @@ data: ``` -## Secret 的信息安全问题 +## Secret 的信息安全问题 {#information-security-for-secrets} 尽管 ConfigMap 和 Secret 的工作方式类似，但 Kubernetes 对 Secret 有一些额外的保护。 @@ -2096,7 +2141,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 +2162,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 +2179,7 @@ on that node. -### 针对集群管理员的安全性建议 +### 针对集群管理员的安全性建议 {#security-recommendations-for-cluster-administrators} {{< caution >}} - 保留（使用 Kubernetes API）对集群中所有 Secret 对象执行 `watch` 或 `list` 操作的能力， 这样只有特权级最高、系统级别的组件能够执行这类操作。 @@ -2185,9 +2230,9 @@ Pod 来访问 Secret 的内容。 ## {{% heading "whatsnext" %}} - 学习如何[使用 `kubectl` 管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl/) diff --git a/content/zh-cn/docs/concepts/configuration/windows-resource-management.md b/content/zh-cn/docs/concepts/configuration/windows-resource-management.md new file mode 100644 index 0000000000..a34682f5ae --- /dev/null +++ b/content/zh-cn/docs/concepts/configuration/windows-resource-management.md @@ -0,0 +1,134 @@ +--- +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）而终止进程。 +如果内存配置过量且所有物理内存都已耗尽，则换页性能就会降低。 + +## CPU 管理 {#resource-management-cpu} + +Windows 可以限制为不同进程分配的 CPU 时间长度，但无法保证最小的 CPU 时间长度。 + +在 Windows 上，kubelet 支持使用命令行标志来设置 kubelet 进程的[调度优先级](https://docs.microsoft.com/zh-cn/windows/win32/procthread/scheduling-priorities)： +`--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` 或更高。 + + +## 资源预留 {#resource-reservation} + +为了满足操作系统、容器运行时和 kubelet 等 Kubernetes 主机进程使用的内存和 CPU， +你可以（且应该）用 `--kube-reserved` 和/或 `--system-reserved` kubelet 标志来预留内存和 CPU 资源。 +在 Windows 上，这些值仅用于计算节点的[可分配](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)资源。 + + +{{< caution >}} +在你部署工作负载时，需对容器设置内存和 CPU 资源的限制。 +这也会从 `NodeAllocatable` 中减去，帮助集群范围的调度器决定哪些 Pod 放到哪些节点上。 + +若调度 Pod 时未设置限制值，可能对 Windows 节点过量配置资源。 +在极端情况下，这会让节点变得不健康。 +{{< /caution >}} + + +在 Windows 上，一种好的做法是预留至少 2GiB 的内存。 + +要决定预留多少 CPU，需明确每个节点的最大 Pod 密度， +并监控节点上运行的系统服务的 CPU 使用率，然后选择一个满足工作负载需求的值。 diff --git a/content/zh/docs/concepts/containers/_index.md b/content/zh-cn/docs/concepts/containers/_index.md similarity index 100% rename from content/zh/docs/concepts/containers/_index.md rename to content/zh-cn/docs/concepts/containers/_index.md diff --git a/content/zh/docs/concepts/containers/container-environment.md b/content/zh-cn/docs/concepts/containers/container-environment.md similarity index 100% rename from content/zh/docs/concepts/containers/container-environment.md rename to content/zh-cn/docs/concepts/containers/container-environment.md diff --git a/content/zh/docs/concepts/containers/container-lifecycle-hooks.md b/content/zh-cn/docs/concepts/containers/container-lifecycle-hooks.md similarity index 100% rename from content/zh/docs/concepts/containers/container-lifecycle-hooks.md rename to content/zh-cn/docs/concepts/containers/container-lifecycle-hooks.md diff --git a/content/zh/docs/concepts/containers/images.md b/content/zh-cn/docs/concepts/containers/images.md similarity index 100% rename from content/zh/docs/concepts/containers/images.md rename to content/zh-cn/docs/concepts/containers/images.md diff --git a/content/zh/docs/concepts/containers/runtime-class.md b/content/zh-cn/docs/concepts/containers/runtime-class.md similarity index 100% rename from content/zh/docs/concepts/containers/runtime-class.md rename to content/zh-cn/docs/concepts/containers/runtime-class.md diff --git a/content/zh/docs/concepts/extend-kubernetes/_index.md b/content/zh-cn/docs/concepts/extend-kubernetes/_index.md similarity index 100% rename from content/zh/docs/concepts/extend-kubernetes/_index.md rename to content/zh-cn/docs/concepts/extend-kubernetes/_index.md diff --git a/content/zh/docs/concepts/extend-kubernetes/api-extension/_index.md b/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/_index.md similarity index 100% rename from content/zh/docs/concepts/extend-kubernetes/api-extension/_index.md rename to content/zh-cn/docs/concepts/extend-kubernetes/api-extension/_index.md diff --git a/content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md similarity index 100% rename from content/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md rename to content/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md diff --git a/content/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources.md similarity index 100% rename from content/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources.md rename to content/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources.md diff --git a/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/_index.md b/content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/_index.md similarity index 100% rename from content/zh/docs/concepts/extend-kubernetes/compute-storage-net/_index.md rename to content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/_index.md diff --git a/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md similarity index 100% rename from content/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md rename to content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md diff --git a/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md b/content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md similarity index 54% rename from content/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md rename to content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md index ab63e7eb85..fea8c05193 100644 --- a/content/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md +++ b/content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins.md @@ -20,6 +20,11 @@ Kubernetes {{< skew currentVersion >}} 支持[容器网络接口](https://github 你必须使用和你的集群相兼容并且满足你的需求的 CNI 插件。 在更广泛的 Kubernetes 生态系统中你可以使用不同的插件（开源和闭源）。 + +要实现 [Kubernetes 网络模型](/zh-cn/docs/concepts/services-networking/#the-kubernetes-network-model)，你需要一个 CNI 插件。 + -## 安装 +## 安装 {#installation} -CNI 插件需要实现 [Kubernetes 网络模型](/zh/docs/concepts/services-networking/#the-kubernetes-network-model)。 -CRI 管理它自己的 CNI 插件。 -在使用插件时，需要记住两个 kubelet 命令行参数： +在网络语境中，容器运行时（Container Runtime）是在节点上的守护进程， +被配置用来为 kubelet 提供 CRI 服务。具体而言，容器运行时必须配置为加载所需的 +CNI 插件，从而实现 Kubernetes 网络模型。 -* `cni-bin-dir`： kubelet 在启动时探测这个目录中的插件 -* `network-plugin`： 要使用的网络插件来自 `cni-bin-dir`。 - 它必须与从插件目录探测到的插件报告的名称匹配。 - 对于 CNI 插件，其值为 "cni"。 +{{< note >}} + +在 Kubernetes 1.24 之前，CNI 插件也可以由 kubelet 使用命令行参数 `cni-bin-dir` +和 `network-plugin` 管理。Kubernetes 1.24 移除了这些命令行参数， +CNI 的管理不再是 kubelet 的工作。 + + +如果你在移除 dockershim 之后遇到问题，请参阅[排查 CNI 插件相关的错误](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/troubleshooting-cni-plugin-related-errors/)。 +{{< /note >}} + + +要了解容器运行时如何管理 CNI 插件的具体信息，可参见对应容器运行时的文档，例如： + +- [containerd](https://github.com/containerd/containerd/blob/main/script/setup/install-cni) +- [CRI-O](https://github.com/cri-o/cri-o/blob/main/contrib/cni/README.md) + + +要了解如何安装和管理 CNI 插件的具体信息，可参阅对应的插件或 +[网络驱动（Networking Provider）](/zh-cn/docs/concepts/cluster-administration/networking/#how-to-implement-the-kubernetes-networking-model) +的文档。 -## 网络插件要求 +## 网络插件要求 {#network-plugin-requirements} -除了提供 -[`NetworkPlugin` 接口](https://github.com/kubernetes/kubernetes/tree/{{< param "fullversion" >}}/pkg/kubelet/dockershim/network/plugins.go) -来配置和清理 Pod 网络之外，该插件还可能需要对 kube-proxy 的特定支持。 -iptables 代理显然依赖于 iptables，插件可能需要确保 iptables 能够监控容器的网络通信。 +对于插件开发人员以及时常会构建并部署 Kubernetes 的用户而言， +插件可能也需要特定的配置来支持 kube-proxy。 +iptables 代理依赖于 iptables，插件可能需要确保 iptables 能够监控容器的网络通信。 例如，如果插件将容器连接到 Linux 网桥，插件必须将 `net/bridge/bridge-nf-call-iptables` -系统参数设置为`1`，以确保 iptables 代理正常工作。 +sysctl 参数设置为 `1`，以确保 iptables 代理正常工作。 如果插件不使用 Linux 网桥（而是类似于 Open vSwitch 或者其它一些机制）， 它应该确保为代理对容器通信执行正确的路由。 + + 默认情况下，如果未指定 kubelet 网络插件，则使用 `noop` 插件， 该插件设置 `net/bridge/bridge-nf-call-iptables=1`，以确保简单的配置 （如带网桥的 Docker ）与 iptables 代理正常工作。 -### CNI +### 本地回路 CNI {#loopback-cni} -通过给 Kubelet 传递 `--network-plugin=cni` 命令行选项可以选择 CNI 插件。 -Kubelet 从 `--cni-conf-dir` （默认是 `/etc/cni/net.d`） 读取文件并使用 -该文件中的 CNI 配置来设置各个 Pod 的网络。 -CNI 配置文件必须与 -[CNI 规约](https://github.com/containernetworking/cni/blob/master/SPEC.md#network-configuration) -匹配，并且配置所引用的所有所需的 CNI 插件都应存在于 -`--cni-bin-dir`（默认是 `/opt/cni/bin`）下。 - -如果这个目录中有多个 CNI 配置文件，kubelet 将会使用按文件名的字典顺序排列 -的第一个作为配置文件。 - -除了配置文件指定的 CNI 插件外，Kubernetes 还需要标准的 CNI -[`lo`](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go) -插件，最低版本是0.2.0。 +除了安装到节点上用于实现 Kubernetes 网络模型的 CNI 插件外，Kubernetes +还需要容器运行时提供一个本地回路接口 `lo`，用于各个沙箱（Pod 沙箱、虚机沙箱……）。 +实现本地回路接口的工作可以通过复用 +[CNI 本地回路插件](https://github.com/containernetworking/plugins/blob/master/plugins/main/loopback/loopback.go)来实现， +也可以通过开发自己的代码来实现 +（参阅 [CRI-O 中的示例](https://github.com/cri-o/ocicni/blob/release-1.24/pkg/ocicni/util_linux.go#L91)）。 -#### 支持 hostPort +### 支持 hostPort {#support-hostport} CNI 网络插件支持 `hostPort`。 你可以使用官方 [portmap](https://github.com/containernetworking/plugins/tree/master/plugins/meta/portmap) @@ -149,7 +170,7 @@ CNI 网络插件支持 `hostPort`。 你可以使用官方 ``` -#### 支持流量整形 +### 支持流量整形 {#support-traffic-shaping} **实验功能** @@ -216,16 +237,6 @@ metadata: kubernetes.io/egress-bandwidth: 1M ... ``` - -## 用法总结 - -* `--network-plugin=cni` 用来表明我们要使用 `cni` 网络插件，实际的 CNI 插件 - 可执行文件位于 `--cni-bin-dir`（默认是 `/opt/cni/bin`）下， CNI 插件配置位于 - `--cni-conf-dir`（默认是 `/etc/cni/net.d`）下。 ## {{% heading "whatsnext" %}} diff --git a/content/zh/docs/concepts/extend-kubernetes/operator.md b/content/zh-cn/docs/concepts/extend-kubernetes/operator.md similarity index 98% rename from content/zh/docs/concepts/extend-kubernetes/operator.md rename to content/zh-cn/docs/concepts/extend-kubernetes/operator.md index c9734f4798..7dd8e6fbd3 100644 --- a/content/zh/docs/concepts/extend-kubernetes/operator.md +++ b/content/zh-cn/docs/concepts/extend-kubernetes/operator.md @@ -212,6 +212,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/) (dotnet operator SDK) @@ -226,6 +227,7 @@ you implement yourself {{% 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/) (dotnet operator SDK) diff --git a/content/zh/docs/concepts/extend-kubernetes/service-catalog.md b/content/zh-cn/docs/concepts/extend-kubernetes/service-catalog.md similarity index 100% rename from content/zh/docs/concepts/extend-kubernetes/service-catalog.md rename to content/zh-cn/docs/concepts/extend-kubernetes/service-catalog.md diff --git a/content/zh/docs/concepts/overview/_index.md b/content/zh-cn/docs/concepts/overview/_index.md similarity index 100% rename from content/zh/docs/concepts/overview/_index.md rename to content/zh-cn/docs/concepts/overview/_index.md diff --git a/content/zh/docs/concepts/overview/components.md b/content/zh-cn/docs/concepts/overview/components.md similarity index 88% rename from content/zh/docs/concepts/overview/components.md rename to content/zh-cn/docs/concepts/overview/components.md index cb88373eb7..902edf5cd3 100644 --- a/content/zh/docs/concepts/overview/components.md +++ b/content/zh-cn/docs/concepts/overview/components.md @@ -33,10 +33,10 @@ a complete and working Kubernetes cluster. --> -当你部署完 Kubernetes，即拥有了一个完整的集群。 +当你部署完 Kubernetes，便拥有了一个完整的集群。 {{< glossary_definition term_id="cluster" length="all" prepend="一个 Kubernetes">}} -本文档概述了交付正常运行的 Kubernetes 集群所需的各种组件。 +本文档概述了一个正常运行的 Kubernetes 集群所需的各种组件。 {{< figure src="/images/docs/components-of-kubernetes.svg" alt="Kubernetes 的组件" caption="Kubernetes 集群的组件" class="diagram-large" >}} @@ -49,8 +49,9 @@ The control plane's components make global decisions about the cluster (for exam --> ## 控制平面组件（Control Plane Components） {#control-plane-components} -控制平面的组件对集群做出全局决策（比如调度），以及检测和响应集群事件（例如，当不满足部署的 -`replicas` 字段时，启动新的 {{< glossary_tooltip text="pod" term_id="pod">}}）。 +控制平面组件会为集群做出全局决策，比如资源的调度。 +以及检测和响应集群事件，例如当不满足部署的 `replicas` 字段时， +要启动新的 {{< glossary_tooltip text="pod" term_id="pod">}}）。 ## Node 组件 {#node-components} -节点组件在每个节点上运行，维护运行的 Pod 并提供 Kubernetes 运行环境。 +节点组件会在每个节点上运行，负责维护运行的 Pod 并提供 Kubernetes 运行环境。 ### kubelet @@ -201,11 +203,12 @@ Kubernetes 启动的容器自动将此 DNS 服务器包含在其 DNS 搜索列 [Dashboard](/docs/tasks/access-application-cluster/web-ui-dashboard/) is a general purpose, web-based UI for Kubernetes clusters. It allows users to manage and troubleshoot applications running in the cluster, as well as the cluster itself. --> -### Web 界面（仪表盘） +### Web 界面（仪表盘） {#web-ui-dashboard} [Dashboard](/zh/docs/tasks/access-application-cluster/web-ui-dashboard/) 是 Kubernetes 集群的通用的、基于 Web 的用户界面。 -它使用户可以管理集群中运行的应用程序以及集群本身并进行故障排除。 +它使用户可以管理集群中运行的应用程序以及集群本身， +并进行故障排除。 -### 容器资源监控 +### 容器资源监控 {#container-resource-monitoring} [容器资源监控](/zh/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) -将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供用于浏览这些数据的界面。 +将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中， +并提供浏览这些数据的界面。 -### 集群层面日志 +### 集群层面日志 {#cluster-level-logging} -[集群层面日志](/zh/docs/concepts/cluster-administration/logging/) 机制负责将容器的日志数据 -保存到一个集中的日志存储中，该存储能够提供搜索和浏览接口。 +[集群层面日志](/zh/docs/concepts/cluster-administration/logging/) +机制负责将容器的日志数据保存到一个集中的日志存储中， +这种集中日志存储提供搜索和浏览接口。 ## {{% heading "whatsnext" %}} diff --git a/content/zh/docs/concepts/overview/kubernetes-api.md b/content/zh-cn/docs/concepts/overview/kubernetes-api.md similarity index 100% rename from content/zh/docs/concepts/overview/kubernetes-api.md rename to content/zh-cn/docs/concepts/overview/kubernetes-api.md diff --git a/content/zh/docs/concepts/overview/what-is-kubernetes.md b/content/zh-cn/docs/concepts/overview/what-is-kubernetes.md similarity index 74% rename from content/zh/docs/concepts/overview/what-is-kubernetes.md rename to content/zh-cn/docs/concepts/overview/what-is-kubernetes.md index e28baf718f..e26ea7c861 100644 --- a/content/zh/docs/concepts/overview/what-is-kubernetes.md +++ b/content/zh-cn/docs/concepts/overview/what-is-kubernetes.md @@ -32,20 +32,21 @@ This page is an overview of Kubernetes. Kubernetes is a portable, extensible, open source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available. --> Kubernetes 是一个可移植、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。 -Kubernetes 拥有一个庞大且快速增长的生态系统，其服务、支持和工具的使用范围广泛。 +Kubernetes 拥有一个庞大且快速增长的生态，其服务、支持和工具的使用范围相当广泛。 **Kubernetes** 这个名字源于希腊语，意为“舵手”或“飞行员”。k8s 这个缩写是因为 k 和 s 之间有八个字符的关系。 -Google 在 2014 年开源了 Kubernetes 项目。Kubernetes 建立在 -[Google 大规模运行生产工作负载十几年经验](https://research.google/pubs/pub43438)的基础上，结合了社区中最优秀的想法和实践。 +Google 在 2014 年开源了 Kubernetes 项目。 +Kubernetes 建立在[Google 大规模运行生产工作负载十几年经验](https://research.google/pubs/pub43438)的基础上， +结合了社区中最优秀的想法和实践。 -## 时光回溯 +## 时光回溯 {#going-back-in-time} 让我们回顾一下为何 Kubernetes 能够裨益四方。 @@ -61,11 +62,13 @@ Early on, organizations ran applications on physical servers. There was no way t --> **传统部署时代：** -早期，各个组织机构在物理服务器上运行应用程序。无法为物理服务器中的应用程序定义资源边界，这会导致资源分配问题。 -例如，如果在物理服务器上运行多个应用程序，则可能会出现一个应用程序占用大部分资源的情况， -结果可能导致其他应用程序的性能下降。 -一种解决方案是在不同的物理服务器上运行每个应用程序，但是由于资源利用不足而无法扩展， -并且维护许多物理服务器的成本很高。 +早期，各机构是在物理服务器上运行应用程序。 +由于无法限制在物理服务器中运行的应用程序资源使用，因此会导致资源分配问题。 +例如，如果在物理服务器上运行多个应用程序， +则可能会出现一个应用程序占用大部分资源的情况，而导致其他应用程序的性能下降。 +一种解决方案是将每个应用程序都运行在不同的物理服务器上， +但是当某个应用程式资源利用率不高时，剩余资源无法被分配给其他应用程式， +而且维护许多物理服务器的成本很高。 **虚拟化部署时代：** -作为解决方案，引入了虚拟化。虚拟化技术允许你在单个物理服务器的 CPU 上运行多个虚拟机（VM）。 -虚拟化允许应用程序在 VM 之间隔离，并提供一定程度的安全，因为一个应用程序的信息 -不能被另一应用程序随意访问。 +因此，虚拟化技术被引入了。虚拟化技术允许你在单个物理服务器的 CPU 上运行多台虚拟机（VM）。 +虚拟化能使应用程序在不同 VM 之间被彼此隔离，且能提供一定程度的安全性， +因为一个应用程序的信息不能被另一应用程序随意访问。 -虚拟化技术能够更好地利用物理服务器上的资源，并且因为可轻松地添加或更新应用程序 -而可以实现更好的可伸缩性，降低硬件成本等等。 +虚拟化技术能够更好地利用物理服务器的资源，并且因为可轻松地添加或更新应用程序， +而因此可以具有更高的可伸缩性，以及降低硬件成本等等的好处。 -每个 VM 是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统。 +每个 VM 是一台完整的计算机，在虚拟化硬件之上运行所有组件，包括其自己的操作系统（OS）。 **容器部署时代：** -容器类似于 VM，但是它们具有被放宽的隔离属性，可以在应用程序之间共享操作系统（OS）。 -因此，容器被认为是轻量级的。容器与 VM 类似，具有自己的文件系统、CPU、内存、进程空间等。 +容器类似于 VM，但是更宽松的隔离特性，使容器之间可以共享操作系统（OS）。 +因此，容器比起 VM 被认为是更轻量级的。且与 VM 类似，每个容器都具有自己的文件系统、CPU、内存、进程空间等。 由于它们与基础架构分离，因此可以跨云和 OS 发行版本进行移植。 * 敏捷应用程序的创建和部署：与使用 VM 镜像相比，提高了容器镜像创建的简便性和效率。 -* 持续开发、集成和部署：通过快速简单的回滚（由于镜像不可变性），支持可靠且频繁的 - 容器镜像构建和部署。 -* 关注开发与运维的分离：在构建/发布时而不是在部署时创建应用程序容器镜像， +* 持续开发、集成和部署：通过快速简单的回滚（由于镜像不可变性）， + 提供可靠且频繁的容器镜像构建和部署。 +* 关注开发与运维的分离：在构建、发布时创建应用程序容器镜像，而不是在部署时， 从而将应用程序与基础架构分离。 -* 可观察性：不仅可以显示操作系统级别的信息和指标，还可以显示应用程序的运行状况和其他指标信号。 -* 跨开发、测试和生产的环境一致性：在便携式计算机上与在云中相同地运行。 +* 可观察性：不仅可以显示 OS 级别的信息和指标，还可以显示应用程序的运行状况和其他指标信号。 +* 跨开发、测试和生产的环境一致性：在笔记本计算机上也可以和在云中运行一样的应用程序。 * 跨云和操作系统发行版本的可移植性：可在 Ubuntu、RHEL、CoreOS、本地、 Google Kubernetes Engine 和其他任何地方运行。 -* 以应用程序为中心的管理：提高抽象级别，从在虚拟硬件上运行 OS 到使用逻辑资源在 - OS 上运行应用程序。 +* 以应用程序为中心的管理：提高抽象级别，从在虚拟硬件上运行 OS 到使用逻辑资源在 OS 上运行应用程序。 * 松散耦合、分布式、弹性、解放的微服务：应用程序被分解成较小的独立部分， 并且可以动态部署和管理 - 而不是在一台大型单机上整体运行。 * 资源隔离：可预测的应用程序性能。 @@ -133,18 +135,20 @@ 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 +164,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} Kubernetes 不是传统的、包罗万象的 PaaS（平台即服务）系统。 -由于 Kubernetes 在容器级别而不是在硬件级别运行，它提供了 PaaS 产品共有的一些普遍适用的功能， +由于 Kubernetes 是在容器级别运行，而非在硬件级别， +它提供了 PaaS 产品共有的一些普遍适用的功能， 例如部署、扩展、负载均衡、日志记录和监视。 -但是，Kubernetes 不是单体系统，默认解决方案都是可选和可插拔的。 -Kubernetes 提供了构建开发人员平台的基础，但是在重要的地方保留了用户的选择和灵活性。 +但是，Kubernetes 不是单体式（monolithic）系统，那些默认解决方案都是可选、可插拔的。 +Kubernetes 为构建开发人员平台提供了基础，但是在重要的地方保留了用户选择权，能有更高的灵活性。 -* 不要求日志记录、监视或警报解决方案。 - 它提供了一些集成作为概念证明，并提供了收集和导出指标的机制。 -* 不提供或不要求配置语言/系统（例如 jsonnet），它提供了声明性 API， +* 不是日志记录、监视或警报的解决方案。 + 它集成了一些功能作为概念证明，并提供了收集和导出指标的机制。 +* 不提供也不要求配置用的语言、系统（例如 jsonnet），它提供了声明性 API， 该声明性 API 可以由任意形式的声明性规范所构成。 * 不提供也不采用任何全面的机器配置、维护、管理或自我修复系统。 * 此外，Kubernetes 不仅仅是一个编排系统，实际上它消除了编排的需要。 编排的技术定义是执行已定义的工作流程：首先执行 A，然后执行 B，再执行 C。 - 相比之下，Kubernetes 包含一组独立的、可组合的控制过程， - 这些过程连续地将当前状态驱动到所提供的所需状态。 - 如何从 A 到 C 的方式无关紧要，也不需要集中控制，这使得系统更易于使用 - 且功能更强大、系统更健壮、更为弹性和可扩展。 + 而 Kubernetes 包含了一组独立可组合的控制过程， + 可以连续地将当前状态驱动到所提供的预期状态。 + 你不需要在乎如何从 A 移动到 C，也不需要集中控制，这使得系统更易于使用 + 且功能更强大、系统更健壮，更为弹性和可扩展。 ## {{% heading "whatsnext" %}} @@ -266,5 +273,5 @@ Kubernetes： * Take a look at the [Kubernetes Components](/docs/concepts/overview/components/) * Ready to [Get Started](/docs/setup/)? --> -* 查阅 [Kubernetes 组件](/zh/docs/concepts/overview/components/) -* 开始 [Kubernetes 入门](/zh/docs/setup/)？ +* 查阅[Kubernetes 组件](/zh/docs/concepts/overview/components/) +* 开始[Kubernetes 的建置](/zh/docs/setup/)吧！ diff --git a/content/zh/docs/concepts/overview/working-with-objects/_index.md b/content/zh-cn/docs/concepts/overview/working-with-objects/_index.md similarity index 100% rename from content/zh/docs/concepts/overview/working-with-objects/_index.md rename to content/zh-cn/docs/concepts/overview/working-with-objects/_index.md diff --git a/content/zh/docs/concepts/overview/working-with-objects/annotations.md b/content/zh-cn/docs/concepts/overview/working-with-objects/annotations.md similarity index 100% rename from content/zh/docs/concepts/overview/working-with-objects/annotations.md rename to content/zh-cn/docs/concepts/overview/working-with-objects/annotations.md diff --git a/content/zh/docs/concepts/overview/working-with-objects/common-labels.md b/content/zh-cn/docs/concepts/overview/working-with-objects/common-labels.md similarity index 100% rename from content/zh/docs/concepts/overview/working-with-objects/common-labels.md rename to content/zh-cn/docs/concepts/overview/working-with-objects/common-labels.md diff --git a/content/zh/docs/concepts/overview/working-with-objects/field-selectors.md b/content/zh-cn/docs/concepts/overview/working-with-objects/field-selectors.md similarity index 100% rename from content/zh/docs/concepts/overview/working-with-objects/field-selectors.md rename to content/zh-cn/docs/concepts/overview/working-with-objects/field-selectors.md diff --git a/content/zh/docs/concepts/overview/working-with-objects/finalizers.md b/content/zh-cn/docs/concepts/overview/working-with-objects/finalizers.md similarity index 100% rename from content/zh/docs/concepts/overview/working-with-objects/finalizers.md rename to content/zh-cn/docs/concepts/overview/working-with-objects/finalizers.md diff --git a/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects.md similarity index 63% rename from content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md rename to content/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 23afa65eab..1cd32dc950 100644 --- a/content/zh/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -20,42 +20,54 @@ card: -本页说明了 Kubernetes 对象在 Kubernetes API 中是如何表示的，以及如何在 `.yaml` 格式的文件中表示。 - +本页说明了在 Kubernetes API 中是如何表示 Kubernetes 对象的， +以及使用 `.yaml` 格式的文件表示 Kubernetes 对象。 -## 理解 Kubernetes 对象 +## 理解 Kubernetes 对象 {#kubernetes-objects} 在 Kubernetes 系统中，*Kubernetes 对象* 是持久化的实体。 -Kubernetes 使用这些实体去表示整个集群的状态。特别地，它们描述了如下信息： +Kubernetes 使用这些实体去表示整个集群的状态。 +比較特别地是，它们描述了如下信息： -* 哪些容器化应用在运行（以及在哪些节点上） +* 哪些容器化应用正在运行（以及在哪些节点上运行） * 可以被应用使用的资源 * 关于应用运行时表现的策略，比如重启策略、升级策略，以及容错策略 -Kubernetes 对象是 “目标性记录” —— 一旦创建对象，Kubernetes 系统将持续工作以确保对象存在。 -通过创建对象，本质上是在告知 Kubernetes 系统，所需要的集群工作负载看起来是什么样子的， -这就是 Kubernetes 集群的 **期望状态（Desired State）**。 +Kubernetes 对象是“目标性记录”——一旦创建对象，Kubernetes 系统将不断工作以确保对象存在。 +通过创建对象，你就是在告知 Kubernetes 系统，你想要的集群工作负载状态看起来应是什么样子的， +这就是 Kubernetes 集群所谓的 **期望状态（Desired State）**。 操作 Kubernetes 对象 —— 无论是创建、修改，或者删除 —— 需要使用 [Kubernetes API](/zh/docs/concepts/overview/kubernetes-api)。 -比如，当使用 `kubectl` 命令行接口时，CLI 会执行必要的 Kubernetes API 调用， -也可以在程序中使用 -[客户端库](/zh/docs/reference/using-api/client-libraries/)直接调用 Kubernetes API。 +比如，当使用 `kubectl` 命令行接口（CLI）时，CLI 会调用必要的 Kubernetes API； +也可以在程序中使用[客户端库](/zh-cn/docs/reference/using-api/client-libraries/)， +来直接调用 Kubernetes API。 -`status` 描述了对象的 _当前状态（Current State）_，它是由 Kubernetes 系统和组件 -设置并更新的。在任何时刻，Kubernetes -{{< glossary_tooltip text="控制平面" term_id="control-plane" >}} -都一直积极地管理着对象的实际状态，以使之与期望状态相匹配。 +`status` 描述了对象的**当前状态（Current State）**，它是由 Kubernetes 系统和组件设置并更新的。 +在任何时刻，Kubernetes {{< glossary_tooltip text="控制平面" term_id="control-plane" >}} +都一直都在积极地管理着对象的实际状态，以使之达成期望状态。 例如，Kubernetes 中的 Deployment 对象能够表示运行在集群中的应用。 -当创建 Deployment 时，可能需要设置 Deployment 的 `spec`，以指定该应用需要有 3 个副本运行。 -Kubernetes 系统读取 Deployment 规约，并启动我们所期望的应用的 3 个实例 -—— 更新状态以与规约相匹配。 -如果这些实例中有的失败了（一种状态变更），Kubernetes 系统通过执行修正操作 -来响应规约和状态间的不一致 —— 在这里意味着它会启动一个新的实例来替换。 +当创建 Deployment 时，可能会去设置 Deployment 的 `spec`，以指定该应用要有 3 个副本运行。 +Kubernetes 系统读取 Deployment 的 `spec`， +并启动我们所期望的应用的 3 个实例 —— 更新状态以与规约相匹配。 +如果这些实例中有的失败了（一种状态变更），Kubernetes 系统会通过执行修正操作 +来响应 `spec` 和状态间的不一致 —— 意味着它会启动一个新的实例来替换。 - 关于对象 spec、status 和 metadata 的更多信息，可参阅 [Kubernetes API 约定](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md)。 -### 描述 Kubernetes 对象 +### 描述 Kubernetes 对象 {#describing-a-kubernetes-object} -创建 Kubernetes 对象时，必须提供对象的规约，用来描述该对象的期望状态， +创建 Kubernetes 对象时，必须提供对象的 `spec`，用来描述该对象的期望状态， 以及关于对象的一些基本信息（例如名称）。 -当使用 Kubernetes API 创建对象时（或者直接创建，或者基于 `kubectl`）， -API 请求必须在请求体中包含 JSON 格式的信息。 -**大多数情况下，需要在 .yaml 文件中为 `kubectl` 提供这些信息**。 +当使用 Kubernetes API 创建对象时（直接创建，或经由 `kubectl`）， +API 请求必须在请求本体中包含 JSON 格式的信息。 +**大多数情况下，你需要提供 `.yaml` 文件为 kubectl 提供这些信息**。 `kubectl` 在发起 API 请求时，将这些信息转换成 JSON 格式。 -这里有一个 `.yaml` 示例文件，展示了 Kubernetes Deployment 的必需字段和对象规约： +这里有一个 `.yaml` 示例文件，展示了 Kubernetes Deployment 的必需字段和对象 `spec`： {{< codenew file="application/deployment.yaml" >}} @@ -135,7 +150,7 @@ One way to create a Deployment using a `.yaml` file like the one above is to use [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) command in the `kubectl` command-line interface, passing the `.yaml` file as an argument. Here's an example: --> -使用类似于上面的 `.yaml` 文件来创建 Deployment 的一种方式是使用 `kubectl` 命令行接口（CLI）中的 +相较于上面使用 `.yaml` 文件来创建 Deployment，另一种类似的方式是使用 `kubectl` 命令行接口（CLI）中的 [`kubectl apply`](/docs/reference/generated/kubectl/kubectl-commands#apply) 命令， 将 `.yaml` 文件作为参数。下面是一个示例： @@ -146,7 +161,7 @@ kubectl apply -f https://k8s.io/examples/application/deployment.yaml -输出类似如下这样： +输出类似下面这样： ``` deployment.apps/nginx-deployment created @@ -162,21 +177,24 @@ In the `.yaml` file for the Kubernetes object you want to create, you'll need to * `metadata` - Data that helps uniquely identify the object, including a `name` string, `UID`, and optional `namespace` * `spec` - What state you desire for the object --> -### 必需字段 {#required-fields} +### 必需字段 {#required-fields} -在想要创建的 Kubernetes 对象对应的 `.yaml` 文件中，需要配置如下的字段： +在想要创建的 Kubernetes 对象所对应的 `.yaml` 文件中，需要配置的字段如下： * `apiVersion` - 创建该对象所使用的 Kubernetes API 的版本 * `kind` - 想要创建的对象的类别 -* `metadata` - 帮助唯一性标识对象的一些数据，包括一个 `name` 字符串、UID 和可选的 `namespace` +* `metadata` - 帮助唯一性标识对象的一些数据，包括一个 `name` 字符串、`UID` 和可选的 `namespace` * `spec` - 你所期望的该对象的状态 -对象 `spec` 的精确格式对每个 Kubernetes 对象来说是不同的，包含了特定于该对象的嵌套字段。 -[Kubernetes API 参考](https://kubernetes.io/docs/reference/kubernetes-api/) -能够帮助我们找到任何我们想创建的对象的规约格式。 +对每个 Kubernetes 对象而言，其 `spec` 之精确格式都是不同的，包含了特定于该对象的嵌套字段。 +我们能在 [Kubernetes API 参考](/zh-cn/docs/reference/kubernetes-api/) +找到我们想要在 Kubernetes 上创建的任何对象的规约格式。 -- 不同的团队可以在不同的命名空间下工作，目前这是非约束性的，在未来的版本中可能会通过 - ACL (Access Control List 访问控制列表) 来实现强制性约束。 +- 不同的团队可以在不同的命名空间下工作。这可以通过 [RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/) 强制执行。 - 集群管理员可以为每个命名空间创建一个或多个 ResourceQuota 对象。 - 当用户在命名空间下创建资源（如 Pod、Service 等）时，Kubernetes 的配额系统会 跟踪集群的资源使用情况，以确保使用的资源用量不超过 ResourceQuota 中定义的硬性资源限额。 @@ -65,14 +63,14 @@ Resource quotas work like this: 提示: 可使用 `LimitRanger` 准入控制器来为没有设置计算资源需求的 Pod 设置默认值。 若想避免这类问题，请参考 - [演练](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)示例。 + [演练](/zh-cn/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)示例。 ResourceQuota 对象的名称必须是合法的 -[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 +[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 ## 存储资源配额 -用户可以对给定命名空间下的[存储资源](/zh/docs/concepts/storage/persistent-volumes/) +用户可以对给定命名空间下的[存储资源](/zh-cn/docs/concepts/storage/persistent-volumes/) 总量进行限制。 此外，还可以根据相关的存储类（Storage Class）来限制存储资源的消耗。 @@ -218,9 +216,9 @@ In addition, you can limit consumption of storage resources based on associated | 资源名称 | 描述 | | --------------------- | ----------------------------------------------------------- | | `requests.storage` | 所有 PVC，存储资源的需求总量不能超过该值。 | -| `persistentvolumeclaims` | 在该命名空间中所允许的 [PVC](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 总量。 | +| `persistentvolumeclaims` | 在该命名空间中所允许的 [PVC](/zh-cn/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 总量。 | | `.storageclass.storage.k8s.io/requests.storage` | 在所有与 `` 相关的持久卷申领中，存储请求的总和不能超过该值。 | -| `.storageclass.storage.k8s.io/persistentvolumeclaims` | 在与 storage-class-name 相关的所有持久卷申领中，命名空间中可以存在的[持久卷申领](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)总数。 | +| `.storageclass.storage.k8s.io/persistentvolumeclaims` | 在与 storage-class-name 相关的所有持久卷申领中，命名空间中可以存在的[持久卷申领](/zh-cn/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)总数。 | 如果所使用的是 CRI 容器运行时，容器日志会被计入临时存储配额。 这可能会导致存储配额耗尽的 Pods 被意外地驱逐出节点。 -参考[日志架构](/zh/docs/concepts/cluster-administration/logging/) +参考[日志架构](/zh-cn/docs/concepts/cluster-administration/logging/) 了解详细信息。 {{< /note >}} @@ -343,7 +341,7 @@ The following types are supported: | 资源名称 | 描述 | | ------------------------------- | ------------------------------------------------- | | `configmaps` | 在该命名空间中允许存在的 ConfigMap 总数上限。 | -| `persistentvolumeclaims` | 在该命名空间中允许存在的 [PVC](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 的总数上限。 | +| `persistentvolumeclaims` | 在该命名空间中允许存在的 [PVC](/zh-cn/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) 的总数上限。 | | `pods` | 在该命名空间中允许存在的非终止状态的 Pod 总数上限。Pod 终止状态等价于 Pod 的 `.status.phase in (Failed, Succeeded)` 为真。 | | `replicationcontrollers` | 在该命名空间中允许存在的 ReplicationController 总数上限。 | | `resourcequotas` | 在该命名空间中允许存在的 ResourceQuota 总数上限。 | @@ -396,8 +394,8 @@ Resources specified on the quota outside of the allowed set results in a validat | `NotTerminating` | 匹配所有 `spec.activeDeadlineSeconds` 是 nil 的 Pod。 | | `BestEffort` | 匹配所有 Qos 是 BestEffort 的 Pod。 | | `NotBestEffort` | 匹配所有 Qos 不是 BestEffort 的 Pod。 | -| `PriorityClass` | 匹配所有引用了所指定的[优先级类](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption)的 Pods。 | -| `CrossNamespacePodAffinity` | 匹配那些设置了跨名字空间 [（反）亲和性条件](/zh/docs/concepts/scheduling-eviction/assign-pod-node)的 Pod。 | +| `PriorityClass` | 匹配所有引用了所指定的[优先级类](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption)的 Pods。 | +| `CrossNamespacePodAffinity` | 匹配那些设置了跨名字空间 [（反）亲和性条件](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node)的 Pod。 | -Pod 可以创建为特定的[优先级](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority)。 +Pod 可以创建为特定的[优先级](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority)。 通过使用配额规约中的 `scopeSelector` 字段，用户可以根据 Pod 的优先级控制其系统资源消耗。 - 查看[资源配额设计文档](https://git.k8s.io/community/contributors/design-proposals/resource-management/admission_control_resource_quota.md) -- 查看[如何使用资源配额的详细示例](/zh/docs/tasks/administer-cluster/quota-api-object/)。 +- 查看[如何使用资源配额的详细示例](/zh-cn/docs/tasks/administer-cluster/quota-api-object/)。 - 阅读[优先级类配额支持的设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/scheduling/pod-priority-resourcequota.md)。 了解更多信息。 - 参阅 [LimitedResources](https://github.com/kubernetes/kubernetes/pull/36765) diff --git a/content/zh/docs/concepts/scheduling-eviction/_index.md b/content/zh-cn/docs/concepts/scheduling-eviction/_index.md similarity index 100% rename from content/zh/docs/concepts/scheduling-eviction/_index.md rename to content/zh-cn/docs/concepts/scheduling-eviction/_index.md diff --git a/content/zh/docs/concepts/scheduling-eviction/api-eviction.md b/content/zh-cn/docs/concepts/scheduling-eviction/api-eviction.md similarity index 100% rename from content/zh/docs/concepts/scheduling-eviction/api-eviction.md rename to content/zh-cn/docs/concepts/scheduling-eviction/api-eviction.md diff --git a/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md similarity index 98% rename from content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md rename to content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md index a210302498..3dcd46b8c4 100644 --- a/content/zh/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -551,12 +551,11 @@ same zone currently running Pods with the `Security=S2` Pod label. 并且节点具有标签 `topology.kubernetes.io/zone=R`，Pod 不能被调度到该节点上。 -查阅[设计文档](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) -以了解 Pod 亲和性与反亲和性的更多示例。 +查阅[设计文档](https://github.com/kubernetes/design-proposals-archive/blob/main/scheduling/podaffinity.md) +以进一步熟悉 Pod 亲和性与反亲和性的示例。 -如果定义了 ResourceQuata, 则容器请求的总量以及 `overhead` 字段都将计算在内。 +如果定义了 [ResourceQuata](/zh/docs/concepts/policy/resource-quotas/), +则容器请求的总量以及 `overhead` 字段都将计算在内。 + + + + +在 kube-scheduler 的[调度插件](/zh-cn/docs/reference/scheduling/config/#scheduling-plugins) +`NodeResourcesFit` 中存在两种支持资源装箱（bin packing）的策略：`MostAllocated` 和 +`RequestedToCapacityRatio`。 + + + + +## 使用 MostAllocated 策略启用资源装箱 {#enabling-bin-packing-using-mostallocated-strategy} + +`MostAllocated` 策略基于资源的利用率来为节点计分，优选分配比率较高的节点。 +针对每种资源类型，你可以设置一个权重值以改变其对节点得分的影响。 + +要为插件 `NodeResourcesFit` 设置 `MostAllocated` 策略， +可以使用一个类似于下面这样的[调度器配置](/zh-cn/docs/reference/scheduling/config/)： + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta3 +kind: KubeSchedulerConfiguration +profiles: +- pluginConfig: + - args: + scoringStrategy: + resources: + - name: cpu + weight: 1 + - name: memory + weight: 1 + - name: intel.com/foo + weight: 3 + - name: intel.com/bar + weight: 3 + type: MostAllocated + name: NodeResourcesFit +``` + + +要进一步了解其它参数及其默认配置，请参阅 +[`NodeResourcesFitArgs`](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/#kubescheduler-config-k8s-io-v1beta3-NodeResourcesFitArgs) +的 API 文档。 + + +## 使用 RequestedToCapacityRatio 策略来启用资源装箱 {#enabling-bin-packing-using-requestedtocapacityratio} + +`RequestedToCapacityRatio` 策略允许用户基于请求值与容量的比率，针对参与节点计分的每类资源设置权重。 +这一策略是的用户可以使用合适的参数来对扩展资源执行装箱操作，进而提升大规模集群中稀有资源的利用率。 +此策略根据所分配资源的一个配置函数来评价节点。 +`NodeResourcesFit` 计分函数中的 `RequestedToCapacityRatio` 可以通过字段 +[scoringStrategy](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/#kubescheduler-config-k8s-io-v1beta3-ScoringStrategy) +来控制。 +在 `scoringStrategy` 字段中，你可以配置两个参数：`requestedToCapacityRatioParam` +和 `resources`。`requestedToCapacityRatioParam` 参数中的 `shape` +设置使得用户能够调整函数的算法，基于 `utilization` 和 `score` 值计算最少请求或最多请求。 +`resources` 参数中包含计分过程中需要考虑的资源的 `name`，以及用来设置每种资源权重的 `weight`。 + + +下面是一个配置示例，使用 `requestedToCapacityRatio` 字段为扩展资源 `intel.com/foo` +和 `intel.com/bar` 设置装箱行为： + +```yaml +apiVersion: kubescheduler.config.k8s.io/v1beta3 +kind: KubeSchedulerConfiguration +profiles: +- pluginConfig: + - args: + scoringStrategy: + resources: + - name: intel.com/foo + weight: 3 + - name: intel.com/bar + weight: 3 + requestedToCapacityRatioParam: + shape: + - utilization: 0 + score: 0 + - utilization: 100 + score: 10 + type: RequestedToCapacityRatio + name: NodeResourcesFit +``` + + +使用 kube-scheduler 标志 `--config=/path/to/config/file` +引用 `KubeSchedulerConfiguration` 文件，可以将配置传递给调度器。 + + +要进一步了解其它参数及其默认配置，可以参阅 +[`NodeResourcesFitArgs`](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/#kubescheduler-config-k8s-io-v1beta3-NodeResourcesFitArgs) +的 API 文档。 + + +### 调整计分函数 {#tuning-the-score-function} + +`shape` 用于指定 `RequestedToCapacityRatio` 函数的行为。 + +```yaml +shape: + - utilization: 0 + score: 0 + - utilization: 100 + score: 10 +``` + + +上面的参数在 `utilization` 为 0% 时给节点评分为 0，在 `utilization` 为 +100% 时给节点评分为 10，因此启用了装箱行为。 +要启用最少请求（least requested）模式，必须按如下方式反转得分值。 + +```yaml + shape: + - utilization: 0 + score: 10 + - utilization: 100 + score: 0 +``` + + +`resources` 是一个可选参数，默认情况下设置为： + +``` yaml +resources: + - name: cpu + weight: 1 + - name: memory + weight: 1 +``` + + +它可以像下面这样用来添加扩展资源： + +```yaml +resources: + - name: intel.com/foo + weight: 5 + - name: cpu + weight: 3 + - name: memory + weight: 1 +``` + + +`weight` 参数是可选的，如果未指定，则设置为 1。 +同时，`weight` 不能设置为负值。 + + +### 节点容量分配的评分 {#node-scoring-for-capacity-allocation} + +本节适用于希望了解此功能的内部细节的人员。 +以下是如何针对给定的一组值来计算节点得分的示例。 + + +请求的资源： + +``` +intel.com/foo : 2 +memory: 256MB +cpu: 2 +``` + + +资源权重： + +``` +intel.com/foo : 5 +memory: 1 +cpu: 3 +``` + +``` +FunctionShapePoint {{0, 0}, {100, 10}} +``` + + +节点 1 配置： + +``` +可用： + intel.com/foo : 4 + memory : 1 GB + cpu: 8 + +已用： + intel.com/foo: 1 + memory: 256MB + cpu: 1 +``` + + +节点得分： + +``` +intel.com/foo = resourceScoringFunction((2+1),4) + = (100 - ((4-3)*100/4) + = (100 - 25) + = 75 # requested + used = 75% * available + = rawScoringFunction(75) + = 7 # floor(75/10) + +memory = resourceScoringFunction((256+256),1024) + = (100 -((1024-512)*100/1024)) + = 50 # requested + used = 50% * available + = rawScoringFunction(50) + = 5 # floor(50/10) + +cpu = resourceScoringFunction((2+1),8) + = (100 -((8-3)*100/8)) + = 37.5 # requested + used = 37.5% * available + = rawScoringFunction(37.5) + = 3 # floor(37.5/10) + +NodeScore = (7 * 5) + (5 * 1) + (3 * 3) / (5 + 1 + 3) + = 5 +``` + + +节点 2 配置： + +``` +可用： + intel.com/foo: 8 + memory: 1GB + cpu: 8 + +已用： + intel.com/foo: 2 + memory: 512MB + cpu: 6 +``` + + +节点得分： + +``` +intel.com/foo = resourceScoringFunction((2+2),8) + = (100 - ((8-4)*100/8) + = (100 - 50) + = 50 + = rawScoringFunction(50) + = 5 + +memory = resourceScoringFunction((256+512),1024) + = (100 -((1024-768)*100/1024)) + = 75 + = rawScoringFunction(75) + = 7 + +cpu = resourceScoringFunction((2+6),8) + = (100 -((8-8)*100/8)) + = 100 + = rawScoringFunction(100) + = 10 + +NodeScore = (5 * 5) + (7 * 1) + (10 * 3) / (5 + 1 + 3) + = 7 +``` + +## {{% heading "whatsnext" %}} + + +- 继续阅读[调度器框架](/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework/) +- 继续阅读[调度器配置](/zh-cn/docs/reference/scheduling/config/) + diff --git a/content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/zh-cn/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md similarity index 100% rename from content/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md rename to content/zh-cn/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md diff --git a/content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md b/content/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework.md similarity index 100% rename from content/zh/docs/concepts/scheduling-eviction/scheduling-framework.md rename to content/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework.md diff --git a/content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration.md similarity index 100% rename from content/zh/docs/concepts/scheduling-eviction/taint-and-toleration.md rename to content/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration.md diff --git a/content/zh/docs/concepts/security/_index.md b/content/zh-cn/docs/concepts/security/_index.md similarity index 100% rename from content/zh/docs/concepts/security/_index.md rename to content/zh-cn/docs/concepts/security/_index.md diff --git a/content/zh/docs/concepts/security/controlling-access.md b/content/zh-cn/docs/concepts/security/controlling-access.md similarity index 100% rename from content/zh/docs/concepts/security/controlling-access.md rename to content/zh-cn/docs/concepts/security/controlling-access.md diff --git a/content/zh/docs/concepts/security/overview.md b/content/zh-cn/docs/concepts/security/overview.md similarity index 96% rename from content/zh/docs/concepts/security/overview.md rename to content/zh-cn/docs/concepts/security/overview.md index 29cc2a06a2..9a9e9845a7 100644 --- a/content/zh/docs/concepts/security/overview.md +++ b/content/zh-cn/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-cn/docs/concepts/security/pod-security-admission.md similarity index 89% rename from content/zh/docs/concepts/security/pod-security-admission.md rename to content/zh-cn/docs/concepts/security/pod-security-admission.md index 87fddd9ddb..54ae5436a0 100644 --- a/content/zh/docs/concepts/security/pod-security-admission.md +++ b/content/zh-cn/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-cn/docs/concepts/security/pod-security-policy.md b/content/zh-cn/docs/concepts/security/pod-security-policy.md new file mode 100644 index 0000000000..6bb83482f6 --- /dev/null +++ b/content/zh-cn/docs/concepts/security/pod-security-policy.md @@ -0,0 +1,1360 @@ +--- +title: Pod 安全策略 +content_type: concept +weight: 30 +--- + + + +{{< feature-state for_k8s_version="v1.21" state="deprecated" >}} + +{{< caution >}} + +PodSecurityPolicy 在 Kubernetes v1.21 版本中被弃用，**将在 v1.25 中删除**。 +我们建议迁移到 [Pod 安全性准入](/zh/docs/concepts/security/pod-security-admission)， +或者第三方的准入插件。 +若需了解迁移指南，可参阅[从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器](/zh/docs/tasks/configure-pod-container/migrate-from-psp/)。 +关于弃用的更多信息，请查阅 [PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)。 +{{< /caution >}} + + +Pod 安全策略使得对 Pod 创建和更新进行细粒度的权限控制成为可能。 + + + + +## 什么是 Pod 安全策略？ {#what-is-a-pod-security-policy} + +_Pod 安全策略（Pod Security Policy）_ 是集群级别的资源，它能够控制 Pod 规约 +中与安全性相关的各个方面。 +[PodSecurityPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) +对象定义了一组 Pod 运行时必须遵循的条件及相关字段的默认值，只有 Pod 满足这些条件才会被系统接受。 +Pod 安全策略允许管理员控制如下方面： + + +| 控制的角度 | 字段名称 | +| ----------------------------------- | --------------------------------- | +| 运行特权容器 | [`privileged`](#privileged) | +| 使用宿主名字空间 | [`hostPID`、`hostIPC`](#host-namespaces) | +| 使用宿主的网络和端口 | [`hostNetwork`, `hostPorts`](#host-namespaces) | +| 控制卷类型的使用 | [`volumes`](#volumes-and-file-systems) | +| 使用宿主文件系统 | [`allowedHostPaths`](#volumes-and-file-systems) | +| 允许使用特定的 FlexVolume 驱动 | [`allowedFlexVolumes`](#flexvolume-drivers) | +| 分配拥有 Pod 卷的 FSGroup 账号 | [`fsGroup`](#volumes-and-file-systems) | +| 以只读方式访问根文件系统 | [`readOnlyRootFilesystem`](#volumes-and-file-systems) | +| 设置容器的用户和组 ID | [`runAsUser`, `runAsGroup`, `supplementalGroups`](#users-and-groups) | +| 限制 root 账号特权级提升 | [`allowPrivilegeEscalation`, `defaultAllowPrivilegeEscalation`](#privilege-escalation) | +| Linux 权能字（Capabilities） | [`defaultAddCapabilities`, `requiredDropCapabilities`, `allowedCapabilities`](#capabilities) | +| 设置容器的 SELinux 上下文 | [`seLinux`](#selinux) | +| 指定容器可以挂载的 proc 类型 | [`allowedProcMountTypes`](#allowedprocmounttypes) | +| 指定容器使用的 AppArmor 模版 | [annotations](#apparmor) | +| 指定容器使用的 seccomp 模版 | [annotations](#seccomp) | +| 指定容器使用的 sysctl 模版 | [`forbiddenSysctls`,`allowedUnsafeSysctls`](#sysctl) | + + +## 启用 Pod 安全策略 {#enabling-pod-security-policies} + +Pod 安全策略实现为一种可选的[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy)。 +[启用了准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in)即可强制实施 +Pod 安全策略，不过如果没有授权认可策略之前即启用准入控制器 **将导致集群中无法创建任何 Pod**。 + + +由于 Pod 安全策略 API（`policy/v1beta1/podsecuritypolicy`）是独立于准入控制器 +来启用的，对于现有集群而言，建议在启用准入控制器之前先添加策略并对其授权。 + + +## 授权策略 {#authorizing-policies} + +PodSecurityPolicy 资源被创建时，并不执行任何操作。为了使用该资源， +需要对发出请求的用户或者目标 Pod +的[服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/)授权， +通过允许其对策略执行 `use` 动词允许其使用该策略。 + + +大多数 Kubernetes Pod 不是由用户直接创建的。相反，这些 Pod 是由 +[Deployment](/zh/docs/concepts/workloads/controllers/deployment/)、 +[ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/) +或者经由控制器管理器模版化的控制器创建。 +赋予控制器访问策略的权限意味着对应控制器所创建的 *所有* Pod 都可访问策略。 +因此，对策略进行授权的优先方案是为 Pod 的服务账号授予访问权限 +（参见[示例](#run-another-pod)）。 + + +### 通过 RBAC 授权 {#via-rbac} + +[RBAC](/zh/docs/reference/access-authn-authz/rbac/) 是一种标准的 Kubernetes +鉴权模式，可以很容易地用来授权策略访问。 + +首先，某 `Role` 或 `ClusterRole` 需要获得使用 `use` 访问目标策略的权限。 +访问授权的规则看起来像这样： + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRole +metadata: + name: +rules: +- apiGroups: ['policy'] + resources: ['podsecuritypolicies'] + verbs: ['use'] + resourceNames: + - <要授权的策略列表> +``` + + +接下来将该 `Role`（或 `ClusterRole`）绑定到授权的用户： + +```yaml +apiVersion: rbac.authorization.k8s.io/v1 +kind: ClusterRoleBinding +metadata: + name: <绑定名称> +roleRef: + kind: ClusterRole + name: <角色名称> + apiGroup: rbac.authorization.k8s.io +subjects: + # 授权命名空间下的所有服务账号（推荐）： + - kind: Group + apiGroup: rbac.authorization.k8s.io + name: system:serviceaccounts: + # 授权特定的服务账号（不建议这样操作）： + - kind: ServiceAccount + name: <被授权的服务账号名称> + namespace: <被授权的 Pod 名字空间> + # 授权特定的用户（不建议这样操作）： + - kind: User + apiGroup: rbac.authorization.k8s.io + name: <被授权的用户名> +``` + + +如果使用的是 `RoleBinding`（而不是 `ClusterRoleBinding`），授权仅限于与该 +`RoleBinding` 处于同一名字空间中的 Pod。 +可以考虑将这种授权模式和系统组结合，对名字空间中的所有 Pod 授予访问权限。 + +```yaml +# 授权某名字空间中所有服务账号 +- kind: Group + apiGroup: rbac.authorization.k8s.io + name: system:serviceaccounts +# 或者与此等价，授权给某名字空间中所有被认证过的用户 +- kind: Group + apiGroup: rbac.authorization.k8s.io + name: system:authenticated +``` + + +参阅[角色绑定示例](/zh/docs/reference/access-authn-authz/rbac#role-binding-examples)查看 +RBAC 绑定的更多实例。 +参阅[下文](#example)，查看对 PodSecurityPolicy 进行授权的完整示例。 + + +## 推荐实践 {#recommended-practice} + +PodSecurityPolicy 正在被一个新的、简化的 `PodSecurity` +{{< glossary_tooltip text="准入控制器" term_id="admission-controller" >}}替代。 +有关此变更的更多详细信息，请参阅 +[PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)。 +参照下述指导，简化从 PodSecurityPolicy 迁移到新的准入控制器步骤： + + +1. 将 PodSecurityPolicies 限制为 + [Pod 安全性标准](/zh/docs/concepts/security/pod-security-standards)所定义的策略： + + - {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}} + - {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}} + - {{< example file="policy/restricted-psp.yaml" >}}Restricted{{< /example >}} + + +2. 通过配置 `system:serviceaccounts:` 组（`` 是目标名字空间）， + 仅将 PSP 绑定到整个命名空间。示例： + + ```yaml + apiVersion: rbac.authorization.k8s.io/v1 + # 此集群角色绑定允许 "development" 名字空间中的所有 Pod 使用 baseline PSP。 + kind: ClusterRoleBinding + metadata: + name: psp-baseline-namespaces + roleRef: + kind: ClusterRole + name: psp-baseline + apiGroup: rbac.authorization.k8s.io + subjects: + - kind: Group + name: system:serviceaccounts:development + apiGroup: rbac.authorization.k8s.io + - kind: Group + name: system:serviceaccounts:canary + apiGroup: rbac.authorization.k8s.io + ``` + + +### 故障排查 {#troubleshooting} + +- [控制器管理器组件](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) + 必须运行在安全的 API 端口之上，并且不能拥有超级用户的访问权限。 + 参阅[控制 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access)以了解 + API 服务器的访问控制。 + + 如果控制器管理器通过可信的 API 端口连接（也称作 `localhost` 监听组件）， + 其请求会绕过身份认证和鉴权模块控制，从而导致所有 PodSecurityPolicy 对象都被允许， + 用户亦能授予自身创建特权容器的特权。 + + 关于配置控制器管理器鉴权的进一步细节， + 请参阅[控制器角色](/zh/docs/reference/access-authn-authz/rbac/#controller-roles)。 + + +## 策略顺序 {#policy-order} + +除了限制 Pod 创建与更新，Pod 安全策略也可用来为其所控制的很多字段设置默认值。 +当存在多个策略对象时，Pod 安全策略控制器依据以下条件选择策略： + + +1. 优先考虑允许 Pod 保持原样，不会更改 Pod 字段默认值或其他配置的 PodSecurityPolicy。 + 这类非更改性质的 PodSecurityPolicy 对象之间的顺序无关紧要。 +2. 如果必须要为 Pod 设置默认值或者其他配置，（按名称顺序）选择第一个允许 + Pod 操作的 PodSecurityPolicy 对象。 + +{{< note >}} + +在更新操作期间（这时不允许更改 Pod 规约），仅使用非更改性质的 +PodSecurityPolicy 来对 Pod 执行验证操作。 +{{< /note >}} + + +## 示例 {#example} + +本示例假定你已经有一个启动了 PodSecurityPolicy 准入控制器的集群并且你拥有集群管理员特权。 + + +### 配置 {#set-up} + +为运行此示例，配置一个名字空间和一个服务账号。我们将用这个服务账号来模拟一个非管理员账号的用户。 + +```shell +kubectl create namespace psp-example +kubectl create serviceaccount -n psp-example fake-user +kubectl create rolebinding -n psp-example fake-editor --clusterrole=edit --serviceaccount=psp-example:fake-user +``` + + +创建两个别名，以更清晰地展示我们所使用的用户账号，同时减少一些键盘输入： + +```shell +alias kubectl-admin='kubectl -n psp-example' +alias kubectl-user='kubectl --as=system:serviceaccount:psp-example:fake-user -n psp-example' +``` + + +### 创建一个策略和一个 Pod + +在一个文件中定义一个示例的 PodSecurityPolicy 对象。 +这里的策略只是用来禁止创建有特权要求的 Pods。 +PodSecurityPolicy 对象的名称必须是合法的 +[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 + +{{< codenew file="policy/example-psp.yaml" >}} + + +使用 kubectl 执行创建操作： + +```shell +kubectl-admin create -f example-psp.yaml +``` + + +现在，作为一个非特权用户，尝试创建一个简单的 Pod： + +```shell +kubectl-user create -f- < +输出类似于： +``` +Error from server (Forbidden): error when creating "STDIN": pods "pause" is forbidden: unable to validate against any pod security policy: [] +``` + + +**发生了什么？** 尽管 PodSecurityPolicy 被创建，Pod 的服务账号或者 +`fake-user` 用户都没有使用该策略的权限。 + +```shell +kubectl-user auth can-i use podsecuritypolicy/example +``` + +``` +no +``` + +创建角色绑定，赋予 `fake-user` `use`（使用）示例策略的权限： + +{{< note >}} + +不建议使用这种方法！ +欲了解优先考虑的方法，请参见[下节](#run-another-pod)。 +{{< /note >}} + +```shell +kubectl-admin create role psp:unprivileged \ + --verb=use \ + --resource=podsecuritypolicy \ + --resource-name=example +``` + +输出： + +``` +role "psp:unprivileged" created +``` + +```shell +kubectl-admin create rolebinding fake-user:psp:unprivileged \ + --role=psp:unprivileged \ + --serviceaccount=psp-example:fake-user +``` + +输出： + +``` +rolebinding "fake-user:psp:unprivileged" created +``` + +```shell +kubectl-user auth can-i use podsecuritypolicy/example +``` + +输出： + +``` +yes +``` + + +现在重试创建 Pod： + +```shell +kubectl-user create -f- < +输出类似于： + +``` +pod "pause" created +``` + + +此次尝试不出所料地成功了！ +不过任何创建特权 Pod 的尝试还是会被拒绝： + +```shell +kubectl-user create -f- < + +输出类似于： +``` +Error from server (Forbidden): error when creating "STDIN": pods "privileged" is forbidden: unable to validate against any pod security policy: [spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed] +``` + + +继续此例之前先删除该 Pod： + +```shell +kubectl-user delete pod pause +``` + + +### 运行另一个 Pod {#run-another-pod} + +我们再试一次，稍微有些不同： + +```shell +kubectl-user create deployment pause --image=k8s.gcr.io/pause +``` + +输出为： + +``` +deployment "pause" created +``` + +```shell +kubectl-user get pods +``` + +输出为： + +``` +No resources found. +``` + +```shell +kubectl-user get events | head -n 2 +``` + +输出为： +``` +LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE +1m 2m 15 pause-7774d79b5 ReplicaSet Warning FailedCreate replicaset-controller Error creating: pods "pause-7774d79b5-" is forbidden: no providers available to validate pod request +``` + + +**发生了什么？** 我们已经为用户 `fake-user` 绑定了 `psp:unprivileged` 角色， +为什么还会收到错误 `Error creating: pods "pause-7774d79b5-" is +forbidden: no providers available to validate pod request +（创建错误：pods "pause-7774d79b5" 被禁止：没有可用来验证 pod 请求的驱动）`？ +答案在于源文件 - `replicaset-controller`。 +`fake-user` 用户成功地创建了 Deployment，而后者也成功地创建了 ReplicaSet， +不过当 ReplicaSet 创建 Pod 时，发现未被授权使用示例 PodSecurityPolicy 资源。 + + +为了修复这一问题，将 `psp:unprivileged` 角色绑定到 Pod 的服务账号。 +在这里，因为我们没有给出服务账号名称，默认的服务账号是 `default`。 + +```shell +kubectl-admin create rolebinding default:psp:unprivileged \ + --role=psp:unprivileged \ + --serviceaccount=psp-example:default +``` + +输出为： + +```none +rolebinding "default:psp:unprivileged" created +``` + + +现在如果你给 ReplicaSet 控制器一分钟的时间来重试，该控制器最终将能够 +成功地创建 Pod： + +```shell +kubectl-user get pods --watch +``` + +输出类似于： + +```none +NAME READY STATUS RESTARTS AGE +pause-7774d79b5-qrgcb 0/1 Pending 0 1s +pause-7774d79b5-qrgcb 0/1 Pending 0 1s +pause-7774d79b5-qrgcb 0/1 ContainerCreating 0 1s +pause-7774d79b5-qrgcb 1/1 Running 0 2s +``` + + +### 清理 {#clean-up} + +删除名字空间即可清理大部分示例资源： + +```shell +kubectl-admin delete ns psp-example +``` + +输出类似于： + +``` +namespace "psp-example" deleted +``` + + +注意 `PodSecurityPolicy` 资源不是名字空间域的资源，必须单独清理： + +```shell +kubectl-admin delete psp example +``` + +输出类似于： + +```none +podsecuritypolicy "example" deleted +``` + + +### 示例策略 {#example-policies} + +下面是一个你可以创建的约束性非常弱的策略，其效果等价于没有使用 Pod 安全策略准入控制器： + +{{< codenew file="policy/privileged-psp.yaml" >}} + + +下面是一个具有约束性的策略，要求用户以非特权账号运行，禁止可能的向 root 权限的升级， +同时要求使用若干安全机制。 + +{{< codenew file="policy/restricted-psp.yaml" >}} + + +更多的示例可参考 +[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/#policy-instantiation)。 + + +## 策略参考 {#policy-reference} + +### Privileged + +**Privileged** - 决定是否 Pod 中的某容器可以启用特权模式。 +默认情况下，容器是不可以访问宿主上的任何设备的，不过一个“privileged（特权的）” +容器则被授权访问宿主上所有设备。 +这种容器几乎享有宿主上运行的进程的所有访问权限。 +对于需要使用 Linux 权能字（如操控网络堆栈和访问设备）的容器而言是有用的。 + + +### 宿主名字空间 {#host-namespaces} + +**HostPID** - 控制 Pod 中容器是否可以共享宿主上的进程 ID 空间。 +注意，如果与 `ptrace` 相结合，这种授权可能被利用，导致向容器外的特权逃逸 +（默认情况下 `ptrace` 是被禁止的）。 + +**HostIPC** - 控制 Pod 容器是否可共享宿主上的 IPC 名字空间。 + +**HostNetwork** - 控制是否 Pod 可以使用节点的网络名字空间。 +此类授权将允许 Pod 访问本地回路（loopback）设备、在本地主机（localhost） +上监听的服务、还可能用来监听同一节点上其他 Pod 的网络活动。 + +**HostPorts** -提供可以在宿主网络名字空间中可使用的端口范围列表。 +该属性定义为一组 `HostPortRange` 对象的列表，每个对象中包含 +`min`（含）与 `max`（含）值的设置。 +默认不允许访问宿主端口。 + + +### 卷和文件系统 {#volumes-and-file-systems} + +**Volumes** - 提供一组被允许的卷类型列表。可被允许的值对应于创建卷时可以设置的卷来源。 +卷类型的完整列表可参见[卷类型](/zh/docs/concepts/storage/volumes/#types-of-volumes)。 +此外，`*` 可以用来允许所有卷类型。 + +对于新的 Pod 安全策略设置而言，建议设置的卷类型的**最小列表**包含： + +- `configMap` +- `downwardAPI` +- `emptyDir` +- `persistentVolumeClaim` +- `secret` +- `projected` + +{{< warning >}} + +PodSecurityPolicy 并不限制可以被 `PersistentVolumeClaim` 所引用的 +`PersistentVolume` 对象的类型。 +此外 `hostPath` 类型的 `PersistentVolume` 不支持只读访问模式。 +应该仅赋予受信用户创建 `PersistentVolume` 对象的访问权限。 +{{< /warning >}} + + +**FSGroup** - 控制应用到某些卷上的附加用户组。 + +- *MustRunAs* - 要求至少指定一个 `range`。 + 使用范围中的最小值作为默认值。所有 range 值都会被用来执行验证。 +- *MayRunAs* - 要求至少指定一个 `range`。 + 允许不设置 `FSGroups`，且无默认值。 + 如果 `FSGroup` 被设置，则所有 range 值都会被用来执行验证检查。 +- *RunAsAny* - 不提供默认值。允许设置任意 `fsGroup` ID 值。 + + +**AllowedHostPaths** - 设置一组宿主文件目录，这些目录项可以在 `hostPath` 卷中使用。 +列表为空意味着对所使用的宿主目录没有限制。 +此选项定义包含一个对象列表，表中对象包含 `pathPrefix` 字段，用来表示允许 +`hostPath` 卷挂载以所指定前缀开头的路径。 +对象中还包含一个 `readOnly` 字段，用来表示对应的卷必须以只读方式挂载。 +例如： + + +```yaml +allowedHostPaths: + # 下面的设置允许 "/foo"、"/foo/"、"/foo/bar" 等路径，但禁止 + # "/fool"、"/etc/foo" 这些路径。 + # "/foo/../" 总会被当作非法路径。 + - pathPrefix: "/foo" + readOnly: true # 仅允许只读模式挂载 +``` + +{{< warning >}} + +容器如果对宿主文件系统拥有不受限制的访问权限，就可以有很多种方式提升自己的特权， +包括读取其他容器中的数据、滥用系统服务（如 `kubelet`）的凭据信息等。 + + +由可写入的目录所构造的 `hostPath` 卷能够允许容器写入数据到宿主文件系统， +并且在写入时避开 `pathPrefix` 所设置的目录限制。 +`readOnly: true` 这一设置在 Kubernetes 1.11 版本之后可用。 +必须针对 `allowedHostPaths` 中的 *所有* 条目设置此属性才能有效地限制容器只能访问 +`pathPrefix` 所指定的目录。 +{{< /warning >}} + + +**ReadOnlyRootFilesystem** - 要求容器必须以只读方式挂载根文件系统来运行 +（即不允许存在可写入层）。 + + +### FlexVolume 驱动 {#flexvolume-drivers} + +此配置指定一个可以被 FlexVolume 卷使用的驱动程序的列表。 +空的列表或者 nil 值意味着对驱动没有任何限制。 +请确保[`volumes`](#volumes-and-file-systems) 字段包含了 `flexVolume` 卷类型， +否则所有 FlexVolume 驱动都被禁止。 + + + +```yaml +apiVersion: policy/v1beta1 +kind: PodSecurityPolicy +metadata: + name: allow-flex-volumes +spec: + # spec 的其他字段 + volumes: + - flexVolume + allowedFlexVolumes: + - driver: example/lvm + - driver: example/cifs +``` + + +### 用户和组 {#users-and-groups} + +**RunAsUser** - 控制使用哪个用户 ID 来运行容器。 + +- *MustRunAs* - 必须至少设置一个 `range`。使用该范围内的第一个值作为默认值。 + 所有范围值都会被验证检查。 + +- *MustRunAsNonRoot* - 要求提交的 Pod 具有非零 `runAsUser` 值，或在镜像中 + （使用 UID 数值）定义了 `USER` 环境变量。 + 如果 Pod 既没有设置 `runAsNonRoot`，也没有设置 `runAsUser`，则该 Pod + 会被修改以设置 `runAsNonRoot=true`，从而要求容器通过 `USER` 指令给出非零的数值形式的用户 ID。 + 此配置没有默认值。采用此配置时，强烈建议设置 `allowPrivilegeEscalation=false`。 +- *RunAsAny* - 没有提供默认值。允许指定任何 `runAsUser` 配置。 + + +**RunAsGroup** - 控制运行容器时使用的主用户组 ID。 + +- *MustRunAs* - 要求至少指定一个 `range` 值。第一个范围中的最小值作为默认值。 + 所有范围值都被用来执行验证检查。 +- *MayRunAs* - 不要求设置 `RunAsGroup`。 + 不过，如果指定了 `RunAsGroup` 被设置，所设置值必须处于所定义的范围内。 +- *RunAsAny* - 未指定默认值。允许 `runAsGroup` 设置任何值。 + + +**SupplementalGroups** - 控制容器可以添加的组 ID。 + +- *MustRunAs* - 要求至少指定一个 `range` 值。第一个范围中的最小值用作默认值。 + 所有范围值都被用来执行验证检查。 +- *MayRunAs* - 要求至少指定一个 `range` 值。 + 允许不指定 `supplementalGroups` 且不设置默认值。 + 如果 `supplementalGroups` 被设置，则所有 range 值都被用来执行验证检查。 +- *RunAsAny* - 未指定默认值。允许为 `supplementalGroups` 设置任何值。 + + +### 特权提升 {#privilege-escalation} + +这一组选项控制容器的`allowPrivilegeEscalation` 属性。该属性直接决定是否为容器进程设置 +[`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt) +参数。此参数会禁止 `setuid` 属性的可执行文件更改有效用户 ID（EUID）， +并且禁止启用额外权能的文件。例如，`no_new_privs` 会禁止使用 `ping` 工具。 +如果想有效地实施 `MustRunAsNonRoot` 控制，需要配置这一选项。 + + +**AllowPrivilegeEscalation** - 决定是否用户可以将容器的安全上下文设置为 +`allowPrivilegeEscalation=true`。默认设置下，这样做是允许的， +目的是避免造成现有的 `setuid` 应用无法运行。将此选项设置为 `false` +可以确保容器的所有子进程都无法获得比父进程更多的特权。 + + +**DefaultAllowPrivilegeEscalation** - 为 `allowPrivilegeEscalation` 选项设置默认值。 +不设置此选项时的默认行为是允许特权提升，以便运行 setuid 程序。 +如果不希望运行 setuid 程序，可以使用此字段将选项的默认值设置为禁止， +同时仍然允许 Pod 显式地请求 `allowPrivilegeEscalation`。 + + +### 权能字 {#capabilities} + +Linux 权能字（Capabilities）将传统上与超级用户相关联的特权作了细粒度的分解。 +其中某些权能字可以用来提升特权，打破容器边界，可以通过 PodSecurityPolicy 来限制。 +关于 Linux 权能字的更多细节，可参阅 +[capabilities(7)](http://man7.org/linux/man-pages/man7/capabilities.7.html)。 + +下列字段都可以配置为权能字的列表。表中的每一项都是 `ALL_CAPS` 中的一个权能字名称， +只是需要去掉 `CAP_` 前缀。 + + +**AllowedCapabilities** - 给出可以被添加到容器的权能字列表。 +默认的权能字集合是被隐式允许的那些。空集合意味着只能使用默认权能字集合， +不允许添加额外的权能字。`*` 可以用来设置允许所有权能字。 + + +**RequiredDropCapabilities** - 必须从容器中去除的权能字。 +所给的权能字会从默认权能字集合中去除，并且一定不可以添加。 +`RequiredDropCapabilities` 中列举的权能字不能出现在 +`AllowedCapabilities` 或 `DefaultAddCapabilities` 所给的列表中。 + + +**DefaultAddCapabilities** - 默认添加到容器的权能字集合。 +这一集合是作为容器运行时所设值的补充。 +关于使用 Docker 容器运行引擎时默认的权能字列表， +可参阅你的容器运行时的文档来了解使用 Linux 权能字的信息。 + + +### SELinux + +- *MustRunAs* - 要求必须配置 `seLinuxOptions`。默认使用 `seLinuxOptions`。 + 针对 `seLinuxOptions` 所给值执行验证检查。 +- *RunAsAny* - 没有提供默认值。允许任意指定的 `seLinuxOptions` 选项。 + + +### AllowedProcMountTypes + +`allowedProcMountTypes` 是一组可以允许的 proc 挂载类型列表。 +空表或者 nil 值表示只能使用 `DefaultProcMountType`。 + +`DefaultProcMount` 使用容器运行时的默认值设置来决定 `/proc` 的只读挂载模式和路径屏蔽。 +大多数容器运行时都会屏蔽 `/proc` 下面的某些路径以避免特殊设备或信息被不小心暴露给容器。 +这一配置使所有 `Default` 字符串值来表示。 + +此外唯一的ProcMountType 是 `UnmaskedProcMount`，意味着即将绕过容器运行时的路径屏蔽行为， +确保新创建的 `/proc` 不会被容器修改。此配置用字符串 `Unmasked` 来表示。 + + +### AppArmor + +通过 PodSecurityPolicy 上的注解来控制。 +详情请参阅 +[AppArmor 文档](/zh/docs/tutorials/policy/apparmor/#podsecuritypolicy-annotations)。 + + + +### Seccomp + +从 Kubernetes v1.19 开始，你可以使用 Pod 或容器的 `securityContext` 中的 `seccompProfile` +字段来[控制 seccomp 配置的使用](/zh/docs/tutorials/security/seccomp/)。 +在更早的版本中，seccomp 是通过为 Pod 添加注解来控制的。 +相同的 PodSecurityPolicy 可以用于不同版本，进而控制如何应用对应的字段或注解。 + +**seccomp.security.alpha.kubernetes.io/defaultProfileName** - +注解用来指定为容器配置默认的 seccomp 模版。可选值为： + + +- `unconfined` - 如果没有指定其他替代方案，Seccomp 不会被应用到容器进程上 + （Kubernets 中的默认设置）。 +- `runtime/default` - 使用默认的容器运行时模版。 +- `docker/default` - 使用 Docker 的默认 seccomp 模版。自 1.11 版本废弃。 + 应改为使用 `runtime/default`。 +- `localhost/<路径名>` - 指定节点上路径 `/<路径名>` 下的一个文件作为其模版。 + 其中 `` 是通过 `kubelet` 的标志 `--seccomp-profile-root` 来指定的。 + 如果未定义 `--seccomp-profile-root` 标志，则使用默认的路径 `/seccomp`， + 其中 `` 是通过 `--root-dir` 标志来设置的。 + + {{< note >}} + + 从 Kubernetes v1.19 开始，`--seccomp-profile-root` 标志已被启用。 + 用户应尝试使用默认路径。 + {{< /note >}} + + +**seccomp.security.alpha.kubernetes.io/allowedProfileNames** - 指定可以为 +Pod seccomp 注解配置的值的注解。取值为一个可用值的列表。 +表中每项可以是上述各值之一，还可以是 `*`，用来表示允许所有的模版。 +如果没有设置此注解，意味着默认的 seccomp 模版是不可更改的。 + + +### Sysctl + +默认情况下，所有的安全的 sysctl 都是被允许的。 + + +- `forbiddenSysctls` - 用来排除某些特定的 sysctl。 + 你可以在此列表中禁止一些安全的或者不安全的 sysctl。 + 此选项设置为 `*` 意味着禁止设置所有 sysctl。 +- `allowedUnsafeSysctls` - 用来启用那些被默认列表所禁用的 sysctl， + 前提是所启用的 sysctl 没有被列在 `forbiddenSysctls` 中。 + + +参阅 [Sysctl 文档](/zh/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy)。 + +## {{% heading "whatsnext" %}} + + +- 参阅 [PodSecurityPolicy Deprecation: Past, Present, and + Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)， + 了解 Pod 安全策略的未来。 + +- 参阅[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)， + 了解策略建议。 +- 阅读 [Pod 安全策略参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy)， + 了解 API 细节。 + diff --git a/content/zh/docs/concepts/security/pod-security-standards.md b/content/zh-cn/docs/concepts/security/pod-security-standards.md similarity index 95% rename from content/zh/docs/concepts/security/pod-security-standards.md rename to content/zh-cn/docs/concepts/security/pod-security-standards.md index e2e6d7890f..4bd324ceb0 100644 --- a/content/zh/docs/concepts/security/pod-security-standards.md +++ b/content/zh-cn/docs/concepts/security/pod-security-standards.md @@ -1,5 +1,7 @@ --- title: Pod 安全性标准 +description: > + 详细了解 Pod 安全性标准（Pod Security Standards）中所定义的不同策略级别。 content_type: concept weight: 10 --- @@ -7,6 +9,8 @@ weight: 10 reviewers: - tallclair title: Pod Security Standards +description: > + A detailed look at the different policy levels defined in the Pod Security Standards. content_type: concept weight: 10 --> @@ -49,18 +53,17 @@ Pod 安全性标准定义了三种不同的 _策略（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 profile may be an absence of applied constraints -rather than an instantiated policy. 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. --> **_Privileged_ 策略是有目的地开放且完全无限制的策略。** 此类策略通常针对由特权较高、受信任的用户所管理的系统级或基础设施级负载。 -Privileged 策略定义中限制较少。对于默认允许（Allow-by-default）实施机制（例如 gatekeeper）， -Privileged 框架可能意味着不应用任何约束而不是实施某策略实例。 -与此不同，对于默认拒绝（Deny-by-default）实施机制（如 Pod 安全策略）而言， -Privileged 策略应该默认允许所有控制（即，禁止所有限制）。 +Privileged 策略定义中限制较少。默认允许的（Allow-by-default）实施机制（例如 gatekeeper） +可以缺省设置为 Privileged。 +与此不同，对于默认拒绝（Deny-by-default）的实施机制（如 Pod 安全策略）而言， +Privileged 策略应该禁止所有限制。 ### Baseline @@ -842,6 +845,22 @@ 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 %}} + + +在 Kubernetes 生态系统中还在开发一些其他的替代方案，例如： + +- [Kubewarden](https://github.com/kubewarden) +- [Kyverno](https://kyverno.io/policies/pod-security/) +- [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper) + 安全策略则是控制面用来对安全上下文以及安全性上下文之外的参数实施某种设置的机制。 在 2020 年 7 月， [Pod 安全性策略](/zh/docs/concepts/security/pod-security-policy/)已被废弃， 取而代之的是内置的 [Pod 安全性准入控制器](/zh/docs/concepts/security/pod-security-admission/)。 -Kubernetes 生态系统中还在开发一些其他的替代方案，例如 -- [OPA Gatekeeper](https://github.com/open-policy-agent/gatekeeper)。 -- [Kubewarden](https://github.com/kubewarden)。 -- [Kyverno](https://kyverno.io/policies/pod-security/)。 - - 如果你为一个 Windows Pod 应用了 Restricted 策略，**可能会** 对该 Pod 的运行时产生影响。 Restricted 策略需要强制执行 Linux 特有的限制（如 seccomp Profile，并且禁止特权提升）。 如果 kubelet 和/或其容器运行时忽略了 Linux 特有的值，那么应该不影响 Windows Pod 正常工作。 然而，对于使用 Windows 容器的 Pod 来说，缺乏强制执行意味着相比于 Restricted 策略，没有任何额外的限制。 + 你应该只在 Privileged 策略下使用 HostProcess 标志来创建 HostProcess Pod。 在 Baseline 和 Restricted 策略下，创建 Windows HostProcess Pod 是被禁止的， 因此任何 HostProcess Pod 都应该被认为是有特权的。 @@ -945,7 +952,14 @@ Restricted 策略需要强制执行 Linux 特有的限制（如 seccomp Profile There is not currently an API standard that controls whether a Pod is considered sandboxed or not. Sandbox Pods may be identified by the use of a sandboxed runtime (such as gVisor or Kata Containers), but there is no standard definition of what a sandboxed runtime is. +--> +### 沙箱（Sandboxed） Pod 怎么处理？ +现在还没有 API 标准来控制 Pod 是否被视作沙箱化 Pod。 +沙箱 Pod 可以通过其是否使用沙箱化运行时（如 gVisor 或 Kata Container）来辨别， +不过目前还没有关于什么是沙箱化运行时的标准定义。 + + -### 沙箱（Sandboxed） Pod 怎么处理？ - -现在还没有 API 标准来控制 Pod 是否被视作沙箱化 Pod。 -沙箱 Pod 可以通过其是否使用沙箱化运行时（如 gVisor 或 Kata Container）来辨别，不过 -目前还没有关于什么是沙箱化运行时的标准定义。 - 沙箱化负载所需要的保护可能彼此各不相同。例如，当负载与下层内核直接隔离开来时， 限制特权化操作的许可就不那么重要。这使得那些需要更多许可权限的负载仍能被有效隔离。 此外，沙箱化负载的保护高度依赖于沙箱化的实现方法。 因此，现在还没有针对所有沙箱化负载的建议策略。 + diff --git a/content/zh-cn/docs/concepts/security/rbac-good-practices.md b/content/zh-cn/docs/concepts/security/rbac-good-practices.md new file mode 100644 index 0000000000..07f54b9b32 --- /dev/null +++ b/content/zh-cn/docs/concepts/security/rbac-good-practices.md @@ -0,0 +1,355 @@ +--- +title: 基于角色的访问控制良好实践 +description: > + 为集群操作人员提供的良好的 RBAC 设计原则和实践。 +content_type: concept +--- + + + + + + + +Kubernetes {{< glossary_tooltip text="RBAC" term_id="rbac" >}} +是一项重要的安全控制措施，用于保证集群用户和工作负载只能访问履行自身角色所需的资源。 +在为集群用户设计权限时，请务必确保集群管理员知道可能发生特权提级的地方， +降低因过多权限而导致安全事件的风险。 + +此文档的良好实践应该与通用 +[RBAC 文档](/zh/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update)一起阅读。 + + + + +## 通用的良好实践 {#general-good-practice} + +### 最小特权 {#least-privilege} + + +理想情况下，分配给用户和服务帐户的 RBAC 权限应该是最小的。 +仅应使用操作明确需要的权限，虽然每个集群会有所不同，但可以应用的一些常规规则： + + +- 尽可能在命名空间级别分配权限。授予用户在特定命名空间中的权限时使用 RoleBinding + 而不是 ClusterRoleBinding。 +- 尽可能避免通过通配符设置权限，尤其是对所有资源的权限。 + 由于 Kubernetes 是一个可扩展的系统，因此通过通配符来授予访问权限不仅会授予集群中当前的所有对象类型， + 还包含所有未来被创建的所有对象类型。 +- 管理员不应使用 `cluster-admin` 账号，除非特别需要。为低特权帐户提供 + [伪装权限](/zh/docs/reference/access-authn-authz/authentication/#user-impersonation) + 可以避免意外修改集群资源。 +- 避免将用户添加到 `system:masters` 组。任何属于此组成员的用户都会绕过所有 RBAC 权限检查， + 始终具有不受限制的超级用户访问权限，并且不能通过删除 `RoleBinding` 或 `ClusterRoleBinding` + 来取消其权限。顺便说一句，如果集群是使用 Webhook 鉴权，此组的成员身份也会绕过该 + Webhook（来自属于该组成员的用户的请求永远不会发送到 Webhook）。 + + +### 最大限度地减少特权令牌的分发 {#minimize-distribution-of-privileged-tokens} + + +理想情况下，不应为 Pod 分配具有强大权限（例如，在[特权提级的风险](#privilege-escalation-risks)中列出的任一权限）的服务帐户。 +如果工作负载需要比较大的权限，请考虑以下做法： +- 限制运行此类 Pod 的节点数量。确保你运行的任何 DaemonSet 都是必需的， + 并且以最小权限运行，以限制容器逃逸的影响范围。 +- 避免将此类 Pod 与不可信任或公开的 Pod 在一起运行。 + 考虑使用[污点和容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)、 + [节点亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)或 + [Pod 反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)确保 + Pod 不会与不可信或不太受信任的 Pod 一起运行。 + 特别注意可信度不高的 Pod 不符合 **Restricted** Pod 安全标准的情况。 + +### 加固 {#hardening} + +Kubernetes 默认提供访问权限并非是每个集群都需要的。 +审查默认提供的 RBAC 权限为安全加固提供了机会。 +一般来说，不应该更改 `system:` 帐户的某些权限，有一些方式来强化现有集群的权限： + + +- 审查 `system:unauthenticated` 组的绑定，并在可能的情况下将其删除， + 因为这会给所有能够访问 API 服务器的人以网络级别的权限。 +- 通过设置 `automountServiceAccountToken: false` 来避免服务账号令牌的默认自动挂载， + 有关更多详细信息，请参阅[使用默认服务账号令牌](/zh/docs/tasks/configure-pod-container/configure-service-account/#use-the-default-service-account-to-access-the-api-server)。 + 此参数可覆盖 Pod 服务账号设置，而需要服务账号令牌的工作负载仍可以挂载。 + + +### 定期检查 {#periodic-review} +定期检查 Kubernetes RBAC 设置是否有冗余条目和提权可能性是至关重要的。 +如果攻击者能够创建与已删除用户同名的用户账号， +他们可以自动继承被删除用户的所有权限，尤其是分配给该用户的权限。 + + +## Kubernetes RBAC - 权限提权的风险 {#privilege-escalation-risks} + +在 Kubernetes RBAC 中有许多特权，如果被授予， +用户或服务帐户可以提升其在集群中的权限并可能影响集群外的系统。 + +本节旨在提醒集群操作员需要注意的不同领域， +以确保他们不会无意中授予超出预期的集群访问权限。 + + +### 列举 Secret {#listing-secrets} + +大家都很清楚，若允许对 Secrets 执行 `get` 访问，用户就获得了访问 Secret 内容的能力。 +同样需要注意的是：`list` 和 `watch` 访问也会授权用户获取 Secret 的内容。 +例如，当返回 List 响应时（例如，通过 +`kubectl get secrets -A -o yaml`），响应包含所有 Secret 的内容。 + + +### 工作负载的创建 {#workload-creation} + +能够创建工作负载的用户（Pod 或管理 Pod 的[工作负载资源](/zh/docs/concepts/workloads/controllers/)） +能够访问下层的节点，除非基于 Kubernetes 的 +[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)做限制。 + + +可以运行特权 Pod 的用户可以利用该访问权限获得节点访问权限， +并可能进一步提升他们的特权。如果你不完全信任某用户或其他主体， +不相信他们能够创建比较安全且相互隔离的 Pod，你应该强制实施 **Baseline** +或 **Restricted** Pod 安全标准。 +你可以使用 [Pod 安全性准入](/zh/docs/concepts/security/pod-security-admission/)或其他（第三方）机制来强制实施这些限制。 + + +你还可以使用已弃用的 [PodSecurityPolicy](/zh/docs/concepts/policy/pod-security-policy/) +机制以限制用户创建特权 Pod 的能力 （特别注意：PodSecurityPolicy 已计划在版本 1.25 中删除）。 + + +在命名空间中创建工作负载还会授予对该命名空间中 Secret 的间接访问权限。 +在 kube-system 或类似特权的命名空间中创建 Pod +可以授予用户不需要通过 RBAC 即可获取 Secret 访问权限。 + + +### 持久卷的创建 {#persistent-volume-creation} + +如 [PodSecurityPolicy](/zh/docs/concepts/policy/pod-security-policy/#volumes-and-file-systems) +文档中所述，创建 PersistentVolumes 的权限可以提权访问底层主机。 +如果需要访问 PersistentVolume，受信任的管理员应该创建 `PersistentVolume`， +受约束的用户应该使用 `PersistentVolumeClaim` 访问该存储。 + + +### 访问 Node 的 `proxy` 子资源 {#access-to-proxy-subresource-of-nodes} + +有权访问 Node 对象的 proxy 子资源的用户有权访问 Kubelet API， +这允许在他们有权访问的节点上的所有 Pod 上执行命令。 +此访问绕过审计日志记录和准入控制，因此在授予对此资源的权限前应小心。 + + +### esclate 动词 {#escalate-verb} +通常，RBAC 系统会阻止用户创建比他所拥有的更多权限的 `ClusterRole`。 +而 `escalate` 动词是个例外。如 +[RBAC 文档](/zh/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update) +中所述，拥有此权限的用户可以有效地提升他们的权限。 + + +### bind 动词 {#bind-verb} + +与 `escalate` 动作类似，授予此权限的用户可以绕过 Kubernetes +对权限提升的内置保护，用户可以创建并绑定尚不具有的权限的角色。 + + +### impersonate 动词 {#impersonate-verb} + +此动词允许用户伪装并获得集群中其他用户的权限。 +授予它时应小心，以确保通过其中一个伪装账号不会获得过多的权限。 + + +### CSR 和证书颁发 {#csrs-and-certificate-issuing} + +CSR API 允许用户拥有 `create` CSR 的权限和 `update` +`certificatesigningrequests/approval` 的权限， +其中签名者是 `kubernetes.io/kube-apiserver-client`， +通过此签名创建的客户端证书允许用户向集群进行身份验证。 +这些客户端证书可以包含任意的名称，包括 Kubernetes 系统组件的副本。 +这将有利于特权提级。 + + +### 令牌请求 {#token-request} + +拥有 `serviceaccounts/token` 的 `create` 权限的用户可以创建 +TokenRequest 来发布现有服务帐户的令牌。 + + +### 控制准入 Webhook {#control-admission-webhooks} + +可以控制 `validatingwebhookconfigurations` 或 `mutatingwebhookconfigurations` +的用户可以控制能读取任何允许进入集群的对象的 webhook， +并且在有变更 webhook 的情况下，还可以变更准入的对象。 + + +## Kubernetes RBAC - 拒绝服务攻击的风险 {#denial-of-service-risks} + +### 对象创建拒绝服务 {#object-creation-dos} +有权在集群中创建对象的用户根据创建对象的大小和数量可能会创建足够大的对象， +产生拒绝服务状况，如 [Kubernetes 使用的 etcd 容易受到 OOM 攻击](https://github.com/kubernetes/kubernetes/issues/107325)中的讨论。 +允许太不受信任或者不受信任的用户对系统进行有限的访问在多租户集群中是特别重要的。 + +缓解此问题的一种选择是使用[资源配额](/zh/docs/concepts/policy/resource-quotas/#object-count-quota)以限制可以创建的对象数量。 \ No newline at end of file diff --git a/content/zh-cn/docs/concepts/security/windows-security.md b/content/zh-cn/docs/concepts/security/windows-security.md new file mode 100644 index 0000000000..9527297be0 --- /dev/null +++ b/content/zh-cn/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-cn/docs/concepts/windows/intro/#compatibility-v1-pod-spec-containers-securitycontext)特权容器。 +然而，可以在 Windows 上使用 [HostProcess 容器](/zh-cn/docs/tasks/configure-pod-container/create-hostprocess-pod)来执行 +Linux 上特权容器执行的许多任务。 diff --git a/content/zh/docs/concepts/services-networking/_index.md b/content/zh-cn/docs/concepts/services-networking/_index.md similarity index 72% rename from content/zh/docs/concepts/services-networking/_index.md rename to content/zh-cn/docs/concepts/services-networking/_index.md index 01d327577f..0f92a136d2 100644 --- a/content/zh/docs/concepts/services-networking/_index.md +++ b/content/zh-cn/docs/concepts/services-networking/_index.md @@ -7,43 +7,46 @@ description: Kubernetes 网络背后的概念和资源。 ## Kubernetes 网络模型 {#the-kubernetes-network-model} -每一个 [`Pod`](/zh/docs/concepts/workloads/pods/) 都有它自己的IP地址， -这就意味着你不需要显式地在 `Pod` 之间创建链接， 你几乎不需要处理容器端口到主机端口之间的映射。 +集群中每一个 [`Pod`](/zh-cn/docs/concepts/workloads/pods/) 都会获得自己的、 +独一无二的 IP 地址， +这就意味着你不需要显式地在 `Pod` 之间创建链接，你几乎不需要处理容器端口到主机端口之间的映射。 这将形成一个干净的、向后兼容的模型；在这个模型里，从端口分配、命名、服务发现、 -[负载均衡](/zh/docs/concepts/services-networking/ingress/#load-balancing)、应用配置和迁移的角度来看， -`Pod` 可以被视作虚拟机或者物理主机。 +[负载均衡](/zh/docs/concepts/services-networking/ingress/#load-balancing)、 +应用配置和迁移的角度来看，`Pod` 可以被视作虚拟机或者物理主机。 + Kubernetes 强制要求所有网络设施都满足以下基本要求（从而排除了有意隔离网络的策略）： -* [节点](/zh/docs/concepts/architecture/nodes/)上的 Pod 可以不通过 NAT 和其他任何节点上的 Pod 通信 + +* Pod 能够与所有其他[节点](/zh-cn/docs/concepts/architecture/nodes/)上的 Pod 通信， + 且不需要网络地址转译（NAT） * 节点上的代理（比如：系统守护进程、kubelet）可以和节点上的所有 Pod 通信 -备注：对于支持在主机网络中运行 `Pod` 的平台（比如：Linux）： - -* 运行在节点主机网络里的 Pod 可以不通过 NAT 和所有节点上的 Pod 通信 + +说明：对于支持在主机网络中运行 `Pod` 的平台（比如：Linux）， +当 Pod 挂接到节点的宿主网络上时，它们仍可以不通过 NAT 和所有节点上的 Pod 通信。 Kubernetes 网络解决四方面的问题： -- 一个 Pod 中的容器之间[通过本地回路（loopback）通信](/zh/docs/concepts/services-networking/dns-pod-service/)。 + +- 一个 Pod 中的容器之间[通过本地回路（loopback）通信](/zh-cn/docs/concepts/services-networking/dns-pod-service/)。 - 集群网络在不同 pod 之间提供通信。 -- [Service 资源](/zh/docs/concepts/services-networking/service/)允许你 - [对外暴露 Pods 中运行的应用程序](/zh/docs/concepts/services-networking/connect-applications-service/)， +- [Service 资源](/zh-cn/docs/concepts/services-networking/service/)允许你 + [向外暴露 Pods 中运行的应用](/zh-cn/docs/concepts/services-networking/connect-applications-service/)， 以支持来自于集群外部的访问。 -- 可以使用 Services 来[发布仅供集群内部使用的服务](/zh/docs/concepts/services-networking/service-traffic-policy/)。 +- 可以使用 Services 来[发布仅供集群内部使用的服务](/zh-cn/docs/concepts/services-networking/service-traffic-policy/)。 diff --git a/content/zh/docs/concepts/services-networking/connect-applications-service.md b/content/zh-cn/docs/concepts/services-networking/connect-applications-service.md similarity index 100% rename from content/zh/docs/concepts/services-networking/connect-applications-service.md rename to content/zh-cn/docs/concepts/services-networking/connect-applications-service.md diff --git a/content/zh/docs/concepts/services-networking/dns-pod-service.md b/content/zh-cn/docs/concepts/services-networking/dns-pod-service.md similarity index 70% rename from content/zh/docs/concepts/services-networking/dns-pod-service.md rename to content/zh-cn/docs/concepts/services-networking/dns-pod-service.md index 2b9dfeb36f..2bee2ba425 100644 --- a/content/zh/docs/concepts/services-networking/dns-pod-service.md +++ b/content/zh-cn/docs/concepts/services-networking/dns-pod-service.md @@ -15,11 +15,11 @@ weight: 20 -Kubernetes 为服务和 Pods 创建 DNS 记录。 -你可以使用一致的 DNS 名称而非 IP 地址来访问服务。 +Kubernetes 为 Service 和 Pod 创建 DNS 记录。 +你可以使用一致的 DNS 名称而非 IP 地址访问 Service。 @@ -30,40 +30,39 @@ Kubernetes DNS schedules a DNS Pod and Service on the cluster, and configures the kubelets to tell individual containers to use the DNS Service's IP to resolve DNS names. --> -## 介绍 +## 介绍 {#introduction} -Kubernetes DNS 在集群上调度 DNS Pod 和服务，并配置 kubelet 以告知各个容器 -使用 DNS 服务的 IP 来解析 DNS 名称。 +Kubernetes DNS 除了在集群上调度 DNS Pod 和 Service， +还配置 kubelet 以告知各个容器使用 DNS Service 的 IP 来解析 DNS 名称。 集群中定义的每个 Service （包括 DNS 服务器自身）都被赋予一个 DNS 名称。 -默认情况下，客户端 Pod 的 DNS 搜索列表会包含 Pod 自身的名字空间和集群 -的默认域。 +默认情况下，客户端 Pod 的 DNS 搜索列表会包含 Pod 自身的名字空间和集群的默认域。 -### Service 的名字空间 +### Service 的名字空间 {#namespaces-of-services} DNS 查询可能因为执行查询的 Pod 所在的名字空间而返回不同的结果。 不指定名字空间的 DNS 查询会被限制在 Pod 所在的名字空间内。 -要访问其他名字空间中的服务，需要在 DNS 查询中给出名字空间。 +要访问其他名字空间中的 Service，需要在 DNS 查询中指定名字空间。 例如，假定名字空间 `test` 中存在一个 Pod，`prod` 名字空间中存在一个服务 `data`。 @@ -73,11 +72,11 @@ Pod 查询 `data` 时没有返回结果，因为使用的是 Pod 的名字空间 Pod 查询 `data.prod` 时则会返回预期的结果，因为查询中指定了名字空间。 DNS 查询可以使用 Pod 中的 `/etc/resolv.conf` 展开。kubelet 会为每个 Pod 生成此文件。例如，对 `data` 的查询可能被展开为 `data.test.svc.cluster.local`。 @@ -91,7 +90,7 @@ options ndots:5 ``` 概括起来，名字空间 `test` 中的 Pod 可以成功地解析 `data.prod` 或者 @@ -116,7 +115,7 @@ considered implementation details and are subject to change without warning. For more up-to-date specification, see [Kubernetes DNS-Based Service Discovery](https://github.com/kubernetes/dns/blob/master/docs/specification.md). --> -以下各节详细介绍了被支持的 DNS 记录类型和被支持的布局。 +以下各节详细介绍已支持的 DNS 记录类型和布局。 其它布局、名称或者查询即使碰巧可以工作，也应视为实现细节， 将来很可能被更改而且不会因此发出警告。 有关最新规范请查看 @@ -127,28 +126,30 @@ 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 -Services, this resolves to the set of IPs of the pods selected by 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 +`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. --> -### 服务 {#services} +### Services -#### A/AAAA 记录 +#### A/AAAA 记录 {#a-aaaa-records} -“普通” 服务（除了无头服务）会以 `my-svc.my-namespace.svc.cluster-domain.example` -这种名字的形式被分配一个 DNS A 或 AAAA 记录，取决于服务的 IP 协议族。 -该名称会解析成对应服务的集群 IP。 +“普通” Service（除了无头 Service）会以 `my-svc.my-namespace.svc.cluster-domain.example` +这种名字的形式被分配一个 DNS A 或 AAAA 记录，取决于 Service 的 IP 协议族。 +该名称会解析成对应 Service 的集群 IP。 -“无头（Headless）” 服务（没有集群 IP）也会以 +“无头（Headless）” Service （没有集群 IP）也会以 `my-svc.my-namespace.svc.cluster-domain.example` 这种名字的形式被指派一个 DNS A 或 AAAA 记录， -具体取决于服务的 IP 协议族。 -与普通服务不同，这一记录会被解析成对应服务所选择的 Pod 集合的 IP。 +具体取决于 Service 的 IP 协议族。 +与普通 Service 不同，这一记录会被解析成对应 Service 所选择的 Pod IP 的集合。 客户端要能够使用这组 IP，或者使用标准的轮转策略从这组 IP 中进行选择。 #### SRV 记录 {#srv-records} -Kubernetes 会为命名端口创建 SRV 记录，这些端口是普通服务或 -[无头服务](/zh/docs/concepts/services-networking/service/#headless-services)的一部分。 -对每个命名端口，SRV 记录具有 `_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example` 这种形式。 -对普通服务，该记录会被解析成端口号和域名：`my-svc.my-namespace.svc.cluster-domain.example`。 -对无头服务，该记录会被解析成多个结果，服务对应的每个后端 Pod 各一个； -其中包含 Pod 端口号和形为 `auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example` +Kubernetes 根据普通 Service 或 +[Headless Service](/zh/docs/concepts/services-networking/service/#headless-services) +中的命名端口创建 SRV 记录。每个命名端口， +SRV 记录格式为 `_my-port-name._my-port-protocol.my-svc.my-namespace.svc.cluster-domain.example`。 +普通 Service，该记录会被解析成端口号和域名：`my-svc.my-namespace.svc.cluster-domain.example`。 +无头 Service，该记录会被解析成多个结果，及该服务的每个后端 Pod 各一个 SRV 记录， +其中包含 Pod 端口号和格式为 `auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example` 的域名。 ## Pods @@ -179,20 +181,20 @@ Kubernetes 会为命名端口创建 SRV 记录，这些端口是普通服务或 -### A/AAAA 记录 +### A/AAAA 记录 {#a-aaaa-records} 一般而言，Pod 会对应如下 DNS 名字解析： @@ -210,11 +212,11 @@ Any pods exposed by a Service have the following DNS resolution available: -### Pod 的 hostname 和 subdomain 字段 +### Pod 的 hostname 和 subdomain 字段 {#pod-s-hostname-and-subdomain-fields} 当前，创建 Pod 时其主机名取自 Pod 的 `metadata.name` 值。 @@ -288,21 +290,21 @@ spec: ``` -如果某无头服务与某 Pod 在同一个名字空间中，且它们具有相同的子域名， +如果某无头 Service 与某 Pod 在同一个名字空间中，且它们具有相同的子域名， 集群的 DNS 服务器也会为该 Pod 的全限定主机名返回 A 记录或 AAAA 记录。 例如，在同一个名字空间中，给定一个主机名为 “busybox-1”、 子域名设置为 “default-subdomain” 的 Pod，和一个名称为 “`default-subdomain`” -的无头服务，Pod 将看到自己的 FQDN 为 +的无头 Service，Pod 将看到自己的 FQDN 为 "`busybox-1.default-subdomain.my-namespace.svc.cluster-domain.example`"。 DNS 会为此名字提供一个 A 记录或 AAAA 记录，指向该 Pod 的 IP。 “`busybox1`” 和 “`busybox2`” 这两个 Pod 分别具有它们自己的 A 或 AAAA 记录。 @@ -314,18 +316,16 @@ along with its IP. Endpoints 对象可以为任何端点地址及其 IP 指定 `hostname`。 {{< note >}} -因为没有为 Pod 名称创建 A 记录或 AAAA 记录，所以要创建 Pod 的 A 记录 -或 AAAA 记录需要 `hostname`。 - +由于不是为 Pod 名称创建 A 或 AAAA 记录的，因此 Pod 的 A 或 AAAA 需要 `hostname`。 没有设置 `hostname` 但设置了 `subdomain` 的 Pod 只会为 -无头服务创建 A 或 AAAA 记录（`default-subdomain.my-namespace.svc.cluster-domain.example`） +无头 Service 创建 A 或 AAAA 记录（`default-subdomain.my-namespace.svc.cluster-domain.example`） 指向 Pod 的 IP 地址。 另外，除非在服务上设置了 `publishNotReadyAddresses=True`，否则只有 Pod 进入就绪状态 才会有与之对应的记录。 @@ -341,12 +341,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 所在名字空间。 @@ -356,7 +357,7 @@ When a Pod is configured to have fully qualified domain name (FQDN), its hostnam 在 Linux 中，内核的主机名字段（`struct utsname` 的 `nodename` 字段）限定 最多 64 个字符。 @@ -364,7 +365,7 @@ If a Pod enables this feature and its FQDN is longer than 64 character, it will 如果 Pod 启用这一特性，而其 FQDN 超出 64 字符，Pod 的启动会失败。 Pod 会一直出于 `Pending` 状态（通过 `kubectl` 所看到的 `ContainerCreating`）， 并产生错误事件，例如 -"Failed to construct FQDN from pod hostname and cluster domain, FQDN +"Failed to construct FQDN from Pod hostname and cluster domain, FQDN `long-FQDN` is too long (64 characters is the max, 70 characters requested)." （无法基于 Pod 主机名和集群域名构造 FQDN，FQDN `long-FQDN` 过长，至多 64 字符，请求字符数为 70）。 @@ -376,12 +377,12 @@ Pod 会一直出于 `Pending` 状态（通过 `kubectl` 所看到的 `ContainerC ### Pod 的 DNS 策略 {#pod-s-dns-policy} @@ -411,6 +413,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 +453,7 @@ spec: ``` -输出类似于 - +输出类似于： ``` nameserver fd00:79:30::a search default.svc.cluster-domain.example svc.cluster-domain.example cluster-domain.example @@ -565,6 +567,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 后缀的 Services 或者网络名称。 + 例如，在 `default` 命名空间中生成一个 Pod，该 Pod 会获得的 DNS 后缀为 `default.svc.cluster.local`。 + 在 Windows 的 Pod 中，你可以解析 `kubernetes.default.svc.cluster.local` 和 `kubernetes`， + 但是不能解析部分限定名称（`kubernetes.default` 和 `kubernetes.default.svc`）。 + ## {{% heading "whatsnext" %}} @@ -29,14 +28,16 @@ weight: 70 {{< feature-state for_k8s_version="v1.23" state="stable" >}} IPv4/IPv6 双协议栈网络能够将 IPv4 和 IPv6 地址分配给 {{< glossary_tooltip text="Pod" term_id="pod" >}} 和 {{< glossary_tooltip text="Service" term_id="service" >}}。 从 1.21 版本开始，Kubernetes 集群默认启用 IPv4/IPv6 双协议栈网络， 以支持同时分配 IPv4 和 IPv6 地址。 @@ -54,9 +55,9 @@ IPv4/IPv6 dual-stack on your Kubernetes cluster provides the following features: Kubernetes 集群的 IPv4/IPv6 双协议栈可提供下面的功能： * 双协议栈 pod 网络 (每个 pod 分配一个 IPv4 和 IPv6 地址) * IPv4 和 IPv6 启用的服务 @@ -73,49 +74,54 @@ The following prerequisites are needed in order to utilize IPv4/IPv6 dual-stack 为了使用 IPv4/IPv6 双栈的 Kubernetes 集群，需要满足以下先决条件： * Kubernetes 1.20 版本或更高版本，有关更早 Kubernetes 版本的使用双栈服务的信息， 请参考对应版本的 Kubernetes 文档。 * 提供商支持双协议栈网络（云提供商或其他提供商必须能够为 Kubernetes 节点提供可路由的 IPv4/IPv6 网络接口） -* 支持双协议栈的[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) +* 支持双协议栈的[网络插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) ## 配置 IPv4/IPv6 双协议栈 - +如果配置 IPv4/IPv6 双栈，请分配双栈集群网络： + * kube-apiserver: * `--service-cluster-ip-range=,` * kube-controller-manager: * `--cluster-cidr=,` * `--service-cluster-ip-range=,` - * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` 对于 IPv4 默认为 /24，对于 IPv6 默认为 /64 + * `--node-cidr-mask-size-ipv4|--node-cidr-mask-size-ipv6` 对于 IPv4 默认为 /24， + 对于 IPv6 默认为 /64 * kube-proxy: * `--cluster-cidr=,` * kubelet: @@ -128,7 +134,8 @@ The following prerequisites are needed in order to utilize IPv4/IPv6 dual-stack IPv4 CIDR 的一个例子：`10.244.0.0/16`（尽管你会提供你自己的地址范围）。 @@ -139,31 +146,35 @@ IPv6 CIDR 的一个例子：`fdXY:IJKL:MNOP:15::/64` -## 服务 +## 服务 {#services} 你可以使用 IPv4 或 IPv6 地址来创建 {{< glossary_tooltip text="Service" term_id="service" >}}。 + 服务的地址族默认为第一个服务集群 IP 范围的地址族（通过 kube-apiserver 的 `--service-cluster-ip-range` 参数配置）。 + 当你定义服务时，可以选择将其配置为双栈。若要指定所需的行为，你可以设置 `.spec.ipFamilyPolicy` 字段为以下值之一： - * `SingleStack`：单栈服务。控制面使用第一个配置的服务集群 IP 范围为服务分配集群 IP。 * `PreferDualStack`： * 为服务分配 IPv4 和 IPv6 集群 IP 地址。 @@ -172,14 +183,18 @@ set the `.spec.ipFamilyPolicy` field to one of the following values: 列表中选择 `.spec.ClusterIP` 如果你想要定义哪个 IP 族用于单栈或定义双栈 IP 族的顺序，可以通过设置 服务上的可选字段 `.spec.ipFamilies` 来选择地址族。 {{< note >}} `.spec.ipFamilies` 字段是不可变的，因为系统无法为已经存在的服务重新分配 `.spec.ClusterIP`。如果你想改变 `.spec.ipFamilies`，则需要删除并重新创建服务。 @@ -195,7 +210,6 @@ You can set `.spec.ipFamilies` to any of the following array values: - `["IPv6"]` - `["IPv4","IPv6"]` (dual stack) - `["IPv6","IPv4"]` (dual stack) - --> - `["IPv4"]` - `["IPv6"]` @@ -212,35 +226,46 @@ The first family you list is used for the legacy `.spec.ClusterIP` field. These examples demonstrate the behavior of various dual-stack Service configuration scenarios. --> -### 双栈服务配置场景 +### 双栈服务配置场景 {#dual-stack-service-configuration-scenarios} 以下示例演示多种双栈服务配置场景下的行为。 -#### 新服务的双栈选项 +#### 新服务的双栈选项 {#dual-stack-options-on-new-services} - 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)的行为方式 + （[无选择算符的服务](/zh-cn/docs/concepts/services-networking/service/#services-without-selectors) + 和[无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services)的行为方式 与此相同。） - + {{< codenew file="service/networking/dual-stack-default-svc.yaml" >}} 2. 此服务规约显式地将 `.spec.ipFamilyPolicy` 设置为 `PreferDualStack`。 当你在双栈集群上创建此服务时，Kubernetes 会为该服务分配 IPv4 和 IPv6 地址。 @@ -258,7 +283,10 @@ These examples demonstrate the behavior of various dual-stack Service configurat {{< codenew file="service/networking/dual-stack-preferred-svc.yaml" >}} 3. 下面的服务规约显式地在 `.spec.ipFamilies` 中指定 `IPv6` 和 `IPv4`，并 将 `.spec.ipFamilyPolicy` 设定为 `PreferDualStack`。 @@ -271,16 +299,21 @@ These examples demonstrate the behavior of various dual-stack Service configurat -#### 现有服务的双栈默认值 +#### 现有服务的双栈默认值 {#dual-stack-defaults-on-existing-services} 下面示例演示了在服务已经存在的集群上新启用双栈时的默认行为。 （将现有集群升级到 1.21 或者更高版本会启用双协议栈支持。） 1. 在集群上启用双栈时，控制面会将现有服务（无论是 `IPv4` 还是 `IPv6`）配置 `.spec.ipFamilyPolicy` 为 `SingleStack` 并设置 `.spec.ipFamilies` @@ -296,7 +329,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 @@ -323,10 +356,15 @@ These examples demonstrate the default behavior when dual-stack is newly enabled ``` 2. 在集群上启用双栈时，带有选择算符的现有 - [无头服务](/zh/docs/concepts/services-networking/service/#headless-services) + [无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services) 由控制面设置 `.spec.ipFamilyPolicy` 为 `SingleStack` 并设置 `.spec.ipFamilies` 为第一个服务集群 IP 范围的地址族（通过配置 kube-apiserver 的 `--service-cluster-ip-range` 参数），即使 `.spec.ClusterIP` 的设置值为 `None` 也如此。 @@ -341,7 +379,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,13 +399,13 @@ These examples demonstrate the default behavior when dual-stack is newly enabled protocol: TCP targetPort: 80 selector: - app: MyApp + app: MyApp ``` -#### 在单栈和双栈之间切换服务 +#### 在单栈和双栈之间切换服务 {#switching-services-between-single-stack-and-dual-stack} 1. 要将服务从单栈更改为双栈，根据需要将 `.spec.ipFamilyPolicy` 从 `SingleStack` 改为 `PreferDualStack` 或 `RequireDualStack`。 - 当你将此服务从单栈更改为双栈时，Kubernetes 将分配缺失的地址族，以便现在 - 该服务具有 IPv4 和 IPv6 地址。 + 当你将此服务从单栈更改为双栈时，Kubernetes 将分配缺失的地址族， + 以便现在该服务具有 IPv4 和 IPv6 地址。 编辑服务规约将 `.spec.ipFamilyPolicy` 从 `SingleStack` 改为 `PreferDualStack`。 - 2. 要将服务从双栈更改为单栈，请将 `.spec.ipFamilyPolicy` 从 `PreferDualStack` 或 `RequireDualStack` 改为 `SingleStack`。 当你将此服务从双栈更改为单栈时，Kubernetes 只保留 `.spec.ClusterIPs` @@ -418,24 +462,27 @@ Services can be changed from single-stack to dual-stack and from dual-stack to s -### 无选择算符的无头服务 +### 无选择算符的无头服务 {#headless-services-without-selector} -对于[不带选择算符的无头服务](/zh/docs/concepts/services-networking/service/#without-selectors)， +对于[不带选择算符的无头服务](/zh-cn/docs/concepts/services-networking/service/#without-selectors)， 若没有显式设置 `.spec.ipFamilyPolicy`，则 `.spec.ipFamilyPolicy` 字段默认设置为 `RequireDualStack`。 -### LoadBalancer 类型服务 +### LoadBalancer 类型服务 {#service-type-loadbalancer} 要为你的服务提供双栈负载均衡器： @@ -444,7 +491,8 @@ To provision a dual-stack load balancer for your Service: {{< note >}} 为了使用双栈的负载均衡器类型服务，你的云驱动必须支持 IPv4 和 IPv6 的负载均衡器。 {{< /note >}} @@ -452,10 +500,14 @@ To use a dual-stack `LoadBalancer` type Service, your cloud provider must suppor -## 出站流量 +## 出站流量 {#egress-traffic} 如果你要启用出站流量，以便使用非公开路由 IPv6 地址的 Pod 到达集群外地址 （例如公网），则需要通过透明代理或 IP 伪装等机制使 Pod 使用公共路由的 @@ -470,11 +522,41 @@ Ensure your {{< glossary_tooltip text="CNI" term_id="cni" >}} provider supports 确认你的 {{< glossary_tooltip text="CNI" term_id="cni" >}} 驱动支持 IPv6。 {{< /note >}} + +## Windows 支持 {#windows-support} + +Windows 上的 Kubernetes 不支持单栈“仅 IPv6” 网络。 然而， +对于 Pod 和节点而言，仅支持单栈形式服务的双栈 IPv4/IPv6 网络是被支持的。 + +你可以使用 `l2bridge` 网络来实现 IPv4/IPv6 双栈联网。 + +{{< note >}} + +Windows 上的 Overlay (VXLAN) 网络**不**支持双栈网络。 +{{< /note >}} + + +关于 Windows 的不同网络模式，你可以进一步阅读 +[Windows 上的网络](/zh-cn/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/) +* [验证 IPv4/IPv6 双协议栈](/zh-cn/docs/tasks/network/validate-dual-stack)网络 +* [使用 kubeadm 启用双协议栈网络](/zh-cn/docs/setup/production-environment/tools/kubeadm/dual-stack-support/) diff --git a/content/zh/docs/concepts/services-networking/endpoint-slices.md b/content/zh-cn/docs/concepts/services-networking/endpoint-slices.md similarity index 100% rename from content/zh/docs/concepts/services-networking/endpoint-slices.md rename to content/zh-cn/docs/concepts/services-networking/endpoint-slices.md diff --git a/content/zh/docs/concepts/services-networking/ingress-controllers.md b/content/zh-cn/docs/concepts/services-networking/ingress-controllers.md similarity index 97% rename from content/zh/docs/concepts/services-networking/ingress-controllers.md rename to content/zh-cn/docs/concepts/services-networking/ingress-controllers.md index a85e073404..06a4c948bd 100644 --- a/content/zh/docs/concepts/services-networking/ingress-controllers.md +++ b/content/zh-cn/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/ingress.md b/content/zh-cn/docs/concepts/services-networking/ingress.md similarity index 95% rename from content/zh/docs/concepts/services-networking/ingress.md rename to content/zh-cn/docs/concepts/services-networking/ingress.md index 037b135c0d..e14cd79ef8 100644 --- a/content/zh/docs/concepts/services-networking/ingress.md +++ b/content/zh-cn/docs/concepts/services-networking/ingress.md @@ -20,7 +20,7 @@ weight: 40 For clarity, this guide defines the following terms: --> -## 术语 +## 术语 {#terminology} 为了表达更加清晰，本指南定义了以下术语： @@ -48,10 +48,11 @@ For clarity, this guide defines the following terms: {{< link text="services" url="/docs/concepts/services-networking/service/" >}} within the cluster. Traffic routing is controlled by rules defined on the Ingress resource. --> -## Ingress 是什么？ +## Ingress 是什么？ {#what-is-ingress} [Ingress](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io) -公开了从集群外部到集群内[服务](/zh/docs/concepts/services-networking/service/)的 HTTP 和 HTTPS 路由。 +公开从集群外部到集群内[服务](/zh/docs/concepts/services-networking/service/)的 +HTTP 和 HTTPS 路由。 流量路由由 Ingress 资源上定义的规则控制。 下面是一个将所有流量都发送到同一 Service 的简单 Ingress 示例： -{{< mermaid >}} -graph LR; - client([客户端])-. Ingress-管理的
    负载均衡器 .->ingress[Ingress]; - ingress-->|路由规则|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="/zh-cn/docs/images/ingress.svg" alt="ingress-diagram" class="diagram-large" caption="图. Ingress" link="https://mermaid.live/edit#pako:eNqNkstuwyAQRX8F4U0r2VHqPlSRKqt0UamLqlnaWWAYJygYLB59KMm_Fxcix-qmGwbuXA7DwAEzzQETXKutof0Ovb4vaoUQkwKUu6pi3FwXM_QSHGBt0VFFt8DRU2OWSGrKUUMlVQwMmhVLEV1Vcm9-aUksiuXRaO_CEhkv4WjBfAgG1TrGaLa-iaUw6a0DcwGI-WgOsF7zm-pN881fvRx1UDzeiFq7ghb1kgqFWiElyTjnuXVG74FkbdumefEpuNuRu_4rZ1pqQ7L5fL6YQPaPNiFuywcG9_-ihNyUkm6YSONWkjVNM8WUIyaeOJLO3clTB_KhL8NQDmVe-OJjxgZM5FhFiiFTK5zjDkxHBQ9_4zB4a-x20EGNSZhyaKmXrg7f5hSsvufUwTMXThtMWiot5Jh6p9ffimHijIezaSVoeN0uiqcfMJvf7w" >}} |/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="/zh-cn/docs/images/ingressFanOut.svg" alt="ingress-fanout-diagram" class="diagram-large" caption="图. Ingress 扇出" link="https://mermaid.live/edit#pako:eNqNUslOwzAQ_RXLvYCUhMQpUFzUUzkgcUBwbHpw4klr4diR7bCo8O8k2FFbFomLPZq3jP00O1xpDpjijWHtFt09zAuFUCUFKHey8vf6NE7QrdoYsDZumGIb4Oi6NAskNeOoZJKpCgxK4oXwrFVgRyi7nCVXWZKRPMlysv5yD6Q4Xryf1Vq_WzDPooJs9egLNDbolKTpT03JzKgh3zWEztJZ0Niu9L-qZGcdmAMfj4cxvWmreba613z9C0B-AMQD-V_AdA-A4j5QZu0SatRKJhSqhZR0wjmPrDP6CeikrutQxy-Cuy2dtq9RpaU2dJKm6fzI5Glmg0VOLio4_5dLjx27hFSC015KJ2VZHtuQvY2fuHcaE43G0MaCREOow_FV5cMxHZ5-oPX75UM5avuXhXuOI9yAaZjg_aLuBl6B3RYaKDDtSw4166QrcKE-emrXcubghgunDaY1kxYizDqnH99UhakzHYykpWD9hjS--fEJoIELqQ" >}} + |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="/zh-cn/docs/images/ingressNameBased.svg" alt="ingress-namebase-diagram" class="diagram-large" caption="图. 基于名称实现虚拟托管的 Ingress" link="https://mermaid.live/edit#pako:eNqNkl9PwyAUxb8KYS-atM1Kp05m9qSJJj4Y97jugcLtRqTQAPVPdN_dVlq3qUt8gZt7zvkBN7xjbgRgiteW1Rt0_zjLNUJcSdD-ZBn21WmcoDu9tuBcXDHN1iDQVWHnSBkmUMEU0xwsSuK5DK5l745QejFNLtMkJVmSZmT1Re9NcTz_uDXOU1QakxTMJtxUHw7ss-SQLhehQEODTsdH4l20Q-zFyc84-Y67pghv5apxHuweMuj9eS2_NiJdPhix-kMgvwQShOyYMNkJoEUYM3PuGkpUKyY1KqVSdCSEiJy35gnoqCzLvo5fpPAbOqlfI26UsXQ0Ho9nB5CnqesRGTnncPYvSqsdUvqp9KRdlI6KojjEkB0mnLgjDRONhqENBYm6oXbLV5V1y6S7-l42_LowlIN2uFm_twqOcAW2YlK0H_i9c-bYb6CCHNO2FFCyRvkc53rbWptaMA83QnpjMS2ZchBh1nizeNMcU28bGEzXkrV_pArN7Sc0rBTu" >}} 如果你希望在 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-topology.md b/content/zh-cn/docs/concepts/services-networking/service-topology.md similarity index 100% rename from content/zh/docs/concepts/services-networking/service-topology.md rename to content/zh-cn/docs/concepts/services-networking/service-topology.md diff --git a/content/zh/docs/concepts/services-networking/service-traffic-policy.md b/content/zh-cn/docs/concepts/services-networking/service-traffic-policy.md similarity index 100% rename from content/zh/docs/concepts/services-networking/service-traffic-policy.md rename to content/zh-cn/docs/concepts/services-networking/service-traffic-policy.md diff --git a/content/zh/docs/concepts/services-networking/service.md b/content/zh-cn/docs/concepts/services-networking/service.md similarity index 93% rename from content/zh/docs/concepts/services-networking/service.md rename to content/zh-cn/docs/concepts/services-networking/service.md index 3d2db97c3c..71140bf426 100644 --- a/content/zh/docs/concepts/services-networking/service.md +++ b/content/zh-cn/docs/concepts/services-networking/service.md @@ -1,5 +1,5 @@ --- -title: 服务 +title: 服务（Service） feature: title: 服务发现与负载均衡 description: > @@ -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:stable + 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" >}} 中或其它集群中的服务。 @@ -266,6 +307,7 @@ where it's running, by adding an Endpoints object manually: apiVersion: v1 kind: Endpoints metadata: + # 这里的 name 要与 Service 的名字相同 name: my-service subsets: - addresses: @@ -280,6 +322,15 @@ The name of the Endpoints object must be a valid Endpoints 对象的名称必须是合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 + +当你为某个 Service 创建一个 [Endpoints](/zh-cn/docs/reference/kubernetes-api/service-resources/endpoints-v1/) +对象时，你要将新对象的名称设置为与 Service 的名称相同。 + +{{< note >}} -{{< note >}} 端点 IPs _必须不可以_ 是：本地回路（IPv4 的 127.0.0.0/8, IPv6 的 ::1/128）或 本地链接（IPv4 的 169.254.0.0/16 和 224.0.0.0/24，IPv6 的 fe80::/64)。 @@ -590,6 +640,14 @@ You can also set the maximum session sticky time by setting 来设置最大会话停留时间。 （默认值为 10800 秒，即 3 小时）。 + +{{< note >}} +在 Windows 上，不支持为服务设置最大会话停留时间。 +{{< /note >}} + + @@ -751,11 +809,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 +818,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 +1199,15 @@ securityGroupName。 #### 混合协议类型的负载均衡器 @@ -1160,14 +1216,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 +2026,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 +2047,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 +2062,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 的冲突风险非常低。 + + + +Kubernetes 支持运行 Linux 或 Windows 节点。 +你可以在统一集群内混布这两种节点。 +本页提供了特定于 Windows 操作系统的网络概述。 + + + +## Windows 容器网络 {#networking} + +Windows 容器网络通过 [CNI 插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)暴露。 +Windows 容器网络的工作方式与虚拟机类似。 +每个容器都有一个连接到 Hyper-V 虚拟交换机（vSwitch）的虚拟网络适配器（vNIC）。 +主机网络服务（Host Networking Service，HNS）和主机计算服务（Host Comute Service，HCS） +协同创建容器并将容器 vNIC 挂接到网络。 +HCS 负责管理容器，而 HNS 负责管理以下网络资源： + +* 虚拟网络（包括创建 vSwitch） +* Endpoint / vNIC +* 命名空间 +* 包括数据包封装、负载均衡规则、ACL 和 NAT 规则在内的策略。 + + +Windows HNS 和 vSwitch 实现命名空间划分，且可以按需为 Pod 或容器创建虚拟 NIC。 +然而，诸如 DNS、路由和指标等许多配置将存放在 Windows 注册表数据库中， +而不是像 Linux 将这些配置作为文件存放在 `/etc` 内。 +针对容器的 Windows 注册表与主机的注册表是分开的，因此将 `/etc/resolv.conf` +从主机映射到一个容器的类似概念与 Linux 上的效果不同。 +这些必须使用容器环境中运行的 Windows API 进行配置。 +因此，实现 CNI 时需要调用 HNS，而不是依赖文件映射将网络详情传递到 Pod 或容器中。 + + +## 网络模式 {#network-mode} + +Windows 支持五种不同的网络驱动/模式：L2bridge、L2tunnel、Overlay (Beta)、Transparent 和 NAT。 +在 Windows 和 Linux 工作节点组成的异构集群中，你需要选择一个同时兼容 Windows 和 Linux 的网络方案。 +下表列出了 Windows 支持的树外插件，并给出了何时使用每种 CNI 的建议： + + +| 网络驱动 | 描述 | 容器数据包修改 | 网络插件 | 网络插件特点 | +| -------------- | ----------- | ------------------------------ | --------------- | ------------------------------ | +| L2bridge | 容器挂接到一个外部 vSwitch。容器挂接到下层网络，但物理网络不需要了解容器的 MAC，因为这些 MAC 在入站/出站时被重写。 | MAC 被重写为主机 MAC，可使用 HNS OutboundNAT 策略将 IP 重写为主机 IP。 | [win-bridge](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-bridge)、[Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md)、Flannel host-gateway 使用 win-bridge| win-bridge 使用 L2bridge 网络模式，将容器连接到主机的下层，提供最佳性能。节点间连接需要用户定义的路由（UDR）。 | +| L2Tunnel | 这是 L2bridge 的一种特例，但仅用在 Azure 上。所有数据包都会被发送到应用了 SDN 策略的虚拟化主机。 | MAC 被重写，IP 在下层网络上可见。| [Azure-CNI](https://github.com/Azure/azure-container-networking/blob/master/docs/cni.md) | Azure-CNI 允许将容器集成到 Azure vNET，允许容器充分利用 [Azure 虚拟网络](https://azure.microsoft.com/zh-cn/services/virtual-network/)所提供的能力集合。例如，安全地连接到 Azure 服务或使用 Azure NSG。参考 [azure-cni 了解有关示例](https://docs.microsoft.com/zh-cn/azure/aks/concepts-network#azure-cni-advanced-networking)。 | +| Overlay | 容器被赋予一个 vNIC，连接到外部 vSwitch。每个上层网络都有自己的 IP 子网，由自定义 IP 前缀进行定义。该上层网络驱动使用 VXLAN 封装。 | 用外部头进行封装。 | [win-overlay](https://github.com/containernetworking/plugins/tree/master/plugins/main/windows/win-overlay)、Flannel VXLAN（使用 win-overlay） | 当需要将虚拟容器网络与主机的下层隔离时（例如出于安全原因），应使用 win-overlay。如果你的数据中心的 IP 个数有限，可以将 IP 在不同的上层网络中重用（带有不同的 VNID 标记）。在 Windows Server 2019 上这个选项需要 [KB4489899](https://support.microsoft.com/zh-cn/help/4489899)。 | +| Transparent（[ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) 的特殊用例） | 需要一个外部 vSwitch。容器挂接到一个外部 vSwitch，由后者通过逻辑网络（逻辑交换机和路由器）实现 Pod 内通信。 | 数据包通过 [GENEVE](https://datatracker.ietf.org/doc/draft-gross-geneve/) 或 [STT](https://datatracker.ietf.org/doc/draft-davie-stt/) 隧道进行封装，以到达其它主机上的 Pod。
    数据包基于 OVN 网络控制器提供的隧道元数据信息被转发或丢弃。
    南北向通信使用 NAT。 | [ovn-kubernetes](https://github.com/openvswitch/ovn-kubernetes) | [通过 ansible 部署](https://github.com/openvswitch/ovn-kubernetes/tree/master/contrib)。通过 Kubernetes 策略可以实施分布式 ACL。支持 IPAM。无需 kube-proxy 即可实现负载均衡。无需 iptables/netsh 即可进行 NAT。 | +| NAT（**Kubernetes 中未使用**） | 容器被赋予一个 vNIC，连接到内部 vSwitch。DNS/DHCP 是使用一个名为 [WinNAT 的内部组件](https://techcommunity.microsoft.com/t5/virtualization/windows-nat-winnat-capabilities-and-limitations/ba-p/382303)实现的 | MAC 和 IP 重写为主机 MAC/IP。 | [nat](https://github.com/Microsoft/windows-container-networking/tree/master/plugins/nat) | 放在此处保持完整性。 | + + +如上所述，Windows 通过 [VXLAN 网络后端](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan)（**Beta 支持**；委派给 win-overlay） +和 [host-gateway 网络后端](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#host-gw)（稳定支持；委派给 win-bridge） +也[支持](https://github.com/flannel-io/cni-plugin#windows-support-experimental) [Flannel](https://github.com/coreos/flannel) 的 [CNI 插件](https://github.com/flannel-io/cni-plugin)。 + + +此插件支持委派给参考 CNI 插件（win-overlay、win-bridge）之一，配合使用 Windows +上的 Flannel 守护程序（Flanneld），以便自动分配节点子网租赁并创建 HNS 网络。 +该插件读取自己的配置文件（cni.conf），并聚合 FlannelD 生成的 subnet.env 文件中的环境变量。 +然后，委派给网络管道的参考 CNI 插件之一，并将包含节点分配子网的正确配置发送给 IPAM 插件（例如：`host-local`）。 + + +对于 Node、Pod 和 Service 对象，TCP/UDP 流量支持以下网络流： + +* Pod → Pod（IP） +* Pod → Pod（名称） +* Pod → Service（集群 IP） +* Pod → Service（PQDN，但前提是没有 "."） +* Pod → Service（FQDN） +* Pod → 外部（IP） +* Pod → 外部（DNS） +* Node → Pod +* Pod → Node + + +## IP 地址管理（IPAM） {#ipam} + +Windows 支持以下 IPAM 选项： + +* [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)（仅适用于 azure-cni） +* [Windows Server IPAM](https://docs.microsoft.com/zh-cn/windows-server/networking/technologies/ipam/ipam-top)（未设置 IPAM 时的回滚选项） + + +## 负载均衡和 Service {#load-balancing-and-services} + +Kubernetes {{< glossary_tooltip text="Service" term_id="service" >}} 是一种抽象：定义了逻辑上的一组 Pod 和一种通过网络访问这些 Pod 的方式。 +在包含 Windows 节点的集群中，你可以使用以下类别的 Service： + +* `NodePort` +* `ClusterIP` +* `LoadBalancer` +* `ExternalName` + + +Windows 容器网络与 Linux 网络有着很重要的差异。 +更多细节和背景信息，参考 [Microsoft Windows 容器网络文档](https://docs.microsoft.com/zh-cn/virtualization/windowscontainers/container-networking/architecture)。 + +在 Windows 上，你可以使用以下设置来配置 Service 和负载均衡行为： + + +{{< table caption="Windows Service 设置" >}} +| 功能特性 | 描述 | 支持的 Windows 操作系统最低版本 | 启用方式 | +| ------- | ----------- | -------------------------- | ------------- | +| 会话亲和性 | 确保每次都将来自特定客户端的连接传递到同一个 Pod。 | Windows Server 2022 | 将 `service.spec.sessionAffinity` 设为 “ClientIP” | +| Direct Server Return (DSR) | 在负载均衡模式中 IP 地址修正和 LBNAT 直接发生在容器 vSwitch 端口；服务流量到达时源 IP 设置为原始 Pod IP。 | Windows Server 2019 | 在 kube-proxy 中设置以下标志：`--feature-gates="WinDSR=true" --enable-dsr=true` | +| 保留目标（Preserve-Destination） | 跳过服务流量的 DNAT，从而在到达后端 Pod 的数据包中保留目标服务的虚拟 IP。也会禁用节点间的转发。 | Windows Server，version 1903 | 在服务注解中设置 `"preserve-destination": "true"` 并在 kube-proxy 中启用 DSR。 | +| IPv4/IPv6 双栈网络 | 进出集群和集群内通信都支持原生的 IPv4 间与 IPv6 间流量 | Windows Server 2019 | 参考 [IPv4/IPv6 双栈](#ipv4ipv6-dual-stack)。 | +| 客户端 IP 保留 | 确保入站流量的源 IP 得到保留。也会禁用节点间转发。 | Windows Server 2019 | 将 `service.spec.externalTrafficPolicy` 设置为 “Local” 并在 kube-proxy 中启用 DSR。 | +{{< /table >}} + + +{{< warning >}} +如果目的地节点在运行 Windows Server 2022，则上层网络的 NodePort Service 存在已知问题。 +要完全避免此问题，可以使用 `externalTrafficPolicy: Local` 配置服务。 + +在安装了 KB5005619 的 Windows Server 2022 或更高版本上，采用 L2bridge 网络时 +Pod 间连接存在已知问题。 +要解决此问题并恢复 Pod 间连接，你可以在 kube-proxy 中禁用 WinDSR 功能。 + +这些问题需要操作系统修复。 +有关更新，请参考 https://github.com/microsoft/Windows-Containers/issues/204。 +{{< /warning >}} + + +## 限制 {#limitations} + +Windows 节点**不支持**以下网络功能： + +* 主机网络模式 +* 从节点本身访问本地 NodePort（可以从其他节点或外部客户端进行访问） +* 为同一 Service 提供 64 个以上后端 Pod（或不同目的地址） +* 在连接到上层网络的 Windows Pod 之间使用 IPv6 通信 +* 非 DSR 模式中的本地流量策略（Local Traffic Policy） + + +* 通过 `win-overlay`、`win-bridge` 使用 ICMP 协议，或使用 Azure-CNI 插件进行出站通信。 + 具体而言，Windows 数据平面（[VFP](https://www.microsoft.com/research/project/azure-virtual-filtering-platform/)）不支持 ICMP 数据包转换，这意味着： + * 指向同一网络内目的地址的 ICMP 数据包（例如 Pod 间的 ping 通信）可正常工作； + * TCP/UDP 数据包可正常工作； + * 通过远程网络指向其它地址的 ICMP 数据包（例如通过 ping 从 Pod 到外部公网的通信）无法被转换， + 因此无法被路由回到这些数据包的源点； + * 由于 TCP/UDP 数据包仍可被转换，所以在调试与外界的连接时， + 你可以将 `ping ` 替换为 `curl `。 + + +其他限制： + +* 由于缺少 `CHECK` 实现，Windows 参考网络插件 win-bridge 和 win-overlay 未实现 +[CNI 规约](https://github.com/containernetworking/cni/blob/master/SPEC.md) 的 v0.4.0 版本。 +* Flannel VXLAN CNI 插件在 Windows 上有以下限制： + * 使用 Flannel v0.12.0（或更高版本）时，节点到 Pod 的连接仅适用于本地 Pod。 + * Flannel 仅限于使用 VNI 4096 和 UDP 端口 4789。 + 有关这些参数的更多详细信息，请参考官方的 [Flannel VXLAN](https://github.com/coreos/flannel/blob/master/Documentation/backends.md#vxlan) 后端文档。 diff --git a/content/zh/docs/concepts/storage/_index.md b/content/zh-cn/docs/concepts/storage/_index.md similarity index 100% rename from content/zh/docs/concepts/storage/_index.md rename to content/zh-cn/docs/concepts/storage/_index.md diff --git a/content/zh/docs/concepts/storage/dynamic-provisioning.md b/content/zh-cn/docs/concepts/storage/dynamic-provisioning.md similarity index 100% rename from content/zh/docs/concepts/storage/dynamic-provisioning.md rename to content/zh-cn/docs/concepts/storage/dynamic-provisioning.md diff --git a/content/zh/docs/concepts/storage/ephemeral-volumes.md b/content/zh-cn/docs/concepts/storage/ephemeral-volumes.md similarity index 100% rename from content/zh/docs/concepts/storage/ephemeral-volumes.md rename to content/zh-cn/docs/concepts/storage/ephemeral-volumes.md diff --git a/content/zh/docs/concepts/storage/persistent-volumes.md b/content/zh-cn/docs/concepts/storage/persistent-volumes.md similarity index 93% rename from content/zh/docs/concepts/storage/persistent-volumes.md rename to content/zh-cn/docs/concepts/storage/persistent-volumes.md index fdf9e6ee50..e9b5ccc140 100644 --- a/content/zh/docs/concepts/storage/persistent-volumes.md +++ b/content/zh-cn/docs/concepts/storage/persistent-volumes.md @@ -374,6 +374,97 @@ However, the particular path specified in the custom recycler Pod template in th 定制回收器 Pod 模板中在 `volumes` 部分所指定的特定路径要替换为 正被回收的卷的路径。 + +### 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` 并选择 一个比你之前所尝试的值更小的值。 如果由于容量限制而无法成功扩展至更高的值，这将很有用。 @@ -933,6 +1012,23 @@ In the CLI, the access modes are abbreviated to: * RWX - ReadWriteMany * RWOP - ReadWriteOncePod +{{< note >}} + +Kubernetes 使用卷访问模式来匹配 PersistentVolumeClaim 和 PersistentVolume。 +在某些场合下，卷访问模式也会限制 PersistentVolume 可以挂载的位置。 +卷访问模式并**不会**在存储已经被挂载的情况下为其实施写保护。 +即使访问模式设置为 ReadWriteOnce、ReadOnlyMany 或 ReadWriteMany，它们也不会对卷形成限制。 +例如，即使某个卷创建时设置为 ReadOnlyMany，也无法保证该卷是只读的。 +如果访问模式设置为 ReadWriteOncePod，则卷会被限制起来并且只能挂载到一个 Pod 上。 +{{< /note >}} + @@ -1411,10 +1507,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 +1521,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 +1721,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 服务器和控制器管理器上启用 @@ -1747,11 +1838,11 @@ and need persistent storage, it is recommended that you use the following patter * 进一步了解[创建持久卷](/zh/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). * 进一步学习[创建 PVC 申领](/zh/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim). -* 阅读[持久存储的设计文档](https://git.k8s.io/community/contributors/design-proposals/storage/persistent-storage.md). +* 阅读[持久存储的设计文档](https://github.com/kubernetes/design-proposals-archive/blob/main/storage/persistent-storage.md). Container 中的文件在磁盘上是临时存放的，这给 Container 中运行的较重要的应用程序带来一些问题。 问题之一是当容器崩溃时文件丢失。 @@ -33,10 +34,7 @@ kubelet 会重新启动容器，但容器会以干净的状态重启。 Kubernetes {{< glossary_tooltip text="卷（Volume）" term_id="volume" >}} 这一抽象概念能够解决这两个问题。 - -阅读本文前建议你熟悉一下 [Pods](/zh/docs/concepts/workloads/pods)。 +阅读本文前建议你熟悉一下 [Pod](/zh-cn/docs/concepts/workloads/pods)。 @@ -120,15 +118,21 @@ Kubernetes supports several types of Volumes: Kubernetes 支持下列类型的卷： -### awsElasticBlockStore {#awselasticblockstore} - +### awsElasticBlockStore （已弃用） {#awselasticblockstore} + +{{< feature-state for_k8s_version="v1.17" state="deprecated" >}} + `awsElasticBlockStore` 卷将 Amazon Web服务（AWS）[EBS 卷](https://aws.amazon.com/ebs/) 挂载到你的 Pod 中。与 `emptyDir` 在 Pod 被删除时也被删除不同，EBS 卷的内容在删除 Pod 时会被保留，卷只是被卸载掉了。 @@ -239,13 +243,18 @@ and the kubelet, set the `InTreePluginAWSUnregister` flag to `true`. 要禁止控制器管理器和 kubelet 加载 `awsElasticBlockStore` 存储插件， 请将 `InTreePluginAWSUnregister` 标志设置为 `true`。 -### azureDisk {#azuredisk} - +### azureDisk （已弃用） {#azuredisk} + +{{< feature-state for_k8s_version="v1.19" state="deprecated" >}} `azureDisk` 卷类型用来在 Pod 上挂载 Microsoft Azure [数据盘（Data Disk）](https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-about-disks-vhds/) 。 @@ -256,22 +265,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 （已弃用） {#azurefile} + +{{< feature-state for_k8s_version="v1.21" state="deprecated" >}} + `azureFile` 卷类型用来在 Pod 上挂载 Microsoft Azure 文件卷（File Volume）（SMB 2.1 和 3.0）。 更多详情请参考 [`azureFile` 卷插件](https://github.com/kubernetes/examples/tree/master/staging/volumes/azure_file/README.md)。 @@ -314,18 +328,19 @@ Driver](https://github.com/kubernetes-sigs/azurefile-csi-driver) must be installed on the cluster and the `CSIMigration` and `CSIMigrationAzureFile` [feature gates](/docs/reference/command-line-tools-reference/feature-gates/) must be enabled. --> -启用 `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 来使用同一卷也是不被支持的。 更多信息请参考 [CephFS 示例](https://github.com/kubernetes/examples/tree/master/volumes/cephfs/)。 -### cinder {#cinder} + +### cinder （已弃用） {#cinder} +{{< feature-state for_k8s_version="v1.18" state="deprecated" >}} + +{{< note >}} -{{< note >}} Kubernetes 必须配置了 OpenStack Cloud Provider。 {{< /note >}} `cinder` 卷类型用于将 OpenStack Cinder 卷挂载到 Pod 中。 -#### Cinder 卷示例配置 + +#### Cinder 卷示例配置 {#cinder-volume-example-configuration} ```yaml apiVersion: v1 @@ -413,29 +434,31 @@ spec: --> #### 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 +806,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 +1624,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 +1669,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`。 有关如何开发 CSI 驱动的更多信息，请参考 [kubernetes-csi 文档](https://kubernetes-csi.github.io/docs/)。 + +#### Windows CSI 代理 {#windows-csi-proxy} + +{{< feature-state for_k8s_version="v1.22" state="stable" >}} + + +CSI 节点插件需要执行多种特权操作，例如扫描磁盘设备和挂载文件系统等。 +这些操作在每个宿主操作系统上都是不同的。对于 Linux 工作节点而言，容器化的 CSI +节点插件通常部署为特权容器。对于 Windows 工作节点而言，容器化 CSI +节点插件的特权操作是通过 [csi-proxy](https://github.com/kubernetes-csi/csi-proxy) +来支持的。csi-proxy 是一个由社区管理的、独立的可执行二进制文件， +需要被预安装到每个 Windows 节点上。 + +要了解更多的细节，可以参考你要部署的 CSI 插件的部署指南。 + @@ -2170,19 +2171,30 @@ configuration changes to existing Storage Classes, PersistentVolumes or Persiste The operations and features that are supported include: 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). --> -启用 `CSIMigration` 功能后，针对现有树内插件的操作会被重定向到相应的 CSI 插件（应已安装和配置）。 +启用 `CSIMigration` 特性后，针对现有树内插件的操作会被重定向到相应的 CSI 插件（应已安装和配置）。 因此，操作员在过渡到取代树内插件的 CSI 驱动时，无需对现有存储类、PV 或 PVC（指树内插件）进行任何配置更改。 -所支持的操作和功能包括：配备（Provisioning）/删除、挂接（Attach）/解挂（Detach）、 +所支持的操作和特性包括：配备（Provisioning）/删除、挂接（Attach）/解挂（Detach）、 挂载（Mount）/卸载（Unmount）和调整卷大小。 + 上面的[卷类型](#volume-types)节列出了支持 `CSIMigration` 并已实现相应 CSI 驱动程序的树内插件。 +下面是支持 Windows 节点上持久性存储的树内插件： + +* [`awsElasticBlockStore`](#awselasticblockstore) +* [`azureDisk`](#azuredisk) +* [`azureFile`](#azurefile) +* [`gcePersistentDisk`](#gcepersistentdisk) +* [`vsphereVolume`](#vspherevolume) + ### flexVolume {{< feature-state for_k8s_version="v1.23" state="deprecated" >}} @@ -2202,14 +2214,24 @@ FlexVolume 是一个使用基于 exec 的模型来与驱动程序对接的树外 Pod 通过 `flexvolume` 树内插件与 FlexVolume 驱动程序交互。 更多详情请参考 FlexVolume [README](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md#readme) 文档。 + +下面的 FlexVolume [插件](https://github.com/Microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows) +以 PowerShell 脚本的形式部署在宿主系统上，支持 Windows 节点： + +* [SMB](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~smb.cmd) +* [iSCSI](https://github.com/microsoft/K8s-Storage-Plugins/tree/master/flexvolume/windows/plugins/microsoft.com~iscsi.cmd) + +{{< note >}} -{{< note >}} -FlexVolume 已弃用。推荐使用树外 CSI 驱动来将外部存储整合进 Kubernetes。 +FlexVolume 已被弃用。推荐使用树外 CSI 驱动来将外部存储整合进 Kubernetes。 FlexVolume 驱动的维护者应开发一个 CSI 驱动并帮助用户从 FlexVolume 驱动迁移到 CSI。 FlexVolume 用户应迁移工作负载以使用对等的 CSI 驱动。 @@ -2334,10 +2356,8 @@ sudo systemctl restart docker ## {{% heading "whatsnext" %}} - - 参考[使用持久卷部署 WordPress 和 MySQL](/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) 示例。 diff --git a/content/zh-cn/docs/concepts/storage/windows-storage.md b/content/zh-cn/docs/concepts/storage/windows-storage.md new file mode 100644 index 0000000000..142fadae0c --- /dev/null +++ b/content/zh-cn/docs/concepts/storage/windows-storage.md @@ -0,0 +1,132 @@ +--- +title: Windows 存储 +content_type: concept +--- + + + + +此页面提供特定于 Windows 操作系统的存储概述。 + + + +## 持久存储 {#storage} +Windows 有一个分层文件系统驱动程序用来挂载容器层和创建基于 NTFS 的文件系统拷贝。 +容器中的所有文件路径仅在该容器的上下文中解析。 + + +* 使用 Docker 时，卷挂载只能是容器中的目录，而不能是单个文件。此限制不适用于 containerd。 +* 卷挂载不能将文件或目录映射回宿主文件系统。 +* 不支持只读文件系统，因为 Windows 注册表和 SAM 数据库始终需要写访问权限。不过，Windows 支持只读的卷。 +* 不支持卷的用户掩码和访问许可，因为宿主与容器之间并不共享 SAM，二者之间不存在映射关系。 + 所有访问许可都是在容器上下文中解析的。 + + +因此，Windows 节点不支持以下存储功能： + + +* 卷子路径挂载：只能在 Windows 容器上挂载整个卷 +* Secret 的子路径挂载 +* 宿主挂载映射 +* 只读的根文件系统（映射的卷仍然支持 `readOnly`） +* 块设备映射 +* 内存作为存储介质（例如 `emptyDir.medium` 设置为 `Memory`） +* 类似 UID/GID、各用户不同的 Linux 文件系统访问许可等文件系统特性 +* 使用 [DefaultMode 设置 Secret 权限](/zh/docs/concepts/configuration/secret/#secret-files-permissions) + （因为该特性依赖 UID/GID） +* 基于 NFS 的存储和卷支持 +* 扩展已挂载卷（resizefs） + + +使用 Kubernetes {{< glossary_tooltip text="卷" term_id="volume" >}}， +对数据持久性和 Pod 卷共享有需求的复杂应用也可以部署到 Kubernetes 上。 +管理与特定存储后端或协议相关的持久卷时，相关的操作包括：对卷的制备（Provisioning）、 +去配（De-provisioning）和调整大小，将卷挂接到 Kubernetes 节点或从节点上解除挂接， +将卷挂载到需要持久数据的 Pod 中的某容器上或从容器上卸载。 + + +卷管理组件作为 Kubernetes 卷[插件](/zh/docs/concepts/storage/volumes/#types-of-volumes)发布。 +Windows 支持以下类型的 Kubernetes 卷插件： + + +* [`FlexVolume plugins`](/zh/docs/concepts/storage/volumes/#flexVolume) + * 请注意自 1.23 版本起，FlexVolume 已被弃用 +* [`CSI Plugins`](/zh/docs/concepts/storage/volumes/#csi) + + +##### 树内（In-Tree）卷插件 {#in-tree-volume-plugins} + +以下树内（In-Tree）插件支持 Windows 节点上的持久存储： + + +* [`awsElasticBlockStore`](/zh/docs/concepts/storage/volumes/#awselasticblockstore) +* [`azureDisk`](/zh/docs/concepts/storage/volumes/#azuredisk) +* [`azureFile`](/zh/docs/concepts/storage/volumes/#azurefile) +* [`gcePersistentDisk`](/zh/docs/concepts/storage/volumes/#gcepersistentdisk) +* [`vsphereVolume`](/zh/docs/concepts/storage/volumes/#vspherevolume) \ No newline at end of file diff --git a/content/zh-cn/docs/concepts/windows/_index.md b/content/zh-cn/docs/concepts/windows/_index.md new file mode 100644 index 0000000000..a78ddcfe75 --- /dev/null +++ b/content/zh-cn/docs/concepts/windows/_index.md @@ -0,0 +1,8 @@ +--- +title: "Kubernetes 中的 Windows" +weight: 50 +--- + diff --git a/content/zh-cn/docs/concepts/windows/intro.md b/content/zh-cn/docs/concepts/windows/intro.md new file mode 100644 index 0000000000..fb44b155a3 --- /dev/null +++ b/content/zh-cn/docs/concepts/windows/intro.md @@ -0,0 +1,721 @@ +--- +title: Kubernetes 中的 Windows 容器 +content_type: concept +weight: 65 +--- + + + + +在许多组织中，所运行的很大一部分服务和应用是 Windows 应用。 +[Windows 容器](https://aka.ms/windowscontainers)提供了一种封装进程和包依赖项的方式， +从而简化了 DevOps 实践，令 Windows 应用程序同样遵从云原生模式。 + +对于同时投入基于 Windows 应用和 Linux 应用的组织而言，他们不必寻找不同的编排系统来管理其工作负载， +使其跨部署的运营效率得以大幅提升，而不必关心所用的操作系统。 + + + + +## Kubernetes 中的 Windows 节点 {#windows-nodes-in-k8s} + +若要在 Kubernetes 中启用对 Windows 容器的编排，可以在现有的 Linux 集群中包含 Windows 节点。 +在 Kubernetes 上调度 {{< glossary_tooltip text="Pod" term_id="pod" >}} 中的 Windows 容器与调度基于 Linux 的容器类似。 + +为了运行 Windows 容器，你的 Kubernetes 集群必须包含多个操作系统。 +尽管你只能在 Linux 上运行{{< glossary_tooltip text="控制平面" term_id="control-plane" >}}， +你可以部署运行 Windows 或 Linux 的工作节点。 + + +支持 Windows {{< glossary_tooltip text="节点" term_id="node" >}}的前提是操作系统为 Windows Server 2019。 + +本文使用术语 **Windows 容器**表示具有进程隔离能力的 Windows 容器。 +Kubernetes 不支持使用 +[Hyper-V 隔离能力](https://docs.microsoft.com/zh-cn/virtualization/windowscontainers/manage-containers/hyperv-container)来运行 +Windows 容器。 + + +## 兼容性与局限性 {#limitations} + +某些节点层面的功能特性仅在使用特定[容器运行时](#container-runtime)时才可用； +另外一些特性则在 Windows 节点上不可用，包括： + +* 巨页（HugePages）：Windows 容器当前不支持。 +* 特权容器：Windows 容器当前不支持。 + [HostProcess 容器](/zh/docs/tasks/configure-pod-container/create-hostprocess-pod/)提供类似功能。 +* TerminationGracePeriod：需要 containerD。 + + +Windows 节点并不支持共享命名空间的所有功能特性。 +有关更多详细信息，请参考 [API 兼容性](#api)。 + +有关 Kubernetes 测试时所使用的 Windows 版本的详细信息，请参考 [Windows 操作系统版本兼容性](#windows-os-version-support)。 + +从 API 和 kubectl 的角度来看，Windows 容器的行为与基于 Linux 的容器非常相似。 +然而，在本节所概述的一些关键功能上，二者存在一些显著差异。 + + +### 与 Linux 比较 {#comparison-with-Linux-similarities} + +Kubernetes 关键组件在 Windows 上的工作方式与在 Linux 上相同。 +本节介绍几个关键的工作负载抽象及其如何映射到 Windows。 + + +* [Pod](/zh/docs/concepts/workloads/pods/) + + Pod 是 Kubernetes 的基本构建块，是可以创建或部署的最小和最简单的单元。 + 你不可以在同一个 Pod 中部署 Windows 和 Linux 容器。 + Pod 中的所有容器都调度到同一 Node 上，每个 Node 代表一个特定的平台和体系结构。 + Windows 容器支持以下 Pod 能力、属性和事件： + + * 每个 Pod 有一个或多个容器，具有进程隔离和卷共享能力 + * Pod `status` 字段 + * 就绪、存活和启动探针 + * postStart 和 preStop 容器生命周期回调 + * ConfigMap 和 Secret：作为环境变量或卷 + * `emptyDir` 卷 + * 命名管道形式的主机挂载 + * 资源限制 + * 操作系统字段： + + `.spec.os.name` 字段应设置为 `windows` 以表明当前 Pod 使用 Windows 容器。 + 需要启用 `IdentifyPodOS` 特性门控才能让这个字段被识别。 + + {{< note >}} + 从 1.24 开始，`IdentifyPodOS` 特性门控进入 Beta 阶段，默认启用。 + {{< /note >}} + + 如果 `IdentifyPodOS` 特性门控已启用并且你将 `.spec.os.name` 字段设置为 `windows`， + 则你不得在对应 Pod 的 `.spec` 中设置以下字段： + + * `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` + + 在上述列表中，通配符（`*`）表示列表中的所有项。 + 例如，`spec.containers[*].securityContext` 指代所有容器的 SecurityContext 对象。 + 如果指定了这些字段中的任意一个，则 API 服务器不会接受此 Pod。 + + +* [工作负载资源](/zh/docs/concepts/workloads/controllers/)包括： + + * ReplicaSet + * Deployment + * StatefulSet + * DaemonSet + * Job + * CronJob + * ReplicationController + +* {{< glossary_tooltip text="Services" term_id="service" >}} + + 有关更多详细信息，请参考[负载均衡和 Service](#load-balancing-and-services)。 + + +Pod、工作负载资源和 Service 是在 Kubernetes 上管理 Windows 工作负载的关键元素。 +然而，它们本身还不足以在动态的云原生环境中对 Windows 工作负载进行恰当的生命周期管理。 +Kubernetes 还支持： + +* `kubectl exec` +* Pod 和容器度量指标 +* {{< glossary_tooltip text="Pod 水平自动扩缩容" term_id="horizontal-pod-autoscaler" >}} +* {{< glossary_tooltip text="资源配额" term_id="resource-quota" >}} +* 调度器抢占 + + +### kubelet 的命令行选项 {#kubelet-compatibility} + +某些 kubelet 命令行选项在 Windows 上的行为不同，如下所述： + + +* `--windows-priorityclass` 允许你设置 kubelet 进程的调度优先级 + （参考 [CPU 资源管理](/zh/docs/concepts/configuration/windows-resource-management/#resource-management-cpu)）。 +* `--kubelet-reserve`、`--system-reserve` 和 `--eviction-hard` 标志更新 + [NodeAllocatable](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)。 +* 未实现使用 `--enforce-node-allocable` 驱逐。 +* 未实现使用 `--eviction-hard` 和 `--eviction-soft` 驱逐。 +* 在 Windows 节点上运行时，kubelet 没有内存或 CPU 限制。 + `--kube-reserved` 和 `--system-reserved` 仅从 `NodeAllocatable` 中减去，并且不保证为工作负载提供的资源。 + 有关更多信息，请参考 [Windows 节点的资源管理](/zh/docs/concepts/configuration/windows-resource-management/#resource-reservation)。 +* 未实现 `MemoryPressure` 条件。 +* kubelet 不会执行 OOM 驱逐操作。 + + +### API 兼容性 {#api} + +由于操作系统和容器运行时的缘故，Kubernetes API 在 Windows 上的工作方式存在细微差异。 +某些工作负载属性是为 Linux 设计的，无法在 Windows 上运行。 + +从较高的层面来看，以下操作系统概念是不同的： + + +* 身份 - Linux 使用 userID（UID）和 groupID（GID），表示为整数类型。 + 用户名和组名是不规范的，它们只是 `/etc/groups` 或 `/etc/passwd` 中的别名， + 作为 UID+GID 的后备标识。 + Windows 使用更大的二进制[安全标识符](https://docs.microsoft.com/zh-cn/windows/security/identity-protection/access-control/security-identifiers)（SID）， + 存放在 Windows 安全访问管理器（Security Access Manager，SAM）数据库中。 + 此数据库在主机和容器之间或容器之间不共享。 +* 文件权限 - Windows 使用基于 SID 的访问控制列表， + 而像 Linux 使用基于对象权限和 UID+GID 的位掩码（POSIX 系统）以及**可选的**访问控制列表。 +* 文件路径 - Windows 上的约定是使用 `\` 而不是 `/`。 + Go IO 库通常接受两者，能让其正常工作，但当你设置要在容器内解读的路径或命令行时， + 可能需要用 `\`。 + + +* 信号 - Windows 交互式应用处理终止的方式不同，可以实现以下一种或多种： + * UI 线程处理包括 `WM_CLOSE` 在内准确定义的消息。 + * 控制台应用使用控制处理程序（Control Handler）处理 Ctrl-C 或 Ctrl-Break。 + * 服务会注册可接受 `SERVICE_CONTROL_STOP` 控制码的服务控制处理程序（Service Control Handler）函数。 + +容器退出码遵循相同的约定，其中 0 表示成功，非零表示失败。 +具体的错误码在 Windows 和 Linux 中可能不同。 +但是，从 Kubernetes 组件（kubelet、kube-proxy）传递的退出码保持不变。 + + +##### 容器规范的字段兼容性 {#compatibility-v1-pod-spec-containers} + +以下列表记录了 Pod 容器规范在 Windows 和 Linux 之间的工作方式差异： + +* 巨页（Huge page）在 Windows 容器运行时中未实现，且不可用。 + 巨页需要不可为容器配置的[用户特权生效](https://docs.microsoft.com/zh-cn/windows/win32/memory/large-page-support)。 +* `requests.cpu` 和 `requests.memory` - + 从节点可用资源中减去请求，因此请求可用于避免一个节点过量供应。 + 但是，请求不能用于保证已过量供应的节点中的资源。 + 如果运营商想要完全避免过量供应，则应将设置请求作为最佳实践应用到所有容器。 + +* `securityContext.allowPrivilegeEscalation` - + 不能在 Windows 上使用；所有权能字都无法生效。 +* `securityContext.capabilities` - POSIX 权能未在 Windows 上实现。 +* `securityContext.privileged` - Windows 不支持特权容器。 +* `securityContext.procMount` - Windows 没有 `/proc` 文件系统。 +* `securityContext.readOnlyRootFilesystem` - + 不能在 Windows 上使用；对于容器内运行的注册表和系统进程，写入权限是必需的。 +* `securityContext.runAsGroup` - 不能在 Windows 上使用，因为不支持 GID。 + +* `securityContext.runAsNonRoot` - + 此设置将阻止以 `ContainerAdministrator` 身份运行容器，这是 Windows 上与 root 用户最接近的身份。 +* `securityContext.runAsUser` - 改用 [`runAsUserName`](/zh/docs/tasks/configure-pod-container/configure-runasusername)。 +* `securityContext.seLinuxOptions` - 不能在 Windows 上使用，因为 SELinux 特定于 Linux。 +* `terminationMessagePath` - 这个字段有一些限制，因为 Windows 不支持映射单个文件。 + 默认值为 `/dev/termination-log`，因为默认情况下它在 Windows 上不存在，所以能生效。 + + +##### Pod 规范的字段兼容性 {#compatibility-v1-pod} + +以下列表记录了 Pod 规范在 Windows 和 Linux 之间的工作方式差异： + +* `hostIPC` 和 `hostpid` - 不能在 Windows 上共享主机命名空间。 +* `hostNetwork` - Windows 操作系统不支持共享主机网络。 +* `dnsPolicy` - Windows 不支持将 Pod `dnsPolicy` 设为 `ClusterFirstWithHostNet`， + 因为未提供主机网络。Pod 始终用容器网络运行。 +* `podSecurityContext`（参见下文） +* `shareProcessNamespace` - 这是一个 beta 版功能特性，依赖于 Windows 上未实现的 Linux 命名空间。 + Windows 无法共享进程命名空间或容器的根文件系统（root filesystem）。 + 只能共享网络。 + +* `terminationGracePeriodSeconds` - 这在 Windows 上的 Docker 中没有完全实现， + 请参考[GitHub issue](https://github.com/moby/moby/issues/25982)。 + 目前的行为是通过 CTRL_SHUTDOWN_EVENT 发送 ENTRYPOINT 进程，然后 Windows 默认等待 5 秒， + 最后使用正常的 Windows 关机行为终止所有进程。 + 5 秒默认值实际上位于[容器内](https://github.com/moby/moby/issues/25982#issuecomment-426441183)的 Windows 注册表中， + 因此在构建容器时可以覆盖这个值。 +* `volumeDevices` - 这是一个 beta 版功能特性，未在 Windows 上实现。 + Windows 无法将原始块设备挂接到 Pod。 +* `volumes` + * 如果你定义一个 `emptyDir` 卷，则你无法将卷源设为 `memory`。 +* 你无法为卷挂载启用 `mountPropagation`，因为这在 Windows 上不支持。 + + +##### Pod 安全上下文的字段兼容性 {#compatibility-v1-pod-spec-containers-securitycontext} + +Pod 的所有 [`securityContext`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#security-context) +字段都无法在 Windows 上生效。 + + +## 节点问题检测器 {#node-problem-detector} + +节点问题检测器（参考[节点健康监测](/zh/docs/tasks/debug/debug-cluster/monitor-node-health/)）初步支持 Windows。 +有关更多信息，请访问该项目的 [GitHub 页面](https://github.com/kubernetes/node-problem-detector#windows)。 + + +### Pause 容器 {#pause-container} + +在 Kubernetes Pod 中，首先创建一个基础容器或 “pause” 容器来承载容器。 +在 Linux 中，构成 Pod 的 cgroup 和命名空间维持持续存在需要一个进程； +而 pause 进程就提供了这个功能。 +属于同一 Pod 的容器（包括基础容器和工作容器）共享一个公共网络端点 +（相同的 IPv4 和/或 IPv6 地址，相同的网络端口空间）。 +Kubernetes 使用 pause 容器以允许工作容器崩溃或重启，而不会丢失任何网络配置。 + + +Kubernetes 维护一个多体系结构的镜像，包括对 Windows 的支持。 +对于 Kubernetes v{{< skew currentVersion >}}，推荐的 pause 镜像为 `k8s.gcr.io/pause:3.6`。 +可在 GitHub 上获得[源代码](https://github.com/kubernetes/kubernetes/tree/master/build/pause)。 + +Microsoft 维护一个不同的多体系结构镜像，支持 Linux 和 Windows amd64， +你可以找到的镜像类似 `mcr.microsoft.com/oss/kubernetes/pause:3.6`。 +此镜像的构建与 Kubernetes 维护的镜像同源，但所有 Windows 可执行文件均由 +Microsoft 进行了[验证码签名](https://docs.microsoft.com/zh-cn/windows-hardware/drivers/install/authenticode)。 +如果你正部署到一个需要签名可执行文件的生产或类生产环境， +Kubernetes 项目建议使用 Microsoft 维护的镜像。 + + +### 容器运行时 {#container-runtime} + +你需要将{{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}安装到集群中的每个节点， +这样 Pod 才能在这些节点上运行。 + +以下容器运行时适用于 Windows： + +{{% thirdparty-content %}} + + +#### ContainerD {#containerd} + +{{< feature-state for_k8s_version="v1.20" state="stable" >}} + +对于运行 Windows 的 Kubernetes 节点，你可以使用 +{{< glossary_tooltip term_id="containerd" text="ContainerD" >}} 1.4.0+ 作为容器运行时。 + +学习如何[在 Windows 上安装 ContainerD](/zh/docs/setup/production-environment/container-runtimes/#install-containerd)。 + + +{{< note >}} +将 GMSA 和 containerd 一起用于访问 Windows +网络共享时存在[已知限制](/zh/docs/tasks/configure-pod-container/configure-gmsa/#gmsa-limitations)， +这需要一个内核补丁。 +{{< /note >}} + + +#### Mirantis 容器运行时 {#mcr} + +[Mirantis 容器运行时](https://docs.mirantis.com/mcr/20.10/overview.html)（MCR） +可作为所有 Windows Server 2019 和更高版本的容器运行时。 + +有关更多信息，请参考[在 Windows Server 上安装 MCR](https://docs.mirantis.com/mcr/20.10/install/mcr-windows.html)。 + + +## Windows 操作系统版本兼容性 {#windows-os-version-support} + +在 Windows 节点上，如果主机操作系统版本必须与容器基础镜像操作系统版本匹配， +则会应用严格的兼容性规则。 +仅 Windows Server 2019 作为容器操作系统时，才能完全支持 Windows 容器。 + +对于 Kubernetes v{{< skew currentVersion >}}，Windows 节点（和 Pod）的操作系统兼容性如下： + +Windows Server LTSC release +: Windows Server 2019 +: Windows Server 2022 + +Windows Server SAC release +: Windows Server version 20H2 + + +也适用 Kubernetes [版本偏差策略](/zh/docs/setup/release/version-skew-policy/)。 + + +## 获取帮助和故障排查 {#troubleshooting} + +对 Kubernetes 集群进行故障排查的主要帮助来源应始于[故障排查](/zh/docs/tasks/debug/)页面。 + +本节包括了一些其他特定于 Windows 的故障排查帮助。 +日志是解决 Kubernetes 中问题的重要元素。 +确保在任何时候向其他贡献者寻求故障排查协助时随附了日志信息。 +遵照 SIG Windows +[日志收集贡献指南](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#gathering-logs)中的指示说明。 + + +### 报告问题和功能请求 {#report-issue-and-feature-request} + +如果你发现疑似 bug，或者你想提出功能请求，请按照 +[SIG Windows 贡献指南](https://github.com/kubernetes/community/blob/master/sig-windows/CONTRIBUTING.md#reporting-issues-and-feature-requests) +新建一个 Issue。 +你应该先搜索 issue 列表，以防之前报告过这个问题，凭你对该问题的经验添加评论， +并随附日志信息。 +Kubernetes Slack 上的 SIG Windows 频道也是一个很好的途径， +可以在创建工单之前获得一些初始支持和故障排查思路。 + +## {{% heading "whatsnext" %}} + + +### 部署工具 {#deployment-tools} + +kubeadm 工具帮助你部署 Kubernetes 集群，提供管理集群的控制平面以及运行工作负载的节点。 +[添加 Windows 节点](/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)阐述了如何使用 +kubeadm 将 Windows 节点部署到你的集群。 + +Kubernetes [集群 API](https://cluster-api.sigs.k8s.io/) 项目也提供了自动部署 Windows 节点的方式。 + + +### Windows 分发渠道 {#windows-distribution-channels} + +有关 Windows 分发渠道的详细阐述，请参考 +[Microsoft 文档](https://docs.microsoft.com/zh-cn/windows-server/get-started-19/servicing-channels-19)。 + +有关支持模型在内的不同 Windows Server 服务渠道的信息，请参考 +[Windows Server 服务渠道](https://docs.microsoft.com/zh-cn/windows-server/get-started/servicing-channels-comparison)。 diff --git a/content/zh/docs/setup/production-environment/windows/user-guide-windows-containers.md b/content/zh-cn/docs/concepts/windows/user-guide.md similarity index 51% rename from content/zh/docs/setup/production-environment/windows/user-guide-windows-containers.md rename to content/zh-cn/docs/concepts/windows/user-guide.md index 3fcbb64e20..7b3ab57b62 100644 --- a/content/zh/docs/setup/production-environment/windows/user-guide-windows-containers.md +++ b/content/zh-cn/docs/concepts/windows/user-guide.md @@ -1,14 +1,13 @@ --- -title: Kubernetes 中 Windows 容器的调度指南 +title: Kubernetes 中的 Windows 容器调度指南 content_type: concept weight: 75 --- - - -Windows 应用程序构成了许多组织中运行的服务和应用程序的很大一部分。 +在许多组织中运行的服务和应用程序中，Windows 应用程序构成了很大一部分。 本指南将引导你完成在 Kubernetes 中配置和部署 Windows 容器的步骤。 - -## 目标 +## 目标 {#objectives} -* 配置一个示例 deployment 以在 Windows 节点上运行 Windows 容器 -* （可选）使用组托管服务帐户（GMSA）为你的 Pod 配置 Active Directory 身份 +* 配置 Deployment 样例以在 Windows 节点上运行 Windows 容器 +* 在 Kubernetes 中突出 Windows 特定的功能 - -## 在你开始之前 +## 在你开始之前 {#before-you-begin} -* 创建一个 Kubernetes 集群，其中包括一个控制平面和 - [运行 Windows 服务器的工作节点](/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/) -* 重要的是要注意，对于 Linux 和 Windows 容器，在 Kubernetes - 上创建和部署服务和工作负载的行为几乎相同。 - 与集群接口的 [kubectl 命令](/zh/docs/reference/kubectl/overview/)相同。 - 提供以下部分中的示例只是为了快速启动 Windows 容器的使用体验。 +* 创建一个 Kubernetes 集群，其中包含一个控制平面和一个[运行 Windows Server 的工作节点](/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/) +* 务必请注意，在 Kubernetes 上创建和部署服务和工作负载的行为方式与 Linux 和 Windows 容器的行为方式大致相同。 + 与集群交互的 [kubectl 命令](/zh/docs/reference/kubectl/)是一致的。 + 下一小节的示例旨在帮助你快速开始使用 Windows 容器。 - -## 入门：部署 Windows 容器 +## 快速开始：部署 Windows 容器 {#getting-started-deploying-a-windows-container} -要在 Kubernetes 上部署 Windows 容器，你必须首先创建一个示例应用程序。 -下面的示例 YAML 文件创建了一个简单的 Web 服务器应用程序。 -创建一个名为 `win-webserver.yaml` 的服务规约，其内容如下： +以下示例 YAML 文件部署了一个在 Windows 容器内运行的简单 Web 服务器的应用程序。 + +创建一个名为 `win-webserver.yaml` 的 Service 规约，其内容如下： ```yaml apiVersion: v1 @@ -77,7 +74,7 @@ metadata: app: win-webserver spec: ports: - # the port that this service should serve on + # 此 Service 服务的端口 - port: 80 targetPort: 80 selector: @@ -112,35 +109,43 @@ spec: kubernetes.io/os: windows ``` - {{< note >}} -端口映射也是支持的，但为简单起见，在此示例中容器端口 80 直接暴露给服务。 + +端口映射也是支持的，但为简单起见，此示例将容器的端口 80 直接暴露给服务。 {{< /note >}} - +1. 检查所有节点是否健康 - ```bash - kubectl get nodes - ``` + ```bash + kubectl get nodes + ``` + +1. 部署 Service 并监视 Pod 更新： - ```bash - kubectl apply -f win-webserver.yaml - kubectl get pods -o wide -w - ``` + ```bash + kubectl apply -f win-webserver.yaml + kubectl get pods -o wide -w + ``` - When the service is deployed correctly both Pods are marked as Ready. To exit the watch command, press Ctrl+C. + + 当 Service 被正确部署时，两个 Pod 都被标记为就绪（Ready）。要退出 watch 命令，请按 Ctrl+C。 + -1. 检查所有节点是否健康： +1. 检查部署是否成功。请验证： - ```bash - kubectl get nodes - ``` + * 使用 `kubectl get pods` 从 Linux 控制平面节点能够列出两个 Pod + * 跨网络的节点到 Pod 通信，从 Linux 控制平面节点上执行 `curl` 访问 + Pod IP 的 80 端口以检查 Web 服务器响应 + * Pod 间通信，使用 docker exec 或 kubectl exec + 在 Pod 之间（以及跨主机，如果你有多个 Windows 节点）互 ping + * Service 到 Pod 的通信，在 Linux 控制平面节点以及独立的 Pod 中执行 `curl` + 访问虚拟的服务 IP（在 `kubectl get services` 下查看） + * 服务发现，使用 Kubernetes [默认 DNS 后缀](/zh/docs/concepts/services-networking/dns-pod-service/#services)的服务名称， + 用 `curl` 访问服务名称 + * 入站连接，在 Linux 控制平面节点或集群外的机器上执行 `curl` 来访问 NodePort 服务 + * 出站连接，使用 kubectl exec，从 Pod 内部执行 `curl` 访问外部 IP -1. 部署服务并观察 pod 更新： - - ```bash - kubectl apply -f win-webserver.yaml - kubectl get pods -o wide -w - ``` - - 正确部署服务后，两个 Pod 都标记为“Ready”。要退出 watch 命令，请按 Ctrl + C。 - -1. 检查部署是否成功。验证： - - * Windows 节点上每个 Pod 有两个容器，使用 `docker ps` - * Linux 控制平面节点列出两个 Pod，使用 `kubectl get pods` - * 跨网络的节点到 Pod 通信，从 Linux 控制平面节点 `curl` 你的 pod IPs 的端口80，以检查 Web 服务器响应 - * Pod 到 Pod 的通信，使用 docker exec 或 kubectl exec 在 Pod 之间 - （以及跨主机，如果你有多个 Windows 节点）进行 ping 操作 - * 服务到 Pod 的通信，从 Linux 控制平面节点和各个 Pod 中 `curl` 虚拟服务 IP - （在 `kubectl get services` 下可见） - * 服务发现，使用 Kubernetes `curl` 服务名称 - [默认 DNS 后缀](/zh/docs/concepts/services-networking/dns-pod-service/#services) - * 入站连接，从 Linux 控制平面节点或集群外部的计算机 `curl` NodePort - * 出站连接，使用 kubectl exec 从 Pod 内部 curl 外部 IP - - -{{< note >}} -由于当前平台对 Windows 网络堆栈的限制，Windows 容器主机无法访问在其上调度的服务的 IP。只有 Windows pods 才能访问服务 IP。 +由于当前 Windows 平台的网络堆栈限制，Windows 容器主机无法访问调度到其上的 Service 的 IP。 +只有 Windows Pod 能够访问 Service IP。 {{< /note >}} - -## 可观测性 {#observability} -### 抓取来自工作负载的日志 - - -日志是可观测性的重要一环；使用日志用户可以获得对负载运行状况的洞察， -因而日志是故障排查的一个重要手法。 -因为 Windows 容器中的 Windows 容器和负载与 Linux 容器的行为不同， -用户很难收集日志，因此运行状态的可见性很受限。 -例如，Windows 工作负载通常被配置为将日志输出到 Windows 事件跟踪 -（Event Tracing for Windows，ETW），或者将日志条目推送到应用的事件日志中。 -[LogMonitor](https://github.com/microsoft/windows-container-tools/tree/master/LogMonitor) -是 Microsoft 提供的一个开源工具，是监视 Windows 容器中所配置的日志源 -的推荐方式。 -LogMonitor 支持监视时间日志、ETW 提供者模块以及自定义的应用日志， -并使用管道的方式将其输出到标准输出（stdout），以便 `kubectl logs ` -这类命令能够读取这些数据。 - -请遵照 LogMonitor GitHub 页面上的指令，将其可执行文件和配置文件复制到 -你的所有容器中，并为其添加必要的入口点（Entrypoint），以便 LogMonitor -能够将你的日志输出推送到标准输出（stdout）。 +## 可观察性 {#observability} +### 捕捉来自工作负载的日志 {#capturing-logs-from-workloads} - -## 使用可配置的容器用户名 +## 配置容器用户 {#configuring-container-user} -从 Kubernetes v1.16 开始，可以为 Windows 容器配置与其镜像默认值不同的用户名 -来运行其入口点和进程。 -此能力的实现方式和 Linux 容器有些不同。 -在[此处](/zh/docs/tasks/configure-pod-container/configure-runasusername/) -可了解更多信息。 +### 使用可配置的容器用户名 {#using-configurable-container-usernames} - -## 使用组托管服务帐户管理工作负载身份 +### 使用组托管服务帐户（GMSA）管理工作负载身份 {#managing-workload-identity-with-group-managed-service-accounts} -从 Kubernetes v1.14 开始，可以将 Windows 容器工作负载配置为使用组托管服务帐户（GMSA）。 -组托管服务帐户是 Active Directory 帐户的一种特定类型，它提供自动密码管理， -简化的服务主体名称（SPN）管理以及将管理委派给跨多台服务器的其他管理员的功能。 -配置了 GMSA 的容器可以访问外部 Active Directory 域资源，同时携带通过 GMSA 配置的身份。 -在[此处](/zh/docs/tasks/configure-pod-container/configure-gmsa/)了解有关为 -Windows 容器配置和使用 GMSA 的更多信息。 +Windows 容器工作负载可以配置为使用组托管服务帐户（Group Managed Service Accounts，GMSA）。 +组托管服务帐户是一种特定类型的活动目录（Active Directory）帐户，可提供自动密码管理、 +简化的服务主体名称（Service Principal Name，SPN）管理，以及将管理委派给多个服务器上的其他管理员的能力。 +配置了 GMSA 的容器可以携带使用 GMSA 配置的身份访问外部活动目录域资源。 +在[此处](/zh/docs/tasks/configure-pod-container/configure-gmsa/)了解有关为 Windows 容器配置和使用 GMSA 的更多信息。 - -## 污点和容忍度 - -目前，用户需要将 Linux 和 Windows 工作负载运行在各自特定的操作系统的节点上， -因而需要结合使用污点和节点选择算符。 这可能仅给 Windows 用户造成不便。 -推荐的方法概述如下，其主要目标之一是该方法不应破坏与现有 Linux 工作负载的兼容性。 - +## 污点和容忍度 {#taints-and-tolerations} + +用户需要使用某种污点（Taint）和节点选择器的组合，以便将 Linux 和 Windows 工作负载各自调度到特定操作系统的节点。 +下面概述了推荐的方法，其主要目标之一是该方法不应破坏现有 Linux 工作负载的兼容性。 + +如果启用了 `IdentifyPodOS` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， +你可以（并且应该）将 Pod 的 `.spec.os.name` 设置为该 Pod 中的容器设计所用于的操作系统。 +对于运行 Linux 容器的 Pod，将 `.spec.os.name` 设置为 `linux`。 +对于运行 Windows 容器的 Pod，将 `.spec.os.name` 设置为 `Windows`。 {{< note >}} + +从 1.24 开始，`IdentifyPodOS` 特性处于 Beta 阶段，默认启用。 {{< /note >}} + -如果 `IdentifyPodOS` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)是启用的， -你可以（并且应该）为 Pod 设置 `.spec.os.name` 以表明该 Pod -中的容器所针对的操作系统。 对于运行 Linux 容器的 Pod，设置 -`.spec.os.name` 为 `linux`。 对于运行 Windows 容器的 Pod，设置 `.spec.os.name` -为 `Windows`。 - -{{< note >}} -从 1.24 开始，`IdentifyPodOS` 功能处于 Beta 阶段，默认启用。 -{{< /note >}} - -在将 Pod 分配给节点时，调度程序不使用 `.spec.os.name` 的值。你应该使用正常的 Kubernetes -机制[将 Pod 分配给节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)， -确保集群的控制平面将 Pod 放置到适合运行的操作系统。 -`.spec.os.name` 值对 Windows Pod 的调度没有影响，因此仍然需要污点、容忍度以及节点选择器， -以确保 Windows Pod 调度至合适的 Windows 节点。 - - -### 确保特定操作系统的工作负载落在适当的容器主机上 +调度器在将 Pod 分配到节点时并不使用 `.spec.os.name` 的值。 +你应该使用正常的 Kubernetes 机制[将 Pod 分配给节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)， +以确保集群的控制平面将 Pod 放置到运行适当操作系统的节点上。 + +`.spec.os.name` 值对 Windows Pod 的调度没有影响， +因此仍然需要污点和容忍以及节点选择器来确保 Windows Pod 落在适当的 Windows 节点。 + + -用户可以使用污点和容忍度确保 Windows 容器可以调度在适当的主机上。目前所有 Kubernetes 节点都具有以下默认标签： +### 确保特定于操作系统的工作负载落到合适的容器主机上 {#ensuring-os-specific-workloads-land-on-the-appropriate-container-host} + +用户可以使用污点（Taint）和容忍度（Toleration）确保将 Windows 容器调度至合适的主机上。 +现在，所有的 Kubernetes 节点都有以下默认标签： * kubernetes.io/os = [windows|linux] * kubernetes.io/arch = [amd64|arm64|...] - -如果 Pod 规范未指定诸如 `"kubernetes.io/os": windows` 之类的 nodeSelector，则该 Pod -可能会被调度到任何主机（Windows 或 Linux）上。 -这是有问题的，因为 Windows 容器只能在 Windows 上运行，而 Linux 容器只能在 Linux 上运行。 +如果 Pod 规约没有指定像 `"kubernetes.io/os": windows` 这样的 nodeSelector， +则 Pod 可以被调度到任何主机上，Windows 或 Linux。 +这可能会有问题，因为 Windows 容器只能在 Windows 上运行，而 Linux 容器只能在 Linux 上运行。 最佳实践是使用 nodeSelector。 - -但是，我们了解到，在许多情况下，用户都有既存的大量的 Linux 容器部署，以及一个现成的配置生态系统， -例如社区 Helm charts，以及程序化 Pod 生成案例，例如 Operators。 -在这些情况下，你可能会不愿意更改配置添加 nodeSelector。替代方法是使用污点。 -由于 kubelet 可以在注册期间设置污点，因此可以轻松修改它，使其仅在 Windows 上运行时自动添加污点。 +但是，我们了解到，在许多情况下，用户已经预先存在大量 Linux 容器部署， +以及现成配置的生态系统，例如社区中的 Helm Chart 包和程序化的 Pod 生成案例，例如 Operator。 +在这些情况下，你可能不愿更改配置来添加节点选择器。 +另一种方法是使用污点。因为 kubelet 可以在注册过程中设置污点， +所以可以很容易地修改为，当只能在 Windows 上运行时，自动添加污点。 - 例如：`--register-with-taints='os=windows:NoSchedule'` - -向所有 Windows 节点添加污点后，Kubernetes 将不会在它们上调度任何负载（包括现有的 Linux Pod）。 -为了使某 Windows Pod 调度到 Windows 节点上，该 Pod 需要 nodeSelector 和合适的匹配的容忍度设置来选择 Windows， +通过向所有 Windows 节点添加污点，任何负载都不会被调度到这些节点上（包括现有的 Linux Pod）。 +为了在 Windows 节点上调度 Windows Pod，它需要 nodeSelector 和匹配合适的容忍度来选择 Windows。 ```yaml nodeSelector: - kubernetes.io/os: windows - node.kubernetes.io/windows-build: '10.0.17763' + kubernetes.io/os: windows + node.kubernetes.io/windows-build: '10.0.17763' tolerations: - - key: "os" - operator: "Equal" - value: "windows" - effect: "NoSchedule" + - key: "os" + operator: "Equal" + value: "windows" + effect: "NoSchedule" ``` - -### 处理同一集群中的多个 Windows 版本 - -每个 Pod 使用的 Windows Server 版本必须与该节点的 Windows Server 版本相匹配。 -如果要在同一集群中使用多个 Windows Server 版本，则应该设置其他节点标签和 -nodeSelector。 - -Kubernetes 1.17 自动添加了一个新标签 `node.kubernetes.io/windows-build` 来简化此操作。 -如果你运行的是旧版本，则建议手动将此标签添加到 Windows 节点。 - -此标签反映了需要兼容的 Windows 主要、次要和内部版本号。以下是当前每个 -Windows Server 版本使用的值。 +### 处理同一集群中的多个 Windows 版本 {#handling-multiple-windows-versions-in-the-same-cluster} -| 产品名称 | 内部编号 | +每个 Pod 使用的 Windows Server 版本必须与节点的版本匹配。 +如果要在同一个集群中使用多个 Windows Server 版本，则应设置额外的节点标签和节点选择器。 + +Kubernetes 1.17 自动添加了一个新标签 `node.kubernetes.io/windows-build` 来简化这一点。 +如果你运行的是旧版本，则建议手动将此标签添加到 Windows 节点。 + +此标签反映了需要匹配以实现兼容性的 Windows 主要、次要和内部版本号。 +以下是目前用于每个 Windows Server 版本的值。 + + +| 产品名称 | 构建号 | |--------------------------------------|------------------------| | 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 | - - -### 使用 RuntimeClass 简化 - -[RuntimeClass](/zh/docs/concepts/containers/runtime-class/) 可用于 -简化使用污点和容忍度的过程。 -集群管理员可以创建 `RuntimeClass` 对象，用于封装这些污点和容忍度。 - -1. 将此文件保存到 `runtimeClasses.yml` 文件。 - 它包括适用于 Windows 操作系统、体系结构和版本的 `nodeSelector`。 +### 使用 RuntimeClass 进行简化 {#simplifying-with-runtimeclass} - ```yaml - apiVersion: node.k8s.io/v1 - kind: RuntimeClass - metadata: - name: windows-2019 - handler: 'docker' - scheduling: - nodeSelector: - kubernetes.io/os: 'windows' - kubernetes.io/arch: 'amd64' - node.kubernetes.io/windows-build: '10.0.17763' - tolerations: - - effect: NoSchedule - key: os - operator: Equal - value: "windows" - ``` +[RuntimeClass] 可用于简化使用污点和容忍度的流程。 +集群管理员可以创建一个用于封装这些污点和容忍度的 `RuntimeClass` 对象。 - -2. 集群管理员执行 `kubectl create -f runtimeClasses.yml` 操作 -3. 根据需要向 Pod 规约中添加 `runtimeClassName: windows-2019` - +1. 以集群管理员身份运行 `kubectl create -f runtimeClasses.yml` +1. 根据情况，向 Pod 规约中添加 `runtimeClassName: windows-2019` + 例如： ```yaml @@ -503,3 +478,5 @@ spec: selector: app: iis-2019 ``` + +[RuntimeClass]: https://kubernetes.io/docs/concepts/containers/runtime-class/ diff --git a/content/zh/docs/concepts/workloads/_index.md b/content/zh-cn/docs/concepts/workloads/_index.md similarity index 100% rename from content/zh/docs/concepts/workloads/_index.md rename to content/zh-cn/docs/concepts/workloads/_index.md diff --git a/content/zh/docs/concepts/workloads/controllers/_index.md b/content/zh-cn/docs/concepts/workloads/controllers/_index.md similarity index 100% rename from content/zh/docs/concepts/workloads/controllers/_index.md rename to content/zh-cn/docs/concepts/workloads/controllers/_index.md diff --git a/content/zh/docs/concepts/workloads/controllers/cron-jobs.md b/content/zh-cn/docs/concepts/workloads/controllers/cron-jobs.md similarity index 78% rename from content/zh/docs/concepts/workloads/controllers/cron-jobs.md rename to content/zh-cn/docs/concepts/workloads/controllers/cron-jobs.md index e31fa8edc3..e52908f51e 100644 --- a/content/zh/docs/concepts/workloads/controllers/cron-jobs.md +++ b/content/zh-cn/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 标准库中的时区数据库包含在二进制文件中，并用作备用数据库，以防系统上没有外部数据库可用。 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-cn/docs/concepts/workloads/controllers/replicaset.md similarity index 78% rename from content/zh/docs/concepts/workloads/controllers/replicaset.md rename to content/zh-cn/docs/concepts/workloads/controllers/replicaset.md index ca92f8378e..b55efa8345 100644 --- a/content/zh/docs/concepts/workloads/controllers/replicaset.md +++ b/content/zh-cn/docs/concepts/workloads/controllers/replicaset.md @@ -48,7 +48,7 @@ ReplicaSet's identifying information within their ownerReferences field. It's th knows of the state of the Pods it is maintaining and plans accordingly. --> ReplicaSet 通过 Pod 上的 -[metadata.ownerReferences](/zh/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents) +[metadata.ownerReferences](/zh-cn/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents) 字段连接到附属 Pod，该字段给出当前对象的属主资源。 ReplicaSet 所获得的 Pod 都在其 ownerReferences 字段中包含了属主 ReplicaSet 的标识信息。正是通过这一连接，ReplicaSet 知道它所维护的 Pod 集合的状态， @@ -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,17 +90,16 @@ Deployment，并在 spec 部分定义你的应用。 -## 示例 +## 示例 {#example} {{< codenew file="controllers/frontend.yaml" >}} 将此清单保存到 `frontend.yaml` 中，并将其提交到 Kubernetes 集群， -应该就能创建 yaml 文件所定义的 ReplicaSet 及其管理的 Pod。 - +就能创建 yaml 文件所定义的 ReplicaSet 及其管理的 Pod。 ```shell kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml @@ -139,25 +139,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,26 +226,19 @@ metadata: -## 非模板 Pod 的获得 +## 非模板 Pod 的获得 {#non-template-pod-acquisitions} -尽管你完全可以直接创建裸的 Pods，强烈建议你确保这些裸的 Pods 并不包含可能与你 -的某个 ReplicaSet 的选择算符相匹配的标签。原因在于 ReplicaSet 并不仅限于拥有 -在其模板中设置的 Pods，它还可以像前面小节中所描述的那样获得其他 Pods。 +尽管你完全可以直接创建裸的 Pod，强烈建议你确保这些裸的 Pod 并不包含可能与你的某个 +ReplicaSet 的选择算符相匹配的标签。原因在于 ReplicaSet 并不仅限于拥有在其模板中设置的 +Pod，它还可以像前面小节中所描述的那样获得其他 Pod。 {{< codenew file="pods/pod-rs.yaml" >}} @@ -256,11 +249,10 @@ ReplicaSet, they will immediately be acquired by it. Suppose you create the Pods after the frontend ReplicaSet has been deployed and has set up its initial Pod replicas to fulfill its replica count requirement: --> -由于这些 Pod 没有控制器（Controller，或其他对象）作为其属主引用，并且 -其标签与 frontend ReplicaSet 的选择算符匹配，它们会立即被该 ReplicaSet -获取。 +由于这些 Pod 没有控制器（Controller，或其他对象）作为其属主引用， +并且其标签与 frontend ReplicaSet 的选择算符匹配，它们会立即被该 ReplicaSet 获取。 -假定你在 frontend ReplicaSet 已经被部署之后创建 Pods，并且你已经在 ReplicaSet +假定你在 frontend ReplicaSet 已经被部署之后创建 Pod，并且你已经在 ReplicaSet 中设置了其初始的 Pod 副本数以满足其副本计数需要： ```shell @@ -273,8 +265,8 @@ its desired count. Fetching the Pods: --> -新的 Pods 会被该 ReplicaSet 获取，并立即被 ReplicaSet 终止，因为 -它们的存在会使得 ReplicaSet 中 Pod 个数超出其期望值。 +新的 Pod 会被该 ReplicaSet 获取，并立即被 ReplicaSet 终止， +因为它们的存在会使得 ReplicaSet 中 Pod 个数超出其期望值。 取回 Pods： @@ -286,9 +278,9 @@ kubectl get pods -输出显示新的 Pods 或者已经被终止，或者处于终止过程中： +输出显示新的 Pod 或者已经被终止，或者处于终止过程中： -```shell +``` NAME READY STATUS RESTARTS AGE frontend-b2zdv 1/1 Running 0 10m frontend-vcmts 1/1 Running 0 10m @@ -319,9 +311,9 @@ kubectl apply -f https://kubernetes.io/examples/controllers/frontend.yaml You shall see that the ReplicaSet has acquired the Pods and has only created new ones according to its spec until the number of its new Pods and the original matches its desired count. As fetching the Pods: --> -你会看到 ReplicaSet 已经获得了该 Pods，并仅根据其规约创建新的 Pods，直到 -新的 Pods 和原来的 Pods 的总数达到其预期个数。 -这时取回 Pods： +你会看到 ReplicaSet 已经获得了该 Pod，并仅根据其规约创建新的 Pod， +直到新的 Pod 和原来的 Pod 的总数达到其预期个数。 +这时取回 Pod 列表： ```shell kubectl get pods @@ -339,10 +331,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。 ReplicaSet 对象的名称必须是合法的 -[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 +[DNS 子域名](/zh-cn/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-cn/docs/concepts/workloads/pods/#pod-templates)， 要求设置标签。在 `frontend.yaml` 示例中，我们指定了标签 `tier: frontend`。 注意不要将标签与其他控制器的选择算符重叠，否则那些控制器会尝试收养此 Pod。 -对于模板的[重启策略](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) +对于模板的[重启策略](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 字段，`.spec.template.spec.restartPolicy`，唯一允许的取值是 `Always`，这也是默认值. ### Pod 选择算符 {#pod-selector} -`.spec.selector` 字段是一个[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)。 +`.spec.selector` 字段是一个[标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/)。 如前文中[所讨论的](#how-a-replicaset-works)，这些是用来标识要被获取的 Pods 的标签。在签名的 `frontend.yaml` 示例中，选择算符为： @@ -408,17 +404,16 @@ matchLabels: tier: frontend ``` -在 ReplicaSet 中，`.spec.template.metadata.labels` 的值必须与 `spec.selector` 值 -相匹配，否则该配置会被 API 拒绝。 +在 ReplicaSet 中，`.spec.template.metadata.labels` 的值必须与 `spec.selector` +值相匹配，否则该配置会被 API 拒绝。 {{< note >}} -对于设置了相同的 `.spec.selector`，但 -`.spec.template.metadata.labels` 和 `.spec.template.spec` 字段不同的 -两个 ReplicaSet 而言，每个 ReplicaSet 都会忽略被另一个 ReplicaSet 所 -创建的 Pods。 +对于设置了相同的 `.spec.selector`，但 +`.spec.template.metadata.labels` 和 `.spec.template.spec` 字段不同的两个 +ReplicaSet 而言，每个 ReplicaSet 都会忽略被另一个 ReplicaSet 所创建的 Pods。 {{< /note >}} -## 使用 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/) +默认情况下，[垃圾收集器](/zh-cn/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 +486,8 @@ curl -X DELETE 'localhost:8080/apis/apps/v1/namespaces/default/replicasets/fron @@ -498,20 +495,19 @@ To update Pods to a new spec in a controlled way, use a 由于新旧 ReplicaSet 的 `.spec.selector` 是相同的，新的 ReplicaSet 将接管老的 Pod。 但是，它不会努力使现有的 Pod 与新的、不同的 Pod 模板匹配。 若想要以可控的方式更新 Pod 的规约，可以使用 -[Deployment](/zh/docs/concepts/workloads/controllers/deployment/#creating-a-deployment) +[Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/#creating-a-deployment) 资源，因为 ReplicaSet 并不直接支持滚动更新。 -### 将 Pod 从 ReplicaSet 中隔离 +### 将 Pod 从 ReplicaSet 中隔离 {#isolating-pods-from-a-replicaset} -可以通过改变标签来从 ReplicaSet 的目标集中移除 Pod。 +可以通过改变标签来从 ReplicaSet 中移除 Pod。 这种技术可以用来从服务中去除 Pod，以便进行排错、数据恢复等。 以这种方式移除的 Pod 将被自动替换（假设副本的数量没有改变）。 @@ -519,9 +515,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 是可用的和可操作的。 @@ -547,11 +543,10 @@ prioritize scaling down pods based on the following general algorithm: 较小的优先被裁减掉 3. 所处节点上副本个数较多的 Pod 优先于所处节点上副本较少者 4. 如果 Pod 的创建时间不同，最近创建的 Pod 优先于早前创建的 Pod 被裁减。 - （当 `LogarithmicScaleDown` 这一 - [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) + （当 `LogarithmicScaleDown` 这一[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) 被启用时，创建时间是按整数幂级来分组的）。 -如果以上比较结果都相同，则随机选择。 +如果以上比较结果都相同，则随机选择。 -通过使用 [`controller.kubernetes.io/pod-deletion-cost`](/zh/docs/reference/labels-annotations-taints/#pod-deletion-cost) +通过使用 [`controller.kubernetes.io/pod-deletion-cost`](/zh-cn/docs/reference/labels-annotations-taints/#pod-deletion-cost) 注解，用户可以对 ReplicaSet 缩容时要先删除哪些 Pods 设置偏好。 此功能特性处于 Beta 阶段，默认被禁用。你可以通过为 kube-apiserver 和 -kube-controller-manager 设置 -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +kube-controller-manager 设置[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) `PodDeletionCost` 来启用此功能。 {{< note >}} @@ -601,7 +595,7 @@ kube-controller-manager 设置 --> - 此机制实施时仅是尽力而为，并不能对 Pod 的删除顺序作出任何保证； - 用户应避免频繁更新注解值，例如根据某观测度量值来更新此注解值是应该避免的。 - 这样做会在 API 服务器上产生大量的 Pod 更新操作。 + 这样做会在 API 服务器上产生大量的 Pod 更新操作。 {{< /note >}} -#### 使用场景示例 +#### 使用场景示例 {#example-use-case} 同一应用的不同 Pods 可能其利用率是不同的。在对应用执行缩容操作时，可能 希望移除利用率较低的 Pods。为了避免频繁更新 Pods，应用应该在执行缩容 @@ -623,17 +617,16 @@ 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/) +ReplicaSet 也可以作为[水平的 Pod 缩放器 (HPA)](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/) 的目标。也就是说，ReplicaSet 可以被 HPA 自动缩放。 以下是 HPA 以我们在前一个示例中创建的副本集为目标的示例。 @@ -642,7 +635,7 @@ ReplicaSet 也可以作为 将这个列表保存到 `hpa-rs.yaml` 并提交到 Kubernetes 集群，就能创建它所定义的 HPA，进而就能根据复制的 Pod 的 CPU 利用率对目标 ReplicaSet进行自动缩放。 @@ -655,7 +648,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 +657,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 滚动更新的对象。 -尽管 ReplicaSet 可以独立使用，目前它们的主要用途是提供给 Deployment 作为 -编排 Pod 创建、删除和更新的一种机制。当使用 Deployment 时，你不必关心 -如何管理它所创建的 ReplicaSet，Deployment 拥有并管理其 ReplicaSet。 +[`Deployment`](/zh-cn/docs/concepts/workloads/controllers/deployment/) 是一个可以拥有 +ReplicaSet 并使用声明式方式在服务器端完成对 Pods 滚动更新的对象。 +尽管 ReplicaSet 可以独立使用，目前它们的主要用途是提供给 Deployment 作为编排 +Pod 创建、删除和更新的一种机制。当使用 Deployment 时，你不必关心如何管理它所创建的 +ReplicaSet，Deployment 拥有并管理其 ReplicaSet。 因此，建议你在需要 ReplicaSet 时使用 Deployment。 -### 裸 Pod +### 裸 Pod {#bare-pods} 与用户直接创建 Pod 的情况不同，ReplicaSet 会替换那些由于某些原因被删除或被终止的 Pod，例如在节点故障或破坏性的节点维护（如内核升级）的情况下。 因为这个原因，我们建议你使用 ReplicaSet，即使应用程序只需要一个 Pod。 想像一下，ReplicaSet 类似于进程监视器，只不过它在多个节点上监视多个 Pod， 而不是在单个节点上监视单个进程。 -ReplicaSet 将本地容器重启的任务委托给了节点上的某个代理（例如，Kubelet 或 Docker）去完成。 +ReplicaSet 将本地容器重启的任务委托给了节点上的某个代理（例如，Kubelet）去完成。 - ### Job -使用[`Job`](/zh/docs/concepts/workloads/controllers/job/) 代替ReplicaSet， +使用[`Job`](/zh-cn/docs/concepts/workloads/controllers/job/) 代替 ReplicaSet， 可以用于那些期望自行终止的 Pod。 ### DaemonSet 对于管理那些提供主机级别功能（如主机监控和主机日志）的容器， -就要用 [`DaemonSet`](/zh/docs/concepts/workloads/controllers/daemonset/) +就要用 [`DaemonSet`](/zh-cn/docs/concepts/workloads/controllers/daemonset/) 而不用 ReplicaSet。 这些 Pod 的寿命与主机寿命有关：这些 Pod 需要先于主机上的其他 Pod 运行， 并且在机器准备重新启动/关闭时安全地终止。 @@ -734,9 +726,9 @@ The two serve the same purpose, and behave similarly, except that a ReplicationC selector requirements as described in the [labels user guide](/docs/concepts/overview/working-with-objects/labels/#label-selectors). As such, ReplicaSets are preferred over ReplicationControllers --> -ReplicaSet 是 [ReplicationController](/zh/docs/concepts/workloads/controllers/replicationcontroller/) +ReplicaSet 是 [ReplicationController](/zh-cn/docs/concepts/workloads/controllers/replicationcontroller/) 的后继者。二者目的相同且行为类似，只是 ReplicationController 不支持 -[标签用户指南](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors) +[标签用户指南](/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors) 中讨论的基于集合的选择算符需求。 因此，相比于 ReplicationController，应优先考虑 ReplicaSet。 @@ -753,9 +745,13 @@ ReplicaSet 是 [ReplicationController](/zh/docs/concepts/workloads/controllers/r * Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions. --> -* 了解 [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/)，了解如何在干扰下运行高度可用的应用。 +* 了解 [Pod](/zh-cn/docs/concepts/workloads/pods)。 +* 了解 [Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/)。 +* [使用 Deployment 运行一个无状态应用](/zh-cn/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-cn/docs/concepts/workloads/pods/disruptions/)， + 了解如何在干扰下运行高度可用的应用。 + diff --git a/content/zh/docs/concepts/workloads/controllers/replicationcontroller.md b/content/zh-cn/docs/concepts/workloads/controllers/replicationcontroller.md similarity index 100% rename from content/zh/docs/concepts/workloads/controllers/replicationcontroller.md rename to content/zh-cn/docs/concepts/workloads/controllers/replicationcontroller.md diff --git a/content/zh/docs/concepts/workloads/controllers/statefulset.md b/content/zh-cn/docs/concepts/workloads/controllers/statefulset.md similarity index 100% rename from content/zh/docs/concepts/workloads/controllers/statefulset.md rename to content/zh-cn/docs/concepts/workloads/controllers/statefulset.md diff --git a/content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished.md similarity index 100% rename from content/zh/docs/concepts/workloads/controllers/ttlafterfinished.md rename to content/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished.md diff --git a/content/zh/docs/concepts/workloads/pods/_index.md b/content/zh-cn/docs/concepts/workloads/pods/_index.md similarity index 100% rename from content/zh/docs/concepts/workloads/pods/_index.md rename to content/zh-cn/docs/concepts/workloads/pods/_index.md diff --git a/content/zh/docs/concepts/workloads/pods/disruptions.md b/content/zh-cn/docs/concepts/workloads/pods/disruptions.md similarity index 100% rename from content/zh/docs/concepts/workloads/pods/disruptions.md rename to content/zh-cn/docs/concepts/workloads/pods/disruptions.md diff --git a/content/zh/docs/concepts/workloads/pods/ephemeral-containers.md b/content/zh-cn/docs/concepts/workloads/pods/ephemeral-containers.md similarity index 100% rename from content/zh/docs/concepts/workloads/pods/ephemeral-containers.md rename to content/zh-cn/docs/concepts/workloads/pods/ephemeral-containers.md diff --git a/content/zh/docs/concepts/workloads/pods/init-containers.md b/content/zh-cn/docs/concepts/workloads/pods/init-containers.md similarity index 95% rename from content/zh/docs/concepts/workloads/pods/init-containers.md rename to content/zh-cn/docs/concepts/workloads/pods/init-containers.md index 198111fe04..18782f28ce 100644 --- a/content/zh/docs/concepts/workloads/pods/init-containers.md +++ b/content/zh-cn/docs/concepts/workloads/pods/init-containers.md @@ -145,8 +145,8 @@ have some advantages for start-up related code: * Init 容器能以不同于 Pod 内应用容器的文件系统视图运行。因此，Init 容器可以访问 应用容器不能访问的 {{< glossary_tooltip text="Secret" term_id="secret" >}} 的权限。 -* 由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器 - 提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。 +* 由于 Init 容器必须在应用容器启动之前运行完成，因此 Init + 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。 一旦前置条件满足，Pod 内的所有的应用容器会并行启动。 +### 示例 {#examples} + +下面是一些如何使用 Init 容器的想法： + +* 等待一个 Service 完成创建，通过类似如下 Shell 命令： + ```shell for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1 ``` - * Register this Pod with a remote server from the downward API with a command like: + +* 注册这个 Pod 到远程服务器，通过在命令中调用 API，类似如下： + ```shell curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register -d 'instance=$()&ip=$()' ``` + + +* 在启动应用容器之前等一段时间，使用类似命令： + ```shell sleep 60 ``` - + -### 示例 {#examples} - -下面是一些如何使用 Init 容器的想法： - -* 等待一个 Service 完成创建，通过类似如下 shell 命令： - - ```shell - for i in {1..100}; do sleep 1; if dig myservice; then exit 0; fi; done; exit 1 - ``` - -* 注册这个 Pod 到远程服务器，通过在命令中调用 API，类似如下： - - ```shell - curl -X POST http://$MANAGEMENT_SERVICE_HOST:$MANAGEMENT_SERVICE_PORT/register \ - -d 'instance=$()&ip=$()' - ``` - -* 在启动应用容器之前等一段时间，使用类似命令： - - ```shell - sleep 60 - ``` - * 克隆 Git 仓库到{{< glossary_tooltip text="卷" term_id="volume" >}}中。 * 将配置值放到配置文件中，运行模板工具为主应用容器动态地生成配置文件。 @@ -249,6 +242,7 @@ kubectl apply -f myapp.yaml The output is similar to this: --> 输出类似于： + ``` pod/myapp-pod created ``` @@ -261,10 +255,12 @@ And check on its status with: ```shell kubectl get -f myapp.yaml ``` + 输出类似于： + ``` NAME READY STATUS RESTARTS AGE myapp-pod 0/1 Init:0/2 0 6m @@ -278,10 +274,12 @@ or for more details: ```shell kubectl describe -f myapp.yaml ``` + 输出类似于： + ``` Name: myapp-pod Namespace: default @@ -408,13 +406,26 @@ init containers. [What's next](#what-s-next) contains a link to a more detailed During Pod startup, the kubelet delays running init containers until the networking and storage are ready. Then the kubelet runs the Pod's init containers in the order they appear in the Pod's spec. +--> +## 具体行为 {#detailed-behavior} +在 Pod 启动过程中，每个 Init 容器会在网络和数据卷初始化之后按顺序启动。 +kubelet 运行依据 Init 容器在 Pod 规约中的出现顺序依次运行之。 + + +每个 Init 容器成功退出后才会启动下一个 Init 容器。 +如果某容器因为容器运行时的原因无法启动，或以错误状态退出，kubelet 会根据 +Pod 的 `restartPolicy` 策略进行重试。 +然而，如果 Pod 的 `restartPolicy` 设置为 "Always"，Init 容器失败时会使用 +`restartPolicy` 的 "OnFailure" 策略。 + -## 具体行为 {#detailed-behavior} - -在 Pod 启动过程中，每个 Init 容器会在网络和数据卷初始化之后按顺序启动。 -kubelet 运行依据 Init 容器在 Pod 规约中的出现顺序依次运行之。 - -每个 Init 容器成功退出后才会启动下一个 Init 容器。 -如果某容器因为容器运行时的原因无法启动，或以错误状态退出，kubelet 会根据 -Pod 的 `restartPolicy` 策略进行重试。 -然而，如果 Pod 的 `restartPolicy` 设置为 "Always"，Init 容器失败时会使用 -`restartPolicy` 的 "OnFailure" 策略。 - 在所有的 Init 容器没有成功之前，Pod 将不会变成 `Ready` 状态。 Init 容器的端口将不会在 Service 中进行聚集。正在初始化中的 Pod 处于 `Pending` 状态， 但会将状况 `Initializing` 设置为 false。 @@ -446,11 +446,6 @@ Altering an init container image field is equivalent to restarting the Pod. Because init containers can be restarted, retried, or re-executed, init container code should be idempotent. In particular, code that writes to files on `EmptyDirs` should be prepared for the possibility that an output file already exists. - -Init containers have all of the fields of an app container. However, Kubernetes -prohibits `readinessProbe` from being used because init containers cannot -define readiness distinct from completion. This is enforced during validation. - --> 对 Init 容器规约的修改仅限于容器的 `image` 字段。 更改 Init 容器的 `image` 字段，等同于重启该 Pod。 @@ -458,6 +453,11 @@ define readiness distinct from completion. This is enforced during validation. 因为 Init 容器可能会被重启、重试或者重新执行，所以 Init 容器的代码应该是幂等的。 特别地，基于 `emptyDirs` 写文件的代码，应该对输出文件可能已经存在做好准备。 + Init 容器具有应用容器的所有字段。然而 Kubernetes 禁止使用 `readinessProbe`， 因为 Init 容器不能定义不同于完成态（Completion）的就绪态（Readiness）。 Kubernetes 会在校验时强制执行此检查。 @@ -487,31 +487,36 @@ Init 容器一直重复失败。 Given the ordering and execution for init containers, the following rules for resource usage apply: +--> +### 资源 {#resources} +在给定的 Init 容器执行顺序下，资源使用适用于如下规则： + + +* 所有 Init 容器上定义的任何特定资源的 limit 或 request 的最大值，作为 + Pod **有效初始 request/limit**。 + 如果任何资源没有指定资源限制，这被视为最高限制。 +* Pod 对资源的 **有效 limit/request** 是如下两者中的较大者： + * 所有应用容器对某个资源的 limit/request 之和 + * 对某个资源的有效初始 limit/request + + -### 资源 {#resources} - -在给定的 Init 容器执行顺序下，资源使用适用于如下规则： - -* 所有 Init 容器上定义的任何特定资源的 limit 或 request 的最大值，作为 Pod *有效初始 request/limit*。 - 如果任何资源没有指定资源限制，这被视为最高限制。 -* Pod 对资源的 *有效 limit/request* 是如下两者的较大者： - * 所有应用容器对某个资源的 limit/request 之和 - * 对某个资源的有效初始 limit/request * 基于有效 limit/request 完成调度，这意味着 Init 容器能够为初始化过程预留资源， 这些资源在 Pod 生命周期过程中并没有被使用。 -* Pod 的 *有效 QoS 层* ，与 Init 容器和应用容器的一样。 +* Pod 的 **有效 QoS 层** ，与 Init 容器和应用容器的一样。 +### Pod 重启的原因 {#pod-restart-reasons} +Pod 重启会导致 Init 容器重新执行，主要有如下几个原因： + + -### Pod 重启的原因 {#pod-restart-reasons} - -Pod 重启会导致 Init 容器重新执行，主要有如下几个原因： - * Pod 的基础设施容器 (译者注：如 `pause` 容器) 被重启。这种情况不多见， 必须由具备 root 权限访问节点的人员来完成。 @@ -549,8 +555,8 @@ applies for Kubernetes v1.20 and later. If you are using an earlier version of Kubernetes, consult the documentation for the version you are using. --> 当 Init 容器的镜像发生改变或者 Init 容器的完成记录因为垃圾收集等原因被丢失时， -Pod 不会被重启。这一行为适用于 Kubernetes v1.20 及更新版本。如果你在使用较早 -版本的 Kubernetes，可查阅你所使用的版本对应的文档。 +Pod 不会被重启。这一行为适用于 Kubernetes v1.20 及更新版本。 +如果你在使用较早版本的 Kubernetes，可查阅你所使用的版本对应的文档。 ## {{% heading "whatsnext" %}} @@ -558,5 +564,6 @@ Pod 不会被重启。这一行为适用于 Kubernetes v1.20 及更新版本。 * Read about [creating a Pod that has an init container](/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container) * Learn how to [debug init containers](/docs/tasks/debug/debug-application/debug-init-containers/) --> -* 阅读[创建包含 Init 容器的 Pod](/zh/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container) -* 学习如何[调试 Init 容器](/zh/docs/tasks/debug/debug-application/debug-init-containers/) +* 阅读[创建包含 Init 容器的 Pod](/zh-cn/docs/tasks/configure-pod-container/configure-pod-initialization/#create-a-pod-that-has-an-init-container) +* 学习如何[调试 Init 容器](/zh-cn/docs/tasks/debug/debug-application/debug-init-containers/) + diff --git a/content/zh/docs/concepts/workloads/pods/pod-lifecycle.md b/content/zh-cn/docs/concepts/workloads/pods/pod-lifecycle.md similarity index 100% rename from content/zh/docs/concepts/workloads/pods/pod-lifecycle.md rename to content/zh-cn/docs/concepts/workloads/pods/pod-lifecycle.md diff --git a/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints.md similarity index 83% rename from content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md rename to content/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index ab91304c04..5c698ac514 100644 --- a/content/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -10,19 +10,14 @@ content_type: concept weight: 40 --> -{{< feature-state for_k8s_version="v1.19" state="stable" >}} - - 你可以使用 _拓扑分布约束（Topology Spread Constraints）_ 来控制 -{{< glossary_tooltip text="Pods" term_id="Pod" >}} 在集群内故障域 -之间的分布，例如区域（Region）、可用区（Zone）、节点和其他用户自定义拓扑域。 +{{< glossary_tooltip text="Pod" term_id="Pod" >}} 在集群内故障域之间的分布， +例如区域（Region）、可用区（Zone）、节点和其他用户自定义拓扑域。 这样做有助于实现高可用并提升资源利用率。 @@ -123,31 +118,75 @@ You can define one or multiple `topologySpreadConstraint` to instruct the kube-s - when `whenUnsatisfiable` equals to "DoNotSchedule", `maxSkew` is the maximum permitted difference between the number of matching pods in the target topology and the global minimum. + (the minimum number of pods that match the label selector in a topology domain. + For example, if you have 3 zones with 0, 2 and 3 matching pods respectively, + The global minimum is 0). - when `whenUnsatisfiable` equals to "ScheduleAnyway", scheduler gives higher precedence to topologies that would help reduce the skew. +--> + +- **maxSkew** 描述 Pod 分布不均的程度。这是给定拓扑类型中任意两个拓扑域中匹配的 + Pod 之间的最大允许差值。它必须大于零。取决于 `whenUnsatisfiable` 的取值， + 其语义会有不同。 + - 当 `whenUnsatisfiable` 等于 "DoNotSchedule" 时，`maxSkew` 是目标拓扑域中匹配的 + Pod 数与全局最小值（一个拓扑域中与标签选择器匹配的 Pod 的最小数量。例如，如果你有 + 3 个区域，分别具有 0 个、2 个 和 3 个匹配的 Pod，则全局最小值为 0。）之间可存在的差异。 + - 当 `whenUnsatisfiable` 等于 "ScheduleAnyway" 时，调度器会更为偏向能够降低偏差值的拓扑域。 + + +- **minDomains** 表示符合条件的域的最小数量。域是拓扑的一个特定实例。 + 符合条件的域是其节点与节点选择器匹配的域。 + + - 指定的 `minDomains` 的值必须大于 0。 + - 当符合条件的、拓扑键匹配的域的数量小于 `minDomains` 时，Pod 拓扑分布将“全局最小值” + （global minimum）设为 0，然后进行 `skew` 计算。“全局最小值”是一个符合条件的域中匹配 + Pod 的最小数量，如果符合条件的域的数量小于 `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 >}} + + - -- **maxSkew** 描述 Pod 分布不均的程度。这是给定拓扑类型中任意两个拓扑域中 - 匹配的 pod 之间的最大允许差值。它必须大于零。取决于 `whenUnsatisfiable` 的 - 取值，其语义会有不同。 - - 当 `whenUnsatisfiable` 等于 "DoNotSchedule" 时，`maxSkew` 是目标拓扑域 - 中匹配的 Pod 数与全局最小值之间可存在的差异。 - - 当 `whenUnsatisfiable` 等于 "ScheduleAnyway" 时，调度器会更为偏向能够降低 - 偏差值的拓扑域。 - **topologyKey** 是节点标签的键。如果两个节点使用此键标记并且具有相同的标签值， - 则调度器会将这两个节点视为处于同一拓扑域中。调度器试图在每个拓扑域中放置数量 - 均衡的 Pod。 + 则调度器会将这两个节点视为处于同一拓扑域中。调度器试图在每个拓扑域中放置数量均衡的 Pod。 + - **whenUnsatisfiable** 指示如果 Pod 不满足分布约束时如何处理： - `DoNotSchedule`（默认）告诉调度器不要调度。 - - `ScheduleAnyway` 告诉调度器仍然继续调度，只是根据如何能将偏差最小化来对 - 节点进行排序。 -- **labelSelector** 用于查找匹配的 pod。匹配此标签的 Pod 将被统计，以确定相应 - 拓扑域中 Pod 的数量。 + - `ScheduleAnyway` 告诉调度器仍然继续调度，只是根据如何能将偏差最小化来对节点进行排序。 + +- **labelSelector** 用于查找匹配的 Pod。匹配此标签的 Pod 将被统计， + 以确定相应拓扑域中 Pod 的数量。 有关详细信息，请参考[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)。 -你可以执行 `kubectl explain Pod.spec.topologySpreadConstraints` 命令以 -了解关于 topologySpreadConstraints 的更多信息。 +你可以执行 `kubectl explain Pod.spec.topologySpreadConstraints` +命令以了解关于 topologySpreadConstraints 的更多信息。 `topologyKey: zone` 意味着均匀分布将只应用于存在标签键值对为 -"zone:<any value>" 的节点。 +"zone:<任何值>" 的节点。 `whenUnsatisfiable: DoNotSchedule` 告诉调度器如果新的 Pod 不满足约束， 则让它保持悬决状态。 -如果调度器将新的 Pod 放入 "zoneA"，Pods 分布将变为 [3, 1]，因此实际的偏差 -为 2（3 - 1）。这违反了 `maxSkew: 1` 的约定。此示例中，新 Pod 只能放置在 +如果调度器将新的 Pod 放入 "zoneA"，Pods 分布将变为 [3, 1]，因此实际的偏差为 +2（3 - 1）。这违反了 `maxSkew: 1` 的约定。此示例中，新 Pod 只能放置在 "zoneB" 上： {{}} @@ -313,8 +351,8 @@ You can use 2 TopologySpreadConstraints to control the Pods spreading on both zo In this case, to match the first constraint, the incoming Pod can only be placed onto "zoneB"; while in terms of the second constraint, the incoming Pod can only be placed onto "node4". Then the results of 2 constraints are ANDed, so the only viable option is to place on "node4". --> 在这种情况下，为了匹配第一个约束，新的 Pod 只能放置在 "zoneB" 中；而在第二个约束中， -新的 Pod 只能放置在 "node4" 上。最后两个约束的结果加在一起，唯一可行的选择是放置 -在 "node4" 上。 +新的 Pod 只能放置在 "node4" 上。最后两个约束的结果加在一起，唯一可行的选择是放置在 +"node4" 上。 如果对集群应用 "two-constraints.yaml"，会发现 "mypod" 处于 `Pending` 状态。 这是因为：为了满足第一个约束，"mypod" 只能放在 "zoneB" 中，而第二个约束要求 @@ -406,7 +444,7 @@ class zoneC cluster; 而且你知道 "zoneC" 必须被排除在外。在这种情况下，可以按如下方式编写 YAML， 以便将 "mypod" 放置在 "zoneB" 上，而不是 "zoneC" 上。同样，`spec.nodeSelector` @@ -437,7 +475,7 @@ There are some implicit conventions worth noting here: - The scheduler will bypass the nodes without `topologySpreadConstraints[*].topologyKey` present. This implies that: 1. the Pods located on those nodes do not impact `maxSkew` calculation - in the above example, suppose "node1" does not have label "zone", then the 2 Pods will be disregarded, hence the incoming Pod will be scheduled into "zoneA". - 2. the incoming Pod has no chances to be scheduled onto this kind of nodes - in the above example, suppose a "node5" carrying label `{zone-typo: zoneC}` joins the cluster, it will be bypassed due to the absence of label key "zone". + 2. the incoming Pod has no chances to be scheduled onto such nodes - in the above example, suppose a "node5" carrying label `{zone-typo: zoneC}` joins the cluster, it will be bypassed due to the absence of label key "zone". --> - 只有与新的 Pod 具有相同命名空间的 Pod 才能作为匹配候选者。 - 调度器会忽略没有 `topologySpreadConstraints[*].topologyKey` 的节点。这意味着： @@ -452,8 +490,8 @@ There are some implicit conventions worth noting here: -- 注意，如果新 Pod 的 `topologySpreadConstraints[*].labelSelector` 与自身的 - 标签不匹配，将会发生什么。 +- 注意，如果新 Pod 的 `topologySpreadConstraints[*].labelSelector` + 与自身的标签不匹配，将会发生什么。 在上面的例子中，如果移除新 Pod 上的标签，Pod 仍然可以调度到 "zoneB"，因为约束仍然满足。 然而，在调度之后，集群的不平衡程度保持不变。zoneA 仍然有 2 个带有 {foo:bar} 标签的 Pod， zoneB 有 1 个带有 {foo:bar} 标签的 Pod。 @@ -471,8 +509,8 @@ topology spread constraints are applied to a Pod if, and only if: --> ### 集群级别的默认约束 {#cluster-level-default-constraints} -为集群设置默认的拓扑分布约束也是可能的。默认拓扑分布约束在且仅在以下条件满足 -时才会应用到 Pod 上： +为集群设置默认的拓扑分布约束也是可能的。 +默认拓扑分布约束在且仅在以下条件满足时才会被应用到 Pod 上： - Pod 没有在其 `.spec.topologySpreadConstraints` 设置任何约束； - Pod 隶属于某个服务、副本控制器、ReplicaSet 或 StatefulSet。 @@ -511,16 +549,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 +583,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)。 -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 管理者的职责。关于如何提供较好的评审意见， @@ -179,10 +179,10 @@ To close a pull request, leave a `/close` comment on the PR. 要关闭 PR，请在 PR 上输入 `/close` 评论。 {{< note >}} -一个名为 [`fejta-bot`](https://github.com/fejta-bot) 的自动服务会在 Issue 停滞 90 +一个名为 [`k8s-ci-robot`](https://github.com/k8s-ci-robot) 的自动服务会在 Issue 停滞 90 天后自动将其标记为过期；然后再等 30 天，如果仍然无人过问，则将其关闭。 PR 管理者应该在 issues 处于无人过问状态 14-30 天后关闭它们。 {{< /note >}} @@ -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/participate/roles-and-responsibilities.md b/content/zh-cn/docs/contribute/participate/roles-and-responsibilities.md similarity index 100% rename from content/zh/docs/contribute/participate/roles-and-responsibilities.md rename to content/zh-cn/docs/contribute/participate/roles-and-responsibilities.md diff --git a/content/zh/docs/contribute/review/_index.md b/content/zh-cn/docs/contribute/review/_index.md similarity index 100% rename from content/zh/docs/contribute/review/_index.md rename to content/zh-cn/docs/contribute/review/_index.md diff --git a/content/zh/docs/contribute/review/for-approvers.md b/content/zh-cn/docs/contribute/review/for-approvers.md similarity index 100% rename from content/zh/docs/contribute/review/for-approvers.md rename to content/zh-cn/docs/contribute/review/for-approvers.md diff --git a/content/zh/docs/contribute/review/reviewing-prs.md b/content/zh-cn/docs/contribute/review/reviewing-prs.md similarity index 99% rename from content/zh/docs/contribute/review/reviewing-prs.md rename to content/zh-cn/docs/contribute/review/reviewing-prs.md index 7710a6dc14..d8eb48f1d6 100644 --- a/content/zh/docs/contribute/review/reviewing-prs.md +++ b/content/zh-cn/docs/contribute/review/reviewing-prs.md @@ -164,7 +164,7 @@ Figure 1. Review process steps. 1. Click on the `+` symbol beside the line you want to comment on. 2. Fill in any comments you have about the line and click either **Add single comment** (if you have only one comment to make) or **Start a review** (if you have multiple comments to make). 3. When finished, click **Review changes** at the top of the page. Here, you can add - add a summary of your review (and leave some positive comments for the contributor!), + a summary of your review (and leave some positive comments for the contributor!), approve the PR, comment or request changes as needed. New contributors should always choose **Comment**. --> diff --git a/content/zh/docs/contribute/style/_index.md b/content/zh-cn/docs/contribute/style/_index.md similarity index 100% rename from content/zh/docs/contribute/style/_index.md rename to content/zh-cn/docs/contribute/style/_index.md diff --git a/content/zh/docs/contribute/style/content-guide.md b/content/zh-cn/docs/contribute/style/content-guide.md similarity index 85% rename from content/zh/docs/contribute/style/content-guide.md rename to content/zh-cn/docs/contribute/style/content-guide.md index 1f787a1b93..91e9d0ee96 100644 --- a/content/zh/docs/contribute/style/content-guide.md +++ b/content/zh-cn/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/contribute/style/content-organization.md b/content/zh-cn/docs/contribute/style/content-organization.md similarity index 100% rename from content/zh/docs/contribute/style/content-organization.md rename to content/zh-cn/docs/contribute/style/content-organization.md diff --git a/content/zh/docs/contribute/style/diagram-guide.md b/content/zh-cn/docs/contribute/style/diagram-guide.md similarity index 100% rename from content/zh/docs/contribute/style/diagram-guide.md rename to content/zh-cn/docs/contribute/style/diagram-guide.md diff --git a/content/zh/docs/contribute/style/hugo-shortcodes/example1.md b/content/zh-cn/docs/contribute/style/hugo-shortcodes/example1.md similarity index 100% rename from content/zh/docs/contribute/style/hugo-shortcodes/example1.md rename to content/zh-cn/docs/contribute/style/hugo-shortcodes/example1.md diff --git a/content/zh/docs/contribute/style/hugo-shortcodes/example2.md b/content/zh-cn/docs/contribute/style/hugo-shortcodes/example2.md similarity index 100% rename from content/zh/docs/contribute/style/hugo-shortcodes/example2.md rename to content/zh-cn/docs/contribute/style/hugo-shortcodes/example2.md diff --git a/content/zh/docs/contribute/style/hugo-shortcodes/index.md b/content/zh-cn/docs/contribute/style/hugo-shortcodes/index.md similarity index 100% rename from content/zh/docs/contribute/style/hugo-shortcodes/index.md rename to content/zh-cn/docs/contribute/style/hugo-shortcodes/index.md diff --git a/content/zh/docs/contribute/style/hugo-shortcodes/podtemplate.json b/content/zh-cn/docs/contribute/style/hugo-shortcodes/podtemplate.json similarity index 100% rename from content/zh/docs/contribute/style/hugo-shortcodes/podtemplate.json rename to content/zh-cn/docs/contribute/style/hugo-shortcodes/podtemplate.json diff --git a/content/zh/docs/contribute/style/page-content-types.md b/content/zh-cn/docs/contribute/style/page-content-types.md similarity index 100% rename from content/zh/docs/contribute/style/page-content-types.md rename to content/zh-cn/docs/contribute/style/page-content-types.md diff --git a/content/zh/docs/contribute/style/style-guide.md b/content/zh-cn/docs/contribute/style/style-guide.md similarity index 100% rename from content/zh/docs/contribute/style/style-guide.md rename to content/zh-cn/docs/contribute/style/style-guide.md diff --git a/content/zh/docs/contribute/style/write-new-topic.md b/content/zh-cn/docs/contribute/style/write-new-topic.md similarity index 100% rename from content/zh/docs/contribute/style/write-new-topic.md rename to content/zh-cn/docs/contribute/style/write-new-topic.md diff --git a/content/zh/docs/contribute/suggesting-improvements.md b/content/zh-cn/docs/contribute/suggesting-improvements.md similarity index 100% rename from content/zh/docs/contribute/suggesting-improvements.md rename to content/zh-cn/docs/contribute/suggesting-improvements.md diff --git a/content/zh/docs/doc-contributor-tools/linkchecker/README.md b/content/zh-cn/docs/doc-contributor-tools/linkchecker/README.md similarity index 87% rename from content/zh/docs/doc-contributor-tools/linkchecker/README.md rename to content/zh-cn/docs/doc-contributor-tools/linkchecker/README.md index 86d1c81683..6f31aed3ab 100644 --- a/content/zh/docs/doc-contributor-tools/linkchecker/README.md +++ b/content/zh-cn/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/home/_index.md b/content/zh-cn/docs/home/_index.md similarity index 100% rename from content/zh/docs/home/_index.md rename to content/zh-cn/docs/home/_index.md diff --git a/content/zh-cn/docs/home/supported-doc-versions.md b/content/zh-cn/docs/home/supported-doc-versions.md new file mode 100644 index 0000000000..d455a039a3 --- /dev/null +++ b/content/zh-cn/docs/home/supported-doc-versions.md @@ -0,0 +1,34 @@ +--- +title: Kubernetes 文档支持的版本 +content_type: custom +layout: supported-versions +card: + name: about + weight: 10 + title: Kubernetes 文档支持的版本 +--- + + + + + +本网站包含当前版本和之前四个版本的 Kubernetes 文档。 + +Kubernetes 版本的文档可用性与当前是否支持该版本是分开的。 +阅读[支持期限](/zh/releases/patch-releases/#support-period)，了解官方支持 Kubernetes 的哪些版本，以及支持多长时间。 diff --git a/content/zh/docs/images/diagram-guide-example-3.svg b/content/zh-cn/docs/images/diagram-guide-example-3.svg similarity index 100% rename from content/zh/docs/images/diagram-guide-example-3.svg rename to content/zh-cn/docs/images/diagram-guide-example-3.svg diff --git a/content/zh/docs/images/ha-control-plane.svg b/content/zh-cn/docs/images/ha-control-plane.svg similarity index 100% rename from content/zh/docs/images/ha-control-plane.svg rename to content/zh-cn/docs/images/ha-control-plane.svg diff --git a/content/zh-cn/docs/images/ingress.svg b/content/zh-cn/docs/images/ingress.svg new file mode 100644 index 0000000000..450a0aae9b --- /dev/null +++ b/content/zh-cn/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/zh-cn/docs/images/ingressFanOut.svg b/content/zh-cn/docs/images/ingressFanOut.svg new file mode 100644 index 0000000000..a6bf202635 --- /dev/null +++ b/content/zh-cn/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/zh-cn/docs/images/ingressNameBased.svg b/content/zh-cn/docs/images/ingressNameBased.svg new file mode 100644 index 0000000000..7e1d7be98c --- /dev/null +++ b/content/zh-cn/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/zh-cn/docs/images/tutor-service-nodePort-fig01.svg b/content/zh-cn/docs/images/tutor-service-nodePort-fig01.svg new file mode 100644 index 0000000000..bb4d866f85 --- /dev/null +++ b/content/zh-cn/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/zh-cn/docs/images/tutor-service-nodePort-fig02.svg b/content/zh-cn/docs/images/tutor-service-nodePort-fig02.svg new file mode 100644 index 0000000000..1a891575e5 --- /dev/null +++ b/content/zh-cn/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/zh/docs/reference/_index.md b/content/zh-cn/docs/reference/_index.md similarity index 96% rename from content/zh/docs/reference/_index.md rename to content/zh-cn/docs/reference/_index.md index 1f3a9dcd93..af2a04118b 100644 --- a/content/zh/docs/reference/_index.md +++ b/content/zh-cn/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/) - [身份认证](/zh/docs/reference/access-authn-authz/authentication/) - [使用启动引导令牌来执行身份认证](/zh/docs/reference/access-authn-authz/bootstrap-tokens/) @@ -53,4 +55,5 @@ Reference documentation: - 服务账号 - [开发者指南](/zh/docs/tasks/configure-pod-container/configure-service-account/) - [管理文档](/zh/docs/reference/access-authn-authz/service-accounts-admin/) - +- [Kubelet 认证和鉴权](/zh/docs/reference/access-authn-authz/kubelet-authn-authz/) + - 包括 kubelet [TLS 启动引导](/zh/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) diff --git a/content/zh/docs/reference/access-authn-authz/abac.md b/content/zh-cn/docs/reference/access-authn-authz/abac.md similarity index 100% rename from content/zh/docs/reference/access-authn-authz/abac.md rename to content/zh-cn/docs/reference/access-authn-authz/abac.md diff --git a/content/zh/docs/reference/access-authn-authz/admission-controllers.md b/content/zh-cn/docs/reference/access-authn-authz/admission-controllers.md similarity index 58% rename from content/zh/docs/reference/access-authn-authz/admission-controllers.md rename to content/zh-cn/docs/reference/access-authn-authz/admission-controllers.md index b5f0976fcd..b1068539c5 100644 --- a/content/zh/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/zh-cn/docs/reference/access-authn-authz/admission-controllers.md @@ -21,14 +21,14 @@ weight: 30 -此页面概述了准入控制器。 +此页面提供准入控制器（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 +### CertificateSubjectRestriction {#certificatesubjectrestriction} -此准入控制器获取具有 `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/authentication.md b/content/zh-cn/docs/reference/access-authn-authz/authentication.md similarity index 100% rename from content/zh/docs/reference/access-authn-authz/authentication.md rename to content/zh-cn/docs/reference/access-authn-authz/authentication.md diff --git a/content/zh/docs/reference/access-authn-authz/authorization.md b/content/zh-cn/docs/reference/access-authn-authz/authorization.md similarity index 100% rename from content/zh/docs/reference/access-authn-authz/authorization.md rename to content/zh-cn/docs/reference/access-authn-authz/authorization.md diff --git a/content/zh/docs/reference/access-authn-authz/bootstrap-tokens.md b/content/zh-cn/docs/reference/access-authn-authz/bootstrap-tokens.md similarity index 94% rename from content/zh/docs/reference/access-authn-authz/bootstrap-tokens.md rename to content/zh-cn/docs/reference/access-authn-authz/bootstrap-tokens.md index 0960a96716..455d97c543 100644 --- a/content/zh/docs/reference/access-authn-authz/bootstrap-tokens.md +++ b/content/zh-cn/docs/reference/access-authn-authz/bootstrap-tokens.md @@ -21,14 +21,14 @@ creating new clusters or joining new nodes to an existing cluster. It was built to support [kubeadm](/docs/reference/setup-tools/kubeadm/), but can be used in other contexts for users that wish to start clusters without `kubeadm`. It is also built to work, via RBAC policy, with the -[Kubelet TLS Bootstrapping](/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) system. +[Kubelet TLS Bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) system. --> 启动引导令牌是一种简单的持有者令牌（Bearer Token），这种令牌是在新建集群 或者在现有集群中添加新节点时使用的。 它被设计成能够支持 [`kubeadm`](/zh/docs/reference/setup-tools/kubeadm/)， 但是也可以被用在其他的案例中以便用户在不使用 `kubeadm` 的情况下启动集群。 它也被设计成可以通过 RBAC 策略，结合 -[Kubelet TLS 启动引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/) +[Kubelet TLS 启动引导](/zh/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) 系统进行工作。 @@ -108,12 +108,16 @@ controller on the controller manager. 过期的令牌可以通过启用控制器管理器中的 `tokencleaner` 控制器来删除。 +``` +--controllers=*,tokencleaner +``` + @@ -121,7 +125,7 @@ Here is what the secret looks like. 每个合法的令牌背后对应着 `kube-system` 名字空间中的某个 Secret 对象。 你可以从 -[这里](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/cluster-lifecycle/bootstrap-discovery.md) +[这里](https://github.com/kubernetes/design-proposals-archive/blob/main/cluster-lifecycle/bootstrap-discovery.md) 找到完整设计文档。 这是 Secret 看起来的样子。 @@ -142,10 +146,11 @@ stringData: # 令牌 ID 和秘密信息，必需。 token-id: 07401b - token-secret: base64(f395accd246ae52d) + token-secret: f395accd246ae52d # 可选的过期时间字段 - expiration: "2017-03-10T03:22:11Z" + expiration: 2017-03-10T03:22:11Z + # 允许的用法 usage-bootstrap-authentication: "true" usage-bootstrap-signing: "true" @@ -259,7 +264,7 @@ data: ``` diff --git a/content/zh/docs/reference/access-authn-authz/certificate-signing-requests.md b/content/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests.md similarity index 100% rename from content/zh/docs/reference/access-authn-authz/certificate-signing-requests.md rename to content/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests.md diff --git a/content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md b/content/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers.md similarity index 100% rename from content/zh/docs/reference/access-authn-authz/extensible-admission-controllers.md rename to content/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers.md diff --git a/content/zh/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md b/content/zh-cn/docs/reference/access-authn-authz/kubelet-authn-authz.md similarity index 100% rename from content/zh/docs/reference/command-line-tools-reference/kubelet-authentication-authorization.md rename to content/zh-cn/docs/reference/access-authn-authz/kubelet-authn-authz.md diff --git a/content/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md b/content/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping.md similarity index 100% rename from content/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping.md rename to content/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping.md diff --git a/content/zh/docs/reference/access-authn-authz/node.md b/content/zh-cn/docs/reference/access-authn-authz/node.md similarity index 97% rename from content/zh/docs/reference/access-authn-authz/node.md rename to content/zh-cn/docs/reference/access-authn-authz/node.md index 72f8545fe6..2a9753860d 100644 --- a/content/zh/docs/reference/access-authn-authz/node.md +++ b/content/zh-cn/docs/reference/access-authn-authz/node.md @@ -90,12 +90,12 @@ have the minimal set of permissions required to operate correctly. --> 为了获得节点鉴权器的授权，kubelet 必须使用一个凭证以表示它在 `system:nodes` 组中，用户名为 `system:node:`。 -上述的组名和用户名格式要与 [kubelet TLS 启动引导](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/)过程中为每个 kubelet 创建的标识相匹配。 +上述的组名和用户名格式要与 [kubelet TLS 启动引导](/zh/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/)过程中为每个 kubelet 创建的标识相匹配。 要启用节点授权器，请使用 `--authorization-mode = Node` 启动 apiserver。 diff --git a/content/zh/docs/reference/access-authn-authz/psp-to-pod-security-standards.md b/content/zh-cn/docs/reference/access-authn-authz/psp-to-pod-security-standards.md similarity index 99% rename from content/zh/docs/reference/access-authn-authz/psp-to-pod-security-standards.md rename to content/zh-cn/docs/reference/access-authn-authz/psp-to-pod-security-standards.md index 97f6663629..40ae2452f8 100644 --- a/content/zh/docs/reference/access-authn-authz/psp-to-pod-security-standards.md +++ b/content/zh-cn/docs/reference/access-authn-authz/psp-to-pod-security-standards.md @@ -30,7 +30,7 @@ For each applicable parameter, the allowed values for the [Baseline](/docs/concepts/security/pod-security-standards/#baseline) and [Restricted](/docs/concepts/security/pod-security-standards/#restricted) profiles are listed. Anything outside the allowed values for those profiles would fall under the -[Privileged](/docs/concepts/security/pod-security-standards/#priveleged) profile. "No opinion" +[Privileged](/docs/concepts/security/pod-security-standards/#privileged) profile. "No opinion" means all values are allowed under all Pod Security Standards. --> 对于每个可应用的参数，表格中给出了 @@ -38,7 +38,7 @@ means all values are allowed under all Pod Security Standards. [Restricted](/zh/docs/concepts/security/pod-security-standards/#restricted) 配置下可接受的取值。 对这两种配置而言不可接受的取值均归入 -[Privileged](/zh/docs/concepts/security/pod-security-standards/#priveleged) +[Privileged](/zh/docs/concepts/security/pod-security-standards/#privileged) 配置下。“无意见”意味着对所有 Pod 安全性标准而言所有取值都可接受。 @@ -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 版本中引入的。
    - + - @@ -58,9 +56,9 @@ FormatOptions 包含为不同类型日志格式提供的选项。 - [FormatOptions](#FormatOptions) -JSONOptions 包含用于 "json" 日志格式的选项。 +JSONOptions 包含用于 "json" 日志格式的选项。
    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,52 +1521,50 @@ 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.     - + - + - + + + + + + + + +代理服务器的 IP 地址（所有 IPv4 接口设置为 “0.0.0.0”，所有 IPv6 接口设置为 “::”）。 +如果配置文件由 --config 指定，则忽略此参数。 +

     @@ -89,20 +100,17 @@ The IP address for the proxy server to serve on (set to '0.0.0.0' for all IPv4 i -若此标志为 true，kube-proxy 会将无法绑定端口的失败操作视为致命错误并退出。 +如果为 true，kube-proxy 会将无法绑定端口的失败操作视为致命错误并退出。

    - + @@ -119,30 +127,6 @@ If true cleanup iptables and ipvs rules and exit. - - - - - - - - - - - - - - @@ -242,32 +226,6 @@ Idle timeout for established TCP connections (0 to leave as-is) - - - - - - - - - - - - - - @@ -283,13 +241,13 @@ Mode to use to detect local traffic. This parameter is ignored if a config file - + - + + + + + + + + + + + + + + + + + + + + + + + + + + + + + @@ -823,6 +821,16 @@ A string slice of values which specify the addresses to use for NodePorts. Value + + + + + + + @@ -928,6 +936,36 @@ The previous version for which you want to show hidden metrics. Only the previou + + + + + + + + + + + + + + + + + + + + + @@ -942,6 +980,16 @@ How long an idle UDP connection will be kept open (e.g. '250ms', '2s'). Must be + + + + + + + @@ -955,6 +1003,16 @@ Print version information and quit + + + + + + + diff --git a/content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md b/content/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler.md similarity index 81% rename from content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md rename to content/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler.md index 0da24c1f84..28fb4f2a61 100644 --- a/content/zh/docs/reference/command-line-tools-reference/kube-scheduler.md +++ b/content/zh-cn/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] @@ -47,14 +46,14 @@ kube-scheduler [flags] +默认值：[] @@ -146,7 +145,7 @@ Kubernetes 核心服务器的 kubeconfig 文件。这是可选的。 -缓存来自 Webhook 授权者的 'authorized' 响应的持续时间。 +缓存来自 Webhook 授权者的 “authorized” 响应的持续时间。 @@ -158,7 +157,7 @@ The duration to cache 'authorized' responses from the webhook authorizer. -缓存来自 Webhook 授权者的 'unauthorized' 响应的持续时间。 +缓存来自 Webhook 授权者的 “unauthorized” 响应的持续时间。 @@ -184,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 或 ::)，所有接口将被使用。 @@ -228,7 +227,7 @@ The path to the configuration file. - + - - - - - - - @@ -534,7 +516,7 @@ DEPRECATED: content type of requests sent to apiserver. This parameter is ignore - + @@ -758,7 +740,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 @@ -781,7 +763,7 @@ unschedulablePods 移动到 backoffQ 或 activeQ。 - + +默认值："x-remote-extra-" +默认值："x-remote-group" +默认值："x-remote-user" @@ -998,7 +980,7 @@ Print version information and quit -以逗号分隔的 ‘模式=N’ 设置列表，用于文件过滤的日志记录（仅适用于文本日志格式）。 +以逗号分隔的 “pattern=N” 设置列表，用于文件过滤的日志记录（仅适用于文本日志格式）。 @@ -1010,7 +992,7 @@ comma-separated list of pattern=N settings for file-filtered logging (only works -如果已设置，将配置值写入此文件并退出。 +如果设置此参数，将配置值写入此文件并退出。 @@ -1019,5 +1001,3 @@ If set, write the configuration values to this file and exit. - - diff --git a/content/zh/docs/reference/command-line-tools-reference/kubelet.md b/content/zh-cn/docs/reference/command-line-tools-reference/kubelet.md similarity index 66% rename from content/zh/docs/reference/command-line-tools-reference/kubelet.md rename to content/zh-cn/docs/reference/command-line-tools-reference/kubelet.md index 7d127e479f..a82f0e1f53 100644 --- a/content/zh/docs/reference/command-line-tools-reference/kubelet.md +++ b/content/zh-cn/docs/reference/command-line-tools-reference/kubelet.md @@ -8,15 +8,19 @@ weight: 28 kubelet 是在每个 Node 节点上运行的主要 “节点代理”。它可以使用以下之一向 apiserver 注册： 主机名（hostname）；覆盖主机名的参数；某云驱动的特定逻辑。 kubelet 是基于 PodSpec 来工作的。每个 PodSpec 是一个描述 Pod 的 YAML 或 JSON 对象。 kubelet 接受通过各种机制（主要是通过 apiserver）提供的一组 PodSpec，并确保这些 @@ -24,27 +28,32 @@ PodSpec 中描述的容器处于运行状态且运行状况良好。 kubelet 不管理不是由 Kubernetes 创建的容器。 除了来自 apiserver 的 PodSpec 之外，还可以通过以下三种方式将容器清单（manifest）提供给 kubelet。 -文件（File）：利用命令行参数传递路径。kubelet 周期性地监视此路径下的文件是否有更新。 -监视周期默认为 20s，且可通过参数进行配置。 +- 文件（File）：利用命令行参数传递路径。kubelet 周期性地监视此路径下的文件是否有更新。 + 监视周期默认为 20s，且可通过参数进行配置。 -HTTP 端点（HTTP endpoint）：利用命令行参数指定 HTTP 端点。 -此端点的监视周期默认为 20 秒，也可以使用参数进行配置。 +- HTTP 端点（HTTP endpoint）：利用命令行参数指定 HTTP 端点。 + 此端点的监视周期默认为 20 秒，也可以使用参数进行配置。 -HTTP 服务器（HTTP server）：kubelet 还可以侦听 HTTP 并响应简单的 API -（目前没有完整规范）来提交新的清单。 +- HTTP 服务器（HTTP server）：kubelet 还可以侦听 HTTP 并响应简单的 API + （目前没有完整规范）来提交新的清单。 ``` kubelet [flags] @@ -65,9 +74,10 @@ kubelet [flags] @@ -77,11 +87,12 @@ If true, adds the file directory to the header @@ -91,11 +102,11 @@ kubelet 用来提供服务的 IP 地址（设置为0.0.0.0 表示 @@ -105,9 +116,10 @@ Comma-separated whitelist of unsafe sysctls or unsafe sysctl patterns (ending in @@ -117,12 +129,12 @@ log to standard error as well as files @@ -132,11 +144,11 @@ Enables anonymous requests to the Kubelet server. Requests that are not rejected @@ -146,11 +158,11 @@ Use the TokenReview API to determine authentication for bearer tokens. (DEPRECAT @@ -160,13 +172,13 @@ The duration to cache responses from the webhook token authenticator. (default 2 @@ -176,11 +188,11 @@ kubelet 服务器的鉴权模式。可选值包括：AlwaysAllow、 @@ -190,12 +202,12 @@ The duration to cache 'authorized' responses from the webhook authorizer. (DEPRE @@ -246,12 +258,12 @@ TLS 证书所在的目录。如果设置了 --tls-cert-file 和 @@ -261,12 +273,12 @@ kubelet 用来操作本机 cgroup 时使用的驱动程序。支持的选项包 @@ -276,24 +288,11 @@ Optional root cgroup to use for pods. This is handled by the container runtime o - - - - - - - @@ -303,12 +302,12 @@ If > 0.0, introduce random client errors and latency. Intended for testing. ( @@ -345,15 +344,15 @@ The provider for cloud services. Set to empty string for running with no cloud p @@ -363,13 +362,13 @@ DNS 服务器的 IP 地址，以逗号分隔。此标志值用于 Pod 中设置 @@ -379,11 +378,12 @@ Domain for this cluster. If set, kubelet will configure all containers to search @@ -393,10 +393,11 @@ kubelet 将在所指定路径中搜索 CNI 插件的可执行文件。 @@ -406,10 +407,11 @@ kubelet 将在所指定路径中搜索 CNI 插件的可执行文件。 @@ -433,12 +435,12 @@ kubelet 将从此标志所指的文件中加载其初始配置。此路径可以 @@ -448,12 +450,12 @@ Set the maximum number of container log files that can be present for a containe @@ -490,11 +492,11 @@ Windows 系统上的 npipe 和 TCP 端点。例如： @@ -504,11 +506,11 @@ Enable lock contention profiling, if profiling is enabled (DEPRECATED: This para @@ -518,11 +520,11 @@ Enable CPU CFS quota enforcement for containers that specify CPU limits (DEPRECA @@ -532,11 +534,11 @@ Sets CPU CFS quota period value, cpu.cfs_period_us, defaults to Lin @@ -546,12 +548,12 @@ CPU Manager policy to use. Possible values: 'none', 'static'. Default: 'none' (d @@ -561,10 +563,11 @@ CPU Manager policy to use. Possible values: 'none', 'static'. Default: 'none' (d @@ -594,9 +597,11 @@ kubelet 使用此目录来保存所下载的配置，跟踪配置运行状况。 @@ -606,11 +611,11 @@ Enables the Attach/Detach controller to manage attachment/detachment of volumes @@ -620,11 +625,11 @@ Enables server endpoints for log collection and local running of containers and @@ -634,16 +639,16 @@ Enable the Kubelet's server. (DEPRECATED: This parameter should be set via the c @@ -653,12 +658,12 @@ A comma separated list of levels of node allocatable enforcement to be enforced @@ -668,11 +673,11 @@ Maximum size of a bursty event records, temporarily allows event records to burs @@ -682,13 +687,13 @@ If > 0, limit event creations per second to this value. If @@ -698,12 +703,12 @@ A set of eviction thresholds (e.g. memory.available<1Gi) that if me @@ -713,12 +718,12 @@ Maximum allowed grace period (in seconds) to use when terminating pods in respon @@ -728,11 +733,11 @@ A set of minimum reclaims (e.g. imagefs.available=2Gi) that describ @@ -742,12 +747,12 @@ kubelet 在驱逐压力状况解除之前的最长等待时间。 @@ -757,12 +762,12 @@ A set of eviction thresholds (e.g. memory.available>1.5Gi) that if @@ -793,18 +798,6 @@ When set to true, Hard eviction thresholds will be ignored while ca - - - - - - - @@ -825,13 +818,13 @@ When set to true, Hard eviction thresholds will be ignored while ca @@ -841,13 +834,13 @@ If enabled, the kubelet will integrate with the kernel memcg notification to det @@ -869,11 +862,11 @@ If enabled, the kubelet will integrate with the kernel memcg notification to det @@ -970,7 +963,7 @@ 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.) --> 用于 alpha 实验性特性的特性开关组，每个开关以 key=value 形式表示。当前可用开关包括：
    APIListChunking=true|false (BETA - 默认值为 true)
    @@ -1072,11 +1065,11 @@ csiMigrationRBD=true|false (ALPHA - 默认值为 false)
     @@ -1086,13 +1079,13 @@ Duration between checking config files for new data. (DEPRECATED: This parameter @@ -1102,12 +1095,12 @@ How should the kubelet setup hairpin NAT. This allows endpoints of a Service to @@ -1117,11 +1110,11 @@ The IP address for the healthz server to serve on (set to 0.0.0.0 f @@ -1151,29 +1144,17 @@ If non-empty, will use this string as identification instead of the actual hostn - - - - - - - @@ -1206,12 +1187,12 @@ The path to the credential provider plugin config file. @@ -1221,12 +1202,12 @@ The percent of disk usage after which image garbage collection is always run. Va @@ -1236,10 +1217,11 @@ The percent of disk usage before which image garbage collection is never run. Lo @@ -1263,11 +1245,11 @@ If no pulling progress is made before this deadline, the image pulling will be c @@ -1277,12 +1259,12 @@ The bit of the fwmark space to mark packets for dropping. Must be w @@ -1305,12 +1287,12 @@ Keep terminated pod volumes mounted to the node after the pod terminates. Can be @@ -1320,11 +1302,11 @@ If enabled, the kubelet will integrate with the kernel memcg notification to det @@ -1334,11 +1316,11 @@ Burst to use while talking with kubernetes apiserver. (DEPRECATED: This paramete @@ -1348,13 +1330,13 @@ Content type of requests sent to apiserver. (default "application/vnd.kubernetes @@ -1364,14 +1346,14 @@ QPS to use while talking with kubernetes API server. The number must be >= 0. @@ -1381,12 +1363,12 @@ kubernetes 系统预留的资源配置，以一组 资源名称=资源数 @@ -1409,11 +1391,11 @@ kubeconfig 配置文件的路径，指定如何连接到 API 服务器。 @@ -1435,11 +1417,11 @@ Optional absolute name of cgroups to create and run the Kubelet in. (DEPRECATED: @@ -1449,10 +1431,10 @@ When logging hits line :, emit a stack trace. (DEPRECATED: @@ -1462,9 +1444,10 @@ If non-empty, write log files in this directory. (DEPRECATED: will be removed in @@ -1474,10 +1457,10 @@ If non-empty, use this log file @@ -1499,12 +1482,12 @@ Maximum number of seconds between log flushes @@ -1514,12 +1497,12 @@ Maximum number of seconds between log flushes @@ -1529,16 +1512,16 @@ Maximum number of seconds between log flushes @@ -1548,11 +1531,11 @@ Sets the log format. Permitted formats: text, json.
     @@ -1562,11 +1545,11 @@ log to standard error instead of files. (DEPRECATED: will be removed in a future @@ -1576,11 +1559,11 @@ If true, kubelet will ensure iptables utility rules are present on @@ -1590,15 +1573,16 @@ URL for accessing additional Pod specifications to run (DEPRECATED: This paramet + @@ -1618,11 +1602,11 @@ kubelet 向 Pod 注入 Kubernetes 主控服务信息时使用的命名空间。 @@ -1632,11 +1616,11 @@ kubelet 进程可以打开的最大文件数量。 @@ -1650,8 +1634,8 @@ Maximum number of old instances of containers to retain globally. Each container --> 设置全局可保留的已停止容器实例个数上限。 每个实例会占用一些磁盘空间。要禁用，请设置为负数。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +已弃用：改用 --eviction-hard 或 --eviction-soft。 +此标志将在未来的版本中删除。 @@ -1661,11 +1645,11 @@ Maximum number of old instances of containers to retain globally. Each container @@ -1675,11 +1659,11 @@ Maximum number of old instances to retain per container. Each container takes up @@ -1689,10 +1673,10 @@ Memory Manager policy to use. Possible values: 'None', 'Stati @@ -1704,12 +1688,12 @@ Minimum age for a finished container before it is garbage collected. Examples: @@ -1719,10 +1703,11 @@ Minimum age for an unused image before it is garbage collected. Examples: @@ -1782,11 +1767,11 @@ IP address (or comma-separated dual-stack IP addresses) of the node. If unset, k @@ -1796,12 +1781,12 @@ The maximum number of images to report in node.status.images. If @@ -1815,8 +1800,7 @@ Traffic to IPs outside this range will use IP masquerade. Set to '0.0.0.0/0' to --> kubelet 向该 IP 段之外的 IP 地址发送的流量将使用 IP 伪装技术。 设置为 0.0.0.0/0 则不使用伪装。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：将在未来的版本中删除。） @@ -1826,12 +1810,12 @@ kubelet 向该 IP 段之外的 IP 地址发送的流量将使用 IP 伪装技术 @@ -1841,11 +1825,11 @@ If true, only write logs to their native severity level (vs also writing to each @@ -1855,12 +1839,12 @@ kubelet 进程的 oom-score-adj 参数值。有效范围为 [-1000，1000] @@ -1885,12 +1869,12 @@ The CIDR to use for pod IP addresses, only used in standalone mode. In cluster m @@ -1900,11 +1884,11 @@ Path to the directory containing static pod files to run, or the path to a singl @@ -1914,13 +1898,13 @@ Set the maximum number of processes per pod. If -1, the kubelet de @@ -1930,11 +1914,11 @@ kubelet 在每个处理器核上可运行的 Pod 数量。此 kubelet 上的 Pod @@ -1944,12 +1928,12 @@ kubelet 服务监听的本机端口号。 @@ -1959,11 +1943,11 @@ kubelet 默认值不同时，kubelet 都会出错。 @@ -1973,13 +1957,13 @@ Unique identifier for identifying the node in a machine database, i.e cloud prov @@ -1989,11 +1973,11 @@ Unique identifier for identifying the node in a machine database, i.e cloud prov @@ -2016,12 +2000,12 @@ If true, when panics occur crash. Intended for testing. (DEPRECATED: will be rem @@ -2044,11 +2028,12 @@ Register the node as schedulable. Won't have any effect if --register-node @@ -2058,12 +2043,12 @@ Register the node with the given list of taints (comma separated = @@ -2073,11 +2058,11 @@ Maximum size of a bursty pulls, temporarily allows pulls to burst to this number @@ -2087,13 +2072,13 @@ If > 0, limit registry pull QPS to this value. If 0, unlimited. @@ -2103,13 +2088,13 @@ A comma-separated list of CPUs or CPU ranges that are reserved for system and ku @@ -2119,11 +2104,11 @@ A comma-separated list of memory reservations for NUMA nodes. (e.g. --rese @@ -2145,12 +2130,12 @@ Directory path for managing kubelet files (volume mounts, etc). @@ -2160,13 +2145,13 @@ Directory path for managing kubelet files (volume mounts, etc). @@ -2176,12 +2161,12 @@ Auto-request and rotate the kubelet serving certificates by requesting new certi @@ -2203,26 +2188,25 @@ Optional absolute name of cgroups to create and run the runtime in. - + @@ -2232,12 +2216,12 @@ Timeout of all runtime requests except long running request - pull, @@ -2247,10 +2231,10 @@ Pull images one at a time. We recommend *not* changing the default value on node @@ -2260,10 +2244,10 @@ If true, avoid header prefixes in the log messages. (DEPRECATED: will be removed @@ -2273,10 +2257,10 @@ If true, avoid headers when opening log files. (DEPRECATED: will be removed in a @@ -2286,13 +2270,13 @@ logs at or above this threshold go to stderr. (DEPRECATED: will be removed in a @@ -2302,11 +2286,11 @@ Maximum time a streaming connection can be idle before the connection is automat @@ -2316,12 +2300,12 @@ Max period between synchronizing running containers and config. (DEPRECATED: Thi @@ -2331,15 +2315,15 @@ Optional absolute name of cgroups in which to place all non-kernel processes tha @@ -2349,13 +2333,13 @@ A set of = (e.g. cpu=200m,m @@ -2365,15 +2349,15 @@ Absolute name of the top level cgroup that is used to manage non-kubernetes comp @@ -2388,15 +2372,15 @@ 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.) --> 服务器端加密算法列表，以逗号分隔。如果不设置，则使用 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_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_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_RC4_128_SHA。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。） @@ -2406,12 +2390,12 @@ TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_ECDSA_WITH_RC4_128_SHA, TLS_E     @@ -2421,11 +2405,11 @@ Minimum TLS version supported. Possible values: VersionTLS10, @@ -2435,12 +2419,12 @@ File containing x509 private key matching --tls-cert-file. (DEPRECA @@ -2450,13 +2434,13 @@ Topology Manager policy to use. Possible values: none, best-e @@ -2502,11 +2486,11 @@ Comma-separated list of pattern=N settings for file-filtered loggin @@ -2516,12 +2500,12 @@ The full path of the directory in which to search for additional third party vol diff --git a/content/zh/docs/reference/config-api/_index.md b/content/zh-cn/docs/reference/config-api/_index.md similarity index 100% rename from content/zh/docs/reference/config-api/_index.md rename to content/zh-cn/docs/reference/config-api/_index.md diff --git a/content/zh/docs/reference/config-api/apiserver-audit.v1.md b/content/zh-cn/docs/reference/config-api/apiserver-audit.v1.md similarity index 100% rename from content/zh/docs/reference/config-api/apiserver-audit.v1.md rename to content/zh-cn/docs/reference/config-api/apiserver-audit.v1.md diff --git a/content/zh/docs/reference/config-api/apiserver-config.v1.md b/content/zh-cn/docs/reference/config-api/apiserver-config.v1.md similarity index 100% rename from content/zh/docs/reference/config-api/apiserver-config.v1.md rename to content/zh-cn/docs/reference/config-api/apiserver-config.v1.md diff --git a/content/zh/docs/reference/config-api/apiserver-config.v1alpha1.md b/content/zh-cn/docs/reference/config-api/apiserver-config.v1alpha1.md similarity index 100% rename from content/zh/docs/reference/config-api/apiserver-config.v1alpha1.md rename to content/zh-cn/docs/reference/config-api/apiserver-config.v1alpha1.md diff --git a/content/zh/docs/reference/config-api/apiserver-encryption.v1.md b/content/zh-cn/docs/reference/config-api/apiserver-encryption.v1.md similarity index 100% rename from content/zh/docs/reference/config-api/apiserver-encryption.v1.md rename to content/zh-cn/docs/reference/config-api/apiserver-encryption.v1.md diff --git a/content/zh-cn/docs/reference/config-api/apiserver-eventratelimit.v1alpha1.md b/content/zh-cn/docs/reference/config-api/apiserver-eventratelimit.v1alpha1.md new file mode 100644 index 0000000000..32503d37fb --- /dev/null +++ b/content/zh-cn/docs/reference/config-api/apiserver-eventratelimit.v1alpha1.md @@ -0,0 +1,152 @@ +--- +title: Event Rate Limit Configuration (v1alpha1) +content_type: tool-reference +package: eventratelimit.admission.k8s.io/v1alpha1 +--- + + +## 资源类型 {#resource-types} + +- [Configuration](#eventratelimit-admission-k8s-io-v1alpha1-Configuration) + +## `Configuration` {#eventratelimit-admission-k8s-io-v1alpha1-Configuration} + + +

    Configuration 为 EventRateLimit 准入控制器提供配置数据。

    + +
    默认 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无 - 允许访问执行 -kubelet TLS 启动引导 +kubelet TLS 启动引导 所需要的资源。
    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/service-accounts-admin.md b/content/zh-cn/docs/reference/access-authn-authz/service-accounts-admin.md similarity index 100% rename from content/zh/docs/reference/access-authn-authz/service-accounts-admin.md rename to content/zh-cn/docs/reference/access-authn-authz/service-accounts-admin.md diff --git a/content/zh/docs/reference/access-authn-authz/webhook.md b/content/zh-cn/docs/reference/access-authn-authz/webhook.md similarity index 83% rename from content/zh/docs/reference/access-authn-authz/webhook.md rename to content/zh-cn/docs/reference/access-authn-authz/webhook.md index 0ef1e6a18d..29032a7353 100644 --- a/content/zh/docs/reference/access-authn-authz/webhook.md +++ b/content/zh-cn/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` 替代。 - `RotateKubeletClientCertificate`：在 kubelet 上启用客户端 TLS 证书的轮换。 更多详细信息，请参见 - [kubelet 配置](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)。 + [kubelet 配置](/zh/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#kubelet-configuration)。 - `RotateKubeletServerCertificate`：在 kubelet 上启用服务器 TLS 证书的轮换。 更多详细信息，请参见 - [kubelet 配置](/zh/docs/reference/command-line-tools-reference/kubelet-tls-bootstrapping/#kubelet-configuration)。 + [kubelet 配置](/zh/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/#kubelet-configuration)。 - `RunAsGroup`：启用对容器初始化过程中设置的主要组 ID 的控制。 - `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-cn/docs/reference/command-line-tools-reference/kube-apiserver.md similarity index 99% rename from content/zh/docs/reference/command-line-tools-reference/kube-apiserver.md rename to content/zh-cn/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-cn/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-cn/docs/reference/command-line-tools-reference/kube-controller-manager.md similarity index 100% rename from content/zh/docs/reference/command-line-tools-reference/kube-controller-manager.md rename to content/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager.md diff --git a/content/zh/docs/reference/command-line-tools-reference/kube-proxy.md b/content/zh-cn/docs/reference/command-line-tools-reference/kube-proxy.md similarity index 88% rename from content/zh/docs/reference/command-line-tools-reference/kube-proxy.md rename to content/zh-cn/docs/reference/command-line-tools-reference/kube-proxy.md index 2cb541d830..3484f8c4da 100644 --- a/content/zh/docs/reference/command-line-tools-reference/kube-proxy.md +++ b/content/zh-cn/docs/reference/command-line-tools-reference/kube-proxy.md @@ -54,31 +54,42 @@ kube-proxy [flags]
    --azure-container-registry-config string--add_dir_header

    -包含 Azure 容器仓库配置信息的文件的路径。 +如果为 true，将文件目录添加到日志消息的头部

    --bind-address 0.0.0.0     默认值：0.0.0.0--alsologtostderr

    + +设置为 true 表示将日志输出到文件的同时输出到 stderr +

    +
    --bind-address string     默认值：0.0.0.0

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

    -
    --boot-id-file string     默认值："/proc/sys/kernel/random/boot_id"--boot_id_file string     默认值："/proc/sys/kernel/random/boot_id"

    - -用来检查 Boot-ID 的文件名，用逗号隔开。 -第一个存在的文件会被使用。 + +逗号分隔的文件列表，用于检查 boot-id。使用第一个存在的文件。

    --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
    --default-not-ready-toleration-seconds int     默认值：300
    - -对污点 NotReady:NoExecute 的容忍时长（以秒计）。 -默认情况下这一容忍度会被添加到尚未具有此容忍度的每个 pod 中。 -
    --default-unreachable-toleration-seconds int     默认值：300
    - -对污点 Unreachable:NoExecute 的容忍时长（以秒计） -默认情况下这一容忍度会被添加到尚未具有此容忍度的每个 pod 中。 -
    --detect-local-mode LocalMode
    --feature-gates <逗号分隔的 'key=True|False' 对’>--feature-gates <逗号分隔的 'key=True|False' 对>

    -一组键=值（key=value）对，描述了 alpha/experimental 的特征。可选项有： +一组键=值（key=value）对，描述了 alpha/experimental 的特征。可选项有：
    APIListChunking=true|false (BETA - 默认值=true)
    APIPriorityAndFairness=true|false (BETA - 默认值=true)
    APIResponseCompression=true|false (BETA - 默认值=true)
    @@ -415,7 +372,6 @@ 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)
    @@ -739,18 +695,60 @@ Path to kubeconfig file with authorization information (the master location is s

    --machine-id-file string     默认值："/etc/machine-id,/var/lib/dbus/machine-id"--log_backtrace_at <“file:N” 格式的字符串>     默认值：0

    -用来检查 Machine-ID 的文件列表，用逗号分隔。 -使用找到的第一个文件。 +当日志命中 file:N，触发一次堆栈追踪

    --log_dir string

    + +如果非空，则在此目录中写入日志文件 +

    --log_file string

    + +如果非空，使用此日志文件 +

    --log_file_max_size uint     默认值：1800

    + +定义日志文件可以增长到的最大大小。单位是兆字节。 +如果值为 0，则最大文件大小不受限制。 +

    --logtostderr     默认值：true
    +

    + +日志输出到 stderr 而不是文件。 +

    +
    --machine_id_file string     默认值："/etc/machine-id,/var/lib/dbus/machine-id"
    --one_output

    + +如果为 true，则仅将日志写入本地的严重性级别（而不是写入每个较低的严重性级别） +

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

    + +如果为 true，则避免在日志消息中使用头部前缀 +

    --skip_log_headers

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

    --stderrthreshold int     默认值：2

    + +设置严重程度达到或超过此阈值的日志输出到标准错误输出。 +

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

    + +设置日志级别详细程度的数值。 +

    --version version[=true]
    --vmodule <逗号分割的 “pattern=N” 设置>

    + +以逗号分割的 pattern=N 设置的列表，用于文件过滤日志 +

    --write-config-to string
    --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'。 @@ -120,7 +119,7 @@ If true, failures to look up missing authentication configuration from the clust -在授权过程中跳过的 HTTP 路径列表，即在不联系 'core' kubernetes 服务器的情况下被授权的 HTTP 路径。 +在授权过程中跳过的 HTTP 路径列表，即在不联系 “core” kubernetes 服务器的情况下被授权的 HTTP 路径。
    --contention-profiling     默认值: true--contention-profiling     默认值：true
    @@ -363,123 +362,106 @@ WinOverlay=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)
    -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)
    -ExperimentalHostUserNamespace默认值ing=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)
    -Seccomp默认值=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) -
    --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
    @@ -745,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
    --profiling     默认值： true--profiling     默认值：true
    @@ -824,7 +806,7 @@ Root certificate bundle to use to verify client certificates on incoming request
    --requestheader-extra-headers-prefix strings      -默认值: "x-remote-extra-"
    @@ -837,7 +819,7 @@ List of request header prefixes to inspect. X-Remote-Extra- is suggested.
    --requestheader-group-headers strings      -默认值: "x-remote-group"
    @@ -850,7 +832,7 @@ List of request headers to inspect for groups. X-Remote-Group is suggested.
    --requestheader-username-headers strings      -默认值: "x-remote-user"
    @@ -897,7 +879,7 @@ The previous version for which you want to show hidden metrics. Only the previou -包含默认的 HTTPS x509 证书的文件。（CA证书（如果有）在服务器证书之后并置）。 +包含默认的 HTTPS x509 证书的文件。（如果有 CA 证书，在服务器证书之后并置）。 如果启用了 HTTPS 服务，并且未提供 --tls-cert-file 和 --tls-private-key-file，则会为公共地址生成一个自签名证书和密钥， 并将其保存到 --cert-dir 指定的目录中。 @@ -962,7 +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"。 +例如: "example.crt,example.key" 或者 "foo.crt,foo.key:*.foo.com,foo.com"。
    设置为 true 表示将文件目录添加到日志消息的头部 +（已弃用：将在未来的版本中删除，进一步了解。）
    kubelet 用来提供服务的 IP 地址（设置为0.0.0.0 表示使用所有 IPv4 接口， -设置为 :: 表示使用所有 IPv6 接口）。已弃用：应在 --config 所给的 -配置文件中进行设置。（进一步了解） +设置为 :: 表示使用所有 IPv6 接口）。 +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    -用逗号分隔的字符串序列设置允许使用的非安全的 sysctls 或 sysctl 模式（以 * 结尾) 。 -使用此参数时风险自担。已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +用逗号分隔的字符串序列设置允许使用的非安全的 sysctls 或 sysctl 模式（以 * 结尾）。 +使用此参数时风险自担。（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    设置为 true 表示将日志输出到文件的同时输出到 stderr +（已弃用：将在未来的版本中删除，进一步了解。）
    设置为 true 表示 kubelet 服务器可以接受匿名请求。未被任何认证组件拒绝的请求将被视为匿名请求。 匿名请求的用户名为 system:anonymous，用户组为 system:unauthenticated。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    使用 TokenReview API 对持有者令牌进行身份认证。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    对 Webhook 令牌认证组件所返回的响应的缓存时间。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    kubelet 服务器的鉴权模式。可选值包括：AlwaysAllow、Webhook。Webhook 模式使用 SubjectAccessReview API 鉴权。 当 --config 参数未被设置时，默认值为 AlwaysAllow，当使用了 --config 时，默认值为 Webhook。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    对 Webhook 认证组件所返回的 “Authorized（已授权）” 应答的缓存时间。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    对 Webhook 认证组件所返回的 “Unauthorized（未授权）” 应答的缓存时间。 --config 时，默认值为 Webhook。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    kubelet 用来操作本机 cgroup 时使用的驱动程序。支持的选项包括 cgroupfs 和 systemd。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    可选的选项，为 Pod 设置根 cgroup。容器运行时会尽可能使用此配置。 默认值 "" 意味着将使用容器运行时的默认设置。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    启用创建 QoS cgroup 层次结构。此值为 true 时 kubelet 为 QoS 和 Pod 创建顶级的 cgroup。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） -
    --chaos-chance float
    - -如果此值大于 0.0，则引入随机客户端错误和延迟。用于测试。 -已启用：将在未来版本中移除。 +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    如果设置了此参数，则使用对应文件中机构之一检查请求中所携带的客户端证书。 若客户端证书通过身份认证，则其对应身份为其证书中所设置的 CommonName。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    DNS 服务器的 IP 地址，以逗号分隔。此标志值用于 Pod 中设置了 “dnsPolicy=ClusterFirst” 时为容器提供 DNS 服务。注意：列表中出现的所有 DNS 服务器必须包含相同的记录组， 否则集群中的名称解析可能无法正常工作。至于名称解析过程中会牵涉到哪些 DNS 服务器， 这一点无法保证。 --config 时，默认值为 Webhook。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    集群的域名。如果设置了此值，kubelet 除了将主机的搜索域配置到所有容器之外，还会为其 配置所搜这里指定的域名。 --config 时，默认值为 Webhook。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    -<警告：alpha 特性> 此值为以逗号分隔的完整路径列表。 +此值为以逗号分隔的完整路径列表。 kubelet 将在所指定路径中搜索 CNI 插件的可执行文件。 仅当容器运行环境设置为 docker 时，此特定于 docker 的参数才有效。 +（已弃用：将会随着 dockershim 一起删除。）
    -<警告：alpha 特性> 此值为一个目录的全路径名。CNI 将在其中缓存文件。 +此值为一个目录的全路径名。CNI 将在其中缓存文件。 仅当容器运行环境设置为 docker 时，此特定于 docker 的参数才有效。 +（已弃用：将会随着 dockershim 一起删除。）
    <警告：alpha 特性> 此值为某目录的全路径名。kubelet 将在其中搜索 CNI 配置文件。 仅当容器运行环境设置为 docker 时，此特定于 docker 的参数才有效。 +（已弃用：将会随着 dockershim 一起删除。）
    设置容器的日志文件个数上限。此值必须不小于 2。 此标志只能与 --container-runtime=remote 标志一起使用。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    设置容器日志文件在轮换生成新文件时之前的最大值（例如，10Mi）。 此标志只能与 --container-runtime=remote 标志一起使用。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    当启用了性能分析时，启用锁竞争分析。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    为设置了 CPU 限制的容器启用 CPU CFS 配额保障。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    -设置 CPU CFS 配额周期 cpu.cfs_period_us。默认使用 Linux 内核所设置的默认值 。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +设置 CPU CFS 配额周期 cpu.cfs_period_us。默认使用 Linux 内核所设置的默认值。 +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    要使用的 CPU 管理器策略。可选值包括：none 和 static。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    <警告：alpha 特性> 设置 CPU 管理器的调和时间。例如：10s 或者 1m。 如果未设置，默认使用节点状态更新频率。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    使用这里的端点与 docker 端点通信。 仅当容器运行环境设置为 docker 时，此特定于 docker 的参数才有效。 +（已弃用：将会随着 dockershim 一起删除。）
    启用 Attach/Detach 控制器来挂接和摘除调度到该节点的卷，同时禁用 kubelet 执行挂接和摘除操作。 +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    启用服务器上用于日志收集和在本地运行容器和命令的端点。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    启用 kubelet 服务器。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    用逗号分隔的列表，包含由 kubelet 强制执行的节点可分配资源级别。 可选配置为：none、pods、system-reserved 和 kube-reserved。 在设置 system-reserved 和 kube-reserved 这两个值时，同时要求设置 --system-reserved-cgroup 和 --kube-reserved-cgroup 这两个参数。 如果设置为 none，则不需要设置其他参数。 -参考相关文档。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +参考相关文档。 +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    事件记录的个数的突发峰值上限，在遵从 --event-qps 阈值约束的前提下 临时允许事件记录达到此数目。仅在 --event-qps 大于 0 时使用。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    设置大于 0 的值表示限制每秒可生成的事件数量。设置为 0 表示不限制。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    触发 Pod 驱逐操作的一组硬性门限（例如：memory.available<1Gi -（内存可用值小于 1 G））设置。在 Linux 节点上，默认值还包括 +（内存可用值小于 1G）设置。在 Linux 节点上，默认值还包括 nodefs.inodesFree<5%。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    响应满足软性驱逐阈值（Soft Eviction Threshold）而终止 Pod 时使用的最长宽限期（以秒为单位）。 如果设置为负数，则遵循 Pod 的指定值。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    当某资源压力过大时，kubelet 将执行 Pod 驱逐操作。 此参数设置软性驱逐操作需要回收的资源的最小数量（例如：imagefs.available=2Gi）。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    kubelet 在驱逐压力状况解除之前的最长等待时间。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    设置一组驱逐阈值（例如：memory.available<1.5Gi）。 如果在相应的宽限期内达到该阈值，则会触发 Pod 驱逐操作。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    设置一组驱逐宽限期（例如，memory.available=1m30s），对应于触发软性 Pod 驱逐操作之前软性驱逐阈值所需持续的时间长短。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    --experimental-bootstrap-kubeconfig string
    - -已弃用：应使用 --bootstrap-kubeconfig 标志 -
    --experimental-check-node-capabilities-before-mount
    设置为 true 表示 kubelet 将会集成内核的 memcg 通知机制而不是使用轮询机制来 判断是否达到了内存驱逐阈值。 此标志将在 1.24 或更高版本移除。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    [试验性功能] 启用此标志之后，kubelet 会避免将标记为敏感的字段（密码、密钥、令牌等） 写入日志中。运行时的日志清理可能会带来相当的计算开销，因此不应该在 产品环境中启用。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    设置为 true 表示如果主机启用了交换分区，kubelet 将直接失败。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    检查配置文件中新数据的时间间隔。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    设置 kubelet 执行发夹模式（hairpin）网络地址转译的方式。 该模式允许后端端点对其自身服务的访问能够再次经由负载均衡转发回自身。 可选项包括 promiscuous-bridge、hairpin-veth 和 none。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    用于运行 healthz 服务器的 IP 地址（设置为 0.0.0.0 表示使用所有 IPv4 接口， 设置为 :: 表示使用所有 IPv6 接口。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    本地 healthz 端点使用的端口（设置为 0 表示禁用）。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    --housekeeping-interval duration     默认值：10s
    - -清理容器操作的时间间隔。 -
    --http-check-frequency duration     默认值：20s
    HTTP 服务以获取新数据的时间间隔。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    镜像垃圾回收上限。磁盘使用空间达到该百分比时，镜像垃圾回收将持续工作。 值必须在 [0，100] 范围内。要禁用镜像垃圾回收，请设置为 100。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    镜像垃圾回收下限。磁盘使用空间在达到该百分比之前，镜像垃圾回收操作不会运行。 值必须在 [0，100] 范围内，并且不得大于 --image-gc-high-threshold的值。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    如果在该参数值所设置的期限之前没有拉取镜像的进展，镜像拉取操作将被取消。 仅当容器运行环境设置为 docker 时，此特定于 docker 的参数才有效。 +（已弃用：将会随着 dockershim 一起删除。）
    标记数据包将被丢弃的 fwmark 位设置。必须在 [0，31] 范围内。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    标记数据包将进行 SNAT 的 fwmark 空间位设置。必须在 [0，31] 范围内。 请将此参数与 kube-proxy 中的相应参数匹配。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    若启用，则 kubelet 将与内核中的 memcg 通知机制集成，不再使用轮询的方式来判定 是否 Pod 达到内存驱逐阈值。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    每秒发送到 apiserver 的突发请求数量上限。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    发送到 apiserver 的请求的内容类型。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    与 apiserver 通信的每秒查询个数（QPS）。 -此值必须 >= 0。如果为 0， 则使用默认 QPS（5）。 +此值必须 >= 0。如果为 0，则使用默认 QPS（5）。 不包含事件和节点心跳 api，它们的速率限制是由一组不同的标志所控制。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    -kubernetes 系统预留的资源配置，以一组 资源名称=资源数量 格式表示。 +kubernetes 系统预留的资源配置，以一组 <资源名称>=<资源数量> 格式表示。 （例如：cpu=200m,memory=500Mi,ephemeral-storage=1Gi,pid='100'）。 当前支持 cpu、memory 和用于根文件系统的 ephemeral-storage。 -请参阅相关文档获取更多信息。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +请参阅这里获取更多信息。 +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    给出某个顶层 cgroup 绝对名称，该 cgroup 用于管理通过标志 --kube-reserved 为 kubernetes 组件所预留的计算资源。例如："/kube-reserved"。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    用于创建和运行 kubelet 的 cgroup 的绝对名称。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    形式为 <file>:<N>。 当日志逻辑执行到命中 <file> 的第 <N> 行时，转储调用堆栈。 -（已弃用：将在未来的版本中删除，进一步了解） +（已弃用：将在未来的版本中删除，进一步了解。）
    如果此值为非空，则在所指定的目录中写入日志文件。 -（已弃用：将在未来的版本中删除，进一步了解） +（已弃用：将在未来的版本中删除，进一步了解。）
    如果此值非空，使用所给字符串作为日志文件名。 +（已弃用：将在未来的版本中删除，进一步了解。）
    设置日志文件的最大值。单位为兆字节（M）。如果值为 0，则表示文件大小无限制。 -（已弃用：将在未来的版本中删除，进一步了解） +（已弃用：将在未来的版本中删除，进一步了解。）
    [实验性特性]在具有拆分输出流的 JSON 格式中，可以将信息消息缓冲一段时间以提高性能。 零字节的默认值禁用缓冲。大小可以指定为字节数（512）、1000 的倍数（1K）、1024 的倍数（2Ki） 或这些（3M、4G、5Mi、6Gi）的幂。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    -[实验性特性]以 JSON 格式，将错误消息写入 stderr，将 info 消息写入 stdout。 +[实验性特性]以 JSON 格式，将错误消息写入 stderr，将 info 消息写入 stdout。 默认是将单个流写入标准输出。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    设置日志文件格式。可以设置的格式有："text"、"json"。 -非默认的格式不会使用以下标志的配置：--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。 +非默认的格式不会使用以下标志的配置：--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。 非默认选项的其它值都应视为 Alpha 特性，将来出现更改时不会额外警告。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    日志输出到 stderr 而不是文件。 （已弃用：将会在未来的版本删除， -进一步了解） +进一步了解。）
    设置为 true 表示 kubelet 将确保 iptables 规则在主机上存在。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    用于访问要运行的其他 Pod 规范的 URL。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    取值为由 HTTP 头部组成的逗号分隔列表，在访问 --manifest-url 所给出的 URL 时使用。 名称相同的多个头部将按所列的顺序添加。该参数可以多次使用。例如： --manifest-url-header 'a:hello,b:again,c:world' --manifest-url-header 'b:beautiful'。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    --master-service-namespace string     默认值：default
    kubelet 进程可以打开的最大文件数量。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    此 kubelet 能运行的 Pod 最大数量。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    每个已停止容器可以保留的的最大实例数量。每个容器占用一些磁盘空间。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +已弃用：改用 --eviction-hard 或 --eviction-soft。 +此标志将在未来的版本中删除。
    -内存管理器策略使用。可选值：'None', 'Static'。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +内存管理器策略使用。可选值：'None'、'Static'。 +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    已结束的容器在被垃圾回收清理之前的最少存活时间。 -例如：300ms、10s 或者 2h45m。 +例如：'300ms'、'10s' 或者 '2h45m'。 已弃用：请改用 --eviction-hard 或者 --eviction-soft。 此标志将在未来的版本中删除。
    -不再使用的镜像在被垃圾回收清理之前的最少存活时间。 -例如：300ms、10s 或者 2h45m。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +已结束的容器在被垃圾回收清理之前的最少存活时间。 +例如：'300ms'、'10s' 或者 '2h45m'。 +已弃用：这个参数应该通过 Kubelet 的 --config 标志指定的配置文件来设置。 +（进一步了解）
    -<警告：alpha 特性> 设置 kubelet/Pod 生命周期中各种事件调用的网络插件的名称。 +设置 kubelet/Pod 生命周期中各种事件调用的网络插件的名称。 仅当容器运行环境设置为 docker 时，此特定于 docker 的参数才有效。 +（已弃用：将会随着 dockershim 一起删除。）
    在 node.status.images 中可以报告的最大镜像数量。如果指定为 -1，则不设上限。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    指定 kubelet 向主控节点汇报节点状态的时间间隔。注意：更改此常量时请务必谨慎， 它必须与节点控制器中的 nodeMonitorGracePeriod 一起使用。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    如果设置此标志为 true，则仅将日志写入其原来的严重性级别中， 而不是同时将其写入更低严重性级别中。 -已弃用：将在未来的版本中删除， -（进一步了解） +已弃用：将在未来的版本中删除。 +（进一步了解。）
    kubelet 进程的 oom-score-adj 参数值。有效范围为 [-1000，1000]。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    用于给 Pod 分配 IP 地址的 CIDR 地址池，仅在独立运行模式下使用。 在集群模式下，CIDR 设置是从主服务器获取的。对于 IPv6，分配的 IP 的最大数量为 65536。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    设置包含要运行的静态 Pod 的文件的路径，或单个静态 Pod 文件的路径。以点（.） 开头的文件将被忽略。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    设置每个 Pod 中的最大进程数目。如果为 -1，则 kubelet 使用节点可分配的 PID 容量作为默认值。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    kubelet 在每个处理器核上可运行的 Pod 数量。此 kubelet 上的 Pod 总数不能超过 --max-pods 标志值。因此，如果此计算结果导致在 kubelet 上允许更多数量的 Pod，则使用 --max-pods 值。值为 0 表示不作限制。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    kubelet 服务监听的本机端口号。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    设置 kubelet 的默认内核调整行为。如果已设置该参数，当任何内核可调参数与 kubelet 默认值不同时，kubelet 都会出错。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    设置主机数据库（即，云驱动）中用来标识节点的唯一标识。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    <警告：alpha 特性> 设置在指定的 QoS 级别预留的 Pod 资源请求，以一组 "资源名称=百分比" 的形式进行设置，例如 memory=50%。 当前仅支持内存（memory）。要求启用 QOSReserved 特性门控。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    kubelet 可以在没有身份验证/鉴权的情况下提供只读服务的端口（设置为 0 表示禁用）。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    向 API 服务器注册节点，如果未提供 --kubeconfig，此标志无关紧要， 因为 Kubelet 没有 API 服务器可注册。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    设置本节点的污点标记，格式为 <key>=<value>:<effect>， 以逗号分隔。当 --register-node 为 false 时此标志无效。 -已弃用：将在未来版本中移除。 +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    设置突发性镜像拉取的个数上限，在不超过 --registration-qps 设置值的前提下 暂时允许此参数所给的镜像拉取个数。仅在 --registry-qps 大于 0 时使用。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    如此值大于 0，可用来限制镜像仓库的 QPS 上限。设置为 0，表示不受限制。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    用逗号分隔的一组 CPU 或 CPU 范围列表，给出为系统和 Kubernetes 保留使用的 CPU。 此列表所给出的设置优先于通过 --system-reserved 和 --kube-reskube-reserved 所保留的 CPU 个数配置。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    -以逗号分隔的 NUMA 节点内存预留列表。（例如 --reserved-memory 0:memory=1Gi,hugepages-1M=2Gi --reserved-memory 1:memory=2Gi）。 +以逗号分隔的 NUMA 节点内存预留列表。（例如 --reserved-memory 0:memory=1Gi,hugepages-1M=2Gi --reserved-memory 1:memory=2Gi）。 每种内存类型的总和应该等于--kube-reserved、--system-reserved和--eviction-threshold。 了解更多详细信息。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    名字解析服务的配置文件名，用作容器 DNS 解析配置的基础。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    <警告：Beta 特性> 设置当客户端证书即将过期时 kubelet 自动从 kube-apiserver 请求新的证书进行轮换。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    当 kubelet 的服务证书即将过期时自动从 kube-apiserver 请求新的证书进行轮换。 要求启用 RotateKubeletServerCertificate 特性门控，以及对提交的 CertificateSigningRequest 对象进行批复（Approve）操作。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    -设置为 true 表示从本地清单或远程 URL 创建完 Pod 后立即退出 kubelet 进程。 +设置为 true 表示从本地清单或远程 URL 创建完 Pod 后立即退出 kubelet 进程。 与 --enable-server 标志互斥。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    设置除了长时间运行的请求（包括 pull、logs、exec 和 attach 等操作）之外的其他运行时请求的超时时间。 到达超时时间时，请求会被取消，抛出一个错误并会等待重试。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    --seccomp-profile-root string     默认值：/var/lib/kubelet/seccomp--seccomp-default RuntimeDefault
    - -<警告：alpha 特性> seccomp 配置文件目录。 -已弃用：将在 1.23 或更高版本中移除，以使用 <root-dir>/seccomp 目录。 +<警告：alpha 特性> 启用 RuntimeDefault 作为所有工作负载的默认 seccomp 配置文件。SeccompDefault 特性门控必须启用以允许此标志，默认情况下禁用。
    逐一拉取镜像。建议 *不要* 在 docker 守护进程版本低于 1.9 或启用了 Aufs 存储后端的节点上 更改默认值。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    -设置为 true 时在日志消息中去掉标头前缀。 -（已弃用：将在未来的版本中删除，进一步了解） +设置为 true 时在日志消息中去掉标头前缀。 +（已弃用：将在未来的版本中删除，进一步了解。）
    -设置为 true，打开日志文件时去掉标头。 -（已弃用：将在未来的版本中删除，进一步了解） +设置为 true，打开日志文件时去掉标头。 +（已弃用：将在未来的版本中删除，进一步了解。）
    设置严重程度达到或超过此阈值的日志输出到标准错误输出。 -（已弃用：将在未来的版本中删除，进一步了解） +（已弃用：将在未来的版本中删除，进一步了解。）
    设置流连接在自动关闭之前可以空闲的最长时间。0 表示没有超时限制。 例如：5m。 注意：与 kubelet 服务器的所有连接最长持续时间为 4 小时。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    在运行中的容器与其配置之间执行同步操作的最长时间间隔。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    此标志值为一个 cgroup 的绝对名称，用于所有尚未放置在根目录下某 cgroup 内的非内核进程。 空值表示不指定 cgroup。回滚该参数需要重启机器。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    系统预留的资源配置，以一组 资源名称=资源数量 的格式表示， （例如：cpu=200m,memory=500Mi,ephemeral-storage=1Gi,pid='100'）。 目前仅支持 cpu 和 memory 的设置。 更多细节可参考 -相关文档。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +相关文档。 +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    此标志给出一个顶层 cgroup 绝对名称，该 cgroup 用于管理非 kubernetes 组件， 这些组件的计算资源通过 --system-reserved 标志进行预留。 例如 "/system-reserved"。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    包含 x509 证书的文件路径，用于 HTTPS 认证。 如果有中间证书，则中间证书要串接在在服务器证书之后。 如果未提供 --tls-cert-file 和 --tls-private-key-file， kubelet 会为公开地址生成自签名证书和密钥，并将其保存到通过 --cert-dir 指定的目录中。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    设置支持的最小 TLS 版本号，可选的版本号包括：VersionTLS10、 VersionTLS11、VersionTLS12 和 VersionTLS13。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    包含与 --tls-cert-file 对应的 x509 私钥文件路径。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    设置拓扑管理策略（Topology Manager policy）。可选值包括：none、 best-effort、restricted 和 single-numa-node。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    拓扑提示信息使用范围。拓扑管理器从提示提供者（Hints Providers）处收集提示信息， 并将其应用到所定义的范围以确保 Pod 准入。 可选值包括：container（默认）、pod。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    用来搜索第三方存储卷插件的目录。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    指定 kubelet 计算和缓存所有 Pod 和卷的磁盘用量总值的时间间隔。要禁用磁盘用量计算， 请设置为 0。 -已弃用：应在 --config 所给的配置文件中进行设置。 -（进一步了解） +（已弃用：应在 --config 所给的配置文件中进行设置。 +请参阅 kubelet-config-file 了解更多信息。）
    + + + + + + + + + + +
    字段描述
    apiVersion
    string    		eventratelimit.admission.k8s.io/v1alpha1
    kind
    string    		Configuration
    limits [Required]
    +[]Limit +    		 + +

    limits 是为所接收到的事件查询设置的限制。可以针对服务器端接收到的事件设置限制， +按逐个名字空间、逐个用户、或逐个来源+对象组合的方式均可以。 +至少需要设置一种限制。

    +
    + +## `Limit` {#eventratelimit-admission-k8s-io-v1alpha1-Limit} + + +**出现在：** + +- [Configuration](#eventratelimit-admission-k8s-io-v1alpha1-Configuration) + + +

    Limit 是为特定限制类型提供的配置数据。

    + + + + + + + + + + + + + + + + + + +
    字段描述
    type [必需]
    +LimitType +    		 + +

    type 是此配置所适用的限制的类型。

    +
    qps [必需]
    +int32 +    		 + +

    qps 是针对此类型的限制每秒钟所允许的事件查询次数。qps 和 burst +字段一起用来确定是否特定的事件查询会被接受。qps 确定的是当超出查询数量的 +burst 值时可以接受的查询个数。

    +
    burst [必需]
    +int32 +    		 + +

    burst 是针对此类型限制的突发事件查询数量。qps 和 burst 字段一起使用可用来确定特定的事件查询是否被接受。 +burst 字段确定针对特定的事件桶（bucket）可以接受的规模上限。 +例如，如果 burst 是 10，qps 是 3，那么准入控制器会在接收 10 个查询之后阻塞所有查询。 +每秒钟可以额外允许 3 个查询。如果这一限额未被用尽，则剩余的限额会被顺延到下一秒钟， +直到再次达到 10 个限额的上限。

    +
    cacheSize
    +int32 +    		 + +

    cacheSize 是此类型限制的 LRU 缓存的规模。如果某个事件桶（bucket）被从缓存中剔除， +该事件桶所对应的限额也会被重置。如果后来再次收到针对某个已被剔除的事件桶的查询， +则该事件桶会重新以干净的状态进入缓存，因而获得全量的突发查询配额。

    +

    默认的缓存大小是 4096。

    +

    如果 limitType 是 “server”，则 cacheSize 设置会被忽略。

    +
    + +## `LimitType` {#eventratelimit-admission-k8s-io-v1alpha1-LimitType} + + +（`string` 类型的别名） + +**出现在：** + +- [Limit](#eventratelimit-admission-k8s-io-v1alpha1-Limit) + + +

    LimitType 是限制类型（例如：per-namespace）。

    + + diff --git a/content/zh/docs/reference/config-api/apiserver-webhookadmission.v1.md b/content/zh-cn/docs/reference/config-api/apiserver-webhookadmission.v1.md similarity index 100% rename from content/zh/docs/reference/config-api/apiserver-webhookadmission.v1.md rename to content/zh-cn/docs/reference/config-api/apiserver-webhookadmission.v1.md diff --git a/content/zh/docs/reference/config-api/client-authentication.v1.md b/content/zh-cn/docs/reference/config-api/client-authentication.v1.md similarity index 100% rename from content/zh/docs/reference/config-api/client-authentication.v1.md rename to content/zh-cn/docs/reference/config-api/client-authentication.v1.md diff --git a/content/zh/docs/reference/config-api/client-authentication.v1beta1.md b/content/zh-cn/docs/reference/config-api/client-authentication.v1beta1.md similarity index 100% rename from content/zh/docs/reference/config-api/client-authentication.v1beta1.md rename to content/zh-cn/docs/reference/config-api/client-authentication.v1beta1.md diff --git a/content/zh/docs/reference/config-api/kube-proxy-config.v1alpha1.md b/content/zh-cn/docs/reference/config-api/kube-proxy-config.v1alpha1.md similarity index 100% rename from content/zh/docs/reference/config-api/kube-proxy-config.v1alpha1.md rename to content/zh-cn/docs/reference/config-api/kube-proxy-config.v1alpha1.md diff --git a/content/zh/docs/reference/config-api/kube-scheduler-config.v1beta2.md b/content/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta2.md similarity index 100% rename from content/zh/docs/reference/config-api/kube-scheduler-config.v1beta2.md rename to content/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta2.md diff --git a/content/zh/docs/reference/config-api/kube-scheduler-config.v1beta3.md b/content/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3.md similarity index 100% rename from content/zh/docs/reference/config-api/kube-scheduler-config.v1beta3.md rename to content/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3.md diff --git a/content/zh/docs/reference/config-api/kubeadm-config.v1beta2.md b/content/zh-cn/docs/reference/config-api/kubeadm-config.v1beta2.md similarity index 98% rename from content/zh/docs/reference/config-api/kubeadm-config.v1beta2.md rename to content/zh-cn/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-cn/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.

    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-cn/docs/reference/config-api/kubeadm-config.v1beta3.md similarity index 99% rename from content/zh/docs/reference/config-api/kubeadm-config.v1beta3.md rename to content/zh-cn/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-cn/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-cn/docs/reference/config-api/kubelet-config.v1alpha1.md similarity index 87% rename from content/zh/docs/reference/config-api/kubelet-config.v1alpha1.md rename to content/zh-cn/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-cn/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

    @@ -57,77 +93,47 @@ Default: 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"

    @@ -136,17 +142,10 @@ Default: "20s"

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

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

    -

    默认值：""

    +

    默认值：""

    @@ -156,16 +155,10 @@ Default: ""

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

    -

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

    默认值：nil

    @@ -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;

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

    -

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

    默认值：""

    @@ -280,15 +248,10 @@ Default: ""

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

    -

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

    默认值：nil

    @@ -299,15 +262,10 @@ Default: nil

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

    -

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

    默认值：""

    @@ -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 来请求证书。

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

    -

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

    默认值：

    
   anonymous:
     enabled: false
   webhook:
     enabled: true
-    cacheTTL: "2m"
+    cacheTTL: "2m"
    @@ -395,24 +333,19 @@ Defaults:

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

    -

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

    默认值：

    
   mode: Webhook
   webhook:
-    cacheAuthorizedTTL: "5m"
-    cacheUnauthorizedTTL: "30s"
+    cacheAuthorizedTTL: "5m"
+    cacheUnauthorizedTTL: "30s"
    @@ -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

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

    -

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

    默认值：5

    @@ -485,21 +400,16 @@ Default: 5 int32 -

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

    -

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

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

    默认值：10

    @@ -511,16 +421,11 @@ Default: 10

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

    -

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

    默认值：true

    @@ -529,16 +434,12 @@ Default: true bool -

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

    -

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

    默认值：false @@ -547,17 +448,13 @@ Default: false int32 -

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

    -

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

    默认值：10248

    @@ -566,15 +463,11 @@ Default: 10248 string -

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

    -

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

    默认值："127.0.0.1"

    @@ -585,15 +478,10 @@ Default: "127.0.0.1"

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

    -

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

    默认值：-999

    @@ -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

    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"

    @@ -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

    volumeStatsAggPeriod
    -meta/v1.Duration +meta/v1.Duration

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

    -

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

    默认值："1m"

    @@ -835,13 +665,9 @@ Default: "1m"

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

    -

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

    默认值：""

    @@ -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;

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

    -

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

    -

    默认值：""

    @@ -892,15 +708,11 @@ Default: ""

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

    -

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

    默认值：true

    @@ -911,14 +723,10 @@ Default: true

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

    -

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

    默认值："cgroupfs"

    @@ -929,14 +737,10 @@ Default: "cgroupfs"

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

    -

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

    默认值："None"

    @@ -947,36 +751,26 @@ Default: "None"

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

    -

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

    默认值：nil

    cpuManagerReconcilePeriod
    -meta/v1.Duration +meta/v1.Duration

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

    -

    DynamicKubeletConfig （已弃用）： -

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

    默认值："10s"

    @@ -987,14 +781,10 @@ Default: "10s"

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

    -

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

    默认值："none"

    @@ -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

    runtimeRequestTimeout
    -meta/v1.Duration +meta/v1.Duration

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

    -

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

    默认值："2m"

    @@ -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"

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

    -

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

    默认值：110

    @@ -1166,15 +927,10 @@ Default: 110

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

    -

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

    默认值：""

    @@ -1184,14 +940,9 @@ Default: ""

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

    -

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

    默认值：-1

    @@ -1202,17 +953,11 @@ Default: -1

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

    -

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

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

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

    @@ -1238,37 +983,25 @@ Default: false

    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"

    @@ -1280,16 +1013,11 @@ Default: "100ms"

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

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

    -

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

    默认值：50

    @@ -1300,14 +1028,9 @@ Default: 50

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

    -

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

    默认值：1000000

    @@ -1317,18 +1040,9 @@ Default: 1000000

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

    -

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

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

    @@ -1338,15 +1052,9 @@ Default: "application/vnd.kubernetes.protobuf"

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

    -

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

    默认值：5

    @@ -1357,16 +1065,10 @@ Default: 5

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

    -

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

    默认值：10

    @@ -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:

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

    -

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

    默认值：nil

    @@ -1451,34 +1136,24 @@ Default: nil

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

    -

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

    默认值：nil

    evictionPressureTransitionPeriod
    -meta/v1.Duration +meta/v1.Duration

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

    -

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

    默认值："5m"

    @@ -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

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

    -

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

    默认值：15

    @@ -1686,22 +1303,12 @@ Default: 15

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

    -

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

    默认值：nil

    @@ -1711,14 +1318,9 @@ Default: nil

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

    -

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

    默认值：true

    @@ -1739,15 +1341,10 @@ Default: true

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

    -

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

    默认值："10Mi"

    @@ -1758,14 +1355,9 @@ Default: "10Mi"

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

    -

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

    默认值："5"

    @@ -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: ""

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

    -

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

    默认值：""

    @@ -1916,18 +1486,14 @@ Default: ""

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

    -

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

    默认值：""

    @@ -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: []

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

    -

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

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

    @@ -2014,15 +1563,10 @@ Default: "/usr/libexec/kubernetes/kubelet-plugins/volume/exec/"

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

    -

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

    默认值：""

    @@ -2034,15 +1578,10 @@ Default: "quot;

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

    -

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

    默认值：false

    @@ -2078,7 +1617,7 @@ Default: true 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-cn/docs/reference/config-api/kubelet-credentialprovider.v1alpha1.md b/content/zh-cn/docs/reference/config-api/kubelet-credentialprovider.v1alpha1.md new file mode 100644 index 0000000000..cf3287b09a --- /dev/null +++ b/content/zh-cn/docs/reference/config-api/kubelet-credentialprovider.v1alpha1.md @@ -0,0 +1,253 @@ +--- +title: Kubelet CredentialProvider (v1alpha1) +content_type: tool-reference +package: credentialprovider.kubelet.k8s.io/v1alpha1 +--- + + + +## 资源类型 {#resource-types} + +- [CredentialProviderRequest](#credentialprovider-kubelet-k8s-io-v1alpha1-CredentialProviderRequest) +- [CredentialProviderResponse](#credentialprovider-kubelet-k8s-io-v1alpha1-CredentialProviderResponse) + +## `CredentialProviderRequest` {#credentialprovider-kubelet-k8s-io-v1alpha1-CredentialProviderRequest} + + +

    +CredentialProviderRequest 包含 kubelet 需要进行身份验证的镜像。 +Kubelet 会通过标准输入将此请求对象传递给插件。一般来说，插件倾向于用它们所收到的相同的 apiVersion 来响应。 +

    + + + + + + + + + + + + + +
    字段描述
    apiVersion
    string    		credentialprovider.kubelet.k8s.io/v1alpha1
    kind
    string    		CredentialProviderRequest
    image [必需]
    +string +    		 + +

    + image 是容器镜像，作为凭据提供程序插件请求的一部分。 + 插件可以有选择地解析镜像以提取获取凭据所需的任何信息。 +

    +
    + +## `CredentialProviderResponse` {#credentialprovider-kubelet-k8s-io-v1alpha1-CredentialProviderResponse} + + +

    +CredentialProviderResponse 持有 kubelet 应用于原始请求中提供的指定镜像的凭据。 +kubelet 将通过标准输出读取插件的响应。此响应的 apiVersion 值应设置为与 CredentialProviderRequest 中 apiVersion 值相同。 +

    + + + + + + + + + + + + + + + + + + + + +
    字段描述
    apiVersion
    string    		credentialprovider.kubelet.k8s.io/v1alpha1
    kind
    string    		CredentialProviderResponse
    cacheKeyType [必需]
    +PluginCacheKeyType +    		 + +

    + cacheKeyType 表明基于请求中所给镜像而要使用的缓存键类型。缓存键类型有三个有效值： + Image、Registry 和 Global。如果指定了无效值，则 kubelet 不会使用该响应。 +

    +
    cacheDuration
    +meta/v1.Duration +    		 + +

    + cacheDuration 表示所提供的凭据应该被缓存的时间。kubelet 使用这个字段为 + auth 中的凭据设置内存中数据的缓存时间。如果为空，kubelet 将使用 CredentialProviderConfig + 中提供的 defaultCacheDuration。如果设置为 0，kubelet 将不会缓存所提供的 auth 数据。 +

    +
    auth
    +map[string]k8s.io/kubelet/pkg/apis/credentialprovider/v1alpha1.AuthConfig +    		 + +

    + auth 是一个映射，其中包含传递到 kubelet 的身份验证信息。 + 每个键都是一个匹配镜像字符串（下面将对此进行详细介绍）。相应的 authConfig 值应该对所有与此键匹配的镜像有效。 + 如果不能为请求的镜像返回有效的凭据，插件应将此字段设置为 null。 +

    + +

    + 映射中每个键值都是一个正则表达式，可以选择包含端口和路径。 + 域名部分可以包含通配符，但在端口或路径中不能使用通配符。 + 支持通配符作为子域，如 *.k8s.io 或 k8s.*.io，以及顶级域，如 k8s.*。 + 还支持匹配部分子域，如 app*.k8s.io。每个通配符只能匹配一个子域段， + 因此 *.io 不匹配 *.k8s.io。 +

    + +

    + 当满足以下所有条件时，kubelet 会将镜像与键值匹配： +

    +
      +
    • 两者都包含相同数量的域部分，并且每个部分都匹配。
      • +
    • imageMatch 的 URL 路径必须是目标镜像的 URL 路径的前缀。
      • +
    • 如果 imageMatch 包含端口，则该端口也必须在镜像中匹配。
      • +
    + +

    + 当返回多个键（key）时，kubelet 会倒序遍历所有键，这样： +

    +
      +
    • 具有相同前缀的较长键位于较短键之前
      • +
    • 具有相同前缀的非通配符键位于通配符键之前。
      • +
    + +

    + 对于任何给定的匹配，kubelet 将尝试使用提供的凭据进行镜像拉取，并在第一次成功验证后停止拉取。 +

    +

    键值示例：

    +
      +
    • 123456789.dkr.ecr.us-east-1.amazonaws.com
      • +
    • *.azurecr.io
      • +
    • gcr.io
      • +
    • ..registry.io
      • +
    • registry.io:8080/path
      • +
    +
    + +## `AuthConfig` {#credentialprovider-kubelet-k8s-io-v1alpha1-AuthConfig} + + +**出现在：** + +- [CredentialProviderResponse](#credentialprovider-kubelet-k8s-io-v1alpha1-CredentialProviderResponse) + + +AuthConfig 包含容器仓库的身份验证信息。目前仅支持基于用户名/密码的身份验证，但未来可能会添加更多身份验证机制。 + + + + + + + + + + + + + +
    字段描述
    username [必需]
    +string +    		 + +

    + username 是用于向容器仓库进行身份验证的用户名。空的用户名是合法的。 +

    +
    password [必需]
    +string +    		 + +

    + password 是用于向容器仓库进行身份验证的密码。空密码是合法的。 +

    +
    + +## `PluginCacheKeyType` {#credentialprovider-kubelet-k8s-io-v1alpha1-PluginCacheKeyType} + + +（string 数据类型的别名） + +**出现在：** + +- [CredentialProviderResponse](#credentialprovider-kubelet-k8s-io-v1alpha1-CredentialProviderResponse) \ No newline at end of file diff --git a/content/zh-cn/docs/reference/config-api/kubelet-credentialprovider.v1beta1.md b/content/zh-cn/docs/reference/config-api/kubelet-credentialprovider.v1beta1.md new file mode 100644 index 0000000000..3bf2430a76 --- /dev/null +++ b/content/zh-cn/docs/reference/config-api/kubelet-credentialprovider.v1beta1.md @@ -0,0 +1,253 @@ +--- +title: Kubelet CredentialProvider (v1beta1) +content_type: tool-reference +package: credentialprovider.kubelet.k8s.io/v1beta1 +--- + + + +## 资源类型 {#resource-types} + +- [CredentialProviderRequest](#credentialprovider-kubelet-k8s-io-v1beta1-CredentialProviderRequest) +- [CredentialProviderResponse](#credentialprovider-kubelet-k8s-io-v1beta1-CredentialProviderResponse) + +## `CredentialProviderRequest` {#credentialprovider-kubelet-k8s-io-v1beta1-CredentialProviderRequest} + + +

    +CredentialProviderRequest 包含 kubelet 需要进行身份验证的镜像。 +Kubelet 会通过标准输入将此请求对象传递给插件。一般来说，插件倾向于用它们所收到的相同的 apiVersion 来响应。 +

    + + + + + + + + + + + + + +
    字段描述
    apiVersion
    string    		credentialprovider.kubelet.k8s.io/v1beta1
    kind
    string    		CredentialProviderRequest
    image [必需]
    +string +    		 + +

    + image 是容器镜像，作为凭据提供程序插件请求的一部分。 + 插件可以有选择地解析镜像以提取获取凭据所需的任何信息。 +

    +
    + +## `CredentialProviderResponse` {#credentialprovider-kubelet-k8s-io-v1beta1-CredentialProviderResponse} + + +

    +CredentialProviderResponse 持有 kubelet 应用于原始请求中提供的指定镜像的凭据。 +kubelet 将通过标准输出读取插件的响应。此响应的 apiVersion 值应设置为与 CredentialProviderRequest 中 apiVersion 值相同。 +

    + + + + + + + + + + + + + + + + + + + + +
    字段描述
    apiVersion
    string    		credentialprovider.kubelet.k8s.io/v1beta1
    kind
    string    		CredentialProviderResponse
    cacheKeyType [必需]
    +PluginCacheKeyType +    		 + +

    + cacheKeyType 表明基于请求中所给镜像而要使用的缓存键类型。缓存键类型有三个有效值： + Image、Registry 和 Global。如果指定了无效值，则 kubelet 不会使用该响应。 +

    +
    cacheDuration
    +meta/v1.Duration +    		 + +

    + cacheDuration 表示所提供的凭据应该被缓存的时间。kubelet 使用这个字段为 + auth 中的凭据设置内存中数据的缓存时间。如果为空，kubelet 将使用 CredentialProviderConfig + 中提供的 defaultCacheDuration。如果设置为 0，kubelet 将不会缓存所提供的 auth 数据。 +

    +
    auth
    +map[string]k8s.io/kubelet/pkg/apis/credentialprovider/v1beta1.AuthConfig +    		 + +

    + auth 是一个映射，其中包含传递到 kubelet 的身份验证信息。 + 每个键都是一个匹配镜像字符串（下面将对此进行详细介绍）。相应的 authConfig 值应该对所有与此键匹配的镜像有效。 + 如果不能为请求的镜像返回有效的凭据，插件应将此字段设置为 null。 +

    + +

    + 映射中每个键值都是一个正则表达式，可以选择包含端口和路径。 + 域名部分可以包含通配符，但在端口或路径中不能使用通配符。 + 支持通配符作为子域，如 *.k8s.io 或 k8s.*.io，以及顶级域，如 k8s.*。 + 还支持匹配部分子域，如 app*.k8s.io。每个通配符只能匹配一个子域段， + 因此 *.io 不匹配 *.k8s.io。 +

    + +

    + 当满足以下所有条件时，kubelet 会将镜像与键值匹配： +

    +
      +
    • 两者都包含相同数量的域部分，并且每个部分都匹配。
      • +
    • imageMatch 的 URL 路径必须是目标镜像的 URL 路径的前缀。
      • +
    • 如果 imageMatch 包含端口，则该端口也必须在镜像中匹配。
      • +
    + +

    + 当返回多个键（key）时，kubelet 会倒序遍历所有键，这样： +

    +
      +
    • 具有相同前缀的较长键位于较短键之前
      • +
    • 具有相同前缀的非通配符键位于通配符键之前。
      • +
    + +

    + 对于任何给定的匹配，kubelet 将尝试使用提供的凭据进行镜像拉取，并在第一次成功验证后停止拉取。 +

    +

    键值示例：

    +
      +
    • 123456789.dkr.ecr.us-east-1.amazonaws.com
      • +
    • *.azurecr.io
      • +
    • gcr.io
      • +
    • ..registry.io
      • +
    • registry.io:8080/path
      • +
    +
    + +## `AuthConfig` {#credentialprovider-kubelet-k8s-io-v1beta1-AuthConfig} + + +**出现在：** + +- [CredentialProviderResponse](#credentialprovider-kubelet-k8s-io-v1beta1-CredentialProviderResponse) + + +AuthConfig 包含容器仓库的身份验证信息。目前仅支持基于用户名/密码的身份验证，但未来可能会添加更多身份验证机制。 + + + + + + + + + + + + + +
    字段描述
    username [必需]
    +string +    		 + +

    + username 是用于向容器仓库进行身份验证的用户名。空的用户名是合法的。 +

    +
    password [必需]
    +string +    		 + +

    + password 是用于向容器仓库进行身份验证的密码。空密码是合法的。 +

    +
    + +## `PluginCacheKeyType` {#credentialprovider-kubelet-k8s-io-v1beta1-PluginCacheKeyType} + + +（string 数据类型的别名） + +**出现在：** + +- [CredentialProviderResponse](#credentialprovider-kubelet-k8s-io-v1beta1-CredentialProviderResponse) \ No newline at end of file diff --git a/content/zh/docs/reference/glossary/addons.md b/content/zh-cn/docs/reference/glossary/addons.md similarity index 100% rename from content/zh/docs/reference/glossary/addons.md rename to content/zh-cn/docs/reference/glossary/addons.md diff --git a/content/zh/docs/reference/glossary/admission-controller.md b/content/zh-cn/docs/reference/glossary/admission-controller.md similarity index 100% rename from content/zh/docs/reference/glossary/admission-controller.md rename to content/zh-cn/docs/reference/glossary/admission-controller.md diff --git a/content/zh/docs/reference/glossary/affinity.md b/content/zh-cn/docs/reference/glossary/affinity.md similarity index 100% rename from content/zh/docs/reference/glossary/affinity.md rename to content/zh-cn/docs/reference/glossary/affinity.md diff --git a/content/zh/docs/reference/glossary/aggregation-layer.md b/content/zh-cn/docs/reference/glossary/aggregation-layer.md similarity index 100% rename from content/zh/docs/reference/glossary/aggregation-layer.md rename to content/zh-cn/docs/reference/glossary/aggregation-layer.md diff --git a/content/zh/docs/reference/glossary/annotation.md b/content/zh-cn/docs/reference/glossary/annotation.md similarity index 100% rename from content/zh/docs/reference/glossary/annotation.md rename to content/zh-cn/docs/reference/glossary/annotation.md diff --git a/content/zh/docs/reference/glossary/api-eviction.md b/content/zh-cn/docs/reference/glossary/api-eviction.md similarity index 100% rename from content/zh/docs/reference/glossary/api-eviction.md rename to content/zh-cn/docs/reference/glossary/api-eviction.md diff --git a/content/zh/docs/reference/glossary/api-group.md b/content/zh-cn/docs/reference/glossary/api-group.md similarity index 100% rename from content/zh/docs/reference/glossary/api-group.md rename to content/zh-cn/docs/reference/glossary/api-group.md diff --git a/content/zh/docs/reference/glossary/app-container.md b/content/zh-cn/docs/reference/glossary/app-container.md similarity index 100% rename from content/zh/docs/reference/glossary/app-container.md rename to content/zh-cn/docs/reference/glossary/app-container.md diff --git a/content/zh/docs/reference/glossary/application-architect.md b/content/zh-cn/docs/reference/glossary/application-architect.md similarity index 100% rename from content/zh/docs/reference/glossary/application-architect.md rename to content/zh-cn/docs/reference/glossary/application-architect.md diff --git a/content/zh/docs/reference/glossary/application-developer.md b/content/zh-cn/docs/reference/glossary/application-developer.md similarity index 100% rename from content/zh/docs/reference/glossary/application-developer.md rename to content/zh-cn/docs/reference/glossary/application-developer.md diff --git a/content/zh/docs/reference/glossary/applications.md b/content/zh-cn/docs/reference/glossary/applications.md similarity index 100% rename from content/zh/docs/reference/glossary/applications.md rename to content/zh-cn/docs/reference/glossary/applications.md diff --git a/content/zh/docs/reference/glossary/approver.md b/content/zh-cn/docs/reference/glossary/approver.md similarity index 100% rename from content/zh/docs/reference/glossary/approver.md rename to content/zh-cn/docs/reference/glossary/approver.md diff --git a/content/zh/docs/reference/glossary/cadvisor.md b/content/zh-cn/docs/reference/glossary/cadvisor.md similarity index 100% rename from content/zh/docs/reference/glossary/cadvisor.md rename to content/zh-cn/docs/reference/glossary/cadvisor.md diff --git a/content/zh/docs/reference/glossary/certificate.md b/content/zh-cn/docs/reference/glossary/certificate.md similarity index 100% rename from content/zh/docs/reference/glossary/certificate.md rename to content/zh-cn/docs/reference/glossary/certificate.md diff --git a/content/zh/docs/reference/glossary/cgroup.md b/content/zh-cn/docs/reference/glossary/cgroup.md similarity index 100% rename from content/zh/docs/reference/glossary/cgroup.md rename to content/zh-cn/docs/reference/glossary/cgroup.md diff --git a/content/zh/docs/reference/glossary/cidr.md b/content/zh-cn/docs/reference/glossary/cidr.md similarity index 100% rename from content/zh/docs/reference/glossary/cidr.md rename to content/zh-cn/docs/reference/glossary/cidr.md diff --git a/content/zh/docs/reference/glossary/cla.md b/content/zh-cn/docs/reference/glossary/cla.md similarity index 100% rename from content/zh/docs/reference/glossary/cla.md rename to content/zh-cn/docs/reference/glossary/cla.md diff --git a/content/zh/docs/reference/glossary/cloud-controller-manager.md b/content/zh-cn/docs/reference/glossary/cloud-controller-manager.md similarity index 87% rename from content/zh/docs/reference/glossary/cloud-controller-manager.md rename to content/zh-cn/docs/reference/glossary/cloud-controller-manager.md index 3d33b8c7fe..7fc039db36 100644 --- a/content/zh/docs/reference/glossary/cloud-controller-manager.md +++ b/content/zh-cn/docs/reference/glossary/cloud-controller-manager.md @@ -33,18 +33,17 @@ that embeds cloud-specific control logic. The cloud controller manager lets you cluster into your cloud provider's API, and separates out the components that interact with that cloud platform from components that only interact with your cluster. --> -云控制器管理器是指嵌入特定云的控制逻辑的 +`cloud-controller-manager` 是指嵌入特定云的控制逻辑之 {{< glossary_tooltip text="控制平面" term_id="control-plane" >}}组件。 -云控制器管理器使得你可以将你的集群连接到云提供商的 API 之上， +`cloud-controller-manager` 允许你将你的集群连接到云提供商的 API 之上， 并将与该云平台交互的组件同与你的集群交互的组件分离开来。 - 通过分离 Kubernetes 和底层云基础设置之间的互操作性逻辑， -云控制器管理器组件使云提供商能够以不同于 Kubernetes 主项目的 +`cloud-controller-manager` 组件使云提供商能够以不同于 Kubernetes 主项目的 步调发布新特征。 diff --git a/content/zh/docs/reference/glossary/cloud-provider.md b/content/zh-cn/docs/reference/glossary/cloud-provider.md similarity index 100% rename from content/zh/docs/reference/glossary/cloud-provider.md rename to content/zh-cn/docs/reference/glossary/cloud-provider.md diff --git a/content/zh/docs/reference/glossary/cluster-architect.md b/content/zh-cn/docs/reference/glossary/cluster-architect.md similarity index 100% rename from content/zh/docs/reference/glossary/cluster-architect.md rename to content/zh-cn/docs/reference/glossary/cluster-architect.md diff --git a/content/zh/docs/reference/glossary/cluster-infrastructure.md b/content/zh-cn/docs/reference/glossary/cluster-infrastructure.md similarity index 100% rename from content/zh/docs/reference/glossary/cluster-infrastructure.md rename to content/zh-cn/docs/reference/glossary/cluster-infrastructure.md diff --git a/content/zh/docs/reference/glossary/cluster-operations.md b/content/zh-cn/docs/reference/glossary/cluster-operations.md similarity index 100% rename from content/zh/docs/reference/glossary/cluster-operations.md rename to content/zh-cn/docs/reference/glossary/cluster-operations.md diff --git a/content/zh/docs/reference/glossary/cluster-operator.md b/content/zh-cn/docs/reference/glossary/cluster-operator.md similarity index 100% rename from content/zh/docs/reference/glossary/cluster-operator.md rename to content/zh-cn/docs/reference/glossary/cluster-operator.md diff --git a/content/zh/docs/reference/glossary/cluster.md b/content/zh-cn/docs/reference/glossary/cluster.md similarity index 69% rename from content/zh/docs/reference/glossary/cluster.md rename to content/zh-cn/docs/reference/glossary/cluster.md index 74d48ff2c2..07b79c5f96 100644 --- a/content/zh/docs/reference/glossary/cluster.md +++ b/content/zh-cn/docs/reference/glossary/cluster.md @@ -4,7 +4,7 @@ id: cluster date: 2019-06-15 full_link: short_description: > - 集群由一组被称作节点的机器组成。这些节点上运行 Kubernetes 所管理的容器化应用。集群具有至少一个工作节点。 + 集群由一组被称作节点的机器组成。这些节点上运行 Kubernetes 所管理的容器化应用。集群具有至少一个工作节点。 aka: tags: @@ -32,8 +32,9 @@ tags: A set of worker machines, called {{< glossary_tooltip text="nodes" term_id="node" >}}, that run containerized applications. Every cluster has at least one worker node. --> -集群由一组被称作节点的机器组成。这些节点上运行 Kubernetes 所管理的容器化应用。集群具有至少一个工作节点。 - +集群是由一组被称作{{< glossary_tooltip text="节点（node）" term_id="node" >}}的机器组成， +这些节点上会运行由 Kubernetes 所管理的容器化应用。 +且每个集群至少有一个工作节点。 -工作节点托管作为应用负载的组件的 Pod 。控制平面管理集群中的工作节点和 Pod 。 -为集群提供故障转移和高可用性，这些控制平面一般跨多主机运行，集群跨多个节点运行。 +工作节点会托管所谓的 Pods，而 Pod 就是作为应用负载的组件。 +控制平面管理集群中的工作节点和 Pods。 +为集群提供故障转移和高可用性， +这些控制平面一般跨多主机运行，而集群也会跨多个节点运行。 diff --git a/content/zh/docs/reference/glossary/cncf.md b/content/zh-cn/docs/reference/glossary/cncf.md similarity index 100% rename from content/zh/docs/reference/glossary/cncf.md rename to content/zh-cn/docs/reference/glossary/cncf.md diff --git a/content/zh/docs/reference/glossary/cni.md b/content/zh-cn/docs/reference/glossary/cni.md similarity index 100% rename from content/zh/docs/reference/glossary/cni.md rename to content/zh-cn/docs/reference/glossary/cni.md diff --git a/content/zh/docs/reference/glossary/code-contributor.md b/content/zh-cn/docs/reference/glossary/code-contributor.md similarity index 100% rename from content/zh/docs/reference/glossary/code-contributor.md rename to content/zh-cn/docs/reference/glossary/code-contributor.md diff --git a/content/zh/docs/reference/glossary/configmap.md b/content/zh-cn/docs/reference/glossary/configmap.md similarity index 100% rename from content/zh/docs/reference/glossary/configmap.md rename to content/zh-cn/docs/reference/glossary/configmap.md diff --git a/content/zh/docs/reference/glossary/container-env-variables.md b/content/zh-cn/docs/reference/glossary/container-env-variables.md similarity index 100% rename from content/zh/docs/reference/glossary/container-env-variables.md rename to content/zh-cn/docs/reference/glossary/container-env-variables.md diff --git a/content/zh/docs/reference/glossary/container-lifecycle-hooks.md b/content/zh-cn/docs/reference/glossary/container-lifecycle-hooks.md similarity index 100% rename from content/zh/docs/reference/glossary/container-lifecycle-hooks.md rename to content/zh-cn/docs/reference/glossary/container-lifecycle-hooks.md diff --git a/content/zh/docs/reference/glossary/container-runtime-interface.md b/content/zh-cn/docs/reference/glossary/container-runtime-interface.md similarity index 100% rename from content/zh/docs/reference/glossary/container-runtime-interface.md rename to content/zh-cn/docs/reference/glossary/container-runtime-interface.md diff --git a/content/zh/docs/reference/glossary/container-runtime.md b/content/zh-cn/docs/reference/glossary/container-runtime.md similarity index 90% rename from content/zh/docs/reference/glossary/container-runtime.md rename to content/zh-cn/docs/reference/glossary/container-runtime.md index 36a0caf416..0040642c43 100644 --- a/content/zh/docs/reference/glossary/container-runtime.md +++ b/content/zh-cn/docs/reference/glossary/container-runtime.md @@ -41,8 +41,9 @@ Kubernetes supports container runtimes such sa and any other implementation of the [Kubernetes CRI (Container Runtime Interface)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md). --> -Kubernetes 支持容器运行时，例如 +Kubernetes 支持许多容器运行环境，例如 {{< glossary_tooltip term_id="docker">}}、 -{{< glossary_tooltip term_id="containerd" >}}、{{< glossary_tooltip term_id="cri-o" >}} +{{< glossary_tooltip term_id="containerd" >}}、 +{{< glossary_tooltip term_id="cri-o" >}} 以及 [Kubernetes CRI (容器运行环境接口)](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/container-runtime-interface.md) 的其他任何实现。 \ No newline at end of file diff --git a/content/zh/docs/reference/glossary/container.md b/content/zh-cn/docs/reference/glossary/container.md similarity index 100% rename from content/zh/docs/reference/glossary/container.md rename to content/zh-cn/docs/reference/glossary/container.md diff --git a/content/zh/docs/reference/glossary/containerd.md b/content/zh-cn/docs/reference/glossary/containerd.md similarity index 100% rename from content/zh/docs/reference/glossary/containerd.md rename to content/zh-cn/docs/reference/glossary/containerd.md diff --git a/content/zh/docs/reference/glossary/contributor.md b/content/zh-cn/docs/reference/glossary/contributor.md similarity index 100% rename from content/zh/docs/reference/glossary/contributor.md rename to content/zh-cn/docs/reference/glossary/contributor.md diff --git a/content/zh/docs/reference/glossary/control-plane.md b/content/zh-cn/docs/reference/glossary/control-plane.md similarity index 100% rename from content/zh/docs/reference/glossary/control-plane.md rename to content/zh-cn/docs/reference/glossary/control-plane.md diff --git a/content/zh/docs/reference/glossary/controller.md b/content/zh-cn/docs/reference/glossary/controller.md similarity index 100% rename from content/zh/docs/reference/glossary/controller.md rename to content/zh-cn/docs/reference/glossary/controller.md diff --git a/content/zh/docs/reference/glossary/cri-o.md b/content/zh-cn/docs/reference/glossary/cri-o.md similarity index 100% rename from content/zh/docs/reference/glossary/cri-o.md rename to content/zh-cn/docs/reference/glossary/cri-o.md diff --git a/content/zh/docs/reference/glossary/cri.md b/content/zh-cn/docs/reference/glossary/cri.md similarity index 100% rename from content/zh/docs/reference/glossary/cri.md rename to content/zh-cn/docs/reference/glossary/cri.md diff --git a/content/zh/docs/reference/glossary/cronjob.md b/content/zh-cn/docs/reference/glossary/cronjob.md similarity index 100% rename from content/zh/docs/reference/glossary/cronjob.md rename to content/zh-cn/docs/reference/glossary/cronjob.md diff --git a/content/zh/docs/reference/glossary/csi.md b/content/zh-cn/docs/reference/glossary/csi.md similarity index 100% rename from content/zh/docs/reference/glossary/csi.md rename to content/zh-cn/docs/reference/glossary/csi.md diff --git a/content/zh/docs/reference/glossary/customresourcedefinition.md b/content/zh-cn/docs/reference/glossary/customresourcedefinition.md similarity index 100% rename from content/zh/docs/reference/glossary/customresourcedefinition.md rename to content/zh-cn/docs/reference/glossary/customresourcedefinition.md diff --git a/content/zh/docs/reference/glossary/daemonset.md b/content/zh-cn/docs/reference/glossary/daemonset.md similarity index 100% rename from content/zh/docs/reference/glossary/daemonset.md rename to content/zh-cn/docs/reference/glossary/daemonset.md diff --git a/content/zh/docs/reference/glossary/data-plane.md b/content/zh-cn/docs/reference/glossary/data-plane.md similarity index 100% rename from content/zh/docs/reference/glossary/data-plane.md rename to content/zh-cn/docs/reference/glossary/data-plane.md diff --git a/content/zh/docs/reference/glossary/deployment.md b/content/zh-cn/docs/reference/glossary/deployment.md similarity index 100% rename from content/zh/docs/reference/glossary/deployment.md rename to content/zh-cn/docs/reference/glossary/deployment.md diff --git a/content/zh/docs/reference/glossary/developer.md b/content/zh-cn/docs/reference/glossary/developer.md similarity index 100% rename from content/zh/docs/reference/glossary/developer.md rename to content/zh-cn/docs/reference/glossary/developer.md diff --git a/content/zh/docs/reference/glossary/device-plugin.md b/content/zh-cn/docs/reference/glossary/device-plugin.md similarity index 100% rename from content/zh/docs/reference/glossary/device-plugin.md rename to content/zh-cn/docs/reference/glossary/device-plugin.md diff --git a/content/zh/docs/reference/glossary/disruption.md b/content/zh-cn/docs/reference/glossary/disruption.md similarity index 100% rename from content/zh/docs/reference/glossary/disruption.md rename to content/zh-cn/docs/reference/glossary/disruption.md diff --git a/content/zh/docs/reference/glossary/docker.md b/content/zh-cn/docs/reference/glossary/docker.md similarity index 100% rename from content/zh/docs/reference/glossary/docker.md rename to content/zh-cn/docs/reference/glossary/docker.md diff --git a/content/zh-cn/docs/reference/glossary/dockershim.md b/content/zh-cn/docs/reference/glossary/dockershim.md new file mode 100644 index 0000000000..22570a4b17 --- /dev/null +++ b/content/zh-cn/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/downstream.md b/content/zh-cn/docs/reference/glossary/downstream.md similarity index 100% rename from content/zh/docs/reference/glossary/downstream.md rename to content/zh-cn/docs/reference/glossary/downstream.md diff --git a/content/zh/docs/reference/glossary/dynamic-volume-provisioning.md b/content/zh-cn/docs/reference/glossary/dynamic-volume-provisioning.md similarity index 100% rename from content/zh/docs/reference/glossary/dynamic-volume-provisioning.md rename to content/zh-cn/docs/reference/glossary/dynamic-volume-provisioning.md diff --git a/content/zh/docs/reference/glossary/endpoint-slice.md b/content/zh-cn/docs/reference/glossary/endpoint-slice.md similarity index 100% rename from content/zh/docs/reference/glossary/endpoint-slice.md rename to content/zh-cn/docs/reference/glossary/endpoint-slice.md diff --git a/content/zh/docs/reference/glossary/endpoint.md b/content/zh-cn/docs/reference/glossary/endpoint.md similarity index 100% rename from content/zh/docs/reference/glossary/endpoint.md rename to content/zh-cn/docs/reference/glossary/endpoint.md diff --git a/content/zh/docs/reference/glossary/ephemeral-container.md b/content/zh-cn/docs/reference/glossary/ephemeral-container.md similarity index 100% rename from content/zh/docs/reference/glossary/ephemeral-container.md rename to content/zh-cn/docs/reference/glossary/ephemeral-container.md diff --git a/content/zh/docs/reference/glossary/etcd.md b/content/zh-cn/docs/reference/glossary/etcd.md similarity index 72% rename from content/zh/docs/reference/glossary/etcd.md rename to content/zh-cn/docs/reference/glossary/etcd.md index a13de28d1a..adb4737975 100644 --- a/content/zh/docs/reference/glossary/etcd.md +++ b/content/zh-cn/docs/reference/glossary/etcd.md @@ -32,7 +32,7 @@ tags: Consistent and highly-available key value store used as Kubernetes' backing store for all cluster data. --> -etcd 是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。 +`etcd` 是兼顾一致性与高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。 -你的 Kubernetes 集群的 etcd 数据库通常需要有个备份计划。 +你的 Kubernetes 集群的 `etcd` 数据库通常需要有个[备份](/zh/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster)计划。 -要了解 etcd 更深层次的信息，请参考 [etcd 文档](https://etcd.io/docs/)。 +如果想要更深入的了解 `etcd`，请参考 [etcd 文档](https://etcd.io/docs/)。 diff --git a/content/zh/docs/reference/glossary/event.md b/content/zh-cn/docs/reference/glossary/event.md similarity index 100% rename from content/zh/docs/reference/glossary/event.md rename to content/zh-cn/docs/reference/glossary/event.md diff --git a/content/zh/docs/reference/glossary/eviction.md b/content/zh-cn/docs/reference/glossary/eviction.md similarity index 100% rename from content/zh/docs/reference/glossary/eviction.md rename to content/zh-cn/docs/reference/glossary/eviction.md diff --git a/content/zh/docs/reference/glossary/extensions.md b/content/zh-cn/docs/reference/glossary/extensions.md similarity index 100% rename from content/zh/docs/reference/glossary/extensions.md rename to content/zh-cn/docs/reference/glossary/extensions.md diff --git a/content/zh/docs/reference/glossary/finalizer.md b/content/zh-cn/docs/reference/glossary/finalizer.md similarity index 100% rename from content/zh/docs/reference/glossary/finalizer.md rename to content/zh-cn/docs/reference/glossary/finalizer.md diff --git a/content/zh/docs/reference/glossary/flexvolume.md b/content/zh-cn/docs/reference/glossary/flexvolume.md similarity index 100% rename from content/zh/docs/reference/glossary/flexvolume.md rename to content/zh-cn/docs/reference/glossary/flexvolume.md diff --git a/content/zh/docs/reference/glossary/garbage-collection.md b/content/zh-cn/docs/reference/glossary/garbage-collection.md similarity index 100% rename from content/zh/docs/reference/glossary/garbage-collection.md rename to content/zh-cn/docs/reference/glossary/garbage-collection.md diff --git a/content/zh/docs/reference/glossary/helm-chart.md b/content/zh-cn/docs/reference/glossary/helm-chart.md similarity index 100% rename from content/zh/docs/reference/glossary/helm-chart.md rename to content/zh-cn/docs/reference/glossary/helm-chart.md diff --git a/content/zh/docs/reference/glossary/horizontal-pod-autoscaler.md b/content/zh-cn/docs/reference/glossary/horizontal-pod-autoscaler.md similarity index 100% rename from content/zh/docs/reference/glossary/horizontal-pod-autoscaler.md rename to content/zh-cn/docs/reference/glossary/horizontal-pod-autoscaler.md diff --git a/content/zh/docs/reference/glossary/host-aliases.md b/content/zh-cn/docs/reference/glossary/host-aliases.md similarity index 100% rename from content/zh/docs/reference/glossary/host-aliases.md rename to content/zh-cn/docs/reference/glossary/host-aliases.md diff --git a/content/zh/docs/reference/glossary/image.md b/content/zh-cn/docs/reference/glossary/image.md similarity index 100% rename from content/zh/docs/reference/glossary/image.md rename to content/zh-cn/docs/reference/glossary/image.md diff --git a/content/zh/docs/reference/glossary/index.md b/content/zh-cn/docs/reference/glossary/index.md similarity index 100% rename from content/zh/docs/reference/glossary/index.md rename to content/zh-cn/docs/reference/glossary/index.md diff --git a/content/zh/docs/reference/glossary/ingress.md b/content/zh-cn/docs/reference/glossary/ingress.md similarity index 100% rename from content/zh/docs/reference/glossary/ingress.md rename to content/zh-cn/docs/reference/glossary/ingress.md diff --git a/content/zh/docs/reference/glossary/init-container.md b/content/zh-cn/docs/reference/glossary/init-container.md similarity index 100% rename from content/zh/docs/reference/glossary/init-container.md rename to content/zh-cn/docs/reference/glossary/init-container.md diff --git a/content/zh/docs/reference/glossary/istio.md b/content/zh-cn/docs/reference/glossary/istio.md similarity index 100% rename from content/zh/docs/reference/glossary/istio.md rename to content/zh-cn/docs/reference/glossary/istio.md diff --git a/content/zh/docs/reference/glossary/job.md b/content/zh-cn/docs/reference/glossary/job.md similarity index 100% rename from content/zh/docs/reference/glossary/job.md rename to content/zh-cn/docs/reference/glossary/job.md diff --git a/content/zh/docs/reference/glossary/kops.md b/content/zh-cn/docs/reference/glossary/kops.md similarity index 100% rename from content/zh/docs/reference/glossary/kops.md rename to content/zh-cn/docs/reference/glossary/kops.md diff --git a/content/zh/docs/reference/glossary/kube-apiserver.md b/content/zh-cn/docs/reference/glossary/kube-apiserver.md similarity index 73% rename from content/zh/docs/reference/glossary/kube-apiserver.md rename to content/zh-cn/docs/reference/glossary/kube-apiserver.md index 05f9605b2a..189ecfc36c 100644 --- a/content/zh/docs/reference/glossary/kube-apiserver.md +++ b/content/zh-cn/docs/reference/glossary/kube-apiserver.md @@ -31,9 +31,9 @@ tags: {{< glossary_tooltip text="control plane" term_id="control-plane" >}} that exposes the Kubernetes API. The API server is the front end for the Kubernetes control plane. --> -API 服务器是 Kubernetes {{< glossary_tooltip text="控制面" term_id="control-plane" >}}的组件， -该组件公开了 Kubernetes API。 -API 服务器是 Kubernetes 控制面的前端。 +API 服务器是 Kubernetes {{< glossary_tooltip text="控制平面" term_id="control-plane" >}}的组件， +该组件负责公开了 Kubernetes API，负责处理接受请求的工作。 +API 服务器是 Kubernetes 控制平面的前端。 @@ -43,5 +43,5 @@ kube-apiserver is designed to scale horizontally—that is, it scales by dep You can run several instances of kube-apiserver and balance traffic between those instances. --> Kubernetes API 服务器的主要实现是 [kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)。 -kube-apiserver 设计上考虑了水平伸缩，也就是说，它可通过部署多个实例进行伸缩。 -你可以运行 kube-apiserver 的多个实例，并在这些实例之间平衡流量。 +`kube-apiserver` 设计上考虑了水平扩缩，也就是说，它可通过部署多个实例来进行扩缩。 +你可以运行 `kube-apiserver` 的多个实例，并在这些实例之间平衡流量。 diff --git a/content/zh-cn/docs/reference/glossary/kube-controller-manager.md b/content/zh-cn/docs/reference/glossary/kube-controller-manager.md new file mode 100644 index 0000000000..12dd0b3988 --- /dev/null +++ b/content/zh-cn/docs/reference/glossary/kube-controller-manager.md @@ -0,0 +1,47 @@ +--- +title: kube-controller-manager +id: kube-controller-manager +date: 2018-04-12 +full_link: /docs/reference/generated/kube-controller-manager/ +short_description: > + 主节点上运行控制器的组件。 + +aka: +tags: +- architecture +- fundamental +--- + + + + +[kube-controller-manager](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) 是{{< glossary_tooltip text="控制平面" term_id="control-plane" >}}的组件， +负责运行{{< glossary_tooltip text="控制器" term_id="controller" >}}进程。 + + + +从逻辑上讲， +每个{{< glossary_tooltip text="控制器" term_id="controller" >}}都是一个单独的进程， +但是为了降低复杂性，它们都被编译到同一个可执行文件，并在同一个进程中运行。 + diff --git a/content/zh-cn/docs/reference/glossary/kube-proxy.md b/content/zh-cn/docs/reference/glossary/kube-proxy.md new file mode 100644 index 0000000000..3fce715cb7 --- /dev/null +++ b/content/zh-cn/docs/reference/glossary/kube-proxy.md @@ -0,0 +1,53 @@ +--- +title: kube-proxy +id: kube-proxy +date: 2018-04-12 +full_link: /zh/docs/reference/command-line-tools-reference/kube-proxy/ +short_description: > + `kube-proxy` 是集群中每个节点上运行的网络代理。 + +aka: +tags: +- fundamental +- networking +--- + + +[kube-proxy](/zh/docs/reference/command-line-tools-reference/kube-proxy/) +是集群中每个{{< glossary_tooltip text="节点（node）" term_id="node" >}}所上运行的网络代理， +实现 Kubernetes {{< glossary_tooltip term_id="service">}} 概念的一部分。 + + + + +kube-proxy 维护节点上的一些网络规则， +这些网络规则会允许从集群内部或外部的网络会话与 Pod 进行网络通信。 + + +如果操作系统提供了可用的数据包过滤层，则 kube-proxy 会通过它来实现网络规则。 +否则，kube-proxy 仅做流量转发。 diff --git a/content/zh/docs/reference/glossary/kube-scheduler.md b/content/zh-cn/docs/reference/glossary/kube-scheduler.md similarity index 69% rename from content/zh/docs/reference/glossary/kube-scheduler.md rename to content/zh-cn/docs/reference/glossary/kube-scheduler.md index 9d6a1842fb..c2964d0d74 100644 --- a/content/zh/docs/reference/glossary/kube-scheduler.md +++ b/content/zh-cn/docs/reference/glossary/kube-scheduler.md @@ -33,7 +33,9 @@ Control plane component that watches for newly created {{< glossary_tooltip term_id="node" text="node">}}, and selects a node for them to run on.--> - 控制平面组件，负责监视新创建的、未指定运行{{< glossary_tooltip term_id="node" text="节点（node）">}}的 {{< glossary_tooltip term_id="pod" text="Pods" >}}，选择节点让 Pod 在上面运行。 + `kube-scheduler` 是{{< glossary_tooltip text="控制平面" term_id="control-plane" >}}的组件， + 负责监视新创建的、未指定运行{{< glossary_tooltip term_id="node" text="节点（node）">}}的 {{< glossary_tooltip term_id="pod" text="Pods" >}}， + 并选择节点来让 Pod 在上面运行。 @@ -41,4 +43,5 @@ to run on.--> Factors taken into account for scheduling decisions include individual and collective resource requirements, hardware/software/policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference and deadlines. --> -调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。 +调度决策考虑的因素包括单个 Pod 及 Pods 集合的资源需求、软硬件及策略约束、 +亲和性及反亲和性规范、数据位置、工作负载间的干扰及最后时限。 diff --git a/content/zh/docs/reference/glossary/kubeadm.md b/content/zh-cn/docs/reference/glossary/kubeadm.md similarity index 100% rename from content/zh/docs/reference/glossary/kubeadm.md rename to content/zh-cn/docs/reference/glossary/kubeadm.md diff --git a/content/zh/docs/reference/glossary/kubectl.md b/content/zh-cn/docs/reference/glossary/kubectl.md similarity index 100% rename from content/zh/docs/reference/glossary/kubectl.md rename to content/zh-cn/docs/reference/glossary/kubectl.md diff --git a/content/zh/docs/reference/glossary/kubelet.md b/content/zh-cn/docs/reference/glossary/kubelet.md similarity index 81% rename from content/zh/docs/reference/glossary/kubelet.md rename to content/zh-cn/docs/reference/glossary/kubelet.md index a00971e224..1a5b4f630b 100644 --- a/content/zh/docs/reference/glossary/kubelet.md +++ b/content/zh-cn/docs/reference/glossary/kubelet.md @@ -28,16 +28,16 @@ tags: -一个在集群中每个{{< glossary_tooltip text="节点（node）" term_id="node" >}}上运行的代理。 -它保证{{< glossary_tooltip text="容器（containers）" term_id="container" >}}都 -运行在 {{< glossary_tooltip text="Pod" term_id="pod" >}} 中。 +`kubelet` 会在集群中每个{{< glossary_tooltip text="节点（node）" term_id="node" >}}上运行。 +它保证{{< glossary_tooltip text="容器（containers）" term_id="container" >}}都运行在 +{{< glossary_tooltip text="Pod" term_id="pod" >}} 中。 -kubelet 接收一组通过各类机制提供给它的 PodSpecs，确保这些 PodSpecs -中描述的容器处于运行状态且健康。 +kubelet 接收一组通过各类机制提供给它的 PodSpecs， +确保这些 PodSpecs 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。 diff --git a/content/zh/docs/reference/glossary/kubernetes-api.md b/content/zh-cn/docs/reference/glossary/kubernetes-api.md similarity index 100% rename from content/zh/docs/reference/glossary/kubernetes-api.md rename to content/zh-cn/docs/reference/glossary/kubernetes-api.md diff --git a/content/zh/docs/reference/glossary/label.md b/content/zh-cn/docs/reference/glossary/label.md similarity index 100% rename from content/zh/docs/reference/glossary/label.md rename to content/zh-cn/docs/reference/glossary/label.md diff --git a/content/zh/docs/reference/glossary/limitrange.md b/content/zh-cn/docs/reference/glossary/limitrange.md similarity index 100% rename from content/zh/docs/reference/glossary/limitrange.md rename to content/zh-cn/docs/reference/glossary/limitrange.md diff --git a/content/zh/docs/reference/glossary/logging.md b/content/zh-cn/docs/reference/glossary/logging.md similarity index 100% rename from content/zh/docs/reference/glossary/logging.md rename to content/zh-cn/docs/reference/glossary/logging.md diff --git a/content/zh/docs/reference/glossary/managed-service.md b/content/zh-cn/docs/reference/glossary/managed-service.md similarity index 100% rename from content/zh/docs/reference/glossary/managed-service.md rename to content/zh-cn/docs/reference/glossary/managed-service.md diff --git a/content/zh/docs/reference/glossary/manifest.md b/content/zh-cn/docs/reference/glossary/manifest.md similarity index 100% rename from content/zh/docs/reference/glossary/manifest.md rename to content/zh-cn/docs/reference/glossary/manifest.md diff --git a/content/zh/docs/reference/glossary/master.md b/content/zh-cn/docs/reference/glossary/master.md similarity index 100% rename from content/zh/docs/reference/glossary/master.md rename to content/zh-cn/docs/reference/glossary/master.md diff --git a/content/zh/docs/reference/glossary/member.md b/content/zh-cn/docs/reference/glossary/member.md similarity index 100% rename from content/zh/docs/reference/glossary/member.md rename to content/zh-cn/docs/reference/glossary/member.md diff --git a/content/zh/docs/reference/glossary/minikube.md b/content/zh-cn/docs/reference/glossary/minikube.md similarity index 100% rename from content/zh/docs/reference/glossary/minikube.md rename to content/zh-cn/docs/reference/glossary/minikube.md diff --git a/content/zh/docs/reference/glossary/mirror-pod.md b/content/zh-cn/docs/reference/glossary/mirror-pod.md similarity index 100% rename from content/zh/docs/reference/glossary/mirror-pod.md rename to content/zh-cn/docs/reference/glossary/mirror-pod.md diff --git a/content/zh/docs/reference/glossary/name.md b/content/zh-cn/docs/reference/glossary/name.md similarity index 100% rename from content/zh/docs/reference/glossary/name.md rename to content/zh-cn/docs/reference/glossary/name.md diff --git a/content/zh/docs/reference/glossary/namespace.md b/content/zh-cn/docs/reference/glossary/namespace.md similarity index 100% rename from content/zh/docs/reference/glossary/namespace.md rename to content/zh-cn/docs/reference/glossary/namespace.md diff --git a/content/zh/docs/reference/glossary/network-policy.md b/content/zh-cn/docs/reference/glossary/network-policy.md similarity index 100% rename from content/zh/docs/reference/glossary/network-policy.md rename to content/zh-cn/docs/reference/glossary/network-policy.md diff --git a/content/zh/docs/reference/glossary/node-pressure-eviction.md b/content/zh-cn/docs/reference/glossary/node-pressure-eviction.md similarity index 100% rename from content/zh/docs/reference/glossary/node-pressure-eviction.md rename to content/zh-cn/docs/reference/glossary/node-pressure-eviction.md diff --git a/content/zh/docs/reference/glossary/node.md b/content/zh-cn/docs/reference/glossary/node.md similarity index 100% rename from content/zh/docs/reference/glossary/node.md rename to content/zh-cn/docs/reference/glossary/node.md diff --git a/content/zh/docs/reference/glossary/object.md b/content/zh-cn/docs/reference/glossary/object.md similarity index 100% rename from content/zh/docs/reference/glossary/object.md rename to content/zh-cn/docs/reference/glossary/object.md diff --git a/content/zh/docs/reference/glossary/operator-pattern.md b/content/zh-cn/docs/reference/glossary/operator-pattern.md similarity index 100% rename from content/zh/docs/reference/glossary/operator-pattern.md rename to content/zh-cn/docs/reference/glossary/operator-pattern.md diff --git a/content/zh/docs/reference/glossary/persistent-volume-claim.md b/content/zh-cn/docs/reference/glossary/persistent-volume-claim.md similarity index 100% rename from content/zh/docs/reference/glossary/persistent-volume-claim.md rename to content/zh-cn/docs/reference/glossary/persistent-volume-claim.md diff --git a/content/zh/docs/reference/glossary/persistent-volume.md b/content/zh-cn/docs/reference/glossary/persistent-volume.md similarity index 100% rename from content/zh/docs/reference/glossary/persistent-volume.md rename to content/zh-cn/docs/reference/glossary/persistent-volume.md diff --git a/content/zh/docs/reference/glossary/platform-developer.md b/content/zh-cn/docs/reference/glossary/platform-developer.md similarity index 100% rename from content/zh/docs/reference/glossary/platform-developer.md rename to content/zh-cn/docs/reference/glossary/platform-developer.md diff --git a/content/zh/docs/reference/glossary/pod-disruption-budget.md b/content/zh-cn/docs/reference/glossary/pod-disruption-budget.md similarity index 100% rename from content/zh/docs/reference/glossary/pod-disruption-budget.md rename to content/zh-cn/docs/reference/glossary/pod-disruption-budget.md diff --git a/content/zh/docs/reference/glossary/pod-disruption.md b/content/zh-cn/docs/reference/glossary/pod-disruption.md similarity index 100% rename from content/zh/docs/reference/glossary/pod-disruption.md rename to content/zh-cn/docs/reference/glossary/pod-disruption.md diff --git a/content/zh/docs/reference/glossary/pod-lifecycle.md b/content/zh-cn/docs/reference/glossary/pod-lifecycle.md similarity index 100% rename from content/zh/docs/reference/glossary/pod-lifecycle.md rename to content/zh-cn/docs/reference/glossary/pod-lifecycle.md diff --git a/content/zh/docs/reference/glossary/pod-priority.md b/content/zh-cn/docs/reference/glossary/pod-priority.md similarity index 100% rename from content/zh/docs/reference/glossary/pod-priority.md rename to content/zh-cn/docs/reference/glossary/pod-priority.md diff --git a/content/zh/docs/reference/glossary/pod-security-policy.md b/content/zh-cn/docs/reference/glossary/pod-security-policy.md similarity index 100% rename from content/zh/docs/reference/glossary/pod-security-policy.md rename to content/zh-cn/docs/reference/glossary/pod-security-policy.md diff --git a/content/zh/docs/reference/glossary/pod.md b/content/zh-cn/docs/reference/glossary/pod.md similarity index 100% rename from content/zh/docs/reference/glossary/pod.md rename to content/zh-cn/docs/reference/glossary/pod.md diff --git a/content/zh/docs/reference/glossary/preemption.md b/content/zh-cn/docs/reference/glossary/preemption.md similarity index 100% rename from content/zh/docs/reference/glossary/preemption.md rename to content/zh-cn/docs/reference/glossary/preemption.md diff --git a/content/zh/docs/reference/glossary/proxy.md b/content/zh-cn/docs/reference/glossary/proxy.md similarity index 100% rename from content/zh/docs/reference/glossary/proxy.md rename to content/zh-cn/docs/reference/glossary/proxy.md diff --git a/content/zh/docs/reference/glossary/qos-class.md b/content/zh-cn/docs/reference/glossary/qos-class.md similarity index 100% rename from content/zh/docs/reference/glossary/qos-class.md rename to content/zh-cn/docs/reference/glossary/qos-class.md diff --git a/content/zh/docs/reference/glossary/quantity.md b/content/zh-cn/docs/reference/glossary/quantity.md similarity index 100% rename from content/zh/docs/reference/glossary/quantity.md rename to content/zh-cn/docs/reference/glossary/quantity.md diff --git a/content/zh/docs/reference/glossary/rbac.md b/content/zh-cn/docs/reference/glossary/rbac.md similarity index 100% rename from content/zh/docs/reference/glossary/rbac.md rename to content/zh-cn/docs/reference/glossary/rbac.md diff --git a/content/zh/docs/reference/glossary/replica-set.md b/content/zh-cn/docs/reference/glossary/replica-set.md similarity index 100% rename from content/zh/docs/reference/glossary/replica-set.md rename to content/zh-cn/docs/reference/glossary/replica-set.md diff --git a/content/zh/docs/reference/glossary/replication-controller.md b/content/zh-cn/docs/reference/glossary/replication-controller.md similarity index 100% rename from content/zh/docs/reference/glossary/replication-controller.md rename to content/zh-cn/docs/reference/glossary/replication-controller.md diff --git a/content/zh/docs/reference/glossary/resource-quota.md b/content/zh-cn/docs/reference/glossary/resource-quota.md similarity index 100% rename from content/zh/docs/reference/glossary/resource-quota.md rename to content/zh-cn/docs/reference/glossary/resource-quota.md diff --git a/content/zh/docs/reference/glossary/reviewer.md b/content/zh-cn/docs/reference/glossary/reviewer.md similarity index 100% rename from content/zh/docs/reference/glossary/reviewer.md rename to content/zh-cn/docs/reference/glossary/reviewer.md diff --git a/content/zh/docs/reference/glossary/secret.md b/content/zh-cn/docs/reference/glossary/secret.md similarity index 100% rename from content/zh/docs/reference/glossary/secret.md rename to content/zh-cn/docs/reference/glossary/secret.md diff --git a/content/zh/docs/reference/glossary/security-context.md b/content/zh-cn/docs/reference/glossary/security-context.md similarity index 100% rename from content/zh/docs/reference/glossary/security-context.md rename to content/zh-cn/docs/reference/glossary/security-context.md diff --git a/content/zh/docs/reference/glossary/selector.md b/content/zh-cn/docs/reference/glossary/selector.md similarity index 100% rename from content/zh/docs/reference/glossary/selector.md rename to content/zh-cn/docs/reference/glossary/selector.md diff --git a/content/zh/docs/reference/glossary/service-account.md b/content/zh-cn/docs/reference/glossary/service-account.md similarity index 100% rename from content/zh/docs/reference/glossary/service-account.md rename to content/zh-cn/docs/reference/glossary/service-account.md diff --git a/content/zh/docs/reference/glossary/service-broker.md b/content/zh-cn/docs/reference/glossary/service-broker.md similarity index 100% rename from content/zh/docs/reference/glossary/service-broker.md rename to content/zh-cn/docs/reference/glossary/service-broker.md diff --git a/content/zh/docs/reference/glossary/service-catalog.md b/content/zh-cn/docs/reference/glossary/service-catalog.md similarity index 100% rename from content/zh/docs/reference/glossary/service-catalog.md rename to content/zh-cn/docs/reference/glossary/service-catalog.md diff --git a/content/zh/docs/reference/glossary/service.md b/content/zh-cn/docs/reference/glossary/service.md similarity index 100% rename from content/zh/docs/reference/glossary/service.md rename to content/zh-cn/docs/reference/glossary/service.md diff --git a/content/zh/docs/reference/glossary/shuffle-sharding.md b/content/zh-cn/docs/reference/glossary/shuffle-sharding.md similarity index 100% rename from content/zh/docs/reference/glossary/shuffle-sharding.md rename to content/zh-cn/docs/reference/glossary/shuffle-sharding.md diff --git a/content/zh/docs/reference/glossary/sig.md b/content/zh-cn/docs/reference/glossary/sig.md similarity index 100% rename from content/zh/docs/reference/glossary/sig.md rename to content/zh-cn/docs/reference/glossary/sig.md diff --git a/content/zh/docs/reference/glossary/statefulset.md b/content/zh-cn/docs/reference/glossary/statefulset.md similarity index 100% rename from content/zh/docs/reference/glossary/statefulset.md rename to content/zh-cn/docs/reference/glossary/statefulset.md diff --git a/content/zh/docs/reference/glossary/static-pod.md b/content/zh-cn/docs/reference/glossary/static-pod.md similarity index 100% rename from content/zh/docs/reference/glossary/static-pod.md rename to content/zh-cn/docs/reference/glossary/static-pod.md diff --git a/content/zh/docs/reference/glossary/storage-class.md b/content/zh-cn/docs/reference/glossary/storage-class.md similarity index 100% rename from content/zh/docs/reference/glossary/storage-class.md rename to content/zh-cn/docs/reference/glossary/storage-class.md diff --git a/content/zh/docs/reference/glossary/sysctl.md b/content/zh-cn/docs/reference/glossary/sysctl.md similarity index 100% rename from content/zh/docs/reference/glossary/sysctl.md rename to content/zh-cn/docs/reference/glossary/sysctl.md diff --git a/content/zh/docs/reference/glossary/taint.md b/content/zh-cn/docs/reference/glossary/taint.md similarity index 100% rename from content/zh/docs/reference/glossary/taint.md rename to content/zh-cn/docs/reference/glossary/taint.md diff --git a/content/zh/docs/reference/glossary/toleration.md b/content/zh-cn/docs/reference/glossary/toleration.md similarity index 100% rename from content/zh/docs/reference/glossary/toleration.md rename to content/zh-cn/docs/reference/glossary/toleration.md diff --git a/content/zh/docs/reference/glossary/uid.md b/content/zh-cn/docs/reference/glossary/uid.md similarity index 100% rename from content/zh/docs/reference/glossary/uid.md rename to content/zh-cn/docs/reference/glossary/uid.md diff --git a/content/zh/docs/reference/glossary/upstream.md b/content/zh-cn/docs/reference/glossary/upstream.md similarity index 100% rename from content/zh/docs/reference/glossary/upstream.md rename to content/zh-cn/docs/reference/glossary/upstream.md diff --git a/content/zh/docs/reference/glossary/userns.md b/content/zh-cn/docs/reference/glossary/userns.md similarity index 100% rename from content/zh/docs/reference/glossary/userns.md rename to content/zh-cn/docs/reference/glossary/userns.md diff --git a/content/zh/docs/reference/glossary/volume-plugin.md b/content/zh-cn/docs/reference/glossary/volume-plugin.md similarity index 100% rename from content/zh/docs/reference/glossary/volume-plugin.md rename to content/zh-cn/docs/reference/glossary/volume-plugin.md diff --git a/content/zh/docs/reference/glossary/volume.md b/content/zh-cn/docs/reference/glossary/volume.md similarity index 100% rename from content/zh/docs/reference/glossary/volume.md rename to content/zh-cn/docs/reference/glossary/volume.md diff --git a/content/zh/docs/reference/glossary/wg.md b/content/zh-cn/docs/reference/glossary/wg.md similarity index 100% rename from content/zh/docs/reference/glossary/wg.md rename to content/zh-cn/docs/reference/glossary/wg.md diff --git a/content/zh/docs/reference/glossary/workload.md b/content/zh-cn/docs/reference/glossary/workload.md similarity index 100% rename from content/zh/docs/reference/glossary/workload.md rename to content/zh-cn/docs/reference/glossary/workload.md diff --git a/content/zh/docs/reference/issues-security/_index.md b/content/zh-cn/docs/reference/issues-security/_index.md similarity index 100% rename from content/zh/docs/reference/issues-security/_index.md rename to content/zh-cn/docs/reference/issues-security/_index.md diff --git a/content/zh/docs/reference/issues-security/issues.md b/content/zh-cn/docs/reference/issues-security/issues.md similarity index 94% rename from content/zh/docs/reference/issues-security/issues.md rename to content/zh-cn/docs/reference/issues-security/issues.md index 23a015a519..0cad3c4329 100644 --- a/content/zh/docs/reference/issues-security/issues.md +++ b/content/zh-cn/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-cn/docs/reference/issues-security/security.md similarity index 68% rename from content/zh/docs/reference/issues-security/security.md rename to content/zh-cn/docs/reference/issues-security/security.md index 3124098682..a6698022b7 100644 --- a/content/zh/docs/reference/issues-security/security.md +++ b/content/zh-cn/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/overview.md b/content/zh-cn/docs/reference/kubectl/_index.md similarity index 71% rename from content/zh/docs/reference/kubectl/overview.md rename to content/zh-cn/docs/reference/kubectl/_index.md index ddc83e8536..38659b2e8d 100644 --- a/content/zh/docs/reference/kubectl/overview.md +++ b/content/zh-cn/docs/reference/kubectl/_index.md @@ -1,37 +1,40 @@ --- -reviewers: -- hw-qiaolei -title: kubectl 概述 -content_type: concept -weight: 20 +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 命令行工具管理 Kubernetes 集群。 -`kubectl` 在 `$HOME/.kube` 目录中查找一个名为 `config` 的配置文件。 -你可以通过设置 KUBECONFIG 环境变量或设置 +`针对配置信息，`kubectl` 在 `$HOME/.kube` 目录中查找一个名为 `config` 的配置文件。 +你可以通过设置 `KUBECONFIG` 环境变量或设置 [`--kubeconfig`](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 参数来指定其它 [kubeconfig](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 文件。 @@ -39,24 +42,32 @@ files by setting the KUBECONFIG environment variable or by setting the This overview covers `kubectl` syntax, describes the command operations, and provides common examples. For details about each command, including all the supported flags and subcommands, see the [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) reference documentation. -For installation instructions see [installing kubectl](/docs/tasks/tools/install-kubectl/). --> 本文概述了 `kubectl` 语法和命令操作描述，并提供了常见的示例。 有关每个命令的详细信息，包括所有受支持的参数和子命令， 请参阅 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 参考文档。 -有关安装说明，请参见[安装 kubectl](/zh/docs/tasks/tools/install-kubectl/) 。 - - + +有关安装说明，请参见[安装 kubectl](/zh/docs/tasks/tools/#kubectl)； +如需快速指南，请参见[备忘单](/zh/docs/reference/kubectl/cheatsheet/)。 +如果你更习惯使用 `docker` 命令行工具， +[Docker 用户的 `kubectl`](/zh/docs/reference/kubectl/docker-cli-to-kubectl/) +介绍了一些 Kubernetes 的等价命令。 + + ## 语法 - -使用以下语法 `kubectl` 从终端窗口运行命令： +使用以下语法从终端窗口运行 `kubectl` 命令： ```shell kubectl [command] [TYPE] [NAME] [flags] @@ -68,34 +79,36 @@ where `command`, `TYPE`, `NAME`, and `flags` are: 其中 `command`、`TYPE`、`NAME` 和 `flags` 分别是： * `command`：指定要对一个或多个资源执行的操作，例如 `create`、`get`、`describe`、`delete`。 -* `TYPE`：指定[资源类型](#资源类型)。资源类型不区分大小写， - 可以指定单数、复数或缩写形式。例如，以下命令输出相同的结果: +* `TYPE`：指定[资源类型](#resource-types)。资源类型不区分大小写， + 可以指定单数、复数或缩写形式。例如，以下命令输出相同的结果： - ```shell - kubectl get pod pod1 - kubectl get pods pod1 - kubectl get po pod1 - ``` + ```shell + kubectl get pod pod1 + kubectl get pods pod1 + kubectl get po pod1 + ``` - * `NAME`：指定资源的名称。名称区分大小写。 - 如果省略名称，则显示所有资源的详细信息 `kubectl get pods`。 + 如果省略名称，则显示所有资源的详细信息。例如：`kubectl get pods`。 在对多个资源执行操作时，你可以按类型和名称指定每个资源，或指定一个或多个文件： - - * 要按类型和名称指定资源： +--> + * 要按类型和名称指定资源： - * 要对所有类型相同的资源进行分组，请执行以下操作：`TYPE1 name1 name2 name<#>`。 + * 要对所有类型相同的资源进行分组，请执行以下操作：`TYPE1 name1 name2 name<#>`。
    + 例子：`kubectl get pod example-pod1 example-pod2` - 例子：`kubectl get pod example-pod1 example-pod2` + * 分别指定多个资源类型：`TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`。
    + 例子：`kubectl get pod/example-pod1 replicationcontroller/example-rc1` - * 分别指定多个资源类型：`TYPE1/name1 TYPE1/name2 TYPE2/name3 TYPE<#>/name<#>`。 + * 用一个或多个文件指定资源：`-f file1 -f file2 -f file<#>` - 例子：`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` + * [使用 YAML 而不是 JSON](/zh/docs/concepts/configuration/overview/#general-configuration-tips)， + 因为 YAML 对用户更友好, 特别是对于配置文件。
    + 例子：`kubectl get -f ./pod.yaml` -* `flags`: 指定可选的参数。例如，可以使用 `-s` 或 `-server` 参数指定 +* `flags`： 指定可选的参数。例如，可以使用 `-s` 或 `--server` 参数指定 Kubernetes API 服务器的地址和端口。 -{{< caution >}} +{{< caution >}} 从命令行指定的参数会覆盖默认值和任何相应的环境变量。 {{< /caution >}} -如果你需要帮助，从终端窗口运行 `kubectl help` 。 +如果你需要帮助，在终端窗口中运行 `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` 命名空间进行操作。 +操作 | 语法 | 描述 +-------------------- | -------------------- | -------------------- +`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] | 在集群上运行指定的镜像。 + - -操作 | 语法 | 描述 --------------------- | -------------------- | -------------------- -`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 格式。 -`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]`| 将 live 配置和文件或标准输入做对比 (**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] | 使用策略合并 patch 程序更新资源的一个或多个字段。 -`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]` | 管理资源的部署。有效的资源类型包括：Deployments, DaemonSets 和 StatefulSets。 -`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]` | 配置应用程序资源。 +`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/内存/存储）的使用情况。 +`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] | 实验性：等待一种或多种资源的特定条件。 - +`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](/zh/docs/reference/kubectl/kubectl/) 参考文档。 - ## 资源类型 -下表列出所有受支持的资源类型及其缩写别名: +下表列出所有受支持的资源类型及其缩写别名。 | 资源名 | 缩写名 | API 分组 | 按命名空间 | 资源类型 | |---|---|---|---|---| @@ -388,7 +421,6 @@ The following table includes a list of all the supported resource types and thei | `storageclasses` | `sc` | storage.k8s.io | false | StorageClass | | `volumeattachments` | | storage.k8s.io | false | VolumeAttachment | - @@ -398,7 +430,8 @@ The following table includes a list of all the supported resource types and thei -有关如何格式化或排序某些命令的输出的信息，请使用以下部分。有关哪些命令支持各种输出选项的详细信息，请参阅[kubectl](/zh/docs/reference/kubectl/kubectl/) 参考文档。 +有关如何格式化或排序某些命令的输出的信息，请参阅以下章节。有关哪些命令支持不同输出选项的详细信息， +请参阅 [kubectl](/zh/docs/reference/kubectl/kubectl/) 参考文档。 -所有 `kubectl` 命令的默认输出格式都是人类可读的纯文本格式。要以特定格式向终端窗口输出详细信息，可以将 `-o` 或 `--output` 参数添加到受支持的 `kubectl` 命令中。 +所有 `kubectl` 命令的默认输出格式都是人类可读的纯文本格式。要以特定格式在终端窗口输出详细信息， +可以将 `-o` 或 `--output` 参数添加到受支持的 `kubectl` 命令中。 -根据 `kubectl` 操作，支持以下输出格式： +取决于具体的 `kubectl` 操作，支持的输出格式如下： -Output format | Description +输出格式 | 描述 --------------| ----------- `-o custom-columns=` | 使用逗号分隔的[自定义列](#custom-columns)列表打印表。 `-o custom-columns-file=` | 使用 `` 文件中的[自定义列](#custom-columns)模板打印表。 @@ -444,10 +478,9 @@ Output format | Description `-o jsonpath=