diff --git a/README-zh.md b/README-zh.md index 00a7ef1a24..e3ac58fb93 100644 --- a/README-zh.md +++ b/README-zh.md @@ -65,7 +65,7 @@ The Kubernetes website uses the [Docsy Hugo theme](https://github.com/google/doc Kubernetes 网站使用的是 [Docsy Hugo 主题](https://github.com/google/docsy#readme)。 即使你打算在容器中运行网站，我们也强烈建议你通过运行以下命令来引入子模块和其他开发依赖项： ```bash -# pull in the Docsy submodule +# 引入 Docsy 子模块 git submodule update --init --recursive --depth 1 ``` @@ -113,7 +113,7 @@ Hugo 扩展版本。 若要在本地构造和测试网站，请运行： ```bash -# install dependencies +# 安装依赖 npm ci make serve ``` diff --git a/content/en/blog/_posts/2018-11-08-kubernetes-docs-update-i18n.md b/content/en/blog/_posts/2018-11-08-kubernetes-docs-update-i18n.md index 38fd24372c..4c9af11a9e 100644 --- a/content/en/blog/_posts/2018-11-08-kubernetes-docs-update-i18n.md +++ b/content/en/blog/_posts/2018-11-08-kubernetes-docs-update-i18n.md @@ -41,7 +41,7 @@ These repo labels let reviewers filter for PRs and issues by language. For examp ### Team review -L10n teams can now review and approve their own PRs. For example, review and approval permissions for English are [assigned in an OWNERS file](https://github.com/kubernetes/website/blob/master/content/en/OWNERS) in the top subfolder for English content. +L10n teams can now review and approve their own PRs. For example, review and approval permissions for English are [assigned in an OWNERS file](https://github.com/kubernetes/website/blob/main/content/en/OWNERS) in the top subfolder for English content. Adding `OWNERS` files to subdirectories lets localization teams review and approve changes without requiring a rubber stamp approval from reviewers who may lack fluency. diff --git a/content/en/blog/_posts/2019-04-26-latest-on-localization.md b/content/en/blog/_posts/2019-04-26-latest-on-localization.md index 8e6176a8ce..98f1d74706 100644 --- a/content/en/blog/_posts/2019-04-26-latest-on-localization.md +++ b/content/en/blog/_posts/2019-04-26-latest-on-localization.md @@ -8,7 +8,7 @@ date: 2019-04-26 Last year we optimized the Kubernetes website for [hosting multilingual content](/blog/2018/11/08/kubernetes-docs-updates-international-edition/). Contributors responded by adding multiple new localizations: as of April 2019, Kubernetes docs are partially available in nine different languages, with six added in 2019 alone. You can see a list of available languages in the language selector at the top of each page. -By _partially available_, I mean that localizations are ongoing projects. They range from mostly complete ([Chinese docs for 1.12](https://v1-12.docs.kubernetes.io/zh/)) to brand new (1.14 docs in [Portuguese](https://kubernetes.io/pt/)). If you're interested in helping an existing localization, read on! +By _partially available_, I mean that localizations are ongoing projects. They range from mostly complete ([Chinese docs for 1.12](https://v1-12.docs.kubernetes.io/zh-cn/)) to brand new (1.14 docs in [Portuguese](https://kubernetes.io/pt/)). If you're interested in helping an existing localization, read on! ## What is a localization? diff --git a/content/en/blog/_posts/2020-09-03-warnings/index.md b/content/en/blog/_posts/2020-09-03-warnings/index.md index 082aa72f6f..a5cfb9f710 100644 --- a/content/en/blog/_posts/2020-09-03-warnings/index.md +++ b/content/en/blog/_posts/2020-09-03-warnings/index.md @@ -60,7 +60,7 @@ so we added two administrator-facing tools to help track use of deprecated APIs Starting in Kubernetes v1.19, when a request is made to a deprecated REST API endpoint, an `apiserver_requested_deprecated_apis` gauge metric is set to `1` in the kube-apiserver process. This metric has labels for the API `group`, `version`, `resource`, and `subresource`, -and a `removed_version` label that indicates the Kubernetes release in which the API will no longer be served. +and a `removed_release` label that indicates the Kubernetes release in which the API will no longer be served. This is an example query using `kubectl`, [prom2json](https://github.com/prometheus/prom2json), and [jq](https://stedolan.github.io/jq/) to determine which deprecated APIs have been requested @@ -169,7 +169,7 @@ You can also find that information through the following Prometheus query, which returns information about requests made to deprecated APIs which will be removed in v1.22: ```promql -apiserver_requested_deprecated_apis{removed_version="1.22"} * on(group,version,resource,subresource) +apiserver_requested_deprecated_apis{removed_release="1.22"} * on(group,version,resource,subresource) group_right() apiserver_request_total ``` diff --git a/content/en/blog/_posts/2021-04-22-gateway-api/index.md b/content/en/blog/_posts/2021-04-22-gateway-api/index.md index c22d45cdbb..145554803d 100644 --- a/content/en/blog/_posts/2021-04-22-gateway-api/index.md +++ b/content/en/blog/_posts/2021-04-22-gateway-api/index.md @@ -30,9 +30,9 @@ This led to design principles that allow the Gateway API to improve upon Ingress The Gateway API introduces a few new resource types: -- **[GatewayClasses](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.GatewayClass)** are cluster-scoped resources that act as templates to explicitly define behavior for Gateways derived from them. This is similar in concept to StorageClasses, but for networking data-planes. -- **[Gateways](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.Gateway)** are the deployed instances of GatewayClasses. They are the logical representation of the data-plane which performs routing, which may be in-cluster proxies, hardware LBs, or cloud LBs. -- **Routes** are not a single resource, but represent many different protocol-specific Route resources. The [HTTPRoute](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.HTTPRoute) has matching, filtering, and routing rules that get applied to Gateways that can process HTTP and HTTPS traffic. Similarly, there are [TCPRoutes](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.TCPRoute), [UDPRoutes](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.UDPRoute), and [TLSRoutes](https://gateway-api.sigs.k8s.io/v1alpha1/references/spec/#networking.x-k8s.io/v1alpha1.TLSRoute) which also have protocol-specific semantics. This model also allows the Gateway API to incrementally expand its protocol support in the future. +- **[GatewayClasses](https://gateway-api.sigs.k8s.io/concepts/api-overview/#gatewayclass)** are cluster-scoped resources that act as templates to explicitly define behavior for Gateways derived from them. This is similar in concept to StorageClasses, but for networking data-planes. +- **[Gateways](https://gateway-api.sigs.k8s.io/concepts/api-overview/#gateway)** are the deployed instances of GatewayClasses. They are the logical representation of the data-plane which performs routing, which may be in-cluster proxies, hardware LBs, or cloud LBs. +- **Routes** are not a single resource, but represent many different protocol-specific Route resources. The [HTTPRoute](https://gateway-api.sigs.k8s.io/concepts/api-overview/#httproute) has matching, filtering, and routing rules that get applied to Gateways that can process HTTP and HTTPS traffic. Similarly, there are [TCPRoutes](https://gateway-api.sigs.k8s.io/concepts/api-overview/#tcproute-and-udproute), [UDPRoutes](https://gateway-api.sigs.k8s.io/concepts/api-overview/#tcproute-and-udproute), and [TLSRoutes](https://gateway-api.sigs.k8s.io/concepts/api-overview/#gateway) which also have protocol-specific semantics. This model also allows the Gateway API to incrementally expand its protocol support in the future. ![The resources of the Gateway API](gateway-api-resources.png) diff --git a/content/en/blog/_posts/2021-09-03-api-server-tracing.md b/content/en/blog/_posts/2021-09-03-api-server-tracing.md index fc98a68d23..344ff8fa46 100644 --- a/content/en/blog/_posts/2021-09-03-api-server-tracing.md +++ b/content/en/blog/_posts/2021-09-03-api-server-tracing.md @@ -42,7 +42,7 @@ samplingRatePerMillion: 10000 ### Enabling Etcd Tracing -Add `--experimental-enable-distributed-tracing`, `--experimental-distributed-tracing-address=0.0.0.0:4317`, `--experimental-distributed-tracing-service-name=etcd` flags to etcd to enable tracing. Note that this traces every request, so it will probably generate a lot of traces if you enable it. +Add `--experimental-enable-distributed-tracing`, `--experimental-distributed-tracing-address=0.0.0.0:4317`, `--experimental-distributed-tracing-service-name=etcd` flags to etcd to enable tracing. Note that this traces every request, so it will probably generate a lot of traces if you enable it. Required etcd version is [v3.5+](https://etcd.io/docs/v3.5/op-guide/monitoring/#distributed-tracing). ### Example Trace: List Nodes diff --git a/content/en/blog/_posts/2022-02-17-updated-dockershim-faq.md b/content/en/blog/_posts/2022-02-17-updated-dockershim-faq.md index 74e61b117d..4950f88097 100644 --- a/content/en/blog/_posts/2022-02-17-updated-dockershim-faq.md +++ b/content/en/blog/_posts/2022-02-17-updated-dockershim-faq.md @@ -86,7 +86,7 @@ in Kubernetes 1.24. If you're running Kubernetes v1.24 or later, see [Can I still use Docker Engine as my container runtime?](#can-i-still-use-docker-engine-as-my-container-runtime). (Remember, you can switch away from the dockershim if you're using any supported Kubernetes release; from release v1.24, you -**must** switch as Kubernetes no longer incluides the dockershim). +**must** switch as Kubernetes no longer includes the dockershim). [kubelet]: /docs/reference/command-line-tools-reference/kubelet/ diff --git a/content/en/docs/concepts/cluster-administration/flow-control.md b/content/en/docs/concepts/cluster-administration/flow-control.md index 40af92cd5b..ccf1eb5887 100644 --- a/content/en/docs/concepts/cluster-administration/flow-control.md +++ b/content/en/docs/concepts/cluster-administration/flow-control.md @@ -471,11 +471,15 @@ poorly-behaved workloads that may be harming system health. requests, broken down by the labels `phase` (which takes on the values `waiting` and `executing`) and `request_kind` (which takes on the values `mutating` and `readOnly`). The observations are made - periodically at a high rate. + periodically at a high rate. Each observed value is a ratio, + between 0 and 1, of a number of requests divided by the + corresponding limit on the number of requests (queue length limit + for waiting and concurrency limit for executing). * `apiserver_flowcontrol_read_vs_write_request_count_watermarks` is a histogram vector of high or low water marks of the number of - requests broken down by the labels `phase` (which takes on the + requests (divided by the corresponding limit to get a ratio in the + range 0 to 1) broken down by the labels `phase` (which takes on the values `waiting` and `executing`) and `request_kind` (which takes on the values `mutating` and `readOnly`); the label `mark` takes on values `high` and `low`. The water marks are accumulated over @@ -502,11 +506,15 @@ poorly-behaved workloads that may be harming system health. values `waiting` and `executing`) and `priority_level`. Each histogram gets observations taken periodically, up through the last activity of the relevant sort. The observations are made at a high - rate. + rate. Each observed value is a ratio, between 0 and 1, of a number + of requests divided by the corresponding limit on the number of + requests (queue length limit for waiting and concurrency limit for + executing). * `apiserver_flowcontrol_priority_level_request_count_watermarks` is a histogram vector of high or low water marks of the number of - requests broken down by the labels `phase` (which takes on the + requests (divided by the corresponding limit to get a ratio in the + range 0 to 1) broken down by the labels `phase` (which takes on the values `waiting` and `executing`) and `priority_level`; the label `mark` takes on values `high` and `low`. The water marks are accumulated over windows bounded by the times when an observation @@ -514,6 +522,31 @@ poorly-behaved workloads that may be harming system health. `apiserver_flowcontrol_priority_level_request_count_samples`. These water marks show the range of values that occurred between samples. +* `apiserver_flowcontrol_priority_level_seat_count_samples` is a + histogram vector of observations of the utilization of a priority + level's concurrency limit, broken down by `priority_level`. This + utilization is the fraction (number of seats occupied) / + (concurrency limit). This metric considers all stages of execution + (both normal and the extra delay at the end of a write to cover for + the corresponding notification work) of all requests except WATCHes; + for those it considers only the initial stage that delivers + notifications of pre-existing objects. Each histogram in the vector + is also labeled with `phase: executing` (there is no seat limit for + the waiting phase). Each histogram gets observations taken + periodically, up through the last activity of the relevant sort. + The observations + are made at a high rate. + +* `apiserver_flowcontrol_priority_level_seat_count_watermarks` is a + histogram vector of high or low water marks of the utilization of a + priority level's concurrency limit, broken down by `priority_level` + and `mark` (which takes on values `high` and `low`). Each histogram + in the vector is also labeled with `phase: executing` (there is no + seat limit for the waiting phase). The water marks are accumulated + over windows bounded by the times when an observation was added to + `apiserver_flowcontrol_priority_level_seat_count_samples`. These + water marks show the range of values that occurred between samples. + * `apiserver_flowcontrol_request_queue_length_after_enqueue` is a histogram vector of queue lengths for the queues, broken down by the labels `priority_level` and `flow_schema`, as sampled by the @@ -556,6 +589,22 @@ poorly-behaved workloads that may be harming system health. and `priority_level` (indicating the one to which the request was assigned). +* `apiserver_flowcontrol_watch_count_samples` is a histogram vector of + the number of active WATCH requests relevant to a given write, + broken down by `flow_schema` and `priority_level`. + +* `apiserver_flowcontrol_work_estimated_seats` is a histogram vector + of the number of estimated seats (maximum of initial and final stage + of execution) associated with requests, broken down by `flow_schema` + and `priority_level`. + +* `apiserver_flowcontrol_request_dispatch_no_accommodation_total` is a + counter vec of the number of events that in principle could have led + to a request being dispatched but did not, due to lack of available + concurrency, broken down by `flow_schema` and `priority_level`. The + relevant sorts of events are arrival of a request and completion of + a request. + ### Debug endpoints When you enable the API Priority and Fairness feature, the `kube-apiserver` diff --git a/content/en/docs/concepts/configuration/manage-resources-containers.md b/content/en/docs/concepts/configuration/manage-resources-containers.md index 2cb2ee1b7f..538372b2f4 100644 --- a/content/en/docs/concepts/configuration/manage-resources-containers.md +++ b/content/en/docs/concepts/configuration/manage-resources-containers.md @@ -799,7 +799,7 @@ memory limit (and possibly request) for that container. * Get hands-on experience [assigning Memory resources to containers and Pods](/docs/tasks/configure-pod-container/assign-memory-resource/). * Get hands-on experience [assigning CPU resources to containers and Pods](/docs/tasks/configure-pod-container/assign-cpu-resource/). * Read how the API reference defines a [container](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container) - and its [resource requirements](https://kubernetes.io/docs/reference/kubernetes-api/workload-resources/pod-v1/#resources) + and its [resource requirements](/docs/reference/kubernetes-api/workload-resources/pod-v1/#resources) * Read about [project quotas](https://xfs.org/index.php/XFS_FAQ#Q:_Quota:_Do_quotas_work_on_XFS.3F) in XFS * Read more about the [kube-scheduler configuration reference (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) diff --git a/content/en/docs/concepts/extend-kubernetes/_index.md b/content/en/docs/concepts/extend-kubernetes/_index.md index c50010a39f..5404f8c463 100644 --- a/content/en/docs/concepts/extend-kubernetes/_index.md +++ b/content/en/docs/concepts/extend-kubernetes/_index.md @@ -17,26 +17,29 @@ no_list: true -Kubernetes is highly configurable and extensible. As a result, -there is rarely a need to fork or submit patches to the Kubernetes -project code. +Kubernetes is highly configurable and extensible. As a result, there is rarely a need to fork or +submit patches to the Kubernetes project code. -This guide describes the options for customizing a Kubernetes -cluster. It is aimed at {{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}} who want to -understand how to adapt their Kubernetes cluster to the needs of -their work environment. Developers who are prospective {{< glossary_tooltip text="Platform Developers" term_id="platform-developer" >}} or Kubernetes Project {{< glossary_tooltip text="Contributors" term_id="contributor" >}} will also find it -useful as an introduction to what extension points and patterns -exist, and their trade-offs and limitations. +This guide describes the options for customizing a Kubernetes cluster. It is aimed at +{{< glossary_tooltip text="cluster operators" term_id="cluster-operator" >}} who want to understand +how to adapt their Kubernetes cluster to the needs of their work environment. Developers who are +prospective {{< glossary_tooltip text="Platform Developers" term_id="platform-developer" >}} or +Kubernetes Project {{< glossary_tooltip text="Contributors" term_id="contributor" >}} will also +find it useful as an introduction to what extension points and patterns exist, and their +trade-offs and limitations. ## Overview -Customization approaches can be broadly divided into *configuration*, which only involves changing flags, local configuration files, or API resources; and *extensions*, which involve running additional programs or services. This document is primarily about extensions. +Customization approaches can be broadly divided into *configuration*, which only involves changing +flags, local configuration files, or API resources; and *extensions*, which involve running +additional programs or services. This document is primarily about extensions. ## Configuration -*Configuration files* and *flags* are documented in the Reference section of the online documentation, under each binary: +*Configuration files* and *flags* are documented in the Reference section of the online +documentation, under each binary: * [kubelet](/docs/reference/command-line-tools-reference/kubelet/) * [kube-proxy](/docs/reference/command-line-tools-reference/kube-proxy/) @@ -44,9 +47,22 @@ Customization approaches can be broadly divided into *configuration*, which only * [kube-controller-manager](/docs/reference/command-line-tools-reference/kube-controller-manager/) * [kube-scheduler](/docs/reference/command-line-tools-reference/kube-scheduler/). -Flags and configuration files may not always be changeable in a hosted Kubernetes service or a distribution with managed installation. When they are changeable, they are usually only changeable by the cluster administrator. Also, they are subject to change in future Kubernetes versions, and setting them may require restarting processes. For those reasons, they should be used only when there are no other options. +Flags and configuration files may not always be changeable in a hosted Kubernetes service or a +distribution with managed installation. When they are changeable, they are usually only changeable +by the cluster administrator. Also, they are subject to change in future Kubernetes versions, and +setting them may require restarting processes. For those reasons, they should be used only when +there are no other options. -*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), [PodSecurityPolicies](/docs/concepts/security/pod-security-policy/), [NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control ([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. They are declarative and use the same conventions as other Kubernetes resources like pods, so new cluster configuration can be repeatable and be managed the same way as applications. And, where they are stable, they enjoy a [defined support policy](/docs/reference/using-api/deprecation-policy/) like other Kubernetes APIs. For these reasons, they are preferred over *configuration files* and *flags* where suitable. +*Built-in Policy APIs*, such as [ResourceQuota](/docs/concepts/policy/resource-quotas/), +[PodSecurityPolicies](/docs/concepts/security/pod-security-policy/), +[NetworkPolicy](/docs/concepts/services-networking/network-policies/) and Role-based Access Control +([RBAC](/docs/reference/access-authn-authz/rbac/)), are built-in Kubernetes APIs. +APIs are typically used with hosted Kubernetes services and with managed Kubernetes installations. +They are declarative and use the same conventions as other Kubernetes resources like pods, +so new cluster configuration can be repeatable and be managed the same way as applications. +And, where they are stable, they enjoy a +[defined support policy](/docs/reference/using-api/deprecation-policy/) like other Kubernetes APIs. +For these reasons, they are preferred over *configuration files* and *flags* where suitable. ## Extensions @@ -70,10 +86,9 @@ There is a specific pattern for writing client programs that work well with Kubernetes called the *Controller* pattern. Controllers typically read an object's `.spec`, possibly do things, and then update the object's `.status`. -A controller is a client of Kubernetes. When Kubernetes is the client and -calls out to a remote service, it is called a *Webhook*. The remote service -is called a *Webhook Backend*. Like Controllers, Webhooks do add a point of -failure. +A controller is a client of Kubernetes. When Kubernetes is the client and calls out to a remote +service, it is called a *Webhook*. The remote service is called a *Webhook Backend*. Like +Controllers, Webhooks do add a point of failure. In the webhook model, Kubernetes makes a network request to a remote service. In the *Binary Plugin* model, Kubernetes executes a binary (program). @@ -95,15 +110,35 @@ This diagram shows the extension points in a Kubernetes system. ![Extension Points](/docs/concepts/extend-kubernetes/extension-points.png) -1. Users often interact with the Kubernetes API using `kubectl`. [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. They only affect the individual user's local environment, and so cannot enforce site-wide policies. -2. The apiserver handles all requests. Several types of extension points in the apiserver allow authenticating requests, or blocking them based on their content, editing content, and handling deletion. These are described in the [API Access Extensions](#api-access-extensions) section. -3. The apiserver serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are defined by the Kubernetes project and can't be changed. You can also add resources that you define, or that other projects have defined, called *Custom Resources*, as explained in the [Custom Resources](#user-defined-types) section. Custom Resources are often used with API Access Extensions. -4. The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend scheduling. These are described in the [Scheduler Extensions](#scheduler-extensions) section. -5. Much of the behavior of Kubernetes is implemented by programs called Controllers which are clients of the API-Server. Controllers are often used in conjunction with Custom Resources. -6. The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on the cluster network. [Network Plugins](#network-plugins) allow for different implementations of pod networking. -7. The kubelet also mounts and unmounts volumes for containers. New types of storage can be supported via [Storage Plugins](#storage-plugins). +1. Users often interact with the Kubernetes API using `kubectl`. + [Kubectl plugins](/docs/tasks/extend-kubectl/kubectl-plugins/) extend the kubectl binary. + They only affect the individual user's local environment, and so cannot enforce site-wide policies. -If you are unsure where to start, this flowchart can help. Note that some solutions may involve several types of extensions. +1. The API server handles all requests. Several types of extension points in the API server allow + authenticating requests, or blocking them based on their content, editing content, and handling + deletion. These are described in the [API Access Extensions](#api-access-extensions) section. + +1. The API server serves various kinds of *resources*. *Built-in resource kinds*, like `pods`, are + defined by the Kubernetes project and can't be changed. You can also add resources that you + define, or that other projects have defined, called *Custom Resources*, as explained in the + [Custom Resources](#user-defined-types) section. Custom Resources are often used with API access + extensions. + +1. The Kubernetes scheduler decides which nodes to place pods on. There are several ways to extend + scheduling. These are described in the [Scheduler Extensions](#scheduler-extensions) section. + +1. Much of the behavior of Kubernetes is implemented by programs called Controllers which are + clients of the API server. Controllers are often used in conjunction with Custom Resources. + +1. The kubelet runs on servers, and helps pods appear like virtual servers with their own IPs on + the cluster network. [Network Plugins](#network-plugins) allow for different implementations of + pod networking. + +1. The kubelet also mounts and unmounts volumes for containers. New types of storage can be + supported via [Storage Plugins](#storage-plugins). + +If you are unsure where to start, this flowchart can help. Note that some solutions may involve +several types of extensions. ![Flowchart for Extension](/docs/concepts/extend-kubernetes/flowchart.png) @@ -112,60 +147,86 @@ If you are unsure where to start, this flowchart can help. Note that some soluti ### User-Defined Types -Consider adding a Custom Resource to Kubernetes if you want to define new controllers, application configuration objects or other declarative APIs, and to manage them using Kubernetes tools, such as `kubectl`. +Consider adding a Custom Resource to Kubernetes if you want to define new controllers, application +configuration objects or other declarative APIs, and to manage them using Kubernetes tools, such +as `kubectl`. Do not use a Custom Resource as data storage for application, user, or monitoring data. -For more about Custom Resources, see the [Custom Resources concept guide](/docs/concepts/extend-kubernetes/api-extension/custom-resources/). +For more about Custom Resources, see the +[Custom Resources concept guide](/docs/concepts/extend-kubernetes/api-extension/custom-resources/). ### Combining New APIs with Automation -The combination of a custom resource API and a control loop is called the [Operator pattern](/docs/concepts/extend-kubernetes/operator/). The Operator pattern is used to manage specific, usually stateful, applications. These custom APIs and control loops can also be used to control other resources, such as storage or policies. +The combination of a custom resource API and a control loop is called the +[Operator pattern](/docs/concepts/extend-kubernetes/operator/). The Operator pattern is used to manage +specific, usually stateful, applications. These custom APIs and control loops can also be used to +control other resources, such as storage or policies. ### Changing Built-in Resources -When you extend the Kubernetes API by adding custom resources, the added resources always fall into a new API Groups. You cannot replace or change existing API groups. -Adding an API does not directly let you affect the behavior of existing APIs (e.g. Pods), but API Access Extensions do. +When you extend the Kubernetes API by adding custom resources, the added resources always fall +into a new API Groups. You cannot replace or change existing API groups. +Adding an API does not directly let you affect the behavior of existing APIs (e.g. Pods), but API +Access Extensions do. ### API Access Extensions -When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then subject to various types of Admission Control. See [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access/) for more on this flow. +When a request reaches the Kubernetes API Server, it is first Authenticated, then Authorized, then +subject to various types of Admission Control. See +[Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access/) +for more on this flow. Each of these steps offers extension points. -Kubernetes has several built-in authentication methods that it supports. It can also sit behind an authenticating proxy, and it can send a token from an Authorization header to a remote service for verification (a webhook). All of these methods are covered in the [Authentication documentation](/docs/reference/access-authn-authz/authentication/). +Kubernetes has several built-in authentication methods that it supports. It can also sit behind an +authenticating proxy, and it can send a token from an Authorization header to a remote service for +verification (a webhook). All of these methods are covered in the +[Authentication documentation](/docs/reference/access-authn-authz/authentication/). ### Authentication -[Authentication](/docs/reference/access-authn-authz/authentication/) maps headers or certificates in all requests to a username for the client making the request. - -Kubernetes provides several built-in authentication methods, and an [Authentication webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) method if those don't meet your needs. +[Authentication](/docs/reference/access-authn-authz/authentication/) maps headers or certificates +in all requests to a username for the client making the request. +Kubernetes provides several built-in authentication methods, and an +[Authentication webhook](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) +method if those don't meet your needs. ### Authorization -[Authorization](/docs/reference/access-authn-authz/authorization/) determines whether specific users can read, write, and do other operations on API resources. It works at the level of whole resources -- it doesn't discriminate based on arbitrary object fields. If the built-in authorization options don't meet your needs, [Authorization webhook](/docs/reference/access-authn-authz/webhook/) allows calling out to user-provided code to make an authorization decision. - +[Authorization](/docs/reference/access-authn-authz/authorization/) determines whether specific +users can read, write, and do other operations on API resources. It works at the level of whole +resources -- it doesn't discriminate based on arbitrary object fields. If the built-in +authorization options don't meet your needs, [Authorization webhook](/docs/reference/access-authn-authz/webhook/) +allows calling out to user-provided code to make an authorization decision. ### Dynamic Admission Control -After a request is authorized, if it is a write operation, it also goes through [Admission Control](/docs/reference/access-authn-authz/admission-controllers/) steps. In addition to the built-in steps, there are several extensions: +After a request is authorized, if it is a write operation, it also goes through +[Admission Control](/docs/reference/access-authn-authz/admission-controllers/) steps. +In addition to the built-in steps, there are several extensions: -* The [Image Policy webhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) restricts what images can be run in containers. -* To make arbitrary admission control decisions, a general [Admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) can be used. Admission Webhooks can reject creations or updates. +* The [Image Policy webhook](/docs/reference/access-authn-authz/admission-controllers/#imagepolicywebhook) + restricts what images can be run in containers. +* To make arbitrary admission control decisions, a general + [Admission webhook](/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) + can be used. Admission Webhooks can reject creations or updates. ## Infrastructure Extensions ### Storage Plugins -[Flex Volumes](https://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. - -FlexVolume is deprecated since Kubernetes v1.23. The Out-of-tree CSI driver is the recommended way to write volume drivers in Kubernetes. See [Kubernetes Volume Plugin FAQ for Storage Vendors](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors) for more information. +[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. +FlexVolume is deprecated since Kubernetes v1.23. The out-of-tree CSI driver is the recommended way +to write volume drivers in Kubernetes. See +[Kubernetes Volume Plugin FAQ for Storage Vendors](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md#kubernetes-volume-plugin-faq-for-storage-vendors) +for more information. ### Device Plugins @@ -173,7 +234,6 @@ Device plugins allow a node to discover new Node resources (in addition to the builtin ones like cpu and memory) via a [Device Plugin](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/). - ### Network Plugins Different networking fabrics can be supported via node-level diff --git a/content/en/docs/concepts/extend-kubernetes/service-catalog.md b/content/en/docs/concepts/extend-kubernetes/service-catalog.md deleted file mode 100644 index 8c8b1aa238..0000000000 --- a/content/en/docs/concepts/extend-kubernetes/service-catalog.md +++ /dev/null @@ -1,237 +0,0 @@ ---- -title: Service Catalog -reviewers: -- chenopis -content_type: concept -weight: 40 ---- - - -{{< glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" >}} - -A service broker, as defined by the [Open service broker API spec](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md), is an endpoint for a set of managed services offered and maintained by a third-party, which could be a cloud provider such as AWS, GCP, or Azure. -Some examples of managed services are Microsoft Azure Cloud Queue, Amazon Simple Queue Service, and Google Cloud Pub/Sub, but they can be any software offering that can be used by an application. - -Using Service Catalog, a {{< glossary_tooltip text="cluster operator" term_id="cluster-operator" >}} can browse the list of managed services offered by a service broker, provision an instance of a managed service, and bind with it to make it available to an application in the Kubernetes cluster. - - - - - -## Example use case - -An {{< glossary_tooltip text="application developer" term_id="application-developer" >}} wants to use message queuing as part of their application running in a Kubernetes cluster. -However, they do not want to deal with the overhead of setting such a service up and administering it themselves. -Fortunately, there is a cloud provider that offers message queuing as a managed service through its service broker. - -A cluster operator can setup Service Catalog and use it to communicate with the cloud provider's service broker to provision an instance of the message queuing service and make it available to the application within the Kubernetes cluster. -The application developer therefore does not need to be concerned with the implementation details or management of the message queue. -The application can access the message queue as a service. - -## Architecture - -Service Catalog uses the [Open service broker API](https://github.com/openservicebrokerapi/servicebroker) to communicate with service brokers, acting as an intermediary for the Kubernetes API Server to negotiate the initial provisioning and retrieve the credentials necessary for the application to use a managed service. - -It is implemented using a [CRDs-based](/docs/concepts/extend-kubernetes/api-extension/custom-resources/#custom-resources) architecture. - -
- -![Service Catalog Architecture](/images/docs/service-catalog-architecture.svg) - - -### API Resources - -Service Catalog installs the `servicecatalog.k8s.io` API and provides the following Kubernetes resources: - -* `ClusterServiceBroker`: An in-cluster representation of a service broker, encapsulating its server connection details. -These are created and managed by cluster operators who wish to use that broker server to make new types of managed services available within their cluster. -* `ClusterServiceClass`: A managed service offered by a particular service broker. -When a new `ClusterServiceBroker` resource is added to the cluster, the Service Catalog controller connects to the service broker to obtain a list of available managed services. It then creates a new `ClusterServiceClass` resource corresponding to each managed service. -* `ClusterServicePlan`: A specific offering of a managed service. For example, a managed service may have different plans available, such as a free tier or paid tier, or it may have different configuration options, such as using SSD storage or having more resources. Similar to `ClusterServiceClass`, when a new `ClusterServiceBroker` is added to the cluster, Service Catalog creates a new `ClusterServicePlan` resource corresponding to each Service Plan available for each managed service. -* `ServiceInstance`: A provisioned instance of a `ClusterServiceClass`. -These are created by cluster operators to make a specific instance of a managed service available for use by one or more in-cluster applications. -When a new `ServiceInstance` resource is created, the Service Catalog controller connects to the appropriate service broker and instruct it to provision the service instance. -* `ServiceBinding`: Access credentials to a `ServiceInstance`. -These are created by cluster operators who want their applications to make use of a `ServiceInstance`. -Upon creation, the Service Catalog controller creates a Kubernetes `Secret` containing connection details and credentials for the Service Instance, which can be mounted into Pods. - -### Authentication - -Service Catalog supports these methods of authentication: - -* Basic (username/password) -* [OAuth 2.0 Bearer Token](https://tools.ietf.org/html/rfc6750) - -## Usage - -A cluster operator can use Service Catalog API Resources to provision managed services and make them available within a Kubernetes cluster. The steps involved are: - -1. Listing the managed services and Service Plans available from a service broker. -1. Provisioning a new instance of the managed service. -1. Binding to the managed service, which returns the connection credentials. -1. Mapping the connection credentials into the application. - -### Listing managed services and Service Plans - -First, a cluster operator must create a `ClusterServiceBroker` resource within the `servicecatalog.k8s.io` group. This resource contains the URL and connection details necessary to access a service broker endpoint. - -This is an example of a `ClusterServiceBroker` resource: - -```yaml -apiVersion: servicecatalog.k8s.io/v1beta1 -kind: ClusterServiceBroker -metadata: - name: cloud-broker -spec: - # Points to the endpoint of a service broker. (This example is not a working URL.) - url: https://servicebroker.somecloudprovider.com/v1alpha1/projects/service-catalog/brokers/default - ##### - # Additional values can be added here, which may be used to communicate - # with the service broker, such as bearer token info or a caBundle for TLS. - ##### -``` - -The following is a sequence diagram illustrating the steps involved in listing managed services and Plans available from a service broker: - -![List Services](/images/docs/service-catalog-list.svg) - -1. Once the `ClusterServiceBroker` resource is added to Service Catalog, it triggers a call to the external service broker for a list of available services. -1. The service broker returns a list of available managed services and a list of Service Plans, which are cached locally as `ClusterServiceClass` and `ClusterServicePlan` resources respectively. -1. A cluster operator can then get the list of available managed services using the following command: - - kubectl get clusterserviceclasses -o=custom-columns=SERVICE\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName - - It should output a list of service names with a format similar to: - - SERVICE NAME EXTERNAL NAME - 4f6e6cf6-ffdd-425f-a2c7-3c9258ad2468 cloud-provider-service - ... ... - - They can also view the Service Plans available using the following command: - - kubectl get clusterserviceplans -o=custom-columns=PLAN\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName - - It should output a list of plan names with a format similar to: - - PLAN NAME EXTERNAL NAME - 86064792-7ea2-467b-af93-ac9694d96d52 service-plan-name - ... ... - - -### Provisioning a new instance - -A cluster operator can initiate the provisioning of a new instance by creating a `ServiceInstance` resource. - -This is an example of a `ServiceInstance` resource: - -```yaml -apiVersion: servicecatalog.k8s.io/v1beta1 -kind: ServiceInstance -metadata: - name: cloud-queue-instance - namespace: cloud-apps -spec: - # References one of the previously returned services - clusterServiceClassExternalName: cloud-provider-service - clusterServicePlanExternalName: service-plan-name - ##### - # Additional parameters can be added here, - # which may be used by the service broker. - ##### -``` - -The following sequence diagram illustrates the steps involved in provisioning a new instance of a managed service: - -![Provision a Service](/images/docs/service-catalog-provision.svg) - -1. When the `ServiceInstance` resource is created, Service Catalog initiates a call to the external service broker to provision an instance of the service. -1. The service broker creates a new instance of the managed service and returns an HTTP response. -1. A cluster operator can then check the status of the instance to see if it is ready. - -### Binding to a managed service - -After a new instance has been provisioned, a cluster operator must bind to the managed service to get the connection credentials and service account details necessary for the application to use the service. This is done by creating a `ServiceBinding` resource. - -The following is an example of a `ServiceBinding` resource: - -```yaml -apiVersion: servicecatalog.k8s.io/v1beta1 -kind: ServiceBinding -metadata: - name: cloud-queue-binding - namespace: cloud-apps -spec: - instanceRef: - name: cloud-queue-instance - ##### - # Additional information can be added here, such as a secretName or - # service account parameters, which may be used by the service broker. - ##### -``` - -The following sequence diagram illustrates the steps involved in binding to a managed service instance: - -![Bind to a managed service](/images/docs/service-catalog-bind.svg) - -1. After the `ServiceBinding` is created, Service Catalog makes a call to the external service broker requesting the information necessary to bind with the service instance. -1. The service broker enables the application permissions/roles for the appropriate service account. -1. The service broker returns the information necessary to connect and access the managed service instance. This is provider and service-specific so the information returned may differ between Service Providers and their managed services. - -### Mapping the connection credentials - -After binding, the final step involves mapping the connection credentials and service-specific information into the application. -These pieces of information are stored in secrets that the application in the cluster can access and use to connect directly with the managed service. - -
- -![Map connection credentials](/images/docs/service-catalog-map.svg) - -#### Pod configuration File - -One method to perform this mapping is to use a declarative Pod configuration. - -The following example describes how to map service account credentials into the application. A key called `sa-key` is stored in a volume named `provider-cloud-key`, and the application mounts this volume at `/var/secrets/provider/key.json`. The environment variable `PROVIDER_APPLICATION_CREDENTIALS` is mapped from the value of the mounted file. - -```yaml -... - spec: - volumes: - - name: provider-cloud-key - secret: - secretName: sa-key - containers: -... - volumeMounts: - - name: provider-cloud-key - mountPath: /var/secrets/provider - env: - - name: PROVIDER_APPLICATION_CREDENTIALS - value: "/var/secrets/provider/key.json" -``` - -The following example describes how to map secret values into application environment variables. In this example, the messaging queue topic name is mapped from a secret named `provider-queue-credentials` with a key named `topic` to the environment variable `TOPIC`. - - -```yaml -... - env: - - name: "TOPIC" - valueFrom: - secretKeyRef: - name: provider-queue-credentials - key: topic -``` - - - - -## {{% heading "whatsnext" %}} - -* If you are familiar with {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}, [install Service Catalog using Helm](/docs/tasks/service-catalog/install-service-catalog-using-helm/) into your Kubernetes cluster. Alternatively, you can [install Service Catalog using the SC tool](/docs/tasks/service-catalog/install-service-catalog-using-sc/). -* View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers). -* Explore the [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) project. - - - - - diff --git a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md index bcfd32ef7d..ee83692419 100644 --- a/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/en/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -81,7 +81,7 @@ 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 -The precise format of the object `spec` is different for every Kubernetes object, and contains nested fields specific to that object. The [Kubernetes API Reference](https://kubernetes.io/docs/reference/kubernetes-api/) can help you find the spec format for all of the objects you can create using Kubernetes. +The precise format of the object `spec` is different for every Kubernetes object, and contains nested fields specific to that object. The [Kubernetes API Reference](/docs/reference/kubernetes-api/) can help you find the spec format for all of the objects you can create using Kubernetes. For example, see the [`spec` field](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodSpec) for the Pod API reference. 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 8d3cc1831c..db9f1d900d 100644 --- a/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/en/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -124,8 +124,8 @@ For example, consider the following Pod spec: In this example, the following rules apply: - * The node *must* have a label with the key `kubernetes.io/os` and - the value `linux`. + * The node *must* have a label with the key `topology.kubernetes.io/zone` and + the value of that label *must* be either `antarctica-east1` or `antarctica-west1`. * The node *preferably* has a label with the key `another-node-label-key` and the value `another-node-label-value`. diff --git a/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md index ff7718a1f3..4bb3471745 100644 --- a/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/en/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -15,7 +15,7 @@ is a property of {{< glossary_tooltip text="Pods" term_id="pod" >}} that *attrac a set of {{< glossary_tooltip text="nodes" term_id="node" >}} (either as a preference or a hard requirement). _Taints_ are the opposite -- they allow a node to repel a set of pods. -_Tolerations_ are applied to pods. Tolerations allow the scheduler to schedule pods with matching taints. Tolerations allow scheduling but don't guarantee scheduling: the scheduler also [evaluates other parameters](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/) as part of its function. +_Tolerations_ are applied to pods. Tolerations allow the scheduler to schedule pods with matching taints. Tolerations allow scheduling but don't guarantee scheduling: the scheduler also [evaluates other parameters](/docs/concepts/scheduling-eviction/pod-priority-preemption/) as part of its function. Taints and tolerations work together to ensure that pods are not scheduled onto inappropriate nodes. One or more taints are applied to a node; this diff --git a/content/en/docs/concepts/security/controlling-access.md b/content/en/docs/concepts/security/controlling-access.md index e7ba78e1c4..04b13a82c5 100644 --- a/content/en/docs/concepts/security/controlling-access.md +++ b/content/en/docs/concepts/security/controlling-access.md @@ -4,6 +4,7 @@ reviewers: - lavalamp title: Controlling Access to the Kubernetes API content_type: concept +weight: 50 --- diff --git a/content/en/docs/concepts/security/multi-tenancy.md b/content/en/docs/concepts/security/multi-tenancy.md new file mode 100755 index 0000000000..f68b25dae3 --- /dev/null +++ b/content/en/docs/concepts/security/multi-tenancy.md @@ -0,0 +1,271 @@ +--- +title: Multi-tenancy +content_type: concept +weight: 70 +--- + + + +This page provides an overview of available configuration options and best practices for cluster multi-tenancy. + +Sharing clusters saves costs and simplifies administration. However, sharing clusters also presents challenges such as security, fairness, and managing _noisy neighbors_. + +Clusters can be shared in many ways. In some cases, different applications may run in the same cluster. In other cases, multiple instances of the same application may run in the same cluster, one for each end user. All these types of sharing are frequently described using the umbrella term _multi-tenancy_. + +While Kubernetes does not have first-class concepts of end users or tenants, it provides several features to help manage different tenancy requirements. These are discussed below. + + +## Use cases + +The first step to determining how to share your cluster is understanding your use case, so you can evaluate the patterns and tools available. In general, multi-tenancy in Kubernetes clusters falls into two broad categories, though many variations and hybrids are also possible. + +### Multiple teams + +A common form of multi-tenancy is to share a cluster between multiple teams within an organization, each of whom may operate one or more workloads. These workloads frequently need to communicate with each other, and with other workloads located on the same or different clusters. + +In this scenario, members of the teams often have direct access to Kubernetes resources via tools such as `kubectl`, or indirect access through GitOps controllers or other types of release automation tools. There is often some level of trust between members of different teams, but Kubernetes policies such as RBAC, quotas, and network policies are essential to safely and fairly share clusters. + +### Multiple customers + +The other major form of multi-tenancy frequently involves a Software-as-a-Service (SaaS) vendor running multiple instances of a workload for customers. This business model is so strongly associated with this deployment style that many people call it "SaaS tenancy." However, a better term might be "multi-customer tenancy,” since SaaS vendors may also use other deployment models, and this deployment model can also be used outside of SaaS. + + +In this scenario, the customers do not have access to the cluster; Kubernetes is invisible from their perspective and is only used by the vendor to manage the workloads. Cost optimization is frequently a critical concern, and Kubernetes policies are used to ensure that the workloads are strongly isolated from each other. + + +## Terminology + +### Tenants + +When discussing multi-tenancy in Kubernetes, there is no single definition for a "tenant". Rather, the definition of a tenant will vary depending on whether multi-team or multi-customer tenancy is being discussed. + +In multi-team usage, a tenant is typically a team, where each team typically deploys a small number of workloads that scales with the complexity of the service. However, the definition of "team" may itself be fuzzy, as teams may be organized into higher-level divisions or subdivided into smaller teams. + + +By contrast, if each team deploys dedicated workloads for each new client, they are using a multi-customer model of tenancy. In this case, a "tenant" is simply a group of users who share a single workload. This may be as large as an entire company, or as small as a single team at that company. + +In many cases, the same organization may use both definitions of "tenants" in different contexts. For example, a platform team may offer shared services such as security tools and databases to multiple internal “customers” and a SaaS vendor may also have multiple teams sharing a development cluster. Finally, hybrid architectures are also possible, such as a SaaS provider using a combination of per-customer workloads for sensitive data, combined with multi-tenant shared services. + + +{{< figure src="/images/docs/multi-tenancy.png" title="A cluster showing coexisting tenancy models" class="diagram-large" >}} + + +### Isolation + +There are several ways to design and build multi-tenant solutions with Kubernetes. Each of these methods comes with its own set of tradeoffs that impact the isolation level, implementation effort, operational complexity, and cost of service. + + +A Kubernetes cluster consists of a control plane which runs Kubernetes software, and a data plane consisting of worker nodes where tenant workloads are executed as pods. Tenant isolation can be applied in both the control plane and the data plane based on organizational requirements. + +The level of isolation offered is sometimes described using terms like “hard” multi-tenancy, which implies strong isolation, and “soft” multi-tenancy, which implies weaker isolation. In particular, "hard" multi-tenancy is often used to describe cases where the tenants do not trust each other, often from security and resource sharing perspectives (e.g. guarding against attacks such as data exfiltration or DoS). Since data planes typically have much larger attack surfaces, "hard" multi-tenancy often requires extra attention to isolating the data-plane, though control plane isolation also remains critical. + +However, the terms "hard" and "soft" can often be confusing, as there is no single definition that will apply to all users. Rather, "hardness" or "softness" is better understood as a broad spectrum, with many different techniques that can be used to maintain different types of isolation in your clusters, based on your requirements. + + +In more extreme cases, it may be easier or necessary to forgo any cluster-level sharing at all and assign each tenant their dedicated cluster, possibly even running on dedicated hardware if VMs are not considered an adequate security boundary. This may be easier with managed Kubernetes clusters, where the overhead of creating and operating clusters is at least somewhat taken on by a cloud provider. The benefit of stronger tenant isolation must be evaluated against the cost and complexity of managing multiple clusters. The [Multi-cluster SIG](https://git.k8s.io/community/sig-multicluster/README.md) is responsible for addressing these types of use cases. + + + +The remainder of this page focuses on isolation techniques used for shared Kubernetes clusters. However, even if you are considering dedicated clusters, it may be valuable to review these recommendations, as it will give you the flexibility to shift to shared clusters in the future if your needs or capabilities change. + + +## Control plane isolation + +Control plane isolation ensures that different tenants cannot access or affect each others' Kubernetes API resources. + +### Namespaces + +In Kubernetes, a {{< glossary_tooltip text="Namespace" term_id="namespace" >}} provides a mechanism for isolating groups of API resources within a single cluster. This isolation has two key dimensions: + +1. Object names within a namespace can overlap with names in other namespaces, similar to files in folders. This allows tenants to name their resources without having to consider what other tenants are doing. + +2. Many Kubernetes security policies are scoped to namespaces. For example, RBAC Roles and Network Policies are namespace-scoped resources. Using RBAC, Users and Service Accounts can be restricted to a namespace. + +In a multi-tenant environment, a Namespace helps segment a tenant's workload into a logical and distinct management unit. In fact, a common practice is to isolate every workload in its own namespace, even if multiple workloads are operated by the same tenant. This ensures that each workload has its own identity and can be configured with an appropriate security policy. + +The namespace isolation model requires configuration of several other Kubernetes resources, networking plugins, and adherence to security best practices to properly isolate tenant workloads. These considerations are discussed below. + +### Access controls + +The most important type of isolation for the control plane is authorization. If teams or their workloads can access or modify each others' API resources, they can change or disable all other types of policies thereby negating any protection those policies may offer. As a result, it is critical to ensure that each tenant has the appropriate access to only the namespaces they need, and no more. This is known as the "Principle of Least Privilege." + + +Role-based access control (RBAC) is commonly used to enforce authorization in the Kubernetes control plane, for both users and workloads (service accounts). [Roles](/docs/reference/access-authn-authz/rbac/#role-and-clusterrole) and [role bindings](/docs/reference/access-authn-authz/rbac/#rolebinding-and-clusterrolebinding) are Kubernetes objects that are used at a namespace level to enforce access control in your application; similar objects exist for authorizing access to cluster-level objects, though these are less useful for multi-tenant clusters. + +In a multi-team environment, RBAC must be used to restrict tenants' access to the appropriate namespaces, and ensure that cluster-wide resources can only be accessed or modified by privileged users such as cluster administrators. + +If a policy ends up granting a user more permissions than they need, this is likely a signal that the namespace containing the affected resources should be refactored into finer-grained namespaces. Namespace management tools may simplify the management of these finer-grained namespaces by applying common RBAC policies to different namespaces, while still allowing fine-grained policies where necessary. + +### Quotas + +Kubernetes workloads consume node resources, like CPU and memory. In a multi-tenant environment, you can use +[Resource Quotas](/docs/concepts/policy/resource-quotas/) to manage resource usage of tenant workloads. +For the multiple teams use case, where tenants have access to the Kubernetes API, you can use resource quotas +to limit the number of API resources (for example: the number of Pods, or the number of ConfigMaps) +that a tenant can create. Limits on object count ensure fairness and aim to avoid _noisy neighbor_ issues from +affecting other tenants that share a control plane. + +Resource quotas are namespaced objects. By mapping tenants to namespaces, cluster admins can use quotas to ensure that a tenant cannot monopolize a cluster's resources or overwhelm its control plane. Namespace management tools simplify the administration of quotas. In addition, while Kubernetes quotas only apply within a single namespace, some namespace management tools allow groups of namespaces to share quotas, giving administrators far more flexibility with less effort than built-in quotas. + +Quotas prevent a single tenant from consuming greater than their allocated share of resources hence minimizing the “noisy neighbor” issue, where one tenant negatively impacts the performance of other tenants' workloads. + +When you apply a quota to namespace, Kubernetes requires you to also specify resource requests and limits for each container. Limits are the upper bound for the amount of resources that a container can consume. Containers that attempt to consume resources that exceed the configured limits will either be throttled or killed, based on the resource type. When resource requests are set lower than limits, each container is guaranteed the requested amount but there may still be some potential for impact across workloads. + +Quotas cannot protect against all kinds of resource sharing, such as network traffic. Node isolation (described below) may be a better solution for this problem. + +## Data Plane Isolation + +Data plane isolation ensures that pods and workloads for different tenants are sufficiently isolated. + +### Network isolation + +By default, all pods in a Kubernetes cluster are allowed to communicate with each other, and all network traffic is unencrypted. This can lead to security vulnerabilities where traffic is accidentally or maliciously sent to an unintended destination, or is intercepted by a workload on a compromised node. + +Pod-to-pod communication can be controlled using [Network Policies](/docs/concepts/services-networking/network-policies/), which restrict communication between pods using namespace labels or IP address ranges. In a multi-tenant environment where strict network isolation between tenants is required, starting with a default policy that denies communication between pods is recommended with another rule that allows all pods to query the DNS server for name resolution. With such a default policy in place, you can begin adding more permissive rules that allow for communication within a namespace. This scheme can be further refined as required. Note that this only applies to pods within a single control plane; pods that belong to different virtual control planes cannot talk to each other via Kubernetes networking. + +Namespace management tools may simplify the creation of default or common network policies. In addition, some of these tools allow you to enforce a consistent set of namespace labels across your cluster, ensuring that they are a trusted basis for your policies. + +{{< warning >}} +Network policies require a [CNI plugin](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni) that supports the implementation of network policies. Otherwise, NetworkPolicy resources will be ignored. +{{< /warning >}} + +More advanced network isolation may be provided by service meshes, which provide OSI Layer 7 policies based on workload identity, in addition to namespaces. These higher-level policies can make it easier to manage namespaced based multi-tenancy, especially when multiple namespaces are dedicated to a single tenant. They frequently also offer encryption using mutual TLS, protecting your data even in the presence of a compromised node, and work across dedicated or virtual clusters. However, they can be significantly more complex to manage and may not be appropriate for all users. + +### Storage isolation + +Kubernetes offers several types of volumes that can be used as persistent storage for workloads. For security and data-isolation, [dynamic volume provisioning](/docs/concepts/storage/dynamic-provisioning/) is recommended and volume types that use node resources should be avoided. + +[StorageClasses](/docs/concepts/storage/storage-classes/) allow you to describe custom "classes" of storage offered by your cluster, based on quality-of-service levels, backup policies, or custom policies determined by the cluster administrators. + +Pods can request storage using a [PersistentVolumeClaim](/docs/concepts/storage/persistent-volumes/). A PersistentVolumeClaim is a namespaced resource, which enables isolating portions of the storage system and dedicating it to tenants within the shared Kubernetes cluster. However, it is important to note that a PersistentVolume is a cluster-wide resource and has a lifecycle independent of workloads and namespaces. + +For example, you can configure a separate StorageClass for each tenant and use this to strengthen isolation. +If a StorageClass is shared, you should set a [reclaim policy of `Delete`](/docs/concepts/storage/storage-classes/#reclaim-policy) +to ensure that a PersistentVolume cannot be reused across different namespaces. + +### Sandboxing containers + +{{% thirdparty-content %}} + +Kubernetes pods are composed of one or more containers that execute on worker nodes. Containers utilize OS-level virtualization and hence offer a weaker isolation boundary than virtual machines that utilize hardware-based virtualization. + +In a shared environment, unpatched vulnerabilities in the application and system layers can be exploited by attackers for container breakouts and remote code execution that allow access to host resources. In some applications, like a Content Management System (CMS), customers may be allowed the ability to upload and execute untrusted scripts or code. In either case, mechanisms to further isolate and protect workloads using strong isolation are desirable. + +Sandboxing provides a way to isolate workloads running in a shared cluster. It typically involves running each pod in a separate execution environment such as a virtual machine or a userspace kernel. Sandboxing is often recommended when you are running untrusted code, where workloads are assumed to be malicious. Part of the reason this type of isolation is necessary is because containers are processes running on a shared kernel; they mount file systems like /sys and /proc from the underlying host, making them less secure than an application that runs on a virtual machine which has its own kernel. While controls such as seccomp, AppArmor, and SELinux can be used to strengthen the security of containers, it is hard to apply a universal set of rules to all workloads running in a shared cluster. Running workloads in a sandbox environment helps to insulate the host from container escapes, where an attacker exploits a vulnerability to gain access to the host system and all the processes/files running on that host. + +Virtual machines and userspace kernels are 2 popular approaches to sandboxing. The following sandboxing implementations are available: +* [gVisor](https://gvisor.dev/) intercepts syscalls from containers and runs them through a userspace kernel, written in Go, with limited access to the underlying host. +* [Kata Containers](https://katacontainers.io/) is an OCI compliant runtime that allows you to run containers in a VM. The hardware virtualization available in Kata offers an added layer of security for containers running untrusted code. + +### Node Isolation + +Node isolation is another technique that you can use to isolate tenant workloads from each other. With node isolation, a set of nodes is dedicated to running pods from a particular tenant and co-mingling of tenant pods is prohibited. This configuration reduces the noisy tenant issue, as all pods running on a node will belong to a single tenant. The risk of information disclosure is slightly lower with node isolation because an attacker that manages to escape from a container will only have access to the containers and volumes mounted to that node. + +Although workloads from different tenants are running on different nodes, it is important to be aware that the kubelet and (unless using virtual control planes) the API service are still shared services. A skilled attacker could use the permissions assigned to the kubelet or other pods running on the node to move laterally within the cluster and gain access to tenant workloads running on other nodes. If this is a major concern, consider implementing compensating controls such as seccomp, AppArmor or SELinux or explore using sandboxed containers or creating separate clusters for each tenant. + +Node isolation is a little easier to reason about from a billing standpoint than sandboxing containers since you can charge back per node rather than per pod. It also has fewer compatibility and performance issues and may be easier to implement than sandboxing containers. For example, nodes for each tenant can be configured with taints so that only pods with the corresponding toleration can run on them. A mutating webhook could then be used to automatically add tolerations and node affinities to pods deployed into tenant namespaces so that they run on a specific set of nodes designated for that tenant. + +Node isolation can be implemented using an [pod node selectors](/docs/concepts/scheduling-eviction/assign-pod-node/) or a [Virtual Kubelet](https://github.com/virtual-kubelet). + +## Additional Considerations + +This section discusses other Kubernetes constructs and patterns that are relevant for multi-tenancy. + +### API Priority and Fairness + +[API priority and fairness](/docs/concepts/cluster-administration/flow-control/) is a Kubernetes feature that allows you to assign a priority to certain pods running within the cluster. When an application calls the Kubernetes API, the API server evaluates the priority assigned to pod. Calls from pods with higher priority are fulfilled before those with a lower priority. When contention is high, lower priority calls can be queued until the server is less busy or you can reject the requests. + +Using API priority and fairness will not be very common in SaaS environments unless you are allowing customers to run applications that interface with the Kubernetes API, e.g. a controller. + +### Quality-of-Service (QoS) {#qos} + +When you’re running a SaaS application, you may want the ability to offer different Quality-of-Service (QoS) tiers of service to different tenants. For example, you may have freemium service that comes with fewer performance guarantees and features and a for-fee service tier with specific performance guarantees. Fortunately, there are several Kubernetes constructs that can help you accomplish this within a shared cluster, including network QoS, storage classes, and pod priority and preemption. The idea with each of these is to provide tenants with the quality of service that they paid for. Let’s start by looking at networking QoS. + +Typically, all pods on a node share a network interface. Without network QoS, some pods may consume an unfair share of the available bandwidth at the expense of other pods. The Kubernetes [bandwidth plugin](https://www.cni.dev/plugins/current/meta/bandwidth/) creates an [extended resource](/docs/concepts/configuration/manage-resources-containers/#extended-resources) for networking that allows you to use Kubernetes resources constructs, i.e. requests/limits, to apply rate limits to pods by using Linux tc queues. Be aware that the plugin is considered experimental as per the [Network Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#support-traffic-shaping) documentation and should be thoroughly tested before use in production environments. + +For storage QoS, you will likely want to create different storage classes or profiles with different performance characteristics. Each storage profile can be associated with a different tier of service that is optimized for different workloads such IO, redundancy, or throughput. Additional logic might be necessary to allow the tenant to associate the appropriate storage profile with their workload. + +Finally, there’s [pod priority and preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/) where you can assign priority values to pods. When scheduling pods, the scheduler will try evicting pods with lower priority when there are insufficient resources to schedule pods that are assigned a higher priority. If you have a use case where tenants have different service tiers in in a shared cluster e.g. free and paid, you may want to give higher priority to certain tiers using this feature. + +### DNS + +Kubernetes clusters include a Domain Name System (DNS) service to provide translations from names to IP addresses, for all Services and Pods. By default, the Kubernetes DNS service allows lookups across all namespaces in the cluster. + +In multi-tenant environments where tenants can access pods and other Kubernetes resources, or where +stronger isolation is required, it may be necessary to prevent pods from looking up services in other +Namespaces. +You can restrict cross-namespace DNS lookups by configuring security rules for the DNS service. +For example, CoreDNS (the default DNS service for Kubernetes) can leverage Kubernetes metadata +to restrict queries to Pods and Services within a namespace. For more information, read an +[example](https://github.com/coredns/policy#kubernetes-metadata-multi-tenancy-policy) of configuring +this within the CoreDNS documentation. + +When a [Virtual Control Plane per tenant](#virtual-control-plane-per-tenant) model is used, a DNS service must be configured per tenant or a multi-tenant DNS service must be used. Here is an example of a [customized version of CoreDNS](https://github.com/kubernetes-sigs/cluster-api-provider-nested/blob/main/virtualcluster/doc/tenant-dns.md) that supports multiple tenants. + +### Operators + +[Operators](/docs/concepts/extend-kubernetes/operator/) are Kubernetes controllers that manage applications. Operators can simplify the management of multiple instances of an application, like a database service, which makes them a common building block in the multi-consumer (SaaS) multi-tenancy use case. + +Operators used in a multi-tenant environment should follow a stricter set of guidelines. Specifically, the Operator should: +* Support creating resources within different tenant namespaces, rather than just in the namespace in which the Operator is deployed. +* Ensure that the Pods are configured with resource requests and limits, to ensure scheduling and fairness. +* Support configuration of Pods for data-plane isolation techniques such as node isolation and sandboxed containers. + +## Implementations + +{{% thirdparty-content %}} + +There are two primary ways to share a Kubernetes cluster for multi-tenancy: using Namespaces (i.e. a Namespace per tenant) or by virtualizing the control plane (i.e. Virtual control plane per tenant). + +In both cases, data plane isolation, and management of additional considerations such as API Priority and Fairness, is also recommended. + +Namespace isolation is well-supported by Kubernetes, has a negligible resource cost, and provides mechanisms to allow tenants to interact appropriately, such as by allowing service-to-service communication. However, it can be difficult to configure, and doesn't apply to Kubernetes resources that can't be namespaced, such as Custom Resource Definitions, Storage Classes, and Webhooks. + +Control plane virtualization allows for isolation of non-namespaced resources at the cost of somewhat higher resource usage and more difficult cross-tenant sharing. It is a good option when namespace isolation is insufficient but dedicated clusters are undesirable, due to the high cost of maintaining them (especially on-prem) or due to their higher overhead and lack of resource sharing. However, even within a virtualized control plane, you will likely see benefits by using namespaces as well. + +The two options are discussed in more detail in the following sections: + +### Namespace per tenant + +As previously mentioned, you should consider isolating each workload in its own namespace, even if you are using dedicated clusters or virtualized control planes. This ensures that each workload only has access to its own resources, such as Config Maps and Secrets, and allows you to tailor dedicated security policies for each workload. In addition, it is a best practice to give each namespace names that are unique across your entire fleet (i.e., even if they are in separate clusters), as this gives you the flexibility to switch between dedicated and shared clusters in the future, or to use multi-cluster tooling such as service meshes. + +Conversely, there are also advantages to assigning namespaces at the tenant level, not just the workload level, since there are often policies that apply to all workloads owned by a single tenant. However, this raises its own problems. Firstly, this makes it difficult or impossible to customize policies to individual workloads, and secondly, it may be challenging to come up with a single level of "tenancy" that should be given a namespace. For example, an organization may have divisions, teams, and subteams - which should be assigned a namespace? + +To solve this, Kubernetes provides the [Hierarchical Namespace Controller (HNC)](https://github.com/kubernetes-sigs/hierarchical-namespaces), which allows you to organize your namespaces into hierarchies, and share certain policies and resources between them. It also helps you manage namespace labels, namespace lifecycles, and delegated management, and share resource quotas across related namespaces. These capabilities can be useful in both multi-team and multi-customer scenarios. + +Other projects that provide similar capabilities and aid in managing namespaced resources are listed below: + +#### Multi-team tenancy + +* [Capsule](https://github.com/clastix/capsule) +* [Kiosk](https://github.com/loft-sh/kiosk) + +#### Multi-customer tenancy + +* [Kubeplus](https://github.com/cloud-ark/kubeplus) + +#### Policy engines + +Policy engines provide features to validate and generate tenant configurations: + +* [Kyverno](https://kyverno.io/) +* [OPA/Gatekeeper](https://github.com/open-policy-agent/gatekeeper) + +### Virtual control plane per tenant + +Another form of control-plane isolation is to use Kubernetes extensions to provide each tenant a virtual control-plane that enables segmentation of cluster-wide API resources. [Data plane isolation](#data-plane-isolation) techniques can be used with this model to securely manage worker nodes across tenants. + +The virtual control plane based multi-tenancy model extends namespace-based multi-tenancy by providing each tenant with dedicated control plane components, and hence complete control over cluster-wide resources and add-on services. Worker nodes are shared across all tenants, and are managed by a Kubernetes cluster that is normally inaccessible to tenants. This cluster is often referred to as a _super-cluster_ (or sometimes as a _host-cluster_). Since a tenant’s control-plane is not directly associated with underlying compute resources it is referred to as a _virtual control plane_. + +A virtual control plane typically consists of the Kubernetes API server, the controller manager, and the etcd data store. It interacts with the super cluster via a metadata synchronization controller which coordinates changes across tenant control planes and the control plane of the super--cluster. + +By using per-tenant dedicated control planes, most of the isolation problems due to sharing one API server among all tenants are solved. Examples include noisy neighbors in the control plane, uncontrollable blast radius of policy misconfigurations, and conflicts between cluster scope objects such as webhooks and CRDs. Hence, the virtual control plane model is particularly suitable for cases where each tenant requires access to a Kubernetes API server and expects the full cluster manageability. + +The improved isolation comes at the cost of running and maintaining an individual virtual control plane per tenant. In addition, per-tenant control planes do not solve isolation problems in the data plane, such as node-level noisy neighbors or security threats. These must still be addressed separately. + +The Kubernetes [Cluster API - Nested (CAPN)](https://github.com/kubernetes-sigs/cluster-api-provider-nested/tree/main/virtualcluster) project provides an implementation of virtual control planes. + +#### Other implementations +* [Kamaji](https://github.com/clastix/kamaji) +* [vcluster](https://github.com/loft-sh/vcluster) + diff --git a/content/en/docs/concepts/security/rbac-good-practices.md b/content/en/docs/concepts/security/rbac-good-practices.md index 7361c3a163..cfcc8b3cb9 100644 --- a/content/en/docs/concepts/security/rbac-good-practices.md +++ b/content/en/docs/concepts/security/rbac-good-practices.md @@ -4,6 +4,7 @@ title: Role Based Access Control Good Practices description: > Principles and practices for good RBAC design for cluster operators. content_type: concept +weight: 60 --- diff --git a/content/en/docs/concepts/security/windows-security.md b/content/en/docs/concepts/security/windows-security.md index 2126bdddaa..8c0704ac2b 100644 --- a/content/en/docs/concepts/security/windows-security.md +++ b/content/en/docs/concepts/security/windows-security.md @@ -6,7 +6,7 @@ reviewers: - perithompson title: Security For Windows Nodes content_type: concept -weight: 75 +weight: 40 --- diff --git a/content/en/docs/concepts/storage/ephemeral-volumes.md b/content/en/docs/concepts/storage/ephemeral-volumes.md index a51984885e..27ea999ccf 100644 --- a/content/en/docs/concepts/storage/ephemeral-volumes.md +++ b/content/en/docs/concepts/storage/ephemeral-volumes.md @@ -207,7 +207,7 @@ because then the scheduler is free to choose a suitable node for the Pod. With immediate binding, the scheduler is forced to select a node that has access to the volume once it is available. -In terms of [resource ownership](/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents), +In terms of [resource ownership](/docs/concepts/workloads/controllers/garbage-collection/#owners-dependents), a Pod that has generic ephemeral storage is the owner of the PersistentVolumeClaim(s) that provide that ephemeral storage. When the Pod is deleted, the Kubernetes garbage collector deletes the PVC, which then usually diff --git a/content/en/docs/concepts/windows/intro.md b/content/en/docs/concepts/windows/intro.md index 91e9412759..a78a849931 100644 --- a/content/en/docs/concepts/windows/intro.md +++ b/content/en/docs/concepts/windows/intro.md @@ -121,7 +121,7 @@ section refers to several key workload abstractions and how they map to Windows. 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. + not be admitted by the API server. * [Workload resources](/docs/concepts/workloads/controllers/) including: * ReplicaSet diff --git a/content/en/docs/concepts/windows/user-guide.md b/content/en/docs/concepts/windows/user-guide.md index 450a1bb5e0..c9e5775da8 100644 --- a/content/en/docs/concepts/windows/user-guide.md +++ b/content/en/docs/concepts/windows/user-guide.md @@ -307,4 +307,4 @@ spec: app: iis-2019 ``` -[RuntimeClass]: https://kubernetes.io/docs/concepts/containers/runtime-class/ +[RuntimeClass]: /docs/concepts/containers/runtime-class/ 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 fe50cf7e2d..7c10da0acb 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 @@ -417,5 +417,5 @@ You can use [Descheduler](https://github.com/kubernetes-sigs/descheduler) to reb ## {{% heading "whatsnext" %}} -- [Blog: Introducing PodTopologySpread](https://kubernetes.io/blog/2020/05/introducing-podtopologyspread/) +- [Blog: Introducing PodTopologySpread](/blog/2020/05/introducing-podtopologyspread/) explains `maxSkew` in details, as well as bringing up some advanced usage examples. diff --git a/content/en/docs/contribute/_index.md b/content/en/docs/contribute/_index.md index 8627e8dd93..b4c7d838fa 100644 --- a/content/en/docs/contribute/_index.md +++ b/content/en/docs/contribute/_index.md @@ -145,7 +145,7 @@ class first,second white {{}} Figure 2. Preparation for your first contribution. -- Read the [Contribution overview](/docs/contribute/new-content/overview/) to +- Read the [Contribution overview](/docs/contribute/new-content/) to learn about the different ways you can contribute. - Check [`kubernetes/website` issues list](https://github.com/kubernetes/website/issues/) for issues that make good entry points. diff --git a/content/en/docs/contribute/advanced.md b/content/en/docs/contribute/advanced.md index 34e0107035..b825ad5e2c 100644 --- a/content/en/docs/contribute/advanced.md +++ b/content/en/docs/contribute/advanced.md @@ -8,7 +8,7 @@ weight: 98 This page assumes that you understand how to -[contribute to new content](/docs/contribute/new-content/overview) and +[contribute to new content](/docs/contribute/new-content/) and [review others' work](/docs/contribute/review/reviewing-prs/), and are ready to learn about more ways to contribute. You need to use the Git command line client and other tools for some of these tasks. diff --git a/content/en/docs/contribute/localization.md b/content/en/docs/contribute/localization.md index 7bfcbb6375..fa405372c2 100644 --- a/content/en/docs/contribute/localization.md +++ b/content/en/docs/contribute/localization.md @@ -13,14 +13,19 @@ card: -This page shows you how to [localize](https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/) the docs for a different language. +This page shows you how to +[localize](https://blog.mozilla.org/l10n/2011/12/14/i18n-vs-l10n-whats-the-diff/) the docs for a +different language. ## Contribute to an existing localization -You can help add or improve content to an existing localization. In [Kubernetes Slack](https://slack.k8s.io/) you'll find a channel for each localization. There is also a general [SIG Docs Localizations Slack channel](https://kubernetes.slack.com/messages/sig-docs-localizations) where you can say hello. +You can help add or improve content to an existing localization. In [Kubernetes +Slack](https://slack.k8s.io/) you'll find a channel for each localization. There is also a general +[SIG Docs Localizations Slack channel](https://kubernetes.slack.com/messages/sig-docs-localizations) +where you can say hello. {{< note >}} If you want to work on a localization that already exists, check @@ -30,11 +35,14 @@ English original. You might see extra details there. ### Find your two-letter language code -First, consult the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php) to find your localization's two-letter language code. For example, the two-letter code for Korean is `ko`. +First, consult the [ISO 639-1 standard](https://www.loc.gov/standards/iso639-2/php/code_list.php) +to find your localization's two-letter language code. For example, the two-letter code for Korean +is `ko`. ### Fork and clone the repo -First, [create your own fork](/docs/contribute/new-content/open-a-pr/#fork-the-repo) of the [kubernetes/website](https://github.com/kubernetes/website) repository. +First, [create your own fork](/docs/contribute/new-content/open-a-pr/#fork-the-repo) of the +[kubernetes/website](https://github.com/kubernetes/website) repository. Then, clone your fork and `cd` into it: @@ -43,7 +51,8 @@ git clone https://github.com//website cd website ``` -The website content directory includes sub-directories for each language. The localization you want to help out with is inside `content/`. +The website content directory includes sub-directories for each language. The localization you +want to help out with is inside `content/`. ### Suggest changes @@ -57,8 +66,9 @@ equivalent fix by updating the localization you're working on. Please limit pull requests to a single localization, since pull requests that change content in multiple localizations could be difficult to review. -Follow [Suggesting Content Improvements](/docs/contribute/suggest-improvements/) to propose changes to -that localization. The process is very similar to proposing changes to the upstream (English) content. +Follow [Suggesting Content Improvements](/docs/contribute/suggesting-improvements/) +to propose changes to that localization. The process is very similar to proposing changes to the +upstream (English) content. ## Start a new localization @@ -86,40 +96,62 @@ can incrementally work towards that goal. ### Find community -Let Kubernetes SIG Docs know you're interested in creating a localization! Join the [SIG Docs Slack channel](https://kubernetes.slack.com/messages/sig-docs) and the [SIG Docs Localizations Slack channel](https://kubernetes.slack.com/messages/sig-docs-localizations). Other localization teams are happy to help you get started and answer any questions you have. +Let Kubernetes SIG Docs know you're interested in creating a localization! Join the +[SIG Docs Slack channel](https://kubernetes.slack.com/messages/sig-docs) and the +[SIG Docs Localizations Slack channel](https://kubernetes.slack.com/messages/sig-docs-localizations). +Other localization teams are happy to help you get started and answer any questions you have. -Please also consider participating in the [SIG Docs Localization Subgroup meeting](https://github.com/kubernetes/community/tree/master/sig-docs). The mission of the SIG Docs localization subgroup is to work across the SIG Docs localization teams to collaborate on defining and documenting the processes for creating localized contribution guides. In addition, the SIG Docs localization subgroup will look for opportunities for the creation and sharing of common tools across localization teams and also serve to identify new requirements to the SIG Docs Leadership team. If you have questions about this meeting, please inquire on the [SIG Docs Localizations Slack channel](https://kubernetes.slack.com/messages/sig-docs-localizations). +Please also consider participating in the +[SIG Docs Localization Subgroup meeting](https://github.com/kubernetes/community/tree/master/sig-docs). +The mission of the SIG Docs localization subgroup is to work across the SIG Docs localization +teams to collaborate on defining and documenting the processes for creating localized contribution +guides. In addition, the SIG Docs localization subgroup will look for opportunities for the +creation and sharing of common tools across localization teams and also serve to identify new +requirements to the SIG Docs Leadership team. If you have questions about this meeting, please +inquire on the [SIG Docs Localizations Slack channel](https://kubernetes.slack.com/messages/sig-docs-localizations). -You can also create a Slack channel for your localization in the `kubernetes/community` repository. For an example of adding a Slack channel, see the PR for [adding a channel for Persian](https://github.com/kubernetes/community/pull/4980). +You can also create a Slack channel for your localization in the `kubernetes/community` +repository. For an example of adding a Slack channel, see the PR for +[adding a channel for Persian](https://github.com/kubernetes/community/pull/4980). ### Join the Kubernetes GitHub organization -Once you've opened a localization PR, you can become members of the Kubernetes GitHub organization. Each person on the team needs to create their own [Organization Membership Request](https://github.com/kubernetes/org/issues/new/choose) in the `kubernetes/org` repository. +Once you've opened a localization PR, you can become members of the Kubernetes GitHub +organization. Each person on the team needs to create their own +[Organization Membership Request](https://github.com/kubernetes/org/issues/new/choose) +in the `kubernetes/org` repository. ### Add your localization team in GitHub -Next, add your Kubernetes localization team to [`sig-docs/teams.yaml`](https://github.com/kubernetes/org/blob/main/config/kubernetes/sig-docs/teams.yaml). For an example of adding a localization team, see the PR to add the [Spanish localization team](https://github.com/kubernetes/org/pull/685). - -Members of `@kubernetes/sig-docs-**-owners` can approve PRs that change content within (and only within) your localization directory: `/content/**/`. - -For each localization, The `@kubernetes/sig-docs-**-reviews` team automates review assignment for new PRs. +Next, add your Kubernetes localization team to +[`sig-docs/teams.yaml`](https://github.com/kubernetes/org/blob/main/config/kubernetes/sig-docs/teams.yaml). +For an example of adding a localization team, see the PR to add the +[Spanish localization team](https://github.com/kubernetes/org/pull/685). +Members of `@kubernetes/sig-docs-**-owners` can approve PRs that change content within (and only +within) your localization directory: `/content/**/`. +For each localization, The `@kubernetes/sig-docs-**-reviews` team automates review assignment for +new PRs. Members of `@kubernetes/website-maintainers` can create new localization branches to coordinate translation efforts. - -Members of `@kubernetes/website-milestone-maintainers` can use the `/milestone` [Prow command](https://prow.k8s.io/command-help) to assign a milestone to issues or PRs. +Members of `@kubernetes/website-milestone-maintainers` can use the `/milestone` +[Prow command](https://prow.k8s.io/command-help) to assign a milestone to issues or PRs. ### Configure the workflow -Next, add a GitHub label for your localization in the `kubernetes/test-infra` repository. A label lets you filter issues and pull requests for your specific language. - -For an example of adding a label, see the PR for adding the [Italian language label](https://github.com/kubernetes/test-infra/pull/11316). +Next, add a GitHub label for your localization in the `kubernetes/test-infra` repository. A label +lets you filter issues and pull requests for your specific language. +For an example of adding a label, see the PR for adding the +[Italian language label](https://github.com/kubernetes/test-infra/pull/11316). ### Modify the site configuration -The Kubernetes website uses Hugo as its web framework. The website's Hugo configuration resides in the [`config.toml`](https://github.com/kubernetes/website/tree/main/config.toml) file. To support a new localization, you'll need to modify `config.toml`. +The Kubernetes website uses Hugo as its web framework. The website's Hugo configuration resides in +the [`config.toml`](https://github.com/kubernetes/website/tree/main/config.toml) file. +To support a new localization, you'll need to modify `config.toml`. -Add a configuration block for the new language to `config.toml`, under the existing `[languages]` block. The German block, for example, looks like: +Add a configuration block for the new language to `config.toml`, under the existing `[languages]` block. +The German block, for example, looks like: ```toml [languages.de] @@ -131,17 +163,25 @@ contentDir = "content/de" weight = 8 ``` -The value for `languageName` will be listed in language selection bar. Assign "language name in native script and language (English language name in latin script)" to `languageName`. For example, `languageName = "한국어 (Korean)"` or `languageName = "Deutsch (German)"`. +The value for `languageName` will be listed in language selection bar. Assign "language name in +native script and language (English language name in latin script)" to `languageName`. +For example, `languageName = "한국어 (Korean)"` or `languageName = "Deutsch (German)"`. -`languageNameLatinScript` can be used to access the language name in latin script and use it in the theme. Assign "language name in latin script" to `languageNameLatinScript`. For example, `languageNameLatinScript ="Korean"` or `languageNameLatinScript = "Deutsch"`. +`languageNameLatinScript` can be used to access the language name in latin script and use it in +the theme. Assign "language name in latin script" to `languageNameLatinScript`. For example, +`languageNameLatinScript ="Korean"` or `languageNameLatinScript = "Deutsch"`. -When assigning a `weight` parameter for your block, find the language block with the highest weight and add 1 to that value. +When assigning a `weight` parameter for your block, find the language block with the highest +weight and add 1 to that value. -For more information about Hugo's multilingual support, see "[Multilingual Mode](https://gohugo.io/content-management/multilingual/)". +For more information about Hugo's multilingual support, see +"[Multilingual Mode](https://gohugo.io/content-management/multilingual/)". ### Add a new localization directory -Add a language-specific subdirectory to the [`content`](https://github.com/kubernetes/website/tree/main/content) folder in the repository. For example, the two-letter code for German is `de`: +Add a language-specific subdirectory to the +[`content`](https://github.com/kubernetes/website/tree/main/content) folder in the repository. +For example, the two-letter code for German is `de`: ```shell mkdir content/de @@ -151,28 +191,34 @@ You also need to create a directory inside `data/i18n` for [localized strings](#site-strings-in-i18n); look at existing localizations for an example. To use these new strings, you must also create a symbolic link from `i18n/.toml` to the actual string configuration in -`data/i18n//.toml` (remember to commit the symbolic -link). +`data/i18n//.toml` (remember to commit the symbolic link). For example, for German the strings live in `data/i18n/de/de.toml`, and `i18n/de.toml` is a symbolic link to `data/i18n/de/de.toml`. ### Localize the community code of conduct -Open a PR against the [`cncf/foundation`](https://github.com/cncf/foundation/tree/main/code-of-conduct-languages) repository to add the code of conduct in your language. - +Open a PR against the [`cncf/foundation`](https://github.com/cncf/foundation/tree/main/code-of-conduct-languages) +repository to add the code of conduct in your language. ### Setting up the OWNERS files -To set the roles of each user contributing to the localization, create an `OWNERS` file inside the language-specific subdirectory with: +To set the roles of each user contributing to the localization, create an `OWNERS` file inside the +language-specific subdirectory with: -- **reviewers**: A list of kubernetes teams with reviewer roles, in this case, the `sig-docs-**-reviews` team created in [Add your localization team in GitHub](#add-your-localization-team-in-github). -- **approvers**: A list of kubernetes teams with approvers roles, in this case, the `sig-docs-**-owners` team created in [Add your localization team in GitHub](#add-your-localization-team-in-github). -- **labels**: A list of GitHub labels to automatically apply to a PR, in this case, the language label created in [Configure the workflow](#configure-the-workflow). +- **reviewers**: A list of kubernetes teams with reviewer roles, in this case, the + `sig-docs-**-reviews` team created in + [Add your localization team in GitHub](#add-your-localization-team-in-github). +- **approvers**: A list of kubernetes teams with approvers roles, in this case, the + `sig-docs-**-owners` team created in + [Add your localization team in GitHub](#add-your-localization-team-in-github). +- **labels**: A list of GitHub labels to automatically apply to a PR, in this case, the language + label created in [Configure the workflow](#configure-the-workflow). More information about the `OWNERS` file can be found at [go.k8s.io/owners](https://go.k8s.io/owners). -The [Spanish OWNERS file](https://git.k8s.io/website/content/es/OWNERS), with language code `es`, looks like: +The [Spanish OWNERS file](https://git.k8s.io/website/content/es/OWNERS), +with language code `es`, looks like: ```yaml # See the OWNERS docs at https://go.k8s.io/owners @@ -190,9 +236,13 @@ labels: - language/es ``` -After adding the language-specific `OWNERS` file, update the [root `OWNERS_ALIASES`](https://git.k8s.io/website/OWNERS_ALIASES) file with the new Kubernetes teams for the localization, `sig-docs-**-owners` and `sig-docs-**-reviews`. +After adding the language-specific `OWNERS` file, update the [root +`OWNERS_ALIASES`](https://git.k8s.io/website/OWNERS_ALIASES) file with the new Kubernetes teams +for the localization, `sig-docs-**-owners` and `sig-docs-**-reviews`. -For each team, add the list of GitHub users requested in [Add your localization team in GitHub](#add-your-localization-team-in-github), in alphabetical order. +For each team, add the list of GitHub users requested in +[Add your localization team in GitHub](#add-your-localization-team-in-github), +in alphabetical order. ```diff --- a/OWNERS_ALIASES @@ -216,33 +266,45 @@ For each team, add the list of GitHub users requested in [Add your localization ### Open a pull request -Next, [open a pull request](/docs/contribute/new-content/open-a-pr/#open-a-pr) (PR) to add a localization to the `kubernetes/website` repository. +Next, [open a pull request](/docs/contribute/new-content/open-a-pr/#open-a-pr) (PR) to add a +localization to the `kubernetes/website` repository. +The PR must include all of the [minimum required content](#minimum-required-content) before it can +be approved. -The PR must include all of the [minimum required content](#minimum-required-content) before it can be approved. - -For an example of adding a new localization, see the PR to enable [docs in French](https://github.com/kubernetes/website/pull/12548). +For an example of adding a new localization, see the PR to enable +[docs in French](https://github.com/kubernetes/website/pull/12548). ### Add a localized README file -To guide other localization contributors, add a new [`README-**.md`](https://help.github.com/articles/about-readmes/) to the top level of [k/website](https://github.com/kubernetes/website/), where `**` is the two-letter language code. For example, a German README file would be `README-de.md`. +To guide other localization contributors, add a new +[`README-**.md`](https://help.github.com/articles/about-readmes/) to the top level of +[k/website](https://github.com/kubernetes/website/), where `**` is the two-letter language code. +For example, a German README file would be `README-de.md`. -Provide guidance to localization contributors in the localized `README-**.md` file. Include the same information contained in `README.md` as well as: +Provide guidance to localization contributors in the localized `README-**.md` file. +Include the same information contained in `README.md` as well as: - A point of contact for the localization project - Any information specific to the localization -After you create the localized README, add a link to the file from the main English `README.md`, and include contact information in English. You can provide a GitHub ID, email address, [Slack channel](https://slack.com/), or other method of contact. You must also provide a link to your localized Community Code of Conduct. +After you create the localized README, add a link to the file from the main English `README.md`, +and include contact information in English. You can provide a GitHub ID, email address, +[Slack channel](https://slack.com/), or other method of contact. You must also provide a link to your +localized Community Code of Conduct. ### Launching your new localization Once a localization meets requirements for workflow and minimum output, SIG Docs will: - Enable language selection on the website -- Publicize the localization's availability through [Cloud Native Computing Foundation](https://www.cncf.io/about/) (CNCF) channels, including the [Kubernetes blog](https://kubernetes.io/blog/). +- Publicize the localization's availability through + [Cloud Native Computing Foundation](https://www.cncf.io/about/)(CNCF) channels, including the + [Kubernetes blog](/blog/). ## Translating content -Localizing *all* of the Kubernetes documentation is an enormous task. It's okay to start small and expand over time. +Localizing *all* of the Kubernetes documentation is an enormous task. It's okay to start small and +expand over time. ### Minimum required content @@ -253,23 +315,29 @@ Description | URLs Home | [All heading and subheading URLs](/docs/home/) Setup | [All heading and subheading URLs](/docs/setup/) Tutorials | [Kubernetes Basics](/docs/tutorials/kubernetes-basics/), [Hello Minikube](/docs/tutorials/hello-minikube/) -Site strings | [All site strings](#Site-strings-in-i18n) in a new localized TOML file +Site strings | [All site strings](#site-strings-in-i18n) in a new localized TOML file Releases | [All heading and subheading URLs](/releases) -Translated documents must reside in their own `content/**/` subdirectory, but otherwise follow the same URL path as the English source. For example, to prepare the [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) tutorial for translation into German, create a subfolder under the `content/de/` folder and copy the English source: +Translated documents must reside in their own `content/**/` subdirectory, but otherwise follow the +same URL path as the English source. For example, to prepare the +[Kubernetes Basics](/docs/tutorials/kubernetes-basics/) tutorial for translation into German, +create a subfolder under the `content/de/` folder and copy the English source: ```shell mkdir -p content/de/docs/tutorials cp content/en/docs/tutorials/kubernetes-basics.md content/de/docs/tutorials/kubernetes-basics.md ``` -Translation tools can speed up the translation process. For example, some editors offers plugins to quickly translate text. +Translation tools can speed up the translation process. For example, some editors offers plugins +to quickly translate text. {{< caution >}} -Machine-generated translation is insufficient on its own. Localization requires extensive human review to meet minimum standards of quality. +Machine-generated translation is insufficient on its own. Localization requires extensive human +review to meet minimum standards of quality. {{< /caution >}} -To ensure accuracy in grammar and meaning, members of your localization team should carefully review all machine-generated translations before publishing. +To ensure accuracy in grammar and meaning, members of your localization team should carefully +review all machine-generated translations before publishing. ### Source files @@ -280,17 +348,21 @@ To find source files for your target version: 1. Navigate to the Kubernetes website repository at https://github.com/kubernetes/website. 2. Select a branch for your target version from the following table: - Target version | Branch - -----|----- - Latest version | [`main`](https://github.com/kubernetes/website/tree/main) - Previous version | [`release-{{< skew prevMinorVersion >}}`](https://github.com/kubernetes/website/tree/release-{{< skew prevMinorVersion >}}) - Next version | [`dev-{{< skew nextMinorVersion >}}`](https://github.com/kubernetes/website/tree/dev-{{< skew nextMinorVersion >}}) -The `main` branch holds content for the current release `{{< latest-version >}}`. The release team will create a `{{< release-branch >}}` branch before the next release: v{{< skew nextMinorVersion >}}. + Target version | Branch + -----|----- + Latest version | [`main`](https://github.com/kubernetes/website/tree/main) + Previous version | [`release-{{< skew prevMinorVersion >}}`](https://github.com/kubernetes/website/tree/release-{{< skew prevMinorVersion >}}) + Next version | [`dev-{{< skew nextMinorVersion >}}`](https://github.com/kubernetes/website/tree/dev-{{< skew nextMinorVersion >}}) + +The `main` branch holds content for the current release `{{< latest-version >}}`. The release team +will create a `{{< release-branch >}}` branch before the next release: v{{< skew nextMinorVersion >}}. ### Site strings in i18n -Localizations must include the contents of [`data/i18n/en/en.toml`](https://github.com/kubernetes/website/blob/main/data/i18n/en/en.toml) in a new language-specific file. Using German as an example: `data/i18n/de/de.toml`. +Localizations must include the contents of +[`data/i18n/en/en.toml`](https://github.com/kubernetes/website/blob/main/data/i18n/en/en.toml) +in a new language-specific file. Using German as an example: `data/i18n/de/de.toml`. Add a new localization directory and file to `data/i18n/`. For example, with German (`de`): @@ -308,17 +380,22 @@ placeholder text for the search form: other = "Suchen" ``` -Localizing site strings lets you customize site-wide text and features: for example, the legal copyright text in the footer on each page. +Localizing site strings lets you customize site-wide text and features: for example, the legal +copyright text in the footer on each page. ### Language specific style guide and glossary -Some language teams have their own language-specific style guide and glossary. For example, see the [Korean Localization Guide](/ko/docs/contribute/localization_ko/). +Some language teams have their own language-specific style guide and glossary. +For example, see the [Korean Localization Guide](/ko/docs/contribute/localization_ko/). ### Language specific Zoom meetings -If the localization project needs a separate meeting time, contact a SIG Docs Co-Chair or Tech Lead to create a new reoccurring Zoom meeting and calendar invite. This is only needed when the the team is large enough to sustain and require a separate meeting. +If the localization project needs a separate meeting time, contact a SIG Docs Co-Chair or Tech +Lead to create a new reoccurring Zoom meeting and calendar invite. This is only needed when +the team is large enough to sustain and require a separate meeting. -Per CNCF policy, the localization teams must upload their meetings to the SIG Docs YouTube playlist. A SIG Docs Co-Chair or Tech Lead can help with the process until SIG Docs automates it. +Per CNCF policy, the localization teams must upload their meetings to the SIG Docs YouTube +playlist. A SIG Docs Co-Chair or Tech Lead can help with the process until SIG Docs automates it. ## Branching strategy @@ -328,42 +405,66 @@ when starting out and the localization is not yet live. To collaborate on a localization branch: -1. A team member of [@kubernetes/website-maintainers](https://github.com/orgs/kubernetes/teams/website-maintainers) opens a localization branch from a source branch on https://github.com/kubernetes/website. +1. A team member of + [@kubernetes/website-maintainers](https://github.com/orgs/kubernetes/teams/website-maintainers) + opens a localization branch from a source branch on https://github.com/kubernetes/website. - Your team approvers joined the `@kubernetes/website-maintainers` team when you [added your localization team](#add-your-localization-team-in-github) to the [`kubernetes/org`](https://github.com/kubernetes/org) repository. + Your team approvers joined the `@kubernetes/website-maintainers` team when you + [added your localization team](#add-your-localization-team-in-github) to the + [`kubernetes/org`](https://github.com/kubernetes/org) repository. - We recommend the following branch naming scheme: + We recommend the following branch naming scheme: - `dev--.` + `dev--.` - For example, an approver on a German localization team opens the localization branch `dev-1.12-de.1` directly against the k/website repository, based on the source branch for Kubernetes v1.12. + For example, an approver on a German localization team opens the localization branch + `dev-1.12-de.1` directly against the k/website repository, based on the source branch for + Kubernetes v1.12. 2. Individual contributors open feature branches based on the localization branch. - For example, a German contributor opens a pull request with changes to `kubernetes:dev-1.12-de.1` from `username:local-branch-name`. + For example, a German contributor opens a pull request with changes to + `kubernetes:dev-1.12-de.1` from `username:local-branch-name`. 3. Approvers review and merge feature branches into the localization branch. -4. Periodically, an approver merges the localization branch to its source branch by opening and approving a new pull request. Be sure to squash the commits before approving the pull request. +4. Periodically, an approver merges the localization branch to its source branch by opening and + approving a new pull request. Be sure to squash the commits before approving the pull request. -Repeat steps 1-4 as needed until the localization is complete. For example, subsequent German localization branches would be: `dev-1.12-de.2`, `dev-1.12-de.3`, etc. +Repeat steps 1-4 as needed until the localization is complete. For example, subsequent German +localization branches would be: `dev-1.12-de.2`, `dev-1.12-de.3`, etc. Teams must merge localized content into the same branch from which the content was sourced. - For example: + - a localization branch sourced from `main` must be merged into `main`. -- a localization branch sourced from `release-{{% skew "prevMinorVersion" %}}` must be merged into `release-{{% skew "prevMinorVersion" %}}`. +- a localization branch sourced from `release-{{% skew "prevMinorVersion" %}}` must be merged into + `release-{{% skew "prevMinorVersion" %}}`. {{< note >}} -If your localization branch was created from `main` branch but it is not merged into `main` before new release branch `{{< release-branch >}}` created, merge it into both `main` and new release branch `{{< release-branch >}}`. To merge your localization branch into new release branch `{{< release-branch >}}`, you need to switch upstream branch of your localization branch to `{{< release-branch >}}`. +If your localization branch was created from `main` branch but it is not merged into `main` before +new release branch `{{< release-branch >}}` created, merge it into both `main` and new release +branch `{{< release-branch >}}`. To merge your localization branch into new release branch +`{{< release-branch >}}`, you need to switch upstream branch of your localization branch to +`{{< release-branch >}}`. {{< /note >}} -At the beginning of every team milestone, it's helpful to open an issue comparing upstream changes between the previous localization branch and the current localization branch. There are two scripts for comparing upstream changes. [`upstream_changes.py`](https://github.com/kubernetes/website/tree/main/scripts#upstream_changespy) is useful for checking the changes made to a specific file. And [`diff_l10n_branches.py`](https://github.com/kubernetes/website/tree/main/scripts#diff_l10n_branchespy) is useful for creating a list of outdated files for a specific localization branch. +At the beginning of every team milestone, it's helpful to open an issue comparing upstream changes +between the previous localization branch and the current localization branch. +There are two scripts for comparing upstream changes. -While only approvers can open a new localization branch and merge pull requests, anyone can open a pull request for a new localization branch. No special permissions are required. +- [`upstream_changes.py`](https://github.com/kubernetes/website/tree/main/scripts#upstream_changespy) + is useful for checking the changes made to a specific file. And +- [`diff_l10n_branches.py`](https://github.com/kubernetes/website/tree/main/scripts#diff_l10n_branchespy) + is useful for creating a list of outdated files for a specific localization branch. -For more information about working from forks or directly from the repository, see ["fork and clone the repo"](#fork-and-clone-the-repo). +While only approvers can open a new localization branch and merge pull requests, anyone can open a +pull request for a new localization branch. No special permissions are required. + +For more information about working from forks or directly from the repository, see +["fork and clone the repo"](#fork-and-clone-the-repo). ## Upstream contributions SIG Docs welcomes upstream contributions and corrections to the English source. + diff --git a/content/en/docs/contribute/new-content/new-features.md b/content/en/docs/contribute/new-content/new-features.md index 268c447402..d40195c32d 100644 --- a/content/en/docs/contribute/new-content/new-features.md +++ b/content/en/docs/contribute/new-content/new-features.md @@ -37,7 +37,7 @@ the techniques described in ### Find out about upcoming features To find out about upcoming features, attend the weekly SIG Release meeting (see -the [community](https://kubernetes.io/community/) page for upcoming meetings) +the [community](/community/) page for upcoming meetings) and monitor the release-specific documentation in the [kubernetes/sig-release](https://github.com/kubernetes/sig-release/) repository. Each release has a sub-directory in the [/sig-release/tree/master/releases/](https://github.com/kubernetes/sig-release/tree/master/releases) diff --git a/content/en/docs/contribute/new-content/open-a-pr.md b/content/en/docs/contribute/new-content/open-a-pr.md index 666dfdce96..2989535ead 100644 --- a/content/en/docs/contribute/new-content/open-a-pr.md +++ b/content/en/docs/contribute/new-content/open-a-pr.md @@ -15,13 +15,15 @@ upcoming Kubernetes release, see [Document a new feature](/docs/contribute/new-content/new-features/). {{< /note >}} -To contribute new content pages or improve existing content pages, open a pull request (PR). Make sure you follow all the requirements in the [Before you begin](/docs/contribute/new-content/overview/#before-you-begin) section. - -If your change is small, or you're unfamiliar with git, read [Changes using GitHub](#changes-using-github) to learn how to edit a page. - -If your changes are large, read [Work from a local fork](#fork-the-repo) to learn how to make changes locally on your computer. +To contribute new content pages or improve existing content pages, open a pull request (PR). +Make sure you follow all the requirements in the +[Before you begin](/docs/contribute/new-content/) section. +If your change is small, or you're unfamiliar with git, read +[Changes using GitHub](#changes-using-github) to learn how to edit a page. +If your changes are large, read [Work from a local fork](#fork-the-repo) to learn how to make +changes locally on your computer. @@ -63,38 +65,39 @@ class id1 k8s Figure 1. Steps for opening a PR using GitHub. -1. On the page where you see the issue, select the pencil icon at the top right. - You can also scroll to the bottom of the page and select **Edit this page**. +1. On the page where you see the issue, select the pencil icon at the top right. + You can also scroll to the bottom of the page and select **Edit this page**. -2. Make your changes in the GitHub markdown editor. +1. Make your changes in the GitHub markdown editor. -3. Below the editor, fill in the **Propose file change** - form. In the first field, give your commit message a title. In - the second field, provide a description. +1. Below the editor, fill in the **Propose file change** form. + In the first field, give your commit message a title. + In the second field, provide a description. - {{< note >}} - Do not use any [GitHub Keywords](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) in your commit message. You can add those to the pull request - description later. - {{< /note >}} + {{< note >}} + Do not use any [GitHub Keywords](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) + in your commit message. You can add those to the pull request description later. + {{< /note >}} -4. Select **Propose file change**. +1. Select **Propose file change**. -5. Select **Create pull request**. +1. Select **Create pull request**. -6. The **Open a pull request** screen appears. Fill in the form: +1. The **Open a pull request** screen appears. Fill in the form: - - The **Subject** field of the pull request defaults to the commit summary. - You can change it if needed. - - The **Body** contains your extended commit message, if you have one, - and some template text. Add the - details the template text asks for, then delete the extra template text. - - Leave the **Allow edits from maintainers** checkbox selected. + - The **Subject** field of the pull request defaults to the commit summary. + You can change it if needed. + - The **Body** contains your extended commit message, if you have one, + and some template text. Add the + details the template text asks for, then delete the extra template text. + - Leave the **Allow edits from maintainers** checkbox selected. - {{< note >}} - PR descriptions are a great way to help reviewers understand your change. For more information, see [Opening a PR](#open-a-pr). - {{}} + {{< note >}} + PR descriptions are a great way to help reviewers understand your change. + For more information, see [Opening a PR](#open-a-pr). + {{}} -7. Select **Create pull request**. +1. Select **Create pull request**. ### Addressing feedback in GitHub @@ -106,12 +109,12 @@ leave a comment with their GitHub username in it. If a reviewer asks you to make changes: 1. Go to the **Files changed** tab. -2. Select the pencil (edit) icon on any files changed by the -pull request. -3. Make the changes requested. -4. Commit the changes. +1. Select the pencil (edit) icon on any files changed by the pull request. +1. Make the changes requested. +1. Commit the changes. -If you are waiting on a reviewer, reach out once every 7 days. You can also post a message in the `#sig-docs` Slack channel. +If you are waiting on a reviewer, reach out once every 7 days. You can also post a message in the +`#sig-docs` Slack channel. When your review is complete, a reviewer merges your PR and your changes go live a few minutes later. @@ -120,7 +123,8 @@ When your review is complete, a reviewer merges your PR and your changes go live If you're more experienced with git, or if your changes are larger than a few lines, work from a local fork. -Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) installed on your computer. You can also use a git UI application. +Make sure you have [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git) installed +on your computer. You can also use a git UI application. Figure 2 shows the steps to follow when you work from a local fork. The details for each step follow. @@ -157,53 +161,56 @@ Figure 2. Working from a local fork to make your changes. ### Fork the kubernetes/website repository 1. Navigate to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository. -2. Select **Fork**. +1. Select **Fork**. ### Create a local clone and set the upstream -3. In a terminal window, clone your fork and update the [Docsy Hugo theme](https://github.com/google/docsy#readme): +1. In a terminal window, clone your fork and update the [Docsy Hugo theme](https://github.com/google/docsy#readme): - ```bash - git clone git@github.com//website - cd website - git submodule update --init --recursive --depth 1 - ``` + ```shell + git clone git@github.com//website + cd website + git submodule update --init --recursive --depth 1 + ``` -4. Navigate to the new `website` directory. Set the `kubernetes/website` repository as the `upstream` remote: +1. Navigate to the new `website` directory. Set the `kubernetes/website` repository as the `upstream` remote: - ```bash - cd website + ```shell + cd website - git remote add upstream https://github.com/kubernetes/website.git - ``` + git remote add upstream https://github.com/kubernetes/website.git + ``` -5. Confirm your `origin` and `upstream` repositories: +1. Confirm your `origin` and `upstream` repositories: - ```bash - git remote -v - ``` + ```shell + git remote -v + ``` - Output is similar to: + Output is similar to: - ```bash - origin git@github.com:/website.git (fetch) - origin git@github.com:/website.git (push) - upstream https://github.com/kubernetes/website.git (fetch) - upstream https://github.com/kubernetes/website.git (push) - ``` + ```none + origin git@github.com:/website.git (fetch) + origin git@github.com:/website.git (push) + upstream https://github.com/kubernetes/website.git (fetch) + upstream https://github.com/kubernetes/website.git (push) + ``` -6. Fetch commits from your fork's `origin/main` and `kubernetes/website`'s `upstream/main`: +1. Fetch commits from your fork's `origin/main` and `kubernetes/website`'s `upstream/main`: - ```bash - git fetch origin - git fetch upstream - ``` + ```shell + git fetch origin + git fetch upstream + ``` - This makes sure your local repository is up to date before you start making changes. + This makes sure your local repository is up to date before you start making changes. - {{< note >}} - This workflow is different than the [Kubernetes Community GitHub Workflow](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md). You do not need to merge your local copy of `main` with `upstream/main` before pushing updates to your fork. - {{< /note >}} + {{< note >}} + This workflow is different than the + [Kubernetes Community GitHub Workflow](https://github.com/kubernetes/community/blob/master/contributors/guide/github-workflow.md). + You do not need to merge your local copy of `main` with `upstream/main` before pushing updates + to your fork. + {{< /note >}} ### Create a branch @@ -211,21 +218,23 @@ Figure 2. Working from a local fork to make your changes. - For improvements to existing content, use `upstream/main`. - For new content about existing features, use `upstream/main`. - - For localized content, use the localization's conventions. For more information, see [localizing Kubernetes documentation](/docs/contribute/localization/). - - For new features in an upcoming Kubernetes release, use the feature branch. For more information, see [documenting for a release](/docs/contribute/new-content/new-features/). + - For localized content, use the localization's conventions. For more information, see + [localizing Kubernetes documentation](/docs/contribute/localization/). + - For new features in an upcoming Kubernetes release, use the feature branch. For more + information, see [documenting for a release](/docs/contribute/new-content/new-features/). - For long-running efforts that multiple SIG Docs contributors collaborate on, - like content reorganization, use a specific feature branch created for that - effort. + like content reorganization, use a specific feature branch created for that effort. If you need help choosing a branch, ask in the `#sig-docs` Slack channel. -2. Create a new branch based on the branch identified in step 1. This example assumes the base branch is `upstream/main`: +1. Create a new branch based on the branch identified in step 1. This example assumes the base + branch is `upstream/main`: - ```bash - git checkout -b upstream/main - ``` + ```shell + git checkout -b upstream/main + ``` -3. Make your changes using a text editor. +3. Make your changes using a text editor. At any time, use the `git status` command to see what files you've changed. @@ -235,109 +244,116 @@ When you are ready to submit a pull request, commit your changes. 1. In your local repository, check which files you need to commit: - ```bash - git status - ``` + ```shell + git status + ``` - Output is similar to: + Output is similar to: - ```bash - On branch - Your branch is up to date with 'origin/'. + ```none + On branch + Your branch is up to date with 'origin/'. - Changes not staged for commit: - (use "git add ..." to update what will be committed) - (use "git checkout -- ..." to discard changes in working directory) + Changes not staged for commit: + (use "git add ..." to update what will be committed) + (use "git checkout -- ..." to discard changes in working directory) - modified: content/en/docs/contribute/new-content/contributing-content.md + modified: content/en/docs/contribute/new-content/contributing-content.md - no changes added to commit (use "git add" and/or "git commit -a") - ``` + no changes added to commit (use "git add" and/or "git commit -a") + ``` -2. Add the files listed under **Changes not staged for commit** to the commit: +1. Add the files listed under **Changes not staged for commit** to the commit: - ```bash - git add - ``` + ```shell + git add + ``` - Repeat this for each file. + Repeat this for each file. -3. After adding all the files, create a commit: +1. After adding all the files, create a commit: - ```bash - git commit -m "Your commit message" - ``` + ```shell + git commit -m "Your commit message" + ``` - {{< note >}} - Do not use any [GitHub Keywords](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) in your commit message. You can add those to the pull request - description later. - {{< /note >}} + {{< note >}} + Do not use any [GitHub Keywords](https://help.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) + in your commit message. You can add those to the pull request + description later. + {{< /note >}} -4. Push your local branch and its new commit to your remote fork: +1. Push your local branch and its new commit to your remote fork: - ```bash - git push origin - ``` + ```shell + git push origin + ``` ### Preview your changes locally {#preview-locally} -It's a good idea to preview your changes locally before pushing them or opening a pull request. A preview lets you catch build errors or markdown formatting problems. +It's a good idea to preview your changes locally before pushing them or opening a pull request. +A preview lets you catch build errors or markdown formatting problems. -You can either build the website's container image or run Hugo locally. Building the container image is slower but displays [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/), which can be useful for debugging. +You can either build the website's container image or run Hugo locally. Building the container +image is slower but displays [Hugo shortcodes](/docs/contribute/style/hugo-shortcodes/), which can +be useful for debugging. {{< tabs name="tab_with_hugo" >}} {{% tab name="Hugo in a container" %}} {{< note >}} -The commands below use Docker as default container engine. Set the `CONTAINER_ENGINE` environment variable to override this behaviour. +The commands below use Docker as default container engine. Set the `CONTAINER_ENGINE` environment +variable to override this behaviour. {{< /note >}} 1. Build the container image locally _You only need this step if you are testing a change to the Hugo tool itself_ - ```bash + + ```shell # Run this in a terminal (if required) make container-image ``` 1. Start Hugo in a container: - ```bash + ```shell # Run this in a terminal make container-serve ``` -1. In a web browser, navigate to `https://localhost:1313`. Hugo watches the - changes and rebuilds the site as needed. +1. In a web browser, navigate to `https://localhost:1313`. Hugo watches the + changes and rebuilds the site as needed. -1. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`, - or close the terminal window. +1. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`, + or close the terminal window. {{% /tab %}} {{% tab name="Hugo on the command line" %}} Alternately, install and use the `hugo` command on your computer: -1. Install the [Hugo](https://gohugo.io/getting-started/installing/) version specified in [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/main/netlify.toml). +1. Install the [Hugo](https://gohugo.io/getting-started/installing/) version specified in + [`website/netlify.toml`](https://raw.githubusercontent.com/kubernetes/website/main/netlify.toml). -2. If you have not updated your website repository, the `website/themes/docsy` directory is empty. - The site cannot build without a local copy of the theme. To update the website theme, run: +1. If you have not updated your website repository, the `website/themes/docsy` directory is empty. + The site cannot build without a local copy of the theme. To update the website theme, run: - ```bash - git submodule update --init --recursive --depth 1 - ``` + ```shell + git submodule update --init --recursive --depth 1 + ``` -3. In a terminal, go to your Kubernetes website repository and start the Hugo server: +1. In a terminal, go to your Kubernetes website repository and start the Hugo server: - ```bash - cd /website - hugo server --buildFuture - ``` + ```shell + cd /website + hugo server --buildFuture + ``` -4. In a web browser, navigate to `https://localhost:1313`. Hugo watches the - changes and rebuilds the site as needed. +1. In a web browser, navigate to `https://localhost:1313`. Hugo watches the + changes and rebuilds the site as needed. -5. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`, - or close the terminal window. +1. To stop the local Hugo instance, go back to the terminal and type `Ctrl+C`, + or close the terminal window. {{% /tab %}} {{< /tabs >}} @@ -345,6 +361,7 @@ Alternately, install and use the `hugo` command on your computer: ### Open a pull request from your fork to kubernetes/website {#open-a-pr} Figure 3 shows the steps to open a PR from your fork to the K8s/website. The details follow. + @@ -374,47 +391,55 @@ class first,second white Figure 3. Steps to open a PR from your fork to the K8s/website. 1. In a web browser, go to the [`kubernetes/website`](https://github.com/kubernetes/website/) repository. -2. Select **New Pull Request**. -3. Select **compare across forks**. -4. From the **head repository** drop-down menu, select your fork. -5. From the **compare** drop-down menu, select your branch. -6. Select **Create Pull Request**. -7. Add a description for your pull request: +1. Select **New Pull Request**. +1. Select **compare across forks**. +1. From the **head repository** drop-down menu, select your fork. +1. From the **compare** drop-down menu, select your branch. +1. Select **Create Pull Request**. +`. Add a description for your pull request: + - **Title** (50 characters or less): Summarize the intent of the change. - **Description**: Describe the change in more detail. - - If there is a related GitHub issue, include `Fixes #12345` or `Closes #12345` in the description. GitHub's automation closes the mentioned issue after merging the PR if used. If there are other related PRs, link those as well. - - If you want advice on something specific, include any questions you'd like reviewers to think about in your description. -8. Select the **Create pull request** button. + - If there is a related GitHub issue, include `Fixes #12345` or `Closes #12345` in the + description. GitHub's automation closes the mentioned issue after merging the PR if used. + If there are other related PRs, link those as well. + - If you want advice on something specific, include any questions you'd like reviewers to + think about in your description. + +1. Select the **Create pull request** button. Congratulations! Your pull request is available in [Pull requests](https://github.com/kubernetes/website/pulls). +After opening a PR, GitHub runs automated tests and tries to deploy a preview using +[Netlify](https://www.netlify.com/). -After opening a PR, GitHub runs automated tests and tries to deploy a preview using [Netlify](https://www.netlify.com/). +- If the Netlify build fails, select **Details** for more information. +- If the Netlify build succeeds, select **Details** opens a staged version of the Kubernetes + website with your changes applied. This is how reviewers check your changes. - - If the Netlify build fails, select **Details** for more information. - - If the Netlify build succeeds, select **Details** opens a staged version of the Kubernetes website with your changes applied. This is how reviewers check your changes. - -GitHub also automatically assigns labels to a PR, to help reviewers. You can add them too, if needed. For more information, see [Adding and removing issue labels](/docs/contribute/review/for-approvers/#adding-and-removing-issue-labels). +GitHub also automatically assigns labels to a PR, to help reviewers. You can add them too, if +needed. For more information, see [Adding and removing issue labels](/docs/contribute/review/for-approvers/#adding-and-removing-issue-labels). ### Addressing feedback locally 1. After making your changes, amend your previous commit: - ```bash - git commit -a --amend - ``` + ```shell + git commit -a --amend + ``` - - `-a`: commits all changes - - `--amend`: amends the previous commit, rather than creating a new one + - `-a`: commits all changes + - `--amend`: amends the previous commit, rather than creating a new one -2. Update your commit message if needed. +1. Update your commit message if needed. -3. Use `git push origin ` to push your changes and re-run the Netlify tests. +1. Use `git push origin ` to push your changes and re-run the Netlify tests. - {{< note >}} - If you use `git commit -m` instead of amending, you must [squash your commits](#squashing-commits) before merging. - {{< /note >}} + {{< note >}} + If you use `git commit -m` instead of amending, you must [squash your commits](#squashing-commits) + before merging. + {{< /note >}} #### Changes from reviewers @@ -422,89 +447,97 @@ Sometimes reviewers commit to your pull request. Before making any other changes 1. Fetch commits from your remote fork and rebase your working branch: - ```bash - git fetch origin - git rebase origin/ - ``` + ```shell + git fetch origin + git rebase origin/ + ``` -2. After rebasing, force-push new changes to your fork: +1. After rebasing, force-push new changes to your fork: - ```bash - git push --force-with-lease origin - ``` + ```shell + git push --force-with-lease origin + ``` #### Merge conflicts and rebasing {{< note >}} -For more information, see [Git Branching - Basic Branching and Merging](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts), [Advanced Merging](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging), or ask in the `#sig-docs` Slack channel for help. +For more information, see [Git Branching - Basic Branching and Merging](https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging#_basic_merge_conflicts), +[Advanced Merging](https://git-scm.com/book/en/v2/Git-Tools-Advanced-Merging), or ask in the +`#sig-docs` Slack channel for help. {{< /note >}} -If another contributor commits changes to the same file in another PR, it can create a merge conflict. You must resolve all merge conflicts in your PR. +If another contributor commits changes to the same file in another PR, it can create a merge +conflict. You must resolve all merge conflicts in your PR. 1. Update your fork and rebase your local branch: - ```bash - git fetch origin - git rebase origin/ - ``` + ```shell + git fetch origin + git rebase origin/ + ``` - Then force-push the changes to your fork: + Then force-push the changes to your fork: - ```bash - git push --force-with-lease origin - ``` + ```shell + git push --force-with-lease origin + ``` -2. Fetch changes from `kubernetes/website`'s `upstream/main` and rebase your branch: +1. Fetch changes from `kubernetes/website`'s `upstream/main` and rebase your branch: - ```bash + ```shell git fetch upstream git rebase upstream/main ``` -3. Inspect the results of the rebase: +1. Inspect the results of the rebase: - ```bash - git status - ``` + ```shell + git status + ``` - This results in a number of files marked as conflicted. + This results in a number of files marked as conflicted. -4. Open each conflicted file and look for the conflict markers: `>>>`, `<<<`, and `===`. Resolve the conflict and delete the conflict marker. +1. Open each conflicted file and look for the conflict markers: `>>>`, `<<<`, and `===`. + Resolve the conflict and delete the conflict marker. - {{< note >}} - For more information, see [How conflicts are presented](https://git-scm.com/docs/git-merge#_how_conflicts_are_presented). - {{< /note >}} + {{< note >}} + For more information, see [How conflicts are presented](https://git-scm.com/docs/git-merge#_how_conflicts_are_presented). + {{< /note >}} -5. Add the files to the changeset: +1. Add the files to the changeset: - ```bash - git add - ``` -6. Continue the rebase: + ```shell + git add + ``` - ```bash - git rebase --continue - ``` +1. Continue the rebase: -7. Repeat steps 2 to 5 as needed. + `` + git rebase --continue + ``` - After applying all commits, the `git status` command shows that the rebase is complete. +1. Repeat steps 2 to 5 as needed. -8. Force-push the branch to your fork: + After applying all commits, the `git status` command shows that the rebase is complete. - ```bash - git push --force-with-lease origin - ``` +1. Force-push the branch to your fork: - The pull request no longer shows any conflicts. + ```shell + git push --force-with-lease origin + ``` + + The pull request no longer shows any conflicts. ### Squashing commits {{< note >}} -For more information, see [Git Tools - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History), or ask in the `#sig-docs` Slack channel for help. +For more information, see [Git Tools - Rewriting History](https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History), +or ask in the `#sig-docs` Slack channel for help. {{< /note >}} -If your PR has multiple commits, you must squash them into a single commit before merging your PR. You can check the number of commits on your PR's **Commits** tab or by running the `git log` command locally. +If your PR has multiple commits, you must squash them into a single commit before merging your PR. +You can check the number of commits on your PR's **Commits** tab or by running the `git log` +command locally. {{< note >}} This topic assumes `vim` as the command line text editor. @@ -512,79 +545,83 @@ This topic assumes `vim` as the command line text editor. 1. Start an interactive rebase: - ```bash - git rebase -i HEAD~ - ``` + ```shell + git rebase -i HEAD~ + ``` - Squashing commits is a form of rebasing. The `-i` switch tells git you want to rebase interactively. `HEAD~}} - For more information, see [Interactive Mode](https://git-scm.com/docs/git-rebase#_interactive_mode). - {{< /note >}} + {{< note >}} + For more information, see [Interactive Mode](https://git-scm.com/docs/git-rebase#_interactive_mode). + {{< /note >}} -2. Start editing the file. +1. Start editing the file. - Change the original text: + Change the original text: - ```bash - pick d875112ca Original commit - pick 4fa167b80 Address feedback 1 - pick 7d54e15ee Address feedback 2 - ``` + ```none + pick d875112ca Original commit + pick 4fa167b80 Address feedback 1 + pick 7d54e15ee Address feedback 2 + ``` - To: + To: - ```bash - pick d875112ca Original commit - squash 4fa167b80 Address feedback 1 - squash 7d54e15ee Address feedback 2 - ``` + ```none + pick d875112ca Original commit + squash 4fa167b80 Address feedback 1 + squash 7d54e15ee Address feedback 2 + ``` - This squashes commits `4fa167b80 Address feedback 1` and `7d54e15ee Address feedback 2` into `d875112ca Original commit`, leaving only `d875112ca Original commit` as a part of the timeline. + This squashes commits `4fa167b80 Address feedback 1` and `7d54e15ee Address feedback 2` into + `d875112ca Original commit`, leaving only `d875112ca Original commit` as a part of the timeline. -3. Save and exit your file. +1. Save and exit your file. -4. Push your squashed commit: +1. Push your squashed commit: - ```bash - git push --force-with-lease origin - ``` + ```shell + git push --force-with-lease origin + ``` ## Contribute to other repos -The [Kubernetes project](https://github.com/kubernetes) contains 50+ repositories. Many of these repositories contain documentation: user-facing help text, error messages, API references or code comments. +The [Kubernetes project](https://github.com/kubernetes) contains 50+ repositories. Many of these +repositories contain documentation: user-facing help text, error messages, API references or code +comments. -If you see text you'd like to improve, use GitHub to search all repositories in the Kubernetes organization. -This can help you figure out where to submit your issue or PR. +If you see text you'd like to improve, use GitHub to search all repositories in the Kubernetes +organization. This can help you figure out where to submit your issue or PR. -Each repository has its own processes and procedures. Before you file an -issue or submit a PR, read that repository's `README.md`, `CONTRIBUTING.md`, and -`code-of-conduct.md`, if they exist. +Each repository has its own processes and procedures. Before you file an issue or submit a PR, +read that repository's `README.md`, `CONTRIBUTING.md`, and `code-of-conduct.md`, if they exist. -Most repositories use issue and PR templates. Have a look through some open -issues and PRs to get a feel for that team's processes. Make sure to fill out -the templates with as much detail as possible when you file issues or PRs. +Most repositories use issue and PR templates. Have a look through some open issues and PRs to get +a feel for that team's processes. Make sure to fill out the templates with as much detail as +possible when you file issues or PRs. ## {{% heading "whatsnext" %}} - - Read [Reviewing](/docs/contribute/review/reviewing-prs) to learn more about the review process. diff --git a/content/en/docs/contribute/participate/_index.md b/content/en/docs/contribute/participate/_index.md index ff4714f803..b76423eded 100644 --- a/content/en/docs/contribute/participate/_index.md +++ b/content/en/docs/contribute/participate/_index.md @@ -115,6 +115,6 @@ SIG Docs approvers. Here's how it works. For more information about contributing to the Kubernetes documentation, see: -- [Contributing new content](/docs/contribute/new-content/overview/) +- [Contributing new content](/docs/contribute/new-content/) - [Reviewing content](/docs/contribute/review/reviewing-prs) - [Documentation style guide](/docs/contribute/style/) diff --git a/content/en/docs/contribute/participate/roles-and-responsibilities.md b/content/en/docs/contribute/participate/roles-and-responsibilities.md index c577c3f8be..10d6072ce3 100644 --- a/content/en/docs/contribute/participate/roles-and-responsibilities.md +++ b/content/en/docs/contribute/participate/roles-and-responsibilities.md @@ -32,7 +32,7 @@ Anyone can: - Suggest improvements on [Slack](https://slack.k8s.io/) or the [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). -After [signing the CLA](/docs/contribute/new-content/overview/#sign-the-cla), anyone can also: +After [signing the CLA](https://github.com/kubernetes/community/blob/master/CLA.md), anyone can also: - Open a pull request to improve existing content, add new content, or write a blog post or case study - Create diagrams, graphics assets, and embeddable screencasts and videos diff --git a/content/en/docs/contribute/review/for-approvers.md b/content/en/docs/contribute/review/for-approvers.md index 9f137c23b5..5d0606d60d 100644 --- a/content/en/docs/contribute/review/for-approvers.md +++ b/content/en/docs/contribute/review/for-approvers.md @@ -141,7 +141,7 @@ To add a label, leave a comment in one of the following formats: To remove a label, leave a comment in one of the following formats: - `/remove-` (for example, `/remove-help`) -- `/remove- ` (for example, `/remove-triage needs-information`)` +- `/remove- ` (for example, `/remove-triage needs-information`) In both cases, the label must already exist. If you try to add a label that does not exist, the command is silently ignored. @@ -181,7 +181,7 @@ If the dead link issue is in the API or `kubectl` documentation, assign them `/p ### Blog issues -We expect [Kubernetes Blog](https://kubernetes.io/blog/) entries to become +We expect [Kubernetes Blog](/blog/) entries to become outdated over time. Therefore, we only maintain blog entries less than a year old. If an issue is related to a blog entry that is more than one year old, close the issue without fixing. diff --git a/content/en/docs/contribute/review/reviewing-prs.md b/content/en/docs/contribute/review/reviewing-prs.md index 5a5bbce533..54b209dc0e 100644 --- a/content/en/docs/contribute/review/reviewing-prs.md +++ b/content/en/docs/contribute/review/reviewing-prs.md @@ -7,7 +7,8 @@ weight: 10 -Anyone can review a documentation pull request. Visit the [pull requests](https://github.com/kubernetes/website/pulls) section in the Kubernetes website repository to see open pull requests. +Anyone can review a documentation pull request. Visit the [pull requests](https://github.com/kubernetes/website/pulls) +section in the Kubernetes website repository to see open pull requests. Reviewing documentation pull requests is a great way to introduce yourself to the Kubernetes community. @@ -27,7 +28,9 @@ Before reviewing, it's a good idea to: Before you start a review: -- Read the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) and ensure that you abide by it at all times. + +- Read the [CNCF Code of Conduct](https://github.com/cncf/foundation/blob/main/code-of-conduct.md) + and ensure that you abide by it at all times. - Be polite, considerate, and helpful. - Comment on positive aspects of PRs as well as changes. - Be empathetic and mindful of how your review may be received. @@ -36,7 +39,8 @@ Before you start a review: ## Review process -In general, review pull requests for content and style in English. Figure 1 outlines the steps for the review process. The details for each step follow. +In general, review pull requests for content and style in English. Figure 1 outlines the steps for +the review process. The details for each step follow. @@ -69,32 +73,39 @@ class third,fourth white Figure 1. Review process steps. -1. Go to - [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls). - You see a list of every open pull request against the Kubernetes website and - docs. +1. Go to [https://github.com/kubernetes/website/pulls](https://github.com/kubernetes/website/pulls). + You see a list of every open pull request against the Kubernetes website and docs. -2. Filter the open PRs using one or all of the following labels: - - `cncf-cla: yes` (Recommended): PRs submitted by contributors who have not signed the CLA cannot be merged. See [Sign the CLA](/docs/contribute/new-content/overview/#sign-the-cla) for more information. - - `language/en` (Recommended): Filters for english language PRs only. - - `size/`: filters for PRs of a certain size. If you're new, start with smaller PRs. +2. Filter the open PRs using one or all of the following labels: - Additionally, ensure the PR isn't marked as a work in progress. PRs using the `work in progress` label are not ready for review yet. + - `cncf-cla: yes` (Recommended): PRs submitted by contributors who have not signed the CLA + cannot be merged. See [Sign the CLA](/docs/contribute/new-content/#sign-the-cla) + for more information. + - `language/en` (Recommended): Filters for english language PRs only. + - `size/`: filters for PRs of a certain size. If you're new, start with smaller PRs. -3. Once you've selected a PR to review, understand the change by: - - Reading the PR description to understand the changes made, and read any linked issues - - Reading any comments by other reviewers - - Clicking the **Files changed** tab to see the files and lines changed - - Previewing the changes in the Netlify preview build by scrolling to the PR's build check section at the bottom of the **Conversation** tab. - Here's a screenshot (this shows GitHub's desktop site; if you're reviewing - on a tablet or smartphone device, the GitHub web UI is slightly different): - {{< figure src="/images/docs/github_netlify_deploy_preview.png" alt="GitHub pull request details including link to Netlify preview" >}} - To open the preview, click on the **Details** link of the **deploy/netlify** line in the list of checks. + Additionally, ensure the PR isn't marked as a work in progress. PRs using the `work in + progress` label are not ready for review yet. -4. Go to the **Files changed** tab to start your review. - 1. Click on the `+` symbol beside the line you want to comment on. - 2. Fill in any comments you have about the line and click either **Add single comment** (if you have only one comment to make) or **Start a review** (if you have multiple comments to make). - 3. When finished, click **Review changes** at the top of the page. Here, you can add +3. Once you've selected a PR to review, understand the change by: + + - Reading the PR description to understand the changes made, and read any linked issues + - Reading any comments by other reviewers + - Clicking the **Files changed** tab to see the files and lines changed + - Previewing the changes in the Netlify preview build by scrolling to the PR's build check + section at the bottom of the **Conversation** tab. + Here's a screenshot (this shows GitHub's desktop site; if you're reviewing + on a tablet or smartphone device, the GitHub web UI is slightly different): + {{< figure src="/images/docs/github_netlify_deploy_preview.png" alt="GitHub pull request details including link to Netlify preview" >}} + To open the preview, click on the **Details** link of the **deploy/netlify** line in the + list of checks. + +4. Go to the **Files changed** tab to start your review. + + 1. Click on the `+` symbol beside the line you want to comment on. + 1. 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). + 1. When finished, click **Review changes** at the top of the page. Here, you can add a summary of your review (and leave some positive comments for the contributor!), approve the PR, comment or request changes as needed. New contributors should always choose **Comment**. @@ -119,14 +130,22 @@ When reviewing, use the following as a starting point. ### Website -- Did this PR change or remove a page title, slug/alias or anchor link? If so, are there broken links as a result of this PR? Is there another option, like changing the page title without changing the slug? +- Did this PR change or remove a page title, slug/alias or anchor link? If so, are there broken + links as a result of this PR? Is there another option, like changing the page title without + changing the slug? + - Does the PR introduce a new page? If so: - - Is the page using the right [page content type](/docs/contribute/style/page-content-types/) and associated Hugo shortcodes? + + - Is the page using the right [page content type](/docs/contribute/style/page-content-types/) + and associated Hugo shortcodes? - Does the page appear correctly in the section's side navigation (or at all)? - Should the page appear on the [Docs Home](/docs/home/) listing? -- Do the changes show up in the Netlify preview? Be particularly vigilant about lists, code blocks, tables, notes and images. + +- Do the changes show up in the Netlify preview? Be particularly vigilant about lists, code + blocks, tables, notes and images. ### Other -For small issues with a PR, like typos or whitespace, prefix your comments with `nit:`. This lets the author know the issue is non-critical. +For small issues with a PR, like typos or whitespace, prefix your comments with `nit:`. +This lets the author know the issue is non-critical. diff --git a/content/en/docs/contribute/style/diagram-guide.md b/content/en/docs/contribute/style/diagram-guide.md index 67e3ceb5e5..b31c2e190e 100644 --- a/content/en/docs/contribute/style/diagram-guide.md +++ b/content/en/docs/contribute/style/diagram-guide.md @@ -242,7 +242,7 @@ Figure 17. A to B more text ``` {{< note >}} -You must include the `{{}}`, `{{}}` shortcode +You must include the Hugo Mermaid shortcode tags at the start and end of the Mermaid code block. You should add a diagram caption below the diagram. {{< /note >}} @@ -429,7 +429,7 @@ Don't forget to check that your diagram renders correctly using the This section shows several examples of Mermaid diagrams. {{< note >}} -The code block examples omit the Hugo `{{}}`, `{{}}` +The code block examples omit the Hugo Mermaid shortcode tags. This allows you to copy the code block into the live editor to experiment on your own. Note that the live editor doesn't recognize Hugo shortcodes. diff --git a/content/en/docs/contribute/suggesting-improvements.md b/content/en/docs/contribute/suggesting-improvements.md index 9cab3f7a72..d79df11476 100644 --- a/content/en/docs/contribute/suggesting-improvements.md +++ b/content/en/docs/contribute/suggesting-improvements.md @@ -1,6 +1,5 @@ --- title: Suggesting content improvements -slug: suggest-improvements content_type: concept weight: 10 card: diff --git a/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md b/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md index ed0980e299..84d1d84b15 100644 --- a/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md +++ b/content/en/docs/reference/command-line-tools-reference/kube-scheduler.md @@ -27,7 +27,7 @@ each Pod in the scheduling queue according to constraints and available resources. The scheduler then ranks each valid Node and binds the Pod to a suitable Node. Multiple different schedulers may be used within a cluster; kube-scheduler is the reference implementation. -See [scheduling](https://kubernetes.io/docs/concepts/scheduling-eviction/) +See [scheduling](/docs/concepts/scheduling-eviction/) for more information about scheduling and the kube-scheduler component. ``` 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 75fc7c1ecf..35518ec197 100644 --- a/content/en/docs/reference/config-api/kubeadm-config.v1beta3.md +++ b/content/en/docs/reference/config-api/kubeadm-config.v1beta3.md @@ -555,7 +555,7 @@ by kubeadm during kubeadm join.

int32 -

bindPorti sets the secure port for the API Server to bind to. +

bindPort sets the secure port for the API Server to bind to. Defaults to 6443.

diff --git a/content/en/docs/reference/glossary/managed-service.md b/content/en/docs/reference/glossary/managed-service.md index 186588252c..4752867bb7 100644 --- a/content/en/docs/reference/glossary/managed-service.md +++ b/content/en/docs/reference/glossary/managed-service.md @@ -16,7 +16,4 @@ tags: Some examples of Managed Services are AWS EC2, Azure SQL Database, and GCP Pub/Sub, but they can be any software offering that can be used by an application. -[Service Catalog](/docs/concepts/extend-kubernetes/service-catalog/) provides a way to -list, provision, and bind with Managed Services offered by -{{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}}. diff --git a/content/en/docs/reference/glossary/service-broker.md b/content/en/docs/reference/glossary/service-broker.md deleted file mode 100644 index d35ea3d688..0000000000 --- a/content/en/docs/reference/glossary/service-broker.md +++ /dev/null @@ -1,22 +0,0 @@ ---- -title: Service Broker -id: service-broker -date: 2018-04-12 -full_link: -short_description: > - An endpoint for a set of Managed Services offered and maintained by a third-party. - -aka: -tags: -- extension ---- - An endpoint for a set of {{< glossary_tooltip text="Managed Services" term_id="managed-service" >}} offered and maintained by a third-party. - - - -{{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}} implement the -[Open Service Broker API spec](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md) -and provide a standard interface for applications to use their Managed Services. -[Service Catalog](/docs/concepts/extend-kubernetes/service-catalog/) provides a way to -list, provision, and bind with Managed Services offered by Service Brokers. - diff --git a/content/en/docs/reference/glossary/service-catalog.md b/content/en/docs/reference/glossary/service-catalog.md index 3404543d18..471311426c 100644 --- a/content/en/docs/reference/glossary/service-catalog.md +++ b/content/en/docs/reference/glossary/service-catalog.md @@ -4,15 +4,15 @@ id: service-catalog date: 2018-04-12 full_link: short_description: > - An extension API that enables applications running in Kubernetes clusters to easily use external managed software offerings, such as a datastore service offered by a cloud provider. + A former extension API that enabled applications running in Kubernetes clusters to easily use external managed software offerings, such as a datastore service offered by a cloud provider. aka: tags: - extension --- - An extension API that enables applications running in Kubernetes clusters to easily use external managed software offerings, such as a datastore service offered by a cloud provider. + A former extension API that enabled applications running in Kubernetes clusters to easily use external managed software offerings, such as a datastore service offered by a cloud provider. -It provides a way to list, provision, and bind with external {{< glossary_tooltip text="Managed Services" term_id="managed-service" >}} from {{< glossary_tooltip text="Service Brokers" term_id="service-broker" >}} without needing detailed knowledge about how those services are created or managed. +It provided a way to list, provision, and bind with external {{< glossary_tooltip text="Managed Services" term_id="managed-service" >}} without needing detailed knowledge about how those services would be created or managed. diff --git a/content/en/docs/reference/kubectl/cheatsheet.md b/content/en/docs/reference/kubectl/cheatsheet.md index 3f96fd6e4c..8769e32b15 100644 --- a/content/en/docs/reference/kubectl/cheatsheet.md +++ b/content/en/docs/reference/kubectl/cheatsheet.md @@ -37,7 +37,7 @@ complete -o default -F __start_kubectl k ```bash source <(kubectl completion zsh) # setup autocomplete in zsh into the current shell -echo "[[ $commands[kubectl] ]] && source <(kubectl completion zsh)" >> ~/.zshrc # add autocomplete permanently to your zsh shell +echo '[[ $commands[kubectl] ]] && source <(kubectl completion zsh)' >> ~/.zshrc # add autocomplete permanently to your zsh shell ``` ### A Note on --all-namespaces @@ -381,6 +381,9 @@ kubectl cluster-info # Display kubectl cluster-info dump # Dump current cluster state to stdout kubectl cluster-info dump --output-directory=/path/to/cluster-state # Dump current cluster state to /path/to/cluster-state +# View existing taints on which exist on current nodes. +kubectl get nodes -o=custom-columns=NodeName:.metadata.name,TaintKey:.spec.taints[*].key,TaintValue:.spec.taints[*].value,TaintEffect:.spec.taints[*].effect + # If a taint with that key and effect already exists, its value is replaced as specified. kubectl taint nodes foo dedicated=special-user:NoSchedule ``` diff --git a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_generate-csr.md b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_generate-csr.md index 9cd82c4316..4bb4c30f76 100644 --- a/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_generate-csr.md +++ b/content/en/docs/reference/setup-tools/kubeadm/generated/kubeadm_certs_generate-csr.md @@ -17,7 +17,7 @@ Generate keys and certificate signing requests Generates keys and certificate signing requests (CSRs) for all the certificates required to run the control plane. This command also generates partial kubeconfig files with private key data in the "users > user > client-key-data" field, and for each kubeconfig file an accompanying ".csr" file is created. -This command is designed for use in [Kubeadm External CA Mode](https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#external-ca-mode). It generates CSRs which you can then submit to your external certificate authority for signing. +This command is designed for use in [Kubeadm External CA Mode](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/#external-ca-mode). It generates CSRs which you can then submit to your external certificate authority for signing. The PEM encoded signed certificates should then be saved alongside the key files, using ".crt" as the file extension, or in the case of kubeconfig files, the PEM encoded signed certificate should be base64 encoded and added to the kubeconfig file in the "users > user > client-certificate-data" field. diff --git a/content/en/docs/reference/using-api/client-libraries.md b/content/en/docs/reference/using-api/client-libraries.md index 8647198fe9..145599cdd9 100644 --- a/content/en/docs/reference/using-api/client-libraries.md +++ b/content/en/docs/reference/using-api/client-libraries.md @@ -28,14 +28,17 @@ The following client libraries are officially maintained by [Kubernetes SIG API Machinery](https://github.com/kubernetes/community/tree/master/sig-api-machinery). -| Language | Client Library | Sample Programs | -|----------|----------------|-----------------| -| dotnet | [github.com/kubernetes-client/csharp](https://github.com/kubernetes-client/csharp) | [browse](https://github.com/kubernetes-client/csharp/tree/master/examples/simple) -| Go | [github.com/kubernetes/client-go/](https://github.com/kubernetes/client-go/) | [browse](https://github.com/kubernetes/client-go/tree/master/examples) -| Haskell | [github.com/kubernetes-client/haskell](https://github.com/kubernetes-client/haskell) | [browse](https://github.com/kubernetes-client/haskell/tree/master/kubernetes-client/example) -| Java | [github.com/kubernetes-client/java](https://github.com/kubernetes-client/java/) | [browse](https://github.com/kubernetes-client/java#installation) -| JavaScript | [github.com/kubernetes-client/javascript](https://github.com/kubernetes-client/javascript) | [browse](https://github.com/kubernetes-client/javascript/tree/master/examples) -| Python | [github.com/kubernetes-client/python/](https://github.com/kubernetes-client/python/) | [browse](https://github.com/kubernetes-client/python/tree/master/examples) +| Language | Client Library | Sample Programs | +|------------|----------------|-----------------| +| C | [github.com/kubernetes-client/c](https://github.com/kubernetes-client/c/) | [browse](https://github.com/kubernetes-client/c/tree/master/examples) +| dotnet | [github.com/kubernetes-client/csharp](https://github.com/kubernetes-client/csharp) | [browse](https://github.com/kubernetes-client/csharp/tree/master/examples/simple) +| Go | [github.com/kubernetes/client-go/](https://github.com/kubernetes/client-go/) | [browse](https://github.com/kubernetes/client-go/tree/master/examples) +| Haskell | [github.com/kubernetes-client/haskell](https://github.com/kubernetes-client/haskell) | [browse](https://github.com/kubernetes-client/haskell/tree/master/kubernetes-client/example) +| Java | [github.com/kubernetes-client/java](https://github.com/kubernetes-client/java/) | [browse](https://github.com/kubernetes-client/java#installation) +| JavaScript | [github.com/kubernetes-client/javascript](https://github.com/kubernetes-client/javascript) | [browse](https://github.com/kubernetes-client/javascript/tree/master/examples) +| Perl | [github.com/kubernetes-client/perl/](https://github.com/kubernetes-client/perl/) | [browse](https://github.com/kubernetes-client/perl/tree/master/examples) +| Python | [github.com/kubernetes-client/python/](https://github.com/kubernetes-client/python/) | [browse](https://github.com/kubernetes-client/python/tree/master/examples) +| Ruby | [github.com/kubernetes-client/ruby/](https://github.com/kubernetes-client/ruby/) | [browse](https://github.com/kubernetes-client/ruby/tree/master/examples) ## Community-maintained client libraries diff --git a/content/en/docs/reference/using-api/deprecation-guide.md b/content/en/docs/reference/using-api/deprecation-guide.md index d448344504..0b5969e9f1 100644 --- a/content/en/docs/reference/using-api/deprecation-guide.md +++ b/content/en/docs/reference/using-api/deprecation-guide.md @@ -330,7 +330,7 @@ For example: ### Locate use of deprecated APIs -Use [client warnings, metrics, and audit information available in 1.19+](https://kubernetes.io/blog/2020/09/03/warnings/#deprecation-warnings) +Use [client warnings, metrics, and audit information available in 1.19+](/blog/2020/09/03/warnings/#deprecation-warnings) to locate use of deprecated APIs. ### Migrate to non-deprecated APIs @@ -340,11 +340,11 @@ to locate use of deprecated APIs. You can use the `kubectl-convert` command (`kubectl convert` prior to v1.20) to automatically convert an existing object: - + `kubectl-convert -f --output-version /`. For example, to convert an older Deployment to `apps/v1`, you can run: - + `kubectl-convert -f ./my-deployment.yaml --output-version apps/v1` Note that this may use non-ideal default values. To learn more about a specific diff --git a/content/en/docs/setup/_index.md b/content/en/docs/setup/_index.md index adc7304033..ba9b3c6785 100644 --- a/content/en/docs/setup/_index.md +++ b/content/en/docs/setup/_index.md @@ -67,4 +67,5 @@ for deploying Kubernetes is [kubeadm](/docs/setup/production-environment/tools/k Kubernetes is designed for its {{< glossary_tooltip term_id="control-plane" text="control plane" >}} to run on Linux. Within your cluster you can run applications on Linux or other operating systems, including Windows. -- Learn to [set up clusters with Windows nodes](/docs/setup/production-environment/windows/) + +- Learn to [set up clusters with Windows nodes](/docs/concepts/windows/) diff --git a/content/en/docs/setup/production-environment/_index.md b/content/en/docs/setup/production-environment/_index.md index 7d8200a6b3..f1c6587c75 100644 --- a/content/en/docs/setup/production-environment/_index.md +++ b/content/en/docs/setup/production-environment/_index.md @@ -28,47 +28,47 @@ on or hand to others, consider how your requirements for a Kubernetes cluster are influenced by the following issues: - *Availability*: A single-machine Kubernetes [learning environment](/docs/setup/#learning-environment) -has a single point of failure. Creating a highly available cluster means considering: + has a single point of failure. Creating a highly available cluster means considering: - Separating the control plane from the worker nodes. - Replicating the control plane components on multiple nodes. - Load balancing traffic to the cluster’s {{< glossary_tooltip term_id="kube-apiserver" text="API server" >}}. - Having enough worker nodes available, or able to quickly become available, as changing workloads warrant it. - *Scale*: If you expect your production Kubernetes environment to receive a stable amount of -demand, you might be able to set up for the capacity you need and be done. However, -if you expect demand to grow over time or change dramatically based on things like -season or special events, you need to plan how to scale to relieve increased -pressure from more requests to the control plane and worker nodes or scale down to reduce unused -resources. + demand, you might be able to set up for the capacity you need and be done. However, + if you expect demand to grow over time or change dramatically based on things like + season or special events, you need to plan how to scale to relieve increased + pressure from more requests to the control plane and worker nodes or scale down to reduce unused + resources. - *Security and access management*: You have full admin privileges on your own -Kubernetes learning cluster. But shared clusters with important workloads, and -more than one or two users, require a more refined approach to who and what can -access cluster resources. You can use role-based access control -([RBAC](/docs/reference/access-authn-authz/rbac/)) and other -security mechanisms to make sure that users and workloads can get access to the -resources they need, while keeping workloads, and the cluster itself, secure. -You can set limits on the resources that users and workloads can access -by managing [policies](/docs/concepts/policy/) and -[container resources](/docs/concepts/configuration/manage-resources-containers/). + Kubernetes learning cluster. But shared clusters with important workloads, and + more than one or two users, require a more refined approach to who and what can + access cluster resources. You can use role-based access control + ([RBAC](/docs/reference/access-authn-authz/rbac/)) and other + security mechanisms to make sure that users and workloads can get access to the + resources they need, while keeping workloads, and the cluster itself, secure. + You can set limits on the resources that users and workloads can access + by managing [policies](/docs/concepts/policy/) and + [container resources](/docs/concepts/configuration/manage-resources-containers/). Before building a Kubernetes production environment on your own, consider handing off some or all of this job to [Turnkey Cloud Solutions](/docs/setup/production-environment/turnkey-solutions/) -providers or other [Kubernetes Partners](https://kubernetes.io/partners/). +providers or other [Kubernetes Partners](/partners/). Options include: - *Serverless*: Just run workloads on third-party equipment without managing -a cluster at all. You will be charged for things like CPU usage, memory, and -disk requests. + a cluster at all. You will be charged for things like CPU usage, memory, and + disk requests. - *Managed control plane*: Let the provider manage the scale and availability -of the cluster's control plane, as well as handle patches and upgrades. + of the cluster's control plane, as well as handle patches and upgrades. - *Managed worker nodes*: Configure pools of nodes to meet your needs, -then the provider makes sure those nodes are available and ready to implement -upgrades when needed. + then the provider makes sure those nodes are available and ready to implement + upgrades when needed. - *Integration*: There are providers that integrate Kubernetes with other -services you may need, such as storage, container registries, authentication -methods, and development tools. + services you may need, such as storage, container registries, authentication + methods, and development tools. Whether you build a production Kubernetes cluster yourself or work with partners, review the following sections to evaluate your needs as they relate @@ -99,52 +99,52 @@ and ensuring that it can be repaired if something goes wrong is important, consider these steps: - *Choose deployment tools*: You can deploy a control plane using tools such -as kubeadm, kops, and kubespray. See -[Installing Kubernetes with deployment tools](/docs/setup/production-environment/tools/) -to learn tips for production-quality deployments using each of those deployment -methods. Different [Container Runtimes](/docs/setup/production-environment/container-runtimes/) -are available to use with your deployments. + as kubeadm, kops, and kubespray. See + [Installing Kubernetes with deployment tools](/docs/setup/production-environment/tools/) + to learn tips for production-quality deployments using each of those deployment + methods. Different [Container Runtimes](/docs/setup/production-environment/container-runtimes/) + are available to use with your deployments. - *Manage certificates*: Secure communications between control plane services -are implemented using certificates. Certificates are automatically generated -during deployment or you can generate them using your own certificate authority. -See [PKI certificates and requirements](/docs/setup/best-practices/certificates/) for details. + are implemented using certificates. Certificates are automatically generated + during deployment or you can generate them using your own certificate authority. + See [PKI certificates and requirements](/docs/setup/best-practices/certificates/) for details. - *Configure load balancer for apiserver*: Configure a load balancer -to distribute external API requests to the apiserver service instances running on different nodes. See -[Create an External Load Balancer](/docs/tasks/access-application-cluster/create-external-load-balancer/) -for details. + to distribute external API requests to the apiserver service instances running on different nodes. See + [Create an External Load Balancer](/docs/tasks/access-application-cluster/create-external-load-balancer/) + for details. - *Separate and backup etcd service*: The etcd services can either run on the -same machines as other control plane services or run on separate machines, for -extra security and availability. Because etcd stores cluster configuration data, -backing up the etcd database should be done regularly to ensure that you can -repair that database if needed. -See the [etcd FAQ](https://etcd.io/docs/v3.4/faq/) for details on configuring and using etcd. -See [Operating etcd clusters for Kubernetes](/docs/tasks/administer-cluster/configure-upgrade-etcd/) -and [Set up a High Availability etcd cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) -for details. + same machines as other control plane services or run on separate machines, for + extra security and availability. Because etcd stores cluster configuration data, + backing up the etcd database should be done regularly to ensure that you can + repair that database if needed. + See the [etcd FAQ](https://etcd.io/docs/v3.4/faq/) for details on configuring and using etcd. + See [Operating etcd clusters for Kubernetes](/docs/tasks/administer-cluster/configure-upgrade-etcd/) + and [Set up a High Availability etcd cluster with kubeadm](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) + for details. - *Create multiple control plane systems*: For high availability, the -control plane should not be limited to a single machine. If the control plane -services are run by an init service (such as systemd), each service should run on at -least three machines. However, running control plane services as pods in -Kubernetes ensures that the replicated number of services that you request -will always be available. -The scheduler should be fault tolerant, -but not highly available. Some deployment tools set up [Raft](https://raft.github.io/) -consensus algorithm to do leader election of Kubernetes services. If the -primary goes away, another service elects itself and take over. + control plane should not be limited to a single machine. If the control plane + services are run by an init service (such as systemd), each service should run on at + least three machines. However, running control plane services as pods in + Kubernetes ensures that the replicated number of services that you request + will always be available. + The scheduler should be fault tolerant, + but not highly available. Some deployment tools set up [Raft](https://raft.github.io/) + consensus algorithm to do leader election of Kubernetes services. If the + primary goes away, another service elects itself and take over. - *Span multiple zones*: If keeping your cluster available at all times is -critical, consider creating a cluster that runs across multiple data centers, -referred to as zones in cloud environments. Groups of zones are referred to as regions. -By spreading a cluster across -multiple zones in the same region, it can improve the chances that your -cluster will continue to function even if one zone becomes unavailable. -See [Running in multiple zones](/docs/setup/best-practices/multiple-zones/) for details. + critical, consider creating a cluster that runs across multiple data centers, + referred to as zones in cloud environments. Groups of zones are referred to as regions. + By spreading a cluster across + multiple zones in the same region, it can improve the chances that your + cluster will continue to function even if one zone becomes unavailable. + See [Running in multiple zones](/docs/setup/best-practices/multiple-zones/) for details. - *Manage on-going features*: If you plan to keep your cluster over time, -there are tasks you need to do to maintain its health and security. For example, -if you installed with kubeadm, there are instructions to help you with -[Certificate Management](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/) -and [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/). -See [Administer a Cluster](/docs/tasks/administer-cluster/) -for a longer list of Kubernetes administrative tasks. + there are tasks you need to do to maintain its health and security. For example, + if you installed with kubeadm, there are instructions to help you with + [Certificate Management](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs/) + and [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/). + See [Administer a Cluster](/docs/tasks/administer-cluster/) + for a longer list of Kubernetes administrative tasks. To learn about available options when you run control plane services, see [kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/), @@ -166,39 +166,36 @@ consider how you want to manage your worker nodes (also referred to simply as *nodes*). - *Configure nodes*: Nodes can be physical or virtual machines. If you want to -create and manage your own nodes, you can install a supported operating system, -then add and run the appropriate -[Node services](/docs/concepts/overview/components/#node-components). Consider: + create and manage your own nodes, you can install a supported operating system, + then add and run the appropriate + [Node services](/docs/concepts/overview/components/#node-components). Consider: - The demands of your workloads when you set up nodes by having appropriate memory, CPU, and disk speed and storage capacity available. - Whether generic computer systems will do or you have workloads that need GPU processors, Windows nodes, or VM isolation. - *Validate nodes*: See [Valid node setup](/docs/setup/best-practices/node-conformance/) -for information on how to ensure that a node meets the requirements to join -a Kubernetes cluster. + for information on how to ensure that a node meets the requirements to join + a Kubernetes cluster. - *Add nodes to the cluster*: If you are managing your own cluster you can -add nodes by setting up your own machines and either adding them manually or -having them register themselves to the cluster’s apiserver. See the -[Nodes](/docs/concepts/architecture/nodes/) section for information on how to set up Kubernetes to add nodes in these ways. -- *Add Windows nodes to the cluster*: Kubernetes offers support for Windows -worker nodes, allowing you to run workloads implemented in Windows containers. See -[Windows in Kubernetes](/docs/setup/production-environment/windows/) for details. + add nodes by setting up your own machines and either adding them manually or + having them register themselves to the cluster’s apiserver. See the + [Nodes](/docs/concepts/architecture/nodes/) section for information on how to set up Kubernetes to add nodes in these ways. - *Scale nodes*: Have a plan for expanding the capacity your cluster will -eventually need. See [Considerations for large clusters](/docs/setup/best-practices/cluster-large/) -to help determine how many nodes you need, based on the number of pods and -containers you need to run. If you are managing nodes yourself, this can mean -purchasing and installing your own physical equipment. + eventually need. See [Considerations for large clusters](/docs/setup/best-practices/cluster-large/) + to help determine how many nodes you need, based on the number of pods and + containers you need to run. If you are managing nodes yourself, this can mean + purchasing and installing your own physical equipment. - *Autoscale nodes*: Most cloud providers support -[Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme) -to replace unhealthy nodes or grow and shrink the number of nodes as demand requires. See the -[Frequently Asked Questions](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md) -for how the autoscaler works and -[Deployment](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#deployment) -for how it is implemented by different cloud providers. For on-premises, there -are some virtualization platforms that can be scripted to spin up new nodes -based on demand. + [Cluster Autoscaler](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#readme) + to replace unhealthy nodes or grow and shrink the number of nodes as demand requires. See the + [Frequently Asked Questions](https://github.com/kubernetes/autoscaler/blob/master/cluster-autoscaler/FAQ.md) + for how the autoscaler works and + [Deployment](https://github.com/kubernetes/autoscaler/tree/master/cluster-autoscaler#deployment) + for how it is implemented by different cloud providers. For on-premises, there + are some virtualization platforms that can be scripted to spin up new nodes + based on demand. - *Set up node health checks*: For important workloads, you want to make sure -that the nodes and pods running on those nodes are healthy. Using the -[Node Problem Detector](/docs/tasks/debug/debug-cluster/monitor-node-health/) -daemon, you can ensure your nodes are healthy. + that the nodes and pods running on those nodes are healthy. Using the + [Node Problem Detector](/docs/tasks/debug/debug-cluster/monitor-node-health/) + daemon, you can ensure your nodes are healthy. ## Production user management @@ -215,39 +212,51 @@ cluster (authentication) and deciding if they have permissions to do what they are asking (authorization): - *Authentication*: The apiserver can authenticate users using client -certificates, bearer tokens, an authenticating proxy, or HTTP basic auth. -You can choose which authentication methods you want to use. -Using plugins, the apiserver can leverage your organization’s existing -authentication methods, such as LDAP or Kerberos. See -[Authentication](/docs/reference/access-authn-authz/authentication/) -for a description of these different methods of authenticating Kubernetes users. -- *Authorization*: When you set out to authorize your regular users, you will probably choose between RBAC and ABAC authorization. See [Authorization Overview](/docs/reference/access-authn-authz/authorization/) to review different modes for authorizing user accounts (as well as service account access to your cluster): - - *Role-based access control* ([RBAC](/docs/reference/access-authn-authz/rbac/)): Lets you assign access to your cluster by allowing specific sets of permissions to authenticated users. Permissions can be assigned for a specific namespace (Role) or across the entire cluster (ClusterRole). Then using RoleBindings and ClusterRoleBindings, those permissions can be attached to particular users. - - *Attribute-based access control* ([ABAC](/docs/reference/access-authn-authz/abac/)): Lets you create policies based on resource attributes in the cluster and will allow or deny access based on those attributes. Each line of a policy file identifies versioning properties (apiVersion and kind) and a map of spec properties to match the subject (user or group), resource property, non-resource property (/version or /apis), and readonly. See [Examples](/docs/reference/access-authn-authz/abac/#examples) for details. + certificates, bearer tokens, an authenticating proxy, or HTTP basic auth. + You can choose which authentication methods you want to use. + Using plugins, the apiserver can leverage your organization’s existing + authentication methods, such as LDAP or Kerberos. See + [Authentication](/docs/reference/access-authn-authz/authentication/) + for a description of these different methods of authenticating Kubernetes users. +- *Authorization*: When you set out to authorize your regular users, you will probably choose + between RBAC and ABAC authorization. See [Authorization Overview](/docs/reference/access-authn-authz/authorization/) + to review different modes for authorizing user accounts (as well as service account access to + your cluster): + - *Role-based access control* ([RBAC](/docs/reference/access-authn-authz/rbac/)): Lets you + assign access to your cluster by allowing specific sets of permissions to authenticated users. + Permissions can be assigned for a specific namespace (Role) or across the entire cluster + (ClusterRole). Then using RoleBindings and ClusterRoleBindings, those permissions can be attached + to particular users. + - *Attribute-based access control* ([ABAC](/docs/reference/access-authn-authz/abac/)): Lets you + create policies based on resource attributes in the cluster and will allow or deny access + based on those attributes. Each line of a policy file identifies versioning properties (apiVersion + and kind) and a map of spec properties to match the subject (user or group), resource property, + non-resource property (/version or /apis), and readonly. See + [Examples](/docs/reference/access-authn-authz/abac/#examples) for details. As someone setting up authentication and authorization on your production Kubernetes cluster, here are some things to consider: - *Set the authorization mode*: When the Kubernetes API server -([kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)) -starts, the supported authentication modes must be set using the *--authorization-mode* -flag. For example, that flag in the *kube-adminserver.yaml* file (in */etc/kubernetes/manifests*) -could be set to Node,RBAC. This would allow Node and RBAC authorization for authenticated requests. + ([kube-apiserver](/docs/reference/command-line-tools-reference/kube-apiserver/)) + starts, the supported authentication modes must be set using the *--authorization-mode* + flag. For example, that flag in the *kube-adminserver.yaml* file (in */etc/kubernetes/manifests*) + could be set to Node,RBAC. This would allow Node and RBAC authorization for authenticated requests. - *Create user certificates and role bindings (RBAC)*: If you are using RBAC -authorization, users can create a CertificateSigningRequest (CSR) that can be -signed by the cluster CA. Then you can bind Roles and ClusterRoles to each user. -See [Certificate Signing Requests](/docs/reference/access-authn-authz/certificate-signing-requests/) -for details. + authorization, users can create a CertificateSigningRequest (CSR) that can be + signed by the cluster CA. Then you can bind Roles and ClusterRoles to each user. + See [Certificate Signing Requests](/docs/reference/access-authn-authz/certificate-signing-requests/) + for details. - *Create policies that combine attributes (ABAC)*: If you are using ABAC -authorization, you can assign combinations of attributes to form policies to -authorize selected users or groups to access particular resources (such as a -pod), namespace, or apiGroup. For more information, see -[Examples](/docs/reference/access-authn-authz/abac/#examples). + authorization, you can assign combinations of attributes to form policies to + authorize selected users or groups to access particular resources (such as a + pod), namespace, or apiGroup. For more information, see + [Examples](/docs/reference/access-authn-authz/abac/#examples). - *Consider Admission Controllers*: Additional forms of authorization for -requests that can come in through the API server include -[Webhook Token Authentication](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication). -Webhooks and other special authorization types need to be enabled by adding -[Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) -to the API server. + requests that can come in through the API server include + [Webhook Token Authentication](/docs/reference/access-authn-authz/authentication/#webhook-token-authentication). + Webhooks and other special authorization types need to be enabled by adding + [Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/) + to the API server. ## Set limits on workload resources @@ -256,38 +265,45 @@ of the Kubernetes control plane. Consider these items when setting up for the needs of your cluster's workloads: - *Set namespace limits*: Set per-namespace quotas on things like memory and CPU. See -[Manage Memory, CPU, and API Resources](/docs/tasks/administer-cluster/manage-resources/) -for details. You can also set -[Hierarchical Namespaces](/blog/2020/08/14/introducing-hierarchical-namespaces/) -for inheriting limits. + [Manage Memory, CPU, and API Resources](/docs/tasks/administer-cluster/manage-resources/) + for details. You can also set + [Hierarchical Namespaces](/blog/2020/08/14/introducing-hierarchical-namespaces/) + for inheriting limits. - *Prepare for DNS demand*: If you expect workloads to massively scale up, -your DNS service must be ready to scale up as well. See -[Autoscale the DNS service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/). + your DNS service must be ready to scale up as well. See + [Autoscale the DNS service in a Cluster](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/). - *Create additional service accounts*: User accounts determine what users can -do on a cluster, while a service account defines pod access within a particular -namespace. By default, a pod takes on the default service account from its namespace. -See [Managing Service Accounts](/docs/reference/access-authn-authz/service-accounts-admin/) -for information on creating a new service account. For example, you might want to: - - Add secrets that a pod could use to pull images from a particular container registry. See [Configure Service Accounts for Pods](/docs/tasks/configure-pod-container/configure-service-account/) for an example. - - Assign RBAC permissions to a service account. See [ServiceAccount permissions](/docs/reference/access-authn-authz/rbac/#service-account-permissions) for details. + do on a cluster, while a service account defines pod access within a particular + namespace. By default, a pod takes on the default service account from its namespace. + See [Managing Service Accounts](/docs/reference/access-authn-authz/service-accounts-admin/) + for information on creating a new service account. For example, you might want to: + - Add secrets that a pod could use to pull images from a particular container registry. See + [Configure Service Accounts for Pods](/docs/tasks/configure-pod-container/configure-service-account/) + for an example. + - Assign RBAC permissions to a service account. See + [ServiceAccount permissions](/docs/reference/access-authn-authz/rbac/#service-account-permissions) + for details. ## {{% heading "whatsnext" %}} - Decide if you want to build your own production Kubernetes or obtain one from -available [Turnkey Cloud Solutions](/docs/setup/production-environment/turnkey-solutions/) -or [Kubernetes Partners](https://kubernetes.io/partners/). + available [Turnkey Cloud Solutions](/docs/setup/production-environment/turnkey-solutions/) + or [Kubernetes Partners](/partners/). - If you choose to build your own cluster, plan how you want to -handle [certificates](/docs/setup/best-practices/certificates/) -and set up high availability for features such as -[etcd](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) -and the -[API server](/docs/setup/production-environment/tools/kubeadm/ha-topology/). -- Choose from [kubeadm](/docs/setup/production-environment/tools/kubeadm/), [kops](/docs/setup/production-environment/tools/kops/) or [Kubespray](/docs/setup/production-environment/tools/kubespray/) -deployment methods. + handle [certificates](/docs/setup/best-practices/certificates/) + and set up high availability for features such as + [etcd](/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm/) + and the + [API server](/docs/setup/production-environment/tools/kubeadm/ha-topology/). +- Choose from [kubeadm](/docs/setup/production-environment/tools/kubeadm/), + [kops](/docs/setup/production-environment/tools/kops/) or + [Kubespray](/docs/setup/production-environment/tools/kubespray/) + deployment methods. - Configure user management by determining your -[Authentication](/docs/reference/access-authn-authz/authentication/) and -[Authorization](/docs/reference/access-authn-authz/authorization/) methods. + [Authentication](/docs/reference/access-authn-authz/authentication/) and + [Authorization](/docs/reference/access-authn-authz/authorization/) methods. - Prepare for application workloads by setting up -[resource limits](/docs/tasks/administer-cluster/manage-resources/), -[DNS autoscaling](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/) -and [service accounts](/docs/reference/access-authn-authz/service-accounts-admin/). + [resource limits](/docs/tasks/administer-cluster/manage-resources/), + [DNS autoscaling](/docs/tasks/administer-cluster/dns-horizontal-autoscaling/) + and [service accounts](/docs/reference/access-authn-authz/service-accounts-admin/). + diff --git a/content/en/docs/setup/production-environment/container-runtimes.md b/content/en/docs/setup/production-environment/container-runtimes.md index deaee23022..dd432afd3d 100644 --- a/content/en/docs/setup/production-environment/container-runtimes.md +++ b/content/en/docs/setup/production-environment/container-runtimes.md @@ -36,8 +36,8 @@ part of Kubernetes (this removal was [announced](/blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation) as part of the v1.20 release). You can read -[Check whether Dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/) to understand how this removal might -affect you. To learn about migrating from using dockershim, see +[Check whether Dockershim removal affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) +to understand how this removal might affect you. To learn about migrating from using dockershim, see [Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/). If you are running a version of Kubernetes other than v{{< skew currentVersion >}}, 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 7f4f28a2cc..a1ea3b9089 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 @@ -11,7 +11,7 @@ weight: 30 Using `kubeadm`, you can create a minimum viable Kubernetes cluster that conforms to best practices. In fact, you can use `kubeadm` to set up a cluster that will pass the -[Kubernetes Conformance tests](https://kubernetes.io/blog/2017/10/software-conformance-certification). +[Kubernetes Conformance tests](/blog/2017/10/software-conformance-certification/). `kubeadm` also supports other cluster lifecycle functions, such as [bootstrap tokens](/docs/reference/access-authn-authz/bootstrap-tokens/) and cluster upgrades. @@ -76,8 +76,9 @@ Install a {{< glossary_tooltip term_id="container-runtime" text="container runti For detailed instructions and other prerequisites, see [Installing kubeadm](/docs/setup/production-environment/tools/kubeadm/install-kubeadm/). {{< note >}} -If you have already installed kubeadm, run `apt-get update && -apt-get upgrade` or `yum update` to get the latest version of kubeadm. +If you have already installed kubeadm, run +`apt-get update && apt-get upgrade` or +`yum update` to get the latest version of kubeadm. When you upgrade, the kubelet restarts every few seconds as it waits in a crashloop for kubeadm to tell it what to do. This crashloop is expected and normal. @@ -91,7 +92,8 @@ to not download the default container images which are hosted at `k8s.gcr.io`. Kubeadm has commands that can help you pre-pull the required images when creating a cluster without an internet connection on its nodes. -See [Running kubeadm without an internet connection](/docs/reference/setup-tools/kubeadm/kubeadm-init#without-internet-connection) for more details. +See [Running kubeadm without an internet connection](/docs/reference/setup-tools/kubeadm/kubeadm-init#without-internet-connection) +for more details. Kubeadm allows you to use a custom image repository for the required images. See [Using custom images](/docs/reference/setup-tools/kubeadm/kubeadm-init#custom-images) @@ -360,7 +362,8 @@ The output is similar to this: 5didvk.d09sbcov8ph2amjw ``` -If you don't have the value of `--discovery-token-ca-cert-hash`, you can get it by running the following command chain on the control-plane node: +If you don't have the value of `--discovery-token-ca-cert-hash`, you can get it by running the +following command chain on the control-plane node: ```bash openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | \ @@ -501,7 +504,7 @@ options. * Verify that your cluster is running properly with [Sonobuoy](https://github.com/heptio/sonobuoy) * See [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade/) for details about upgrading your cluster using `kubeadm`. -* Learn about advanced `kubeadm` usage in the [kubeadm reference documentation](/docs/reference/setup-tools/kubeadm/kubeadm) +* Learn about advanced `kubeadm` usage in the [kubeadm reference documentation](/docs/reference/setup-tools/kubeadm/) * Learn more about Kubernetes [concepts](/docs/concepts/) and [`kubectl`](/docs/reference/kubectl/). * See the [Cluster Networking](/docs/concepts/cluster-administration/networking/) page for a bigger list of Pod network add-ons. @@ -575,7 +578,7 @@ Example for `kubeadm upgrade`: or {{< skew currentVersion >}} To learn more about the version skew between the different Kubernetes component see -the [Version Skew Policy](https://kubernetes.io/releases/version-skew-policy/). +the [Version Skew Policy](/releases/version-skew-policy/). ## Limitations {#limitations} @@ -608,4 +611,6 @@ supports your chosen platform. ## Troubleshooting {#troubleshooting} -If you are running into difficulties with kubeadm, please consult our [troubleshooting docs](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/). +If you are running into difficulties with kubeadm, please consult our +[troubleshooting docs](/docs/setup/production-environment/tools/kubeadm/troubleshooting-kubeadm/). + diff --git a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md index 010f0aa94b..993ecf3878 100644 --- a/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md +++ b/content/en/docs/setup/production-environment/tools/kubeadm/install-kubeadm.md @@ -182,7 +182,6 @@ name=Kubernetes baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch enabled=1 gpgcheck=1 -repo_gpgcheck=1 gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg exclude=kubelet kubeadm kubectl EOF diff --git a/content/en/docs/setup/production-environment/tools/kubespray.md b/content/en/docs/setup/production-environment/tools/kubespray.md index fd594b92f8..e0525562c6 100644 --- a/content/en/docs/setup/production-environment/tools/kubespray.md +++ b/content/en/docs/setup/production-environment/tools/kubespray.md @@ -6,7 +6,7 @@ weight: 30 -This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Packet (bare metal), Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-sigs/kubespray). +This quickstart helps to install a Kubernetes cluster hosted on GCE, Azure, OpenStack, AWS, vSphere, Equinix Metal (formerly Packet), Oracle Cloud Infrastructure (Experimental) or Baremetal with [Kubespray](https://github.com/kubernetes-sigs/kubespray). Kubespray is a composition of [Ansible](https://docs.ansible.com/) playbooks, [inventory](https://github.com/kubernetes-sigs/kubespray/blob/master/docs/ansible.md), provisioning tools, and domain knowledge for generic OS/Kubernetes clusters configuration management tasks. Kubespray provides: @@ -46,7 +46,7 @@ Kubespray provides the following utilities to help provision your environment: * [Terraform](https://www.terraform.io/) scripts for the following cloud providers: * [AWS](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/aws) * [OpenStack](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/openstack) - * [Packet](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/packet) + * [Equinix Metal](https://github.com/kubernetes-sigs/kubespray/tree/master/contrib/terraform/metal) ### (2/5) Compose an inventory file diff --git a/content/en/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md b/content/en/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md index 95066ac612..897d44a54f 100644 --- a/content/en/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md +++ b/content/en/docs/tasks/access-application-cluster/communicate-containers-same-pod-shared-volume.md @@ -127,7 +127,7 @@ the shared Volume is lost. ## {{% heading "whatsnext" %}} -* Learn more about [patterns for composite containers](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns). +* Learn more about [patterns for composite containers](/blog/2015/06/the-distributed-system-toolkit-patterns/). * Learn about [composite containers for modular architecture](https://www.slideshare.net/Docker/slideshare-burns). diff --git a/content/en/docs/tasks/administer-cluster/certificates.md b/content/en/docs/tasks/administer-cluster/certificates.md index 44effe9340..f48ddaac66 100644 --- a/content/en/docs/tasks/administer-cluster/certificates.md +++ b/content/en/docs/tasks/administer-cluster/certificates.md @@ -4,124 +4,156 @@ content_type: task weight: 20 --- - When using client certificate authentication, you can generate certificates manually through `easyrsa`, `openssl` or `cfssl`. - - - ### easyrsa **easyrsa** can manually generate certificates for your cluster. -1. Download, unpack, and initialize the patched version of easyrsa3. +1. Download, unpack, and initialize the patched version of `easyrsa3`. - curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz - tar xzf easy-rsa.tar.gz - cd easy-rsa-master/easyrsa3 - ./easyrsa init-pki -1. Generate a new certificate authority (CA). `--batch` sets automatic mode; - `--req-cn` specifies the Common Name (CN) for the CA's new root certificate. + ```shell + curl -LO https://storage.googleapis.com/kubernetes-release/easy-rsa/easy-rsa.tar.gz + tar xzf easy-rsa.tar.gz + cd easy-rsa-master/easyrsa3 + ./easyrsa init-pki + ``` +1. Generate a new certificate authority (CA). `--batch` sets automatic mode; + `--req-cn` specifies the Common Name (CN) for the CA's new root certificate. - ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass -1. Generate server certificate and key. - The argument `--subject-alt-name` sets the possible IPs and DNS names the API server will - be accessed with. The `MASTER_CLUSTER_IP` is usually the first IP from the service CIDR - that is specified as the `--service-cluster-ip-range` argument for both the API server and - the controller manager component. The argument `--days` is used to set the number of days - after which the certificate expires. - The sample below also assumes that you are using `cluster.local` as the default - DNS domain name. + ```shell + ./easyrsa --batch "--req-cn=${MASTER_IP}@`date +%s`" build-ca nopass + ``` - ./easyrsa --subject-alt-name="IP:${MASTER_IP},"\ - "IP:${MASTER_CLUSTER_IP},"\ - "DNS:kubernetes,"\ - "DNS:kubernetes.default,"\ - "DNS:kubernetes.default.svc,"\ - "DNS:kubernetes.default.svc.cluster,"\ - "DNS:kubernetes.default.svc.cluster.local" \ - --days=10000 \ - build-server-full server nopass -1. Copy `pki/ca.crt`, `pki/issued/server.crt`, and `pki/private/server.key` to your directory. -1. Fill in and add the following parameters into the API server start parameters: +1. Generate server certificate and key. - --client-ca-file=/yourdirectory/ca.crt - --tls-cert-file=/yourdirectory/server.crt - --tls-private-key-file=/yourdirectory/server.key + The argument `--subject-alt-name` sets the possible IPs and DNS names the API server will + be accessed with. The `MASTER_CLUSTER_IP` is usually the first IP from the service CIDR + that is specified as the `--service-cluster-ip-range` argument for both the API server and + the controller manager component. The argument `--days` is used to set the number of days + after which the certificate expires. + The sample below also assumes that you are using `cluster.local` as the default + DNS domain name. + + ```shell + ./easyrsa --subject-alt-name="IP:${MASTER_IP},"\ + "IP:${MASTER_CLUSTER_IP},"\ + "DNS:kubernetes,"\ + "DNS:kubernetes.default,"\ + "DNS:kubernetes.default.svc,"\ + "DNS:kubernetes.default.svc.cluster,"\ + "DNS:kubernetes.default.svc.cluster.local" \ + --days=10000 \ + build-server-full server nopass + ``` + +1. Copy `pki/ca.crt`, `pki/issued/server.crt`, and `pki/private/server.key` to your directory. + +1. Fill in and add the following parameters into the API server start parameters: + + ```shell + --client-ca-file=/yourdirectory/ca.crt + --tls-cert-file=/yourdirectory/server.crt + --tls-private-key-file=/yourdirectory/server.key + ``` ### openssl **openssl** can manually generate certificates for your cluster. -1. Generate a ca.key with 2048bit: +1. Generate a ca.key with 2048bit: - openssl genrsa -out ca.key 2048 -1. According to the ca.key generate a ca.crt (use -days to set the certificate effective time): + ```shell + openssl genrsa -out ca.key 2048 + ``` - openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt -1. Generate a server.key with 2048bit: +1. According to the ca.key generate a ca.crt (use `-days` to set the certificate effective time): - openssl genrsa -out server.key 2048 -1. Create a config file for generating a Certificate Signing Request (CSR). - Be sure to substitute the values marked with angle brackets (e.g. ``) - with real values before saving this to a file (e.g. `csr.conf`). - Note that the value for `MASTER_CLUSTER_IP` is the service cluster IP for the - API server as described in previous subsection. - The sample below also assumes that you are using `cluster.local` as the default - DNS domain name. + ```shell + openssl req -x509 -new -nodes -key ca.key -subj "/CN=${MASTER_IP}" -days 10000 -out ca.crt + ``` - [ req ] - default_bits = 2048 - prompt = no - default_md = sha256 - req_extensions = req_ext - distinguished_name = dn +1. Generate a server.key with 2048bit: - [ dn ] - C = - ST = - L = - O = - OU = - CN = + ```shell + openssl genrsa -out server.key 2048 + ``` - [ req_ext ] - subjectAltName = @alt_names +1. Create a config file for generating a Certificate Signing Request (CSR). - [ alt_names ] - DNS.1 = kubernetes - DNS.2 = kubernetes.default - DNS.3 = kubernetes.default.svc - DNS.4 = kubernetes.default.svc.cluster - DNS.5 = kubernetes.default.svc.cluster.local - IP.1 = - IP.2 = + Be sure to substitute the values marked with angle brackets (e.g. ``) + with real values before saving this to a file (e.g. `csr.conf`). + Note that the value for `MASTER_CLUSTER_IP` is the service cluster IP for the + API server as described in previous subsection. + The sample below also assumes that you are using `cluster.local` as the default + DNS domain name. - [ v3_ext ] - authorityKeyIdentifier=keyid,issuer:always - basicConstraints=CA:FALSE - keyUsage=keyEncipherment,dataEncipherment - extendedKeyUsage=serverAuth,clientAuth - subjectAltName=@alt_names -1. Generate the certificate signing request based on the config file: + ```ini + [ req ] + default_bits = 2048 + prompt = no + default_md = sha256 + req_extensions = req_ext + distinguished_name = dn - openssl req -new -key server.key -out server.csr -config csr.conf -1. Generate the server certificate using the ca.key, ca.crt and server.csr: + [ dn ] + C = + ST = + L = + O = + OU = + CN = - openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \ - -CAcreateserial -out server.crt -days 10000 \ - -extensions v3_ext -extfile csr.conf -1. View the certificate signing request: + [ req_ext ] + subjectAltName = @alt_names - openssl req -noout -text -in ./server.csr -1. View the certificate: + [ alt_names ] + DNS.1 = kubernetes + DNS.2 = kubernetes.default + DNS.3 = kubernetes.default.svc + DNS.4 = kubernetes.default.svc.cluster + DNS.5 = kubernetes.default.svc.cluster.local + IP.1 = + IP.2 = - openssl x509 -noout -text -in ./server.crt + [ v3_ext ] + authorityKeyIdentifier=keyid,issuer:always + basicConstraints=CA:FALSE + keyUsage=keyEncipherment,dataEncipherment + extendedKeyUsage=serverAuth,clientAuth + subjectAltName=@alt_names + ``` + +1. Generate the certificate signing request based on the config file: + + ```shell + openssl req -new -key server.key -out server.csr -config csr.conf + ``` + +1. Generate the server certificate using the ca.key, ca.crt and server.csr: + + ```shell + openssl x509 -req -in server.csr -CA ca.crt -CAkey ca.key \ + -CAcreateserial -out server.crt -days 10000 \ + -extensions v3_ext -extfile csr.conf + ``` + +1. View the certificate signing request: + + ```shell + openssl req -noout -text -in ./server.csr + ``` + +1. View the certificate: + + ```shell + openssl x509 -noout -text -in ./server.crt + ``` Finally, add the same parameters into the API server start parameters. @@ -129,101 +161,121 @@ Finally, add the same parameters into the API server start parameters. **cfssl** is another tool for certificate generation. -1. Download, unpack and prepare the command line tools as shown below. - Note that you may need to adapt the sample commands based on the hardware - architecture and cfssl version you are using. +1. Download, unpack and prepare the command line tools as shown below. - curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfssl - chmod +x cfssl - curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson - chmod +x cfssljson - curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo - chmod +x cfssl-certinfo -1. Create a directory to hold the artifacts and initialize cfssl: + Note that you may need to adapt the sample commands based on the hardware + architecture and cfssl version you are using. - mkdir cert - cd cert - ../cfssl print-defaults config > config.json - ../cfssl print-defaults csr > csr.json -1. Create a JSON config file for generating the CA file, for example, `ca-config.json`: + ```shell + curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl_1.5.0_linux_amd64 -o cfssl + chmod +x cfssl + curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssljson_1.5.0_linux_amd64 -o cfssljson + chmod +x cfssljson + curl -L https://github.com/cloudflare/cfssl/releases/download/v1.5.0/cfssl-certinfo_1.5.0_linux_amd64 -o cfssl-certinfo + chmod +x cfssl-certinfo + ``` - { - "signing": { - "default": { - "expiry": "8760h" - }, - "profiles": { - "kubernetes": { - "usages": [ - "signing", - "key encipherment", - "server auth", - "client auth" - ], - "expiry": "8760h" - } - } - } - } -1. Create a JSON config file for CA certificate signing request (CSR), for example, - `ca-csr.json`. Be sure to replace the values marked with angle brackets with - real values you want to use. +1. Create a directory to hold the artifacts and initialize cfssl: - { - "CN": "kubernetes", - "key": { - "algo": "rsa", - "size": 2048 - }, - "names":[{ - "C": "", - "ST": "", - "L": "", - "O": "", - "OU": "" - }] - } -1. Generate CA key (`ca-key.pem`) and certificate (`ca.pem`): + ```shell + mkdir cert + cd cert + ../cfssl print-defaults config > config.json + ../cfssl print-defaults csr > csr.json + ``` - ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca -1. Create a JSON config file for generating keys and certificates for the API - server, for example, `server-csr.json`. Be sure to replace the values in angle brackets with - real values you want to use. The `MASTER_CLUSTER_IP` is the service cluster - IP for the API server as described in previous subsection. - The sample below also assumes that you are using `cluster.local` as the default - DNS domain name. +1. Create a JSON config file for generating the CA file, for example, `ca-config.json`: - { - "CN": "kubernetes", - "hosts": [ - "127.0.0.1", - "", - "", - "kubernetes", - "kubernetes.default", - "kubernetes.default.svc", - "kubernetes.default.svc.cluster", - "kubernetes.default.svc.cluster.local" - ], - "key": { - "algo": "rsa", - "size": 2048 - }, - "names": [{ - "C": "", - "ST": "", - "L": "", - "O": "", - "OU": "" - }] - } -1. Generate the key and certificate for the API server, which are by default - saved into file `server-key.pem` and `server.pem` respectively: + ```json + { + "signing": { + "default": { + "expiry": "8760h" + }, + "profiles": { + "kubernetes": { + "usages": [ + "signing", + "key encipherment", + "server auth", + "client auth" + ], + "expiry": "8760h" + } + } + } + } + ``` - ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \ +1. Create a JSON config file for CA certificate signing request (CSR), for example, + `ca-csr.json`. Be sure to replace the values marked with angle brackets with + real values you want to use. + + ```json + { + "CN": "kubernetes", + "key": { + "algo": "rsa", + "size": 2048 + }, + "names":[{ + "C": "", + "ST": "", + "L": "", + "O": "", + "OU": "" + }] + } + ``` + +1. Generate CA key (`ca-key.pem`) and certificate (`ca.pem`): + + ```shell + ../cfssl gencert -initca ca-csr.json | ../cfssljson -bare ca + ``` + +1. Create a JSON config file for generating keys and certificates for the API + server, for example, `server-csr.json`. Be sure to replace the values in angle brackets with + real values you want to use. The `` is the service cluster + IP for the API server as described in previous subsection. + The sample below also assumes that you are using `cluster.local` as the default + DNS domain name. + + ```json + { + "CN": "kubernetes", + "hosts": [ + "127.0.0.1", + "", + "", + "kubernetes", + "kubernetes.default", + "kubernetes.default.svc", + "kubernetes.default.svc.cluster", + "kubernetes.default.svc.cluster.local" + ], + "key": { + "algo": "rsa", + "size": 2048 + }, + "names": [{ + "C": "", + "ST": "", + "L": "", + "O": "", + "OU": "" + }] + } + ``` + +1. Generate the key and certificate for the API server, which are by default + saved into file `server-key.pem` and `server.pem` respectively: + + ```shell + ../cfssl gencert -ca=ca.pem -ca-key=ca-key.pem \ --config=ca-config.json -profile=kubernetes \ server-csr.json | ../cfssljson -bare server - + ``` ## Distributing Self-Signed CA Certificate @@ -234,12 +286,12 @@ refresh the local list for valid certificates. On each client, perform the following operations: -```bash +```shell sudo cp ca.crt /usr/local/share/ca-certificates/kubernetes.crt sudo update-ca-certificates ``` -``` +```none Updating certificates in /etc/ssl/certs... 1 added, 0 removed; done. Running hooks in /etc/ca-certificates/update.d.... @@ -250,6 +302,6 @@ done. You can use the `certificates.k8s.io` API to provision x509 certificates to use for authentication as documented -[here](/docs/tasks/tls/managing-tls-in-a-cluster). - +in the [Managing TLS in a cluster](/docs/tasks/tls/managing-tls-in-a-cluster) +task page. diff --git a/content/en/docs/tasks/administer-cluster/controller-manager-leader-migration.md b/content/en/docs/tasks/administer-cluster/controller-manager-leader-migration.md index 45abdde6ac..7d0890197b 100644 --- a/content/en/docs/tasks/administer-cluster/controller-manager-leader-migration.md +++ b/content/en/docs/tasks/administer-cluster/controller-manager-leader-migration.md @@ -15,7 +15,7 @@ content_type: task ## Background -As part of the [cloud provider extraction effort](https://kubernetes.io/blog/2019/04/17/the-future-of-cloud-providers-in-kubernetes/), all cloud specific controllers must be moved out of the `kube-controller-manager`. All existing clusters that run cloud controllers in the `kube-controller-manager` must migrate to instead run the controllers in a cloud provider specific `cloud-controller-manager`. +As part of the [cloud provider extraction effort](/blog/2019/04/17/the-future-of-cloud-providers-in-kubernetes/), all cloud specific controllers must be moved out of the `kube-controller-manager`. All existing clusters that run cloud controllers in the `kube-controller-manager` must migrate to instead run the controllers in a cloud provider specific `cloud-controller-manager`. Leader Migration provides a mechanism in which HA clusters can safely migrate "cloud specific" controllers between the `kube-controller-manager` and the `cloud-controller-manager` via a shared resource lock between the two components while upgrading the replicated control plane. For a single-node control plane, or if unavailability of controller managers can be tolerated during the upgrade, Leader Migration is not needed and this guide can be ignored. 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 97fa2bc352..1b2a2e4cbe 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 @@ -73,7 +73,7 @@ To use `cgroupfs` and to prevent `kubeadm upgrade` from modifying the about its value. This applies to a case where you do not wish future versions of kubeadm to apply the `systemd` driver by default. -See the below section on "Modify the kubelet ConfigMap" for details on +See the below section on "[Modify the kubelet ConfigMap](#modify-the-kubelet-configmap)" for details on how to be explicit about the value. If you wish to configure a container runtime to use the `cgroupfs` driver, 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 783b107927..66f59a3dad 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -11,7 +11,7 @@ weight: 20 This page explains how to upgrade a Kubernetes cluster created with kubeadm from version {{< skew currentVersionAddMinor -1 >}}.x to version {{< skew currentVersion >}}.x, and from version {{< skew currentVersion >}}.x to {{< skew currentVersion >}}.y (where `y > x`). Skipping MINOR versions -when upgrading is unsupported. For more details, please visit [Version Skew Policy](https://kubernetes.io/releases/version-skew-policy/). +when upgrading is unsupported. For more details, please visit [Version Skew Policy](/releases/version-skew-policy/). To see information about upgrading clusters created using older versions of kubeadm, please refer to following pages instead: diff --git a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md index ef046077a8..b10f75dd9c 100644 --- a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md +++ b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md @@ -29,7 +29,7 @@ configuration. These tasks will help you to migrate: -* [Check whether Dockershim deprecation affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/) +* [Check whether Dockershim removal affects you](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/) * [Migrate Docker Engine nodes from dockershim to cri-dockerd](/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd/) * [Migrating telemetry and security agents from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/) diff --git a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md index 3835057c91..496f25fa0c 100644 --- a/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md +++ b/content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md @@ -8,24 +8,33 @@ weight: 70 -Kubernetes' support for direct integration with Docker Engine is deprecated, and will be removed. Most apps do not have a direct dependency on runtime hosting containers. However, there are still a lot of telemetry and monitoring agents that has a dependency on docker to collect containers metadata, logs and metrics. This document aggregates information on how to detect these dependencies and links on how to migrate these agents to use generic tools or alternative runtimes. +{{% thirdparty-content %}} + +Kubernetes' support for direct integration with Docker Engine is deprecated and +has been removed. Most apps do not have a direct dependency on runtime hosting +containers. However, there are still a lot of telemetry and monitoring agents +that have a dependency on Docker to collect containers metadata, logs, and +metrics. This document aggregates information on how to detect these +dependencies as well as links on how to migrate these agents to use generic tools or +alternative runtimes. ## Telemetry and security agents -Within a Kubernetes cluster there are a few different ways to run telemetry or security agents. -Some agents have a direct dependency on Docker Engine when they run as DaemonSets or -directly on nodes. +Within a Kubernetes cluster there are a few different ways to run telemetry or +security agents. Some agents have a direct dependency on Docker Engine when +they run as DaemonSets or directly on nodes. ### Why do some telemetry agents communicate with Docker Engine? Historically, Kubernetes was written to work specifically with Docker Engine. -Kubernetes took care of networking and scheduling, relying on Docker Engine for launching -and running containers (within Pods) on a node. Some information that is relevant to telemetry, -such as a pod name, is only available from Kubernetes components. Other data, such as container -metrics, is not the responsibility of the container runtime. Early telemetry agents needed to query the -container runtime **and** Kubernetes to report an accurate picture. Over time, Kubernetes gained -the ability to support multiple runtimes, and now supports any runtime that is compatible with -the container runtime interface. +Kubernetes took care of networking and scheduling, relying on Docker Engine for +launching and running containers (within Pods) on a node. Some information that +is relevant to telemetry, such as a pod name, is only available from Kubernetes +components. Other data, such as container metrics, is not the responsibility of +the container runtime. Early telemetry agents needed to query the container +runtime *and* Kubernetes to report an accurate picture. Over time, Kubernetes +gained the ability to support multiple runtimes, and now supports any runtime +that is compatible with the [container runtime interface](/docs/concepts/architecture/cri/). Some telemetry agents rely specifically on Docker Engine tooling. For example, an agent might run a command such as @@ -68,12 +77,90 @@ The script above only detects the most common uses. ### Detecting Docker dependency from node agents -In case your cluster nodes are customized and install additional security and -telemetry agents on the node, make sure to check with the vendor of the agent whether it has dependency on Docker. +If your cluster nodes are customized and install additional security and +telemetry agents on the node, check with the agent vendor +to verify whether it has any dependency on Docker. ### Telemetry and security agent vendors +This section is intended to aggregate information about various telemetry and +security agents that may have a dependency on container runtimes. + We keep the work in progress version of migration instructions for various telemetry and security agent vendors in [Google doc](https://docs.google.com/document/d/1ZFi4uKit63ga5sxEiZblfb-c23lFhvy6RXVPikS8wf0/edit#). Please contact the vendor to get up to date instructions for migrating from dockershim. +## Migration from dockershim + +### [Aqua](https://www.aquasec.com) + +No changes are needed: everything should work seamlessly on the runtime switch. + +### [Datadog](https://www.datadoghq.com/product/) + +How to migrate: +[Docker deprecation in Kubernetes](https://docs.datadoghq.com/agent/guide/docker-deprecation/) +The pod that accesses Docker Engine may have a name containing any of: + +- `datadog-agent` +- `datadog` +- `dd-agent` + +### [Dynatrace](https://www.dynatrace.com/) + +How to migrate: +[Migrating from Docker-only to generic container metrics in Dynatrace](https://community.dynatrace.com/t5/Best-practices/Migrating-from-Docker-only-to-generic-container-metrics-in/m-p/167030#M49) + +Containerd support announcement: [Get automated full-stack visibility into +containerd-based Kubernetes +environments](https://www.dynatrace.com/news/blog/get-automated-full-stack-visibility-into-containerd-based-kubernetes-environments/) + +CRI-O support announcement: [Get automated full-stack visibility into your CRI-O Kubernetes containers (Beta)](https://www.dynatrace.com/news/blog/get-automated-full-stack-visibility-into-your-cri-o-kubernetes-containers-beta/) + +The pod accessing Docker may have name containing: +- `dynatrace-oneagent` + +### [Falco](https://falco.org) + +How to migrate: + +[Migrate Falco from dockershim](https://falco.org/docs/getting-started/deployment/#docker-deprecation-in-kubernetes) +Falco supports any CRI-compatible runtime (containerd is used in the default configuration); the documentation explains all details. +The pod accessing Docker may have name containing: +- `falco` + +### [Prisma Cloud Compute](https://docs.paloaltonetworks.com/prisma/prisma-cloud.html) + +Check [documentation for Prisma Cloud](https://docs.paloaltonetworks.com/prisma/prisma-cloud/prisma-cloud-admin-compute/install/install_kubernetes.html), +under the "Install Prisma Cloud on a CRI (non-Docker) cluster" section. +The pod accessing Docker may be named like: +- `twistlock-defender-ds` + +### [SignalFx (Splunk)](https://www.splunk.com/en_us/investor-relations/acquisitions/signalfx.html) + +The SignalFx Smart Agent (deprecated) uses several different monitors for Kubernetes including +`kubernetes-cluster`, `kubelet-stats/kubelet-metrics`, and `docker-container-stats`. +The `kubelet-stats` monitor was previously deprecated by the vendor, in favor of `kubelet-metrics`. +The `docker-container-stats` monitor is the one affected by dockershim removal. +Do not use the `docker-container-stats` with container runtimes other than Docker Engine. + + +How to migrate from dockershim-dependent agent: +1. Remove `docker-container-stats` from the list of [configured monitors](https://github.com/signalfx/signalfx-agent/blob/main/docs/monitor-config.md). + Note, keeping this monitor enabled with non-dockershim runtime will result in incorrect metrics + being reported when docker is installed on node and no metrics when docker is not installed. +2. [Enable and configure `kubelet-metrics`](https://github.com/signalfx/signalfx-agent/blob/main/docs/monitors/kubelet-metrics.md) monitor. + + +{{< note >}} +The set of collected metrics will change. Review your alerting rules and dashboards. +{{< /note >}} + +The Pod accessing Docker may be named something like: + +- `signalfx-agent` + +### Yahoo Kubectl Flame + +Flame does not support container runtimes other than Docker. See +[https://github.com/yahoo/kubectl-flame/issues/51](https://github.com/yahoo/kubectl-flame/issues/51) diff --git a/content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md b/content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md index 54a9da1c08..8148a465f0 100644 --- a/content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md +++ b/content/en/docs/tasks/configure-pod-container/configure-persistent-volume-storage.md @@ -88,7 +88,7 @@ would provision a network resource like a Google Compute Engine persistent disk, an NFS share, or an Amazon Elastic Block Store volume. Cluster administrators can also use [StorageClasses](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#storageclass-v1-storage) to set up -[dynamic provisioning](https://kubernetes.io/blog/2016/10/dynamic-provisioning-and-storage-in-kubernetes). +[dynamic provisioning](/blog/2016/10/dynamic-provisioning-and-storage-in-kubernetes). Here is the configuration file for the hostPath PersistentVolume: diff --git a/content/en/docs/tasks/configure-pod-container/migrate-from-psp.md b/content/en/docs/tasks/configure-pod-container/migrate-from-psp.md index 1879ba5ba7..f7d78ea13e 100644 --- a/content/en/docs/tasks/configure-pod-container/migrate-from-psp.md +++ b/content/en/docs/tasks/configure-pod-container/migrate-from-psp.md @@ -323,7 +323,7 @@ configuration of the API server: To verify that the PodSecurityPolicy admission controller is no longer enabled, you can manually run a test by impersonating a user without access to any PodSecurityPolicies (see the -[PodSecurityPolicy example](/docs/concepts/policy/pod-security-policy/#example)), or by verifying in +[PodSecurityPolicy example](/docs/concepts/security/pod-security-policy/#example)), or by verifying in the API server logs. At startup, the API server outputs log lines listing the loaded admission controller plugins: diff --git a/content/en/docs/tasks/debug/debug-cluster/_index.md b/content/en/docs/tasks/debug/debug-cluster/_index.md index 9c0ad56a4c..29fb9a06ae 100644 --- a/content/en/docs/tasks/debug/debug-cluster/_index.md +++ b/content/en/docs/tasks/debug/debug-cluster/_index.md @@ -36,7 +36,13 @@ kubectl cluster-info dump ### Example: debugging a down/unreachable node -Sometimes when debugging it can be useful to look at the status of a node -- for example, because you've noticed strange behavior of a Pod that's running on the node, or to find out why a Pod won't schedule onto the node. As with Pods, you can use `kubectl describe node` and `kubectl get node -o yaml` to retrieve detailed information about nodes. For example, here's what you'll see if a node is down (disconnected from the network, or kubelet dies and won't restart, etc.). Notice the events that show the node is NotReady, and also notice that the pods are no longer running (they are evicted after five minutes of NotReady status). +Sometimes when debugging it can be useful to look at the status of a node -- for example, because +you've noticed strange behavior of a Pod that's running on the node, or to find out why a Pod +won't schedule onto the node. As with Pods, you can use `kubectl describe node` and `kubectl get +node -o yaml` to retrieve detailed information about nodes. For example, here's what you'll see if +a node is down (disconnected from the network, or kubelet dies and won't restart, etc.). Notice +the events that show the node is NotReady, and also notice that the pods are no longer running +(they are evicted after five minutes of NotReady status). ```shell kubectl get nodes @@ -222,14 +228,16 @@ of the relevant log files. On systemd-based systems, you may need to use `journ ### Control Plane nodes - * `/var/log/kube-apiserver.log` - API Server, responsible for serving the API - * `/var/log/kube-scheduler.log` - Scheduler, responsible for making scheduling decisions - * `/var/log/kube-controller-manager.log` - a component that runs most Kubernetes built-in {{}}, with the notable exception of scheduling (the kube-scheduler handles scheduling). +* `/var/log/kube-apiserver.log` - API Server, responsible for serving the API +* `/var/log/kube-scheduler.log` - Scheduler, responsible for making scheduling decisions +* `/var/log/kube-controller-manager.log` - a component that runs most Kubernetes built-in + {{}}, with the notable exception of scheduling + (the kube-scheduler handles scheduling). ### Worker Nodes - * `/var/log/kubelet.log` - logs from the kubelet, responsible for running containers on the node - * `/var/log/kube-proxy.log` - logs from `kube-proxy`, which is responsible for directing traffic to Service endpoints +* `/var/log/kubelet.log` - logs from the kubelet, responsible for running containers on the node +* `/var/log/kube-proxy.log` - logs from `kube-proxy`, which is responsible for directing traffic to Service endpoints ## Cluster failure modes @@ -237,45 +245,46 @@ This is an incomplete list of things that could go wrong, and how to adjust your ### Contributing causes - - VM(s) shutdown - - Network partition within cluster, or between cluster and users - - Crashes in Kubernetes software - - Data loss or unavailability of persistent storage (e.g. GCE PD or AWS EBS volume) - - Operator error, for example misconfigured Kubernetes software or application software +- VM(s) shutdown +- Network partition within cluster, or between cluster and users +- Crashes in Kubernetes software +- Data loss or unavailability of persistent storage (e.g. GCE PD or AWS EBS volume) +- Operator error, for example misconfigured Kubernetes software or application software ### Specific scenarios - - API server VM shutdown or apiserver crashing - - Results - - unable to stop, update, or start new pods, services, replication controller - - existing pods and services should continue to work normally, unless they depend on the Kubernetes API - - API server backing storage lost - - Results - - the kube-apiserver component fails to start successfully and become healthy - - kubelets will not be able to reach it but will continue to run the same pods and provide the same service proxying - - manual recovery or recreation of apiserver state necessary before apiserver is restarted - - Supporting services (node controller, replication controller manager, scheduler, etc) VM shutdown or crashes - - currently those are colocated with the apiserver, and their unavailability has similar consequences as apiserver - - in future, these will be replicated as well and may not be co-located - - they do not have their own persistent state - - Individual node (VM or physical machine) shuts down - - Results - - pods on that Node stop running - - Network partition - - Results - - partition A thinks the nodes in partition B are down; partition B thinks the apiserver is down. (Assuming the master VM ends up in partition A.) - - Kubelet software fault - - Results - - crashing kubelet cannot start new pods on the node - - kubelet might delete the pods or not - - node marked unhealthy - - replication controllers start new pods elsewhere - - Cluster operator error - - Results - - loss of pods, services, etc - - lost of apiserver backing store - - users unable to read API - - etc. +- API server VM shutdown or apiserver crashing + - Results + - unable to stop, update, or start new pods, services, replication controller + - existing pods and services should continue to work normally, unless they depend on the Kubernetes API +- API server backing storage lost + - Results + - the kube-apiserver component fails to start successfully and become healthy + - kubelets will not be able to reach it but will continue to run the same pods and provide the same service proxying + - manual recovery or recreation of apiserver state necessary before apiserver is restarted +- Supporting services (node controller, replication controller manager, scheduler, etc) VM shutdown or crashes + - currently those are colocated with the apiserver, and their unavailability has similar consequences as apiserver + - in future, these will be replicated as well and may not be co-located + - they do not have their own persistent state +- Individual node (VM or physical machine) shuts down + - Results + - pods on that Node stop running +- Network partition + - Results + - partition A thinks the nodes in partition B are down; partition B thinks the apiserver is down. + (Assuming the master VM ends up in partition A.) +- Kubelet software fault + - Results + - crashing kubelet cannot start new pods on the node + - kubelet might delete the pods or not + - node marked unhealthy + - replication controllers start new pods elsewhere +- Cluster operator error + - Results + - loss of pods, services, etc + - lost of apiserver backing store + - users unable to read API + - etc. ### Mitigations @@ -308,9 +317,13 @@ This is an incomplete list of things that could go wrong, and how to adjust your ## {{% heading "whatsnext" %}} -* Learn about the metrics available in the [Resource Metrics Pipeline](resource-metrics-pipeline) -* Discover additional tools for [monitoring resource usage](resource-usage-monitoring) -* Use Node Problem Detector to [monitor node health](monitor-node-health) -* Use `crictl` to [debug Kubernetes nodes](crictl) -* Get more information about [Kubernetes auditing](audit) -* Use `telepresence` to [develop and debug services locally](local-debugging) +* Learn about the metrics available in the + [Resource Metrics Pipeline](/docs/tasks/debug/debug-cluster/resource-metrics-pipeline/) +* Discover additional tools for + [monitoring resource usage](/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) +* Use Node Problem Detector to + [monitor node health](/docs/tasks/debug/debug-cluster/monitor-node-health/) +* Use `crictl` to [debug Kubernetes nodes](/docs/tasks/debug/debug-cluster/crictl/) +* Get more information about [Kubernetes auditing](/docs/tasks/debug/debug-cluster/audit/) +* Use `telepresence` to [develop and debug services locally](/docs/tasks/debug/debug-cluster/local-debugging/) + diff --git a/content/en/docs/tasks/debug/debug-cluster/windows.md b/content/en/docs/tasks/debug/debug-cluster/windows.md index 095fdb9571..c3a06faf16 100644 --- a/content/en/docs/tasks/debug/debug-cluster/windows.md +++ b/content/en/docs/tasks/debug/debug-cluster/windows.md @@ -17,7 +17,7 @@ content_type: concept 1. My Pods are stuck at "Container Creating" or restarting over and over Ensure that your pause image is compatible with your Windows OS version. - See [Pause container](/docs/setup/production-environment/windows/intro-windows-in-kubernetes#pause-container) + See [Pause container](/docs/concepts/windows/intro/#pause-container) to see the latest / recommended pause image and/or get more information. {{< note >}} @@ -32,7 +32,7 @@ content_type: concept Windows Node. More information on how to specify a compatible node for your Pod can be found in - [this guide](/docs/setup/production-environment/windows/user-guide-windows-containers/#ensuring-os-specific-workloads-land-on-the-appropriate-container-host). + [this guide](/docs/concepts/windows/user-guide/#ensuring-os-specific-workloads-land-on-the-appropriate-container-host). ## Network troubleshooting {#troubleshooting-network} @@ -102,8 +102,8 @@ content_type: concept 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". + 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 @@ -112,9 +112,11 @@ content_type: concept 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`. + 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). + 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 @@ -170,4 +172,5 @@ If these steps don't resolve your problem, you can get help running Windows cont * StackOverflow [Windows Server Container](https://stackoverflow.com/questions/tagged/windows-server-container) topic * Kubernetes Official Forum [discuss.kubernetes.io](https://discuss.kubernetes.io/) -* Kubernetes Slack [#SIG-Windows Channel](https://kubernetes.slack.com/messages/sig-windows) \ No newline at end of file +* Kubernetes Slack [#SIG-Windows Channel](https://kubernetes.slack.com/messages/sig-windows) + diff --git a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md index 6857f1a4d5..31a5fc1677 100644 --- a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md +++ b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning.md @@ -353,6 +353,34 @@ spec: {{< /tabs >}} +### Version removal + +An older API version cannot be dropped from a CustomResourceDefinition manifest until existing persisted data has been migrated to the newer API version for all clusters that served the older version of the custom resource, and the old version is removed from the `status.storedVersions` of the CustomResourceDefinition. + +```yaml +apiVersion: apiextensions.k8s.io/v1 +kind: CustomResourceDefinition + name: crontabs.example.com +spec: + group: example.com + names: + plural: crontabs + singular: crontab + kind: CronTab + scope: Namespaced + versions: + - name: v1beta1 + # This indicates the v1beta1 version of the custom resource is no longer served. + # API requests to this version receive a not found error in the server response. + served: false + schema: ... + - name: v1 + served: true + # The new served version should be set as the storage version + storage: true + schema: ... +``` + ## Webhook conversion {{< feature-state state="stable" for_k8s_version="v1.16" >}} diff --git a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md index 93fc8266ed..7766bcedf3 100644 --- a/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md +++ b/content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md @@ -28,11 +28,12 @@ the documentation for that version to see advice that is relevant for your clust ## Create a CustomResourceDefinition When you create a new CustomResourceDefinition (CRD), the Kubernetes API Server -creates a new RESTful resource path for each version you specify. The CRD can be -either namespaced or cluster-scoped, as specified in the CRD's `scope` field. As -with existing built-in objects, deleting a namespace deletes all custom objects -in that namespace. CustomResourceDefinitions themselves are non-namespaced and -are available to all namespaces. +creates a new RESTful resource path for each version you specify. The custom +resource created from a CRD object can be either namespaced or cluster-scoped, +as specified in the CRD's `spec.scope` field. As with existing built-in +objects, deleting a namespace deletes all custom objects in that namespace. +CustomResourceDefinitions themselves are non-namespaced and are available to +all namespaces. For example, if you save the following CustomResourceDefinition to `resourcedefinition.yaml`: @@ -187,7 +188,8 @@ kubectl get crontabs ``` ```none -Error from server (NotFound): Unable to list {"stable.example.com" "v1" "crontabs"}: the server could not find the requested resource (get crontabs.stable.example.com) +Error from server (NotFound): Unable to list {"stable.example.com" "v1" "crontabs"}: the server could not +find the requested resource (get crontabs.stable.example.com) ``` If you later recreate the same CustomResourceDefinition, it will start out empty. @@ -206,22 +208,28 @@ CustomResourceDefinition, the structural schema was optional. A structural schema is an [OpenAPI v3.0 validation schema](#validation) which: -1. specifies a non-empty type (via `type` in OpenAPI) for the root, for each specified field of an object node (via `properties` or `additionalProperties` in OpenAPI) and for each item in an array node (via `items` in OpenAPI), with the exception of: +1. specifies a non-empty type (via `type` in OpenAPI) for the root, for each specified field of an object node + (via `properties` or `additionalProperties` in OpenAPI) and for each item in an array node + (via `items` in OpenAPI), with the exception of: * a node with `x-kubernetes-int-or-string: true` * a node with `x-kubernetes-preserve-unknown-fields: true` -2. for each field in an object and each item in an array which is specified within any of `allOf`, `anyOf`, `oneOf` or `not`, the schema also specifies the field/item outside of those logical junctors (compare example 1 and 2). -3. does not set `description`, `type`, `default`, `additionalProperties`, `nullable` within an `allOf`, `anyOf`, `oneOf` or `not`, with the exception of the two pattern for `x-kubernetes-int-or-string: true` (see below). +2. for each field in an object and each item in an array which is specified within any of `allOf`, `anyOf`, + `oneOf` or `not`, the schema also specifies the field/item outside of those logical junctors (compare example 1 and 2). +3. does not set `description`, `type`, `default`, `additionalProperties`, `nullable` within an `allOf`, `anyOf`, + `oneOf` or `not`, with the exception of the two pattern for `x-kubernetes-int-or-string: true` (see below). 4. if `metadata` is specified, then only restrictions on `metadata.name` and `metadata.generateName` are allowed. - Non-structural example 1: + ```yaml allOf: - properties: foo: ... ``` + conflicts with rule 2. The following would be correct: + ```yaml properties: foo: @@ -313,10 +321,13 @@ Violations of the structural schema rules are reported in the `NonStructural` co ### Field pruning -CustomResourceDefinitions store validated resource data in the cluster's persistence store, {{< glossary_tooltip term_id="etcd" text="etcd">}}. As with native Kubernetes resources such as {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}}, if you specify a field that the API server does not recognize, the unknown field is _pruned_ (removed) before being persisted. +CustomResourceDefinitions store validated resource data in the cluster's persistence store, {{< glossary_tooltip term_id="etcd" text="etcd">}}. +As with native Kubernetes resources such as {{< glossary_tooltip text="ConfigMap" term_id="configmap" >}}, +if you specify a field that the API server does not recognize, the unknown field is _pruned_ (removed) before being persisted. {{< note >}} -CRDs converted from `apiextensions.k8s.io/v1beta1` to `apiextensions.k8s.io/v1` might lack structural schemas, and `spec.preserveUnknownFields` might be `true`. +CRDs converted from `apiextensions.k8s.io/v1beta1` to `apiextensions.k8s.io/v1` might lack structural schemas, +and `spec.preserveUnknownFields` might be `true`. For legacy CustomResourceDefinition objects created as `apiextensions.k8s.io/v1beta1` with `spec.preserveUnknownFields` set to @@ -376,7 +387,10 @@ to clients, `kubectl` also checks for unknown fields and rejects those objects w #### Controlling pruning -By default, all unspecified fields for a custom resource, across all versions, are pruned. It is possible though to opt-out of that for specifc sub-trees of fields by adding `x-kubernetes-preserve-unknown-fields: true` in the [structural OpenAPI v3 validation schema](#specifying-a-structural-schema). +By default, all unspecified fields for a custom resource, across all versions, are pruned. It is possible though to +opt-out of that for specifc sub-trees of fields by adding `x-kubernetes-preserve-unknown-fields: true` in the +[structural OpenAPI v3 validation schema](#specifying-a-structural-schema). + For example: ```yaml @@ -455,7 +469,8 @@ properties: x-kubernetes-int-or-string: true ``` -Also those nodes are partially excluded from rule 3 in the sense that the following two patterns are allowed (exactly those, without variations in order to additional fields): +Also those nodes are partially excluded from rule 3 in the sense that the following two patterns are allowed +(exactly those, without variations in order to additional fields): ```yaml x-kubernetes-int-or-string: true @@ -488,7 +503,8 @@ RawExtensions (as in `runtime.RawExtension` defined in [k8s.io/apimachinery](https://github.com/kubernetes/apimachinery/blob/03ac7a9ade429d715a1a46ceaa3724c18ebae54f/pkg/runtime/types.go#L94)) holds complete Kubernetes objects, i.e. with `apiVersion` and `kind` fields. -It is possible to specify those embedded objects (both completely without constraints or partially specified) by setting `x-kubernetes-embedded-resource: true`. For example: +It is possible to specify those embedded objects (both completely without constraints or partially specified) +by setting `x-kubernetes-embedded-resource: true`. For example: ```yaml type: object @@ -508,7 +524,8 @@ foo: ... ``` -Because `x-kubernetes-preserve-unknown-fields: true` is specified alongside, nothing is pruned. The use of `x-kubernetes-preserve-unknown-fields: true` is optional though. +Because `x-kubernetes-preserve-unknown-fields: true` is specified alongside, nothing is pruned. +The use of `x-kubernetes-preserve-unknown-fields: true` is optional though. With `x-kubernetes-embedded-resource: true`, the `apiVersion`, `kind` and `metadata` are implicitly specified and validated. @@ -771,6 +788,7 @@ The CronTab "my-new-cron-object" is invalid: The `rule` under `x-kubernetes-validations` represents the expression which will be evaluated by CEL. The `message` represents the message displayed when validation fails. If message is unset, the above response would be: + ``` The CronTab "my-new-cron-object" is invalid: * spec: Invalid value: map[string]interface {}{"maxReplicas":10, "minReplicas":0, "replicas":20}: failed rule: self.replicas <= self.maxReplicas @@ -781,16 +799,19 @@ The request of CRDs create/update will fail if compilation of validation rules f Compilation process includes type checking as well. The compilation failure: + - `no_matching_overload`: this function has no overload for the types of the arguments. - e.g. Rule like `self == true` against a field of integer type will get error: + e.g. Rule like `self == true` against a field of integer type will get error: + ``` Invalid value: apiextensions.ValidationRule{Rule:"self == true", Message:""}: compilation failed: ERROR: \:1:6: found no matching overload for '_==_' applied to '(int, bool)' ``` - `no_such_field`: does not contain the desired field. - e.g. Rule like `self.nonExistingField > 0` against a non-existing field will return the error: + e.g. Rule like `self.nonExistingField > 0` against a non-existing field will return the error: + ``` Invalid value: apiextensions.ValidationRule{Rule:"self.nonExistingField > 0", Message:""}: compilation failed: ERROR: \:1:5: undefined field 'nonExistingField' ``` @@ -798,11 +819,11 @@ The compilation failure: - `invalid argument`: invalid argument to macros. e.g. Rule like `has(self)` will return error: + ``` Invalid value: apiextensions.ValidationRule{Rule:"has(self)", Message:""}: compilation failed: ERROR: :1:4: invalid argument to has() macro ``` - Validation Rules Examples: | Rule | Purpose | @@ -994,16 +1015,18 @@ Here is the declarations type mapping between OpenAPIv3 and CEL type: | 'string' with format=datetime | timestamp (google.protobuf.Timestamp) | | 'string' with format=duration | duration (google.protobuf.Duration) | -xref: [CEL types](https://github.com/google/cel-spec/blob/v0.6.0/doc/langdef.md#values), [OpenAPI -types](https://swagger.io/specification/#data-types), [Kubernetes Structural Schemas](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema). +xref: [CEL types](https://github.com/google/cel-spec/blob/v0.6.0/doc/langdef.md#values), +[OpenAPI types](https://swagger.io/specification/#data-types), +[Kubernetes Structural Schemas](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#specifying-a-structural-schema). #### Validation functions {#available-validation-functions} Functions available include: - - CEL standard functions, defined in the [list of standard definitions](https://github.com/google/cel-spec/blob/v0.7.0/doc/langdef.md#list-of-standard-definitions) - - CEL standard [macros](https://github.com/google/cel-spec/blob/v0.7.0/doc/langdef.md#macros) - - CEL [extended string function library](https://pkg.go.dev/github.com/google/cel-go@v0.11.2/ext#Strings) - - Kubernetes [CEL extension library](https://pkg.go.dev/k8s.io/apiextensions-apiserver@v0.24.0/pkg/apiserver/schema/cel/library#pkg-functions) + +- CEL standard functions, defined in the [list of standard definitions](https://github.com/google/cel-spec/blob/v0.7.0/doc/langdef.md#list-of-standard-definitions) +- CEL standard [macros](https://github.com/google/cel-spec/blob/v0.7.0/doc/langdef.md#macros) +- CEL [extended string function library](https://pkg.go.dev/github.com/google/cel-go@v0.11.2/ext#Strings) +- Kubernetes [CEL extension library](https://pkg.go.dev/k8s.io/apiextensions-apiserver@v0.24.0/pkg/apiserver/schema/cel/library#pkg-functions) #### Transition rules @@ -1038,7 +1061,8 @@ applied, e.g. "*path*: update rule *rule* cannot be set on schema because the sc schema is not mergeable". Transition rules are only allowed on _correlatable portions_ of a schema. -A portion of the schema is correlatable if all `array` parent schemas are of type `x-kubernetes-list-type=map`; any `set`or `atomic`array parent schemas make it impossible to unambiguously correlate a `self` with `oldSelf`. +A portion of the schema is correlatable if all `array` parent schemas are of type `x-kubernetes-list-type=map`; +any `set`or `atomic`array parent schemas make it impossible to unambiguously correlate a `self` with `oldSelf`. Here are some examples for transition rules: @@ -1070,12 +1094,13 @@ For example, a rule that asserts that `self.foo == 1` does not by itself have an risk of rejection on validation resource budget groups. But if `foo` is a string and you define a validation rule `self.foo.contains("someString")`, that rule takes longer to execute depending on how long `foo` is. -Another example would be if `foo` were an array, and you specified a validation rule `self.foo.all(x, x > 5)`. The cost system always assumes the worst-case scenario if -a limit on the length of `foo` is not given, and this will happen for anything that can be iterated -over (lists, maps, etc.). +Another example would be if `foo` were an array, and you specified a validation rule `self.foo.all(x, x > 5)`. +The cost system always assumes the worst-case scenario if a limit on the length of `foo` is not +given, and this will happen for anything that can be iterated over (lists, maps, etc.). Because of this, it is considered best practice to put a limit via `maxItems`, `maxProperties`, and -`maxLength` for anything that will be processed in a validation rule in order to prevent validation errors during cost estimation. For example, given this schema with one rule: +`maxLength` for anything that will be processed in a validation rule in order to prevent validation +errors during cost estimation. For example, given this schema with one rule: ```yaml openAPIV3Schema: @@ -1090,10 +1115,11 @@ openAPIV3Schema: ``` then the API server rejects this rule on validation budget grounds with error: + ``` - spec.validation.openAPIV3Schema.properties[spec].properties[foo].x-kubernetes-validations[0].rule: Forbidden: - CEL rule exceeded budget by more than 100x (try simplifying the rule, or adding maxItems, maxProperties, and - maxLength where arrays, maps, and strings are used) +spec.validation.openAPIV3Schema.properties[spec].properties[foo].x-kubernetes-validations[0].rule: Forbidden: +CEL rule exceeded budget by more than 100x (try simplifying the rule, or adding maxItems, maxProperties, and +maxLength where arrays, maps, and strings are used) ``` The rejection happens because `self.all` implies calling `contains()` on every string in `foo`, @@ -1136,7 +1162,8 @@ openAPIV3Schema: ``` If a list inside of a list has a validation rule that uses `self.all`, that is significantly more expensive -than a non-nested list with the same rule. A rule that would have been allowed on a non-nested list might need lower limits set on both nested lists in order to be allowed. For example, even without having limits set, +than a non-nested list with the same rule. A rule that would have been allowed on a non-nested list might need +lower limits set on both nested lists in order to be allowed. For example, even without having limits set, the following rule is allowed: ```yaml @@ -1247,15 +1274,20 @@ Defaulting happens on the object * when reading from etcd using the storage version defaults, * after mutating admission plugins with non-empty patches using the admission webhook object version defaults. -Defaults applied when reading data from etcd are not automatically written back to etcd. An update request via the API is required to persist those defaults back into etcd. +Defaults applied when reading data from etcd are not automatically written back to etcd. +An update request via the API is required to persist those defaults back into etcd. Default values must be pruned (with the exception of defaults for `metadata` fields) and must validate against a provided schema. -Default values for `metadata` fields of `x-kubernetes-embedded-resources: true` nodes (or parts of a default value covering `metadata`) are not pruned during CustomResourceDefinition creation, but through the pruning step during handling of requests. +Default values for `metadata` fields of `x-kubernetes-embedded-resources: true` nodes (or parts of +a default value covering `metadata`) are not pruned during CustomResourceDefinition creation, but +through the pruning step during handling of requests. #### Defaulting and Nullable -**New in 1.20:** null values for fields that either don't specify the nullable flag, or give it a `false` value, will be pruned before defaulting happens. If a default is present, it will be applied. When nullable is `true`, null values will be conserved and won't be defaulted. +**New in 1.20:** null values for fields that either don't specify the nullable flag, or give it a +`false` value, will be pruned before defaulting happens. If a default is present, it will be +applied. When nullable is `true`, null values will be conserved and won't be defaulted. For example, given the OpenAPI schema below: @@ -1293,13 +1325,20 @@ spec: bar: null ``` -with `foo` pruned and defaulted because the field is non-nullable, `bar` maintaining the null value due to `nullable: true`, and `baz` pruned because the field is non-nullable and has no default. +with `foo` pruned and defaulted because the field is non-nullable, `bar` maintaining the null +value due to `nullable: true`, and `baz` pruned because the field is non-nullable and has no +default. ### Publish Validation Schema in OpenAPI v2 -CustomResourceDefinition [OpenAPI v3 validation schemas](#validation) which are [structural](#specifying-a-structural-schema) and [enable pruning](#field-pruning) are published as part of the [OpenAPI v2 spec](/docs/concepts/overview/kubernetes-api/#openapi-and-swagger-definitions) from Kubernetes API server. +CustomResourceDefinition [OpenAPI v3 validation schemas](#validation) which are +[structural](#specifying-a-structural-schema) and [enable pruning](#field-pruning) are published +as part of the [OpenAPI v2 spec](/docs/concepts/overview/kubernetes-api/#openapi-and-swagger-definitions) +from Kubernetes API server. -The [kubectl](/docs/reference/kubectl/) command-line tool consumes the published schema to perform client-side validation (`kubectl create` and `kubectl apply`), schema explanation (`kubectl explain`) on custom resources. The published schema can be consumed for other purposes as well, like client generation or documentation. +The [kubectl](/docs/reference/kubectl/) command-line tool consumes the published schema to perform +client-side validation (`kubectl create` and `kubectl apply`), schema explanation (`kubectl explain`) +on custom resources. The published schema can be consumed for other purposes as well, like client generation or documentation. The OpenAPI v3 validation schema is converted to OpenAPI v2 schema, and show up in `definitions` and `paths` fields in the [OpenAPI v2 spec](/docs/concepts/overview/kubernetes-api/#openapi-and-swagger-definitions). @@ -1309,9 +1348,13 @@ kubectl in previous 1.13 version. These modifications prevent kubectl from being valid OpenAPI schemas that it doesn't understand. The conversion won't modify the validation schema defined in CRD, and therefore won't affect [validation](#validation) in the API server. -1. The following fields are removed as they aren't supported by OpenAPI v2 (in future versions OpenAPI v3 will be used without these restrictions) +1. The following fields are removed as they aren't supported by OpenAPI v2 + (in future versions OpenAPI v3 will be used without these restrictions) + - The fields `allOf`, `anyOf`, `oneOf` and `not` are removed -2. If `nullable: true` is set, we drop `type`, `nullable`, `items` and `properties` because OpenAPI v2 is not able to express nullable. To avoid kubectl to reject good objects, this is necessary. + +2. If `nullable: true` is set, we drop `type`, `nullable`, `items` and `properties` because OpenAPI v2 is + not able to express nullable. To avoid kubectl to reject good objects, this is necessary. ### Additional printer columns @@ -1402,7 +1445,8 @@ differentiates between columns shown in standard view or wide view (using the `- #### Type -A column's `type` field can be any of the following (compare [OpenAPI v3 data types](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#dataTypes)): +A column's `type` field can be any of the following (compare +[OpenAPI v3 data types](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#dataTypes)): - `integer` – non-floating-point numbers - `number` – floating point numbers @@ -1495,8 +1539,9 @@ the status replica value in the `/scale` subresource will default to 0. - It must be set to work with HPA. - Only JSONPaths under `.status` or `.spec` and with the dot notation are allowed. - If there is no value under the `labelSelectorPath` in the custom resource, -the status selector value in the `/scale` subresource will default to the empty string. - - The field pointed by this JSON path must be a string field (not a complex selector struct) which contains a serialized label selector in string form. + the status selector value in the `/scale` subresource will default to the empty string. + - The field pointed by this JSON path must be a string field (not a complex selector struct) + which contains a serialized label selector in string form. In the following example, both status and scale subresources are enabled. @@ -1703,3 +1748,4 @@ crontabs/my-new-cron-object 3s * Serve [multiple versions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning/) of a CustomResourceDefinition. + diff --git a/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md b/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md index e37e5b6569..e99ea5473c 100644 --- a/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md +++ b/content/en/docs/tasks/job/automated-tasks-with-cron-jobs.md @@ -13,7 +13,8 @@ CronJobs was promoted to general availability in Kubernetes v1.21. If you are us Kubernetes, please refer to the documentation for the version of Kubernetes that you are using, so that you see accurate information. Older Kubernetes versions do not support the `batch/v1` CronJob API. -You can use a {{< glossary_tooltip text="CronJob" term_id="cronjob" >}} to run {{< glossary_tooltip text="Jobs" term_id="job" >}} on a time-based schedule. +You can use a {{< glossary_tooltip text="CronJob" term_id="cronjob" >}} to run {{< glossary_tooltip text="Jobs" term_id="job" >}} +on a time-based schedule. These automated jobs run like [Cron](https://en.wikipedia.org/wiki/Cron) tasks on a Linux or UNIX system. Cron jobs are useful for creating periodic and recurring tasks, like running backups or sending emails. @@ -87,6 +88,7 @@ You can stop watching the job and view the cron job again to see that it schedul ```shell kubectl get cronjob hello ``` + The output is similar to this: ``` @@ -94,7 +96,8 @@ NAME SCHEDULE SUSPEND ACTIVE LAST SCHEDULE AGE hello */1 * * * * False 0 50s 75s ``` -You should see that the cron job `hello` successfully scheduled a job at the time specified in `LAST SCHEDULE`. There are currently 0 active jobs, meaning that the job has completed or failed. +You should see that the cron job `hello` successfully scheduled a job at the time specified in +`LAST SCHEDULE`. There are currently 0 active jobs, meaning that the job has completed or failed. Now, find the pods that the last scheduled job created and view the standard output of one of the pods. @@ -127,7 +130,7 @@ kubectl delete cronjob hello ``` Deleting the cron job removes all the jobs and pods it created and stops it from creating additional jobs. -You can read more about removing jobs in [garbage collection](/docs/concepts/workloads/controllers/garbage-collection/). +You can read more about removing jobs in [garbage collection](/docs/concepts/architecture/garbage-collection/). ## Writing a Cron Job Spec @@ -144,7 +147,8 @@ All modifications to a cron job, especially its `.spec`, are applied only to the ### Schedule The `.spec.schedule` is a required field of the `.spec`. -It takes a [Cron](https://en.wikipedia.org/wiki/Cron) format string, such as `0 * * * *` or `@hourly`, as schedule time of its jobs to be created and executed. +It takes a [Cron](https://en.wikipedia.org/wiki/Cron) format string, such as `0 * * * *` or `@hourly`, +as schedule time of its jobs to be created and executed. The format also includes extended "Vixie cron" step values. As explained in the [FreeBSD manual](https://www.freebsd.org/cgi/man.cgi?crontab%285%29): @@ -157,13 +161,15 @@ The format also includes extended "Vixie cron" step values. As explained in the > asterisk, so if you want to say "every two hours", just use `*/2`. {{< note >}} -A question mark (`?`) in the schedule has the same meaning as an asterisk `*`, that is, it stands for any of available value for a given field. +A question mark (`?`) in the schedule has the same meaning as an asterisk `*`, that is, +it stands for any of available value for a given field. {{< /note >}} ### Job Template The `.spec.jobTemplate` is the template for the job, and it is required. -It has exactly the same schema as a [Job](/docs/concepts/workloads/controllers/job/), except that it is nested and does not have an `apiVersion` or `kind`. +It has exactly the same schema as a [Job](/docs/concepts/workloads/controllers/job/), except that +it is nested and does not have an `apiVersion` or `kind`. For information about writing a job `.spec`, see [Writing a Job Spec](/docs/concepts/workloads/controllers/job/#writing-a-job-spec). ### Starting Deadline @@ -188,8 +194,10 @@ It specifies how to treat concurrent executions of a job that is created by this The spec may specify only one of the following concurrency policies: * `Allow` (default): The cron job allows concurrently running jobs -* `Forbid`: The cron job does not allow concurrent runs; if it is time for a new job run and the previous job run hasn't finished yet, the cron job skips the new job run -* `Replace`: If it is time for a new job run and the previous job run hasn't finished yet, the cron job replaces the currently running job run with a new job run +* `Forbid`: The cron job does not allow concurrent runs; if it is time for a new job run and the + previous job run hasn't finished yet, the cron job skips the new job run +* `Replace`: If it is time for a new job run and the previous job run hasn't finished yet, the + cron job replaces the currently running job run with a new job run Note that concurrency policy only applies to the jobs created by the same cron job. If there are multiple cron jobs, their respective jobs are always allowed to run concurrently. @@ -203,13 +211,15 @@ Defaults to false. {{< caution >}} Executions that are suspended during their scheduled time count as missed jobs. -When `.spec.suspend` changes from `true` to `false` on an existing cron job without a [starting deadline](#starting-deadline), the missed jobs are scheduled immediately. +When `.spec.suspend` changes from `true` to `false` on an existing cron job without a +[starting deadline](#starting-deadline), the missed jobs are scheduled immediately. {{< /caution >}} ### Jobs History Limits The `.spec.successfulJobsHistoryLimit` and `.spec.failedJobsHistoryLimit` fields are optional. These fields specify how many completed and failed jobs should be kept. -By default, they are set to 3 and 1 respectively. Setting a limit to `0` corresponds to keeping none of the corresponding kind of jobs after they finish. +By default, they are set to 3 and 1 respectively. Setting a limit to `0` corresponds to keeping +none of the corresponding kind of jobs after they finish. diff --git a/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md b/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md index a4a145f5b4..dc8aef2857 100644 --- a/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md +++ b/content/en/docs/tasks/run-application/force-delete-stateful-set-pod.md @@ -51,7 +51,7 @@ Pods may also enter these states when the user attempts graceful deletion of a P on an unreachable Node. The only ways in which a Pod in such a state can be removed from the apiserver are as follows: -* The Node object is deleted (either by you, or by the [Node Controller](/docs/concepts/architecture/nodes/)). +* The Node object is deleted (either by you, or by the [Node Controller](/docs/concepts/architecture/nodes/#node-controller)). * The kubelet on the unresponsive Node starts responding, kills the Pod and removes the entry from the apiserver. * Force deletion of the Pod by the user. diff --git a/content/en/docs/tasks/run-application/run-replicated-stateful-application.md b/content/en/docs/tasks/run-application/run-replicated-stateful-application.md index 8d9e754c2e..89127691e9 100644 --- a/content/en/docs/tasks/run-application/run-replicated-stateful-application.md +++ b/content/en/docs/tasks/run-application/run-replicated-stateful-application.md @@ -206,7 +206,7 @@ Ready before starting Pod `N+1`. After the init containers complete successfully, the regular containers run. The MySQL Pods consist of a `mysql` container that runs the actual `mysqld` server, and an `xtrabackup` container that acts as a -[sidecar](https://kubernetes.io/blog/2015/06/the-distributed-system-toolkit-patterns). +[sidecar](/blog/2015/06/the-distributed-system-toolkit-patterns). The `xtrabackup` sidecar looks at the cloned data files and determines if it's necessary to initialize MySQL replication on the replica. diff --git a/content/en/docs/tasks/service-catalog/_index.md b/content/en/docs/tasks/service-catalog/_index.md deleted file mode 100644 index 77e5fa25e4..0000000000 --- a/content/en/docs/tasks/service-catalog/_index.md +++ /dev/null @@ -1,6 +0,0 @@ ---- -title: "Service Catalog" -description: Install the Service Catalog extension API. -weight: 150 ---- - diff --git a/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md b/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md deleted file mode 100644 index b01f380a1a..0000000000 --- a/content/en/docs/tasks/service-catalog/install-service-catalog-using-helm.md +++ /dev/null @@ -1,116 +0,0 @@ ---- -title: Install Service Catalog using Helm -reviewers: -- chenopis -content_type: task ---- - - -{{< glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" >}} - -Use [Helm](https://helm.sh/) to install Service Catalog on your Kubernetes cluster. -Up to date information on this process can be found at the -[kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog/blob/master/docs/install.md) repo. - -## {{% heading "prerequisites" %}} - -* Understand the key concepts of [Service Catalog](/docs/concepts/extend-kubernetes/service-catalog/). -* Service Catalog requires a Kubernetes cluster running version 1.7 or higher. -* You must have a Kubernetes cluster with cluster DNS enabled. - * If you are using a cloud-based Kubernetes cluster or {{< glossary_tooltip text="Minikube" term_id="minikube" >}}, you may already have cluster DNS enabled. - * If you are using `hack/local-up-cluster.sh`, ensure that the `KUBE_ENABLE_CLUSTER_DNS` environment variable is set, then run the install script. -* [Install and setup kubectl](/docs/tasks/tools/) v1.7 or higher. Make sure it is configured to connect to the Kubernetes cluster. -* Install [Helm](https://helm.sh/) v2.7.0 or newer. - * Follow the [Helm install instructions](https://helm.sh/docs/intro/install/). - * If you already have an appropriate version of Helm installed, execute `helm init` to install Tiller, the server-side component of Helm. - - - - - -## Add the service-catalog Helm repository - -Once Helm is installed, add the *service-catalog* Helm repository to your local machine by executing the following command: - -```shell -helm repo add svc-cat https://kubernetes-sigs.github.io/service-catalog -``` - -Check to make sure that it installed successfully by executing the following command: - -```shell -helm search repo service-catalog -``` - -If the installation was successful, the command should output the following: - -``` -NAME CHART VERSION APP VERSION DESCRIPTION -svc-cat/catalog 0.2.1 service-catalog API server and controller-manager helm chart -svc-cat/catalog-v0.2 0.2.2 service-catalog API server and controller-manager helm chart -``` - -## Enable RBAC - -Your Kubernetes cluster must have RBAC enabled, which requires your Tiller Pod(s) to have `cluster-admin` access. - -When using Minikube v0.25 or older, you must run Minikube with RBAC explicitly enabled: - -```shell -minikube start --extra-config=apiserver.Authorization.Mode=RBAC -``` - -When using Minikube v0.26+, run: - -```shell -minikube start -``` - -With Minikube v0.26+, do not specify `--extra-config`. The flag has since been changed to --extra-config=apiserver.authorization-mode and Minikube now uses RBAC by default. Specifying the older flag may cause the start command to hang. - -If you are using `hack/local-up-cluster.sh`, set the `AUTHORIZATION_MODE` environment variable with the following values: - -``` -AUTHORIZATION_MODE=Node,RBAC hack/local-up-cluster.sh -O -``` - -By default, `helm init` installs the Tiller Pod into the `kube-system` namespace, with Tiller configured to use the `default` service account. - -{{< note >}} -If you used the `--tiller-namespace` or `--service-account` flags when running `helm init`, the `--serviceaccount` flag in the following command needs to be adjusted to reference the appropriate namespace and ServiceAccount name. -{{< /note >}} - -Configure Tiller to have `cluster-admin` access: - -```shell -kubectl create clusterrolebinding tiller-cluster-admin \ - --clusterrole=cluster-admin \ - --serviceaccount=kube-system:default -``` - - -## Install Service Catalog in your Kubernetes cluster - -Install Service Catalog from the root of the Helm repository using the following command: - -{{< tabs name="helm-versions" >}} -{{% tab name="Helm version 3" %}} -```shell -helm install catalog svc-cat/catalog --namespace catalog -``` -{{% /tab %}} -{{% tab name="Helm version 2" %}} -```shell -helm install svc-cat/catalog --name catalog --namespace catalog -``` -{{% /tab %}} -{{< /tabs >}} - - - -## {{% heading "whatsnext" %}} - -* View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers). -* Explore the [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) project. - - diff --git a/content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md b/content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md deleted file mode 100644 index a724d5b17b..0000000000 --- a/content/en/docs/tasks/service-catalog/install-service-catalog-using-sc.md +++ /dev/null @@ -1,80 +0,0 @@ ---- -title: Install Service Catalog using SC -reviewers: -- chenopis -content_type: task ---- - - -{{< glossary_definition term_id="service-catalog" length="all" prepend="Service Catalog is" >}} - -You can use the GCP [Service Catalog Installer](https://github.com/GoogleCloudPlatform/k8s-service-catalog#installation) -tool to easily install or uninstall Service Catalog on your Kubernetes cluster, linking it to -Google Cloud projects. - -Service Catalog can work with any kind of managed service, not only Google Cloud. - -## {{% heading "prerequisites" %}} - -* Understand the key concepts of [Service Catalog](/docs/concepts/extend-kubernetes/service-catalog/). -* Install [Go 1.6+](https://golang.org/dl/) and set the `GOPATH`. -* Install the [cfssl](https://github.com/cloudflare/cfssl) tool needed for generating SSL artifacts. -* Service Catalog requires Kubernetes version 1.7+. -* [Install and setup kubectl](/docs/tasks/tools/) so that it is configured to connect to a Kubernetes v1.7+ cluster. -* The kubectl user must be bound to the *cluster-admin* role for it to install Service Catalog. To ensure that this is true, run the following command: - - kubectl create clusterrolebinding cluster-admin-binding --clusterrole=cluster-admin --user= - - - - - -## Install `sc` in your local environment - -The installer runs on your local computer as a CLI tool named `sc`. - -Install using `go get`: - -```shell -go get github.com/GoogleCloudPlatform/k8s-service-catalog/installer/cmd/sc -``` - -`sc` should now be installed in your `GOPATH/bin` directory. - -## Install Service Catalog in your Kubernetes cluster - -First, verify that all dependencies have been installed. Run: - -```shell -sc check -``` - -If the check is successful, it should return: - -``` -Dependency check passed. You are good to go. -``` - -Next, run the install command and specify the `storageclass` that you want to use for the backup: - -```shell -sc install --etcd-backup-storageclass "standard" -``` - -## Uninstall Service Catalog - -If you would like to uninstall Service Catalog from your Kubernetes cluster using the `sc` tool, run: - -```shell -sc uninstall -``` - - - - -## {{% heading "whatsnext" %}} - -* View [sample service brokers](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers). -* Explore the [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) project. - - diff --git a/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md b/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md index 7691466889..bad390575d 100644 --- a/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md +++ b/content/en/docs/tasks/tls/manual-rotation-of-ca-certificates.md @@ -161,7 +161,7 @@ Configurations with a single API server will experience unavailability while the 1. Check the logs from control plane components, along with the kubelet and the kube-proxy. Ensure those components are not reporting any TLS errors; see - [looking at the logs](/docs/tasks/debug-application-cluster/debug-cluster/#looking-at-logs) for more details. + [looking at the logs](/docs/tasks/debug/debug-cluster/#looking-at-logs) for more details. 1. Validate logs from any aggregated api servers and pods using in-cluster config. diff --git a/content/en/docs/tasks/tools/install-kubectl-linux.md b/content/en/docs/tasks/tools/install-kubectl-linux.md index 7fd52b56f4..d027ab647d 100644 --- a/content/en/docs/tasks/tools/install-kubectl-linux.md +++ b/content/en/docs/tasks/tools/install-kubectl-linux.md @@ -141,7 +141,6 @@ name=Kubernetes baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-\$basearch enabled=1 gpgcheck=1 -repo_gpgcheck=1 gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg EOF sudo yum install -y kubectl diff --git a/content/en/docs/tutorials/security/cluster-level-pss.md b/content/en/docs/tutorials/security/cluster-level-pss.md index 4da0502aca..8a303af651 100644 --- a/content/en/docs/tutorials/security/cluster-level-pss.md +++ b/content/en/docs/tutorials/security/cluster-level-pss.md @@ -19,12 +19,15 @@ to all namespaces in a cluster. To apply Pod Security Standards to specific namespaces, refer to [Apply Pod Security Standards at the namespace level](/docs/tutorials/security/ns-level-pss). +If you are running a version of Kubernetes other than v{{< skew currentVersion >}}, +check the documentation for that version. + ## {{% heading "prerequisites" %}} Install the following on your workstation: - [KinD](https://kind.sigs.k8s.io/docs/user/quick-start/#installation) -- [kubectl](https://kubernetes.io/docs/tasks/tools/) +- [kubectl](/docs/tasks/tools/) ## Choose the right Pod Security Standard to apply @@ -38,12 +41,12 @@ that are most appropriate for your configuration, do the following: 1. Create a cluster with no Pod Security Standards applied: ```shell - kind create cluster --name psa-wo-cluster-pss --image kindest/node:v1.23.0 + kind create cluster --name psa-wo-cluster-pss --image kindest/node:v1.24.0 ``` The output is similar to this: ``` Creating cluster "psa-wo-cluster-pss" ... - ✓ Ensuring node image (kindest/node:v1.23.0) 🖼 + ✓ Ensuring node image (kindest/node:v1.24.0) 🖼 ✓ Preparing nodes 📦 ✓ Writing configuration 📜 ✓ Starting control-plane 🕹️ @@ -245,12 +248,12 @@ following: these Pod Security Standards: ```shell - kind create cluster --name psa-with-cluster-pss --image kindest/node:v1.23.0 --config /tmp/pss/cluster-config.yaml + kind create cluster --name psa-with-cluster-pss --image kindest/node:v1.24.0 --config /tmp/pss/cluster-config.yaml ``` The output is similar to this: ``` Creating cluster "psa-with-cluster-pss" ... - ✓ Ensuring node image (kindest/node:v1.23.0) 🖼 + ✓ Ensuring node image (kindest/node:v1.24.0) 🖼 ✓ Preparing nodes 📦 ✓ Writing configuration 📜 ✓ Starting control-plane 🕹️ diff --git a/content/en/examples/pods/pod-with-affinity-anti-affinity.yaml b/content/en/examples/pods/pod-with-affinity-anti-affinity.yaml index a7d14b2d6f..5dcc7693b6 100644 --- a/content/en/examples/pods/pod-with-affinity-anti-affinity.yaml +++ b/content/en/examples/pods/pod-with-affinity-anti-affinity.yaml @@ -8,10 +8,11 @@ spec: requiredDuringSchedulingIgnoredDuringExecution: nodeSelectorTerms: - matchExpressions: - - key: kubernetes.io/os + - key: topology.kubernetes.io/zone operator: In values: - - linux + - antarctica-east1 + - antarctica-west1 preferredDuringSchedulingIgnoredDuringExecution: - weight: 1 preference: @@ -29,4 +30,4 @@ spec: - key-2 containers: - name: with-node-affinity - image: k8s.gcr.io/pause:2.0 \ No newline at end of file + image: k8s.gcr.io/pause:2.0 diff --git a/content/en/includes/task-tutorial-prereqs.md b/content/en/includes/task-tutorial-prereqs.md index b5d3c0abf3..db8edf8505 100644 --- a/content/en/includes/task-tutorial-prereqs.md +++ b/content/en/includes/task-tutorial-prereqs.md @@ -4,5 +4,5 @@ cluster, you can create one by using [minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/) or you can use one of these Kubernetes playgrounds: -* [Katacoda](https://www.katacoda.com/courses/kubernetes/playground) +* [Killercoda](https://killercoda.com/playgrounds/scenario/kubernetes) * [Play with Kubernetes](http://labs.play-with-k8s.com/) diff --git a/content/en/releases/patch-releases.md b/content/en/releases/patch-releases.md index d0f56d19c3..91bdcc58bb 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 | | --------------------- | -------------------- | ----------- | -| June 2022 | 2022-06-10 | 2022-06-15 | | July 2022 | 2022-07-08 | 2022-07-13 | | August 2022 | 2022-08-12 | 2022-08-17 | | September 2022 | 2022-09-09 | 2022-09-14 | +| October 2022 | 2022-10-07 | 2022-10-12 | ## 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.3 | 2022-07-08 | 2022-07-13 | | | 1.24.2 | 2022-06-10 | 2022-06-15 | | | 1.24.1 | 2022-05-20 | 2022-05-24 | | @@ -104,6 +105,7 @@ End of Life for **1.23** is **2023-02-28**. | Patch Release | Cherry Pick Deadline | Target Date | Note | |---------------|----------------------|-------------|------| +| 1.23.9 | 2022-07-08 | 2022-07-13 | | | 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 | | @@ -121,6 +123,7 @@ End of Life for **1.22** is **2022-10-28** | Patch Release | Cherry Pick Deadline | Target Date | Note | |---------------|----------------------|-------------|------| +| 1.22.12 | 2022-07-08 | 2022-07-13 | | | 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 | | @@ -133,35 +136,13 @@ End of Life for **1.22** is **2022-10-28** | 1.22.2 | 2021-09-10 | 2021-09-15 | | | 1.22.1 | 2021-08-16 | 2021-08-19 | | -### 1.21 - -**1.21** enters maintenance mode on **2022-04-28** - -End of Life for **1.21** is **2022-06-28** - -| Patch Release | Cherry Pick Deadline | Target Date | Note | -| ------------- | -------------------- | ----------- | ------------------------------------------------------------------------ | -| 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 These releases are no longer supported. | Minor Version | Final Patch Release | EOL Date | Note | | ------------- | ------------------- | ---------- | ---------------------------------------------------------------------- | +| 1.21 | 1.21.14 | 2022-06-28 | | | 1.20 | 1.20.15 | 2022-02-28 | | | 1.19 | 1.19.16 | 2021-10-28 | | | 1.18 | 1.18.20 | 2021-06-18 | Created to resolve regression introduced in 1.18.19 | diff --git a/content/en/releases/release-managers.md b/content/en/releases/release-managers.md index b3a562c9e3..1c4eba3863 100644 --- a/content/en/releases/release-managers.md +++ b/content/en/releases/release-managers.md @@ -69,7 +69,7 @@ Release Managers are responsible for: - Reviewing cherry picks - Ensuring the release branch stays healthy and that no unintended patch gets merged -- Mentoring the [Release Manager Associates](#associates) group +- Mentoring the [Release Manager Associates](#release-manager-associates) group - Actively developing features and maintaining the code in k/release - Supporting Release Manager Associates and contributors through actively participating in the Buddy program @@ -212,7 +212,7 @@ Example: [1.15 Release Team](https://git.k8s.io/sig-release/releases/release-1.1 [handbook-packaging]: https://git.k8s.io/sig-release/release-engineering/packaging.md [handbook-patch-release]: https://git.k8s.io/sig-release/release-engineering/role-handbooks/patch-release-team.md [k-sig-release-releases]: https://git.k8s.io/sig-release/releases -[patches]: /patch-releases.md +[patches]: /releases/patch-releases/ [src]: https://git.k8s.io/community/committee-security-response/README.md [release-team]: https://git.k8s.io/sig-release/release-team/README.md [security-release-process]: https://git.k8s.io/security/security-release-process.md diff --git a/content/en/releases/release.md b/content/en/releases/release.md index f69424b7f9..6775401a11 100644 --- a/content/en/releases/release.md +++ b/content/en/releases/release.md @@ -281,7 +281,7 @@ Issues are marked as targeting a milestone via the Prow "/milestone" command. The Release Team's [Bug Triage Lead](https://git.k8s.io/sig-release/release-team/role-handbooks/bug-triage/README.md) and overall community watch incoming issues and triage them, as described in the contributor guide section on -[issue triage](/contributors/guide/issue-triage.md). +[issue triage](https://k8s.dev/docs/guide/issue-triage/). Marking issues with the milestone provides the community better visibility regarding when an issue was observed and by when the community feels it must be @@ -355,11 +355,11 @@ issue kind labels must be set: - `kind/feature`: New functionality. - `kind/flake`: CI test case is showing intermittent failures. -[cherry-picks]: /contributors/devel/sig-release/cherry-picks.md +[cherry-picks]: https://git.k8s.io/community/contributors/devel/sig-release/cherry-picks.md [code-freeze]: https://git.k8s.io/sig-release/releases/release_phases.md#code-freeze [enhancements-freeze]: https://git.k8s.io/sig-release/releases/release_phases.md#enhancements-freeze [exceptions]: https://git.k8s.io/sig-release/releases/release_phases.md#exceptions [keps]: https://git.k8s.io/enhancements/keps -[release-managers]: https://kubernetes.io/releases/release-managers/ +[release-managers]: /releases/release-managers/ [release-team]: https://git.k8s.io/sig-release/release-team -[sig-list]: /sig-list.md \ No newline at end of file +[sig-list]: https://k8s.dev/sigs diff --git a/content/en/releases/version-skew-policy.md b/content/en/releases/version-skew-policy.md index 730f892c80..4d0fa8c9d9 100644 --- a/content/en/releases/version-skew-policy.md +++ b/content/en/releases/version-skew-policy.md @@ -26,7 +26,7 @@ For more information, see [Kubernetes Release Versioning](https://git.k8s.io/des The Kubernetes project maintains release branches for the most recent three minor releases ({{< skew currentVersion >}}, {{< skew currentVersionAddMinor -1 >}}, {{< skew currentVersionAddMinor -2 >}}). 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://kubernetes.io/releases/patch-releases/#cadence), plus additional urgent releases, when required. +Patch releases are cut from those branches at a [regular cadence](/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/containers/container-environment-variables.md b/content/es/docs/concepts/containers/container-environment-variables.md index 7f35309329..f266ff7796 100644 --- a/content/es/docs/concepts/containers/container-environment-variables.md +++ b/content/es/docs/concepts/containers/container-environment-variables.md @@ -48,7 +48,7 @@ FOO_SERVICE_HOST= FOO_SERVICE_PORT= ``` Los servicios tienen direcciones IP dedicadas y están disponibles para el Container a través de DNS, -si el [complemento para DNS](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/) está habilitado. +si el [complemento para DNS](http://releases.k8s.io/master/cluster/addons/dns/) está habilitado. diff --git a/content/es/docs/concepts/services-networking/service.md b/content/es/docs/concepts/services-networking/service.md index 5ef231df3a..7329aa1075 100644 --- a/content/es/docs/concepts/services-networking/service.md +++ b/content/es/docs/concepts/services-networking/service.md @@ -54,7 +54,7 @@ Para aplicaciones no nativas, Kubernetes ofrece una manera de colocar un puerto Un Service en Kubernetes es un objeto REST, similar a un Pod. Como todos los objetos REST, puedes hacer un `Post` a una definición de un Service al servidor API para crear una nueva instancia. EL nombre de un objeto Service debe ser un [nombre RFC 1035 válido](/docs/concepts/overview/working-with-objects/names#rfc-1035-label-names). -Por ejemplo, supongamos que tienes un conjunto de Pods en el que cada uno escucha el puerto TCP 9376 y contiene la etiqueta `app=MyApp`: +Por ejemplo, supongamos que tienes un conjunto de Pods en el que cada uno escucha el puerto TCP 9376 y contiene la etiqueta `app.kubernetes.io/name=MyApp`: ```yaml apiVersion: v1 @@ -63,14 +63,14 @@ metadata: name: mi-servicio spec: selector: - app: MyApp + app.kubernetes.io/name: MyApp ports: - protocol: TCP port: 80 targetPort: 9376 ``` -Esta especificación crea un nuevo objeto Service llamado "mi-servicio", que apunta via TCP al puerto 9376 de cualquier Pod con la etiqueta `app=MyApp`. +Esta especificación crea un nuevo objeto Service llamado "mi-servicio", que apunta via TCP al puerto 9376 de cualquier Pod con la etiqueta `app.kubernetes.io/name=MyApp`. Kubernetes asigna una dirección IP a este Service (Algunas veces llamado "Cluster IP"), la cual es usada por los proxies de los Services (mira [IPs Virtuales y proxies de servicios](#virtual-ips-and-service-proxies) abajo). @@ -297,7 +297,7 @@ spec: {{< note >}} Como con los {{< glossary_tooltip term_id="name" text="nombres">}} de Kubernetes en general, los nombres para los puertos deben contener alfanuméricos en minúsculas y `-`. Los nombres de puertos deben comenzar y terminar con un carácter alfanumérico. -Por ejemplo, los nombres `123-abc` and `web` son válidos, pero `123_abc` y `-web` no lo son. +Por ejemplo, los nombres `123-abc` and `web` son válidos, pero `123_abc` y `-web` no lo son. {{< /note >}} ## Eligiendo tu propia dirección IP @@ -799,11 +799,11 @@ NLB solo funciona con ciertas clases de instancias; mira la [documentación AWS] A diferencia de los balanceadores de cargas, el balanceador de carga de red (NLB) reenvía la dirección IP del cliente a través del nodo. Si el campo `.spec.externalTrafficPolicy` está fijado a `clúster`, la dirección IP del cliente no es propagada a los Pods finales. Al fijar `.spec.externalTrafficPolicy` en `Local`, la dirección IP del cliente se propaga a los Pods finales, -pero esto puede resultar a una distribución de tráfico desigual. Los nodos sin ningún Pod para un Service particular de tipo LoadBalancer fallarán en la comprobación de estado del grupo objetivo del NLB en el puerto `.spec.healthCheckNodePort` y no recibirán ningún tráfico. +pero esto puede resultar a una distribución de tráfico desigual. Los nodos sin ningún Pod para un Service particular de tipo LoadBalancer fallarán en la comprobación de estado del grupo objetivo del NLB en el puerto `.spec.healthCheckNodePort` y no recibirán ningún tráfico. -Para conseguir trafico equilibrado, usa un DaemonSet o especifica [pod anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) para no localizar en el mismo nodo. +Para conseguir trafico equilibrado, usa un DaemonSet o especifica [pod anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) para no localizar en el mismo nodo. -También puedes usar Services NLB con la anotación del [balanceador de carga interno](/docs/concepts/services-networking/service/#internal-load-balancer) +También puedes usar Services NLB con la anotación del [balanceador de carga interno](/docs/concepts/services-networking/service/#internal-load-balancer) Para permitir que el tráfico del cliente alcance las instancias detrás del NLB, los grupos de seguridad del Nodo se modifican con las siguientes reglas de IP: @@ -822,7 +822,7 @@ spec: ``` {{< note >}} -Si no se establece `.spec.loadBalancerSourceRanges`, Kubernetes permite el tráfico +Si no se establece `.spec.loadBalancerSourceRanges`, Kubernetes permite el tráfico desde `0.0.0.0/0` a los Grupos de Seguridad del Nodo. Si los nodos tienen direcciones IP públicas, ten en cuenta que el tráfico que no viene del NLB también puede alcanzar todas las instancias en esos grupos de seguridad modificados. {{< /note >}} @@ -865,9 +865,9 @@ Hay otras anotaciones para administrar balanceadores de carga en la nube en TKE ### Tipo ExternalName {#externalname} -Los Services de tipo ExternalName mapean un Service a un nombre DNS, no a un selector típico como `mi-servicio` o `cassandra`. Estos Services se especifican con el parámetro `spec.externalName`. +Los Services de tipo ExternalName mapean un Service a un nombre DNS, no a un selector típico como `mi-servicio` o `cassandra`. Estos Services se especifican con el parámetro `spec.externalName`. -Esta definición de Service, por ejemplo, mapea el Service `mi-Servicio` en el namespace `prod` a `my.database.example.com`: +Esta definición de Service, por ejemplo, mapea el Service `mi-Servicio` en el namespace `prod` a `my.database.example.com`: ```yaml apiVersion: v1 @@ -884,7 +884,7 @@ spec: ExternalName acepta una cadena de texto IPv4, pero como un nombre DNS compuesto de dígitos, no como una dirección IP. ExternalNames que se parecen a direcciones IPv4 no se resuelven por el CoreDNS o ingress-nginx, ya que ExternalName se usa para especificar un nombre DNS canónico. Al fijar una dirección IP, considera usar [headless Services](#headless-services). {{< /note >}} -Cuando busca el host `mi-servicio.prod.svc.cluster.local`, el Service DNS del clúster devuelve un registro `CNAME` con el valor `my.database.example.com`. Acceder a `mi-servicio` funciona de la misma manera que otros Services, pero con la diferencia crucial de que la redirección ocurre a nivel del DNS en lugar reenviarlo o redirigirlo. Si posteriormente decides mover tu base de datos al clúster, puedes iniciar sus Pods, agregar selectores apropiados o endpoints, y cambiar el `type` del Service. +Cuando busca el host `mi-servicio.prod.svc.cluster.local`, el Service DNS del clúster devuelve un registro `CNAME` con el valor `my.database.example.com`. Acceder a `mi-servicio` funciona de la misma manera que otros Services, pero con la diferencia crucial de que la redirección ocurre a nivel del DNS en lugar reenviarlo o redirigirlo. Si posteriormente decides mover tu base de datos al clúster, puedes iniciar sus Pods, agregar selectores apropiados o endpoints, y cambiar el `type` del Service. {{< warning >}} @@ -894,15 +894,15 @@ Para protocolos que usan el nombre del host esta diferencia puede llevar a error {{< /warning >}} {{< note >}} -Esta sección está en deuda con el artículo de blog [Kubernetes Tips - Part 1](https://akomljen.com/kubernetes-tips-part-1/) de [Alen Komljen](https://akomljen.com/). +Esta sección está en deuda con el artículo de blog [Kubernetes Tips - Part 1](https://akomljen.com/kubernetes-tips-part-1/) de [Alen Komljen](https://akomljen.com/). {{< /note >}} ### IPs Externas -Si existen IPs externas que enrutan hacia uno o más nodos del clúster, los Services de Kubernetes pueden ser expuestos en esas `externalIPs`. El tráfico que ingresa al clúster con la IP externa (como IP de destino), en el puerto del Service, será enrutado a uno de estos endpoints del Service. Las `externalIPs` no son administradas por Kubernetes y son responsabilidad del administrador del clúster. +Si existen IPs externas que enrutan hacia uno o más nodos del clúster, los Services de Kubernetes pueden ser expuestos en esas `externalIPs`. El tráfico que ingresa al clúster con la IP externa (como IP de destino), en el puerto del Service, será enrutado a uno de estos endpoints del Service. Las `externalIPs` no son administradas por Kubernetes y son responsabilidad del administrador del clúster. En la especificación del Service, las `externalIPs` se pueden especificar junto con cualquiera de los `ServiceTypes`. -En el ejemplo de abajo, "`mi-servicio`" puede ser accedido por clientes en "`80.11.12.10:80`" (`externalIP:port`) +En el ejemplo de abajo, "`mi-servicio`" puede ser accedido por clientes en "`80.11.12.10:80`" (`externalIP:port`) ```yaml apiVersion: v1 @@ -911,7 +911,7 @@ metadata: name: mi-servicio spec: selector: - app: MyApp + app.kubernetes.io/name: MyApp ports: - name: http protocol: TCP @@ -925,21 +925,21 @@ spec: Usar el proxy del userspace for VIPs funciona en pequeña y mediana escala, pero no escalará a clústeres muy grandes con miles de Services. El tópico [original design proposal for portals](https://github.com/kubernetes/kubernetes/issues/1107) tiene más detalles sobre esto. -Usar el proxy del userspace oculta la dirección IP de origen de un paquete que accede al Service. Esto hace que algún tipo de filtrado (firewalling) sea imposible. El modo proxy iptables no oculta IPs de origen en el clúster, pero aún tiene impacto en clientes que vienen desde un balanceador de carga o un node-port. +Usar el proxy del userspace oculta la dirección IP de origen de un paquete que accede al Service. Esto hace que algún tipo de filtrado (firewalling) sea imposible. El modo proxy iptables no oculta IPs de origen en el clúster, pero aún tiene impacto en clientes que vienen desde un balanceador de carga o un node-port. -El campo `Type` está diseñado como una funcionalidad anidada - cada nivel se agrega al anterior. Esto no es estrictamente requerido en todos los proveedores de la nube (ej. Google Compute Engine no necesita asignar un `NodePort` para que funcione el `LoadBalancer`, pero AWS si) pero la API actual lo requiere. +El campo `Type` está diseñado como una funcionalidad anidada - cada nivel se agrega al anterior. Esto no es estrictamente requerido en todos los proveedores de la nube (ej. Google Compute Engine no necesita asignar un `NodePort` para que funcione el `LoadBalancer`, pero AWS si) pero la API actual lo requiere. ## Implementación de IP Virtual {#the-gory-details-of-virtual-ips} La información previa sería suficiente para muchas personas que quieren usar Services. Sin embargo, ocurren muchas cosas detrás de bastidores que valdría la pena entender. -### Evitar colisiones +### Evitar colisiones Una de las principales filosofías de Kubernetes es que no debe estar expuesto a situaciones que podrían hacer que sus acciones fracasen por su propia culpa. Para el diseño del recurso de Service, esto significa no obligarlo a elegir su propio número de puerto si esa elección puede colisionar con la de otra persona. Eso es un fracaso de aislamiento. Para permitirte elegir un número de puerto en tus Services, debemos asegurarnos que dos Services no puedan colisionar. Kubernetes lo hace asignando a cada Service su propia dirección IP. -Para asegurarse que cada Service recibe una IP única, un asignador interno actualiza atómicamente el mapa global de asignaciones en {{< glossary_tooltip term_id="etcd" >}} antes de crear cada Service. El objeto mapa debe existir en el registro para que los Services obtengan asignaciones de dirección IP, de lo contrario las creaciones fallarán con un mensaje indicando que la dirección IP no pudo ser asignada. +Para asegurarse que cada Service recibe una IP única, un asignador interno actualiza atómicamente el mapa global de asignaciones en {{< glossary_tooltip term_id="etcd" >}} antes de crear cada Service. El objeto mapa debe existir en el registro para que los Services obtengan asignaciones de dirección IP, de lo contrario las creaciones fallarán con un mensaje indicando que la dirección IP no pudo ser asignada. En el plano de control, un controlador de trasfondo es responsable de crear el mapa (requerido para soportar la migración desde versiones más antiguas de Kubernetes que usaban bloqueo en memoria). Kubernetes también utiliza controladores para revisar asignaciones inválidas (ej. debido a la intervención de un administrador) y para limpiar las direcciones IP que ya no son usadas por ningún Service. @@ -947,7 +947,7 @@ En el plano de control, un controlador de trasfondo es responsable de crear el m A diferencia de direcciones IP del Pod, que enrutan a un destino fijo, las IPs del Service no son respondidas por ningún host. En lugar de ello, El kube-proxy usa iptables (lógica de procesamiento de paquetes en Linux) para definir direcciones IP _virtuales_ que se redirigen de forma transparente cuando se necesita. Cuando el cliente se conecta con la VIP, su tráfico es transportado automáticamente al endpoint apropiado. Las variables de entorno y DNS para los Services son pobladas en términos de la dirección IP virtual del Service (y el puerto). -Kube-proxy soporta tres modos — userspace, iptables e IPVS — los cuales operan ligeramente diferente cada uno. +Kube-proxy soporta tres modos — userspace, iptables e IPVS — los cuales operan ligeramente diferente cada uno. #### Userspace @@ -955,11 +955,11 @@ Por ejemplo, considera la aplicación de procesamiento de imágenes descrita arr Cuando un cliente se conecta a la dirección IP virtual del Service, la regla de iptables entra en acción, y redirige los paquetes al propio puerto del proxy. El "proxy del Service" elige un backend, y comienza a redirigir el tráfico desde el cliente al backend. -Esto quiere decir que los dueños del Service pueden elegir cualquier puerto que quieran sin riesgo de colisión. Los clientes pueden conectarse a una IP y un puerto, sin estar conscientes de a cuáles Pods están accediendo. +Esto quiere decir que los dueños del Service pueden elegir cualquier puerto que quieran sin riesgo de colisión. Los clientes pueden conectarse a una IP y un puerto, sin estar conscientes de a cuáles Pods están accediendo. #### iptables -Nuevamente, considera la aplicación de procesamiento de imágenes descrita arriba. Cuando se crea el Service Backend, el plano de control de Kubernetes asigna una dirección IP virtual, por ejemplo 10.0.0.1. Asumiendo que el puerto del servicio es 1234, el Service es observado por todas las instancias del kube-proxy en el clúster. Cuando un proxy mira un nuevo Service, instala una serie de reglas de iptables que redirigen desde la dirección IP virtual a las reglas del Service. Las reglas del Service enlazan a las reglas del Endpoint que redirigen el tráfico (usando NAT de destino) a los backends. +Nuevamente, considera la aplicación de procesamiento de imágenes descrita arriba. Cuando se crea el Service Backend, el plano de control de Kubernetes asigna una dirección IP virtual, por ejemplo 10.0.0.1. Asumiendo que el puerto del servicio es 1234, el Service es observado por todas las instancias del kube-proxy en el clúster. Cuando un proxy mira un nuevo Service, instala una serie de reglas de iptables que redirigen desde la dirección IP virtual a las reglas del Service. Las reglas del Service enlazan a las reglas del Endpoint que redirigen el tráfico (usando NAT de destino) a los backends. Cuando un cliente se conecta a la dirección IP virtual del Service la regla de iptables son aplicadas. A diferencia del modo proxy userspace, el kube-proxy no tiene que estar corriendo para que funcione la dirección IP virtual, y los nodos observan el tráfico que viene desde la dirección IP del cliente sin alteraciones. @@ -1014,11 +1014,11 @@ El kube-proxy no soporta la administración de asociaciones SCTP cuando está en Si tu proveedor de la nube lo soporta, puedes usar un Service en modo LoadBalancer para configurar un proxy invertido HTTP/HTTPS, redirigido a los Endpoints del Service. {{< note >}} -También puedes usar {{< glossary_tooltip term_id="ingress" >}} en lugar de un Service para exponer Services HTTP/HTTPS. +También puedes usar {{< glossary_tooltip term_id="ingress" >}} en lugar de un Service para exponer Services HTTP/HTTPS. {{< /note >}} ### Protocolo PROXY -Si tu proveedor de la nube lo soporta, puedes usar un Service en modo LoadBalancer para configurar un balanceador de carga fuera de Kubernetes mismo, que redirigirá las conexiones prefijadas con [protocolo PROXY](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt). +Si tu proveedor de la nube lo soporta, puedes usar un Service en modo LoadBalancer para configurar un balanceador de carga fuera de Kubernetes mismo, que redirigirá las conexiones prefijadas con [protocolo PROXY](https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt). El balanceador de carga enviará una serie inicial de octetos describiendo la conexión entrante, similar a este ejemplo diff --git a/content/es/docs/concepts/workloads/pods/init-containers.md b/content/es/docs/concepts/workloads/pods/init-containers.md index fafb6ae2f6..2ae5323771 100644 --- a/content/es/docs/concepts/workloads/pods/init-containers.md +++ b/content/es/docs/concepts/workloads/pods/init-containers.md @@ -113,7 +113,7 @@ kind: Pod metadata: name: myapp-pod labels: - app: myapp + app.kubernetes.io/name: MyApp spec: containers: - name: myapp-container @@ -165,7 +165,7 @@ El resultado es similar a esto: Name: myapp-pod Namespace: default [...] -Labels: app=myapp +Labels: app.kubernetes.io/name=MyApp Status: Pending [...] Init Containers: diff --git a/content/es/docs/setup/release/building-from-source.md b/content/es/docs/setup/release/building-from-source.md index 42db05df4c..0ff6152b97 100644 --- a/content/es/docs/setup/release/building-from-source.md +++ b/content/es/docs/setup/release/building-from-source.md @@ -30,7 +30,7 @@ cd kubernetes make release ``` -Para más detalles sobre el proceso de compilación de una release, visita la carpeta kubernetes/kubernetes [`build`](http://releases.k8s.io/{{< param "githubbranch" >}}/build/) +Para más detalles sobre el proceso de compilación de una release, visita la carpeta kubernetes/kubernetes [`build`](http://releases.k8s.io/master/build/) diff --git a/content/es/includes/task-tutorial-prereqs.md b/content/es/includes/task-tutorial-prereqs.md index 7c47e436f3..55ee0fb835 100644 --- a/content/es/includes/task-tutorial-prereqs.md +++ b/content/es/includes/task-tutorial-prereqs.md @@ -1,5 +1,5 @@ Debes tener un cluster Kubernetes a tu dispocición, y la herramienta de línea de comandos `kubectl` debe estar configurada. Si no tienes un cluster, puedes crear uno utilizando [Minikube](/docs/setup/minikube), o puedes utilizar una de las siguientes herramientas en línea: -* [Katacoda](https://www.katacoda.com/courses/kubernetes/playground) +* [Killercoda](https://killercoda.com/playgrounds/scenario/kubernetes) * [Play with Kubernetes](http://labs.play-with-k8s.com/) diff --git a/content/fr/docs/concepts/containers/container-environment.md b/content/fr/docs/concepts/containers/container-environment.md index adad1ab64a..d73e26442d 100644 --- a/content/fr/docs/concepts/containers/container-environment.md +++ b/content/fr/docs/concepts/containers/container-environment.md @@ -49,7 +49,7 @@ FOO_SERVICE_PORT= ``` Les services ont des adresses IP dédiées et sont disponibles pour le conteneur avec le DNS, -si le [module DNS](http://releases.k8s.io/{{< param "githubbranch" >}}/cluster/addons/dns/) est activé.  +si le [module DNS](http://releases.k8s.io/master/cluster/addons/dns/) est activé.  diff --git a/content/fr/docs/concepts/overview/what-is-kubernetes.md b/content/fr/docs/concepts/overview/what-is-kubernetes.md index 07a6c738d8..e962c05dd7 100644 --- a/content/fr/docs/concepts/overview/what-is-kubernetes.md +++ b/content/fr/docs/concepts/overview/what-is-kubernetes.md @@ -46,7 +46,7 @@ C'est pourquoi Kubernetes a également été conçu pour servir de plate-forme e De plus, le [plan de contrôle Kubernetes (control plane)](/docs/concepts/overview/components/) est construit sur les mêmes [APIs](/docs/reference/using-api/api-overview/) que celles accessibles aux développeurs et utilisateurs. -Les utilisateurs peuvent écrire leurs propres contrôleurs (controllers), tels que les [ordonnanceurs (schedulers)](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/devel/scheduler.md), +Les utilisateurs peuvent écrire leurs propres contrôleurs (controllers), tels que les [ordonnanceurs (schedulers)](https://github.com/kubernetes/community/blob/master/contributors/devel/scheduler.md), avec [leurs propres APIs](/docs/concepts/api-extension/custom-resources/) qui peuvent être utilisés par un [outil en ligne de commande](/docs/user-guide/kubectl-overview/). Ce choix de [conception](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) a permis de construire un ensemble d'autres systèmes par dessus Kubernetes. diff --git a/content/fr/docs/concepts/services-networking/service.md b/content/fr/docs/concepts/services-networking/service.md index 9d8484b18e..d8587068fc 100644 --- a/content/fr/docs/concepts/services-networking/service.md +++ b/content/fr/docs/concepts/services-networking/service.md @@ -289,7 +289,7 @@ Kubernetes prend en charge 2 modes principaux de recherche d'un service: les var ### Variables d'environnement Lorsqu'un pod est exécuté sur un nœud, le kubelet ajoute un ensemble de variables d'environnement pour chaque service actif. -Il prend en charge à la fois les variables [Docker links](https://docs.docker.com/userguide/dockerlinks/) (voir [makeLinkVariables](http://releases.k8s.io/{{< param "githubbranch" >}}/pkg/kubelet/envvars/envvars.go#L49)) et plus simplement les variables `{SVCNAME}_SERVICE_HOST` et `{SVCNAME}_SERVICE_PORT`, où le nom du service est en majuscules et les tirets sont convertis en underscore. +Il prend en charge à la fois les variables [Docker links](https://docs.docker.com/userguide/dockerlinks/) (voir [makeLinkVariables](http://releases.k8s.io/master/pkg/kubelet/envvars/envvars.go#L49)) et plus simplement les variables `{SVCNAME}_SERVICE_HOST` et `{SVCNAME}_SERVICE_PORT`, où le nom du service est en majuscules et les tirets sont convertis en underscore. Par exemple, le service `redis-master` qui expose le port TCP 6379 et a reçu l'adresse IP de cluster 10.0.0.11, produit les variables d'environnement suivantes: diff --git a/content/fr/docs/concepts/storage/volumes.md b/content/fr/docs/concepts/storage/volumes.md index 9fc229b5f2..596bb84644 100644 --- a/content/fr/docs/concepts/storage/volumes.md +++ b/content/fr/docs/concepts/storage/volumes.md @@ -137,7 +137,7 @@ Afin d'utiliser cette fonctionnalité, le [Pilote AWS EBS CSI](https://github.co Un type de volume `azureDisk` est utilisé pour monter un disque de données ([Data Disk](https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-linux-about-disks-vhds/)) dans un Pod. -Plus de détails sont disponibles [ici](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_disk/README.md). +Plus de détails sont disponibles [ici](https://github.com/kubernetes/examples/tree/master/staging/volumes/azure_disk/README.md). #### Migration CSI @@ -150,7 +150,7 @@ Afin d'utiliser cette fonctionnalité, le [Pilote Azure Disk CSI](https://github Un type de volume `azureFile` est utilisé pour monter un volume de fichier Microsoft Azure (SMB 2.1 et 3.0) dans un Pod. -Plus de détails sont disponibles [ici](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/azure_file/README.md). +Plus de détails sont disponibles [ici](https://github.com/kubernetes/examples/tree/master/staging/volumes/azure_file/README.md). #### Migration CSI @@ -170,7 +170,7 @@ CephFS peut être monté plusieurs fois en écriture simultanément. Vous devez exécuter votre propre serveur Ceph avec le partage exporté avant de pouvoir l'utiliser. {{< /caution >}} -Voir [l'exemple CephFS](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/cephfs/) pour plus de détails. +Voir [l'exemple CephFS](https://github.com/kubernetes/examples/tree/master/volumes/cephfs/) pour plus de détails. ### cinder {#cinder} @@ -315,7 +315,7 @@ Si plusieurs WWNs sont spécifiés, targetWWNs s'attend à ce que ces WWNs provi Vous devez configurer un zonage FC SAN pour allouer et masquer au préalable ces LUNs (volumes) aux cibles WWNs afin que les hôtes Kubernetes puissent y accéder. {{< /caution >}} -Voir [l'exemple FC](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/fibre_channel) pour plus de détails. +Voir [l'exemple FC](https://github.com/kubernetes/examples/tree/master/staging/volumes/fibre_channel) pour plus de détails. ### flocker {#flocker} @@ -330,7 +330,7 @@ Cela signifie que les données peuvent être transmises entre les Pods selon les Vous devez exécuter votre propre installation de Flocker avant de pouvoir l'utiliser. {{< /caution >}} -Voir [l'exemple Flocker](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/flocker) pour plus de détails. +Voir [l'exemple Flocker](https://github.com/kubernetes/examples/tree/master/staging/volumes/flocker) pour plus de détails. ### gcePersistentDisk {#gcepersistentdisk} @@ -465,7 +465,7 @@ GlusterFS peut être monté plusieurs fois en écriture simultanément. Vous devez exécuter votre propre installation de GlusterFS avant de pouvoir l'utiliser. {{< /caution >}} -Voir [l'exemple GlusterFS](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/glusterfs) pour plus de détails. +Voir [l'exemple GlusterFS](https://github.com/kubernetes/examples/tree/master/volumes/glusterfs) pour plus de détails. ### hostPath {#hostpath} @@ -537,7 +537,7 @@ Une fonctionnalité de iSCSI est qu'il peut être monté en lecture seule par pl Cela signifie que vous pouvez préremplir un volume avec votre jeu de données et l'exposer en parallèle à partir d'autant de Pods que nécessaire. Malheureusement, les volumes iSCSI peuvent seulement être montés par un seul consommateur en mode lecture-écriture - les écritures simultanées ne sont pas autorisées. -Voir [l'exemple iSCSI](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/iscsi) pour plus de détails. +Voir [l'exemple iSCSI](https://github.com/kubernetes/examples/tree/master/volumes/iscsi) pour plus de détails. ### local {#local} @@ -605,7 +605,7 @@ Cela signifie qu'un volume NFS peut être prérempli avec des données et que le Vous devez exécuter votre propre serveur NFS avec le partage exporté avant de pouvoir l'utiliser. {{< /caution >}} -Voir [l'exemple NFS](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/nfs) pour plus de détails. +Voir [l'exemple NFS](https://github.com/kubernetes/examples/tree/master/staging/volumes/nfs) pour plus de détails. ### persistentVolumeClaim {#persistentvolumeclaim} @@ -624,7 +624,7 @@ Actuellement, les types de sources de volume suivantes peuvent être projetés : - [`configMap`](#configmap) - `serviceAccountToken` -Toutes les sources doivent se trouver dans le même namespace que celui du Pod. Pour plus de détails, voir le [document de conception tout-en-un ](https://github.com/kubernetes/community/blob/{{< param "githubbranch" >}}/contributors/design-proposals/node/all-in-one-volume.md). +Toutes les sources doivent se trouver dans le même namespace que celui du Pod. Pour plus de détails, voir le [document de conception tout-en-un ](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/node/all-in-one-volume.md). La projection des jetons de compte de service (service account) est une fonctionnalité introduite dans Kubernetes 1.11 et promue en Beta dans la version 1.12. Pour activer cette fonctionnalité dans la version 1.11, il faut configurer explicitement la ["feature gate" `TokenRequestProjection`](/docs/reference/command-line-tools-reference/feature-gates/) à "True". @@ -776,7 +776,7 @@ spec: Il faut s'assurer d'avoir un PortworxVolume existant avec le nom `pxvol` avant de l'utiliser dans le Pod. {{< /caution >}} -Plus de détails et d'exemples peuvent être trouvé [ici](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/portworx/README.md). +Plus de détails et d'exemples peuvent être trouvé [ici](https://github.com/kubernetes/examples/tree/master/staging/volumes/portworx/README.md). ### quobyte {#quobyte} @@ -804,7 +804,7 @@ Une fonctionnalité de RBD est qu'il peut être monté en lecture seule par plus Cela signifie que vous pouvez préremplir un volume avec votre jeu de données et l'exposer en parallèle à partir d'autant de Pods que nécessaire. Malheureusement, les volumes RBD peuvent seulement être montés par un seul consommateur en mode lecture-écriture - les écritures simultanées ne sont pas autorisées. -Voir [l'exemple RBD](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/volumes/rbd) pour plus de détails. +Voir [l'exemple RBD](https://github.com/kubernetes/examples/tree/master/volumes/rbd) pour plus de détails. ### scaleIO {#scaleio} @@ -842,7 +842,7 @@ spec: fsType: xfs ``` -Pour plus de détails, consulter [les exemples ScaleIO](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/volumes/scaleio). +Pour plus de détails, consulter [les exemples ScaleIO](https://github.com/kubernetes/examples/tree/master/staging/volumes/scaleio). ### secret {#secret} diff --git a/content/fr/docs/concepts/workloads/controllers/statefulset.md b/content/fr/docs/concepts/workloads/controllers/statefulset.md index f223a8432f..14221ba82a 100644 --- a/content/fr/docs/concepts/workloads/controllers/statefulset.md +++ b/content/fr/docs/concepts/workloads/controllers/statefulset.md @@ -32,7 +32,7 @@ Un [Deployment](/fr/docs/concepts/workloads/controllers/deployment/) ou ## Limitations -* Le stockage pour un Pod donné doit être provisionné soit par un [approvisionneur de PersistentVolume](https://github.com/kubernetes/examples/tree/{{< param "githubbranch" >}}/staging/persistent-volume-provisioning/README.md) basé sur un `storage class` donné, soit pré-provisionné par un admin. +* Le stockage pour un Pod donné doit être provisionné soit par un [approvisionneur de PersistentVolume](https://github.com/kubernetes/examples/tree/master/staging/persistent-volume-provisioning/README.md) basé sur un `storage class` donné, soit pré-provisionné par un admin. * Supprimer et/ou réduire l'échelle d'un StatefulSet à zéro ne supprimera *pas* les volumes associés avec le StatefulSet. Ceci est fait pour garantir la sécurité des données, ce qui a généralement plus de valeur qu'une purge automatique de toutes les ressources relatives à un StatefulSet. * Les StatefulSets nécessitent actuellement un [Service Headless](/fr/docs/concepts/services-networking/service/#headless-services) qui est responsable de l'identité réseau des Pods. Vous êtes responsable de la création de ce Service. * Les StatefulSets ne fournissent aucune garantie de la terminaison des pods lorsqu'un StatefulSet est supprimé. Pour avoir une terminaison ordonnée et maîtrisée des pods du StatefulSet, il est possible de réduire l'échelle du StatefulSet à 0 avant de le supprimer. diff --git a/content/fr/docs/contribute/localization.md b/content/fr/docs/contribute/localization.md index 91667afdd2..332aeb4ea4 100644 --- a/content/fr/docs/contribute/localization.md +++ b/content/fr/docs/contribute/localization.md @@ -147,7 +147,7 @@ La dernière version est **{{< latest-version >}}**, donc la branche de la relea ### Chaînes de sites en i18n/ -Les localisations doivent inclure le contenu des éléments suivants [`i18n/en.toml`](https://github.com/kubernetes/website/blob/master/i18n/en.toml) dans un nouveau fichier spécifique à la langue. +Les localisations doivent inclure le contenu des éléments suivants [`i18n/en.toml`](https://github.com/kubernetes/website/blob/main/i18n/en.toml) dans un nouveau fichier spécifique à la langue. Prenons l'allemand comme exemple : `i18n/de.toml`. Ajouter un nouveau fichier de localisation dans `i18n/`. Par exemple, avec l'allemand (de) : @@ -230,5 +230,3 @@ Une fois qu'une traduction répond aux exigences de logistique et à une couvert - Activer la sélection de la langue sur le site Web - Publier la disponibilité de la traduction via les canaux de la [Cloud Native Computing Foundation](https://www.cncf.io/), y compris sur le blog de [Kubernetes](https://kubernetes.io/blog/). - - diff --git a/content/fr/docs/contribute/participating.md b/content/fr/docs/contribute/participating.md index 0658be231f..4fe2583859 100644 --- a/content/fr/docs/contribute/participating.md +++ b/content/fr/docs/contribute/participating.md @@ -102,7 +102,7 @@ Pour en savoir plus sur comment devenir un relecteur SIG Docs et sur les respons Lorsque vous remplissez les [conditions requises](https://github.com/kubernetes/community/blob/master/community-membership.md#reviewer), vous pouvez devenir un relecteur SIG Docs. Les relecteurs d'autres SIG doivent demander séparément le statut de relecteur dans le SIG Docs. -Pour postuler, ouvrez une pull request et ajoutez vous à la section `reviewers` du fichier [top-level OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) dans le dépôt `kubernetes/website`. +Pour postuler, ouvrez une pull request et ajoutez vous à la section `reviewers` du fichier [top-level OWNERS](https://github.com/kubernetes/website/blob/main/OWNERS) dans le dépôt `kubernetes/website`. Affectez la PR à un ou plusieurs approbateurs SIG Docs. Si votre pull request est approuvée, vous êtes maintenant un relecteur SIG Docs. @@ -130,7 +130,7 @@ Pour en savoir plus sur comment devenir un approbateur SIG Docs et sur les respo Lorsque vous remplissez les [conditions requises](https://github.com/kubernetes/community/blob/master/community-membership.md#approver), vous pouvez devenir un approbateur SIG Docs. Les approbateurs appartenant à d'autres SIG doivent demander séparément le statut d'approbateur dans SIG Docs. -Pour postuler, ouvrez une pull request pour vous ajouter à la section `approvers` du fichier [top-level OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) dans le dépot `kubernetes/website`. +Pour postuler, ouvrez une pull request pour vous ajouter à la section `approvers` du fichier [top-level OWNERS](https://github.com/kubernetes/website/blob/main/OWNERS) dans le dépot `kubernetes/website`. Affectez la PR à un ou plusieurs approbateurs SIG Docs. Si votre Pull Request est approuvée, vous êtes à présent approbateur SIG Docs. @@ -184,9 +184,9 @@ Le [dépôt du site web Kubernetes](https://github.com/kubernetes/website) utili - blunderbuss - approve -Ces deux plugins utilisent les fichiers [OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) et [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/master/OWNERS_ALIASES) à la racine du dépôt Github `kubernetes/website` pour contrôler comment prow fonctionne. +Ces deux plugins utilisent les fichiers [OWNERS](https://github.com/kubernetes/website/blob/main/OWNERS) et [OWNERS_ALIASES](https://github.com/kubernetes/website/blob/main/OWNERS_ALIASES) à la racine du dépôt Github `kubernetes/website` pour contrôler comment prow fonctionne. -Un fichier [OWNERS](https://github.com/kubernetes/website/blob/master/OWNERS) contient une liste de personnes qui sont des relecteurs et des approbateurs SIG Docs. +Un fichier [OWNERS](https://github.com/kubernetes/website/blob/main/OWNERS) contient une liste de personnes qui sont des relecteurs et des approbateurs SIG Docs. Les fichiers OWNERS existent aussi dans les sous-dossiers, et peuvent ignorer qui peut agir en tant que relecteur ou approbateur des fichiers de ce sous-répertoire et de ses descendants. Pour plus d'informations sur les fichiers OWNERS en général, voir [OWNERS](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md). @@ -203,5 +203,3 @@ Pour plus d'informations sur la contribution à la documentation Kubernetes, voi - [Commencez à contribuer](/docs/contribute/start/) - [Documentation style](/docs/contribute/style/) - - diff --git a/content/fr/docs/setup/release/building-from-source.md b/content/fr/docs/setup/release/building-from-source.md index b8a8e46bca..81b2328a1a 100644 --- a/content/fr/docs/setup/release/building-from-source.md +++ b/content/fr/docs/setup/release/building-from-source.md @@ -29,6 +29,6 @@ cd kubernetes make release ``` -Pour plus de détails sur le processus de release, voir le repertoire [`build`](http://releases.k8s.io/{{< param "githubbranch" >}}/build/) dans kubernetes/kubernetes. +Pour plus de détails sur le processus de release, voir le repertoire [`build`](http://releases.k8s.io/master/build/) dans kubernetes/kubernetes. diff --git a/content/fr/includes/task-tutorial-prereqs.md b/content/fr/includes/task-tutorial-prereqs.md index 50d60b8546..c561cb8c4a 100644 --- a/content/fr/includes/task-tutorial-prereqs.md +++ b/content/fr/includes/task-tutorial-prereqs.md @@ -1,5 +1,5 @@ Vous devez disposer d'un cluster Kubernetes et l'outil de ligne de commande kubectl doit être configuré pour communiquer avec votre cluster. Si vous ne possédez pas déjà de cluster, vous pouvez en créer un en utilisant [Minikube](/docs/setup/minikube), ou vous pouvez utiliser l'un de ces environnements Kubernetes: -* [Katacoda](https://www.katacoda.com/courses/kubernetes/playground) +* [Killercoda](https://killercoda.com/playgrounds/scenario/kubernetes) * [Play with Kubernetes](http://labs.play-with-k8s.com/) diff --git a/content/ja/docs/concepts/security/overview.md b/content/ja/docs/concepts/security/overview.md index 3cb67943f6..f1bb1fed43 100644 --- a/content/ja/docs/concepts/security/overview.md +++ b/content/ja/docs/concepts/security/overview.md @@ -125,7 +125,7 @@ TLS経由のアクセスのみ | コードがTCP通信を必要とする場合 関連するKubernetesセキュリティについて学びます。 * [Podセキュリティの標準](/ja/docs/concepts/security/pod-security-standards/) -* [Podのネットワークポリシー]](/ja/docs/concepts/services-networking/network-policies/) +* [Podのネットワークポリシー](/ja/docs/concepts/services-networking/network-policies/) * [Kubernetes APIへのアクセスを制御する](/docs/concepts/security/controlling-access) * [クラスターの保護](/docs/tasks/administer-cluster/securing-a-cluster/) * コントロールプレーンとの[通信時のデータ暗号化](/docs/tasks/tls/managing-tls-in-a-cluster/) diff --git a/content/ja/docs/reference/glossary/service-catalog.md b/content/ja/docs/reference/glossary/service-catalog.md index 328bcf7280..b05d1528d8 100644 --- a/content/ja/docs/reference/glossary/service-catalog.md +++ b/content/ja/docs/reference/glossary/service-catalog.md @@ -13,4 +13,4 @@ tags: Kubernetesクラスターで稼働するアプリケーションが、クラウドプロバイダーによって提供されるデータストアサービスのように、外部のマネージドソフトウェアを容易に使えるようにするための拡張APIです。 -サービスカタログを使用することで{{< glossary_tooltip text="サービスブローカー" term_id="service-broker" >}}が提供する{{< glossary_tooltip text="マネージドサービス" term_id="managed-service" >}}を、それらのサービスがどのように作成されるか、また管理されるかについての知識を無しに、一覧表示したり、プロビジョニングや使用をすることができます。 +サービスカタログを使用することで、提供されている{{< glossary_tooltip text="マネージドサービス" term_id="managed-service" >}}を、それらのサービスがどのように作成されるか、また管理されるかについての知識を無しに、一覧表示したり、プロビジョニングや使用をすることができます。 diff --git a/content/ja/docs/tasks/debug-application-cluster/monitor-node-health.md b/content/ja/docs/tasks/debug-application-cluster/monitor-node-health.md index f40075e919..44d627a04c 100644 --- a/content/ja/docs/tasks/debug-application-cluster/monitor-node-health.md +++ b/content/ja/docs/tasks/debug-application-cluster/monitor-node-health.md @@ -59,7 +59,7 @@ reviewers: ## コンフィギュレーションを上書きします -`Node Problem Detector`の Dockerイメージをビルドする際に、[default configuration(https://github.com/kubernetes/node-problem-detector/tree/v0.1/config)が埋め込まれます。 +`Node Problem Detector`の Dockerイメージをビルドする際に、[default configuration](https://github.com/kubernetes/node-problem-detector/tree/v0.1/config)が埋め込まれます。 [`ConfigMap`](/ja/docs/tasks/configure-pod-container/configure-pod-configmap/) を使用することで設定を上書きすることができます。 diff --git a/content/ja/examples/application/mysql/mysql-configmap.yaml b/content/ja/examples/application/mysql/mysql-configmap.yaml index 6aa5bfe4e5..9adb0344a3 100644 --- a/content/ja/examples/application/mysql/mysql-configmap.yaml +++ b/content/ja/examples/application/mysql/mysql-configmap.yaml @@ -4,15 +4,14 @@ metadata: name: mysql labels: app: mysql + app.kubernetes.io/name: mysql data: primary.cnf: | # 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/ko/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md index 494d3b1601..51ecff20b4 100644 --- a/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/ko/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -15,159 +15,182 @@ weight: 20 {{< glossary_tooltip text="파드" term_id="pod" >}}를 제한할 수 있다. 이를 수행하는 방법에는 여러 가지가 있으며 권장되는 접근 방식은 모두 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/)를 사용하여 선택을 용이하게 한다. -보통 스케줄러가 자동으로 합리적인 배치(예: 자원이 부족한 노드에 파드를 배치하지 않도록 -노드 간에 파드를 분배하는 등)를 수행하기에 이러한 제약 조건은 필요하지 않지만 -간혹 파드가 배포될 노드를 제어해야 하는 경우가 있다. -예를 들어 SSD가 장착된 머신에 파드가 배포되도록 하거나 또는 많은 통신을 하는 두 개의 서로 다른 서비스의 파드를 -동일한 가용성 영역(availability zone)에 배치할 수 있다. - +보통은 스케줄러가 자동으로 합리적인 배치(예: 자원이 부족한 노드에 파드를 배치하지 않도록 +노드 간에 파드를 분배)를 수행하기에 이러한 제약 조건은 필요하지 않다. +그러나, 예를 들어 SSD가 장착된 머신에 파드가 배포되도록 하거나 또는 +많은 통신을 하는 두 개의 서로 다른 서비스의 파드를 동일한 가용성 영역(availability zone)에 배치하는 경우와 같이, +파드가 어느 노드에 배포될지를 제어해야 하는 경우도 있다. -## 노드 셀렉터(nodeSelector) +쿠버네티스가 특정 파드를 어느 노드에 스케줄링할지 고르는 +다음의 방법 중 하나를 골라 사용할 수 있다. -`nodeSelector` 는 가장 간단하고 권장되는 노드 선택 제약 조건의 형태이다. -`nodeSelector` 는 PodSpec의 필드이다. 이는 키-값 쌍의 매핑으로 지정한다. 파드가 노드에서 동작할 수 있으려면, -노드는 키-값의 쌍으로 표시되는 레이블을 각자 가지고 있어야 한다(이는 추가 레이블을 가지고 있을 수 있다). -일반적으로 하나의 키-값 쌍이 사용된다. + * [노드 레이블](#built-in-node-labels)에 매칭되는 [nodeSelector](#nodeselector) 필드 + * [어피니티 / 안티 어피니티](#affinity-and-anti-affinity) + * [nodeName](#nodename) 필드 -`nodeSelector` 를 어떻게 사용하는지 예시를 통해 알아보도록 하자. +## 노드 레이블 {#built-in-node-labels} -### 0 단계: 사전 준비 +다른 쿠버네티스 오브젝트와 마찬가지로, 노드도 [레이블](/ko/docs/concepts/overview/working-with-objects/labels/)을 가진다. +[레이블을 수동으로 추가](/ko/docs/tasks/configure-pod-container/assign-pods-nodes/#노드에-레이블-추가)할 수 있다. +또한 쿠버네티스도 클러스터의 모든 노드에 표준화된 레이블 집합을 적용한다. +[잘 알려진 레이블, 어노테이션, 테인트](/ko/docs/reference/labels-annotations-taints/)에서 널리 사용되는 노드 레이블의 목록을 확인한다. -이 예시는 쿠버네티스 파드에 대한 기본적인 이해를 하고 있고 [쿠버네티스 클러스터가 설정](/ko/docs/setup/)되어 있다고 가정한다. +{{}} +이러한 레이블에 대한 값은 클라우드 제공자별로 다르며 정확하지 않을 수 있다. +예를 들어, `kubernetes.io/hostname`에 대한 값은 특정 환경에서는 노드 이름과 동일할 수 있지만 +다른 환경에서는 다른 값일 수도 있다. +{{}} -### 1 단계: 노드에 레이블 붙이기 +### 노드 격리/제한 {#node-isolation-restriction} -`kubectl get nodes` 를 실행해서 클러스터 노드 이름을 가져온다. 이 중에 레이블을 추가하기 원하는 것 하나를 선택한 다음에 `kubectl label nodes <노드 이름> <레이블 키>=<레이블 값>` 을 실행해서 선택한 노드에 레이블을 추가한다. 예를 들어 노드의 이름이 'kubernetes-foo-node-1.c.a-robinson.internal' 이고, 원하는 레이블이 'disktype=ssd' 라면, `kubectl label nodes kubernetes-foo-node-1.c.a-robinson.internal disktype=ssd` 를 실행한다. +노드에 레이블을 추가하여 +파드를 특정 노드 또는 노드 그룹에 스케줄링되도록 지정할 수 있다. +이 기능을 사용하여 특정 파드가 특정 격리/보안/규제 속성을 만족하는 노드에서만 +실행되도록 할 수 있다. -`kubectl get nodes --show-labels` 를 다시 실행해서 노드가 현재 가진 레이블을 확인하여, 이 작업을 검증할 수 있다. 또한 `kubectl describe node "노드 이름"` 을 사용해서 노드에 주어진 레이블의 전체 목록을 확인할 수 있다. +노드 격리를 위해 레이블을 사용할 때, {{}}이 변경할 수 없는 레이블 키를 선택한다. +그렇지 않으면 kubelet이 해당 레이블을 변경하여 노드가 사용 불가능(compromised) 상태로 빠지고 +스케줄러가 이 노드에 워크로드를 스케줄링하는 일이 발생할 수 있다. -### 2 단계: 파드 설정에 nodeSelector 필드 추가하기 +[`NodeRestriction` 어드미션 플러그인](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)은 +kubelet이 `node-restriction.kubernetes.io/` 접두사를 갖는 레이블을 +설정하거나 변경하지 못하도록 한다. -실행하고자 하는 파드의 설정 파일을 가져오고, 이처럼 nodeSelector 섹션을 추가한다. 예를 들어 이것이 파드 설정이라면, +노드 격리를 위해 레이블 접두사를 사용하려면, -```yaml -apiVersion: v1 -kind: Pod -metadata: - name: nginx - labels: - env: test -spec: - containers: - - name: nginx - image: nginx -``` +1. [노드 인가자(authorizer)](/docs/reference/access-authn-authz/node/)를 사용하고 있는지, 그리고 `NodeRestriction` 어드미션 플러그인을 **활성화** 했는지 확인한다. +1. 노드에 `node-restriction.kubernetes.io/` 접두사를 갖는 레이블을 추가하고, [노드 셀렉터](#nodeselector)에서 해당 레이블을 사용한다. + 예: `example.com.node-restriction.kubernetes.io/fips=true` 또는 `example.com.node-restriction.kubernetes.io/pci-dss=true` -이 다음에 nodeSelector 를 다음과 같이 추가한다. +## 노드셀렉터(nodeSelector) {#nodeselector} -{{< codenew file="pods/pod-nginx.yaml" >}} +`nodeSelector`는 노드 선택 제약사항의 가장 간단하면서도 추천하는 형태이다. +파드 스펙에 `nodeSelector` 필드를 추가하고, +타겟으로 삼고 싶은 노드가 갖고 있는 [노드 레이블](#built-in-node-labels)을 명시한다. +쿠버네티스는 사용자가 명시한 레이블을 갖고 있는 노드에만 +파드를 스케줄링한다. -그런 다음에 `kubectl apply -f https://k8s.io/examples/pods/pod-nginx.yaml` 을 -실행하면, 레이블이 붙여진 노드에 파드가 스케줄된다. -`kubectl get pods -o wide` 를 실행해서 파드가 할당된 -"NODE" 를 보면 작동하는지 검증할 수 있다. +[노드에 파드 할당](/ko/docs/tasks/configure-pod-container/assign-pods-nodes)에서 +더 많은 정보를 확인한다. -## 넘어가기 전에: 내장 노드 레이블들 {#built-in-node-labels} +## 어피니티(affinity)와 안티-어피니티(anti-affinity) {#affinity-and-anti-affinity} -[붙인](#1-단계-노드에-레이블-붙이기) 레이블뿐만 아니라, 노드에는 -표준 레이블 셋이 미리 채워져 있다. 이들 목록은 [잘 알려진 레이블, 어노테이션 및 테인트](/ko/docs/reference/labels-annotations-taints/)를 참고한다. +`nodeSelector` 는 파드를 특정 레이블이 있는 노드로 제한하는 가장 간단한 방법이다. +어피니티/안티-어피니티 기능은 표현할 수 있는 제약 종류를 크게 확장한다. +주요 개선 사항은 다음과 같다. -{{< note >}} -이 레이블들의 값은 클라우드 공급자에 따라 다르고 신뢰성이 보장되지 않는다. -예를 들어 `kubernetes.io/hostname` 은 어떤 환경에서는 노드 이름과 같지만, -다른 환경에서는 다른 값일 수 있다. -{{< /note >}} +* 어피니티/안티-어피니티 언어가 더 표현적이다. + `nodeSelector`로는 명시한 레이블이 있는 노드만 선택할 수 있다. + 어피니티/안티-어피니티는 선택 로직에 대한 좀 더 많은 제어권을 제공한다. +* 규칙이 "소프트(soft)" 또는 "선호사항(preference)" 임을 나타낼 수 있으며, + 이 덕분에 스케줄러는 매치되는 노드를 찾지 못한 경우에도 파드를 스케줄링할 수 있다. +* 다른 노드 (또는 다른 토폴로지 도메인)에서 실행 중인 + 다른 파드의 레이블을 사용하여 파드를 제한할 수 있으며, + 이를 통해 어떤 파드들이 노드에 함께 위치할 수 있는지에 대한 규칙을 정의할 수 있다. -## 노드 격리(isolation)/제한(restriction) +어피니티 기능은 다음의 두 가지 종류로 구성된다. -노드 오브젝트에 레이블을 추가하면 파드가 특정 노드 또는 노드 그룹을 목표 대상으로 할 수 있게 된다. -이는 특정 파드가 어떤 격리, 보안, 또는 규제 속성이 있는 노드에서만 실행되도록 사용할 수 있다. -이 목적으로 레이블을 사용하는 경우, 노드에서 kubelet 프로세스로 수정할 수 없는 레이블 키를 선택하는 것을 권장한다. -이렇게 하면 손상된 노드가 해당 kubelet 자격 증명을 사용해서 해당 레이블을 자체 노드 오브젝트에 설정하고, -스케줄러가 손상된 노드로 워크로드를 스케줄 하는 것을 방지할 수 있다. +* *노드 어피니티* 기능은 `nodeSelector` 필드와 비슷하지만 + 더 표현적이고 소프트(soft) 규칙을 지정할 수 있게 해 준다. +* *파드 간 어피니티/안티-어피니티* 는 다른 파드의 레이블을 이용하여 + 해당 파드를 제한할 수 있게 해 준다. -`NodeRestriction` 어드미션 플러그인은 kubelet이 `node-restriction.kubernetes.io/` 접두사로 레이블을 설정 또는 수정하지 못하게 한다. -노드 격리에 해당 레이블 접두사를 사용하려면 다음과 같이 한다. +### 노드 어피니티 {#node-affinity} -1. [노드 권한부여자](/docs/reference/access-authn-authz/node/)를 사용하고 있고, [NodeRestriction 어드미션 플러그인](/docs/reference/access-authn-authz/admission-controllers/#noderestriction)을 _활성화_ 해야 한다. -2. 노드 오브젝트의 `node-restriction.kubernetes.io/` 접두사 아래에 레이블을 추가하고, 해당 레이블을 노드 셀렉터에서 사용한다. -예를 들어, `example.com.node-restriction.kubernetes.io/fips=true` 또는 `example.com.node-restriction.kubernetes.io/pci-dss=true` 이다. +노드 어피니티는 개념적으로 `nodeSelector` 와 비슷하며, +노드의 레이블을 기반으로 파드가 스케줄링될 수 있는 노드를 제한할 수 있다. +노드 어피니티에는 다음의 두 종류가 있다. -## 어피니티(affinity)와 안티-어피니티(anti-affinity) + * `requiredDuringSchedulingIgnoredDuringExecution`: + 규칙이 만족되지 않으면 스케줄러가 파드를 스케줄링할 수 없다. + 이 기능은 `nodeSelector`와 유사하지만, 좀 더 표현적인 문법을 제공한다. + * `preferredDuringSchedulingIgnoredDuringExecution`: + 스케줄러는 조건을 만족하는 노드를 찾으려고 노력한다. + 해당되는 노드가 없더라도, 스케줄러는 여전히 파드를 스케줄링한다. -`nodeSelector` 는 파드를 특정 레이블이 있는 노드로 제한하는 매우 간단한 방법을 제공한다. -어피니티/안티-어피니티 기능은 표현할 수 있는 제약 종류를 크게 확장한다. 주요 개선 사항은 다음과 같다. +{{}} +앞의 두 유형에서, `IgnoredDuringExecution`는 +쿠버네티스가 파드를 스케줄링한 뒤에 노드 레이블이 변경되어도 파드는 계속 해당 노드에서 실행됨을 의미한다. +{{}} -1. 어피니티/안티-어피니티 언어가 더 표현적이다. 언어는 논리 연산자인 AND 연산으로 작성된 - 정확한 매칭 항목 이외에 더 많은 매칭 규칙을 제공한다. -2. 규칙이 엄격한 요구 사항이 아니라 "유연한(soft)"/"선호(preference)" 규칙을 나타낼 수 있기에 스케줄러가 규칙을 만족할 수 없더라도, - 파드가 계속 스케줄되도록 한다. -3. 노드 자체에 레이블을 붙이기보다는 노드(또는 다른 토폴로지 도메인)에서 실행 중인 다른 파드의 레이블을 제한할 수 있다. - 이를 통해 어떤 파드가 함께 위치할 수 있는지와 없는지에 대한 규칙을 적용할 수 있다. +파드 스펙의 `.spec.affinity.nodeAffinity` 필드에 +노드 어피니티를 명시할 수 있다. -어피니티 기능은 "노드 어피니티" 와 "파드 간 어피니티/안티-어피니티" 두 종류의 어피니티로 구성된다. -노드 어피니티는 기존 `nodeSelector` 와 비슷하지만(그러나 위에서 나열된 첫째와 두 번째 이점이 있다.), -파드 간 어피니티/안티-어피니티는 위에서 나열된 세번째 항목에 설명된 대로 -노드 레이블이 아닌 파드 레이블에 대해 제한되고 위에서 나열된 첫 번째와 두 번째 속성을 가진다. - -### 노드 어피니티 - -노드 어피니티는 개념적으로 `nodeSelector` 와 비슷하다 -- 이는 노드의 레이블을 기반으로 파드를 -스케줄할 수 있는 노드를 제한할 수 있다. - -여기에 현재 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 로 부르는 -두 가지 종류의 노드 어피니티가 있다. 전자는 파드가 노드에 스케줄되도록 *반드시* -규칙을 만족해야 하는 것(`nodeSelector` 와 비슷하나 보다 표현적인 구문을 사용해서)을 지정하고, -후자는 스케줄러가 시도하려고는 하지만, 보증하지 않는 *선호(preferences)* 를 지정한다는 점에서 -이를 각각 "엄격함(hard)" 과 "유연함(soft)" 으로 생각할 수 있다. -이름의 "IgnoredDuringExecution" 부분은 `nodeSelector` 작동 방식과 유사하게 노드의 -레이블이 런타임 중에 변경되어 파드의 어피니티 규칙이 더 이상 충족되지 않으면 파드가 그 노드에서 -동작한다는 의미이다. 향후에는 파드의 노드 어피니티 요구 사항을 충족하지 않는 노드에서 파드를 제거한다는 -점을 제외하고는 `requiredDuringSchedulingIgnoredDuringExecution` 와 동일한 `requiredDuringSchedulingRequiredDuringExecution` 를 제공할 계획이다. - -따라서 `requiredDuringSchedulingIgnoredDuringExecution` 의 예로는 "인텔 CPU가 있는 노드에서만 파드 실행"이 -될 수 있고, `preferredDuringSchedulingIgnoredDuringExecution` 의 예로는 "장애 조치 영역 XYZ에 파드 집합을 실행하려고 -하지만, 불가능하다면 다른 곳에서 일부를 실행하도록 허용"이 있을 것이다. - -노드 어피니티는 PodSpec의 `affinity` 필드의 `nodeAffinity` 필드에서 지정된다. - -여기에 노드 어피니티를 사용하는 파드 예시가 있다. +예를 들어, 다음과 같은 파드 스펙이 있다고 하자. {{< codenew file="pods/pod-with-node-affinity.yaml" >}} -이 노드 어피니티 규칙은 키가 `kubernetes.io/e2e-az-name` 이고 값이 `e2e-az1` 또는 `e2e-az2` 인 -레이블이 있는 노드에만 파드를 배치할 수 있다고 말한다. 또한, 이 기준을 충족하는 노드들 -중에서 키가 `another-node-label-key` 이고 값이 `another-node-label-value` 인 레이블이 있는 노드를 -선호하도록 한다. +이 예시에서는 다음의 규칙이 적용된다. -예시에서 연산자 `In` 이 사용되고 있는 것을 볼 수 있다. 새로운 노드 어피니티 구문은 다음의 연산자들을 지원한다. `In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt`, `Lt`. -`NotIn` 과 `DoesNotExist` 를 사용해서 안티-어피니티를 수행하거나, -특정 노드에서 파드를 쫓아내는 [노드 테인트(taint)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 설정할 수 있다. + * 노드는 키가 `kubernetes.io/os`이고 값이 `linux`인 레이블을 + 갖고 *있어야 한다* . + * 키가 `another-node-label-key`이고 값이 `another-node-label-value`인 레이블을 + 갖고 있는 노드를 *선호한다* . -`nodeSelector` 와 `nodeAffinity` 를 모두 지정한다면 파드가 후보 노드에 스케줄되기 위해서는 -*둘 다* 반드시 만족해야 한다. +`operator` 필드를 사용하여 +쿠버네티스가 규칙을 해석할 때 사용할 논리 연산자를 지정할 수 있다. +`In`, `NotIn`, `Exists`, `DoesNotExist`, `Gt` 및 `Lt` 연산자를 사용할 수 있다. -`nodeAffinity` 유형과 연관된 `nodeSelectorTerms` 를 지정하면, `nodeSelectorTerms` 중 **하나라도** 만족시키는 노드에 파드가 스케줄된다. +`NotIn` 및 `DoesNotExist` 연산자를 사용하여 노드 안티-어피니티 규칙을 정의할 수 있다. +또는, 특정 노드에서 파드를 쫓아내는 +[노드 테인트(taint)](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)를 설정할 수 있다. -`nodeSelectorTerms` 와 연관된 여러 `matchExpressions` 를 지정하면, 파드는 `matchExpressions` 를 **모두** 만족하는 노드에만 스케줄된다. +{{}} +`nodeSelector`와 `nodeAffinity`를 모두 사용하는 경우, +파드가 노드에 스케줄링되려면 두 조건 *모두* 만족되어야 한다. -파드가 스케줄된 노드의 레이블을 지우거나 변경해도 파드는 제거되지 않는다. 다시 말해서 어피니티 선택은 파드를 스케줄링 하는 시점에만 작동한다. +`nodeAffinity`에 연결된 `nodeSelectorTerms`를 여러 개 명시한 경우, +명시된 `nodeSelectorTerms` 중 하나를 만족하는 노드에도 +파드가 스케줄링될 수 있다. -`preferredDuringSchedulingIgnoredDuringExecution` 의 `weight` 필드의 범위는 1-100이다. 모든 스케줄링 요구 사항 (리소스 요청, RequiredDuringScheduling 어피니티 표현식 등)을 만족하는 각 노드들에 대해 스케줄러는 이 필드의 요소들을 반복해서 합계를 계산하고 노드가 MatchExpressions 에 일치하는 경우 합계에 "가중치(weight)"를 추가한다. 이후에 이 점수는 노드에 대한 다른 우선순위 함수의 점수와 합쳐진다. 전체 점수가 가장 높은 노드를 가장 선호한다. +단일 `nodeSelectorTerms`와 연결된 `matchExpressions`를 여러 개 명시한 경우, +모든 `matchExpressions`를 만족하는 노드에만 +파드가 스케줄링될 수 있다. +{{}} -#### 스케줄링 프로파일당 노드 어피니티 +[노드 어피니티를 사용해 노드에 파드 할당](/ko/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)에서 +더 많은 정보를 확인한다. + +#### 노드 어피니티 가중치(weight) {#node-affinity-weight} + +각 `preferredDuringSchedulingIgnoredDuringExecution` 어피니티 타입 인스턴스에 대해 +1-100 범위의 `weight`를 명시할 수 있다. +스케줄러가 다른 모든 파드 스케줄링 요구 사항을 만족하는 노드를 찾으면, +스케줄러는 노드가 만족한 모든 선호하는(preferred) 규칙에 대해 +합계 계산을 위한 `weight` 값을 각각 추가한다. + +최종 합계는 해당 노드에 대한 다른 우선 순위 함수 점수에 더해진다. +스케줄러가 파드에 대한 스케줄링 판단을 할 때, +총 점수가 가장 높은 노드가 우선 순위를 갖는다. + +예를 들어, 다음과 같은 파드 스펙이 있다고 하자. + +{{< codenew file="pods/pod-with-affinity-anti-affinity.yaml" >}} + +`requiredDuringSchedulingIgnoredDuringExecution` 규칙을 만족하는 노드가 2개 있고, +하나에는 `label-1:key-1` 레이블이 있고 다른 하나에는 `label-2:key-2` 레이블이 있으면, +스케줄러는 각 노드의 `weight`를 확인한 뒤 +해당 노드에 대한 다른 점수에 가중치를 더하고, +최종 점수가 가장 높은 노드에 해당 파드를 스케줄링한다. + +{{}} +이 예시에서 쿠버네티스가 정상적으로 파드를 스케줄링하려면, +보유하고 있는 노드에 `kubernetes.io/os=linux` 레이블이 있어야 한다. +{{}} + +#### 스케줄링 프로파일당 노드 어피니티 {#node-affinity-per-scheduling-profile} {{< feature-state for_k8s_version="v1.20" state="beta" >}} 여러 [스케줄링 프로파일](/ko/docs/reference/scheduling/config/#여러-프로파일)을 구성할 때 노드 어피니티가 있는 프로파일을 연결할 수 있는데, 이는 프로파일이 특정 노드 집합에만 적용되는 경우 유용하다. -이렇게 하려면 [스케줄러 구성](/ko/docs/reference/scheduling/config/)에 있는 -[`NodeAffinity` 플러그인](/ko/docs/reference/scheduling/config/#스케줄링-플러그인-1)의 인수에 `addedAffinity`를 추가한다. 예를 들면 +이렇게 하려면 다음과 같이 [스케줄러 구성](/ko/docs/reference/scheduling/config/)에 있는 +[`NodeAffinity` 플러그인](/ko/docs/reference/scheduling/config/#스케줄링-플러그인-1)의 `args` 필드에 `addedAffinity`를 추가한다. ```yaml -apiVersion: kubescheduler.config.k8s.io/v1beta1 +apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: @@ -188,29 +211,41 @@ profiles: `addedAffinity`는 `.spec.schedulerName`을 `foo-scheduler`로 설정하는 모든 파드에 적용되며 PodSpec에 지정된 NodeAffinity도 적용된다. -즉, 파드를 매칭시키려면, 노드가 `addedAffinity`와 파드의 `.spec.NodeAffinity`를 충족해야 한다. +즉, 파드를 매칭시키려면, 노드가 `addedAffinity`와 +파드의 `.spec.NodeAffinity`를 충족해야 한다. -`addedAffinity`는 엔드 유저에게 표시되지 않으므로, 예상치 못한 동작이 일어날 수 있다. 프로파일의 -스케줄러 이름과 명확한 상관 관계가 있는 노드 레이블을 사용하는 것이 좋다. +`addedAffinity`는 엔드 유저에게 표시되지 않으므로, +예상치 못한 동작이 일어날 수 있다. +스케줄러 프로파일 이름과 명확한 상관 관계가 있는 노드 레이블을 사용한다. {{< note >}} -[데몬셋용 파드를 생성](/ko/docs/concepts/workloads/controllers/daemonset/#기본-스케줄러로-스케줄)하는 데몬셋 컨트롤러는 -스케줄링 프로파일을 인식하지 못한다. -따라서 `addedAffinity`없이 `default-scheduler`와 같은 스케줄러 프로파일을 유지하는 것이 좋다. 그런 다음 데몬셋의 파드 템플릿이 스케줄러 이름을 사용해야 한다. -그렇지 않으면, 데몬셋 컨트롤러에 의해 생성된 일부 파드가 스케줄되지 않은 상태로 유지될 수 있다. +[데몬셋 파드를 생성](/ko/docs/concepts/workloads/controllers/daemonset/#기본-스케줄러로-스케줄)하는 데몬셋 컨트롤러는 +스케줄링 프로파일을 지원하지 않는다. +데몬셋 컨트롤러가 파드를 생성할 때, 기본 쿠버네티스 스케줄러는 해당 파드를 배치하고 +데몬셋 컨트롤러의 모든 `nodeAffinity` 규칙을 준수한다. {{< /note >}} -### 파드간 어피니티와 안티-어피니티 +### 파드간 어피니티와 안티-어피니티 {#inter-pod-affinity-and-anti-affinity} -파드간 어피니티와 안티-어피니티를 사용하면 노드의 레이블을 기반으로 하지 않고, *노드에서 이미 실행 중인 파드 레이블을 기반으로* -파드가 스케줄될 수 있는 노드를 제한할 수 있다. 규칙은 "X가 규칙 Y를 충족하는 하나 이상의 파드를 이미 실행중인 경우 -이 파드는 X에서 실행해야 한다(또는 안티-어피니티가 없는 경우에는 동작하면 안된다)"는 형태이다. Y는 -선택적으로 연관된 네임스페이스 목록을 가진 LabelSelector로 표현된다. 노드와는 다르게 파드는 네임스페이스이기에 -(그리고 따라서 파드의 레이블은 암암리에 네임스페이스이다) 파드 레이블위의 레이블 셀렉터는 반드시 -셀렉터가 적용될 네임스페이스를 지정해야만 한다. 개념적으로 X는 노드, 랙, -클라우드 공급자 영역, 클라우드 공급자 지역 등과 같은 토폴로지 도메인이다. 시스템이 이런 토폴로지 -도메인을 나타내는 데 사용하는 노드 레이블 키인 `topologyKey` 를 사용하여 이를 표현한다. -예: [넘어가기 전에: 빌트인 노드 레이블](#built-in-node-labels) 섹션 위에 나열된 레이블 키를 본다. +파드간 어피니티와 안티-어피니티를 사용하여, +노드 레이블 대신, 각 노드에 이미 실행 중인 다른 **파드** 의 레이블을 기반으로 +파드가 스케줄링될 노드를 제한할 수 있다. + +파드간 어피니티와 안티-어피니티 규칙은 +"X가 규칙 Y를 충족하는 하나 이상의 파드를 이미 실행중인 경우 이 파드는 X에서 실행해야 한다(또는 +안티-어피니티의 경우에는 "실행하면 안 된다")"의 형태이며, +여기서 X는 노드, 랙, 클라우드 제공자 존 또는 리전 등이며 +Y는 쿠버네티스가 충족할 규칙이다. + +이러한 규칙(Y)은 [레이블 셀렉터](/ko/docs/concepts/overview/working-with-objects/labels/#레이블-셀렉터) 형태로 작성하며, +연관된 네임스페이스 목록을 선택적으로 명시할 수도 있다. +쿠버네티스에서 파드는 네임스페이스에 속하는(namespaced) 오브젝트이므로, +파드 레이블도 암묵적으로 특정 네임스페이스에 속하게 된다. +파드 레이블에 대한 모든 레이블 셀렉터는 쿠버네티스가 해당 레이블을 어떤 네임스페이스에서 탐색할지를 명시해야 한다. + +`topologyKey`를 사용하여 토폴로지 도메인(X)를 나타낼 수 있으며, +이는 시스템이 도메인을 표시하기 위해 사용하는 노드 레이블의 키이다. +이에 대한 예시는 [잘 알려진 레이블, 어노테이션, 테인트](/ko/docs/reference/labels-annotations-taints/)를 참고한다. {{< note >}} 파드간 어피니티와 안티-어피니티에는 상당한 양의 프로세싱이 필요하기에 @@ -219,80 +254,100 @@ PodSpec에 지정된 NodeAffinity도 적용된다. {{< /note >}} {{< note >}} -파드 안티-어피니티에서는 노드에 일관된 레이블을 지정해야 한다. 즉, 클러스터의 모든 노드는 `topologyKey` 와 매칭되는 적절한 레이블을 가지고 있어야 한다. 일부 또는 모든 노드에 지정된 `topologyKey` 레이블이 없는 경우에는 의도하지 않은 동작이 발생할 수 있다. +파드 안티-어피니티에서는 노드에 일관된 레이블을 지정해야 한다. +즉, 클러스터의 모든 노드는 `topologyKey` 와 매칭되는 적절한 레이블을 가지고 있어야 한다. +일부 또는 모든 노드에 지정된 `topologyKey` 레이블이 없는 경우에는 +의도하지 않은 동작이 발생할 수 있다. {{< /note >}} -노드 어피니티와 마찬가지로 현재 파드 어피니티와 안티-어피니티로 부르는 "엄격함" 대 "유연함"의 요구사항을 나타내는 `requiredDuringSchedulingIgnoredDuringExecution` 와 -`preferredDuringSchedulingIgnoredDuringExecution` 두 가지 종류가 있다. -앞의 노드 어피니티 섹션의 설명을 본다. -`requiredDuringSchedulingIgnoredDuringExecution` 어피니티의 예시는 -"서로 많은 통신을 하기 때문에 서비스 A와 서비스 B를 같은 영역에 함께 위치시키는 것"이고, -`preferredDuringSchedulingIgnoredDuringExecution` 안티-어피니티의 예시는 "서비스를 여러 영역에 걸쳐서 분배하는 것"이다 -(엄격한 요구사항은 영역보다 파드가 더 많을 수 있기 때문에 엄격한 요구사항은 의미가 없다). +#### 파드간 어피니티 및 안티-어피니티 종류 {#types-of-inter-pod-affinity-and-anti-affinity} -파드간 어피니티는 PodSpec에서 `affinity` 필드 중 `podAffinity` 필드로 지정한다. -그리고 파드간 안티-어피니티는 PodSpec에서 `affinity` 필드 중 `podAntiAffinity` 필드로 지정한다. +노드 어피니티와 마찬가지로 +파드 어피니티 및 안티-어피니티에는 다음의 2 종류가 있다. -#### 파드 어피니티를 사용하는 파드의 예시 + * `requiredDuringSchedulingIgnoredDuringExecution` + * `preferredDuringSchedulingIgnoredDuringExecution` + +예를 들어, `requiredDuringSchedulingIgnoredDuringExecution` 어피니티를 사용하여 +서로 통신을 많이 하는 두 서비스의 파드를 +동일 클라우드 제공자 존에 배치하도록 스케줄러에게 지시할 수 있다. +비슷하게, `preferredDuringSchedulingIgnoredDuringExecution` 안티-어피니티를 사용하여 +서비스의 파드를 +여러 클라우드 제공자 존에 퍼뜨릴 수 있다. + +파드간 어피니티를 사용하려면, 파드 스펙에 `affinity.podAffinity` 필드를 사용한다. +파드간 안티-어피니티를 사용하려면, +파드 스펙에 `affinity.podAntiAffinity` 필드를 사용한다. + +#### 파드 어피니티 예시 {#an-example-of-a-pod-that-uses-pod-affinity} + +다음과 같은 파드 스펙을 가정한다. {{< codenew file="pods/pod-with-pod-affinity.yaml" >}} -이 파드의 어피니티는 하나의 파드 어피니티 규칙과 하나의 파드 안티-어피니티 규칙을 정의한다. -이 예시에서 `podAffinity` 는 `requiredDuringSchedulingIgnoredDuringExecution` 이고 `podAntiAffinity` 는 -`preferredDuringSchedulingIgnoredDuringExecution` 이다. 파드 어피니티 규칙에 의하면 키 "security" 와 값 -"S1"인 레이블이 있는 하나 이상의 이미 실행 중인 파드와 동일한 영역에 있는 경우에만 파드를 노드에 스케줄할 수 있다. -(보다 정확하게는, 클러스터에 키 "security"와 값 "S1"인 레이블을 가지고 있는 실행 중인 파드가 있는 키 -`topology.kubernetes.io/zone` 와 값 V인 노드가 최소 하나 이상 있고, -노드 N이 키 `topology.kubernetes.io/zone` 와 -일부 값이 V인 레이블을 가진다면 파드는 노드 N에서 실행할 수 있다.) -파드 안티-어피니티 규칙에 의하면 파드는 키 "security"와 값 "S2"인 레이블을 가진 파드와 -동일한 영역의 노드에 스케줄되지 않는다. -[디자인 문서](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)를 통해 -`requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 의 -파드 어피니티와 안티-어피니티에 대한 많은 예시를 맛볼 수 있다. +이 예시는 하나의 파드 어피니티 규칙과 +하나의 파드 안티-어피니티 규칙을 정의한다. +파드 어피니티 규칙은 "하드" `requiredDuringSchedulingIgnoredDuringExecution`을, +안티-어피니티 규칙은 "소프트" `preferredDuringSchedulingIgnoredDuringExecution`을 사용한다. -파드 어피니티와 안티-어피니티의 적합한 연산자는 `In`, `NotIn`, `Exists`, `DoesNotExist` 이다. +위의 어피니티 규칙은 `security=S1` 레이블이 있는 하나 이상의 기존 파드의 존와 동일한 존에 있는 노드에만 +파드를 스케줄링하도록 스케줄러에 지시한다. +더 정확히 말하면, 만약 `security=S1` 파드 레이블이 있는 하나 이상의 기존 파드를 실행하고 있는 노드가 +`zone=V`에 하나 이상 존재한다면, +스케줄러는 파드를 `topology.kubernetes.io/zone=V` 레이블이 있는 노드에 배치해야 한다. -원칙적으로, `topologyKey` 는 적법한 어느 레이블-키도 될 수 있다. -하지만, 성능과 보안상의 이유로 topologyKey에는 몇 가지 제약조건이 있다. +위의 안티-어피니티 규칙은 `security=S2` 레이블이 있는 하나 이상의 기존 파드의 존와 동일한 존에 있는 노드에는 +가급적 파드를 스케줄링하지 않도록 스케줄러에 지시한다. +더 정확히 말하면, 만약 `security=S2` 파드 레이블이 있는 파드가 실행되고 있는 `zone=R`에 +다른 노드도 존재한다면, +스케줄러는 `topology.kubernetes.io/zone=R` 레이블이 있는 노드에는 가급적 해당 파드를 스케줄링하지 않야아 한다. -1. 파드 어피니티에서 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 는 -`topologyKey` 의 빈 값을 허용하지 않는다. -2. 파드 안티-어피니티에서도 `requiredDuringSchedulingIgnoredDuringExecution` 와 `preferredDuringSchedulingIgnoredDuringExecution` 는 -`topologyKey` 의 빈 값을 허용하지 않는다. -3. `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티에서 `topologyKey` 를 `kubernetes.io/hostname` 로 제한하기 위해 어드미션 컨트롤러 `LimitPodHardAntiAffinityTopology` 가 도입되었다. 사용자 지정 토폴로지를 사용할 수 있도록 하려면, 어드미션 컨트롤러를 수정하거나 아니면 이를 비활성화해야 한다. -4. 위의 경우를 제외하고, `topologyKey` 는 적법한 어느 레이블-키도 가능하다. +[디자인 문서](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)에서 +파드 어피니티와 안티-어피니티에 대한 +많은 예시를 볼 수 있다. -`labelSelector` 와 `topologyKey` 외에도 `labelSelector` 와 일치해야 하는 네임스페이스 목록 `namespaces` 를 -선택적으로 지정할 수 있다(이것은 `labelSelector` 와 `topologyKey` 와 같은 수준의 정의이다). -생략되어 있거나 비어있을 경우 어피니티/안티-어피니티 정의가 있는 파드의 네임스페이스가 기본 값이다. +파드 어피니티와 안티-어피니티의 `operator` 필드에 +`In`, `NotIn`, `Exists` 및 `DoesNotExist` 값을 사용할 수 있다. -파드를 노드에 스케줄하려면 `requiredDuringSchedulingIgnoredDuringExecution` 어피니티와 안티-어피니티와 -연관된 `matchExpressions` 가 모두 충족되어야 한다. +원칙적으로, `topologyKey` 에는 성능과 보안상의 이유로 다음의 예외를 제외하면 +어느 레이블 키도 사용할 수 있다. -#### 네임스페이스 셀렉터 -{{< feature-state for_k8s_version="v1.22" state="beta" >}} +* 파드 어피니티 및 안티-어피니티에 대해, 빈 `topologyKey` 필드는 + `requiredDuringSchedulingIgnoredDuringExecution` 및 `preferredDuringSchedulingIgnoredDuringExecution` 내에 허용되지 않는다. +* `requiredDuringSchedulingIgnoredDuringExecution` 파드 안티-어피니티 규칙에 대해, + `LimitPodHardAntiAffinityTopology` 어드미션 컨트롤러는 + `topologyKey`를 `kubernetes.io/hostname`으로 제한한다. + 커스텀 토폴로지를 허용하고 싶다면 어드미션 컨트롤러를 수정하거나 비활성화할 수 있다. -사용자는 네임스페이스 집합에 대한 레이블 쿼리인 `namespaceSelector` 를 사용하여 일치하는 네임스페이스를 선택할 수도 있다. -어피니티 용어는 `namespaceSelector` 에서 선택한 네임스페이스와 `namespaces` 필드에 나열된 네임스페이스의 결합에 적용된다. -빈 `namespaceSelector` ({})는 모든 네임스페이스와 일치하는 반면, null 또는 빈 `namespaces` 목록과 -null `namespaceSelector` 는 "이 파드의 네임스페이스"를 의미한다. +`labelSelector`와 `topologyKey`에 더하여 선택적으로, +`labelSelector`가 비교해야 하는 네임스페이스의 목록을 +`labelSelector` 및 `topologyKey` 필드와 동일한 계위의 `namespaces` 필드에 명시할 수 있다. +생략하거나 비워 두면, +해당 어피니티/안티-어피니티 정의가 있는 파드의 네임스페이스를 기본값으로 사용한다. -이 기능은 베타이며 기본으로 활성화되어 있다. kube-apiserver 및 kube-scheduler 모두에서 -[기능 게이트](/ko/docs/reference/command-line-tools-reference/feature-gates/) -`PodAffinityNamespaceSelector` 를 사용하여 비활성화할 수 있다. +#### 네임스페이스 셀렉터 {#namespace-selector} +{{< feature-state for_k8s_version="v1.24" state="stable" >}} -#### 더 실용적인 유스케이스 +네임스페이스 집합에 대한 레이블 쿼리인 `namespaceSelector` 를 사용하여 일치하는 네임스페이스를 선택할 수도 있다. +`namespaceSelector` 또는 `namespaces` 필드에 의해 선택된 네임스페이스 모두에 적용된다. +빈 `namespaceSelector` ({})는 모든 네임스페이스와 일치하는 반면, +null 또는 빈 `namespaces` 목록과 null `namespaceSelector` 는 규칙이 적용된 파드의 네임스페이스에 매치된다. -파드간 어피니티와 안티-어피니티는 레플리카셋, 스테이트풀셋, 디플로이먼트 등과 같은 -상위 레벨 모음과 함께 사용할 때 더욱 유용할 수 있다. 워크로드 집합이 동일한 노드와 같이 +#### 더 실제적인 유스케이스 {#more-practical-use-cases} + +파드간 어피니티와 안티-어피니티는 레플리카셋, 스테이트풀셋, 디플로이먼트 등과 같은 +상위 레벨 모음과 함께 사용할 때 더욱 유용할 수 있다. +이러한 규칙을 사용하여, 워크로드 집합이 예를 들면 '동일한 노드'와 같이 동일하게 정의된 토폴로지와 같은 위치에 배치되도록 쉽게 구성할 수 있다. -##### 항상 같은 노드에 위치시키기 +redis와 같은 인-메모리 캐시를 사용하는 웹 애플리케이션을 실행하는 세 개의 노드로 구성된 클러스터를 가정한다. +이 때 웹 서버를 가능한 한 캐시와 같은 위치에서 실행되도록 하기 위해 +파드간 어피니티/안티-어피니티를 사용할 수 있다. -세 개의 노드가 있는 클러스터에서 웹 애플리케이션에는 redis와 같은 인-메모리 캐시가 있다. 웹 서버가 가능한 캐시와 함께 위치하기를 원한다. - -다음은 세 개의 레플리카와 셀렉터 레이블이 `app=store` 가 있는 간단한 redis 디플로이먼트의 yaml 스니펫이다. 디플로이먼트에는 스케줄러가 단일 노드에서 레플리카를 함께 배치하지 않도록 `PodAntiAffinity` 가 구성되어 있다. +다음의 redis 캐시 디플로이먼트 예시에서, 레플리카는 `app=store` 레이블을 갖는다. +`podAntiAffinity` 규칙은 스케줄러로 하여금 +`app=store` 레이블이 있는 레플리카를 한 노드에 여러 개 배치하지 못하도록 한다. +이렇게 하여 캐시 파드를 각 노드에 분산하여 생성한다. ```yaml apiVersion: apps/v1 @@ -324,7 +379,10 @@ spec: image: redis:3.2-alpine ``` -아래 yaml 스니펫의 웹서버 디플로이먼트는 `podAntiAffinity` 와 `podAffinity` 설정을 가지고 있다. 이렇게 하면 스케줄러에 모든 레플리카는 셀렉터 레이블이 `app=store` 인 파드와 함께 위치해야 한다. 또한 각 웹 서버 레플리카가 단일 노드의 같은 위치에 있지 않도록 한다. +웹 서버를 위한 다음의 디플로이먼트는 `app=web-store` 레이블을 갖는 레플리카를 생성한다. +파드 어피니티 규칙은 스케줄러로 하여금 `app=store` 레이블이 있는 파드를 실행 중인 노드에 각 레플리카를 배치하도록 한다. +파드 안티-어피니티 규칙은 스케줄러로 하여금 `app=web-store` 레이블이 있는 서버 파드를 +한 노드에 여러 개 배치하지 못하도록 한다. ```yaml apiVersion: apps/v1 @@ -365,44 +423,25 @@ spec: image: nginx:1.16-alpine ``` -만약 위의 두 디플로이먼트를 생성하면 세 개의 노드가 있는 클러스터는 다음과 같아야 한다. +위의 두 디플로이먼트를 생성하면 다음과 같은 클러스터 형상이 나타나는데, +세 노드에 각 웹 서버가 캐시와 함께 있는 형상이다. | node-1 | node-2 | node-3 | |:--------------------:|:-------------------:|:------------------:| | *webserver-1* | *webserver-2* | *webserver-3* | | *cache-1* | *cache-2* | *cache-3* | -여기서 볼 수 있듯이 `web-server` 의 세 레플리카들이 기대했던 것처럼 자동으로 캐시와 함께 위치하게 된다. +[ZooKeeper 튜토리얼](/ko/docs/tutorials/stateful-application/zookeeper/#노드-실패-방지)에서 +위 예시와 동일한 기술을 사용해 +고 가용성을 위한 안티-어피니티로 구성된 스테이트풀셋의 예시를 확인한다. -``` -kubectl get pods -o wide -``` -출력은 다음과 유사할 것이다. -``` -NAME READY STATUS RESTARTS AGE IP NODE -redis-cache-1450370735-6dzlj 1/1 Running 0 8m 10.192.4.2 kube-node-3 -redis-cache-1450370735-j2j96 1/1 Running 0 8m 10.192.2.2 kube-node-1 -redis-cache-1450370735-z73mh 1/1 Running 0 8m 10.192.3.1 kube-node-2 -web-server-1287567482-5d4dz 1/1 Running 0 7m 10.192.2.3 kube-node-1 -web-server-1287567482-6f7v5 1/1 Running 0 7m 10.192.4.3 kube-node-3 -web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3.2 kube-node-2 -``` +## nodeName {#nodename} -##### 절대 동일한 노드에 위치시키지 않게 하기 - -위의 예시에서 `topologyKey:"kubernetes.io/hostname"` 과 함께 `PodAntiAffinity` 규칙을 사용해서 -두 개의 인스터스가 동일한 호스트에 있지 않도록 redis 클러스터를 배포한다. -같은 기술을 사용해서 고 가용성을 위해 안티-어피니티로 구성된 스테이트풀셋의 예시는 -[ZooKeeper 튜토리얼](/ko/docs/tutorials/stateful-application/zookeeper/#노드-실패-방지)을 본다. - -## nodeName - -`nodeName` 은 가장 간단한 형태의 노트 선택 제약 조건이지만, -한계로 인해 일반적으로는 사용하지 않는다. -`nodeName` 은 PodSpec의 필드이다. 만약 비어있지 않으면, 스케줄러는 -파드를 무시하고 명명된 노드에서 실행 중인 kubelet이 -파드를 실행하려고 한다. 따라서 만약 PodSpec에 `nodeName` 가 -제공된 경우, 노드 선택을 위해 위의 방법보다 우선한다. +`nodeName`은 어피니티 또는 `nodeSelector`보다 더 직접적인 형태의 노드 선택 방법이다. +`nodeName`은 파드 스펙의 필드 중 하나이다. +`nodeName` 필드가 비어 있지 않으면, 스케줄러는 파드를 무시하고, +명명된 노드의 kubelet이 해당 파드를 자기 노드에 배치하려고 시도한다. +`nodeName`은 `nodeSelector` 또는 어피니티/안티-어피니티 규칙보다 우선적으로 적용(overrule)된다. `nodeName` 을 사용해서 노드를 선택할 때의 몇 가지 제한은 다음과 같다. @@ -414,7 +453,7 @@ web-server-1287567482-s330j 1/1 Running 0 7m 10.192.3 - 클라우드 환경의 노드 이름은 항상 예측 가능하거나 안정적인 것은 아니다. -여기에 `nodeName` 필드를 사용하는 파드 설정 파일 예시가 있다. +다음은 `nodeName` 필드를 사용하는 파드 스펙 예시이다. ```yaml apiVersion: v1 @@ -428,19 +467,14 @@ spec: nodeName: kube-01 ``` -위 파드는 kube-01 노드에서 실행될 것이다. - - +위 파드는 `kube-01` 노드에서만 실행될 것이다. ## {{% heading "whatsnext" %}} - -[테인트](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)는 노드가 특정 파드들을 *쫓아낼* 수 있다. - -[노드 어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)와 -[파드간 어피니티/안티-어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)에 대한 디자인 문서에는 -이러한 기능에 대한 추가 배경 정보가 있다. - -파드가 노드에 할당되면 kubelet은 파드를 실행하고 노드의 로컬 리소스를 할당한다. -[토폴로지 매니저](/docs/tasks/administer-cluster/topology-manager/)는 -노드 수준의 리소스 할당 결정에 참여할 수 있다. +* [테인트 및 톨러레이션](/ko/docs/concepts/scheduling-eviction/taint-and-toleration/)에 대해 더 읽어본다. +* [노드 어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md)와 + [파드간 어피니티/안티-어피니티](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md)에 대한 디자인 문서를 읽어본다. +* [토폴로지 매니저](/docs/tasks/administer-cluster/topology-manager/)가 + 노드 수준 리소스 할당 결정에 어떻게 관여하는지 알아본다. +* [노드셀렉터(nodeSelector)](/ko/docs/tasks/configure-pod-container/assign-pods-nodes/)를 어떻게 사용하는지 알아본다. +* [어피니티/안티-어피니티](/ko/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)를 어떻게 사용하는지 알아본다. diff --git a/content/ko/examples/pods/pod-with-affinity-anti-affinity.yaml b/content/ko/examples/pods/pod-with-affinity-anti-affinity.yaml new file mode 100644 index 0000000000..5dcc7693b6 --- /dev/null +++ b/content/ko/examples/pods/pod-with-affinity-anti-affinity.yaml @@ -0,0 +1,33 @@ +apiVersion: v1 +kind: Pod +metadata: + name: with-affinity-anti-affinity +spec: + affinity: + nodeAffinity: + requiredDuringSchedulingIgnoredDuringExecution: + nodeSelectorTerms: + - matchExpressions: + - key: topology.kubernetes.io/zone + operator: In + values: + - antarctica-east1 + - antarctica-west1 + preferredDuringSchedulingIgnoredDuringExecution: + - weight: 1 + preference: + matchExpressions: + - key: label-1 + operator: In + values: + - key-1 + - weight: 50 + preference: + matchExpressions: + - key: label-2 + operator: In + values: + - key-2 + containers: + - name: with-node-affinity + image: k8s.gcr.io/pause:2.0 diff --git a/content/ko/includes/task-tutorial-prereqs.md b/content/ko/includes/task-tutorial-prereqs.md index e27f4b99e4..9109e34433 100644 --- a/content/ko/includes/task-tutorial-prereqs.md +++ b/content/ko/includes/task-tutorial-prereqs.md @@ -4,5 +4,5 @@ [minikube](/ko/docs/tasks/tools/#minikube)를 사용해서 생성하거나 다음의 쿠버네티스 플레이그라운드 중 하나를 사용할 수 있다. -* [Katacoda](https://www.katacoda.com/courses/kubernetes/playground) +* [Killercoda](https://killercoda.com/playgrounds/scenario/kubernetes) * [Play with Kubernetes](https://labs.play-with-k8s.com/) diff --git a/content/pt-br/docs/concepts/overview/working-with-objects/namespaces.md b/content/pt-br/docs/concepts/overview/working-with-objects/namespaces.md index 81c67e04f2..40167e9986 100644 --- a/content/pt-br/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/pt-br/docs/concepts/overview/working-with-objects/namespaces.md @@ -75,7 +75,7 @@ kubectl config view --minify | grep namespace: Quando você cria um [Serviço](/docs/concepts/services-networking/service/), ele cria uma [entrada DNS](/docs/concepts/services-networking/dns-pod-service/) correspondente. Esta entrada possui o formato: `..svc.cluster.local`, de forma que se um contêiner utilizar apenas `` ele será resolvido para um serviço que é local ao namespace. -Isso é útil para utilizar a mesma configuração em vários namespaces, por exemplo em Desenvolvimento, `Staging` e Produç. Se você quiser acessar múltiplos namespaces, precisará utilizar um _Fully Qualified Domain Name_ (FQDN). +Isso é útil para utilizar a mesma configuração em vários namespaces, por exemplo em Desenvolvimento, `Staging` e Produção. Se você quiser acessar múltiplos namespaces, precisará utilizar um _Fully Qualified Domain Name_ (FQDN). ## Nem todos os objetos pertencem a algum Namespace diff --git a/content/pt-br/docs/concepts/security/overview.md b/content/pt-br/docs/concepts/security/overview.md index cfef9135f7..0cbbbf2961 100644 --- a/content/pt-br/docs/concepts/security/overview.md +++ b/content/pt-br/docs/concepts/security/overview.md @@ -103,7 +103,7 @@ vulnerável a um ataque de exaustão de recursos e, por consequência, o risco d Autorização RBAC (acesso à API Kubernetes) | https://kubernetes.io/docs/reference/access-authn-authz/rbac/ Autenticação | https://kubernetes.io/docs/concepts/security/controlling-access/ Gerenciamento de segredos na aplicação (e encriptando-os no etcd em repouso) | https://kubernetes.io/docs/concepts/configuration/secret/
https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/ -Políticas de segurança do Pod | https://kubernetes.io/docs/concepts/policy/pod-security-policy/ +Garantir que os Pods atendem aos padrões de segurança do Pod | https://kubernetes.io/docs/concepts/security/pod-security-standards/#policy-instantiation Qualidade de serviço (e gerenciamento de recursos de cluster) | https://kubernetes.io/docs/tasks/configure-pod-container/quality-service-pod/ Políticas de Rede | https://kubernetes.io/docs/concepts/services-networking/network-policies/ TLS para Kubernetes Ingress | https://kubernetes.io/docs/concepts/services-networking/ingress/#tls diff --git a/content/pt-br/docs/concepts/storage/persistent-volumes.md b/content/pt-br/docs/concepts/storage/persistent-volumes.md index 75b8e86fe0..12ff2700fe 100644 --- a/content/pt-br/docs/concepts/storage/persistent-volumes.md +++ b/content/pt-br/docs/concepts/storage/persistent-volumes.md @@ -22,7 +22,7 @@ O gerenciamento de armazenamento é uma questão bem diferente do gerenciamento Um _PersistentVolume_ (PV) é uma parte do armazenamento dentro do cluster que tenha sido provisionada por um administrador, ou dinamicamente utilizando [Classes de Armazenamento](/docs/concepts/storage/storage-classes/). Isso é um recurso dentro do cluster da mesma forma que um nó também é. PVs são plugins de volume da mesma forma que Volumes, porém eles têm um ciclo de vida independente de qualquer Pod que utilize um PV. Essa API tem por objetivo mostrar os detalhes da implementação do armazenamento, seja ele NFS, iSCSI, ou um armazenamento específico de um provedor de cloud pública. -Uma_PersistentVolumeClaim_ (PVC) é uma requisição para armazenamento por um usuário. É similar a um Pod. Pods utilizam recursos do nó e PVCs utilizam recursos do PV. Pods podem solicitar níveis específicos de recursos (CPU e Memória). Claims podem solicitar tamanho e modos de acesso específicos (exemplo: montagem como ReadWriteOnce, ReadOnlyMany ou ReadWriteMany, veja [Modos de Acesso](#modos-de-acesso)). +Uma _PersistentVolumeClaim_ (PVC) é uma requisição para armazenamento por um usuário. É similar a um Pod. Pods utilizam recursos do nó e PVCs utilizam recursos do PV. Pods podem solicitar níveis específicos de recursos (CPU e Memória). Claims podem solicitar tamanho e modos de acesso específicos (exemplo: montagem como ReadWriteOnce, ReadOnlyMany ou ReadWriteMany, veja [Modos de Acesso](#modos-de-acesso)). Enquanto as PersistentVolumeClaims permitem que um usuário utilize recursos de armazenamento de forma limitada, é comum que usuários precisem de PersistentVolumes com diversas propriedades, como desempenho, para problemas diversos. Os administradores de cluster precisam estar aptos a oferecer uma variedade de PersistentVolumes que difiram em tamanho e modo de acesso, sem expor os usuários a detalhes de como esses volumes são implementados. Para necessidades como essas, temos o recurso de _StorageClass_. diff --git a/content/pt-br/docs/reference/glossary/cluster-infrastructure.md b/content/pt-br/docs/reference/glossary/cluster-infrastructure.md new file mode 100644 index 0000000000..a65f04a346 --- /dev/null +++ b/content/pt-br/docs/reference/glossary/cluster-infrastructure.md @@ -0,0 +1,13 @@ +--- +title: Infraestrutura de Cluster +id: cluster-infrastructure +date: 2019-05-12 +full_link: +short_description: > + A camada de infraestrutura fornece e mantém máquinas virtuais, redes, grupos de segurança e outros. + +aka: +tags: +- operation +--- + A camada de infraestrutura fornece e mantém máquinas virtuais, redes, grupos de segurança e outros. diff --git a/content/ru/docs/tutorials/kubernetes-basics/_index.html b/content/ru/docs/tutorials/kubernetes-basics/_index.html index e6548931c3..ccdaefe8b8 100644 --- a/content/ru/docs/tutorials/kubernetes-basics/_index.html +++ b/content/ru/docs/tutorials/kubernetes-basics/_index.html @@ -99,7 +99,7 @@ card:
-
6. Обновление приложение
 +
6. Обновление приложения
diff --git a/content/ru/includes/task-tutorial-prereqs.md b/content/ru/includes/task-tutorial-prereqs.md index 0190567b09..4467c1d417 100644 --- a/content/ru/includes/task-tutorial-prereqs.md +++ b/content/ru/includes/task-tutorial-prereqs.md @@ -4,5 +4,5 @@ [Minikube](/docs/setup/learning-environment/minikube/), или вы можете использовать одну из песочниц Kubernetes: -* [Katacoda](https://www.katacoda.com/courses/kubernetes/playground) +* [Killercoda](https://killercoda.com/playgrounds/scenario/kubernetes) * [Play with Kubernetes](http://labs.play-with-k8s.com/) diff --git a/content/uk/docs/tutorials/kubernetes-basics/expose/expose-intro.html b/content/uk/docs/tutorials/kubernetes-basics/expose/expose-intro.html index d439553731..0b230ec82b 100644 --- a/content/uk/docs/tutorials/kubernetes-basics/expose/expose-intro.html +++ b/content/uk/docs/tutorials/kubernetes-basics/expose/expose-intro.html @@ -113,7 +113,7 @@ weight: 10
-

Service маршрутизує трафік між Pod'ами, що входять до його складу. Service - це абстракція, завдяки якій Pod'и в Kubernetes "вмирають" і відтворюються, не впливаючи на роботу вашого застосунку. Services в Kubernetes здійснюють виявлення і маршрутизацію між залежними Pod'ами (як наприклад, фронтенд- і бекенд-компоненти застосунку).

有关为博客提供内容的信息，请参见 -https://kubernetes.io/zh/docs/contribute/new-content/blogs-case-studies/#write-a-blog-post +https://kubernetes.io/zh-cn/docs/contribute/new-content/blogs-case-studies/#write-a-blog-post {{< /comment >}} \ No newline at end of file diff --git a/content/zh-cn/blog/_posts/2015-03-00-Kubernetes-Gathering-Videos.md b/content/zh-cn/blog/_posts/2015-03-00-Kubernetes-Gathering-Videos.md index 90dd2a1317..f085117d1c 100644 --- a/content/zh-cn/blog/_posts/2015-03-00-Kubernetes-Gathering-Videos.md +++ b/content/zh-cn/blog/_posts/2015-03-00-Kubernetes-Gathering-Videos.md @@ -1,18 +1,13 @@ --- - title: " Kubernetes 采集视频 " date: 2015-03-23 slug: kubernetes-gathering-videos --- - + @@ -114,6 +112,6 @@ Thanks to the advent of software-defined overlay networks such as [flannel](http With the growing popularity of container-based microservice architectures, the lessons Google has learned from running such systems internally have become of increasing interest to the external DevOps community. By revealing some of the inner workings of our cluster manager Borg, and building our next-generation cluster manager as both an open-source project (Kubernetes) and a publicly available hosted service ([Google Container Engine](http://cloud.google.com/container-engine)), we hope these lessons can benefit the broader community outside of Google and advance the state-of-the-art in container scheduling and cluster management. --> 随着基于容器的微服务架构的日益普及，Google 从内部运行此类系统所汲取的经验教训已引起外部 DevOps 社区越来越多的兴趣。 -通过揭示集群管理器 Borg 的一些内部工作原理，并将下一代集群管理器构建为一个开源项目（Kubernetes）和一个公开可用的托管服务（[Google Container Engine]（http://cloud.google.com/container-engine)) ，我们希望这些课程可以使 Google 之外的广大社区受益，并推动容器调度和集群管理方面的最新技术发展。 +通过揭示集群管理器 Borg 的一些内部工作原理，并将下一代集群管理器构建为一个开源项目（Kubernetes）和一个公开可用的托管服务（[Google Container Engine](http://cloud.google.com/container-engine)），我们希望这些课程可以使 Google 之外的广大社区受益，并推动容器调度和集群管理方面的最新技术发展。 diff --git a/content/zh-cn/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout.md b/content/zh-cn/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout.md index a95a116b49..323cdad934 100644 --- a/content/zh-cn/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout.md +++ b/content/zh-cn/blog/_posts/2015-04-00-Weekly-Kubernetes-Community-Hangout.md @@ -1,17 +1,15 @@ --- -title: " 每周 Kubernetes 社区例会笔记 - 2015年4月3日 " +title: " 每周 Kubernetes 社区例会笔记 - 2015 年 4 月 3 日 " date: 2015-04-04 slug: weekly-kubernetes-community-hangout -url: /zh/blog/2015/04/Weekly-Kubernetes-Community-Hangout --- + diff --git a/content/zh-cn/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 index 275cbead77..c715afe8b2 100644 --- a/content/zh-cn/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 @@ -1,17 +1,15 @@ - --- title: " 通过 RKT 对 Kubernetes 的 AppC 支持 " date: 2015-05-04 slug: appc-support-for-kubernetes-through-rkt -url: /zh/blog/2015/05/Appc-Support-For-Kubernetes-Through-Rkt --- + + diff --git a/content/zh-cn/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md b/content/zh-cn/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md index 68a50e93c8..0ac0f14276 100644 --- a/content/zh-cn/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md +++ b/content/zh-cn/blog/_posts/2015-05-00-Kubernetes-On-Openstack.md @@ -3,14 +3,11 @@ title: " OpenStack 上的 Kubernetes " date: 2015-05-19 slug: kubernetes-on-openstack --- - [![](https://3.bp.blogspot.com/-EOrCHChZJZE/VVZzq43g6CI/AAAAAAAAF-E/JUilRHk369E/s400/Untitled%2Bdrawing.jpg)](https://3.bp.blogspot.com/-EOrCHChZJZE/VVZzq43g6CI/AAAAAAAAF-E/JUilRHk369E/s1600/Untitled%2Bdrawing.jpg) diff --git a/content/zh-cn/blog/_posts/2015-05-00-Weekly-Kubernetes-Community-Hangout.md b/content/zh-cn/blog/_posts/2015-05-00-Weekly-Kubernetes-Community-Hangout.md index 8b7e00355d..39f88f204c 100644 --- a/content/zh-cn/blog/_posts/2015-05-00-Weekly-Kubernetes-Community-Hangout.md +++ b/content/zh-cn/blog/_posts/2015-05-00-Weekly-Kubernetes-Community-Hangout.md @@ -3,14 +3,11 @@ title: " Kubernetes 社区每周聚会笔记- 2015年5月1日 " date: 2015-05-11 slug: weekly-kubernetes-community-hangout --- - +url: /blog/2015/07/Announcing-First-Kubernetes-Enterprise +--> 在谷歌，我们依赖 Linux 容器应用程序去运行我们的核心基础架构。所有服务，从搜索引擎到Gmail服务，都运行在容器中。事实上，我们非常喜欢容器，甚至我们的谷歌云计算引擎虚拟机也运行在容器上！由于容器对于我们的业务至关重要，我们已经与社区合作开发许多基本的容器技术（从 cgroups 到 Docker 的 LibContainer）,甚至决定去构建谷歌的下一代开源容器调度技术，Kubernetes。 diff --git a/content/zh-cn/blog/_posts/2015-08-00-Weekly-Kubernetes-Community-Hangout.md b/content/zh-cn/blog/_posts/2015-08-00-Weekly-Kubernetes-Community-Hangout.md index 7e2bc24423..54f648fd5c 100644 --- a/content/zh-cn/blog/_posts/2015-08-00-Weekly-Kubernetes-Community-Hangout.md +++ b/content/zh-cn/blog/_posts/2015-08-00-Weekly-Kubernetes-Community-Hangout.md @@ -1,19 +1,15 @@ - ---- -title: " Kubernetes社区每周环聊笔记-2015年7月31日 " -date: 2015-08-04 -slug: weekly-kubernetes-community-hangout -url: /zh/blog/2015/08/Weekly-Kubernetes-Community-Hangout ---- - + diff --git a/content/zh-cn/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 index 2fb1d70b9f..1eecaafae6 100644 --- a/content/zh-cn/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 @@ -1,16 +1,13 @@ --- -title: " 使用 Puppet 管理 Kubernetes Pods，Services 和 Replication Controllers " +title: "使用 Puppet 管理 Kubernetes Pod、Service 和 Replication Controller" date: 2015-12-17 slug: managing-kubernetes-pods-services-and-replication-controllers-with-puppet --- - + diff --git a/content/zh-cn/blog/_posts/2017-11-00-Autoscaling-In-Kubernetes.md b/content/zh-cn/blog/_posts/2017-11-00-Autoscaling-In-Kubernetes.md index cab6c2b331..c30f22aa35 100644 --- a/content/zh-cn/blog/_posts/2017-11-00-Autoscaling-In-Kubernetes.md +++ b/content/zh-cn/blog/_posts/2017-11-00-Autoscaling-In-Kubernetes.md @@ -3,14 +3,11 @@ title: " Kubernetes 中自动缩放 " date: 2017-11-17 slug: autoscaling-in-kubernetes --- - -Kubernetes v1.10 使得可以通过 Beta 版本的[配置文件](/zh/docs/tasks/administer-cluster/kubelet-config-file/) +Kubernetes v1.10 使得可以通过 Beta 版本的[配置文件](/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/) API 配置 kubelet。 Kubernetes 已经提供了用于在 API 服务器中存储任意文件数据的 ConfigMap 抽象。 diff --git a/content/zh-cn/blog/_posts/2018-10-01-health-checking-grpc.md b/content/zh-cn/blog/_posts/2018-10-01-health-checking-grpc.md index e8a2ce686b..0b98ea5baf 100644 --- a/content/zh-cn/blog/_posts/2018-10-01-health-checking-grpc.md +++ b/content/zh-cn/blog/_posts/2018-10-01-health-checking-grpc.md @@ -21,7 +21,7 @@ To learn more, see [Configure Liveness, Readiness and Startup Probes](/docs/task This article was originally written about an external tool to achieve the same task._ --> **更新（2021 年 12 月）：** “Kubernetes 从 v1.23 开始具有内置 gRPC 健康探测。 -了解更多信息，请参阅[配置存活探针、就绪探针和启动探针](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)。 +了解更多信息，请参阅[配置存活探针、就绪探针和启动探针](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)。 本文最初是为有关实现相同任务的外部工具所写。” RuntimeClass 资源是将运行时属性显示到控制平面的重要基础。 例如，要对具有支持不同运行时间的异构节点的集群实施调度程序支持，我们可以在 RuntimeClass 定义中添加 -[NodeAffinity](/zh/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)条件。 +[NodeAffinity](/zh-cn/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity)条件。 另一个需要解决的领域是管理可变资源需求以运行不同运行时的 Pod。 [Pod Overhead 提案](https://docs.google.com/document/d/1EJKT4gyl58-kzt2bnwkv08MIUZ6lkDpXcxkHqCvvAp4/preview) 是一项较早的尝试，与 RuntimeClass 设计非常吻合，并且可能会进一步推广。 @@ -128,7 +128,7 @@ RuntimeClass will be under active development at least through 2019, and we’re --> - 试试吧！ 作为Alpha功能，还有一些其他设置步骤可以使用RuntimeClass。 - 有关如何使其运行，请参考 [RuntimeClass文档](/zh/docs/concepts/containers/runtime-class/#runtime-class) 。 + 有关如何使其运行，请参考 [RuntimeClass文档](/zh-cn/docs/concepts/containers/runtime-class/#runtime-class) 。 - 查看 [RuntimeClass Kubernetes 增强建议](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/runtime-class.md) 以获取更多细节设计细节。 - [沙盒隔离级别决策](https://docs.google.com/document/d/1fe7lQUjYKR0cijRmSbH_y0_l3CYPkwtQa5ViywuNo8Q/preview) 记录了最初使 RuntimeClass 成为 Pod 级别选项的思考过程。 diff --git a/content/zh-cn/blog/_posts/2018-11-08-kubernetes-docs-update-i18n.md b/content/zh-cn/blog/_posts/2018-11-08-kubernetes-docs-update-i18n.md index 90831b02b0..2f6895968a 100644 --- a/content/zh-cn/blog/_posts/2018-11-08-kubernetes-docs-update-i18n.md +++ b/content/zh-cn/blog/_posts/2018-11-08-kubernetes-docs-update-i18n.md @@ -63,8 +63,8 @@ Prow 根据文件路径自动添加语言标签。感谢 SIG Docs 贡献者 [Jun ### 团队审核 - -L10n 团队现在可以审查和批准他们自己的 PR。例如，英语的审核和批准权限在位于用于显示英语内容的顶级子文件夹中的 [OWNERS 文件中指定](https://github.com/kubernetes/website/blob/master/content/en/OWNERS)。 + +L10n 团队现在可以审查和批准他们自己的 PR。例如，英语的审核和批准权限在位于用于显示英语内容的顶级子文件夹中的 [OWNERS 文件中指定](https://github.com/kubernetes/website/blob/main/content/en/OWNERS)。 将 `OWNERS` 文件添加到子目录可以让本地化团队审查和批准更改，而无需由可能并不擅长该门语言的审阅者进行批准。 diff --git a/content/zh-cn/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 index 3ac5bc89c4..a14274d331 100644 --- a/content/zh-cn/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 @@ -1,12 +1,12 @@ --- +layout: blog title: Raw Block Volume 支持进入 Beta date: 2019-03-07 +slug: raw-block-volume-support-to-beta --- + **作者: Zach Corleissen（Linux 基金会）** 去年我们对 Kubernetes 网站进行了优化，加入了[多语言内容的支持](https://kubernetes.io/blog/2018/11/08/kubernetes-docs-updates-international-edition/)。贡献者们踊跃响应，加入了多种新的本地化内容：截至 2019 年 4 月，Kubernetes 文档有了 9 个不同语言的未完成版本，其中有 6 个是 2019 年加入的。在每个 Kubernetes 文档页面的上方，读者都可以看到一个语言选择器，其中列出了所有可用语言。 -不论是完成度最高的[中文版 v1.12](https://v1-12.docs.kubernetes.io/zh/)，还是最新加入的[葡萄牙文版 v1.14](https://kubernetes.io/pt/)，各语言的本地化内容还未完成，这是一个进行中的项目。如果读者有兴趣对现有本地化工作提供支持，请继续阅读。 +不论是完成度最高的[中文版 v1.12](https://v1-12.docs.kubernetes.io/zh-cn/)，还是最新加入的[葡萄牙文版 v1.14](https://kubernetes.io/pt/)，各语言的本地化内容还未完成，这是一个进行中的项目。如果读者有兴趣对现有本地化工作提供支持，请继续阅读。 + ## 什么是本地化 翻译是以词表意的问题。而本地化在此基础之上，还包含了过程和设计方面的工作。 @@ -18,6 +40,15 @@ date: 2019-04-26 本地化很重要，能够有效的降低 Kubernetes 的采纳和支持门槛。如果能用母语阅读 Kubernetes 文档，就能更轻松的开始使用 Kubernetes，并对其发展作出贡献。 + ## 如何启动本地化工作 不同语言的本地化工作都是单独的功能——和其它 Kubernetes 功能一致，贡献者们在一个 SIG 中进行本地化工作，分享出来进行评审，并加入项目。 @@ -26,6 +57,27 @@ date: 2019-04-26 每个团队都有自己的工作流。有些团队手工完成所有的内容翻译；有些会使用带有翻译插件的编译器，并使用评审机来提供正确性的保障。SIG Docs 专注于输出的标准；这就给了本地化团队采用适合自己工作情况的工作流。这样一来，团队可以根据最佳实践进行协作，并以 Kubernetes 的社区精神进行分享。 + ## 为本地化工作添砖加瓦 如果你有兴趣为 Kubernetes 文档加入新语种的本地化内容，[Kubernetes contribution guide](https://kubernetes.io/docs/contribute/localization/) 中包含了这方面的相关内容。 @@ -46,6 +98,14 @@ date: 2019-04-26 |葡萄牙文|[#kubernetes-docs-pt](https://kubernetes.slack.com/messages/CJ21AS0NA/)| |西班牙文|[#kubernetes-docs-es](https://kubernetes.slack.com/messages/CH7GB2E3B/)| + + ## 下一步？ 最新的[印地文本地化](https://kubernetes.slack.com/messages/CJ14B9BDJ/)工作正在启动。为什么不加入你的语言？ diff --git a/content/zh-cn/blog/_posts/2019-06-12-contributor-summit-shanghai.md b/content/zh-cn/blog/_posts/2019-06-12-contributor-summit-shanghai.md index 1d136352bd..ae932956ae 100644 --- a/content/zh-cn/blog/_posts/2019-06-12-contributor-summit-shanghai.md +++ b/content/zh-cn/blog/_posts/2019-06-12-contributor-summit-shanghai.md @@ -2,6 +2,7 @@ layout: blog title: '欢迎参加在上海举行的贡献者峰会' date: 2019-06-11 +slug: join-us-at-the-contributor-summit-in-shanghai --- + diff --git a/content/zh-cn/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 index d8e9d2a49e..31554dbe91 100644 --- a/content/zh-cn/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 @@ -69,9 +69,9 @@ Standard labels are used by Kubernetes components to support some features. For The labels are reaching general availability in this release. Kubernetes components have been updated to populate the GA and beta labels and to react to both. However, if you are using the beta labels in your pod specs for features such as node affinity, or in your custom controllers, we recommend that you start migrating them to the new GA labels. You can find the documentation for the new labels here: --> -- [实例类型](/zh/docs/reference/labels-annotations-taints/#nodekubernetesioinstance-type) -- [地区](/zh/docs/reference/labels-annotations-taints/#topologykubernetesioregion) -- [区域](/zh/docs/reference/labels-annotations-taints/#topologykubernetesiozone) +- [实例类型](/zh-cn/docs/reference/labels-annotations-taints/#nodekubernetesioinstance-type) +- [地区](/zh-cn/docs/reference/labels-annotations-taints/#topologykubernetesioregion) +- [区域](/zh-cn/docs/reference/labels-annotations-taints/#topologykubernetesiozone) -虽然在典型部署中，我们已按日志量更新了99％以上的日志条目，但仍有数千个日志需要更新。 选择一个您要改进的文件或目录，然后[迁移现有的日志调用以使用结构化日志]（https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/migration-to-structured-logging.md）。这是对Kubernetes做出第一笔贡献的好方法! +虽然在典型部署中，我们已按日志量更新了99％以上的日志条目，但仍有数千个日志需要更新。 选择一个您要改进的文件或目录，然后[迁移现有的日志调用以使用结构化日志](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/migration-to-structured-logging.md)。这是对Kubernetes做出第一笔贡献的好方法! diff --git a/content/zh-cn/blog/_posts/2020-09-30-writing-crl-scheduler/index.md b/content/zh-cn/blog/_posts/2020-09-30-writing-crl-scheduler/index.md index 05019ae42f..d2f1fa1e40 100644 --- a/content/zh-cn/blog/_posts/2020-09-30-writing-crl-scheduler/index.md +++ b/content/zh-cn/blog/_posts/2020-09-30-writing-crl-scheduler/index.md @@ -45,14 +45,14 @@ Most stateless systems, web servers for example, are created without the need to One of Kubernetes' responsibilities is to place "resources" (e.g, a disk or container) into the cluster and satisfy the constraints they request. For example: "I must be in availability zone _A_" (see [Running in multiple zones](/docs/setup/best-practices/multiple-zones/#nodes-are-labeled)), or "I can't be placed onto the same node as this other Pod" (see [Affinity and anti-affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity)). --> Kubernetes 的职责之一是将 "资源"（如磁盘或容器）放入集群中，并满足其请求的约束。 -例如。"我必须在可用性区域 _A_"（见[在多个区域运行](/zh/docs/setup/best-practices/multiple-zone/#nodes-are-labeled)）， +例如。"我必须在可用性区域 _A_"（见[在多个区域运行](/zh-cn/docs/setup/best-practices/multiple-zones/#nodes-are-labeled)）， 或者 "我不能被放置到与某个 Pod 相同的节点上" -（见[亲和与反亲和](/zh/docs/setup/best-practices/multiple-zone/#nodes-are-labeled)）。 +（见[亲和与反亲和](/zh-cn/docs/setup/best-practices/multiple-zones/#nodes-are-labeled)）。 -作为对这些约束的补充，Kubernetes 提供了 [StatefulSets](/zh/docs/concepts/workloads/controllers/statefulset/)， +作为对这些约束的补充，Kubernetes 提供了 [StatefulSets](/zh-cn/docs/concepts/workloads/controllers/statefulset/)， 为 Pod 提供身份，以及 "跟随" 这些指定 Pod 的持久化存储。 在 StatefulSet 中，身份是由 Pod 名称末尾一个呈增序的整数处理的。 值得注意的是，这个整数必须始终是连续的：在一个 StatefulSet 中， @@ -91,7 +91,7 @@ When adding additional resources to the cluster we also distribute them across z Note that anti-affinities are satisfied no matter the order in which pods are assigned to Kubernetes nodes. In the example, pods 0, 1 and 2 were assigned to zones A, B, and C respectively, but pods 3 and 4 were assigned in a different order, to zones B and A respectively. The anti-affinity is still satisfied because the pods are still placed in different zones. --> 请注意，无论 Pod 被分配到 Kubernetes 节点的顺序如何，都会满足反亲和性。 -在这个例子中，Pod 0、1 、2 分别被分配到 A、B 、C 区，但 Pod 3 和 4 以不同的顺序被分配到 B 和 A 区。 +在这个例子中，Pod 0、1、2 分别被分配到 A、B、C 区，但 Pod 3 和 4 以不同的顺序被分配到 B 和 A 区。 反亲和性仍然得到满足，因为 Pod 仍然被放置在不同的区域。 现在，请记住，规模为 _n_ 的 StatefulSet 中的 Pods 一定具有 `[0,n)` 范围内的 id。 当把一个 StatefulSet 规模缩减了 _m_ 时，Kubernetes 会移除 _m_ 个 Pod，从最高的序号开始，向最低的序号移动， -[与它们被添加的顺序相反](/zh/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantees)。 +[与它们被添加的顺序相反](/zh-cn/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantees)。 考虑一下下面的集群拓扑结构。 我们对以下内容的综合认识是导致这种误解的原因。 -* Kubernetes [自动跨区分配 Pod](/zh/docs/setup/best-practices/multiple-zone/#pods-are-spread-across-zone) 的能力 +* Kubernetes [自动跨区分配 Pod](/zh-cn/docs/setup/best-practices/multiple-zones/#pods-are-spread-across-zones) 的能力 * 一个有 _n_ 个副本的 StatefulSet，当 Pod 被部署时，它们会按照 `{0...n-1}` 的顺序依次创建。 -更多细节见 [StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantees)。 +更多细节见 [StatefulSet](/zh-cn/docs/concepts/workloads/controllers/statefulset/#deployment-and-scaling-guarantees)。 -_**更新**：本文有[较新版本](/zh/blog/2022/02/17/dockershim-faq/)。_ +_**更新**：本文有[较新版本](/zh-cn/blog/2022/02/17/dockershim-faq/)。_ 当然可以，在 1.20 版本中仅有的改变就是：如果使用 Docker 运行时，启动 -[kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) +[kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) 的过程中将打印一条警告日志。 另外还有一个需要关注的点，那就是当创建镜像时，系统维护或嵌入容器方面的任务将无法工作。 对于前者，可以用 [`crictl`](https://github.com/kubernetes-sigs/cri-tools) 工具作为临时替代方案 -(参见[从 docker 命令映射到 crictl](/zh/docs/reference/tools/map-crictl-dockercli/))； +(参见[从 docker 命令映射到 crictl](/zh-cn/docs/reference/tools/map-crictl-dockercli/))； 对于后者，可以用新的容器创建选项，比如 [cr](https://github.com/kubernetes-sigs/cri-tools)、 [img](https://github.com/genuinetools/img)、 @@ -315,7 +315,7 @@ For instructions on how to use containerd and CRI-O with Kubernetes, see the Kubernetes documentation on [Container Runtimes] --> 对于如何协同 Kubernetes 使用 containerd 和 CRI-O 的说明，参见 Kubernetes 文档中这部分： -[容器运行时](/zh/docs/setup/production-environment/container-runtimes)。 +[容器运行时](/zh-cn/docs/setup/production-environment/container-runtimes)。 **更新**：Kubernetes 通过 `dockershim` 对 Docker 的支持现已移除。 -有关更多信息，请阅读[移除 FAQ](/zh/dockershim)。 +有关更多信息，请阅读[移除 FAQ](/zh-cn/dockershim)。 你还可以通过专门的 [GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917) 讨论弃用。 还在寻求更多答案吗？请参考我们附带的 -[移除 Dockershim 的常见问题](/zh/blog/2020/12/02/dockershim-faq/) _(2022年2月更新)_。 +[移除 Dockershim 的常见问题](/zh-cn/blog/2020/12/02/dockershim-faq/) _(2022年2月更新)_。 diff --git a/content/zh-cn/blog/_posts/2020-12-08-kubernetes-release-1.20.md b/content/zh-cn/blog/_posts/2020-12-08-kubernetes-release-1.20.md index c88a1cf745..ccc01f3b33 100644 --- a/content/zh-cn/blog/_posts/2020-12-08-kubernetes-release-1.20.md +++ b/content/zh-cn/blog/_posts/2020-12-08-kubernetes-release-1.20.md @@ -56,7 +56,7 @@ evergreen: true 请注意，作为新的内置命令，`kubectl debug` 优先于任何名为 “debug” 的 kubectl 插件。你必须重命名受影响的插件。 -`kubectl alpha debug` 现在不推荐使用，并将在后续版本中删除。更新你的脚本以使用 `kubectl debug`。 有关更多信息 `kubectl debug`，请参阅[调试正在运行的 Pod]((https://kubernetes.io/zh/docs/tasks/debug/debug-application/debug-running-pod/)。 +`kubectl alpha debug` 现在不推荐使用，并将在后续版本中删除。更新你的脚本以使用 `kubectl debug`。 有关更多信息 `kubectl debug`，请参阅[调试正在运行的 Pod]((https://kubernetes.io/zh-cn/docs/tasks/debug/debug-application/debug-running-pod/)。 ### 测试版：API 优先级和公平性 {#beta-api-priority-and-fairness) @@ -110,7 +110,7 @@ Kubernetes 社区写了一篇关于弃用的详细[博客文章](https://blog.k8 新引入的 `ExecProbeTimeout` 特性门控所提供的修复使集群操作员能够恢复到以前的行为，但这种行为将在后续版本中锁定并删除。为了恢复到以前的行为，集群运营商应该将此特性门控设置为 `false`。 -有关更多详细信息，请查看有关配置探针的[更新文档](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes)。 +有关更多详细信息，请查看有关配置探针的[更新文档](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#configure-probes)。 ## 其他更新 {#other-updates} diff --git a/content/zh-cn/blog/_posts/2021-09-27-SIG-Node-Spotlight/index.md b/content/zh-cn/blog/_posts/2021-09-27-SIG-Node-Spotlight/index.md index c5da376b8d..1909f2cd33 100644 --- a/content/zh-cn/blog/_posts/2021-09-27-SIG-Node-Spotlight/index.md +++ b/content/zh-cn/blog/_posts/2021-09-27-SIG-Node-Spotlight/index.md @@ -168,7 +168,8 @@ SK/EH: It takes time and effort to get to any open source community. SIG Node ma ### 最后你有什么想法/资源要分享吗？ SK/EH：进入任何开源社区都需要时间和努力。一开始 SIG Node 可能会因为参与者的数量、工作量和项目范围而让你不知所措。但这是完全值得的。 -请加入我们这个热情的社区! [SIG Node GitHub Repo]（https://github.com/kubernetes/community/tree/master/sig-node）包含许多有用的资源，包括 Slack、邮件列表和其他联系信息。 +请加入我们这个热情的社区! [SIG Node GitHub Repo](https://github.com/kubernetes/community/tree/master/sig-node) +包含许多有用的资源，包括 Slack、邮件列表和其他联系信息。 -[Services](/zh/docs/concepts/services-networking/service/) 在 1.20 版本之前是单协议栈的， +[Services](/zh-cn/docs/concepts/services-networking/service/) 在 1.20 版本之前是单协议栈的， 因此，使用两个 IP 协议族意味着需为每个 IP 协议族创建一个 Service。在 1.20 版本中对用户体验进行简化， 重新实现了 Service 以支持两个 IP 协议族，这意味着一个 Service 就可以处理 IPv4 和 IPv6 协议。 对于 Service 而言，任意的 IPv4 和 IPv6 协议组合都可以实现负载均衡。 @@ -88,7 +88,7 @@ While Services are set according to what you configure, Pods default to whatever Even though dual-stack is possible, it is not mandatory to use it. Examples in the documentation show the variety possible in [dual-stack service configurations](/docs/concepts/services-networking/dual-stack/#dual-stack-service-configuration-scenarios). --> 尽管双协议栈是可用的，但并不强制你使用它。 -在[双协议栈服务配置](/zh/docs/concepts/services-networking/dual-stack/#dual-stack-service-configuration-scenarios) +在[双协议栈服务配置](/zh-cn/docs/concepts/services-networking/dual-stack/#dual-stack-service-configuration-scenarios) 文档中的示例列出了可能出现的各种场景. -虽然现在上游 Kubernetes 支持[双协议栈网络](/zh/docs/concepts/services-networking/dual-stack/) +虽然现在上游 Kubernetes 支持[双协议栈网络](/zh-cn/docs/concepts/services-networking/dual-stack/) 作为 GA 或稳定特性，但每个提供商对双协议栈 Kubernetes 的支持可能会有所不同。节点需要提供可路由的 IPv4/IPv6 网络接口。 -Pod 需要是双协议栈的。[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) +Pod 需要是双协议栈的。[网络插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) 是用来为 Pod 分配 IP 地址的，所以集群需要支持双协议栈的网络插件。一些容器网络接口（CNI）插件支持双协议栈，例如 kubenet。 支持双协议栈的生态系统在不断壮大；你可以使用 -[kubeadm 创建双协议栈集群](/zh/docs/setup/production-environment/tools/kubeadm/dual-stack-support/), +[kubeadm 创建双协议栈集群](/zh-cn/docs/setup/production-environment/tools/kubeadm/dual-stack-support/), 在本地尝试用 [KIND 创建双协议栈集群](https://kind.sigs.k8s.io/docs/user/configuration/#ip-family)， 还可以将双协议栈集群部署到云上（在查阅 CNI 或 kubenet 可用性的文档之后） diff --git a/content/zh-cn/blog/_posts/2021-12-16-StatefulSet-PVC-Auto-Deletion.md b/content/zh-cn/blog/_posts/2021-12-16-StatefulSet-PVC-Auto-Deletion.md index 6722e9bd4e..2f19fcae56 100644 --- a/content/zh-cn/blog/_posts/2021-12-16-StatefulSet-PVC-Auto-Deletion.md +++ b/content/zh-cn/blog/_posts/2021-12-16-StatefulSet-PVC-Auto-Deletion.md @@ -23,9 +23,9 @@ Kubernetes v1.23 introduced a new, alpha-level policy for StatefulSet spec template for cases when they should be deleted automatically when the StatefulSet is deleted or pods in the StatefulSet are scaled down. --> -Kubernetes v1.23 为 [StatefulSets](/zh/docs/concepts/workloads/controllers/statefulset/) +Kubernetes v1.23 为 [StatefulSets](/zh-cn/docs/concepts/workloads/controllers/statefulset/) 引入了一个新的 alpha 级策略，用来控制由 StatefulSet 规约模板生成的 -[PersistentVolumeClaims](/zh/docs/concepts/storage/persistent-volumes/) (PVCs) 的生命周期， +[PersistentVolumeClaims](/zh-cn/docs/concepts/storage/persistent-volumes/) (PVCs) 的生命周期， 用于当删除 StatefulSet 或减少 StatefulSet 中的 Pods 数量时 PVCs 应该被自动删除的场景。 -查阅[文档](/zh/docs/concepts/workloads/controllers/statefulset/#persistentvolumeclaim-policies) +查阅[文档](/zh-cn/docs/concepts/workloads/controllers/statefulset/#persistentvolumeclaim-policies) 获取更多详细信息。 Kubernetes 将在即将发布的 1.24 版本中移除 dockershim。我们很高兴能够通过支持开源容器运行时、支持更小的 kubelet 以及为使用 Kubernetes 的团队提高工程速度来重申我们的社区价值。 -如果你[使用 Docker Engine 作为 Kubernetes 集群的容器运行时](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/)， +如果你[使用 Docker Engine 作为 Kubernetes 集群的容器运行时](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/)， 请准备好在 1.24 中迁移！要检查你是否受到影响， -请参考[检查移除 Dockershim 对你的影响](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/)。 +请参考[检查移除 Dockershim 对你的影响](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/)。 ## 弃用时间线 {#deprecation-timeline} -我们[正式宣布](/zh/blog/2020/12/08/kubernetes-1-20-release-announcement/)于 +我们[正式宣布](/zh-cn/blog/2020/12/08/kubernetes-1-20-release-announcement/)于 2020 年 12 月弃用 dockershim。目标是在 2022 年 4 月， Kubernetes 1.24 中完全移除 dockershim。 -此时间线与我们的[弃用策略](/zh/docs/reference/using api/deprecation-policy/#deprecating-a-feature-or-behavior)一致， +此时间线与我们的[弃用策略](/zh-cn/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior)一致， 即规定已弃用的行为必须在其宣布弃用后至少运行 1 年。 -在这一点上，我们相信你（和 Kubernetes）从移除 dockershim 中获得的价值可以弥补你将要进行的迁移工作。 +在这一点上，我们相信你（和 Kubernetes）从移除 dockershim 中获得的价值可以弥补你将要进行的迁移工作。 现在就开始计划以避免出现意外。在 Kubernetes 1.24 发布之前，我们将提供更多更新信息和指南。 diff --git a/content/zh-cn/blog/_posts/2022-01-19-Securing-Admission-Controllers.md b/content/zh-cn/blog/_posts/2022-01-19-Securing-Admission-Controllers.md index 99dad347e5..caf4c05423 100644 --- a/content/zh-cn/blog/_posts/2022-01-19-Securing-Admission-Controllers.md +++ b/content/zh-cn/blog/_posts/2022-01-19-Securing-Admission-Controllers.md @@ -23,7 +23,7 @@ slug: secure-your-admission-controllers-and-webhooks [Admission control](/docs/reference/access-authn-authz/admission-controllers/) is a key part of Kubernetes security, alongside authentication and authorization. Webhook admission controllers are extensively used to help improve the security of Kubernetes clusters in a variety of ways including restricting the privileges of workloads and ensuring that images deployed to the cluster meet organization’s security requirements. --> -[准入控制](/zh/docs/reference/access-authn-authz/admission-controllers/)和认证、授权都是 Kubernetes 安全性的关键部分。 +[准入控制](/zh-cn/docs/reference/access-authn-authz/admission-controllers/)和认证、授权都是 Kubernetes 安全性的关键部分。 Webhook 准入控制器被广泛用于以多种方式帮助提高 Kubernetes 集群的安全性， 包括限制工作负载权限和确保部署到集群的镜像满足组织安全要求。 @@ -109,7 +109,7 @@ In most cases, the admission controller webhook used by a cluster will be instal -* **限制 [RBAC](/zh/docs/reference/access-authn-authz/rbac/) 权限**。 +* **限制 [RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/) 权限**。 任何有权修改 webhook 对象的配置或准入控制器使用的工作负载的用户都可以破坏其运行。 因此，确保只有集群管理员拥有这些权限非常重要。 diff --git a/content/zh-cn/blog/_posts/2022-02-17-updated-dockershim-faq.md b/content/zh-cn/blog/_posts/2022-02-17-updated-dockershim-faq.md index 8023f68989..cca8050a31 100644 --- a/content/zh-cn/blog/_posts/2022-02-17-updated-dockershim-faq.md +++ b/content/zh-cn/blog/_posts/2022-02-17-updated-dockershim-faq.md @@ -21,7 +21,7 @@ aliases: [ '/dockershim' ] published in late 2020. The article includes updates from the v1.24 release of Kubernetes.** --> -**本文是针对 2020 年末发布的[弃用 Dockershim 的常见问题](/zh/blog/2020/12/02/dockershim-faq/)的博客更新。 +**本文是针对 2020 年末发布的[弃用 Dockershim 的常见问题](/zh-cn/blog/2020/12/02/dockershim-faq/)的博客更新。 本文包括 Kubernetes v1.24 版本的更新。** --- @@ -36,7 +36,7 @@ from Kubernetes. --> 本文介绍了一些关于从 Kubernetes 中移除 _dockershim_ 的常见问题。 该移除最初是作为 Kubernetes v1.20 -版本的一部分[宣布](/zh/blog/2020/12/08/kubernetes-1-20-release-announcement/)的。 +版本的一部分[宣布](/zh-cn/blog/2020/12/08/kubernetes-1-20-release-announcement/)的。 Kubernetes 在 [v1.24 版](/releases/#release-v1-24)移除了 dockershim。 关于细节请参考博文 -[别慌: Kubernetes 和 Docker](/zh/blog/2020/12/02/dont-panic-kubernetes-and-docker/)。 +[别慌: Kubernetes 和 Docker](/zh-cn/blog/2020/12/02/dont-panic-kubernetes-and-docker/)。 要确定移除 dockershim 是否会对你或你的组织的影响，可以查阅： -[检查弃用 Dockershim 对你的影响](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/) +[检查弃用 Dockershim 对你的影响](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/) 这篇文章。 - 一篇详细说明[承诺和后续操作](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/)的博文。 -- 检查是否存在迁移到其他 [容器运行时](/zh/docs/setup/production-environment/container-runtimes/#container-runtimes) 的主要障碍。 +- 检查是否存在迁移到其他 [容器运行时](/zh-cn/docs/setup/production-environment/container-runtimes/#container-runtimes) 的主要障碍。 - 添加 [从 dockershim 迁移](/docs/tasks/administer-cluster/migrating-from-dockershim/)的指南。 -- 创建了一个[有关 dockershim 移除和使用 CRI 兼容运行时的列表](/zh/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/)。 +- 创建了一个[有关 dockershim 移除和使用 CRI 兼容运行时的列表](/zh-cn/docs/reference/node/topics-on-dockershim-and-cri-compatible-runtimes/)。 该列表包括一些已经提到的文档，还涵盖了选定的外部资源（包括供应商指南）。 可以使用，在 1.20 版本中唯一的改动是，如果使用 Docker Engine， -在 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) +在 [kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) 启动时会打印一个警告日志。 你将在 1.23 版本及以前版本看到此警告，dockershim 已在 Kubernetes 1.24 版本中移除 。 如果你运行的是 Kubernetes v1.24 或更高版本，请参阅 [我仍然可以使用 Docker Engine 作为我的容器运行时吗？](#can-i-still-use-docker-engine-as-my-container-runtime) @@ -341,7 +341,7 @@ and for the latter you can use newer container build options like [img], [builda --> 另外还有一个需要关注的点，那就是当创建镜像时，系统维护或嵌入容器方面的任务将无法工作。 对于前者，可以用 [`crictl`](https://github.com/kubernetes-sigs/cri-tools) 工具作为临时替代方案 -(参阅[从 docker cli 到 crictl 的映射](/zh/docs/tasks/debug/debug-cluster/crictl/#mapping-from-docker-cli-to-crictl))。 +(参阅[从 docker cli 到 crictl 的映射](/zh-cn/docs/tasks/debug/debug-cluster/crictl/#mapping-from-docker-cli-to-crictl))。 对于后者，可以用新的容器创建选项，例如 [img](https://github.com/genuinetools/img)、 [buildah](https://github.com/containers/buildah)、 diff --git a/content/zh-cn/blog/_posts/2022-03-31-ready-for-dockershim-removal.md b/content/zh-cn/blog/_posts/2022-03-31-ready-for-dockershim-removal.md index d5b6d10ae5..99de335164 100644 --- a/content/zh-cn/blog/_posts/2022-03-31-ready-for-dockershim-removal.md +++ b/content/zh-cn/blog/_posts/2022-03-31-ready-for-dockershim-removal.md @@ -20,12 +20,12 @@ slug: ready-for-dockershim-removal -早在 2020 年 12 月，Kubernetes 就宣布[弃用 Dockershim](/zh/blog/2020/12/02/dont-panic-kubernetes-and-docker/)。 +早在 2020 年 12 月，Kubernetes 就宣布[弃用 Dockershim](/zh-cn/blog/2020/12/02/dont-panic-kubernetes-and-docker/)。 在 Kubernetes 中，dockershim 是一个软件 shim， 它允许你将整个 Docker 引擎用作 Kubernetes 中的容器运行时。 在即将发布的 v1.24 版本中，我们将移除 Dockershim - 在宣布弃用之后到彻底移除这段时间内，我们至少预留了一年的时间继续支持此功能， -这符合相关的[项目策略](/zh/docs/reference/using-api/deprecation-policy/)。 +这符合相关的[项目策略](/zh-cn/docs/reference/using-api/deprecation-policy/)。 如果你是集群操作员，则该指南包含你在此版本中需要了解的实际情况。 另外还包括你需要做些什么来确保你的集群不会崩溃！ @@ -38,7 +38,7 @@ Way back in December of 2020, Kubernetes announced the [deprecation of Dockershi If you are rolling your own cluster or are otherwise unsure whether or not this removal affects you, stay on the safe side and [check to see if you have any dependencies on Docker Engine](/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/). Please note that using Docker Desktop to build your application containers is not a Docker dependency for your cluster. Container images created by Docker are compliant with the [Open Container Initiative (OCI)](https://opencontainers.org/), a Linux Foundation governance structure that defines industry standards around container formats and runtimes. They will work just fine on any container runtime supported by Kubernetes. --> 如果你正在管理自己的集群或不确定此删除是否会影响到你， -请保持安全状态并[检查你对 Docker Engine 是否有依赖](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/)。 +请保持安全状态并[检查你对 Docker Engine 是否有依赖](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-removal-affects-you/)。 请注意，使用 Docker Desktop 构建应用程序容器并不算是集群对 Docker 有依赖。 Docker 创建的容器镜像符合 [Open Container Initiative (OCI)](https://opencontainers.org/) 规范， 而 OCI 是 Linux 基金会的一种治理架构，负责围绕容器格式和运行时定义行业标准。 @@ -51,13 +51,13 @@ If you are using a managed Kubernetes service from a cloud provider, and you hav 并且你确定没有更改过容器运行时，那么你可能不需要做任何事情。 Amazon EKS、Azure AKS 和 Google GKE 现在都默认使用 containerd， 但如果你的集群中有任何自定义的节点，你要确保它们不需要被更新。 -要检查节点的运行时，请参考[查明节点上所使用的容器运行时](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/)。 +要检查节点的运行时，请参考[查明节点上所使用的容器运行时](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/)。 无论你是在管理自己的集群还是使用云服务提供商管理的 Kubernetes 服务， -你可能都需要[迁移依赖 Docker Engine 的遥测或安全代理](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/)。 +你可能都需要[迁移依赖 Docker Engine 的遥测或安全代理](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents/)。 -如果你仍有疑问，请先查看[弃用 Dockershim 的常见问题](/zh/blog/2022/02/17/dockershim-faq/)。 +如果你仍有疑问，请先查看[弃用 Dockershim 的常见问题](/zh-cn/blog/2022/02/17/dockershim-faq/)。 diff --git a/content/zh-cn/blog/_posts/2022-04-07-Kubernetes-1-24-removals-and-deprecations.md b/content/zh-cn/blog/_posts/2022-04-07-Kubernetes-1-24-removals-and-deprecations.md index ed73904af3..3963d3915a 100644 --- a/content/zh-cn/blog/_posts/2022-04-07-Kubernetes-1-24-removals-and-deprecations.md +++ b/content/zh-cn/blog/_posts/2022-04-07-Kubernetes-1-24-removals-and-deprecations.md @@ -67,7 +67,7 @@ the authors succinctly captured the change's impact and encouraged users to rema > Container Runtime Interface (CRI) created for Kubernetes. Docker-produced images > will continue to work in your cluster with all runtimes, as they always have. --> -在文章[别慌: Kubernetes 和 Docker](/zh/blog/2020/12/02/dont-panic-kubernetes-and-docker/) 中， +在文章[别慌: Kubernetes 和 Docker](/zh-cn/blog/2020/12/02/dont-panic-kubernetes-and-docker/) 中， 作者简洁地记述了变化的影响，并鼓励用户保持冷静： >弃用 Docker 这个底层运行时，转而支持符合为 Kubernetes 创建的容器运行接口 >Container Runtime Interface (CRI) 的运行时。 @@ -80,7 +80,7 @@ to container runtimes that are directly compatible with Kubernetes. You can find page in the Kubernetes documentation. --> 已经有一些文档指南，提供了关于从 dockershim 迁移到与 Kubernetes 直接兼容的容器运行时的有用信息。 -你可以在 Kubernetes 文档中的[从 dockershim 迁移](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/) +你可以在 Kubernetes 文档中的[从 dockershim 迁移](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/) 页面上找到它们。 有关 Kubernetes 为何不再使用 dockershim 的更多信息， 请参见：[Kubernetes 正在离开 Dockershim](/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim/) -和[最新的弃用 Dockershim 的常见问题](/zh/blog/2022/02/17/dockershim-faq/)。 +和[最新的弃用 Dockershim 的常见问题](/zh-cn/blog/2022/02/17/dockershim-faq/)。 查看[你的集群准备好使用 v1.24 了吗？](/blog/2022/03/31/ready-for-dockershim-removal/) 一文， 了解如何确保你的集群在从 1.23 版本升级到 1.24 版本后继续工作。 @@ -113,7 +113,7 @@ same API is available and that APIs have a minimum lifetime as indicated by the ## Kubernetes API 删除和弃用流程 {#the-Kubernetes-api-removal-and-deprecation-process} Kubernetes 包含大量随时间演变的组件。在某些情况下，这种演变会导致 API、标志或整个特性被删除。 -为了防止用户面对重大变化，Kubernetes 贡献者采用了一项特性[弃用策略](/zh/docs/reference/using-api/deprecation-policy/)。 +为了防止用户面对重大变化，Kubernetes 贡献者采用了一项特性[弃用策略](/zh-cn/docs/reference/using-api/deprecation-policy/)。 此策略确保仅当同一 API 的较新稳定版本可用并且 API 具有以下稳定性级别所指示的最短生命周期时，才可能弃用稳定版本 API： @@ -212,14 +212,14 @@ Docker Engine dependencies. Before upgrading to v1.24, you decide to either rema ## 需要做什么 {#what-to-do} ### 删除 Dockershim {#dockershim-removal} -如前所述，有一些关于从 [dockershim 迁移](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/)的指南。 -你可以[从查明节点上所使用的容器运行时](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/)开始。 +如前所述，有一些关于从 [dockershim 迁移](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/)的指南。 +你可以[从查明节点上所使用的容器运行时](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/find-out-runtime-you-use/)开始。 如果你的节点使用 dockershim，则还有其他可能的 Docker Engine 依赖项， 例如 Pod 或执行 Docker 命令的第三方工具或 Docker 配置文件中的私有注册表。 -你可以按照[检查弃用 Dockershim 对你的影响](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/) +你可以按照[检查弃用 Dockershim 对你的影响](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/check-if-dockershim-deprecation-affects-you/) 的指南来查看可能的 Docker 引擎依赖项。在升级到 1.24 版本之前， 你决定要么继续使用 Docker Engine 并 [将 Docker Engine 节点从 dockershim 迁移到 cri-dockerd](/docs/tasks/administer-cluster/migrating-from-dockershim/migrate-dockershim-dockerd/)， -要么迁移到与 CRI 兼容的运行时。这是[将节点上的容器运行时从 Docker Engine 更改为 containerd](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/) 的指南。 +要么迁移到与 CRI 兼容的运行时。这是[将节点上的容器运行时从 Docker Engine 更改为 containerd](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/) 的指南。 ### `kubectl convert` {#kubectl-convert} -kubectl 的 [`kubectl convert`](/zh/docs/tasks/tools/included/kubectl-convert-overview/) +kubectl 的 [`kubectl convert`](/zh-cn/docs/tasks/tools/included/kubectl-convert-overview/) 插件有助于解决弃用 API 的迁移问题。该插件方便了不同 API 版本之间清单的转换， 例如，从弃用的 API 版本到非弃用的 API 版本。关于 API 迁移过程的更多信息可以在 [已弃用 API 的迁移指南](/docs/reference/using-api/deprecation-guide/)中找到。按照 @@ -258,7 +258,7 @@ Kubernetes API 的 beta 版本，这些 API 当前为稳定版。1.25 版本还 -[Kubernetes 1.25 计划移除的 API 的官方列表](/zh/docs/reference/using-api/deprecation-guide/#v1-25)是： +[Kubernetes 1.25 计划移除的 API 的官方列表](/zh-cn/docs/reference/using-api/deprecation-guide/#v1-25)是： * The beta CronJob API (batch/v1beta1) * The beta EndpointSlice API (discovery.k8s.io/v1beta1) @@ -274,7 +274,7 @@ The official [list of API removals planned for Kubernetes 1.26](/docs/reference/ * The beta FlowSchema and PriorityLevelConfiguration APIs (flowcontrol.apiserver.k8s.io/v1beta1) * The beta HorizontalPodAutoscaler API (autoscaling/v2beta2) --> -[Kubernetes 1.25 计划移除的 API 的官方列表](/zh/docs/reference/using-api/deprecation-guide/#v1-25)是： +[Kubernetes 1.25 计划移除的 API 的官方列表](/zh-cn/docs/reference/using-api/deprecation-guide/#v1-25)是： * The beta FlowSchema 和 PriorityLevelConfiguration API (flowcontrol.apiserver.k8s.io/v1beta1) * The beta HorizontalPodAutoscaler API (autoscaling/v2beta2) @@ -297,5 +297,5 @@ Kubernetes 发行说明中宣告了弃用信息。你可以在以下版本的发 * 我们将正式宣布 [Kubernetes 1.24](https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.24.md#deprecation) 的弃用信息， 作为该版本 CHANGELOG 的一部分。 -有关弃用和删除过程的信息，请查看 Kubernetes 官方[弃用策略](/zh/docs/reference/using-api/deprecation-policy/#deprecating-parts-of-the-api) 文档。 +有关弃用和删除过程的信息，请查看 Kubernetes 官方[弃用策略](/zh-cn/docs/reference/using-api/deprecation-policy/#deprecating-parts-of-the-api) 文档。 diff --git a/content/zh-cn/blog/_posts/2022-05-03-dockershim-historical-context.md b/content/zh-cn/blog/_posts/2022-05-03-dockershim-historical-context.md index 5a99445271..1243b46d77 100644 --- a/content/zh-cn/blog/_posts/2022-05-03-dockershim-historical-context.md +++ b/content/zh-cn/blog/_posts/2022-05-03-dockershim-historical-context.md @@ -21,11 +21,12 @@ So what is the dockershim, and why is it going away? --> **作者：** Kat Cosgrove -自 Kubernetes v1.24 起，Dockershim 已被删除，这对项目来说是一个积极的举措。 -然而，背景对于充分理解某事很重要，无论是社交还是软件开发，这值得更深入的审查。 -除了 Kubernetes v1.24 中的 dockershim 移除之外，我们在社区中看到了一些 -混乱（有时处于恐慌级别）和对这一决定的不满，主要是由于缺乏有关此删除背景的了解。 -弃用并最终从 Kubernetes 中删除 dockershim 的决定并不是迅速或轻率地做出的。 +自 Kubernetes v1.24 起，Dockershim 已被删除，这对项目来说是一个积极的举措。 +然而，背景对于充分理解某事很重要，无论是社交还是软件开发，这值得更深入的审查。 +除了 Kubernetes v1.24 中的 dockershim 移除之外， +我们在社区中看到了一些混乱（有时处于恐慌级别）和对这一决定的不满， +主要是由于缺乏有关此删除背景的了解。弃用并最终从 Kubernetes 中删除 +dockershim 的决定并不是迅速或轻率地做出的。 尽管如此，它已经工作了很长时间，以至于今天的许多用户都比这个决定更新， 更不用提当初为何引入 dockershim 了。 @@ -34,55 +35,57 @@ So what is the dockershim, and why is it going away? -在 Kubernetes 的早期，我们只支持一个容器运行时，那个运行时就是 Docker Engine。 -那时，并没有太多其他选择，而 Docker 是使用容器的主要工具，所以这不是一个有争议的选择。 -最终，我们开始添加更多的容器运行时，比如 rkt 和 hypernetes，很明显 Kubernetes 用户 -希望选择最适合他们的运行时。 因此，Kubernetes 需要一种方法来允许集群操作员灵活地使用 -他们选择的任何运行时。 +在 Kubernetes 的早期，我们只支持一个容器运行时，那个运行时就是 Docker Engine。 +那时，并没有太多其他选择，而 Docker 是使用容器的主要工具，所以这不是一个有争议的选择。 +最终，我们开始添加更多的容器运行时，比如 rkt 和 hypernetes，很明显 Kubernetes +用户希望选择最适合他们的运行时。因此，Kubernetes 需要一种方法来允许集群操作员灵活地使用他们选择的任何运行时。 [容器运行时接口](/blog/2016/12/container-runtime-interface-cri-in-kubernetes/) (CRI) 已发布以支持这种灵活性。 CRI 的引入对项目和用户来说都很棒，但它确实引入了一个问题：Docker Engine -作为容器运行时的使用早于 CRI，并且 Docker Engine 不兼容 CRI。 为了解决这个问题，在 kubelet 组件 -中引入了一个小型软件 shim (dockershim)，专门用于填补 Docker Engine 和 CRI 之间的空白， +作为容器运行时的使用早于 CRI，并且 Docker Engine 不兼容 CRI。 为了解决这个问题，在 kubelet +组件中引入了一个小型软件 shim (dockershim)，专门用于填补 Docker Engine 和 CRI 之间的空白， 允许集群操作员继续使用 Docker Engine 作为他们的容器运行时基本上不间断。 -然而，这个小软件 shim 从来没有打算成为一个永久的解决方案。 多年来，它的存在给 kubelet -本身带来了许多不必要的复杂性。 由于这个 shim，Docker 的一些集成实现不一致，导致维护人员 -的负担增加，并且维护特定于供应商的代码不符合我们的开源理念。 为了减少这种维护负担并朝着支 -持开放标准的更具协作性的社区迈进，[引入了 KEP-2221](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2221- remove-dockershim)， -建议移除 dockershim。 随着 Kubernetes v1.20 的发布，正式弃用。 +然而，这个小软件 shim 从来没有打算成为一个永久的解决方案。 多年来，它的存在给 +kubelet 本身带来了许多不必要的复杂性。由于这个 shim，Docker +的一些集成实现不一致，导致维护人员的负担增加，并且维护特定于供应商的代码不符合我们的开源理念。 +为了减少这种维护负担并朝着支持开放标准的更具协作性的社区迈进， +[引入了 KEP-2221](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2221-remove-dockershim)， +建议移除 dockershim。随着 Kubernetes v1.20 的发布，正式弃用。 -我们没有很好地传达这一点，不幸的是，弃用公告在社区内引起了一些恐慌。关于这对 Docker 作为 -一家公司意味着什么，Docker 构建的容器镜像是否仍然可以运行，以及 Docker Engine 究竟是 -什么导致了社交媒体上的一场大火，人们感到困惑。这是我们的错；我们应该更清楚地传达当时发生 -的事情和原因。为了解决这个问题，我们发布了[一篇博客](/zh/blog/2020/12/02/dont-panic-kubernetes-and-docker/) -和[相应的 FAQ](/zh/blog/2020/12/02/dockershim-faq/ ) 以减轻社区的恐惧并纠正对 -Docker 是什么以及容器如何在 Kubernetes 中工作的一些误解。由于社区的关注，Docker 和 Mirantis -共同决定继续以 [cri-dockerd] 的形式支持 dockershim 代码（https://www.mirantis.com/blog/the-future-of-dockershim-is -cri-dockerd/)， -允许你在需要时继续使用 Docker Engine 作为容器运行时。对于想要尝试其他运行时（如 containerd 或 cri-o） -的用户，[已编写迁移文档](/zh/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/)。 +我们没有很好地传达这一点，不幸的是，弃用公告在社区内引起了一些恐慌。关于这对 +Docker作为一家公司意味着什么，Docker 构建的容器镜像是否仍然可以运行，以及 +Docker Engine 究竟是什么导致了社交媒体上的一场大火，人们感到困惑。 +这是我们的错；我们应该更清楚地传达当时发生的事情和原因。为了解决这个问题， +我们发布了[一篇博客](/zh-cn/blog/2020/12/02/dont-panic-kubernetes-and-docker/)和[相应的 FAQ](/zh-cn/blog/2020/12/02/dockershim-faq/) +以减轻社区的恐惧并纠正对 Docker 是什么以及容器如何在 Kubernetes 中工作的一些误解。 +由于社区的关注，Docker 和 Mirantis 共同决定继续以 +[cri-dockerd](https://www.mirantis.com/blog/the-future-of-dockershim-is-cri-dockerd/) +的形式支持 dockershim 代码，允许你在需要时继续使用 Docker Engine 作为容器运行时。 +对于想要尝试其他运行时（如 containerd 或 cri-o）的用户， +[已编写迁移文档](/zh-cn/docs/tasks/administer-cluster/migrating-from-dockershim/change-runtime-containerd/)。 -我们后来[调查了社区](https://kubernetes.io/blog/2021/11/12/are-you-ready-for-dockershim-removal/) -[发现还有很多用户有疑问和顾虑](/zh/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim)。 -作为回应，Kubernetes 维护人员和 CNCF 承诺通过扩展文档和其他程序来解决这些问题。 事实上，这篇博文是 -这个计划的一部分。 随着如此多的最终用户成功迁移到其他运行时，以及改进的文档，我们相信每个人现在都为迁移铺平了道路。 +我们后来[调查了社区](https://kubernetes.io/blog/2021/11/12/are-you-ready-for-dockershim-removal/)[发现还有很多用户有疑问和顾虑](/zh-cn/blog/2022/01/07/kubernetes-is-moving-on-from-dockershim)。 +作为回应，Kubernetes 维护人员和 CNCF 承诺通过扩展文档和其他程序来解决这些问题。 +事实上，这篇博文是这个计划的一部分。随着如此多的最终用户成功迁移到其他运行时，以及改进的文档， +我们相信每个人现在都为迁移铺平了道路。 -Docker 不会消失，无论是作为一种工具还是作为一家公司。 它是云原生社区的重要组成部分， -也是 Kubernetes 项目的历史。 没有他们，我们就不会是现在的样子。 也就是说，从 kubelet -中删除 dockershim 最终对社区、生态系统、项目和整个开源都有好处。 这是我们所有人齐心协力 -支持开放标准的机会，我们很高兴在 Docker 和社区的帮助下这样做。 \ No newline at end of file +Docker 不会消失，无论是作为一种工具还是作为一家公司。它是云原生社区的重要组成部分， +也是 Kubernetes 项目的历史。没有他们，我们就不会是现在的样子。也就是说，从 kubelet +中删除 dockershim 最终对社区、生态系统、项目和整个开源都有好处。 +这是我们所有人齐心协力支持开放标准的机会，我们很高兴在 Docker 和社区的帮助下这样做。 diff --git a/content/zh-cn/blog/_posts/2022-05-05-volume-expansion-ga.md b/content/zh-cn/blog/_posts/2022-05-05-volume-expansion-ga.md index 7b1872e34e..3a5ae01872 100644 --- a/content/zh-cn/blog/_posts/2022-05-05-volume-expansion-ga.md +++ b/content/zh-cn/blog/_posts/2022-05-05-volume-expansion-ga.md @@ -111,7 +111,7 @@ CSI 驱动必须在控制器或节点服务（如果合适，二者兼备） 请参阅 CSI 驱动的文档，了解其是否支持卷扩充。 有关支持卷扩充的树内（intree）卷类型， -请参阅卷扩充文档：[扩充 PVC 申领](/zh/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)。 +请参阅卷扩充文档：[扩充 PVC 申领](/zh-cn/docs/concepts/storage/persistent-volumes/#expanding-persistent-volumes-claims)。 -在 Kubernetes v1.24 版本中，[存储容量](/zh/docs/concepts/storage/storage-capacity/)跟踪已经成为一项正式发布的功能。 +在 Kubernetes v1.24 版本中，[存储容量](/zh-cn/docs/concepts/storage/storage-capacity/)跟踪已经成为一项正式发布的功能。 + + +**作者**：Sergey Kanzhelev (Google) + + +在 Kubernetes 1.24 中，gRPC 探针（probe）功能进入了 beta 阶段，默认情况下可用。 +现在，你可以为 gRPC 应用程序配置启动、活跃和就绪探测，而无需公开任何 HTTP 端点， +也不需要可执行文件。Kubernetes 可以通过 gRPC 直接连接到你的工作负载并查询其状态。 + + +## 一些历史 + +让管理你的工作负载的系统检查应用程序是否健康、启动是否正常，以及应用程序是否认为自己可以接收流量，是很有用的。 +在添加 gRPC 探针支持之前，Kubernetes 已经允许你通过从容器镜像内部运行可执行文件、发出 HTTP +请求或检查 TCP 连接是否成功来检查健康状况。 + + +对于大多数应用程序来说，这些检查就足够了。如果你的应用程序提供了用于运行状况（或准备就绪）检查的 +gRPC 端点，则很容易重新调整 `exec` 探针的用途，将其用于 gRPC 运行状况检查。 +在博文[在 Kubernetes 上对 gRPC 服务器进行健康检查](/zh-cn/blog/2018/10/01/health-checking-grpc-servers-on-kubernetes/)中， +Ahmet Alp Balkan 描述了如何做到这一点 —— 这种机制至今仍在工作。 + + +2018 年 8 月 21 日所[创建](https://github.com/grpc-ecosystem/grpc-health-probe/commit/2df4478982e95c9a57d5fe3f555667f4365c025d)的一种常用工具可以启用此功能， +工具于 [2018 年 9 月 19 日](https://github.com/grpc-ecosystem/grpc-health-probe/releases/tag/v0.1.0-alpha.1)首次发布。 + + +这种 gRPC 应用健康检查的方法非常受欢迎。使用 GitHub 上的基本搜索，发现了带有 `grpc_health_probe` +的 [3,626 个 Dockerfile 文件](https://github.com/search?l=Dockerfile&q=grpc_health_probe&type=code)和 +[6,621 个 yaml 文件](https://github.com/search?l=YAML&q=grpc_health_probe&type=Code)（在撰写本文时）。 +这很好地表明了该工具的受欢迎程度，以及对其本地支持的需求。 + + +Kubernetes v1.23 引入了一个 alpha 质量的实现，原生支持使用 gRPC 查询工作负载状态。 +因为这是一个 alpha 特性，所以在 1.23 版中默认是禁用的。 + + +## 使用该功能 + +我们用与其他探针类似的方式构建了 gRPC 健康检查，相信如果你熟悉 Kubernetes 中的其他探针类型， +它会[很容易使用](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe)。 +与涉及 `grpc_health_probe` 可执行文件的解决办法相比，原生支持的健康探针有许多好处。 + + +有了原生 gRPC 支持，你不需要在镜像中下载和携带 `10MB` 的额外可执行文件。 +Exec 探针通常比 gRPC 调用慢，因为它们需要实例化一个新进程来运行可执行文件。 +当 Pod 在最大资源下运行并且在实例化新进程时遇到困难时，它还使得对边界情况的检查变得不那么智能。 + + +不过有一些限制。由于为探针配置客户端证书很难，因此不支持依赖客户端身份验证的服务。 +内置探针也不检查服务器证书，并忽略相关问题。 + + +内置检查也不能配置为忽略某些类型的错误（`grpc_health_probe` 针对不同的错误返回不同的退出代码）， +并且不能“串接”以在单个探测中对多个服务运行健康检查。 + + +但是所有这些限制对于 gRPC 来说都是相当标准的，并且有简单的解决方法。 + + +## 自己试试 + +### 集群级设置 + +你现在可以尝试这个功能。要尝试原生 gRPC 探针，你可以自己启动一个启用了 +`GRPCContainerProbe` 特性门控的 Kubernetes 集群，可用的[工具](/zh-cn/docs/tasks/tools/)有很多。 + + +由于特性门控 `GRPCContainerProbe` 在 1.24 版本中是默认启用的，因此许多供应商支持此功能开箱即用。 +因此，你可以在自己选择的平台上创建 1.24 版本集群。一些供应商允许在 1.23 版本集群上启用 alpha 特性。 + + +例如，在编写本文时，你可以在 GKE 上运行测试集群来进行快速测试。 +其他供应商可能也有类似的功能，尤其是当你在 Kubernetes 1.24 版本发布很久后才阅读这篇博客时。 + + +在 GKE 上使用以下命令（注意，版本是 `1.23`，并且指定了 `enable-kubernetes-alpha`）。 + +```shell +gcloud container clusters create test-grpc \ + --enable-kubernetes-alpha \ + --no-enable-autorepair \ + --no-enable-autoupgrade \ + --release-channel=rapid \ + --cluster-version=1.23 +``` + + +你还需要配置 kubectl 来访问集群： + +```shell +gcloud container clusters get-credentials test-grpc +``` + + +### 试用该功能 + +让我们创建 Pod 来测试 gRPC 探针是如何工作的。对于这个测试，我们将使用 `agnhost` 镜像。 +这是一个 k8s 维护的镜像，可用于各种工作负载测试。例如，它有一个有用的 +[grpc-health-checking](https://github.com/kubernetes/kubernetes/blob/b2c5bd2a278288b5ef19e25bf7413ecb872577a4/test/images/agnhost/README.md#grpc-health-checking) +模块，该模块暴露了两个端口：一个是提供健康检查服务的端口，另一个是对 `make-serving` 和 +`make-not-serving` 命令做出反应的 http 端口。 + + +下面是一个 Pod 定义示例。它启用 `grpc-health-checking` 模块，暴露 5000 和 8080 端口，并配置 gRPC 就绪探针： + +``` yaml +--- +apiVersion: v1 +kind: Pod +metadata: + name: test-grpc +spec: + containers: + - name: agnhost + image: k8s.gcr.io/e2e-test-images/agnhost:2.35 + command: ["/agnhost", "grpc-health-checking"] + ports: + - containerPort: 5000 + - containerPort: 8080 + readinessProbe: + grpc: + port: 5000 +``` + + +如果文件名为 `test.yaml`，你可以用以下命令创建 Pod，并检查它的状态。如输出片段所示，Pod 将处于就绪状态。 + +```shell +kubectl apply -f test.yaml +kubectl describe test-grpc +``` + + +输出将包含如下内容： + +``` +Conditions: + Type Status + Initialized True + Ready True + ContainersReady True + PodScheduled True +``` + + +现在让我们将健康检查端点状态更改为 `NOT_SERVING`。为了调用 Pod 的 http 端口，让我们创建一个端口转发： + +```shell +kubectl port-forward test-grpc 8080:8080 +``` + + +你可以用 `curl` 来调用这个命令。 + +```shell +curl http://localhost:8080/make-not-serving +``` + + +几秒钟后，端口状态将切换到未就绪。 + +```shell +kubectl describe pod test-grpc +``` + + +现在的输出将显示： + +``` +Conditions: + Type Status + Initialized True + Ready False + ContainersReady False + PodScheduled True + +... + + Warning Unhealthy 2s (x6 over 42s) kubelet Readiness probe failed: service unhealthy (responded with "NOT_SERVING") +``` + + +一旦切换回来，Pod 将在大约一秒钟后恢复到就绪状态： + +``` bsh +curl http://localhost:8080/make-serving +kubectl describe test-grpc +``` + + +输出表明 Pod 恢复为 `Ready`： + +``` +Conditions: + Type Status + Initialized True + Ready True + ContainersReady True + PodScheduled True +``` + + +Kubernetes 上这种新的内置 gRPC 健康探测，使得通过 gRPC 实现健康检查比依赖使用额外的 `exec` +探测的旧方法更容易。请阅读官方 +[文档](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/#define-a-grpc-liveness-probe) +了解更多信息并在该功能正式发布（GA）之前提供反馈。 + + +## 总结 + +Kubernetes 是一个流行的工作负载编排平台，我们根据反馈和需求添加功能。 +像 gRPC 探针支持这样的特性是一个小的改进，它将使许多应用程序开发人员的生活更容易，应用程序更有弹性。 +在该功能 GA（正式发布）之前，现在就试试，并给出反馈。 diff --git a/content/zh-cn/blog/_posts/2022-05-16-volume-populators-beta.md b/content/zh-cn/blog/_posts/2022-05-16-volume-populators-beta.md index 7f4e5f5b38..cb867f9837 100644 --- a/content/zh-cn/blog/_posts/2022-05-16-volume-populators-beta.md +++ b/content/zh-cn/blog/_posts/2022-05-16-volume-populators-beta.md @@ -245,7 +245,7 @@ of this feature. [Volume populators and data sources](/docs/concepts/storage/persistent-volumes/#volume-populators-and-data-sources), within the documentation topic about persistent volumes, explains how to use this feature in your cluster. --> -[卷填充器与数据源](/zh/docs/concepts/storage/persistent-volumes/#volume-populators-and-data-sources), +[卷填充器与数据源](/zh-cn/docs/concepts/storage/persistent-volumes/#volume-populators-and-data-sources), 在有关持久卷的文档主题中，解释了如何在集群中使用此功能。 Kubernetes v1.24 引入了一个新的 alpha 级特性，可以防止未经授权的用户修改基于 Kubernetes -集群中已有的 [`VolumeSnapshot`](/zh/docs/concepts/storage/volume-snapshots/) -创建的 [`PersistentVolumeClaim`](/zh/docs/concepts/storage/persistent-volumes/) 的卷模式。 +集群中已有的 [`VolumeSnapshot`](/zh-cn/docs/concepts/storage/volume-snapshots/) +创建的 [`PersistentVolumeClaim`](/zh-cn/docs/concepts/storage/persistent-volumes/) 的卷模式。 -[卷模式](/zh/docs/concepts/storage/persistent-volumes/#volume-mode)确定卷是格式化为文件系统还是显示为原始块设备。 +[卷模式](/zh-cn/docs/concepts/storage/persistent-volumes/#volume-mode)确定卷是格式化为文件系统还是显示为原始块设备。 3. 给 `VolumeSnapshotContent` 添加 - [`snapshot.storage.kubernetes.io/allowVolumeModeChange`](/zh/docs/reference/labels-annotations-taints/#snapshot-storage-kubernetes-io-allowvolumemodechange) + [`snapshot.storage.kubernetes.io/allowVolumeModeChange`](/zh-cn/docs/reference/labels-annotations-taints/#snapshot-storage-kubernetes-io-allowvolumemodechange) 注解。 -在 Kubernetes 中，[Services](/zh/docs/concepts/services-networking/service/) +在 Kubernetes 中，[Services](/zh-cn/docs/concepts/services-networking/service/) 是一种抽象，用来暴露运行在一组 Pod 上的应用。 Service 可以有一个集群范围的虚拟 IP 地址（使用 `type: ClusterIP` 的 Service）。 客户端可以使用该虚拟 IP 地址进行连接， Kubernetes 为对该 Service 的访问流量提供负载均衡，以访问不同的后端 Pod。 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 index 4752273dad..a0565b93f8 100644 --- 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 @@ -22,7 +22,7 @@ block for running complex stateful applications. As the use of Kubernetes has gr 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. --> -Kubernetes [StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/)， +Kubernetes [StatefulSet](/zh-cn/docs/concepts/workloads/controllers/statefulset/)， 自 1.5 版本中引入并在 1.9 版本中变得稳定以来，已被广泛用于运行有状态应用。它提供固定的 Pod 身份标识、 每个 Pod 的持久存储以及 Pod 的有序部署、扩缩容和滚动更新功能。你可以将 StatefulSet 视为运行复杂有状态应用程序的原子构建块。随着 Kubernetes 的使用增多，需要 StatefulSet 的场景也越来越多。 @@ -233,7 +233,7 @@ break applications or catch them by surprise? Please [open an issue](https://git - [Enhancement Tracking Issue](https://github.com/kubernetes/enhancements/issues/961) --> ## 进一步阅读和后续步骤 {#next-steps} -- [最多不可用 Pod 数](/zh/docs/concepts/workloads/controllers/statefulset/#maximum-unavailable-pods) +- [最多不可用 Pod 数](/zh-cn/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-cn/blog/_posts/2022-06-01-annual-report-2021.md b/content/zh-cn/blog/_posts/2022-06-01-annual-report-2021.md new file mode 100644 index 0000000000..93c119560b --- /dev/null +++ b/content/zh-cn/blog/_posts/2022-06-01-annual-report-2021.md @@ -0,0 +1,51 @@ +--- +layout: blog +title: "2021 年度总结报告" +date: 2022-06-01 +slug: annual-report-summary-2021 +--- + + + +**作者：**Paris Pittman（指导委员会） + + +去年，我们发布了第一期 +[2020 年度总结报告](/blog/2021/06/28/announcing-kubernetes-community-group-annual-reports/)， +现在已经是时候发布第二期了！ + +[2021 年度总结报告](https://www.cncf.io/reports/kubernetes-annual-report-2021/) + + +这份总结反映了 2021 年已完成的工作以及 2022 下半年置于台面上的倡议。 +请将这份总结转发给正参与上游活动、计划云原生战略和寻求帮助的那些组织和个人。 +若要查阅特定社区小组的完整报告，请访问 +[kubernetes/community 仓库](https://github.com/kubernetes/community)查找各小组的文件夹。例如： +[sig-api-machinery/annual-report-2021.md](https://github.com/kubernetes/community/blob/master/sig-api-machinery/annual-report-2021.md) + + +你将看到这份总结报告本身涵盖的领域在增长。我们准备和制作这份报告大约用了 6 个月的时间。 +作为一个随着长短期需求而快速发展的项目，这么长的制作周期对任何人来说可能帮助都不大， +报告的价值也有所缩水。我等苦思无良策，请诸君不吝赐教： +https://github.com/kubernetes/steering/issues/242 + +参考： +[年度报告文献](https://github.com/kubernetes/community/blob/master/committee-steering/governance/annual-reports.md) diff --git a/content/zh-cn/community/code-of-conduct.md b/content/zh-cn/community/code-of-conduct.md index e5942dc439..3dc283fec8 100644 --- a/content/zh-cn/community/code-of-conduct.md +++ b/content/zh-cn/community/code-of-conduct.md @@ -15,13 +15,13 @@ community_styles_migrated: true

Kubernetes 遵循 -CNCF 行为规范。 +CNCF 行为规范。 CNCF 社区规范文本如下链接 commit 0ce4694。 如果你发现这个 CNCF 社区规范文本已经过时，请 diff --git a/content/zh-cn/docs/concepts/architecture/cloud-controller.md b/content/zh-cn/docs/concepts/architecture/cloud-controller.md index 05caa7690f..2e1e65850f 100644 --- a/content/zh-cn/docs/concepts/architecture/cloud-controller.md +++ b/content/zh-cn/docs/concepts/architecture/cloud-controller.md @@ -93,12 +93,12 @@ hosts running inside your tenancy with the cloud provider. The node controller p cluster. --> 1. 使用从云平台 API 获取的对应服务器的唯一标识符更新 Node 对象； -2. 利用特定云平台的信息为 Node 对象添加注解和标签，例如节点所在的 - 区域（Region）和所具有的资源（CPU、内存等等）； +2. 利用特定云平台的信息为 Node 对象添加注解和标签，例如节点所在的区域 + （Region）和所具有的资源（CPU、内存等等）； 3. 获取节点的网络地址和主机名； -4. 检查节点的健康状况。如果节点无响应，控制器通过云平台 API 查看该节点是否 - 已从云中禁用、删除或终止。如果节点已从云中删除，则控制器从 Kubernetes 集群 - 中删除 Node 对象。 +4. 检查节点的健康状况。如果节点无响应，控制器通过云平台 API + 查看该节点是否已从云中禁用、删除或终止。如果节点已从云中删除， + 则控制器从 Kubernetes 集群中删除 Node 对象。 ### 路由控制器 {#route-controller} -Route 控制器负责适当地配置云平台中的路由，以便 Kubernetes 集群中不同节点上的 -容器之间可以相互通信。 +Route 控制器负责适当地配置云平台中的路由，以便 Kubernetes 集群中不同节点上的容器之间可以相互通信。 取决于云驱动本身，路由控制器可能也会为 Pod 网络分配 IP 地址块。 @@ -195,12 +194,14 @@ To set up Endpoints resources for the Services, it requires access to Create, Li --> ### 服务控制器 {#authorization-service-controller} -服务控制器监测 Service 对象的 Create、Update 和 Delete 事件，并配置 -对应服务的 Endpoints 对象。 -为了访问 Service 对象，它需要 List、Watch 访问权限；为了更新 Service 对象 -它需要 Patch 和 Update 访问权限。 -为了能够配置 Service 对应的 Endpoints 资源，它需要 Create、List、Get、Watch -和 Update 等访问权限。 +服务控制器监测 Service 对象的 Create、Update 和 Delete 事件， +并配置对应服务的 Endpoints 对象。 + +为了访问 Service 对象，它需要 List 和 Watch 访问权限。 +为了更新 Service 对象，它需要 Patch 和 Update 访问权限。 + +为了能够配置 Service 对应的 Endpoints 资源， +它需要 Create、List、Get、Watch 和 Update 等访问权限。 `v1/Service`: @@ -230,8 +231,8 @@ controller manager looks like: --> ### 其他 {#authorization-miscellaneous} -云控制器管理器的实现中，其核心部分需要创建 Event 对象的访问权限以及 -创建 ServiceAccount 资源以保证操作安全性的权限。 +在云控制器管理器的实现中，其核心部分需要创建 Event 对象的访问权限， +并创建 ServiceAccount 资源以保证操作安全性的权限。 `v1/Event`: @@ -318,10 +319,10 @@ To upgrade a HA control plane to use the cloud controller manager, see [Migrate Want to know how to implement your own cloud controller manager, or extend an existing project? --> -[云控制器管理器的管理](/zh/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager) +[云控制器管理器的管理](/zh-cn/docs/tasks/administer-cluster/running-cloud-controller/#cloud-controller-manager) 给出了运行和管理云控制器管理器的指南。 -要升级 HA 控制平面以使用云控制器管理器，请参见 [将复制的控制平面迁移以使用云控制器管理器](/zh/docs/tasks/administer-cluster/controller-manager-leader-migration/) +要升级 HA 控制平面以使用云控制器管理器，请参见[将复制的控制平面迁移以使用云控制器管理器](/zh-cn/docs/tasks/administer-cluster/controller-manager-leader-migration/)。 想要了解如何实现自己的云控制器管理器，或者对现有项目进行扩展么？ @@ -338,11 +339,11 @@ The implementation of the shared controllers highlighted in this document (Node, For more information about developing plugins, see [Developing Cloud Controller Manager](/docs/tasks/administer-cluster/developing-cloud-controller-manager/). --> -本文中列举的共享控制器（节点控制器、路由控制器和服务控制器等）的实现以及 -其他一些生成具有 CloudProvider 接口的框架的代码，都是 Kubernetes 的核心代码。 +本文中列举的共享控制器（节点控制器、路由控制器和服务控制器等）的实现以及其他一些生成具有 +CloudProvider 接口的框架的代码，都是 Kubernetes 的核心代码。 特定于云驱动的实现虽不是 Kubernetes 核心成分，仍要实现 `CloudProvider` 接口。 关于如何开发插件的详细信息，可参考 -[开发云控制器管理器](/zh/docs/tasks/administer-cluster/developing-cloud-controller-manager/) +[开发云控制器管理器](/zh-cn/docs/tasks/administer-cluster/developing-cloud-controller-manager/) 文档。 diff --git a/content/zh-cn/docs/concepts/architecture/control-plane-node-communication.md b/content/zh-cn/docs/concepts/architecture/control-plane-node-communication.md index 8a92d69f2e..e8d99338ff 100644 --- a/content/zh-cn/docs/concepts/architecture/control-plane-node-communication.md +++ b/content/zh-cn/docs/concepts/architecture/control-plane-node-communication.md @@ -1,11 +1,11 @@ --- -title: 控制面到节点通信 +title: 节点与控制面之间的通信 content_type: concept weight: 20 --- 本文列举控制面节点（确切说是 API 服务器）和 Kubernetes 集群之间的通信路径。 -目的是为了让用户能够自定义他们的安装，以实现对网络配置的加固，使得集群能够在不可信的网络上 -（或者在一个云服务商完全公开的 IP 上）运行。 +目的是为了让用户能够自定义他们的安装，以实现对网络配置的加固， +使得集群能够在不可信的网络上（或者在一个云服务商完全公开的 IP 上）运行。 + -## 节点到控制面 +## 节点到控制面 {#node-to-control-plane} Kubernetes 采用的是中心辐射型（Hub-and-Spoke）API 模式。 -所有从集群（或所运行的 Pods）发出的 API 调用都终止于 API 服务器。 +所有从节点（或运行于其上的 Pod）发出的 API 调用都终止于 API 服务器。 其它控制面组件都没有被设计为可暴露远程服务。 API 服务器被配置为在一个安全的 HTTPS 端口（通常为 443）上监听远程连接请求， -并启用一种或多种形式的客户端[身份认证](/zh/docs/reference/access-authn-authz/authentication/)机制。 -一种或多种客户端[鉴权机制](/zh/docs/reference/access-authn-authz/authorization/)应该被启用， -特别是在允许使用[匿名请求](/zh/docs/reference/access-authn-authz/authentication/#anonymous-requests) -或[服务账号令牌](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。 +并启用一种或多种形式的客户端[身份认证](/zh-cn/docs/reference/access-authn-authz/authentication/)机制。 +一种或多种客户端[鉴权机制](/zh-cn/docs/reference/access-authn-authz/authorization/)应该被启用， +特别是在允许使用[匿名请求](/zh-cn/docs/reference/access-authn-authz/authentication/#anonymous-requests) +或[服务账户令牌](/zh-cn/docs/reference/access-authn-authz/authentication/#service-account-tokens)的时候。 应该使用集群的公共根证书开通节点，这样它们就能够基于有效的客户端凭据安全地连接 API 服务器。 一种好的方法是以客户端证书的形式将客户端凭据提供给 kubelet。 -请查看 [kubelet TLS 启动引导](/zh/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) +请查看 [kubelet TLS 启动引导](/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) 以了解如何自动提供 kubelet 客户端证书。 想要连接到 API 服务器的 Pod 可以使用服务账号安全地进行连接。 当 Pod 被实例化时，Kubernetes 自动把公共根证书和一个有效的持有者令牌注入到 Pod 里。 -`kubernetes` 服务（位于 `default` 名字空间中）配置了一个虚拟 IP 地址，用于（通过 kube-proxy）转发 -请求到 API 服务器的 HTTPS 末端。 +`kubernetes` 服务（位于 `default` 名字空间中）配置了一个虚拟 IP 地址， +用于（通过 kube-proxy）转发请求到 API 服务器的 HTTPS 末端。 控制面组件也通过安全端口与集群的 API 服务器通信。 这样，从集群节点和节点上运行的 Pod 到控制面的连接的缺省操作模式即是安全的， 能够在不可信的网络或公网上运行。 @@ -68,26 +89,31 @@ As a result, the default operating mode for connections from the nodes and pods -## 控制面到节点 +## 控制面到节点 {#control-plane-to-node} 从控制面（API 服务器）到节点有两种主要的通信路径。 第一种是从 API 服务器到集群中每个节点上运行的 kubelet 进程。 第二种是从 API 服务器通过它的代理功能连接到任何节点、Pod 或者服务。 -### API 服务器到 kubelet +### API 服务器到 kubelet {#api-server-to-kubelet} 从 API 服务器到 kubelet 的连接用于： @@ -100,29 +126,37 @@ These connections terminate at the kubelet's HTTPS endpoint. By default, the api 在非受信网络或公开网络上运行也是 **不安全的**。 -为了对这个连接进行认证，使用 `--kubelet-certificate-authority` 标志给 API -服务器提供一个根证书包，用于 kubelet 的服务证书。 +为了对这个连接进行认证，使用 `--kubelet-certificate-authority` 标志给 +API 服务器提供一个根证书包，用于 kubelet 的服务证书。 如果无法实现这点，又要求避免在非受信网络或公共网络上进行连接，可在 API 服务器和 kubelet 之间使用 [SSH 隧道](#ssh-tunnels)。 最后，应该启用 -[kubelet 用户认证和/或鉴权](/zh/docs/reference/access-authn-authz/kubelet-authn-authz/) +[kubelet 用户认证和/或鉴权](/zh-cn/docs/reference/access-authn-authz/kubelet-authn-authz/) 来保护 kubelet API。 -### API 服务器到节点、Pod 和服务 +### API 服务器到节点、Pod 和服务 {#api-server-to-nodes-pods-and-services} 从 API 服务器到节点、Pod 或服务的连接默认为纯 HTTP 方式，因此既没有认证，也没有加密。 这些连接可通过给 API URL 中的节点、Pod 或服务名称添加前缀 `https:` 来运行在安全的 HTTPS 连接上。 @@ -133,40 +167,53 @@ The connections from the apiserver to a node, pod, or service default to plain H ### SSH 隧道 {#ssh-tunnels} -Kubernetes 支持使用 SSH 隧道来保护从控制面到节点的通信路径。在这种配置下，API -服务器建立一个到集群中各节点的 SSH 隧道（连接到在 22 端口监听的 SSH 服务） +Kubernetes 支持使用 SSH 隧道来保护从控制面到节点的通信路径。在这种配置下， +API 服务器建立一个到集群中各节点的 SSH 隧道（连接到在 22 端口监听的 SSH 服务器） 并通过这个隧道传输所有到 kubelet、节点、Pod 或服务的请求。 这一隧道保证通信不会被暴露到集群节点所运行的网络之外。 +{{< note >}} + SSH 隧道目前已被废弃。除非你了解个中细节，否则不应使用。 Konnectivity 服务是对此通信通道的替代品。 +{{< /note >}} -### Konnectivity 服务 +### Konnectivity 服务 {#konnectivity-service} {{< feature-state for_k8s_version="v1.18" state="beta" >}} + 作为 SSH 隧道的替代方案，Konnectivity 服务提供 TCP 层的代理，以便支持从控制面到集群的通信。 -Konnectivity 服务包含两个部分：Konnectivity 服务器和 Konnectivity 代理，分别运行在 -控制面网络和节点网络中。Konnectivity 代理建立并维持到 Konnectivity 服务器的网络连接。 +Konnectivity 服务包含两个部分：Konnectivity 服务器和 Konnectivity 代理， +分别运行在控制面网络和节点网络中。 +Konnectivity 代理建立并维持到 Konnectivity 服务器的网络连接。 启用 Konnectivity 服务之后，所有控制面到节点的通信都通过这些连接传输。 -请浏览 [Konnectivity 服务任务](/zh/docs/tasks/extend-kubernetes/setup-konnectivity/) +请浏览 [Konnectivity 服务任务](/zh-cn/docs/tasks/extend-kubernetes/setup-konnectivity/) 在你的集群中配置 Konnectivity 服务。 diff --git a/content/zh-cn/docs/concepts/architecture/controller.md b/content/zh-cn/docs/concepts/architecture/controller.md index 7c11a5a0d2..fecf82269a 100644 --- a/content/zh-cn/docs/concepts/architecture/controller.md +++ b/content/zh-cn/docs/concepts/architecture/controller.md @@ -50,7 +50,7 @@ detail. ## 控制器模式 {#controller-pattern} 一个控制器至少追踪一种类型的 Kubernetes 资源。这些 -[对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/) +[对象](/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects/) 有一个代表期望状态的 `spec` 字段。 该资源的控制器负责确保其当前状态接近期望状态。 @@ -96,7 +96,7 @@ and eventually the work is done. Job 是一种 Kubernetes 资源，它运行一个或者多个 {{< glossary_tooltip term_id="pod" >}}， 来执行一个任务然后停止。 -（一旦[被调度了](/zh/docs/concepts/scheduling-eviction/)，对 `kubelet` 来说 Pod +（一旦[被调度了](/zh-cn/docs/concepts/scheduling-eviction/)，对 `kubelet` 来说 Pod 对象就会变成了期望状态的一部分）。 在集群中，当 Job 控制器拿到新任务时，它会保证一组 Node 节点上的 `kubelet` @@ -175,7 +175,7 @@ cloud provider APIs, and other services by --> 在温度计的例子中，如果房间很冷，那么某个控制器可能还会启动一个防冻加热器。 就 Kubernetes 集群而言，控制面间接地与 IP 地址管理工具、存储服务、云驱动 -APIs 以及其他服务协作，通过[扩展 Kubernetes](/zh/docs/concepts/extend-kubernetes/) +APIs 以及其他服务协作，通过[扩展 Kubernetes](/zh-cn/docs/concepts/extend-kubernetes/) 来实现这点。 -* 阅读 [Kubernetes 控制平面组件](/zh/docs/concepts/overview/components/#control-plane-components) -* 了解 [Kubernetes 对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/) +* 阅读 [Kubernetes 控制平面组件](/zh-cn/docs/concepts/overview/components/#control-plane-components) +* 了解 [Kubernetes 对象](/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects/) 的一些基本知识 -* 进一步学习 [Kubernetes API](/zh/docs/concepts/overview/kubernetes-api/) +* 进一步学习 [Kubernetes API](/zh-cn/docs/concepts/overview/kubernetes-api/) * 如果你想编写自己的控制器，请看 Kubernetes 的 - [扩展模式](/zh/docs/concepts/extend-kubernetes/#extension-patterns)。 + [扩展模式](/zh-cn/docs/concepts/extend-kubernetes/#extension-patterns)。 diff --git a/content/zh-cn/docs/concepts/architecture/cri.md b/content/zh-cn/docs/concepts/architecture/cri.md index 68cd082fc0..c0b3579578 100644 --- a/content/zh-cn/docs/concepts/architecture/cri.md +++ b/content/zh-cn/docs/concepts/architecture/cri.md @@ -46,7 +46,7 @@ flags](/docs/reference/command-line-tools-reference/kubelet) --> 当通过 gRPC 连接到容器运行时时，kubelet 充当客户端。 运行时和镜像服务端点必须在容器运行时中可用，可以使用 -[命令行标志](/zh/docs/reference/command-line-tools-reference/kubelet)的 +[命令行标志](/zh-cn/docs/reference/command-line-tools-reference/kubelet)的 `--image-service-endpoint` 和 `--container-runtime-endpoint` 在 kubelet 中单独配置。 diff --git a/content/zh-cn/docs/concepts/architecture/garbage-collection.md b/content/zh-cn/docs/concepts/architecture/garbage-collection.md index c095601354..d45b98fa8f 100644 --- a/content/zh-cn/docs/concepts/architecture/garbage-collection.md +++ b/content/zh-cn/docs/concepts/architecture/garbage-collection.md @@ -32,16 +32,16 @@ allows the clean up of resources like the following: manager * [Node Lease objects](/docs/concepts/architecture/nodes/#heartbeats) --> -* [失败的 Pod](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection) -* [已完成的 Job](/zh/docs/concepts/workloads/controllers/ttlafterfinished/) +* [失败的 Pod](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection) +* [已完成的 Job](/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished/) * [不再存在属主引用的对象](#owners-dependents) * [未使用的容器和容器镜像](#containers-images) -* [动态制备的、StorageClass 回收策略为 Delete 的 PV 卷](/zh/docs/concepts/storage/persistent-volumes/#delete) -* [阻滞或者过期的 CertificateSigningRequest (CSRs)](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process) +* [动态制备的、StorageClass 回收策略为 Delete 的 PV 卷](/zh-cn/docs/concepts/storage/persistent-volumes/#delete) +* [阻滞或者过期的 CertificateSigningRequest (CSRs)](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/#request-signing-process) * 在以下情形中删除了的{{}}对象： - * 当集群使用[云控制器管理器](/zh/docs/concepts/architecture/cloud-controller/)运行于云端时； + * 当集群使用[云控制器管理器](/zh-cn/docs/concepts/architecture/cloud-controller/)运行于云端时； * 当集群使用类似于云控制器管理器的插件运行在本地环境中时。 -* [节点租约对象](/zh/docs/concepts/architecture/nodes/#heartbeats) +* [节点租约对象](/zh-cn/docs/concepts/architecture/nodes/#heartbeats) ## 属主与依赖 {#owners-dependents} -Kubernetes 中很多对象通过[*属主引用*](/zh/docs/concepts/overview/working-with-objects/owners-dependents/) +Kubernetes 中很多对象通过[*属主引用*](/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents/) 链接到彼此。属主引用（Owner Reference）可以告诉控制面哪些对象依赖于其他对象。 Kubernetes 使用属主引用来为控制面以及其他 API 客户端在删除某对象时提供一个清理关联资源的机会。 在大多数场合，Kubernetes 都是自动管理属主引用的。 @@ -69,7 +69,7 @@ to the labels, each `EndpointSlice` that is managed on behalf of a Service has an owner reference. Owner references help different parts of Kubernetes avoid interfering with objects they don’t control. --> -属主关系与某些资源所使用的[标签和选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)不同。 +属主关系与某些资源所使用的[标签和选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/)不同。 例如，考虑一个创建 `EndpointSlice` 对象的 {{}} 对象。Service 对象使用*标签*来允许控制面确定哪些 `EndpointSlice` 对象被该 Service 使用。除了标签，每个被 Service 托管的 `EndpointSlice` 对象还有一个属主引用属性。 @@ -181,7 +181,7 @@ to learn more. 在前台级联删除过程中，唯一可能阻止属主对象被删除的是那些带有 `ownerReference.blockOwnerDeletion=true` 字段的依赖对象。 -参阅[使用前台级联删除](/zh/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion) +参阅[使用前台级联删除](/zh-cn/docs/tasks/administer-cluster/use-cascading-deletion/#use-foreground-cascading-deletion) 以了解进一步的细节。 要配置对未使用容器和镜像的垃圾收集选项，可以使用一个 -[配置文件](/zh/docs/tasks/administer-cluster/kubelet-config-file/)，基于 -[`KubeletConfiguration`](/zh/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) +[配置文件](/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/)，基于 +[`KubeletConfiguration`](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) 资源类型来调整与垃圾搜集相关的 kubelet 行为。 @@ -353,8 +353,8 @@ configure garbage collection: * Learn more about Kubernetes [finalizers](/docs/concepts/overview/working-with-objects/finalizers/). * Learn about the [TTL controller](/docs/concepts/workloads/controllers/ttlafterfinished/) (beta) that cleans up finished Jobs. --> -* 进一步了解 [Kubernetes 对象的属主关系](/zh/docs/concepts/overview/working-with-objects/owners-dependents/)。 -* 进一步了解 Kubernetes [finalizers](/zh/docs/concepts/overview/working-with-objects/finalizers/)。 -* 进一步了解 [TTL 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/) (beta)， +* 进一步了解 [Kubernetes 对象的属主关系](/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents/)。 +* 进一步了解 Kubernetes [finalizers](/zh-cn/docs/concepts/overview/working-with-objects/finalizers/)。 +* 进一步了解 [TTL 控制器](/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished/) (beta)， 该控制器负责清理已完成的 Job。 diff --git a/content/zh-cn/docs/concepts/architecture/nodes.md b/content/zh-cn/docs/concepts/architecture/nodes.md index 0ab1e695ca..a57f98dc14 100644 --- a/content/zh-cn/docs/concepts/architecture/nodes.md +++ b/content/zh-cn/docs/concepts/architecture/nodes.md @@ -38,7 +38,7 @@ Kubernetes 通过将容器放入在节点（Node）上运行的 Pod 中来执行 通常集群中会有若干个节点；而在一个学习用或者资源受限的环境中，你的集群中也可能 只有一个节点。 -节点上的[组件](/zh/docs/concepts/overview/components/#node-components)包括 +节点上的[组件](/zh-cn/docs/concepts/overview/components/#node-components)包括 {{< glossary_tooltip text="kubelet" term_id="kubelet" >}}、 {{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}以及 {{< glossary_tooltip text="kube-proxy" term_id="kube-proxy" >}}。 @@ -110,7 +110,7 @@ The name of a Node object must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). --> Node 对象的名称必须是合法的 -[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)。 ### 节点名称唯一性 {#node-name-uniqueness} -节点的[名称](/zh/docs/concepts/overview/working-with-objects/names#names)用来标识 Node 对象。 +节点的[名称](/zh-cn/docs/concepts/overview/working-with-objects/names#names)用来标识 Node 对象。 没有两个 Node 可以同时使用相同的名称。 Kubernetes 还假定名字相同的资源是同一个对象。 就 Node 而言，隐式假定使用相同名称的实例会具有相同的状态（例如网络配置、根磁盘内容） 和类似节点标签这类属性。这可能在节点被更改但其名称未变时导致系统状态不一致。 @@ -167,7 +167,7 @@ For self-registration, the kubelet is started with the following options: （逗号分隔的 `=:`）注册节点。当 `register-node` 为 false 时无效。 - `--node-ip` - 节点 IP 地址。 - `--node-labels` - 在集群中注册节点时要添加的{{< glossary_tooltip text="标签" term_id="label" >}}。 - （参见 [NodeRestriction 准入控制插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)所实施的标签限制）。 + （参见 [NodeRestriction 准入控制插件](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#noderestriction)所实施的标签限制）。 - `--node-status-update-frequency` - 指定 kubelet 向控制面发送状态的频率。 -启用[Node 鉴权模式](/zh/docs/reference/access-authn-authz/node/)和 -[NodeRestriction 准入插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)时， +启用[Node 鉴权模式](/zh-cn/docs/reference/access-authn-authz/node/)和 +[NodeRestriction 准入插件](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#noderestriction)时， 仅授权 `kubelet` 创建或修改其自己的节点资源。 {{< note >}} @@ -256,7 +256,7 @@ kubectl cordon $NODENAME See [Safely Drain a Node](/docs/tasks/administer-cluster/safely-drain-node/) for more details. --> -更多细节参考[安全地腾空节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)。 +更多细节参考[安全地腾空节点](/zh-cn/docs/tasks/administer-cluster/safely-drain-node/)。 {{< note >}} 当节点上出现问题时，Kubernetes 控制面会自动创建与影响节点的状况对应的 -[污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。 +[污点](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/)。 调度器在将 Pod 指派到某 Node 时会考虑 Node 上的污点设置。 Pod 也可以设置{{< glossary_tooltip text="容忍度" term_id="toleration" >}}， 以便能够在设置了特定污点的 Node 上运行。 @@ -439,7 +439,7 @@ Pod 也可以设置{{< glossary_tooltip text="容忍度" term_id="toleration" >} See [Taint Nodes by Condition](/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition) for more details. --> -进一步的细节可参阅[根据状况为节点设置污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition)。 +进一步的细节可参阅[根据状况为节点设置污点](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/#taint-nodes-by-condition)。 -可以在学习如何在节点上[预留计算资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) +可以在学习如何在节点上[预留计算资源](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) 的时候了解有关容量和可分配资源的更多信息。 如果要为非 Pod 进程显式保留资源。 -请参考[为系统守护进程预留资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)。 +请参考[为系统守护进程预留资源](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#system-reserved)。 {{< /note >}} -如果启用了 `TopologyManager` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， +如果启用了 `TopologyManager` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)， `kubelet` 可以在作出资源分配决策时使用拓扑提示。 -参考[控制节点上拓扑管理策略](/zh/docs/tasks/administer-cluster/topology-manager/)了解详细信息。 +参考[控制节点上拓扑管理策略](/zh-cn/docs/tasks/administer-cluster/topology-manager/)了解详细信息。 节点体面关闭的特性对应两个 -[`KubeletConfiguration`](/zh/docs/tasks/administer-cluster/kubelet-config-file/) 选项： +[`KubeletConfiguration`](/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/) 选项： * `shutdownGracePeriod`： * 指定节点应延迟关闭的总持续时间。此时间是 Pod 体面终止的时间总和，不区分常规 Pod - 还是[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。 + 还是[关键 Pod](/zh-cn/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical)。 * `shutdownGracePeriodCriticalPods`： - * 在节点关闭期间指定用于终止[关键 Pod](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) + * 在节点关闭期间指定用于终止[关键 Pod](/zh-cn/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/#marking-pod-as-critical) 的持续时间。该值应小于 `shutdownGracePeriod`。 假设集群中存在以下自定义的 Pod -[优先级类](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass)。 +[优先级类](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/#priorityclass)。 | Pod 优先级类名称 | Pod 优先级类数值 | |-------------------------|------------------------| @@ -982,7 +982,7 @@ in a cluster, Within the [kubelet configuration](/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration) the settings for `shutdownGracePeriodByPodPriority` could look like: --> -在 [kubelet 配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)中， +在 [kubelet 配置](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)中， `shutdownGracePeriodByPodPriority` 可能看起来是这样： | Pod 优先级类数值 | 关闭期限 | @@ -1059,8 +1059,8 @@ their respective shutdown periods. 如果此功能特性被启用，但没有提供配置数据，则不会出现排序操作。 使用此功能特性需要启用 `GracefulNodeShutdownBasedOnPodPriority` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， -并将 [kubelet 配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/) +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)， +并将 [kubelet 配置](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/) 中的 `shutdownGracePeriodByPodPriority` 设置为期望的配置， 其中包含 Pod 的优先级类数值以及对应的关闭期限。 @@ -1107,7 +1107,7 @@ must be set to false. --> 要在节点上启用交换内存，必须启用kubelet 的 `NodeSwap` 特性门控， 同时使用 `--fail-swap-on` 命令行参数或者将 `failSwapOn` -[配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)设置为 false。 +[配置](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/#kubelet-config-k8s-io-v1beta1-KubeletConfiguration)设置为 false。 -* 进一步了解节点[组件](/zh/docs/concepts/overview/components/#node-components)。 +* 进一步了解节点[组件](/zh-cn/docs/concepts/overview/components/#node-components)。 * 阅读 [Node 的 API 定义](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core)。 * 阅读架构设计文档中有关 [Node](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md#the-kubernetes-node) 的章节。 -* 了解[污点和容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。 +* 了解[污点和容忍度](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/)。 diff --git a/content/zh-cn/docs/concepts/cluster-administration/_index.md b/content/zh-cn/docs/concepts/cluster-administration/_index.md index d37c50dcad..c340a741c7 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/_index.md +++ b/content/zh-cn/docs/concepts/cluster-administration/_index.md @@ -25,7 +25,7 @@ The cluster administration overview is for anyone creating or administering a Ku It assumes some familiarity with core Kubernetes [concepts](/docs/concepts/). --> 集群管理概述面向任何创建和管理 Kubernetes 集群的读者人群。 -我们假设你大概了解一些核心的 Kubernetes [概念](/zh/docs/concepts/)。 +我们假设你大概了解一些核心的 Kubernetes [概念](/zh-cn/docs/concepts/)。 @@ -40,7 +40,7 @@ Before choosing a guide, here are some considerations: --> ## 规划集群 {#planning-a-cluster} -查阅[安装](/zh/docs/setup/)中的指导，获取如何规划、建立以及配置 Kubernetes +查阅[安装](/zh-cn/docs/setup/)中的指导，获取如何规划、建立以及配置 Kubernetes 集群的示例。本文所列的文章称为*发行版* 。 {{< note >}} @@ -68,12 +68,12 @@ Before choosing a guide, here are some considerations: - 你的集群是在**本地**还是**云（IaaS）** 上？Kubernetes 不能直接支持混合集群。 作为代替，你可以建立多个集群。 - **如果你在本地配置 Kubernetes**，需要考虑哪种 - [网络模型](/zh/docs/concepts/cluster-administration/networking/)最适合。 + [网络模型](/zh-cn/docs/concepts/cluster-administration/networking/)最适合。 - 你的 Kubernetes 在**裸金属硬件**上还是**虚拟机（VMs）** 上运行？ - 你是想**运行一个集群**，还是打算**参与开发 Kubernetes 项目代码**？ 如果是后者，请选择一个处于开发状态的发行版。 某些发行版只提供二进制发布版，但提供更多的选择。 -- 让你自己熟悉运行一个集群所需的[组件](/zh/docs/concepts/overview/components/)。 +- 让你自己熟悉运行一个集群所需的[组件](/zh-cn/docs/concepts/overview/components/)。 ## 管理集群 {#managing-a-cluster} -* 学习如何[管理节点](/zh/docs/concepts/architecture/nodes/)。 +* 学习如何[管理节点](/zh-cn/docs/concepts/architecture/nodes/)。 -* 学习如何设定和管理集群共享的[资源配额](/zh/docs/concepts/policy/resource-quotas/) 。 +* 学习如何设定和管理集群共享的[资源配额](/zh-cn/docs/concepts/policy/resource-quotas/) 。 ## 保护集群 {#securing-a-cluster} -* [生成证书](/zh/docs/tasks/administer-cluster/certificates/) +* [生成证书](/zh-cn/docs/tasks/administer-cluster/certificates/) 节描述了使用不同的工具链生成证书的步骤。 -* [Kubernetes 容器环境](/zh/docs/concepts/containers/container-environment/) +* [Kubernetes 容器环境](/zh-cn/docs/concepts/containers/container-environment/) 描述了 Kubernetes 节点上由 Kubelet 管理的容器的环境。 -* [控制到 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access/) +* [控制到 Kubernetes API 的访问](/zh-cn/docs/concepts/security/controlling-access/) 描述了如何为用户和 service accounts 建立权限许可。 -* [身份认证](/zh/docs/reference/access-authn-authz/authentication/) +* [身份认证](/zh-cn/docs/reference/access-authn-authz/authentication/) 节阐述了 Kubernetes 中的身份认证功能，包括许多认证选项。 -* [鉴权](/zh/docs/reference/access-authn-authz/authorization/) +* [鉴权](/zh-cn/docs/reference/access-authn-authz/authorization/) 与身份认证不同，用于控制如何处理 HTTP 请求。 -* [使用准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers) +* [使用准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers) 阐述了在认证和授权之后拦截到 Kubernetes API 服务的请求的插件。 -* [在 Kubernetes 集群中使用 Sysctls](/zh/docs/tasks/administer-cluster/sysctl-cluster/) +* [在 Kubernetes 集群中使用 Sysctls](/zh-cn/docs/tasks/administer-cluster/sysctl-cluster/) 描述了管理员如何使用 `sysctl` 命令行工具来设置内核参数。 -* [审计](/zh/docs/tasks/debug/debug-cluster/audit/) +* [审计](/zh-cn/docs/tasks/debug/debug-cluster/audit/) 描述了如何与 Kubernetes 的审计日志交互。 ### 保护 kubelet {#securing-the-kubelet} -* [主控节点通信](/zh/docs/concepts/architecture/control-plane-node-communication/) -* [TLS 引导](/zh/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) -* [Kubelet 认证/授权](/zh/docs/reference/access-authn-authz/kubelet-authn-authz/) +* [主控节点通信](/zh-cn/docs/concepts/architecture/control-plane-node-communication/) +* [TLS 引导](/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) +* [Kubelet 认证/授权](/zh-cn/docs/reference/access-authn-authz/kubelet-authn-authz/) ## 可选集群服务 {#optional-cluster-services} -* [DNS 集成](/zh/docs/concepts/services-networking/dns-pod-service/) +* [DNS 集成](/zh-cn/docs/concepts/services-networking/dns-pod-service/) 描述了如何将一个 DNS 名解析到一个 Kubernetes service。 -* [记录和监控集群活动](/zh/docs/concepts/cluster-administration/logging/) +* [记录和监控集群活动](/zh-cn/docs/concepts/cluster-administration/logging/) 阐述了 Kubernetes 的日志如何工作以及怎样实现。 diff --git a/content/zh-cn/docs/concepts/cluster-administration/certificates.md b/content/zh-cn/docs/concepts/cluster-administration/certificates.md index b900e77ec9..2297ffac05 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/certificates.md +++ b/content/zh-cn/docs/concepts/cluster-administration/certificates.md @@ -14,5 +14,5 @@ weight: 20 -要了解如何为集群生成证书，参阅[证书](/zh/docs/tasks/administer-cluster/certificates/)。 +要了解如何为集群生成证书，参阅[证书](/zh-cn/docs/tasks/administer-cluster/certificates/)。 diff --git a/content/zh-cn/docs/concepts/cluster-administration/flow-control.md b/content/zh-cn/docs/concepts/cluster-administration/flow-control.md index a28154dfe6..7acd2ad4a7 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/flow-control.md +++ b/content/zh-cn/docs/concepts/cluster-administration/flow-control.md @@ -38,8 +38,8 @@ API 优先级和公平性（APF）是一种替代方案，可提升上述最大 APF 以更细粒度的方式对请求进行分类和隔离。 它还引入了空间有限的排队机制，因此在非常短暂的突发情况下，API 服务器不会拒绝任何请求。 通过使用公平排队技术从队列中分发请求，这样， -一个行为不佳的 {{< glossary_tooltip text="控制器" term_id="controller" >}} -就不会饿死其他控制器（即使优先级相同）。 +一个行为不佳的{{< glossary_tooltip text="控制器" term_id="controller" >}}就不会饿死其他控制器 +（即使优先级相同）。 -{{< caution >}} -属于“长时间运行”类型的请求（主要是 watch）不受 API 优先级和公平性过滤器的约束。 +属于“长时间运行”类型的请求（主要是 `watch`）不受 API 优先级和公平性过滤器的约束。 如果未启用 APF 特性，即便设置 `--max-requests-inflight` 标志，该类请求也不受约束。 {{< /caution >}} - API 优先级与公平性（APF）特性由特性门控控制，默认情况下启用。 有关特性门控的一般性描述以及如何启用和禁用特性门控， -请参见[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 +请参见[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。 APF 的特性门控称为 `APIPriorityAndFairness`。 -此特性也与某个 {{< glossary_tooltip term_id="api-group" text="API 组" >}} -相关： +此特性也与某个 {{< glossary_tooltip term_id="api-group" text="API 组" >}}相关： (a) `v1alpha1` 版本，默认被禁用； (b) `v1beta1` 和 `v1beta2` 版本，默认被启用。 你可以在启动 `kube-apiserver` 时，添加以下命令行标志来禁用此功能门控及 API Beta 组： @@ -105,15 +101,15 @@ kube-apiserver \ Alternatively, you can enable the v1alpha1 version of the API group with `--runtime-config=flowcontrol.apiserver.k8s.io/v1alpha1=true`. --> -或者，你也可以通过 -`--runtime-config=flowcontrol.apiserver.k8s.io/v1alpha1=true` +或者，你也可以通过 `--runtime-config=flowcontrol.apiserver.k8s.io/v1alpha1=true` 启用 API 组的 v1alpha1 版本。 -命令行标志 `--enable-priority-fairness=false` 将彻底禁用 APF 特性，即使其他标志启用它也是无效。 +命令行标志 `--enable-priority-fairness=false` 将彻底禁用 APF 特性， +即使其他标志启用它也是无效。 将请求划分到流中之后，APF 功能将请求分配到队列中。 -分配时使用一种称为 {{< glossary_tooltip term_id="shuffle-sharding" text="混洗分片（Shuffle-Sharding）" >}} +分配时使用一种称为{{< glossary_tooltip term_id="shuffle-sharding" text="混洗分片（Shuffle-Sharding）" >}} 的技术。 该技术可以相对有效地利用队列隔离低强度流与高强度流。 @@ -223,7 +220,8 @@ server. --> ### 豁免请求 {#Exempt-requests} -某些特别重要的请求不受制于此特性施加的任何限制。这些豁免可防止不当的流控配置完全禁用 API 服务器。 +某些特别重要的请求不受制于此特性施加的任何限制。 +这些豁免可防止不当的流控配置完全禁用 API 服务器。 ### PriorityLevelConfiguration {#PriorityLevelConfiguration} -一个 PriorityLevelConfiguration 表示单个隔离类型。每个 PriorityLevelConfigurations +一个 PriorityLevelConfiguration 表示单个隔离类型。每个 PriorityLevelConfiguration 对未完成的请求数有各自的限制，对排队中的请求数也有限制。 -PriorityLevelConfigurations 的并发限制不是指定请求绝对数量，而是在“并发份额”中指定。 -API 服务器的总并发量限制通过这些份额按例分配到现有 PriorityLevelConfigurations 中。 +PriorityLevelConfiguration 的并发限制不是指定请求绝对数量，而是在“并发份额”中指定。 +API 服务器的总并发量限制通过这些份额按例分配到现有 PriorityLevelConfiguration 中。 集群管理员可以更改 `--max-requests-inflight` （或 `--max-mutating-requests-inflight` ）的值， 再重新启动 `kube-apiserver` 来增加或减小服务器的总流量， -然后所有的 PriorityLevelConfigurations 将看到其最大并发增加（或减少）了相同的比例。 +然后所有的 PriorityLevelConfiguration 将看到其最大并发增加（或减少）了相同的比例。 +{{< caution >}} -{{< caution >}} -启用 APF 功能后，服务器的总并发量限制将设置为 +启用 APF 特性后，服务器的总并发量限制将设置为 `--max-requests-inflight` 和 `--max-mutating-requests-inflight` 之和。 可变请求和不可变请求之间不再有任何区别； 如果对于某种资源，你需要区别对待不同请求，请创建不同的 FlowSchema 分别匹配可变请求和不可变请求。 @@ -299,16 +297,19 @@ an HTTP 429 (Too Many Requests) error. A type of `Queue` means that requests above the threshold will be queued, with the shuffle sharding and fair queuing techniques used to balance progress between request flows. --> -当入站请求的数量大于分配的 PriorityLevelConfigurations 中允许的并发级别时， `type` 字段将确定对额外请求的处理方式。 +当入站请求的数量大于分配的 PriorityLevelConfiguration 中允许的并发级别时， +`type` 字段将确定对额外请求的处理方式。 `Reject` 类型，表示多余的流量将立即被 HTTP 429（请求过多）错误所拒绝。 `Queue` 类型，表示对超过阈值的请求进行排队，将使用阈值分片和公平排队技术来平衡请求流之间的进度。 -公平排队算法支持通过排队配置对优先级微调。 可以在[增强建议](#whats-next)中阅读算法的详细信息，但总之： +公平排队算法支持通过排队配置对优先级微调。 +可以在[增强建议](https://github.com/kubernetes/enhancements/tree/master/keps/sig-api-machinery/1040-priority-and-fairness)中阅读算法的详细信息， +但总之： +* 修改 `handSize` 允许你调整过载情况下不同流之间的冲突概率以及单个流可用的整体并发性。 {{< note >}} + -* 修改 `handSize` 允许你调整过载情况下不同流之间的冲突概率以及单个流可用的整体并发性。 - - {{< note >}} + --> 较大的 `handSize` 使两个单独的流程发生碰撞的可能性较小（因此，一个流可以饿死另一个流）， 但是更有可能的是少数流可以控制 apiserver。 较大的 `handSize` 还可能增加单个高并发流的延迟量。 @@ -356,11 +356,11 @@ given mouse (low-intensity flow) is squished by the elephants (high-intensity fl an illustrative collection of numbers of elephants. See https://play.golang.org/p/Gi0PLgVHiUg , which computes this table. --> -下表显示了有趣的随机分片配置集合， -每行显示给定的老鼠（低强度流）被不同数量的大象挤压（高强度流）的概率。 +下表显示了有趣的随机分片配置集合，每行显示给定的老鼠（低强度流） +被不同数量的大象挤压（高强度流）的概率。 表来源请参阅： https://play.golang.org/p/Gi0PLgVHiUg -{{< table caption = "Example Shuffle Sharding Configurations" >}} +{{< table caption = "混分切片配置示例" >}} 随机分片 | 队列数 | 1 个大象 | 4 个大象 | 16 个大象 |----------|-----------|------------|----------------|--------------------| @@ -377,21 +377,23 @@ https://play.golang.org/p/Gi0PLgVHiUg , which computes this table. | 6 | 1024 | 6.337324016514285e-16 | 8.09060164312957e-11 | 4.517408062903668e-07 | {{< /table >}} - -### FlowSchema {#FlowSchema} - +### FlowSchema + FlowSchema 匹配一些入站请求，并将它们分配给优先级。 每个入站请求都会对所有 FlowSchema 测试是否匹配， 首先从 `matchingPrecedence` 数值最低的匹配开始（我们认为这是逻辑上匹配度最高）， 然后依次进行，直到首个匹配出现。 +{{< caution >}} -{{< caution >}} 对一个请求来说，只有首个匹配的 FlowSchema 才有意义。 如果一个入站请求与多个 FlowSchema 匹配，则将基于 `matchingPrecedence` 值最高的请求进行筛选。 如果一个请求匹配多个 FlowSchema 且 `matchingPrecedence` 的值相同，则按 `name` 的字典序选择最小， @@ -480,6 +481,7 @@ this behavior. The four mandatory objects are as follows. * 强制的 `exempt` 优先级用于完全不受流控限制的请求：它们总是立刻被分发。 强制的 `exempt` FlowSchema 把 `system:masters` 组的所有请求都归入该优先级。 如果合适，你可以定义新的 FlowSchema，将其他请求定向到该优先级。 + -## 健康检查并发豁免 {#Health-check-concurrency-exemption} - +## 健康检查并发豁免 {#Health-check-concurrency-exemption} + 推荐配置没有为本地 kubelet 对 kube-apiserver 执行健康检查的请求进行任何特殊处理 ——它们倾向于使用安全端口，但不提供凭据。 在推荐配置中，这些请求将分配 `global-default` FlowSchema 和 `global-default` 优先级， @@ -694,6 +695,7 @@ requests from rate limiting. --> 如果添加以下 FlowSchema，健康检查请求不受速率限制。 +{{< caution >}} -{{< caution >}} 进行此更改后，任何敌对方都可以发送与此 FlowSchema 匹配的任意数量的健康检查请求。 如果你有 Web 流量过滤器或类似的外部安全机制保护集群的 API 服务器免受常规网络流量的侵扰， 则可以配置规则，阻止所有来自集群外部的健康检查请求。 @@ -720,7 +721,6 @@ and the priority level to which it was assigned, respectively. The API objects' names are not included in these headers in case the requesting user does not have permission to view them, so when debugging you can use a command like --> - ## 问题诊断 {#diagnostics} 启用了 APF 的 API 服务器，它每个 HTTP 响应都有两个额外的 HTTP 头： @@ -738,7 +738,7 @@ kubectl get prioritylevelconfigurations -o custom-columns="uid:{metadata.uid},na to get a mapping of UIDs to names for both FlowSchemas and PriorityLevelConfigurations. --> -来获取 UID 到 FlowSchema 的名称和 UID 到 PriorityLevelConfigurations 的名称的映射。 +来获取 UID 到 FlowSchema 的名称和 UID 到 PriorityLevelConfiguration 的名称的映射。 -{{< note >}} 在 Kubernetes v1.20 之前的版本中，标签 `flow_schema` 和 `priority_level` 的名称有时被写作 `flowSchema` 和 `priorityLevel`，即存在不一致的情况。 如果你在运行 Kubernetes v1.19 或者更早版本，你需要参考你所使用的集群 @@ -931,6 +931,8 @@ poorly-behaved workloads that may be harming system health. 记录请求队列的长度，由标签 `priority_level` 和 `flow_schema` 进一步区分。 每个排队中的请求都会为其直方图贡献一个样本，并在添加请求后立即上报队列的长度。 请注意，这样产生的统计数据与无偏调查不同。 + + {{< note >}} - {{< note >}} 直方图中的离群值在这里表示单个流（即，一个用户或一个名称空间的请求， 具体取决于配置）正在疯狂地向 API 服务器发请求，并受到限制。 相反，如果一个优先级的直方图显示该优先级的所有队列都比其他优先级的队列长， - 则增加 PriorityLevelConfigurations 的并发份额是比较合适的。 + 则增加 PriorityLevelConfiguration 的并发份额是比较合适的。 {{< /note >}} * `apiserver_flowcontrol_request_concurrency_limit` 是一个表向量， - 记录并发限制的计算值（基于 API 服务器的总并发限制和 PriorityLevelConfigurations + 记录并发限制的计算值（基于 API 服务器的总并发限制和 PriorityLevelConfiguration 的并发份额），并按标签 `priority_level` 进一步区分。 - {{< note >}} - 由于每个 FlowSchema 总会给请求分配 PriorityLevelConfigurations， + 由于每个 FlowSchema 总会给请求分配 PriorityLevelConfiguration， 因此你可以为一个优先级添加所有 FlowSchema 的直方图，以获取分配给 该优先级的请求的有效直方图。 {{< /note >}} @@ -1014,7 +1016,9 @@ serves the following additional paths at its HTTP[S] ports. kubectl get --raw /debug/api_priority_and_fairness/dump_priority_levels ``` - + 输出类似于： ```none @@ -1039,7 +1043,9 @@ serves the following additional paths at its HTTP[S] ports. kubectl get --raw /debug/api_priority_and_fairness/dump_queues ``` - + 输出类似于： ```none @@ -1063,7 +1069,9 @@ serves the following additional paths at its HTTP[S] ports. kubectl get --raw /debug/api_priority_and_fairness/dump_requests ``` - + 输出类似于： ```none @@ -1078,16 +1086,20 @@ serves the following additional paths at its HTTP[S] ports. --> 针对每个优先级别，输出中还包含一条虚拟记录，对应豁免限制。 - + 你可以使用以下命令获得更详细的清单： ```shell kubectl get --raw '/debug/api_priority_and_fairness/dump_requests?includeRequestDetails=1' ``` - - + 输出类似于： + ```none PriorityLevelName, FlowSchemaName, QueueIndex, RequestIndexInQueue, FlowDistingsher, ArriveTime, UserName, Verb, APIPath, Namespace, Name, APIVersion, Resource, SubResource, system, system-nodes, 12, 0, system:node:127.0.0.1, 2020-07-23T15:31:03.583823404Z, system:node:127.0.0.1, create, /api/v1/namespaces/scaletest/configmaps, diff --git a/content/zh-cn/docs/concepts/cluster-administration/logging.md b/content/zh-cn/docs/concepts/cluster-administration/logging.md index ff6e2612ed..8b53c28ae3 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/logging.md +++ b/content/zh-cn/docs/concepts/cluster-administration/logging.md @@ -478,7 +478,7 @@ a [ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap/) to c --> 下面是两个配置文件，可以用来实现一个带日志代理的边车容器。 第一个文件包含用来配置 fluentd 的 -[ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)。 +[ConfigMap](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/)。 {{< codenew file="admin/logging/fluentd-sidecar-config.yaml" >}} diff --git a/content/zh-cn/docs/concepts/cluster-administration/manage-deployment.md b/content/zh-cn/docs/concepts/cluster-administration/manage-deployment.md index 7d77f529e2..38bda5a21f 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/manage-deployment.md +++ b/content/zh-cn/docs/concepts/cluster-administration/manage-deployment.md @@ -12,8 +12,8 @@ You've deployed your application and exposed it via a service. Now what? Kuberne 你已经部署了应用并通过服务暴露它。然后呢？ Kubernetes 提供了一些工具来帮助管理你的应用部署，包括扩缩容和更新。 我们将更深入讨论的特性包括 -[配置文件](/zh/docs/concepts/configuration/overview/)和 -[标签](/zh/docs/concepts/overview/working-with-objects/labels/)。 +[配置文件](/zh-cn/docs/concepts/configuration/overview/)和 +[标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/)。 @@ -85,7 +85,7 @@ A URL can also be specified as a configuration source, which is handy for deploy 还可以使用 URL 作为配置源，便于直接使用已经提交到 Github 上的配置文件进行部署： ```shell -kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/zh/examples/application/nginx/nginx-deployment.yaml +kubectl apply -f https://raw.githubusercontent.com/kubernetes/website/main/content/zh-cn/examples/application/nginx/nginx-deployment.yaml ``` ``` @@ -239,7 +239,7 @@ persistentvolumeclaim/my-pvc created If you're interested in learning more about `kubectl`, go ahead and read [Command line tool (kubectl)](/docs/reference/kubectl/). --> 如果你有兴趣进一步学习关于 `kubectl` 的内容，请阅读 -[命令行工具（kubectl）](/zh/docs/reference/kubectl/)。 +[命令行工具（kubectl）](/zh-cn/docs/reference/kubectl/)。 想要了解更多信息，请参考 -[注解](/zh/docs/concepts/overview/working-with-objects/annotations/)和 +[注解](/zh-cn/docs/concepts/overview/working-with-objects/annotations/)和 [`kubectl annotate`](/docs/reference/generated/kubectl/kubectl-commands/#annotate) 命令文档。 @@ -535,7 +535,7 @@ For more information, please see [kubectl scale](/docs/reference/generated/kubec 想要了解更多信息，请参考 [kubectl scale](/docs/reference/generated/kubectl/kubectl-commands/#scale)命令文档、 [kubectl autoscale](/docs/reference/generated/kubectl/kubectl-commands/#autoscale) 命令文档和 -[水平 Pod 自动伸缩](/zh/docs/tasks/run-application/horizontal-pod-autoscale/) 文档。 +[水平 Pod 自动伸缩](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/) 文档。 你可以使用 `kubectl patch` 来更新 API 对象。此命令支持 JSON patch、 JSON merge patch、以及 strategic merge patch。 请参考 -[使用 kubectl patch 更新 API 对象](/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/) +[使用 kubectl patch 更新 API 对象](/zh-cn/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/) 和 [kubectl patch](/docs/reference/generated/kubectl/kubectl-commands/#patch). @@ -716,7 +716,7 @@ That's it! The Deployment will declaratively update the deployed nginx applicati --> 没错，就是这样！Deployment 将在后台逐步更新已经部署的 nginx 应用。 它确保在更新过程中，只有一定数量的旧副本被开闭，并且只有一定基于所需 Pod 数量的新副本被创建。 -想要了解更多细节，请参考 [Deployment](/zh/docs/concepts/workloads/controllers/deployment/)。 +想要了解更多细节，请参考 [Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/)。 ## {{% heading "whatsnext" %}} @@ -724,5 +724,5 @@ That's it! The Deployment will declaratively update the deployed nginx applicati - [Learn about how to use `kubectl` for application introspection and debugging.](/docs/tasks/debug/debug-application/debug-running-pod/) - [Configuration Best Practices and Tips](/docs/concepts/configuration/overview/) --> -- 学习[如何使用 `kubectl` 观察和调试应用](/zh/docs/tasks/debug/debug-application/debug-running-pod/) -- 阅读[配置最佳实践和技巧](/zh/docs/concepts/configuration/overview/) +- 学习[如何使用 `kubectl` 观察和调试应用](/zh-cn/docs/tasks/debug/debug-application/debug-running-pod/) +- 阅读[配置最佳实践和技巧](/zh-cn/docs/concepts/configuration/overview/) diff --git a/content/zh-cn/docs/concepts/cluster-administration/networking.md b/content/zh-cn/docs/concepts/cluster-administration/networking.md index 4bfae1a551..edc6866ec8 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/networking.md +++ b/content/zh-cn/docs/concepts/cluster-administration/networking.md @@ -29,8 +29,8 @@ problems to address: 1. 高度耦合的容器间通信：这个已经被 {{< glossary_tooltip text="Pods" term_id="pod" >}} 和 `localhost` 通信解决了。 2. Pod 间通信：本文档讲述重点。 -3. Pod 和服务间通信：由[服务](/zh/docs/concepts/services-networking/service/)负责。 -4. 外部和服务间通信：也由[服务](/zh/docs/concepts/services-networking/service/)负责。 +3. Pod 和服务间通信：由[服务](/zh-cn/docs/concepts/services-networking/service/)负责。 +4. 外部和服务间通信：也由[服务](/zh-cn/docs/concepts/services-networking/service/)负责。 @@ -56,7 +56,7 @@ Kubernetes 的宗旨就是在应用之间共享机器。 而 API 服务器还需要知道如何将动态端口数值插入到配置模块中，服务也需要知道如何找到对方等等。 与其去解决这些问题，Kubernetes 选择了其他不同的方法。 -要了解 Kubernetes 网络模型，请参阅[此处](/zh/docs/concepts/services-networking/)。 +要了解 Kubernetes 网络模型，请参阅[此处](/zh-cn/docs/concepts/services-networking/)。 -1. [kubectl proxy](/zh/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api)： +1. [kubectl proxy](/zh-cn/docs/tasks/access-application-cluster/access-cluster/#directly-accessing-the-rest-api)： - 运行在用户的桌面或 pod 中 - 从本机地址到 Kubernetes apiserver 的代理 @@ -56,7 +56,7 @@ There are several different proxies you may encounter when using Kubernetes: - can be used to reach a Node, Pod, or Service - does load balancing when used to reach a Service --> -2. [apiserver proxy](/zh/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services)： +2. [apiserver proxy](/zh-cn/docs/tasks/access-application-cluster/access-cluster/#discovering-builtin-services)： - 是一个建立在 apiserver 内部的“堡垒” - 将集群外部的用户与集群 IP 相连接，这些IP是无法通过其他方式访问的 @@ -75,7 +75,7 @@ There are several different proxies you may encounter when using Kubernetes: - provides load balancing - is only used to reach services --> -3. [kube proxy](/zh/docs/concepts/services-networking/service/#ips-and-vips)： +3. [kube proxy](/zh-cn/docs/concepts/services-networking/service/#ips-and-vips)： - 在每个节点上运行 - 代理 UDP、TCP 和 SCTP diff --git a/content/zh-cn/docs/concepts/cluster-administration/system-logs.md b/content/zh-cn/docs/concepts/cluster-administration/system-logs.md index 164d416b9f..2365e3bd23 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/system-logs.md +++ b/content/zh-cn/docs/concepts/cluster-administration/system-logs.md @@ -38,7 +38,7 @@ klog 是 Kubernetes 的日志库。 [klog](https://github.com/kubernetes/klog) 为 Kubernetes 系统组件生成日志消息。 -有关 klog 配置的更多信息，请参见[命令行工具参考](/zh/docs/reference/command-line-tools-reference/)。 +有关 klog 配置的更多信息，请参见[命令行工具参考](/zh-cn/docs/reference/command-line-tools-reference/)。 JSON 输出并不支持太多标准 klog 参数。对于不受支持的 klog 参数的列表， -请参见[命令行工具参考](/zh/docs/reference/command-line-tools-reference/)。 +请参见[命令行工具参考](/zh-cn/docs/reference/command-line-tools-reference/)。 并不是所有日志都保证写成 JSON 格式（例如，在进程启动期间）。 如果你打算解析日志，请确保可以处理非 JSON 格式的日志行。 @@ -388,7 +388,7 @@ The `logrotate` tool rotates logs daily, or once the log size is greater than 10 * Read about [deprecation of klog flags](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components) * Read about the [Conventions for logging severity](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md) --> -* 阅读 [Kubernetes 日志架构](/zh/docs/concepts/cluster-administration/logging/) +* 阅读 [Kubernetes 日志架构](/zh-cn/docs/concepts/cluster-administration/logging/) * 阅读[结构化日志提案（英文）](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/1602-structured-logging) * 阅读[上下文日志提案（英文）](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/3077-contextual-logging) * 阅读 [klog 参数的废弃（英文）](https://github.com/kubernetes/enhancements/tree/master/keps/sig-instrumentation/2845-deprecate-klog-specific-flags-in-k8s-components) diff --git a/content/zh-cn/docs/concepts/cluster-administration/system-metrics.md b/content/zh-cn/docs/concepts/cluster-administration/system-metrics.md index f054161998..2f971177fe 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/system-metrics.md +++ b/content/zh-cn/docs/concepts/cluster-administration/system-metrics.md @@ -204,7 +204,7 @@ kubelet 在驱动程序上保持打开状态。这意味着为了执行基础结 现在，收集加速器指标的责任属于供应商，而不是 kubelet。供应商必须提供一个收集指标的容器， 并将其公开给指标服务（例如 Prometheus）。 -[`DisableAcceleratorUsageMetrics` 特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +[`DisableAcceleratorUsageMetrics` 特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) 禁止由 kubelet 收集的指标。 关于[何时会在默认情况下启用此功能也有一定规划](https://github.com/kubernetes/enhancements/tree/411e51027db842355bd489691af897afc1a41a5e/keps/sig-node/1867-disable-accelerator-usage-metrics#graduation-criteria)。 @@ -271,7 +271,7 @@ The kube-scheduler identifies the resource [requests and limits](/docs/concepts/ - the unit of the resource if known (for example, `cores`) --> kube-scheduler 组件能够辩识各个 Pod 所配置的资源 -[请求和约束](/zh/docs/concepts/configuration/manage-resources-containers/)。 +[请求和约束](/zh-cn/docs/concepts/configuration/manage-resources-containers/)。 在 Pod 的资源请求值或者约束值非零时，kube-scheduler 会以度量值时间序列的形式 生成报告。该时间序列值包含以下标签： - 名字空间 @@ -341,4 +341,4 @@ Here is an example: * Read about the [Kubernetes deprecation policy](/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior) --> * 阅读有关指标的 [Prometheus 文本格式](https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md#text-based-format) -* 阅读有关 [Kubernetes 弃用策略](/zh/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior) +* 阅读有关 [Kubernetes 弃用策略](/zh-cn/docs/reference/using-api/deprecation-policy/#deprecating-a-feature-or-behavior) diff --git a/content/zh-cn/docs/concepts/cluster-administration/system-traces.md b/content/zh-cn/docs/concepts/cluster-administration/system-traces.md index 71ede2f3e7..2a3860a361 100644 --- a/content/zh-cn/docs/concepts/cluster-administration/system-traces.md +++ b/content/zh-cn/docs/concepts/cluster-administration/system-traces.md @@ -114,7 +114,7 @@ with `--tracing-config-file=`. This is an example config that re spans for 1 in 10000 requests, and uses the default OpenTelemetry endpoint: --> 要启用追踪特性，需要启用 kube-apiserver 上的 `APIServerTracing` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。 然后，使用 `--tracing-config-file=<<配置文件路径>` 为 kube-apiserver 提供追踪配置文件。 下面是一个示例配置，它为万分之一的请求记录 spans，并使用了默认的 OpenTelemetry 端口。 @@ -132,7 +132,7 @@ For more information about the `TracingConfiguration` struct, see --> 有关 TracingConfiguration 结构体的更多信息，请参阅 -[API 服务器配置 API (v1alpha1)](/zh/docs/reference/config-api/apiserver-config.v1alpha1/#apiserver-k8s-io-v1alpha1-TracingConfiguration)。 +[API 服务器配置 API (v1alpha1)](/zh-cn/docs/reference/config-api/apiserver-config.v1alpha1/#apiserver-k8s-io-v1alpha1-TracingConfiguration)。 ## ConfigMap 对象 -ConfigMap 是一个 API [对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/)， +ConfigMap 是一个 API [对象](/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects/)， 让你可以存储其他对象所需要使用的配置。 和其他 Kubernetes 对象都有一个 `spec` 不同的是，ConfigMap 使用 `data` 和 `binaryData` 字段。这些字段能够接收键-值对作为其取值。`data` 和 `binaryData` @@ -81,7 +81,7 @@ ConfigMap 是一个 API [对象](/zh/docs/concepts/overview/working-with-objects 则被设计用来保存二进制数据作为 base64 编码的字串。 ConfigMap 的名字必须是一个合法的 -[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)。 {{< note >}} -使用 ConfigMap 作为 [subPath](/zh/docs/concepts/storage/volumes#using-subpath) 卷挂载的容器将不会收到 ConfigMap 的更新。 +使用 ConfigMap 作为 [subPath](/zh-cn/docs/concepts/storage/volumes#using-subpath) 卷挂载的容器将不会收到 ConfigMap 的更新。 {{< /note >}} 此功能特性由 `ImmutableEphemeralVolumes` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)来控制。 +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)来控制。 你可以通过将 `immutable` 字段设置为 `true` 创建不可变更的 ConfigMap。 例如： @@ -465,7 +465,7 @@ to the deleted ConfigMap, it is recommended to recreate these pods. * Read [The Twelve-Factor App](https://12factor.net/) to understand the motivation for separating code from configuration. --> -* 阅读 [Secret](/zh/docs/concepts/configuration/secret/)。 -* 阅读[配置 Pod 使用 ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)。 -* 阅读[修改 ConfigMap（或任何其他 Kubernetes 对象）](/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)。 +* 阅读 [Secret](/zh-cn/docs/concepts/configuration/secret/)。 +* 阅读[配置 Pod 使用 ConfigMap](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/)。 +* 阅读[修改 ConfigMap（或任何其他 Kubernetes 对象）](/zh-cn/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)。 * 阅读 [Twelve-Factor 应用](https://12factor.net/zh_cn/)来了解将代码和配置分开的动机。 diff --git a/content/zh-cn/docs/concepts/configuration/manage-resources-containers.md b/content/zh-cn/docs/concepts/configuration/manage-resources-containers.md index 001ab761ef..7c1d37f9fa 100644 --- a/content/zh-cn/docs/concepts/configuration/manage-resources-containers.md +++ b/content/zh-cn/docs/concepts/configuration/manage-resources-containers.md @@ -145,8 +145,8 @@ through the Kubernetes API server. --> CPU 和内存统称为“计算资源”，或简称为“资源”。 计算资源的数量是可测量的，可以被请求、被分配、被消耗。 -它们与 [API 资源](/zh/docs/concepts/overview/kubernetes-api/) 不同。 -API 资源（如 Pod 和 [Service](/zh/docs/concepts/services-networking/service/)）是可通过 +它们与 [API 资源](/zh-cn/docs/concepts/overview/kubernetes-api/) 不同。 +API 资源（如 Pod 和 [Service](/zh-cn/docs/concepts/services-networking/service/)）是可通过 Kubernetes API 服务器读取和修改的对象。 kubelet 也使用此类存储来保存 -[节点层面的容器日志](/zh/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)， +[节点层面的容器日志](/zh-cn/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)， 容器镜像文件、以及运行中容器的可写入层。 {{< caution >}} @@ -502,7 +502,7 @@ Kubernetes 有两种方式支持节点上配置本地临时性存储： （kubelet）来保存数据的。 kubelet 也会生成 -[节点层面的容器日志](/zh/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)， +[节点层面的容器日志](/zh-cn/docs/concepts/cluster-administration/logging/#logging-at-the-node-level)， 并按临时性本地存储的方式对待之。 字段 `.status.allocatable` 描述节点上可以用于 Pod 的资源总量（例如：15 个虚拟 CPU、7538 MiB 内存）。关于 Kubernetes 中节点可分配资源的信息，可参阅 -[为系统守护进程预留计算资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/)。 +[为系统守护进程预留计算资源](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/)。 -你可以配置[资源配额](/zh/docs/concepts/policy/resource-quotas/)功能特性以限制每个名字空间可以使用的资源总量。 +你可以配置[资源配额](/zh-cn/docs/concepts/policy/resource-quotas/)功能特性以限制每个名字空间可以使用的资源总量。 当某名字空间中存在 ResourceQuota 时，Kubernetes 会在该名字空间中的对象强制实施配额。 例如，如果你为不同的团队分配名字空间，你可以为这些名字空间添加 ResourceQuota。 设置资源配额有助于防止一个团队占用太多资源，以至于这种占用会影响其他团队。 @@ -1375,10 +1375,10 @@ memory limit (and possibly request) for that container. * Read about [project quotas](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html) in XFS * Read more about the [kube-scheduler configuration reference (v1beta3)](/docs/reference/config-api/kube-scheduler-config.v1beta3/) --> -* 获取[分配内存资源给容器和 Pod ](/zh/docs/tasks/configure-pod-container/assign-memory-resource/) 的实践经验 -* 获取[分配 CPU 资源给容器和 Pod ](/zh/docs/tasks/configure-pod-container/assign-cpu-resource/) 的实践经验 +* 获取[分配内存资源给容器和 Pod ](/zh-cn/docs/tasks/configure-pod-container/assign-memory-resource/) 的实践经验 +* 获取[分配 CPU 资源给容器和 Pod ](/zh-cn/docs/tasks/configure-pod-container/assign-cpu-resource/) 的实践经验 * 阅读 API 参考中 [Container](/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container) 和其[资源请求](/docs/reference/kubernetes-api/workload-resources/pod-v1/#resources)定义。 * 阅读 XFS 中[配额](https://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/xfs-quotas.html)的文档 -* 进一步阅读 [kube-scheduler 配置参考 (v1beta3)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta3/) +* 进一步阅读 [kube-scheduler 配置参考 (v1beta3)](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/) diff --git a/content/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig.md b/content/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig.md index fa77d3c2de..c46b91d3c7 100644 --- a/content/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig.md +++ b/content/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig.md @@ -58,7 +58,7 @@ For step-by-step instructions on creating and specifying kubeconfig files, see [Configure Access to Multiple Clusters](/docs/tasks/access-application-cluster/configure-access-multiple-clusters). --> 有关创建和指定 kubeconfig 文件的分步说明，请参阅 -[配置对多集群的访问](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters)。 +[配置对多集群的访问](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters)。 @@ -193,7 +193,7 @@ Here are the rules that `kubectl` uses when it merges kubeconfig files: [Setting the KUBECONFIG environment variable](/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable). --> 有关设置 `KUBECONFIG` 环境变量的示例，请参阅 - [设置 KUBECONFIG 环境变量](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)。 + [设置 KUBECONFIG 环境变量](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/#set-the-kubeconfig-environment-variable)。 -* [配置对多集群的访问](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +* [配置对多集群的访问](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) * [`kubectl config`](/docs/reference/generated/kubectl/kubectl-commands#config) diff --git a/content/zh-cn/docs/concepts/configuration/overview.md b/content/zh-cn/docs/concepts/configuration/overview.md index 01314daf34..b0d9c2a033 100644 --- a/content/zh-cn/docs/concepts/configuration/overview.md +++ b/content/zh-cn/docs/concepts/configuration/overview.md @@ -77,8 +77,8 @@ This is a living document. If you think of something that is not on this list bu - Don't use naked Pods (that is, Pods not bound to a [ReplicaSet](/docs/concepts/workloads/controllers/replicaset/) or [Deployment](/docs/concepts/workloads/controllers/deployment/)) if you can avoid it. Naked Pods will not be rescheduled in the event of a node failure. --> - 如果可能，不要使用独立的 Pods（即，未绑定到 -[ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/) 或 -[Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 的 Pod）。 +[ReplicaSet](/zh-cn/docs/concepts/workloads/controllers/replicaset/) 或 +[Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/) 的 Pod）。 如果节点发生故障，将不会重新调度独立的 Pods。 Deployment 既可以创建一个 ReplicaSet 来确保预期个数的 Pod 始终可用，也可以指定替换 Pod 的策略（例如 -[RollingUpdate](/zh/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)）。 -除了一些显式的 [`restartPolicy: Never`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) -场景外，Deployment 通常比直接创建 Pod 要好得多。[Job](/zh/docs/concepts/workloads/controllers/job/) 也可能是合适的选择。 +[RollingUpdate](/zh-cn/docs/concepts/workloads/controllers/deployment/#rolling-update-deployment)）。 +除了一些显式的 [`restartPolicy: Never`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) +场景外，Deployment 通常比直接创建 Pod 要好得多。[Job](/zh-cn/docs/concepts/workloads/controllers/job/) 也可能是合适的选择。 - 在创建相应的后端工作负载（Deployment 或 ReplicaSet），以及在需要访问它的任何工作负载之前创建 - [服务](/zh/docs/concepts/services-networking/service/)。 + [服务](/zh-cn/docs/concepts/services-networking/service/)。 当 Kubernetes 启动容器时，它提供指向启动容器时正在运行的所有服务的环境变量。 例如，如果存在名为 `foo` 的服务，则所有容器将在其初始环境中获得以下变量。 @@ -118,7 +118,7 @@ Deployment 既可以创建一个 ReplicaSet 来确保预期个数的 Pod 始终 - An optional (though strongly recommended) [cluster add-on](/docs/concepts/cluster-administration/addons/) is a DNS server. The DNS server watches the Kubernetes API for new `Services` and creates a set of DNS records for each. If DNS has been enabled throughout the cluster then all `Pods` should be able to do name resolution of `Services` automatically. --> -- 一个可选（尽管强烈推荐）的[集群插件](/zh/docs/concepts/cluster-administration/addons/) +- 一个可选（尽管强烈推荐）的[集群插件](/zh-cn/docs/concepts/cluster-administration/addons/) 是 DNS 服务器。DNS 服务器为新的 `Services` 监视 Kubernetes API，并为每个创建一组 DNS 记录。 如果在整个集群中启用了 DNS，则所有 `Pods` 应该能够自动对 `Services` 进行名称解析。 @@ -135,14 +135,14 @@ DNS server watches the Kubernetes API for new `Services` and creates a set of DN If you only need access to the port for debugging purposes, you can use the [apiserver proxy](/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls) or [`kubectl port-forward`](/docs/tasks/access-application-cluster/port-forward-access-application-cluster/). --> 如果你只需要访问端口以进行调试，则可以使用 - [apiserver proxy](/zh/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls)或 - [`kubectl port-forward`](/zh/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)。 + [apiserver proxy](/zh-cn/docs/tasks/access-application-cluster/access-cluster/#manually-constructing-apiserver-proxy-urls)或 + [`kubectl port-forward`](/zh-cn/docs/tasks/access-application-cluster/port-forward-access-application-cluster/)。 如果你明确需要在节点上公开 Pod 的端口，请在使用 `hostPort` 之前考虑使用 - [NodePort](/zh/docs/concepts/services-networking/service/#type-nodeport) 服务。 + [NodePort](/zh-cn/docs/concepts/services-networking/service/#type-nodeport) 服务。 - 当你不需要 `kube-proxy` 负载均衡时，使用 - [无头服务](/zh/docs/concepts/services-networking/service/#headless-services) + [无头服务](/zh-cn/docs/concepts/services-networking/service/#headless-services) (`ClusterIP` 被设置为 `None`)以便于服务发现。 -- 定义并使用[标签](/zh/docs/concepts/overview/working-with-objects/labels/)来识别应用程序 +- 定义并使用[标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/)来识别应用程序 或 Deployment 的 __语义属性__，例如`{ app: myapp, tier: frontend, phase: test, deployment: v3 }`。 你可以使用这些标签为其他资源选择合适的 Pod； 例如，一个选择所有 `tier: frontend` Pod 的服务，或者 `app: myapp` 的所有 `phase: test` 组件。 @@ -175,7 +175,7 @@ services) (which have a `ClusterIP` of `None`) for service discovery when you do A Service can be made to span multiple Deployments by omitting release-specific labels from its selector. [Deployments](/docs/concepts/workloads/controllers/deployment/) make it easy to update a running service without downtime. --> 通过从选择器中省略特定发行版的标签，可以使服务跨越多个 Deployment。 -当你需要不停机的情况下更新正在运行的服务，可以使用[Deployment](/zh/docs/concepts/workloads/controllers/deployment/)。 +当你需要不停机的情况下更新正在运行的服务，可以使用[Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/)。 -- 对于常见场景，应使用 [Kubernetes 通用标签](/zh/docs/concepts/overview/working-with-objects/common-labels/)。 +- 对于常见场景，应使用 [Kubernetes 通用标签](/zh-cn/docs/concepts/overview/working-with-objects/common-labels/)。 这些标准化的标签丰富了对象的元数据，使得包括 `kubectl` 和 - [仪表板（Dashboard）](/zh/docs/tasks/access-application-cluster/web-ui-dashboard) + [仪表板（Dashboard）](/zh-cn/docs/tasks/access-application-cluster/web-ui-dashboard) 这些工具能够以可互操作的方式工作。 - 使用标签选择器进行 `get` 和 `delete` 操作，而不是特定的对象名称。 -- 请参阅[标签选择器](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)和 - [有效使用标签](/zh/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)部分。 +- 请参阅[标签选择器](/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors)和 + [有效使用标签](/zh-cn/docs/concepts/cluster-administration/manage-deployment/#using-labels-effectively)部分。 - 使用`kubectl run`和`kubectl expose`来快速创建单容器部署和服务。 - 有关示例，请参阅[使用服务访问集群中的应用程序](/zh/docs/tasks/access-application-cluster/service-access-application-cluster/)。 + 有关示例，请参阅[使用服务访问集群中的应用程序](/zh-cn/docs/tasks/access-application-cluster/service-access-application-cluster/)。 diff --git a/content/zh-cn/docs/concepts/configuration/secret.md b/content/zh-cn/docs/concepts/configuration/secret.md index 961b149257..b67534c238 100644 --- a/content/zh-cn/docs/concepts/configuration/secret.md +++ b/content/zh-cn/docs/concepts/configuration/secret.md @@ -74,8 +74,8 @@ 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. 为 Secret [启用静态加密](/zh-cn/docs/tasks/administer-cluster/encrypt-data/)； +1. [启用或配置 RBAC 规则](/zh-cn/docs/reference/access-authn-authz/authorization/)来限制读取和写入 Secret 的数据（包括通过间接方式）。需要注意的是，被准许创建 Pod 的人也隐式地被授权获取 Secret 内容。 1. 在适当的情况下，还可以使用 RBAC 等机制来限制允许哪些主体创建新 Secret 或替换现有 Secret。 @@ -139,7 +139,7 @@ Here are some of your options: token). --> - 如果你的云原生组件需要执行身份认证来访问你所知道的、在同一 Kubernetes 集群中运行的另一个应用， - 你可以使用 [ServiceAccount](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens) + 你可以使用 [ServiceAccount](/zh-cn/docs/reference/access-authn-authz/authentication/#service-account-tokens) 及其令牌来标识你的客户端身份。 - 你可以运行的第三方工具也有很多，这些工具可以运行在集群内或集群外，提供机密数据管理。 例如，这一工具可能是 Pod 通过 HTTPS 访问的一个服务，该服务在客户端能够正确地通过身份认证 @@ -153,9 +153,9 @@ Here are some of your options: trusted Pods onto nodes that provide a Trusted Platform Module, configured out-of-band. --> - 就身份认证而言，你可以为 X.509 证书实现一个定制的签名者，并使用 - [CertificateSigningRequest](/zh/docs/reference/access-authn-authz/certificate-signing-requests/) + [CertificateSigningRequest](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/) 来让该签名者为需要证书的 Pod 发放证书。 -- 你可以使用一个[设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) +- 你可以使用一个[设备插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) 来将节点本地的加密硬件暴露给特定的 Pod。例如，你可以将可信任的 Pod 调度到提供可信平台模块（Trusted Platform Module，TPM）的节点上。 这类节点是另行配置的。 @@ -191,9 +191,9 @@ There are several options to create a Secret: ### 创建 Secret {#creating-a-secret} -- [使用 `kubectl` 命令来创建 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl/) -- [基于配置文件来创建 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-config-file/) -- [使用 kustomize 来创建 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kustomize/) +- [使用 `kubectl` 命令来创建 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- [基于配置文件来创建 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- [使用 kustomize 来创建 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kustomize/) -你仍然可以[手动创建](/zh/docs/tasks/configure-pod-container/configure-service-account/#manually-create-a-service-account-api-token) +你仍然可以[手动创建](/zh-cn/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 服务器的令牌。 @@ -648,7 +648,7 @@ A container using a Secret as a [subPath](/docs/concepts/storage/volumes#using-subpath) volume mount does not receive automated Secret updates. --> -对于以 [subPath](/zh/docs/concepts/storage/volumes#using-subpath) 形式挂载 Secret 卷的容器而言， +对于以 [subPath](/zh-cn/docs/concepts/storage/volumes#using-subpath) 形式挂载 Secret 卷的容器而言， 它们无法收到自动的 Secret 更新。 {{< /note >}} @@ -660,7 +660,7 @@ the [kubelet configuration](/docs/reference/config-api/kubelet-config.v1beta1/) --> Kubelet 组件会维护一个缓存，在其中保存节点上 Pod 卷中使用的 Secret 的当前主键和取值。 你可以配置 kubelet 如何检测所缓存数值的变化。 -[kubelet 配置](/zh/docs/reference/config-api/kubelet-config.v1beta1/)中的 +[kubelet 配置](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/)中的 `configMapAndSecretChangeDetectionStrategy` 字段控制 kubelet 所采用的策略。 默认的策略是 `Watch`。 @@ -886,7 +886,7 @@ documentation. --> ##### 手动设定 imagePullSecret {#manually-specifying-an-imagepullsecret} -你可以通过阅读[容器镜像](/zh/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) +你可以通过阅读[容器镜像](/zh-cn/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) 文档了解如何设置 `imagePullSecrets`。 -参考 [ServiceAccount](/zh/docs/tasks/configure-pod-container/configure-service-account/) +参考 [ServiceAccount](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/) 文档了解服务账号的工作原理。你也可以查看 [`Pod`](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#pod-v1-core) 资源中的 `automountServiceAccountToken` 和 `serviceAccountName` 字段文档， @@ -1814,7 +1814,7 @@ The following YAML contains an example config for a TLS Secret: Kubernetes 提供一种内置的 `kubernetes.io/tls` Secret 类型，用来存放 TLS 场合通常要使用的证书及其相关密钥。 -TLS Secret 的一种典型用法是为 [Ingress](/zh/docs/concepts/services-networking/ingress/) +TLS Secret 的一种典型用法是为 [Ingress](/zh-cn/docs/concepts/services-networking/ingress/) 资源配置传输过程中的数据加密，不过也可以用于其他资源或者直接在负载中使用。 当使用此类型的 Secret 时，Secret 配置中的 `data` （或 `stringData`）字段必须包含 `tls.key` 和 `tls.crt` 主键，尽管 API 服务器实际上并不会对每个键的取值作进一步的合法性检查。 @@ -2164,8 +2164,8 @@ on that node. [authorization policies](/docs/reference/access-authn-authz/authorization/) such as [RBAC](/docs/reference/access-authn-authz/rbac/). --> -- 部署与 Secret API 交互的应用时，你应该使用 [RBAC](/zh/docs/reference/access-authn-authz/rbac/) - 这类[鉴权策略](/zh/docs/reference/access-authn-authz/authorization/)来限制访问。 +- 部署与 Secret API 交互的应用时，你应该使用 [RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/) + 这类[鉴权策略](/zh-cn/docs/reference/access-authn-authz/authorization/)来限制访问。 -- 学习如何[使用 `kubectl` 管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kubectl/) -- 学习如何[使用配置文件管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-config-file/) -- 学习如何[使用 kustomize 管理 Secret](/zh/docs/tasks/configmap-secret/managing-secret-using-kustomize/) -- 阅读 [API 参考](/zh/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/)了解 `Secret` +- 学习如何[使用 `kubectl` 管理 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kubectl/) +- 学习如何[使用配置文件管理 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-config-file/) +- 学习如何[使用 kustomize 管理 Secret](/zh-cn/docs/tasks/configmap-secret/managing-secret-using-kustomize/) +- 阅读 [API 参考](/zh-cn/docs/reference/kubernetes-api/config-and-storage-resources/secret-v1/)了解 `Secret` diff --git a/content/zh-cn/docs/concepts/configuration/windows-resource-management.md b/content/zh-cn/docs/concepts/configuration/windows-resource-management.md index a34682f5ae..4a4cefb483 100644 --- a/content/zh-cn/docs/concepts/configuration/windows-resource-management.md +++ b/content/zh-cn/docs/concepts/configuration/windows-resource-management.md @@ -104,7 +104,7 @@ On Windows these values are only used to calculate the node's 为了满足操作系统、容器运行时和 kubelet 等 Kubernetes 主机进程使用的内存和 CPU， 你可以（且应该）用 `--kube-reserved` 和/或 `--system-reserved` kubelet 标志来预留内存和 CPU 资源。 -在 Windows 上，这些值仅用于计算节点的[可分配](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)资源。 +在 Windows 上，这些值仅用于计算节点的[可分配](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)资源。 ## 容器镜像 {#container-images} -[容器镜像](/zh/docs/concepts/containers/images/)是一个随时可以运行的软件包， +[容器镜像](/zh-cn/docs/concepts/containers/images/)是一个随时可以运行的软件包， 包含运行应用程序所需的一切：代码和它需要的所有运行时、应用程序和系统库，以及一些基本设置的默认值。 根据设计，容器是不可变的：你不能更改已经运行的容器的代码。 @@ -53,7 +53,7 @@ the change, then recreate the container to start from the updated image. * Read about [Pods](/docs/concepts/workloads/pods/) --> -* 进一步阅读[容器镜像](/zh/docs/concepts/containers/images/) -* 进一步阅读 [Pods](/zh/docs/concepts/workloads/pods/) +* 进一步阅读[容器镜像](/zh-cn/docs/concepts/containers/images/) +* 进一步阅读 [Pods](/zh-cn/docs/concepts/workloads/pods/) diff --git a/content/zh-cn/docs/concepts/containers/container-environment.md b/content/zh-cn/docs/concepts/containers/container-environment.md index 362e9d4c1b..32ed23ba50 100644 --- a/content/zh-cn/docs/concepts/containers/container-environment.md +++ b/content/zh-cn/docs/concepts/containers/container-environment.md @@ -34,8 +34,8 @@ The Kubernetes Container environment provides several important resources to Con Kubernetes 的容器环境给容器提供了几个重要的资源： -* 文件系统，其中包含一个[镜像](/zh/docs/concepts/containers/images/) - 和一个或多个的[卷](/zh/docs/concepts/storage/volumes/) +* 文件系统，其中包含一个[镜像](/zh-cn/docs/concepts/containers/images/) + 和一个或多个的[卷](/zh-cn/docs/concepts/storage/volumes/) * 容器自身的信息 * 集群中其他对象的信息 @@ -59,7 +59,7 @@ as are any environment variables specified statically in the container image. [`gethostname`](https://man7.org/linux/man-pages/man2/gethostname.2.html) 函数来获取。 Pod 名称和命名空间可以通过 -[下行 API](/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) +[下行 API](/zh-cn/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/) 转换为环境变量。 Pod 定义中的用户所定义的环境变量也可在容器中使用，就像在 container 镜像中静态指定的任何环境变量一样。 @@ -100,7 +100,7 @@ if [DNS addon](https://releases.k8s.io/{{< param "fullversion" >}}/cluster/addon * Get hands-on experience [attaching handlers to Container lifecycle events](/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/). --> -* 学习更多有关[容器生命周期回调](/zh/docs/concepts/containers/container-lifecycle-hooks/)的知识 -* 动手[为容器生命周期事件添加处理程序](/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) +* 学习更多有关[容器生命周期回调](/zh-cn/docs/concepts/containers/container-lifecycle-hooks/)的知识 +* 动手[为容器生命周期事件添加处理程序](/zh-cn/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) diff --git a/content/zh-cn/docs/concepts/containers/container-lifecycle-hooks.md b/content/zh-cn/docs/concepts/containers/container-lifecycle-hooks.md index 32d86af26a..9791183f47 100644 --- a/content/zh-cn/docs/concepts/containers/container-lifecycle-hooks.md +++ b/content/zh-cn/docs/concepts/containers/container-lifecycle-hooks.md @@ -80,7 +80,7 @@ A more detailed description of the termination behavior can be found in [Termination of Pods](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination). --> 有关终止行为的更详细描述，请参见 -[终止 Pod](/zh/docs/concepts/workloads/pods/pod-lifecycle/#termination-of-pods)。 +[终止 Pod](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#termination-of-pods)。 -* 进一步了解[容器环境](/zh/docs/concepts/containers/container-environment/) -* 动手实践，[为容器生命周期事件添加处理程序](/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) +* 进一步了解[容器环境](/zh-cn/docs/concepts/containers/container-environment/) +* 动手实践，[为容器生命周期事件添加处理程序](/zh-cn/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/) diff --git a/content/zh-cn/docs/concepts/containers/images.md b/content/zh-cn/docs/concepts/containers/images.md index 12c48ef463..f3783775cc 100644 --- a/content/zh-cn/docs/concepts/containers/images.md +++ b/content/zh-cn/docs/concepts/containers/images.md @@ -101,7 +101,7 @@ these values have: --> ### 镜像拉取策略 {#image-pull-policy} -容器的 `imagePullPolicy` 和镜像的标签会影响 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 尝试拉取（下载）指定的镜像。 +容器的 `imagePullPolicy` 和镜像的标签会影响 [kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) 尝试拉取（下载）指定的镜像。 以下列表包含了 `imagePullPolicy` 可以设置的值，以及这些值的效果： @@ -179,7 +179,7 @@ running the same code no matter what tag changes happen at the registry. 镜像摘要唯一标识了镜像的特定版本，因此 Kubernetes 每次启动具有指定镜像名称和摘要的容器时，都会运行相同的代码。 通过摘要指定镜像可固定你运行的代码，这样镜像仓库的变化就不会导致版本的混杂。 -有一些第三方的[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/) +有一些第三方的[准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/) 在创建 Pod（和 Pod 模板）时产生变更，这样运行的工作负载就是根据镜像摘要，而不是标签来定义的。 无论镜像仓库上的标签发生什么变化，你都想确保你所有的工作负载都运行相同的代码，那么指定镜像摘要会很有用。 @@ -247,7 +247,7 @@ If you would like to always force a pull, you can do one of the following: 当你提交 Pod 时，Kubernetes 会将策略设置为 `Always`。 - 省略 `imagePullPolicy` 和镜像的标签； 当你提交 Pod 时，Kubernetes 会将策略设置为 `Always`。 -- 启用准入控制器 [AlwaysPullImages](/zh/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)。 +- 启用准入控制器 [AlwaysPullImages](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)。 有关配置私有容器镜像仓库的示例，请参阅任务 -[从私有镜像库中提取图像](/zh/docs/tasks/configure-pod-container/pull-image-private-registry)。 +[从私有镜像库中提取图像](/zh-cn/docs/tasks/configure-pod-container/pull-image-private-registry)。 该示例使用 Docker Hub 中的私有注册表。 你需要对使用私有仓库的每个 Pod 执行以上操作。 不过，设置该字段的过程也可以通过为 -[服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/) +[服务账号](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/) 资源设置 `imagePullSecrets` 来自动完成。 有关详细指令可参见 -[将 ImagePullSecrets 添加到服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)。 +[将 ImagePullSecrets 添加到服务账号](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/#add-imagepullsecrets-to-a-service-account)。 你也可以将此方法与节点级别的 `.docker/config.json` 配置结合使用。 来自不同来源的凭据会被合并。 @@ -685,7 +685,7 @@ common use cases and suggested solutions. - Move sensitive data into a "Secret" resource, instead of packaging it in an image. --> 3. 集群使用专有镜像，且有些镜像需要更严格的访问控制 - - 确保 [AlwaysPullImages 准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)被启用。否则，所有 Pod 都可以使用所有镜像。 + - 确保 [AlwaysPullImages 准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)被启用。否则，所有 Pod 都可以使用所有镜像。 - 确保将敏感数据存储在 Secret 资源中，而不是将其打包在镜像里 4. 集群是多租户的并且每个租户需要自己的私有仓库 - - 确保 [AlwaysPullImages 准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)。否则，所有租户的所有的 Pod 都可以使用所有镜像。 + - 确保 [AlwaysPullImages 准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#alwayspullimages)。否则，所有租户的所有的 Pod 都可以使用所有镜像。 - 为私有仓库启用鉴权 - 为每个租户生成访问仓库的凭据，放置在 Secret 中，并将 Secrert 发布到各租户的命名空间下。 - 租户将 Secret 添加到每个名字空间中的 imagePullSecrets @@ -716,4 +716,4 @@ Kubelet will merge any `imagePullSecrets` into a single virtual `.docker/config. * Learn about [container image garbage collection](/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection). --> * 阅读 [OCI Image Manifest 规范](https://github.com/opencontainers/image-spec/blob/master/manifest.md)。 -* 了解[容器镜像垃圾收集](/zh/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)。 +* 了解[容器镜像垃圾收集](/zh-cn/docs/concepts/architecture/garbage-collection/#container-image-garbage-collection)。 diff --git a/content/zh-cn/docs/concepts/containers/runtime-class.md b/content/zh-cn/docs/concepts/containers/runtime-class.md index 99b9f8851d..5eb922eee5 100644 --- a/content/zh-cn/docs/concepts/containers/runtime-class.md +++ b/content/zh-cn/docs/concepts/containers/runtime-class.md @@ -92,7 +92,7 @@ The configurations have a corresponding `handler` name, referenced by the Runtim handler must be a valid [DNS label name](/docs/concepts/overview/working-with-objects/names/#dns-label-names). --> 所有这些配置都具有相应的 `handler` 名，并被 RuntimeClass 引用。 -handler 必须是有效的 [DNS 标签名](/zh/docs/concepts/overview/working-with-objects/names/#dns-label-names)。 +handler 必须是有效的 [DNS 标签名](/zh-cn/docs/concepts/overview/working-with-objects/names/#dns-label-names)。 {{< note >}} 建议将 RuntimeClass 写操作（create、update、patch 和 delete）限定于集群管理员使用。 -通常这是默认配置。参阅[授权概述](/zh/docs/reference/access-authn-authz/authorization/)了解更多信息。 +通常这是默认配置。参阅[授权概述](/zh-cn/docs/reference/access-authn-authz/authorization/)了解更多信息。 {{< /note >}} 这一设置会告诉 kubelet 使用所指的 RuntimeClass 来运行该 pod。 如果所指的 RuntimeClass 不存在或者 CRI 无法运行相应的 handler， -那么 pod 将会进入 `Failed` 终止[阶段](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)。 -你可以查看相应的[事件](/zh/docs/tasks/debug/debug-application/debug-running-pod/)， +那么 pod 将会进入 `Failed` 终止[阶段](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase)。 +你可以查看相应的[事件](/zh-cn/docs/tasks/debug/debug-application/debug-running-pod/)， 获取执行过程中的错误信息。 更多有关 node selector 和 tolerations 的配置信息，请查阅 -[将 Pod 分派到节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)。 +[将 Pod 分派到节点](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/)。 - [RuntimeClass 设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md) - [RuntimeClass 调度设计](https://github.com/kubernetes/enhancements/blob/master/keps/sig-node/585-runtime-class/README.md#runtimeclass-scheduling) -- 阅读关于 [Pod 开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/) 的概念 +- 阅读关于 [Pod 开销](/zh-cn/docs/concepts/scheduling-eviction/pod-overhead/) 的概念 - [PodOverhead 特性设计](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead) diff --git a/content/zh-cn/docs/concepts/extend-kubernetes/_index.md b/content/zh-cn/docs/concepts/extend-kubernetes/_index.md index e6f8d4bf86..95b0b1cf31 100644 --- a/content/zh-cn/docs/concepts/extend-kubernetes/_index.md +++ b/content/zh-cn/docs/concepts/extend-kubernetes/_index.md @@ -79,11 +79,11 @@ Customization approaches can be broadly divided into *configuration*, which only 配置文件和参数标志的说明位于在线文档的参考章节，按可执行文件组织： -* [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) -* [kube-proxy](/zh/docs/reference/command-line-tools-reference/kube-proxy/) -* [kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/) -* [kube-controller-manager](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) -* [kube-scheduler](/zh/docs/reference/command-line-tools-reference/kube-scheduler/). +* [kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) +* [kube-proxy](/zh-cn/docs/reference/command-line-tools-reference/kube-proxy/) +* [kube-apiserver](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/) +* [kube-controller-manager](/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/) +* [kube-scheduler](/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler/). -*内置的策略 API*，例如[ResourceQuota](/zh/docs/concepts/policy/resource-quotas/)、 -[PodSecurityPolicies](/zh/docs/concepts/security/pod-security-policy/)、 -[NetworkPolicy](/zh/docs/concepts/services-networking/network-policies/) -和基于角色的访问控制（[RBAC](/zh/docs/reference/access-authn-authz/rbac/)） +*内置的策略 API*，例如[ResourceQuota](/zh-cn/docs/concepts/policy/resource-quotas/)、 +[PodSecurityPolicies](/zh-cn/docs/concepts/security/pod-security-policy/)、 +[NetworkPolicy](/zh-cn/docs/concepts/services-networking/network-policies/) +和基于角色的访问控制（[RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/)） 等等都是内置的 Kubernetes API。 API 通常用于托管的 Kubernetes 服务和受控的 Kubernetes 安装环境中。 这些 API 是声明式的，与 Pod 这类其他 Kubernetes 资源遵从相同的约定， 所以新的集群配置是可复用的，并且可以当作应用程序来管理。 此外，对于稳定版本的 API 而言，它们与其他 Kubernetes API 一样， -采纳的是一种[预定义的支持策略](/zh/docs/reference/using-api/deprecation-policy/)。 +采纳的是一种[预定义的支持策略](/zh-cn/docs/reference/using-api/deprecation-policy/)。 出于以上原因，在条件允许的情况下，基于 API 的方案应该优先于配置文件和参数标志。 1. 用户通常使用 `kubectl` 与 Kubernetes API 交互。 - [kubectl 插件](/zh/docs/tasks/extend-kubectl/kubectl-plugins/)能够扩展 kubectl 程序的行为。 + [kubectl 插件](/zh-cn/docs/tasks/extend-kubectl/kubectl-plugins/)能够扩展 kubectl 程序的行为。 这些插件只会影响到每个用户的本地环境，因此无法用来强制实施整个站点范围的策略。 2. API 服务器处理所有请求。API 服务器中的几种扩展点能够使用户对请求执行身份认证、 @@ -273,7 +273,7 @@ For more about Custom Resources, see the [Custom Resources concept guide](/docs/ 不要使用自定义资源来充当应用、用户或者监控数据的数据存储。 -关于自定义资源的更多信息，可参见[自定义资源概念指南](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。 +关于自定义资源的更多信息，可参见[自定义资源概念指南](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。 ### 身份认证 {#authentication} -[身份认证](/zh/docs/reference/access-authn-authz/authentication/)负责将所有请求中 +[身份认证](/zh-cn/docs/reference/access-authn-authz/authentication/)负责将所有请求中 的头部或证书映射到发出该请求的客户端的用户名。 Kubernetes 提供若干种内置的认证方法，以及 -[认证 Webhook](/zh/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) +[认证 Webhook](/zh-cn/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) 方法以备内置方法无法满足你的要求。 ### 鉴权 {#authorization} -[鉴权](/zh/docs/reference/access-authn-authz/authorization/) +[鉴权](/zh-cn/docs/reference/access-authn-authz/authorization/) 操作负责确定特定的用户是否可以读、写 API 资源或对其执行其他操作。 此操作仅在整个资源集合的层面进行。 换言之，它不会基于对象的特定字段作出不同的判决。 如果内置的鉴权选项无法满足你的需要，你可以使用 -[鉴权 Webhook](/zh/docs/reference/access-authn-authz/webhook/)来调用用户提供 +[鉴权 Webhook](/zh-cn/docs/reference/access-authn-authz/webhook/)来调用用户提供 的代码，执行定制的鉴权操作。 ### 设备插件 {#device-plugins} -使用[设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)， +使用[设备插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/)， 节点能够发现新的节点资源（除了内置的类似 CPU 和内存这类资源）。 ### 网络插件 {#network-plugins} -通过节点层面的[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)， +通过节点层面的[网络插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)， 可以支持不同的网络设施。 -* 进一步了解[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) -* 了解[动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/) +* 进一步了解[自定义资源](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +* 了解[动态准入控制](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/) * 进一步了解基础设施扩展 - * [网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) - * [设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) -* 了解 [kubectl 插件](/zh/docs/tasks/extend-kubectl/kubectl-plugins/) -* 了解 [Operator 模式](/zh/docs/concepts/extend-kubernetes/operator/) + * [网络插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) + * [设备插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) +* 了解 [kubectl 插件](/zh-cn/docs/tasks/extend-kubectl/kubectl-plugins/) +* 了解 [Operator 模式](/zh-cn/docs/concepts/extend-kubernetes/operator/) diff --git a/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md b/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md index d2a0c6c188..52a0c64e7e 100644 --- a/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md +++ b/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation.md @@ -32,7 +32,7 @@ The aggregation layer is different from [Custom Resources](/docs/concepts/extend 或者你自己开发的 API。 聚合层不同于 -[定制资源（Custom Resources）](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。 +[定制资源（Custom Resources）](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/)。 后者的目的是让 {{< glossary_tooltip term_id="kube-apiserver" text="kube-apiserver" >}} 能够认识新的对象类别（Kind）。 @@ -83,10 +83,10 @@ If your extension API server cannot achieve that latency requirement, consider m Alternatively: learn how to [extend the Kubernetes API using Custom Resource Definitions](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/). --> -* 阅读[配置聚合层](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 文档， +* 阅读[配置聚合层](/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer/) 文档， 了解如何在自己的环境中启用聚合器。 -* 接下来，了解[安装扩展 API 服务器](/zh/docs/tasks/extend-kubernetes/setup-extension-api-server/)， +* 接下来，了解[安装扩展 API 服务器](/zh-cn/docs/tasks/extend-kubernetes/setup-extension-api-server/)， 开始使用聚合层。 * 从 API 参考资料中研究关于 [APIService](/docs/reference/kubernetes-api/cluster-resources/api-service-v1/) 的内容。 -或者，学习如何[使用自定义资源定义扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。 +或者，学习如何[使用自定义资源定义扩展 Kubernetes API](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/)。 diff --git a/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources.md b/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources.md index e2021c4043..f69c13963f 100644 --- a/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources.md +++ b/content/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources.md @@ -37,9 +37,9 @@ collection of Pod objects. ## 定制资源 *资源（Resource）* 是 -[Kubernetes API](/zh/docs/concepts/overview/kubernetes-api/) 中的一个端点， +[Kubernetes API](/zh-cn/docs/concepts/overview/kubernetes-api/) 中的一个端点， 其中存储的是某个类别的 -[API 对象](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects/) +[API 对象](/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects/) 的一个集合。 例如内置的 *pods* 资源包含一组 Pod 对象。 @@ -84,7 +84,7 @@ keep the current state of Kubernetes objects in sync with the desired state. The controller interprets the structured data as a record of the user's desired state, and continually maintains this state. --> -使用[声明式 API](/zh/docs/concepts/overview/kubernetes-api/)， +使用[声明式 API](/zh-cn/docs/concepts/overview/kubernetes-api/)， 你可以 _声明_ 或者设定你的资源的期望状态，并尝试让 Kubernetes 对象的当前状态 同步到其期望状态。控制器负责将结构化的数据解释为用户所期望状态的记录，并 持续地维护该状态。 @@ -99,7 +99,7 @@ for specific applications into an extension of the Kubernetes API. --> 你可以在一个运行中的集群上部署和更新定制控制器，这类操作与集群的生命周期无关。 定制控制器可以用于任何类别的资源，不过它们与定制资源结合起来时最为有效。 -[Operator 模式](/zh/docs/concepts/extend-kubernetes/operator/)就是将定制资源 +[Operator 模式](/zh-cn/docs/concepts/extend-kubernetes/operator/)就是将定制资源 与定制控制器相结合的。你可以使用定制控制器来将特定于某应用的领域知识组织 起来，以编码的形式构造对 Kubernetes API 的扩展。 @@ -113,7 +113,7 @@ or let your API stand alone. ## 我是否应该向我的 Kubernetes 集群添加定制资源？ 在创建新的 API 时，请考虑是 -[将你的 API 与 Kubernetes 集群 API 聚合起来](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) +[将你的 API 与 Kubernetes 集群 API 聚合起来](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 还是让你的 API 独立运行。 {{< note >}} -请使用 [Secret](/zh/docs/concepts/configuration/secret/) 来保存敏感数据。 +请使用 [Secret](/zh-cn/docs/concepts/configuration/secret/) 来保存敏感数据。 Secret 类似于 configMap，但更为安全。 {{< /note >}} @@ -251,7 +251,7 @@ Kubernetes provides two ways to add custom resources to your cluster: Kubernetes 提供了两种方式供你向集群中添加定制资源： - CRD 相对简单，创建 CRD 可以不必编程。 -- [API 聚合](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) +- [API 聚合](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 需要编程，但支持对 API 行为进行更多的控制，例如数据如何存储以及在不同 API 版本间如何转换等。 ## CustomResourceDefinitions -[CustomResourceDefinition](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) +[CustomResourceDefinition](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) API 资源允许你定义定制资源。 定义 CRD 对象的操作会使用你所设定的名字和模式定义（Schema）创建一个新的定制资源， Kubernetes API 负责为你的定制资源提供存储和访问服务。 CRD 对象的名称必须是合法的 -[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)。 | 特性 | 描述 | CRDs | 聚合 API | | ------- | ----------- | ---- | -------------- | -| 合法性检查 | 帮助用户避免错误，允许你独立于客户端版本演化 API。这些特性对于由很多无法同时更新的客户端的场合。| 可以。大多数验证可以使用 [OpenAPI v3.0 合法性检查](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) 来设定。其他合法性检查操作可以通过添加[合法性检查 Webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)来实现。 | 可以，可执行任何合法性检查。| -| 默认值设置 | 同上 | 可以。可通过 [OpenAPI v3.0 合法性检查](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting)的 `default` 关键词（自 1.17 正式发布）或[更改性（Mutating）Webhook](/zh/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)来实现（不过从 etcd 中读取老的对象时不会执行这些 Webhook）。 | 可以。 | -| 多版本支持 | 允许通过两个 API 版本同时提供同一对象。可帮助简化类似字段更名这类 API 操作。如果你能控制客户端版本，这一特性将不再重要。 | [可以](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning)。 | 可以。 | +| 合法性检查 | 帮助用户避免错误，允许你独立于客户端版本演化 API。这些特性对于由很多无法同时更新的客户端的场合。| 可以。大多数验证可以使用 [OpenAPI v3.0 合法性检查](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) 来设定。其他合法性检查操作可以通过添加[合法性检查 Webhook](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#validatingadmissionwebhook-alpha-in-1-8-beta-in-1-9)来实现。 | 可以，可执行任何合法性检查。| +| 默认值设置 | 同上 | 可以。可通过 [OpenAPI v3.0 合法性检查](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#defaulting)的 `default` 关键词（自 1.17 正式发布）或[更改性（Mutating）Webhook](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#mutatingadmissionwebhook)来实现（不过从 etcd 中读取老的对象时不会执行这些 Webhook）。 | 可以。 | +| 多版本支持 | 允许通过两个 API 版本同时提供同一对象。可帮助简化类似字段更名这类 API 操作。如果你能控制客户端版本，这一特性将不再重要。 | [可以](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definition-versioning)。 | 可以。 | | 定制存储 | 支持使用具有不同性能模式的存储（例如，要使用时间序列数据库而不是键值存储），或者因安全性原因对存储进行隔离（例如对敏感信息执行加密）。 | 不可以。 | 可以。 | -| 定制业务逻辑 | 在创建、读取、更新或删除对象时，执行任意的检查或操作。 | 可以。要使用 [Webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。 | 可以。 | -| 支持 scale 子资源 | 允许 HorizontalPodAutoscaler 和 PodDisruptionBudget 这类子系统与你的新资源交互。 | [可以](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource)。 | 可以。 | -| 支持 status 子资源 | 允许在用户写入 spec 部分而控制器写入 status 部分时执行细粒度的访问控制。允许在对定制资源的数据进行更改时增加对象的代际（Generation）；这需要资源对 spec 和 status 部分有明确划分。| [可以](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#status-subresource)。 | 可以。 | +| 定制业务逻辑 | 在创建、读取、更新或删除对象时，执行任意的检查或操作。 | 可以。要使用 [Webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。 | 可以。 | +| 支持 scale 子资源 | 允许 HorizontalPodAutoscaler 和 PodDisruptionBudget 这类子系统与你的新资源交互。 | [可以](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#scale-subresource)。 | 可以。 | +| 支持 status 子资源 | 允许在用户写入 spec 部分而控制器写入 status 部分时执行细粒度的访问控制。允许在对定制资源的数据进行更改时增加对象的代际（Generation）；这需要资源对 spec 和 status 部分有明确划分。| [可以](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#status-subresource)。 | 可以。 | | 其他子资源 | 添加 CRUD 之外的操作，例如 "logs" 或 "exec"。 | 不可以。 | 可以。 | -| strategic-merge-patch | 新的端点要支持标记了 `Content-Type: application/strategic-merge-patch+json` 的 PATCH 操作。对于更新既可在本地更改也可在服务器端更改的对象而言是有用的。要了解更多信息，可参见[使用 `kubectl patch` 来更新 API 对象](/zh/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)。 | 不可以。 | 可以。 | +| strategic-merge-patch | 新的端点要支持标记了 `Content-Type: application/strategic-merge-patch+json` 的 PATCH 操作。对于更新既可在本地更改也可在服务器端更改的对象而言是有用的。要了解更多信息，可参见[使用 `kubectl patch` 来更新 API 对象](/zh-cn/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/)。 | 不可以。 | 可以。 | | 支持协议缓冲区 | 新的资源要支持想要使用协议缓冲区（Protocol Buffer）的客户端。 | 不可以。 | 可以。 | -| OpenAPI Schema | 是否存在新资源类别的 OpenAPI（Swagger）Schema 可供动态从服务器上读取？是否存在机制确保只能设置被允许的字段以避免用户犯字段拼写错误？是否实施了字段类型检查（换言之，不允许在 `string` 字段设置 `int` 值）？ | 可以，依据 [OpenAPI v3.0 合法性检查](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) 模式（1.16 中进入正式发布状态）。 | 可以。| +| OpenAPI Schema | 是否存在新资源类别的 OpenAPI（Swagger）Schema 可供动态从服务器上读取？是否存在机制确保只能设置被允许的字段以避免用户犯字段拼写错误？是否实施了字段类型检查（换言之，不允许在 `string` 字段设置 `int` 值）？ | 可以，依据 [OpenAPI v3.0 合法性检查](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/#validation) 模式（1.16 中进入正式发布状态）。 | 可以。| ## 访问定制资源 -Kubernetes [客户端库](/zh/docs/reference/using-api/client-libraries/)可用来访问定制资源。 +Kubernetes [客户端库](/zh-cn/docs/reference/using-api/client-libraries/)可用来访问定制资源。 并非所有客户端库都支持定制资源。_Go_ 和 _Python_ 客户端库是支持的。 当你添加了新的定制资源后，可以用如下方式之一访问它们： @@ -553,6 +553,6 @@ Kubernetes [客户端库](/zh/docs/reference/using-api/client-libraries/)可用 * Learn how to [Extend the Kubernetes API with the aggregation layer](/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/). * Learn how to [Extend the Kubernetes API with CustomResourceDefinition](/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/). --> -* 了解如何[使用聚合层扩展 Kubernetes API](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) -* 了解如何[使用 CustomResourceDefinition 来扩展 Kubernetes API](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) +* 了解如何[使用聚合层扩展 Kubernetes API](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) +* 了解如何[使用 CustomResourceDefinition 来扩展 Kubernetes API](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) diff --git a/content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md b/content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md index c1f94153e0..90a4494d0f 100644 --- a/content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md +++ b/content/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins.md @@ -67,7 +67,7 @@ to advertise that the node has 2 "Foo" devices installed and available. * 设备插件的 Unix 套接字。 * 设备插件的 API 版本。 * `ResourceName` 是需要公布的。这里 `ResourceName` 需要遵循 - [扩展资源命名方案](/zh/docs/concepts/configuration/manage-resources-containers/#extended-resources)， + [扩展资源命名方案](/zh-cn/docs/concepts/configuration/manage-resources-containers/#extended-resources)， 类似于 `vendor-domain/resourcetype`。（比如 NVIDIA GPU 就被公布为 `nvidia.com/gpu`。） 成功注册后，设备插件就向 kubelet 发送它所管理的设备列表，然后 kubelet @@ -86,7 +86,7 @@ other resources, with the following differences: * Devices cannot be shared between containers. --> 然后，用户可以请求设备作为 Pod 规范的一部分， -参见[Container](/zh/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)。 +参见[Container](/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#Container)。 请求扩展资源类似于管理请求和限制的方式， 其他资源，有以下区别： @@ -441,7 +441,7 @@ it does (for example: hotplug/hotunplug, device health changes), client is expec However, calling `GetAllocatableResources` endpoint is not sufficient in case of cpu and/or memory update and Kubelet needs to be restarted to reflect the correct resource capacity and allocatable. --> -`GetAllocatableResources` 应该仅被用于评估一个节点上的[可分配的](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) +`GetAllocatableResources` 应该仅被用于评估一个节点上的[可分配的](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) 资源。如果目标是评估空闲/未分配的资源，此调用应该与 List() 端点一起使用。 除非暴露给 kubelet 的底层资源发生变化 否则 `GetAllocatableResources` 得到的结果将保持不变。 这种情况很少发生，但当发生时（例如：热插拔，设备健康状况改变），客户端应该调用 `GetAlloctableResources` 端点。 @@ -471,7 +471,7 @@ Preceding Kubernetes v1.23, to enable this feature `kubelet` must be started wit --> 从 Kubernetes v1.23 开始，`GetAllocatableResources` 被默认启用。 你可以通过关闭 `KubeletPodResourcesGetAllocatable` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) 来禁用。 +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) 来禁用。 在 Kubernetes v1.23 之前，要启用这一功能，`kubelet` 必须用以下标志启动： @@ -484,7 +484,7 @@ plugins report [when they register themselves to the kubelet](/docs/concepts/ext --> `ContainerDevices` 会向外提供各个设备所隶属的 NUMA 单元这类拓扑信息。 NUMA 单元通过一个整数 ID 来标识，其取值与设备插件所报告的一致。 -[设备插件注册到 kubelet 时](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) +[设备插件注册到 kubelet 时](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) 会报告这类信息。 -* 查看[调度 GPU 资源](/zh/docs/tasks/manage-gpus/scheduling-gpus/) 来学习使用设备插件 -* 查看在上如何[公布节点上的扩展资源](/zh/docs/tasks/administer-cluster/extended-resource-node/) -* 学习[拓扑管理器](/zh/docs/tasks/administer-cluster/topology-manager/) -* 阅读如何在 Kubernetes 中使用 [TLS Ingress 的硬件加速](/zh/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) +* 查看[调度 GPU 资源](/zh-cn/docs/tasks/manage-gpus/scheduling-gpus/) 来学习使用设备插件 +* 查看在上如何[公布节点上的扩展资源](/zh-cn/docs/tasks/administer-cluster/extended-resource-node/) +* 学习[拓扑管理器](/zh-cn/docs/tasks/administer-cluster/topology-manager/) +* 阅读如何在 Kubernetes 中使用 [TLS Ingress 的硬件加速](/zh-cn/blog/2019/04/24/hardware-accelerated-ssl/tls-termination-in-ingress-controllers-using-kubernetes-device-plugins-and-runtimeclass/) diff --git a/content/zh-cn/docs/concepts/extend-kubernetes/operator.md b/content/zh-cn/docs/concepts/extend-kubernetes/operator.md index 7dd8e6fbd3..5403556037 100644 --- a/content/zh-cn/docs/concepts/extend-kubernetes/operator.md +++ b/content/zh-cn/docs/concepts/extend-kubernetes/operator.md @@ -19,9 +19,9 @@ to manage applications and their components. Operators follow Kubernetes principles, notably the [control loop](/docs/concepts/architecture/controller/). --> Operator 是 Kubernetes 的扩展软件，它利用 -[定制资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +[定制资源](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 管理应用及其组件。 -Operator 遵循 Kubernetes 的理念，特别是在[控制器](/zh/docs/concepts/architecture/controller/) +Operator 遵循 Kubernetes 的理念，特别是在[控制器](/zh-cn/docs/concepts/architecture/controller/) 方面。 @@ -67,7 +67,7 @@ Kubernetes 的 {{< glossary_tooltip text="Operator 模式" term_id="operator-pat Kubernetes 自身代码的情况下，通过为一个或多个自定义资源关联{{< glossary_tooltip text="控制器" term_id="controller" >}} 来扩展集群的能力。 Operator 是 Kubernetes API 的客户端，充当 -[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +[自定义资源](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 的控制器。 * 阅读 {{< glossary_tooltip text="CNCF" term_id="cncf" >}} [Operator 白皮书](https://github.com/cncf/tag-app-delivery/blob/eece8f7307f2970f46f100f51932db106db46968/operator-wg/whitepaper/Operator-WhitePaper_v1-0.md)。 -* 详细了解 [定制资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +* 详细了解 [定制资源](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/) * 在 [OperatorHub.io](https://operatorhub.io/) 上找到现成的、适合你的 Operator * [发布](https://operatorhub.io/)你的 Operator，让别人也可以使用 * 阅读 [CoreOS 原始文章](https://web.archive.org/web/20170129131616/https://coreos.com/blog/introducing-operators.html)，它介绍了 Operator 模式（这是一个存档版本的原始文章）。 diff --git a/content/zh-cn/docs/concepts/extend-kubernetes/service-catalog.md b/content/zh-cn/docs/concepts/extend-kubernetes/service-catalog.md deleted file mode 100644 index fe5437c1ba..0000000000 --- a/content/zh-cn/docs/concepts/extend-kubernetes/service-catalog.md +++ /dev/null @@ -1,445 +0,0 @@ ---- -title: 服务目录 -content_type: concept -weight: 40 ---- - - - -{{< glossary_definition term_id="service-catalog" length="all" prepend="服务目录（Service Catalog）是" >}} - - -服务代理（Service Broker）是由[Open Service Broker API 规范](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md)定义的一组托管服务的端点，这些服务由第三方提供并维护，其中的第三方可以是 AWS、GCP 或 Azure 等云服务提供商。 -托管服务的一些示例是 Microsoft Azure Cloud Queue、Amazon Simple Queue Service 和 Google Cloud Pub/Sub，但它们可以是应用程序能够使用的任何软件交付物。 - -使用服务目录，{{< glossary_tooltip text="集群操作员" term_id="cluster-operator" >}} -可以浏览某服务代理所提供的托管服务列表，供应托管服务实例并与之绑定， -以使其可以被 Kubernetes 集群中的应用程序使用。 - - - -## 示例用例 - -{{< glossary_tooltip text="应用开发人员" term_id="application-developer" >}}， -希望使用消息队列，作为其在 Kubernetes 集群中运行的应用程序的一部分。 -但是，他们不想承受构造这种服务的开销，也不想自行管理。 -幸运的是，有一家云服务提供商通过其服务代理以托管服务的形式提供消息队列服务。 - -集群操作员可以设置服务目录并使用它与云服务提供商的服务代理通信，进而部署消息队列服务的实例 -并使其对 Kubernetes 中的应用程序可用。 -应用开发者于是可以不关心消息队列的实现细节，也不用对其进行管理。 -他们的应用程序可以简单的将其作为服务使用。 - - -## 架构 {#architecture} - -服务目录使用[Open Service Broker API](https://github.com/openservicebrokerapi/servicebroker) -与服务代理进行通信，并作为 Kubernetes API 服务器的中介，以便协商启动部署和获取 -应用程序使用托管服务时必须的凭据。 - -它是[基于 CRDs](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/#custom-resources) -架构实现的。 - -![服务目录架构](/images/docs/service-catalog-architecture.svg) - - -## API 资源 {#api-resources} - -服务目录安装 `servicecatalog.k8s.io` API 并提供以下 Kubernetes 资源： - -* `ClusterServiceBroker`：服务目录的集群内表现形式，封装了其服务连接细节。集群运维人员创建和管理这些资源，并希望使用该代理服务在集群中提供新类型的托管服务。 -* `ClusterServiceClass`：由特定服务代理提供的托管服务。当新的 `ClusterServiceBroker` 资源被添加到集群时，服务目录控制器将连接到服务代理以获取可用的托管服务列表。然后为每个托管服务创建对应的新 `ClusterServiceClass` 资源。 -* `ClusterServicePlan`：托管服务的特定产品。例如托管服务可能有不同的计划可用，如免费版本和付费版本，或者可能有不同的配置选项，例如使用 SSD 存储或拥有更多资源。与 `ClusterServiceClass` 类似，当一个新的 `ClusterServiceBroker` 被添加到集群时，服务目录会为每个托管服务的每个可用服务计划创建对应的新 `ClusterServicePlan` 资源。 -* `ServiceInstance`：`ClusterServiceClass` 提供的示例。由集群运维人员创建，以使托管服务的特定实例可供一个或多个集群内应用程序使用。当创建一个新的 `ServiceInstance` 资源时，服务目录控制器将连接到相应的服务代理并指示它调配服务实例。 -* `ServiceBinding`：`ServiceInstance` 的访问凭据。由希望其应用程序使用服务 `ServiceInstance` 的集群运维人员创建。创建之后，服务目录控制器将创建一个 Kubernetes `Secret`，其中包含服务实例的连接细节和凭据，可以挂载到 Pod 中。 - - -### 认证 {#authentication} - -服务目录支持这些认证方法： - -* 基本认证（用户名/密码） -* [OAuth 2.0 不记名令牌](https://tools.ietf.org/html/rfc6750) - - -## 使用方式 - -集群运维人员可以使用服务目录 API 资源来供应托管服务并使其在 Kubernetes 集群内可用。涉及的步骤有： - -1. 列出服务代理提供的托管服务和服务计划。 -2. 配置托管服务的新实例。 -3. 绑定到托管服务，它将返回连接凭证。 -4. 将连接凭证映射到应用程序中。 - - -### 列出托管服务和服务计划 - -首先，集群运维人员在 `servicecatalog.k8s.io` 组内创建一个 `ClusterServiceBroker` 资源。此资源包含访问服务代理终结点所需的 URL 和连接详细信息。 - -这是一个 `ClusterServiceBroker` 资源的例子： - -```yaml -apiVersion: servicecatalog.k8s.io/v1beta1 -kind: ClusterServiceBroker -metadata: - name: cloud-broker -spec: - # 指向服务代理的末端。(这里的 URL 是无法使用的。) - url: https://servicebroker.somecloudprovider.com/v1alpha1/projects/service-catalog/brokers/default - ##### - # 这里可以添加额外的用来与服务代理通信的属性值, - # 例如持有者令牌信息或者 TLS 的 CA 包。 - ##### -``` - - -下面的时序图展示了从服务代理列出可用托管服务和计划所涉及的各个步骤： - -![列举服务](/images/docs/service-catalog-list.svg) - -1. 一旦 `ClusterServiceBroker` 资源被添加到了服务目录之后，将会触发一个到外部服务代理的 - 调用，以列举所有可用服务； -1. 服务代理返回可用的托管服务和服务计划列表，这些列表将本地缓存在 `ClusterServiceClass` - 和 `ClusterServicePlan` 资源中。 -1. 集群运维人员接下来可以使用以下命令获取可用托管服务的列表： - - - - ```shell - kubectl get clusterserviceclasses \ - -o=custom-columns=SERVICE\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName - ``` - - 它应该输出一个和以下格式类似的服务名称列表： - - ``` - SERVICE NAME EXTERNAL NAME - 4f6e6cf6-ffdd-425f-a2c7-3c9258ad2468 cloud-provider-service - ... ... - ``` - - 他们还可以使用以下命令查看可用的服务计划： - - ```shell - kubectl get clusterserviceplans \ - -o=custom-columns=PLAN\ NAME:.metadata.name,EXTERNAL\ NAME:.spec.externalName - ``` - - 它应该输出一个和以下格式类似的服务计划列表： - - ``` - PLAN NAME EXTERNAL NAME - 86064792-7ea2-467b-af93-ac9694d96d52 service-plan-name - ... ... - ``` - - -### 供应一个新实例 - -集群运维人员 可以通过创建一个 `ServiceInstance` 资源来启动一个新实例的配置。 - -下面是一个 `ServiceInstance` 资源的例子： - -```yaml -apiVersion: servicecatalog.k8s.io/v1beta1 -kind: ServiceInstance -metadata: - name: cloud-queue-instance - namespace: cloud-apps -spec: - # 引用之前返回的服务之一 - clusterServiceClassExternalName: cloud-provider-service - clusterServicePlanExternalName: service-plan-name - ##### - # 这里可添加额外的参数，供服务代理使用 - ##### -``` - - -以下时序图展示了配置托管服务新实例所涉及的步骤： - -![供应服务](/images/docs/service-catalog-provision.svg) - -1. 创建 `ServiceInstance` 资源时，服务目录将启动一个到外部服务代理的调用， - 请求供应一个实例。 -1. 服务代理创建一个托管服务的新实例并返回 HTTP 响应。 -1. 接下来，集群运维人员可以检查实例的状态是否就绪。 - - -### 绑定到托管服务 - -在设置新实例之后，集群运维人员必须绑定到托管服务才能获取应用程序使用服务所需的连接凭据和服务账户的详细信息。该操作通过创建一个 `ServiceBinding` 资源完成。 - -以下是 `ServiceBinding` 资源的示例： - -```yaml -apiVersion: servicecatalog.k8s.io/v1beta1 -kind: ServiceBinding -metadata: - name: cloud-queue-binding - namespace: cloud-apps -spec: - instanceRef: - name: cloud-queue-instance - ##### - # 这里可以添加供服务代理使用的额外信息，例如 Secret 名称或者服务账号参数， - ##### -``` - - -以下顺序图展示了绑定到托管服务实例的步骤： - -![绑定到托管服务](/images/docs/service-catalog-bind.svg) - -1. 在创建 `ServiceBinding` 之后，服务目录调用外部服务代理，请求绑定服务实例所需的信息。 -1. 服务代理为相应服务账户启用应用权限/角色。 -1. 服务代理返回连接和访问托管服务示例所需的信息。这是由提供商和服务特定的，故返回的信息可能因服务提供商和其托管服务而有所不同。 - - -### 映射连接凭据 - -完成绑定之后的最后一步就是将连接凭据和服务特定的信息映射到应用程序中。这些信息存储在 secret 中，集群中的应用程序可以访问并使用它们直接与托管服务进行连接。 - -
- -![映射连接凭据](/images/docs/service-catalog-map.svg) - - -#### Pod 配置文件 - -执行此映射的一种方法是使用声明式 Pod 配置。 - -以下示例描述了如何将服务账户凭据映射到应用程序中。名为 `sa-key` 的密钥保存在一个名为 -`provider-cloud-key` 的卷中，应用程序会将该卷挂载在 `/var/secrets/provider/key.json` -路径下。环境变量 `PROVIDER_APPLICATION_CREDENTIALS` 将映射为挂载文件的路径。 - -```yaml -... - spec: - volumes: - - name: provider-cloud-key - secret: - secretName: sa-key - containers: -... - volumeMounts: - - name: provider-cloud-key - mountPath: /var/secrets/provider - env: - - name: PROVIDER_APPLICATION_CREDENTIALS - value: "/var/secrets/provider/key.json" -``` - - -以下示例描述了如何将 Secret 值映射为应用程序的环境变量。 -在这个示例中，消息队列的主题名从 Secret `provider-queue-credentials` 中名为 -`topic` 的主键映射到环境变量 `TOPIC` 中。 - -```yaml -... - env: - - name: "TOPIC" - valueFrom: - secretKeyRef: - name: provider-queue-credentials - key: topic -``` - -## {{% heading "whatsnext" %}} - - -* 如果你熟悉 {{< glossary_tooltip text="Helm Charts" term_id="helm-chart" >}}， - 可以[使用 Helm 安装服务目录](/zh/docs/tasks/service-catalog/install-service-catalog-using-helm/) - 到 Kubernetes 集群中。或者，你可以 - [使用 SC 工具安装服务目录](/zh/docs/tasks/service-catalog/install-service-catalog-using-sc/)。 -* 查看[服务代理示例](https://github.com/openservicebrokerapi/servicebroker/blob/master/gettingStarted.md#sample-service-brokers) -* 浏览 [kubernetes-sigs/service-catalog](https://github.com/kubernetes-sigs/service-catalog) 项目 - - diff --git a/content/zh-cn/docs/concepts/overview/components.md b/content/zh-cn/docs/concepts/overview/components.md index 902edf5cd3..e7f844aaa6 100644 --- a/content/zh-cn/docs/concepts/overview/components.md +++ b/content/zh-cn/docs/concepts/overview/components.md @@ -63,7 +63,7 @@ for an example control plane setup that runs across multiple machines. 控制平面组件可以在集群中的任何节点上运行。 然而，为了简单起见，设置脚本通常会在同一个计算机上启动所有控制平面组件， 并且不会在此计算机上运行用户容器。 -请参阅[使用 kubeadm 构建高可用性集群](/zh/docs/setup/production-environment/tools/kubeadm/high-availability/) +请参阅[使用 kubeadm 构建高可用性集群](/zh-cn/docs/setup/production-environment/tools/kubeadm/high-availability/) 中关于跨多机器控制平面设置的示例。 ### kube-apiserver @@ -177,7 +177,7 @@ Selected addons are described below; for an extended list of available addons, p see [Addons](/docs/concepts/cluster-administration/addons/). --> 下面描述众多插件中的几种。有关可用插件的完整列表，请参见 -[插件（Addons）](/zh/docs/concepts/cluster-administration/addons/)。 +[插件（Addons）](/zh-cn/docs/concepts/cluster-administration/addons/)。 ### Web 界面（仪表盘） {#web-ui-dashboard} -[Dashboard](/zh/docs/tasks/access-application-cluster/web-ui-dashboard/) +[Dashboard](/zh-cn/docs/tasks/access-application-cluster/web-ui-dashboard/) 是 Kubernetes 集群的通用的、基于 Web 的用户界面。 它使用户可以管理集群中运行的应用程序以及集群本身， 并进行故障排除。 @@ -218,7 +218,7 @@ about containers in a central database, and provides a UI for browsing that data --> ### 容器资源监控 {#container-resource-monitoring} -[容器资源监控](/zh/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) +[容器资源监控](/zh-cn/docs/tasks/debug/debug-cluster/resource-usage-monitoring/) 将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中， 并提供浏览这些数据的界面。 @@ -230,7 +230,7 @@ saving container logs to a central log store with search/browsing interface. --> ### 集群层面日志 {#cluster-level-logging} -[集群层面日志](/zh/docs/concepts/cluster-administration/logging/) +[集群层面日志](/zh-cn/docs/concepts/cluster-administration/logging/) 机制负责将容器的日志数据保存到一个集中的日志存储中， 这种集中日志存储提供搜索和浏览接口。 @@ -242,7 +242,7 @@ saving container logs to a central log store with search/browsing interface. * Learn about [kube-scheduler](/docs/concepts/scheduling-eviction/kube-scheduler/) * Read etcd's official [documentation](https://etcd.io/docs/) --> -* 进一步了解[节点](/zh/docs/concepts/architecture/nodes/) -* 进一步了解[控制器](/zh/docs/concepts/architecture/controller/) -* 进一步了解 [kube-scheduler](/zh/docs/concepts/scheduling-eviction/kube-scheduler/) +* 进一步了解[节点](/zh-cn/docs/concepts/architecture/nodes/) +* 进一步了解[控制器](/zh-cn/docs/concepts/architecture/controller/) +* 进一步了解 [kube-scheduler](/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler/) * 阅读 etcd 官方[文档](https://etcd.io/docs/) diff --git a/content/zh-cn/docs/concepts/overview/kubernetes-api.md b/content/zh-cn/docs/concepts/overview/kubernetes-api.md index 52b9c32b1e..ce6a1575d7 100644 --- a/content/zh-cn/docs/concepts/overview/kubernetes-api.md +++ b/content/zh-cn/docs/concepts/overview/kubernetes-api.md @@ -35,8 +35,8 @@ API 服务器负责提供 HTTP API，以供用户、集群中的不同部分和 Kubernetes API 使你可以查询和操纵 Kubernetes API 中对象（例如：Pod、Namespace、ConfigMap 和 Event）的状态。 -大部分操作都可以通过 [kubectl](/zh/docs/reference/kubectl/) 命令行接口或 -类似 [kubeadm](/zh/docs/reference/setup-tools/kubeadm/) 这类命令行工具来执行， +大部分操作都可以通过 [kubectl](/zh-cn/docs/reference/kubectl/) 命令行接口或 +类似 [kubeadm](/zh-cn/docs/reference/setup-tools/kubeadm/) 这类命令行工具来执行， 这些工具在背后也是调用 API。不过，你也可以使用 REST 调用来访问这些 API。 如果你正在编写程序来访问 Kubernetes API，可以考虑使用 -[客户端库](/zh/docs/reference/using-api/client-libraries/)之一。 +[客户端库](/zh-cn/docs/reference/using-api/client-libraries/)之一。 @@ -157,7 +157,7 @@ for the kube-apiserver component. Kubernetes {{< param "version" >}} 提供将其 API 以 OpenAPI v3 形式发布的 beta 支持； 这一功能特性处于 beta 状态，默认被开启。 你可以通过为 kube-apiserver 组件关闭 `OpenAPIV3` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)来禁用此 beta 特性。 +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)来禁用此 beta 特性。 一般而言，新的 API 资源和新的资源字段可以被频繁地添加进来。 删除资源或者字段则要遵从 -[API 废弃策略](/zh/docs/reference/using-api/deprecation-policy/)。 +[API 废弃策略](/zh-cn/docs/reference/using-api/deprecation-policy/)。 关于 API 版本分级的定义细节，请参阅 -[API 版本参考](/zh/docs/reference/using-api/#api-versioning)页面。 +[API 版本参考](/zh-cn/docs/reference/using-api/#api-versioning)页面。 -1. 你可以使用[自定义资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +1. 你可以使用[自定义资源](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/) 来以声明式方式定义 API 服务器如何提供你所选择的资源 API。 1. 你也可以选择实现自己的 - [聚合层](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) + [聚合层](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 来扩展 Kubernetes API。 ## {{% heading "whatsnext" %}} @@ -323,11 +323,11 @@ The Kubernetes API can be extended in one of two ways: [API changes](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme). --> - 了解如何通过添加你自己的 - [CustomResourceDefinition](/zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) + [CustomResourceDefinition](/zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) 来扩展 Kubernetes API。 -- [控制 Kubernetes API 访问](/zh/docs/concepts/security/controlling-access/)页面描述了集群如何针对 +- [控制 Kubernetes API 访问](/zh-cn/docs/concepts/security/controlling-access/)页面描述了集群如何针对 API 访问管理身份认证和鉴权。 -- 通过阅读 [API 参考](/zh/docs/reference/kubernetes-api/)了解 API 端点、资源类型以及示例。 +- 通过阅读 [API 参考](/zh-cn/docs/reference/kubernetes-api/)了解 API 端点、资源类型以及示例。 - 阅读 [API 变更（英文）](https://git.k8s.io/community/contributors/devel/sig-architecture/api_changes.md#readme) 以了解什么是兼容性的变更以及如何变更 API。 diff --git a/content/zh-cn/docs/concepts/overview/what-is-kubernetes.md b/content/zh-cn/docs/concepts/overview/what-is-kubernetes.md index e26ea7c861..25feebb7fc 100644 --- a/content/zh-cn/docs/concepts/overview/what-is-kubernetes.md +++ b/content/zh-cn/docs/concepts/overview/what-is-kubernetes.md @@ -273,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-cn/docs/concepts/overview/components/) +* 开始[Kubernetes 的建置](/zh-cn/docs/setup/)吧！ diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/annotations.md b/content/zh-cn/docs/concepts/overview/working-with-objects/annotations.md index 4d2ff7fc6f..c8a03e0bc6 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/annotations.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/annotations.md @@ -163,5 +163,5 @@ spec: -* 进一步了解[标签和选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)。 +* 进一步了解[标签和选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/)。 diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/field-selectors.md b/content/zh-cn/docs/concepts/overview/working-with-objects/field-selectors.md index f5a78976da..35fc5cdda4 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/field-selectors.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/field-selectors.md @@ -11,7 +11,7 @@ weight: 60 _Field selectors_ let you [select Kubernetes resources](/docs/concepts/overview/working-with-objects/kubernetes-objects) based on the value of one or more resource fields. Here are some example field selector queries: --> “字段选择器（Field selectors）”允许你根据一个或多个资源字段的值 -[筛选 Kubernetes 资源](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects)。 +[筛选 Kubernetes 资源](/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects)。 下面是一些使用字段选择器查询的例子： * `metadata.name=my-service` @@ -21,7 +21,7 @@ _Field selectors_ let you [select Kubernetes resources](/docs/concepts/overview/ -下面这个 `kubectl` 命令将筛选出 [`status.phase`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) +下面这个 `kubectl` 命令将筛选出 [`status.phase`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-phase) 字段值为 `Running` 的所有 Pod： ```shell @@ -81,7 +81,7 @@ As with [label](/docs/concepts/overview/working-with-objects/labels) and other s --> ## 链式选择器 {#chained-selectors} -同[标签](/zh/docs/concepts/overview/working-with-objects/labels/)和其他选择器一样， +同[标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/)和其他选择器一样， 字段选择器可以通过使用逗号分隔的列表组成一个选择链。 下面这个 `kubectl` 命令将筛选 `status.phase` 字段不等于 `Running` 同时 `spec.restartPolicy` 字段等于 `Always` 的所有 Pod： diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/finalizers.md b/content/zh-cn/docs/concepts/overview/working-with-objects/finalizers.md index 6a0a784fcf..21654acda9 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/finalizers.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/finalizers.md @@ -87,7 +87,7 @@ Kubernetes 清除 `pv-protection` Finalizer，控制器就会删除该卷。 ## Owner references, labels, and finalizers {#owners-labels-finalizers} Like {{}}, -[owner references](/concepts/overview/working-with-objects/owners-dependents/) +[owner references](/docs/concepts/overview/working-with-objects/owners-dependents/) describe the relationships between objects in Kubernetes, but are used for a different purpose. When a {{}} manages objects @@ -99,7 +99,7 @@ any Pods in the cluster with the same label. ## 属主引用、标签和 Finalizers {#owners-labels-finalizers} 与{{}}类似， -[属主引用](/zh/concepts/overview/working-with-objects/owners-dependents/) +[属主引用](/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents/) 描述了 Kubernetes 中对象之间的关系，但它们作用不同。 当一个{{}} 管理类似于 Pod 的对象时，它使用标签来跟踪相关对象组的变化。 @@ -154,4 +154,3 @@ Finalizers 通常因为特殊原因被添加到资源上，所以强行删除它 on the Kubernetes blog. --> * 在 Kubernetes 博客上阅读[使用 Finalizers 控制删除](/blog/2021/05/14/using-finalizers-to-control-deletion/)。 - diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects.md b/content/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects.md index 1cd32dc950..36c1212fcd 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects.md @@ -64,7 +64,7 @@ Kubernetes 对象是“目标性记录”——一旦创建对象，Kubernetes 这就是 Kubernetes 集群所谓的 **期望状态（Desired State）**。 操作 Kubernetes 对象 —— 无论是创建、修改，或者删除 —— 需要使用 -[Kubernetes API](/zh/docs/concepts/overview/kubernetes-api)。 +[Kubernetes API](/zh-cn/docs/concepts/overview/kubernetes-api)。 比如，当使用 `kubectl` 命令行接口（CLI）时，CLI 会调用必要的 Kubernetes API； 也可以在程序中使用[客户端库](/zh-cn/docs/reference/using-api/client-libraries/)， 来直接调用 Kubernetes API。 @@ -217,7 +217,7 @@ detail the structure of that `.status` field, and its content for each different 另一个对象规约的例子是 StatefulSet API 中的 [`spec` 字段](/docs/reference/kubernetes-api/workload-resources/stateful-set-v1/#StatefulSetSpec)。 对于 StatefulSet 而言，其 `.spec` 字段设置了 StatefulSet 及其期望状态。 -在 StatefulSet 的 `.spec` 内，有一个为 Pod 对象提供的[模板](/zh/docs/concepts/workloads/pods/#pod-templates)。该模板描述了 StatefulSet 控制器为了满足 StatefulSet 规约而要创建的 Pod。 +在 StatefulSet 的 `.spec` 内，有一个为 Pod 对象提供的[模板](/zh-cn/docs/concepts/workloads/pods/#pod-templates)。该模板描述了 StatefulSet 控制器为了满足 StatefulSet 规约而要创建的 Pod。 不同类型的对象可以由不同的 `.status` 信息。API 参考页面给出了 `.status` 字段的详细结构， 以及针对不同类型 API 对象的具体内容。 @@ -228,7 +228,7 @@ detail the structure of that `.status` field, and its content for each different * Learn about [controllers](/docs/concepts/architecture/controller/) in Kubernetes. * [Using the Kubernetes API](/docs/reference/using-api/) explains some more API concepts. --> -* 了解最重要的 Kubernetes 基本对象，例如 [Pod](/zh/docs/concepts/workloads/pods/)。 -* 了解 Kubernetes 中的[控制器](/zh/docs/concepts/architecture/controller/)。 -* [使用 Kubernetes API](/zh/docs/reference/using-api/) 一节解释了一些 API 概念。 +* 了解最重要的 Kubernetes 基本对象，例如 [Pod](/zh-cn/docs/concepts/workloads/pods/)。 +* 了解 Kubernetes 中的[控制器](/zh-cn/docs/concepts/architecture/controller/)。 +* [使用 Kubernetes API](/zh-cn/docs/reference/using-api/) 一节解释了一些 API 概念。 diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/labels.md b/content/zh-cn/docs/concepts/overview/working-with-objects/labels.md index a1840bacbd..650eb02a4e 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/labels.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/labels.md @@ -40,7 +40,7 @@ and CLIs. Non-identifying information should be recorded using [annotations](/docs/concepts/overview/working-with-objects/annotations/). --> 标签能够支持高效的查询和监听操作，对于用户界面和命令行是很理想的。 -应使用[注解](/zh/docs/concepts/overview/working-with-objects/annotations/)记录非识别信息。 +应使用[注解](/zh-cn/docs/concepts/overview/working-with-objects/annotations/)记录非识别信息。 @@ -72,7 +72,7 @@ Example labels: -有一些[常用标签](/zh/docs/concepts/overview/working-with-objects/common-labels/)的例子；你可以任意制定自己的约定。 +有一些[常用标签](/zh-cn/docs/concepts/overview/working-with-objects/common-labels/)的例子；你可以任意制定自己的约定。 请记住，标签的 Key 对于给定对象必须是唯一的。 ## 标签选择算符 {#label-selectors} -与[名称和 UID](/zh/docs/concepts/overview/working-with-objects/names/) 不同， +与[名称和 UID](/zh-cn/docs/concepts/overview/working-with-objects/names/) 不同， 标签不支持唯一性。通常，我们希望许多对象携带相同的标签。 ### 在 API 对象中设置引用 -一些 Kubernetes 对象，例如 [`services`](/zh/docs/concepts/services-networking/service/) -和 [`replicationcontrollers`](/zh/docs/concepts/workloads/controllers/replicationcontroller/) ， +一些 Kubernetes 对象，例如 [`services`](/zh-cn/docs/concepts/services-networking/service/) +和 [`replicationcontrollers`](/zh-cn/docs/concepts/workloads/controllers/replicationcontroller/) ， 也使用了标签选择算符去指定了其他资源的集合，例如 -[pods](/zh/docs/concepts/workloads/pods/)。 +[pods](/zh-cn/docs/concepts/workloads/pods/)。 #### 支持基于集合需求的资源 -比较新的资源，例如 [`Job`](/zh/docs/concepts/workloads/controllers/job/)、 -[`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/)、 -[`Replica Set`](/zh/docs/concepts/workloads/controllers/replicaset/) 和 -[`DaemonSet`](/zh/docs/concepts/workloads/controllers/daemonset/)， +比较新的资源，例如 [`Job`](/zh-cn/docs/concepts/workloads/controllers/job/)、 +[`Deployment`](/zh-cn/docs/concepts/workloads/controllers/deployment/)、 +[`Replica Set`](/zh-cn/docs/concepts/workloads/controllers/replicaset/) 和 +[`DaemonSet`](/zh-cn/docs/concepts/workloads/controllers/daemonset/)， 也支持 _基于集合的_ 需求。 ```yaml @@ -400,5 +400,5 @@ See the documentation on [node selection](/docs/concepts/configuration/assign-po #### 选择节点集 通过标签进行选择的一个用例是确定节点集，方便 Pod 调度。 -有关更多信息，请参阅[选择节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)文档。 +有关更多信息，请参阅[选择节点](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/)文档。 diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/names.md b/content/zh-cn/docs/concepts/overview/working-with-objects/names.md index e7ccb39110..91eb354810 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/names.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/names.md @@ -17,15 +17,15 @@ For example, you can only have one Pod named `myapp-1234` within the same [names 每个 Kubernetes 对象也有一个 [_UID_](#uids) 来标识在整个集群中的唯一性。 -比如，在同一个[名字空间](/zh/docs/concepts/overview/working-with-objects/namespaces/) +比如，在同一个[名字空间](/zh-cn/docs/concepts/overview/working-with-objects/namespaces/) 中有一个名为 `myapp-1234` 的 Pod，但是可以命名一个 Pod 和一个 Deployment 同为 `myapp-1234`。 对于用户提供的非唯一性的属性，Kubernetes 提供了 -[标签（Labels）](/zh/docs/concepts/working-with-objects/labels)和 -[注解（Annotation）](/zh/docs/concepts/overview/working-with-objects/annotations/)机制。 +[标签（Labels）](/zh-cn/docs/concepts/working-with-objects/labels)和 +[注解（Annotation）](/zh-cn/docs/concepts/overview/working-with-objects/annotations/)机制。 @@ -173,7 +173,7 @@ UUIDs 是标准化的，见 ISO/IEC 9834-8 和 ITU-T X.667。 * Read about [labels](/docs/concepts/overview/working-with-objects/labels/) in Kubernetes. * See the [Identifiers and Names in Kubernetes](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md) design document. --> -* 进一步了解 Kubernetes [标签](/zh/docs/concepts/overview/working-with-objects/labels/) +* 进一步了解 Kubernetes [标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/) * 参阅 [Kubernetes 标识符和名称](https://git.k8s.io/community/contributors/design-proposals/architecture/identifiers.md)的设计文档 diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/namespaces.md b/content/zh-cn/docs/concepts/overview/working-with-objects/namespaces.md index 62d47ad897..46c3f35ac9 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/namespaces.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/namespaces.md @@ -49,7 +49,7 @@ resource can only be in one namespace. -名字空间是在多个用户之间划分集群资源的一种方法（通过[资源配额](/zh/docs/concepts/policy/resource-quotas/)）。 +名字空间是在多个用户之间划分集群资源的一种方法（通过[资源配额](/zh-cn/docs/concepts/policy/resource-quotas/)）。 ## 使用名字空间 -名字空间的创建和删除在[名字空间的管理指南文档](/zh/docs/tasks/administer-cluster/namespaces/)描述。 +名字空间的创建和删除在[名字空间的管理指南文档](/zh-cn/docs/tasks/administer-cluster/namespaces/)描述。 ## 名字空间和 DNS -当你创建一个[服务](/zh/docs/concepts/services-networking/service/)时， -Kubernetes 会创建一个相应的 [DNS 条目](/zh/docs/concepts/services-networking/dns-pod-service/)。 +当你创建一个[服务](/zh-cn/docs/concepts/services-networking/service/)时， +Kubernetes 会创建一个相应的 [DNS 条目](/zh-cn/docs/concepts/services-networking/dns-pod-service/)。 因此，所有的名字空间名称都必须是合法的 -[RFC 1123 DNS 标签](/zh/docs/concepts/overview/working-with-objects/names/#dns-label-names)。 +[RFC 1123 DNS 标签](/zh-cn/docs/concepts/overview/working-with-objects/names/#dns-label-names)。 {{< warning >}} 为了缓解这类问题，需要将创建名字空间的权限授予可信的用户。 如果需要，你可以额外部署第三方的安全控制机制，例如以 -[准入 Webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/) +[准入 Webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/) 的形式，阻止用户创建与公共 [TLD](https://data.iana.org/TLD/tlds-alpha-by-domain.txt) 同名的名字空间。 {{< /warning >}} @@ -224,7 +224,7 @@ persistentVolumes, are not in any namespace. --> 大多数 kubernetes 资源（例如 Pod、Service、副本控制器等）都位于某些名字空间中。 但是名字空间资源本身并不在名字空间中。而且底层资源，例如 -[节点](/zh/docs/concepts/architecture/nodes/)和持久化卷不属于任何名字空间。 +[节点](/zh-cn/docs/concepts/architecture/nodes/)和持久化卷不属于任何名字空间。 -* 进一步了解[建立新的名字空间](/zh/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)。 -* 进一步了解[删除名字空间](/zh/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)。 +* 进一步了解[建立新的名字空间](/zh-cn/docs/tasks/administer-cluster/namespaces/#creating-a-new-namespace)。 +* 进一步了解[删除名字空间](/zh-cn/docs/tasks/administer-cluster/namespaces/#deleting-a-namespace)。 diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/object-management.md b/content/zh-cn/docs/concepts/overview/working-with-objects/object-management.md index b1dd99ca60..47c758d267 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/object-management.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/object-management.md @@ -325,10 +325,10 @@ Disadvantages compared to imperative object configuration: - [Kubectl Book](https://kubectl.docs.kubernetes.io) - [Kubernetes API Reference](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) --> -- [使用指令式命令管理 Kubernetes 对象](/zh/docs/tasks/manage-kubernetes-objects/imperative-command/) -- [使用对象配置管理 Kubernetes 对象（指令式）](/zh/docs/tasks/manage-kubernetes-objects/imperative-config/) -- [使用对象配置管理 Kubernetes 对象（声明式）](/zh/docs/tasks/manage-kubernetes-objects/declarative-config/) -- [使用 Kustomize（声明式）管理 Kubernetes 对象](/zh/docs/tasks/manage-kubernetes-objects/kustomization/) +- [使用指令式命令管理 Kubernetes 对象](/zh-cn/docs/tasks/manage-kubernetes-objects/imperative-command/) +- [使用对象配置管理 Kubernetes 对象（指令式）](/zh-cn/docs/tasks/manage-kubernetes-objects/imperative-config/) +- [使用对象配置管理 Kubernetes 对象（声明式）](/zh-cn/docs/tasks/manage-kubernetes-objects/declarative-config/) +- [使用 Kustomize（声明式）管理 Kubernetes 对象](/zh-cn/docs/tasks/manage-kubernetes-objects/kustomization/) - [Kubectl 命令参考](/docs/reference/generated/kubectl/kubectl-commands/) - [Kubectl Book](https://kubectl.docs.kubernetes.io) - [Kubernetes API 参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/) diff --git a/content/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents.md b/content/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents.md index b7f5d0cb71..a02810877f 100644 --- a/content/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents.md +++ b/content/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents.md @@ -31,7 +31,7 @@ to the labels, each `EndpointSlice` that is managed on behalf of a Service has an owner reference. Owner references help different parts of Kubernetes avoid interfering with objects they don’t control. --> -属主关系不同于一些资源使用的[标签和选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)机制。 +属主关系不同于一些资源使用的[标签和选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/)机制。 例如，有一个创建 `EndpointSlice` 对象的 Service， 该 Service 使用标签来让控制平面确定，哪些 `EndpointSlice` 对象属于该 Service。 除开标签，每个代表 Service 所管理的 `EndpointSlice` 都有一个属主引用。 @@ -132,7 +132,7 @@ bound to a Pod. ## 属主关系与 Finalizer {#ownership-and-finalizers} 当你告诉 Kubernetes 删除一个资源，API 服务器允许管理控制器处理该资源的任何 -[Finalizer 规则](/zh/docs/concepts/overview/working-with-objects/finalizers/)。 +[Finalizer 规则](/zh-cn/docs/concepts/overview/working-with-objects/finalizers/)。 {{}} 防止意外删除你的集群所依赖的、用于正常运作的资源。 例如，如果你试图删除一个仍被 Pod 使用的 `PersistentVolume`，该资源不会被立即删除， @@ -150,7 +150,7 @@ specify an orphan deletion policy, Kubernetes adds the `orphan` finalizer so that the controller ignores dependent resources after it deletes the owner object. --> -当你使用[前台或孤立级联删除](/zh/docs/concepts/architecture/garbage-collection/#cascading-deletion)时， +当你使用[前台或孤立级联删除](/zh-cn/docs/concepts/architecture/garbage-collection/#cascading-deletion)时， Kubernetes 也会向属主资源添加 Finalizer。 在前台删除中，会添加 `foreground` Finalizer，这样控制器必须在删除了拥有 `ownerReferences.blockOwnerDeletion=true` 的附属资源后，才能删除属主对象。 @@ -164,6 +164,6 @@ Kubernetes 也会向属主资源添加 Finalizer。 * Learn about [garbage collection](/docs/concepts/architecture/garbage-collection). * Read the API reference for [object metadata](/docs/reference/kubernetes-api/common-definitions/object-meta/#System). --> -* 了解更多关于 [Kubernetes Finalizer](/zh/docs/concepts/overview/working-with-objects/finalizers/)。 -* 了解关于[垃圾收集](/zh/docs/concepts/architecture/garbage-collection)。 +* 了解更多关于 [Kubernetes Finalizer](/zh-cn/docs/concepts/overview/working-with-objects/finalizers/)。 +* 了解关于[垃圾收集](/zh-cn/docs/concepts/architecture/garbage-collection)。 * 阅读[对象元数据](/docs/reference/kubernetes-api/common-definitions/object-meta/#System)的 API 参考文档。 diff --git a/content/zh-cn/docs/concepts/policy/limit-range.md b/content/zh-cn/docs/concepts/policy/limit-range.md index 8412d9e80c..da2560b6a0 100644 --- a/content/zh-cn/docs/concepts/policy/limit-range.md +++ b/content/zh-cn/docs/concepts/policy/limit-range.md @@ -11,7 +11,7 @@ By default, containers run with unbounded [compute resources](/docs/concepts/con With resource quotas, cluster administrators can restrict resource consumption and creation on a {{< glossary_tooltip text="namespace" term_id="namespace" >}} basis. Within a namespace, a Pod or Container can consume as much CPU and memory as defined by the namespace's resource quota. There is a concern that one Pod or Container could monopolize all available resources. A LimitRange is a policy to constrain resource allocations (to Pods or Containers) in a namespace. --> -默认情况下， Kubernetes 集群上的容器运行使用的[计算资源](/zh/docs/concepts/configuration/manage-resources-containers/)没有限制。 +默认情况下， Kubernetes 集群上的容器运行使用的[计算资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/)没有限制。 使用资源配额，集群管理员可以以{{< glossary_tooltip text="名字空间" term_id="namespace" >}}为单位，限制其资源的使用与创建。 在命名空间中，一个 Pod 或 Container 最多能够使用命名空间的资源配额所定义的 CPU 和内存用量。 有人担心，一个 Pod 或 Container 会垄断所有可用的资源。 @@ -53,7 +53,7 @@ The name of a LimitRange object must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). --> LimitRange 的名称必须是合法的 -[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 +[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 关于使用限值的例子，可参看 -- [如何配置每个命名空间最小和最大的 CPU 约束](/zh/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)。 -- [如何配置每个命名空间最小和最大的内存约束](/zh/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)。 -- [如何配置每个命名空间默认的 CPU 申请值和限制值](/zh/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)。 -- [如何配置每个命名空间默认的内存申请值和限制值](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)。 -- [如何配置每个命名空间最小和最大存储使用量](/zh/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage)。 -- [配置每个命名空间的配额的详细例子](/zh/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)。 +- [如何配置每个命名空间最小和最大的 CPU 约束](/zh-cn/docs/tasks/administer-cluster/manage-resources/cpu-constraint-namespace/)。 +- [如何配置每个命名空间最小和最大的内存约束](/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-constraint-namespace/)。 +- [如何配置每个命名空间默认的 CPU 申请值和限制值](/zh-cn/docs/tasks/administer-cluster/manage-resources/cpu-default-namespace/)。 +- [如何配置每个命名空间默认的内存申请值和限制值](/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)。 +- [如何配置每个命名空间最小和最大存储使用量](/zh-cn/docs/tasks/administer-cluster/limit-storage-consumption/#limitrange-to-limit-requests-for-storage)。 +- [配置每个命名空间的配额的详细例子](/zh-cn/docs/tasks/administer-cluster/manage-resources/quota-memory-cpu-namespace/)。 diff --git a/content/zh-cn/docs/concepts/policy/node-resource-managers.md b/content/zh-cn/docs/concepts/policy/node-resource-managers.md index 73f28da383..5636547075 100644 --- a/content/zh-cn/docs/concepts/policy/node-resource-managers.md +++ b/content/zh-cn/docs/concepts/policy/node-resource-managers.md @@ -30,7 +30,7 @@ The main manager, the Topology Manager, is a Kubelet component that co-ordinates The configuration of individual managers is elaborated in dedicated documents: --> 主管理器，也叫拓扑管理器（Topology Manager），是一个 Kubelet 组件， -它通过[策略](/zh/docs/tasks/administer-cluster/topology-manager/)， +它通过[策略](/zh-cn/docs/tasks/administer-cluster/topology-manager/)， 协调全局的资源管理过程。 各个管理器的配置方式会在专项文档中详细阐述： @@ -40,6 +40,6 @@ The configuration of individual managers is elaborated in dedicated documents: - [Device Manager](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager) - [Memory Manager Policies](/docs/tasks/administer-cluster/memory-manager/) --> -- [CPU 管理器策略](/zh/docs/tasks/administer-cluster/cpu-management-policies/) -- [设备管理器](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager) -- [内存管理器策略](/zh/docs/tasks/administer-cluster/memory-manager/) +- [CPU 管理器策略](/zh-cn/docs/tasks/administer-cluster/cpu-management-policies/) +- [设备管理器](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/#device-plugin-integration-with-the-topology-manager) +- [内存管理器策略](/zh-cn/docs/tasks/administer-cluster/memory-manager/) diff --git a/content/zh-cn/docs/concepts/policy/pid-limiting.md b/content/zh-cn/docs/concepts/policy/pid-limiting.md index 85b1c531aa..61fed9674b 100644 --- a/content/zh-cn/docs/concepts/policy/pid-limiting.md +++ b/content/zh-cn/docs/concepts/policy/pid-limiting.md @@ -105,7 +105,7 @@ and limits. However, you specify it in a different way: rather than defining a Pod's resource limit in the `.spec` for a Pod, you configure the limit as a setting on the kubelet. Pod-defined PID limits are not currently supported. --> -PID 限制是与[计算资源](/zh/docs/concepts/configuration/manage-resources-containers/) +PID 限制是与[计算资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/) 请求和限制相辅相成的一种机制。不过，你需要用一种不同的方式来设置这一限制： 你需要将其设置到 kubelet 上而不是在 Pod 的 `.spec` 中为 Pod 设置资源限制。 目前还不支持在 Pod 级别设置 PID 限制。 @@ -146,7 +146,7 @@ gate](/docs/reference/command-line-tools-reference/feature-gates/) `SupportNodePidsLimit` to work. --> 在 Kubernetes 1.20 版本之前，在节点级别通过 PID 资源限制预留 PID 的能力 -需要启用[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +需要启用[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) `SupportNodePidsLimit` 才行。 {{< /note >}} @@ -166,7 +166,7 @@ Kubernetes 允许你限制 Pod 中运行的进程个数。你可以在节点级 而不是为特定的 Pod 来将其设置为资源限制。 每个节点都可以有不同的 PID 限制设置。 要设置限制值，你可以设置 kubelet 的命令行参数 `--pod-max-pids`，或者 -在 kubelet 的[配置文件](/zh/docs/tasks/administer-cluster/kubelet-config-file/) +在 kubelet 的[配置文件](/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/) 中设置 `PodPidsLimit`。 {{< note >}} @@ -176,7 +176,7 @@ the [feature gate](/docs/reference/command-line-tools-reference/feature-gates/) `SupportPodPidsLimit` to work. --> 在 Kubernetes 1.20 版本之前，为 Pod 设置 PID 资源限制的能力需要启用 -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) `SupportNodePidsLimit` 才行。 {{< /note >}} @@ -197,7 +197,7 @@ Eviction signal value is calculated periodically and does NOT enforce the limit. 你可以配置 kubelet 使之在 Pod 行为不正常或者消耗不正常数量资源的时候将其终止。 这一特性称作驱逐。你可以针对不同的驱逐信号 -[配置资源不足的处理](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)。 +[配置资源不足的处理](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/)。 使用 `pid.available` 驱逐信号来配置 Pod 使用的 PID 个数的阈值。 你可以设置硬性的和软性的驱逐策略。不过，即使使用硬性的驱逐策略， 如果 PID 个数增长过快，节点仍然可能因为触及节点 PID 限制而进入一种不稳定状态。 @@ -233,6 +233,6 @@ Pod 行为不正常而没有 PID 可用。 - 关于历史背景，请阅读 [Kubernetes 1.14 中限制进程 ID 以提升稳定性](/blog/2019/04/15/process-id-limiting-for-stability-improvements-in-kubernetes-1.14/) 的博文。 -- 请阅读[为容器管理资源](/zh/docs/concepts/configuration/manage-resources-containers/)。 -- 学习如何[配置资源不足情况的处理](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)。 +- 请阅读[为容器管理资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/)。 +- 学习如何[配置资源不足情况的处理](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/)。 diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/_index.md b/content/zh-cn/docs/concepts/scheduling-eviction/_index.md index de33763b46..3919a6cfa0 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/_index.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/_index.md @@ -35,18 +35,18 @@ of terminating one or more Pods on Nodes. ## 调度 -* [Kubernetes 调度器](/zh/docs/concepts/scheduling-eviction/kube-scheduler/) -* [将 Pods 指派到节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/) -* [Pod 开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/) -* [污点和容忍](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/) -* [调度框架](/zh/docs/concepts/scheduling-eviction/scheduling-framework) -* [调度器的性能调试](/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) -* [扩展资源的资源装箱](/zh/docs/concepts/scheduling-eviction/resource-bin-packing/) +* [Kubernetes 调度器](/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler/) +* [将 Pods 指派到节点](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/) +* [Pod 开销](/zh-cn/docs/concepts/scheduling-eviction/pod-overhead/) +* [污点和容忍](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/) +* [调度框架](/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework) +* [调度器的性能调试](/zh-cn/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) +* [扩展资源的资源装箱](/zh-cn/docs/concepts/scheduling-eviction/resource-bin-packing/) ## Pod 干扰 -* [Pod 优先级和抢占](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/) -* [节点压力驱逐](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/) -* [API发起的驱逐](/zh/docs/concepts/scheduling-eviction/api-eviction/) +* [Pod 优先级和抢占](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/) +* [节点压力驱逐](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/) +* [API发起的驱逐](/zh-cn/docs/concepts/scheduling-eviction/api-eviction/) diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/api-eviction.md b/content/zh-cn/docs/concepts/scheduling-eviction/api-eviction.md index f51af2f678..4b9615951b 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/api-eviction.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/api-eviction.md @@ -30,12 +30,12 @@ on the Pod. 此操作创建一个 `Eviction` 对象，该对象再驱动 API 服务器终止选定的 Pod。 API 发起的驱逐将遵从你的 -[`PodDisruptionBudgets`](/zh/docs/tasks/run-application/configure-pdb/) -和 [`terminationGracePeriodSeconds`](/zh/docs/concepts/workloads/pods/pod-lifecycle#pod-termination) +[`PodDisruptionBudgets`](/zh-cn/docs/tasks/run-application/configure-pdb/) +和 [`terminationGracePeriodSeconds`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle#pod-termination) 配置。 使用 API 创建 Eviction 对象，就像对 Pod 执行策略控制的 -[`DELETE` 操作](/zh/docs/reference/kubernetes-api/workload-resources/pod-v1/#delete-delete-a-pod) +[`DELETE` 操作](/zh-cn/docs/reference/kubernetes-api/workload-resources/pod-v1/#delete-delete-a-pod) ## 调用 Eviction API -你可以使用 [Kubernetes 语言客户端](/zh/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api) +你可以使用 [Kubernetes 语言客户端](/zh-cn/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api) 来访问 Kubernetes API 并创建 `Eviction` 对象。 要执行此操作，你应该用 POST 发出要尝试的请求，类似于下面的示例： @@ -201,6 +201,6 @@ If you notice stuck evictions, try one of the following solutions: * Learn about [Node-pressure Eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/). * Learn about [Pod Priority and Preemption](/docs/concepts/scheduling-eviction/pod-priority-preemption/). --> -* 了解如何使用 [Pod 干扰预算](/zh/docs/tasks/run-application/configure-pdb/) 保护你的应用。 -* 了解[节点压力引发的驱逐](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)。 -* 了解 [Pod 优先级和抢占](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/)。 +* 了解如何使用 [Pod 干扰预算](/zh-cn/docs/tasks/run-application/configure-pdb/) 保护你的应用。 +* 了解[节点压力引发的驱逐](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/)。 +* 了解 [Pod 优先级和抢占](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/)。 diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md b/content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md index 3dcd46b8c4..c6d249d465 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node.md @@ -30,7 +30,7 @@ services that communicate a lot into the same availability zone. 你可以约束一个 {{< glossary_tooltip text="Pod" term_id="pod" >}} 只能在特定的{{< glossary_tooltip text="节点" term_id="node" >}}上运行。 有几种方法可以实现这点，推荐的方法都是用 -[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)来进行选择。 +[标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/)来进行选择。 通常这样的约束不是必须的，因为调度器将自动进行合理的放置（比如，将 Pod 分散到节点上， 而不是将 Pod 放置在可用资源不足的节点上等等）。但在某些情况下，你可能需要进一步控制 Pod 被部署到的节点。例如，确保 Pod 最终落在连接了 SSD 的机器上， @@ -62,10 +62,10 @@ for a list of common node labels. --> ## 节点标签 {#built-in-node-labels} -与很多其他 Kubernetes 对象类似，节点也有[标签](/zh/docs/concepts/overview/working-with-objects/labels/)。 -你可以[手动地添加标签](/zh/docs/tasks/configure-pod-container/assign-pods-nodes/#add-a-label-to-a-node)。 +与很多其他 Kubernetes 对象类似，节点也有[标签](/zh-cn/docs/concepts/overview/working-with-objects/labels/)。 +你可以[手动地添加标签](/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes/#add-a-label-to-a-node)。 Kubernetes 也会为集群中所有节点添加一些标准的标签。 -参见[常用的标签、注解和污点](/zh/docs/reference/labels-annotations-taints/)以了解常见的节点标签。 +参见[常用的标签、注解和污点](/zh-cn/docs/reference/labels-annotations-taints/)以了解常见的节点标签。 {{< note >}} -[`NodeRestriction` 准入插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)防止 +[`NodeRestriction` 准入插件](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#noderestriction)防止 kubelet 使用 `node-restriction.kubernetes.io/` 前缀设置或修改标签。 要使用该标签前缀进行节点隔离： @@ -118,8 +118,8 @@ kubelet 使用 `node-restriction.kubernetes.io/` 前缀设置或修改标签。 2. Add labels with the `node-restriction.kubernetes.io/` prefix to your nodes, and use those labels in your [node selectors](#nodeselector). For example, `example.com.node-restriction.kubernetes.io/fips=true` or `example.com.node-restriction.kubernetes.io/pci-dss=true`. --> -1. 确保你在使用[节点鉴权](/zh/docs/reference/access-authn-authz/node/)机制并且已经启用了 - [NodeRestriction 准入插件](/zh/docs/reference/access-authn-authz/admission-controllers/#noderestriction)。 +1. 确保你在使用[节点鉴权](/zh-cn/docs/reference/access-authn-authz/node/)机制并且已经启用了 + [NodeRestriction 准入插件](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#noderestriction)。 2. 将带有 `node-restriction.kubernetes.io/` 前缀的标签添加到 Node 对象， 然后在[节点选择器](#nodeSelector)中使用这些标签。 例如，`example.com.node-restriction.kubernetes.io/fips=true` 或 @@ -142,7 +142,7 @@ Kubernetes 只会将 Pod 调度到拥有你所指定的每个标签的节点上 See [Assign Pods to Nodes](/docs/tasks/configure-pod-container/assign-pods-nodes) for more information. --> -进一步的信息可参见[将 Pod 指派给节点](/zh/docs/tasks/configure-pod-container/assign-pods-nodes)。 +进一步的信息可参见[将 Pod 指派给节点](/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes)。 `NotIn` 和 `DoesNotExist` 可用来实现节点反亲和性行为。 -你也可以使用[节点污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/) +你也可以使用[节点污点](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/) 将 Pod 从特定节点上驱逐。 {{< note >}} @@ -279,7 +279,7 @@ satisfied. See [Assign Pods to Nodes using Node Affinity](/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/) for more information. --> -参阅[使用节点亲和性来为 Pod 指派节点](/zh/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)， +参阅[使用节点亲和性来为 Pod 指派节点](/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)， 以了解进一步的信息。 -在配置多个[调度方案](/zh/docs/reference/scheduling/config/#multiple-profiles)时， +在配置多个[调度方案](/zh-cn/docs/reference/scheduling/config/#multiple-profiles)时， 你可以将某个方案与节点亲和性关联起来，如果某个调度方案仅适用于某组特殊的节点时， 这样做是很有用的。 -要实现这点，可以在[调度器配置](/zh/docs/reference/scheduling/config/)中为 -[`NodeAffinity` 插件](/zh/docs/reference/scheduling/config/#scheduling-plugins)的 +要实现这点，可以在[调度器配置](/zh-cn/docs/reference/scheduling/config/)中为 +[`NodeAffinity` 插件](/zh-cn/docs/reference/scheduling/config/#scheduling-plugins)的 `args` 字段添加 `addedAffinity`。例如： ```yaml @@ -397,7 +397,7 @@ does not support scheduling profiles. When the DaemonSet controller creates Pods, the default Kubernetes scheduler places those Pods and honors any `nodeAffinity` rules in the DaemonSet controller. --> -DaemonSet 控制器[为 DaemonSet 创建 Pods](/zh/docs/concepts/workloads/controllers/daemonset/#scheduled-by-default-scheduler)， +DaemonSet 控制器[为 DaemonSet 创建 Pods](/zh-cn/docs/concepts/workloads/controllers/daemonset/#scheduled-by-default-scheduler)， 但该控制器不理会调度方案。 DaemonSet 控制器创建 Pod 时，默认的 Kubernetes 调度器负责放置 Pod， 并遵从 DaemonSet 控制器中奢侈的 `nodeAffinity` 规则。 @@ -434,7 +434,7 @@ Kubernetes, so Pod labels also implicitly have namespaces. Any label selectors for Pod labels should specify the namespaces in which Kubernetes should look for those labels. --> -你通过[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors) +你通过[标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors) 的形式来表达规则（Y），并可根据需要指定选关联的名字空间列表。 Pod 在 Kubernetes 中是名字空间作用域的对象，因此 Pod 的标签也隐式地具有名字空间属性。 针对 Pod 标签的所有标签选择算符都要指定名字空间，Kubernetes @@ -446,7 +446,7 @@ the node label that the system uses to denote the domain. For examples, see [Well-Known Labels, Annotations and Taints](/docs/reference/labels-annotations-taints/). --> 你会通过 `topologyKey` 来表达拓扑域（X）的概念，其取值是系统用来标示域的节点标签键。 -相关示例可参见[常用标签、注解和污点](/zh/docs/reference/labels-annotations-taints/)。 +相关示例可参见[常用标签、注解和污点](/zh-cn/docs/reference/labels-annotations-taints/)。 {{< note >}} -参阅 [ZooKeeper 教程](/zh/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure) +参阅 [ZooKeeper 教程](/zh-cn/docs/tutorials/stateful-application/zookeeper/#tolerating-node-failure) 了解一个 StatefulSet 的示例，该 StatefulSet 配置了反亲和性以实现高可用， 所使用的是与此例相同的技术。 @@ -810,11 +810,11 @@ The above Pod will only run on the node `kube-01`. * Learn how to use [nodeSelector](/docs/tasks/configure-pod-container/assign-pods-nodes/). * Learn how to use [affinity and anti-affinity](/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/). --> -* 进一步阅读[污点与容忍度](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)文档。 +* 进一步阅读[污点与容忍度](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/)文档。 * 阅读[节点亲和性](https://git.k8s.io/community/contributors/design-proposals/scheduling/nodeaffinity.md) 和[Pod 间亲和性与反亲和性](https://git.k8s.io/community/contributors/design-proposals/scheduling/podaffinity.md) 的设计文档。 -* 了解[拓扑管理器](/zh/docs/tasks/administer-cluster/topology-manager/)如何参与节点层面资源分配决定。 -* 了解如何使用 [nodeSelector](/zh/docs/tasks/configure-pod-container/assign-pods-nodes/)。 -* 了解如何使用[亲和性和反亲和性](/zh/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)。 +* 了解[拓扑管理器](/zh-cn/docs/tasks/administer-cluster/topology-manager/)如何参与节点层面资源分配决定。 +* 了解如何使用 [nodeSelector](/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes/)。 +* 了解如何使用[亲和性和反亲和性](/zh-cn/docs/tasks/configure-pod-container/assign-pods-nodes-using-node-affinity/)。 diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler.md b/content/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler.md index 30791e6249..07da211616 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler.md @@ -57,7 +57,7 @@ is the default scheduler for Kubernetes and runs as part of the kube-scheduler is designed so that, if you want and need to, you can write your own scheduling component and use that instead. --> -[kube-scheduler](/zh/docs/reference/command-line-tools-reference/kube-scheduler/) +[kube-scheduler](/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler/) 是 Kubernetes 集群的默认调度器，并且是集群 {{< glossary_tooltip text="控制面" term_id="control-plane" >}} 的一部分。 如果你真的希望或者有这方面的需求，kube-scheduler 在设计上是允许 @@ -101,7 +101,7 @@ policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference, and so on. --> 在做调度决定时需要考虑的因素包括：单独和整体的资源请求、硬件/软件/策略限制、 -亲和以及反亲和要求、数据局域性、负载间的干扰等等。 +亲和以及反亲和要求、数据局部性、负载间的干扰等等。 -1. [调度策略](/zh/docs/reference/scheduling/policies) 允许你配置过滤的 _断言(Predicates)_ +1. [调度策略](/zh-cn/docs/reference/scheduling/policies) 允许你配置过滤的 _断言(Predicates)_ 和打分的 _优先级(Priorities)_ 。 -2. [调度配置](/zh/docs/reference/scheduling/config/#profiles) 允许你配置实现不同调度阶段的插件， +2. [调度配置](/zh-cn/docs/reference/scheduling/config/#profiles) 允许你配置实现不同调度阶段的插件， 包括：`QueueSort`, `Filter`, `Score`, `Bind`, `Reserve`, `Permit` 等等。 你也可以配置 kube-scheduler 运行不同的配置文件。 @@ -178,10 +178,10 @@ of the scheduler: * Learn about [topology management policies](/docs/tasks/administer-cluster/topology-manager/) * Learn about [Pod Overhead](/docs/concepts/scheduling-eviction/pod-overhead/) --> -* 阅读关于 [调度器性能调优](/zh/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) -* 阅读关于 [Pod 拓扑分布约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/) -* 阅读关于 kube-scheduler 的 [参考文档](/zh/docs/reference/command-line-tools-reference/kube-scheduler/) -* 阅读 [kube-scheduler 配置参考 (v1beta3)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta3/) -* 了解关于 [配置多个调度器](/zh/docs/tasks/extend-kubernetes/configure-multiple-schedulers/) 的方式 -* 了解关于 [拓扑结构管理策略](/zh/docs/tasks/administer-cluster/topology-manager/) -* 了解关于 [Pod 额外开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/) +* 阅读关于 [调度器性能调优](/zh-cn/docs/concepts/scheduling-eviction/scheduler-perf-tuning/) +* 阅读关于 [Pod 拓扑分布约束](/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints/) +* 阅读关于 kube-scheduler 的 [参考文档](/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler/) +* 阅读 [kube-scheduler 配置参考 (v1beta3)](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/) +* 了解关于 [配置多个调度器](/zh-cn/docs/tasks/extend-kubernetes/configure-multiple-schedulers/) 的方式 +* 了解关于 [拓扑结构管理策略](/zh-cn/docs/tasks/administer-cluster/topology-manager/) +* 了解关于 [Pod 额外开销](/zh-cn/docs/concepts/scheduling-eviction/pod-overhead/) diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction.md b/content/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction.md index 810324c0c2..8a0910315e 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction.md @@ -128,9 +128,9 @@ memory is reclaimable under pressure. --> `memory.available` 的值来自 cgroupfs，而不是像 `free -m` 这样的工具。 这很重要，因为 `free -m` 在容器中不起作用，如果用户使用 -[节点可分配资源](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) +[节点可分配资源](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) 这一功能特性，资源不足的判定是基于 CGroup 层次结构中的用户 Pod 所处的局部及 CGroup 根节点作出的。 -这个[脚本](/zh/examples/admin/resource/memory-available.sh) +这个[脚本](/zh-cn/examples/admin/resource/memory-available.sh) 重现了 kubelet 为计算 `memory.available` 而执行的相同步骤。 kubelet 在其计算中排除了 inactive_file（即非活动 LRU 列表上基于文件来虚拟的内存的字节数）， 因为它假定在压力下内存是可回收的。 @@ -161,7 +161,7 @@ For a list of the deprecated features, see [kubelet garbage collection deprecati --> 一些 kubelet 垃圾收集功能已被弃用，以支持驱逐。 有关已弃用功能的列表，请参阅 -[kubelet 垃圾收集弃用](/zh/docs/concepts/cluster-administration/kubelet-garbage-collection/#deprecation)。 +[kubelet 垃圾收集弃用](/zh-cn/docs/concepts/cluster-administration/kubelet-garbage-collection/#deprecation)。 {{}} 你可以使用 `--eviction-minimum-reclaim` 标志或 -[kubelet 配置文件](/zh/docs/tasks/administer-cluster/kubelet-config-file/) +[kubelet 配置文件](/zh-cn/docs/tasks/administer-cluster/kubelet-config-file/) 为每个资源配置最小回收量。 当 kubelet 注意到某个资源耗尽时，它会继续回收该资源，直到回收到你所指定的数量为止。 @@ -772,7 +772,7 @@ to estimate or measure an optimal memory limit value for that container. * Check out the [Eviction API](/docs/reference/generated/kubernetes-api/{{}}/#create-eviction-pod-v1-core) --> * 了解 [API 发起的驱逐](/docs/reference/generated/kubernetes-api/v1.23/) -* 了解 [Pod 优先级和驱逐](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/) +* 了解 [Pod 优先级和驱逐](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/) * 了解 [PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/) -* 了解[服务质量](/zh/docs/tasks/configure-pod-container/quality-service-pod/)（QoS） +* 了解[服务质量](/zh-cn/docs/tasks/configure-pod-container/quality-service-pod/)（QoS） * 查看[驱逐 API](/docs/reference/generated/kubernetes-api/{{}}/#create-eviction-pod-v1-core) diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/pod-overhead.md b/content/zh-cn/docs/concepts/scheduling-eviction/pod-overhead.md index 17951dd91e..046a27cd99 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/pod-overhead.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/pod-overhead.md @@ -40,8 +40,8 @@ time according to the overhead associated with the Pod's [RuntimeClass](/docs/concepts/containers/runtime-class/). --> -在 Kubernetes 中，Pod 的开销是根据与 Pod 的 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/) -相关联的开销在[准入](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)时设置的。 +在 Kubernetes 中，Pod 的开销是根据与 Pod 的 [RuntimeClass](/zh-cn/docs/concepts/containers/runtime-class/) +相关联的开销在[准入](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#what-are-admission-webhooks)时设置的。 -在准入阶段 RuntimeClass [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/) +在准入阶段 RuntimeClass [准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/) 更新工作负载的 PodSpec 以包含 RuntimeClass 中定义的 `overhead`。如果 PodSpec 中已定义该字段，该 Pod 将会被拒绝。 在这个例子中，由于只指定了 RuntimeClass 名称，所以准入控制器更新了 Pod，使之包含 `overhead`。 @@ -154,7 +154,7 @@ map[cpu:250m memory:120Mi] If a [ResourceQuota](/docs/concepts/policy/resource-quotas/) is defined, the sum of container requests as well as the `overhead` field are counted. --> -如果定义了 [ResourceQuata](/zh/docs/concepts/policy/resource-quotas/), +如果定义了 [ResourceQuata](/zh-cn/docs/concepts/policy/resource-quotas/), 则容器请求的总量以及 `overhead` 字段都将计算在内。 -* 学习更多关于 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/) 的信息 +* 学习更多关于 [RuntimeClass](/zh-cn/docs/concepts/containers/runtime-class/) 的信息 * 阅读 [PodOverhead 设计](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/688-pod-overhead)增强建议以获取更多上下文 diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption.md b/content/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption.md index f22065f8f9..afa224896a 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption.md @@ -23,7 +23,7 @@ importance of a Pod relative to other Pods. If a Pod cannot be scheduled, the scheduler tries to preempt (evict) lower priority Pods to make scheduling of the pending Pod possible. --> -[Pod](/zh/docs/concepts/workloads/pods/) 可以有 _优先级_。 +[Pod](/zh-cn/docs/concepts/workloads/pods/) 可以有 _优先级_。 优先级表示一个 Pod 相对于其他 Pod 的重要性。 如果一个 Pod 无法被调度，调度程序会尝试抢占（驱逐）较低优先级的 Pod， 以使悬决 Pod 可以被调度。 @@ -44,7 +44,7 @@ for details. 在一个并非所有用户都是可信的集群中，恶意用户可能以最高优先级创建 Pod， 导致其他 Pod 被驱逐或者无法被调度。 管理员可以使用 ResourceQuota 来阻止用户创建高优先级的 Pod。 -参见[默认限制优先级消费](/zh/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default)。 +参见[默认限制优先级消费](/zh-cn/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default)。 {{< /warning >}} @@ -82,7 +82,7 @@ These are common classes and are used to [ensure that critical components are al --> Kubernetes 已经提供了 2 个 PriorityClass： `system-cluster-critical` 和 `system-node-critical`。 -这些是常见的类，用于[确保始终优先调度关键组件](/zh/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)。 +这些是常见的类，用于[确保始终优先调度关键组件](/zh-cn/docs/tasks/administer-cluster/guaranteed-scheduling-critical-addon-pods/)。 {{< /note >}} #### 支持 PodDisruptionBudget，但不保证 -[PodDisruptionBudget](/zh/docs/concepts/workloads/pods/disruptions/) +[PodDisruptionBudget](/zh-cn/docs/concepts/workloads/pods/disruptions/) (PDB) 允许多副本应用程序的所有者限制因自愿性质的干扰而同时终止的 Pod 数量。 Kubernetes 在抢占 Pod 时支持 PDB，但对 PDB 的支持是基于尽力而为原则的。 调度器会尝试寻找不会因被抢占而违反 PDB 的牺牲者，但如果没有找到这样的牺牲者， @@ -639,7 +639,7 @@ exceeding its requests, it won't be evicted. Another Pod with higher priority that exceeds its requests may be evicted. --> kubelet 使用优先级来确定 -[节点压力驱逐](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/) Pod 的顺序。 +[节点压力驱逐](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/) Pod 的顺序。 你可以使用 QoS 类来估计 Pod 最有可能被驱逐的顺序。kubelet 根据以下因素对 Pod 进行驱逐排名： 1. 对紧俏资源的使用是否超过请求值 @@ -647,7 +647,7 @@ kubelet 使用优先级来确定 1. 相对于请求的资源使用量 有关更多详细信息，请参阅 -[kubelet 驱逐时 Pod 的选择](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/#pod-selection-for-kubelet-eviction)。 +[kubelet 驱逐时 Pod 的选择](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/#pod-selection-for-kubelet-eviction)。 当某 Pod 的资源用量未超过其请求时，kubelet 节点压力驱逐不会驱逐该 Pod。 如果优先级较低的 Pod 没有超过其请求，则不会被驱逐。 @@ -663,7 +663,7 @@ kubelet 使用优先级来确定 * Learn about [Node-pressure Eviction](/docs/concepts/scheduling-eviction/node-pressure-eviction/) --> * 阅读有关将 ResourceQuota 与 PriorityClass 结合使用的信息： - [默认限制优先级消费](/zh/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default) -* 了解 [Pod 干扰](/zh/docs/concepts/workloads/pods/disruptions/) + [默认限制优先级消费](/zh-cn/docs/concepts/policy/resource-quotas/#limit-priority-class-consumption-by-default) +* 了解 [Pod 干扰](/zh-cn/docs/concepts/workloads/pods/disruptions/) * 了解 [API 发起的驱逐](/docs/reference/generated/kubernetes-api/v1.23/) -* 了解[节点压力驱逐](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/) +* 了解[节点压力驱逐](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/) diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md b/content/zh-cn/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md index dd6e1da395..6ceffe8461 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/scheduler-perf-tuning.md @@ -23,7 +23,7 @@ is the Kubernetes default scheduler. It is responsible for placement of Pods on Nodes in a cluster. --> 作为 kubernetes 集群的默认调度器， -[kube-scheduler](/zh/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler) +[kube-scheduler](/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler) 主要负责将 Pod 调度到集群的 Node 上。 -要修改这个值，先编辑 [kube-scheduler 的配置文件](/zh/docs/reference/config-api/kube-scheduler-config.v1beta3/) +要修改这个值，先编辑 [kube-scheduler 的配置文件](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/) 然后重启调度器。 大多数情况下，这个配置文件是 `/etc/kubernetes/config/kube-scheduler.yaml`。 @@ -128,7 +128,7 @@ stops searching for more feasible nodes and moves on to the kube-scheduler 会将它转换为节点数的整数值。在调度期间，如果 kube-scheduler 已确认的可调度节点数足以超过了配置的百分比数量， kube-scheduler 将停止继续查找可调度节点并继续进行 -[打分阶段](/zh/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)。 +[打分阶段](/zh-cn/docs/concepts/scheduling-eviction/kube-scheduler/#kube-scheduler-implementation)。 -* 参见 [kube-scheduler 配置参考 (v1beta3)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta3/) +* 参见 [kube-scheduler 配置参考 (v1beta3)](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/) diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework.md b/content/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework.md index 9e0fee45ac..80cefde2e1 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/scheduling-framework.md @@ -451,7 +451,7 @@ enabled by default. --> 你可以在调度器配置中启用或禁用插件。 如果你在使用 Kubernetes v1.18 或更高版本，大部分调度 -[插件](/zh/docs/reference/scheduling/config/#scheduling-plugins) +[插件](/zh-cn/docs/reference/scheduling/config/#scheduling-plugins) 都在使用中且默认启用。 如果你正在使用 Kubernetes v1.18 或更高版本，你可以将一组插件设置为 一个调度器配置文件，然后定义不同的配置文件来满足各类工作负载。 -了解更多关于[多配置文件](/zh/docs/reference/scheduling/config/#multiple-profiles)。 +了解更多关于[多配置文件](/zh-cn/docs/reference/scheduling/config/#multiple-profiles)。 diff --git a/content/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration.md b/content/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration.md index 1e02d72fdd..53e60e1cb8 100644 --- a/content/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration.md +++ b/content/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration.md @@ -11,37 +11,38 @@ is a property of {{< glossary_tooltip text="Pods" term_id="pod" >}} that *attrac a set of {{< glossary_tooltip text="nodes" term_id="node" >}} (either as a preference or a hard requirement). _Taints_ are the opposite -- they allow a node to repel a set of pods. --> -[_节点亲和性_](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) +[节点亲和性](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) 是 {{< glossary_tooltip text="Pod" term_id="pod" >}} 的一种属性，它使 Pod 被吸引到一类特定的{{< glossary_tooltip text="节点" term_id="node" >}} （这可能出于一种偏好，也可能是硬性要求）。 -_污点_（Taint）则相反——它使节点能够排斥一类特定的 Pod。 +**污点（Taint）** 则相反——它使节点能够排斥一类特定的 Pod。 -容忍度（Toleration）是应用于 Pod 上的，允许（但并不要求）Pod -调度到带有与之匹配的污点的节点上。 +**容忍度（Toleration）** 是应用于 Pod 上的。容忍度允许调度器调度带有对应污点的节点。 +容忍度允许调度但并不保证调度：作为其功能的一部分， +调度器也会[评估其他参数](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/)。 污点和容忍度（Toleration）相互配合，可以用来避免 Pod 被分配到不合适的节点上。 -每个节点上都可以应用一个或多个污点，这表示对于那些不能容忍这些污点的 Pod，是不会被该节点接受的。 +每个节点上都可以应用一个或多个污点，这表示对于那些不能容忍这些污点的 Pod， +是不会被该节点接受的。 -## 概念 - +## 概念 {#concepts} + 你可以使用命令 [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint) 给节点增加一个污点。比如， ```shell @@ -52,14 +53,7 @@ kubectl taint nodes node1 key1=value1:NoSchedule places a taint on node `node1`. The taint has key `key1`, value `value1`, and taint effect `NoSchedule`. This means that no pod will be able to schedule onto `node1` unless it has a matching toleration. -```shell -kubectl taint nodes node1 key:NoSchedule -``` - To remove the taint added by the command above, you can run: -```shell -kubectl taint nodes node1 key1=value1:NoSchedule- -``` --> 给节点 `node1` 增加一个污点，它的键名是 `key1`，键值是 `value1`，效果是 `NoSchedule`。 这表示只有拥有和这个污点相匹配的容忍度的 Pod 才能够被分配到 `node1` 这个节点。 @@ -75,9 +69,9 @@ You specify a toleration for a pod in the PodSpec. Both of the following tolerat taint created by the `kubectl taint` line above, and thus a pod with either toleration would be able to schedule onto `node1`: --> -你可以在 PodSpec 中定义 Pod 的容忍度。 +你可以在 Pod 规约中为 Pod 设置容忍度。 下面两个容忍度均与上面例子中使用 `kubectl taint` 命令创建的污点相匹配， -因此如果一个 Pod 拥有其中的任何一个容忍度都能够被分配到 `node1` ： +因此如果一个 Pod 拥有其中的任何一个容忍度，都能够被调度到 `node1` ： ```yaml tolerations: @@ -117,6 +111,7 @@ A toleration "matches" a taint if the keys are the same and the effects are the * 如果 `operator` 是 `Exists` （此时容忍度不能指定 `value`），或者 * 如果 `operator` 是 `Equal` ，则它们的 `value` 应该相等 +{{< note >}} -{{< note >}} 存在两种特殊情况： -如果一个容忍度的 `key` 为空且 operator 为 `Exists`， -表示这个容忍度与任意的 key 、value 和 effect 都匹配，即这个容忍度能容忍任意 taint。 +如果一个容忍度的 `key` 为空且 `operator` 为 `Exists`， +表示这个容忍度与任意的 key、value 和 effect 都匹配，即这个容忍度能容忍任何污点。 如果 `effect` 为空，则可以与所有键名 `key1` 的效果相匹配。 {{< /note >}} @@ -141,7 +135,7 @@ pod that does not tolerate the taint on the node, but it is not required. The th `NoExecute`, described later. --> 上述例子中 `effect` 使用的值为 `NoSchedule`，你也可以使用另外一个值 `PreferNoSchedule`。 -这是“优化”或“软”版本的 `NoSchedule` —— 系统会 *尽量* 避免将 Pod 调度到存在其不能容忍污点的节点上， +这是“优化”或“软”版本的 `NoSchedule` —— 系统会 **尽量** 避免将 Pod 调度到存在其不能容忍污点的节点上， 但这不是强制的。`effect` 的值还可以设置为 `NoExecute`，下文会详细描述这个值。 -* 如果未被过滤的污点中存在至少一个 effect 值为 `NoSchedule` 的污点， - 则 Kubernetes 不会将 Pod 分配到该节点。 -* 如果未被过滤的污点中不存在 effect 值为 `NoSchedule` 的污点， +* 如果未被忽略的污点中存在至少一个 effect 值为 `NoSchedule` 的污点， + 则 Kubernetes 不会将 Pod 调度到该节点。 +* 如果未被忽略的污点中不存在 effect 值为 `NoSchedule` 的污点， 但是存在 effect 值为 `PreferNoSchedule` 的污点， - 则 Kubernetes 会 *尝试* 不将 Pod 分配到该节点。 -* 如果未被过滤的污点中存在至少一个 effect 值为 `NoExecute` 的污点， - 则 Kubernetes 不会将 Pod 分配到该节点（如果 Pod 还未在节点上运行）， + 则 Kubernetes 会 **尝试** 不将 Pod 调度到该节点。 +* 如果未被忽略的污点中存在至少一个 effect 值为 `NoExecute` 的污点， + 则 Kubernetes 不会将 Pod 调度到该节点（如果 Pod 还未在节点上运行）， 或者将 Pod 从该节点驱逐（如果 Pod 已经在节点上运行）。 -在这种情况下，上述 Pod 不会被分配到上述节点，因为其没有容忍度和第三个污点相匹配。 +在这种情况下，上述 Pod 不会被调度到上述节点，因为其没有容忍度和第三个污点相匹配。 但是如果在给节点添加上述污点之前，该 Pod 已经在上述节点运行， 那么它还可以继续运行在该节点上，因为第三个污点是三个污点中唯一不能被这个 Pod 容忍的。 @@ -219,8 +213,7 @@ an optional `tolerationSeconds` field that dictates how long the pod will stay b to the node after the taint is added. For example, --> 通常情况下，如果给一个节点添加了一个 effect 值为 `NoExecute` 的污点， -则任何不能忍受这个污点的 Pod 都会马上被驱逐， -任何可以忍受这个污点的 Pod 都不会被驱逐。 +则任何不能忍受这个污点的 Pod 都会马上被驱逐，任何可以忍受这个污点的 Pod 都不会被驱逐。 但是，如果 Pod 存在一个 effect 值为 `NoExecute` 的容忍度指定了可选属性 `tolerationSeconds` 的值，则表示在给节点添加了上述污点之后， Pod 还能继续在节点上运行的时间。例如， @@ -245,14 +238,14 @@ taint is removed before that time, the pod will not be evicted. -## 使用例子 - -通过污点和容忍度，可以灵活地让 Pod **避开** 某些节点或者将 Pod 从某些节点驱逐。下面是几个使用例子： +## 使用例子 {#example-use-cases} + +通过污点和容忍度，可以灵活地让 Pod **避开**某些节点或者将 Pod 从某些节点驱逐。 +下面是几个使用例子： * **专用节点**：如果你想将某些节点专门分配给特定的一组用户使用，你可以给这些节点添加一个污点（即， `kubectl taint nodes nodename dedicated=groupName:NoSchedule`）， - 然后给这组用户的 Pod 添加一个相对应的 toleration（通过编写一个自定义的 - [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)，很容易就能做到）。 - 拥有上述容忍度的 Pod 就能够被分配到上述专用节点，同时也能够被分配到集群中的其它节点。 - 如果你希望这些 Pod 只能被分配到上述专用节点，那么你还需要给这些专用节点另外添加一个和上述 - 污点类似的 label （例如：`dedicated=groupName`），同时 还要在上述准入控制器中给 Pod - 增加节点亲和性要求上述 Pod 只能被分配到添加了 `dedicated=groupName` 标签的节点上。 + 然后给这组用户的 Pod 添加一个相对应的容忍度 + （通过编写一个自定义的[准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/)， + 很容易就能做到）。 + 拥有上述容忍度的 Pod 就能够被调度到上述专用节点，同时也能够被调度到集群中的其它节点。 + 如果你希望这些 Pod 只能被调度到上述专用节点， + 那么你还需要给这些专用节点另外添加一个和上述污点类似的 label （例如：`dedicated=groupName`）， + 同时还要在上述准入控制器中给 Pod 增加节点亲和性要求，要求上述 Pod 只能被调度到添加了 + `dedicated=groupName` 标签的节点上。 * **配备了特殊硬件的节点**：在部分节点配备了特殊硬件（比如 GPU）的集群中， - 我们希望不需要这类硬件的 Pod 不要被分配到这些特殊节点，以便为后继需要这类硬件的 Pod 保留资源。 - 要达到这个目的，可以先给配备了特殊硬件的节点添加 taint + 我们希望不需要这类硬件的 Pod 不要被调度到这些特殊节点，以便为后继需要这类硬件的 Pod 保留资源。 + 要达到这个目的，可以先给配备了特殊硬件的节点添加污点 （例如 `kubectl taint nodes nodename special=true:NoSchedule` 或 `kubectl taint nodes nodename special=true:PreferNoSchedule`)， - 然后给使用了这类特殊硬件的 Pod 添加一个相匹配的 toleration。 + 然后给使用了这类特殊硬件的 Pod 添加一个相匹配的容忍度。 和专用节点的例子类似，添加这个容忍度的最简单的方法是使用自定义 - [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)。 - 比如，我们推荐使用[扩展资源](/zh/docs/concepts/configuration/manage-resources-containers/#extended-resources) + [准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/)。 + 比如，我们推荐使用[扩展资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/#extended-resources) 来表示特殊硬件，给配置了特殊硬件的节点添加污点时包含扩展资源名称， - 然后运行一个 [ExtendedResourceToleration](/zh/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration) - 准入控制器。此时，因为节点已经被设置污点了，没有对应容忍度的 Pod - 不会被调度到这些节点。但当你创建一个使用了扩展资源的 Pod 时， - `ExtendedResourceToleration` 准入控制器会自动给 Pod 加上正确的容忍度， - 这样 Pod 就会被自动调度到这些配置了特殊硬件件的节点上。 - 这样就能够确保这些配置了特殊硬件的节点专门用于运行需要使用这些硬件的 Pod， + 然后运行一个 [ExtendedResourceToleration](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#extendedresourcetoleration) + 准入控制器。此时，因为节点已经被设置污点了，没有对应容忍度的 Pod 不会被调度到这些节点。 + 但当你创建一个使用了扩展资源的 Pod 时，`ExtendedResourceToleration` 准入控制器会自动给 + Pod 加上正确的容忍度，这样 Pod 就会被自动调度到这些配置了特殊硬件的节点上。 + 这种方式能够确保配置了特殊硬件的节点专门用于运行需要这些硬件的 Pod， 并且你无需手动给这些 Pod 添加容忍度。 -* **基于污点的驱逐**: 这是在每个 Pod 中配置的在节点出现问题时的驱逐行为，接下来的章节会描述这个特性。 +* **基于污点的驱逐**: 这是在每个 Pod 中配置的在节点出现问题时的驱逐行为， + 接下来的章节会描述这个特性。 -前文提到过污点的 effect 值 `NoExecute` 会影响已经在节点上运行的 Pod +前文提到过污点的效果值 `NoExecute` 会影响已经在节点上运行的 Pod，如下 - * 如果 Pod 不能忍受 effect 值为 `NoExecute` 的污点，那么 Pod 将马上被驱逐 - * 如果 Pod 能够忍受 effect 值为 `NoExecute` 的污点，但是在容忍度定义中没有指定 - `tolerationSeconds`，则 Pod 还会一直在这个节点上运行。 - * 如果 Pod 能够忍受 effect 值为 `NoExecute` 的污点，而且指定了 `tolerationSeconds`， - 则 Pod 还能在这个节点上继续运行这个指定的时间长度。 +* 如果 Pod 不能忍受这类污点，Pod 会马上被驱逐 +* 如果 Pod 能够忍受这类污点，但是在容忍度定义中没有指定 `tolerationSeconds`， + 则 Pod 还会一直在这个节点上运行。 +* 如果 Pod 能够忍受这类污点，而且指定了 `tolerationSeconds`， + 则 Pod 还能在这个节点上继续运行这个指定的时间长度。 +--> 当某种条件为真时，节点控制器会自动给节点添加一个污点。当前内置的污点包括： - * `node.kubernetes.io/not-ready`：节点未准备好。这相当于节点状态 `Ready` 的值为 "`False`"。 - * `node.kubernetes.io/unreachable`：节点控制器访问不到节点. 这相当于节点状态 `Ready` 的值为 "`Unknown`"。 - * `node.kubernetes.io/memory-pressure`：节点存在内存压力。 - * `node.kubernetes.io/disk-pressure`：节点存在磁盘压力。 - * `node.kubernetes.io/pid-pressure`: 节点的 PID 压力。 - * `node.kubernetes.io/network-unavailable`：节点网络不可用。 - * `node.kubernetes.io/unschedulable`: 节点不可调度。 - * `node.cloudprovider.kubernetes.io/uninitialized`：如果 kubelet 启动时指定了一个 "外部" 云平台驱动， +* `node.kubernetes.io/not-ready`：节点未准备好。这相当于节点状况 `Ready` 的值为 "`False`"。 +* `node.kubernetes.io/unreachable`：节点控制器访问不到节点. 这相当于节点状况 `Ready` + 的值为 "`Unknown`"。 +* `node.kubernetes.io/memory-pressure`：节点存在内存压力。 +* `node.kubernetes.io/disk-pressure`：节点存在磁盘压力。 +* `node.kubernetes.io/pid-pressure`: 节点的 PID 压力。 +* `node.kubernetes.io/network-unavailable`：节点网络不可用。 +* `node.kubernetes.io/unschedulable`: 节点不可调度。 +* `node.cloudprovider.kubernetes.io/uninitialized`：如果 kubelet 启动时指定了一个“外部”云平台驱动， 它将给当前节点添加一个污点将其标志为不可用。在 cloud-controller-manager 的一个控制器初始化这个节点后，kubelet 将删除这个污点。 @@ -384,37 +380,35 @@ In case a node is to be evicted, the node controller or the kubelet adds relevan with `NoExecute` effect. If the fault condition returns to normal the kubelet or node controller can remove the relevant taint(s). --> -在节点被驱逐时，节点控制器或者 kubelet 会添加带有 `NoExecute` 效应的相关污点。 +在节点被驱逐时，节点控制器或者 kubelet 会添加带有 `NoExecute` 效果的相关污点。 如果异常状态恢复正常，kubelet 或节点控制器能够移除相关的污点。 - {{< note >}} -为了保证由于节点问题引起的 Pod 驱逐 -[速率限制](/zh/docs/concepts/architecture/nodes/)行为正常， -系统实际上会以限定速率的方式添加污点。在像主控节点与工作节点间通信中断等场景下， -这样做可以避免 Pod 被大量驱逐。 + +控制面会限制向节点添加新污点的速率。这一速率限制可以管理多个节点同时不可达时 +（例如出现网络中断的情况），可能触发的驱逐的数量。 {{< /note >}} -使用这个功能特性，结合 `tolerationSeconds`，Pod 就可以指定当节点出现一个 -或全部上述问题时还将在这个节点上运行多长的时间。 +你可以为 Pod 设置 `tolerationSeconds`，以指定当节点失效或者不响应时， +Pod 维系与该节点间绑定关系的时长。 -比如，一个使用了很多本地状态的应用程序在网络断开时，仍然希望停留在当前节点上运行一段较长的时间， -愿意等待网络恢复以避免被驱逐。在这种情况下，Pod 的容忍度可能是下面这样的： +比如，你可能希望在出现网络分裂事件时，对于一个与节点本地状态有着深度绑定的应用而言， +仍然停留在当前节点上运行一段较长的时间，以等待网络恢复以避免被驱逐。 +你为这种 Pod 所设置的容忍度看起来可能是这样： ```yaml tolerations: @@ -424,60 +418,54 @@ tolerations: tolerationSeconds: 6000 ``` - - {{< note >}} -Kubernetes 会自动给 Pod 添加一个 key 为 `node.kubernetes.io/not-ready` 的容忍度 -并配置 `tolerationSeconds=300`，除非用户提供的 Pod 配置中已经已存在了 key 为 -`node.kubernetes.io/not-ready` 的容忍度。 - -同样，Kubernetes 会给 Pod 添加一个 key 为 `node.kubernetes.io/unreachable` 的容忍度 -并配置 `tolerationSeconds=300`，除非用户提供的 Pod 配置中已经已存在了 key 为 -`node.kubernetes.io/unreachable` 的容忍度。 -{{< /note >}} - -这种自动添加的容忍度意味着在其中一种问题被检测到时 Pod -默认能够继续停留在当前节点运行 5 分钟。 +Kubernetes 会自动给 Pod 添加针对 `node.kubernetes.io/not-ready` 和 +`node.kubernetes.io/unreachable` 的容忍度，且配置 `tolerationSeconds=300`， +除非用户自身或者某控制器显式设置此容忍度。 + +这些自动添加的容忍度意味着 Pod 可以在检测到对应的问题之一时，在 5 +分钟内保持绑定在该节点上。 +{{< /note >}} -[DaemonSet](/zh/docs/concepts/workloads/controllers/daemonset/) 中的 Pod 被创建时， +[DaemonSet](/zh-cn/docs/concepts/workloads/controllers/daemonset/) 中的 Pod 被创建时， 针对以下污点自动添加的 `NoExecute` 的容忍度将不会指定 `tolerationSeconds`： - * `node.kubernetes.io/unreachable` - * `node.kubernetes.io/not-ready` +* `node.kubernetes.io/unreachable` +* `node.kubernetes.io/not-ready` 这保证了出现上述问题时 DaemonSet 中的 Pod 永远不会被驱逐。 -## 基于节点状态添加污点 - +## 基于节点状态添加污点 {#taint-nodes-by-condition} +控制平面使用节点{{}}自动创建 +与[节点状况](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions) +对应的、效果为 `NoSchedule` 的污点。 + + - -控制平面使用节点{{}}自动创建 -与[节点状况](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/#node-conditions)对应的带有 `NoSchedule` 效应的污点。 - 调度器在进行调度时检查污点，而不是检查节点状况。这确保节点状况不会直接影响调度。 -例如，如果 `DiskPressure` 节点状况处于活跃状态，则控制平面 -添加 `node.kubernetes.io/disk-pressure` 污点并且不会调度新的 pod -到受影响的节点。如果 `MemoryPressure` 节点状况处于活跃状态，则 -控制平面添加 `node.kubernetes.io/memory-pressure` 污点。 +例如，如果 `DiskPressure` 节点状况处于活跃状态，则控制平面添加 +`node.kubernetes.io/disk-pressure` 污点并且不会调度新的 Pod 到受影响的节点。 +如果 `MemoryPressure` 节点状况处于活跃状态，则控制平面添加 +`node.kubernetes.io/memory-pressure` 污点。 - 对于新创建的 Pod，可以通过添加相应的 Pod 容忍度来忽略节点状况。 -控制平面还在具有除 `BestEffort` 之外的 {{}}的 Pod 上 -添加 `node.kubernetes.io/memory-pressure` 容忍度。 +控制平面还在具有除 `BestEffort` 之外的 +{{}}的 Pod 上添加 +`node.kubernetes.io/memory-pressure` 容忍度。 这是因为 Kubernetes 将 `Guaranteed` 或 `Burstable` QoS 类中的 Pod（甚至没有设置内存请求的 Pod） 视为能够应对内存压力，而新创建的 `BestEffort` Pod 不会被调度到受影响的节点上。 @@ -525,11 +509,11 @@ breaking. DaemonSet 控制器自动为所有守护进程添加如下 `NoSchedule` 容忍度以防 DaemonSet 崩溃： - * `node.kubernetes.io/memory-pressure` - * `node.kubernetes.io/disk-pressure` - * `node.kubernetes.io/pid-pressure` (1.14 或更高版本) - * `node.kubernetes.io/unschedulable` (1.10 或更高版本) - * `node.kubernetes.io/network-unavailable` (**只适合主机网络配置**) +* `node.kubernetes.io/memory-pressure` +* `node.kubernetes.io/disk-pressure` +* `node.kubernetes.io/pid-pressure` (1.14 或更高版本) +* `node.kubernetes.io/unschedulable` (1.10 或更高版本) +* `node.kubernetes.io/network-unavailable` (**只适合主机网络配置**) -* 阅读[节点压力驱逐](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/)，以及如何配置其行为 -* 阅读 [Pod 优先级](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/) +* 阅读[节点压力驱逐](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/)， + 以及如何配置其行为 +* 阅读 [Pod 优先级](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/) diff --git a/content/zh-cn/docs/concepts/security/controlling-access.md b/content/zh-cn/docs/concepts/security/controlling-access.md index 5946a002b6..b8b671cb8a 100644 --- a/content/zh-cn/docs/concepts/security/controlling-access.md +++ b/content/zh-cn/docs/concepts/security/controlling-access.md @@ -1,6 +1,7 @@ --- title: Kubernetes API 访问控制 content_type: concept +weight: 50 --- @@ -28,8 +30,8 @@ authorized for API access. When a request reaches the API, it goes through several stages, illustrated in the following diagram: --> -用户使用 `kubectl`、客户端库或构造 REST 请求来访问 [Kubernetes API](/zh/docs/concepts/overview/kubernetes-api/)。 -人类用户和 [Kubernetes 服务账户](/zh/docs/tasks/configure-pod-container/configure-service-account/)都可以被鉴权访问 API。 +用户使用 `kubectl`、客户端库或构造 REST 请求来访问 [Kubernetes API](/zh-cn/docs/concepts/overview/kubernetes-api/)。 +人类用户和 [Kubernetes 服务账户](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/)都可以被鉴权访问 API。 当请求到达 API 时，它会经历多个阶段，如下图所示： ![Kubernetes API 请求处理步骤示意图](/images/docs/admin/access-control-overview.svg) @@ -72,7 +74,7 @@ Authenticators are described in more detail in --> 如上图步骤 **1** 所示，建立 TLS 后， HTTP 请求将进入认证（Authentication）步骤。 集群创建脚本或者集群管理员配置 API 服务器，使之运行一个或多个身份认证组件。 -身份认证组件在[认证](/zh/docs/reference/access-authn-authz/authentication/)节中有更详细的描述。 +身份认证组件在[认证](/zh-cn/docs/reference/access-authn-authz/authentication/)节中有更详细的描述。 ## 准入控制 {#admission-control} @@ -223,7 +225,7 @@ for the corresponding API object, and then written to the object store (shown as 除了拒绝对象之外，准入控制器还可以为字段设置复杂的默认值。 -可用的准入控制模块在[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)中进行了描述。 +可用的准入控制模块在[准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/)中进行了描述。 请求通过所有准入控制器后，将使用检验例程检查对应的 API 对象，然后将其写入对象存储（如步骤 **4** 所示）。 @@ -241,7 +243,7 @@ For more information, see [Auditing](/docs/tasks/debug/debug-cluster/audit/). Kubernetes 审计提供了一套与安全相关的、按时间顺序排列的记录，其中记录了集群中的操作序列。 集群对用户、使用 Kubernetes API 的应用程序以及控制平面本身产生的活动进行审计。 -更多信息请参考 [审计](/zh/docs/tasks/debug/debug-cluster/audit/). +更多信息请参考 [审计](/zh-cn/docs/tasks/debug/debug-cluster/audit/). ## API 服务器端口和 IP {#api-server-ports-and-ips} @@ -327,23 +329,23 @@ You can learn about: --> 阅读更多有关身份认证、鉴权和 API 访问控制的文档： -- [认证](/zh/docs/reference/access-authn-authz/authentication/) - - [使用 Bootstrap 令牌进行身份认证](/zh/docs/reference/access-authn-authz/bootstrap-tokens/) -- [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/) - - [动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/) -- [鉴权](/zh/docs/reference/access-authn-authz/authorization/) - - [基于角色的访问控制](/zh/docs/reference/access-authn-authz/rbac/) - - [基于属性的访问控制](/zh/docs/reference/access-authn-authz/abac/) - - [节点鉴权](/zh/docs/reference/access-authn-authz/node/) - - [Webhook 鉴权](/zh/docs/reference/access-authn-authz/webhook/) -- [证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/) - - 包括 [CSR 认证](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection) - 和[证书签名](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#signing) +- [认证](/zh-cn/docs/reference/access-authn-authz/authentication/) + - [使用 Bootstrap 令牌进行身份认证](/zh-cn/docs/reference/access-authn-authz/bootstrap-tokens/) +- [准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/) + - [动态准入控制](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/) +- [鉴权](/zh-cn/docs/reference/access-authn-authz/authorization/) + - [基于角色的访问控制](/zh-cn/docs/reference/access-authn-authz/rbac/) + - [基于属性的访问控制](/zh-cn/docs/reference/access-authn-authz/abac/) + - [节点鉴权](/zh-cn/docs/reference/access-authn-authz/node/) + - [Webhook 鉴权](/zh-cn/docs/reference/access-authn-authz/webhook/) +- [证书签名请求](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/) + - 包括 [CSR 认证](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection) + 和[证书签名](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/#signing) - 服务账户 - - [开发者指导](/zh/docs/tasks/configure-pod-container/configure-service-account/) - - [管理](/zh/docs/reference/access-authn-authz/service-accounts-admin/) + - [开发者指导](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/) + - [管理](/zh-cn/docs/reference/access-authn-authz/service-accounts-admin/) 你可以了解 - Pod 如何使用 - [Secrets](/zh/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials) + [Secrets](/zh-cn/docs/concepts/configuration/secret/#service-accounts-automatically-create-and-attach-secrets-with-api-credentials) 获取 API 凭证. diff --git a/content/zh-cn/docs/concepts/security/overview.md b/content/zh-cn/docs/concepts/security/overview.md index 9a9e9845a7..165c339de1 100644 --- a/content/zh-cn/docs/concepts/security/overview.md +++ b/content/zh-cn/docs/concepts/security/overview.md @@ -165,7 +165,7 @@ good information practices, read and follow the advice about --> ### 集群组件 {#cluster-components} -如果想要保护集群免受意外或恶意的访问，采取良好的信息管理实践，请阅读并遵循有关[保护集群](/zh/docs/tasks/administer-cluster/securing-a-cluster/)的建议。 +如果想要保护集群免受意外或恶意的访问，采取良好的信息管理实践，请阅读并遵循有关[保护集群](/zh-cn/docs/tasks/administer-cluster/securing-a-cluster/)的建议。 学习了解相关的 Kubernetes 安全主题： -* [Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/) -* [Pod 的网络策略](/zh/docs/concepts/services-networking/network-policies/) -* [控制对 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access/) -* [保护你的集群](/zh/docs/tasks/administer-cluster/securing-a-cluster/) -* 为控制面[加密通信中的数据](/zh/docs/tasks/tls/managing-tls-in-a-cluster/) -* [加密静止状态的数据](/zh/docs/tasks/administer-cluster/encrypt-data/) -* [Kubernetes 中的 Secret](/zh/docs/concepts/configuration/secret/) -* [运行时类](/zh/docs/concepts/containers/runtime-class) +* [Pod 安全标准](/zh-cn/docs/concepts/security/pod-security-standards/) +* [Pod 的网络策略](/zh-cn/docs/concepts/services-networking/network-policies/) +* [控制对 Kubernetes API 的访问](/zh-cn/docs/concepts/security/controlling-access/) +* [保护你的集群](/zh-cn/docs/tasks/administer-cluster/securing-a-cluster/) +* 为控制面[加密通信中的数据](/zh-cn/docs/tasks/tls/managing-tls-in-a-cluster/) +* [加密静止状态的数据](/zh-cn/docs/tasks/administer-cluster/encrypt-data/) +* [Kubernetes 中的 Secret](/zh-cn/docs/concepts/configuration/secret/) +* [运行时类](/zh-cn/docs/concepts/containers/runtime-class) diff --git a/content/zh-cn/docs/concepts/security/pod-security-admission.md b/content/zh-cn/docs/concepts/security/pod-security-admission.md index b5097a995e..9a3d6533d8 100644 --- a/content/zh-cn/docs/concepts/security/pod-security-admission.md +++ b/content/zh-cn/docs/concepts/security/pod-security-admission.md @@ -29,7 +29,7 @@ The Kubernetes [Pod Security Standards](/docs/concepts/security/pod-security-sta different isolation levels for Pods. These standards let you define how you want to restrict the behavior of pods in a clear, consistent fashion. --> -Kubernetes [Pod 安全性标准（Security Standards）](/zh/docs/concepts/security/pod-security-standards/) +Kubernetes [Pod 安全性标准（Security Standards）](/zh-cn/docs/concepts/security/pod-security-standards/) 为 Pod 定义不同的隔离级别。这些标准能够让你以一种清晰、一致的方式定义如何限制 Pod 行为。 作为一项 Beta 功能特性，Kubernetes 提供一种内置的 _Pod 安全性_ {{< glossary_tooltip text="准入控制器" term_id="admission-controller" >}}， -作为 [PodSecurityPolicies](/zh/docs/concepts/security/pod-security-policy/) +作为 [PodSecurityPolicies](/zh-cn/docs/concepts/security/pod-security-policy/) 特性的后继演化版本。Pod 安全性限制是在 Pod 被创建时在 {{< glossary_tooltip text="名字空间" term_id="namespace" >}}层面实施的。 @@ -51,34 +51,32 @@ The PodSecurityPolicy API is deprecated and will be [removed](/docs/reference/using-api/deprecation-guide/#v1-25) from Kubernetes in v1.25. --> PodSecurityPolicy API 已经被废弃，会在 Kubernetes v1.25 发行版中 -[移除](/zh/docs/reference/using-api/deprecation-guide/#v1-25)。 +[移除](/zh-cn/docs/reference/using-api/deprecation-guide/#v1-25)。 {{< /note >}} +## {{% heading "prerequisites" %}} + -## {{% heading "prerequisites" %}} - 要使用此机制，你的集群必须强制执行 Pod 安全准入。 -### 内置 Pod 安全准入强制执行 - -在 Kubernetes v{{< skew currentVersion >}} 中，`PodSecurity` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)是一项 Beta 特性， -默认被启用。你必须启用此功能门控。如果你运行的是不同版本的 Kubernetes，请查阅该版本的文档。 - +### 内置 Pod 安全准入强制执行 +在 Kubernetes v1.23 中，`PodSecurity` +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)是一项 Beta 特性， +默认被启用。 +本页面是 Kubernetes v{{< skew currentVersion >}} 文档的一部分。 +如果你运行的是其它版本的 Kubernetes，请查阅该版本的文档。 在 [https://git.k8s.io/pod-security-admission/webhook](https://git.k8s.io/pod-security-admission/webhook) 上可以找到一个预先构建的容器镜像、证书生成脚本以及一些示例性质的清单。 +执行下面的命令来安装： ```shell git clone git@github.com:kubernetes/pod-security-admission.git @@ -132,11 +131,11 @@ Standards](/docs/concepts/security/pod-security-standards): `privileged`, `basel `restricted`. Refer to the [Pod Security Standards](/docs/concepts/security/pod-security-standards) page for an in-depth look at those requirements. --> -Pod 安全性准入插件对 Pod 的[安全性上下文](/zh/docs/tasks/configure-pod-container/security-context/) -有一定的要求，并且依据 [Pod 安全性标准](/zh/docs/concepts/security/pod-security-standards) +Pod 安全性准入插件对 Pod 的[安全性上下文](/zh-cn/docs/tasks/configure-pod-container/security-context/) +有一定的要求，并且依据 [Pod 安全性标准](/zh-cn/docs/concepts/security/pod-security-standards) 所定义的三个级别（`privileged`、`baseline` 和 `restricted`）对其他字段也有要求。 关于这些需求的更进一步讨论，请参阅 -[Pod 安全性标准](/zh/docs/concepts/security/pod-security-standards/)页面。 +[Pod 安全性标准](/zh-cn/docs/concepts/security/pod-security-standards/)页面。 {{< table caption="Pod 安全准入模式" >}} 模式 | 描述 :---------|:------------ **enforce** | 策略违例会导致 Pod 被拒绝 -**audit** | 策略违例会触发[审计日志](/zh/docs/tasks/debug/debug-cluster/audit/)中记录新事件时添加审计注解；但是 Pod 仍是被接受的。 +**audit** | 策略违例会触发[审计日志](/zh-cn/docs/tasks/debug/debug-cluster/audit/)中记录新事件时添加审计注解；但是 Pod 仍是被接受的。 **warn** | 策略违例会触发用户可见的警告信息，但是 Pod 仍是被接受的。 {{< /table >}} @@ -191,21 +188,21 @@ For each mode, there are two labels that determine the policy used: pod-security.kubernetes.io/: # Optional: per-mode version label that can be used to pin the policy to the -# version that shipped with a given Kubernetes minor version (for example v{{< skew latestVersion >}}). +# version that shipped with a given Kubernetes minor version (for example v{{< skew currentVersion >}}). # # MODE must be one of `enforce`, `audit`, or `warn`. # VERSION must be a valid Kubernetes minor version, or `latest`. pod-security.kubernetes.io/-version: --> ``` -# 针对模式的级别标签用来标示针对该模式所应用的策略级别 +# 模式的级别标签用来标示对应模式所应用的策略级别 # # MODE 必须是 `enforce`、`audit` 或 `warn` 之一 # LEVEL 必须是 `privileged`、baseline` 或 `restricted` 之一 pod-security.kubernetes.io/: # 可选：针对每个模式版本的版本标签可以将策略锁定到 -# 给定 Kubernetes 小版本号所附带的版本（例如 v{{< skew latestVersion >}}） +# 给定 Kubernetes 小版本号所附带的版本（例如 v{{< skew currentVersion >}}） # # MODE 必须是 `enforce`、`audit` 或 `warn` 之一 # VERSION 必须是一个合法的 Kubernetes 小版本号或者 `latest` @@ -215,8 +212,7 @@ pod-security.kubernetes.io/-version: -关于用法示例，可参阅 -[使用名字空间标签来强制实施 Pod 安全标准](/zh/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/)。 +关于用法示例，可参阅[使用名字空间标签来强制实施 Pod 安全标准](/zh-cn/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/)。 ## 豁免 {#exemptions} -你可以为 Pod 安全性的实施设置 _豁免（Exemptions）_ 规则， +你可以为 Pod 安全性的实施设置 **豁免（Exemptions）** 规则， 从而允许创建一些本来会被与给定名字空间相关的策略所禁止的 Pod。 -豁免规则可以在[准入控制器配置](/zh/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller) +豁免规则可以在[准入控制器配置](/zh-cn/docs/tasks/configure-pod-container/enforce-standards-admission-controller/#configure-the-admission-controller) 中静态配置。 -豁免规则可以显式枚举。满足豁免标准的请求会被准入控制器 _忽略_ +豁免规则可以显式枚举。满足豁免标准的请求会被准入控制器 **忽略** （所有 `enforce`、`audit` 和 `warn` 行为都会被略过）。 豁免的维度包括： @@ -306,7 +303,7 @@ current policy level: - Valid updates to `.spec.activeDeadlineSeconds` - Valid updates to `.spec.tolerations` --> -- 除了对 seccomp 或 AppArmor 注解之外的所有 meatadata 更新操作： +- 除了对 seccomp 或 AppArmor 注解之外的所有元数据（Metadata）更新操作： - `seccomp.security.alpha.kubernetes.io/pod` （已弃用） - `container.seccomp.security.alpha.kubernetes.io/*` （已弃用） - `container.apparmor.security.beta.kubernetes.io/*` @@ -322,9 +319,9 @@ current policy level: - [Enforce Pod Security Standards with Namespace Labels](/docs/tasks/configure-pod-container/enforce-standards-namespace-labels) - [Migrate from PodSecurityPolicy to the Built-In PodSecurity Admission Controller](/docs/tasks/configure-pod-container/migrate-from-psp) --> -- [Pod 安全性标准](/zh/docs/concepts/security/pod-security-standards/) -- [强制实施 Pod 安全性标准](/zh/docs/setup/best-practices/enforcing-pod-security-standards/) -- [通过配置内置的准入控制器强制实施 Pod 安全性标准](/zh/docs/tasks/configure-pod-container/enforce-standards-admission-controller/) -- [使用名字空间标签来实施 Pod 安全性标准](/zh/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/) -- [从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器](/zh/docs/tasks/configure-pod-container/migrate-from-psp/) +- [Pod 安全性标准](/zh-cn/docs/concepts/security/pod-security-standards/) +- [强制实施 Pod 安全性标准](/zh-cn/docs/setup/best-practices/enforcing-pod-security-standards/) +- [通过配置内置的准入控制器强制实施 Pod 安全性标准](/zh-cn/docs/tasks/configure-pod-container/enforce-standards-admission-controller/) +- [使用名字空间标签来实施 Pod 安全性标准](/zh-cn/docs/tasks/configure-pod-container/enforce-standards-namespace-labels/) +- [从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器](/zh-cn/docs/tasks/configure-pod-container/migrate-from-psp/) diff --git a/content/zh-cn/docs/concepts/security/pod-security-policy.md b/content/zh-cn/docs/concepts/security/pod-security-policy.md index 6bb83482f6..2b097ccb89 100644 --- a/content/zh-cn/docs/concepts/security/pod-security-policy.md +++ b/content/zh-cn/docs/concepts/security/pod-security-policy.md @@ -24,9 +24,9 @@ For more information on the deprecation, see [PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/). --> PodSecurityPolicy 在 Kubernetes v1.21 版本中被弃用，**将在 v1.25 中删除**。 -我们建议迁移到 [Pod 安全性准入](/zh/docs/concepts/security/pod-security-admission)， +我们建议迁移到 [Pod 安全性准入](/zh-cn/docs/concepts/security/pod-security-admission)， 或者第三方的准入插件。 -若需了解迁移指南，可参阅[从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器](/zh/docs/tasks/configure-pod-container/migrate-from-psp/)。 +若需了解迁移指南，可参阅[从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器](/zh-cn/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 >}} @@ -50,15 +50,15 @@ administrator to control the following: --> ## 什么是 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 Security Policy）**是集群级别的资源，它能够控制 Pod +规约中与安全性相关的各个方面。 +[PodSecurityPolicy](/zh-cn/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) 对象定义了一组 Pod 运行时必须遵循的条件及相关字段的默认值，只有 Pod 满足这些条件才会被系统接受。 -Pod 安全策略允许管理员控制如下方面： +Pod 安全策略允许管理员控制如下操作： ## 启用 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 安全策略实现为一种可选的[准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy)。 +[启用了准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in)即可强制实施 +Pod 安全策略，不过如果没有授权认可策略之前即启用准入控制器**将导致集群中无法创建任何 Pod**。 -由于 Pod 安全策略 API（`policy/v1beta1/podsecuritypolicy`）是独立于准入控制器 -来启用的，对于现有集群而言，建议在启用准入控制器之前先添加策略并对其授权。 +由于 Pod 安全策略 API（`policy/v1beta1/podsecuritypolicy`）是独立于准入控制器来启用的， +对于现有集群而言，建议在启用准入控制器之前先添加策略并对其授权。 大多数 Kubernetes Pod 不是由用户直接创建的。相反，这些 Pod 是由 -[Deployment](/zh/docs/concepts/workloads/controllers/deployment/)、 -[ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/) -或者经由控制器管理器模版化的控制器创建。 -赋予控制器访问策略的权限意味着对应控制器所创建的 *所有* Pod 都可访问策略。 +[Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/)、 +[ReplicaSet](/zh-cn/docs/concepts/workloads/controllers/replicaset/) +或者经由控制器管理器模板化的控制器创建。 +赋予控制器访问策略的权限意味着对应控制器所创建的**所有** Pod 都可访问策略。 因此，对策略进行授权的优先方案是为 Pod 的服务账号授予访问权限 （参见[示例](#run-another-pod)）。 @@ -164,7 +164,7 @@ policies. The rules to grant access look like this: --> ### 通过 RBAC 授权 {#via-rbac} -[RBAC](/zh/docs/reference/access-authn-authz/rbac/) 是一种标准的 Kubernetes +[RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/) 是一种标准的 Kubernetes 鉴权模式，可以很容易地用来授权策略访问。 首先，某 `Role` 或 `ClusterRole` 需要获得使用 `use` 访问目标策略的权限。 @@ -272,7 +272,7 @@ For more examples of RBAC bindings, see [Role Binding Examples](/docs/reference/access-authn-authz/rbac#role-binding-examples). For a complete example of authorizing a PodSecurityPolicy, see [below](#example). --> -参阅[角色绑定示例](/zh/docs/reference/access-authn-authz/rbac#role-binding-examples)查看 +参阅[角色绑定示例](/zh-cn/docs/reference/access-authn-authz/rbac#role-binding-examples)查看 RBAC 绑定的更多实例。 参阅[下文](#example)，查看对 PodSecurityPolicy 进行授权的完整示例。 @@ -303,7 +303,7 @@ PodSecurityPolicy 正在被一个新的、简化的 `PodSecurity` - {{< example file="policy/restricted-psp.yaml" >}}Restricted{{< /example >}} --> 1. 将 PodSecurityPolicies 限制为 - [Pod 安全性标准](/zh/docs/concepts/security/pod-security-standards)所定义的策略： + [Pod 安全性标准](/zh-cn/docs/concepts/security/pod-security-standards)所定义的策略： - {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}} - {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}} @@ -371,9 +371,9 @@ PodSecurityPolicy 正在被一个新的、简化的 `PodSecurity` --> ### 故障排查 {#troubleshooting} -- [控制器管理器组件](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) +- [控制器管理器组件](/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/) 必须运行在安全的 API 端口之上，并且不能拥有超级用户的访问权限。 - 参阅[控制 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access)以了解 + 参阅[控制 Kubernetes API 的访问](/zh-cn/docs/concepts/security/controlling-access)以了解 API 服务器的访问控制。 如果控制器管理器通过可信的 API 端口连接（也称作 `localhost` 监听组件）， @@ -381,7 +381,7 @@ PodSecurityPolicy 正在被一个新的、简化的 `PodSecurity` 用户亦能授予自身创建特权容器的特权。 关于配置控制器管理器鉴权的进一步细节， - 请参阅[控制器角色](/zh/docs/reference/access-authn-authz/rbac/#controller-roles)。 + 请参阅[控制器角色](/zh-cn/docs/reference/access-authn-authz/rbac/#controller-roles)。 -### 创建一个策略和一个 Pod +### 创建一个策略和一个 Pod {#create-a-policy-and-a-pod} 在一个文件中定义一个示例的 PodSecurityPolicy 对象。 这里的策略只是用来禁止创建有特权要求的 Pods。 PodSecurityPolicy 对象的名称必须是合法的 -[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)。 {{< codenew file="policy/example-psp.yaml" >}} @@ -588,7 +588,7 @@ spec: EOF ``` 输出类似于： @@ -716,8 +716,7 @@ rolebinding "default:psp:unprivileged" created Now if you give it a minute to retry, the replicaset-controller should eventually succeed in creating the pod: --> -现在如果你给 ReplicaSet 控制器一分钟的时间来重试，该控制器最终将能够 -成功地创建 Pod： +现在如果你给 ReplicaSet 控制器一分钟的时间来重试，该控制器最终将能够成功地创建 Pod： ```shell kubectl-user get pods --watch @@ -791,10 +790,11 @@ several security mechanisms. {{< codenew file="policy/restricted-psp.yaml" >}} 更多的示例可参考 -[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/#policy-instantiation)。 +[Pod 安全标准](/zh-cn/docs/concepts/security/pod-security-standards/#policy-instantiation)。 **FSGroup** - 控制应用到某些卷上的附加用户组。 -- *MustRunAs* - 要求至少指定一个 `range`。 +- **MustRunAs** - 要求至少指定一个 `range`。 使用范围中的最小值作为默认值。所有 range 值都会被用来执行验证。 -- *MayRunAs* - 要求至少指定一个 `range`。 +- **MayRunAs** - 要求至少指定一个 `range`。 允许不设置 `FSGroups`，且无默认值。 如果 `FSGroup` 被设置，则所有 range 值都会被用来执行验证检查。 -- *RunAsAny* - 不提供默认值。允许设置任意 `fsGroup` ID 值。 +- **RunAsAny** - 不提供默认值。允许设置任意 `fsGroup` ID 值。 **RunAsGroup** - 控制运行容器时使用的主用户组 ID。 -- *MustRunAs* - 要求至少指定一个 `range` 值。第一个范围中的最小值作为默认值。 +- **MustRunAs** - 要求至少指定一个 `range` 值。第一个范围中的最小值作为默认值。 所有范围值都被用来执行验证检查。 -- *MayRunAs* - 不要求设置 `RunAsGroup`。 +- **MayRunAs** - 不要求设置 `RunAsGroup`。 不过，如果指定了 `RunAsGroup` 被设置，所设置值必须处于所定义的范围内。 -- *RunAsAny* - 未指定默认值。允许 `runAsGroup` 设置任何值。 +- **RunAsAny** - 未指定默认值。允许 `runAsGroup` 设置任何值。 **SupplementalGroups** - 控制容器可以添加的组 ID。 -- *MustRunAs* - 要求至少指定一个 `range` 值。第一个范围中的最小值用作默认值。 +- **MustRunAs** - 要求至少指定一个 `range` 值。第一个范围中的最小值用作默认值。 所有范围值都被用来执行验证检查。 -- *MayRunAs* - 要求至少指定一个 `range` 值。 +- **MayRunAs** - 要求至少指定一个 `range` 值。 允许不指定 `supplementalGroups` 且不设置默认值。 如果 `supplementalGroups` 被设置，则所有 range 值都被用来执行验证检查。 -- *RunAsAny* - 未指定默认值。允许为 `supplementalGroups` 设置任何值。 +- **RunAsAny** - 未指定默认值。允许为 `supplementalGroups` 设置任何值。 ### 特权提升 {#privilege-escalation} -这一组选项控制容器的`allowPrivilegeEscalation` 属性。该属性直接决定是否为容器进程设置 +这一组选项控制容器的 `allowPrivilegeEscalation` 属性。该属性直接决定是否为容器进程设置 [`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt) 参数。此参数会禁止 `setuid` 属性的可执行文件更改有效用户 ID（EUID）， 并且禁止启用额外权能的文件。例如，`no_new_privs` 会禁止使用 `ping` 工具。 @@ -1128,7 +1128,7 @@ pods to request `allowPrivilegeEscalation` explicitly. **DefaultAllowPrivilegeEscalation** - 为 `allowPrivilegeEscalation` 选项设置默认值。 不设置此选项时的默认行为是允许特权提升，以便运行 setuid 程序。 如果不希望运行 setuid 程序，可以使用此字段将选项的默认值设置为禁止， -同时仍然允许 Pod 显式地请求 `allowPrivilegeEscalation`。 +同时仍然允许 Pod 显式地请求 `allowPrivilegeEscalation`。 ### 权能字 {#capabilities} @@ -1176,7 +1176,7 @@ added. Capabilities listed in `RequiredDropCapabilities` must not be included in **DefaultAddCapabilities** - 默认添加到容器的权能字集合。 这一集合是作为容器运行时所设值的补充。 @@ -1193,9 +1193,9 @@ specified. --> ### SELinux -- *MustRunAs* - 要求必须配置 `seLinuxOptions`。默认使用 `seLinuxOptions`。 +- **MustRunAs** - 要求必须配置 `seLinuxOptions`。默认使用 `seLinuxOptions`。 针对 `seLinuxOptions` 所给值执行验证检查。 -- *RunAsAny* - 没有提供默认值。允许任意指定的 `seLinuxOptions` 选项。 +- **RunAsAny** - 没有提供默认值。允许任意指定的 `seLinuxOptions` 选项。 ### AppArmor 通过 PodSecurityPolicy 上的注解来控制。 详情请参阅 -[AppArmor 文档](/zh/docs/tutorials/policy/apparmor/#podsecuritypolicy-annotations)。 - +[AppArmor 文档](/zh-cn/docs/tutorials/security/apparmor/#podsecuritypolicy-annotations)。 - `unconfined` - 如果没有指定其他替代方案，Seccomp 不会被应用到容器进程上 （Kubernets 中的默认设置）。 -- `runtime/default` - 使用默认的容器运行时模版。 -- `docker/default` - 使用 Docker 的默认 seccomp 模版。自 1.11 版本废弃。 +- `runtime/default` - 使用默认的容器运行时模板。 +- `docker/default` - 使用 Docker 的默认 seccomp 模板。自 1.11 版本废弃。 应改为使用 `runtime/default`。 -- `localhost/<路径名>` - 指定节点上路径 `/<路径名>` 下的一个文件作为其模版。 +- `localhost/<路径名>` - 指定节点上路径 `/<路径名>` 下的一个文件作为其模板。 其中 `` 是通过 `kubelet` 的标志 `--seccomp-profile-root` 来指定的。 如果未定义 `--seccomp-profile-root` 标志，则使用默认的路径 `/seccomp`， 其中 `` 是通过 `--root-dir` 标志来设置的。 @@ -1308,8 +1301,8 @@ default cannot be changed. --> **seccomp.security.alpha.kubernetes.io/allowedProfileNames** - 指定可以为 Pod seccomp 注解配置的值的注解。取值为一个可用值的列表。 -表中每项可以是上述各值之一，还可以是 `*`，用来表示允许所有的模版。 -如果没有设置此注解，意味着默认的 seccomp 模版是不可更改的。 +表中每项可以是上述各值之一，还可以是 `*`，用来表示允许所有的模板。 +如果没有设置此注解，意味着默认的 seccomp 模板是不可更改的。 -参阅 [Sysctl 文档](/zh/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy)。 +参阅 [Sysctl 文档](/zh-cn/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 安全标准](/zh-cn/docs/concepts/security/pod-security-standards/)， 了解策略建议。 -- 阅读 [Pod 安全策略参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy)， +- 阅读 [PodSecurityPolicy 参考](/zh-cn/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy)， 了解 API 细节。 - diff --git a/content/zh-cn/docs/concepts/security/pod-security-standards.md b/content/zh-cn/docs/concepts/security/pod-security-standards.md index 4bd324ceb0..243bd9529c 100644 --- a/content/zh-cn/docs/concepts/security/pod-security-standards.md +++ b/content/zh-cn/docs/concepts/security/pod-security-standards.md @@ -21,17 +21,18 @@ weight: 10 The Pod Security Standards define three different _policies_ to broadly cover the security spectrum. These policies are _cumulative_ and range from highly-permissive to highly-restrictive. This guide outlines the requirements of each policy. +--> +Pod 安全性标准定义了三种不同的 **策略（Policy）**，以广泛覆盖安全应用场景。 +这些策略是 **叠加式的（Cumulative）**，安全级别从高度宽松至高度受限。 +本指南概述了每个策略的要求。 + -Pod 安全性标准定义了三种不同的 _策略（Policy）_，以广泛覆盖安全应用场景。 -这些策略是 _渐进式的（Cumulative）_，安全级别从高度宽松至高度受限。 -本指南概述了每个策略的要求。 - | Profile | 描述 | | ------ | ----------- | | Privileged | 不受限制的策略，提供最大可能范围的权限许可。此策略允许已知的特权提升。 | @@ -97,151 +98,74 @@ fail validation. 控制（Control） 策略（Policy） - + - HostProcess - + Windows Pod 提供了运行 HostProcess 容器 的能力，这使得对 Windows 节点的特权访问成为可能。Baseline 策略中禁止对宿主的特权访问。{{< feature-state for_k8s_version="v1.23" state="beta" >}} +

+

限制的字段

  • spec.securityContext.windowsOptions.hostProcess
  • spec.containers[*].securityContext.windowsOptions.hostProcess
  • spec.initContainers[*].securityContext.windowsOptions.hostProcess
  • spec.ephemeralContainers[*].securityContext.windowsOptions.hostProcess
-

Allowed Values

+

准许的取值

    -
  • Undefined/nil
    • -
  • false
    • -
- --> - -

Windows Pod 提供了运行 - HostProcess 容器 的能力， - 这使得对 Windows 节点的特权访问成为可能。 - 基线策略中对宿主的特权访问是被禁止的。 - HostProcess Pod 是 Kubernetes v1.22 版本的 - alpha 特性。

-

限制的字段

-
    -
  • spec.securityContext.windowsOptions.hostProcess
    • -
  • spec.containers[*].securityContext.windowsOptions.hostProcess
    • -
  • spec.initContainers[*].securityContext.windowsOptions.hostProcess
    • -
  • spec.ephemeralContainers[*].securityContext.windowsOptions.hostProcess
    • -
-

允许的值

-
    -
  • 未定义/nil
    • +
  • 未定义、nil
  • false
- - 宿主名字空间 - 宿主名字空间 + +

必须禁止共享宿主上的名字空间。

+

限制的字段

  • spec.hostNetwork
  • spec.hostPID
  • spec.hostIPC
-

Allowed Values

+

准许的取值

    -
  • Undefined/nil
    • -
  • false
    • -
- - --> - -

必须禁止共享宿主名字空间。

-

限制的字段

-
    -
  • spec.hostNetwork
    • -
  • spec.hostPID
    • -
  • spec.hostIPC
    • -
-

允许的值

-
    -
  • 未定义/nil
    • +
  • 未定义、nil
  • false
- - 特权容器 - + 特权容器 -

特权 Pod 关闭了大多数安全性机制，必须被禁止。

-

限制的字段

+

特权 Pod 会使大多数安全性机制失效，必须被禁止。

+

限制的字段

  • spec.containers[*].securityContext.privileged
  • spec.initContainers[*].securityContext.privileged
  • spec.ephemeralContainers[*].securityContext.privileged
-

允许的值

+

准许的取值

    -
  • 未定义/nil
    • +
  • 未定义、nil
  • false
- - 权能 - + 权能 -

必须禁止添加除下列字段之外的权能。

-

限制的字段

+

必须禁止添加除下列字段之外的权能。

+

限制的字段

  • spec.containers[*].securityContext.capabilities.add
  • spec.initContainers[*].securityContext.capabilities.add
  • spec.ephemeralContainers[*].securityContext.capabilities.add
-

允许的值

+

准许的取值

    -
  • Undefined/nil
    • +
  • 未定义、nil
  • AUDIT_WRITE
  • CHOWN
  • DAC_OVERRIDE
    • @@ -259,150 +183,74 @@ fail validation. - - HostPath 卷 - + HostPath 卷 -

    必须禁止 HostPath 卷。

    -

    限制的字段

    +

    必须禁止 HostPath 卷。

    +

    限制的字段

    • spec.volumes[*].hostPath
    -

    允许的值

    +

    准许的取值

      -
    • 未定义/nil
      • +
    • 未定义、nil
    + - - 宿主端口 - 宿主端口 + +

    应该禁止使用宿主端口，或者至少限制只能使用某确定列表中的端口。

    +

    限制的字段

    • spec.containers[*].ports[*].hostPort
    • spec.initContainers[*].ports[*].hostPort
    • spec.ephemeralContainers[*].ports[*].hostPort
    -

    Allowed Values

    +

    准许的取值

      -
    • Undefined/nil
      • -
    • Known list
      • -
    • 0
      • -
    - --> - -

    应禁止使用宿主端口，或者至少限定为已知列表。

    -

    限制的字段

    -
      -
    • spec.containers[*].ports[*].hostPort
      • -
    • spec.initContainers[*].ports[*].hostPort
      • -
    • spec.ephemeralContainers[*].ports[*].hostPort
      • -
    -

    允许的值

    -
      -
    • 未定义/nil
      • -
    • 已知列表
      • +
    • 未定义、nil
      • +
    • 已知列表
    • 0
    - AppArmor - -

    在受支持的主机上，默认使用 runtime/default AppArmor Profile。 - 基线策略应避免覆盖或者禁用默认策略，以及限制覆盖一些 Profile 集合的权限。

    -

    限制的字段

    +

    在受支持的主机上，默认使用 runtime/default AppArmor 配置。Baseline 策略应避免覆盖或者禁用默认策略，以及限制覆盖一些配置集合的权限。

    +

    限制的字段

    • metadata.annotations["container.apparmor.security.beta.kubernetes.io/*"]
    -

    允许的值

    +

    准许的取值

      -
    • 未定义/nil
      • +
    • 未定义、nil
    • runtime/default
    • localhost/*
    - SELinux - -

    设置 SELinux 类型的操作是被限制的，设置自定义的 SELinux 用户或角色选项是被禁止的。

    -

    限制的字段

    +

    设置 SELinux 类型的操作是被限制的，设置自定义的 SELinux 用户或角色选项是被禁止的。

    +

    限制的字段

    • spec.securityContext.seLinuxOptions.type
    • spec.containers[*].securityContext.seLinuxOptions.type
    • spec.initContainers[*].securityContext.seLinuxOptions.type
    • spec.ephemeralContainers[*].securityContext.seLinuxOptions.type
    -

    允许的值

    +

    准许的取值

      -
    • 未定义/""
      • +
    • 未定义、""
    • container_t
    • container_init_t
    • container_kvm_t
    -

    限制的字段

    +

    限制的字段

    • spec.securityContext.seLinuxOptions.user
    • spec.containers[*].securityContext.seLinuxOptions.user
      • @@ -413,74 +261,43 @@ fail validation.
    • spec.initContainers[*].securityContext.seLinuxOptions.role
    • spec.ephemeralContainers[*].securityContext.seLinuxOptions.role
    -

    允许的值

    +

    准许的取值

      -
    • 未定义/""
      • +
    • 未定义、""
    - - /proc 挂载类型 - + /proc挂载类型 -

    要求使用默认的 /proc 掩码以减小攻击面。

    -

    限制的字段

    +

    要求使用默认的 /proc 掩码以减小攻击面。

    +

    限制的字段

    • spec.containers[*].securityContext.procMount
    • spec.initContainers[*].securityContext.procMount
    • spec.ephemeralContainers[*].securityContext.procMount
    -

    允许的值

    +

    准许的取值

      -
    • 未定义/nil
      • +
    • 未定义、nil
    • Default
    Seccomp - Seccomp 配置必须不能显式设置为 Unconfined。

    +

    限制的字段

    • spec.securityContext.seccompProfile.type
    • spec.containers[*].securityContext.seccompProfile.type
    • spec.initContainers[*].securityContext.seccompProfile.type
    • spec.ephemeralContainers[*].securityContext.seccompProfile.type
    -

    Allowed Values

    +

    准许的取值

      -
    • Undefined/nil
      • -
    • RuntimeDefault
      • -
    • Localhost
      • -
    - --> - -

    Seccomp Profile 禁止被显式设置为 Unconfined。

    -

    限制的字段

    -
      -
    • spec.securityContext.seccompProfile.type
      • -
    • spec.containers[*].securityContext.seccompProfile.type
      • -
    • spec.initContainers[*].securityContext.seccompProfile.type
      • -
    • spec.ephemeralContainers[*].securityContext.seccompProfile.type
      • -
    -

    允许的值

    -
      -
    • 未定义/nil
      • +
    • 未定义、nil
    • RuntimeDefault
    • Localhost
    @@ -488,32 +305,15 @@ fail validation. Sysctls - -

    Sysctls 可以禁用安全机制或影响宿主上所有容器，因此除了若干“安全”的子集之外，应该被禁止。 - 如果某 sysctl 是受容器或 Pod 的名字空间限制，且与节点上其他 Pod 或进程相隔离，可认为是安全的。

    -

    限制的字段

    +

    Sysctls 可以禁用安全机制或影响宿主上所有容器，因此除了若干“安全”的子集之外，应该被禁止。如果某 sysctl 是受容器或 Pod 的名字空间限制，且与节点上其他 Pod 或进程相隔离，可认为是安全的。

    +

    限制的字段

    • spec.securityContext.sysctls[*].name
    -

    允许的值

    +

    准许的取值

      -
    • 未定义/nil
      • +
    • 未定义、nil
    • kernel.shm_rmid_forced
    • net.ipv4.ip_local_port_range
    • net.ipv4.ip_unprivileged_port_start
      • @@ -532,66 +332,43 @@ fail validation. expense of some compatibility.** It is targeted at operators and developers of security-critical applications, as well as lower-trust users. The following listed controls should be enforced/disallowed: - -In this table, wildcards (`*`) indicate all elements in a list. For example, -`spec.containers[*].securityContext` refers to the Security Context object for _all defined -containers_. If any of the listed containers fails to meet the requirements, the entire pod will -fail validation. --> **_Restricted_ 策略旨在实施当前保护 Pod 的最佳实践，尽管这样作可能会牺牲一些兼容性。** 该类策略主要针对运维人员和安全性很重要的应用的开发人员，以及不太被信任的用户。 下面列举的控制需要被实施（禁止）： {{< note >}} + 在下述表格中，通配符（`*`）意味着一个列表中的所有元素。 -例如 `spec.containers[*].securityContext` 表示 _所定义的所有容器_ 的安全性上下文对象。 +例如 `spec.containers[*].securityContext` 表示 **所定义的所有容器** 的安全性上下文对象。 如果所列出的任一容器不能满足要求，整个 Pod 将无法通过校验。 {{< /note >}} - - + - - - - + + - - + - 卷类型 --> - - - 特权提升（v1.8+） --> - - - - - 以非 root 账号运行 + --> - - - + --> -

      Containers 不可以将 runAsUser 设置为 0

      -

      限制的字段

      -
        -
      • spec.securityContext.runAsUser
        • -
      • spec.containers[*].securityContext.runAsUser
        • -
      • spec.initContainers[*].securityContext.runAsUser
        • -
      • spec.ephemeralContainers[*].securityContext.runAsUser
        • -
      -

      允许的字段

      -
        -
      • any non-zero value
        • -
      • 未定义/空值
        • -
      --> -

      Seccomp Profile 必须被显式设置成一个允许的值。禁止使用 Unconfined - Profile 或者指定 不存在的 Profile。

      -

      限制的字段

      -
        -
      • spec.securityContext.seccompProfile.type
        • -
      • spec.containers[*].securityContext.seccompProfile.type
        • -
      • spec.initContainers[*].securityContext.seccompProfile.type
        • -
      • spec.ephemeralContainers[*].securityContext.seccompProfile.type
        • -
      -

      允许的值

      -
        -
      • RuntimeDefault
        • -
      • Localhost
        • -
      - - 如果 Pod 级别的 spec.securityContext.seccompProfile.type - 已设置得当，容器级别的安全上下文字段可以为 未定义/nil。 - 反过来说，如果 _所有的_ 容器级别的安全上下文字段已设置，则 Pod 级别的字段可为 未定义/nil。 - - + - - - - 权能（v1.22+） + --> - @@ -833,13 +507,19 @@ of individual policies are not defined here. 随着相关机制的成熟，这些机制会按策略分别定义在下面。特定策略的实施方法不在这里定义。 -[**Pod 安全性准入控制器**](/zh/docs/concepts/security/pod-security-admission/) + +[**Pod 安全性准入控制器**](/zh-cn/docs/concepts/security/pod-security-admission/) - {{< example file="security/podsecurity-privileged.yaml" >}}Privileged 名字空间{{< /example >}} - {{< example file="security/podsecurity-baseline.yaml" >}}Baseline 名字空间{{< /example >}} - {{< example file="security/podsecurity-restricted.yaml" >}}Restricted 名字空间{{< /example >}} -[**PodSecurityPolicy**](/zh/docs/concepts/security/pod-security-policy/) （已弃用） + +[**PodSecurityPolicy**](/zh-cn/docs/concepts/security/pod-security-policy/) （已弃用） - {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}} - {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}} @@ -896,7 +576,7 @@ in the Pod manifest, and represent parameters to the container runtime. --> ### 安全策略与安全上下文的区别是什么？ -[安全上下文](/zh/docs/tasks/configure-pod-container/security-context/)在运行时配置 Pod +[安全上下文](/zh-cn/docs/tasks/configure-pod-container/security-context/)在运行时配置 Pod 和容器。安全上下文是在 Pod 清单中作为 Pod 和容器规约的一部分来定义的， 所代表的是传递给容器运行时的参数。 @@ -908,8 +588,8 @@ built-in [Pod Security Admission Controller](/docs/concepts/security/pod-securit --> 安全策略则是控制面用来对安全上下文以及安全性上下文之外的参数实施某种设置的机制。 在 2020 年 7 月， -[Pod 安全性策略](/zh/docs/concepts/security/pod-security-policy/)已被废弃， -取而代之的是内置的 [Pod 安全性准入控制器](/zh/docs/concepts/security/pod-security-admission/)。 +[Pod 安全性策略](/zh-cn/docs/concepts/security/pod-security-policy/)已被废弃， +取而代之的是内置的 [Pod 安全性准入控制器](/zh-cn/docs/concepts/security/pod-security-admission/)。 -### 沙箱（Sandboxed） Pod 怎么处理？ +### 沙箱（Sandboxed）Pod 怎么处理？ {#what-about-sandboxed-pods} 现在还没有 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 index 3e9ed6ef07..a8ccbaca4e 100644 --- a/content/zh-cn/docs/concepts/security/rbac-good-practices.md +++ b/content/zh-cn/docs/concepts/security/rbac-good-practices.md @@ -3,6 +3,7 @@ title: 基于角色的访问控制良好实践 description: > 为集群操作人员提供的良好的 RBAC 设计原则和实践。 content_type: concept +weight: 60 --- @@ -31,7 +33,7 @@ Kubernetes {{< glossary_tooltip text="RBAC" term_id="rbac" >}} 降低因过多权限而导致安全事件的风险。 此文档的良好实践应该与通用 -[RBAC 文档](/zh/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update)一起阅读。 +[RBAC 文档](/zh-cn/docs/reference/access-authn-authz/rbac/#restrictions-on-role-creation-or-update)一起阅读。 @@ -74,7 +76,7 @@ some general rules that can be applied are : 由于 Kubernetes 是一个可扩展的系统，因此通过通配符来授予访问权限不仅会授予集群中当前的所有对象类型， 还包含所有未来被创建的所有对象类型。 - 管理员不应使用 `cluster-admin` 账号，除非特别需要。为低特权帐户提供 - [伪装权限](/zh/docs/reference/access-authn-authz/authentication/#user-impersonation) + [伪装权限](/zh-cn/docs/reference/access-authn-authz/authentication/#user-impersonation) 可以避免意外修改集群资源。 - 避免将用户添加到 `system:masters` 组。任何属于此组成员的用户都会绕过所有 RBAC 权限检查， 始终具有不受限制的超级用户访问权限，并且不能通过删除 `RoleBinding` 或 `ClusterRoleBinding` @@ -102,9 +104,9 @@ In cases where a workload requires powerful permissions, consider the following - 限制运行此类 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)确保 + 考虑使用[污点和容忍度](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/)、 + [节点亲和性](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity)或 + [Pod 反亲和性](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity)确保 Pod 不会与不可信或不太受信任的 Pod 一起运行。 特别注意可信度不高的 Pod 不符合 **Restricted** Pod 安全标准的情况。 ### 工作负载的创建 {#workload-creation} -能够创建工作负载的用户（Pod 或管理 Pod 的[工作负载资源](/zh/docs/concepts/workloads/controllers/)） +能够创建工作负载的用户（Pod 或管理 Pod 的[工作负载资源](/zh-cn/docs/concepts/workloads/controllers/)） 能够访问下层的节点，除非基于 Kubernetes 的 -[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)做限制。 +[Pod 安全标准](/zh-cn/docs/concepts/security/pod-security-standards/)做限制。 -可以为 Windows Pod 或容器指定 [RunAsUsername](/zh/docs/tasks/configure-pod-container/configure-runasusername) +可以为 Windows Pod 或容器指定 [RunAsUsername](/zh-cn/docs/tasks/configure-pod-container/configure-runasusername) 以作为特定用户执行容器进程。这大致相当于 [RunAsUser](/zh-cn/docs/concepts/security/pod-security-policy/#users-and-groups)。 -Windows 容器还可以通过使用[组管理的服务账号](/zh/docs/tasks/configure-pod-container/configure-gmsa/)作为 +Windows 容器还可以通过使用[组管理的服务账号](/zh-cn/docs/tasks/configure-pod-container/configure-gmsa/)作为 Active Directory 身份运行。 -* 进一步了解如何[使用 Service 访问集群中的应用](/zh/docs/tasks/access-application-cluster/service-access-application-cluster/) -* 进一步了解如何[使用 Service 将前端连接到后端](/zh/docs/tasks/access-application-cluster/connecting-frontend-backend/) -* 进一步了解如何[创建外部负载均衡器](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/) +* 进一步了解如何[使用 Service 访问集群中的应用](/zh-cn/docs/tasks/access-application-cluster/service-access-application-cluster/) +* 进一步了解如何[使用 Service 将前端连接到后端](/zh-cn/docs/tasks/access-application-cluster/connecting-frontend-backend/) +* 进一步了解如何[创建外部负载均衡器](/zh-cn/docs/tasks/access-application-cluster/create-external-load-balancer/) diff --git a/content/zh-cn/docs/concepts/services-networking/dns-pod-service.md b/content/zh-cn/docs/concepts/services-networking/dns-pod-service.md index 2bee2ba425..9946a88eb3 100644 --- a/content/zh-cn/docs/concepts/services-networking/dns-pod-service.md +++ b/content/zh-cn/docs/concepts/services-networking/dns-pod-service.md @@ -168,7 +168,7 @@ of the form `auto-generated-name.my-svc.my-namespace.svc.cluster-domain.example` #### SRV 记录 {#srv-records} Kubernetes 根据普通 Service 或 -[Headless Service](/zh/docs/concepts/services-networking/service/#headless-services) +[Headless Service](/zh-cn/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`。 @@ -370,7 +370,7 @@ Pod 会一直出于 `Pending` 状态（通过 `kubectl` 所看到的 `ContainerC （无法基于 Pod 主机名和集群域名构造 FQDN，FQDN `long-FQDN` 过长，至多 64 字符，请求字符数为 70）。 对于这种场景而言，改善用户体验的一种方式是创建一个 -[准入 Webhook 控制器](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)， +[准入 Webhook 控制器](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)， 在用户创建顶层对象（如 Deployment）的时候控制 FQDN 的长度。 {{< /note >}} @@ -405,11 +405,11 @@ DNS 策略可以逐个 Pod 来设定。目前 Kubernetes 支持以下特定 Pod 这些策略可以在 Pod 规约中的 `dnsPolicy` 字段设置： - "`Default`": Pod 从运行所在的节点继承名称解析配置。参考 - [相关讨论](/zh/docs/tasks/administer-cluster/dns-custom-nameservers) + [相关讨论](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers) 获取更多信息。 - "`ClusterFirst`": 与配置的集群域后缀不匹配的任何 DNS 查询（例如 "www.kubernetes.io"） 都将转发到从节点继承的上游名称服务器。集群管理员可能配置了额外的存根域和上游 DNS 服务器。 - 参阅[相关讨论](/zh/docs/tasks/administer-cluster/dns-custom-nameservers) + 参阅[相关讨论](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers) 了解在这些场景中如何处理 DNS 查询的信息。 - "`ClusterFirstWithHostNet`"：对于以 hostNetwork 方式运行的 Pod，应显式设置其 DNS 策略 "`ClusterFirstWithHostNet`"。 @@ -609,5 +609,5 @@ For guidance on administering DNS configurations, check [Configure DNS Service](/docs/tasks/administer-cluster/dns-custom-nameservers/) --> 有关管理 DNS 配置的指导，请查看 -[配置 DNS 服务](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/) +[配置 DNS 服务](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers/) diff --git a/content/zh-cn/docs/concepts/services-networking/endpoint-slices.md b/content/zh-cn/docs/concepts/services-networking/endpoint-slices.md index 05f808a1a9..b3f0949298 100644 --- a/content/zh-cn/docs/concepts/services-networking/endpoint-slices.md +++ b/content/zh-cn/docs/concepts/services-networking/endpoint-slices.md @@ -82,7 +82,7 @@ Kubernetes Service. 这些 EndpointSlice 将包含对与 Service 选择算符匹配的所有 Pod 的引用。 EndpointSlice 通过唯一的协议、端口号和 Service 名称将网络端点组织在一起。 EndpointSlice 的名称必须是合法的 -[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)。 例如，下面是 Kubernetes Service `example` 的 EndpointSlice 资源示例。 @@ -459,5 +459,5 @@ implementation in `kube-proxy`. -* 阅读[使用 Service 连接到应用](/zh/docs/concepts/services-networking/connect-applications-service/) +* 阅读[使用 Service 连接到应用](/zh-cn/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/zh-cn/docs/concepts/services-networking/ingress-controllers.md b/content/zh-cn/docs/concepts/services-networking/ingress-controllers.md index 06a4c948bd..1e2d6ae078 100644 --- a/content/zh-cn/docs/concepts/services-networking/ingress-controllers.md +++ b/content/zh-cn/docs/concepts/services-networking/ingress-controllers.md @@ -143,13 +143,13 @@ You may deploy any number of ingress controllers using [ingress class](/docs/con within a cluster. Note the `.metadata.name` of your ingress class resource. When you create an ingress you would need that name to specify the `ingressClassName` field on your Ingress object (refer to [IngressSpec v1 reference](/docs/reference/kubernetes-api/service-resources/ingress-v1/#IngressSpec). `ingressClassName` is a replacement of the older [annotation method](/docs/concepts/services-networking/ingress/#deprecated-annotation). --> 你可以使用 -[Ingress 类](/zh/docs/concepts/services-networking/ingress/#ingress-class)在集群中部署任意数量的 +[Ingress 类](/zh-cn/docs/concepts/services-networking/ingress/#ingress-class)在集群中部署任意数量的 Ingress 控制器。 请注意你的 Ingress 类资源的 `.metadata.name` 字段。 当你创建 Ingress 时，你需要用此字段的值来设置 Ingress 对象的 `ingressClassName` 字段（请参考 [IngressSpec v1 reference](/docs/reference/kubernetes-api/service-resources/ingress-v1/#IngressSpec)）。 `ingressClassName` -是之前的[注解](/zh/docs/concepts/services-networking/ingress/#deprecated-annotation)做法的替代。 +是之前的[注解](/zh-cn/docs/concepts/services-networking/ingress/#deprecated-annotation)做法的替代。 如果你不为 Ingress 指定 IngressClass，并且你的集群中只有一个 IngressClass 被标记为默认，那么 Kubernetes 会将此集群的默认 IngressClass -[应用](/zh/docs/concepts/services-networking/ingress/#default-ingress-class)到 Ingress 上。 +[应用](/zh-cn/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) +[`ingressclass.kubernetes.io/is-default-class` 注解](/zh-cn/docs/reference/labels-annotations-taints/#ingressclass-kubernetes-io-is-default-class) 的值设置为 `"true"` 来将一个 IngressClass 标记为集群默认。 理想情况下，所有 Ingress 控制器都应满足此规范，但各种 Ingress 控制器的操作略有不同。 @@ -181,6 +181,6 @@ Make sure you review your ingress controller's documentation to understand the c * Learn more about [Ingress](/docs/concepts/services-networking/ingress/). * [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube). --> -* 进一步了解 [Ingress](/zh/docs/concepts/services-networking/ingress/)。 -* [在 Minikube 上使用 NGINX 控制器安装 Ingress](/zh/docs/tasks/access-application-cluster/ingress-minikube)。 +* 进一步了解 [Ingress](/zh-cn/docs/concepts/services-networking/ingress/)。 +* [在 Minikube 上使用 NGINX 控制器安装 Ingress](/zh-cn/docs/tasks/access-application-cluster/ingress-minikube)。 diff --git a/content/zh-cn/docs/concepts/services-networking/ingress.md b/content/zh-cn/docs/concepts/services-networking/ingress.md index e14cd79ef8..6b5bf60c38 100644 --- a/content/zh-cn/docs/concepts/services-networking/ingress.md +++ b/content/zh-cn/docs/concepts/services-networking/ingress.md @@ -36,7 +36,7 @@ For clarity, this guide defines the following terms: 在此示例和在大多数常见的 Kubernetes 部署环境中，集群中的节点都不在公共网络中。 * 边缘路由器（Edge Router）: 在集群中强制执行防火墙策略的路由器。可以是由云提供商管理的网关，也可以是物理硬件。 * 集群网络（Cluster Network）: 一组逻辑的或物理的连接，根据 Kubernetes - [网络模型](/zh/docs/concepts/cluster-administration/networking/)在集群内实现通信。 + [网络模型](/zh-cn/docs/concepts/cluster-administration/networking/)在集群内实现通信。 * 服务（Service）：Kubernetes {{< glossary_tooltip term_id="service" >}}， 使用{{< glossary_tooltip text="标签" term_id="label" >}}选择器（selectors）辨认一组 Pod。 除非另有说明，否则假定服务只具有在集群网络中可路由的虚拟 IP。 @@ -51,7 +51,7 @@ Traffic routing is controlled by rules defined on the Ingress resource. ## Ingress 是什么？ {#what-is-ingress} [Ingress](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#ingress-v1beta1-networking-k8s-io) -公开从集群外部到集群内[服务](/zh/docs/concepts/services-networking/service/)的 +公开从集群外部到集群内[服务](/zh-cn/docs/concepts/services-networking/service/)的 HTTP 和 HTTPS 路由。 流量路由由 Ingress 资源上定义的规则控制。 @@ -66,7 +66,7 @@ Here is a simple example where an Ingress sends all its traffic to one Service: An Ingress may be configured to give Services externally-reachable URLs, load balance traffic, terminate SSL / TLS, and offer name based virtual hosting. An [Ingress controller](/docs/concepts/services-networking/ingress-controllers) is responsible for fulfilling the Ingress, usually with a load balancer, though it may also configure your edge router or additional frontends to help handle the traffic. --> Ingress 可为 Service 提供外部可访问的 URL、负载均衡流量、终止 SSL/TLS，以及基于名称的虚拟托管。 -[Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers) +[Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers) 通常负责通过负载均衡器来实现 Ingress，尽管它也可以配置边缘路由器或其他前端来帮助处理流量。 Ingress 不会公开任意端口或协议。 将 HTTP 和 HTTPS 以外的服务公开到 Internet 时，通常使用 -[Service.Type=NodePort](/zh/docs/concepts/services-networking/service/#type-nodeport) -或 [Service.Type=LoadBalancer](/zh/docs/concepts/services-networking/service/#loadbalancer) +[Service.Type=NodePort](/zh-cn/docs/concepts/services-networking/service/#type-nodeport) +或 [Service.Type=LoadBalancer](/zh-cn/docs/concepts/services-networking/service/#loadbalancer) 类型的 Service。 ## 环境准备 -你必须拥有一个 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers) 才能满足 Ingress 的要求。 +你必须拥有一个 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers) 才能满足 Ingress 的要求。 仅创建 Ingress 资源本身没有任何效果。 你可能需要部署 Ingress 控制器，例如 [ingress-nginx](https://kubernetes.github.io/ingress-nginx/deploy/)。 -你可以从许多 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers) 中进行选择。 +你可以从许多 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers) 中进行选择。 Ingress 需要指定 `apiVersion`、`kind`、 `metadata`和 `spec` 字段。 -Ingress 对象的命名必须是合法的 [DNS 子域名名称](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 -关于如何使用配置文件，请参见[部署应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)、 -[配置容器](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/)、 -[管理资源](/zh/docs/concepts/cluster-administration/manage-deployment/)。 +Ingress 对象的命名必须是合法的 [DNS 子域名名称](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 +关于如何使用配置文件，请参见[部署应用](/zh-cn/docs/tasks/run-application/run-stateless-application-deployment/)、 +[配置容器](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/)、 +[管理资源](/zh-cn/docs/concepts/cluster-administration/manage-deployment/)。 Ingress 经常使用注解（annotations）来配置一些选项，具体取决于 Ingress 控制器，例如[重写目标注解](https://github.com/kubernetes/ingress-nginx/blob/master/docs/examples/rewrite/README.md)。 -不同的 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)支持不同的注解。 +不同的 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers)支持不同的注解。 查看你所选的 Ingress 控制器的文档，以了解其支持哪些注解。 {{< note >}} -取决于你所使用的 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)， -你可能需要创建默认 HTTP 后端[服务](/zh/docs/concepts/services-networking/service/)。 +取决于你所使用的 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers)， +你可能需要创建默认 HTTP 后端[服务](/zh-cn/docs/concepts/services-networking/service/)。 {{< /note >}} 值得注意的是，尽管健康检查不是通过 Ingress 直接暴露的，在 Kubernetes 中存在并行的概念，比如 -[就绪检查](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)， +[就绪检查](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)， 允许你实现相同的目的。 请检查特定控制器的说明文档（[nginx](https://git.k8s.io/ingress-nginx/README.md)、 [GCE](https://git.k8s.io/ingress-gce/README.md#health-checks)）以了解它们是怎样处理健康检查的。 @@ -1000,7 +1000,7 @@ Please check the documentation of the relevant [Ingress controller](/docs/concep ## 跨可用区失败 {#failing-across-availability-zones} 不同的云厂商使用不同的技术来实现跨故障域的流量分布。详情请查阅相关 Ingress 控制器的文档。 -请查看相关 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers)的文档以了解详细信息。 +请查看相关 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers)的文档以了解详细信息。 -* 使用 [Service.Type=LoadBalancer](/zh/docs/concepts/services-networking/service/#loadbalancer) -* 使用 [Service.Type=NodePort](/zh/docs/concepts/services-networking/service/#nodeport) +* 使用 [Service.Type=LoadBalancer](/zh-cn/docs/concepts/services-networking/service/#loadbalancer) +* 使用 [Service.Type=NodePort](/zh-cn/docs/concepts/services-networking/service/#nodeport) ## {{% heading "whatsnext" %}} @@ -1026,6 +1026,6 @@ You can expose a Service in multiple ways that don't directly involve the Ingres * [Set up Ingress on Minikube with the NGINX Controller](/docs/tasks/access-application-cluster/ingress-minikube/) --> * 进一步了解 [Ingress](/docs/reference/kubernetes-api/service-resources/ingress-v1/) API -* 进一步了解 [Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers/) -* [使用 NGINX 控制器在 Minikube 上安装 Ingress](/zh/docs/tasks/access-application-cluster/ingress-minikube/) +* 进一步了解 [Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers/) +* [使用 NGINX 控制器在 Minikube 上安装 Ingress](/zh-cn/docs/tasks/access-application-cluster/ingress-minikube/) diff --git a/content/zh-cn/docs/concepts/services-networking/network-policies.md b/content/zh-cn/docs/concepts/services-networking/network-policies.md index ef2884c281..88bbebdfaa 100644 --- a/content/zh-cn/docs/concepts/services-networking/network-policies.md +++ b/content/zh-cn/docs/concepts/services-networking/network-policies.md @@ -58,7 +58,7 @@ Network policies are implemented by the [network plugin](/docs/concepts/extend-k --> ## 前置条件 {#prerequisites} -网络策略通过[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) +网络策略通过[网络插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) 来实现。要使用网络策略，你必须使用支持 NetworkPolicy 的网络解决方案。 创建一个 NetworkPolicy 资源对象而没有控制器来使它生效的话，是没有任何作用的。 @@ -144,8 +144,8 @@ __podSelector__: Each NetworkPolicy includes a `podSelector` which selects the g --> __必需字段__：与所有其他的 Kubernetes 配置一样，NetworkPolicy 需要 `apiVersion`、 `kind` 和 `metadata` 字段。关于配置文件操作的一般信息，请参考 -[配置 Pod 以使用 ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/), -和[对象管理](/zh/docs/concepts/overview/working-with-objects/object-management)。 +[配置 Pod 以使用 ConfigMap](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/), +和[对象管理](/zh-cn/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) 中包含了在一个名字空间中定义特定网络策略所需的所有信息。 @@ -204,7 +204,7 @@ See the [Declare Network Policy](/docs/tasks/administer-cluster/declare-network- 3. （Egress 规则）允许 “default” 命名空间中任何带有标签 “role=db” 的 Pod 到 CIDR 10.0.0.0/24 下 5978 TCP 端口的连接。 -参阅[声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/)演练 +参阅[声明网络策略](/zh-cn/docs/tasks/administer-cluster/declare-network-policy/)演练 了解更多示例。 你的集群所使用的 {{< glossary_tooltip text="CNI" term_id="cni" >}} 插件 必须支持在 NetworkPolicy 规约中使用 `endPort` 字段。 -如果你的[网络插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) +如果你的[网络插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) 不支持 `endPort` 字段，而你指定了一个包含 `endPort` 字段的 NetworkPolicy， 策略只对单个 `port` 字段生效。 {{< /note >}} @@ -530,7 +530,7 @@ While NetworkPolicy cannot target a namespace by its name with some object field standardized label to target a specific namespace. --> 只要 `NamespaceDefaultLabelName` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) 被启用，Kubernetes 控制面会在所有名字空间上设置一个不可变更的标签 `kubernetes.io/metadata.name`。该标签的值是名字空间的名称。 @@ -540,11 +540,11 @@ standardized label to target a specific namespace. ## 通过网络策略（至少目前还）无法完成的工作 {#what-you-can-t-do-with-network-policies-at-least-not-yet} -到 Kubernetes {{< skew latestVersion >}} 为止，NetworkPolicy API 还不支持以下功能，不过 +到 Kubernetes {{< skew currentVersion >}} 为止，NetworkPolicy API 还不支持以下功能，不过 你可能可以使用操作系统组件（如 SELinux、OpenVSwitch、IPTables 等等） 或者第七层技术（Ingress 控制器、服务网格实现）或准入控制器来实现一些 替代方案。 @@ -588,7 +588,7 @@ As of Kubernetes {{< skew latestVersion >}}, the following functionality does no walkthrough for further examples. - See more [recipes](https://github.com/ahmetb/kubernetes-network-policy-recipes) for common scenarios enabled by the NetworkPolicy resource. --> -- 参阅[声明网络策略](/zh/docs/tasks/administer-cluster/declare-network-policy/) +- 参阅[声明网络策略](/zh-cn/docs/tasks/administer-cluster/declare-network-policy/) 演练了解更多示例； - 有关 NetworkPolicy 资源所支持的常见场景的更多信息，请参见 [此指南](https://github.com/ahmetb/kubernetes-network-policy-recipes)。 diff --git a/content/zh-cn/docs/concepts/services-networking/service-topology.md b/content/zh-cn/docs/concepts/services-networking/service-topology.md index 4ab71cee41..e899786565 100644 --- a/content/zh-cn/docs/concepts/services-networking/service-topology.md +++ b/content/zh-cn/docs/concepts/services-networking/service-topology.md @@ -25,7 +25,7 @@ introduced in Kubernetes v1.21, provide similar functionality. --> 此功能特性，尤其是 Alpha 阶段的 `topologyKeys` API，在 Kubernetes v1.21 版本中已被废弃。Kubernetes v1.21 版本中引入的 -[拓扑感知的提示](/zh/docs/concepts/services-networking/topology-aware-hints/), +[拓扑感知的提示](/zh-cn/docs/concepts/services-networking/topology-aware-hints/), 提供类似的功能。 {{}} @@ -104,7 +104,7 @@ as the last value in the list. ## 使用服务拓扑 {#using-service-topology} 如果集群启用了 `ServiceTopology` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)， 你就可以在 Service 规约中设定 `topologyKeys` 字段，从而控制其流量路由。 此字段是 `Node` 标签的优先顺序字段，将用于在访问这个 `Service` 时对端点进行排序。 流量会被定向到第一个标签值和源 `Node` 标签值相匹配的 `Node`。 @@ -300,6 +300,6 @@ spec: * Read about [enabling Service Topology](/docs/tasks/administer-cluster/enabling-service-topology) * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) --> -* 阅读关于[启用服务拓扑](/zh/docs/tasks/administer-cluster/enabling-service-topology/) -* 阅读[用服务连接应用程序](/zh/docs/concepts/services-networking/connect-applications-service/) +* 阅读关于[启用服务拓扑](/zh-cn/docs/tasks/administer-cluster/enabling-service-topology/) +* 阅读[用服务连接应用程序](/zh-cn/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/zh-cn/docs/concepts/services-networking/service-traffic-policy.md b/content/zh-cn/docs/concepts/services-networking/service-traffic-policy.md index dad9dcc79b..b291c17758 100644 --- a/content/zh-cn/docs/concepts/services-networking/service-traffic-policy.md +++ b/content/zh-cn/docs/concepts/services-networking/service-traffic-policy.md @@ -43,7 +43,7 @@ When the feature is enabled, you can enable the internal-only traffic policy for This tells kube-proxy to only use node local endpoints for cluster internal traffic. --> `ServiceInternalTrafficPolicy` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) 是 Beta 功能，默认启用。 +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) 是 Beta 功能，默认启用。 启用该功能后，你就可以通过将 {{< glossary_tooltip text="Services" term_id="service" >}} 的 `.spec.internalTrafficPolicy` 项设置为 `Local`， 来为它指定一个内部专用的流量策略。 @@ -99,7 +99,7 @@ When the [feature gate](/docs/reference/command-line-tools-reference/feature-gat kube-proxy 基于 `spec.internalTrafficPolicy` 的设置来过滤路由的目标服务端点。 当它的值设为 `Local` 时，只选择节点本地的服务端点。 当它的值设为 `Cluster` 或缺省时，则选择所有的服务端点。 -启用[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +启用[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) `ServiceInternalTrafficPolicy` 后， `spec.internalTrafficPolicy` 的值默认设为 `Cluster`。 @@ -123,6 +123,6 @@ kube-proxy 基于 `spec.internalTrafficPolicy` 的设置来过滤路由的目标 * Read about [Service External Traffic Policy](/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip) * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) --> -* 请阅读[拓扑感知提示](/zh/docs/concepts/services-networking/topology-aware-hints) -* 请阅读[Service 的外部流量策略](/zh/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip) -* 请阅读[用 Service 连接应用](/zh/docs/concepts/services-networking/connect-applications-service/) +* 请阅读[拓扑感知提示](/zh-cn/docs/concepts/services-networking/topology-aware-hints) +* 请阅读[Service 的外部流量策略](/zh-cn/docs/tasks/access-application-cluster/create-external-load-balancer/#preserving-the-client-source-ip) +* 请阅读[用 Service 连接应用](/zh-cn/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/zh-cn/docs/concepts/services-networking/service.md b/content/zh-cn/docs/concepts/services-networking/service.md index 71140bf426..bedb122737 100644 --- a/content/zh-cn/docs/concepts/services-networking/service.md +++ b/content/zh-cn/docs/concepts/services-networking/service.md @@ -320,7 +320,7 @@ The name of the Endpoints object must be a valid [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). --> Endpoints 对象的名称必须是合法的 -[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)。 如果你启用了 kube-proxy 的 `ProxyTerminatingEndpoints` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)， kube-proxy 会检查节点是否有本地的端点，以及是否所有的本地端点都被标记为终止中。 -你可以（几乎总是应该）使用[附加组件](/zh/docs/concepts/cluster-administration/addons/) +你可以（几乎总是应该）使用[附加组件](/zh-cn/docs/concepts/cluster-administration/addons/) 为 Kubernetes 集群设置 DNS 服务。 支持集群的 DNS 服务器（例如 CoreDNS）监视 Kubernetes API 中的新服务，并为每个服务创建一组 DNS 记录。 @@ -905,7 +905,7 @@ Kubernetes 还支持命名端口的 DNS SRV（服务）记录。 Kubernetes DNS 服务器是唯一的一种能够访问 `ExternalName` 类型的 Service 的方式。 更多关于 `ExternalName` 信息可以查看 -[DNS Pod 和 Service](/zh/docs/concepts/services-networking/dns-pod-service/)。 +[DNS Pod 和 Service](/zh-cn/docs/concepts/services-networking/dns-pod-service/)。 -你也可以使用 [Ingress](/zh/docs/concepts/services-networking/ingress/) 来暴露自己的服务。 +你也可以使用 [Ingress](/zh-cn/docs/concepts/services-networking/ingress/) 来暴露自己的服务。 Ingress 不是一种服务类型，但它充当集群的入口点。 它可以将路由规则整合到一个资源中，因为它可以在同一IP地址下公开多个服务。 @@ -1407,6 +1407,17 @@ metadata: [...] ``` +{{% /tab %}} +{{% tab name="OCI" %}} + +```yaml +[...] +metadata: + name: my-service + annotations: + service.beta.kubernetes.io/oci-load-balancer-internal: true +[...] +``` {{% /tab %}} {{< /tabs >}} @@ -1735,10 +1746,10 @@ groups are modified with the following IP rules: --> 为了获得均衡流量，请使用 DaemonSet 或指定 -[Pod 反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) +[Pod 反亲和性](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) 使其不在同一节点上。 -你还可以将 NLB 服务与[内部负载平衡器](/zh/docs/concepts/services-networking/service/#internal-load-balancer) +你还可以将 NLB 服务与[内部负载平衡器](/zh-cn/docs/concepts/services-networking/service/#internal-load-balancer) 注解一起使用。 为了使客户端流量能够到达 NLB 后面的实例，使用以下 IP 规则修改了节点安全组： @@ -2089,7 +2100,7 @@ assigned from the lower band. This allows users to use the lower band of the `service-cluster-ip-range` for their Services with static IPs assigned with a very low risk of running into conflicts. --> -如果启用 `ServiceIPStaticSubrange`[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， +如果启用 `ServiceIPStaticSubrange`[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)， 分配策略根据配置的 `service-cluster-ip-range` 的大小，使用以下公式 `min(max(16, cidrSize / 16), 256)` 进行划分，该公式可描述为 “在不小于 16 且不大于 256 之间有一个步进量（Graduated Step）”，将 @@ -2351,7 +2362,7 @@ followed by the data from the client. * Read about [Ingress](/docs/concepts/services-networking/ingress/) * Read about [Endpoint Slices](/docs/concepts/services-networking/endpoint-slices/) --> -* 阅读[使用服务访问应用](/zh/docs/concepts/services-networking/connect-applications-service/) -* 阅读了解 [Ingress](/zh/docs/concepts/services-networking/ingress/) -* 阅读了解[端点切片（Endpoint Slices）](/zh/docs/concepts/services-networking/endpoint-slices/) +* 阅读[使用服务访问应用](/zh-cn/docs/concepts/services-networking/connect-applications-service/) +* 阅读了解 [Ingress](/zh-cn/docs/concepts/services-networking/ingress/) +* 阅读了解[端点切片（Endpoint Slices）](/zh-cn/docs/concepts/services-networking/endpoint-slices/) diff --git a/content/zh-cn/docs/concepts/services-networking/topology-aware-hints.md b/content/zh-cn/docs/concepts/services-networking/topology-aware-hints.md index f0b28aca2a..a867c2a537 100644 --- a/content/zh-cn/docs/concepts/services-networking/topology-aware-hints.md +++ b/content/zh-cn/docs/concepts/services-networking/topology-aware-hints.md @@ -41,7 +41,7 @@ by default. To try out this feature, you have to enable the `TopologyAwareHints` {{< note >}} “拓扑感知提示”特性处于 Beta 阶段，并且默认情况下**未**启用。 要试用此特性，你必须启用 `TopologyAwareHints` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。 {{< /note >}} @@ -117,7 +117,7 @@ as many endpoints to the zone with 2 CPU cores. 此特性开启后，EndpointSlice 控制器负责在 EndpointSlice 上设置提示信息。 控制器按比例给每个区域分配一定比例数量的端点。 这个比例来源于此区域中运行节点的 -[可分配](/zh/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) +[可分配](/zh-cn/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable) CPU 核心数。 例如，如果一个区域拥有 2 CPU 核心，而另一个区域只有 1 CPU 核心， 那控制器将给那个有 2 CPU 的区域分配两倍数量的端点。 @@ -292,4 +292,4 @@ Kubernetes 控制平面和每个节点上的 kube-proxy，在使用拓扑感知 * Read [Connecting Applications with Services](/docs/concepts/services-networking/connect-applications-service/) --> -* 参阅[通过服务连通应用](/zh/docs/concepts/services-networking/connect-applications-service/) +* 参阅[通过服务连通应用](/zh-cn/docs/concepts/services-networking/connect-applications-service/) diff --git a/content/zh-cn/docs/concepts/services-networking/windows-networking.md b/content/zh-cn/docs/concepts/services-networking/windows-networking.md index b6a7662461..ea2df2e815 100644 --- a/content/zh-cn/docs/concepts/services-networking/windows-networking.md +++ b/content/zh-cn/docs/concepts/services-networking/windows-networking.md @@ -42,7 +42,7 @@ is responsible for the management of networking resources such as: --> ## Windows 容器网络 {#networking} -Windows 容器网络通过 [CNI 插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)暴露。 +Windows 容器网络通过 [CNI 插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/)暴露。 Windows 容器网络的工作方式与虚拟机类似。 每个容器都有一个连接到 Hyper-V 虚拟交换机（vSwitch）的虚拟网络适配器（vNIC）。 主机网络服务（Host Networking Service，HNS）和主机计算服务（Host Comute Service，HCS） diff --git a/content/zh-cn/docs/concepts/storage/dynamic-provisioning.md b/content/zh-cn/docs/concepts/storage/dynamic-provisioning.md index f673dfa5f5..f256992599 100644 --- a/content/zh-cn/docs/concepts/storage/dynamic-provisioning.md +++ b/content/zh-cn/docs/concepts/storage/dynamic-provisioning.md @@ -23,7 +23,7 @@ automatically provisions storage when it is requested by users. 动态卷供应允许按需创建存储卷。 如果没有动态供应，集群管理员必须手动地联系他们的云或存储提供商来创建新的存储卷， 然后在 Kubernetes 集群创建 -[`PersistentVolume` 对象](/zh/docs/concepts/storage/persistent-volumes/)来表示这些卷。 +[`PersistentVolume` 对象](/zh-cn/docs/concepts/storage/persistent-volumes/)来表示这些卷。 动态供应功能消除了集群管理员预先配置存储的需要。 相反，它在用户请求时自动供应存储。 @@ -58,7 +58,7 @@ have the ability to select from multiple storage options. More information on storage classes can be found [here](/docs/concepts/storage/storage-classes/). --> -点击[这里](/zh/docs/concepts/storage/storage-classes/)查阅有关存储类的更多信息。 +点击[这里](/zh-cn/docs/concepts/storage/storage-classes/)查阅有关存储类的更多信息。 要启用动态供应功能，集群管理员需要为用户预先创建一个或多个 `StorageClass` 对象。 `StorageClass` 对象定义当动态供应被调用时，哪一个驱动将被使用和哪些参数将被传递给驱动。 -StorageClass 对象的名字必须是一个合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 +StorageClass 对象的名字必须是一个合法的 [DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 以下清单创建了一个 `StorageClass` 存储类 "slow"，它提供类似标准磁盘的永久磁盘。 ```yaml @@ -172,7 +172,7 @@ can enable this behavior by: is enabled on the API server. --> - 标记一个 `StorageClass` 为 *默认*； -- 确保 [`DefaultStorageClass` 准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)在 API 服务端被启用。 +- 确保 [`DefaultStorageClass` 准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)在 API 服务端被启用。 -在[多区域](/zh/docs/setup/best-practices/multiple-zones/)集群中，Pod 可以被分散到多个区域。 +在[多区域](/zh-cn/docs/setup/best-practices/multiple-zones/)集群中，Pod 可以被分散到多个区域。 单区域存储后端应该被供应到 Pod 被调度到的区域。 -这可以通过设置[卷绑定模式](/zh/docs/concepts/storage/storage-classes/#volume-binding-mode)来实现。 +这可以通过设置[卷绑定模式](/zh-cn/docs/concepts/storage/storage-classes/#volume-binding-mode)来实现。 diff --git a/content/zh-cn/docs/concepts/storage/ephemeral-volumes.md b/content/zh-cn/docs/concepts/storage/ephemeral-volumes.md index f92c561bdb..2e7c7980df 100644 --- a/content/zh-cn/docs/concepts/storage/ephemeral-volumes.md +++ b/content/zh-cn/docs/concepts/storage/ephemeral-volumes.md @@ -23,7 +23,7 @@ with [volumes](/docs/concepts/storage/volumes/) is suggested, in particular PersistentVolumeClaim and PersistentVolume. --> 本文档描述 Kubernetes 中的 _临时卷（Ephemeral Volume）_。 -建议先了解[卷](/zh/docs/concepts/storage/volumes/)，特别是 PersistentVolumeClaim 和 PersistentVolume。 +建议先了解[卷](/zh-cn/docs/concepts/storage/volumes/)，特别是 PersistentVolumeClaim 和 PersistentVolume。 Kubernetes 为了不同的目的，支持几种不同类型的临时卷： -- [emptyDir](/zh/docs/concepts/storage/volumes/#emptydir)： +- [emptyDir](/zh-cn/docs/concepts/storage/volumes/#emptydir)： Pod 启动时为空，存储空间来自本地的 kubelet 根目录（通常是根磁盘）或内存 -- [configMap](/zh/docs/concepts/storage/volumes/#configmap)、 - [downwardAPI](/zh/docs/concepts/storage/volumes/#downwardapi)、 - [secret](/zh/docs/concepts/storage/volumes/#secret)： +- [configMap](/zh-cn/docs/concepts/storage/volumes/#configmap)、 + [downwardAPI](/zh-cn/docs/concepts/storage/volumes/#downwardapi)、 + [secret](/zh-cn/docs/concepts/storage/volumes/#secret)： 将不同类型的 Kubernetes 数据注入到 Pod 中 -- [CSI 临时卷](/zh/docs/concepts/storage/volumes/#csi-ephemeral-volumes)： +- [CSI 临时卷](/zh-cn/docs/concepts/storage/volumes/#csi-ephemeral-volumes)： 类似于前面的卷类型，但由专门[支持此特性](https://kubernetes-csi.github.io/docs/drivers.html) 的指定 [CSI 驱动程序](https://github.com/container-storage-interface/spec/blob/master/spec.md)提供 @@ -103,7 +103,7 @@ CSI ephemeral volumes *must* be provided by third-party CSI storage drivers. --> `emptyDir`、`configMap`、`downwardAPI`、`secret` 是作为 -[本地临时存储](/zh/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage) +[本地临时存储](/zh-cn/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage) 提供的。它们由各个节点上的 kubelet 管理。 CSI 临时卷 *必须* 由第三方 CSI 存储驱动程序提供。 @@ -144,7 +144,7 @@ shows which drivers support ephemeral volumes. --> 该特性需要启用参数 `CSIInlineVolume` -[特性门控（feature gate）](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 +[特性门控（feature gate）](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。 该参数从 Kubernetes 1.16 开始默认启用。 {{< note >}} @@ -171,7 +171,7 @@ Here's an example manifest for a Pod that uses CSI ephemeral storage: 从概念上讲，CSI 临时卷类似于 `configMap`、`downwardAPI` 和 `secret` 类型的卷： 其存储在每个节点本地管理，并在将 Pod 调度到节点后与其他本地资源一起创建。 在这个阶段，Kubernetes 没有重新调度 Pods 的概念。卷创建不太可能失败，否则 Pod 启动将会受阻。 -特别是，这些卷 **不** 支持[感知存储容量的 Pod 调度](/zh/docs/concepts/storage/storage-capacity/)。 +特别是，这些卷 **不** 支持[感知存储容量的 Pod 调度](/zh-cn/docs/concepts/storage/storage-capacity/)。 它们目前也没包括在 Pod 的存储资源使用限制中，因为 kubelet 只能对它自己管理的存储强制执行。 下面是使用 CSI 临时存储的 Pod 的示例清单： @@ -226,7 +226,7 @@ CSI 临时卷允许用户直接向 CSI 驱动程序提供 `volumeAttributes`， 例如，通常在 StorageClass 中定义的参数不应通过使用内联临时卷向用户公开。 作为一个集群管理员，你可以使用 -[PodSecurityPolicy](/zh/docs/concepts/security/pod-security-policy/) +[PodSecurityPolicy](/zh-cn/docs/concepts/security/pod-security-policy/) 来控制在 Pod 中可以使用哪些 CSI 驱动程序， 具体则是通过 [`allowedCSIDrivers` 字段](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicyspec-v1beta1-policy) 指定。 @@ -239,7 +239,7 @@ allowed to be used as inline volumes within a Pod spec may do so by: --> 如果集群管理员需要限制 CSI 驱动程序在 Pod 规约中被作为内联卷使用，可以这样做： - 从 CSIDriver 规约的 `volumeLifecycleModes` 中删除 `Ephemeral`，这可以防止驱动程序被用作内联临时卷。 -- 使用[准入 Webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/) +- 使用[准入 Webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/) 来限制如何使用此驱动程序。 -就[资源所有权](/zh/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)而言， +就[资源所有权](/zh-cn/docs/concepts/workloads/controllers/garbage-collection/#owners-and-dependents)而言， 拥有通用临时存储的 Pod 是提供临时存储 (ephemeral storage) 的 PersistentVolumeClaim 的所有者。 当 Pod 被删除时，Kubernetes 垃圾收集器会删除 PVC， 然后 PVC 通常会触发卷的删除，因为存储类的默认回收策略是删除卷。 @@ -436,7 +436,7 @@ use an [admission webhook](/docs/reference/access-authn-authz/extensible-admissi 启用 GenericEphemeralVolume 特性会导致那些没有 PVCs 创建权限的用户， 在创建 Pods 时，被允许间接的创建 PVCs。 集群管理员必须意识到这一点。 -如果这不符合他们的安全模型，他们应该使用一个[准入 Webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/) +如果这不符合他们的安全模型，他们应该使用一个[准入 Webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/) 拒绝包含通用临时卷的 Pods。 -[为 PVC 卷所设置的逐名字空间的配额](/zh/docs/concepts/policy/resource-quotas/#storage-resource-quota) +[为 PVC 卷所设置的逐名字空间的配额](/zh-cn/docs/concepts/policy/resource-quotas/#storage-resource-quota) 仍然有效，因此即使允许用户使用这种新机制，他们也不能使用它来规避其他策略。 ## {{% heading "whatsnext" %}} @@ -456,7 +456,7 @@ See [local ephemeral storage](/docs/concepts/configuration/manage-resources-cont --> ### kubelet 管理的临时卷 {#ephemeral-volumes-managed-by-kubelet} -参阅[本地临时存储](/zh/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage)。 +参阅[本地临时存储](/zh-cn/docs/concepts/configuration/manage-resources-containers/#local-ephemeral-storage)。 本文描述 Kubernetes 中的 _持久卷（Persistent Volume）_ 。 -建议先熟悉[卷（Volume）](/zh/docs/concepts/storage/volumes/)的概念。 +建议先熟悉[卷（Volume）](/zh-cn/docs/concepts/storage/volumes/)的概念。 @@ -52,7 +52,7 @@ PersistentVolumeClaim。 A _PersistentVolume_ (PV) is a piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned using [Storage Classes](/docs/concepts/storage/storage-classes/). It is a resource in the cluster just like a node is a cluster resource. PVs are volume plugins like Volumes, but have a lifecycle independent of any individual Pod that uses the PV. This API object captures the details of the implementation of the storage, be that NFS, iSCSI, or a cloud-provider-specific storage system. --> 持久卷（PersistentVolume，PV）是集群中的一块存储，可以由管理员事先供应，或者 -使用[存储类（Storage Class）](/zh/docs/concepts/storage/storage-classes/)来动态供应。 +使用[存储类（Storage Class）](/zh-cn/docs/concepts/storage/storage-classes/)来动态供应。 持久卷是集群资源，就像节点也是集群资源一样。PV 持久卷和普通的 Volume 一样，也是使用 卷插件来实现的，只是它们拥有独立于任何使用 PV 的 Pod 的生命周期。 此 API 对象中记述了存储的实现细节，无论其背后是 NFS、iSCSI 还是特定于云平台的存储系统。 @@ -77,7 +77,7 @@ See the [detailed walkthrough with working examples](/docs/tasks/configure-pod-c 仅限于卷大小和访问模式，同时又不能将卷是如何实现的这些细节暴露给用户。 为了满足这类需求，就有了 _存储类（StorageClass）_ 资源。 -参见[基于运行示例的详细演练](/zh/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)。 +参见[基于运行示例的详细演练](/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)。 为了基于存储类完成动态的存储供应，集群管理员需要在 API 服务器上启用 -`DefaultStorageClass` [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)。 +`DefaultStorageClass` [准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass)。 举例而言，可以通过保证 `DefaultStorageClass` 出现在 API 服务器组件的 `--enable-admission-plugins` 标志值中实现这点；该标志的值可以是逗号 分隔的有序列表。关于 API 服务器标志的更多信息，可以参考 -[kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/) +[kube-apiserver](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/) 文档。 不过，管理员可以按 -[参考资料](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) +[参考资料](/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/) 中所述，使用 Kubernetes 控制器管理器命令行参数来配置一个定制的回收器（Recycler） Pod 模板。此定制的回收器 Pod 模板必须包含一个 `volumes` 规约，如下例所示： @@ -484,7 +484,7 @@ The control plane still checks that [storage class](/docs/concepts/storage/stora --> 绑定操作不会考虑某些卷匹配条件是否满足，包括节点亲和性等等。 控制面仍然会检查 -[存储类](/zh/docs/concepts/storage/storage-classes/)、访问模式和所请求的 +[存储类](/zh-cn/docs/concepts/storage/storage-classes/)、访问模式和所请求的 存储尺寸都是合法的。 ```yaml @@ -720,7 +720,7 @@ Recovery from failing PVC expansion by users is available as an alpha feature si {{< note >}} Kubernetes 从 1.23 版本开始将允许用户恢复失败的 PVC 扩展这一能力作为 alpha 特性支持。 `RecoverVolumeExpansionFailure` 必须被启用以允许使用此特性。 -可参考[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +可参考[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) 文档了解更多信息。 {{< /note >}} @@ -787,23 +787,23 @@ PV 持久卷是用插件的形式来实现的。Kubernetes 目前支持以下插 * [`rbd`](/docs/concepts/storage/volumes/#rbd) - Rados Block Device (RBD) volume * [`vsphereVolume`](/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK volume --> -* [`awsElasticBlockStore`](/zh/docs/concepts/storage/volumes/#awselasticblockstore) - AWS 弹性块存储（EBS） -* [`azureDisk`](/zh/docs/concepts/storage/volumes/#azuredisk) - Azure Disk -* [`azureFile`](/zh/docs/concepts/storage/volumes/#azurefile) - Azure File -* [`cephfs`](/zh/docs/concepts/storage/volumes/#cephfs) - CephFS volume -* [`csi`](/zh/docs/concepts/storage/volumes/#csi) - 容器存储接口 (CSI) -* [`fc`](/zh/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) 存储 -* [`gcePersistentDisk`](/zh/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE 持久化盘 -* [`glusterfs`](/zh/docs/concepts/storage/volumes/#glusterfs) - Glusterfs 卷 -* [`hostPath`](/zh/docs/concepts/storage/volumes/#hostpath) - HostPath 卷 +* [`awsElasticBlockStore`](/zh-cn/docs/concepts/storage/volumes/#awselasticblockstore) - AWS 弹性块存储（EBS） +* [`azureDisk`](/zh-cn/docs/concepts/storage/volumes/#azuredisk) - Azure Disk +* [`azureFile`](/zh-cn/docs/concepts/storage/volumes/#azurefile) - Azure File +* [`cephfs`](/zh-cn/docs/concepts/storage/volumes/#cephfs) - CephFS volume +* [`csi`](/zh-cn/docs/concepts/storage/volumes/#csi) - 容器存储接口 (CSI) +* [`fc`](/zh-cn/docs/concepts/storage/volumes/#fc) - Fibre Channel (FC) 存储 +* [`gcePersistentDisk`](/zh-cn/docs/concepts/storage/volumes/#gcepersistentdisk) - GCE 持久化盘 +* [`glusterfs`](/zh-cn/docs/concepts/storage/volumes/#glusterfs) - Glusterfs 卷 +* [`hostPath`](/zh-cn/docs/concepts/storage/volumes/#hostpath) - HostPath 卷 （仅供单节点测试使用；不适用于多节点集群； 请尝试使用 `local` 卷作为替代） -* [`iscsi`](/zh/docs/concepts/storage/volumes/#iscsi) - iSCSI (SCSI over IP) 存储 -* [`local`](/zh/docs/concepts/storage/volumes/#local) - 节点上挂载的本地存储设备 -* [`nfs`](/zh/docs/concepts/storage/volumes/#nfs) - 网络文件系统 (NFS) 存储 -* [`portworxVolume`](/zh/docs/concepts/storage/volumes/#portworxvolume) - Portworx 卷 -* [`rbd`](/zh/docs/concepts/storage/volumes/#rbd) - Rados 块设备 (RBD) 卷 -* [`vsphereVolume`](/zh/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK 卷 +* [`iscsi`](/zh-cn/docs/concepts/storage/volumes/#iscsi) - iSCSI (SCSI over IP) 存储 +* [`local`](/zh-cn/docs/concepts/storage/volumes/#local) - 节点上挂载的本地存储设备 +* [`nfs`](/zh-cn/docs/concepts/storage/volumes/#nfs) - 网络文件系统 (NFS) 存储 +* [`portworxVolume`](/zh-cn/docs/concepts/storage/volumes/#portworxvolume) - Portworx 卷 +* [`rbd`](/zh-cn/docs/concepts/storage/volumes/#rbd) - Rados 块设备 (RBD) 卷 +* [`vsphereVolume`](/zh-cn/docs/concepts/storage/volumes/#vspherevolume) - vSphere VMDK 卷 {{< note >}} 对大多数类型的卷而言，你不需要设置节点亲和性字段。 -[AWS EBS](/zh/docs/concepts/storage/volumes/#awselasticblockstore)、 -[GCE PD](/zh/docs/concepts/storage/volumes/#gcepersistentdisk) 和 -[Azure Disk](/zh/docs/concepts/storage/volumes/#azuredisk) 卷类型都能 +[AWS EBS](/zh-cn/docs/concepts/storage/volumes/#awselasticblockstore)、 +[GCE PD](/zh-cn/docs/concepts/storage/volumes/#gcepersistentdisk) 和 +[Azure Disk](/zh-cn/docs/concepts/storage/volumes/#azuredisk) 卷类型都能 自动设置相关字段。 -你需要为 [local](/zh/docs/concepts/storage/volumes/#local) 卷显式地设置 +你需要为 [local](/zh-cn/docs/concepts/storage/volumes/#local) 卷显式地设置 此属性。 {{< /note >}} @@ -1221,7 +1221,7 @@ The name of a PersistentVolumeClaim object must be a valid --> 每个 PVC 对象都有 `spec` 和 `status` 部分，分别对应申领的规约和状态。 PersistentVolumeClaim 对象的名称必须是合法的 -[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). ```yaml @@ -1280,7 +1280,7 @@ Claims can specify a [label selector](/docs/concepts/overview/working-with-objec --> ### 选择算符 {#selector} -申领可以设置[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors) +申领可以设置[标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors) 来进一步过滤卷集合。只有标签与选择算符相匹配的卷能够绑定到申领上。 选择算符包含两个字段： @@ -1309,7 +1309,7 @@ be bound to the PVC. ### 类 {#class} 申领可以通过为 `storageClassName` 属性设置 -[StorageClass](/zh/docs/concepts/storage/storage-classes/) 的名称来请求特定的存储类。 +[StorageClass](/zh-cn/docs/concepts/storage/storage-classes/) 的名称来请求特定的存储类。 只有所请求的类的 PV 卷，即 `storageClassName` 值与 PVC 设置相同的 PV 卷， 才能绑定到 PVC 申领。 @@ -1327,7 +1327,7 @@ PVC 申领不必一定要请求某个类。如果 PVC 的 `storageClassName` 属 存储类的 PV 卷（未设置注解或者注解值为 `""` 的 PersistentVolume（PV）对象在系统中不会被删除，因为这样做可能会引起数据丢失。 未设置 `storageClassName` 的 PVC 与此大不相同，也会被集群作不同处理。 具体筛查方式取决于 -[`DefaultStorageClass` 准入控制器插件](/zh/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) +[`DefaultStorageClass` 准入控制器插件](/zh-cn/docs/reference/access-authn-authz/admission-controllers/#defaultstorageclass) 是否被启用。 卷快照（Volume Snapshot）特性的添加仅是为了支持 CSI 卷插件。 -有关细节可参阅[卷快照](/zh/docs/concepts/storage/volume-snapshots/)文档。 +有关细节可参阅[卷快照](/zh-cn/docs/concepts/storage/volume-snapshots/)文档。 要启用从卷快照数据源恢复数据卷的支持，可在 API 服务器和控制器管理器上启用 `VolumeSnapshotDataSource` 特性门控。 @@ -1757,7 +1757,7 @@ spec: --> ## 卷克隆 {#volume-cloning} -[卷克隆](/zh/docs/concepts/storage/volume-pvc-datasource/)功能特性仅适用于 +[卷克隆](/zh-cn/docs/concepts/storage/volume-pvc-datasource/)功能特性仅适用于 CSI 卷插件。 -* 进一步了解[创建持久卷](/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). +* 进一步了解[创建持久卷](/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolume). +* 进一步学习[创建 PVC 申领](/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage/#create-a-persistentvolumeclaim). * 阅读[持久存储的设计文档](https://github.com/kubernetes/design-proposals-archive/blob/main/storage/persistent-storage.md). 本文档描述 Kubernetes 中的*投射卷（Projected Volumes）*。 -建议先熟悉[卷](/zh/docs/concepts/storage/volumes/)概念。 +建议先熟悉[卷](/zh-cn/docs/concepts/storage/volumes/)概念。 @@ -42,9 +42,9 @@ Currently, the following types of volume sources can be projected: 目前，以下类型的卷源可以被投射： -* [`secret`](/zh/docs/concepts/storage/volumes/#secret) -* [`downwardAPI`](/zh/docs/concepts/storage/volumes/#downwardapi) -* [`configMap`](/zh/docs/concepts/storage/volumes/#configmap) +* [`secret`](/zh-cn/docs/concepts/storage/volumes/#secret) +* [`downwardAPI`](/zh-cn/docs/concepts/storage/volumes/#downwardapi) +* [`configMap`](/zh-cn/docs/concepts/storage/volumes/#configmap) * [`serviceAccountToken`](#serviceaccounttoken) ## serviceAccountToken 投射卷 {#serviceaccounttoken} 当 `TokenRequestProjection` 特性被启用时，你可以将当前 -[服务账号](/zh/docs/reference/access-authn-authz/authentication/#service-account-tokens) +[服务账号](/zh-cn/docs/reference/access-authn-authz/authentication/#service-account-tokens) 的令牌注入到 Pod 中特定路径下。例如： {{< codenew file="pods/storage/projected-service-account-token.yaml" >}} @@ -108,7 +108,7 @@ is optional and it defaults to the identifier of the API server. --> 示例 Pod 中包含一个投射卷，其中包含注入的服务账号令牌。 此 Pod 中的容器可以使用该令牌访问 Kubernetes API 服务器， 使用 -[pod 的 ServiceAccount](/zh/docs/tasks/configure-pod-container/configure-service-account/) +[pod 的 ServiceAccount](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/) 进行身份验证。`audience` 字段包含令牌所针对的受众。 收到令牌的主体必须使用令牌受众中所指定的某个标识符来标识自身，否则应该拒绝该令牌。 此字段是可选的，默认值为 API 服务器的标识。 @@ -130,7 +130,7 @@ of the projected volume. A container using a projected volume source as a [`subPath`](/docs/concepts/storage/volumes/#using-subpath) volume mount will not receive updates for those volume sources. --> -以 [`subPath`](/zh/docs/concepts/storage/volumes/#using-subpath) +以 [`subPath`](/zh-cn/docs/concepts/storage/volumes/#using-subpath) 形式使用投射卷源的容器无法收到对应卷源的更新。 {{< /note >}} diff --git a/content/zh-cn/docs/concepts/storage/storage-capacity.md b/content/zh-cn/docs/concepts/storage/storage-capacity.md index 7cf604cf56..c89d98e3bc 100644 --- a/content/zh-cn/docs/concepts/storage/storage-capacity.md +++ b/content/zh-cn/docs/concepts/storage/storage-capacity.md @@ -25,7 +25,7 @@ multiple scheduling retries will be needed. {{< feature-state for_k8s_version="v1.24" state="stable" >}} 本页面描述了 Kubernetes 如何跟踪存储容量以及调度程序如何为了余下的尚未挂载的卷使用该信息将 -[Pod 调度](/zh/docs/concepts/scheduling-eviction/)到能够访问到足够存储容量的节点上。 +[Pod 调度](/zh-cn/docs/concepts/scheduling-eviction/)到能够访问到足够存储容量的节点上。 如果没有跟踪存储容量，调度程序可能会选择一个没有足够容量来提供卷的节点，并且需要多次调度重试。 ## {{% heading "prerequisites" %}} @@ -100,7 +100,7 @@ significant resources there. 如果有以下情况，存储容量信息将会被 Kubernetes 调度程序使用： - Pod 使用的卷还没有被创建， - 卷使用引用了 CSI 驱动的 {{< glossary_tooltip text="StorageClass" term_id="storage-class" >}}， -并且使用了 `WaitForFirstConsumer` [卷绑定模式](/zh/docs/concepts/storage/storage-classes/#volume-binding-mode)， +并且使用了 `WaitForFirstConsumer` [卷绑定模式](/zh-cn/docs/concepts/storage/storage-classes/#volume-binding-mode)， - 驱动程序的 `CSIDriver` 对象的 `StorageCapacity` 被设置为 true。 在这种情况下，调度程序仅考虑将 Pod 调度到有足够存储容量的节点上。这个检测非常简单， @@ -109,7 +109,7 @@ significant resources there. 对于具有 `Immediate` 卷绑定模式的卷，存储驱动程序将决定在何处创建该卷，而不取决于将使用该卷的 Pod。 然后，调度程序将 Pod 调度到创建卷后可使用该卷的节点上。 -对于 [CSI 临时卷](/zh/docs/concepts/storage/volumes/#csi)，调度总是在不考虑存储容量的情况下进行。 +对于 [CSI 临时卷](/zh-cn/docs/concepts/storage/volumes/#csi)，调度总是在不考虑存储容量的情况下进行。 这是基于这样的假设：该卷类型仅由节点本地的特殊 CSI 驱动程序使用，并且不需要大量资源。 本文描述了 Kubernetes 中 StorageClass 的概念。建议先熟悉 -[卷](/zh/docs/concepts/storage/volumes/)和 -[持久卷](/zh/docs/concepts/storage/persistent-volumes)的概念。 +[卷](/zh-cn/docs/concepts/storage/volumes/)和 +[持久卷](/zh-cn/docs/concepts/storage/persistent-volumes)的概念。 @@ -74,7 +74,7 @@ for details. --> 管理员可以为没有申请绑定到特定 StorageClass 的 PVC 指定一个默认的存储类： 更多详情请参阅 -[PersistentVolumeClaim 章节](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。 +[PersistentVolumeClaim 章节](/zh-cn/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。 ```yaml apiVersion: storage.k8s.io/v1 @@ -249,7 +249,7 @@ the class or PV, If a mount option is invalid, the PV mount fails. The `volumeBindingMode` field controls when [volume binding and dynamic provisioning](/docs/concepts/storage/persistent-volumes/#provisioning) should occur. --> -`volumeBindingMode` 字段控制了[卷绑定和动态制备](/zh/docs/concepts/storage/persistent-volumes/#provisioning) +`volumeBindingMode` 字段控制了[卷绑定和动态制备](/zh-cn/docs/concepts/storage/persistent-volumes/#provisioning) 应该发生在什么时候。 -动态配置和预先创建的 PV 也支持 [CSI卷](/zh/docs/concepts/storage/volumes/#csi)， +动态配置和预先创建的 PV 也支持 [CSI卷](/zh-cn/docs/concepts/storage/volumes/#csi)， 但是你需要查看特定 CSI 驱动程序的文档以查看其支持的拓扑键名和例子。 {{< note >}} @@ -770,7 +770,7 @@ vSphere 存储类有两种制备器 [弃用](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#why-are-we-migrating-in-tree-plugins-to-csi)。 更多关于 CSI 制备器的详情，请参阅 [Kubernetes vSphere CSI 驱动](https://vsphere-csi-driver.sigs.k8s.io/) -和 [vSphereVolume CSI 迁移](/zh/docs/concepts/storage/volumes/#csi-migration-5)。 +和 [vSphereVolume CSI 迁移](/zh-cn/docs/concepts/storage/volumes/#csi-migration-5)。 在存储制备期间，为挂载凭证创建一个名为 `secretName` 的 Secret。如果集群同时启用了 -[RBAC](/zh/docs/reference/access-authn-authz/rbac/) 和 -[控制器角色](/zh/docs/reference/access-authn-authz/rbac/#controller-roles)， +[RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/) 和 +[控制器角色](/zh-cn/docs/reference/access-authn-authz/rbac/#controller-roles)， 为 `system:controller:persistent-volume-binder` 的 clusterrole 添加 `Secret` 资源的 `create` 权限。 diff --git a/content/zh-cn/docs/concepts/storage/volume-health-monitoring.md b/content/zh-cn/docs/concepts/storage/volume-health-monitoring.md index 0b7f5924a4..bf1c732fd6 100644 --- a/content/zh-cn/docs/concepts/storage/volume-health-monitoring.md +++ b/content/zh-cn/docs/concepts/storage/volume-health-monitoring.md @@ -64,7 +64,7 @@ You need to enable the `CSIVolumeHealth` [feature gate](/docs/reference/command- --> {{< note >}} 你需要启用 `CSIVolumeHealth` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)， +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)， 才能在节点上使用此特性。 {{< /note >}} diff --git a/content/zh-cn/docs/concepts/storage/volume-pvc-datasource.md b/content/zh-cn/docs/concepts/storage/volume-pvc-datasource.md index 06454b6234..d50dcdd99c 100644 --- a/content/zh-cn/docs/concepts/storage/volume-pvc-datasource.md +++ b/content/zh-cn/docs/concepts/storage/volume-pvc-datasource.md @@ -21,7 +21,7 @@ weight: 60 This document describes the concept of cloning existing CSI Volumes in Kubernetes. Familiarity with [Volumes](/docs/concepts/storage/volumes) is suggested. --> 本文档介绍 Kubernetes 中克隆现有 CSI 卷的概念。阅读前建议先熟悉 -[卷](/zh/docs/concepts/storage/volumes)。 +[卷](/zh-cn/docs/concepts/storage/volumes)。 diff --git a/content/zh-cn/docs/concepts/storage/volume-snapshot-classes.md b/content/zh-cn/docs/concepts/storage/volume-snapshot-classes.md index 8739de2d04..47f617fe11 100644 --- a/content/zh-cn/docs/concepts/storage/volume-snapshot-classes.md +++ b/content/zh-cn/docs/concepts/storage/volume-snapshot-classes.md @@ -12,8 +12,8 @@ with [volume snapshots](/docs/concepts/storage/volume-snapshots/) and [storage classes](/docs/concepts/storage/storage-classes) is suggested. --> 本文档描述了 Kubernetes 中 VolumeSnapshotClass 的概念。建议熟悉 -[卷快照（Volume Snapshots）](/zh/docs/concepts/storage/volume-snapshots/)和 -[存储类（Storage Class）](/zh/docs/concepts/storage/storage-classes)。 +[卷快照（Volume Snapshots）](/zh-cn/docs/concepts/storage/volume-snapshots/)和 +[存储类（Storage Class）](/zh-cn/docs/concepts/storage/storage-classes)。 diff --git a/content/zh-cn/docs/concepts/storage/volume-snapshots.md b/content/zh-cn/docs/concepts/storage/volume-snapshots.md index d556faafea..719bcfa2a3 100644 --- a/content/zh-cn/docs/concepts/storage/volume-snapshots.md +++ b/content/zh-cn/docs/concepts/storage/volume-snapshots.md @@ -18,7 +18,7 @@ weight: 40 In Kubernetes, a _VolumeSnapshot_ represents a snapshot of a volume on a storage system. This document assumes that you are already familiar with Kubernetes [persistent volumes](/docs/concepts/storage/persistent-volumes/). --> 在 Kubernetes 中，卷快照是一个存储系统上卷的快照，本文假设你已经熟悉了 Kubernetes -的 [持久卷](/zh/docs/concepts/storage/persistent-volumes/)。 +的 [持久卷](/zh-cn/docs/concepts/storage/persistent-volumes/)。 @@ -118,7 +118,7 @@ Instead of using a pre-existing snapshot, you can request that a snapshot to be #### 动态的 {#dynamic} 可以从 `PersistentVolumeClaim` 中动态获取快照，而不用使用已经存在的快照。 -在获取快照时，[卷快照类](/zh/docs/concepts/storage/volume-snapshot-classes/) +在获取快照时，[卷快照类](/zh-cn/docs/concepts/storage/volume-snapshot-classes/) 指定要用的特定于存储提供程序的参数。 更多详细信息，请参阅 -[卷快照和从快照还原卷](/zh/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support)。 +[卷快照和从快照还原卷](/zh-cn/docs/concepts/storage/persistent-volumes/#volume-snapshot-and-restore-volume-from-snapshot-support)。 diff --git a/content/zh-cn/docs/concepts/storage/volumes.md b/content/zh-cn/docs/concepts/storage/volumes.md index b8d0eb94ff..ebe50dd897 100644 --- a/content/zh-cn/docs/concepts/storage/volumes.md +++ b/content/zh-cn/docs/concepts/storage/volumes.md @@ -332,7 +332,7 @@ must be installed on the cluster and the `CSIMigration` and `CSIMigrationAzureFi `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/) +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) 必须被启用。 要禁止控制器管理器和 kubelet 加载树内 Cinder 插件，你可以启用 -`InTreePluginOpenStackUnregister` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 +`InTreePluginOpenStackUnregister` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。 ### configMap @@ -468,7 +468,7 @@ provides a way to inject configuration data into Pods. The data stored in a ConfigMap object can be referenced in a volume of type `configMap` and then consumed by containerized applications running in a Pod. --> -[`configMap`](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/) +[`configMap`](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/) 卷提供了向 Pod 注入配置数据的方法。 ConfigMap 对象中存储的数据可以被 `configMap` 类型的卷引用，然后被 Pod 中运行的容器化应用使用。 @@ -524,7 +524,7 @@ keyed with `log_level`. * Text data is exposed as files using the UTF-8 character encoding. For other character encodings, use `binaryData`. --> {{< note >}} -* 在使用 [ConfigMap](/zh/docs/tasks/configure-pod-container/configure-pod-configmap/) 之前你首先要创建它。 +* 在使用 [ConfigMap](/zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/) 之前你首先要创建它。 * 容器以 [subPath](#using-subpath) 卷挂载方式使用 ConfigMap 时，将无法接收 ConfigMap 的更新。 * 文本数据挂载成文件时采用 UTF-8 字符编码。如果使用其他字符编码形式，可使用 `binaryData` 字段。 @@ -550,7 +550,7 @@ receive Downward API updates. -更多详细信息请参考 [`downwardAPI` 卷示例](/zh/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)。 +更多详细信息请参考 [`downwardAPI` 卷示例](/zh-cn/docs/tasks/inject-data-application/downward-api-volume-expose-pod-information/)。 ### emptyDir @@ -612,7 +612,7 @@ backed volumes are sized to 50% of the memory on a Linux host. --> {{< note >}} -当启用 `SizeMemoryBackedVolumes` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +当启用 `SizeMemoryBackedVolumes` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) 时，你可以为基于内存提供的卷指定大小。 如果未指定大小，则基于内存的卷的大小为 Linux 主机上内存的 50％。 {{< /note>}} @@ -818,7 +818,7 @@ Before creating a PersistentVolume, you must create the PD: --> #### 手动供应基于区域 PD 的 PersistentVolume {#manually-provisioning-regional-pd-pv} -使用[为 GCE PD 定义的存储类](/zh/docs/concepts/storage/storage-classes/#gce) +使用[为 GCE PD 定义的存储类](/zh-cn/docs/concepts/storage/storage-classes/#gce) 可以实现动态供应。在创建 PersistentVolume 之前，你首先要创建 PD。 ```shell @@ -1063,7 +1063,7 @@ Watch out when using this type of volume, because: * 具有相同配置（例如基于同一 PodTemplate 创建）的多个 Pod 会由于节点上文件的不同而在不同节点上有不同的行为。 * 下层主机上创建的文件或目录只能由 root 用户写入。你需要在 - [特权容器](/zh/docs/tasks/configure-pod-container/security-context/) + [特权容器](/zh-cn/docs/tasks/configure-pod-container/security-context/) 中以 root 身份运行进程，或者修改主机上的文件权限以便容器能够写入 `hostPath` 卷。 使用 `local` 卷时，建议创建一个 StorageClass 并将其 `volumeBindingMode` 设置为 `WaitForFirstConsumer`。要了解更多详细信息，请参考 -[local StorageClass 示例](/zh/docs/concepts/storage/storage-classes/#local)。 +[local StorageClass 示例](/zh-cn/docs/concepts/storage/storage-classes/#local)。 延迟卷绑定的操作可以确保 Kubernetes 在为 PersistentVolumeClaim 作出绑定决策时，会评估 Pod 可能具有的其他节点约束，例如：如节点资源需求、节点选择器、Pod亲和性和 Pod 反亲和性。 @@ -1324,7 +1324,7 @@ A `persistentVolumeClaim` volume is used to mount a are a way for users to "claim" durable storage (such as a GCE PersistentDisk or an iSCSI volume) without knowing the details of the particular cloud environment. --> -`persistentVolumeClaim` 卷用来将[持久卷](/zh/docs/concepts/storage/persistent-volumes/)（PersistentVolume）挂载到 Pod 中。 +`persistentVolumeClaim` 卷用来将[持久卷](/zh-cn/docs/concepts/storage/persistent-volumes/)（PersistentVolume）挂载到 Pod 中。 持久卷申领（PersistentVolumeClaim）是用户在不知道特定云环境细节的情况下“申领”持久存储（例如 GCE PersistentDisk 或者 iSCSI 卷）的一种方法。 @@ -1332,7 +1332,7 @@ GCE PersistentDisk 或者 iSCSI 卷）的一种方法。 See the [PersistentVolumes example](/docs/concepts/storage/persistent-volumes/) for more details. --> -更多详情请参考[持久卷示例](/zh/docs/concepts/storage/persistent-volumes/)。 +更多详情请参考[持久卷示例](/zh-cn/docs/concepts/storage/persistent-volumes/)。 ### portworxVolume {#portworxvolume} @@ -1395,7 +1395,7 @@ For more details, see the [Portworx volume](https://github.com/kubernetes/exampl A projected volume maps several existing volume sources into the same directory. For more details, see [projected volumes](/docs/concepts/storage/projected-volumes/). --> -投射卷能将若干现有的卷来源映射到同一目录上。更多详情请参考[投射卷](/zh/docs/concepts/storage/projected-volumes/)。 +投射卷能将若干现有的卷来源映射到同一目录上。更多详情请参考[投射卷](/zh-cn/docs/concepts/storage/projected-volumes/)。 ### quobyte (已弃用) {#quobyte} @@ -1483,7 +1483,7 @@ must be enabled. `rbd.csi.ceph.com` {{}} 驱动程序。 要使用该特性，必须在集群内安装 [Ceph CSI 驱动](https://github.com/ceph/ceph-csi)，并启用 `CSIMigration` 和 `csiMigrationRBD` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。 -更多详情请参考[配置 Secrets](/zh/docs/concepts/configuration/secret/)。 +更多详情请参考[配置 Secrets](/zh-cn/docs/concepts/configuration/secret/)。 ### storageOS (已弃用) {#storageos} @@ -1666,7 +1666,7 @@ must be installed on the cluster and the `CSIMigration` and `CSIMigrationvSphere 为了使用此功能特性，必须在集群中安装 [vSphere CSI 驱动](https://github.com/kubernetes-sigs/vsphere-csi-driver)，并启用 `CSIMigration` 和 `CSIMigrationvSphere` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。 要了解如何使用资源规约来请求空间，可参考 -[如何管理资源](/zh/docs/concepts/configuration/manage-resources-containers/)。 +[如何管理资源](/zh-cn/docs/concepts/configuration/manage-resources-containers/)。 你可以和以前一样，安装自己的 -[带有原始块卷支持的 PV/PVC](/zh/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)， +[带有原始块卷支持的 PV/PVC](/zh-cn/docs/concepts/storage/persistent-volumes/#raw-block-volume-support)， 采用 CSI 对此过程没有影响。 你可以直接在 Pod 规约中配置 CSI 卷。采用这种方式配置的卷都是临时卷， 无法在 Pod 重新启动后继续存在。 -进一步的信息可参阅[临时卷](/zh/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume)。 +进一步的信息可参阅[临时卷](/zh-cn/docs/concepts/storage/ephemeral-volumes/#csi-ephemeral-volume)。 -参考[使用持久卷部署 WordPress 和 MySQL](/zh/docs/tutorials/stateful-application/mysql-wordpress-persistent-volume/) 示例。 +参考[使用持久卷部署 WordPress 和 MySQL](/zh-cn/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 index 142fadae0c..697aa22477 100644 --- a/content/zh-cn/docs/concepts/storage/windows-storage.md +++ b/content/zh-cn/docs/concepts/storage/windows-storage.md @@ -72,7 +72,7 @@ As a result, the following storage functionality is not supported on Windows nod * 块设备映射 * 内存作为存储介质（例如 `emptyDir.medium` 设置为 `Memory`） * 类似 UID/GID、各用户不同的 Linux 文件系统访问许可等文件系统特性 -* 使用 [DefaultMode 设置 Secret 权限](/zh/docs/concepts/configuration/secret/#secret-files-permissions) +* 使用 [DefaultMode 设置 Secret 权限](/zh-cn/docs/concepts/configuration/secret/#secret-files-permissions) （因为该特性依赖 UID/GID） * 基于 NFS 的存储和卷支持 * 扩展已挂载卷（resizefs） @@ -97,7 +97,7 @@ 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: --> -卷管理组件作为 Kubernetes 卷[插件](/zh/docs/concepts/storage/volumes/#types-of-volumes)发布。 +卷管理组件作为 Kubernetes 卷[插件](/zh-cn/docs/concepts/storage/volumes/#types-of-volumes)发布。 Windows 支持以下类型的 Kubernetes 卷插件： -* [`FlexVolume plugins`](/zh/docs/concepts/storage/volumes/#flexVolume) +* [`FlexVolume plugins`](/zh-cn/docs/concepts/storage/volumes/#flexVolume) * 请注意自 1.23 版本起，FlexVolume 已被弃用 -* [`CSI Plugins`](/zh/docs/concepts/storage/volumes/#csi) +* [`CSI Plugins`](/zh-cn/docs/concepts/storage/volumes/#csi) -* [`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 +* [`awsElasticBlockStore`](/zh-cn/docs/concepts/storage/volumes/#awselasticblockstore) +* [`azureDisk`](/zh-cn/docs/concepts/storage/volumes/#azuredisk) +* [`azureFile`](/zh-cn/docs/concepts/storage/volumes/#azurefile) +* [`gcePersistentDisk`](/zh-cn/docs/concepts/storage/volumes/#gcepersistentdisk) +* [`vsphereVolume`](/zh-cn/docs/concepts/storage/volumes/#vspherevolume) \ No newline at end of file diff --git a/content/zh-cn/docs/concepts/windows/intro.md b/content/zh-cn/docs/concepts/windows/intro.md index fb44b155a3..1ea44cfc3d 100644 --- a/content/zh-cn/docs/concepts/windows/intro.md +++ b/content/zh-cn/docs/concepts/windows/intro.md @@ -92,7 +92,7 @@ including: * 巨页（HugePages）：Windows 容器当前不支持。 * 特权容器：Windows 容器当前不支持。 - [HostProcess 容器](/zh/docs/tasks/configure-pod-container/create-hostprocess-pod/)提供类似功能。 + [HostProcess 容器](/zh-cn/docs/tasks/configure-pod-container/create-hostprocess-pod/)提供类似功能。 * TerminationGracePeriod：需要 containerD。 -* [Pod](/zh/docs/concepts/workloads/pods/) +* [Pod](/zh-cn/docs/concepts/workloads/pods/) Pod 是 Kubernetes 的基本构建块，是可以创建或部署的最小和最简单的单元。 你不可以在同一个 Pod 中部署 Windows 和 Linux 容器。 @@ -220,7 +220,7 @@ Kubernetes 关键组件在 Windows 上的工作方式与在 Linux 上相同。 * {{< glossary_tooltip text="Services" term_id="service" >}} See [Load balancing and Services](#load-balancing-and-services) for more details. --> -* [工作负载资源](/zh/docs/concepts/workloads/controllers/)包括： +* [工作负载资源](/zh-cn/docs/concepts/workloads/controllers/)包括： * ReplicaSet * Deployment @@ -281,14 +281,14 @@ Some kubelet command line options behave differently on Windows, as described be * The kubelet does not take OOM eviction actions --> * `--windows-priorityclass` 允许你设置 kubelet 进程的调度优先级 - （参考 [CPU 资源管理](/zh/docs/concepts/configuration/windows-resource-management/#resource-management-cpu)）。 + （参考 [CPU 资源管理](/zh-cn/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)。 + [NodeAllocatable](/zh-cn/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)。 + 有关更多信息，请参考 [Windows 节点的资源管理](/zh-cn/docs/concepts/configuration/windows-resource-management/#resource-reservation)。 * 未实现 `MemoryPressure` 条件。 * kubelet 不会执行 OOM 驱逐操作。 @@ -419,7 +419,7 @@ work between Windows and Linux: --> * `securityContext.runAsNonRoot` - 此设置将阻止以 `ContainerAdministrator` 身份运行容器，这是 Windows 上与 root 用户最接近的身份。 -* `securityContext.runAsUser` - 改用 [`runAsUserName`](/zh/docs/tasks/configure-pod-container/configure-runasusername)。 +* `securityContext.runAsUser` - 改用 [`runAsUserName`](/zh-cn/docs/tasks/configure-pod-container/configure-runasusername)。 * `securityContext.seLinuxOptions` - 不能在 Windows 上使用，因为 SELinux 特定于 Linux。 * `terminationMessagePath` - 这个字段有一些限制，因为 Windows 不支持映射单个文件。 默认值为 `/dev/termination-log`，因为默认情况下它在 Windows 上不存在，所以能生效。 @@ -468,7 +468,7 @@ The following list documents differences between how Pod specifications work bet supported on Windows. --> * `terminationGracePeriodSeconds` - 这在 Windows 上的 Docker 中没有完全实现， - 请参考[GitHub issue](https://github.com/moby/moby/issues/25982)。 + 请参考 [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 注册表中， @@ -499,7 +499,7 @@ For more information, visit the project's [GitHub page](https://github.com/kuber --> ## 节点问题检测器 {#node-problem-detector} -节点问题检测器（参考[节点健康监测](/zh/docs/tasks/debug/debug-cluster/monitor-node-health/)）初步支持 Windows。 +节点问题检测器（参考[节点健康监测](/zh-cn/docs/tasks/debug/debug-cluster/monitor-node-health/)）初步支持 Windows。 有关更多信息，请访问该项目的 [GitHub 页面](https://github.com/kubernetes/node-problem-detector#windows)。 {{< note >}} 将 GMSA 和 containerd 一起用于访问 Windows -网络共享时存在[已知限制](/zh/docs/tasks/configure-pod-container/configure-gmsa/#gmsa-limitations)， +网络共享时存在[已知限制](/zh-cn/docs/tasks/configure-pod-container/configure-gmsa/#gmsa-limitations)， 这需要一个内核补丁。 {{< /note >}} @@ -637,7 +637,7 @@ Windows Server SAC release -也适用 Kubernetes [版本偏差策略](/zh/docs/setup/release/version-skew-policy/)。 +也适用 Kubernetes [版本偏差策略](/zh-cn/releases/version-skew-policy/)。 ## 获取帮助和故障排查 {#troubleshooting} -对 Kubernetes 集群进行故障排查的主要帮助来源应始于[故障排查](/zh/docs/tasks/debug/)页面。 +对 Kubernetes 集群进行故障排查的主要帮助来源应始于[故障排查](/zh-cn/docs/tasks/debug/)页面。 本节包括了一些其他特定于 Windows 的故障排查帮助。 日志是解决 Kubernetes 中问题的重要元素。 @@ -698,7 +698,7 @@ The Kubernetes [cluster API](https://cluster-api.sigs.k8s.io/) project also prov ### 部署工具 {#deployment-tools} kubeadm 工具帮助你部署 Kubernetes 集群，提供管理集群的控制平面以及运行工作负载的节点。 -[添加 Windows 节点](/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)阐述了如何使用 +[添加 Windows 节点](/zh-cn/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/)阐述了如何使用 kubeadm 将 Windows 节点部署到你的集群。 Kubernetes [集群 API](https://cluster-api.sigs.k8s.io/) 项目也提供了自动部署 Windows 节点的方式。 diff --git a/content/zh-cn/docs/concepts/windows/user-guide.md b/content/zh-cn/docs/concepts/windows/user-guide.md index 7b3ab57b62..49d89b9461 100644 --- a/content/zh-cn/docs/concepts/windows/user-guide.md +++ b/content/zh-cn/docs/concepts/windows/user-guide.md @@ -47,9 +47,9 @@ The example in the section below is provided to jumpstart your experience with W --> ## 在你开始之前 {#before-you-begin} -* 创建一个 Kubernetes 集群，其中包含一个控制平面和一个[运行 Windows Server 的工作节点](/zh/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/) +* 创建一个 Kubernetes 集群，其中包含一个控制平面和一个[运行 Windows Server 的工作节点](/zh-cn/docs/tasks/administer-cluster/kubeadm/adding-windows-nodes/) * 务必请注意，在 Kubernetes 上创建和部署服务和工作负载的行为方式与 Linux 和 Windows 容器的行为方式大致相同。 - 与集群交互的 [kubectl 命令](/zh/docs/reference/kubectl/)是一致的。 + 与集群交互的 [kubectl 命令](/zh-cn/docs/reference/kubectl/)是一致的。 下一小节的示例旨在帮助你快速开始使用 Windows 容器。 调度器在将 Pod 分配到节点时并不使用 `.spec.os.name` 的值。 -你应该使用正常的 Kubernetes 机制[将 Pod 分配给节点](/zh/docs/concepts/scheduling-eviction/assign-pod-node/)， +你应该使用正常的 Kubernetes 机制[将 Pod 分配给节点](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/)， 以确保集群的控制平面将 Pod 放置到运行适当操作系统的节点上。 `.spec.os.name` 值对 Windows Pod 的调度没有影响， diff --git a/content/zh-cn/docs/concepts/workloads/_index.md b/content/zh-cn/docs/concepts/workloads/_index.md index a61176f660..5d895415d3 100644 --- a/content/zh-cn/docs/concepts/workloads/_index.md +++ b/content/zh-cn/docs/concepts/workloads/_index.md @@ -26,7 +26,7 @@ Pod is running means that all the Pods on that node fail. Kubernetes treats that of failure as final: you would need to create a new Pod even if the node later recovers. --> 无论你的负载是单一组件还是由多个一同工作的组件构成，在 Kubernetes 中你 -可以在一组 [Pods](/zh/docs/concepts/workloads/pods) 中运行它。 +可以在一组 [Pods](/zh-cn/docs/concepts/workloads/pods) 中运行它。 在 Kubernetes 中，Pod 代表的是集群上处于运行状态的一组 {{< glossary_tooltip text="容器" term_id="container" >}}。 @@ -37,7 +37,7 @@ For example, once a pod is running in your cluster then a critical fault on the all the pods on that node fail. Kubernetes treats that level of failure as final: you would need to create a new `Pod` to recover, even if the node later becomes healthy. --> -Kubernetes Pods 有[确定的生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/)。 +Kubernetes Pods 有[确定的生命周期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/)。 例如，当某 Pod 在你的集群中运行时，Pod 运行所在的 {{< glossary_tooltip text="节点" term_id="node" >}} 出现致命错误时， 所有该节点上的 Pods 都会失败。Kubernetes 将这类失败视为最终状态： @@ -72,15 +72,15 @@ Kubernetes 提供若干种内置的工作负载资源： `Pods` for that `StatefulSet`, can replicate data to other `Pods` in the same `StatefulSet` to improve overall resilience. --> -* [Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 和 - [ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/) +* [Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/) 和 + [ReplicaSet](/zh-cn/docs/concepts/workloads/controllers/replicaset/) （替换原来的资源 {{< glossary_tooltip text="ReplicationController" term_id="replication-controller" >}}）。 `Deployment` 很适合用来管理你的集群上的无状态应用，`Deployment` 中的所有 `Pod` 都是相互等价的，并且在需要的时候被换掉。 -* [StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/) +* [StatefulSet](/zh-cn/docs/concepts/workloads/controllers/statefulset/) 让你能够运行一个或者多个以某种方式跟踪应用状态的 Pods。 例如，如果你的负载会将数据作持久存储，你可以运行一个 `StatefulSet`，将每个 - `Pod` 与某个 [`PersistentVolume`](/zh/docs/concepts/storage/persistent-volumes/) + `Pod` 与某个 [`PersistentVolume`](/zh-cn/docs/concepts/storage/persistent-volumes/) 对应起来。你在 `StatefulSet` 中各个 `Pod` 内运行的代码可以将数据复制到同一 `StatefulSet` 中的其它 `Pod` 中以提高整体的服务可靠性。 -* [DaemonSet](/zh/docs/concepts/workloads/controllers/daemonset/) +* [DaemonSet](/zh-cn/docs/concepts/workloads/controllers/daemonset/) 定义提供节点本地支撑设施的 `Pods`。这些 Pods 可能对于你的集群的运维是 非常重要的，例如作为网络链接的辅助工具或者作为网络 {{< glossary_tooltip text="插件" term_id="addons" >}} 的一部分等等。每次你向集群中添加一个新节点时，如果该节点与某 `DaemonSet` 的规约匹配，则控制面会为该 `DaemonSet` 调度一个 `Pod` 到该新节点上运行。 -* [Job](/zh/docs/concepts/workloads/controllers/job/) 和 - [CronJob](/zh/docs/concepts/workloads/controllers/cron-jobs/)。 +* [Job](/zh-cn/docs/concepts/workloads/controllers/job/) 和 + [CronJob](/zh-cn/docs/concepts/workloads/controllers/cron-jobs/)。 定义一些一直运行到结束并停止的任务。`Job` 用来表达的是一次性的任务，而 `CronJob` 会根据其时间规划反复运行。 @@ -117,7 +117,7 @@ then you can implement or install an extension that does provide that feature. --> 在庞大的 Kubernetes 生态系统中，你还可以找到一些提供额外操作的第三方 工作负载资源。通过使用 -[定制资源定义（CRD）](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/)， +[定制资源定义（CRD）](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/)， 你可以添加第三方工作负载资源，以完成原本不是 Kubernetes 核心功能的工作。 例如，如果你希望运行一组 `Pods`，但要求所有 Pods 都可用时才执行操作 （比如针对某种高吞吐量的分布式任务），你可以实现一个能够满足这一需求 @@ -135,18 +135,18 @@ As well as reading about each resource, you can learn about specific tasks that --> 除了阅读了解每类资源外，你还可以了解与这些资源相关的任务： -* [使用 Deployment 运行一个无状态的应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/) -* 以[单实例](/zh/docs/tasks/run-application/run-single-instance-stateful-application/) - 或者[多副本集合](/zh/docs/tasks/run-application/run-replicated-stateful-application/) +* [使用 Deployment 运行一个无状态的应用](/zh-cn/docs/tasks/run-application/run-stateless-application-deployment/) +* 以[单实例](/zh-cn/docs/tasks/run-application/run-single-instance-stateful-application/) + 或者[多副本集合](/zh-cn/docs/tasks/run-application/run-replicated-stateful-application/) 的形式运行有状态的应用； -* [使用 `CronJob` 运行自动化的任务](/zh/docs/tasks/job/automated-tasks-with-cron-jobs/) +* [使用 `CronJob` 运行自动化的任务](/zh-cn/docs/tasks/job/automated-tasks-with-cron-jobs/) 要了解 Kubernetes 将代码与配置分离的实现机制，可参阅 -[配置部分](/zh/docs/concepts/configuration/)。 +[配置部分](/zh-cn/docs/concepts/configuration/)。 关于 Kubernetes 如何为应用管理 Pods，还有两个支撑概念能够提供相关背景信息： -* [垃圾收集](/zh/docs/concepts/workloads/controllers/garbage-collection/)机制负责在 +* [垃圾收集](/zh-cn/docs/concepts/workloads/controllers/garbage-collection/)机制负责在 对象的 _属主资源_ 被删除时在集群中清理这些对象。 -* [_Time-to-Live_ 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/) +* [_Time-to-Live_ 控制器](/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished/) 会在 Job 结束之后的指定时间间隔之后删除它们。 一旦你的应用处于运行状态，你就可能想要以 -[`Service`](/zh/docs/concepts/services-networking/service/) +[`Service`](/zh-cn/docs/concepts/services-networking/service/) 的形式使之可在互联网上访问；或者对于 Web 应用而言，使用 -[`Ingress`](/zh/docs/concepts/services-networking/ingress) 资源将其暴露到互联网上。 +[`Ingress`](/zh-cn/docs/concepts/services-networking/ingress) 资源将其暴露到互联网上。 diff --git a/content/zh-cn/docs/concepts/workloads/controllers/deployment.md b/content/zh-cn/docs/concepts/workloads/controllers/deployment.md index 77914f837b..50e3ef0b89 100644 --- a/content/zh-cn/docs/concepts/workloads/controllers/deployment.md +++ b/content/zh-cn/docs/concepts/workloads/controllers/deployment.md @@ -21,8 +21,8 @@ weight: 10 一个 Deployment 为 {{< glossary_tooltip text="Pod" term_id="pod" >}} 和 {{< glossary_tooltip term_id="replica-set" text="ReplicaSet" >}} @@ -76,7 +76,7 @@ The following are typical use cases for Deployments: * [扩大 Deployment 规模以承担更多负载](#scaling-a-deployment)。 * [暂停 Deployment ](#pausing-and-resuming-a-deployment) 以应用对 PodTemplateSpec 所作的多项修改， 然后恢复其执行以启动新的上线版本。 -* [使用 Deployment 状态](#deployment-status) 来判定上线过程是否出现停滞。 +* [使用 Deployment 状态](#deployment-status)来判定上线过程是否出现停滞。 * [清理较旧的不再需要的 ReplicaSet](#clean-up-policy) 。 例如，假定你在创建一个 Deployment 以生成 `nginx:1.14.2` 的 5 个副本，但接下来 -更新 Deployment 以创建 5 个 `nginx:1.16.1` 的副本，而此时只有 3 个`nginx:1.14.2` +更新 Deployment 以创建 5 个 `nginx:1.16.1` 的副本，而此时只有 3 个 `nginx:1.14.2` 副本已创建。在这种情况下，Deployment 会立即开始杀死 3 个 `nginx:1.14.2` Pods， 并开始创建 `nginx:1.16.1` Pods。它不会等待 `nginx:1.14.2` 的 5 个副本都创建完成后才开始执行变更动作。 @@ -636,7 +636,7 @@ In API version `apps/v1`, a Deployment's label selector is immutable after it ge {{< /note >}} * 使用 `kubectl annotate deployment/nginx-deployment kubernetes.io/change-cause="image updated to 1.16.1"` @@ -1063,7 +1063,7 @@ Assuming [horizontal Pod autoscaling](/docs/tasks/run-application/horizontal-pod in your cluster, you can setup an autoscaler for your Deployment and choose the minimum and maximum number of Pods you want to run based on the CPU utilization of your existing Pods. --> -假设集群启用了[Pod 的水平自动缩放](/zh/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)， +假设集群启用了[Pod 的水平自动缩放](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale-walkthrough/)， 你可以为 Deployment 设置自动缩放器，并基于现有 Pod 的 CPU 利用率选择要运行的 Pod 个数下限和上限。 @@ -1599,7 +1599,7 @@ number of seconds the Deployment controller waits before indicating (in the Depl Deployment progress has stalled. --> 检测此状况的一种方法是在 Deployment 规约中指定截止时间参数： -（[`.spec.progressDeadlineSeconds`]（#progress-deadline-seconds））。 +（[`.spec.progressDeadlineSeconds`](#progress-deadline-seconds)）。 `.spec.progressDeadlineSeconds` 给出的是一个秒数值，Deployment 控制器在（通过 Deployment 状态） 标示 Deployment 进展停滞之前，需要等待所给的时长。 @@ -1854,8 +1854,8 @@ can create multiple Deployments, one for each release, following the canary patt ## 金丝雀部署 {#canary-deployment} 如果要使用 Deployment 向用户子集或服务器子集上线版本， -则可以遵循[资源管理](/zh/docs/concepts/cluster-administration/manage-deployment/#canary-deployments) -所描述的金丝雀模式，创建多个 Deployment，每个版本一个。 +则可以遵循[资源管理](/zh-cn/docs/concepts/cluster-administration/manage-deployment/#canary-deployments)所描述的金丝雀模式， +创建多个 Deployment，每个版本一个。 Deployment 对象的名称必须是合法的 -[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)。 Deployment 还需要 [`.spec` 部分](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。 -`.spec.template` 是一个 [Pod 模板](/zh/docs/concepts/workloads/pods/#pod-templates)。 +`.spec.template` 是一个 [Pod 模板](/zh-cn/docs/concepts/workloads/pods/#pod-templates)。 它和 {{< glossary_tooltip text="Pod" term_id="pod" >}} 的语法规则完全相同。 只是这里它是嵌套的，因此不需要 `apiVersion` 或 `kind`。 @@ -1909,7 +1909,7 @@ labels and an appropriate restart policy. For labels, make sure not to overlap w Only a [`.spec.template.spec.restartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) equal to `Always` is allowed, which is the default if not specified. --> -只有 [`.spec.template.spec.restartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) +只有 [`.spec.template.spec.restartPolicy`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 等于 `Always` 才是被允许的，这也是在没有指定时的默认设置。 -如果一个 [HorizontalPodAutoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale/) +如果一个 [HorizontalPodAutoscaler](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/) （或者其他执行水平扩缩操作的类似 API）在管理 Deployment 的扩缩， 则不要设置 `.spec.replicas`。 @@ -1960,7 +1960,7 @@ for the Pods targeted by this Deployment. ### 选择算符 {#selector} `.spec.selector` 是指定本 Deployment 的 Pod -[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/)的必需字段。 +[标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/)的必需字段。 `.spec.selector` 必须匹配 `.spec.template.metadata.labels`，否则请求会被 API 拒绝。 @@ -2033,7 +2033,7 @@ replacement will be created immediately (even if the old Pod is still in a Termi 才会创建新版本的 Pod。如果你手动删除一个 Pod，其生命周期是由 ReplicaSet 来控制的， 后者会立即创建一个替换 Pod（即使旧的 Pod 仍然处于 Terminating 状态）。 如果你需要一种“最多 n 个”的 Pod 个数保证，你需要考虑使用 -[StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/)。 +[StatefulSet](/zh-cn/docs/concepts/workloads/controllers/statefulset/)。 {{< /note >}} -* 了解 [Pod](/zh/docs/concepts/workloads/pods)。 -* [使用 Deployment 运行一个无状态应用](/zh/docs/tasks/run-application/run-stateless-application-deployment/)。 +* 了解 [Pod](/zh-cn/docs/concepts/workloads/pods)。 +* [使用 Deployment 运行一个无状态应用](/zh-cn/docs/tasks/run-application/run-stateless-application-deployment/)。 * `Deployment` 是 Kubernetes REST API 中的一个顶层资源。 阅读 {{< api-reference page="workload-resources/deployment-v1" >}} 对象定义，以了解 Deployment 的 API 细节。 -* 阅读 [PodDisruptionBudget](/zh/docs/concepts/workloads/pods/disruptions/) +* 阅读 [PodDisruptionBudget](/zh-cn/docs/concepts/workloads/pods/disruptions/) 了解如何使用它来在可能出现干扰的情况下管理应用的可用性。 diff --git a/content/zh-cn/docs/concepts/workloads/controllers/job.md b/content/zh-cn/docs/concepts/workloads/controllers/job.md index 30411c769e..430cc4627e 100644 --- a/content/zh-cn/docs/concepts/workloads/controllers/job.md +++ b/content/zh-cn/docs/concepts/workloads/controllers/job.md @@ -1,5 +1,5 @@ --- -title: Jobs +title: Job content_type: concept feature: title: 批量执行 @@ -37,10 +37,10 @@ You can also use a Job to run multiple Pods in parallel. If you want to run a Job (either a single task, or several in parallel) on a schedule, see [CronJob](/docs/concepts/workloads/controllers/cron-jobs/). --> -Job 会创建一个或者多个 Pods，并将继续重试 Pods 的执行，直到指定数量的 Pods 成功终止。 -随着 Pods 成功结束，Job 跟踪记录成功完成的 Pods 个数。 +Job 会创建一个或者多个 Pod，并将继续重试 Pod 的执行，直到指定数量的 Pod 成功终止。 +随着 Pod 成功结束，Job 跟踪记录成功完成的 Pod 个数。 当数量达到指定的成功个数阈值时，任务（即 Job）结束。 -删除 Job 的操作会清除所创建的全部 Pods。 +删除 Job 的操作会清除所创建的全部 Pod。 挂起 Job 的操作会删除 Job 的所有活跃 Pod，直到 Job 被再次恢复执行。 一种简单的使用场景下，你会创建一个 Job 对象以便以一种可靠的方式运行某 Pod 直到完成。 @@ -50,7 +50,7 @@ Job 会创建一个或者多个 Pods，并将继续重试 Pods 的执行，直 你也可以使用 Job 以并行的方式运行多个 Pod。 如果你想按某种排期表（Schedule）运行 Job（单个任务或多个并行任务），请参阅 -[CronJob](/docs/concepts/workloads/controllers/cron-jobs/)。 +[CronJob](/zh-cn/docs/concepts/workloads/controllers/cron-jobs/)。 @@ -140,9 +140,9 @@ To view completed Pods of a Job, use `kubectl get pods`. To list all the Pods that belong to a Job in a machine readable form, you can use a command like this: --> -要查看 Job 对应的已完成的 Pods，可以执行 `kubectl get pods`。 +要查看 Job 对应的已完成的 Pod，可以执行 `kubectl get pods`。 -要以机器可读的方式列举隶属于某 Job 的全部 Pods，你可以使用类似下面这条命令： +要以机器可读的方式列举隶属于某 Job 的全部 Pod，你可以使用类似下面这条命令： ```shell pods=$(kubectl get pods --selector=job-name=pi --output=jsonpath='{.items[*].metadata.name}') @@ -193,7 +193,7 @@ A Job also needs a [`.spec` section](https://git.k8s.io/community/contributors/d ## 编写 Job 规约 {#writing-a-job-spec} 与 Kubernetes 中其他资源的配置类似，Job 也需要 `apiVersion`、`kind` 和 `metadata` 字段。 -Job 的名字必须是合法的 [DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 +Job 的名字必须是合法的 [DNS 子域名](/zh-cn/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)。 @@ -209,18 +209,18 @@ labels (see [pod selector](#pod-selector)) and an appropriate restart policy. Only a [`RestartPolicy`](/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) equal to `Never` or `OnFailure` is allowed. --> -### Pod 模版 {#pod-template} +### Pod 模板 {#pod-template} Job 的 `.spec` 中只有 `.spec.template` 是必需的字段。 -字段 `.spec.template` 的值是一个 [Pod 模版](/zh/docs/concepts/workloads/pods/#pod-templates)。 +字段 `.spec.template` 的值是一个 [Pod 模板](/zh-cn/docs/concepts/workloads/pods/#pod-templates)。 其定义规范与 {{< glossary_tooltip text="Pod" term_id="pod" >}} 完全相同，只是其中不再需要 `apiVersion` 或 `kind` 字段。 -除了作为 Pod 所必需的字段之外，Job 中的 Pod 模版必需设置合适的标签 +除了作为 Pod 所必需的字段之外，Job 中的 Pod 模板必须设置合适的标签 （参见 [Pod 选择算符](#pod-selector)）和合适的重启策略。 -Job 中 Pod 的 [`RestartPolicy`](/zh/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) +Job 中 Pod 的 [`RestartPolicy`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#restart-policy) 只能设置为 `Never` 或 `OnFailure` 之一。 -对于 _非并行_ 的 Job，你可以不设置 `spec.completions` 和 `spec.parallelism`。 +对于**非并行**的 Job，你可以不设置 `spec.completions` 和 `spec.parallelism`。 这两个属性都不设置时，均取默认值 1。 -对于 _确定完成计数_ 类型的 Job，你应该设置 `.spec.completions` 为所需要的完成个数。 +对于**确定完成计数**类型的 Job，你应该设置 `.spec.completions` 为所需要的完成个数。 你可以设置 `.spec.parallelism`，也可以不设置。其默认值为 1。 -对于一个 _工作队列_ Job，你不可以设置 `.spec.completions`，但要将`.spec.parallelism` +对于一个**工作队列** Job，你不可以设置 `.spec.completions`，但要将`.spec.parallelism` 设置为一个非负整数。 关于如何利用不同类型的 Job 的更多信息，请参见 [Job 模式](#job-patterns)一节。 @@ -316,7 +316,7 @@ parallelism, for a variety of reasons: 如果未设置，则默认为 1。 如果设置为 0，则 Job 相当于启动之后便被暂停，直到此值被增加。 -实际并行性（在任意时刻运行状态的 Pods 个数）可能比并行性请求略大或略小， +实际并行性（在任意时刻运行状态的 Pod 个数）可能比并行性请求略大或略小， 原因如下： -- 对于 _确定完成计数_ Job，实际上并行执行的 Pods 个数不会超出剩余的完成数。 +- 对于**确定完成计数** Job，实际上并行执行的 Pod 个数不会超出剩余的完成数。 如果 `.spec.parallelism` 值较高，会被忽略。 -- 对于 _工作队列_ Job，有任何 Job 成功结束之后，不会有新的 Pod 启动。 - 不过，剩下的 Pods 允许执行完毕。 +- 对于**工作队列** Job，有任何 Job 成功结束之后，不会有新的 Pod 启动。 + 不过，剩下的 Pod 允许执行完毕。 - 如果 Job {{< glossary_tooltip text="控制器" term_id="controller" >}} 没有来得及作出响应，或者 -- 如果 Job 控制器因为任何原因（例如，缺少 `ResourceQuota` 或者没有权限）无法创建 Pods。 - Pods 个数可能比请求的数目小。 +- 如果 Job 控制器因为任何原因（例如，缺少 `ResourceQuota` 或者没有权限）无法创建 Pod。 + Pod 个数可能比请求的数目小。 - Job 控制器可能会因为之前同一 Job 中 Pod 失效次数过多而压制新 Pod 的创建。 - 当 Pod 处于体面终止进程中，需要一定时间才能停止。 @@ -350,7 +350,7 @@ parallelism, for a variety of reasons: Jobs with _fixed completion count_ - that is, jobs that have non null `.spec.completions` - can have a completion mode that is specified in `.spec.completionMode`: --> -带有 *确定完成计数* 的 Job，即 `.spec.completions` 不为 null 的 Job， +带有**确定完成计数**的 Job，即 `.spec.completions` 不为 null 的 Job， 都可以在其 `.spec.completionMode` 中设置完成模式： ### Pod 回退失效策略 {#pod-backoff-failure-policy} -在有些情形下，你可能希望 Job 在经历若干次重试之后直接进入失败状态，因为这很 -可能意味着遇到了配置错误。 +在有些情形下，你可能希望 Job 在经历若干次重试之后直接进入失败状态， +因为这很可能意味着遇到了配置错误。 为了实现这点，可以将 `.spec.backoffLimit` 设置为视 Job 为失败之前的重试次数。 失效回退的限制值默认为 6。 与 Job 相关的失效的 Pod 会被 Job 控制器重建，回退重试时间将会按指数增长 @@ -509,13 +509,12 @@ old jobs after noting their status. Delete the job with `kubectl` (e.g. `kubect ## Job 终止与清理 {#clean-up-finished-jobs-automatically} Job 完成时不会再创建新的 Pod，不过已有的 Pod [通常](#pod-backoff-failure-policy)也不会被删除。 -保留这些 Pod 使得你可以查看已完成的 Pod 的日志输出，以便检查错误、警告 -或者其它诊断性输出。 +保留这些 Pod 使得你可以查看已完成的 Pod 的日志输出，以便检查错误、警告或者其它诊断性输出。 Job 完成时 Job 对象也一样被保留下来，这样你就可以查看它的状态。 在查看了 Job 状态之后删除老的 Job 的操作留给了用户自己。 你可以使用 `kubectl` 来删除 Job（例如，`kubectl delete jobs/pi` 或者 `kubectl delete -f ./job.yaml`）。 -当使用 `kubectl` 来删除 Job 时，该 Job 所创建的 Pods 也会被删除。 +当使用 `kubectl` 来删除 Job 时，该 Job 所创建的 Pod 也会被删除。 注意 Job 的 `.spec.activeDeadlineSeconds` 优先级高于其 `.spec.backoffLimit` 设置。 因此，如果一个 Job 正在重试一个或多个失效的 Pod，该 Job 一旦到达 -`activeDeadlineSeconds` 所设的时限即不再部署额外的 Pod，即使其重试次数还未 -达到 `backoffLimit` 所设的限制。 +`activeDeadlineSeconds` 所设的时限即不再部署额外的 Pod， +即使其重试次数还未达到 `backoffLimit` 所设的限制。 例如： @@ -574,14 +572,14 @@ Keep in mind that the `restartPolicy` applies to the Pod, and not to the Job its That is, the Job termination mechanisms activated with `.spec.activeDeadlineSeconds` and `.spec.backoffLimit` result in a permanent Job failure that requires manual intervention to resolve. --> 注意 Job 规约和 Job 中的 -[Pod 模版规约](/zh/docs/concepts/workloads/pods/init-containers/#detailed-behavior) +[Pod 模板规约](/zh-cn/docs/concepts/workloads/pods/init-containers/#detailed-behavior) 都有 `activeDeadlineSeconds` 字段。 请确保你在合适的层次设置正确的字段。 还要注意的是，`restartPolicy` 对应的是 Pod，而不是 Job 本身： 一旦 Job 状态变为 `type: Failed`，就不会再发生 Job 重启的动作。 -换言之，由 `.spec.activeDeadlineSeconds` 和 `.spec.backoffLimit` 所触发的 Job 终结机制 -都会导致 Job 永久性的失败，而这类状态都需要手工干预才能解决。 +换言之，由 `.spec.activeDeadlineSeconds` 和 `.spec.backoffLimit` 所触发的 Job +终结机制都会导致 Job 永久性的失败，而这类状态都需要手工干预才能解决。 ## 自动清理完成的 Job {#clean-up-finished-jobs-automatically} -完成的 Job 通常不需要留存在系统中。在系统中一直保留它们会给 API -服务器带来额外的压力。 +完成的 Job 通常不需要留存在系统中。在系统中一直保留它们会给 API 服务器带来额外的压力。 如果 Job 由某种更高级别的控制器来管理，例如 -[CronJobs](/zh/docs/concepts/workloads/controllers/cron-jobs/)， +[CronJobs](/zh-cn/docs/concepts/workloads/controllers/cron-jobs/)， 则 Job 可以被 CronJob 基于特定的根据容量裁定的清理策略清理掉。 ### 已完成 Job 的 TTL 机制 {#ttl-mechanisms-for-finished-jobs} @@ -621,10 +618,9 @@ be honored. For example: --> 自动清理已完成 Job （状态为 `Complete` 或 `Failed`）的另一种方式是使用由 -[TTL 控制器](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)所提供 +[TTL 控制器](/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished/)所提供 的 TTL 机制。 -通过设置 Job 的 `.spec.ttlSecondsAfterFinished` 字段，可以让该控制器清理掉 -已结束的资源。 +通过设置 Job 的 `.spec.ttlSecondsAfterFinished` 字段，可以让该控制器清理掉已结束的资源。 TTL 控制器清理 Job 时，会级联式地删除 Job 对象。 换言之，它会删除所有依赖的对象，包括 Pod 及 Job 本身。 @@ -674,7 +670,7 @@ NoSQL database to scan, and so on. Job 对象可以用来支持多个 Pod 的可靠的并发执行。 Job 对象不是设计用来支持相互通信的并行进程的，后者一般在科学计算中应用较多。 -Job 的确能够支持对一组相互独立而又有所关联的 *工作条目* 的并行处理。 +Job 的确能够支持对一组相互独立而又有所关联的**工作条目**的并行处理。 这类工作条目可能是要发送的电子邮件、要渲染的视频帧、要编解码的文件、NoSQL 数据库中要扫描的主键范围等等。 @@ -685,8 +681,8 @@ considering one set of work items that the user wants to manage together — There are several different patterns for parallel computation, each with strengths and weaknesses. The tradeoffs are: --> -在一个复杂系统中，可能存在多个不同的工作条目集合。这里我们仅考虑用户希望一起管理的 -工作条目集合之一 — *批处理作业*。 +在一个复杂系统中，可能存在多个不同的工作条目集合。 +这里我们仅考虑用户希望一起管理的工作条目集合之一：**批处理作业**。 并行计算的模式有好多种，每种都有自己的强项和弱点。这里要权衡的因素有： @@ -707,8 +703,8 @@ The tradeoffs are: - 创建与工作条目相等的 Pod 或者令每个 Pod 可以处理多个工作条目。 前者通常不需要对现有代码和容器做较大改动； 后者则更适合工作条目数量较大的场合，原因同上。 -- 有几种技术都会用到工作队列。这意味着需要运行一个队列服务，并修改现有程序或容器 - 使之能够利用该工作队列。 +- 有几种技术都会用到工作队列。这意味着需要运行一个队列服务， + 并修改现有程序或容器使之能够利用该工作队列。 与之比较，其他方案在修改现有容器化应用以适应需求方面可能更容易一些。 当你使用 `.spec.completions` 来设置完成数时，Job 控制器所创建的每个 Pod 使用完全相同的 [`spec`](https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#spec-and-status)。 -这意味着任务的所有 Pod 都有相同的命令行，都使用相同的镜像和数据卷，甚至连 -环境变量都（几乎）相同。 +这意味着任务的所有 Pod 都有相同的命令行，都使用相同的镜像和数据卷， +甚至连环境变量都（几乎）相同。 这些模式是让每个 Pod 执行不同工作的几种不同形式。 下表显示的是每种模式下 `.spec.parallelism` 和 `.spec.completions` 所需要的设置。 @@ -746,10 +742,10 @@ Here, `W` is the number of work items. | 模式 | `.spec.completions` | `.spec.parallelism` | | ----- |:-------------------:|:--------------------:| -| [每工作条目一 Pod 的队列](/zh/docs/tasks/job/coarse-parallel-processing-work-queue/) | W | 任意值 | -| [Pod 个数可变的队列](/zh/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | 任意值 | -| [静态任务分派的带索引的 Job](/zh/docs/tasks/job/indexed-parallel-processing-static) | W | | 任意值 | -| [Job 模版扩展](/zh/docs/tasks/job/parallel-processing-expansion/) | 1 | 应该为 1 | +| [每工作条目一 Pod 的队列](/zh-cn/docs/tasks/job/coarse-parallel-processing-work-queue/) | W | 任意值 | +| [Pod 个数可变的队列](/zh-cn/docs/tasks/job/fine-parallel-processing-work-queue/) | 1 | 任意值 | +| [静态任务分派的带索引的 Job](/zh-cn/docs/tasks/job/indexed-parallel-processing-static) | W | | 任意值 | +| [Job 模板扩展](/zh-cn/docs/tasks/job/parallel-processing-expansion/) | 1 | 应该为 1 | -当 Job 被从挂起状态恢复执行时，其 `.status.startTime` 字段会被重置为 -当前的时间。这意味着 `.spec.activeDeadlineSeconds` 计时器会在 Job 挂起时 -被停止，并在 Job 恢复执行时复位。 +当 Job 被从挂起状态恢复执行时，其 `.status.startTime` 字段会被重置为当前的时间。 +这意味着 `.spec.activeDeadlineSeconds` 计时器会在 Job 挂起时被停止， +并在 Job 恢复执行时复位。 -要记住的是，挂起 Job 会删除其所有活跃的 Pod。当 Job 被挂起时，你的 Pod 会 -收到 SIGTERM 信号而被[终止](/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。 +要记住的是，挂起 Job 会删除其所有活跃的 Pod。当 Job 被挂起时， +你的 Pod 会收到 SIGTERM 信号而被[终止](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)。 Pod 的体面终止期限会被考虑，不过 Pod 自身也必须在此期限之内处理完信号。 处理逻辑可能包括保存进度以便将来恢复，或者取消已经做出的变更等等。 Pod 以这种形式终止时，不会被记入 Job 的 `completions` 计数。 @@ -863,11 +858,10 @@ exist in the Job's status, the Job has never been stopped. Events are also created when the Job is suspended and resumed: --> -Job 的 "Suspended" 类型的状况在状态值为 "True" 时意味着 Job 正被 -挂起；`lastTransitionTime` 字段可被用来确定 Job 被挂起的时长。 +Job 的 "Suspended" 类型的状况在状态值为 "True" 时意味着 Job 正被挂起； +`lastTransitionTime` 字段可被用来确定 Job 被挂起的时长。 如果此状况字段的取值为 "False"，则 Job 之前被挂起且现在在运行。 -如果 "Suspended" 状况在 `status` 字段中不存在，则意味着 Job 从未 -被停止执行。 +如果 "Suspended" 状况在 `status` 字段中不存在，则意味着 Job 从未被停止执行。 当 Job 被挂起和恢复执行时，也会生成事件： @@ -912,8 +906,8 @@ on the [API server](/docs/reference/command-line-tools-reference/kube-apiserver/ It is enabled by default. --> {{< note >}} -为了使用此功能，你必须在 [API 服务器](/zh/docs/reference/command-line-tools-reference/kube-apiserver/)上启用 -`JobMutableNodeSchedulingDirectives` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 +为了使用此功能，你必须在 [API 服务器](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/)上启用 +`JobMutableNodeSchedulingDirectives` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。 默认情况下启用。 {{< /note >}} @@ -931,7 +925,7 @@ a custom queue controller has no influence on where the pods of a job will actua --> [suspend](#suspend-a-job) 字段是实现这些语义的第一步。 suspend 允许自定义队列控制器，以决定工作何时开始；然而，一旦工作被取消暂停， -自定义队列控制器对 Job 中 Pods 的实际放置位置没有影响。 +自定义队列控制器对 Job 中 Pod 的实际放置位置没有影响。 Job 的 Pod 模板中可以更新的字段是节点亲和性、节点选择器、容忍、标签和注解。 - - 做这个操作时请务必小心。 -如果你所设定的标签选择算符并不唯一针对 Job 对应的 Pod 集合，甚或该算符还能匹配 -其他无关的 Pod，这些无关的 Job 的 Pod 可能会被删除。 -或者当前 Job 会将另外一些 Pod 当作是完成自身工作的 Pods， +如果你所设定的标签选择算符并不唯一针对 Job 对应的 Pod 集合， +甚或该算符还能匹配其他无关的 Pod，这些无关的 Job 的 Pod 可能会被删除。 +或者当前 Job 会将另外一些 Pod 当作是完成自身工作的 Pod， 又或者两个 Job 之一或者二者同时都拒绝创建 Pod，无法运行至完成状态。 如果所设置的算符不具有唯一性，其他控制器（如 RC 副本控制器）及其所管理的 Pod 集合可能会变得行为不可预测。 @@ -1005,9 +997,9 @@ Before deleting it, you make a note of what selector it uses: 假定名为 `old` 的 Job 已经处于运行状态。 你希望已有的 Pod 继续运行，但你希望 Job 接下来要创建的其他 Pod -使用一个不同的 Pod 模版，甚至希望 Job 的名字也发生变化。 +使用一个不同的 Pod 模板，甚至希望 Job 的名字也发生变化。 你无法更新现有的 Job，因为这些字段都是不可更新的。 -因此，你会删除 `old` Job，但 _允许该 Job 的 Pod 集合继续运行_。 +因此，你会删除 `old` Job，但**允许该 Job 的 Pod 集合继续运行**。 这是通过 `kubectl delete jobs/old --cascade=orphan` 实现的。 在删除之前，我们先记下该 Job 所使用的选择算符。 @@ -1044,8 +1036,8 @@ the selector that the system normally generates for you automatically. 由于现有 Pod 都具有标签 `controller-uid=a8f3d00d-c6d2-11e5-9f87-42010af00002`， 它们也会被名为 `new` 的 Job 所控制。 -你需要在新 Job 中设置 `manualSelector: true`，因为你并未使用系统通常自动为你 -生成的选择算符。 +你需要在新 Job 中设置 `manualSelector: true`， +因为你并未使用系统通常自动为你生成的选择算符。 ```yaml kind: Job @@ -1066,8 +1058,8 @@ The new Job itself will have a different uid from `a8f3d00d-c6d2-11e5-9f87-42010 mismatch. --> 新的 Job 自身会有一个不同于 `a8f3d00d-c6d2-11e5-9f87-42010af00002` 的唯一 ID。 -设置 `manualSelector: true` 是在告诉系统你知道自己在干什么并要求系统允许这种不匹配 -的存在。 +设置 `manualSelector: true` +是在告诉系统你知道自己在干什么并要求系统允许这种不匹配的存在。 -要使用该行为，你必须为 [API 服务器](/zh/docs/reference/command-line-tools-reference/kube-apiserver/) -和[控制器管理器](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) +要使用该行为，你必须为 [API 服务器](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/) +和[控制器管理器](/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/) 启用 `JobTrackingWithFinalizers` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。 默认是启用的。 ### 副本控制器 {#replication-controller} -Job 与[副本控制器](/zh/docs/concepts/workloads/controllers/replicationcontroller/)是彼此互补的。 +Job 与[副本控制器](/zh-cn/docs/concepts/workloads/controllers/replicationcontroller/)是彼此互补的。 副本控制器管理的是那些不希望被终止的 Pod （例如，Web 服务器）， Job 管理的是那些希望被终止的 Pod（例如，批处理作业）。 -正如在 [Pod 生命期](/zh/docs/concepts/workloads/pods/pod-lifecycle/) 中讨论的， +正如在 [Pod 生命期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/) 中讨论的， `Job` 仅适合于 `restartPolicy` 设置为 `OnFailure` 或 `Never` 的 Pod。 注意：如果 `restartPolicy` 未设置，其默认值是 `Always`。 @@ -1192,8 +1185,8 @@ complicated to get started with and offers less integration with Kubernetes. --> ### 单个 Job 启动控制器 Pod {#single-job-starts-controller-pod} -另一种模式是用唯一的 Job 来创建 Pod，而该 Pod 负责启动其他 Pod，因此扮演了一种 -后启动 Pod 的控制器的角色。 +另一种模式是用唯一的 Job 来创建 Pod，而该 Pod 负责启动其他 Pod， +因此扮演了一种后启动 Pod 的控制器的角色。 这种模式的灵活性更高，但是有时候可能会把事情搞得很复杂，很难入门， 并且与 Kubernetes 的集成度很低。 @@ -1230,13 +1223,13 @@ object, but maintains complete control over what Pods are created and how work i can use to define a series of Jobs that will run based on a schedule, similar to the UNIX tool `cron`. --> -* 了解 [Pods](/zh/docs/concepts/workloads/pods)。 +* 了解 [Pod](/zh-cn/docs/concepts/workloads/pods)。 * 了解运行 Job 的不同的方式： - * [使用工作队列进行粗粒度并行处理](/zh/docs/tasks/job/coarse-parallel-processing-work-queue/) - * [使用工作队列进行精细的并行处理](/zh/docs/tasks/job/fine-parallel-processing-work-queue/) - * [使用索引作业完成静态工作分配下的并行处理](/zh/docs/tasks/job/indexed-parallel-processing-static/)（Beta 阶段） - * 基于一个模板运行多个 Job：[使用展开的方式进行并行处理](/zh/docs/tasks/job/parallel-processing-expansion/) + * [使用工作队列进行粗粒度并行处理](/zh-cn/docs/tasks/job/coarse-parallel-processing-work-queue/) + * [使用工作队列进行精细的并行处理](/zh-cn/docs/tasks/job/fine-parallel-processing-work-queue/) + * [使用索引作业完成静态工作分配下的并行处理](/zh-cn/docs/tasks/job/indexed-parallel-processing-static/)（Beta 阶段） + * 基于一个模板运行多个 Job：[使用展开的方式进行并行处理](/zh-cn/docs/tasks/job/parallel-processing-expansion/) * 跟随[自动清理完成的 Job](#clean-up-finished-jobs-automatically) 文中的链接，了解你的集群如何清理完成和失败的任务。 * `Job` 是 Kubernetes REST API 的一部分。阅读 {{< api-reference page="workload-resources/job-v1" >}} 对象定义理解关于该资源的 API。 -* 阅读 [`CronJob`](/zh/docs/concepts/workloads/controllers/cron-jobs/)，它允许你定义一系列定期运行的 Job，类似于 UNIX 工具 `cron`。 +* 阅读 [`CronJob`](/zh-cn/docs/concepts/workloads/controllers/cron-jobs/)，它允许你定义一系列定期运行的 Job，类似于 UNIX 工具 `cron`。 diff --git a/content/zh-cn/docs/concepts/workloads/controllers/replicaset.md b/content/zh-cn/docs/concepts/workloads/controllers/replicaset.md index b55efa8345..06f8123a51 100644 --- a/content/zh-cn/docs/concepts/workloads/controllers/replicaset.md +++ b/content/zh-cn/docs/concepts/workloads/controllers/replicaset.md @@ -38,7 +38,7 @@ template. ReplicaSet 是通过一组字段来定义的，包括一个用来识别可获得的 Pod 的集合的选择算符、一个用来标明应该维护的副本个数的数值、一个用来指定应该创建新 Pod 以满足副本个数条件时要使用的 Pod 模板等等。 -每个 ReplicaSet 都通过根据需要创建和 删除 Pod 以使得副本个数达到期望值， +每个 ReplicaSet 都通过根据需要创建和删除 Pod 以使得副本个数达到期望值， 进而实现其存在价值。当 ReplicaSet 需要创建新的 Pod 时，会使用所提供的 Pod 模板。 ReplicaSet 使用其选择算符来辨识要获得的 Pod 集合。如果某个 Pod 没有 -OwnerReference 或者其 OwnerReference 不是一个 -{{< glossary_tooltip text="控制器" term_id="controller" >}}，且其匹配到 -某 ReplicaSet 的选择算符，则该 Pod 立即被此 ReplicaSet 获得。 +OwnerReference 或者其 OwnerReference 不是一个{{< glossary_tooltip text="控制器" term_id="controller" >}}， +且其匹配到某 ReplicaSet 的选择算符，则该 Pod 立即被此 ReplicaSet 获得。 -最后可以查看启动了的 Pods： +最后可以查看启动了的 Pod 集合： ```shell kubectl get pods @@ -191,8 +190,8 @@ frontend-wtsmm 1/1 Running 0 6m36s You can also verify that the owner reference of these pods is set to the frontend ReplicaSet. To do this, get the yaml of one of the Pods running: --> -你也可以查看 Pods 的属主引用被设置为前端的 ReplicaSet。 -要实现这点，可取回运行中的 Pods 之一的 YAML： +你也可以查看 Pod 的属主引用被设置为前端的 ReplicaSet。 +要实现这点，可取回运行中的某个 Pod 的 YAML： ```shell kubectl get pods frontend-b2zdv -o yaml @@ -268,7 +267,7 @@ Fetching the Pods: 新的 Pod 会被该 ReplicaSet 获取，并立即被 ReplicaSet 终止， 因为它们的存在会使得 ReplicaSet 中 Pod 个数超出其期望值。 -取回 Pods： +取回 Pod： ```shell @@ -292,7 +291,7 @@ pod2 0/1 Terminating 0 1s -如果你先行创建 Pods： +如果你先行创建 Pod： ```shell kubectl apply -f https://kubernetes.io/examples/pods/pod-rs.yaml @@ -334,7 +333,7 @@ pod2 1/1 Running 0 36s -采用这种方式，一个 ReplicaSet 中可以包含异质的 Pods 集合。 +采用这种方式，一个 ReplicaSet 中可以包含异质的 Pod 集合。 -### Pod 模版 {#pod-template} +### Pod 模板 {#pod-template} -`.spec.template` 是一个 [Pod 模版](/zh-cn/docs/concepts/workloads/pods/#pod-templates)， +`.spec.template` 是一个 [Pod 模板](/zh-cn/docs/concepts/workloads/pods/#pod-templates)， 要求设置标签。在 `frontend.yaml` 示例中，我们指定了标签 `tier: frontend`。 注意不要将标签与其他控制器的选择算符重叠，否则那些控制器会尝试收养此 Pod。 @@ -396,7 +395,7 @@ be rejected by the API. ### Pod 选择算符 {#pod-selector} `.spec.selector` 字段是一个[标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/)。 -如前文中[所讨论的](#how-a-replicaset-works)，这些是用来标识要被获取的 Pods +如前文中[所讨论的](#how-a-replicaset-works)，这些是用来标识要被获取的 Pod 的标签。在签名的 `frontend.yaml` 示例中，选择算符为： ```yaml @@ -413,7 +412,7 @@ For 2 ReplicaSets specifying the same `.spec.selector` but different `.spec.temp --> 对于设置了相同的 `.spec.selector`，但 `.spec.template.metadata.labels` 和 `.spec.template.spec` 字段不同的两个 -ReplicaSet 而言，每个 ReplicaSet 都会忽略被另一个 ReplicaSet 所创建的 Pods。 +ReplicaSet 而言，每个 ReplicaSet 都会忽略被另一个 ReplicaSet 所创建的 Pod。 {{< /note >}} -## 使用 ReplicaSets {#working-with-replicasets} +## 使用 ReplicaSet {#working-with-replicasets} ### 删除 ReplicaSet 和它的 Pod {#deleting-a-replicaset-and-its-pods} @@ -470,7 +469,7 @@ For example: --> ### 只删除 ReplicaSet {#deleting-just-a-replicaset} -你可以只删除 ReplicaSet 而不影响它的 Pods，方法是使用 +你可以只删除 ReplicaSet 而不影响它的各个 Pod，方法是使用 [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete) 命令并设置 `--cascade=orphan` 选项。 @@ -517,17 +516,17 @@ assuming that the number of replicas is not also changed). 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. --> -### 缩放 RepliaSet {#scaling-a-replicaset} +### 扩缩 RepliaSet {#scaling-a-replicaset} -通过更新 `.spec.replicas` 字段，ReplicaSet 可以被轻松的进行缩放。ReplicaSet +通过更新 `.spec.replicas` 字段，ReplicaSet 可以被轻松地进行扩缩。ReplicaSet 控制器能确保匹配标签选择器的数量的 Pod 是可用的和可操作的。 -在降低集合规模时，ReplicaSet 控制器通过对可用的 Pods 进行排序来优先选择 -要被删除的 Pods。其一般性算法如下： +在降低集合规模时，ReplicaSet 控制器通过对可用的所有 Pod 进行排序来优先选择要被删除的那些 Pod。 +其一般性算法如下： -1. 首先选择剔除悬决（Pending，且不可调度）的 Pods -2. 如果设置了 `controller.kubernetes.io/pod-deletion-cost` 注解，则注解值 - 较小的优先被裁减掉 +1. 首先选择剔除悬决（Pending，且不可调度）的各个 Pod +2. 如果设置了 `controller.kubernetes.io/pod-deletion-cost` 注解，则注解值较小的优先被裁减掉 3. 所处节点上副本个数较多的 Pod 优先于所处节点上副本较少者 4. 如果 Pod 的创建时间不同，最近创建的 Pod 优先于早前创建的 Pod 被裁减。 （当 `LogarithmicScaleDown` 这一[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/) @@ -560,7 +558,7 @@ Using the [`controller.kubernetes.io/pod-deletion-cost`](/docs/reference/labels- annotation, users can set a preference regarding which pods to remove first when downscaling a ReplicaSet. --> 通过使用 [`controller.kubernetes.io/pod-deletion-cost`](/zh-cn/docs/reference/labels-annotations-taints/#pod-deletion-cost) -注解，用户可以对 ReplicaSet 缩容时要先删除哪些 Pods 设置偏好。 +注解，用户可以对 ReplicaSet 缩容时要先删除哪些 Pod 设置偏好。 此注解要设置到 Pod 上，取值范围为 [-2147483647, 2147483647]。 -所代表的的是删除同一 ReplicaSet 中其他 Pod 相比较而言的开销。 -删除开销较小的 Pods 比删除开销较高的 Pods 更容易被删除。 +所代表的是删除同一 ReplicaSet 中其他 Pod 相比较而言的开销。 +删除开销较小的 Pod 比删除开销较高的 Pod 更容易被删除。 -Pods 如果未设置此注解，则隐含的设置值为 0。负值也是可接受的。 +Pod 如果未设置此注解，则隐含的设置值为 0。负值也是可接受的。 如果注解值非法，API 服务器会拒绝对应的 Pod。 #### 使用场景示例 {#example-use-case} -同一应用的不同 Pods 可能其利用率是不同的。在对应用执行缩容操作时，可能 -希望移除利用率较低的 Pods。为了避免频繁更新 Pods，应用应该在执行缩容 -操作之前更新一次 `controller.kubernetes.io/pod-deletion-cost` 注解值 +同一应用的不同 Pod 可能其利用率是不同的。在对应用执行缩容操作时， +可能希望移除利用率较低的 Pod。为了避免频繁更新 Pod，应用应该在执行缩容操作之前更新一次 +`controller.kubernetes.io/pod-deletion-cost` 注解值 （将注解值设置为一个与其 Pod 利用率对应的值）。 -如果应用自身控制器缩容操作时（例如 Spark 部署的驱动 Pod），这种机制 -是可以起作用的。 +如果应用自身控制器缩容操作时（例如 Spark 部署的驱动 Pod），这种机制是可以起作用的。 -### ReplicaSet 作为水平的 Pod 自动缩放器目标 {#replicaset-as-a-horizontal-pod-autoscaler-target} +### ReplicaSet 作为水平的 Pod 自动扩缩器目标 {#replicaset-as-a-horizontal-pod-autoscaler-target} -ReplicaSet 也可以作为[水平的 Pod 缩放器 (HPA)](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/) -的目标。也就是说，ReplicaSet 可以被 HPA 自动缩放。 +ReplicaSet 也可以作为[水平的 Pod 扩缩器 (HPA)](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/) +的目标。也就是说，ReplicaSet 可以被 HPA 自动扩缩。 以下是 HPA 以我们在前一个示例中创建的副本集为目标的示例。 {{< codenew file="controllers/hpa-rs.yaml" >}} @@ -638,7 +635,7 @@ create the defined HPA that autoscales the target ReplicaSet depending on the CP of the replicated Pods. --> 将这个列表保存到 `hpa-rs.yaml` 并提交到 Kubernetes 集群，就能创建它所定义的 -HPA，进而就能根据复制的 Pod 的 CPU 利用率对目标 ReplicaSet进行自动缩放。 +HPA，进而就能根据复制的 Pod 的 CPU 利用率对目标 ReplicaSet 进行自动扩缩。 ```shell kubectl apply -f https://k8s.io/examples/controllers/hpa-rs.yaml @@ -648,7 +645,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 @@ -671,7 +668,7 @@ As such, it is recommended to use Deployments when you want ReplicaSets. ### Deployment（推荐） {#deployment-recommended} [`Deployment`](/zh-cn/docs/concepts/workloads/controllers/deployment/) 是一个可以拥有 -ReplicaSet 并使用声明式方式在服务器端完成对 Pods 滚动更新的对象。 +ReplicaSet 并使用声明式方式在服务器端完成对 Pod 滚动更新的对象。 尽管 ReplicaSet 可以独立使用，目前它们的主要用途是提供给 Deployment 作为编排 Pod 创建、删除和更新的一种机制。当使用 Deployment 时，你不必关心如何管理它所创建的 ReplicaSet，Deployment 拥有并管理其 ReplicaSet。 @@ -754,4 +751,3 @@ ReplicaSet 是 [ReplicationController](/zh-cn/docs/concepts/workloads/controller 对象定义理解关于该资源的 API。 * 阅读 [Pod 干扰预算（Disruption Budget）](/zh-cn/docs/concepts/workloads/pods/disruptions/)， 了解如何在干扰下运行高度可用的应用。 - diff --git a/content/zh-cn/docs/concepts/workloads/controllers/replicationcontroller.md b/content/zh-cn/docs/concepts/workloads/controllers/replicationcontroller.md index f83b5d4686..851dafd0a0 100644 --- a/content/zh-cn/docs/concepts/workloads/controllers/replicationcontroller.md +++ b/content/zh-cn/docs/concepts/workloads/controllers/replicationcontroller.md @@ -7,7 +7,7 @@ feature: 重新启动失败的容器，在节点死亡时替换并重新调度容器，杀死不响应用户定义的健康检查的容器，并且在它们准备好服务之前不会将它们公布给客户端。 content_type: concept weight: 90 ---- +--- {{< note >}} -现在推荐使用配置 [`ReplicaSet`](/zh/docs/concepts/workloads/controllers/replicaset/) 的 -[`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/) 来建立副本管理机制。 +现在推荐使用配置 [`ReplicaSet`](/zh-cn/docs/concepts/workloads/controllers/replicaset/) 的 +[`Deployment`](/zh-cn/docs/concepts/workloads/controllers/deployment/) 来建立副本管理机制。 {{< /note >}} ### Pod 选择算符 {#pod-selector} -`.spec.selector` 字段是一个[标签选择算符](/zh/docs/concepts/overview/working-with-objects/labels/#label-selectors)。 +`.spec.selector` 字段是一个[标签选择算符](/zh-cn/docs/concepts/overview/working-with-objects/labels/#label-selectors)。 ReplicationController 管理标签与选择算符匹配的所有 Pod。 它不区分它创建或删除的 Pod 和其他人或进程创建或删除的 Pod。 这允许在不影响正在运行的 Pod 的情况下替换 ReplicationController。 @@ -299,7 +299,7 @@ If you do not specify `.spec.replicas`, then it defaults to 1. 你可以通过设置 `.spec.replicas` 来指定应该同时运行多少个 Pod。 在任何时候，处于运行状态的 Pod 个数都可能高于或者低于设定值。例如，副本个数刚刚被增加或减少时，或者一个 Pod 处于优雅终止过程中而其替代副本已经提前开始创建时。 -如果你没有指定 `.spec.replicas` ，那么它默认是 1。 +如果你没有指定 `.spec.replicas`，那么它默认是 1。 ### Deployment （推荐） -[`Deployment`](/zh/docs/concepts/workloads/controllers/deployment/) 是一种更高级别的 API 对象，用于更新其底层 ReplicaSet 及其 Pod。 +[`Deployment`](/zh-cn/docs/concepts/workloads/controllers/deployment/) 是一种更高级别的 API 对象，用于更新其底层 ReplicaSet 及其 Pod。 如果你想要这种滚动更新功能，那么推荐使用 Deployment，因为它们是声明式的、服务端的，并且具有其它特性。 ## {{% heading "whatsnext" %}} -- 了解 [Pods](/zh/docs/concepts/workloads/pods)。 -- 了解 [Depolyment](/zh/docs/concepts/workloads/controllers/deployment/)，ReplicationController 的替代品。 +- 了解 [Pods](/zh-cn/docs/concepts/workloads/pods)。 +- 了解 [Depolyment](/zh-cn/docs/concepts/workloads/controllers/deployment/)，ReplicationController 的替代品。 - `ReplicationController` 是 Kubernetes REST API 的一部分，阅读 {{< api-reference page="workload-resources/replication-controller-v1" >}} 对象定义以了解 replication controllers 的 API。 diff --git a/content/zh-cn/docs/concepts/workloads/controllers/statefulset.md b/content/zh-cn/docs/concepts/workloads/controllers/statefulset.md index 22a3cdcca7..8897131ba1 100644 --- a/content/zh-cn/docs/concepts/workloads/controllers/statefulset.md +++ b/content/zh-cn/docs/concepts/workloads/controllers/statefulset.md @@ -27,7 +27,7 @@ StatefulSet 是用来管理有状态应用的工作负载 API 对象。 StatefulSets are valuable for applications that require one or more of the following. --> -## 使用 StatefulSets +## 使用 StatefulSets {#using-statefulsets} StatefulSets 对于需要满足以下一个或多个需求的应用程序很有价值： @@ -53,8 +53,8 @@ that provides a set of stateless replicas. 在上面描述中，“稳定的”意味着 Pod 调度或重调度的整个过程是有持久性的。 如果应用程序不需要任何稳定的标识符或有序的部署、删除或伸缩，则应该使用 由一组无状态的副本控制器提供的工作负载来部署应用程序，比如 -[Deployment](/zh/docs/concepts/workloads/controllers/deployment/) 或者 -[ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/) +[Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/) 或者 +[ReplicaSet](/zh-cn/docs/concepts/workloads/controllers/replicaset/) 可能更适用于你的无状态应用部署需要。 ### 最短就绪秒数 {#minimum-ready-seconds} {{< feature-state for_k8s_version="v1.23" state="beta" >}} - {{< note >}} -集群域会被设置为 `cluster.local`，除非有[其他配置](/zh/docs/concepts/services-networking/dns-pod-service/)。 +集群域会被设置为 `cluster.local`，除非有[其他配置](/zh-cn/docs/concepts/services-networking/dns-pod-service/)。 {{< /note >}} StatefulSet 不应将 `pod.Spec.TerminationGracePeriodSeconds` 设置为 0。 这种做法是不安全的，要强烈阻止。更多的解释请参考 -[强制删除 StatefulSet Pod](/zh/docs/tasks/run-application/force-delete-stateful-set-pod/)。 +[强制删除 StatefulSet Pod](/zh-cn/docs/tasks/run-application/force-delete-stateful-set-pod/)。 在上面的 nginx 示例被创建后，会按照 web-0、web-1、web-2 的顺序部署三个 Pod。 -在 web-0 进入 [Running 和 Ready](/zh/docs/concepts/workloads/pods/pod-lifecycle/) +在 web-0 进入 [Running 和 Ready](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/) 状态前不会部署 web-1。在 web-1 进入 Running 和 Ready 状态前不会部署 web-2。 如果 web-1 已经处于 Running 和 Ready 状态，而 web-2 尚未部署，在此期间发生了 web-0 运行失败，那么 web-2 将不会被部署，要等到 web-0 部署完成并进入 Running 和 @@ -417,7 +417,7 @@ StatefulSet 允许你放宽其排序保证， `OrderedReady` pod management is the default for StatefulSets. It implements the behavior described [above](#deployment-and-scaling-guarantees). --> -#### OrderedReady Pod 管理 +#### OrderedReady Pod 管理 {#orderedready-pod-management} `OrderedReady` Pod 管理是 StatefulSet 的默认设置。它实现了 [上面](#deployment-and-scaling-guarantees)描述的功能。 @@ -467,7 +467,7 @@ StatefulSet 的 `.spec.updateStrategy` 字段让 `RollingUpdate` : `RollingUpdate` 更新策略对 StatefulSet 中的 Pod 执行自动的滚动更新。这是默认的更新策略。 - + -### 最大不可用 Pod +### 最大不可用 Pod {#maximum-unavailable-pods} {{< feature-state for_k8s_version="v1.24" state="alpha" >}} @@ -529,7 +529,7 @@ The value can be an absolute number (for example, `5`) or a percentage of desire Pods (for example, `10%`). Absolute number is calculated from the percentage value by rounding it up. This field cannot be 0. The default setting is 1. --> -你可以通过指定 `.spec.updateStrategy.rollingUpdate.maxUnavailable` +你可以通过指定 `.spec.updateStrategy.rollingUpdate.maxUnavailable` 字段来控制更新期间不可用的 Pod 的最大数量。 该值可以是绝对值（例如，“5”）或者是期望 Pod 个数的百分比（例如，`10%`）。 绝对值是根据百分比值四舍五入计算的。 @@ -547,13 +547,13 @@ unavailable Pod in the range `0` to `replicas - 1`, it will be counted towards {{< note >}} The `maxUnavailable` field is in Alpha stage and it is honored only by API servers that are running with the `MaxUnavailableStatefulSet` -[feature gate](/docs/reference/commmand-line-tools-reference/feature-gates/) +[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) enabled. {{< /note >}} --> {{< note >}} `maxUnavailable` 字段处于 Alpha 阶段，仅当 API 服务器启用了 `MaxUnavailableStatefulSet` -[特性门控](/zh/docs/reference/commmand-line-tools-reference/feature-gates/)时才起作用。 +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)时才起作用。 {{< /note >}} -在 StatefulSet 的生命周期中，可选字段 +在 StatefulSet 的生命周期中，可选字段 `.spec.persistentVolumeClaimRetentionPolicy` 控制是否删除以及如何删除 PVC。 使用该字段，你必须启用 `StatefulSetAutoDeletePVC` -[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 +[特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)。 启用后，你可以为每个 StatefulSet 配置两个策略： - StatefulSet {{}}为其 PVC 添加了 -[属主引用](/zh/docs/concepts/overview/working-with-objects/owners-dependents/#owner-references-in-object-specifications)， +[属主引用](/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents/#owner-references-in-object-specifications)， 这些 PVC 在 Pod 终止后被{{}}删除。 这使 Pod 能够在删除 PVC 之前（以及在删除后备 PV 和卷之前，取决于保留策略）干净地卸载所有卷。 当你设置 `whenDeleted` 删除策略，对 StatefulSet 实例的属主引用放置在与该 StatefulSet 关联的所有 PVC 上。 @@ -713,7 +713,7 @@ to be garbage collected after only the condemned Pods have terminated. 首先将已销毁的 Pod 设置为与 StatefulSet 模板 对应的 PVC 的属主。 这会导致 PVC 仅在已废弃的 Pod 终止后被垃圾收集。 - -如果 [HorizontalPodAutoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale/) +如果 [HorizontalPodAutoscaler](/zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/) （或任何类似的水平缩放 API）正在管理 Statefulset 的缩放， 请不要设置 `.spec.replicas`。 相反，允许 Kubernetes 控制平面自动管理 `.spec.replicas` 字段。 @@ -779,15 +779,15 @@ the `.spec.replicas` field automatically. * Read about [PodDisruptionBudget](/docs/concepts/workloads/pods/disruptions/) and how you can use it to manage application availability during disruptions. --> -* 了解 [Pod](/zh/docs/concepts/workloads/pods)。 +* 了解 [Pod](/zh-cn/docs/concepts/workloads/pods)。 * 了解如何使用 StatefulSet - * 跟随示例[部署有状态应用](/zh/docs/tutorials/stateful-application/basic-stateful-set/)。 - * 跟随示例[使用 StatefulSet 部署 Cassandra](/zh/docs/tutorials/stateful-application/cassandra/)。 - * 跟随示例[运行多副本的有状态应用程序](/zh/docs/tasks/run-application/run-replicated-stateful-application/)。 - * 了解如何[扩缩 StatefulSet](/zh/docs/tasks/run-application/scale-stateful-set/)。 - * 了解[删除 StatefulSet](/zh/docs/tasks/run-application/delete-stateful-set/)涉及到的操作。 - * 了解如何[配置 Pod 以使用卷进行存储](/zh/docs/tasks/configure-pod-container/configure-volume-storage/)。 - * 了解如何[配置 Pod 以使用 PersistentVolume 作为存储](/zh/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)。 + * 跟随示例[部署有状态应用](/zh-cn/docs/tutorials/stateful-application/basic-stateful-set/)。 + * 跟随示例[使用 StatefulSet 部署 Cassandra](/zh-cn/docs/tutorials/stateful-application/cassandra/)。 + * 跟随示例[运行多副本的有状态应用程序](/zh-cn/docs/tasks/run-application/run-replicated-stateful-application/)。 + * 了解如何[扩缩 StatefulSet](/zh-cn/docs/tasks/run-application/scale-stateful-set/)。 + * 了解[删除 StatefulSet](/zh-cn/docs/tasks/run-application/delete-stateful-set/)涉及到的操作。 + * 了解如何[配置 Pod 以使用卷进行存储](/zh-cn/docs/tasks/configure-pod-container/configure-volume-storage/)。 + * 了解如何[配置 Pod 以使用 PersistentVolume 作为存储](/zh-cn/docs/tasks/configure-pod-container/configure-persistent-volume-storage/)。 * `StatefulSet` 是 Kubernetes REST API 中的顶级资源。阅读 {{< api-reference page="workload-resources/stateful-set-v1" >}} 对象定义理解关于该资源的 API。 -* 阅读 [Pod 干扰预算（Disruption Budget）](/zh/docs/concepts/workloads/pods/disruptions/)，了解如何在干扰下运行高度可用的应用。 +* 阅读 [Pod 干扰预算（Disruption Budget）](/zh-cn/docs/concepts/workloads/pods/disruptions/)，了解如何在干扰下运行高度可用的应用。 diff --git a/content/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished.md b/content/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished.md index 352ddaf83d..7887151b9a 100644 --- a/content/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished.md +++ b/content/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished.md @@ -37,7 +37,7 @@ up finished Jobs (either `Complete` or `Failed`) automatically by specifying the TTL-after-finished 控制器只支持 Job。集群操作员可以通过指定 Job 的 `.spec.ttlSecondsAfterFinished` 字段来自动清理已结束的作业（`Complete` 或 `Failed`），如 -[示例](/zh/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically) +[示例](/zh-cn/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically) 所示。 * 在作业清单（manifest）中指定此字段，以便 Job 在完成后的某个时间被自动清除。 * 将此字段设置为现有的、已完成的作业，以采用此新功能。 -* 在创建作业时使用 [mutating admission webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) +* 在创建作业时使用 [mutating admission webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) 动态设置该字段。集群管理员可以使用它对完成的作业强制执行 TTL 策略。 -* 使用 [mutating admission webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) +* 使用 [mutating admission webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks) 在作业完成后动态设置该字段，并根据作业状态、标签等选择不同的 TTL 值。 -* [自动清理 Job](/zh/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically) +* [自动清理 Job](/zh-cn/docs/concepts/workloads/controllers/job/#clean-up-finished-jobs-automatically) * [设计文档](https://github.com/kubernetes/enhancements/blob/master/keps/sig-apps/592-ttl-after-finish/README.md) diff --git a/content/zh-cn/docs/concepts/workloads/pods/_index.md b/content/zh-cn/docs/concepts/workloads/pods/_index.md index 5eec324a1a..12063e1e84 100644 --- a/content/zh-cn/docs/concepts/workloads/pods/_index.md +++ b/content/zh-cn/docs/concepts/workloads/pods/_index.md @@ -52,8 +52,8 @@ during Pod startup. You can also inject for debugging if your cluster offers this. --> 除了应用容器，Pod 还可以包含在 Pod 启动期间运行的 -[Init 容器](/zh/docs/concepts/workloads/pods/init-containers/)。 -你也可以在集群中支持[临时性容器](/zh/docs/concepts/workloads/pods/ephemeral-containers/) +[Init 容器](/zh-cn/docs/concepts/workloads/pods/init-containers/)。 +你也可以在集群中支持[临时性容器](/zh-cn/docs/concepts/workloads/pods/ephemeral-containers/) 的情况下，为调试的目的注入临时性容器。 @@ -271,7 +271,7 @@ When you create the manifest for a Pod object, make sure the name specified is a [DNS subdomain name](/docs/concepts/overview/working-with-objects/names#dns-subdomain-names). --> 当你为 Pod 对象创建清单时，要确保所指定的 Pod 名称是合法的 -[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 +[DNS 子域名](/zh-cn/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 Pod 中的容器所看到的系统主机名与为 Pod 配置的 `name` 属性值相同。 -[网络](/zh/docs/concepts/cluster-administration/networking/)部分提供了更多有关此内容的信息。 +[网络](/zh-cn/docs/concepts/cluster-administration/networking/)部分提供了更多有关此内容的信息。 -* 了解 [Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/) -* 了解 [RuntimeClass](/zh/docs/concepts/containers/runtime-class/)，以及如何使用它 +* 了解 [Pod 生命周期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/) +* 了解 [RuntimeClass](/zh-cn/docs/concepts/containers/runtime-class/)，以及如何使用它 来配置不同的 Pod 使用不同的容器运行时配置 -* 了解 [Pod 拓扑分布约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/) -* 了解 [PodDisruptionBudget](/zh/docs/concepts/workloads/pods/disruptions/)，以及你 +* 了解 [Pod 拓扑分布约束](/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints/) +* 了解 [PodDisruptionBudget](/zh-cn/docs/concepts/workloads/pods/disruptions/)，以及你 如何可以利用它在出现干扰因素时管理应用的可用性。 * Pod 在 Kubernetes REST API 中是一个顶层资源。 {{< api-reference page="workload-resources/pod-v1" >}} diff --git a/content/zh-cn/docs/concepts/workloads/pods/disruptions.md b/content/zh-cn/docs/concepts/workloads/pods/disruptions.md index 8afcb0f696..24e7ac25dc 100644 --- a/content/zh-cn/docs/concepts/workloads/pods/disruptions.md +++ b/content/zh-cn/docs/concepts/workloads/pods/disruptions.md @@ -60,7 +60,7 @@ an application. Examples are: - 云提供商或虚拟机管理程序中的故障导致的虚拟机消失 - 内核错误 - 节点由于集群网络隔离从集群中消失 -- 由于节点[资源不足](/zh/docs/concepts/scheduling-eviction/node-pressure-eviction/)导致 pod 被驱逐。 +- 由于节点[资源不足](/zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/)导致 pod 被驱逐。 集群管理员操作包括： -- [排空（drain）节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)进行修复或升级。 +- [排空（drain）节点](/zh-cn/docs/tasks/administer-cluster/safely-drain-node/)进行修复或升级。 - 从集群中排空节点以缩小集群（了解[集群自动扩缩](https://github.com/kubernetes/autoscaler/#readme)）。 - 从节点中移除一个 Pod，以允许其他 Pod 使用该节点。 @@ -145,13 +145,13 @@ and [stateful](/docs/tasks/run-application/run-replicated-stateful-application/) or across zones (if using a [multi-zone cluster](/docs/setup/multiple-zones).) --> -- 确保 Pod 在请求中给出[所需资源](/zh/docs/tasks/configure-pod-container/assign-memory-resource/)。 +- 确保 Pod 在请求中给出[所需资源](/zh-cn/docs/tasks/configure-pod-container/assign-memory-resource/)。 - 如果需要更高的可用性，请复制应用程序。 - （了解有关运行多副本的[无状态](/zh/docs/tasks/run-application/run-stateless-application-deployment/) - 和[有状态](/zh/docs/tasks/run-application/run-replicated-stateful-application/)应用程序的信息。） + （了解有关运行多副本的[无状态](/zh-cn/docs/tasks/run-application/run-stateless-application-deployment/) + 和[有状态](/zh-cn/docs/tasks/run-application/run-replicated-stateful-application/)应用程序的信息。） - 为了在运行复制应用程序时获得更高的可用性，请跨机架（使用 - [反亲和性](/zh/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) - 或跨区域（如果使用[多区域集群](/zh/docs/setup/best-practices/multiple-zones/)）扩展应用程序。 + [反亲和性](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) + 或跨区域（如果使用[多区域集群](/zh-cn/docs/setup/best-practices/multiple-zones/)）扩展应用程序。 集群管理员和托管提供商应该使用遵循 PodDisruptionBudgets 的接口 -（通过调用[Eviction API](/zh/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)）， +（通过调用[Eviction API](/zh-cn/docs/tasks/administer-cluster/safely-drain-node/#the-eviction-api)）， 而不是直接删除 Pod 或 Deployment。 当使用驱逐 API 驱逐 Pod 时，Pod 会被体面地 -[终止](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)，期间会 +[终止](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination)，期间会 参考 [PodSpec](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podspec-v1-core) 中的 `terminationGracePeriodSeconds` 配置值。 @@ -506,7 +506,7 @@ the nodes in your cluster, such as a node or system software upgrade, here are s * Learn about [updating a deployment](/docs/concepts/workloads/controllers/deployment/#updating-a-deployment) including steps to maintain its availability during the rollout. --> -* 参考[配置 Pod 干扰预算](/zh/docs/tasks/run-application/configure-pdb/)中的方法来保护你的应用。 -* 进一步了解[排空节点](/zh/docs/tasks/administer-cluster/safely-drain-node/)的信息。 -* 了解[更新 Deployment](/zh/docs/concepts/workloads/controllers/deployment/#updating-a-deployment) +* 参考[配置 Pod 干扰预算](/zh-cn/docs/tasks/run-application/configure-pdb/)中的方法来保护你的应用。 +* 进一步了解[排空节点](/zh-cn/docs/tasks/administer-cluster/safely-drain-node/)的信息。 +* 了解[更新 Deployment](/zh-cn/docs/concepts/workloads/controllers/deployment/#updating-a-deployment) 的过程，包括如何在其进程中维持应用的可用性 diff --git a/content/zh-cn/docs/concepts/workloads/pods/ephemeral-containers.md b/content/zh-cn/docs/concepts/workloads/pods/ephemeral-containers.md index 0535b4afe3..a464991304 100644 --- a/content/zh-cn/docs/concepts/workloads/pods/ephemeral-containers.md +++ b/content/zh-cn/docs/concepts/workloads/pods/ephemeral-containers.md @@ -124,11 +124,11 @@ sharing](/docs/tasks/configure-pod-container/share-process-namespace/) so you can view processes in other containers. --> 使用临时容器时，启用 -[进程名字空间共享](/zh/docs/tasks/configure-pod-container/share-process-namespace/) +[进程名字空间共享](/zh-cn/docs/tasks/configure-pod-container/share-process-namespace/) 很有帮助，可以查看其他容器中的进程。 {{% heading "whatsnext" %}} -* 了解如何[使用临时调试容器来进行调试](/zh/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container) +* 了解如何[使用临时调试容器来进行调试](/zh-cn/docs/tasks/debug/debug-application/debug-running-pod/#ephemeral-container) diff --git a/content/zh-cn/docs/concepts/workloads/pods/pod-lifecycle.md b/content/zh-cn/docs/concepts/workloads/pods/pod-lifecycle.md index 3458799573..4c120be05a 100644 --- a/content/zh-cn/docs/concepts/workloads/pods/pod-lifecycle.md +++ b/content/zh-cn/docs/concepts/workloads/pods/pod-lifecycle.md @@ -45,7 +45,7 @@ or is [terminated](#pod-termination). Pod 对象的状态包含了一组 [Pod 状况（Conditions）](#pod-conditions)。 如果应用需要的话，你也可以向其中注入[自定义的就绪性信息](#pod-readiness-gate)。 -Pod 在其生命周期中只会被[调度](/zh/docs/concepts/scheduling-eviction/)一次。 +Pod 在其生命周期中只会被[调度](/zh-cn/docs/concepts/scheduling-eviction/)一次。 一旦 Pod 被调度（分派）到某个节点，Pod 会一直在该节点运行，直到 Pod 停止或者 被[终止](#pod-termination)。 @@ -66,7 +66,7 @@ are [scheduled for deletion](#pod-garbage-collection) after a timeout period. 和一个个独立的应用容器一样，Pod 也被认为是相对临时性（而不是长期存在）的实体。 Pod 会被创建、赋予一个唯一的 -ID（[UID](/zh/docs/concepts/overview/working-with-objects/names/#uids)）， +ID（[UID](/zh-cn/docs/concepts/overview/working-with-objects/names/#uids)）， 并被调度到节点，并在终止（根据重启策略）或删除之前一直运行在该节点。 如果一个{{< glossary_tooltip text="节点" term_id="node" >}}死掉了，调度到该节点 @@ -182,7 +182,7 @@ There are three possible container states: `Waiting`, `Running`, and `Terminated ## 容器状态 {#container-states} Kubernetes 会跟踪 Pod 中每个容器的状态，就像它跟踪 Pod 总体上的[阶段](#pod-phase)一样。 -你可以使用[容器生命周期回调](/zh/docs/concepts/containers/container-lifecycle-hooks/) +你可以使用[容器生命周期回调](/zh-cn/docs/concepts/containers/container-lifecycle-hooks/) 来在容器生命周期中的特定时间点触发事件。 一旦{{< glossary_tooltip text="调度器" term_id="kube-scheduler" >}}将 Pod @@ -306,7 +306,7 @@ Pod 有一个 PodStatus 对象，其中包含一个 --> * `PodScheduled`：Pod 已经被调度到某节点； * `ContainersReady`：Pod 中所有容器都已就绪； -* `Initialized`：所有的 [Init 容器](/zh/docs/concepts/workloads/pods/init-containers/) +* `Initialized`：所有的 [Init 容器](/zh-cn/docs/concepts/workloads/pods/init-containers/) 都已成功完成； * `Ready`：Pod 可以为请求提供服务，并且应该被添加到对应服务的负载均衡池中。 @@ -382,8 +382,8 @@ status: -你所添加的 Pod 状况名称必须满足 Kubernetes -[标签键名格式](/zh/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)。 +你所添加的 Pod 状况名称必须满足 Kubernetes +[标签键名格式](/zh-cn/docs/concepts/overview/working-with-objects/labels/#syntax-and-character-set)。 ## 容器探针 {#container-probes} -probe 是由 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 对容器执行的定期诊断。 +probe 是由 [kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) 对容器执行的定期诊断。 要执行诊断，kubelet 既可以在容器内执行代码，也可以发出一个网络请求。 如欲了解如何设置存活态、就绪态和启动探针的进一步细节，可以参阅 -[配置存活态、就绪态和启动探针](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)。 +[配置存活态、就绪态和启动探针](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)。 -如果容器中的进程能够在遇到问题或不健康的情况下自行崩溃，则不一定需要存活态探针; -`kubelet` 将根据 Pod 的`restartPolicy` 自动执行修复操作。 +如果容器中的进程能够在遇到问题或不健康的情况下自行崩溃，则不一定需要存活态探针; +`kubelet` 将根据 Pod 的 `restartPolicy` 自动执行修复操作。 如果你希望容器在探测失败时被杀死并重新启动，那么请指定一个存活态探针， -并指定`restartPolicy` 为 "`Always`" 或 "`OnFailure`"。 +并指定 `restartPolicy` 为 "`Always`" 或 "`OnFailure`"。 1. 如果 Pod 中的容器之一定义了 `preStop` - [回调](/zh/docs/concepts/containers/container-lifecycle-hooks)， + [回调](/zh-cn/docs/concepts/containers/container-lifecycle-hooks)， `kubelet` 开始在容器内运行该回调逻辑。如果超出体面终止限期时，`preStop` 回调逻辑 仍在运行，`kubelet` 会请求给予该 Pod 的宽限期一次性增加 2 秒钟。 @@ -874,7 +874,7 @@ API 服务器直接删除 Pod 对象，这样新的与之同名的 Pod 即可以 在节点侧，被设置为立即终止的 Pod 仍然会在被强行杀死之前获得一点点的宽限时间。 如果你需要强制删除 StatefulSet 的 Pod，请参阅 -[从 StatefulSet 中删除 Pod](/zh/docs/tasks/run-application/force-delete-stateful-set-pod/) +[从 StatefulSet 中删除 Pod](/zh-cn/docs/tasks/run-application/force-delete-stateful-set-pod/) 的任务文档。 -* 动手实践[为容器生命周期时间关联处理程序](/zh/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)。 -* 动手实践[配置存活态、就绪态和启动探针](/zh/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)。 -* 进一步了解[容器生命周期回调](/zh/docs/concepts/containers/container-lifecycle-hooks/)。 +* 动手实践[为容器生命周期时间关联处理程序](/zh-cn/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/)。 +* 动手实践[配置存活态、就绪态和启动探针](/zh-cn/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/)。 +* 进一步了解[容器生命周期回调](/zh-cn/docs/concepts/containers/container-lifecycle-hooks/)。 * 关于 API 中定义的有关 Pod 和容器状态的详细规范信息， 可参阅 API 参考文档中 Pod 的 [`.status`](/docs/reference/kubernetes-api/workload-resources/pod-v1/#PodStatus) 字段。 diff --git a/content/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints.md b/content/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints.md index 5c698ac514..40ef623ad6 100644 --- a/content/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints.md +++ b/content/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints.md @@ -76,7 +76,7 @@ graph TB -你可以复用在大多数集群上自动创建和填充的[常用标签](/zh/docs/reference/labels-annotations-taints/)， +你可以复用在大多数集群上自动创建和填充的[常用标签](/zh-cn/docs/reference/labels-annotations-taints/)， 而不是手动添加标签。 `minDomains` 字段是在 1.24 版本中新增的 alpha 字段。你必须启用 - `MinDomainsInPodToplogySpread` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)才能使用它。 + `MinDomainsInPodToplogySpread` [特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/)才能使用它。 {{< /note >}} -你可以在 [调度方案（Scheduling Profile）](/zh/docs/reference/scheduling/config/#profiles) +你可以在 [调度方案（Scheduling Profile）](/zh-cn/docs/reference/scheduling/config/#profiles) 中将默认约束作为 `PodTopologySpread` 插件参数的一部分来设置。 约束的设置采用[如前所述的 API](#api)，只是 `labelSelector` 必须为空。 选择算符是根据 Pod 所属的服务、副本控制器、ReplicaSet 或 StatefulSet 来设置的。 @@ -553,7 +553,7 @@ profiles: is disabled by default. It's recommended to use `PodTopologySpread` to achieve similar behavior. --> -[`SelectorSpread` 插件](/zh/docs/reference/scheduling/config/#scheduling-plugins)默认是被禁用的。 +[`SelectorSpread` 插件](/zh-cn/docs/reference/scheduling/config/#scheduling-plugins)默认是被禁用的。 建议使用 `PodTopologySpread` 来实现类似的行为。 {{< /note >}} diff --git a/content/zh-cn/docs/contribute/_index.md b/content/zh-cn/docs/contribute/_index.md index b21312ff8b..1ec143445b 100644 --- a/content/zh-cn/docs/contribute/_index.md +++ b/content/zh-cn/docs/contribute/_index.md @@ -216,7 +216,7 @@ Figure 2. Preparation for your first contribution. 图 2. 第一次贡献的准备工作。 如果你仅想从上游代码重新生成 Kubernetes API 或 `kube-*` 组件的参考文档。请参考以下说明： -- [生成 Kubernetes API 的参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-api/) -- [生成 Kubernetes 组件和工具的参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-components/) +- [生成 Kubernetes API 的参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-api/) +- [生成 Kubernetes 组件和工具的参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-components/) ## {{% heading "prerequisites" %}} @@ -406,7 +406,7 @@ You are now ready to follow the [Generating Reference Documentation for the Kube [published Kubernetes API reference documentation](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/). --> 现在，你可以按照 -[生成 Kubernetes API 的参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-api/) +[生成 Kubernetes API 的参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-api/) 指南来生成 [已发布的 Kubernetes API 参考文档](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)。 @@ -417,7 +417,7 @@ You are now ready to follow the [Generating Reference Documentation for the Kube * [Generating Reference Docs for Kubernetes Components and Tools](/docs/home/contribute/generated-reference/kubernetes-components/) * [Generating Reference Documentation for kubectl Commands](/docs/home/contribute/generated-reference/kubectl/) --> -* [生成 Kubernetes API 的参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-api/) -* [为 Kubernetes 组件和工具生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-components/) -* [生成 kubectl 命令的参考文档](/zh/docs/contribute/generate-ref-docs/kubectl/) +* [生成 Kubernetes API 的参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-api/) +* [为 Kubernetes 组件和工具生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-components/) +* [生成 kubectl 命令的参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubectl/) diff --git a/content/zh-cn/docs/contribute/generate-ref-docs/kubectl.md b/content/zh-cn/docs/contribute/generate-ref-docs/kubectl.md index 97f539bdf9..957ca8b347 100644 --- a/content/zh-cn/docs/contribute/generate-ref-docs/kubectl.md +++ b/content/zh-cn/docs/contribute/generate-ref-docs/kubectl.md @@ -36,7 +36,7 @@ reference page, see 生成参考文档，如 [kubectl apply](/docs/reference/generated/kubectl/kubectl-commands#apply) 和 [kubectl taint](/docs/reference/generated/kubectl/kubectl-commands#taint)。 本主题没有讨论如何生成 [kubectl](/docs/reference/generated/kubectl/kubectl-commands/) 组件选项的参考页面。 -相关说明请参见[为 Kubernetes 组件和工具生成参考页面](/zh/docs/contribute/generate-ref-docs/kubernetes-components/)。 +相关说明请参见[为 Kubernetes 组件和工具生成参考页面](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-components/)。 {{< /note >}} ## {{% heading "prerequisites" %}} @@ -416,7 +416,7 @@ topics will be visible in the 对 `kubernetes/website` 仓库创建 PR。跟踪你的 PR，并根据需要回应评审人的评论。 继续跟踪你的 PR，直到它被合入。 -在 PR 合入的几分钟后，你更新的参考主题将出现在[已发布文档](/zh/docs/home/)中。 +在 PR 合入的几分钟后，你更新的参考主题将出现在[已发布文档](/zh-cn/docs/home/)中。 ## {{% heading "whatsnext" %}} @@ -425,7 +425,7 @@ topics will be visible in the * [Generating Reference Documentation for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/) * [Generating Reference Documentation for the Kubernetes API](/docs/contribute/generate-ref-docs/kubernetes-api/) --> -* [生成参考文档快速入门](/zh/docs/contribute/generate-ref-docs/quickstart/) -* [为 Kubernetes 组件和工具生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-components/) -* [为 Kubernetes API 生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-api/) +* [生成参考文档快速入门](/zh-cn/docs/contribute/generate-ref-docs/quickstart/) +* [为 Kubernetes 组件和工具生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-components/) +* [为 Kubernetes API 生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-api/) diff --git a/content/zh-cn/docs/contribute/generate-ref-docs/kubernetes-api.md b/content/zh-cn/docs/contribute/generate-ref-docs/kubernetes-api.md index 7ec78b9c17..74fc1fe897 100644 --- a/content/zh-cn/docs/contribute/generate-ref-docs/kubernetes-api.md +++ b/content/zh-cn/docs/contribute/generate-ref-docs/kubernetes-api.md @@ -31,7 +31,7 @@ Kubernetes API 参考文档是从 构建的， 且使用[kubernetes-sigs/reference-docs](https://github.com/kubernetes-sigs/reference-docs) 生成代码。 -如果你在生成的文档中发现错误，则需要[在上游修复](/zh/docs/contribute/generate-ref-docs/contribute-upstream/)。 +如果你在生成的文档中发现错误，则需要[在上游修复](/zh-cn/docs/contribute/generate-ref-docs/contribute-upstream/)。 如果你只需要从 [OpenAPI](https://github.com/OAI/OpenAPI-Specification) 规范中重新生成参考文档，请继续阅读此页。 @@ -305,7 +305,7 @@ Submit your changes as a Monitor your pull request, and respond to reviewer comments as needed. Continue to monitor your pull request until it has been merged. --> -基于你所生成的更改[创建 PR](/zh/docs/contribute/new-content/open-a-pr/)， +基于你所生成的更改[创建 PR](/zh-cn/docs/contribute/new-content/open-a-pr/)， 提交到 [kubernetes/website](https://github.com/kubernetes/website) 仓库。 监视你提交的 PR，并根据需要回复 reviewer 的评论。继续监视你的 PR，直到合并为止。 @@ -316,7 +316,7 @@ to monitor your pull request until it has been merged. * [Generating Reference Docs for Kubernetes Components and Tools](/docs/contribute/generate-ref-docs/kubernetes-components/) * [Generating Reference Documentation for kubectl Commands](/docs/contribute/generate-ref-docs/kubectl/) --> -* [生成参考文档快速入门](/zh/docs/contribute/generate-ref-docs/quickstart/) -* [为 Kubernetes 组件和工具生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-components/) -* [为 kubectl 命令集生成参考文档](/zh/docs/contribute/generate-ref-docs/kubectl/) +* [生成参考文档快速入门](/zh-cn/docs/contribute/generate-ref-docs/quickstart/) +* [为 Kubernetes 组件和工具生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-components/) +* [为 kubectl 命令集生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubectl/) diff --git a/content/zh-cn/docs/contribute/generate-ref-docs/kubernetes-components.md b/content/zh-cn/docs/contribute/generate-ref-docs/kubernetes-components.md index 0ca9d48df6..a89e8d655e 100644 --- a/content/zh-cn/docs/contribute/generate-ref-docs/kubernetes-components.md +++ b/content/zh-cn/docs/contribute/generate-ref-docs/kubernetes-components.md @@ -23,7 +23,7 @@ This page shows how to build the Kubernetes component and tool reference pages. Start with the [Prerequisites section](/docs/contribute/generate-ref-docs/quickstart/#before-you-begin) in the Reference Documentation Quickstart guide. --> -阅读参考文档快速入门指南中的[准备工作](/zh/docs/contribute/generate-ref-docs/quickstart/#before-you-begin)节。 +阅读参考文档快速入门指南中的[准备工作](/zh-cn/docs/contribute/generate-ref-docs/quickstart/#before-you-begin)节。 @@ -31,7 +31,7 @@ in the Reference Documentation Quickstart guide. Follow the [Reference Documentation Quickstart](/docs/contribute/generate-ref-docs/quickstart/) to generate the Kubernetes component and tool reference pages. --> -按照[参考文档快速入门](/zh/docs/contribute/generate-ref-docs/quickstart/) +按照[参考文档快速入门](/zh-cn/docs/contribute/generate-ref-docs/quickstart/) 指引，生成 Kubernetes 组件和工具的参考文档。 ## {{% heading "whatsnext" %}} @@ -43,8 +43,8 @@ to generate the Kubernetes component and tool reference pages. * [Contributing to the Upstream Kubernetes Project for Documentation](/docs/contribute/generate-ref-docs/contribute-upstream/) --> -* [生成参考文档快速入门](/zh/docs/contribute/generate-ref-docs/quickstart/) -* [为 kubectll 命令生成参考文档](/zh/docs/contribute/generate-ref-docs/kubectl/) -* [为 Kubernetes API 生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-api/) -* [为上游 Kubernetes 项目做贡献以改进文档](/zh/docs/contribute/generate-ref-docs/contribute-upstream/) +* [生成参考文档快速入门](/zh-cn/docs/contribute/generate-ref-docs/quickstart/) +* [为 kubectll 命令生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubectl/) +* [为 Kubernetes API 生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-api/) +* [为上游 Kubernetes 项目做贡献以改进文档](/zh-cn/docs/contribute/generate-ref-docs/contribute-upstream/) diff --git a/content/zh-cn/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md b/content/zh-cn/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md index 5d5cde99f8..7954f939c0 100644 --- a/content/zh-cn/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md +++ b/content/zh-cn/docs/contribute/generate-ref-docs/prerequisites-ref-docs.md @@ -41,5 +41,5 @@ - 你需要知道如何为一个 GitHub 仓库创建拉取请求（PR）。 这牵涉到创建仓库的派生（fork）副本。 - 有关信息可进一步查看[基于本地副本开展工作](/zh/docs/contribute/new-content/open-a-pr/#fork-the-repo)。 + 有关信息可进一步查看[基于本地副本开展工作](/zh-cn/docs/contribute/new-content/open-a-pr/#fork-the-repo)。 diff --git a/content/zh-cn/docs/contribute/generate-ref-docs/quickstart.md b/content/zh-cn/docs/contribute/generate-ref-docs/quickstart.md index 521b834153..7c4336aae5 100644 --- a/content/zh-cn/docs/contribute/generate-ref-docs/quickstart.md +++ b/content/zh-cn/docs/contribute/generate-ref-docs/quickstart.md @@ -57,7 +57,7 @@ see the [contributing upstream guide](/docs/contribute/generate-ref-docs/contrib {{< note>}} 如果你希望更改构建工具和 API 参考资料，可以阅读 -[上游贡献指南](/zh/docs/contribute/generate-ref-docs/contribute-upstream). +[上游贡献指南](/zh-cn/docs/contribute/generate-ref-docs/contribute-upstream). {{< /note >}} 通过工具导入的单页面的 Markdown 文档必须遵从 -[文档样式指南](/zh/docs/contribute/style/style-guide/)。 +[文档样式指南](/zh-cn/docs/contribute/style/style-guide/)。 要手动设置所需的构造仓库，执行构建目标，以生成各个参考文档，可参考下面的指南： -* [为 Kubernetes 组件和工具生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-components/) -* [为 kubectl 命令生成参考文档](/zh/docs/contribute/generate-ref-docs/kubectl/) -* [为 Kubernetes API 生成参考文档](/zh/docs/contribute/generate-ref-docs/kubernetes-api/) +* [为 Kubernetes 组件和工具生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-components/) +* [为 kubectl 命令生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubectl/) +* [为 Kubernetes API 生成参考文档](/zh-cn/docs/contribute/generate-ref-docs/kubernetes-api/) diff --git a/content/zh-cn/docs/contribute/localization.md b/content/zh-cn/docs/contribute/localization.md index 47d56e6163..9c21b55e2a 100644 --- a/content/zh-cn/docs/contribute/localization.md +++ b/content/zh-cn/docs/contribute/localization.md @@ -73,7 +73,7 @@ The website content directory includes sub-directories for each language. The lo ### 派生（fork）并且克隆仓库 {#fork-and-clone-the-repo} 首先，为 [kubernetes/website](https://github.com/kubernetes/website) 仓库 -[创建你自己的副本](/zh/docs/contribute/new-content/open-a-pr/#fork-the-repo)。 +[创建你自己的副本](/zh-cn/docs/contribute/new-content/open-a-pr/#fork-the-repo)。 ### 打开拉取请求 {#open-a-pull-request} -接下来，[打开拉取请求](/zh/docs/contribute/new-content/open-a-pr/#open-a-pr)（PR） +接下来，[打开拉取请求](/zh-cn/docs/contribute/new-content/open-a-pr/#open-a-pr)（PR） 将本地化添加到 `kubernetes/website` 存储库。 PR 必须包含所有[最低要求内容](#minimum-required-content)才能获得批准。 @@ -515,9 +515,9 @@ Releases | [All heading and subheading URLs](/releases) --> 描述 | 网址 -----|----- -主页 | [所有标题和副标题网址](/zh/docs/home/) -安装 | [所有标题和副标题网址](/zh/docs/setup/) -教程 | [Kubernetes 基础](/zh/docs/tutorials/kubernetes-basics/), [Hello Minikube](/zh/docs/tutorials/hello-minikube/) +主页 | [所有标题和副标题网址](/zh-cn/docs/home/) +安装 | [所有标题和副标题网址](/zh-cn/docs/setup/) +教程 | [Kubernetes 基础](/zh-cn/docs/tutorials/kubernetes-basics/), [Hello Minikube](/zh-cn/docs/tutorials/hello-minikube/) 网站字符串 | [所有网站字符串](#Site-strings-in-i18n) 发行版本 | [所有标题和副标题 URL](/releases) @@ -525,7 +525,7 @@ Releases | [All heading and subheading URLs](/releases) Translated documents must reside in their own `content/**/` subdirectory, but otherwise follow the same URL path as the English source. For example, to prepare the [Kubernetes Basics](/docs/tutorials/kubernetes-basics/) tutorial for translation into German, create a subfolder under the `content/de/` folder and copy the English source: --> 翻译后的文档必须保存在自己的 `content/**/` 子目录中，否则将遵循与英文源相同的 URL 路径。 -例如，要准备将 [Kubernetes 基础](/zh/docs/tutorials/kubernetes-basics/) 教程翻译为德语， +例如，要准备将 [Kubernetes 基础](/zh-cn/docs/tutorials/kubernetes-basics/) 教程翻译为德语， 请在 `content/de/` 文件夹下创建一个子文件夹并复制英文源： ```shell @@ -634,7 +634,7 @@ Some language teams have their own language-specific style guide and glossary. F ### 特定语言的样式指南和词汇表 {#language-specific-style-guide-and-glossary} 一些语言团队有自己的特定语言样式指南和词汇表。 -例如，请参见[中文本地化指南](/zh/docs/contribute/localization_zh/)。 +例如，请参见[中文本地化指南](/zh-cn/docs/contribute/localization_zh/)。 - 你可以使用 [Docsy 短代码](https://www.docsy.dev/docs/adding-content/shortcodes/) - 或[定制的 Hugo 短代码](/zh/docs/contribute/style/hugo-shortcodes/)贡献 Kubernetes 文档。 + 或[定制的 Hugo 短代码](/zh-cn/docs/contribute/style/hugo-shortcodes/)贡献 Kubernetes 文档。 - 除了标准的 Hugo 短代码外， - 我们还在文档中使用一些[定制的 Hugo 短代码](/zh/docs/contribute/style/hugo-shortcodes/)来控制内容的呈现。 + 我们还在文档中使用一些[定制的 Hugo 短代码](/zh-cn/docs/contribute/style/hugo-shortcodes/)来控制内容的呈现。 - 文档的源代码有多种语言形式，位于 `/content/` 目录下。 每种语言都有一个自己的目录，用两个字母表示，这两个字母是基于 [ISO 639-1 标准](https://www.loc.gov/standards/iso639-2/php/code_list.php)来确定的。 例如，英语文档的源代码位于 `/content/en/docs/` 目录下。 - 关于为多语言文档做贡献以及如何开始新翻译的详细信息， - 可参考[本地化文档](/zh/docs/contribute/localization)。 + 可参考[本地化文档](/zh-cn/docs/contribute/localization)。 -- [发起一个包含新博文的 PR](/zh/docs/contribute/new-content/open-a-pr/#fork-the-repo)。 +- [发起一个包含新博文的 PR](/zh-cn/docs/contribute/new-content/open-a-pr/#fork-the-repo)。 新博文要创建于 [`content/en/blog/_posts`](https://github.com/kubernetes/website/tree/main/content/en/blog/_posts) 目录下。 - 确保你的博文遵从合适的命名规范，并带有下面的引言（元数据）信息： diff --git a/content/zh-cn/docs/contribute/new-content/new-features.md b/content/zh-cn/docs/contribute/new-content/new-features.md index 031ce848fd..bf75186ac3 100644 --- a/content/zh-cn/docs/contribute/new-content/new-features.md +++ b/content/zh-cn/docs/contribute/new-content/new-features.md @@ -64,7 +64,7 @@ the techniques described in 在你选定了某个功能特性，为其撰写文档（主笔或辅助），请在 `#sig-docs` Slack 频道、SIG Docs 的每周例会上， 或者在功能特性对应的 PR 上提出咨询。 如果继续工作是没有问题的，你可以使用 -[向他人的 PR 中提交](/zh/docs/contribute/review/for-approvers/#commit-into-another-persons-pr) +[向他人的 PR 中提交](/zh-cn/docs/contribute/review/for-approvers/#commit-into-another-persons-pr) 中描述的技术之一，参与 PR 的编辑工作。 如果你在处理的功能特性处于 Alpha 或 Beta 阶段并由某特性门控控制， 请确保在你的 PR 中，该特性门控被添加到 -[Alpha/Beta 特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features) +[Alpha/Beta 特性门控](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-alpha-or-beta-features) 表格中。对于新的特性门控选项，需要为该特性门控提供一段描述。 如果所处理的功能特性已经进入正式发布（GA）状态或者被废弃， 请确保将其从上述表格中迁移到 -[已毕业或废弃的特性](/zh/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-graduated-or-deprecated-features) +[已毕业或废弃的特性](/zh-cn/docs/reference/command-line-tools-reference/feature-gates/#feature-gates-for-graduated-or-deprecated-features) 表格中，并确保迁移后保留其 Alpha、Beta 版本变迁历史。 {{< note >}} **代码开发者们**：如果你在为下一个 Kubernetes 发行版本中的某功能特性撰写文档， -请参考[为发行版本撰写功能特性文档](/zh/docs/contribute/new-content/new-features/)。 +请参考[为发行版本撰写功能特性文档](/zh-cn/docs/contribute/new-content/new-features/)。 {{< /note >}} 要贡献新的内容页面或者改进已有内容页面，请发起拉取请求（PR）。 -请确保你满足了[开始之前](/zh/docs/contribute/new-content/#before-you-begin)一节中所列举的所有要求。 +请确保你满足了[开始之前](/zh-cn/docs/contribute/new-content/#before-you-begin)一节中所列举的所有要求。 -- 阅读[评阅](/zh/docs/contribute/review/reviewing-prs)节，学习评阅过程。 +- 阅读[评阅](/zh-cn/docs/contribute/review/reviewing-prs)节，学习评阅过程。 diff --git a/content/zh-cn/docs/contribute/participate/_index.md b/content/zh-cn/docs/contribute/participate/_index.md index 42b4df0ef6..acffd9d90a 100644 --- a/content/zh-cn/docs/contribute/participate/_index.md +++ b/content/zh-cn/docs/contribute/participate/_index.md @@ -214,7 +214,7 @@ SIG Docs 批准人。下面是合并的工作机制： diff --git a/content/zh-cn/docs/contribute/participate/pr-wranglers.md b/content/zh-cn/docs/contribute/participate/pr-wranglers.md index b2d9748839..9ec889d8cd 100644 --- a/content/zh-cn/docs/contribute/participate/pr-wranglers.md +++ b/content/zh-cn/docs/contribute/participate/pr-wranglers.md @@ -15,11 +15,11 @@ SIG Docs [approvers](/docs/contribute/participate/roles-and-responsibilities/#ap This section covers the duties of a PR wrangler. For more information on giving good reviews, see [Reviewing changes](/docs/contribute/review/). --> -SIG Docs 的[批准人（Approvers）](/zh/docs/contribute/participate/roles-and-responsibilities/#approvers)们每周轮流负责 +SIG Docs 的[批准人（Approvers）](/zh-cn/docs/contribute/participate/roles-and-responsibilities/#approvers)们每周轮流负责 [管理仓库的 PR](https://github.com/kubernetes/website/wiki/PR-Wranglers)。 本节介绍 PR 管理者的职责。关于如何提供较好的评审意见， -可参阅[评审变更](/zh/docs/contribute/review/)。 +可参阅[评审变更](/zh-cn/docs/contribute/review/)。 @@ -36,11 +36,11 @@ Each day in a week-long shift as PR Wrangler: 在为期一周的轮值期内，PR 管理者要： - 每天对新增的 Issues 判定和打标签。参见 - [对 Issues 进行判定和分类](/zh/docs/contribute/review/for-approvers/#triage-and-categorize-issues) + [对 Issues 进行判定和分类](/zh-cn/docs/contribute/review/for-approvers/#triage-and-categorize-issues) 以了解 SIG Docs 如何使用元数据的详细信息。 - 检查[悬决的 PR](https://github.com/kubernetes/website/pulls) 的质量并确保它们符合 - [样式指南](/zh/docs/contribute/style/style-guide/)和 - [内容指南](/zh/docs/contribute/style/content-guide/)要求。 + [样式指南](/zh-cn/docs/contribute/style/style-guide/)和 + [内容指南](/zh-cn/docs/contribute/style/content-guide/)要求。 - 首先查看最小的 PR（`size/XS`），然后逐渐扩展到最大的 PR（`size/XXL`），尽可能多地评审 PR。 @@ -77,7 +77,7 @@ Each day in a week-long shift as PR Wrangler: - 使用 `/approve` 评论来批准可以合并的 PR，在 PR 就绪时将其合并。 - PR 在被合并之前，应该有来自其他成员的 `/lgtm` 评论。 - 可以考虑接受那些技术上准确，但文风上不满足 - [风格指南](/zh/docs/contribute/style/style-guide/)要求的 PR。 + [风格指南](/zh-cn/docs/contribute/style/style-guide/)要求的 PR。 批准变更时，可以登记一个新的 Issue 来解决文档风格问题。 你通常可以将这些风格修复问题标记为 `good first issue`。 - 将风格修复事项标记为 `good first issue` 可以很好地确保向新加入的贡献者分派一些比较简单的任务， diff --git a/content/zh-cn/docs/contribute/participate/roles-and-responsibilities.md b/content/zh-cn/docs/contribute/participate/roles-and-responsibilities.md index fc410d5845..8df7b4cddf 100644 --- a/content/zh-cn/docs/contribute/participate/roles-and-responsibilities.md +++ b/content/zh-cn/docs/contribute/participate/roles-and-responsibilities.md @@ -40,7 +40,7 @@ Anyone can: - Contribute to a localization - Suggest improvements on [Slack](http://slack.k8s.io/) or the [SIG docs mailing list](https://groups.google.com/forum/#!forum/kubernetes-sig-docs). -After [signing the CLA](/docs/contribute/new-content/overview/#sign-the-cla), anyone can also: +After [signing the CLA](https://github.com/kubernetes/community/blob/master/CLA.md), anyone can also: - Open a pull request to improve existing content, add new content, or write a blog post or case study - Create diagrams, graphics assets, and embeddable screencasts and videos @@ -62,7 +62,7 @@ For more information, see [contributing new content](/docs/contribute/new-conten [SIG Docs 邮件列表](https://groups.google.com/forum/#!forum/kubernetes-sig-docs) 上提出改进建议。 -在[签署了 CLA](/zh-cn/docs/contribute/new-content/#sign-the-cla) 之后，任何人还可以： +在[签署了 CLA](https://github.com/kubernetes/community/blob/master/CLA.md) 之后，任何人还可以： - 发起拉取请求（PR），改进现有内容、添加新内容、撰写博客或者案例分析 - 创建示意图、图形资产或者嵌入式的截屏和视频内容 diff --git a/content/zh-cn/docs/contribute/review/for-approvers.md b/content/zh-cn/docs/contribute/review/for-approvers.md index c5763a378c..54879831b0 100644 --- a/content/zh-cn/docs/contribute/review/for-approvers.md +++ b/content/zh-cn/docs/contribute/review/for-approvers.md @@ -27,8 +27,8 @@ In addition to the rotation, a bot assigns reviewers and approvers for the PR based on the owners for the affected files. --> SIG Docs -[评阅人（Reviewers）](/zh/docs/contribute/participate/roles-and-responsibilities/#reviewers) -和[批准人（Approvers）](/zh/docs/contribute/participate/roles-and-responsibilities/#approvers) +[评阅人（Reviewers）](/zh-cn/docs/contribute/participate/roles-and-responsibilities/#reviewers) +和[批准人（Approvers）](/zh-cn/docs/contribute/participate/roles-and-responsibilities/#approvers) 在对变更进行评审时需要做一些额外的事情。 每周都有一个特定的文档批准人自愿负责对 PR 进行分类和评阅。 @@ -51,7 +51,7 @@ Everything described in [Reviewing a pull request](/docs/contribute/review/revie Kubernetes 文档遵循 [Kubernetes 代码评阅流程](https://github.com/kubernetes/community/blob/master/contributors/guide/owners.md#the-code-review-process)。 -[评阅 PR](/zh/docs/contribute/review/reviewing-prs/) 文档中所描述的所有规程都适用， +[评阅 PR](/zh-cn/docs/contribute/review/reviewing-prs/) 文档中所描述的所有规程都适用， 不过评阅人和批准人还要做以下工作： ## 添加和删除 Issue 标签 {#adding-and-removing-issue-labels} @@ -361,7 +361,7 @@ If the dead link issue is in the API or `kubectl` documentation, assign them `/p ### Blog issues -We expect [Kubernetes Blog](https://kubernetes.io/blog/) entries to become +We expect [Kubernetes Blog](/blog/) entries to become outdated over time. Therefore, we only maintain blog entries less than a year old. If an issue is related to a blog entry that is more than one year old, close the issue without fixing. @@ -375,7 +375,7 @@ close the issue without fixing. ### 博客问题 {#blog-issues} -我们预期 [Kubernetes 博客](https://kubernetes.io/blog/)条目随着时间推移都会过期。 +我们预期 [Kubernetes 博客](/zh-cn/blog/)条目随着时间推移都会过期。 因此，我们只维护一年内的博客条目。 如果某个 Issue 是与某个超过一年的博客条目有关的，可以直接关闭 Issue，不必修复。 diff --git a/content/zh-cn/docs/contribute/style/content-guide.md b/content/zh-cn/docs/contribute/style/content-guide.md index 91e9d0ee96..d506a90975 100644 --- a/content/zh-cn/docs/contribute/style/content-guide.md +++ b/content/zh-cn/docs/contribute/style/content-guide.md @@ -30,7 +30,7 @@ docs, follow the [style guide](/docs/contribute/style/style-guide). 你可以在 https://slack.k8s.io 注册到 Kubernetes Slack。 关于为 Kubernetes 文档创建新内容的更多信息，可参考 -[样式指南](/zh/docs/contribute/style/style-guide)。 +[样式指南](/zh-cn/docs/contribute/style/style-guide)。 @@ -92,9 +92,9 @@ Kubernetes 文档包含 Kubernetes 项目下的多个项目的应用示例。 Kubernetes 需要某些第三方内容才能正常工作。例如 容器运行时（containerd、CRI-O、Docker）， -[联网策略](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) -（CNI 插件），[Ingress 控制器](/zh/docs/concepts/services-networking/ingress-controllers/) -以及[日志](/zh/docs/concepts/cluster-administration/logging/)等。 +[联网策略](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/) +（CNI 插件），[Ingress 控制器](/zh-cn/docs/concepts/services-networking/ingress-controllers/) +以及[日志](/zh-cn/docs/concepts/cluster-administration/logging/)等。 只有对应的第三方开源软件（OSS）是运行 Kubernetes 所必需的，才可以在文档中包含 指向这些 Kubernetes 项目之外的软件的链接。 @@ -138,4 +138,4 @@ If you have questions about allowed content, join the [Kubernetes Slack](https:/ ## {{% heading "whatsnext" %}} -* 阅读[样式指南](/zh/docs/contribute/style/style-guide)。 +* 阅读[样式指南](/zh-cn/docs/contribute/style/style-guide)。 diff --git a/content/zh-cn/docs/contribute/style/content-organization.md b/content/zh-cn/docs/contribute/style/content-organization.md index eb35c80b5f..247d016057 100644 --- a/content/zh-cn/docs/contribute/style/content-organization.md +++ b/content/zh-cn/docs/contribute/style/content-organization.md @@ -159,7 +159,7 @@ One example is [Custom Hugo Shortcodes](/docs/contribute/style/hugo-shortcodes/) 除了独立的内容页面（Markdown 文件），Hugo 还支持 [页面包](https://gohugo.io/content-management/page-bundles/)。 -一个例子是[定制的 Hugo 短代码（shortcodes）](/zh/docs/contribute/style/hugo-shortcodes/)。 +一个例子是[定制的 Hugo 短代码（shortcodes）](/zh-cn/docs/contribute/style/hugo-shortcodes/)。 它被认为是 `leaf bundle`（叶子包）。 目录下的所有内容，包括 `index.md`，都是包的一部分。此外还包括页面间相对链接、可被处理的图像等： @@ -222,7 +222,7 @@ The `SASS` source of the stylesheets for this site is stored below `src/sass` an * Learn about the [Content guide](/docs/contribute/style/content-guide) --> -* 了解[定制 Hugo 短代码](/zh/docs/contribute/style/hugo-shortcodes/) -* 了解[样式指南](/zh/docs/contribute/style/style-guide) -* 了解[内容指南](/zh/docs/contribute/style/content-guide) +* 了解[定制 Hugo 短代码](/zh-cn/docs/contribute/style/hugo-shortcodes/) +* 了解[样式指南](/zh-cn/docs/contribute/style/style-guide) +* 了解[内容指南](/zh-cn/docs/contribute/style/content-guide) diff --git a/content/zh-cn/docs/contribute/style/diagram-guide.md b/content/zh-cn/docs/contribute/style/diagram-guide.md index 7a88803e45..55d0282f48 100644 --- a/content/zh-cn/docs/contribute/style/diagram-guide.md +++ b/content/zh-cn/docs/contribute/style/diagram-guide.md @@ -85,10 +85,10 @@ All you need to begin working with Mermaid is the following: * 对 Markdown 有一个基本的了解 * 使用 Mermaid 在线编辑器 -* 使用 [Hugo 短代码（shortcode）](/zh/docs/contribute/style/hugo-shortcodes/) +* 使用 [Hugo 短代码（shortcode）](/zh-cn/docs/contribute/style/hugo-shortcodes/) * 使用 [Hugo {{}} 短代码](https://gohugo.io/content-management/shortcodes/#figure) -* 执行 [Hugo 本地预览](/zh/docs/contribute/new-content/open-a-pr/#preview-locally) -* 熟悉[贡献新内容](/zh/docs/contribute/new-content/)的流程 +* 执行 [Hugo 本地预览](/zh-cn/docs/contribute/new-content/open-a-pr/#preview-locally) +* 熟悉[贡献新内容](/zh-cn/docs/contribute/new-content/)的流程 {{< note >}} -你必须在 Mermaid 代码块之前和之后分别添加 `{{}}`、`{{}}` +你必须在 Mermaid 代码块之前和之后分别添加 Hugo Mermaid 短代码标记，而且你应该在图表之后为其添加图表标题。 {{< /note >}} @@ -416,7 +416,7 @@ The following lists advantages of the Inline method: You should use the [local](/docs/contribute/new-content/open-a-pr/#preview-locally) and Netlify previews to verify the diagram is properly rendered. --> -你应该使用[本地](/zh/docs/contribute/new-content/open-a-pr/#preview-locally)和 Netlify +你应该使用[本地](/zh-cn/docs/contribute/new-content/open-a-pr/#preview-locally)和 Netlify 预览来验证图表是可以正常渲染的。 {{< caution >}} @@ -564,7 +564,7 @@ Be sure to check that your diagram renders properly using the [local](/docs/contribute/new-content/open-a-pr/#preview-locally) and Netlify previews. --> -要使用[本地](/zh/docs/contribute/new-content/open-a-pr/#preview-locally)和 +要使用[本地](/zh-cn/docs/contribute/new-content/open-a-pr/#preview-locally)和 Netlify 预览来检查你的图表可以正常渲染。 -代码块示例中忽略了 Hugo `{{}}`、`{{}}` 短代码标记。 +代码块示例中忽略了 Hugo Mermaid 短代码标记。 这样，你就可以将这些代码段复制到在线编辑器中自行实验。 注意，在线编辑器无法识别 Hugo 短代码。 {{< /note >}} @@ -728,7 +728,7 @@ page. --> ### 示例 1 - Pod 拓扑分布约束 -图 6 展示的是 [Pod 拓扑分布约束](/zh/docs/concepts/workloads/pods/pod-topology-spread-constraints/#node-labels) +图 6 展示的是 [Pod 拓扑分布约束](/zh-cn/docs/concepts/workloads/pods/pod-topology-spread-constraints/#node-labels) 页面所出现的图表。 {{< mermaid >}} @@ -792,7 +792,7 @@ Figure 7 shows the diagram appearing in the [What is Ingress](/docs/concepts/ser --> ### 示例 2 - Ingress -图 7 显示的是 [Ingress 是什么](/zh/docs/concepts/services-networking/ingress/#what-is-ingress) +图 7 显示的是 [Ingress 是什么](/zh-cn/docs/concepts/services-networking/ingress/#what-is-ingress) 页面所出现的图表。 {{< mermaid >}} @@ -860,7 +860,7 @@ K8s components to start a container. 图 8 给出的是一个 Mermaid 时序图，展示启动容器时 K8s 组件间的控制流。 -{{< figure src="/zh/docs/images/diagram-guide-example-3.svg" alt="K8s system flow diagram" class="diagram-large" caption="Figure 8. K8s system flow diagram" link="https://mermaid-js.github.io/mermaid-live-editor/edit/#eyJjb2RlIjoiJSV7aW5pdDp7XCJ0aGVtZVwiOlwibmV1dHJhbFwifX0lJVxuc2VxdWVuY2VEaWFncmFtXG4gICAgYWN0b3IgbWVcbiAgICBwYXJ0aWNpcGFudCBhcGlTcnYgYXMgY29udHJvbCBwbGFuZTxicj48YnI-YXBpLXNlcnZlclxuICAgIHBhcnRpY2lwYW50IGV0Y2QgYXMgY29udHJvbCBwbGFuZTxicj48YnI-ZXRjZCBkYXRhc3RvcmVcbiAgICBwYXJ0aWNpcGFudCBjbnRybE1nciBhcyBjb250cm9sIHBsYW5lPGJyPjxicj5jb250cm9sbGVyPGJyPm1hbmFnZXJcbiAgICBwYXJ0aWNpcGFudCBzY2hlZCBhcyBjb250cm9sIHBsYW5lPGJyPjxicj5zY2hlZHVsZXJcbiAgICBwYXJ0aWNpcGFudCBrdWJlbGV0IGFzIG5vZGU8YnI-PGJyPmt1YmVsZXRcbiAgICBwYXJ0aWNpcGFudCBjb250YWluZXIgYXMgbm9kZTxicj48YnI-Y29udGFpbmVyPGJyPnJ1bnRpbWVcbiAgICBtZS0-PmFwaVNydjogMS4ga3ViZWN0bCBjcmVhdGUgLWYgcG9kLnlhbWxcbiAgICBhcGlTcnYtLT4-ZXRjZDogMi4gc2F2ZSBuZXcgc3RhdGVcbiAgICBjbnRybE1nci0-PmFwaVNydjogMy4gY2hlY2sgZm9yIGNoYW5nZXNcbiAgICBzY2hlZC0-PmFwaVNydjogNC4gd2F0Y2ggZm9yIHVuYXNzaWduZWQgcG9kcyhzKVxuICAgIGFwaVNydi0-PnNjaGVkOiA1LiBub3RpZnkgYWJvdXQgcG9kIHcgbm9kZW5hbWU9XCIgXCJcbiAgICBzY2hlZC0-PmFwaVNydjogNi4gYXNzaWduIHBvZCB0byBub2RlXG4gICAgYXBpU3J2LS0-PmV0Y2Q6IDcuIHNhdmUgbmV3IHN0YXRlXG4gICAga3ViZWxldC0-PmFwaVNydjogOC4gbG9vayBmb3IgbmV3bHkgYXNzaWduZWQgcG9kKHMpXG4gICAgYXBpU3J2LT4-a3ViZWxldDogOS4gYmluZCBwb2QgdG8gbm9kZVxuICAgIGt1YmVsZXQtPj5jb250YWluZXI6IDEwLiBzdGFydCBjb250YWluZXJcbiAgICBrdWJlbGV0LT4-YXBpU3J2OiAxMS4gdXBkYXRlIHBvZCBzdGF0dXNcbiAgICBhcGlTcnYtLT4-ZXRjZDogMTIuIHNhdmUgbmV3IHN0YXRlIiwibWVybWFpZCI6IntcbiAgXCJ0aGVtZVwiOiBcImRlZmF1bHRcIlxufSIsInVwZGF0ZUVkaXRvciI6ZmFsc2UsImF1dG9TeW5jIjp0cnVlLCJ1cGRhdGVEaWFncmFtIjp0cnVlfQ" >}} +{{< figure src="/zh-cn/docs/images/diagram-guide-example-3.svg" alt="K8s system flow diagram" class="diagram-large" caption="Figure 8. K8s system flow diagram" link="https://mermaid-js.github.io/mermaid-live-editor/edit/#eyJjb2RlIjoiJSV7aW5pdDp7XCJ0aGVtZVwiOlwibmV1dHJhbFwifX0lJVxuc2VxdWVuY2VEaWFncmFtXG4gICAgYWN0b3IgbWVcbiAgICBwYXJ0aWNpcGFudCBhcGlTcnYgYXMgY29udHJvbCBwbGFuZTxicj48YnI-YXBpLXNlcnZlclxuICAgIHBhcnRpY2lwYW50IGV0Y2QgYXMgY29udHJvbCBwbGFuZTxicj48YnI-ZXRjZCBkYXRhc3RvcmVcbiAgICBwYXJ0aWNpcGFudCBjbnRybE1nciBhcyBjb250cm9sIHBsYW5lPGJyPjxicj5jb250cm9sbGVyPGJyPm1hbmFnZXJcbiAgICBwYXJ0aWNpcGFudCBzY2hlZCBhcyBjb250cm9sIHBsYW5lPGJyPjxicj5zY2hlZHVsZXJcbiAgICBwYXJ0aWNpcGFudCBrdWJlbGV0IGFzIG5vZGU8YnI-PGJyPmt1YmVsZXRcbiAgICBwYXJ0aWNpcGFudCBjb250YWluZXIgYXMgbm9kZTxicj48YnI-Y29udGFpbmVyPGJyPnJ1bnRpbWVcbiAgICBtZS0-PmFwaVNydjogMS4ga3ViZWN0bCBjcmVhdGUgLWYgcG9kLnlhbWxcbiAgICBhcGlTcnYtLT4-ZXRjZDogMi4gc2F2ZSBuZXcgc3RhdGVcbiAgICBjbnRybE1nci0-PmFwaVNydjogMy4gY2hlY2sgZm9yIGNoYW5nZXNcbiAgICBzY2hlZC0-PmFwaVNydjogNC4gd2F0Y2ggZm9yIHVuYXNzaWduZWQgcG9kcyhzKVxuICAgIGFwaVNydi0-PnNjaGVkOiA1LiBub3RpZnkgYWJvdXQgcG9kIHcgbm9kZW5hbWU9XCIgXCJcbiAgICBzY2hlZC0-PmFwaVNydjogNi4gYXNzaWduIHBvZCB0byBub2RlXG4gICAgYXBpU3J2LS0-PmV0Y2Q6IDcuIHNhdmUgbmV3IHN0YXRlXG4gICAga3ViZWxldC0-PmFwaVNydjogOC4gbG9vayBmb3IgbmV3bHkgYXNzaWduZWQgcG9kKHMpXG4gICAgYXBpU3J2LT4-a3ViZWxldDogOS4gYmluZCBwb2QgdG8gbm9kZVxuICAgIGt1YmVsZXQtPj5jb250YWluZXI6IDEwLiBzdGFydCBjb250YWluZXJcbiAgICBrdWJlbGV0LT4-YXBpU3J2OiAxMS4gdXBkYXRlIHBvZCBzdGF0dXNcbiAgICBhcGlTcnYtLT4-ZXRjZDogMTIuIHNhdmUgbmV3IHN0YXRlIiwibWVybWFpZCI6IntcbiAgXCJ0aGVtZVwiOiBcImRlZmF1bHRcIlxufSIsInVwZGF0ZUVkaXRvciI6ZmFsc2UsImF1dG9TeW5jIjp0cnVlLCJ1cGRhdGVEaWFncmFtIjp0cnVlfQ" >}} 运行 Kubernetes 需要第三方软件。例如：你通常需要将 -[DNS 服务器](/zh/docs/tasks/administer-cluster/dns-custom-nameservers/#introduction) +[DNS 服务器](/zh-cn/docs/tasks/administer-cluster/dns-custom-nameservers/#introduction) 添加到集群中，以便名称解析工作。 -当我们链接到第三方软件或以其他方式提及它时，我们会遵循[内容指南](/zh/docs/contribute/style/content-guide/) +当我们链接到第三方软件或以其他方式提及它时，我们会遵循[内容指南](/zh-cn/docs/contribute/style/content-guide/) 并标记这些第三方项目。 * 了解 [Hugo](https://gohugo.io/)。 -* 了解[撰写新的话题](/zh/docs/contribute/style/write-new-topic/)。 -* 了解[使用页面内容类型](/zh/docs/contribute/style/page-content-types/)。 -* 了解[发起 PR](/zh/docs/contribute/new-content/open-a-pr/)。 -* 了解[进阶贡献](/zh/docs/contribute/advanced/)。 +* 了解[撰写新的话题](/zh-cn/docs/contribute/style/write-new-topic/)。 +* 了解[使用页面内容类型](/zh-cn/docs/contribute/style/page-content-types/)。 +* 了解[发起 PR](/zh-cn/docs/contribute/new-content/open-a-pr/)。 +* 了解[进阶贡献](/zh-cn/docs/contribute/advanced/)。 diff --git a/content/zh-cn/docs/contribute/style/page-content-types.md b/content/zh-cn/docs/contribute/style/page-content-types.md index de72b6b4c4..2c4f11b51d 100644 --- a/content/zh-cn/docs/contribute/style/page-content-types.md +++ b/content/zh-cn/docs/contribute/style/page-content-types.md @@ -198,7 +198,7 @@ published example of a concept page. - 在 `body` 节中，详细解释对应概念； - 对于 `whatsnext` 节，提供一个项目符号列表（最多 5 个），帮助读者进一步学习掌握概念 -[注解](/zh/docs/concepts/overview/working-with-objects/annotations/)页面是一个已经 +[注解](/zh-cn/docs/concepts/overview/working-with-objects/annotations/)页面是一个已经 上线的概念页面的例子。 -- 了解[样式指南](/zh/docs/contribute/style/style-guide/) -- 了解[内容指南](/zh/docs/contribute/style/content-guide/) -- 了解[内容组织](/zh/docs/contribute/style/content-organization/) +- 了解[样式指南](/zh-cn/docs/contribute/style/style-guide/) +- 了解[内容指南](/zh-cn/docs/contribute/style/content-guide/) +- 了解[内容组织](/zh-cn/docs/contribute/style/content-organization/) diff --git a/content/zh-cn/docs/contribute/style/style-guide.md b/content/zh-cn/docs/contribute/style/style-guide.md index aee75544b4..83c9056f22 100644 --- a/content/zh-cn/docs/contribute/style/style-guide.md +++ b/content/zh-cn/docs/contribute/style/style-guide.md @@ -459,8 +459,8 @@ To specify the Kubernetes version for a task or tutorial page, include `min-kube 代码示例或者配置示例如果包含版本信息，应该与对应的文字描述一致。 如果所给的信息是特定于具体版本的，需要在 -[任务模版](/zh/docs/contribute/style/page-content-types/#task) -或[教程模版](/zh/docs/contribute/style/page-content-types/#tutorial) +[任务模版](/zh-cn/docs/contribute/style/page-content-types/#task) +或[教程模版](/zh-cn/docs/contribute/style/page-content-types/#tutorial) 的 `prerequisites` 小节定义 Kubernetes 版本。 页面保存之后，`prerequisites` 小节会显示为 **开始之前**。 @@ -952,7 +952,7 @@ Write Markdown-style links: `[link text](URL)`. For example: `[Hugo shortcodes]( 可以 | 不可以 :--| :----- 插入超级链接时给出它们所链接到的目标内容的上下文。例如：你的机器上某些端口处于开放状态。参见检查所需端口了解更详细信息。| 使用有二义性的术语，如“点击这里”。例如：你的机器上某些端口处于打开状态。参见这里了解详细信息。 -编写 Markdown 风格的链接：`[链接文本](URL)`。例如：`[Hugo 短代码](/zh/docs/contribute/style/hugo-shortcodes/#table-captions)`，输出是[Hugo 短代码](/zh/docs/contribute/style/hugo-shortcodes/#table-captions). | 编写 HTML 风格的超级链接：`访问我们的教程！`，或者创建会打开新 Tab 页或新窗口的链接。例如：`[网站示例](https://example.com){target="_blank"}`。 +编写 Markdown 风格的链接：`[链接文本](URL)`。例如：`[Hugo 短代码](/zh-cn/docs/contribute/style/hugo-shortcodes/#table-captions)`，输出是[Hugo 短代码](/zh-cn/docs/contribute/style/hugo-shortcodes/#table-captions). | 编写 HTML 风格的超级链接：`访问我们的教程！`，或者创建会打开新 Tab 页或新窗口的链接。例如：`[网站示例](https://example.com){target="_blank"}`。 {{< /table >}} -如[发起 PR](/zh/docs/contribute/new-content/open-a-pr/)中所述，创建 Kubernetes 文档库的派生副本。 +如[发起 PR](/zh-cn/docs/contribute/new-content/open-a-pr/)中所述，创建 Kubernetes 文档库的派生副本。 @@ -46,8 +46,8 @@ Tutorial | A tutorial page shows how to accomplish a goal that ties together sev {{< table caption = "选择页面类型的说明" >}} 类型 | 描述 :--- | :---------- -概念（Concept） | 概念页面负责解释 Kubernetes 的某方面。例如，概念页面可以描述 Kubernetes Deployment 对象，并解释当部署、扩展和更新时，它作为应用程序所扮演的角色。一般来说，概念页面不包括步骤序列，而是提供任务或教程的链接。概念主题的示例可参见 节点。 -任务（Task） | 任务页面展示如何完成特定任务。其目的是给读者提供一系列的步骤，让他们在阅读时可以实际执行。任务页面可长可短，前提是它始终围绕着某个主题展开。在任务页面中，可以将简短的解释与要执行的步骤混合在一起。如果需要提供较长的解释，则应在概念主题中进行。相关联的任务和概念主题应该相互链接。一个简短的任务页面的实例可参见 配置 Pod 使用卷存储。一个较长的任务页面的实例可参见 配置活跃性和就绪性探针。 +概念（Concept） | 概念页面负责解释 Kubernetes 的某方面。例如，概念页面可以描述 Kubernetes Deployment 对象，并解释当部署、扩展和更新时，它作为应用程序所扮演的角色。一般来说，概念页面不包括步骤序列，而是提供任务或教程的链接。概念主题的示例可参见 节点。 +任务（Task） | 任务页面展示如何完成特定任务。其目的是给读者提供一系列的步骤，让他们在阅读时可以实际执行。任务页面可长可短，前提是它始终围绕着某个主题展开。在任务页面中，可以将简短的解释与要执行的步骤混合在一起。如果需要提供较长的解释，则应在概念主题中进行。相关联的任务和概念主题应该相互链接。一个简短的任务页面的实例可参见 配置 Pod 使用卷存储。一个较长的任务页面的实例可参见 配置活跃性和就绪性探针。 教程（Tutorial） | 教程页面展示如何实现某个目标，该目标将若干 Kubernetes 功能特性联系在一起。教程可能提供一些步骤序列，读者可以在阅读页面时实际执行这些步骤。或者它可以提供相关代码片段的解释。例如，教程可以提供代码示例的讲解。教程可以包括对 Kubernetes 几个关联特性的简要解释，但有关更深入的特性解释应该链接到相关概念主题。 {{< /table >}} @@ -56,7 +56,7 @@ Use a [content type](/docs/contribute/style/page-content-types/) for each new pa that you write. Using page type helps ensure consistency among topics of a given type. --> -为每个新页面选择其[内容类型](/zh/docs/contribute/style/page-content-types/)。 +为每个新页面选择其[内容类型](/zh-cn/docs/contribute/style/page-content-types/)。 使用页面类型有助于确保给定类型的各主题之间保持一致。 有关使用此技术的主题的示例，请参见 -[运行单实例有状态的应用](/zh/docs/tasks/run-application/run-single-instance-stateful-application/)。 +[运行单实例有状态的应用](/zh-cn/docs/tasks/run-application/run-single-instance-stateful-application/)。 -* 了解[使用页面内容类型](/zh/docs/contribute/style/page-content-types/). -* 了解[创建 PR](/zh/docs/contribute/new-content/open-a-pr/). +* 了解[使用页面内容类型](/zh-cn/docs/contribute/style/page-content-types/). +* 了解[创建 PR](/zh-cn/docs/contribute/new-content/open-a-pr/). diff --git a/content/zh-cn/docs/home/_index.md b/content/zh-cn/docs/home/_index.md index ee0aaf68d7..738ee19bb4 100644 --- a/content/zh-cn/docs/home/_index.md +++ b/content/zh-cn/docs/home/_index.md @@ -62,7 +62,7 @@ overview: # title: K8s Release Notes # description: If you are installing Kubernetes or upgrading to the newest version, refer to the current release notes. # button: "Download Kubernetes" -# button_path: "/zh/docs/setup/release/notes" +# button_path: "/zh-cn/docs/setup/release/notes" # - name: about # title: About the documentation # description: This website contains documentation for the current and previous 4 versions of Kubernetes. @@ -71,37 +71,37 @@ cards: title: "了解 Kubernetes" description: "了解 Kubernetes 和其基础概念。" button: "查看概念" - button_path: "/zh/docs/concepts" + button_path: "/zh-cn/docs/concepts" - name: tutorials title: "尝试 Kubernetes" description: "按照教程学习如何在 Kubernetes 上部署应用。" button: "查看教程" - button_path: "/zh/docs/tutorials" + button_path: "/zh-cn/docs/tutorials" - name: setup title: "设置 K8s 集群" description: "按照你的资源情况和需求运行 Kubernetes。" button: "设置 Kubernetes" - button_path: "/zh/docs/setup" + button_path: "/zh-cn/docs/setup" - name: tasks title: "了解如何使用 Kubernetes" description: "查看常见任务以及如何使用简单步骤执行它们。" button: "查看任务" - button_path: "/zh/docs/tasks" + button_path: "/zh-cn/docs/tasks" - name: training title: "培训" description: "通过 Kubernetes 认证，助你的云原生项目成功！" button: "查看培训" - button_path: "/zh/training" + button_path: "/zh-cn/training" - name: reference title: 查阅参考信息 description: 浏览术语、命令行语法、API 资源类型和安装工具文档。 button: 查看参考 - button_path: /zh/docs/reference + button_path: /zh-cn/docs/reference - name: contribute title: 为文档作贡献 description: 任何人，无论对该项目熟悉与否，都能贡献自己的力量。 button: 为文档作贡献 - button_path: /zh/docs/contribute + button_path: /zh-cn/docs/contribute - name: release-notes title: K8s 发布说明 description: 如果你正在安装或升级 Kubernetes，最好参考最新的发布说明。 diff --git a/content/zh-cn/docs/home/supported-doc-versions.md b/content/zh-cn/docs/home/supported-doc-versions.md index d455a039a3..6fc4dcf339 100644 --- a/content/zh-cn/docs/home/supported-doc-versions.md +++ b/content/zh-cn/docs/home/supported-doc-versions.md @@ -31,4 +31,4 @@ which versions of Kubernetes are officially supported, and for how long. 本网站包含当前版本和之前四个版本的 Kubernetes 文档。 Kubernetes 版本的文档可用性与当前是否支持该版本是分开的。 -阅读[支持期限](/zh/releases/patch-releases/#support-period)，了解官方支持 Kubernetes 的哪些版本，以及支持多长时间。 +阅读[支持期限](/zh-cn/releases/patch-releases/#support-period)，了解官方支持 Kubernetes 的哪些版本，以及支持多长时间。 diff --git a/content/zh-cn/docs/reference/_index.md b/content/zh-cn/docs/reference/_index.md index af2a04118b..c0ca319c1f 100644 --- a/content/zh-cn/docs/reference/_index.md +++ b/content/zh-cn/docs/reference/_index.md @@ -38,15 +38,14 @@ This section of the Kubernetes documentation contains references. * [API access control](/docs/reference/access-authn-authz/) - details on how Kubernetes controls API access * [Well-Known Labels, Annotations and Taints](/docs/reference/labels-annotations-taints/) --> -## API 参考 +## API 参考 {#api-reference} -* [术语表](/zh/docs/reference/glossary/) - 一个全面的标准化的 Kubernetes 术语表 - -* [Kubernetes API 参考](/zh/docs/reference/kubernetes-api/) +* [术语表](/zh-cn/docs/reference/glossary/) —— 一个全面的、标准化的 Kubernetes 术语表 +* [Kubernetes API 参考](/zh-cn/docs/reference/kubernetes-api/) * [Kubernetes API 单页参考 {{< param "version" >}}](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)。 -* [使用 Kubernetes API ](/zh/docs/reference/using-api/) - Kubernetes 的 API 概述 -* [API 的访问控制](/zh/docs/reference/access-authn-authz/) - 关于 Kubernetes 如何控制 API 访问的详细信息 -* [常见的标签、注解和污点](/zh/docs/reference/labels-annotations-taints/) +* [使用 Kubernetes API ](/zh-cn/docs/reference/using-api/) —— Kubernetes 的 API 概述 +* [API 的访问控制](/zh-cn/docs/reference/access-authn-authz/) —— 关于 Kubernetes 如何控制 API 访问的详细信息 +* [常见的标签、注解和污点](/zh-cn/docs/reference/labels-annotations-taints/) -## 官方支持的客户端库 +## 官方支持的客户端库 {#officially-supported-client-libraries} -如果你需要通过编程语言调用 Kubernetes API，你可以使用 -[客户端库](/zh/docs/reference/using-api/client-libraries/)。以下是官方支持的客户端库： +如果你需要通过编程语言调用 Kubernetes API，你可以使用[客户端库](/zh-cn/docs/reference/using-api/client-libraries/)。 +以下是官方支持的客户端库： - [Kubernetes Go 语言客户端库](https://github.com/kubernetes/client-go/) - [Kubernetes Python 语言客户端库](https://github.com/kubernetes-client/python) @@ -83,10 +82,10 @@ client libraries: --> ## CLI -* [kubectl](/zh/docs/reference/kubectl/) - 主要的 CLI 工具，用于运行命令和管理 Kubernetes 集群。 - * [JSONPath](/zh/docs/reference/kubectl/jsonpath/) - 通过 kubectl 使用 - [JSONPath 表达式](https://goessner.net/articles/JsonPath/) 的语法指南。 -* [kubeadm](/zh/docs/reference/setup-tools/kubeadm/) - 此 CLI 工具可轻松配置安全的 Kubernetes 集群。 +* [kubectl](/zh-cn/docs/reference/kubectl/) —— 主要的 CLI 工具，用于运行命令和管理 Kubernetes 集群。 + * [JSONPath](/zh-cn/docs/reference/kubectl/jsonpath/) —— 通过 kubectl 使用 + [JSONPath 表达式](https://goessner.net/articles/JsonPath/) 的语法指南。 +* [kubeadm](/zh-cn/docs/reference/setup-tools/kubeadm/) - 此 CLI 工具可轻松配置安全的 Kubernetes 集群。 -## 组件 +## 组件 {#components} -* [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) - - 在每个节点上运行的主代理。kubelet 接收一组 PodSpecs 并确保其所描述的容器健康地运行。 -* [kube-apiserver](/zh/docs/reference/command-line-tools-reference/kube-apiserver/) - +* [kubelet](/zh-cn/docs/reference/command-line-tools-reference/kubelet/) —— + 在每个节点上运行的主代理。kubelet 接收一组 PodSpec 并确保其所描述的容器健康地运行。 +* [kube-apiserver](/zh-cn/docs/reference/command-line-tools-reference/kube-apiserver/) —— REST API，用于验证和配置 API 对象（如 Pod、服务或副本控制器等）的数据。 -* [kube-controller-manager](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) - +* [kube-controller-manager](/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/) —— 一个守护进程，其中包含 Kubernetes 所附带的核心控制回路。 -* [kube-proxy](/zh/docs/reference/command-line-tools-reference/kube-proxy/) - +* [kube-proxy](/zh-cn/docs/reference/command-line-tools-reference/kube-proxy/) —— 可进行简单的 TCP/UDP 流转发或针对一组后端执行轮流 TCP/UDP 转发。 -* [kube-scheduler](/zh/docs/reference/command-line-tools-reference/kube-scheduler/) - +* [kube-scheduler](/zh-cn/docs/reference/command-line-tools-reference/kube-scheduler/) —— 一个调度程序，用于管理可用性、性能和容量。 - * [调度策略](/zh/docs/reference/scheduling/policies) - * [调度配置](/zh/docs/reference/scheduling/config#profiles) - * 应该在控制平面和工作节点上打开的 [端口和协议](/zh/docs/reference/ports-and-protocols/) - - 列表 + * [调度策略](/zh-cn/docs/reference/scheduling/policies) + * [调度配置](/zh-cn/docs/reference/scheduling/config#profiles) + * 应该在控制平面和工作节点上打开的[端口和协议](/zh-cn/docs/reference/ports-and-protocols/)列表 -## 配置 API +## 配置 API {#config-apis} 本节包含用于配置 kubernetes 组件或工具的 "未发布" API 的文档。 尽管这些 API 对于用户或操作者使用或管理集群来说是必不可少的， 它们大都没有以 RESTful 的方式在 API 服务器上公开。 -* [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/) -* [kubelet 凭据驱动 (v1beta1)](/zh/docs/reference/config-api/kubelet-credentialprovider.v1beta1/) -* [kube-scheduler 配置 (v1beta2)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta2/) 和 - [kube-scheduler 配置 (v1beta3)](/zh/docs/reference/config-api/kube-scheduler-config.v1beta3/) -* [kube-proxy 配置 (v1alpha1)](/zh/docs/reference/config-api/kube-proxy-config.v1alpha1/) -* [`audit.k8s.io/v1` API](/zh/docs/reference/config-api/apiserver-audit.v1/) -* [客户端认证 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/) +* [kube-apiserver 配置 (v1alpha1)](/zh-cn/docs/reference/config-api/apiserver-config.v1alpha1/) +* [kube-apiserver 配置 (v1)](/zh-cn/docs/reference/config-api/apiserver-config.v1/) +* [kube-apiserver 加密 (v1)](/zh-cn/docs/reference/config-api/apiserver-encryption.v1/) +* [kube-apiserver 事件速率限制 (v1alpha1)](/zh-cn/docs/reference/config-api/apiserver-eventratelimit.v1/) +* [kubelet 配置 (v1alpha1)](/zh-cn/docs/reference/config-api/kubelet-config.v1alpha1/) 和 + [kubelet 配置 (v1beta1)](/zh-cn/docs/reference/config-api/kubelet-config.v1beta1/) +* [kubelet 凭据驱动 (v1alpha1)](/zh-cn/docs/reference/config-api/kubelet-credentialprovider.v1alpha1/) +* [kubelet 凭据驱动 (v1beta1)](/zh-cn/docs/reference/config-api/kubelet-credentialprovider.v1beta1/) +* [kube-scheduler 配置 (v1beta2)](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta2/) 和 + [kube-scheduler 配置 (v1beta3)](/zh-cn/docs/reference/config-api/kube-scheduler-config.v1beta3/) +* [kube-proxy 配置 (v1alpha1)](/zh-cn/docs/reference/config-api/kube-proxy-config.v1alpha1/) +* [`audit.k8s.io/v1` API](/zh-cn/docs/reference/config-api/apiserver-audit.v1/) +* [客户端身份认证 API (v1beta1)](/zh-cn/docs/reference/config-api/client-authentication.v1beta1/) 和 + [客户端身份认证 API (v1)](/zh-cn/docs/reference/config-api/client-authentication.v1/) +* [WebhookAdmission 配置 (v1)](/zh-cn/docs/reference/config-api/apiserver-webhookadmission.v1/) +* [ImagePolicy API (v1alpha1)](/zh-cn/docs/reference/config-api/imagepolicy.v1alpha1/) +## kubeadm 的配置 API {#config-api-for-kubeadm} -## kubeadm 的配置 API - -* [v1beta2](/zh/docs/reference/config-api/kubeadm-config.v1beta2/) -* [v1beta3](/zh/docs/reference/config-api/kubeadm-config.v1beta3/) +* [v1beta2](/zh-cn/docs/reference/config-api/kubeadm-config.v1beta2/) +* [v1beta3](/zh-cn/docs/reference/config-api/kubeadm-config.v1beta3/) -## 设计文档 +## 设计文档 {#design-docs} Kubernetes 功能的设计文档归档，不妨考虑从 -[Kubernetes 架构](https://git.k8s.io/community/contributors/design-proposals/architecture/architecture.md) 和 -[Kubernetes 设计概述](https://git.k8s.io/community/contributors/design-proposals) +[Kubernetes 架构](https://git.k8s.io/design-proposals-archive/architecture/architecture.md) 和 +[Kubernetes 设计概述](https://git.k8s.io/design-proposals-archive) 开始阅读。 diff --git a/content/zh-cn/docs/reference/access-authn-authz/_index.md b/content/zh-cn/docs/reference/access-authn-authz/_index.md index c26b1e38b2..4a47d52636 100644 --- a/content/zh-cn/docs/reference/access-authn-authz/_index.md +++ b/content/zh-cn/docs/reference/access-authn-authz/_index.md @@ -16,8 +16,8 @@ read [Controlling Access to the Kubernetes API](/docs/concepts/security/controll Reference documentation: --> -关于 Kubernetes 如何实现和控制 API 访问的介绍性材料，可阅读 -[控制 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access/)。 +关于 Kubernetes 如何实现和控制 API 访问的介绍性材料， +可阅读[控制 Kubernetes API 的访问](/zh-cn/docs/concepts/security/controlling-access/)。 参考文档： @@ -40,20 +40,21 @@ Reference documentation: - [Kubelet Authentication & Authorization](/docs/reference/access-authn-authz/kubelet-authn-authz/) - including kubelet [TLS bootstrapping](/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) --> -- [身份认证](/zh/docs/reference/access-authn-authz/authentication/) - - [使用启动引导令牌来执行身份认证](/zh/docs/reference/access-authn-authz/bootstrap-tokens/) -- [准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/) - - [动态准入控制](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/) -- [鉴权与授权](/zh/docs/reference/access-authn-authz/authorization/) - - [基于角色的访问控制](/zh/docs/reference/access-authn-authz/rbac/) - - [基于属性的访问控制](/zh/docs/reference/access-authn-authz/abac/) - - [节点鉴权](/zh/docs/reference/access-authn-authz/node/) - - [Webhook 鉴权](/zh/docs/reference/access-authn-authz/webhook/) -- [证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/) - - 包含 [CSR 的批复](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection) - 和[证书签名](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#signing) +- [身份认证](/zh-cn/docs/reference/access-authn-authz/authentication/) + - [使用启动引导令牌来执行身份认证](/zh-cn/docs/reference/access-authn-authz/bootstrap-tokens/) +- [准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/) + - [动态准入控制](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/) +- [鉴权与授权](/zh-cn/docs/reference/access-authn-authz/authorization/) + - [基于角色的访问控制](/zh-cn/docs/reference/access-authn-authz/rbac/) + - [基于属性的访问控制](/zh-cn/docs/reference/access-authn-authz/abac/) + - [节点鉴权](/zh-cn/docs/reference/access-authn-authz/node/) + - [Webhook 鉴权](/zh-cn/docs/reference/access-authn-authz/webhook/) +- [证书签名请求](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/) + - 包含 [CSR 的批复](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/#approval-rejection) + 和[证书签名](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/#signing) - 服务账号 - - [开发者指南](/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/) + - [开发者指南](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/) + - [管理文档](/zh-cn/docs/reference/access-authn-authz/service-accounts-admin/) +- [Kubelet 认证和鉴权](/zh-cn/docs/reference/access-authn-authz/kubelet-authn-authz/) + - 包括 kubelet [TLS 启动引导](/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping/) + diff --git a/content/zh-cn/docs/reference/access-authn-authz/admission-controllers.md b/content/zh-cn/docs/reference/access-authn-authz/admission-controllers.md index a64cd6d252..5380576973 100644 --- a/content/zh-cn/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/zh-cn/docs/reference/access-authn-authz/admission-controllers.md @@ -47,7 +47,7 @@ which are configured in the API. 并编译进 `kube-apiserver` 可执行文件，并且只能由集群管理员配置。 在该列表中，有两个特殊的控制器：MutatingAdmissionWebhook 和 ValidatingAdmissionWebhook。 它们根据 API 中的配置，分别执行变更和验证 -[准入控制 webhook](/zh/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。 +[准入控制 webhook](/zh-cn/docs/reference/access-authn-authz/extensible-admission-controllers/#admission-webhooks)。 -## 为什么需要准入控制器？ {#why-do-i-need-them} - +## 为什么需要准入控制器？ {#why-do-i-need-them} + Kubernetes 的许多高级功能都要求启用一个准入控制器，以便正确地支持该特性。 因此，没有正确配置准入控制器的 Kubernetes API 服务器是不完整的，它无法支持你所期望的所有特性。 -## 如何启用一个准入控制器？ {#how-do-i-turn-on-an-admission-controller} - +## 如何启用一个准入控制器？ {#how-do-i-turn-on-an-admission-controller} + Kubernetes API 服务器的 `enable-admission-plugins` 标志接受一个（以逗号分隔的）准入控制插件列表， 这些插件会在集群修改对象之前被调用。 @@ -163,7 +161,6 @@ kube-apiserver -h | grep enable-admission-plugins - 在目前版本中，默认启用的插件有： ``` @@ -226,7 +223,7 @@ See [Certificate Signing Requests](/docs/reference/access-authn-authz/certificat information on the permissions required to perform different actions on CertificateSigningRequest resources. --> 有关对 CertificateSigningRequest 资源执行不同操作所需权限的详细信息， -请参阅[证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/)。 +请参阅[证书签名请求](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/)。 ### CertificateSigning {#certificatesigning} @@ -244,7 +241,7 @@ See [Certificate Signing Requests](/docs/reference/access-authn-authz/certificat information on the permissions required to perform different actions on CertificateSigningRequest resources. --> 有关对 CertificateSigningRequest 资源执行不同操作所需权限的详细信息， -请参阅[证书签名请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/)。 +请参阅[证书签名请求](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/)。 ### CertificateSubjectRestriction {#certificatesubjectrestriction} @@ -286,7 +283,7 @@ See the [ingress](/docs/concepts/services-networking/ingress/) documentation for classes and how to mark one as default. --> 关于 Ingress 类以及如何将 Ingress 类标记为默认的更多信息，请参见 -[Ingress](/zh/docs/concepts/services-networking/ingress/) 页面。 +[Ingress](/zh-cn/docs/concepts/services-networking/ingress/) 页面。 ### DefaultStorageClass {#defaultstorageclass} @@ -315,7 +312,7 @@ This admission controller ignores any `PersistentVolumeClaim` updates; it acts o See [persistent volume](/docs/concepts/storage/persistent-volumes/) documentation about persistent volume claims and storage classes and how to mark a storage class as default. --> -关于持久卷申领和存储类，以及如何将存储类标记为默认，请参见[持久卷](/zh/docs/concepts/storage/persistent-volumes/)页面。 +关于持久卷申领和存储类，以及如何将存储类标记为默认，请参见[持久卷](/zh-cn/docs/concepts/storage/persistent-volumes/)页面。 ### DefaultTolerationSeconds {#defaulttolerationseconds} @@ -477,7 +474,7 @@ See the [EventRateLimit Config API (v1alpha1)](/docs/reference/config-api/apiser for more details. --> 详情请参见 -[EventRateLimit 配置 API 文档（v1alpha1）](/zh/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/)。 +[EventRateLimit 配置 API 文档（v1alpha1）](/zh-cn/docs/reference/config-api/apiserver-eventratelimit.v1alpha1/)。 ### ExtendedResourceToleration {#extendedresourcetoleration} @@ -491,7 +488,7 @@ add these tolerations. --> 此插件有助于创建带有扩展资源的专用节点。 如果运维人员想要创建带有扩展资源（如 GPU、FPGA 等）的专用节点，他们应该以扩展资源名称作为键名， -[为节点设置污点](/zh/docs/concepts/scheduling-eviction/taint-and-toleration/)。 +[为节点设置污点](/zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/)。 如果启用了此准入控制器，会将此类污点的容忍度自动添加到请求扩展资源的 Pod 中， 用户不必再手动添加这些容忍度。 @@ -504,13 +501,12 @@ ImagePolicyWebhook 准入控制器允许使用后端 Webhook 做出准入决策 -#### 配置文件格式 {#configuration-file-format} - +#### 配置文件格式 {#configuration-file-format} + ImagePolicyWebhook 使用配置文件来为后端行为设置选项。该文件可以是 JSON 或 YAML， 并具有以下格式: @@ -568,7 +564,7 @@ formatted file which sets up the connection to the backend. It is required that the backend communicate over TLS. --> ImagePolicyWebhook 的配置文件必须引用 -[kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +[kubeconfig](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 格式的文件；该文件用来设置与后端的连接。要求后端使用 TLS 进行通信。 关于 HTTP 配置的更多信息，请参阅 -[kubeconfig](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +[kubeconfig](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 文档。 -#### 请求载荷 - +#### 请求载荷 {#request-payloads} + 当面对一个准入决策时，API 服务器发送一个描述操作的 JSON 序列化的 `imagepolicy.k8s.io/v1alpha1` `ImageReview` 对象。 该对象包含描述被准入容器的字段，以及与 `*.image-policy.k8s.io/*` 匹配的所有 Pod 注解。 @@ -714,33 +709,31 @@ To disallow access, the service would return: For further documentation refer to the [`imagepolicy.v1alpha1` API](/docs/reference/config-api/imagepolicy.v1alpha1/). --> -更多的文档，请参阅 [`imagepolicy.v1alpha1` API](/zh/docs/reference/config-api/imagepolicy.v1alpha1/)。 +更多的文档，请参阅 [`imagepolicy.v1alpha1` API](/zh-cn/docs/reference/config-api/imagepolicy.v1alpha1/)。 -#### 使用注解进行扩展 {#extending-with-annotations} - +#### 使用注解进行扩展 {#extending-with-annotations} + 一个 Pod 中匹配 `*.image-policy.k8s.io/*` 的注解都会被发送给 Webhook。 这样做使得了解后端镜像策略的用户可以向它发送额外的信息， 并让不同的后端实现接收不同的信息。 -你可以在这里输入的信息有： - +你可以在这里输入的信息有： + * 在紧急情况下，请求破例覆盖某个策略。 * 从一个记录了破例的请求的工单（Ticket）系统得到的一个工单号码。 * 向策略服务器提供提示信息，用于提供镜像的 imageID，以方便它进行查找。 @@ -780,8 +773,8 @@ and the [example of LimitRange](/docs/tasks/administer-cluster/manage-resources/ for more details. --> 请查看 -[limitRange API 文档](/zh/docs/reference/kubernetes-api/policy-resources/limit-range-v1/)和 -[LimitRange 例子](/zh/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)以了解更多细节。 +[limitRange API 文档](/zh-cn/docs/reference/kubernetes-api/policy-resources/limit-range-v1/)和 +[LimitRange 例子](/zh-cn/docs/tasks/administer-cluster/manage-resources/memory-default-namespace/)以了解更多细节。 ### MutatingAdmissionWebhook {#mutatingadmissionwebhook} @@ -993,7 +986,7 @@ allowVolumeExpansion: true For more information about persistent volume claims, see [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims). --> 关于持久化卷申领的更多信息，请参见 -[PersistentVolumeClaim](/zh/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。 +[PersistentVolumeClaim](/zh-cn/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims)。 ### PersistentVolumeLabel {#persistentvolumelabel} @@ -1037,7 +1030,8 @@ This file may be json or yaml and has the following format: --> #### 配置文件格式 {#configuration-file-format-podnodeselector} -`PodNodeSelector` 使用配置文件来设置后端行为的选项。请注意，配置文件格式将在将来某个版本中改为版本化文件。 +`PodNodeSelector` 使用配置文件来设置后端行为的选项。 +请注意，配置文件格式将在将来某个版本中改为版本化文件。 该文件可以是 JSON 或 YAML，格式如下： ```yaml @@ -1134,10 +1128,10 @@ for more information. --> 这是下节所讨论的已被废弃的 [PodSecurityPolicy](#podsecuritypolicy) 准入控制器的替代品。 此准入控制器负责在创建和修改 Pod 时，根据请求的安全上下文和 -[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/) +[Pod 安全标准](/zh-cn/docs/concepts/security/pod-security-standards/) 来确定是否可以执行请求。 -更多信息请参阅 [Pod 安全性准入控制器](/zh/docs/concepts/security/pod-security-admission/)。 +更多信息请参阅 [Pod 安全性准入控制器](/zh-cn/docs/concepts/security/pod-security-admission/)。 ### PodSecurityPolicy {#podsecuritypolicy} @@ -1154,8 +1148,7 @@ based on the requested security context and the available Pod Security Policies. See also the [PodSecurityPolicy](/docs/concepts/security/pod-security-policy/) documentation for more information. --> -查看 [Pod 安全策略文档](/zh/docs/concepts/security/pod-security-policy/) -进一步了解其间细节。 +查看 [Pod 安全策略文档](/zh-cn/docs/concepts/security/pod-security-policy/)进一步了解其间细节。 ### PodTolerationRestriction {#podtolerationrestriction} @@ -1234,15 +1227,14 @@ See the [ResourceQuota API reference](/docs/reference/kubernetes-api/policy-reso and the [example of Resource Quota](/docs/concepts/policy/resource-quotas/) for more details. --> 请参阅 -[resourceQuota API 参考](/zh/docs/reference/kubernetes-api/policy-resources/resource-quota-v1/) -和 [Resource Quota 例子](/zh/docs/concepts/policy/resource-quotas/)了解更多细节。 +[resourceQuota API 参考](/zh-cn/docs/reference/kubernetes-api/policy-resources/resource-quota-v1/) +和 [Resource Quota 例子](/zh-cn/docs/concepts/policy/resource-quotas/)了解更多细节。 - - -### RuntimeClass {#runtimeclass} - -{{< feature-state for_k8s_version="v1.20" state="stable" >}} - -如果你所定义的 RuntimeClass 包含 [Pod 开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/)， -这个准入控制器会检查新的 Pod。被启用后，此准入控制器会拒绝所有已经设置了 overhead 字段的 Pod 创建请求。 +如果你所定义的 RuntimeClass 包含 [Pod 开销](/zh-cn/docs/concepts/scheduling-eviction/pod-overhead/)， +这个准入控制器会检查新的 Pod。 +被启用后，此准入控制器会拒绝所有已经设置了 overhead 字段的 Pod 创建请求。 对于配置了 RuntimeClass 并在其 `.spec` 中选定 RuntimeClass 的 Pod， 此准入控制器会根据相应 RuntimeClass 中定义的值为 Pod 设置 `.spec.overhead`。 -详情请参见 [Pod 开销](/zh/docs/concepts/scheduling-eviction/pod-overhead/)。 +详情请参见 [Pod 开销](/zh-cn/docs/concepts/scheduling-eviction/pod-overhead/)。 ### SecurityContextDeny {#securitycontextdeny} @@ -1276,20 +1265,21 @@ task. If you don't use [Pod Security admission](/docs/concepts/security/pod-security-admission/), [PodSecurityPolicies](/docs/concepts/security/pod-security-policy/), nor any external enforcement mechanism, then you could use this admission controller to restrict the set of values a security context can take. +--> +此准入控制器将拒绝任何试图设置特定提升 +[SecurityContext](/zh-cn/docs/tasks/configure-pod-container/security-context/) +中某些字段的 Pod，正如任务[为 Pod 或 Container 配置安全上下文](/zh-cn/docs/tasks/configure-pod-container/security-context/) +中所展示的那样。如果集群没有使用 +[Pod 安全性准入](/zh-cn/docs/concepts/security/pod-security-admission/)、 +[PodSecurityPolicy](/zh-cn/docs/concepts/security/pod-security-policy/)， +也没有任何外部强制机制，那么你可以使用此准入控制器来限制安全上下文所能获取的值集。 + -此准入控制器将拒绝任何试图设置特定提升 -[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/)、 -[PodSecurityPolicy](/zh/docs/concepts/security/pod-security-policy/)， -也没有任何外部强制机制，那么你可以使用此准入控制器来限制安全上下文所能获取的值集。 - 有关限制 Pod 权限的更多内容，请参阅 -[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/)。 +[Pod 安全标准](/zh-cn/docs/concepts/security/pod-security-standards/)。 ### ServiceAccount {#serviceaccount} @@ -1300,7 +1290,7 @@ We strongly recommend using this admission controller if you intend to make use `ServiceAccount` objects. --> 此准入控制器实现了 -[ServiceAccount](/zh/docs/tasks/configure-pod-container/configure-service-account/) +[ServiceAccount](/zh-cn/docs/tasks/configure-pod-container/configure-service-account/) 的自动化。 如果你打算使用 Kubernetes 的 ServiceAccount 对象，我们强烈建议你使用这个准入控制器。 @@ -1317,9 +1307,9 @@ for more detailed information. --> `StorageObjectInUseProtection` 插件将 `kubernetes.io/pvc-protection` 或 `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)。 +或持久卷（PV）中。如果用户尝试删除 PVC/PV，除非 PVC/PV 的保护控制器移除终结器（finalizers）， +否则 PVC/PV 不会被删除。有关更多详细信息， +请参考[保护使用中的存储对象](/zh-cn/docs/concepts/storage/persistent-volumes/#storage-object-in-use-protection)。 ### TaintNodesByCondition {#taintnodesbycondition} @@ -1353,7 +1343,7 @@ 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 other validating admission controllers will permit the request to finish. --> -如果以此方式调用的 Webhook 有其它副作用（如：减少配额），则它必须具有协调机制。 +如果以此方式调用的 Webhook 有其它副作用（如：减少配额），则它 **必须** 具有协调机制。 这是因为无法保证后续的 Webhook 或其他验证性准入控制器都允许请求完成。 -尽管无法通过 API 调用来添加普通用户，Kubernetes 仍然认为能够提供由集群的证书 -机构签名的合法证书的用户是通过身份认证的用户。基于这样的配置，Kubernetes -使用证书中的 'subject' 的通用名称（Common Name）字段（例如，"/CN=bob"）来 -确定用户名。接下来，基于角色访问控制（RBAC）子系统会确定用户是否有权针对 -某资源执行特定的操作。进一步的细节可参阅 -[证书请求](/zh/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user) +尽管无法通过 API 调用来添加普通用户， +Kubernetes 仍然认为能够提供由集群的证书机构签名的合法证书的用户是通过身份认证的用户。 +基于这样的配置，Kubernetes 使用证书中的 'subject' 的通用名称（Common Name）字段 +（例如，"/CN=bob"）来确定用户名。 +接下来，基于角色访问控制（RBAC）子系统会确定用户是否有权针对某资源执行特定的操作。 +进一步的细节可参阅 +[证书请求](/zh-cn/docs/reference/access-authn-authz/certificate-signing-requests/#normal-user) 下普通用户主题。 与此不同，服务账号是 Kubernetes API 所管理的用户。它们被绑定到特定的名字空间， -或者由 API 服务器自动创建，或者通过 API 调用创建。服务账号与一组以 Secret 保存 -的凭据相关，这些凭据会被挂载到 Pod 中，从而允许集群内的进程访问 Kubernetes -API。 +或者由 API 服务器自动创建，或者通过 API 调用创建。服务账号与一组以 Secret +保存的凭据相关，这些凭据会被挂载到 Pod 中，从而允许集群内的进程访问 Kubernetes API。 -API 请求则或者与某普通用户相关联，或者与某服务账号相关联，亦或者被视作 -[匿名请求](#anonymous-requests)。这意味着集群内外的每个进程在向 API 服务器发起 -请求时都必须通过身份认证，否则会被视作匿名用户。这里的进程可以是在某工作站上 -输入 `kubectl` 命令的操作人员，也可以是节点上的 `kubelet` 组件，还可以是控制面 -的成员。 +API 请求则或者与某普通用户相关联，或者与某服务账号相关联， +亦或者被视作[匿名请求](#anonymous-requests)。这意味着集群内外的每个进程在向 API +服务器发起请求时都必须通过身份认证，否则会被视作匿名用户。这里的进程可以是在某工作站上输入 +`kubectl` 命令的操作人员，也可以是节点上的 `kubelet` 组件，还可以是控制面的成员。 -所有（属性）值对于身份认证系统而言都是不透明的，只有被 -[鉴权组件](/zh/docs/reference/access-authn-authz/authorization/) -解释过之后才有意义。 +所有（属性）值对于身份认证系统而言都是不透明的， +只有被[鉴权组件](/zh-cn/docs/reference/access-authn-authz/authorization/)解释过之后才有意义。 你可以同时启用多种身份认证方法，并且你通常会至少使用两种方法： @@ -148,14 +146,14 @@ Integrations with other authentication protocols (LDAP, SAML, Kerberos, alternat can be accomplished using an [authenticating proxy](#authenticating-proxy) or the [authentication webhook](#webhook-token-authentication). --> -当集群中启用了多个身份认证模块时，第一个成功地对请求完成身份认证的模块会 -直接做出评估决定。API 服务器并不保证身份认证模块的运行顺序。 +当集群中启用了多个身份认证模块时，第一个成功地对请求完成身份认证的模块会直接做出评估决定。 +API 服务器并不保证身份认证模块的运行顺序。 对于所有通过身份认证的用户，`system:authenticated` 组都会被添加到其组列表中。 -与其它身份认证协议（LDAP、SAML、Kerberos、X509 的替代模式等等）都可以通过 -使用一个[身份认证代理](#authenticating-proxy)或 -[身份认证 Webhoook](#webhook-token-authentication)来实现。 +与其它身份认证协议（LDAP、SAML、Kerberos、X509 的替代模式等等） +都可以通过使用一个[身份认证代理](#authenticating-proxy)或[身份认证 Webhoook](#webhook-token-authentication) +来实现。 ### 静态令牌文件 {#static-token-file} -当 API 服务器的命令行设置了 `--token-auth-file=SOMEFILE` 选项时，会从文件中 -读取持有者令牌。目前，令牌会长期有效，并且在不重启 API 服务器的情况下 -无法更改令牌列表。 +当 API 服务器的命令行设置了 `--token-auth-file=SOMEFILE` 选项时，会从文件中读取持有者令牌。 +目前，令牌会长期有效，并且在不重启 API 服务器的情况下无法更改令牌列表。 令牌文件是一个 CSV 文件，包含至少 3 个列：令牌、用户名和用户的 UID。 其余列被视为可选的组名。 +{{< note >}} -{{< note >}} 如果要设置的组名不止一个，则对应的列必须用双引号括起来，例如 ```conf @@ -241,12 +234,10 @@ header as shown below. --> #### 在请求中放入持有者令牌 {#putting-a-bearer-token-in-a-request} -当使用持有者令牌来对某 HTTP 客户端执行身份认证时，API 服务器希望看到 -一个名为 `Authorization` 的 HTTP 头，其值格式为 `Bearer `。 -持有者令牌必须是一个可以放入 HTTP 头部值字段的字符序列，至多可使用 -HTTP 的编码和引用机制。 -例如：如果持有者令牌为 `31ada4fd-adec-460c-809a-9e56ceb75269`，则其 -出现在 HTTP 头部时如下所示： +当使用持有者令牌来对某 HTTP 客户端执行身份认证时，API 服务器希望看到一个名为 +`Authorization` 的 HTTP 头，其值格式为 `Bearer `。 +持有者令牌必须是一个可以放入 HTTP 头部值字段的字符序列，至多可使用 HTTP 的编码和引用机制。 +例如：如果持有者令牌为 `31ada4fd-adec-460c-809a-9e56ceb75269`，则其出现在 HTTP 头部时如下所示： ```http Authorization: Bearer 31ada4fd-adec-460c-809a-9e56ceb75269 @@ -267,7 +258,7 @@ dynamically managed and created. Controller Manager contains a TokenCleaner controller that deletes bootstrap tokens as they expire. --> 为了支持平滑地启动引导新的集群，Kubernetes 包含了一种动态管理的持有者令牌类型， -称作 *启动引导令牌（Bootstrap Token）*。 +称作 **启动引导令牌（Bootstrap Token）**。 这些令牌以 Secret 的形式保存在 `kube-system` 名字空间中，可以被动态管理和创建。 控制器管理器包含的 `TokenCleaner` 控制器能够在启动引导令牌过期时将其删除。 @@ -276,8 +267,8 @@ The tokens are of the form `[a-z0-9]{6}.[a-z0-9]{16}`. The first component is a Token ID and the second component is the Token Secret. You specify the token in an HTTP header as follows: --> -这些令牌的格式为 `[a-z0-9]{6}.[a-z0-9]{16}`。第一个部分是令牌的 ID；第二个部分 -是令牌的 Secret。你可以用如下所示的方式来在 HTTP 头部设置令牌： +这些令牌的格式为 `[a-z0-9]{6}.[a-z0-9]{16}`。第一个部分是令牌的 ID； +第二个部分是令牌的 Secret。你可以用如下所示的方式来在 HTTP 头部设置令牌： ```http Authorization: Bearer 781292.db7bc3a58fc5f07e @@ -290,8 +281,7 @@ the TokenCleaner controller via the `-controllers` flag on the Controller Manager. This is done with something like `-controllers=*,tokencleaner`. `kubeadm` will do this for you if you are using it to bootstrap a cluster. --> -你必须在 API 服务器上设置 `--enable-bootstrap-token-auth` 标志来启用基于启动 -引导令牌的身份认证组件。 +你必须在 API 服务器上设置 `--enable-bootstrap-token-auth` 标志来启用基于启动引导令牌的身份认证组件。 你必须通过控制器管理器的 `--controllers` 标志来启用 TokenCleaner 控制器； 这可以通过类似 `--controllers=*,tokencleaner` 这种设置来做到。 如果你使用 `kubeadm` 来启动引导新的集群，该工具会帮你完成这些设置。 @@ -306,17 +296,16 @@ cluster. --> 身份认证组件的认证结果为 `system:bootstrap:<令牌 ID>`，该用户属于 `system:bootstrappers` 用户组。 -这里的用户名和组设置都是有意设计成这样，其目的是阻止用户在启动引导集群之后 -继续使用这些令牌。 -这里的用户名和组名可以用来（并且已经被 `kubeadm` 用来）构造合适的鉴权 -策略，以完成启动引导新集群的工作。 +这里的用户名和组设置都是有意设计成这样，其目的是阻止用户在启动引导集群之后继续使用这些令牌。 +这里的用户名和组名可以用来（并且已经被 `kubeadm` 用来）构造合适的鉴权策略， +以完成启动引导新集群的工作。 -请参阅[启动引导令牌](/zh/docs/reference/access-authn-authz/bootstrap-tokens/) +请参阅[启动引导令牌](/zh-cn/docs/reference/access-authn-authz/bootstrap-tokens/) 以了解关于启动引导令牌身份认证组件与控制器的更深入的信息，以及如何使用 `kubeadm` 来管理这些令牌。 @@ -332,8 +321,8 @@ If unspecified, the API server's TLS private key will be used. --> ### 服务账号令牌 {#service-account-tokens} -服务账号（Service Account）是一种自动被启用的用户认证机制，使用经过签名的 -持有者令牌来验证请求。该插件可接受两个可选参数： +服务账号（Service Account）是一种自动被启用的用户认证机制，使用经过签名的持有者令牌来验证请求。 +该插件可接受两个可选参数： * `--service-account-key-file` 一个包含用来为持有者令牌签名的 PEM 编码密钥。 若未指定，则使用 API 服务器的 TLS 私钥。 @@ -348,15 +337,15 @@ talk to the API server. Accounts may be explicitly associated with pods using th `serviceAccountName` field of a `PodSpec`. --> 服务账号通常由 API 服务器自动创建并通过 `ServiceAccount` -[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/) +[准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/) 关联到集群中运行的 Pod 上。 持有者令牌会挂载到 Pod 中可预知的位置，允许集群内进程与 API 服务器通信。 服务账号也可以使用 Pod 规约的 `serviceAccountName` 字段显式地关联到 Pod 上。 +{{< note >}} -{{< note >}} `serviceAccountName` 通常会被忽略，因为关联关系是自动建立的。 {{< /note >}} @@ -385,10 +374,10 @@ Kubernetes API. To manually create a service account, use the `kubectl create serviceaccount (NAME)` command. This creates a service account in the current namespace and an associated secret. --> -在集群外部使用服务账号持有者令牌也是完全合法的，且可用来为长时间运行的、需要与 -Kubernetes API 服务器通信的任务创建标识。要手动创建服务账号，可以使用 -`kubectl create serviceaccount <名称>` 命令。此命令会在当前的名字空间中生成一个 -服务账号和一个与之关联的 Secret。 +在集群外部使用服务账号持有者令牌也是完全合法的，且可用来为长时间运行的、需要与 Kubernetes +API 服务器通信的任务创建标识。要手动创建服务账号，可以使用 +`kubectl create serviceaccount <名称>` 命令。 +此命令会在当前的名字空间中生成一个服务账号和一个与之关联的 Secret。 ```bash kubectl create serviceaccount jenkins @@ -420,8 +409,7 @@ secrets: The created secret holds the public CA of the API server and a signed JSON Web Token (JWT). --> -所创建的 Secret 中会保存 API 服务器的公开的 CA 证书和一个已签名的 JSON Web -令牌（JWT）。 +所创建的 Secret 中会保存 API 服务器的公开的 CA 证书和一个已签名的 JSON Web 令牌（JWT）。 ```bash kubectl get secret jenkins-token-1yvwg -o yaml @@ -452,10 +440,10 @@ metadata: type: kubernetes.io/service-account-token ``` +{{< note >}} -{{< note >}} 字段值是按 Base64 编码的，这是因为 Secret 数据总是采用 Base64 编码来存储。 {{< /note >}} @@ -481,8 +469,8 @@ when granting permissions to service accounts and read capabilities for secrets. 服务账号被身份认证后，所确定的用户名为 `system:serviceaccount:<名字空间>:<服务账号>`， 并被分配到用户组 `system:serviceaccounts` 和 `system:serviceaccounts:<名字空间>`。 -警告：由于服务账号令牌保存在 Secret 对象中，任何能够读取这些 Secret 的用户 -都可以被认证为对应的服务账号。在为用户授予访问服务账号的权限时，以及对 Secret +警告：由于服务账号令牌保存在 Secret 对象中，任何能够读取这些 Secret +的用户都可以被认证为对应的服务账号。在为用户授予访问服务账号的权限时，以及对 Secret 的读权限时，要格外小心。 要识别用户，身份认证组件使用 OAuth2 -[令牌响应](https://openid.net/specs/openid-connect-core-1_0.html#TokenResponse) -中的 `id_token`（而非 `access_token`）作为持有者令牌。 +[令牌响应](https://openid.net/specs/openid-connect-core-1_0.html#TokenResponse)中的 +`id_token`（而非 `access_token`）作为持有者令牌。 关于如何在请求中设置令牌，可参见[前文](#putting-a-bearer-token-in-a-request)。 {{< mermaid >}} @@ -626,9 +614,8 @@ wish to utilize multiple OAuth clients should explore providers which support th `azp` (authorized party) claim, a mechanism for allowing one client to issue tokens on behalf of another. --> -很重要的一点是，API 服务器并非一个 OAuth2 客户端，相反，它只能被配置为 -信任某一个令牌发放者。这使得使用公共服务（如 Google）的用户可以不信任发放给 -第三方的凭据。 +很重要的一点是，API 服务器并非一个 OAuth2 客户端，相反，它只能被配置为信任某一个令牌发放者。 +这使得使用公共服务（如 Google）的用户可以不信任发放给第三方的凭据。 如果管理员希望使用多个 OAuth 客户端，他们应该研究一下那些支持 `azp` （Authorized Party，被授权方）申领的服务。 `azp` 是一种允许某客户端代替另一客户端发放令牌的机制。 @@ -643,8 +630,8 @@ CloudFoundry [UAA](https://github.com/cloudfoundry/uaa), or Tremolo Security's [OpenUnison](https://openunison.github.io/). --> Kubernetes 并未提供 OpenID Connect 的身份服务。 -你可以使用现有的公共的 OpenID Connect 身份服务（例如 Google 或者 -[其他服务](https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)）。 +你可以使用现有的公共的 OpenID Connect 身份服务 +（例如 Google 或者[其他服务](https://connect2id.com/products/nimbus-oauth-openid-connect-sdk/openid-connect-providers)）。 或者，你也可以选择自己运行一个身份服务，例如 CoreOS [dex](https://github.com/coreos/dex)、 [Keycloak](https://github.com/keycloak/keycloak)、 @@ -672,12 +659,10 @@ Or you can use [this similar script](https://raw.githubusercontent.com/TremoloSe 关于上述第三条需求，即要求具备 CA 签名的证书，有一些额外的注意事项。 如果你部署了自己的身份服务，而不是使用云厂商（如 Google 或 Microsoft）所提供的服务， 你必须对身份服务的 Web 服务器证书进行签名，签名所用证书的 `CA` 标志要设置为 -`TRUE`，即使用的是自签名证书。这是因为 GoLang 的 TLS 客户端实现对证书验证 -标准方面有非常严格的要求。如果你手头没有现成的 CA 证书，可以使用 CoreOS +`TRUE`，即使用的是自签名证书。这是因为 GoLang 的 TLS 客户端实现对证书验证标准方面有非常严格的要求。如果你手头没有现成的 CA 证书，可以使用 CoreOS 团队所开发的[这个脚本](https://github.com/dexidp/dex/blob/master/examples/k8s/gencert.sh) 来创建一个简单的 CA 和被签了名的证书与密钥对。 -或者你也可以使用 -[这个类似的脚本](https://raw.githubusercontent.com/TremoloSecurity/openunison-qs-kubernetes/master/src/main/bash/makessl.sh)， +或者你也可以使用[这个类似的脚本](https://raw.githubusercontent.com/TremoloSecurity/openunison-qs-kubernetes/master/src/main/bash/makessl.sh)， 生成一个合法期更长、密钥尺寸更大的 SHA256 证书。 #### 使用 kubectl {#using-kubectl} -##### 选项一 - OIDC 身份认证组件 +##### 选项一：OIDC 身份认证组件 -第一种方案是使用 kubectl 的 `oidc` 身份认证组件，该组件将 `id_token` 设置 -为所有请求的持有者令牌，并且在令牌过期时自动刷新。在你登录到你的身份服务之后， +第一种方案是使用 kubectl 的 `oidc` 身份认证组件，该组件将 `id_token` 设置为所有请求的持有者令牌， +并且在令牌过期时自动刷新。在你登录到你的身份服务之后， 可以使用 kubectl 来添加你的 `id_token`、`refresh_token`、`client_id` 和 `client_secret`，以配置该插件。 @@ -769,7 +754,7 @@ Once your `id_token` expires, `kubectl` will attempt to refresh your `id_token` The `kubectl` command lets you pass in a token using the `--token` option. Copy and paste the `id_token` into this option: --> -##### 选项二 - 使用 `--token` 选项 +##### 选项二：使用 `--token` 选项 `kubectl` 命令允许你使用 `--token` 选项传递一个令牌。 你可以将 `id_token` 的内容复制粘贴过来，作为此标志的取值： @@ -790,8 +775,8 @@ Webhook authentication is a hook for verifying bearer tokens. Webhook 身份认证是一种用来验证持有者令牌的回调机制。 -* `--authentication-token-webhook-config-file` 指向一个配置文件，其中描述 - 如何访问远程的 Webhook 服务。 +* `--authentication-token-webhook-config-file` 指向一个配置文件， + 其中描述如何访问远程的 Webhook 服务。 * `--authentication-token-webhook-cache-ttl` 用来设定身份认证决定的缓存时间。 默认时长为 2 分钟。 @@ -800,7 +785,7 @@ The configuration file uses the [kubeconfig](/docs/concepts/configuration/organi file format. Within the file, `clusters` refers to the remote service and `users` refers to the API server webhook. An example would be: --> -配置文件使用 [kubeconfig](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +配置文件使用 [kubeconfig](/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 文件的格式。文件中，`clusters` 指代远程服务，`users` 指代远程 API 服务 Webhook。下面是一个例子： @@ -865,11 +850,10 @@ contexts: When a client attempts to authenticate with the API server using a bearer token as discussed [above](#putting-a-bearer-token-in-a-request), the authentication webhook POSTs a JSON-serialized `TokenReview` object containing the token to the remote service. --> -当客户端尝试在 API 服务器上使用持有者令牌完成身份认证（ -如[前](#putting-a-bearer-token-in-a-request)所述）时， +当客户端尝试在 API 服务器上使用持有者令牌完成身份认证 +（如[前](#putting-a-bearer-token-in-a-request)所述）时， 身份认证 Webhook 会用 POST 请求发送一个 JSON 序列化的对象到远程服务。 -该对象是 `TokenReview` 对象， -其中包含持有者令牌。 +该对象是 `TokenReview` 对象，其中包含持有者令牌。 Kubernetes 不会强制请求提供此 HTTP 头部。 -要注意的是，Webhook API 对象和其他 Kubernetes API 对象一样，也要受到同一 -[版本兼容规则](/zh/docs/concepts/overview/kubernetes-api/)约束。 +要注意的是，Webhook API 对象和其他 Kubernetes API 对象一样， +也要受到同一[版本兼容规则](/zh-cn/docs/concepts/overview/kubernetes-api/)约束。 实现者应检查请求的 `apiVersion` 字段以确保正确的反序列化， -并且**必须**以与请求相同版本的 `TokenReview` 对象进行响应。 +并且 **必须** 以与请求相同版本的 `TokenReview` 对象进行响应。 {{< tabs name="TokenReview_request" >}} @@ -891,7 +875,8 @@ The Kubernetes API server defaults to sending `authentication.k8s.io/v1beta1` to To opt into receiving `authentication.k8s.io/v1` token reviews, the API server must be started with `--authentication-token-webhook-version=v1`. --> Kubernetes API 服务器默认发送 `authentication.k8s.io/v1beta1` 令牌以实现向后兼容性。 -要选择接收 `authentication.k8s.io/v1` 令牌认证，API 服务器必须以 `--authentication-token-webhook-version=v1` 启动。 +要选择接收 `authentication.k8s.io/v1` 令牌认证，API 服务器必须带着参数 +`--authentication-token-webhook-version=v1` 启动。 {{< /note >}} ```yaml @@ -944,7 +929,7 @@ A successful validation of the bearer token would return: 远程服务预计会填写请求的 `status` 字段以指示登录成功。 响应正文的 `spec` 字段被忽略并且可以省略。 远程服务必须使用它收到的相同 `TokenReview` API 版本返回响应。 -承载令牌的成功验证将返回： +持有者令牌的成功验证将返回： {{< tabs name="TokenReview_response_success" >}} {{% tab name="authentication.k8s.io/v1" %}} @@ -1066,22 +1051,24 @@ API 服务器可以配置成从请求的头部字段值（如 `X-Remote-User`） * `--requestheader-group-headers` 1.6+. Optional, case-insensitive. "X-Remote-Group" is suggested. Header names to check, in order, for the user's groups. All values in all specified headers are used as group names. * `--requestheader-extra-headers-prefix` 1.6+. Optional, case-insensitive. "X-Remote-Extra-" is suggested. Header prefixes to look for to determine extra information about the user (typically used by the configured authorization plugin). Any headers beginning with any of the specified prefixes have the prefix removed. The remainder of the header name is lowercased and [percent-decoded](https://tools.ietf.org/html/rfc3986#section-2.1) and becomes the extra key, and the header value is the extra value. --> -* `--requestheader-username-headers` 必需字段，大小写不敏感。用来设置要获得用户身份所要检查的头部字段名称列表（有序）。第一个包含数值的字段会被用来提取用户名。 +* `--requestheader-username-headers` 必需字段，大小写不敏感。 + 用来设置要获得用户身份所要检查的头部字段名称列表（有序）。 + 第一个包含数值的字段会被用来提取用户名。 * `--requestheader-group-headers` 可选字段，在 Kubernetes 1.6 版本以后支持，大小写不敏感。 建议设置为 "X-Remote-Group"。用来指定一组头部字段名称列表，以供检查用户所属的组名称。 所找到的全部头部字段的取值都会被用作用户组名。 * `--requestheader-extra-headers-prefix` 可选字段，在 Kubernetes 1.6 版本以后支持，大小写不敏感。 - 建议设置为 "X-Remote-Extra-"。用来设置一个头部字段的前缀字符串，API 服务器会基于所给 - 前缀来查找与用户有关的一些额外信息。这些额外信息通常用于所配置的鉴权插件。 - API 服务器会将与所给前缀匹配的头部字段过滤出来，去掉其前缀部分，将剩余部分 - 转换为小写字符串并在必要时执行[百分号解码](https://tools.ietf.org/html/rfc3986#section-2.1) - 后，构造新的附加信息字段键名。原来的头部字段值直接作为附加信息字段的值。 + 建议设置为 "X-Remote-Extra-"。用来设置一个头部字段的前缀字符串， + API 服务器会基于所给前缀来查找与用户有关的一些额外信息。这些额外信息通常用于所配置的鉴权插件。 + API 服务器会将与所给前缀匹配的头部字段过滤出来，去掉其前缀部分，将剩余部分转换为小写字符串， + 并在必要时执行[百分号解码](https://tools.ietf.org/html/rfc3986#section-2.1)后， + 构造新的附加信息字段键名。原来的头部字段值直接作为附加信息字段的值。 +{{< note >}} -{{< note >}} 在 1.13.3 版本之前（包括 1.10.7、1.9.11），附加字段的键名只能包含 [HTTP 头部标签的合法字符](https://tools.ietf.org/html/rfc7230#section-3.2.6)。 {{< /note >}} @@ -1137,17 +1124,16 @@ the risks and the mechanisms to protect the CA's usage. * `--requestheader-allowed-names` Optional. List of Common Name values (CNs). If set, a valid client certificate with a CN in the specified list must be presented before the request headers are checked for user names. If empty, any CN is allowed. --> 为了防范头部信息侦听，在请求中的头部字段被检视之前， -身份认证代理需要向 API 服务器提供一份合法的客户端证书， -供后者使用所给的 CA 来执行验证。 -警告：*不要* 在不同的上下文中复用 CA 证书，除非你清楚这样做的风险是什么以及 -应如何保护 CA 用法的机制。 +身份认证代理需要向 API 服务器提供一份合法的客户端证书，供后者使用所给的 CA 来执行验证。 +警告：**不要** 在不同的上下文中复用 CA 证书，除非你清楚这样做的风险是什么以及应如何保护 +CA 用法的机制。 * `--requestheader-client-ca-file` 必需字段，给出 PEM 编码的证书包。 在检查请求的头部字段以提取用户名信息之前，必须提供一个合法的客户端证书， 且该证书要能够被所给文件中的机构所验证。 * `--requestheader-allowed-names` 可选字段，用来给出一组公共名称（CN）。 - 如果此标志被设置，则在检视请求中的头部以提取用户信息之前，必须提供 - 包含此列表中所给的 CN 名的、合法的客户端证书。 + 如果此标志被设置，则在检视请求中的头部以提取用户信息之前， + 必须提供包含此列表中所给的 CN 名的、合法的客户端证书。 ## 匿名请求 {#anonymous-requests} -启用匿名请求支持之后，如果请求没有被已配置的其他身份认证方法拒绝，则被视作 -匿名请求（Anonymous Requests）。这类请求获得用户名 `system:anonymous` 和 -对应的用户组 `system:unauthenticated`。 +启用匿名请求支持之后，如果请求没有被已配置的其他身份认证方法拒绝， +则被视作匿名请求（Anonymous Requests）。这类请求获得用户名 `system:anonymous` +和对应的用户组 `system:unauthenticated`。 -例如，在一个配置了令牌身份认证且启用了匿名访问的服务器上，如果请求提供了非法的 -持有者令牌，则会返回 `401 Unauthorized` 错误。 -如果请求没有提供持有者令牌，则被视为匿名请求。 +例如，在一个配置了令牌身份认证且启用了匿名访问的服务器上，如果请求提供了非法的持有者令牌， +则会返回 `401 Unauthorized` 错误。如果请求没有提供持有者令牌，则被视为匿名请求。 在 1.5.1-1.5.x 版本中，匿名访问默认情况下是被禁用的，可以通过为 API 服务器设定 `--anonymous-auth=true` 来启用。 @@ -1186,8 +1171,8 @@ that grant access to the `*` user or `*` group do not include anonymous users. --> 在 1.6 及之后版本中，如果所使用的鉴权模式不是 `AlwaysAllow`，则匿名访问默认是被启用的。 从 1.6 版本开始，ABAC 和 RBAC 鉴权模块要求对 `system:anonymous` 用户或者 -`system:unauthenticated` 用户组执行显式的权限判定，所以之前的为 `*` 用户或 -`*` 用户组赋予访问权限的策略规则都不再包含匿名用户。 +`system:unauthenticated` 用户组执行显式的权限判定，所以之前的为用户 `*` 或用户组 +`*` 赋予访问权限的策略规则都不再包含匿名用户。 -带伪装的请求首先会被身份认证识别为发出请求的用户，之后会切换到使用被伪装的用户 -的用户信息。 +带伪装的请求首先会被身份认证识别为发出请求的用户， +之后会切换到使用被伪装的用户的用户信息。 -* 用户发起 API 调用时 _同时_ 提供自身的凭据和伪装头部字段信息 +* 用户发起 API 调用时 **同时** 提供自身的凭据和伪装头部字段信息 * API 服务器对用户执行身份认证 * API 服务器确认通过认证的用户具有伪装特权 * 请求用户的信息被替换成伪装字段的值 @@ -1238,19 +1223,17 @@ The following HTTP headers can be used to performing an impersonation request: 可选字段；要求 "Impersonate-User" 必须被设置。 * `Impersonate-Extra-<附加名称>`：一个动态的头部字段，用来设置与用户相关的附加字段。 此字段可选；要求 "Impersonate-User" 被设置。为了能够以一致的形式保留， - `<附加名称>`部分必须是小写字符，如果有任何字符不是 - [合法的 HTTP 头部标签字符](https://tools.ietf.org/html/rfc7230#section-3.2.6)， + `<附加名称>`部分必须是小写字符， + 如果有任何字符不是[合法的 HTTP 头部标签字符](https://tools.ietf.org/html/rfc7230#section-3.2.6)， 则必须是 utf8 字符，且转换为[百分号编码](https://tools.ietf.org/html/rfc3986#section-2.1)。 * `Impersonate-Uid`：一个唯一标识符，用来表示所伪装的用户。此头部可选。 - 如果设置，则要求 "Impersonate-User" 也存在。 - Kubernetes 对此字符串没有格式要求。 + 如果设置，则要求 "Impersonate-User" 也存在。Kubernetes 对此字符串没有格式要求。 +{{< note >}} -{{< note >}} -在 1.11.3 版本之前（以及 1.10.7、1.9.11），`<附加名称>` 只能包含 -合法的 HTTP 标签字符。 +在 1.11.3 版本之前（以及 1.10.7、1.9.11），`<附加名称>` 只能包含合法的 HTTP 标签字符。 {{< /note >}} {{< note >}} @@ -1379,31 +1362,45 @@ kind: ClusterRole metadata: name: limited-impersonator rules: -# 可以伪装成用户 "jane.doe@example.com" -- apiGroups: [""] - resources: ["users"] - verbs: ["impersonate"] - resourceNames: ["jane.doe@example.com"] - -# 可以伪装成用户组 "developers" 和 "admins" -- apiGroups: [""] - resources: ["groups"] - verbs: ["impersonate"] - resourceNames: ["developers","admins"] - -# 可以将附加字段 "scopes" 伪装成 "view" 和 "development" -- apiGroups: ["authentication.k8s.io"] - resources: ["userextras/scopes"] - verbs: ["impersonate"] - resourceNames: ["view", "development"] - -# 可以伪装 UID "06f6ce97-e2c5-4ab8-7ba5-7654dd08d52b" -- apiGroups: ["authentication.k8s.io"] - resources: ["uids"] - verbs: ["impersonate"] - resourceNames: ["06f6ce97-e2c5-4ab8-7ba5-7654dd08d52b"] + # 可以伪装成用户 "jane.doe@example.com" + - apiGroups: [""] + resources: ["users"] + verbs: ["impersonate"] + resourceNames: ["jane.doe@example.com"] + + # 可以伪装成用户组 "developers" 和 "admins" + - apiGroups: [""] + resources: ["groups"] + verbs: ["impersonate"] + resourceNames: ["developers","admins"] + + # 可以将附加字段 "scopes" 伪装成 "view" 和 "development" + - apiGroups: ["authentication.k8s.io"] + resources: ["userextras/scopes"] + verbs: ["impersonate"] + resourceNames: ["view", "development"] + + # 可以伪装 UID "06f6ce97-e2c5-4ab8-7ba5-7654dd08d52b" + - apiGroups: ["authentication.k8s.io"] + resources: ["uids"] + verbs: ["impersonate"] + resourceNames: ["06f6ce97-e2c5-4ab8-7ba5-7654dd08d52b"] ``` +{{< note >}} + +基于伪装成一个用户或用户组的能力，你可以执行任何操作，好像你就是那个用户或用户组一样。 +出于这一原因，伪装操作是不受名字空间约束的。 +如果你希望允许使用 Kubernetes RBAC 来执行身份伪装，就需要使用 `ClusterRole` +和 `ClusterRoleBinding`，而不是 `Role` 或 `RoleBinding`。 +{{< /note >}} + @@ -1421,11 +1418,11 @@ protocol specific logic, then returns opaque credentials to use. Almost all cred use cases require a server side component with support for the [webhook token authenticator](#webhook-token-authentication) to interpret the credential format produced by the client plugin. --> -`k8s.io/client-go` 及使用它的工具（如 `kubectl` 和 `kubelet`）可以执行某个外部 -命令来获得用户的凭据信息。 +`k8s.io/client-go` 及使用它的工具（如 `kubectl` 和 `kubelet`） +可以执行某个外部命令来获得用户的凭据信息。 -这一特性的目的是便于客户端与 `k8s.io/client-go` 并不支持的身份认证协议（LDAP、 -Kerberos、OAuth2、SAML 等）继承。 +这一特性的目的是便于客户端与 `k8s.io/client-go` 并不支持的身份认证协议 +（LDAP、Kerberos、OAuth2、SAML 等）继承。 插件实现特定于协议的逻辑，之后返回不透明的凭据以供使用。 几乎所有的凭据插件使用场景中都需要在服务器端存在一个支持 [Webhook 令牌身份认证组件](#webhook-token-authentication)的模块， @@ -1441,10 +1438,10 @@ to install a credential plugin on their workstation. --> ### 示例应用场景 {#example-use-case} -在一个假想的应用场景中，某组织运行这一个外部的服务，能够将特定用户的已签名的 -令牌转换成 LDAP 凭据。此服务还能够对 -[Webhook 令牌身份认证组件](#webhook-token-authentication)的请求做出响应以 -验证所提供的令牌。用户需要在自己的工作站上安装一个凭据插件。 +在一个假想的应用场景中，某组织运行这一个外部的服务，能够将特定用户的已签名的令牌转换成 +LDAP 凭据。此服务还能够对 +[Webhook 令牌身份认证组件](#webhook-token-authentication)的请求做出响应以验证所提供的令牌。 +用户需要在自己的工作站上安装一个凭据插件。 ### 配置 {#configuration} -凭据插件通过 [kubectl 配置文件](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +凭据插件通过 [kubectl 配置文件](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 来作为 user 字段的一部分设置。 {{< tabs name="exec_plugin_kubeconfig_example_1" >}} @@ -1562,7 +1559,6 @@ users: command: "example-client-go-exec-plugin" # 解析 ExecCredentials 资源时使用的 API 版本。必需。 - # # 插件返回的 API 版本必需与这里列出的版本匹配。 # # 要与支持多个版本的工具（如 client.authentication.k8s.io/v1beta1）集成， @@ -1706,7 +1702,6 @@ users: command: "example-client-go-exec-plugin" # 解析 ExecCredentials 资源时使用的 API 版本。必需。 - # # 插件返回的 API 版本必需与这里列出的版本匹配。 # # 要与支持多个版本的工具（如 client.authentication.k8s.io/v1）集成， @@ -1823,7 +1818,7 @@ and required in `client.authentication.k8s.io/v1`. 输入对象中的 `spec.interactive` 字段来确定是否提供了 `stdin`。 插件的 `stdin` 需求（即，为了能够让插件成功运行，是否 `stdin` 是可选的、 必须提供的或者从不会被使用的）是通过 -[kubeconfig](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +[kubeconfig](/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 中的 `user.exec.interactiveMode` 来声明的（参见下面的表格了解合法值）。 字段 `user.exec.interactiveMode` 在 `client.authentication.k8s.io/v1beta1` 中是可选的，在 `client.authentication.k8s.io/v1` 中是必需的。 @@ -1848,7 +1843,7 @@ and required in `client.authentication.k8s.io/v1`. To use bearer token credentials, the plugin returns a token in the status of the [`ExecCredential`](/docs/reference/config-api/client-authentication.v1beta1/#client-authentication-k8s-io-v1beta1-ExecCredential) --> -与使用持有者令牌凭据，插件在 [`ExecCredential`](/zh/docs/reference/config-api/client-authentication.v1beta1/#client-authentication-k8s-io-v1beta1-ExecCredential) +与使用持有者令牌凭据，插件在 [`ExecCredential`](/zh-cn/docs/reference/config-api/client-authentication.v1beta1/#client-authentication-k8s-io-v1beta1-ExecCredential) 的状态中返回一个令牌： {{< tabs name="exec_plugin_ExecCredential_example_1" >}} @@ -1933,8 +1928,7 @@ Presence or absence of an expiry has the following impact: - If an expiry is omitted, the bearer token and TLS credentials are cached until the server responds with a 401 HTTP status code or until the process exits. --> -作为一种可选方案，响应中还可以包含以 -[RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339) +作为一种可选方案，响应中还可以包含以 [RFC 3339](https://datatracker.ietf.org/doc/html/rfc3339) 时间戳格式给出的证书到期时间。 证书到期时间的有无会有如下影响： @@ -1979,7 +1973,7 @@ credential acquisition logic. The following `ExecCredential` manifest describes a cluster information sample. --> 为了让 exec 插件能够获得特定与集群的信息，可以在 -[kubeconfig](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +[kubeconfig](/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 中的 `user.exec` 设置 `provideClusterInfo`。 这一特定于集群的信息就会通过 `KUBERNETES_EXEC_INFO` 环境变量传递给插件。 此环境变量中的信息可以用来执行特定于集群的凭据获取逻辑。 @@ -2034,6 +2028,6 @@ The following `ExecCredential` manifest describes a cluster information sample. * Read the [client authentication reference (v1beta1)](/docs/reference/config-api/client-authentication.v1beta1/) * Read the [client authentication reference (v1)](/docs/reference/config-api/client-authentication.v1/) --> -* 阅读[客户端认证参考文档 (v1beta1)](/zh/docs/reference/config-api/client-authentication.v1beta1/) -* 阅读[客户端认证参考文档 (v1)](/zh/docs/reference/config-api/client-authentication.v1/) +* 阅读[客户端认证参考文档 (v1beta1)](/zh-cn/docs/reference/config-api/client-authentication.v1beta1/) +* 阅读[客户端认证参考文档 (v1)](/zh-cn/docs/reference/config-api/client-authentication.v1/) diff --git a/content/zh-cn/docs/reference/access-authn-authz/authorization.md b/content/zh-cn/docs/reference/access-authn-authz/authorization.md index c7d2bae333..fbac09ef60 100644 --- a/content/zh-cn/docs/reference/access-authn-authz/authorization.md +++ b/content/zh-cn/docs/reference/access-authn-authz/authorization.md @@ -35,7 +35,7 @@ cloud-provider-wide access control systems which may handle other APIs besides the Kubernetes API. --> 在 Kubernetes 中，你必须在鉴权（授予访问权限）之前进行身份验证（登录），有关身份验证的信息， -请参阅[访问控制概述](/zh/docs/concepts/security/controlling-access/). +请参阅[访问控制概述](/zh-cn/docs/concepts/security/controlling-access/). Kubernetes 期望请求中存在 REST API 常见的属性。 这意味着 Kubernetes 鉴权适用于现有的组织范围或云提供商范围的访问控制系统， @@ -48,7 +48,15 @@ Kubernetes authorizes API requests using the API server. It evaluates all of the request attributes against all policies and allows or denies the request. All parts of an API request must be allowed by some policy in order to proceed. This means that permissions are denied by default. +--> +## 确定是允许还是拒绝请求 {#determine-whether-a-request-is-allowed-or-denied} +Kubernetes 使用 API 服务器对 API 请求进行鉴权。 +它根据所有策略评估所有请求属性来决定允许或拒绝请求。 +一个 API 请求的所有部分都必须被某些策略允许才能继续。 +这意味着默认情况下拒绝权限。 + + -## 确定是允许还是拒绝请求 - -Kubernetes 使用 API 服务器对 API 请求进行鉴权。 -它根据所有策略评估所有请求属性来决定允许或拒绝请求。 -一个 API 请求的所有部分都必须被某些策略允许才能继续。 -这意味着默认情况下拒绝权限。 - （尽管 Kubernetes 使用 API 服务器，但是依赖于特定对象种类的特定字段的访问控制 和策略由准入控制器处理。） @@ -94,22 +95,21 @@ Kubernetes reviews only the following API request attributes: Kubernetes 仅审查以下 API 请求属性： -* **用户** - 身份验证期间提供的 `user` 字符串。 -* **组** - 经过身份验证的用户所属的组名列表。 -* **额外信息** - 由身份验证层提供的任意字符串键到字符串值的映射。 -* **API** - 指示请求是否针对 API 资源。 -* **请求路径** - 各种非资源端点的路径，如 `/api` 或 `/healthz`。 -* **API 请求动词** - API 动词 `get`、`list`、`create`、`update`、`patch`、`watch`、 +* **用户** —— 身份验证期间提供的 `user` 字符串。 +* **组** —— 经过身份验证的用户所属的组名列表。 +* **额外信息** —— 由身份验证层提供的任意字符串键到字符串值的映射。 +* **API** —— 指示请求是否针对 API 资源。 +* **请求路径** —— 各种非资源端点的路径，如 `/api` 或 `/healthz`。 +* **API 请求动词** —— API 动词 `get`、`list`、`create`、`update`、`patch`、`watch`、 `proxy`、`redirect`、`delete` 和 `deletecollection` 用于资源请求。 - 要确定资源 API 端点的请求动词，请参阅 - [确定请求动词](#determine-the-request-verb)。 -* **HTTP 请求动词** - HTTP 动词 `get`、`post`、`put` 和 `delete` 用于非资源请求。 -* **Resource** - 正在访问的资源的 ID 或名称（仅限资源请求）- + 要确定资源 API 端点的请求动词，请参阅[确定请求动词](#determine-the-request-verb)。 +* **HTTP 请求动词** —— HTTP 动词 `get`、`post`、`put` 和 `delete` 用于非资源请求。 +* **资源** —— 正在访问的资源的 ID 或名称（仅限资源请求）- 对于使用 `get`、`update`、`patch` 和 `delete` 动词的资源请求，你必须提供资源名称。 -* **子资源** - 正在访问的子资源（仅限资源请求）。 -* **名字空间** - 正在访问的对象的名称空间（仅适用于名字空间资源请求）。 -* **API 组** - 正在访问的 {{< glossary_tooltip text="API 组" term_id="api-group" >}} - （仅限资源请求）。空字符串表示[核心 API 组](/zh/docs/reference/using-api/#api-groups)。 +* **子资源** —— 正在访问的子资源（仅限资源请求）。 +* **名字空间** —— 正在访问的对象的名称空间（仅适用于名字空间资源请求）。 +* **API 组** —— 正在访问的 {{< glossary_tooltip text="API 组" term_id="api-group" >}} + （仅限资源请求）。空字符串表示[核心 API 组](/zh-cn/docs/reference/using-api/#api-groups)。 ## 确定请求动词 {#determine-the-request-verb} **非资源请求** -对于 `/api/v1/...` 或 `/apis///...` 之外的端点的请求被 -视为“非资源请求（Non-Resource Requests）”，并使用该请求的 HTTP 方法的 -小写形式作为其请求动词。 +对于 `/api/v1/...` 或 `/apis///...` +之外的端点的请求被视为 “非资源请求（Non-Resource Requests）”， +并使用该请求的 HTTP 方法的小写形式作为其请求动词。 + 例如，对 `/api` 或 `/healthz` 这类端点的 `GET` 请求将使用 `get` 作为其动词。 **资源请求** -要确定对资源 API 端点的请求动词，需要查看所使用的 HTTP 动词以及该请求是针对 -单个资源还是一组资源： +要确定对资源 API 端点的请求动词，需要查看所使用的 HTTP 动词以及该请求是针对单个资源还是一组资源： Kubernetes 有时使用专门的动词以对额外的权限进行鉴权。例如： -* [PodSecurityPolicy](/zh/docs/concepts/security/pod-security-policy/) +* [PodSecurityPolicy](/zh-cn/docs/concepts/security/pod-security-policy/) * `policy` API 组中 `podsecuritypolicies` 资源使用 `use` 动词 -* [RBAC](/zh/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) +* [RBAC](/zh-cn/docs/reference/access-authn-authz/rbac/#privilege-escalation-prevention-and-bootstrapping) * 对 `rbac.authorization.k8s.io` API 组中 `roles` 和 `clusterroles` 资源的 `bind` 和 `escalate` 动词 -* [身份认证](/zh/docs/reference/access-authn-authz/authentication/) +* [身份认证](/zh-cn/docs/reference/access-authn-authz/authentication/) * 对核心 API 组中 `users`、`groups` 和 `serviceaccounts` 以及 `authentication.k8s.io` API 组中的 `userextras` 所使用的 `impersonate` 动词。 ## 鉴权模块 {#authorization-modules} -* **Node** - 一个专用鉴权组件，根据调度到 kubelet 上运行的 Pod 为 kubelet 授予权限。 - 了解有关使用节点鉴权模式的更多信息，请参阅[节点鉴权](/zh/docs/reference/access-authn-authz/node/)。 -* **ABAC** - 基于属性的访问控制（ABAC）定义了一种访问控制范型，通过使用将属性组合 - 在一起的策略，将访问权限授予用户。策略可以使用任何类型的属性（用户属性、资源属性、 - 对象，环境属性等）。要了解有关使用 ABAC 模式的更多信息，请参阅 - [ABAC 模式](/zh/docs/reference/access-authn-authz/abac/)。 -* **RBAC** - 基于角色的访问控制（RBAC）是一种基于企业内个人用户的角色来管理对 - 计算机或网络资源的访问的方法。在此上下文中，权限是单个用户执行特定任务的能力， +* **Node** —— 一个专用鉴权模式，根据调度到 kubelet 上运行的 Pod 为 kubelet 授予权限。 + 要了解有关使用节点鉴权模式的更多信息，请参阅[节点鉴权](/zh-cn/docs/reference/access-authn-authz/node/)。 +* **ABAC** —— 基于属性的访问控制（ABAC）定义了一种访问控制范型，通过使用将属性组合在一起的策略， + 将访问权限授予用户。策略可以使用任何类型的属性（用户属性、资源属性、对象，环境属性等）。 + 要了解有关使用 ABAC 模式的更多信息，请参阅 + [ABAC 模式](/zh-cn/docs/reference/access-authn-authz/abac/)。 +* **RBAC** —— 基于角色的访问控制（RBAC） + 是一种基于企业内个人用户的角色来管理对计算机或网络资源的访问的方法。 + 在此上下文中，权限是单个用户执行特定任务的能力， 例如查看、创建或修改文件。要了解有关使用 RBAC 模式的更多信息，请参阅 - [RBAC 模式](/zh/docs/reference/access-authn-authz/rbac/)。 - * 被启用之后，RBAC（基于角色的访问控制）使用 `rbac.authorization.k8s.io` API 组来 - 驱动鉴权决策，从而允许管理员通过 Kubernetes API 动态配置权限策略。 + [RBAC 模式](/zh-cn/docs/reference/access-authn-authz/rbac/)。 + * 被启用之后，RBAC（基于角色的访问控制）使用 `rbac.authorization.k8s.io` API + 组来驱动鉴权决策，从而允许管理员通过 Kubernetes API 动态配置权限策略。 * 要启用 RBAC，请使用 `--authorization-mode = RBAC` 启动 API 服务器。 -* **Webhook** - WebHook 是一个 HTTP 回调：发生某些事情时调用的 HTTP POST； - 通过 HTTP POST 进行简单的事件通知。实现 WebHook 的 Web 应用程序会在发生某些事情时 - 将消息发布到 URL。要了解有关使用 Webhook 模式的更多信息，请参阅 - [Webhook 模式](/zh/docs/reference/access-authn-authz/webhook/)。 +* **Webhook** —— WebHook 是一个 HTTP 回调：发生某些事情时调用的 HTTP POST； + 通过 HTTP POST 进行简单的事件通知。 + 实现 WebHook 的 Web 应用程序会在发生某些事情时将消息发布到 URL。 + 要了解有关使用 Webhook 模式的更多信息，请参阅 + [Webhook 模式](/zh-cn/docs/reference/access-authn-authz/webhook/)。 + 输出类似于： ``` @@ -236,7 +241,9 @@ yes kubectl auth can-i create deployments --namespace prod ``` - + 输出类似于： ``` @@ -247,15 +254,16 @@ no Administrators can combine this with [user impersonation](/docs/reference/access-authn-authz/authentication/#user-impersonation) to determine what action other users can perform. --> -管理员可以将此与 -[用户扮演](/zh/docs/reference/access-authn-authz/authentication/#user-impersonation) +管理员可以将此与[用户扮演（User Impersonation）](/zh-cn/docs/reference/access-authn-authz/authentication/#user-impersonation) 结合使用，以确定其他用户可以执行的操作。 ```bash kubectl auth can-i list secrets --namespace dev --as dave ``` - + 输出类似于： ``` @@ -266,7 +274,7 @@ no Similarly, to check whether a ServiceAccount named `dev-sa` in Namespace `dev` can list Pods in the Namespace `target`: --> -类似地，检查名字空间 `dev` 里的 `dev-sa` 服务账号是否可以列举名字空间 `target` 里的 Pod： +类似地，检查名字空间 `dev` 里的 `dev-sa` 服务账户是否可以列举名字空间 `target` 里的 Pod： ```bash kubectl auth can-i list pods \ @@ -274,7 +282,9 @@ kubectl auth can-i list pods \ --as system:serviceaccount:dev:dev-sa ``` - + 输出类似于： ``` @@ -297,10 +307,9 @@ field of the returned object is the result of the query. 服务器鉴权公开给外部服务。该组中的其他资源包括： * `SubjectAccessReview` - 对任意用户的访问进行评估，而不仅仅是当前用户。 - 当鉴权决策被委派给 API 服务器时很有用。例如，kubelet 和扩展 API 服务器使用 - 它来确定用户对自己的 API 的访问权限。 -* `LocalSubjectAccessReview` - 与 `SubjectAccessReview` 类似，但仅限于特定的 - 名字空间。 + 当鉴权决策被委派给 API 服务器时很有用。例如，kubelet 和扩展 API + 服务器使用它来确定用户对自己的 API 的访问权限。 +* `LocalSubjectAccessReview` - 与 `SubjectAccessReview` 类似，但仅限于特定的名字空间。 * `SelfSubjectRulesReview` - 返回用户可在名字空间内执行的操作集的审阅。 用户可以快速汇总自己的访问权限，或者用于 UI 中的隐藏/显示动作。 @@ -349,7 +358,7 @@ your policies include: The following flags can be used: --> -## 为你的鉴权模块设置参数 +## 为你的鉴权模块设置参数 {#using-flags-for-your-authorization-module} 你必须在策略中包含一个参数标志，以指明你的策略包含哪个鉴权模块： @@ -363,8 +372,7 @@ The following flags can be used: * `--authorization-mode=AlwaysDeny` This flag blocks all requests. Use this flag only for testing. * `--authorization-mode=AlwaysAllow` This flag allows all requests. Use this flag only if you do not require authorization for your API requests. --> -* `--authorization-mode=ABAC` 基于属性的访问控制（ABAC）模式允许你 - 使用本地文件配置策略。 +* `--authorization-mode=ABAC` 基于属性的访问控制（ABAC）模式允许你使用本地文件配置策略。 * `--authorization-mode=RBAC` 基于角色的访问控制（RBAC）模式允许你使用 Kubernetes API 创建和存储策略。 * `--authorization-mode=Webhook` WebHook 是一种 HTTP 回调模式，允许你使用远程 @@ -372,15 +380,13 @@ The following flags can be used: * `--authorization-mode=Node` 节点鉴权是一种特殊用途的鉴权模式，专门对 kubelet 发出的 API 请求执行鉴权。 * `--authorization-mode=AlwaysDeny` 该标志阻止所有请求。仅将此标志用于测试。 -* `--authorization-mode=AlwaysAllow` 此标志允许所有请求。仅在你不需要 API 请求 - 的鉴权时才使用此标志。 +* `--authorization-mode=AlwaysAllow` 此标志允许所有请求。仅在你不需要 API 请求的鉴权时才使用此标志。 -你可以选择多个鉴权模块。模块按顺序检查，以便较靠前的模块具有更高的优先级来允许 -或拒绝请求。 +你可以选择多个鉴权模块。模块按顺序检查，以便较靠前的模块具有更高的优先级来允许或拒绝请求。 -### 提升途径 {#escalation-paths} +### 特权提升途径 {#escalation-paths} + - 挂载该名字空间内的任意 Secret - 可以用来访问其他工作负载专用的 Secret - 可以用来获取权限更高的服务账号的令牌 @@ -447,9 +454,8 @@ This should be considered when deciding on your RBAC controls. * To learn more about Authentication, see **Authentication** in [Controlling Access to the Kubernetes API](/docs/concepts/security/controlling-access/). * To learn more about Admission Control, see [Using Admission Controllers](/docs/reference/access-authn-authz/admission-controllers/). --> -* 要了解有关身份验证的更多信息，请参阅 - [控制对 Kubernetes API 的访问](/zh/docs/concepts/security/controlling-access/) - 中的 **身份验证** 部分。 -* 要了解有关准入控制的更多信息，请参阅 - [使用准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/)。 +* 要了解有关身份验证的更多信息， + 请参阅[控制对 Kubernetes API 的访问](/zh-cn/docs/concepts/security/controlling-access/)中的 + **身份验证** 部分。 +* 要了解有关准入控制的更多信息，请参阅[使用准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/)。 diff --git a/content/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping.md b/content/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping.md index 5cea5de021..05a3a8d81b 100644 --- a/content/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping.md +++ b/content/zh-cn/docs/reference/access-authn-authz/kubelet-tls-bootstrapping.md @@ -302,7 +302,7 @@ requests related to certificate provisioning. With RBAC in place, scoping the tokens to a group allows for great flexibility. For example, you could disable a particular bootstrap group's access when you are done provisioning the nodes. --> -随着这个功能特性的逐渐成熟，你需要确保令牌绑定到某基于角色的的访问控制（RBAC） +随着这个功能特性的逐渐成熟，你需要确保令牌绑定到某基于角色的访问控制（RBAC） 策略上，从而严格限制请求（使用[启动引导令牌](/zh/docs/reference/access-authn-authz/bootstrap-tokens/)） 仅限于客户端申请提供证书。当 RBAC 被配置启用时，可以将令牌限制到某个组， 从而提高灵活性。例如，你可以在准备节点期间禁止某特定启动引导组的访问。 @@ -338,7 +338,7 @@ for TLS bootstrapping. --> 从 kubelet 的角度，所有令牌看起来都很像，没有特别的含义。 从 kube-apiserver 服务器的角度，启动引导令牌是很特殊的。 -根据其 `type`、`namespace` 和 `name`，kube-apiserver 能够将认作特殊的令牌， +根据其 `type`、`namespace` 和 `name`，kube-apiserver 能够将其认作特殊的令牌， 并授予携带该令牌的任何人特殊的启动引导权限，换言之，将其视为 `system:bootstrappers` 组的成员。这就满足了 TLS 启动引导的基本需求。 @@ -604,7 +604,7 @@ collection. 作为 [kube-controller-manager](/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/) 的一部分的 `csrapproving` 控制器是自动被启用的。 该控制器使用 [`SubjectAccessReview` API](/zh/docs/reference/access-authn-authz/authorization/#checking-api-access) -来确定是否某给定用户被授权请求 CSR，之后基于鉴权结果执行批复操作。 +来确定给定用户是否被授权请求 CSR，之后基于鉴权结果执行批复操作。 为了避免与其它批复组件发生冲突，内置的批复组件不会显式地拒绝任何 CSRs。 该组件仅是忽略未被授权的请求。 控制器也会作为垃圾收集的一部分清除已过期的证书。 @@ -900,4 +900,4 @@ certificate approve ` and `kubectl certificate deny `. 管理员可以通过 `kubectl get csr` 来列举所有的 CSR，使用 `kubectl descsribe csr ` 来描述某个 CSR 的细节。 管理员可以使用 `kubectl certificate approve ` 来拒绝某 CSR。 \ No newline at end of file +`kubectl certificate deny ` 来拒绝某 CSR。 diff --git a/content/zh-cn/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 index 67c7ccd03e..0cd54ac7f0 100644 --- a/content/zh-cn/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 @@ -14,15 +14,16 @@ weight: 95 --> + -下面的表格列举了 [PodSecurityPolicy](/zh/docs/concepts/security/pod-security-policy/) +下面的表格列举了 [PodSecurityPolicy](/zh-cn/docs/concepts/security/pod-security-policy/) 对象上的配置参数，这些字段是否会变更或检查 Pod 配置，以及这些配置值如何映射到 -[Pod 安全性标准（Pod Security Standards）](/zh/docs/concepts/security/pod-security-standards/) +[Pod 安全性标准（Pod Security Standards）](/zh-cn/docs/concepts/security/pod-security-standards/) 之上。 对于每个可应用的参数，表格中给出了 -[Baseline](/zh/docs/concepts/security/pod-security-standards/#baseline) 和 -[Restricted](/zh/docs/concepts/security/pod-security-standards/#restricted) +[Baseline](/zh-cn/docs/concepts/security/pod-security-standards/#baseline) 和 +[Restricted](/zh-cn/docs/concepts/security/pod-security-standards/#restricted) 配置下可接受的取值。 对这两种配置而言不可接受的取值均归入 -[Privileged](/zh/docs/concepts/security/pod-security-standards/#privileged) +[Privileged](/zh-cn/docs/concepts/security/pod-security-standards/#privileged) 配置下。“无意见”意味着对所有 Pod 安全性标准而言所有取值都可接受。 -如果想要了解如何一步步完成迁移，可参阅 -[从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器](/zh/docs/tasks/configure-pod-container/migrate-from-psp/)。 +如果想要了解如何一步步完成迁移，可参阅[从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器](/zh-cn/docs/tasks/configure-pod-container/migrate-from-psp/)。 -## PodSecurityPolicy 规约 {#podsecuritypolicy-spec} - +## PodSecurityPolicy 规约 {#podsecuritypolicy-spec} + 下面表格中所列举的字段是 `PodSecurityPolicySpec` 的一部分，是通过 `.spec` 字段路径来设置的。 @@ -280,15 +279,14 @@ under the `.spec` field path. -## PodSecurityPolicy 注解 {#podsecuritypolicy-annotations} - -下面表格中所列举的[注解](/zh/docs/concepts/overview/working-with-objects/annotations/) -可以通过 `.metadata.annotations` 设置到 PodSecurityPolicy 对象之上。 +## PodSecurityPolicy 注解 {#podsecuritypolicy-annotations} + +下面表格中所列举的[注解](/zh-cn/docs/concepts/overview/working-with-objects/annotations/)可以通过 +`.metadata.annotations` 设置到 PodSecurityPolicy 对象之上。
      Restricted 策略规范Restricted 策略规范
      控制（Control）策略（Policy）控制策略
      基线策略的所有要求。Baseline 策略的所有要求。
      -

      In addition to restricting HostPath volumes, the restricted policy limits usage of non-core volume types to those defined through PersistentVolumes.

      -

      Restricted Fields

      +

      除了限制 HostPath 卷之外，此类策略还限制可以通过 PersistentVolumes 定义的非核心卷类型。

      +

      限制的字段

      • spec.volumes[*]
      -

      Allowed Values

      - Every item in the spec.volumes[*] list must set one of the following fields to a non-null value: -
        -
      • spec.volumes[*].configMap
        • -
      • spec.volumes[*].csi
        • -
      • spec.volumes[*].downwardAPI
        • -
      • spec.volumes[*].emptyDir
        • -
      • spec.volumes[*].ephemeral
        • -
      • spec.volumes[*].persistentVolumeClaim
        • -
      • spec.volumes[*].projected
        • -
      • spec.volumes[*].secret
        • -
      -       		卷类型 -

      除了限制 HostPath 卷之外，此类策略还限制可以通过 PersistentVolumes 定义的非核心卷类型。

      -

      限制的字段

      -
        -
      • spec.volumes[*]
        • -
      -

      允许的值

      - spec.volumes[*] 列表中的每个条目必须将下面字段之一设置为非空值： +

      准许的取值

      + spec.volumes[*] 列表中的每个条目必须将下面字段之一设置为非空值：
      • spec.volumes[*].configMap
      • spec.volumes[*].csi
        • @@ -605,210 +382,107 @@ fail validation.
      -

      Privilege escalation (such as via set-user-ID or set-group-ID file mode) should not be allowed.

      -

      Restricted Fields

      +

      禁止（通过 SetUID 或 SetGID 文件模式）获得特权提升。

      +

      限制的字段

      • spec.containers[*].securityContext.allowPrivilegeEscalation
      • spec.initContainers[*].securityContext.allowPrivilegeEscalation
      • spec.ephemeralContainers[*].securityContext.allowPrivilegeEscalation
      -

      Allowed Values

      -
        -
      • false
        • -
      -       		特权提升（v1.8+） -

      禁止（通过 SetUID 或 SetGID 文件模式）获得特权提升。

      -
      -

      限制的字段

      -
        -
      • spec.containers[*].securityContext.allowPrivilegeEscalation
        • -
      • spec.initContainers[*].securityContext.allowPrivilegeEscalation
        • -
      • spec.ephemeralContainers[*].securityContext.allowPrivilegeEscalation
        • -
      -

      允许的值

      +

      允许的取值

      • false
      以非 root 账号运行 +

      容器必须以非 root 账号运行。

      +

      限制的字段

      • spec.securityContext.runAsNonRoot
      • spec.containers[*].securityContext.runAsNonRoot
      • spec.initContainers[*].securityContext.runAsNonRoot
      • spec.ephemeralContainers[*].securityContext.runAsNonRoot
      -

      Allowed Values

      +

      准许的取值

      • true
      - The container fields may be undefined/nil if the pod-level - spec.securityContext.runAsNonRoot is set to true. - -       		-

      必须要求容器以非 root 用户运行。

      -

      限制的字段

      -
        -
      • spec.securityContext.runAsNonRoot
        • -
      • spec.containers[*].securityContext.runAsNonRoot
        • -
      • spec.initContainers[*].securityContext.runAsNonRoot
        • -
      • spec.ephemeralContainers[*].securityContext.runAsNonRoot
        • -
      -

      允许的值

      -
        -
      • true
        • -
      - - 如果 Pod 级别 spec.securityContext.runAsNonRoot 设置为 - true，则允许容器组的安全上下文字段设置为 未定义/nil。 + 如果 Pod 级别 spec.securityContext.runAsNonRoot 设置为 true，则允许容器组的安全上下文字段设置为 未定义/nil。
      非 root 用户（v1.23+）非 root 用户（v1.23+） - 容器不可以将 runAsUser 设置为 0

      +

      限制的字段

      • spec.securityContext.runAsUser
      • spec.containers[*].securityContext.runAsUser
      • spec.initContainers[*].securityContext.runAsUser
      • spec.ephemeralContainers[*].securityContext.runAsUser
      -

      Allowed Values

      +

      准许的取值

        -
      • any non-zero value
        • +
      • 所有的非零值
      • undefined/null
      -
      Seccomp (v1.19+) - Seccomp Profile 必须被显式设置成一个允许的值。禁止使用 Unconfined Profile 或者指定 不存在的 Profile。

      +

      限制的字段

      • spec.securityContext.seccompProfile.type
      • spec.containers[*].securityContext.seccompProfile.type
      • spec.initContainers[*].securityContext.seccompProfile.type
      • spec.ephemeralContainers[*].securityContext.seccompProfile.type
      -

      Allowed Values

      +

      准许的取值

      • RuntimeDefault
      • Localhost
      - The container fields may be undefined/nil if the pod-level - spec.securityContext.seccompProfile.type field is set appropriately. - Conversely, the pod-level field may be undefined/nil if _all_ container- - level fields are set. + 如果 Pod 级别的 spec.securityContext.seccompProfile.type 已设置得当，容器级别的安全上下文字段可以为 未定义/nil。反而言之，如果 所有的 容器级别的安全上下文字段已设置，则 Pod 级别的字段可为 未定义/nil。 -
      权能（v1.22+）

      - Containers must drop ALL capabilities, and are only permitted to add back - the NET_BIND_SERVICE capability. + 容器必须弃用 ALL 权能，并且只允许添加 NET_BIND_SERVICE 权能。

      -

      Restricted Fields

      +

      限制的字段

      • spec.containers[*].securityContext.capabilities.drop
      • spec.initContainers[*].securityContext.capabilities.drop
      • spec.ephemeralContainers[*].securityContext.capabilities.drop
      -

      Allowed Values

      +

      准许的取值

        -
      • Any list of capabilities that includes ALL
        • +
      • 包括 ALL 在内的任意权能列表。
      -

      Restricted Fields

      +

      限制的字段

      • spec.containers[*].securityContext.capabilities.add
      • spec.initContainers[*].securityContext.capabilities.add
      • spec.ephemeralContainers[*].securityContext.capabilities.add
      -

      Allowed Values

      +

      准许的取值

        -
      • Undefined/nil
        • -
      • NET_BIND_SERVICE
        • -
      -       		-

      - 容器组必须弃用 ALL 权能，并且只允许添加 NET_BIND_SERVICE 权能。 -

      -

      限制的字段

      -
        -
      • spec.containers[*].securityContext.capabilities.drop
        • -
      • spec.initContainers[*].securityContext.capabilities.drop
        • -
      • spec.ephemeralContainers[*].securityContext.capabilities.drop
        • -
      -

      允许的值

      -
        -
      • 包含 ALL 的任何一种权能列表。
        • -
      -
      -

      限制的字段

      -
        -
      • spec.containers[*].securityContext.capabilities.add
        • -
      • spec.initContainers[*].securityContext.capabilities.add
        • -
      • spec.ephemeralContainers[*].securityContext.capabilities.add
        • -
      -

      允许的值

      -
        -
      • 未定义/nil
        • +
      • 未定义、nil
      • NET_BIND_SERVICE
      diff --git a/content/zh-cn/docs/reference/command-line-tools-reference/kubelet.md b/content/zh-cn/docs/reference/command-line-tools-reference/kubelet.md index a82f0e1f53..fc7f1f31ef 100644 --- a/content/zh-cn/docs/reference/command-line-tools-reference/kubelet.md +++ b/content/zh-cn/docs/reference/command-line-tools-reference/kubelet.md @@ -1351,7 +1351,7 @@ A set of <resource name>=<resource quantity> (e.g. <资源名称>=<资源数量> 格式表示。 （例如：cpu=200m,memory=500Mi,ephemeral-storage=1Gi,pid='100'）。 当前支持 cpu、memory 和用于根文件系统的 ephemeral-storage。 -请参阅这里获取更多信息。 +请参阅这里获取更多信息。 （已弃用：应在 --config 所给的配置文件中进行设置。 请参阅 kubelet-config-file 了解更多信息。） diff --git a/content/zh-cn/docs/reference/config-api/kubelet-config.v1beta1.md b/content/zh-cn/docs/reference/config-api/kubelet-config.v1beta1.md index 9650311462..15864fe93d 100644 --- a/content/zh-cn/docs/reference/config-api/kubelet-config.v1beta1.md +++ b/content/zh-cn/docs/reference/config-api/kubelet-config.v1beta1.md @@ -2,7 +2,6 @@ title: Kubelet 配置 (v1beta1) content_type: tool-reference package: kubelet.config.k8s.io/v1beta1 -auto_generated: true ---

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

      默认值：""

      @@ -696,7 +695,7 @@ Default: "&qout; -

      cgroupRoot是用来运行 Pod 的控制组 (CGroup）。 +

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

      @@ -725,7 +724,7 @@ Default: true or systemd). Default: "cgroupfs" --> -

      cgroupDriver是 kubelet 用来操控宿主系统上控制组 (CGroup） +

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

      默认值："cgroupfs"

      @@ -1399,7 +1398,8 @@ Default: nil -->

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

      -

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

      +

      目前仅支持 CPU 和内存。更多细节可参见 + https://kubernetes.io/zh-cn/docs/concepts/configuration/manage-resources-containers/ 。

      默认值：Nil

      diff --git a/content/zh-cn/docs/reference/glossary/addons.md b/content/zh-cn/docs/reference/glossary/addons.md index 31fc1f0098..3fd0546714 100644 --- a/content/zh-cn/docs/reference/glossary/addons.md +++ b/content/zh-cn/docs/reference/glossary/addons.md @@ -2,7 +2,7 @@ title: 附加组件（Add-ons） id: addons date: 2019-12-15 -full_link: /zh/docs/concepts/cluster-administration/addons/ +full_link: /zh-cn/docs/concepts/cluster-administration/addons/ short_description: > 扩展 Kubernetes 功能的资源。 @@ -37,4 +37,4 @@ tags: -[安装附加组件](/zh/docs/concepts/cluster-administration/addons/) 阐释了更多关于如何在集群内使用附加组件，并列出了一些流行的附加组件。 +[安装附加组件](/zh-cn/docs/concepts/cluster-administration/addons/) 阐释了更多关于如何在集群内使用附加组件，并列出了一些流行的附加组件。 diff --git a/content/zh-cn/docs/reference/glossary/admission-controller.md b/content/zh-cn/docs/reference/glossary/admission-controller.md index 22567c4861..90e63e52b1 100644 --- a/content/zh-cn/docs/reference/glossary/admission-controller.md +++ b/content/zh-cn/docs/reference/glossary/admission-controller.md @@ -2,7 +2,7 @@ title: 准入控制器（Admission Controller） id: admission-controller date: 2019-06-28 -full_link: /zh/docs/reference/access-authn-authz/admission-controllers/ +full_link: /zh-cn/docs/reference/access-authn-authz/admission-controllers/ short_description: > 在对象持久化之前拦截 Kubernetes Api 服务器请求的一段代码 aka: @@ -47,4 +47,4 @@ validating controllers may not. 准入控制器可针对 Kubernetes Api 服务器进行配置，可以执行验证，变更或两者都执行。任何准入控制器都可以拒绝访问请求。 变更（mutating）控制器可以修改其允许的对象，验证（validating）控制器则不可以。 -* [Kubernetes 文档中的准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/) \ No newline at end of file +* [Kubernetes 文档中的准入控制器](/zh-cn/docs/reference/access-authn-authz/admission-controllers/) \ No newline at end of file diff --git a/content/zh-cn/docs/reference/glossary/affinity.md b/content/zh-cn/docs/reference/glossary/affinity.md index b3450ed02f..44aa0ab6ca 100644 --- a/content/zh-cn/docs/reference/glossary/affinity.md +++ b/content/zh-cn/docs/reference/glossary/affinity.md @@ -36,8 +36,8 @@ There are two kinds of affinity: * [node affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity) * [pod-to-pod affinity](/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity) --> -* [节点亲和性](/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) +* [节点亲和性](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#node-affinity) +* [Pod 间亲和性](/zh-cn/docs/concepts/scheduling-eviction/assign-pod-node/#inter-pod-affinity-and-anti-affinity) -当你配置了 {{< glossary_tooltip text="Kubernetes API Server" term_id="kube-apiserver" >}} 来 [支持额外的 API](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/)， +当你配置了 {{< glossary_tooltip text="Kubernetes API Server" term_id="kube-apiserver" >}} 来 [支持额外的 API](/zh-cn/docs/tasks/extend-kubernetes/configure-aggregation-layer/)， 你就可以在 Kubernetes API 中增加 `APIService` 对象来 "申领（Claim）" 一个 URL 路径。 diff --git a/content/zh-cn/docs/reference/glossary/annotation.md b/content/zh-cn/docs/reference/glossary/annotation.md index a305352e32..5554aafbbc 100644 --- a/content/zh-cn/docs/reference/glossary/annotation.md +++ b/content/zh-cn/docs/reference/glossary/annotation.md @@ -2,7 +2,7 @@ title: 注解（Annotation） id: annotation date: 2018-04-12 -full_link: /zh/docs/concepts/overview/working-with-objects/annotations/ +full_link: /zh-cn/docs/concepts/overview/working-with-objects/annotations/ short_description: > 注解是以键值对的形式给资源对象附加随机的无法标识的元数据。 diff --git a/content/zh-cn/docs/reference/glossary/api-eviction.md b/content/zh-cn/docs/reference/glossary/api-eviction.md index 0f1aabd435..4ed41b8648 100644 --- a/content/zh-cn/docs/reference/glossary/api-eviction.md +++ b/content/zh-cn/docs/reference/glossary/api-eviction.md @@ -2,7 +2,7 @@ title: API 发起的驱逐 id: api-eviction date: 2021-04-27 -full_link: /zh/docs/concepts/scheduling-eviction/pod-eviction/#api-eviction +full_link: /zh-cn/docs/concepts/scheduling-eviction/pod-eviction/#api-eviction short_description: > API 发起的驱逐是一个先调用 Eviction API 创建驱逐对象，再由该对象体面地中止 Pod 的过程。 aka: @@ -46,13 +46,13 @@ API-initiated eviction is not the same as [node-pressure eviction](/docs/concept 你可以通过 kube-apiserver 的客户端，比如 `kubectl drain` 这样的命令，直接调用 Eviction API 发起驱逐。 当 `Eviction` 对象创建出来之后，该对象将驱动 API 服务器终止选定的Pod。 -API 发起的驱逐取决于你配置的 [`PodDisruptionBudgets`](/zh/docs/tasks/run-application/configure-pdb/) -和 [`terminationGracePeriodSeconds`](/zh/docs/concepts/workloads/pods/pod-lifecycle#pod-termination)。 +API 发起的驱逐取决于你配置的 [`PodDisruptionBudgets`](/zh-cn/docs/tasks/run-application/configure-pdb/) +和 [`terminationGracePeriodSeconds`](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle#pod-termination)。 API 发起的驱逐不同于 -[节点压力引发的驱逐](/zh/docs/concepts/scheduling-eviction/eviction/#kubelet-eviction)。 +[节点压力引发的驱逐](/zh-cn/docs/concepts/scheduling-eviction/eviction/#kubelet-eviction)。 -* 有关详细信息，请参阅 [API 发起的驱逐](/zh/docs/concepts/scheduling-eviction/api-eviction/)。 \ No newline at end of file +* 有关详细信息，请参阅 [API 发起的驱逐](/zh-cn/docs/concepts/scheduling-eviction/api-eviction/)。 \ No newline at end of file diff --git a/content/zh-cn/docs/reference/glossary/api-group.md b/content/zh-cn/docs/reference/glossary/api-group.md index a219943be7..42006b5e90 100644 --- a/content/zh-cn/docs/reference/glossary/api-group.md +++ b/content/zh-cn/docs/reference/glossary/api-group.md @@ -2,7 +2,7 @@ title: API Group id: api-group date: 2019-09-02 -full_link: /zh/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning +full_link: /zh-cn/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning short_description: > Kubernetes API 中的一组相关路径 @@ -47,4 +47,4 @@ API group 在 REST 路径和序列化对象的 `apiVersion` 字段中指定。 -* 阅读 [API Group](/zh/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning) 了解更多信息。 +* 阅读 [API Group](/zh-cn/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning) 了解更多信息。 diff --git a/content/zh-cn/docs/reference/glossary/certificate.md b/content/zh-cn/docs/reference/glossary/certificate.md index 05b50e37dc..7de6715c16 100644 --- a/content/zh-cn/docs/reference/glossary/certificate.md +++ b/content/zh-cn/docs/reference/glossary/certificate.md @@ -2,7 +2,7 @@ title: 证书（Certificate） id: certificate date: 2018-04-12 -full_link: /zh/docs/tasks/tls/managing-tls-in-a-cluster/ +full_link: /zh-cn/docs/tasks/tls/managing-tls-in-a-cluster/ short_description: > 证书是个安全加密文件，用来确认对 Kubernetes 集群访问的合法性。 diff --git a/content/zh-cn/docs/reference/glossary/cloud-controller-manager.md b/content/zh-cn/docs/reference/glossary/cloud-controller-manager.md index 7fc039db36..72c581453c 100644 --- a/content/zh-cn/docs/reference/glossary/cloud-controller-manager.md +++ b/content/zh-cn/docs/reference/glossary/cloud-controller-manager.md @@ -2,7 +2,7 @@ title: 云控制器管理器（Cloud Controller Manager） id: cloud-controller-manager date: 2018-04-12 -full_link: /zh/docs/concepts/architecture/cloud-controller/ +full_link: /zh-cn/docs/concepts/architecture/cloud-controller/ short_description: > 将 Kubernetes 与第三方云提供商进行集成的控制面组件。 diff --git a/content/zh-cn/docs/reference/glossary/cni.md b/content/zh-cn/docs/reference/glossary/cni.md index 64febe0215..5f87815cb5 100644 --- a/content/zh-cn/docs/reference/glossary/cni.md +++ b/content/zh-cn/docs/reference/glossary/cni.md @@ -2,7 +2,7 @@ title: 容器网络接口（CNI） id: cni date: 2018-05-25 -full_link: /zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni +full_link: /zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni short_description: > 容器网络接口 (CNI) 插件是遵循 appc/CNI 协议的一类网络插件。 @@ -41,4 +41,4 @@ tags: * For information on Kubernetes and CNI, see ["Network plugins"](/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni). --> -* 想了解 Kubernetes 和 CNI 请参考 ["网络插件"](/zh/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni)。 +* 想了解 Kubernetes 和 CNI 请参考 ["网络插件"](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/network-plugins/#cni)。 diff --git a/content/zh-cn/docs/reference/glossary/configmap.md b/content/zh-cn/docs/reference/glossary/configmap.md index cc22e9de56..b90382e518 100644 --- a/content/zh-cn/docs/reference/glossary/configmap.md +++ b/content/zh-cn/docs/reference/glossary/configmap.md @@ -2,7 +2,7 @@ title: ConfigMap id: configmap date: 2018-04-12 -full_link: /zh/docs/tasks/configure-pod-container/configure-pod-configmap/ +full_link: /zh-cn/docs/tasks/configure-pod-container/configure-pod-configmap/ short_description: > ConfigMap 是一种 API 对象，用来将非机密性的数据保存到键值对中。使用时可以用作环境变量、命令行参数或者存储卷中的配置文件。 diff --git a/content/zh-cn/docs/reference/glossary/container-env-variables.md b/content/zh-cn/docs/reference/glossary/container-env-variables.md index e8796a12bd..134b0c0c7e 100644 --- a/content/zh-cn/docs/reference/glossary/container-env-variables.md +++ b/content/zh-cn/docs/reference/glossary/container-env-variables.md @@ -2,7 +2,7 @@ title: 容器环境变量（Container Environment Variables） id: container-env-variables date: 2018-04-12 -full_link: /zh/docs/concepts/containers/container-environment/ +full_link: /zh-cn/docs/concepts/containers/container-environment/ short_description: > 容器环境变量提供了 name=value 形式的、运行容器化应用所必须的一些重要信息。 diff --git a/content/zh-cn/docs/reference/glossary/container-lifecycle-hooks.md b/content/zh-cn/docs/reference/glossary/container-lifecycle-hooks.md index 6a43d283c9..1823b66b4c 100644 --- a/content/zh-cn/docs/reference/glossary/container-lifecycle-hooks.md +++ b/content/zh-cn/docs/reference/glossary/container-lifecycle-hooks.md @@ -2,7 +2,7 @@ title: 容器生命周期钩子（Container Lifecycle Hooks） id: container-lifecycle-hooks date: 2018-10-08 -full_link: /zh/docs/concepts/containers/container-lifecycle-hooks/ +full_link: /zh-cn/docs/concepts/containers/container-lifecycle-hooks/ short_description: > 生命周期钩子暴露容器管理生命周期中的事件，允许用户在事件发生时运行代码。 diff --git a/content/zh-cn/docs/reference/glossary/container-runtime-interface.md b/content/zh-cn/docs/reference/glossary/container-runtime-interface.md index 39bc8d0017..b902dc5da0 100644 --- a/content/zh-cn/docs/reference/glossary/container-runtime-interface.md +++ b/content/zh-cn/docs/reference/glossary/container-runtime-interface.md @@ -2,7 +2,7 @@ title: 容器运行时接口 id: container-runtime-interface date: 2021-11-24 -full_link: /zh/docs/concepts/architecture/cri +full_link: /zh-cn/docs/concepts/architecture/cri short_description: > kubelet 和容器运行时之间通信的主要协议。 @@ -37,6 +37,6 @@ The Kubernetes Container Runtime Interface (CRI) defines the main {{< glossary_tooltip text="container runtime" term_id="container-runtime" >}}. --> Kubernetes 容器运行时接口（CRI）定义了主要 [gRPC](https://grpc.io) 协议， -用于[集群组件](/zh/docs/concepts/overview/components/#node-components) +用于[集群组件](/zh-cn/docs/concepts/overview/components/#node-components) {{< glossary_tooltip text="kubelet" term_id="kubelet" >}} 和 {{< glossary_tooltip text="容器运行时" term_id="container-runtime" >}}。 \ No newline at end of file diff --git a/content/zh-cn/docs/reference/glossary/container-runtime.md b/content/zh-cn/docs/reference/glossary/container-runtime.md index 0040642c43..4eaf10627e 100644 --- a/content/zh-cn/docs/reference/glossary/container-runtime.md +++ b/content/zh-cn/docs/reference/glossary/container-runtime.md @@ -2,7 +2,7 @@ title: 容器运行时（Container Runtime） id: container-runtime date: 2019-06-05 -full_link: /zh/docs/setup/production-environment/container-runtimes +full_link: /zh-cn/docs/setup/production-environment/container-runtimes short_description: > 容器运行时是负责运行容器的软件。 diff --git a/content/zh-cn/docs/reference/glossary/container.md b/content/zh-cn/docs/reference/glossary/container.md index 450a8af998..1ca18e3ca4 100644 --- a/content/zh-cn/docs/reference/glossary/container.md +++ b/content/zh-cn/docs/reference/glossary/container.md @@ -2,7 +2,7 @@ title: 容器（Container） id: container date: 2018-04-12 -full_link: /zh/docs/concepts/overview/what-is-kubernetes/#why-containers +full_link: /zh-cn/docs/concepts/overview/what-is-kubernetes/#why-containers short_description: > 容器是可移植、可执行的轻量级的镜像，镜像中包含软件及其相关依赖。 diff --git a/content/zh-cn/docs/reference/glossary/controller.md b/content/zh-cn/docs/reference/glossary/controller.md index e60b710603..a0c0c02bce 100644 --- a/content/zh-cn/docs/reference/glossary/controller.md +++ b/content/zh-cn/docs/reference/glossary/controller.md @@ -2,7 +2,7 @@ title: 控制器（Controller） id: controller date: 2018-04-12 -full_link: /zh/docs/concepts/architecture/controller/ +full_link: /zh-cn/docs/concepts/architecture/controller/ short_description: > 控制器通过 apiserver 监控集群的公共状态，并致力于将当前状态转变为期望的状态。 diff --git a/content/zh-cn/docs/reference/glossary/cri.md b/content/zh-cn/docs/reference/glossary/cri.md index 8c8da979e9..24450960d0 100644 --- a/content/zh-cn/docs/reference/glossary/cri.md +++ b/content/zh-cn/docs/reference/glossary/cri.md @@ -2,7 +2,7 @@ title: 容器运行时接口（CRI） id: cri date: 2019-03-07 -full_link: /zh/docs/concepts/overview/components/#container-runtime +full_link: /zh-cn/docs/concepts/overview/components/#container-runtime short_description: > 一组与 kubelet 集成的容器运行时 API diff --git a/content/zh-cn/docs/reference/glossary/cronjob.md b/content/zh-cn/docs/reference/glossary/cronjob.md index fe16d58762..487731fe31 100644 --- a/content/zh-cn/docs/reference/glossary/cronjob.md +++ b/content/zh-cn/docs/reference/glossary/cronjob.md @@ -2,7 +2,7 @@ title: 周期调度任务（CronJob） id: cronjob date: 2018-04-12 -full_link: /zh/docs/concepts/workloads/controllers/cron-jobs/ +full_link: /zh-cn/docs/concepts/workloads/controllers/cron-jobs/ short_description: > 周期调度的任务（作业）。 @@ -32,7 +32,7 @@ tags: Manages a [Job](/docs/concepts/workloads/controllers/job/) that runs on a periodic schedule. --> - 管理定期运行的 [任务](/zh/docs/concepts/workloads/controllers/job/)。 + 管理定期运行的 [任务](/zh-cn/docs/concepts/workloads/controllers/job/)。 diff --git a/content/zh-cn/docs/reference/glossary/csi.md b/content/zh-cn/docs/reference/glossary/csi.md index 89bb66cafd..d430ef3eca 100644 --- a/content/zh-cn/docs/reference/glossary/csi.md +++ b/content/zh-cn/docs/reference/glossary/csi.md @@ -2,7 +2,7 @@ title: 容器存储接口（Container Storage Interface，CSI） id: csi date: 2018-06-25 -full_link: /zh/docs/concepts/storage/volumes/#csi +full_link: /zh-cn/docs/concepts/storage/volumes/#csi short_description: > 容器存储接口 （CSI）定义了存储系统暴露给容器的标准接口。 @@ -48,5 +48,5 @@ CSI 允许存储驱动提供商为 Kubernetes 创建定制化的存储插件， [将它部署到你的集群上](https://kubernetes-csi.github.io/docs/deploying.html)。 然后你才能创建使用该 CSI 驱动的 {{< glossary_tooltip text="Storage Class" term_id="storage-class" >}} 。 -* [Kubernetes 文档中关于 CSI 的描述](/zh/docs/concepts/storage/volumes/#csi) +* [Kubernetes 文档中关于 CSI 的描述](/zh-cn/docs/concepts/storage/volumes/#csi) * [可用的 CSI 驱动列表](https://kubernetes-csi.github.io/docs/drivers.html) diff --git a/content/zh-cn/docs/reference/glossary/customresourcedefinition.md b/content/zh-cn/docs/reference/glossary/customresourcedefinition.md index c29e02d8c5..2d63482c3e 100644 --- a/content/zh-cn/docs/reference/glossary/customresourcedefinition.md +++ b/content/zh-cn/docs/reference/glossary/customresourcedefinition.md @@ -2,7 +2,7 @@ title: CustomResourceDefinition id: CustomResourceDefinition date: 2018-04-12 -full_link: /zh/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/ +full_link: /zh-cn/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/ short_description: > 通过定制化的代码给你的 Kubernetes API 服务器增加资源对象，而无需编译完整的定制 API 服务器。 diff --git a/content/zh-cn/docs/reference/glossary/daemonset.md b/content/zh-cn/docs/reference/glossary/daemonset.md index 5f35ae5012..7096011743 100644 --- a/content/zh-cn/docs/reference/glossary/daemonset.md +++ b/content/zh-cn/docs/reference/glossary/daemonset.md @@ -2,7 +2,7 @@ title: DaemonSet id: daemonset date: 2018-04-12 -full_link: /zh/docs/concepts/workloads/controllers/daemonset/ +full_link: /zh-cn/docs/concepts/workloads/controllers/daemonset/ short_description: > 确保 Pod 的副本在集群中的一组节点上运行。 diff --git a/content/zh-cn/docs/reference/glossary/deployment.md b/content/zh-cn/docs/reference/glossary/deployment.md index ca52523e46..e09f680581 100644 --- a/content/zh-cn/docs/reference/glossary/deployment.md +++ b/content/zh-cn/docs/reference/glossary/deployment.md @@ -2,7 +2,7 @@ title: Deployment id: deployment date: 2018-04-12 -full_link: /zh/docs/concepts/workloads/controllers/deployment/ +full_link: /zh-cn/docs/concepts/workloads/controllers/deployment/ short_description: > Deployment 是管理应用副本的 API 对象。 diff --git a/content/zh-cn/docs/reference/glossary/device-plugin.md b/content/zh-cn/docs/reference/glossary/device-plugin.md index 30664b8c31..9bbecf8d1d 100644 --- a/content/zh-cn/docs/reference/glossary/device-plugin.md +++ b/content/zh-cn/docs/reference/glossary/device-plugin.md @@ -2,7 +2,7 @@ title: 设备插件（Device Plugin） id: device-plugin date: 2019-02-02 -full_link: /zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/ +full_link: /zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/ short_description: > 一种软件扩展，可以使 Pod 访问由特定厂商初始化或者安装的设备。 aka: @@ -49,4 +49,4 @@ See [Device Plugins](/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) for more information. --> -更多信息请查阅[设备插件](/zh/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) \ No newline at end of file +更多信息请查阅[设备插件](/zh-cn/docs/concepts/extend-kubernetes/compute-storage-net/device-plugins/) \ No newline at end of file diff --git a/content/zh-cn/docs/reference/glossary/disruption.md b/content/zh-cn/docs/reference/glossary/disruption.md index 6cfc0a1809..aa4fca945c 100644 --- a/content/zh-cn/docs/reference/glossary/disruption.md +++ b/content/zh-cn/docs/reference/glossary/disruption.md @@ -2,7 +2,7 @@ title: 干扰（Disruption） id: disruption date: 2019-09-10 -full_link: /zh/docs/concepts/workloads/pods/disruptions/ +full_link: /zh-cn/docs/concepts/workloads/pods/disruptions/ short_description: > 导致 Pod 服务停止的事件。 aka: @@ -44,4 +44,4 @@ See [Disruptions](/docs/concepts/workloads/pods/disruptions/) for more informati 如果你作为一个集群操作人员，销毁了一个从属于某个应用的 Pod, Kubernetes 视之为**自愿干扰（Voluntary Disruption）**。 如果由于节点故障 或者影响更大区域故障的断电导致 Pod 离线，kubernetes 视之为**非愿干扰（Involuntary Disruption）**。 -更多信息请查阅[Disruptions](/zh/docs/concepts/workloads/pods/disruptions/) \ No newline at end of file +更多信息请查阅[Disruptions](/zh-cn/docs/concepts/workloads/pods/disruptions/) \ No newline at end of file diff --git a/content/zh-cn/docs/reference/glossary/docker.md b/content/zh-cn/docs/reference/glossary/docker.md index bec6c834f2..78ac4c9f50 100644 --- a/content/zh-cn/docs/reference/glossary/docker.md +++ b/content/zh-cn/docs/reference/glossary/docker.md @@ -2,7 +2,7 @@ title: Docker id: docker date: 2018-04-12 -full_link: /zh/docs/reference/kubectl/docker-cli-to-kubectl/ +full_link: /zh-cn/docs/reference/kubectl/docker-cli-to-kubectl/ short_description: > Docker 是一种可以提供操作系统级别虚拟化（也称作容器）的软件技术。 diff --git a/content/zh-cn/docs/reference/glossary/dockershim.md b/content/zh-cn/docs/reference/glossary/dockershim.md index 22570a4b17..b12b08d54a 100644 --- a/content/zh-cn/docs/reference/glossary/dockershim.md +++ b/content/zh-cn/docs/reference/glossary/dockershim.md @@ -2,7 +2,7 @@ title: Dockershim id: dockershim date: 2022-04-15 -full_link: /zh/dockershim +full_link: /zh-cn/dockershim short_description: > dockershim 是 Kubernetes v1.23 及之前版本中的一个组件，Kubernetes 系统组件通过它与 Docker Engine 通信。 @@ -37,4 +37,4 @@ Kubernetes 系统组件通过它与 {{< glossary_tooltip text="Docker Engine" te Starting with version 1.24, dockershim has been removed from Kubernetes. For more information, see [Dockershim FAQ](/dockershim). --> 从 Kubernetes v1.24 开始，dockershim 已从 Kubernetes 中移除. -想了解更多信息，可参考[移除 Dockershim 的常见问题](/zh/dockershim)。 \ No newline at end of file +想了解更多信息，可参考[移除 Dockershim 的常见问题](/zh-cn/dockershim)。 \ No newline at end of file diff --git a/content/zh-cn/docs/reference/glossary/dynamic-volume-provisioning.md b/content/zh-cn/docs/reference/glossary/dynamic-volume-provisioning.md index 5606af15a4..a4f8212ba8 100644 --- a/content/zh-cn/docs/reference/glossary/dynamic-volume-provisioning.md +++ b/content/zh-cn/docs/reference/glossary/dynamic-volume-provisioning.md @@ -2,7 +2,7 @@ title: 动态卷供应（Dynamic Volume Provisioning） id: dynamicvolumeprovisioning date: 2018-04-12 -full_link: /zh/docs/concepts/storage/dynamic-provisioning/ +full_link: /zh-cn/docs/concepts/storage/dynamic-provisioning/ short_description: > 允许用户请求自动创建存储卷。 diff --git a/content/zh-cn/docs/reference/glossary/endpoint-slice.md b/content/zh-cn/docs/reference/glossary/endpoint-slice.md index dcfc35e308..f08f9adf4b 100644 --- a/content/zh-cn/docs/reference/glossary/endpoint-slice.md +++ b/content/zh-cn/docs/reference/glossary/endpoint-slice.md @@ -2,7 +2,7 @@ title: EndpointSlice id: endpoint-slice date: 2018-04-12 -full_link: /zh/docs/concepts/services-networking/endpoint-slices/ +full_link: /zh-cn/docs/concepts/services-networking/endpoint-slices/ short_description: > 一种将网络端点与 Kubernetes 资源组合在一起的方法。 diff --git a/content/zh-cn/docs/reference/glossary/ephemeral-container.md b/content/zh-cn/docs/reference/glossary/ephemeral-container.md index a317bbfb10..0816175899 100644 --- a/content/zh-cn/docs/reference/glossary/ephemeral-container.md +++ b/content/zh-cn/docs/reference/glossary/ephemeral-container.md @@ -2,7 +2,7 @@ title: 临时容器（Ephemeral Container） id: ephemeral-container date: 2019-08-26 -full_link: /zh/docs/concepts/workloads/pods/ephemeral-containers/ +full_link: /zh-cn/docs/concepts/workloads/pods/ephemeral-containers/ short_description: > 你可以在 Pod 中临时运行的一种容器类型 aka: diff --git a/content/zh-cn/docs/reference/glossary/etcd.md b/content/zh-cn/docs/reference/glossary/etcd.md index adb4737975..8929d62f17 100644 --- a/content/zh-cn/docs/reference/glossary/etcd.md +++ b/content/zh-cn/docs/reference/glossary/etcd.md @@ -2,7 +2,7 @@ title: etcd id: etcd date: 2018-04-12 -full_link: /zh/docs/tasks/administer-cluster/configure-upgrade-etcd/ +full_link: /zh-cn/docs/tasks/administer-cluster/configure-upgrade-etcd/ short_description: > etcd 是兼具一致性和高可用性的键值数据库，用作保存 Kubernetes 所有集群数据的后台数据库。 @@ -40,7 +40,7 @@ If your Kubernetes cluster uses etcd as its backing store, make sure you have a [back up](/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster) plan for those data. --> -你的 Kubernetes 集群的 `etcd` 数据库通常需要有个[备份](/zh/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster)计划。 +你的 Kubernetes 集群的 `etcd` 数据库通常需要有个[备份](/zh-cn/docs/tasks/administer-cluster/configure-upgrade-etcd/#backing-up-an-etcd-cluster)计划。 diff --git a/content/zh-cn/docs/reference/glossary/event.md b/content/zh-cn/docs/reference/glossary/event.md index 37d143e60b..6c74215300 100644 --- a/content/zh-cn/docs/reference/glossary/event.md +++ b/content/zh-cn/docs/reference/glossary/event.md @@ -51,6 +51,6 @@ Events should be treated as informative, best-effort, supplemental data. In Kubernetes, [auditing](/docs/tasks/debug/debug-cluster/audit/) generates a different kind of Event record (API group `audit.k8s.io`). --> -在 Kubernetes 中，[审计](/zh/docs/tasks/debug/debug-cluster/audit/) +在 Kubernetes 中，[审计](/zh-cn/docs/tasks/debug/debug-cluster/audit/) 机制会生成一种不同种类的 Event 记录（API 组为 `audit.k8s.io`）。 diff --git a/content/zh-cn/docs/reference/glossary/eviction.md b/content/zh-cn/docs/reference/glossary/eviction.md index 30666ca2b1..142b9fa602 100644 --- a/content/zh-cn/docs/reference/glossary/eviction.md +++ b/content/zh-cn/docs/reference/glossary/eviction.md @@ -2,7 +2,7 @@ title: 驱逐 id: eviction date: 2021-05-08 -full_link: /zh/docs/concepts/scheduling-eviction/ +full_link: /zh-cn/docs/concepts/scheduling-eviction/ short_description: > 终止节点上一个或多个 Pod 的过程。 aka: @@ -33,6 +33,6 @@ There are two kinds of eviction: * [API-initiated eviction](/docs/reference/generated/kubernetes-api/v1.23/) --> 驱逐的两种类型 -* [节点压力驱逐](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/) +* [节点压力驱逐](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/) * [API 发起的驱逐](/docs/reference/generated/kubernetes-api/v1.23/) diff --git a/content/zh-cn/docs/reference/glossary/extensions.md b/content/zh-cn/docs/reference/glossary/extensions.md index bec430f31d..ae33b45a2e 100644 --- a/content/zh-cn/docs/reference/glossary/extensions.md +++ b/content/zh-cn/docs/reference/glossary/extensions.md @@ -2,7 +2,7 @@ title: 扩展组件（Extensions） id: Extensions date: 2019-02-01 -full_link: /zh/docs/concepts/extend-kubernetes/extend-cluster/#extensions +full_link: /zh-cn/docs/concepts/extend-kubernetes/extend-cluster/#extensions short_description: > 扩展组件是扩展并与 Kubernetes 深度集成以支持新型硬件的软件组件。 aka: @@ -37,5 +37,5 @@ Many cluster administrators use a hosted or distribution instance of Kubernetes. 许多集群管理员会使用托管的 Kubernetes 或其某种发行包，这些集群预装了扩展。 因此，大多数 Kubernetes 用户将不需要 -安装[扩展组件](/zh/docs/concepts/extend-kubernetes/extend-cluster/#extensions)， +安装[扩展组件](/zh-cn/docs/concepts/extend-kubernetes/extend-cluster/#extensions)， 需要编写新的扩展组件的用户就更少了。 diff --git a/content/zh-cn/docs/reference/glossary/finalizer.md b/content/zh-cn/docs/reference/glossary/finalizer.md index 82b462784c..2de7c10073 100644 --- a/content/zh-cn/docs/reference/glossary/finalizer.md +++ b/content/zh-cn/docs/reference/glossary/finalizer.md @@ -2,7 +2,7 @@ title: Finalizer id: finalizer date: 2021-07-07 -full_link: /zh/docs/concepts/overview/working-with-objects/finalizers/ +full_link: /zh-cn/docs/concepts/overview/working-with-objects/finalizers/ short_description: > 一个带有命名空间的键，告诉 Kubernetes 等到特定的条件被满足后， 再完全删除被标记为删除的资源。 @@ -17,7 +17,7 @@ tags: title: Finalizer id: finalizer date: 2021-07-07 -full_link: /zh/docs/concepts/overview/working-with-objects/finalizers/ +full_link: /zh-cn/docs/concepts/overview/working-with-objects/finalizers/ short_description: > A namespaced key that tells Kubernetes to wait until specific conditions are met before it fully deletes an object marked for deletion. diff --git a/content/zh-cn/docs/reference/glossary/flexvolume.md b/content/zh-cn/docs/reference/glossary/flexvolume.md index e0f15afb4c..c00fd05922 100644 --- a/content/zh-cn/docs/reference/glossary/flexvolume.md +++ b/content/zh-cn/docs/reference/glossary/flexvolume.md @@ -2,7 +2,7 @@ title: FlexVolume id: flexvolume date: 2018-06-25 -full_link: /zh/docs/concepts/storage/volumes/#flexvolume +full_link: /zh-cn/docs/concepts/storage/volumes/#flexvolume short_description: > FlexVolume 是一个已弃用的接口，用于创建树外卷插件。 {{< glossary_tooltip text="容器存储接口（CSI）" term_id="csi" >}} @@ -47,6 +47,6 @@ FlexVolume 驱动程序的二进制文件和依赖项必须安装在主机上。 * [More information on FlexVolumes](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) * [Volume Plugin FAQ for Storage Vendors](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md) --> -* [Kubernetes 文档中的 Flexvolume](/zh/docs/concepts/storage/volumes/#flexvolume) +* [Kubernetes 文档中的 Flexvolume](/zh-cn/docs/concepts/storage/volumes/#flexvolume) * [更多关于 Flexvolumes 的信息](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-storage/flexvolume.md) * [存储供应商的卷插件 FAQ](https://github.com/kubernetes/community/blob/master/sig-storage/volume-plugin-faq.md) diff --git a/content/zh-cn/docs/reference/glossary/garbage-collection.md b/content/zh-cn/docs/reference/glossary/garbage-collection.md index effc51483c..f6ca64f58d 100644 --- a/content/zh-cn/docs/reference/glossary/garbage-collection.md +++ b/content/zh-cn/docs/reference/glossary/garbage-collection.md @@ -2,7 +2,7 @@ title: 垃圾收集 id: garbage-collection date: 2021-07-07 -full_link: /zh/docs/concepts/workloads/controllers/garbage-collection/ +full_link: /zh-cn/docs/concepts/workloads/controllers/garbage-collection/ short_description: > Kubernetes 用于清理集群资源的各种机制的统称。 @@ -42,8 +42,8 @@ Kubernetes uses garbage collection to clean up resources like [unused containers that have expired or failed. --> Kubernetes 使用垃圾收集机制来清理资源，例如： -[未使用的容器和镜像](/zh/docs/concepts/workloads/controllers/garbage-collection/#containers-images)、 -[失败的 Pod](/zh/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)、 -[目标资源拥有的对象](/zh/docs/concepts/overview/working-with-objects/owners-dependents/)、 -[已完成的 Job](/zh/docs/concepts/workloads/controllers/ttlafterfinished/)、 +[未使用的容器和镜像](/zh-cn/docs/concepts/workloads/controllers/garbage-collection/#containers-images)、 +[失败的 Pod](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)、 +[目标资源拥有的对象](/zh-cn/docs/concepts/overview/working-with-objects/owners-dependents/)、 +[已完成的 Job](/zh-cn/docs/concepts/workloads/controllers/ttlafterfinished/)、 过期或出错的资源。 \ No newline at end of file diff --git a/content/zh-cn/docs/reference/glossary/horizontal-pod-autoscaler.md b/content/zh-cn/docs/reference/glossary/horizontal-pod-autoscaler.md index 45e5033a5a..49b18de3ee 100644 --- a/content/zh-cn/docs/reference/glossary/horizontal-pod-autoscaler.md +++ b/content/zh-cn/docs/reference/glossary/horizontal-pod-autoscaler.md @@ -2,7 +2,7 @@ title: Pod 水平自动扩缩器（Horizontal Pod Autoscaler） id: horizontal-pod-autoscaler date: 2018-04-12 -full_link: /zh/docs/tasks/run-application/horizontal-pod-autoscale/ +full_link: /zh-cn/docs/tasks/run-application/horizontal-pod-autoscale/ short_description: > Pod 水平自动扩缩器（Horizontal Pod Autoscaler）是一种 API 资源，它根据目标 CPU 利用率或自定义度量目标扩缩 Pod 副本的数量。 diff --git a/content/zh-cn/docs/reference/glossary/ingress.md b/content/zh-cn/docs/reference/glossary/ingress.md index 2b08741574..e48b9948a1 100644 --- a/content/zh-cn/docs/reference/glossary/ingress.md +++ b/content/zh-cn/docs/reference/glossary/ingress.md @@ -2,7 +2,7 @@ title: Ingress id: ingress date: 2018-04-12 -full_link: /zh/docs/concepts/services-networking/ingress/ +full_link: /zh-cn/docs/concepts/services-networking/ingress/ short_description: > Ingress 是对集群中服务的外部访问进行管理的 API 对象，典型的访问方式是 HTTP。 diff --git a/content/zh-cn/docs/reference/glossary/job.md b/content/zh-cn/docs/reference/glossary/job.md index aa557297be..220f811144 100644 --- a/content/zh-cn/docs/reference/glossary/job.md +++ b/content/zh-cn/docs/reference/glossary/job.md @@ -2,7 +2,7 @@ title: Job id: job date: 2018-04-12 -full_link: /zh/docs/concepts/workloads/controllers/job/ +full_link: /zh-cn/docs/concepts/workloads/controllers/job/ short_description: > Job 是需要运行完成的确定性的或批量的任务。 diff --git a/content/zh-cn/docs/reference/glossary/kube-controller-manager.md b/content/zh-cn/docs/reference/glossary/kube-controller-manager.md index f770230160..132a05936b 100644 --- a/content/zh-cn/docs/reference/glossary/kube-controller-manager.md +++ b/content/zh-cn/docs/reference/glossary/kube-controller-manager.md @@ -29,7 +29,7 @@ tags: Control plane component that runs {{< glossary_tooltip text="controller" term_id="controller" >}} processes. --> -[kube-controller-manager](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) +[kube-controller-manager](/zh-cn/docs/reference/command-line-tools-reference/kube-controller-manager/) 是{{< glossary_tooltip text="控制平面" term_id="control-plane" >}}的组件， 负责运行{{< 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 index 3fce715cb7..ef7b661715 100644 --- a/content/zh-cn/docs/reference/glossary/kube-proxy.md +++ b/content/zh-cn/docs/reference/glossary/kube-proxy.md @@ -2,7 +2,7 @@ title: kube-proxy id: kube-proxy date: 2018-04-12 -full_link: /zh/docs/reference/command-line-tools-reference/kube-proxy/ +full_link: /zh-cn/docs/reference/command-line-tools-reference/kube-proxy/ short_description: > `kube-proxy` 是集群中每个节点上运行的网络代理。 @@ -15,7 +15,7 @@ tags: title: kube-proxy id: kube-proxy date: 2018-04-12 -full_link: /zh/docs/reference/command-line-tools-reference/kube-proxy/ +full_link: /zh-cn/docs/reference/command-line-tools-reference/kube-proxy/ short_description: > `kube-proxy` is a network proxy that runs on each node in the cluster. @@ -30,7 +30,7 @@ tags: implementing part of the Kubernetes {{< glossary_tooltip term_id="service">}} concept. --> -[kube-proxy](/zh/docs/reference/command-line-tools-reference/kube-proxy/) +[kube-proxy](/zh-cn/docs/reference/command-line-tools-reference/kube-proxy/) 是集群中每个{{< glossary_tooltip text="节点（node）" term_id="node" >}}所上运行的网络代理， 实现 Kubernetes {{< glossary_tooltip term_id="service">}} 概念的一部分。 diff --git a/content/zh-cn/docs/reference/glossary/kube-scheduler.md b/content/zh-cn/docs/reference/glossary/kube-scheduler.md index c2964d0d74..f9c6ecdaf8 100644 --- a/content/zh-cn/docs/reference/glossary/kube-scheduler.md +++ b/content/zh-cn/docs/reference/glossary/kube-scheduler.md @@ -2,7 +2,7 @@ title: kube-scheduler id: kube-scheduler date: 2018-04-12 -full_link: /zh/docs/reference/command-line-tools-reference/kube-scheduler/ +full_link: /zh-cn/docs/reference/command-line-tools-reference/kube-scheduler/ short_description: > 控制平面组件，负责监视新创建的、未指定运行节点的 Pod，选择节点让 Pod 在上面运行。 diff --git a/content/zh-cn/docs/reference/glossary/kubeadm.md b/content/zh-cn/docs/reference/glossary/kubeadm.md index f565376100..106edda93c 100644 --- a/content/zh-cn/docs/reference/glossary/kubeadm.md +++ b/content/zh-cn/docs/reference/glossary/kubeadm.md @@ -2,7 +2,7 @@ title: Kubeadm id: kubeadm date: 2018-04-12 -full_link: /zh/docs/setup/production-environment/tools/kubeadm/ +full_link: /zh-cn/docs/setup/production-environment/tools/kubeadm/ short_description: > 用来快速安装 Kubernetes 并搭建安全稳定的集群的工具。 diff --git a/content/zh-cn/docs/reference/glossary/kubernetes-api.md b/content/zh-cn/docs/reference/glossary/kubernetes-api.md index 060ddf93cd..0a6c096a42 100644 --- a/content/zh-cn/docs/reference/glossary/kubernetes-api.md +++ b/content/zh-cn/docs/reference/glossary/kubernetes-api.md @@ -2,7 +2,7 @@ title: Kubernetes API id: kubernetes-api date: 2018-04-12 -full_link: /zh/docs/concepts/overview/kubernetes-api/ +full_link: /zh-cn/docs/concepts/overview/kubernetes-api/ short_description: > Kubernetes API 是通过 RESTful 接口提供 Kubernetes 功能服务并负责集群状态存储的应用程序。 diff --git a/content/zh-cn/docs/reference/glossary/label.md b/content/zh-cn/docs/reference/glossary/label.md index f2c661cc44..e0654faa26 100644 --- a/content/zh-cn/docs/reference/glossary/label.md +++ b/content/zh-cn/docs/reference/glossary/label.md @@ -2,7 +2,7 @@ title: 标签（Label） id: label date: 2018-04-12 -full_link: /zh/docs/concepts/overview/working-with-objects/labels/ +full_link: /zh-cn/docs/concepts/overview/working-with-objects/labels/ short_description: > 用来为对象设置可标识的属性标记；这些标记对用户而言是有意义且重要的。 diff --git a/content/zh-cn/docs/reference/glossary/logging.md b/content/zh-cn/docs/reference/glossary/logging.md index 64d8dbd0ac..17e490de27 100644 --- a/content/zh-cn/docs/reference/glossary/logging.md +++ b/content/zh-cn/docs/reference/glossary/logging.md @@ -2,7 +2,7 @@ title: 日志（Logging） id: logging date: 2019-04-04 -full_link: /zh/docs/concepts/cluster-administration/logging/ +full_link: /zh-cn/docs/concepts/cluster-administration/logging/ short_description: > 日志是集群或应用程序记录的事件列表。 @@ -18,7 +18,7 @@ tags: title: Logging id: logging date: 2019-04-04 -full_link: /zh/docs/concepts/cluster-administration/logging/ +full_link: /zh-cn/docs/concepts/cluster-administration/logging/ short_description: > Logs are the list of events that are logged by cluster or application. diff --git a/content/zh-cn/docs/reference/glossary/managed-service.md b/content/zh-cn/docs/reference/glossary/managed-service.md index 567736f091..9863824a25 100644 --- a/content/zh-cn/docs/reference/glossary/managed-service.md +++ b/content/zh-cn/docs/reference/glossary/managed-service.md @@ -34,13 +34,6 @@ tags: 托管服务的一些例子有 AWS EC2、Azure SQL 数据库和 GCP Pub/Sub 等， 不过它们也可以是可以被某应用使用的任何软件交付件。 -[服务目录](/zh/docs/concepts/extend-kubernetes/service-catalog/) -提供了一种方法用来列举、制备和绑定到 -{{< glossary_tooltip text="服务代理商（Service Brokers）" term_id="service-broker" >}} -所提供的托管服务。 diff --git a/content/zh-cn/docs/reference/glossary/minikube.md b/content/zh-cn/docs/reference/glossary/minikube.md index 4d834cd807..b688f96822 100644 --- a/content/zh-cn/docs/reference/glossary/minikube.md +++ b/content/zh-cn/docs/reference/glossary/minikube.md @@ -44,4 +44,4 @@ You can use Minikube to Minikube 在用户计算机上的一个虚拟机内运行单节点 Kubernetes 集群。 你可以使用 Minikube -[在学习环境中尝试 Kubernetes](/zh/docs/setup/learning-environment/). +[在学习环境中尝试 Kubernetes](/zh-cn/docs/setup/learning-environment/). diff --git a/content/zh-cn/docs/reference/glossary/name.md b/content/zh-cn/docs/reference/glossary/name.md index 6c6dd2b15c..984b85f1f7 100644 --- a/content/zh-cn/docs/reference/glossary/name.md +++ b/content/zh-cn/docs/reference/glossary/name.md @@ -2,7 +2,7 @@ title: 名称（Name） id: name date: 2018-04-12 -full_link: /zh/docs/concepts/overview/working-with-objects/names/ +full_link: /zh-cn/docs/concepts/overview/working-with-objects/names/ short_description: > 客户端提供的字符串，用来指代资源 URL 中的对象，如 `/api/v1/pods/some-name`。 diff --git a/content/zh-cn/docs/reference/glossary/namespace.md b/content/zh-cn/docs/reference/glossary/namespace.md index 5934d748fe..b2033d2a03 100644 --- a/content/zh-cn/docs/reference/glossary/namespace.md +++ b/content/zh-cn/docs/reference/glossary/namespace.md @@ -2,7 +2,7 @@ title: 名字空间（Namespace） id: namespace date: 2018-04-12 -full_link: /zh/docs/concepts/overview/working-with-objects/namespaces/ +full_link: /zh-cn/docs/concepts/overview/working-with-objects/namespaces/ short_description: > 名字空间是 Kubernetes 用来支持隔离单个集群中的资源组的一种抽象。 diff --git a/content/zh-cn/docs/reference/glossary/network-policy.md b/content/zh-cn/docs/reference/glossary/network-policy.md index 864b6760d9..69c8f50319 100644 --- a/content/zh-cn/docs/reference/glossary/network-policy.md +++ b/content/zh-cn/docs/reference/glossary/network-policy.md @@ -2,7 +2,7 @@ title: 网络策略 id: network-policy date: 2018-04-12 -full_link: /zh/docs/concepts/services-networking/network-policies/ +full_link: /zh-cn/docs/concepts/services-networking/network-policies/ short_description: > 网络策略是一种规范，规定了允许 Pod 组之间、Pod 与其他网络端点之间以怎样的方式进行通信。 diff --git a/content/zh-cn/docs/reference/glossary/node-pressure-eviction.md b/content/zh-cn/docs/reference/glossary/node-pressure-eviction.md index c5faa5f135..ad2108e9d8 100644 --- a/content/zh-cn/docs/reference/glossary/node-pressure-eviction.md +++ b/content/zh-cn/docs/reference/glossary/node-pressure-eviction.md @@ -2,7 +2,7 @@ title: 节点压力驱逐 id: node-pressure-eviction date: 2021-05-13 -full_link: /zh/docs/concepts/scheduling-eviction/node-pressure-eviction/ +full_link: /zh-cn/docs/concepts/scheduling-eviction/node-pressure-eviction/ short_description: > 节点压力驱逐是 kubelet 主动使 Pod 失败以回收节点上的资源的过程。 aka: diff --git a/content/zh-cn/docs/reference/glossary/node.md b/content/zh-cn/docs/reference/glossary/node.md index d9ac8a9deb..be28602cac 100644 --- a/content/zh-cn/docs/reference/glossary/node.md +++ b/content/zh-cn/docs/reference/glossary/node.md @@ -2,7 +2,7 @@ title: 节点（Node） id: node date: 2018-04-12 -full_link: /zh/docs/concepts/architecture/nodes/ +full_link: /zh-cn/docs/concepts/architecture/nodes/ short_description: > Kubernetes 中的工作机器称作节点。 @@ -15,7 +15,7 @@ tags: title: Node id: node date: 2018-04-12 -full_link: /zh/docs/concepts/architecture/nodes/ +full_link: /zh-cn/docs/concepts/architecture/nodes/ short_description: > A node is a worker machine in Kubernetes. diff --git a/content/zh-cn/docs/reference/glossary/object.md b/content/zh-cn/docs/reference/glossary/object.md index 99576b5665..0a5a07d10a 100644 --- a/content/zh-cn/docs/reference/glossary/object.md +++ b/content/zh-cn/docs/reference/glossary/object.md @@ -2,7 +2,7 @@ title: 对象（Object） id: object date: 2020-10-12 -full_link: /zh/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects +full_link: /zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects/#kubernetes-objects short_description: > Kubernetes 系统中的实体, 代表了集群的部分状态。 aka: diff --git a/content/zh-cn/docs/reference/glossary/operator-pattern.md b/content/zh-cn/docs/reference/glossary/operator-pattern.md index c6da670257..21751ab4ab 100644 --- a/content/zh-cn/docs/reference/glossary/operator-pattern.md +++ b/content/zh-cn/docs/reference/glossary/operator-pattern.md @@ -2,7 +2,7 @@ title: Operator 模式 id: operator-pattern date: 2019-05-21 -full_link: /zh/docs/concepts/extend-kubernetes/operator/ +full_link: /zh-cn/docs/concepts/extend-kubernetes/operator/ short_description: > 一种用于管理自定义资源的专用控制器 @@ -28,7 +28,7 @@ The [operator pattern](/docs/concepts/extend-kubernetes/operator/) is a system design that links a {{< glossary_tooltip term_id="controller" >}} to one or more custom resources. --> -[operator 模式](/zh/docs/concepts/extend-kubernetes/operator/) 是一种系统设计, +[operator 模式](/zh-cn/docs/concepts/extend-kubernetes/operator/) 是一种系统设计, 将 {{< glossary_tooltip term_id="controller" >}} 关联到一个或多个自定义资源。 diff --git a/content/zh-cn/docs/reference/glossary/persistent-volume-claim.md b/content/zh-cn/docs/reference/glossary/persistent-volume-claim.md index f5ab57a3e8..4eb2e49e2b 100644 --- a/content/zh-cn/docs/reference/glossary/persistent-volume-claim.md +++ b/content/zh-cn/docs/reference/glossary/persistent-volume-claim.md @@ -2,7 +2,7 @@ title: 持久卷申领（Persistent Volume Claim） id: persistent-volume-claim date: 2018-04-12 -full_link: /zh/docs/concepts/storage/persistent-volumes/ +full_link: /zh-cn/docs/concepts/storage/persistent-volumes/ short_description: > 声明在持久卷中定义的存储资源，以便可以将其挂载为容器中的卷。 diff --git a/content/zh-cn/docs/reference/glossary/persistent-volume.md b/content/zh-cn/docs/reference/glossary/persistent-volume.md index 671e3a8bf3..8bcd24d6a8 100644 --- a/content/zh-cn/docs/reference/glossary/persistent-volume.md +++ b/content/zh-cn/docs/reference/glossary/persistent-volume.md @@ -2,7 +2,7 @@ title: 持久卷（Persistent Volume） id: persistent-volume date: 2018-04-12 -full_link: /zh/docs/concepts/storage/persistent-volumes/ +full_link: /zh-cn/docs/concepts/storage/persistent-volumes/ short_description: > 持久卷是代表集群中一块存储空间的 API 对象。 它是通用的、可插拔的、并且不受单个 Pod 生命周期约束的持久化资源。 diff --git a/content/zh-cn/docs/reference/glossary/platform-developer.md b/content/zh-cn/docs/reference/glossary/platform-developer.md index 41e8b99995..a03cf67d81 100644 --- a/content/zh-cn/docs/reference/glossary/platform-developer.md +++ b/content/zh-cn/docs/reference/glossary/platform-developer.md @@ -41,8 +41,8 @@ develop extensions which are contributed to the Kubernetes community. Others develop closed-source commercial or site-specific extensions. --> -平台开发人员可以使用[定制资源](/zh/docs/concepts/extend-kubernetes/api-extension/custom-resources/) -或[使用汇聚层扩展 Kubernetes API](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) +平台开发人员可以使用[定制资源](/zh-cn/docs/concepts/extend-kubernetes/api-extension/custom-resources/) +或[使用汇聚层扩展 Kubernetes API](/zh-cn/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) 来为其 Kubernetes 实例增加功能，特别是为其应用程序添加功能。 一些平台开发人员也是 kubernetes {{< glossary_tooltip text="贡献者" term_id="contributor" >}}， 他们会开发贡献给 Kubernetes 社区的扩展。 diff --git a/content/zh-cn/docs/reference/glossary/pod-disruption-budget.md b/content/zh-cn/docs/reference/glossary/pod-disruption-budget.md index 444bec87e3..32077d48cd 100644 --- a/content/zh-cn/docs/reference/glossary/pod-disruption-budget.md +++ b/content/zh-cn/docs/reference/glossary/pod-disruption-budget.md @@ -1,7 +1,7 @@ --- id: pod-disruption-budget title: Pod Disruption Budget -full-link: /zh/docs/concepts/workloads/pods/disruptions/ +full-link: /zh-cn/docs/concepts/workloads/pods/disruptions/ date: 2019-02-12 short_description: > Pod Disruption Budget 是这样一种对象：它保证在主动中断（ voluntary disruptions）时，多实例应用的 {{< glossary_tooltip text="Pod" term_id="pod" >}} 不会少于一定的数量。 @@ -43,7 +43,7 @@ tags: Involuntary disruptions cannot be prevented by PDBs; however they do count against the budget. --> - [Pod 干扰预算（Pod Disruption Budget，PDB）](/zh/docs/concepts/workloads/pods/disruptions/) + [Pod 干扰预算（Pod Disruption Budget，PDB）](/zh-cn/docs/concepts/workloads/pods/disruptions/) 使应用所有者能够为多实例应用创建一个对象，来确保一定数量的具有指定标签的 Pod 在任何时候都不会被主动驱逐。 PDB 无法防止非主动的中断，但是会计入预算（budget）。 diff --git a/content/zh-cn/docs/reference/glossary/pod-disruption.md b/content/zh-cn/docs/reference/glossary/pod-disruption.md index 5ea9d70b10..39b8ce8d83 100644 --- a/content/zh-cn/docs/reference/glossary/pod-disruption.md +++ b/content/zh-cn/docs/reference/glossary/pod-disruption.md @@ -37,7 +37,7 @@ tags: Pods on Nodes are terminated either voluntarily or involuntarily. --> -[pod 干扰](/zh/docs/concepts/workloads/pods/disruptions/) 是指节点上的 pod 被自愿或非自愿终止的过程。 +[pod 干扰](/zh-cn/docs/concepts/workloads/pods/disruptions/) 是指节点上的 pod 被自愿或非自愿终止的过程。 diff --git a/content/zh-cn/docs/reference/glossary/pod-lifecycle.md b/content/zh-cn/docs/reference/glossary/pod-lifecycle.md index d83ca39ad0..8eff328c4d 100644 --- a/content/zh-cn/docs/reference/glossary/pod-lifecycle.md +++ b/content/zh-cn/docs/reference/glossary/pod-lifecycle.md @@ -2,7 +2,7 @@ title: Pod 生命周期 id: pod-lifecycle date: 2019-02-17 -full-link: /zh/docs/concepts/workloads/pods/pod-lifecycle/ +full-link: /zh-cn/docs/concepts/workloads/pods/pod-lifecycle/ related: - pod - container @@ -36,7 +36,7 @@ A high-level summary of what phase the Pod is in within its lifecyle. -[Pod 生命周期](/zh/docs/concepts/workloads/pods/pod-lifecycle/) 是关于 Pod +[Pod 生命周期](/zh-cn/docs/concepts/workloads/pods/pod-lifecycle/) 是关于 Pod 处于哪个阶段的概述。包含了下面5种可能的的阶段: Running、Pending、Succeeded、 Failed、Unknown。关于 Pod 的阶段的更高级描述请查阅 [PodStatus](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podstatus-v1-core) `phase` 字段。 diff --git a/content/zh-cn/docs/reference/glossary/pod-priority.md b/content/zh-cn/docs/reference/glossary/pod-priority.md index d029d0593c..1ddc48e1a8 100644 --- a/content/zh-cn/docs/reference/glossary/pod-priority.md +++ b/content/zh-cn/docs/reference/glossary/pod-priority.md @@ -2,7 +2,7 @@ title: Pod 优先级（Pod Priority） id: pod-priority date: 2019-01-31 -full_link: /zh/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority +full_link: /zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority short_description: > Pod 优先级表示一个 Pod 相对于其他 Pod 的重要性。 @@ -34,7 +34,7 @@ tags: -[Pod 优先级](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority) +[Pod 优先级](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/#pod-priority) 允许用户为 Pod 设置高于或低于其他 Pod 的优先级 -- 这对于生产集群 工作负载而言是一个重要的特性。 diff --git a/content/zh-cn/docs/reference/glossary/pod-security-policy.md b/content/zh-cn/docs/reference/glossary/pod-security-policy.md index f80416fb44..db49173930 100644 --- a/content/zh-cn/docs/reference/glossary/pod-security-policy.md +++ b/content/zh-cn/docs/reference/glossary/pod-security-policy.md @@ -2,7 +2,7 @@ title: Pod 安全策略 id: pod-security-policy date: 2018-04-12 -full_link: /zh/docs/concepts/security/pod-security-policy/ +full_link: /zh-cn/docs/concepts/security/pod-security-policy/ short_description: > 为 Pod 的创建和更新操作启用细粒度的授权。 @@ -47,5 +47,5 @@ Pod 安全策略是集群级别的资源，它控制着 Pod 规约中的安全 PodSecurityPolicy is deprecated as of Kubernetes v1.21, and will be removed in v1.25. We recommend migrating to [Pod Security Admission](/docs/concepts/security/pod-security-admission/), or a 3rd party admission plugin. --> PodSecurityPolicy 自 Kubernetes v1.21 起已弃用，并将在 v1.25 中删除。 -我们建议迁移到 [Pod 安全准入](/zh/docs/concepts/security/pod-security-admission/)或第三方准入插件。 +我们建议迁移到 [Pod 安全准入](/zh-cn/docs/concepts/security/pod-security-admission/)或第三方准入插件。 diff --git a/content/zh-cn/docs/reference/glossary/preemption.md b/content/zh-cn/docs/reference/glossary/preemption.md index 328d0abfac..7875e60d0b 100644 --- a/content/zh-cn/docs/reference/glossary/preemption.md +++ b/content/zh-cn/docs/reference/glossary/preemption.md @@ -2,7 +2,7 @@ title: 抢占（Preemption） id: preemption date: 2019-01-31 -full_link: /zh/docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption +full_link: /zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption short_description: > Kubernetes 中的抢占逻辑通过驱逐节点上的低优先级 Pod 来帮助悬决的 Pod 找到合适的节点。 @@ -37,6 +37,6 @@ Kubernetes 中的抢占逻辑通过驱逐{{< glossary_tooltip term_id="node" >}} If a Pod cannot be scheduled, the scheduler tries to [preempt](/docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption) lower priority Pods to make scheduling of the pending Pod possible. --> 如果一个 Pod 无法调度，调度器会尝试 -[抢占](/zh/docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption) +[抢占](/zh-cn/docs/concepts/scheduling-eviction/pod-priority-preemption/#preemption) 较低优先级的 Pod，以使得悬决的 Pod 有可能被调度。 diff --git a/content/zh-cn/docs/reference/glossary/proxy.md b/content/zh-cn/docs/reference/glossary/proxy.md index c9d4ff0bea..b186dd6065 100644 --- a/content/zh-cn/docs/reference/glossary/proxy.md +++ b/content/zh-cn/docs/reference/glossary/proxy.md @@ -43,7 +43,7 @@ actual server's reply to the client. network proxy that runs on each node in your cluster, implementing part of the Kubernetes {{< glossary_tooltip term_id="service">}} concept. --> -[kube-proxy](/zh/docs/reference/command-line-tools-reference/kube-proxy/) 是集群中每个节点上运行的网络代理，实现了部分 Kubernetes {{< glossary_tooltip term_id="service">}} 概念。 +[kube-proxy](/zh-cn/docs/reference/command-line-tools-reference/kube-proxy/) 是集群中每个节点上运行的网络代理，实现了部分 Kubernetes {{< glossary_tooltip term_id="service">}} 概念。 - - -由第三方提供并维护的一组{{< glossary_tooltip text="托管服务" term_id="managed-service">}}的访问端点。 - - - - - -{{< glossary_tooltip text="服务代理（Service Brokers）" term_id="service-broker">}}会实现 -[开放服务代理 API 规范](https://github.com/openservicebrokerapi/servicebroker/blob/v2.13/spec.md) -并为应用提供使用其托管服务的标准接口。 -[服务目录（Service Catalog）](/zh/docs/concepts/extend-kubernetes/service-catalog/)则提供一种方法，用来列举、供应和绑定服务代理商所提供的托管服务。 diff --git a/content/zh-cn/docs/reference/glossary/service-catalog.md b/content/zh-cn/docs/reference/glossary/service-catalog.md index 134085e034..a50e6e4778 100644 --- a/content/zh-cn/docs/reference/glossary/service-catalog.md +++ b/content/zh-cn/docs/reference/glossary/service-catalog.md @@ -18,7 +18,7 @@ id: service-catalog date: 2018-04-12 full_link: short_description: > - An extension API that enables applications running in Kubernetes clusters to easily use external managed software offerings, such as a datastore service offered by a cloud provider. + A former extension API that enables applications running in Kubernetes clusters to easily use external managed software offerings, such as a datastore service offered by a cloud provider. aka: tags: @@ -28,18 +28,17 @@ tags: -服务目录是一种扩展 API，它能让 Kubernetes 集群中运行的应用易于使用外部托管的的软件服务，例如云供应商提供的数据仓库服务。 +服务目录是一种过去曾经存在的扩展 API，它能让 Kubernetes 集群中运行的应用易于使用外部托管的的软件服务，例如云供应商提供的数据仓库服务。 -服务目录可以检索、供应、和绑定由 {{< glossary_tooltip text="服务代理人（Service Brokers）" term_id="service-broker" >}} -提供的外部{{< glossary_tooltip text="托管服务（Managed Services）" term_id="managed-service" >}}， +服务目录可以检索、供应、和绑定外部{{< glossary_tooltip text="托管服务（Managed Services）" term_id="managed-service" >}}， 而无需知道那些服务具体是怎样创建和托管的。 diff --git a/content/zh-cn/docs/reference/glossary/service.md b/content/zh-cn/docs/reference/glossary/service.md index fb611558b5..7c4a3c58d6 100644 --- a/content/zh-cn/docs/reference/glossary/service.md +++ b/content/zh-cn/docs/reference/glossary/service.md @@ -2,7 +2,7 @@ title: 服务（Service） id: service date: 2018-04-12 -full_link: /zh/docs/concepts/services-networking/service/ +full_link: /zh-cn/docs/concepts/services-networking/service/ short_description: > 将运行在一组 Pods 上的应用程序公开为网络服务的抽象方法。 diff --git a/content/zh-cn/docs/reference/glossary/statefulset.md b/content/zh-cn/docs/reference/glossary/statefulset.md index 6e796d9419..e94318e78a 100644 --- a/content/zh-cn/docs/reference/glossary/statefulset.md +++ b/content/zh-cn/docs/reference/glossary/statefulset.md @@ -2,7 +2,7 @@ title: StatefulSet id: statefulset date: 2018-04-12 -full_link: /zh/docs/concepts/workloads/controllers/statefulset/ +full_link: /zh-cn/docs/concepts/workloads/controllers/statefulset/ short_description: > StatefulSet 用来管理某 Pod 集合的部署和扩缩，并为这些 Pod 提供持久存储和持久标识符。 aka: diff --git a/content/zh-cn/docs/reference/glossary/static-pod.md b/content/zh-cn/docs/reference/glossary/static-pod.md index e785a96a85..fd9103c322 100644 --- a/content/zh-cn/docs/reference/glossary/static-pod.md +++ b/content/zh-cn/docs/reference/glossary/static-pod.md @@ -2,7 +2,7 @@ title: 静态 Pod（Static Pod） id: static-pod date: 2019-02-12 -full_link: /zh/docs/tasks/configure-pod-container/static-pod/ +full_link: /zh-cn/docs/tasks/configure-pod-container/static-pod/ short_description: > 静态Pod（Static Pod）是指由特定节点上的 kubelet 守护进程直接管理的 Pod。 diff --git a/content/zh-cn/docs/reference/glossary/storage-class.md b/content/zh-cn/docs/reference/glossary/storage-class.md index 1ad1834b15..b0fc008df7 100644 --- a/content/zh-cn/docs/reference/glossary/storage-class.md +++ b/content/zh-cn/docs/reference/glossary/storage-class.md @@ -2,7 +2,7 @@ title: StorageClass id: storageclass date: 2018-04-12 -full_link: /zh/docs/concepts/storage/storage-classes/ +full_link: /zh-cn/docs/concepts/storage/storage-classes/ short_description: > StorageClass 是管理员用来描述可用的不同存储类型的一种方法。 diff --git a/content/zh-cn/docs/reference/glossary/sysctl.md b/content/zh-cn/docs/reference/glossary/sysctl.md index b987583df7..1c35bc662b 100644 --- a/content/zh-cn/docs/reference/glossary/sysctl.md +++ b/content/zh-cn/docs/reference/glossary/sysctl.md @@ -2,7 +2,7 @@ title: sysctl id: sysctl date: 2019-02-12 -full_link: /zh/docs/tasks/administer-cluster/sysctl-cluster/ +full_link: /zh-cn/docs/tasks/administer-cluster/sysctl-cluster/ short_description: > 用于获取和设置 Unix 内核参数的接口 diff --git a/content/zh-cn/docs/reference/glossary/taint.md b/content/zh-cn/docs/reference/glossary/taint.md index 8961ce205d..65040d6bbe 100644 --- a/content/zh-cn/docs/reference/glossary/taint.md +++ b/content/zh-cn/docs/reference/glossary/taint.md @@ -2,7 +2,7 @@ title: 污点（Taint） id: taint date: 2019-01-11 -full_link: /zh/docs/concepts/scheduling-eviction/taint-and-toleration/ +full_link: /zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/ short_description: > 污点是一种一个核心对象，包含三个必需的属性：key、value 和 effect。 污点会阻止在节点或节点组上调度 Pod。 diff --git a/content/zh-cn/docs/reference/glossary/toleration.md b/content/zh-cn/docs/reference/glossary/toleration.md index 963d75b94c..d42ff66958 100644 --- a/content/zh-cn/docs/reference/glossary/toleration.md +++ b/content/zh-cn/docs/reference/glossary/toleration.md @@ -2,7 +2,7 @@ title: 容忍度（Toleration） id: toleration date: 2019-01-11 -full_link: /zh/docs/concepts/scheduling-eviction/taint-and-toleration/ +full_link: /zh-cn/docs/concepts/scheduling-eviction/taint-and-toleration/ short_description: > 一个核心对象，由三个必需的属性组成：key、value 和 effect。 容忍度允许将 Pod 调度到具有对应污点的节点或节点组上。 diff --git a/content/zh-cn/docs/reference/glossary/uid.md b/content/zh-cn/docs/reference/glossary/uid.md index 74faf6d1e7..13d5433ac1 100644 --- a/content/zh-cn/docs/reference/glossary/uid.md +++ b/content/zh-cn/docs/reference/glossary/uid.md @@ -2,7 +2,7 @@ title: UID id: uid date: 2018-04-12 -full_link: /zh/docs/concepts/overview/working-with-objects/names/ +full_link: /zh-cn/docs/concepts/overview/working-with-objects/names/ short_description: > 由 Kubernetes 系统生成、用来唯一标识对象的字符串。 diff --git a/content/zh-cn/docs/reference/glossary/volume.md b/content/zh-cn/docs/reference/glossary/volume.md index 7ef39eee2f..9159e275ca 100644 --- a/content/zh-cn/docs/reference/glossary/volume.md +++ b/content/zh-cn/docs/reference/glossary/volume.md @@ -2,7 +2,7 @@ title: 卷（Volume） id: volume date: 2018-04-12 -full_link: /zh/docs/concepts/storage/volumes/ +full_link: /zh-cn/docs/concepts/storage/volumes/ short_description: > 包含可被 Pod 中容器访问的数据的目录。 @@ -47,4 +47,4 @@ A Kubernetes volume lives as long as the Pod that encloses it. Consequently, a v -更多信息可参考[storage](/zh/docs/concepts/storage/) \ No newline at end of file +更多信息可参考[storage](/zh-cn/docs/concepts/storage/) \ No newline at end of file diff --git a/content/zh-cn/docs/reference/glossary/workload.md b/content/zh-cn/docs/reference/glossary/workload.md index 394b42bd1c..68cd860a83 100644 --- a/content/zh-cn/docs/reference/glossary/workload.md +++ b/content/zh-cn/docs/reference/glossary/workload.md @@ -2,7 +2,7 @@ title: 工作负载（Workload） id: workloads date: 2019-02-13 -full_link: /zh/docs/concepts/workloads/ +full_link: /zh-cn/docs/concepts/workloads/ short_description: > 工作负载是在 Kubernetes 上运行的应用程序。 diff --git a/content/zh-cn/docs/reference/issues-security/issues.md b/content/zh-cn/docs/reference/issues-security/issues.md index 0cad3c4329..45a248990c 100644 --- a/content/zh-cn/docs/reference/issues-security/issues.md +++ b/content/zh-cn/docs/reference/issues-security/issues.md @@ -1,7 +1,7 @@ --- title: Kubernetes 问题追踪 weight: 10 -aliases: [/zh/cve/, /zh/cves/] +aliases: [/zh-cn/cve/, /zh-cn/cves/] --- 要报告安全问题，请遵循 -[Kubernetes 安全问题公开流程](/zh/docs/reference/issues-security/security/#report-a-vulnerability)。 +[Kubernetes 安全问题公开流程](/zh-cn/docs/reference/issues-security/security/#report-a-vulnerability)。 `针对配置信息，`kubectl` 在 `$HOME/.kube` 目录中查找一个名为 `config` 的配置文件。 你可以通过设置 `KUBECONFIG` 环境变量或设置 -[`--kubeconfig`](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) -参数来指定其它 [kubeconfig](/zh/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 文件。 +[`--kubeconfig`](/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig/) +参数来指定其它 [kubeconfig](/zh-cn/docs/concepts/configuration/organize-cluster-access-kubeconfig/) 文件。 -有关安装说明，请参见[安装 kubectl](/zh/docs/tasks/tools/#kubectl)； -如需快速指南，请参见[备忘单](/zh/docs/reference/kubectl/cheatsheet/)。 +有关安装说明，请参见[安装 kubectl](/zh-cn/docs/tasks/tools/#kubectl)； +如需快速指南，请参见[备忘单](/zh-cn/docs/reference/kubectl/cheatsheet/)。 如果你更习惯使用 `docker` 命令行工具， -[Docker 用户的 `kubectl`](/zh/docs/reference/kubectl/docker-cli-to-kubectl/) +[Docker 用户的 `kubectl`](/zh-cn/docs/reference/kubectl/docker-cli-to-kubectl/) 介绍了一些 Kubernetes 的等价命令。 @@ -131,7 +131,7 @@ for example `create`, `get`, `describe`, `delete`. * 用一个或多个文件指定资源：`-f file1 -f file2 -f file<#>` - * [使用 YAML 而不是 JSON](/zh/docs/concepts/configuration/overview/#general-configuration-tips)， + * [使用 YAML 而不是 JSON](/zh-cn/docs/concepts/configuration/overview/#general-configuration-tips)， 因为 YAML 对用户更友好, 特别是对于配置文件。
      例子：`kubectl get -f ./pod.yaml` @@ -341,7 +341,7 @@ Operation | Syntax | Description To learn more about command operations, see the [kubectl](/docs/reference/kubectl/kubectl/) reference documentation. --> 了解更多有关命令操作的信息， -请参阅 [kubectl](/zh/docs/reference/kubectl/kubectl/) 参考文档。 +请参阅 [kubectl](/zh-cn/docs/reference/kubectl/kubectl/) 参考文档。 有关如何格式化或排序某些命令的输出的信息，请参阅以下章节。有关哪些命令支持不同输出选项的详细信息， -请参阅 [kubectl](/zh/docs/reference/kubectl/kubectl/) 参考文档。 +请参阅 [kubectl](/zh-cn/docs/reference/kubectl/kubectl/) 参考文档。 请记住：有关每个命令支持哪种输出格式的详细信息， -请参阅 [kubectl](/zh/docs/reference/kubectl/kubectl/) 参考文档。 +请参阅 [kubectl](/zh-cn/docs/reference/kubectl/kubectl/) 参考文档。 要将对象排序后输出到终端窗口，可以将 `--sort-by` 参数添加到支持的 `kubectl` 命令。 通过使用 `--sort-by` 参数指定任何数字或字符串字段来对对象进行排序。 -要指定字段，请使用 [jsonpath](/zh/docs/reference/kubectl/jsonpath/) 表达式。 +要指定字段，请使用 [jsonpath](/zh-cn/docs/reference/kubectl/jsonpath/) 表达式。 * 阅读 `kubectl` 参考文档： - * kubectl [命令参考](/zh/docs/reference/kubectl/kubectl/) + * kubectl [命令参考](/zh-cn/docs/reference/kubectl/kubectl/) * 参考[命令行参数](/docs/reference/generated/kubectl/kubectl-commands/) -* 学习关于 [`kubectl` 使用约定](/zh/docs/reference/kubectl/conventions/) -* 阅读 kubectl 中的 [JSONPath 支持](/zh/docs/reference/kubectl/jsonpath/) -* 了解如何[使用插件扩展 kubectl](/zh/docs/tasks/extend-kubectl/kubectl-plugins) +* 学习关于 [`kubectl` 使用约定](/zh-cn/docs/reference/kubectl/conventions/) +* 阅读 kubectl 中的 [JSONPath 支持](/zh-cn/docs/reference/kubectl/jsonpath/) +* 了解如何[使用插件扩展 kubectl](/zh-cn/docs/tasks/extend-kubectl/kubectl-plugins) * 查看更多[示例 cli 插件](https://github.com/kubernetes/sample-cli-plugin)。 \ No newline at end of file diff --git a/content/zh-cn/docs/reference/kubectl/cheatsheet.md b/content/zh-cn/docs/reference/kubectl/cheatsheet.md index 9ea9111fd3..a20e05c713 100644 --- a/content/zh-cn/docs/reference/kubectl/cheatsheet.md +++ b/content/zh-cn/docs/reference/kubectl/cheatsheet.md @@ -94,7 +94,7 @@ detailed config file information. ## Kubectl 上下文和配置 设置 `kubectl` 与哪个 Kubernetes 集群进行通信并修改配置信息。 -查看[使用 kubeconfig 跨集群授权访问](/zh/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) +查看[使用 kubeconfig 跨集群授权访问](/zh-cn/docs/tasks/access-application-cluster/configure-access-multiple-clusters/) 文档获取配置文件详细信息。 -列出所支持的全部资源类型和它们的简称、[API 组](/zh/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning), 是否是[名字空间作用域](/zh/docs/concepts/overview/working-with-objects/namespaces) 和 [Kind](/zh/docs/concepts/overview/working-with-objects/kubernetes-objects)。 +列出所支持的全部资源类型和它们的简称、[API 组](/zh-cn/docs/concepts/overview/kubernetes-api/#api-groups-and-versioning), 是否是[名字空间作用域](/zh-cn/docs/concepts/overview/working-with-objects/namespaces) 和 [Kind](/zh-cn/docs/concepts/overview/working-with-objects/kubernetes-objects)。 ```bash kubectl api-resources @@ -846,8 +846,8 @@ Output format | Description `-o=custom-columns=` | 使用逗号分隔的自定义列来打印表格 `-o=custom-columns-file=` | 使用 `` 文件中的自定义列模板打印表格 `-o=json` | 输出 JSON 格式的 API 对象 -`-o=jsonpath=
      将 PodSecurityPolicy 注解映射到 Pod 安全性标准