Merge remote-tracking branch 'upstream/main' into dev-1.24
This commit is contained in:
Nate W
@@ -31,7 +31,7 @@ kubectl config view
|
||||
```
|
||||
|
||||
Many of the [examples](https://github.com/kubernetes/examples/tree/master/) provide an introduction to using
|
||||
kubectl. Complete documentation is found in the [kubectl manual](/docs/reference/kubectl/overview/).
|
||||
kubectl. Complete documentation is found in the [kubectl manual](/docs/reference/kubectl/).
|
||||
|
||||
### Directly accessing the REST API
|
||||
|
||||
|
||||
@@ -43,6 +43,7 @@ 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`.
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
|
||||
@@ -49,6 +49,24 @@ Rootless Podman is not supported.
|
||||
|
||||
<!-- Supporting rootless podman is discussed in https://github.com/kubernetes/minikube/issues/8719 -->
|
||||
|
||||
## Running Kubernetes inside Unprivileged Containers
|
||||
|
||||
{{% thirdparty-content %}}
|
||||
|
||||
### sysbox
|
||||
|
||||
[Sysbox](https://github.com/nestybox/sysbox) is an open-source container runtime
|
||||
(similar to "runc") that supports running system-level workloads such as Docker
|
||||
and Kubernetes inside unprivileged containers isolated with the Linux user
|
||||
namespace.
|
||||
|
||||
See [Sysbox Quick Start Guide: Kubernetes-in-Docker](https://github.com/nestybox/sysbox/blob/master/docs/quickstart/kind.md) for more info.
|
||||
|
||||
Sysbox supports running Kubernetes inside unprivileged containers without
|
||||
requiring Cgroup v2 and without the `KubeletInUserNamespace` feature gate. It
|
||||
does this by exposing specially crafted `/proc` and `/sys` filesystems inside
|
||||
the container plus several other advanced OS virtualization techniques.
|
||||
|
||||
## Running Rootless Kubernetes directly on a host
|
||||
|
||||
{{% thirdparty-content %}}
|
||||
@@ -235,7 +253,7 @@ This feature gate also allows kube-proxy to ignore an error during setting `RLIM
|
||||
The `KubeletInUserNamespace` feature gate was introduced in Kubernetes v1.22 with "alpha" status.
|
||||
|
||||
Running kubelet in a user namespace without using this feature gate is also possible
|
||||
by mounting a specially crafted proc filesystem, but not officially supported.
|
||||
by mounting a specially crafted proc filesystem (as done by [Sysbox](https://github.com/nestybox/sysbox)), but not officially supported.
|
||||
|
||||
### Configuring kube-proxy
|
||||
|
||||
@@ -272,4 +290,3 @@ on the rootlesscontaine.rs website.
|
||||
- [Usernetes](https://github.com/rootless-containers/usernetes)
|
||||
- [Running K3s with rootless mode](https://rancher.com/docs/k3s/latest/en/advanced/#running-k3s-with-rootless-mode-experimental)
|
||||
- [KEP-2033: Kubelet-in-UserNS (aka Rootless mode)](https://github.com/kubernetes/enhancements/tree/master/keps/sig-node/2033-kubelet-in-userns-aka-rootless)
|
||||
|
||||
|
||||
+1
-1
@@ -22,7 +22,7 @@ Historically, Kubernetes was written to work specifically with Docker Engine.
|
||||
Kubernetes took care of networking and scheduling, relying on Docker Engine for launching
|
||||
and running containers (within Pods) on a node. Some information that is relevant to telemetry,
|
||||
such as a pod name, is only available from Kubernetes components. Other data, such as container
|
||||
metrics, is not the responsibility of the container runtime. Early yelemetry agents needed to query the
|
||||
metrics, is not the responsibility of the container runtime. Early telemetry agents needed to query the
|
||||
container runtime **and** Kubernetes to report an accurate picture. Over time, Kubernetes gained
|
||||
the ability to support multiple runtimes, and now supports any runtime that is compatible with
|
||||
the container runtime interface.
|
||||
|
||||
@@ -91,7 +91,7 @@ flag.
|
||||
It is recommended that the kubernetes system daemons are placed under a top
|
||||
level control group (`runtime.slice` on systemd machines for example). Each
|
||||
system daemon should ideally run within its own child control group. Refer to
|
||||
[the design proposal](https://git.k8s.io/community/contributors/design-proposals/node/node-allocatable.md#recommended-cgroups-setup)
|
||||
[the design proposal](https://git.k8s.io/design-proposals-archive/node/node-allocatable.md#recommended-cgroups-setup)
|
||||
for more details on recommended control group hierarchy.
|
||||
|
||||
Note that Kubelet **does not** create `--kube-reserved-cgroup` if it doesn't
|
||||
|
||||
@@ -23,8 +23,6 @@ This task also assumes that you have met the following prerequisites:
|
||||
and have [configured PodDisruptionBudgets](/docs/tasks/run-application/configure-pdb/) for
|
||||
applications that need them.
|
||||
|
||||
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
## (Optional) Configure a disruption budget {#configure-poddisruptionbudget}
|
||||
@@ -100,95 +98,12 @@ replicas to fall below the specified budget are blocked.
|
||||
|
||||
If you prefer not to use [kubectl drain](/docs/reference/generated/kubectl/kubectl-commands/#drain) (such as
|
||||
to avoid calling to an external command, or to get finer control over the pod
|
||||
eviction process), you can also programmatically cause evictions using the eviction API.
|
||||
eviction process), you can also programmatically cause evictions using the
|
||||
eviction API.
|
||||
|
||||
You should first be familiar with using [Kubernetes language clients](/docs/tasks/administer-cluster/access-cluster-api/#programmatic-access-to-the-api) to access the API.
|
||||
|
||||
The eviction subresource of a
|
||||
Pod can be thought of as a kind of policy-controlled DELETE operation on the Pod
|
||||
itself. To attempt an eviction (more precisely: to attempt to
|
||||
*create* an Eviction), you POST an attempted operation. Here's an example:
|
||||
|
||||
{{< tabs name="Eviction_example" >}}
|
||||
{{% tab name="policy/v1" %}}
|
||||
{{< note >}}
|
||||
`policy/v1` Eviction is available in v1.22+. Use `policy/v1beta1` with prior releases.
|
||||
{{< /note >}}
|
||||
|
||||
```json
|
||||
{
|
||||
"apiVersion": "policy/v1",
|
||||
"kind": "Eviction",
|
||||
"metadata": {
|
||||
"name": "quux",
|
||||
"namespace": "default"
|
||||
}
|
||||
}
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{% tab name="policy/v1beta1" %}}
|
||||
{{< note >}}
|
||||
Deprecated in v1.22 in favor of `policy/v1`
|
||||
{{< /note >}}
|
||||
|
||||
```json
|
||||
{
|
||||
"apiVersion": "policy/v1beta1",
|
||||
"kind": "Eviction",
|
||||
"metadata": {
|
||||
"name": "quux",
|
||||
"namespace": "default"
|
||||
}
|
||||
}
|
||||
```
|
||||
{{% /tab %}}
|
||||
{{< /tabs >}}
|
||||
|
||||
You can attempt an eviction using `curl`:
|
||||
|
||||
```bash
|
||||
curl -v -H 'Content-type: application/json' https://your-cluster-api-endpoint.example/api/v1/namespaces/default/pods/quux/eviction -d @eviction.json
|
||||
```
|
||||
|
||||
The API can respond in one of three ways:
|
||||
|
||||
- If the eviction is granted, then the Pod is deleted as if you sent
|
||||
a `DELETE` request to the Pod's URL and received back `200 OK`.
|
||||
- If the current state of affairs wouldn't allow an eviction by the rules set
|
||||
forth in the budget, you get back `429 Too Many Requests`. This is
|
||||
typically used for generic rate limiting of *any* requests, but here we mean
|
||||
that this request isn't allowed *right now* but it may be allowed later.
|
||||
- If there is some kind of misconfiguration; for example multiple PodDisruptionBudgets
|
||||
that refer the same Pod, you get a `500 Internal Server Error` response.
|
||||
|
||||
For a given eviction request, there are two cases:
|
||||
|
||||
- There is no budget that matches this pod. In this case, the server always
|
||||
returns `200 OK`.
|
||||
- There is at least one budget. In this case, any of the three above responses may
|
||||
apply.
|
||||
|
||||
## Stuck evictions
|
||||
|
||||
In some cases, an application may reach a broken state, one where unless you intervene the
|
||||
eviction API will never return anything other than 429 or 500.
|
||||
|
||||
For example: this can happen if ReplicaSet is creating Pods for your application but
|
||||
the replacement Pods do not become `Ready`. You can also see similar symptoms if the
|
||||
last Pod evicted has a very long termination grace period.
|
||||
|
||||
In this case, there are two potential solutions:
|
||||
|
||||
- Abort or pause the automated operation. Investigate the reason for the stuck application,
|
||||
and restart the automation.
|
||||
- After a suitably long wait, `DELETE` the Pod from your cluster's control plane, instead
|
||||
of using the eviction API.
|
||||
|
||||
Kubernetes does not specify what the behavior should be in this case; it is up to the
|
||||
application owners and cluster owners to establish an agreement on behavior in these cases.
|
||||
For more information, see [API-initiated eviction](/docs/concepts/scheduling-eviction/api-eviction/).
|
||||
|
||||
## {{% heading "whatsnext" %}}
|
||||
|
||||
|
||||
* Follow steps to protect your application by [configuring a Pod Disruption Budget](/docs/tasks/run-application/configure-pdb/).
|
||||
|
||||
|
||||
Reference in New Issue
Block a user