jiebi/CodeConvo huggingface dataset:
outline: none; padding: .5em 0 .5em 0; } <ins> /* CSS for 'figure' full-screen display */ /* Define styles for full-screen overlay */ .figure-fullscreen-overlay { position: fixed; inset: 0; z-index: 9999; background-color: rgba(255, 255, 255, 0.95); /* White background with some transparency */ display: flex; justify-content: center; align-items: center; padding: calc(5% + 20px); box-sizing: border-box; } /* CSS class to scale the image when zoomed */ .figure-zoomed { transform: scale(1.2); } /* Define styles for full-screen image */ .figure-fullscreen-img { max-width: 100%; max-height: 100%; object-fit: contain; /* Maintain aspect ratio and fit within the container */ } /* Define styles for close button */ .figure-close-button { position: absolute; top: 1%; right: 2%; cursor: pointer; font-size: calc(5vw + 10px); color: #333; } </ins>  No newline at end of file
This document outlines the various components you need to have for a complete and working Kubernetes cluster. <del> {{< figure src="/images/docs/components-of-kubernetes.svg" alt="Components of Kubernetes" caption="The components of a Kubernetes cluster" class="diagram-large" >}} </del> <ins> {{< figure src="/images/docs/components-of-kubernetes.svg" alt="Components of Kubernetes" caption="The components of a Kubernetes cluster" class="diagram-large" clicktozoom="true" >}} </ins> <!-- body --> ## Control Plane Components
<script src="https://cdnjs.cloudflare.com/ajax/libs/iframe-resizer/4.3.9/iframeResizer.min.js" integrity="sha384-hHTwgxzjpO1G1NI0wMHWQYUxnGtpWyDjVSZrFnDrlWa5OL+DFY57qnDWw/5WSJOl" crossorigin="anonymous"></script> {{- end -}} <ins> <!-- Enable zoom-on-click for figures that opt in to this --> {{- if .HasShortcode "figure" -}} <script defer src="{{ "js/zoom.js" | relURL }}"></script> {{- end -}} </ins> {{- if eq (lower .Params.cid) "community" -}} {{- if eq .Params.community_styles_migrated true -}} <link href="/css/community.css" rel="stylesheet"><!-- legacy styles -->
<ins> {{ $src := (.Page.Resources.GetMatch (printf "**%s*" (.Get "src"))) }} {{ $clickToZoom := .Get "clicktozoom" }} <figure{{ with .Get "class" }} class="{{ . }} {{ if $clickToZoom }}clickable-zoom{{ end }}"{{ end }}> {{- if .Get "link" -}} <a href="{{ .Get "link" }}"{{ with .Get "target" }} target="{{ . }}"{{ end }}{{ with .Get "rel" }} rel="{{ . }}"{{ end }}> {{- end }} <img src="{{ if $src }}{{ $src.RelPermalink }}{{ else }}{{ .Get "src" }}{{ end }}" {{- if or (.Get "alt") (.Get "caption") }} alt="{{ with .Get "alt" }}{{ . }}{{ else }}{{ .Get "caption" | markdownify| plainify }}{{ end }}" {{- end -}} {{- with .Get "width" }} width="{{ . }}"{{ end -}} {{- with .Get "height" }} height="{{ . }}"{{ end -}} /> <!-- Closing img tag --> {{- if .Get "link" }}</a>{{ end -}} {{- if or (or (.Get "title") (.Get "caption")) (.Get "attr") -}} <figcaption> {{ with (.Get "title") -}} <h4>{{ . }}</h4> {{- end -}} {{- if or (.Get "caption") (.Get "attr") -}}<p> {{- .Get "caption" | markdownify -}} {{- with .Get "attrlink" }} <a href="{{ . }}"> {{- end -}} {{- .Get "attr" | markdownify -}} {{- if .Get "attrlink" }}</a>{{ end }}</p> {{- end }} </figcaption> {{- end }} </figure> </ins>  No newline at end of file
<ins> // The page and script is loaded successfully $(document).ready(function() { // Function to handle hover over <figure> elements function handleFigureHover() { // Only change cursor to zoom-in if figure has 'clickable-zoom' class if ($(this).hasClass('clickable-zoom') && !$(this).hasClass('figure-fullscreen-content')) { $(this).css('cursor', 'zoom-in'); } } // Attach hover event to <figure> elements with 'clickable-zoom' class $('figure.clickable-zoom').hover(handleFigureHover, function() { // Mouse out - revert cursor back to default $(this).css('cursor', 'default'); }); // Attach click event to <figure> elements with 'clickable-zoom' class $('figure.clickable-zoom').click(function() { var $figure = $(this); // Check if the figure has 'clickable-zoom' class if ($figure.hasClass('clickable-zoom')) { var $img = $figure.find('img'); // Get the <img> element within the clicked <figure> // Toggle 'figure-zoomed' class to scale the image $img.toggleClass('figure-zoomed'); // Create a full-screen overlay var $fullscreenOverlay = $('<div class="figure-fullscreen-overlay"></div>'); // Clone the <img> element to display in full-screen var $fullscreenImg = $img.clone(); $fullscreenImg.addClass('figure-fullscreen-img'); // Append the full-screen image to the overlay $fullscreenOverlay.append($fullscreenImg); // Create a close button for the full-screen overlay var $closeButton = $('<span class="figure-close-button">&times;</span>'); $closeButton.click(function() { // Remove the full-screen overlay when close button is clicked $fullscreenOverlay.remove(); $('body').css('overflow', 'auto'); // Restore scrolling to the underlying page // Remove 'figure-zoomed' class to reset image scale $img.removeClass('figure-zoomed'); }); $fullscreenOverlay.append($closeButton); // Append the overlay to the body $('body').append($fullscreenOverlay); // Disable scrolling on the underlying page $('body').css('overflow', 'hidden'); // Close full-screen figure when clicking outside of it (on the overlay) $fullscreenOverlay.click(function(event) { if (event.target === this) { // Clicked on the overlay area (outside the full-screen image) $fullscreenOverlay.remove(); $('body').css('overflow', 'auto'); // Restore scrolling to the underlying page // Remove 'figure-zoomed' class to reset image scale $img.removeClass('figure-zoomed'); } }); } }); }); </ins>
<!-- overview --> <del> Kubernetes runs your workload by placing containers into Pods to run on _Nodes_. </del> <ins> Kubernetes runs your {{< glossary_tooltip text="workload" term_id="workload" >}} by placing containers into Pods to run on _Nodes_. </ins> A node may be a virtual or physical machine, depending on the cluster. Each node is managed by the {{< glossary_tooltip text="control plane" term_id="control-plane" >}}
section [Graceful Node Shutdown](#graceful-node-shutdown) for more details. When a node is shutdown but not detected by kubelet's Node Shutdown Manager, the pods <del> that are part of a StatefulSet will be stuck in terminating status on </del> <ins> that are part of a {{< glossary_tooltip text="StatefulSet" term_id="statefulset" >}} will be stuck in terminating status on </ins> the shutdown node and cannot move to a new running node. This is because kubelet on the shutdown node is not available to delete the pods so the StatefulSet cannot create a new pod with the same name. If there are volumes used by the pods, the
To mitigate the above situation, a  user can manually add the taint `node.kubernetes.io/out-of-service` with either `NoExecute` or `NoSchedule` effect to a Node marking it out-of-service. If the `NodeOutOfServiceVolumeDetach`[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) <del> is enabled on `kube-controller-manager`, and a Node is marked out-of-service with this taint, the </del> <ins> is enabled on {{< glossary_tooltip text="kube-controller-manager" term_id="kube-controller-manager" >}}, and a Node is marked out-of-service with this taint, the </ins> pods on the node will be forcefully deleted if there are no matching tolerations on it and volume detach operations for the pods terminating on the node will happen immediately. This allows the Pods on the out-of-service node to recover quickly on a different node.
## {{% heading "whatsnext" %}} <del> * Learn about the [components](/docs/concepts/overview/components/#node-components) that make up a node. * Read the [API definition for Node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core). * Read the [Node](https://git.k8s.io/design-proposals-archive/architecture/architecture.md#the-kubernetes-node) section of the architecture design document. * Read about [taints and tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/). </del> <ins> Learn more about the following: * [Components](/docs/concepts/overview/components/#node-components) that make up a node. * [API definition for Node](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/#node-v1-core). * [Node](https://git.k8s.io/design-proposals-archive/architecture/architecture.md#the-kubernetes-node) section of the architecture design document. * [Taints and Tolerations](/docs/concepts/scheduling-eviction/taint-and-toleration/). * [Node Resource Managers](/docs/concepts/policy/node-resource-managers/). * [Resource Management for Windows nodes](/docs/concepts/configuration/windows-resource-management/). </ins>
- operation --- <del> एग्रीगेशन लेयर आपको अपने क्लस्टर में अतिरिक्त कुबेरनेट्स-शैली API स्थापित करने देता है।``` </del> <ins> एग्रीगेशन लेयर आपको अपने क्लस्टर में अतिरिक्त कुबेरनेट्स-शैली API स्थापित करने देता है। </ins> <!--more--> <del> जब आपने {{< glossary_tooltip text="कुबेरनेट्स API सर्वर" term_id="kube-apiserver" >}} को [अतिरिक्त API का समर्थन](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) करने के लिए कॉन्फ़िगर किया हो, आप कुबेरनेट्स एपीआई में URL पथ का "दावा" करने के लिए `APIService` ऑब्जेक्ट जोड़ सकते हैं। </del> <ins> जब आपने {{< glossary_tooltip text="कुबेरनेट्स API सर्वर" term_id="kube-apiserver" >}} को [अतिरिक्त API का समर्थन](/docs/tasks/extend-kubernetes/configure-aggregation-layer/) करने के लिए कॉन्फ़िगर किया हो, आप कुबेरनेट्स API में URL पाथ का "दावा" करने के लिए `APIService` ऑब्जेक्ट जोड़ सकते हैं। </ins>
<ins> --- title: ファイナライザー(Finalizers) content_type: concept weight: 80 --- <!-- overview --> {{<glossary_definition term_id="finalizer" length="long">}} ファイナライザーを利用すると、対象のリソースを削除する前に特定のクリーンアップを行うように{{<glossary_tooltip text="コントローラー" term_id="controller">}}に警告することで、{{<glossary_tooltip text="ガベージコレクション" term_id="garbage-collection">}}を管理することができます。 大抵の場合ファイナライザーは実行されるコードを指定することはありません。 その代わり、一般的にはアノテーションのように特定のリソースに関するキーのリストになります。 Kubernetesはいくつかのファイナライザーを自動的に追加しますが、自分で追加することもできます。 ## ファイナライザーはどのように動作するか マニフェストファイルを使ってリソースを作るとき、`metadata.finalizers`フィールドの中でファイナライザーを指定することができます。 リソースを削除しようとするとき、削除リクエストを扱うAPIサーバーは`finalizers`フィールドの値を確認し、以下のように扱います。 * 削除を開始した時間をオブジェクトの`metadata.deletionTimestamp`フィールドに設定します。 * `metadata.finalizers`フィールドが空になるまでオブジェクトが削除されるのを阻止します。 * ステータスコード`202`(HTTP "Accepted")を返します。 ファイナライザーを管理しているコントローラーは、オブジェクトの削除がリクエストされたことを示す`metadata.deletionTimestamp`がオブジェクトに設定されたことを検知します。 するとコントローラーはリソースに指定されたファイナライザーの要求を満たそうとします。 ファイナライザーの条件が満たされるたびに、そのコントローラーはリソースの`finalizers`フィールドの対象のキーを削除します。 `finalizers`フィールドが空になったとき、`deletionTimestamp`フィールドが設定されたオブジェクトは自動的に削除されます。管理外のリソース削除を防ぐためにファイナライザーを利用することもできます。 ファイナライザーの一般的な例は`kubernetes.io/pv-protection`で、これは `PersistentVolume`オブジェクトが誤って削除されるのを防ぐためのものです。 `PersistentVolume`オブジェクトをPodが利用中の場合、Kubernetesは`pv-protection`ファイナライザーを追加します。 `PersistentVolume`を削除しようとすると`Terminating`ステータスになりますが、ファイナライザーが存在しているためコントローラーはボリュームを削除することができません。 Podが`PersistentVolume`の利用を停止するとKubernetesは`pv-protection`ファイナライザーを削除し、コントローラーがボリュームを削除します。 ## オーナーリファレンス、ラベル、ファイナライザー {#owners-labels-finalizers} {{<glossary_tooltip text="ラベル" term_id="label">}}のように、 [オーナーリファレンス](/docs/concepts/overview/working-with-objects/owners-dependents/)はKubernetesのオブジェクト間の関係性を説明しますが、利用される目的が異なります。 {{<glossary_tooltip text="コントローラー" term_id="controller">}} がPodのようなオブジェクトを管理するとき、関連するオブジェクトのグループの変更を追跡するためにラベルを利用します。 例えば、{{<glossary_tooltip text="Job" term_id="job">}}がいくつかのPodを作成するとき、JobコントローラーはそれらのPodにラベルを付け、クラスター内の同じラベルを持つPodの変更を追跡します。 Jobコントローラーは、Podを作成したJobを指す*オーナーリファレンス*もそれらのPodに追加します。 Podが実行されているときにJobを削除すると、Kubernetesはオーナーリファレンス(ラベルではない)を使って、クリーンアップする必要のあるPodをクラスター内から探し出します。 また、Kubernetesは削除対象のリソースのオーナーリファレンスを認識して、ファイナライザーを処理します。 状況によっては、ファイナライザーが依存オブジェクトの削除をブロックしてしまい、対象のオーナーオブジェクトが完全に削除されず予想以上に長時間残ってしまうことがあります。 このような状況では、対象のオーナーと依存オブジェクトの、ファイナライザーとオーナーリファレンスを確認して問題を解決する必要があります。 {{<note>}} オブジェクトが削除中の状態で詰まってしまった場合、削除を続行するために手動でファイナライザーを削除することは避けてください。 通常、ファイナライザーは理由があってリソースに追加されているものであるため、強制的に削除してしまうとクラスターで何らかの問題を引き起こすことがあります。 そのファイナライザーの目的を理解しているかつ、別の方法で達成できる場合にのみ行うべきです(例えば、依存オブジェクトを手動で削除するなど)。 {{</note>}} ## {{% heading "whatsnext" %}} * Kubernetesブログの[ファイナライザーを利用した削除の制御](/blog/2021/05/14/using-finalizers-to-control-deletion/)をお読みください。 </ins>
<ins> --- title: ファイナライザー id: finalizer date: 2021-07-07 full_link: /ja/docs/concepts/overview/working-with-objects/finalizers/ short_description: > 削除対象としてマークされたオブジェクトを完全に削除する前に、特定の条件が満たされるまでKubernetesを待機させるための名前空間付きのキーです。 aka: tags: - fundamental - operation --- ファイナライザーは、削除対象としてマークされたリソースを完全に削除する前に、特定の条件が満たされるまでKubernetesを待機させるための名前空間付きのキーです。 ファイナライザーは、削除されたオブジェクトが所有していたリソースをクリーンアップするように{{<glossary_tooltip text="コントローラー" term_id="controller">}}に警告します。 <!--more--> Kubernetesにファイナライザーが指定されたオブジェクトを削除するように指示すると、Kubernetes APIはそのオブジェクトに`.metadata.deletionTimestamp`を追加し削除対象としてマークして、ステータスコード`202`(HTTP "Accepted")を返します。 コントロールプレーンやその他のコンポーネントがファイナライザーによって定義されたアクションを実行している間、対象のオブジェクトは終了中の状態のまま残っています。 それらのアクションが完了したら、そのコントローラーは関係しているファイナライザーを対象のオブジェクトから削除します。 `metadata.finalizers`フィールドが空になったら、Kubernetesは削除が完了したと判断しオブジェクトを削除します。 ファイナライザーはリソースの{{<glossary_tooltip text="ガベージコレクション" term_id="garbage-collection">}}を管理するために使うことができます。 例えば、コントローラーが対象のリソースを削除する前に関連するリソースやインフラをクリーンアップするためにファイナライザーを定義することができます。 </ins>
## Start a Kubelet process configured via the config file {{< note >}} <del> If you use kubeadm to initialize your cluster, use the kubelet-config while creating your cluster with `kubeadmin init`. </del> <ins> If you use kubeadm to initialize your cluster, use the kubelet-config while creating your cluster with `kubeadm init`. </ins> See [configuring kubelet using kubeadm](/docs/setup/production-environment/tools/kubeadm/kubelet-integration/) for details. {{< /note >}}
Being vulnerable does not necessarily mean that your service will be exploited. Though your services are vulnerable in some ways unknown to you, offenders still need to identify these vulnerabilities and then exploit them. If offenders fail to exploit your service vulnerabilities, you win! In other words, having a vulnerability that can’t be exploited, represents a risk that can’t be realized. <del> {{< figure src="Example.png" alt="Image of an example of offender gaining foothold in a service" class="diagram-large" caption="Figure 1. An Offender gaining foothold in a vulnerable service" >}} </del> <ins> {{< figure src="security_behavior_figure_1.svg" alt="Image of an example of offender gaining foothold in a service" class="diagram-large" caption="Figure 1. An Offender gaining foothold in a vulnerable service" >}} </ins> The above diagram shows an example in which the offender does not yet have a foothold in the service; that is, it is assumed that your service does not run code controlled by the offender on day 1. In our example the service has vulnerabilities in the API exposed to clients. To gain an initial foothold the offender uses a malicious client to try and exploit one of the service API vulnerabilities. The malicious client sends an exploit that triggers some unplanned behavior of the service.
Kubernetes is often used to support workloads designed with microservice architecture. By design, microservices aim to follow the UNIX philosophy of "Do One Thing And Do It Well". Each microservice has a bounded context and a clear interface. In other words, you can expect the microservice clients to send relatively regular requests and the microservice to present a relatively regular behavior as a response to these requests. Consequently, a microservice architecture is an excellent candidate for security-behavior monitoring. <del> {{< figure src="Microservices.png" alt="Image showing why microservices are well suited for security-behavior monitoring" class="diagram-large" caption="Figure 2. Microservices are well suited for security-behavior monitoring" >}} </del> <ins> {{< figure src="security_behavior_figure_2.svg" alt="Image showing why microservices are well suited for security-behavior monitoring" class="diagram-large" caption="Figure 2. Microservices are well suited for security-behavior monitoring" >}} </ins> The diagram above clarifies how dividing a monolithic service to a set of microservices improves our ability to perform security-behavior monitoring and control. In a monolithic service approach, different client requests are intertwined, resulting in a diminished ability to identify irregular client behaviors. Without prior knowledge, an observer of the intertwined client requests will find it hard to distinguish between types of requests and their related characteristics. Further, internal client requests are not exposed to the observer. Lastly, the aggregated behavior of the monolithic service is a compound of the many different internal behaviors of its components, making it hard to identify irregular service behavior.
## Clean up <del> Run `kind delete cluster --name psa-with-cluster-pss` and `kind delete cluster --name psa-wo-cluster-pss` to delete the clusters you created. </del> <ins> Now delete the clusters which you created above by running the following command: ```shell kind delete cluster --name psa-with-cluster-pss ``` ```shell kind delete cluster --name psa-wo-cluster-pss ``` </ins> ## {{% heading "whatsnext" %}}
Different kinds of object can also have different `.status`; again, the API reference pages detail the structure of that `.status` field, and its content for each different type of object. <ins> ## Server side field validation Starting with Kubernetes v1.25, the API server offers server side [field validation](/docs/reference/using-api/api-concepts/#field-validation) that detects unrecognized or duplicate fields in an object. It provides all the functionality of `kubectl --validate` on the server side. The `kubectl` tool uses the `--validate` flag to set the level of field validation. It accepts the values `ignore`, `warn`, and `strict` while also accepting the values `true` (equivalent to `strict`) and `false` (equivalent to `ignore`). The default validation setting for `kubectl` is `--validate=true`. `Strict` : Strict field validation, errors on validation failure `Warn` : Field validation is performed, but errors are exposed as warnings rather than failing the request `Ignore` : No server side field validation is performed When `kubectl` cannot connect to an API server that supports field validation it will fall back to using client-side validation. Kubernetes 1.27 and later versions always offer field validation; older Kubernetes releases might not. If your cluster is older than v1.27, check the documentation for your version of Kubernetes. </ins> ## {{% heading "whatsnext" %}} If you're new to Kubernetes, read more about the following:
Kubernetes provides great primitives for deploying applications to a cluster: it can be as simple as `kubectl create -f app.yaml`. Deploy apps across multiple clusters has never been that simple. How should app workloads be distributed? Should the app resources be replicated into all clusters, replicated into selected clusters, or partitioned into clusters? How is  access to the clusters managed? What happens if some of the resources that a user wants to distribute pre-exist, in some or all of the clusters, in some form? <del> In SIG Multicluster, our journey has revealed that there are multiple possible models to solve these problems and there probably is no single best-fit, all-scenario solution. [Federation](/docs/concepts/cluster-administration/federation/), however, is the single biggest Kubernetes open source sub-project, and has seen the maximum interest and contribution from the community in this problem space. The project initially reused the Kubernetes API to do away with any added usage complexity for an existing Kubernetes user. This approach was not viable, because of the problems summarised below: </del> <ins> In SIG Multicluster, our journey has revealed that there are multiple possible models to solve these problems and there probably is no single best-fit, all-scenario solution. [Kubernetes Cluster Federation (KubeFed for short)](https://github.com/kubernetes-sigs/kubefed), however, is the single biggest Kubernetes open source sub-project, and has seen the maximum interest and contribution from the community in this problem space. The project initially reused the Kubernetes API to do away with any added usage complexity for an existing Kubernetes user. This approach was not viable, because of the problems summarised below: </ins> * Difficulties in re-implementing the Kubernetes API at the cluster level, as federation-specific extensions were stored in annotations. * Limited flexibility in federated types, placement and reconciliation, due to 1:1 emulation of the Kubernetes API.
## {{% heading "prerequisites" %}} <del> These instructions are for Kubernetes {{< skew currentVersion >}}. If you want to check the integrity of components for a different version of Kubernetes, check the documentation for that Kubernetes release. </del> You will need to have the following tools installed: - `cosign` ([install guide](https://docs.sigstore.dev/cosign/installation/)) - `curl` (often provided by your operating system) <ins> - `jq` ([download jq](https://stedolan.github.io/jq/download/)) </ins> ## Verifying binary signatures
done ``` <del> Then verify the blob by using `cosign`: </del> <ins> Then verify the blob by using `cosign verify-blob`: </ins> ```shell <del> cosign verify-blob "$BINARY" --signature "$BINARY".sig --certificate "$BINARY".cert </del> <ins> cosign verify-blob "$BINARY"  --signature "$BINARY".sig  --certificate "$BINARY".cert  --certificate-identity krel-staging@k8s-releng-prod.iam.gserviceaccount.com  --certificate-oidc-issuer https://accounts.google.com </ins> ``` <del> cosign v1.9.0 is required to be able to use the `--certificate` flag. Please use `--cert` for older versions of cosign. </del> {{< note >}} <del> To learn more about keyless signing, please refer to [Keyless Signatures](https://github.com/sigstore/cosign/blob/main/KEYLESS.md#keyless-signatures). </del> <ins> Cosign 2.0 requires the `--certificate-identity` and `--certificate-oidc-issuer` options. To learn more about keyless signing, please refer to [Keyless Signatures](https://docs.sigstore.dev/cosign/keyless). Previous versions of Cosign required that you set `COSIGN_EXPERIMENTAL=1`. For additional information, plase refer to the [sigstore Blog](https://blog.sigstore.dev/cosign-2-0-released/) </ins> {{< /note >}} ## Verifying image signatures
Install crictl (required for kubeadm / Kubelet Container Runtime Interface (CRI)) ```bash <del> CRICTL_VERSION="v1.25.0" </del> <ins> CRICTL_VERSION="v1.26.0" </ins> ARCH="amd64" curl -L "https://github.com/kubernetes-sigs/cri-tools/releases/download/${CRICTL_VERSION}/crictl-${CRICTL_VERSION}-linux-${ARCH}.tar.gz" | sudo tar -C $DOWNLOAD_DIR -xz ```
## {{% heading "whatsnext" %}} <del> * [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) </del> <ins> * [Using kubeadm to Create a Cluster](/docs/setup/production-environment/tools/kubeadm/create-cluster-kubeadm/) </ins>  No newline at end of file
* Etcd's official [documentation](https://etcd.io/docs/). * Several [container runtimes](/docs/setup/production-environment/container-runtimes/) in Kubernetes. * Integrating with cloud providers using [cloud-controller-manager](/docs/concepts/architecture/cloud-controller/). <del> * [kubectl](/docs/reference/generated/kubectl/kubectl-commands) commands. </del> <ins> * [kubectl](/docs/reference/generated/kubectl/kubectl-commands) commands. </ins>  No newline at end of file