Merge pull request #30705 from jlbutler/merged-main-dev-1.23
Periodic integration branch sync for 1.23
This commit is contained in:
@@ -22,5 +22,5 @@ tags:
|
||||
|
||||
<!--more-->
|
||||
|
||||
PDBs cannot prevent an involuntary disruption, but
|
||||
will count against the budget.
|
||||
Involuntary disruptions cannot be prevented by PDBs; however they
|
||||
do count against the budget.
|
||||
|
||||
@@ -289,10 +289,11 @@ kubectl scale --replicas=5 rc/foo rc/bar rc/baz # Scale multip
|
||||
## Deleting resources
|
||||
|
||||
```bash
|
||||
kubectl delete -f ./pod.json # Delete a pod using the type and name specified in pod.json
|
||||
kubectl delete pod,service baz foo # Delete pods and services with same names "baz" and "foo"
|
||||
kubectl delete pods,services -l name=myLabel # Delete pods and services with label name=myLabel
|
||||
kubectl -n my-ns delete pod,svc --all # Delete all pods and services in namespace my-ns,
|
||||
kubectl delete -f ./pod.json # Delete a pod using the type and name specified in pod.json
|
||||
kubectl delete pod unwanted --now # Delete a pod with no grace period
|
||||
kubectl delete pod,service baz foo # Delete pods and services with same names "baz" and "foo"
|
||||
kubectl delete pods,services -l name=myLabel # Delete pods and services with label name=myLabel
|
||||
kubectl -n my-ns delete pod,svc --all # Delete all pods and services in namespace my-ns,
|
||||
# Delete all pods matching the awk pattern1 or pattern2
|
||||
kubectl get pods -n mynamespace --no-headers=true | awk '/pattern1|pattern2/{print $1}' | xargs kubectl delete -n mynamespace pod
|
||||
```
|
||||
@@ -323,6 +324,24 @@ kubectl exec my-pod -c my-container -- ls / # Run command in existing po
|
||||
kubectl top pod POD_NAME --containers # Show metrics for a given pod and its containers
|
||||
kubectl top pod POD_NAME --sort-by=cpu # Show metrics for a given pod and sort it by 'cpu' or 'memory'
|
||||
```
|
||||
## Copy files and directories to and from containers
|
||||
|
||||
```bash
|
||||
kubectl cp /tmp/foo_dir my-pod:/tmp/bar_dir # Copy /tmp/foo_dir local directory to /tmp/bar_dir in a remote pod in the current namespace
|
||||
kubectl cp /tmp/foo my-pod:/tmp/bar -c my-container # Copy /tmp/foo local file to /tmp/bar in a remote pod in a specific container
|
||||
kubectl cp /tmp/foo my-namespace/my-pod:/tmp/bar # Copy /tmp/foo local file to /tmp/bar in a remote pod in namespace my-namespace
|
||||
kubectl cp my-namespace/my-pod:/tmp/foo /tmp/bar # Copy /tmp/foo from a remote pod to /tmp/bar locally
|
||||
```
|
||||
{{< note >}}
|
||||
`kubectl cp` requires that the 'tar' binary is present in your container image. If 'tar' is not present,`kubectl cp` will fail.
|
||||
For advanced use cases, such as symlinks, wildcard expansion or file mode preservation consider using `kubectl exec`.
|
||||
{{< /note >}}
|
||||
|
||||
```bash
|
||||
tar cf - /tmp/foo | kubectl exec -i -n my-namespace my-pod -- tar xf - -C /tmp/bar # Copy /tmp/foo local file to /tmp/bar in a remote pod in namespace my-namespace
|
||||
kubectl exec -n my-namespace my-pod -- tar cf - /tmp/foo | tar xf - -C /tmp/bar # Copy /tmp/foo from a remote pod to /tmp/bar locally
|
||||
```
|
||||
|
||||
|
||||
## Interacting with Deployments and Services
|
||||
```bash
|
||||
|
||||
@@ -91,6 +91,7 @@ If:
|
||||
* the `KUBERNETES_SERVICE_HOST` environment variable is set, and
|
||||
* the `KUBERNETES_SERVICE_PORT` environment variable is set, and
|
||||
* you don't explicitly specify a namespace on the kubectl command line
|
||||
|
||||
then kubectl assumes it is running in your cluster. The kubectl tool looks up the
|
||||
namespace of that ServiceAccount (this is the same as the namespace of the Pod)
|
||||
and acts against that namespace. This is different from what happens outside of a
|
||||
@@ -545,4 +546,3 @@ Current user: plugins-user
|
||||
|
||||
* To find out more about plugins, take a look at the [example cli plugin](https://github.com/kubernetes/sample-cli-plugin).
|
||||
|
||||
|
||||
|
||||
@@ -36,10 +36,9 @@ Example: `kubernetes.io/metadata.name=mynamespace`
|
||||
|
||||
Used on: Namespaces
|
||||
|
||||
When the `NamespaceDefaultLabelName`
|
||||
[feature gate](/docs/reference/command-line-tools-reference/feature-gates/) is enabled,
|
||||
the Kubernetes API server sets this label on all namespaces. The label value is set to
|
||||
the name of the namespace.
|
||||
The Kubernetes API server (part of the {{< glossary_tooltip text="control plane" term_id="control-plane" >}})
|
||||
sets this label on all namespaces. The label value is set
|
||||
to the name of the namespace. You can't change this label's value.
|
||||
|
||||
This is useful if you want to target a specific namespace with a label
|
||||
{{< glossary_tooltip text="selector" term_id="selector" >}}.
|
||||
|
||||
@@ -49,3 +49,19 @@ Use Kompose to:
|
||||
* Translate a Docker Compose file into Kubernetes objects
|
||||
* Go from local Docker development to managing your application via Kubernetes
|
||||
* Convert v1 or v2 Docker Compose `yaml` files or [Distributed Application Bundles](https://docs.docker.com/compose/bundles/)
|
||||
|
||||
## Kui
|
||||
|
||||
[`Kui`](https://github.com/kubernetes-sigs/kui) is a GUI tool that takes your normal
|
||||
`kubectl` command line requests and responds with graphics.
|
||||
|
||||
Kui takes the normal `kubectl` command line requests and responds with graphics. Instead
|
||||
of ASCII tables, Kui provides a GUI rendering with tables that you can sort.
|
||||
|
||||
Kui lets you:
|
||||
|
||||
* Directly click on long, auto-generated resource names instead of copying and pasting
|
||||
* Type in `kubectl` commands and see them execute, even sometimes faster than `kubectl` itself
|
||||
* Query a {{< glossary_tooltip text="Job" term_id="job">}} and see its execution rendered
|
||||
as a waterfall diagram
|
||||
* Click through resources in your cluster using a tabbed UI
|
||||
@@ -19,12 +19,12 @@ The `healthz` endpoint is deprecated (since Kubernetes v1.16), and you should us
|
||||
The `livez` endpoint can be used with the `--livez-grace-period` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) to specify the startup duration.
|
||||
For a graceful shutdown you can specify the `--shutdown-delay-duration` [flag](/docs/reference/command-line-tools-reference/kube-apiserver) with the `/readyz` endpoint.
|
||||
Machines that check the `healthz`/`livez`/`readyz` of the API server should rely on the HTTP status code.
|
||||
A status code `200` indicates the API server is `healthy`/`live`/`ready`, depending of the called endpoint.
|
||||
The more verbose options shown below are intended to be used by human operators to debug their cluster or specially the state of the API server.
|
||||
A status code `200` indicates the API server is `healthy`/`live`/`ready`, depending on the called endpoint.
|
||||
The more verbose options shown below are intended to be used by human operators to debug their cluster or understand the state of the API server.
|
||||
|
||||
The following examples will show how you can interact with the health API endpoints.
|
||||
|
||||
For all endpoints you can use the `verbose` parameter to print out the checks and their status.
|
||||
For all endpoints, you can use the `verbose` parameter to print out the checks and their status.
|
||||
This can be useful for a human operator to debug the current status of the API server, it is not intended to be consumed by a machine:
|
||||
|
||||
```shell
|
||||
@@ -93,7 +93,7 @@ The output show that the `etcd` check is excluded:
|
||||
|
||||
{{< feature-state state="alpha" >}}
|
||||
|
||||
Each individual health check exposes an HTTP endpoint and could can be checked individually.
|
||||
Each individual health check exposes an HTTP endpoint and can be checked individually.
|
||||
The schema for the individual health checks is `/livez/<healthcheck-name>` where `livez` and `readyz` and be used to indicate if you want to check the liveness or the readiness of the API server.
|
||||
The `<healthcheck-name>` path can be discovered using the `verbose` flag from above and take the path between `[+]` and `ok`.
|
||||
These individual health checks should not be consumed by machines but can be helpful for a human operator to debug a system:
|
||||
|
||||
Reference in New Issue
Block a user