From c231ba5be3357dee8235343bf61fe6438ace4c0b Mon Sep 17 00:00:00 2001 From: "Noah Ispas (iamNoah1)" Date: Tue, 5 Apr 2022 10:15:15 +0200 Subject: [PATCH 01/27] add necessary tools, correct git output example --- .../docs/contribute/generate-ref-docs/contribute-upstream.md | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/content/en/docs/contribute/generate-ref-docs/contribute-upstream.md b/content/en/docs/contribute/generate-ref-docs/contribute-upstream.md index 4abf2de68b..ffce805718 100644 --- a/content/en/docs/contribute/generate-ref-docs/contribute-upstream.md +++ b/content/en/docs/contribute/generate-ref-docs/contribute-upstream.md @@ -27,6 +27,8 @@ API or the `kube-*` components from the upstream code, see the following instruc - [Golang](https://golang.org/doc/install) version 1.13+ - [Docker](https://docs.docker.com/engine/installation/) - [etcd](https://github.com/coreos/etcd/) + - [make](https://www.gnu.org/software/make/) + - [gcc compiler/linker](https://gcc.gnu.org/) - Your `GOPATH` environment variable must be set, and the location of `etcd` must be in your `PATH` environment variable. @@ -142,8 +144,9 @@ Run `git status` to see what was generated. On branch master ... modified: api/openapi-spec/swagger.json + modified: api/openapi-spec/v3/apis__apps__v1_openapi.json + modified: pkg/generated/openapi/zz_generated.openapi.go modified: staging/src/k8s.io/api/apps/v1/generated.proto - modified: staging/src/k8s.io/api/apps/v1/types.go modified: staging/src/k8s.io/api/apps/v1/types_swagger_doc_generated.go ``` From 63e7cf796b7b27cd47218238158f9ff50409380e Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Fri, 1 Apr 2022 21:14:56 +0800 Subject: [PATCH 02/27] [zh] Fix cassandra tutorial translation --- .../stateful-application/cassandra.md | 209 +++++++++--------- 1 file changed, 107 insertions(+), 102 deletions(-) diff --git a/content/zh/docs/tutorials/stateful-application/cassandra.md b/content/zh/docs/tutorials/stateful-application/cassandra.md index 461b050938..ea55fd4a24 100644 --- a/content/zh/docs/tutorials/stateful-application/cassandra.md +++ b/content/zh/docs/tutorials/stateful-application/cassandra.md @@ -19,18 +19,20 @@ Cassandra, a database, needs persistent storage to provide data durability (appl In this example, a custom Cassandra seed provider lets the database discover new Cassandra instances as they join the Cassandra cluster. --> 本教程描述拉如何在 Kubernetes 上运行 [Apache Cassandra](https://cassandra.apache.org/)。 -数据库 Cassandra 需要永久性存储提供数据持久性（应用 _状态_）。 -在此示例中，自定义 Cassandra seed provider 使数据库在加入 Cassandra 集群时发现新的 Cassandra 实例。 +数据库 Cassandra 需要永久性存储提供数据持久性（应用“状态”）。 +在此示例中，自定义 Cassandra seed provider 使数据库在加入 Cassandra +集群时发现新的 Cassandra 实例。 -使用 *StatefulSets* 可以更轻松地将有状态的应用程序部署到你的 Kubernetes 集群中。 +使用"StatefulSets"可以更轻松地将有状态的应用程序部署到你的 Kubernetes 集群中。 有关本教程中使用的功能的更多信息， 参阅 [StatefulSet](/zh/docs/concepts/workloads/controllers/statefulset/)。 +{{< note >}} -{{< note >}} -Cassandra 和 Kubernetes 都使用术语 _node_ 来表示集群的成员。 -在本教程中，属于 StatefulSet 的 Pod 是 Cassandra 节点，并且是 Cassandra 集群的成员（称为 _ring_）。 +Cassandra 和 Kubernetes 都使用术语“节点（node）”来表示集群的成员。 +在本教程中，属于 StatefulSet 的 Pod 是 Cassandra 节点，并且是 Cassandra 集群的成员（称为 “ring”）。 当这些 Pod 在你的 Kubernetes 集群中运行时，Kubernetes 控制平面会将这些 Pod 调度到 Kubernetes 的 {{< glossary_tooltip text="节点" term_id="node" >}}上。 @@ -51,7 +52,8 @@ This tutorial deploys a custom Cassandra seed provider that lets the database di new Cassandra Pods as they appear inside your Kubernetes cluster. --> 当 Cassandra 节点启动时，使用 _seed列表_ 来引导发现 ring 中其他节点。 -本教程部署了一个自定义的 Cassandra seed provider，使数据库可以发现新的 Cassandra Pod 出现在 Kubernetes 集群中。 +本教程部署了一个自定义的 Cassandra seed provider，使数据库可以发现新的 Cassandra Pod +出现在 Kubernetes 集群中。 {{< /note >}} ## {{% heading "objectives" %}} @@ -69,7 +71,6 @@ new Cassandra Pods as they appear inside your Kubernetes cluster. * 修改 StatefulSet。 * 删除 StatefulSet 及其 {{< glossary_tooltip text="Pod" term_id="pod" >}}. - ## {{% heading "prerequisites" %}} {{< include "task-tutorial-prereqs.md" >}} @@ -81,7 +82,8 @@ To complete this tutorial, you should already have a basic familiarity with {{< glossary_tooltip text="StatefulSets" term_id="StatefulSet" >}}. --> 要完成本教程，你应该已经熟悉 {{< glossary_tooltip text="Pod" term_id="pod" >}}， -{{< glossary_tooltip text="Service" term_id="service" >}}和 {{< glossary_tooltip text="StatefulSet" term_id="StatefulSet" >}}。 +{{< glossary_tooltip text="Service" term_id="service" >}} 和 +{{< glossary_tooltip text="StatefulSet" term_id="StatefulSet" >}}。 如果没有看到名为 `cassandra` 的服务，则表示创建失败。 -请阅读[Debug Services](/zh/docs/tasks/debug-application-cluster/debug-service/)，以解决常见问题。 +请阅读[调试服务](/zh/docs/tasks/debug-application-cluster/debug-service/)，以解决常见问题。 ## 验证 Cassandra StatefulSet -1.获取 Cassandra StatefulSet: +1. 获取 Cassandra StatefulSet: - ```shell - kubectl get statefulset cassandra - ``` + ```shell + kubectl get statefulset cassandra + ``` - + --> 响应应该与此类似： - ``` - NAME DESIRED CURRENT AGE - cassandra 3 0 13s - ``` + ``` + NAME DESIRED CURRENT AGE + cassandra 3 0 13s + ``` - + --> `StatefulSet` 资源会按顺序部署 Pod。 -2.获取 Pod 查看已排序的创建状态： - - ```shell - kubectl get pods -l="app=cassandra" - ``` - +2. 获取 Pod 查看已排序的创建状态： + + ```shell + kubectl get pods -l="app=cassandra" + ``` + + 响应应该与此类似： - ```shell - NAME READY STATUS RESTARTS AGE - cassandra-0 1/1 Running 0 1m - cassandra-1 0/1 ContainerCreating 0 8s - ``` + ``` + NAME READY STATUS RESTARTS AGE + cassandra-0 1/1 Running 0 1m + cassandra-1 0/1 ContainerCreating 0 8s + ``` - + --> 这三个 Pod 要花几分钟的时间才能部署。部署之后，相同的命令将返回类似于以下的输出： - ``` - NAME READY STATUS RESTARTS AGE - cassandra-0 1/1 Running 0 10m - cassandra-1 1/1 Running 0 9m - cassandra-2 1/1 Running 0 8m - ``` + ``` + NAME READY STATUS RESTARTS AGE + cassandra-0 1/1 Running 0 10m + cassandra-1 1/1 Running 0 9m + cassandra-2 1/1 Running 0 8m + ``` -3.运行第一个 Pod 中的 Cassandra [nodetool](https://cwiki.apache.org/confluence/display/CASSANDRA2/NodeTool)，以显示 ring 的状态。 +3. 运行第一个 Pod 中的 Cassandra [nodetool](https://cwiki.apache.org/confluence/display/CASSANDRA2/NodeTool)， + 以显示 ring 的状态。 - ```shell - kubectl exec -it cassandra-0 -- nodetool status - ``` + ```shell + kubectl exec -it cassandra-0 -- nodetool status + ``` - + --> 响应应该与此类似： - ``` - Datacenter: DC1-K8Demo - ====================== - Status=Up/Down - |/ State=Normal/Leaving/Joining/Moving - -- Address Load Tokens Owns (effective) Host ID Rack - UN 172.17.0.5 83.57 KiB 32 74.0% e2dd09e6-d9d3-477e-96c5-45094c08db0f Rack1-K8Demo - UN 172.17.0.4 101.04 KiB 32 58.8% f89d6835-3a42-4419-92b3-0e62cae1479c Rack1-K8Demo - UN 172.17.0.6 84.74 KiB 32 67.1% a6a1e8c2-3dc5-4417-b1a0-26507af2aaad Rack1-K8Demo - ``` + ``` + Datacenter: DC1-K8Demo + ====================== + Status=Up/Down + |/ State=Normal/Leaving/Joining/Moving + -- Address Load Tokens Owns (effective) Host ID Rack + UN 172.17.0.5 83.57 KiB 32 74.0% e2dd09e6-d9d3-477e-96c5-45094c08db0f Rack1-K8Demo + UN 172.17.0.4 101.04 KiB 32 58.8% f89d6835-3a42-4419-92b3-0e62cae1479c Rack1-K8Demo + UN 172.17.0.6 84.74 KiB 32 67.1% a6a1e8c2-3dc5-4417-b1a0-26507af2aaad Rack1-K8Demo + ``` + --> 此命令你的终端中打开一个编辑器。需要更改的是 `replicas` 字段。下面是 StatefulSet 文件的片段示例： ```yaml @@ -340,65 +344,65 @@ Use `kubectl edit` to modify the size of a Cassandra StatefulSet. 1. Get the Cassandra StatefulSet to verify your change: --> -2.将副本数 (replicas) 更改为 4，然后保存清单。 +2. 将副本数（replicas）更改为 4，然后保存清单。 StatefulSet 现在可以扩展到运行 4 个 Pod。 -3.获取 Cassandra StatefulSet 验证更改： +3. 获取 Cassandra StatefulSet 验证更改： - ```shell - kubectl get statefulset cassandra - ``` + ```shell + kubectl get statefulset cassandra + ``` - + --> 响应应该与此类似： - ``` - NAME DESIRED CURRENT AGE - cassandra 4 4 36m - ``` + ``` + NAME DESIRED CURRENT AGE + cassandra 4 4 36m + ``` ## {{% heading "cleanup" %}} 删除或缩小 StatefulSet 不会删除与 StatefulSet 关联的卷。 这个设置是出于安全考虑，因为你的数据比自动清除所有相关的 StatefulSet 资源更有价值。 {{< warning >}} + 根据存储类和回收策略，删除 *PersistentVolumeClaims* 可能导致关联的卷也被删除。 千万不要认为其容量声明被删除，你就能访问数据。 {{< /warning >}} -1.运行以下命令（连在一起成为一个单独的命令）删除 Cassandra StatefulSet 中的所有内容： + +1. 运行以下命令（连在一起成为一个单独的命令）删除 Cassandra StatefulSet 中的所有内容： - ```shell - grace=$(kubectl get pod cassandra-0 -o=jsonpath='{.spec.terminationGracePeriodSeconds}') \ - && kubectl delete statefulset -l app=cassandra \ - && echo "Sleeping ${grace} seconds" 1>&2 \ - && sleep $grace \ - && kubectl delete persistentvolumeclaim -l app=cassandra - ``` + ```shell + grace=$(kubectl get pod cassandra-0 -o=jsonpath='{.spec.terminationGracePeriodSeconds}') \ + && kubectl delete statefulset -l app=cassandra \ + && echo "Sleeping ${grace} seconds" 1>&2 \ + && sleep $grace \ + && kubectl delete persistentvolumeclaim -l app=cassandra + ``` -2.运行以下命令，删除你为 Cassandra 设置的 Service： +2. 运行以下命令，删除你为 Cassandra 设置的 Service： - ```shell - kubectl delete service -l app=cassandra - ``` + ```shell + kubectl delete service -l app=cassandra + ``` ## Cassandra 容器环境变量 -本教程中的 Pod 使用来自 Google [container registry](https://cloud.google.com/container-registry/docs/) -的 [`gcr.io/google-samples/cassandra:v13`](https://github.com/kubernetes/examples/blob/master/cassandra/image/Dockerfile) 镜像。 -上面的 Docker 镜像基于 [debian-base](https://github.com/kubernetes/release/tree/master/images/build/debian-base)，并且包含 OpenJDK 8。 + +本教程中的 Pod 使用来自 Google [容器镜像库](https://cloud.google.com/container-registry/docs/) +的 [`gcr.io/google-samples/cassandra:v13`](https://github.com/kubernetes/examples/blob/master/cassandra/image/Dockerfile) +镜像。上面的 Docker 镜像基于 [debian-base](https://github.com/kubernetes/release/tree/master/images/build/debian-base)， +并且包含 OpenJDK 8。 该映像包括来自 Apache Debian 存储库的标准 Cassandra 安装。 通过使用环境变量，您可以更改插入到 `cassandra.yaml` 中的值。 -| Environment variable | Default value | +| 环境变量 | 默认值 | | ------------------------ |:---------------: | | `CASSANDRA_CLUSTER_NAME` | `'Test Cluster'` | | `CASSANDRA_NUM_TOKENS` | `32` | | `CASSANDRA_RPC_ADDRESS` | `0.0.0.0` | - - ## {{% heading "whatsnext" %}} +{{< note >}} +To reconfigure a cluster that has already been created see +[Reconfiguring a kubeadm cluster](/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure). +{{< /note >}} -{{< feature-state for_k8s_version="v1.12" state="stable" >}} + ## Customizing the control plane with flags in `ClusterConfiguration` 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 8349b4a817..1dcc375eef 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 @@ -162,6 +162,9 @@ To customize control plane components, including optional IPv6 assignment to liv for control plane components and etcd server, provide extra arguments to each component as documented in [custom arguments](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/). +To reconfigure a cluster that has already been created see +[Reconfiguring a kubeadm cluster](/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure). + To run `kubeadm init` again, you must first [tear down the cluster](#tear-down). If you join a node with a different architecture to your cluster, make sure that your deployed DaemonSets diff --git a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure.md b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure.md new file mode 100644 index 0000000000..6c63600266 --- /dev/null +++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure.md @@ -0,0 +1,281 @@ +--- +reviewers: +- sig-cluster-lifecycle +title: Reconfiguring a kubeadm cluster +content_type: task +weight: 10 +--- + + + +kubeadm does not support automated ways of reconfiguring components that +were deployed on managed nodes. One way of automating this would be +by using a custom [operator](/docs/concepts/extend-kubernetes/operator/). + +To modify the components configuration you must manually edit associated cluster +objects and files on disk. + +This guide shows the correct sequence of steps that need to be performed +to achieve kubeadm cluster reconfiguration. + +## {{% heading "prerequisites" %}} + +- You need a cluster that was deployed using kubeadm +- Have administrator credentials (`/etc/kubernetes/admin.conf`) and network connectivity +to a running kube-apiserver in the cluster from a host that has kubectl installed +- Have a text editor installed on all hosts + + + +## Reconfiguring the cluster + +kubeadm writes a set of cluster wide component configuration options in +ConfigMaps and other objects. These objects must be manually edited. The command `kubectl edit` +can be used for that. + +The `kubectl edit` command will open a text editor where you can edit and save the object directly. + +You can use the environment variables `KUBECONFIG` and `KUBE_EDITOR` to specify the location of +the kubectl consumed kubeconfig file and preferred text editor. + +For example: +``` +KUBECONFIG=/etc/kubernetes/admin.conf KUBE_EDITOR=nano kubectl edit +``` + +{{< note >}} +Upon saving any changes to these cluster objects, components running on nodes may not be +automatically updated. The steps below instruct you on how to perform that manually. +{{< /note >}} + +{{< warning >}} +Component configuration in ConfigMaps is stored as unstructured data (YAML string). +This means that validation will not be performed upon updating the contents of a ConfigMap. +You have to be careful to follow the documented API format for a particular +component configuration and avoid introducing typos and YAML indentation mistakes. +{{< /warning >}} + +### Applying cluster configuration changes + +#### Updating the `ClusterConfiguration` + +During cluster creation and upgrade, kubeadm writes its +[`ClusterConfiguration`](/docs/reference/config-api/kubeadm-config.v1beta3/) +in a ConfigMap called `kubeadm-config` in the `kube-system` namespace. + +To change a particular option in the `ClusterConfiguration` you can edit the ConfigMap with this command: + +```shell +kubectl edit cm -n kube-system kubeadm-config +``` + +The configuration is located under the `data.ClusterConfiguration` key. + +{{< note >}} +The `ClusterConfiguration` includes a variety of options that affect the configuration of individual +components such as kube-apiserver, kube-scheduler, kube-controller-manager, CoreDNS, etcd and kube-proxy. +Changes to the configuration must be reflected on node components manually. +{{< /note >}} + +#### Reflecting `ClusterConfiguration` changes on control plane nodes + +kubeadm manages the control plane components as static Pod manifests located in +the directory `/etc/kubernetes/manifests`. +Any changes to the `ClusterConfiguration` under the `apiServer`, `controllerManager`, `scheduler` or `etcd` +keys must be reflected in the associated files in the manifests directory on a control plane node. + +Such changes may include: +- `extraArgs` - requires updating the list of flags passed to a component container +- `extraMounts` - requires updated the volume mounts for a component container +- `*SANs` - requires writing new certificates with updated Subject Alternative Names. + +Before proceeding with these changes, make sure you have backed up the directory `/etc/kubernetes/`. + +To write new certificates you can use: +```shell +kubeadm init phase certs --config +``` + +To write new manifest files in `/etc/kubernetes/manifests` you can use: + +```shell +kubeadm init phase control-plane --config +``` + +The `` contents must match the updated `ClusterConfiguration`. +The `` value must be the name of the component. + +{{< note >}} +Updating a file in `/etc/kubernetes/manifests` will tell the kubelet to restart the static Pod for the corresponding component. +Try doing these changes one node at a time to leave the cluster without downtime. +{{< /note >}} + +### Applying kubelet configuration changes + +#### Updating the `KubeletConfiguration` + +During cluster creation and upgrade, kubeadm writes its +[`KubeletConfiguration`](/docs/reference/config-api/kubelet-config.v1beta1/) +in a ConfigMap called `kubelet-config` in the `kube-system` namespace. + +You can edit the ConfigMap with this command: + +```shell +kubectl edit cm -n kube-system kubelet-config +``` + +The configuration is located under the `data.kubelet` key. + +#### Reflecting the kubelet changes + +To reflect the change on kubeadm nodes you must do the following: +- Log in to a kubeadm node +- Run `kubeadm upgrade node phase kubelet-config` to download the latest `kubelet-config` +ConfigMap contents into the local file `/var/lib/kubelet/config.conf` +- Edit the file `/var/lib/kubelet/kubeadm-flags.env` to apply additional configuration with +flags +- Restart the kubelet service with `systemctl restart kubelet` + +{{< note >}} +Do these changes one node at a time to allow workloads to be rescheduled properly. +{{< /note >}} + +{{< note >}} +During `kubeadm upgrade`, kubeadm downloads the `KubeletConfiguration` from the +`kubelet-config` ConfigMap and overwrite the contents of `/var/lib/kubelet/config.conf`. +This means that node local configuration must be applied either by flags in +`/var/lib/kubelet/kubeadm-flags.env` or by manually updating the contents of +`/var/lib/kubelet/config.conf` after `kubeadm upgrade`, and then restarting the kubelet. +{{< /note >}} + +### Applying kube-proxy configuration changes + +#### Updating the `KubeProxyConfiguration` + +During cluster creation and upgrade, kubeadm writes its +[`KubeProxyConfiguration`](/docs/reference/config-api/kube-proxy-config.v1alpha1/) +in a ConfigMap in the `kube-system` namespace called `kube-proxy`. + +This ConfigMap is used by the `kube-proxy` DaemonSet in the `kube-system` namespace. + +To change a particular option in the `KubeProxyConfiguration`, you can edit the ConfigMap with this command: + +```shell +kubectl edit cm -n kube-system kube-proxy +``` + +The configuration is located under the `data.config.conf` key. + +#### Reflecting the kube-proxy changes + +Once the `kube-proxy` ConfigMap is updated, you can restart all kube-proxy Pods: + +Obtain the Pod names: + +```shell +kubectl get po -n kube-system | grep kube-proxy +``` + +Delete a Pod with: + +```shell +kubectl delete po -n kube-system +``` + +New Pods that use the updated ConfigMap will be created. + +{{< note >}} +Because kubeadm deploys kube-proxy as a DaemonSet, node specific configuration is unsupported. +{{< /note >}} + +### Applying CoreDNS configuration changes + +#### Updating the CoreDNS Deployment and Service + +kubeadm deploys CoreDNS as a Deployment called `coredns` and with a Service `kube-dns`, +both in the `kube-system` namespace. + +To update any of the CoreDNS settings, you can edit the Deployment and +Service objects: + +```shell +kubectl edit deployment -n kube-system coredns +kubectl edit service -n kube-system kube-dns +``` + +#### Reflecting the CoreDNS changes + +Once the CoreDNS changes are applied you can delete the CoreDNS Pods: + +Obtain the Pod names: + +```shell +kubectl get po -n kube-system | grep coredns +``` + +Delete a Pod with: + +```shell +kubectl delete po -n kube-system +``` + +New Pods with the updated CoreDNS configuration will be created. + +{{< note >}} +kubeadm does not allow CoreDNS configuration during cluster creation and upgrade. +This means that if you execute `kubeadm upgrade apply`, your changes to the CoreDNS +objects will be lost and must be reapplied. +{{< /note >}} + +## Persisting the reconfiguration + +During the execution of `kubeadm upgrade` on a managed node, kubeadm might overwrite configuration +that was applied after the cluster was created (reconfiguration). + +### Persisting Node object reconfiguration + +kubeadm writes Labels, Taints, CRI socket and other information on the Node object for a particular +Kubernetes node. To change any of the contents of this Node object you can use: + +```shell +kubectl edit no +``` + +During `kubeadm upgrade` the contents of such a Node might get overwritten. +If you would like to persist your modifications to the Node object after upgrade, +you can prepare a [kubectl patch](/docs/tasks/manage-kubernetes-objects/update-api-object-kubectl-patch/) +and apply it to the Node object: + +```shell +kubectl patch no --patch-file +``` + +#### Persisting control plane component reconfiguration + +The main source of control plane configuration is the `ClusterConfiguration` +object stored in the cluster. To extend the static Pod manifests configuration, +[patches](/docs/setup/production-environment/tools/kubeadm/control-plane-flags/#patches) can be used. + +These patch files must remain as files on the control plane nodes to ensure that +they can be used by the `kubeadm upgrade ... --patches `. + +If reconfiguration is done to the `ClusterConfiguration` and static Pod manifests on disk, +the set of node specific patches must be updated accordingly. + +#### Persisting kubelet reconfiguration + +Any changes to the `KubeletConfiguration` stored in `/var/lib/kubelet/config.conf` will be overwritten on +`kubeadm upgrade` by downloading the contents of the cluster wide `kubelet-config` ConfigMap. +To persist kubelet node specific configuration either the file `/var/lib/kubelet/config.conf` +has to be updated manually post-upgrade or the file `/var/lib/kubelet/kubeadm-flags.env` can include flags. +The kubelet flags override the associated `KubeletConfiguration` options, but note that +some of the flags are deprecated. + +A kubelet restart will be required after changing `/var/lib/kubelet/config.conf` or +`/var/lib/kubelet/kubeadm-flags.env`. + +{{% heading "whatsnext" %}} + +- [Upgrading kubeadm clusters](/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade) +- [Customizing components with the kubeadm API](/docs/setup/production-environment/tools/kubeadm/control-plane-flags) +- [Certificate management with kubeadm](/docs/tasks/administer-cluster/kubeadm/kubeadm-certs) 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 ec24fca8e8..36e5a1a00c 100644 --- a/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md +++ b/content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md @@ -43,7 +43,12 @@ first drain the node (or nodes) that you are upgrading. In the case of control p they could be running CoreDNS Pods or other critical workloads. For more information see [Draining nodes](/docs/tasks/administer-cluster/safely-drain-node/). - All containers are restarted after upgrade, because the container spec hash value is changed. -- To verify that the kubelet service has successfully restarted after the kubelet has been upgraded, you can execute `systemctl status kubelet` or view the service logs with `journalctl -xeu kubelet`. +- To verify that the kubelet service has successfully restarted after the kubelet has been upgraded, +you can execute `systemctl status kubelet` or view the service logs with `journalctl -xeu kubelet`. +- Usage of the `--config` flag of `kubeadm upgrade` with +[kubeadm configuration API types](/docs/reference/config-api/kubeadm-config.v1beta3) +with the purpose of reconfiguring the cluster is not recommended and can have unexpected results. Follow the steps in +[Reconfiguring a kubeadm cluster](/docs/tasks/administer-cluster/kubeadm/kubeadm-reconfigure) instead. From 6b25f92384c2f58629dcaa120444ad8dd7d05f82 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Fri, 8 Apr 2022 10:49:23 +0800 Subject: [PATCH 06/27] [zh] Rersync securing a cluster This PR also fixes an English link in the admission controllers page, which doesn't deserve a separate PR. --- .../admission-controllers.md | 2 +- .../administer-cluster/securing-a-cluster.md | 52 ++++++++++++++----- 2 files changed, 40 insertions(+), 14 deletions(-) diff --git a/content/zh/docs/reference/access-authn-authz/admission-controllers.md b/content/zh/docs/reference/access-authn-authz/admission-controllers.md index f6582e86e1..46c9d862f4 100644 --- a/content/zh/docs/reference/access-authn-authz/admission-controllers.md +++ b/content/zh/docs/reference/access-authn-authz/admission-controllers.md @@ -1333,7 +1333,7 @@ This admission controller will deny any Pod that attempts to set certain escalat fields, as shown in the [Configure a Security Context for a Pod or Container](/docs/tasks/configure-pod-container/security-context/) task. -If you don't use [Pod Security admission]((/docs/concepts/security/pod-security-admission/), +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. diff --git a/content/zh/docs/tasks/administer-cluster/securing-a-cluster.md b/content/zh/docs/tasks/administer-cluster/securing-a-cluster.md index ffc364d3ea..397c3d40a6 100644 --- a/content/zh/docs/tasks/administer-cluster/securing-a-cluster.md +++ b/content/zh/docs/tasks/administer-cluster/securing-a-cluster.md @@ -1,5 +1,5 @@ --- -title: 保护集群安全 +title: 保护集群 content_type: task --- 与身份验证一样，简单而广泛的角色可能适合于较小的集群，但是随着更多的用户与集群交互， -可能需要将团队划分到有更多角色限制的、单独的名字空间中去。 +可能需要将团队划分到有更多角色限制的、 +单独的{{< glossary_tooltip text="名字空间" term_id="namespace" >}}中去。 ### 控制容器运行的特权 Pod 定义包含了一个[安全上下文](/zh/docs/tasks/configure-pod-container/security-context/)， 用于描述一些访问请求，如以某个节点上的特定 Linux 用户（如 root）身份运行， 以特权形式运行，访问主机网络，以及一些在宿主节点上不受约束地运行的其它控制权限等等。 -[Pod 安全策略](/zh/docs/concepts/policy/pod-security-policy/) -可以限制哪些用户或服务帐户可以提供危险的安全上下文设置。 -例如，Pod 的安全策略可以限制卷挂载，尤其是 `hostpath`，这些都是 Pod 应该被控制的一些方面。 + +你可以配置 [Pod 安全准入](/zh/docs/concepts/security/pod-security-admission/)来在某个 +{{< glossary_tooltip text="名字空间" term_id="namespace" >}}中 +强制实施特定的 +[Pod 安全标准（Pod Security Standard）](/zh/docs/concepts/security/pod-security-standards/)， +或者检查安全上的缺陷。 一般来说，大多数应用程序需要对主机资源的有限制的访问， 这样它们可以在不访问主机信息的情况下，成功地以 root 账号（UID 0）运行。 但是，考虑到与 root 用户相关的特权，在编写应用程序容器时，你应该使用非 root 用户运行。 -类似地，希望阻止客户端应用程序从其容器中逃逸的管理员，应该使用限制性较强的 Pod 安全策略。 +类似地，希望阻止客户端应用程序从其容器中逃逸的管理员，应该应用 **Baseline** +或 **Restricted** Pod 安全标准。 ### 在启用第三方集成之前，请先审查它们 @@ -400,9 +408,27 @@ or run with elevated permissions if those service accounts are granted access to 如果执行 Pod 创建操作的组件能够在 `kube-system` 这类名字空间中创建 Pod， 则这类组件也可能获得意外的权限，因为这些 Pod 可以访问服务账户的 Secret， -或者，如果对应服务帐户被授权访问宽松的 [Pod 安全策略](/zh/docs/concepts/policy/pod-security-policy/)， +或者，如果对应服务帐户被授权访问宽松的 +[PodSecurityPolicy](/zh/docs/concepts/policy/pod-security-policy/)， 它们就能以较高的权限运行。 + +如果你使用 [Pod 安全准入](/zh/docs/concepts/security/pod-security-admission/)， +并且允许任何组件在一个允许执行特权 Pod 的名字空间中创建 Pod，这些 Pod +就可能从所在的容器中逃逸，利用被拓宽的访问权限来实现特权提升。 + + +你不应该允许不可信的组件在任何系统名字空间（名字以 `kube-` 开头）中创建 Pod， +也不允许它们在访问权限授权可被利用来提升特权的名字空间中创建 Pod。 + +`languageName` 的值将列在语言选择栏中。 +将 `languageName` 赋值为“本地脚本中的语言名称（拉丁脚本中的语言名称）”。 +例如，`languageName = "한국어 (Korean)"`。 +`languageNameLatinScript` 可用于访问拉丁脚本中的语言名称并在主题中使用。 +将 `languageNameLatinScript` 赋值为“拉丁脚本中的语言名称”。 +例如，`languageNameLatinScript ="Korean"`。 + -在你完成到 RBAC 的迁移后，应该调整集群的访问控制，确保相关的策略满足你的 -信息安全需求。 +在你完成到 RBAC 的迁移后，应该调整集群的访问控制，确保相关的策略满足你的信息安全需求。 From b3e75c52a60cbd38ec8efc461101b9bc5787894b Mon Sep 17 00:00:00 2001 From: Sarang Joshi Date: Fri, 8 Apr 2022 15:19:53 +0530 Subject: [PATCH 13/27] Nit: grammar fix on install-kubectl-linux.md --- content/en/docs/tasks/tools/install-kubectl-linux.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/tools/install-kubectl-linux.md b/content/en/docs/tasks/tools/install-kubectl-linux.md index cf2386dfc7..6595fb1588 100644 --- a/content/en/docs/tasks/tools/install-kubectl-linux.md +++ b/content/en/docs/tasks/tools/install-kubectl-linux.md @@ -152,7 +152,7 @@ sudo yum install -y kubectl {{< tabs name="other_kubectl_install" >}} {{% tab name="Snap" %}} -If you are on Ubuntu or another Linux distribution that support [snap](https://snapcraft.io/docs/core/install) package manager, kubectl is available as a [snap](https://snapcraft.io/) application. +If you are on Ubuntu or another Linux distribution that supports the [snap](https://snapcraft.io/docs/core/install) package manager, kubectl is available as a [snap](https://snapcraft.io/) application. ```shell snap install kubectl --classic From 85ad3461af27e312c0d77265b2ae42b34bb9e50e Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?=E9=98=BF=E6=9D=B0=E9=B2=81?= Date: Sat, 2 Apr 2022 17:28:16 +0800 Subject: [PATCH 14/27] docs: Resync network-policies.md --- .../services-networking/network-policies.md | 92 +++++++++++-------- 1 file changed, 54 insertions(+), 38 deletions(-) diff --git a/content/zh/docs/concepts/services-networking/network-policies.md b/content/zh/docs/concepts/services-networking/network-policies.md index fe52d20dce..c49c4b99f1 100644 --- a/content/zh/docs/concepts/services-networking/network-policies.md +++ b/content/zh/docs/concepts/services-networking/network-policies.md @@ -4,7 +4,7 @@ content_type: concept weight: 50 --- - -在定义基于 Pod 或名字空间的 NetworkPolicy 时，你会使用 +在定义基于 Pod 或名字空间的 NetworkPolicy 时，你会使用 {{< glossary_tooltip text="选择算符" term_id="selector">}} 来设定哪些流量 可以进入或离开与该算符匹配的 Pod。 @@ -62,33 +62,50 @@ Network policies are implemented by the [network plugin](/docs/concepts/extend-k 创建一个 NetworkPolicy 资源对象而没有控制器来使它生效的话，是没有任何作用的。 -## 隔离和非隔离的 Pod {#isolated-and-non-isolated-pods} -默认情况下，Pod 是非隔离的，它们接受任何来源的流量。 +## Pod 隔离的两种类型 -Pod 在被某 NetworkPolicy 选中时进入被隔离状态。 -一旦名字空间中有 NetworkPolicy 选择了特定的 Pod，该 Pod 会拒绝该 NetworkPolicy -所不允许的连接。 -（名字空间下其他未被 NetworkPolicy 所选择的 Pod 会继续接受所有的流量） +Pod 有两种隔离: 出口的隔离和入口的隔离。它们涉及到可以建立哪些连接。 +这里的“隔离”不是绝对的，而是意味着“有一些限制”。 +另外的，“非隔离方向”意味着在所述方向上没有限制。这两种隔离（或不隔离）是独立声明的， +并且都与从一个 Pod 到另一个 Pod 的连接有关。 -网络策略不会冲突，它们是累积的。 -如果任何一个或多个策略选择了一个 Pod, 则该 Pod 受限于这些策略的 -入站（Ingress）/出站（Egress）规则的并集。因此评估的顺序并不会影响策略的结果。 + -为了允许两个 Pods 之间的网络数据流，源端 Pod 上的出站（Egress）规则和 -目标端 Pod 上的入站（Ingress）规则都需要允许该流量。 -如果源端的出站（Egress）规则或目标端的入站（Ingress）规则拒绝该流量， -则流量将被拒绝。 +默认情况下，一个 Pod 的出口是非隔离的，即所有外向连接都是被允许的。如果有任何的 NetworkPolicy +选择该 Pod 并在其 `policyTypes` 中包含 “Egress”，则该 Pod 是出口隔离的， +我们称这样的策略适用于该 Pod 的出口。当一个 Pod 的出口被隔离时， +唯一允许的来自 Pod 的连接是适用于出口的 Pod 的某个 NetworkPolicy 的 `egress` 列表所允许的连接。 +这些 `egress` 列表的效果是相加的。 + + + +默认情况下，一个 Pod 对入口是非隔离的，即所有入站连接都是被允许的。如果有任何的 NetworkPolicy +选择该 Pod 并在其 `policyTypes` 中包含 “Ingress”，则该 Pod 被隔离入口， +我们称这种策略适用于该 Pod 的入口。 当一个 Pod 的入口被隔离时，唯一允许进入该 Pod +的连接是来自该 Pod 节点的连接和适用于入口的 Pod 的某个 NetworkPolicy 的 `ingress` +列表所允许的连接。这些 `ingress` 列表的效果是相加的。 + + + +网络策略是相加的，所以不会产生冲突。如果策略适用于 Pod 某一特定方向的流量， +Pod 在对应方向所允许的连接是适用的网络策略所允许的集合。 +因此，评估的顺序不影响策略的结果。 + +要允许从源 Pod 到目的 Pod 的连接，源 Pod 的出口策略和目的 Pod 的入口策略都需要允许连接。 +如果任何一方不允许连接，建立连接将会失败。 {{< note >}} @@ -262,7 +279,7 @@ __namespaceSelector__ *和* __podSelector__： 一个指定 `namespaceSelector` ... ``` - 在 `from` 数组中仅包含一个元素，只允许来自标有 `role=client` 的 Pod 且 @@ -339,8 +356,8 @@ You can create a "default" isolation policy for a namespace by creating a Networ --> ### 默认拒绝所有入站流量 -你可以通过创建选择所有容器但不允许任何进入这些容器的入站流量的 NetworkPolicy -来为名字空间创建 "default" 隔离策略。 +你可以通过创建选择所有容器但不允许任何进入这些容器的入站流量的 NetworkPolicy +来为名字空间创建 “default” 隔离策略。 {{< codenew file="service/networking/network-policy-default-deny-ingress.yaml" >}} @@ -369,8 +386,8 @@ You can create a "default" egress isolation policy for a namespace by creating a --> ### 默认拒绝所有出站流量 -你可以通过创建选择所有容器但不允许来自这些容器的任何出站流量的 NetworkPolicy -来为名字空间创建 "default" egress 隔离策略。 +你可以通过创建选择所有容器但不允许来自这些容器的任何出站流量的 NetworkPolicy +来为名字空间创建 “default” 隔离策略。 {{< codenew file="service/networking/network-policy-default-deny-egress.yaml" >}} @@ -429,7 +446,7 @@ When the feature gate is enabled, you can set the `protocol` field of a NetworkP 启用该特性门控后，用户可以将 NetworkPolicy 的 `protocol` 字段设置为 `SCTP`。 {{< note >}} - 你必须使用支持 SCTP 协议网络策略的 {{< glossary_tooltip text="CNI" term_id="cni" >}} 插件。 @@ -474,17 +491,17 @@ spec: ``` -上面的规则允许名字空间 `default` 中所有带有标签 `db` 的 Pod 使用 TCP 协议 +上面的规则允许名字空间 `default` 中所有带有标签 `role=db` 的 Pod 使用 TCP 协议 与 `10.0.0.0/24` 范围内的 IP 通信，只要目标端口介于 32000 和 32768 之间就可以。 @@ -493,7 +510,7 @@ The following restrictions apply when using this field: * 作为一种 Beta 阶段的特性，端口范围设定默认是被启用的。要在整个集群 范围内禁止使用 `endPort` 字段，你（或者你的集群管理员）需要为 API 服务器设置 `-feature-gates=NetworkPolicyEndPort=false,...` 以禁用 - `NetworkPolicyEndPort` + `NetworkPolicyEndPort` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/)。 * `endPort` 字段必须等于或者大于 `port` 字段的值。 * 两个字段的设置值都只能是数字。 @@ -502,7 +519,7 @@ The following restrictions apply when using this field: @@ -518,7 +535,7 @@ the policy will be applied only for the single `port` field. --> ## 基于名字指向某名字空间 {#targeting-a-namespace-by-its-name} -{{< feature-state state="beta" for_k8s_version="1.21" >}} +{{< feature-state for_k8s_version="1.22" state="stable" >}} -这篇文章介绍如何给容器配置存活、就绪和启动探测器。 +这篇文章介绍如何给容器配置活跃（Liveness）、就绪（Readiness）和启动（Startup）探测器。 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) -使用存活探测器来知道什么时候要重启容器。 -例如，存活探测器可以捕捉到死锁（应用程序在运行，但是无法继续执行后面的步骤）。 -这样的情况下重启容器有助于让应用程序在有问题的情况下更可用。 +使用存活探测器来确定什么时候要重启容器。 +例如，存活探测器可以探测到应用死锁（应用程序在运行，但是无法继续执行后面的步骤）情况。 +重启这种状态下的容器有助于提高应用的可用性，即使其中存在缺陷。 -kubelet 使用就绪探测器可以知道容器什么时候准备好了并可以开始接受请求流量， 当一个 Pod -内的所有容器都准备好了，才能把这个 Pod 看作就绪了。 +kubelet 使用就绪探测器可以知道容器何时准备好接受请求流量，当一个 Pod +内的所有容器都就绪时，才能认为该 Pod 就绪。 这种信号的一个用途就是控制哪个 Pod 作为 Service 的后端。 -在 Pod 还没有准备好的时候，会从 Service 的负载均衡器中被剔除的。 +若 Pod 尚未就绪，会被从 Service 的负载均衡器中剔除。 -kubelet 使用启动探测器可以知道应用程序容器什么时候启动了。 -如果配置了这类探测器，就可以控制容器在启动成功后再进行存活性和就绪检查， -确保这些存活、就绪探测器不会影响应用程序的启动。 -这可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉。 +kubelet 使用启动探测器来了解应用容器何时启动。 +如果配置了这类探测器，你就可以控制容器在启动成功后再进行存活性和就绪态检查， +确保这些存活、就绪探测器不会影响应用的启动。 +启动探测器可以用于对慢启动容器进行存活性检测，避免它们在启动运行之前就被杀掉。 ## {{% heading "prerequisites" %}} @@ -61,10 +61,10 @@ In this exercise, you create a Pod that runs a container based on the --> ## 定义存活命令 {#define-a-liveness-command} -许多长时间运行的应用程序最终会过渡到断开的状态，除非重新启动，否则无法恢复。 -Kubernetes 提供了存活探测器来发现并补救这种情况。 +许多长时间运行的应用最终会进入损坏状态，除非重新启动，否则无法被恢复。 +Kubernetes 提供了存活探测器来发现并处理这种情况。 -在这篇练习中，你会创建一个 Pod，其中运行一个基于 `k8s.gcr.io/busybox` 镜像的容器。 +在本练习中，你会创建一个 Pod，其中运行一个基于 `k8s.gcr.io/busybox` 镜像的容器。 下面是这个 Pod 的配置文件。 {{< codenew file="pods/probe/exec-liveness.yaml" >}} @@ -81,7 +81,7 @@ and restarts it. When the container starts, it executes this command: --> -在这个配置文件中，可以看到 Pod 中只有一个容器。 +在这个配置文件中，可以看到 Pod 中只有一个 `Container`。 `periodSeconds` 字段指定了 kubelet 应该每 5 秒执行一次存活探测。 `initialDelaySeconds` 字段告诉 kubelet 在执行第一次探测前应该等待 5 秒。 kubelet 在容器内执行命令 `cat /tmp/healthy` 来进行探测。 @@ -101,7 +101,7 @@ code. After 30 seconds, `cat /tmp/healthy` returns a failure code. Create the Pod: --> -这个容器生命的前 30 秒， `/tmp/healthy` 文件是存在的。 +这个容器生命的前 30 秒，`/tmp/healthy` 文件是存在的。 所以在这最开始的 30 秒内，执行命令 `cat /tmp/healthy` 会返回成功代码。 30 秒之后，执行命令 `cat /tmp/healthy` 就会返回失败代码。 @@ -164,7 +164,7 @@ FirstSeen LastSeen Count From SubobjectPath Type -再等另外 30 秒，检查看这个容器被重启了： +再等 30 秒，确认这个容器被重启了： ```shell kubectl get pod liveness-exec @@ -205,12 +205,12 @@ returns a success code, the kubelet considers the container to be alive and healthy. If the handler returns a failure code, the kubelet kills the container and restarts it. --> -在这个配置文件中，可以看到 Pod 也只有一个容器。 +在这个配置文件中，你可以看到 Pod 也只有一个容器。 `periodSeconds` 字段指定了 kubelet 每隔 3 秒执行一次存活探测。 `initialDelaySeconds` 字段告诉 kubelet 在执行第一次探测前应该等待 3 秒。 -kubelet 会向容器内运行的服务（服务会监听 8080 端口）发送一个 HTTP GET 请求来执行探测。 +kubelet 会向容器内运行的服务（服务在监听 8080 端口）发送一个 HTTP GET 请求来执行探测。 如果服务器上 `/healthz` 路径下的处理程序返回成功代码，则 kubelet 认为容器是健康存活的。 -如果处理程序返回失败代码，则 kubelet 会杀死这个容器并且重新启动它。 +如果处理程序返回失败代码，则 kubelet 会杀死这个容器并将其重启。 -任何大于或等于 200 并且小于 400 的返回代码标示成功，其它返回代码都标示失败。 +返回大于或等于 200 并且小于 400 的任何代码都标示成功，其它返回代码都标示失败。 -可以在这里看服务的源码 [server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/agnhost/liveness/server.go)。 - -容器存活的最开始 10 秒中，`/healthz` 处理程序返回一个 200 的状态码。之后处理程序返回 500 的状态码。 +你可以访问 [server.go](https://github.com/kubernetes/kubernetes/blob/master/test/images/agnhost/liveness/server.go)。 +阅读服务的源码。 +容器存活期间的最开始 10 秒中，`/healthz` 处理程序返回 200 的状态码。 +之后处理程序返回 500 的状态码。 ```go http.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) { @@ -261,7 +262,7 @@ kubectl apply -f https://k8s.io/examples/pods/probe/http-liveness.yaml After 10 seconds, view Pod events to verify that liveness probes have failed and the container has been restarted: --> -10 秒之后，通过看 Pod 事件来检测存活探测器已经失败了并且容器被重新启动了。 +10 秒之后，通过查看 Pod 事件来确认活跃探测器已经失败，并且容器被重新启动了。 ```shell kubectl describe pod liveness-http @@ -274,7 +275,7 @@ the HTTP liveness probe uses that proxy. In releases after v1.13, local HTTP proxy environment variable settings do not affect the HTTP liveness probe. --> -在 1.13（包括 1.13版本）之前的版本中，如果在 Pod 运行的节点上设置了环境变量 +在 1.13 之前（包括 1.13）的版本中，如果在 Pod 运行的节点上设置了环境变量 `http_proxy`（或者 `HTTP_PROXY`），HTTP 的存活探测会使用这个代理。 在 1.13 之后的版本中，设置本地的 HTTP 代理环境变量不会影响 HTTP 的存活探测。 @@ -289,7 +290,7 @@ can't it is considered a failure. ## 定义 TCP 的存活探测 {#define-a-TCP-liveness-probe} 第三种类型的存活探测是使用 TCP 套接字。 -通过配置，kubelet 会尝试在指定端口和容器建立套接字链接。 +使用这种配置时，kubelet 会尝试在指定端口和容器建立套接字链接。 如果能建立连接，这个容器就被看作是健康的，如果不能则这个容器就被看作是有问题的。 {{< codenew file="pods/probe/tcp-liveness-readiness.yaml" >}} @@ -312,13 +313,13 @@ To try the TCP liveness check, create a Pod: --> 如你所见，TCP 检测的配置和 HTTP 检测非常相似。 下面这个例子同时使用就绪和存活探测器。kubelet 会在容器启动 5 秒后发送第一个就绪探测。 -这会尝试连接 `goproxy` 容器的 8080 端口。 +探测器会尝试连接 `goproxy` 容器的 8080 端口。 如果探测成功，这个 Pod 会被标记为就绪状态，kubelet 将继续每隔 10 秒运行一次检测。 除了就绪探测，这个配置包括了一个存活探测。 kubelet 会在容器启动 15 秒后进行第一次存活探测。 -与就绪探测类似，会尝试连接 `goproxy` 容器的 8080 端口。 -如果存活探测失败，这个容器会被重新启动。 +与就绪探测类似，活跃探测器会尝试连接 `goproxy` 容器的 8080 端口。 +如果存活探测失败，容器会被重新启动。 ```shell kubectl apply -f https://k8s.io/examples/pods/probe/tcp-liveness-readiness.yaml @@ -333,6 +334,98 @@ After 15 seconds, view Pod events to verify that liveness probes: kubectl describe pod goproxy ``` + +## 定义 gRPC 活跃探测器 + +{{< feature-state for_k8s_version="v1.23" state="alpha" >}} + + +如果你的应用实现了 [gRPC 健康检查协议](https://github.com/grpc/grpc/blob/master/doc/health-checking.md)， +kubelet 可以配置为使用该协议来执行应用活跃性检查。 +你必须启用 `GRPCContainerProbe` +[特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) +才能配置依赖于 gRPC 的检查机制。 + +下面是一个示例清单： + +{{< codenew file="pods/probe/grpc-liveness.yaml">}} + + +要使用 gRPC 探测器，必须配置 `port` 属性。如果健康状态端点配置在非默认服务之上， +你还必须设置 `service` 属性。 + +{{< note >}} + +与 HTTP 和 TCP 探测器不同，gRPC 探测不能使用命名端口或定制主机。 +{{< /note >}} + + +配置问题（例如：错误的 `port` 和 `service`、未实现健康检查协议） +都被认作是探测失败，这一点与 HTTP 和 TCP 探测器类似。 + +```shell +kubectl apply -f https://k8s.io/examples/pods/probe/grpc-liveness.yaml +``` + + +15 秒钟之后，查看 Pod 事件确认活跃性检查并未失败： + +```shell +kubectl describe pod etcd-with-grpc +``` + + +在 Kubernetes 1.23 之前，gRPC 健康探测通常使用 +[grpc-health-probe](https://github.com/grpc-ecosystem/grpc-health-probe/) +来实现，如博客 [Health checking gRPC servers on Kubernetes（对 Kubernetes 上的 gRPC 服务器执行健康检查）](/blog/2018/10/01/health-checking-grpc-servers-on-kubernetes/)所描述。 +内置的 gRPC 探测器行为与 `grpc-health-probe` 所实现的行为类似。 +从 `grpc-health-probe` 迁移到内置探测器时，请注意以下差异： + + +- 内置探测器运行时针对的是 Pod 的 IP 地址，不像 `grpc-health-probe` + 那样通常针对 `127.0.0.1` 执行探测； + 请一定配置你的 gRPC 端点使之监听于 Pod 的 IP 地址之上。 +- 内置探测器不支持任何身份认证参数（例如 `tls`）。 +- 对于内置的探测器而言，不存在错误代码。所有错误都被视作探测失败。 +- 如果 `ExecProbeTimeout` 特性门控被设置为 `false`，则 `grpc-health-probe` + 不会考虑 `timeoutSeconds` 设置状态（默认值为 1s）， + 而内置探测器则会在超时时返回失败。 + ## 使用启动探测器保护慢启动容器 {#define-startup-probes} -有时候，会有一些现有的应用程序在启动时需要较多的初始化时间。 -要不影响对引起探测死锁的快速响应，这种情况下，设置存活探测参数是要技巧的。 -技巧就是使用一个命令来设置启动探测，针对HTTP 或者 TCP 检测，可以通过设置 -`failureThreshold * periodSeconds` 参数来保证有足够长的时间应对糟糕情况下的启动时间。 +有时候，会有一些现有的应用在启动时需要较长的初始化时间。 +要这种情况下，若要不影响对死锁作出快速响应的探测，设置存活探测参数是要技巧的。 +技巧就是使用相同的命令来设置启动探测，针对 HTTP 或 TCP 检测，可以通过将 +`failureThreshold * periodSeconds` 参数设置为足够长的时间来应对糟糕情况下的启动时间。 -所以，前面的例子就变成了： +这样，前面的例子就变成了： ```yaml ports: @@ -408,9 +501,10 @@ provide a fast response to container deadlocks. If the startup probe never succeeds, the container is killed after 300s and subject to the pod's `restartPolicy`. --> -幸亏有启动探测，应用程序将会有最多 5 分钟(30 * 10 = 300s) 的时间来完成它的启动。 -一旦启动探测成功一次，存活探测任务就会接管对容器的探测，对容器死锁可以快速响应。 -如果启动探测一直没有成功，容器会在 300 秒后被杀死，并且根据 `restartPolicy` 来设置 Pod 状态。 +幸亏有启动探测，应用程序将会有最多 5 分钟（30 * 10 = 300s）的时间来完成其启动过程。 +一旦启动探测成功一次，存活探测任务就会接管对容器的探测，对容器死锁作出快速响应。 +如果启动探测一直没有成功，容器会在 300 秒后被杀死，并且根据 `restartPolicy` 来 +执行进一步处置。 ## 定义就绪探测器 {#define-readiness-probes} -有时候，应用程序会暂时性的不能提供通信服务。 -例如，应用程序在启动时可能需要加载很大的数据或配置文件，或是启动后要依赖等待外部服务。 -在这种情况下，既不想杀死应用程序，也不想给它发送请求。 +有时候，应用会暂时性地无法为请求提供服务。 +例如，应用在启动时可能需要加载大量的数据或配置文件，或是启动后要依赖等待外部服务。 +在这种情况下，既不想杀死应用，也不想给它发送请求。 Kubernetes 提供了就绪探测器来发现并缓解这些情况。 容器所在 Pod 上报还未就绪的信息，并且不接受通过 Kubernetes Service 的流量。 @@ -443,8 +537,8 @@ Readiness probes runs on the container during its whole lifecycle. Liveness probes *do not* wait for readiness probes to succeed. If you want to wait before executing a liveness probe you should use initialDelaySeconds or a startupProbe. --> {{< caution >}} -活跃性探测器 *不等待* 就绪性探测器成功。 -如果要在执行活跃性探测器之前等待，应该使用 initialDelaySeconds 或 startupProbe。 +活跃探测器 **不等待** 就绪性探测器成功。 +如果要在执行活跃探测器之前等待，应该使用 `initialDelaySeconds` 或 `startupProbe`。 {{< /caution >}} -HTTP 和 TCP 的就绪探测器配置也和存活探测器的配置一样的。 +HTTP 和 TCP 的就绪探测器配置也和存活探测器的配置完全相同。 就绪和存活探测可以在同一个容器上并行使用。 -两者都用可以确保流量不会发给还没有准备好的容器，并且容器会在它们失败的时候被重新启动。 +两者都可以确保流量不会发给还未就绪的容器，当这些探测失败时容器会被重新启动。 [Probe](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#probe-v1-core) -有很多配置字段，可以使用这些字段精确的控制存活和就绪检测的行为： +有很多配置字段，可以使用这些字段精确地控制活跃和就绪检测的行为： -* `initialDelaySeconds`：容器启动后要等待多少秒后存活和就绪探测器才被初始化，默认是 0 秒，最小值是 0。 +* `initialDelaySeconds`：容器启动后要等待多少秒后才启动存活和就绪探测器， + 默认是 0 秒，最小值是 0。 * `periodSeconds`：执行探测的时间间隔（单位是秒）。默认是 10 秒。最小值是 1。 * `timeoutSeconds`：探测的超时后等待多少秒。默认值是 1 秒。最小值是 1。 * `successThreshold`：探测器在失败后，被视为成功的最小连续成功数。默认值是 1。 存活和启动探测的这个值必须是 1。最小值是 1。 * `failureThreshold`：当探测失败时，Kubernetes 的重试次数。 - 存活探测情况下的放弃就意味着重新启动容器。 - 就绪探测情况下的放弃 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。 + 对存活探测而言，放弃就意味着重新启动容器。 + 对就绪探测而言，放弃意味着 Pod 会被打上未就绪的标签。默认值是 3。最小值是 1。 {{< note >}} -在 Kubernetes 1.20 版本之前，exec 探针会忽略 `timeoutSeconds`：探针会无限期地 -持续运行，甚至可能超过所配置的限期，直到返回结果为止。 +在 Kubernetes 1.20 版本之前，`exec` 探针会忽略 `timeoutSeconds`： +探针会无限期地持续运行，甚至可能超过所配置的限期，直到返回结果为止。 这一缺陷在 Kubernetes v1.20 版本中得到修复。你可能一直依赖于之前错误的探测行为， -甚至你都没有觉察到这一问题的存在，因为默认的超时值是 1 秒钟。 +甚至都没有觉察到这一问题的存在，因为默认的超时值是 1 秒钟。 作为集群管理员，你可以在所有的 kubelet 上禁用 `ExecProbeTimeout` [特性门控](/zh/docs/reference/command-line-tools-reference/feature-gates/) -（将其设置为 `false`），从而恢复之前版本中的运行行为，之后当集群中所有的 +（将其设置为 `false`），从而恢复之前版本中的运行行为。之后当集群中所有的 exec 探针都设置了 `timeoutSeconds` 参数后，移除此标志重载。 -如果你有 Pods 受到此默认 1 秒钟超时值的影响，你应该更新 Pod 对应的探针的 -超时值，这样才能为最终去除该特性门控做好准备。 +如果你有 Pod 受到此默认 1 秒钟超时值的影响，你应该更新这些 Pod 对应的探针的超时值， +这样才能为最终去除该特性门控做好准备。 ### TCP 探测 {#tcp-probes} -对于一次 TCP 探测，kubelet 在节点上（不是在 Pod 里面）建立探测连接， +对于 TCP 探测而言，kubelet 在节点上（不是在 Pod 里面）发起探测连接， 这意味着你不能在 `host` 参数上配置服务名称，因为 kubelet 不能解析服务名称。 -### 探测器级别 `terminationGracePeriodSeconds` +### 探测器层面的 `terminationGracePeriodSeconds` {{< feature-state for_k8s_version="v1.22" state="beta" >}} + +在 1.21 发行版之前，Pod 层面的 `terminationGracePeriodSeconds` +被用来终止活跃探测或启动探测失败的容器。 +这一行为上的关联不是我们想要的，可能导致 Pod 层面设置了 `terminationGracePeriodSeconds` +时容器要花非常长的时间才能重新启动。 + -在 1.21 及更高版本中，当特性门控 `ProbeTerminationGracePeriod` 为 -启用状态时，用户可以指定一个探测级别的 `terminationGracePeriodSeconds` 作为 -探针规格的一部分。当特性门控被启用时，并且 -Pod 级和探针级的 `terminationGracePeriodSeconds` 都已设置，kubelet 将 -使用探针级设置的值。 +在 1.21 及更高版本中，当特性门控 `ProbeTerminationGracePeriod` 被启用时， +用户可以指定一个探测器层面的 `terminationGracePeriodSeconds` 作为探测器规约的一部分。 +当该特性门控被启用，并且 Pod 层面和探测器层面的 `terminationGracePeriodSeconds` +都已设置，kubelet 将使用探测器层面设置的值。 -{{< note >}} -从 Kubernetes 1.22 开始，`ProbeTerminationGracePeriod` 特性门控只 -在 API 服务器上可用。 kubelet 始终遵守探针级别 -`terminationGracePeriodSeconds` 字段（如果它存在于 Pod 上）。 +在 Kubernetes 1.22 中，`ProbeTerminationGracePeriod` 特性门控只能用在 API 服务器上。 +kubelet 始终遵守探针级别 `terminationGracePeriodSeconds` 字段 +（如果它存在于 Pod 上）。 -如果你已经为现有 Pod 设置了 “terminationGracePeriodSeconds” 字段并且 -不再希望使用针对每个探针的终止宽限期，则必须删除那些现有的 Pod。 +如果你已经为现有 Pod 设置了 `terminationGracePeriodSeconds` +字段并且不再希望使用针对每个探针的终止宽限期，则必须删除现有的这类 Pod。 -当你（或控制平面或某些其他组件）创建替换 -Pods，并且特性门控 “ProbeTerminationGracePeriod” 被禁用，那么 -API 服务器会忽略 Pod 级别的 `terminationGracePeriodSeconds` 字段，即使 -Pod 或 Pod 模板指定了它。 -{{< /note >}} +当你（或控制平面或某些其他组件）创建替换 Pod，并且特性门控 `ProbeTerminationGracePeriod` +被禁用时，API 服务器会忽略 Pod 级别的 `terminationGracePeriodSeconds` 字段设置， +即使 Pod 或 Pod 模板指定了它。 例如: @@ -745,8 +850,8 @@ spec: Probe-level `terminationGracePeriodSeconds` cannot be set for readiness probes. It will be rejected by the API server. --> -探测器级别的 `terminationGracePeriodSeconds` 不能用于设置就绪态探针。 -它将被 API 服务器拒绝。 +探测器层面的 `terminationGracePeriodSeconds` 不能用于就绪态探针。 +这一设置将被 API 服务器拒绝。 ## {{% heading "whatsnext" %}} diff --git a/content/zh/examples/pods/probe/grpc-liveness.yaml b/content/zh/examples/pods/probe/grpc-liveness.yaml new file mode 100644 index 0000000000..578fd080a4 --- /dev/null +++ b/content/zh/examples/pods/probe/grpc-liveness.yaml @@ -0,0 +1,15 @@ +apiVersion: v1 +kind: Pod +metadata: + name: etcd-with-grpc +spec: + containers: + - name: etcd + image: k8s.gcr.io/etcd:3.5.1-0 + command: [ "/usr/local/bin/etcd", "--data-dir", "/var/lib/etcd", "--listen-client-urls", "http://0.0.0.0:2379", "--advertise-client-urls", "http://127.0.0.1:2379", "--log-level", "debug"] + ports: + - containerPort: 2379 + livenessProbe: + grpc: + port: 2379 + initialDelaySeconds: 10 From 27ec191771eb9659223affdeb234f5189a7062bd Mon Sep 17 00:00:00 2001 From: Mark Andreev Date: Sat, 9 Apr 2022 13:13:20 +0400 Subject: [PATCH 16/27] Remove link to domana.io The domain name Romana.io is for sale. I suggest to remove this invalid ref. --- content/en/docs/concepts/cluster-administration/addons.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/concepts/cluster-administration/addons.md b/content/en/docs/concepts/cluster-administration/addons.md index 126272973f..89351eb6ab 100644 --- a/content/en/docs/concepts/cluster-administration/addons.md +++ b/content/en/docs/concepts/cluster-administration/addons.md @@ -29,7 +29,7 @@ This page lists some of the available add-ons and links to their respective inst * [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) is OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC), Multiple OVN overlay networking, dynamic subnet creation, dynamic creation of virtual networks, VLAN Provider network, Direct provider network and pluggable with other Multi-network plugins, ideal for edge based cloud native workloads in Multi-cluster networking * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) provides integration between VMware NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift. * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) is an SDN platform that provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring. -* [Romana](https://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize). +* **Romana** is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize). * [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database. ## Service Discovery From 4764a50fee4bbf5cd52b2c2d0ee95d2a66384188 Mon Sep 17 00:00:00 2001 From: sou <08thse@users.noreply.github.com> Date: Sat, 9 Apr 2022 23:52:46 +0900 Subject: [PATCH 17/27] Update create-hostprocess-pod.md Fix typo (Window -> Windows) --- .../tasks/configure-pod-container/create-hostprocess-pod.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/en/docs/tasks/configure-pod-container/create-hostprocess-pod.md b/content/en/docs/tasks/configure-pod-container/create-hostprocess-pod.md index b3bbcaa06d..a7dcbafd34 100644 --- a/content/en/docs/tasks/configure-pod-container/create-hostprocess-pod.md +++ b/content/en/docs/tasks/configure-pod-container/create-hostprocess-pod.md @@ -20,7 +20,7 @@ the direct installation of host services. Administrative tasks such as installation of security patches, event log collection, and more can be performed without requiring cluster operators to -log onto each Window node. HostProcess containers can run as any user that is +log onto each Windows node. HostProcess containers can run as any user that is available on the host or is in the domain of the host machine, allowing administrators to restrict resource access through user permissions. While neither filesystem or process isolation are supported, a new volume is created on the host upon starting the container From 5a4e1e32540ab40e5b53c2497820f367525660c5 Mon Sep 17 00:00:00 2001 From: Qiming Teng Date: Sun, 10 Apr 2022 09:18:37 +0800 Subject: [PATCH 18/27] [zh] Remove PSP The upstream English page is removed. --- .../concepts/policy/pod-security-policy.md | 1335 ----------------- 1 file changed, 1335 deletions(-) delete mode 100644 content/zh/docs/concepts/policy/pod-security-policy.md diff --git a/content/zh/docs/concepts/policy/pod-security-policy.md b/content/zh/docs/concepts/policy/pod-security-policy.md deleted file mode 100644 index f1b099352d..0000000000 --- a/content/zh/docs/concepts/policy/pod-security-policy.md +++ /dev/null @@ -1,1335 +0,0 @@ ---- -title: Pod 安全策略 -content_type: concept -weight: 30 ---- - - - -{{< feature-state for_k8s_version="v1.21" state="deprecated" >}} - -{{< caution >}} - -PodSecurityPolicy 在 Kubernetes v1.21 版本中被弃用，**将在 v1.25 中删除**。 -我们建议迁移到 [Pod 安全性准入](/zh/docs/concepts/security/pod-security-admission)， -或者第三方的准入插件。 -若需了解迁移指南，可参阅[从 PodSecurityPolicy 迁移到内置的 PodSecurity 准入控制器](/zh/docs/tasks/configure-pod-container/migrate-from-psp/)。 -关于弃用的更多信息，请查阅 [PodSecurityPolicy Deprecation: Past, Present, and Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)。 -{{< /caution >}} - - -Pod 安全策略使得对 Pod 创建和更新进行细粒度的权限控制成为可能。 - - -## 什么是 Pod 安全策略？ - -_Pod 安全策略（Pod Security Policy）_ 是集群级别的资源，它能够控制 Pod 规约 -中与安全性相关的各个方面。 -[PodSecurityPolicy](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy) -对象定义了一组 Pod 运行时必须遵循的条件及相关字段的默认值，只有 Pod 满足这些条件 -才会被系统接受。 -Pod 安全策略允许管理员控制如下方面： - - -| 控制的角度 | 字段名称 | -| ----------------------------------- | --------------------------------- | -| 运行特权容器 | [`privileged`](#privileged) | -| 使用宿主名字空间 | [`hostPID`、`hostIPC`](#host-namespaces) | -| 使用宿主的网络和端口 | [`hostNetwork`, `hostPorts`](#host-namespaces) | -| 控制卷类型的使用 | [`volumes`](#volumes-and-file-systems) | -| 使用宿主文件系统 | [`allowedHostPaths`](#volumes-and-file-systems) | -| 允许使用特定的 FlexVolume 驱动 | [`allowedFlexVolumes`](#flexvolume-drivers) | -| 分配拥有 Pod 卷的 FSGroup 账号 | [`fsGroup`](#volumes-and-file-systems) | -| 以只读方式访问根文件系统 | [`readOnlyRootFilesystem`](#volumes-and-file-systems) | -| 设置容器的用户和组 ID | [`runAsUser`, `runAsGroup`, `supplementalGroups`](#users-and-groups) | -| 限制 root 账号特权级提升 | [`allowPrivilegeEscalation`, `defaultAllowPrivilegeEscalation`](#privilege-escalation) | -| Linux 权能字（Capabilities） | [`defaultAddCapabilities`, `requiredDropCapabilities`, `allowedCapabilities`](#capabilities) | -| 设置容器的 SELinux 上下文 | [`seLinux`](#selinux) | -| 指定容器可以挂载的 proc 类型 | [`allowedProcMountTypes`](#allowedprocmounttypes) | -| 指定容器使用的 AppArmor 模版 | [annotations](#apparmor) | -| 指定容器使用的 seccomp 模版 | [annotations](#seccomp) | -| 指定容器使用的 sysctl 模版 | [`forbiddenSysctls`,`allowedUnsafeSysctls`](#sysctl) | - - -_Pod 安全策略_ 由设置和策略组成，它们能够控制 Pod 访问的安全特征。这些设置分为如下三类： - -- *基于布尔值控制* ：这种类型的字段默认为最严格限制的值。 -- *基于被允许的值集合控制* ：这种类型的字段会与这组值进行对比，以确认值被允许。 -- *基于策略控制* ：设置项通过一种策略提供的机制来生成该值，这种机制能够确保指定的值落在被允许的这组值中。 - - -## 启用 Pod 安全策略 - -Pod 安全策略实现为一种可选的 -[准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#podsecuritypolicy)。 -[启用了准入控制器](/zh/docs/reference/access-authn-authz/admission-controllers/#how-do-i-turn-on-an-admission-control-plug-in) -即可强制实施 Pod 安全策略，不过如果没有授权认可策略之前即启用 -准入控制器 **将导致集群中无法创建任何 Pod**。 - - -由于 Pod 安全策略 API（`policy/v1beta1/podsecuritypolicy`）是独立于准入控制器 -来启用的，对于现有集群而言，建议在启用准入控制器之前先添加策略并对其授权。 - - -## 授权策略 {#authorizing-policies} - -PodSecurityPolicy 资源被创建时，并不执行任何操作。为了使用该资源，需要对 -发出请求的用户或者目标 Pod 的 -[服务账号](/zh/docs/tasks/configure-pod-container/configure-service-account/) -授权，通过允许其对策略执行 `use` 动词允许其使用该策略。 - - -大多数 Kubernetes Pod 不是由用户直接创建的。相反，这些 Pod 是由 -[Deployment](/zh/docs/concepts/workloads/controllers/deployment/)、 -[ReplicaSet](/zh/docs/concepts/workloads/controllers/replicaset/) -或者经由控制器管理器模版化的控制器创建。 -赋予控制器访问策略的权限意味着对应控制器所创建的 *所有* Pod 都可访问策略。 -因此，对策略进行授权的优先方案是为 Pod 的服务账号授予访问权限 -（参见[示例](#run-another-pod)）。 - - -### 通过 RBAC 授权 {#via-rbac} - -[RBAC](/zh/docs/reference/access-authn-authz/rbac/) 是一种标准的 Kubernetes -鉴权模式，可以很容易地用来授权策略访问。 - -首先，某 `Role` 或 `ClusterRole` 需要获得使用 `use` 访问目标策略的权限。 -访问授权的规则看起来像这样： - -```yaml -apiVersion: rbac.authorization.k8s.io/v1 -kind: ClusterRole -metadata: - name: -rules: -- apiGroups: ['policy'] - resources: ['podsecuritypolicies'] - verbs: ['use'] - resourceNames: - - <要授权的策略列表> -``` - - -接下来将该 `Role`（或 `ClusterRole`）绑定到授权的用户： - -```yaml -apiVersion: rbac.authorization.k8s.io/v1 -kind: ClusterRoleBinding -metadata: - name: -roleRef: - kind: ClusterRole - name: - apiGroup: rbac.authorization.k8s.io -subjects: -# 授权命名空间下的所有服务账号（推荐）： -- kind: Group - apiGroup: rbac.authorization.k8s.io - name: system:serviceaccounts: -# 授权特定的服务账号（不建议这样操作）： -- kind: ServiceAccount - name: - namespace: -# 授权特定的用户（不建议这样操作）： -- kind: User - apiGroup: rbac.authorization.k8s.io - name: -``` - - -如果使用的是 `RoleBinding`（而不是 `ClusterRoleBinding`），授权仅限于 -与该 `RoleBinding` 处于同一名字空间中的 Pods。 -可以考虑将这种授权模式和系统组结合，对名字空间中的所有 Pod 授予访问权限。 - -```yaml -# 授权某名字空间中所有服务账号 -- kind: Group - apiGroup: rbac.authorization.k8s.io - name: system:serviceaccounts -# 或者与之等价，授权给某名字空间中所有被认证过的用户 -- kind: Group - apiGroup: rbac.authorization.k8s.io - name: system:authenticated -``` - - -参阅[角色绑定示例](/zh/docs/reference/access-authn-authz/rbac#role-binding-examples) -查看 RBAC 绑定的更多实例。 -参阅[下文](#example)，查看对 PodSecurityPolicy 进行授权的完整示例。 - - -## 推荐实践 {#recommended-practice} - -PodSecurityPolicy 正在被一个新的、简化的 `PodSecurity` {{< glossary_tooltip -text="准入控制器" term_id="admission-controller" >}}替代。 -有关此变更的更多详细信息，请参阅 [PodSecurityPolicy Deprecation: Past, Present, and -Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)。 -参照下述指导，简化从 PodSecurityPolicy 迁移到新的准入控制器步骤： - - -1. 将 PodSecurityPolicies 限制为 [Pod 安全性标准](/zh/docs/concepts/security/pod-security-standards)所定义的策略： - - {{< example file="policy/privileged-psp.yaml" >}}Privileged{{< /example >}} - - {{< example file="policy/baseline-psp.yaml" >}}Baseline{{< /example >}} - - {{< example file="policy/restricted-psp.yaml" >}}Restricted{{< /example >}} -2. 通过配置 `system:serviceaccounts:` 组（`` 是目标命名空间），仅将 PSP 绑定到整个命名空间。示例： - - ```yaml - apiVersion: rbac.authorization.k8s.io/v1 - # This cluster role binding allows all pods in the "development" namespace to use the baseline PSP. - kind: ClusterRoleBinding - metadata: - name: psp-baseline-namespaces - roleRef: - kind: ClusterRole - name: psp-baseline - apiGroup: rbac.authorization.k8s.io - subjects: - - kind: Group - name: system:serviceaccounts:development - apiGroup: rbac.authorization.k8s.io - - kind: Group - name: system:serviceaccounts:canary - apiGroup: rbac.authorization.k8s.io - ``` - -### 故障排查 {#troubleshooting} - -- [控制器管理器组件](/zh/docs/reference/command-line-tools-reference/kube-controller-manager/) - 必须运行在 - [安全的 API 端口](/zh/docs/concepts/security/controlling-access/)， - 并且一定不能具有超级用户权限。 - 否则其请求会绕过身份认证和鉴权模块控制，从而导致所有 PodSecurityPolicy 对象 - 都被启用，用户亦能创建特权容器。 - 关于配置控制器管理器鉴权相关的详细信息，可参阅 - [控制器角色](/zh/docs/reference/access-authn-authz/rbac/#controller-roles)。 - - -## 策略顺序 {#policy-order} - -除了限制 Pod 创建与更新，Pod 安全策略也可用来为其所控制的很多字段 -设置默认值。当存在多个策略对象时，Pod 安全策略控制器依据以下条件选择 -策略： - - -1. 优先考虑允许 Pod 保持原样，不会更改 Pod 字段默认值或其他配置的 PodSecurityPolicy。 - 这类非更改性质的 PodSecurityPolicy 对象之间的顺序无关紧要。 -2. 如果必须要为 Pod 设置默认值或者其他配置，（按名称顺序）选择第一个允许 - Pod 操作的 PodSecurityPolicy 对象。 - - -{{< note >}} -在更新操作期间（这时不允许更改 Pod 规约），仅使用非更改性质的 -PodSecurityPolicy 来对 Pod 执行验证操作。 -{{< /note >}} - - -## 示例 {#example} - -_本示例假定你已经有一个启动了 PodSecurityPolicy 准入控制器的集群并且 -你拥有集群管理员特权。_ - - -### 配置 {#set-up} - -为运行此示例，配置一个名字空间和一个服务账号。我们将用这个服务账号来 -模拟一个非管理员账号的用户。 - -```shell -kubectl create namespace psp-example -kubectl create serviceaccount -n psp-example fake-user -kubectl create rolebinding -n psp-example fake-editor --clusterrole=edit --serviceaccount=psp-example:fake-user -``` - - -创建两个别名，以更清晰地展示我们所使用的用户账号，同时减少一些键盘输入： - -```shell -alias kubectl-admin='kubectl -n psp-example' -alias kubectl-user='kubectl --as=system:serviceaccount:psp-example:fake-user -n psp-example' -``` - - -### 创建一个策略和一个 Pod - -在一个文件中定义一个示例的 PodSecurityPolicy 对象。 -这里的策略只是用来禁止创建有特权要求的 Pods。 -PodSecurityPolicy 对象的名称必须是合法的 -[DNS 子域名](/zh/docs/concepts/overview/working-with-objects/names#dns-subdomain-names)。 - -{{< codenew file="policy/example-psp.yaml" >}} - - -使用 kubectl 执行创建操作： - -```shell -kubectl-admin create -f example-psp.yaml -``` - - -现在，作为一个非特权用户，尝试创建一个简单的 Pod： - -```shell -kubectl-user create -f- < -输出类似于： -``` -Error from server (Forbidden): error when creating "STDIN": pods "pause" is forbidden: unable to validate against any pod security policy: [] -``` - - -**发生了什么？** 尽管 PodSecurityPolicy 被创建，Pod 的服务账号或者 -`fake-user` 用户都没有使用该策略的权限。 - -```shell -kubectl-user auth can-i use podsecuritypolicy/example -``` - -``` -no -``` - -创建角色绑定，赋予 `fake-user` 使用 `use` 访问示例策略的权限： - - -{{< note >}} -不建议使用这种方法！ -欲了解优先考虑的方法，请参见[下节](#run-another-pod)。 -{{< /note >}} - -```shell -kubectl-admin create role psp:unprivileged \ - --verb=use \ - --resource=podsecuritypolicy \ - --resource-name=example -``` - -输出： - -``` -role "psp:unprivileged" created -``` - -```shell -kubectl-admin create rolebinding fake-user:psp:unprivileged \ - --role=psp:unprivileged \ - --serviceaccount=psp-example:fake-user -``` - -输出： - -``` -rolebinding "fake-user:psp:unprivileged" created -``` - -```shell -kubectl-user auth can-i use podsecuritypolicy/example -``` - -输出： - -``` -yes -``` - - -现在重试创建 Pod： - -```shell -kubectl-user create -f- < -输出类似于： -``` -pod "pause" created -``` - - -此次尝试不出所料地成功了！ -不过任何创建特权 Pod 的尝试还是会被拒绝： - -```shell -kubectl-user create -f- < - -输出类似于： -``` -Error from server (Forbidden): error when creating "STDIN": pods "privileged" is forbidden: unable to validate against any pod security policy: [spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed] -``` - - -继续此例之前先删除该 Pod： - -```shell -kubectl-user delete pod pause -``` - - -### 运行另一个 Pod {#run-another-pod} - -我们再试一次，稍微有些不同： - -```shell -kubectl-user create deployment pause --image=k8s.gcr.io/pause -``` - -输出为： - -``` -deployment "pause" created -``` - -```shell -kubectl-user get pods -``` - -输出为： - -``` -No resources found. -``` - -```shell -kubectl-user get events | head -n 2 -``` - -输出为： -``` -LASTSEEN FIRSTSEEN COUNT NAME KIND SUBOBJECT TYPE REASON SOURCE MESSAGE -1m 2m 15 pause-7774d79b5 ReplicaSet Warning FailedCreate replicaset-controller Error creating: pods "pause-7774d79b5-" is forbidden: no providers available to validate pod request -``` - - -**发生了什么？** 我们已经为用户 `fake-user` 绑定了 `psp:unprivileged` 角色， -为什么还会收到错误 `Error creating: pods "pause-7774d79b5-" is -forbidden: no providers available to validate pod request -（创建错误：pods "pause-7774d79b5" 被禁止：没有可用来验证 pod 请求的驱动）`？ -答案在于源文件 - `replicaset-controller`。 -`fake-user` 用户成功地创建了 Deployment，而后者也成功地创建了 ReplicaSet， -不过当 ReplicaSet 创建 Pod 时，发现未被授权使用示例 PodSecurityPolicy 资源。 - - -为了修复这一问题，将 `psp:unprivileged` 角色绑定到 Pod 的服务账号。 -在这里，因为我们没有给出服务账号名称，默认的服务账号是 `default`。 - -```shell -kubectl-admin create rolebinding default:psp:unprivileged \ - --role=psp:unprivileged \ - --serviceaccount=psp-example:default -``` - -输出为： - -``` -rolebinding "default:psp:unprivileged" created -``` - - -现在如果你给 ReplicaSet 控制器一分钟的时间来重试，该控制器最终将能够 -成功地创建 Pod： - -```shell -kubectl-user get pods --watch -``` - -输出类似于： - -``` -NAME READY STATUS RESTARTS AGE -pause-7774d79b5-qrgcb 0/1 Pending 0 1s -pause-7774d79b5-qrgcb 0/1 Pending 0 1s -pause-7774d79b5-qrgcb 0/1 ContainerCreating 0 1s -pause-7774d79b5-qrgcb 1/1 Running 0 2s -``` - - -### 清理 {#clean-up} - -删除名字空间即可清理大部分示例资源： - -```shell -kubectl-admin delete ns psp-example -``` - -输出类似于： - -``` -namespace "psp-example" deleted -``` - - -注意 `PodSecurityPolicy` 资源不是名字空间域的资源，必须单独清理： - -```shell -kubectl-admin delete psp example -``` - -输出类似于： -``` -podsecuritypolicy "example" deleted -``` - - -### 示例策略 {#example-policies} - -下面是一个你可以创建的约束性非常弱的策略，其效果等价于没有使用 Pod 安全 -策略准入控制器： - -{{< codenew file="policy/privileged-psp.yaml" >}} - - -下面是一个具有约束性的策略，要求用户以非特权账号运行，禁止可能的向 root 权限 -的升级，同时要求使用若干安全机制。 - -{{< codenew file="policy/restricted-psp.yaml" >}} - - -更多的示例可参考 -[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/#policy-instantiation)。 - - -## 策略参考 {#policy-reference} - -### Privileged - -**Privileged** - 决定是否 Pod 中的某容器可以启用特权模式。 -默认情况下，容器是不可以访问宿主上的任何设备的，不过一个“privileged（特权的）” -容器则被授权访问宿主上所有设备。 -这种容器几乎享有宿主上运行的进程的所有访问权限。 -对于需要使用 Linux 权能字（如操控网络堆栈和访问设备）的容器而言是有用的。 - - -### 宿主名字空间 {#host-namespaces} - -**HostPID** - 控制 Pod 中容器是否可以共享宿主上的进程 ID 空间。 -注意，如果与 `ptrace` 相结合，这种授权可能被利用，导致向容器外的特权逃逸 -（默认情况下 `ptrace` 是被禁止的）。 - -**HostIPC** - 控制 Pod 容器是否可共享宿主上的 IPC 名字空间。 - -**HostNetwork** - 控制是否 Pod 可以使用节点的网络名字空间。 -此类授权将允许 Pod 访问本地回路（loopback）设备、在本地主机（localhost） -上监听的服务、还可能用来监听同一节点上其他 Pod 的网络活动。 - -**HostPorts** -提供可以在宿主网络名字空间中可使用的端口范围列表。 -该属性定义为一组 `HostPortRange` 对象的列表，每个对象中包含 -`min`（含）与 `max`（含）值的设置。 -默认不允许访问宿主端口。 - - -### 卷和文件系统 {#volumes-and-file-systems} - -**Volumes** - 提供一组被允许的卷类型列表。可被允许的值对应于创建卷时可以 -设置的卷来源。卷类型的完整列表可参见 -[卷类型](/zh/docs/concepts/storage/volumes/#types-of-volumes)。 -此外， `*` 可以用来允许所有卷类型。 - -对于新的 Pod 安全策略设置而言，建议设置的卷类型的*最小列表*包含： - -- configMap -- downwardAPI -- emptyDir -- persistentVolumeClaim -- secret -- projected - - -{{< warning >}} -PodSecurityPolicy 并不限制可以被 `PersistentVolumeClaim` 所引用的 -`PersistentVolume` 对象的类型。 -此外 `hostPath` 类型的 `PersistentVolume` 不支持只读访问模式。 -应该仅赋予受信用户创建 `PersistentVolume` 对象的访问权限。 -{{< /warning >}} - - -**FSGroup** - 控制应用到某些卷上的附加用户组。 - - - *MustRunAs* - 要求至少指定一个 `range`。 - 使用范围中的最小值作为默认值。所有 range 值都会被用来执行验证。 - - *MayRunAs* - 要求至少指定一个 `range`。 - 允许不设置 `FSGroups`，且无默认值。 - 如果 `FSGroup` 被设置，则所有 range 值都会被用来执行验证检查。 - - *RunAsAny* - 不提供默认值。允许设置任意 `fsGroup` ID 值。 - - -**AllowedHostPaths** - 设置一组宿主文件目录，这些目录项可以在 `hostPath` 卷中 -使用。列表为空意味着对所使用的宿主目录没有限制。 -此选项定义包含一个对象列表，表中对象包含 `pathPrefix` 字段，用来表示允许 -`hostPath` 卷挂载以所指定前缀开头的路径。 -对象中还包含一个 `readOnly` 字段，用来表示对应的卷必须以只读方式挂载。 -例如： - - -```yaml -allowedHostPaths: - # 下面的设置允许 "/foo"、"/foo/"、"/foo/bar" 等路径，但禁止 - # "/fool"、"/etc/foo" 这些路径。 - # "/foo/../" 总会被当作非法路径。 - - pathPrefix: "/foo" - readOnly: true # 仅允许只读模式挂载 -``` - - - -{{< warning >}} -容器如果对宿主文件系统拥有不受限制的访问权限，就可以有很多种方式提升自己的特权， -包括读取其他容器中的数据、滥用系统服务（如 `kubelet`）的凭据信息等。 - -由可写入的目录所构造的 `hostPath` 卷能够允许容器写入数据到宿主文件系统， -并且在写入时避开 `pathPrefix` 所设置的目录限制。 -`readOnly: true` 这一设置在 Kubernetes 1.11 版本之后可用。 -必须针对 `allowedHostPaths` 中的 *所有* 条目设置此属性才能有效地限制容器 -只能访问 `pathPrefix` 所指定的目录。 -{{< /warning >}} - -**ReadOnlyRootFilesystem** - 要求容器必须以只读方式挂载根文件系统来运行 -（即不允许存在可写入层）。 - - -### FlexVolume 驱动 {#flexvolume-drivers} - -此配置指定一个可以被 FlexVolume 卷使用的驱动程序的列表。 -空的列表或者 nil 值意味着对驱动没有任何限制。 -请确保[`volumes`](#volumes-and-file-systems) 字段包含了 `flexVolume` 卷类型， -否则所有 FlexVolume 驱动都被禁止。 - - - -```yaml -apiVersion: policy/v1beta1 -kind: PodSecurityPolicy -metadata: - name: allow-flex-volumes -spec: - # spec d的其他字段 - volumes: - - flexVolume - allowedFlexVolumes: - - driver: example/lvm - - driver: example/cifs -``` - - -### 用户和组 {#users-and-groups} - -**RunAsUser** - 控制使用哪个用户 ID 来运行容器。 - - - *MustRunAs* - 必须配置一个 `range`。使用该范围内的第一个值作为默认值。 - 所有 range 值都被用于验证检查。 -- *MustRunAsNonRoot* - 要求提交的 Pod 具有非零 `runAsUser` 值，或在镜像中 - （使用 UID 数值）定义了 `USER` 环境变量。 - 如果 Pod 既没有设置 `runAsNonRoot`，也没有设置 `runAsUser`，则该 Pod 会被 - 修改以设置 `runAsNonRoot=true`，从而要求容器通过 `USER` 指令给出非零的数值形式 - 的用户 ID。此配置没有默认值。采用此配置时，强烈建议设置 - `allowPrivilegeEscalation=false`。 -- *RunAsAny* - 没有提供默认值。允许指定任何 `runAsUser` 配置。 - - -**RunAsGroup** - 控制运行容器时使用的主用户组 ID。 - - - *MustRunAs* - 要求至少指定一个 `range` 值。第一个 range - 中的最小值作为默认值。所有 range 值都被用来执行验证检查。 - - *MayRunAs* - 不要求设置 `RunAsGroup`。 - 不过，如果指定了 `RunAsGroup` 被设置，所设置值必须处于所定义的范围内。 - - *RunAsAny* - 未指定默认值。允许 `runAsGroup` 设置任何值。 - - -**SupplementalGroups** - 控制容器可以添加的组 ID。 - - - *MustRunAs* - 要求至少指定一个 `range` 值。 - 第一个 range 中的最小值用作默认值。 - 所有 range 值都被用来执行验证检查。 - - *MayRunAs* - 要求至少指定一个 `range` 值。 - 允许不指定 `supplementalGroups` 且不设置默认值。 - 如果 `supplementalGroups` 被设置，则所有 range 值都被用来执行验证检查。 - - *RunAsAny* - 未指定默认值。允许为 `supplementalGroups` 设置任何值。 - - -### 特权提升 {#privilege-escalation} - -这一组选项控制容器的`allowPrivilegeEscalation` 属性。该属性直接决定是否为 -容器进程设置 -[`no_new_privs`](https://www.kernel.org/doc/Documentation/prctl/no_new_privs.txt) -参数。此参数会禁止 `setuid` 属性的可执行文件更改有效用户 ID（EUID），并且 -禁止启用额外权能的文件。例如，`no_new_privs` 会禁止使用 `ping` 工具。 -如果想有效地实施 `MustRunAsNonRoot` 控制，需要配置这一选项。 - - -**AllowPrivilegeEscalation** - 决定是否用户可以将容器的安全上下文设置为 -`allowPrivilegeEscalation=true`。默认设置下，这样做是允许的，目的是避免 -造成现有的 `setuid` 应用无法运行。将此选项设置为 `false` 可以确保容器的所有 -子进程都无法获得比父进程更多的特权。 - - -**DefaultAllowPrivilegeEscalation** - 为 `allowPrivilegeEscalation` 选项设置 -默认值。不设置此选项时的默认行为是允许特权提升，以便运行 setuid 程序。 -如果不希望运行 setuid 程序，可以使用此字段将选项的默认值设置为禁止，同时 -仍然允许 Pod 显式地请求 `allowPrivilegeEscalation`。 - - -### 权能字 {#capabilities} - -Linux 权能字（Capabilities）将传统上与超级用户相关联的特权作了细粒度的分解。 -其中某些权能字可以用来提升特权，打破容器边界，可以通过 PodSecurityPolicy -来限制。关于 Linux 权能字的更多细节，可参阅 -[capabilities(7)](http://man7.org/linux/man-pages/man7/capabilities.7.html)。 - -下列字段都可以配置为权能字的列表。表中的每一项都是 `ALL_CAPS` 中的一个权能字 -名称，只是需要去掉 `CAP_` 前缀。 - - -**AllowedCapabilities** - 给出可以被添加到容器的权能字列表。 -默认的权能字集合是被隐式允许的那些。空集合意味着只能使用默认权能字集合， -不允许添加额外的权能字。`*` 可以用来设置允许所有权能字。 - - -**RequiredDropCapabilities** - 必须从容器中去除的权能字。 -所给的权能字会从默认权能字集合中去除，并且一定不可以添加。 -`RequiredDropCapabilities` 中列举的权能字不能出现在 -`AllowedCapabilities` 或 `DefaultAddCapabilities` 所给的列表中。 - - -**DefaultAddCapabilities** - 默认添加到容器的权能字集合。 -这一集合是作为容器运行时所设值的补充。 -关于使用 Docker 容器运行引擎时默认的权能字列表，可参阅 -[Docker 文档](https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities)。 - - -### SELinux - -- *MustRunAs* - 要求必须配置 `seLinuxOptions`。默认使用 `seLinuxOptions`。 - 针对 `seLinuxOptions` 所给值执行验证检查。 -- *RunAsAny* - 没有提供默认值。允许任意指定的 `seLinuxOptions` 选项。 - - -### AllowedProcMountTypes - -`allowedProcMountTypes` 是一组可以允许的 proc 挂载类型列表。 -空表或者 nil 值表示只能使用 `DefaultProcMountType`。 - -`DefaultProcMount` 使用容器运行时的默认值设置来决定 `/proc` 的只读挂载模式 -和路径屏蔽。大多数容器运行时都会屏蔽 `/proc` 下面的某些路径以避免特殊设备或 -信息被不小心暴露给容器。这一配置使所有 `Default` 字符串值来表示。 - -此外唯一的ProcMountType 是 `UnmaskedProcMount`，意味着即将绕过容器运行时的 -路径屏蔽行为，确保新创建的 `/proc` 不会被容器修改。此配置用字符串 -`Unmasked` 来表示。 - - -### AppArmor - -通过 PodSecurityPolicy 上的注解来控制。 -详情请参阅 -[AppArmor 文档](/zh/docs/tutorials/policy/apparmor/#podsecuritypolicy-annotations)。 - - - -### Seccomp - -Pod 对 seccomp 模版的使用可以通过在 PodSecurityPolicy 上设置注解来控制。 -Seccomp 是 Kubernetes 的一项 alpha 阶段特性。 - -**seccomp.security.alpha.kubernetes.io/defaultProfileName** - 注解用来 -指定为容器配置默认的 seccomp 模版。可选值为： - - -- `unconfined` - 如果没有指定其他替代方案，Seccomp 不会被应用到容器进程上 - （Kubernets 中的默认设置）。 -- `runtime/default` - 使用默认的容器运行时模版。 -- `docker/default` - 使用 Docker 的默认 seccomp 模版。自 1.11 版本废弃。 - 应改为使用 `runtime/default`。 -- `localhost/<路径名>` - 指定节点上路径 `/<路径名>` 下的一个 - 文件作为其模版。其中 `` 是通过 `kubelet` 的标志 - `--seccomp-profile-root` 来指定的。 - - -**seccomp.security.alpha.kubernetes.io/allowedProfileNames** - 指定可以为 -Pod seccomp 注解配置的值的注解。取值为一个可用值的列表。 -表中每项可以是上述各值之一，还可以是 `*`，用来表示允许所有的模版。 -如果没有设置此注解，意味着默认的 seccomp 模版是不可更改的。 - - -### Sysctl - -默认情况下，所有的安全的 sysctl 都是被允许的。 - - -- `forbiddenSysctls` - 用来排除某些特定的 sysctl。 - 你可以在此列表中禁止一些安全的或者不安全的 sysctl。 - 此选项设置为 `*` 意味着禁止设置所有 sysctl。 -- `allowedUnsafeSysctls` - 用来启用那些被默认列表所禁用的 sysctl， - 前提是所启用的 sysctl 没有被列在 `forbiddenSysctls` 中。 - -参阅 [Sysctl 文档](/zh/docs/tasks/administer-cluster/sysctl-cluster/#podsecuritypolicy)。 - -## {{% heading "whatsnext" %}} - - -- 参阅 [PodSecurityPolicy Deprecation: Past, Present, and - Future](/blog/2021/04/06/podsecuritypolicy-deprecation-past-present-and-future/)，了解 Pod 安全策略的未来。 - -- 参阅[Pod 安全标准](/zh/docs/concepts/security/pod-security-standards/) - 了解策略建议。 -- 阅读 [Pod 安全策略参考](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#podsecuritypolicy-v1beta1-policy)了解 API 细节。 From 0bb7611b6dac913d3b60535cb74099843a32177c Mon Sep 17 00:00:00 2001 From: Arhell Date: Sun, 10 Apr 2022 09:26:33 +0300 Subject: [PATCH 19/27] [ja] fix wrong path --- .../tools/kubeadm/setup-ha-etcd-with-kubeadm.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md b/content/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md index 6a8958dbb1..9c2939792c 100644 --- a/content/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md +++ b/content/ja/docs/setup/production-environment/tools/kubeadm/setup-ha-etcd-with-kubeadm.md @@ -242,8 +242,8 @@ this example. ```sh root@HOST0 $ kubeadm init phase etcd local --config=/tmp/${HOST0}/kubeadmcfg.yaml - root@HOST1 $ kubeadm init phase etcd local --config=/tmp/${HOST1}/kubeadmcfg.yaml - root@HOST2 $ kubeadm init phase etcd local --config=/tmp/${HOST2}/kubeadmcfg.yaml + root@HOST1 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml + root@HOST2 $ kubeadm init phase etcd local --config=$HOME/kubeadmcfg.yaml ``` 1. Optional: Check the cluster health From d1fb823abc10ca9dfbe715d8f09b0d9801ccf5fb Mon Sep 17 00:00:00 2001 From: "xin.li" Date: Mon, 11 Apr 2022 09:26:36 +0800 Subject: [PATCH 20/27] [zh] Update addons.md Signed-off-by: xin.li --- content/zh/docs/concepts/cluster-administration/addons.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/content/zh/docs/concepts/cluster-administration/addons.md b/content/zh/docs/concepts/cluster-administration/addons.md index 15b9efe804..d12aa56282 100644 --- a/content/zh/docs/concepts/cluster-administration/addons.md +++ b/content/zh/docs/concepts/cluster-administration/addons.md @@ -39,7 +39,7 @@ Add-ons 扩展了 Kubernetes 的功能。 * [OVN4NFV-K8S-Plugin](https://github.com/opnfv/ovn4nfv-k8s-plugin) is OVN based CNI controller plugin to provide cloud native based Service function chaining(SFC), Multiple OVN overlay networking, dynamic subnet creation, dynamic creation of virtual networks, VLAN Provider network, Direct provider network and pluggable with other Multi-network plugins, ideal for edge based cloud native workloads in Multi-cluster networking * [NSX-T](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) Container Plug-in (NCP) provides integration between VMware NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift. * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) is an SDN platform that provides policy-based networking between Kubernetes Pods and non-Kubernetes environments with visibility and security monitoring. -* [Romana](http://romana.io) is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize). +* **Romana** is a Layer 3 networking solution for pod networks that also supports the [NetworkPolicy API](/docs/concepts/services-networking/network-policies/). Kubeadm add-on installation details available [here](https://github.com/romana/romana/tree/master/containerize). * [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) provides networking and network policy, will carry on working on both sides of a network partition, and does not require an external database. --> ## 网络和网络策略 @@ -79,8 +79,8 @@ Add-ons 扩展了 Kubernetes 的功能。 CaaS / PaaS 平台（例如关键容器服务（PKS）和 OpenShift）之间的集成。 * [Nuage](https://github.com/nuagenetworks/nuage-kubernetes/blob/v5.1.1-1/docs/kubernetes-1-installation.rst) 是一个 SDN 平台，可在 Kubernetes Pods 和非 Kubernetes 环境之间提供基于策略的联网，并具有可视化和安全监控。 -* [Romana](https://romana.io) 是一个 pod 网络的第三层解决方案，并支持[ - NetworkPolicy API](/zh/docs/concepts/services-networking/network-policies/)。 +* Romana 是一个 pod 网络的第三层解决方案，并支持 + [NetworkPolicy API](/zh/docs/concepts/services-networking/network-policies/)。 Kubeadm add-on 安装细节可以在[这里](https://github.com/romana/romana/tree/master/containerize)找到。 * [Weave Net](https://www.weave.works/docs/net/latest/kubernetes/kube-addon/) 提供在网络分组两端参与工作的网络和网络策略，并且不需要额外的数据库。 From 004ee5e7931a2d1915c07457d5aff30a17066e9c Mon Sep 17 00:00:00 2001 From: Mengjiao Liu Date: Mon, 11 Apr 2022 10:42:40 +0800 Subject: [PATCH 21/27] [zh] Fix wrong link in garbage-collection file --- .../administer-cluster/use-cascading-deletion.md | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-) diff --git a/content/zh/docs/tasks/administer-cluster/use-cascading-deletion.md b/content/zh/docs/tasks/administer-cluster/use-cascading-deletion.md index c2b722ee29..a01fc21f86 100644 --- a/content/zh/docs/tasks/administer-cluster/use-cascading-deletion.md +++ b/content/zh/docs/tasks/administer-cluster/use-cascading-deletion.md @@ -11,11 +11,12 @@ content_type: task 本页面向你展示如何设置在你的集群执行{{}} -时要使用的[级联删除](/zh/docs/concepts/workloads/controllers/garbage-collection/#cascading-deletion) +时要使用的[级联删除](/zh/docs/concepts/architecture/garbage-collection/#cascading-deletion) 类型。 ## {{% heading "prerequisites" %}} @@ -64,14 +65,14 @@ apiVersion: v1 ## 使用前台级联删除 {#use-foreground-cascading-deletion} -默认情况下，Kubernetes 使用[后台级联删除](/zh/docs/concepts/workloads/controllers/garbage-collection/#background-deletion) +默认情况下，Kubernetes 使用[后台级联删除](/zh/docs/concepts/architecture/garbage-collection/#background-deletion) 以删除依赖某对象的其他对象。取决于你的集群所运行的 Kubernetes 版本， 你可以使用 `kubectl` 或者 Kubernetes API 来切换到前台级联删除。 {{}} @@ -188,7 +189,7 @@ For details, read the [documentation for your Kubernetes version](/docs/home/sup 输出中包含 `foregroundDeletion` {{}}， 类似这样： - ```none + ``` "kind": "Deployment", "apiVersion": "apps/v1", "metadata": { @@ -528,5 +529,5 @@ kubectl get pods -l app=nginx --> * 了解 Kubernetes 中的[属主与依赖](/zh/docs/concepts/overview/working-with-objects/owners-dependents/) * 了解 Kubernetes [finalizers](/zh/docs/concepts/overview/working-with-objects/finalizers/) -* 了解[垃圾收集](/zh/docs/concepts/workloads/controllers/garbage-collection/). +* 了解[垃圾收集](/zh/docs/concepts/architecture/garbage-collection/). From d62122cecb47f1a275b880cb210d8d9350ff1638 Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 11 Apr 2022 15:16:06 +0900 Subject: [PATCH 22/27] [ja] Translate tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents into Japanese (#31304) * done * Update content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md Co-authored-by: nasa9084 Co-authored-by: nasa9084 --- ...migrating-telemetry-and-security-agents.md | 70 +++++++++++++++++++ 1 file changed, 70 insertions(+) create mode 100644 content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md diff --git a/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md b/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md new file mode 100644 index 0000000000..a3b9a03d18 --- /dev/null +++ b/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md @@ -0,0 +1,70 @@ +--- +title: dockershimからテレメトリーやセキュリティエージェントを移行する +content_type: task +weight: 70 +--- + + + +Kubernetes 1.20でdockershimは非推奨になりました。 + +[Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/)から、ほとんどのアプリがコンテナをホストするランタイムに直接依存しないことは既にご存知かもしれません。 +しかし、コンテナのメタデータやログ、メトリクスを収集するためにDockerに依存しているテレメトリーやセキュリティエージェントはまだ多く存在します。 +この文書では、これらの依存関係を検出する方法と、これらのエージェントを汎用ツールまたは代替ランタイムに移行する方法に関するリンクを集約しています。 + +## テレメトリーとセキュリティエージェント + +Kubernetesクラスター上でエージェントを実行するには、いくつかの方法があります。エージェントはノード上で直接、またはDaemonSetとして実行することができます。 + +### テレメトリーエージェントがDockerに依存する理由とは？ + +歴史的には、KubernetesはDockerの上に構築されていました。 +Kubernetesはネットワークとスケジューリングを管理し、Dockerはコンテナをノードに配置して操作していました。 +そのため、KubernetesからはPod名などのスケジューリング関連のメタデータを、Dockerからはコンテナの状態情報を取得することができます。 +時が経つにつれ、コンテナを管理するためのランタイムも増えてきました。 +また、多くのランタイムにまたがるコンテナ状態情報の抽出を一般化するプロジェクトやKubernetesの機能もあります。 + +いくつかのエージェントはDockerツールに関連しています。 +エージェントは[`docker ps`](https://docs.docker.com/engine/reference/commandline/ps/)や[`docker top`](https://docs.docker.com/engine/reference/commandline/top/)といったコマンドを実行し、コンテナやプロセスの一覧を表示します。 +または[docker logs](https://docs.docker.com/engine/reference/commandline/logs/)を使えば、dockerログを購読することができます。 + +Dockerがコンテナランタイムとして非推奨になったため、これらのコマンドはもう使えません。 + +### Dockerに依存するDaemonSetの特定 {#identify-docker-dependency} + +Podがノード上で動作している`dockerd`を呼び出したい場合、Podは以下のいずれかを行う必要があります。 + +- Dockerデーモンの特権ソケットがあるファイルシステムを{{< glossary_tooltip text="volume" term_id="volume" >}}のようにマウントする。 + +- Dockerデーモンの特権ソケットの特定のパスを直接ボリュームとしてマウントします。 + +例: COSイメージでは、DockerはそのUnixドメインソケットを`/var/run/docker.sock`に公開します。 +つまり、Pod仕様には`/var/run/docker.sock`の`hostPath`ボリュームマウントが含まれることになります。 + +以下は、Dockerソケットを直接マッピングしたマウントを持つPodを探すためのシェルスクリプトのサンプルです。 + +このスクリプトは、Podの名前空間と名前を出力します。 + +`grep '/var/run/docker.sock'`を削除して、他のマウントを確認することもできます。 + +```bash +kubectl get pods --all-namespaces \ +-o=jsonpath='{range .items[*]}{"\n"}{.metadata.namespace}{":\t"}{.metadata.name}{":\t"}{range .spec.volumes[*]}{.hostPath.path}{", "}{end}{end}' \ +| sort \ +| grep '/var/run/docker.sock' +``` + +{{< note >}} +Podがホスト上のDockerにアクセスするための代替方法があります。 +例えば、フルパスの代わりに親ディレクトリ`/var/run`をマウントすることができます([この例](https://gist.github.com/itaysk/7bc3e56d69c4d72a549286d98fd557dd) のように)。 +上記のスクリプトは、最も一般的な使用方法のみを検出します。 +{{< /note >}} + +### ノードエージェントからDockerの依存性を検出する + +クラスターノードをカスタマイズし、セキュリティやテレメトリーのエージェントをノードに追加インストールする場合、エージェントのベンダーにDockerへの依存性があるかどうかを必ず確認してください。 + +### テレメトリーとセキュリティエージェントのベンダー + +様々なテレメトリーおよびセキュリティエージェントベンダーのための移行指示の作業中バージョンを[Google doc](https://docs.google.com/document/d/1ZFi4uKit63ga5sxEiZblfb-c23lFhvy6RXVPikS8wf0/edit#)に保管しています。 +dockershimからの移行に関する最新の手順については、各ベンダーにお問い合わせください。 From eeaee1f058cfcaed3dce7a0f8e77c3151d7bc458 Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 11 Apr 2022 15:22:06 +0900 Subject: [PATCH 23/27] [ja] Translate tasks/administer-cluster/kubeadm/configure-cgroup-driver into Japanese (#31222) * done * self review * fix * Update content/ja/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md Co-authored-by: nasa9084 * Update content/ja/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md Co-authored-by: nasa9084 Co-authored-by: nasa9084 --- .../kubeadm/configure-cgroup-driver.md | 104 ++++++++++++++++++ 1 file changed, 104 insertions(+) create mode 100644 content/ja/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md diff --git a/content/ja/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md b/content/ja/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md new file mode 100644 index 0000000000..90205b6106 --- /dev/null +++ b/content/ja/docs/tasks/administer-cluster/kubeadm/configure-cgroup-driver.md @@ -0,0 +1,104 @@ +--- +title: cgroupドライバーの設定 +content_type: task +weight: 10 +--- + + + +このページでは、kubeadmクラスターのコンテナランタイムcgroupドライバーに合わせて、kubelet cgroupドライバーを設定する方法について説明します。 + +## {{% heading "prerequisites" %}} + +Kubernetesの[コンテナランタイムの要件](/docs/setup/production-environment/container-runtimes)を熟知している必要があります。 + + + +## コンテナランタイムのcgroupドライバーの設定 + +[Container runtimes](/docs/setup/production-environment/container-runtimes)ページでは、kubeadmベースのセットアップでは`cgroupfs`ドライバーではなく、`systemd`ドライバーが推奨されると説明されています。 + +このページでは、デフォルトの`systemd`ドライバーを使用して多くの異なるコンテナランタイムをセットアップする方法についての詳細も説明されています。 + +## kubelet cgroupドライバーの設定 + +kubeadmでは、`kubeadm init`の際に`KubeletConfiguration`構造体を渡すことができます。 + +この`KubeletConfiguration`には、kubeletのcgroupドライバーを制御する`cgroupDriver`フィールドを含めることができます。 + +{{< note >}} +v1.22では、ユーザーが`KubeletConfiguration`の`cgroupDriver`フィールドを設定していない場合、`kubeadm`はデフォルトで`systemd`を設定するようになりました。 +{{< /note >}} + +フィールドを明示的に設定する最小限の例です: + +```yaml +# kubeadm-config.yaml +kind: ClusterConfiguration +apiVersion: kubeadm.k8s.io/v1beta3 +kubernetesVersion: v1.21.0 +--- +kind: KubeletConfiguration +apiVersion: kubelet.config.k8s.io/v1beta1 +cgroupDriver: systemd +``` + +このような設定ファイルは、kubeadmコマンドに渡すことができます: + +```shell +kubeadm init --config kubeadm-config.yaml +``` + +{{< note >}} +Kubeadmはクラスター内の全ノードで同じ`KubeletConfiguration`を使用します。 + +`KubeletConfiguration`は`kube-system`名前空間下の[ConfigMap](/docs/concepts/configuration/configmap)オブジェクトに格納されます。 + +サブコマンド`init`、`join`、`upgrade`を実行すると、kubeadmが`KubeletConfiguration`を`/var/lib/kubelet/config.yaml`以下にファイルとして書き込み、ローカルノードのkubeletに渡します。 +{{< /note >}} + +## cgroupfsドライバーの使用 + +このガイドで説明するように、`cgroupfs`ドライバーをkubeadmと一緒に使用することは推奨されません。 +`cgroupfs`を使い続け、`kubeadm upgrade`が既存のセットアップで`KubeletConfiguration` cgroupドライバーを変更しないようにするには、その値を明示的に指定する必要があります。 +これは、将来のバージョンのkubeadmに`systemd`ドライバーをデフォルトで適用させたくない場合に適用されます。 +値を明示する方法については、後述の「kubelet ConfigMapの修正」の項を参照してください。 +`cgroupfs`ドライバーを使用するようにコンテナランタイムを設定したい場合は、選択したコンテナランタイムのドキュメントを参照する必要があります。 + +## `systemd`ドライバーへの移行 + +既存のkubeadmクラスターのcgroupドライバーを`systemd`にインプレースで変更する場合は、kubeletのアップグレードと同様の手順が必要です。 +これには、以下に示す両方の手順を含める必要があります。 + +{{< note >}} +あるいは、クラスター内の古いノードを`systemd`ドライバーを使用する新しいノードに置き換えることも可能です。 +この場合、新しいノードに参加する前に以下の最初のステップのみを実行し、古いノードを削除する前にワークロードが新しいノードに安全に移動できることを確認する必要があります。 +{{< /note >}} + +### kubelet ConfigMapの修正 + +- `kubectl get cm -n kube-system | grep kubelet-config`で、kubelet ConfigMapの名前を探します。 +- `kubectl edit cm kubelet-config-x.yy -n kube-system`を呼び出します(`x.yy`はKubernetesのバージョンに置き換えてください)。 +- 既存の`cgroupDriver`の値を修正するか、以下のような新しいフィールドを追加します。 + +``yaml + cgroupDriver: systemd +``` + +このフィールドは、ConfigMapの`kubelet:`セクションの下に存在する必要があります。 + +### 全ノードでcgroupドライバーを更新 + +クラスター内の各ノードについて: + +- [Drain the node](/docs/tasks/administer-cluster/safely-drain-node)を`kubectl drain --ignore-daemonsets`を使ってドレーンします。 +- `systemctl stop kubelet`を使用して、kubeletを停止します。 +- コンテナランタイムの停止。 +- コンテナランタイムのcgroupドライバーを`systemd`に変更します。 +- `var/lib/kubelet/config.yaml`に`cgroupDriver: systemd`を設定します。 +- コンテナランタイムの開始。 +- `systemctl start kubelet`でkubeletを起動します。 +- [Drain the node](/docs/tasks/administer-cluster/safely-drain-node)を`kubectl uncordon `を使って行います。 + +ワークロードが異なるノードでスケジュールするための十分な時間を確保するために、これらのステップを1つずつノード上で実行します。 +プロセスが完了したら、すべてのノードとワークロードが健全であることを確認します。 From feebdc06d07f4f3e2c5e137e844b6742ecc04576 Mon Sep 17 00:00:00 2001 From: Wang Date: Mon, 11 Apr 2022 15:24:05 +0900 Subject: [PATCH 24/27] [ja] Translate tasks/administer-cluster/migrating-from-dockershim into Japanese (#31322) * new pr * Update content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md Co-authored-by: nasa9084 Co-authored-by: nasa9084 --- .../migrating-from-dockershim/_index.md | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) create mode 100644 content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md diff --git a/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md b/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md new file mode 100644 index 0000000000..b93d71071e --- /dev/null +++ b/content/ja/docs/tasks/administer-cluster/migrating-from-dockershim/_index.md @@ -0,0 +1,18 @@ +--- +title: dockershimからの移行 +weight: 10 +content_type: task +--- + + + +dockershimから他のコンテナランタイムに移行する際に知っておくべき情報を紹介します。 + +Kubernetes 1.20で[dockershim deprecation](blog/2020/12/08/kubernetes-1-20-release-announcement/#dockershim-deprecation)が発表されてから、様々なワークロードやKubernetesインストールにどう影響するのかという質問が寄せられています。 + +この問題をよりよく理解するために、[Dockershim Deprecation FAQ](/blog/2020/12/02/dockershim-faq/)ブログが役に立つでしょう。 + +dockershimから代替のコンテナランタイムに移行することが推奨されます。 +[コンテナランタイム](/ja/docs/setup/production-environment/container-runtimes/)のセクションをチェックして、どのような選択肢があるかを確認してください。 +問題が発生した場合は、必ず[問題の報告](https://github.com/kubernetes/kubernetes/issues)をしてください。 +そうすれば、問題が適時に修正され、クラスターがdockershimの削除に対応できるようになります。 From 4fdd4979883361624a3f2fe010a96ba5af5a722f Mon Sep 17 00:00:00 2001 From: Arhell Date: Mon, 11 Apr 2022 11:19:09 +0300 Subject: [PATCH 25/27] [zh] update scheduler configuration sample version --- .../docs/concepts/scheduling-eviction/resource-bin-packing.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md b/content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md index 46442f5868..6b25f6f80f 100644 --- a/content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md +++ b/content/zh/docs/concepts/scheduling-eviction/resource-bin-packing.md @@ -69,7 +69,7 @@ resources `intel.com/foo` and `intel.com/bar`. `intel.com/foo` 和 `intel.com/bar` 的装箱行为 ```yaml -apiVersion: kubescheduler.config.k8s.io/v1beta1 +apiVersion: kubescheduler.config.k8s.io/v1beta3 kind: KubeSchedulerConfiguration profiles: # ... From 164bdfa5a1f344895b6a808a6eebfd498d44fe2e Mon Sep 17 00:00:00 2001 From: Mengjiao Liu Date: Mon, 11 Apr 2022 17:50:08 +0800 Subject: [PATCH 26/27] Update links in file default-storage-class-prereqs.md to avoid using targets that are redirected. --- content/en/includes/default-storage-class-prereqs.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/en/includes/default-storage-class-prereqs.md b/content/en/includes/default-storage-class-prereqs.md index 57758ef66e..8bf132be51 100644 --- a/content/en/includes/default-storage-class-prereqs.md +++ b/content/en/includes/default-storage-class-prereqs.md @@ -1,6 +1,6 @@ You need to either have a [dynamic PersistentVolume provisioner](/docs/concepts/storage/dynamic-provisioning/) with a default [StorageClass](/docs/concepts/storage/storage-classes/), -or [statically provision PersistentVolumes](/docs/user-guide/persistent-volumes/#provisioning) -yourself to satisfy the [PersistentVolumeClaims](/docs/user-guide/persistent-volumes/#persistentvolumeclaims) +or [statically provision PersistentVolumes](/docs/concepts/storage/persistent-volumes/#provisioning) +yourself to satisfy the [PersistentVolumeClaims](/docs/concepts/storage/persistent-volumes/#persistentvolumeclaims) used here. From 5b50040c54a17643e17aa6d248f283471cf02a61 Mon Sep 17 00:00:00 2001 From: 0xff-dev Date: Fri, 8 Apr 2022 14:43:41 +0800 Subject: [PATCH 27/27] [zh] sync resource-metrics-pipeline.md --- .../resource-metrics-pipeline.md | 421 ++++++++++++++---- 1 file changed, 336 insertions(+), 85 deletions(-) diff --git a/content/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md b/content/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md index 635c8c429d..d30724cb2f 100644 --- a/content/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md +++ b/content/zh/docs/tasks/debug-application-cluster/resource-metrics-pipeline.md @@ -13,56 +13,249 @@ content_type: concept -资源使用指标，例如容器 CPU 和内存使用率，可通过 Metrics API 在 Kubernetes 中获得。 -这些指标可以直接被用户访问，比如使用 `kubectl top` 命令行，或者被集群中的控制器 -（例如 Horizontal Pod Autoscalers) 使用来做决策。 + +对于 Kubernetes，_Metrics API_ 提供了一组基本的指标，以支持自动伸缩和类似的用例。 +该 API 提供有关节点和 Pod 的资源使用情况的信息， +包括 CPU 和内存的指标。如果将 Metrics API 部署到集群中， +那么 Kubernetes API 的客户端就可以查询这些信息，并且可以使用 Kubernetes 的访问控制机制来管理权限。 + +[HorizontalPodAutoscaler](/zh/docs/tasks/run-application/horizontal-pod-autoscale/) (HPA) 和 +[VerticalPodAutoscaler](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler#readme) (VPA) +使用 metrics API 中的数据调整工作负载副本和资源，以满足客户需求。 + +你也可以通过 [`kubectl top`](/zh/docs/reference/generated/kubectl/kubectl-commands#top) 命令来查看资源指标。 + +{{< note >}} + +Metrics API 及其启用的指标管道仅提供最少的 CPU 和内存指标，以启用使用 HPA 和/或 VPA 的自动扩展。 +如果你想提供更完整的指标集，你可以通过部署使用 _Custom Metrics API_ 的第二个 +[指标管道](/zh/docs/tasks/debug-application-cluster/resource-usage-monitoring/#full-metrics-pipeline) 来作为简单的 Metrics API 的补充。 +{{< /note >}} + + +图 1 说明了资源指标管道的架构。 + +{{< mermaid >}} +flowchart RL +subgraph cluster[Cluster] +direction RL +S[

] +A[Metrics-
Server] +subgraph B[Nodes] +direction TB +D[cAdvisor] --> C[kubelet] +E[Container
runtime] --> D +E1[Container
runtime] --> D +P[pod data] -.- C +end +L[API
server] +W[HPA] +C ---->|Summary
API| A -->|metrics
API| L --> W +end +L ---> K[kubectl
top] +classDef box fill:#fff,stroke:#000,stroke-width:1px,color:#000; +class W,B,P,K,cluster,D,E,E1 box +classDef spacewhite fill:#ffffff,stroke:#fff,stroke-width:0px,color:#000 +class S spacewhite +classDef k8s fill:#326ce5,stroke:#fff,stroke-width:1px,color:#fff; +class A,L,C k8s +{{< /mermaid >}} + + +图 1. 资源指标管道 + +图中从右到左的架构组件包括以下内容： + +* [cAdvisor](https://github.com/google/cadvisor): 用于收集、聚合和公开 Kubelet 中包含的容器指标的守护程序。 +* [kubelet](/zh/docs/concepts/overview/components/#kubelet): 用于管理容器资源的节点代理。 + 可以使用 `/metrics/resource` 和 `/stats` kubelet API 端点访问资源指标。 +* [Summary API](#summary-api-source): kubelet 提供的 API，用于发现和检索可通过 `/stats` 端点获得的每个节点的汇总统计信息。 +* [metrics-server](#metrics-server): 集群插件组件，用于收集和聚合从每个 kubelet 中提取的资源指标。 + API 服务器提供 Metrics API 以供 HPA、VPA 和 `kubectl top` 命令使用。 Metrics Server 是 Metrics API 的参考实现。 +* [Metrics API](#metrics-api): Kubernetes API 支持访问用于工作负载自动缩放的 CPU 和内存。 + 要在你的集群中进行这项工作，你需要一个提供 Metrics API 的 API 扩展服务器。 + + + {{< note >}} + cAdvisor 支持从 cgroups 读取指标，它适用于 Linux 上的典型容器运行时。 + 如果你使用基于其他资源隔离机制的容器运行时，例如虚拟化，那么该容器运行时必须支持 + [CRI 容器指标](https://github.com/kubernetes/community/blob/master/contributors/devel/sig-node/cri-container-stats.md) + 以便 kubelet 可以使用指标。 + {{< /note >}} ## Metrics API {#the-metrics-api} -通过 Metrics API，你可以获得指定节点或 Pod 当前使用的资源量。 -此 API 不存储指标值，因此想要获取某个指定节点 10 分钟前的 -资源使用量是不可能的。 +{{< feature-state for_k8s_version="1.8" state="beta" >}} + +metrics-server 实现了 Metrics API。此 API 允许你访问集群中节点和 Pod 的 CPU 和内存使用情况。 +它的主要作用是将资源使用指标提供给 K8s 自动缩放器组件。 + +下面是一个 `minikube` 节点的 Metrics API 请求示例，通过 `jq` 管道处理以便于阅读： + +```shell +kubectl get --raw "/apis/metrics.k8s.io/v1beta1/nodes/minikube" | jq '.' +``` + + +这是使用 `curl` 来执行的相同 API 调用： + +```shell +curl http://localhost:8080/apis/metrics.k8s.io/v1beta1/nodes/minikube +``` + + +响应示例： + +```json +{ + "kind": "NodeMetrics", + "apiVersion": "metrics.k8s.io/v1beta1", + "metadata": { + "name": "minikube", + "selfLink": "/apis/metrics.k8s.io/v1beta1/nodes/minikube", + "creationTimestamp": "2022-01-27T18:48:43Z" + }, + "timestamp": "2022-01-27T18:48:33Z", + "window": "30s", + "usage": { + "cpu": "487558164n", + "memory": "732212Ki" + } +} +``` -此 API 与其他 API 没有区别： + +下面是一个 `kube-system` 命名空间中的 `kube-scheduler-minikube` Pod 的 Metrics API 请求示例， +通过 `jq` 管道处理以便于阅读： + +```shell +kubectl get --raw "/apis/metrics.k8s.io/v1beta1/namespaces/kube-system/pods/kube-scheduler-minikube" | jq '.' +``` + + +这是使用 `curl` 来完成的相同 API 调用： + +```shell +curl http://localhost:8080/apis/metrics.k8s.io/v1beta1/namespaces/kube-system/pods/kube-scheduler-minikube +``` + + +响应示例： + +```json +{ + "kind": "PodMetrics", + "apiVersion": "metrics.k8s.io/v1beta1", + "metadata": { + "name": "kube-scheduler-minikube", + "namespace": "kube-system", + "selfLink": "/apis/metrics.k8s.io/v1beta1/namespaces/kube-system/pods/kube-scheduler-minikube", + "creationTimestamp": "2022-01-27T19:25:00Z" + }, + "timestamp": "2022-01-27T19:24:31Z", + "window": "30s", + "containers": [ + { + "name": "kube-scheduler", + "usage": { + "cpu": "9559630n", + "memory": "22244Ki" + } + } + ] +} +``` -- 此 API 和其它 Kubernetes API 一起位于同一端点（endpoint）之下且可发现， - 路径为 `/apis/metrics.k8s.io/` -- 它具有相同的安全性、可扩展性和可靠性保证 + +Metrics API 在 [k8s.io/metrics](https://github.com/kubernetes/metrics) 代码库中定义。 +你必须启用 [API 聚合层](/zh/docs/tasks/extend-kubernetes/configure-aggregation-layer/)并为 +`metrics.k8s.io` API 注册一个 [APIService](/zh/docs/reference/kubernetes-api/cluster-resources/api-service-v1/)。 + +要了解有关 Metrics API 的更多信息， +请参阅资源 [Resource Metrics API Design](https://github.com/kubernetes/design-proposals-archive/blob/main/instrumentation/resource-metrics-api.md)、 +[metrics-server 代码库](https://github.com/kubernetes-sigs/metrics-server) 和 +[Resource Metrics API](https://github.com/kubernetes/metrics#resource-metrics-api)。 -Metrics API 在 [k8s.io/metrics](https://github.com/kubernetes/metrics/blob/master/pkg/apis/metrics/v1beta1/types.go) -仓库中定义。你可以在那里找到有关 Metrics API 的更多信息。 - - {{< note >}} -Metrics API 需要在集群中部署 Metrics Server。否则它将不可用。 +你必须部署提供 Metrics API 服务的 metrics-server 或其他适配器才能访问它。 {{< /note >}} ## 度量资源用量 {#measuring-resource-usage} ### CPU -CPU 用量按其一段时间内的平均值统计，单位为 -[CPU 核](/zh/docs/concepts/configuration/manage-resources-containers/#meaning-of-cpu)。 -此度量值通过在内核（包括 Linux 和 Windows）提供的累积 CPU 计数器乘以一个系数得到。 -`kubelet` 组件负责选择计算系数所使用的窗口大小。 +CPU 报告为以 cpu 为单位测量的平均核心使用率。在 Kubernetes 中， +一个 cpu 相当于云提供商的 1 个 vCPU/Core，以及裸机 Intel 处理器上的 1 个超线程。 + +该值是通过对内核提供的累积 CPU 计数器（在 Linux 和 Windows 内核中）取一个速率得出的。 +用于计算 CPU 的时间窗口显示在 Metrics API 的窗口字段下。 + +要了解更多关于 Kubernetes 如何分配和测量 CPU 资源的信息，请参阅 +[CPU 的含义](/zh/docs/concepts/configuration/manage-resources-container/#meaning-of-cpu)。 ### 内存 {#memory} -内存用量按工作集（Working Set）的大小字节数统计，其数值为收集度量值的那一刻的内存用量。 -如果一切都很理想化，“工作集” 是任务在使用的内存总量，该内存是不可以在内存压力较大 -的情况下被释放的。 -不过，具体的工作集计算方式取决于宿主 OS，有很大不同，且通常都大量使用启发式 -规则来给出一个估计值。 -其中包含所有匿名内存使用（没有后台文件提供存储者），因为 Kubernetes 不支持交换分区。 -度量值通常包含一些高速缓存（有后台文件提供存储）内存，因为宿主操作系统并不是总能 -回收这些页面。 +内存报告为在收集度量标准的那一刻的工作集大小，以字节为单位。 + +在理想情况下，“工作集”是在内存压力下无法释放的正在使用的内存量。 +然而，工作集的计算因主机操作系统而异，并且通常大量使用启发式算法来产生估计。 + +Kubernetes 模型中，容器工作集是由容器运行时计算的与相关容器关联的匿名内存。 +工作集指标通常还包括一些缓存（文件支持）内存，因为主机操作系统不能总是回收页面。 + +要了解有关 Kubernetes 如何分配和测量内存资源的更多信息， +请参阅[内存的含义](/zh/docs/concepts/configuration/manage-resources-container/#meaning-of-memory)。 ## Metrics 服务器 {#metrics-server} -[Metrics 服务器](https://github.com/kubernetes-sigs/metrics-server) -是集群范围资源用量数据的聚合器。 -默认情况下，在由 `kube-up.sh` 脚本创建的集群中会以 Deployment 的形式被部署。 -如果你使用其他 Kubernetes 安装方法，则可以使用提供的 -[部署组件 components.yaml](https://github.com/kubernetes-sigs/metrics-server/releases) -来部署。 +metrics-server 从 kubelet 中获取资源指标，并通过 Metrics API 在 Kubernetes API 服务器中公开它们，以供 HPA 和 VPA 使用。 +你还可以使用 `kubectl top` 命令查看这些指标。 + +metrics-server 使用 Kubernetes API 来跟踪集群中的节点和 Pod。metrics-server 服务器通过 HTTP 查询每个节点以获取指标。 +metrics-server 还构建了 Pod 元数据的内部视图，并维护 Pod 健康状况的缓存。 +缓存的 Pod 健康信息可通过 metrics-server 提供的扩展 API 获得。 + +例如，对于 HPA 查询，metrics-server 需要确定哪些 Pod 满足 Deployment 中的标签选择器。 -Metric 服务器从每个节点上的 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) -公开的 Summary API 中采集指标信息。 -该 API 通过 -[Kubernetes 聚合器](/zh/docs/concepts/extend-kubernetes/api-extension/apiserver-aggregation/) -注册到主 API 服务器上。 +metrics-server 调用 [kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) API +从每个节点收集指标。根据它使用的度量服务器版本： + +* 版本 v0.6.0+ 中，使用指标资源端点 `/metrics/resource` +* 旧版本中使用 Summary API 端点 `/stats/summary` -在[设计文档](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md) -中可以了解到有关 Metrics 服务器的更多信息。 + +了解更多 metrics-server，参阅 [metrics-server 代码库](https://github.com/kubernetes-sigs/metrics-server)。 + +你还可以查看以下内容： + +* [metrics-server 设计](https://github.com/kubernetes/community/blob/master/contributors/design-proposals/instrumentation/metrics-server.md) +* [metrics-server FAQ](https://github.com/kubernetes-sigs/metrics-server/blob/master/FAQ.md) +* [metrics-server known issues](https://github.com/kubernetes-sigs/metrics-server/blob/master/KNOWN_ISSUES.md) +* [metrics-server releases](https://github.com/kubernetes-sigs/metrics-server/releases) +* [Horizontal Pod Autoscaling](/zh/docs/tasks/run-application/horizontal-pod-autoscale/) -### 摘要 API 来源 +### Summary API 来源 -[Kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 在节点、卷、pod 和容器级别收集统计信息， -并在[摘要API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go) +[Kubelet](/zh/docs/reference/command-line-tools-reference/kubelet/) 在节点、卷、Pod 和容器级别收集统计信息， +并在[Summary API](https://github.com/kubernetes/kubernetes/blob/7d309e0104fedb57280b261e5677d919cb2a0e2d/staging/src/k8s.io/kubelet/pkg/apis/stats/v1alpha1/types.go) 中提供它们的统计信息供消费者阅读。 -在 1.23 版本前，这些资源主要来自 [cAdvisor](https://github.com/google/cadvisor)。但在 1.23 版本中 -引入了 `PodAndContainerStatsFromCRI` FeatureGate， -CRI 实现了可以收集容器和 pod 级别的统计信息。 -注意：这需要 CRI 实现的支持（containerd >= 1.6.0，CRI-O >= 1.23.0）。 +下面是一个 `minikube` 节点的 Summary API 请求示例： + +```shell +kubectl get --raw "/api/v1/nodes/minikube/proxy/stats/summary" +``` + + +这是使用 `curl` 来执行的相同 API 调用： + +```shell +curl http://localhost:8080/api/v1/nodes/minikube/proxy/stats/summary +``` + +{{< note >}} + +从 metrics-server 0.6.x 开始，Summary API `/stats/summary` 端点被 `/metrics/resource` 端点替换。 +{{< /note >}}