whentimeslows/website
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge remote-tracking branch 'upstream/main' into dev-1.24

Browse Source
This commit is contained in:
Nate W
2022-03-07 16:23:45 -08:00
parent e0b67982f5 0754ec0546
commit 5a0f2583c6
155 changed files with 12643 additions and 2225 deletions
Download Patch File Download Diff File Expand all files Collapse all files
content/en/docs/tasks/access-application-cluster/access-cluster.md
+2 -2
View File
@@ -27,8 +27,8 @@ kubectl config view
```
Many of the [examples](/docs/reference/kubectl/cheatsheet/) provide an introduction to using
kubectl and complete documentation is found in the
[kubectl manual](/docs/reference/kubectl/overview/).
`kubectl`, and complete documentation is found in the
[kubectl reference](/docs/reference/kubectl/).
## Directly accessing the REST API
content/en/docs/tasks/administer-cluster/access-cluster-api.md
+1 -1
View File
@@ -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
content/en/docs/tasks/administer-cluster/kubeadm/kubeadm-upgrade.md
+1
View File
@@ -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 -->
content/en/docs/tasks/administer-cluster/kubelet-in-userns.md
+19 -2
View File
@@ -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)
content/en/docs/tasks/administer-cluster/migrating-from-dockershim/migrating-telemetry-and-security-agents.md
+1 -1
View File
@@ -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.
content/en/docs/tasks/administer-cluster/reserve-compute-resources.md
+1 -1
View File
@@ -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
content/en/docs/tasks/administer-cluster/safely-drain-node.md
+3 -88
View File
@@ -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/).
content/en/docs/tasks/debug-application-cluster/troubleshooting.md
+1 -1
View File
@@ -36,7 +36,7 @@ accomplish commonly used tasks, and [Tutorials](/docs/tutorials/) are more
comprehensive walkthroughs of real-world, industry-specific, or end-to-end
development scenarios. The [Reference](/docs/reference/) section provides
detailed documentation on the [Kubernetes API](/docs/reference/generated/kubernetes-api/{{< param "version" >}}/)
and command-line interfaces (CLIs), such as [`kubectl`](/docs/reference/kubectl/overview/).
and command-line interfaces (CLIs), such as [`kubectl`](/docs/reference/kubectl/).
## Help! My question isn't covered! I need help now!
content/en/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions.md
+7 -7
View File
@@ -725,7 +725,7 @@ For example:
properties:
spec:
type: object
x-kubernetes-validation-rules:
x-kubernetes-validations:
- rule: "self.minReplicas <= self.replicas"
message: "replicas should be greater than or equal to minReplicas."
- rule: "self.replicas <= self.maxReplicas"
@@ -829,7 +829,7 @@ Xref: [Supported evaluation on CEL](https://github.com/google/cel-spec/blob/v0.6
...
openAPIV3Schema:
type: object
x-kubernetes-validation-rules:
x-kubernetes-validations:
- rule: "self.status.availableReplicas >= self.spec.minReplicas"
properties:
spec:
@@ -856,7 +856,7 @@ Xref: [Supported evaluation on CEL](https://github.com/google/cel-spec/blob/v0.6
properties:
spec:
type: object
x-kubernetes-validation-rules:
x-kubernetes-validations:
- rule: "has(self.foo)"
properties:
...
@@ -874,7 +874,7 @@ Xref: [Supported evaluation on CEL](https://github.com/google/cel-spec/blob/v0.6
properties:
spec:
type: object
x-kubernetes-validation-rules:
x-kubernetes-validations:
- rule: "self['xyz'].foo > 0"
additionalProperties:
...
@@ -894,7 +894,7 @@ Xref: [Supported evaluation on CEL](https://github.com/google/cel-spec/blob/v0.6
...
foo:
type: array
x-kubernetes-validation-rules:
x-kubernetes-validations:
- rule: "size(self) == 1"
items:
type: string
@@ -912,7 +912,7 @@ Xref: [Supported evaluation on CEL](https://github.com/google/cel-spec/blob/v0.6
...
foo:
type: integer
x-kubernetes-validation-rules:
x-kubernetes-validations:
- rule: "self > 0"
```
Examples:
@@ -1125,7 +1125,7 @@ with `foo` pruned and defaulted because the field is non-nullable, `bar` maintai
CustomResourceDefinition [OpenAPI v3 validation schemas](#validation) which are [structural](#specifying-a-structural-schema) and [enable pruning](#field-pruning) are published as part of the [OpenAPI v2 spec](/docs/concepts/overview/kubernetes-api/#openapi-and-swagger-definitions) from Kubernetes API server.
The [kubectl](/docs/reference/kubectl/overview) command-line tool consumes the published schema to perform client-side validation (`kubectl create` and `kubectl apply`), schema explanation (`kubectl explain`) on custom resources. The published schema can be consumed for other purposes as well, like client generation or documentation.
The [kubectl](/docs/reference/kubectl/) command-line tool consumes the published schema to perform client-side validation (`kubectl create` and `kubectl apply`), schema explanation (`kubectl explain`) on custom resources. The published schema can be consumed for other purposes as well, like client generation or documentation.
The OpenAPI v3 validation schema is converted to OpenAPI v2 schema, and
show up in `definitions` and `paths` fields in the [OpenAPI v2 spec](/docs/concepts/overview/kubernetes-api/#openapi-and-swagger-definitions).
content/en/docs/tasks/tls/managing-tls-in-a-cluster.md
+14 -5
View File
@@ -18,7 +18,7 @@ draft](https://github.com/ietf-wg-acme/acme/).
{{< note >}}
Certificates created using the `certificates.k8s.io` API are signed by a
dedicated CA. It is possible to configure your cluster to use the cluster root
[dedicated CA](#a-note-to-cluster-administrators). It is possible to configure your cluster to use the cluster root
CA for this purpose, but you should never rely on this. Do not assume that
these certificates will validate against the cluster root CA.
{{< /note >}}
@@ -42,16 +42,25 @@ install it via your operating system's software sources, or fetch it from
## Trusting TLS in a cluster
Trusting the custom CA from an application running as a pod usually requires
Trusting the [custom CA](#a-note-to-cluster-administrators) from an application running as a pod usually requires
some extra application configuration. You will need to add the CA certificate
bundle to the list of CA certificates that the TLS client or server trusts. For
example, you would do this with a golang TLS config by parsing the certificate
chain and adding the parsed certificates to the `RootCAs` field in the
[`tls.Config`](https://godoc.org/crypto/tls#Config) struct.
You can distribute the CA certificate as a
[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap) that your
pods have access to use.
{{< note >}}
Even though the custom CA certificate may be included in the filesystem (in the
ConfigMap `kube-root-ca.crt`),
you should not use that certificate authority for any purpose other than to verify internal
Kubernetes endpoints. An example of an internal Kubernetes endpoint is the
Service named `kubernetes` in the default namespace.
If you want to use a custom certificate authority for your workloads, you should generate
that CA separately, and distribute its CA certificate using a
[ConfigMap](/docs/tasks/configure-pod-container/configure-pod-configmap) that your pods
have access to read.
{{< /note >}}
## Requesting a certificate