jiebi/CodeConvo huggingface dataset:
The Kubernetes project recommends that you use the TokenReview API, because this method invalidates tokens that are bound to API objects such as Secrets, ServiceAccounts, and Pods when those objects are deleted. For example, if you <del> delete the Pod that contains a projected ServiceAccount token, the TokenReview API invalidates that token immediately. If you use OIDC validation instead, your clients continue to treat the token as valid until the token reaches its expiration timestamp. </del> <ins> delete the Pod that contains a projected ServiceAccount token, the cluster invalidates that token immediately and a TokenReview immediately fails. If you use OIDC validation instead, your clients continue to treat the token as valid until the token reaches its expiration timestamp. </ins> Your application should always define the audience that it accepts, and should check that the token's audiences match the audiences that the application expects. This helps to minimize the scope of the token so that it can only be <del> used in your appplication and nowhere else. </del> <ins> used in your application and nowhere else. </ins> ## Alternatives
{{% tab name="Linux" %}} <!-- <del> 1. Install the `containerd.io` package from the official Docker repositories. Instructions for setting up the Docker repository for your respective Linux distribution and installing the `containerd.io` package can be found at [Install Docker Engine](https://docs.docker.com/engine/install/#server). </del> <ins> 1. Install the `containerd.io` package from the official Docker repositories. Instructions for setting up the Docker repository for your respective Linux distribution and installing the `containerd.io` package can be found at [Install Docker Engine](https://docs.docker.com/engine/install/#server). </ins> --> 1. 从官方Docker仓库安装 `containerd.io` 软件包。可以在 [安装 Docker 引擎](https://docs.docker.com/engine/install/#server)
{{% tab name="Windows (PowerShell)" %}} <!-- <del> Start a Powershell session, set `$Version` to the desired version (ex: `$Version=1.4.3`), and then run the following commands: </del> <ins> Start a Powershell session, set `$Version` to the desired version (ex: `$Version=1.4.3`), and then run the following commands: </ins> --> <del> 启动 Powershell 会话，将 `$Version` 设置为所需的版本（例如：`$ Version=1.4.3`）， </del> <ins> 启动 Powershell 会话，将 `$Version` 设置为所需的版本（例如：`$Version=1.4.3`）， </ins> 然后运行以下命令： <!--
### Docker <!-- <del> 1. On each of your nodes, install the Docker for your Linux distribution as per [Install Docker Engine](https://docs.docker.com/engine/install/#server). You can find the latest validated version of Docker in this [dependencies](https://git.k8s.io/kubernetes/build/dependencies.yaml) file. </del> <ins> 1. On each of your nodes, install the Docker for your Linux distribution as per [Install Docker Engine](https://docs.docker.com/engine/install/#server). You can find the latest validated version of Docker in this [dependencies](https://git.k8s.io/kubernetes/build/dependencies.yaml) file. </ins> --> 1. 在每个节点上，根据[安装 Docker 引擎](https://docs.docker.com/engine/install/#server) 为你的 Linux 发行版安装 Docker。
{{< note >}} <!-- <del> `overlay2` is the preferred storage driver for systems running Linux kernel version 4.0 or higher, or RHEL or CentOS using version 3.10.0-514 and above. </del> <ins> `overlay2` is the preferred storage driver for systems running Linux kernel version 4.0 or higher, or RHEL or CentOS using version 3.10.0-514 and above. </ins> --> 对于运行 Linux 内核版本 4.0 或更高版本，或使用 3.10.0-51 及更高版本的 RHEL 或 CentOS 的系统，`overlay2`是首选的存储驱动程序。
| `BalanceAttachedNodeVolumes` | `false` | Alpha | 1.11 | | | `BoundServiceAccountTokenVolume` | `false` | Alpha | 1.13 | 1.20 | | `BoundServiceAccountTokenVolume` | `true` | Beta | 1.21 | | <ins> | `ControllerManagerLeaderMigration` | `false` | Alpha | 1.21 | | </ins> | `CPUManager` | `false` | Alpha | 1.8 | 1.9 | | `CPUManager` | `true` | Beta | 1.10 | | | `CSIInlineVolume` | `false` | Alpha | 1.15 | 1.15 |
extended tokens by starting `kube-apiserver` with flag `--service-account-extend-token-expiration=false`. Check [Bound Service Account Tokens](https://github.com/kubernetes/enhancements/blob/master/keps/sig-auth/1205-bound-service-account-tokens/README.md) for more details. <ins> - `ControllerManagerLeaderMigration`: Enables Leader Migration for [kube-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#initial-leader-migration-configuration) and [cloud-controller-manager](/docs/tasks/administer-cluster/controller-manager-leader-migration/#deploy-cloud-controller-manager) which allows a cluster operator to live migrate controllers from the kube-controller-manager into an external controller-manager (e.g. the cloud-controller-manager) in an HA cluster without downtime. </ins> - `CPUManager`: Enable container level CPU affinity support, see [CPU Management Policies](/docs/tasks/administer-cluster/cpu-management-policies/). - `CRIContainerLogRotation`: Enable container log rotation for CRI container runtime. The default max size of a log file is 10MB and the
No resources found in default namespace. ``` <del> To sum things up, when there's an override owner reference from a child to a parent, deleting the parent deletes the children automatically. This is called `cascade`. The default for cascade is `true`, however, you can use the --cascade=false option for `kubectl delete` to delete an object and orphan its children. </del> <ins> To sum things up, when there's an override owner reference from a child to a parent, deleting the parent deletes the children automatically. This is called `cascade`. The default for cascade is `true`, however, you can use the --cascade=orphan option for `kubectl delete` to delete an object and orphan its children. </ins> <del> In the following example, there is a parent and a child. Notice the owner references are still included. If I delete the parent using --cascade=false, the parent is deleted but the child still exists: </del> <ins> In the following example, there is a parent and a child. Notice the owner references are still included. If I delete the parent using --cascade=orphan, the parent is deleted but the child still exists: </ins> ``` kubectl get configmap
fields to be updated.  Also, the DaemonSet controller will use the original template the next time a node (even with the same name) is created. <del> You can delete a DaemonSet.  If you specify `--cascade=false` with `kubectl`, then the Pods </del> <ins> You can delete a DaemonSet.  If you specify `--cascade=orphan` with `kubectl`, then the Pods </ins> will be left on the nodes.  If you subsequently create a new DaemonSet with the same selector, the new DaemonSet adopts the existing Pods. If any Pods need replacing the DaemonSet replaces them according to its `updateStrategy`.
You can delete a ReplicationController without affecting any of its pods. <del> Using kubectl, specify the `--cascade=false` option to [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). </del> <ins> Using kubectl, specify the `--cascade=orphan` option to [`kubectl delete`](/docs/reference/generated/kubectl/kubectl-commands#delete). </ins> When using the REST API or Go client library, you can delete the ReplicationController object.
<h3>Kubernetes Service 总览</h3> <!--        <p>Kubernetes <a href="/docs/concepts/workloads/pods/pod-overview/">Pods</a> are mortal. Pods in fact have a <a href="/docs/concepts/workloads/pods/pod-lifecycle/">lifecycle</a>. When a worker node dies, the Pods running on the Node are also lost. A <a href="/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> might then dynamically drive the cluster back to desired state via creation of new Pods to keep your application running. As another example, consider an image-processing backend with 3 replicas. Those replicas are exchangeable; the front-end system should not care about backend replicas or even if a Pod is lost and recreated. That said, each Pod in a Kubernetes cluster has a unique IP address, even Pods on the same Node, so there needs to be a way of automatically reconciling changes among Pods so that your applications continue to function.</p>--> <del> <p> Kubernetes <a href="/zh/docs/concepts/workloads/pods/">Pod</a> 是转瞬即逝的。 Pod 实际上拥有 <a href="/zh/docs/concepts/workloads/pods/pod-lifecycle/">生命周期</a>。 当一个工作 Node 挂掉后, 在 Node 上运行的 Pod 也会消亡。 <a href="/zh/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> 会自动地通过创建新的 Pod 驱动集群回到目标状态，以保证应用程序正常运行。 换一个例子，考虑一个具有3个副本数的用作图像处理的后端程序。这些副本是可替换的; 前端系统不应该关心后端副本，即使 Pod 丢失或重新创建。也就是说，Kubernetes 集群中的每个 Pod (即使是在同一个 Node 上的 Pod )都有一个惟一的 IP 地址，因此需要一种方法自动协调 Pod 之间的变更，以便应用程序保持运行。</p> </del> <ins> <p> Kubernetes <a href="/zh/docs/concepts/workloads/pods/">Pod</a> 是转瞬即逝的。 Pod 实际上拥有 <a href="/zh/docs/concepts/workloads/pods/pod-lifecycle/">生命周期</a>。 当一个工作 Node 挂掉后, 在 Node 上运行的 Pod 也会消亡。 <a href="/zh/docs/concepts/workloads/controllers/replicaset/">ReplicaSet</a> 会自动地通过创建新的 Pod 驱动集群回到目标状态，以保证应用程序正常运行。 换一个例子，考虑一个具有3个副本数的用作图像处理的后端程序。这些副本是可替换的; 前端系统不应该关心后端副本，即使 Pod 丢失或重新创建。也就是说，Kubernetes 集群中的每个 Pod (即使是在同一个 Node 上的 Pod )都有一个唯一的 IP 地址，因此需要一种方法自动协调 Pod 之间的变更，以便应用程序保持运行。</p> </ins> <!--        <p>A Service in Kubernetes is an abstraction which defines a logical set of Pods and a policy by which to access them. Services enable a loose coupling between dependent Pods. A Service is defined using YAML <a href="/docs/concepts/configuration/overview/#general-configuration-tips">(preferred)</a> or JSON, like all Kubernetes objects. The set of Pods targeted by a Service is usually determined by a <i>LabelSelector</i> (see below for why you might want a Service without including <code>selector</code> in the spec).</p>--> <p> Kubernetes 中的服务(Service)是一种抽象概念，它定义了 Pod 的逻辑集和访问 Pod 的协议。Service 使从属 Pod 之间的松耦合成为可能。 和其他 Kubernetes 对象一样, Service 用 YAML <a href="/zh/docs/concepts/configuration/overview/#general-configuration-tips">(更推荐)</a> 或者 JSON 来定义. Service 下的一组 Pod 通常由 <i>LabelSelector</i> (请参阅下面的说明为什么您可能想要一个 spec 中不包含<code>selector</code>的服务)来标记。</p>
### Restricting profiles with the PodSecurityPolicy <ins> {{< note >}} PodSecurityPolicy is deprecated in Kubernetes v1.21, and will be removed in v1.25. See [PodSecurityPolicy documentation](/docs/concepts/policy/pod-security-policy/) for more information. {{< /note >}} </ins> If the PodSecurityPolicy extension is enabled, cluster-wide AppArmor restrictions can be applied. To enable the PodSecurityPolicy, the following flag must be set on the `apiserver`:
to the REST api. For further documentation refer to the authorization.v1beta1 API objects and <del> [webhook.go](https://github.com/kubernetes/kubernetes/blob/{{< param "githubbranch" >}}/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go). </del> <ins> [webhook.go](https://github.com/kubernetes/kubernetes/blob/master/staging/src/k8s.io/apiserver/plugin/pkg/authorizer/webhook/webhook.go). </ins>
Use `activeDeadlineSeconds` on the Pod to prevent init containers from failing forever. The active deadline includes init containers. <del> However it is recommended to use `activeDeadlineSeconds` if user deploy their application </del> <ins> However it is recommended to use `activeDeadlineSeconds` only if teams deploy their application </ins> as a Job, because `activeDeadlineSeconds` has an effect even after initContainer finished. The Pod which is already running correctly would be killed by `activeDeadlineSeconds` if you set.
힙스터에서 메트릭 가져오기는 Kubernetes 1.11에서 사용 중단(deprecated)됨. {{< /note >}} <del> 자세한 사항은 [메트릭 API를 위한 지원](#메트릭-API를-위한-지원)을 참조한다. </del> <ins> 자세한 사항은 [메트릭 API를 위한 지원](#메트릭-api를-위한-지원)을 참조한다. </ins> 오토스케일러는 스케일 하위 리소스를 사용하여 상응하는 확장 가능 컨트롤러(예: 레플리케이션 컨트롤러, 디플로이먼트, 레플리케이션 셋)에 접근한다. 스케일은 레플리카의 개수를 동적으로 설정하고 각 현재 상태를 검사 할 수 있게 해주는 인터페이스이다.
[params.ui] # Enable to show the side bar menu in its compact state. sidebar_menu_compact = false <ins> # https://github.com/gohugoio/hugo/issues/8918#issuecomment-903314696 sidebar_cache_limit = 1 </ins> #  Set to true to disable breadcrumb navigation. breadcrumb_disable = false #  Set to true to hide the sidebar search box (the top nav search box will still be displayed if search is enabled)
{{ range . }} {{ with (where $.section.Translations ".Lang" . ) -}} {{ $p := index . 0 -}} <del> {{ $pages =  $pages | lang.Merge (union $p.Pages $p.Sections) -}} </del> <ins> {{ $pages = where ( $pages | lang.Merge (union $p.Pages $p.Sections)) ".Params.toc_hide" "!=" true -}} </ins> {{ end -}} {{ end -}} {{ end -}}
See the [webhook response](#response) section for the data expected from webhooks. The example admission webhook server leaves the `ClientAuth` field <del> [empty](https://github.com/kubernetes/kubernetes/blob/v1.13.0/test/images/webhook/config.go#L47-L48), </del> <ins> [empty](https://github.com/kubernetes/kubernetes/blob/v1.22.0/test/images/agnhost/webhook/config.go#L38-L39), </ins> which defaults to `NoClientCert`. This means that the webhook server does not authenticate the identity of the clients, supposedly apiservers. If you need mutual TLS or other ways to authenticate the clients, see
<!-- This page covers how to customize the components that kubeadm deploys. For control plane components <del> you can use flags in the `ClusteConfiguration` structure or patches per-node. For the kubelet </del> <ins> you can use flags in the `ClusterConfiguration` structure or patches per-node. For the kubelet </ins> and kube-proxy you can use `KubeletConfiguration` and `KubeProxyConfiguration`, accordingly. All of these options are possible via the kubeadm configuration API. For more details on each field in the configuration you can navigate to our <del> [API reference pages](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3). </del> <ins> [API reference pages](/docs/reference/config-api/kubeadm-config.v1beta3/). </ins> --> 本页面介绍了如何自定义 kubeadm 部署的组件。 <del> 你可以使用 `ClusteConfiguration` 结构中定义的参数，或者在每个节点上应用补丁来定制控制平面组件。 </del> <ins> 你可以使用 `ClusterConfiguration` 结构中定义的参数，或者在每个节点上应用补丁来定制控制平面组件。 </ins> 你可以使用 `KubeletConfiguration` 和 `KubeProxyConfiguration` 结构分别定制 kubelet 和 kube-proxy 组件。 所有这些选项都可以通过 kubeadm 配置 API 实现。
To customize kube-proxy you can pass a `KubeProxyConfiguration` next your `ClusterConfiguration` or `InitConfiguration` to `kubeadm init` separated by `---`. <del> For more details you can navigate to our [API reference pages](https://godoc.org/k8s.io/kubernetes/cmd/kubeadm/app/apis/kubeadm/v1beta3). </del> <ins> For more details you can navigate to our [API reference pages](/docs/reference/config-api/kubeadm-config.v1beta3/). </ins> --> ## 自定义 kube-proxy   {#customizing-kube-proxy}
To make a report, submit your vulnerability to the [Kubernetes bug bounty program](https://hackerone.com/kubernetes). This allows triage and handling of the vulnerability with standardized response times. <del> You can also email the private [security@kubernetes.io](mailto:security@kubernetes.io) list with the security details and the details expected for [all Kubernetes bug reports](https://git.k8s.io/kubernetes/.github/ISSUE_TEMPLATE/bug-report.md). </del> <ins> You can also email the private [security@kubernetes.io](mailto:security@kubernetes.io) list with the security details and the details expected for [all Kubernetes bug reports](https://github.com/kubernetes/kubernetes/blob/master/.github/ISSUE_TEMPLATE/bug-report.yaml). </ins> You may encrypt your email to this list using the GPG keys of the [Security Response Committee members](https://git.k8s.io/security/README.md#product-security-committee-psc). Encryption using GPG is NOT required to make a disclosure.
### Reverting the Registry Name in kubelet <del> The image used by kubelet for the pod sandbox (`pause`) can be overridden by setting the `--pod-infra-container-image` flag. For example: </del> <ins> The image used by kubelet for the pod sandbox (`pause`) can be overridden by configuring your container runtime or by setting the `--pod-infra-container-image` flag depending on the version of Kubernetes you are using. Other runtimes: [containerd](/docs/setup/production-environment/container-runtimes/#override-pause-image-containerd), [CRI-O](/docs/setup/production-environment/container-runtimes/#override-pause-image-cri-o), [cri-dockerd](/docs/setup/production-environment/container-runtimes/#override-pause-image-cri-dockerd-mcr). When using dockershim before v1.23: </ins> ``` kubelet --pod-infra-container-image=k8s.gcr.io/pause:3.5
Your container runtime must support at least v1alpha2 of the container runtime interface. <del> Kubernetes {{< skew currentVersion >}}  defaults to using v1 of the CRI API. If a container runtime does not support the v1 API, the kubelet falls back to </del> <ins> Kubernetes [starting v1.26](/blog/2022/11/18/upcoming-changes-in-kubernetes-1-26/#cri-api-removal) _only works_ with v1 of the CRI API. Earlier versions default to v1 version, however if a container runtime does not support the v1 API, the kubelet falls back to </ins> using the (deprecated) v1alpha2 API instead. ## Container runtimes
You might need to restart `containerd` as well once you've updated the config file: `systemctl restart containerd`. <ins> Please note, that it is a best practice for kubelet to declare the matching `pod-infra-container-image`. If not configured, kubelet may attempt to garbage collect the `pause` image. There is ongoing work in [containerd to pin the pause image](https://github.com/containerd/containerd/issues/6352) and not require this setting on kubelet any longer. </ins> ### CRI-O This section contains the necessary steps to install CRI-O as a container runtime.
If you use Docker Engine via dockershim as your container runtime and wish to upgrade to v1.24, it is recommended that you either migrate to another runtime or find an alternative means to obtain Docker Engine support. Check out the [container runtimes](/docs/setup/production-environment/container-runtimes/) <del> section to know your options. Make sure to </del> <ins> section to know your options. The version of Kubernetes with dockershim (1.23) is out of support and the v1.24 will run out of support [soon](/releases/#release-v1-24). Make sure to </ins> [report issues](https://github.com/kubernetes/kubernetes/issues) you encountered with the migration so the issues can be fixed in a timely manner and your cluster would be <del> ready for dockershim removal. </del> <ins> ready for dockershim removal. After v1.24 running out of support, you will need to contact your Kubernetes provider for support or upgrade multiple versions at a time if there are critical issues affecting your cluster. </ins> Your cluster might have more than one kind of node, although this is not a common configuration.
* Check out [container runtimes](/docs/setup/production-environment/container-runtimes/) to understand your options for an alternative. <del> * There is a [GitHub issue](https://github.com/kubernetes/kubernetes/issues/106917) to track the discussion about the deprecation and removal of dockershim. </del> * If you find a defect or other technical concern relating to migrating away from dockershim, you can [report an issue](https://github.com/kubernetes/kubernetes/issues/new/choose) to the Kubernetes project.
Kubernetes. They needed to be pushed to some registry to allow them to be used by Kubernetes. <ins> ## Known issues ### Some filesystem metrics are missing and the metrics format is different The Kubelet `/metrics/cadvisor` endpoint provides Prometheus metrics, as documented in [Metrics for Kubernetes system components](/docs/concepts/cluster-administration/system-metrics/). If you install a metrics collector that depends on that endpoint, you might see the following issues: - The metrics format on the Docker node is `k8s_<container-name>_<pod-name>_<namespace>_<pod-uid>_<restart-count>` but the format on other runtime is different. For example, on containerd node it is `<container-id>`. - Some filesystem metrics are missing, as follows: ``` container_fs_inodes_free container_fs_inodes_total container_fs_io_current container_fs_io_time_seconds_total container_fs_io_time_weighted_seconds_total container_fs_limit_bytes container_fs_read_seconds_total container_fs_reads_merged_total container_fs_sector_reads_total container_fs_sector_writes_total container_fs_usage_bytes container_fs_write_seconds_total container_fs_writes_merged_total ``` #### Workaround You can mitigate this issue by using [cAdvisor](https://github.com/google/cadvisor) as a standalone daemonset. 1. Find the latest [cAdvisor release](https://github.com/google/cadvisor/releases) with the name pattern `vX.Y.Z-containerd-cri` (for example, `v0.42.0-containerd-cri`). 2. Follow the steps in [cAdvisor Kubernetes Daemonset](https://github.com/google/cadvisor/tree/master/deploy/kubernetes) to create the daemonset. 3. Point the installed metrics collector to use the cAdvisor `/metrics` endpoint which provides the full set of [Prometheus container metrics](https://github.com/google/cadvisor/blob/master/docs/storage/prometheus.md). Alternatives: - Use alternative third party metrics collection solution. - Collect metrics from the Kubelet summary API that is served at `/stats/summary`. </ins> ## {{% heading "whatsnext" %}} - Read [Migrating from dockershim](/docs/tasks/administer-cluster/migrating-from-dockershim/) to understand your next steps
<!-- overview --> <del> If you want to control traffic flow at the IP address or port level (OSI layer 3 or 4), then you might consider using Kubernetes NetworkPolicies for particular applications in your cluster.  NetworkPolicies are an application-centric construct which allow you to specify how a {{< glossary_tooltip text="pod" term_id="pod">}} is allowed to communicate with various network "entities" (we use the word "entity" here to avoid overloading the more common terms such as "endpoints" and "services", which have specific Kubernetes connotations) over the network. </del> <ins> If you want to control traffic flow at the IP address or port level (OSI layer 3 or 4), then you might consider using Kubernetes NetworkPolicies for particular applications in your cluster.  NetworkPolicies are an application-centric construct which allow you to specify how a {{< glossary_tooltip text="pod" term_id="pod">}} is allowed to communicate with various network "entities" (we use the word "entity" here to avoid overloading the more common terms such as "endpoints" and "services", which have specific Kubernetes connotations) over the network. NetworkPolicies apply to a connection with a pod on one or both ends, and are not relevant to other connections. </ins> The entities that a Pod can communicate with are identified through a combination of the following 3 identifiers: