Merge pull request #30705 from jlbutler/merged-main-dev-1.23
Periodic integration branch sync for 1.23
This commit is contained in:
Kubernetes Prow Robot
@@ -260,12 +260,6 @@ Multus supports all [reference plugins](https://github.com/containernetworking/p
|
||||
|
||||
[NSX-T Container Plug-in (NCP)](https://docs.vmware.com/en/VMware-NSX-T/2.0/nsxt_20_ncp_kubernetes.pdf) provides integration between NSX-T and container orchestrators such as Kubernetes, as well as integration between NSX-T and container-based CaaS/PaaS platforms such as Pivotal Container Service (PKS) and OpenShift.
|
||||
|
||||
### OpenVSwitch
|
||||
|
||||
[OpenVSwitch](https://www.openvswitch.org/) is a somewhat more mature but also
|
||||
complicated way to build an overlay network. This is endorsed by several of the
|
||||
"Big Shops" for networking.
|
||||
|
||||
### OVN (Open Virtual Networking)
|
||||
|
||||
OVN is an opensource network virtualization solution developed by the
|
||||
|
||||
@@ -145,7 +145,7 @@ Kubernetes provides several built-in authentication methods, and an [Authenticat
|
||||
|
||||
### Authorization
|
||||
|
||||
[Authorization](/docs/reference/access-authn-authz/webhook/) determines whether specific users can read, write, and do other operations on API resources. It works at the level of whole resources -- it doesn't discriminate based on arbitrary object fields. If the built-in authorization options don't meet your needs, and [Authorization webhook](/docs/reference/access-authn-authz/webhook/) allows calling out to user-provided code to make an authorization decision.
|
||||
[Authorization](/docs/reference/access-authn-authz/authorization/) determines whether specific users can read, write, and do other operations on API resources. It works at the level of whole resources -- it doesn't discriminate based on arbitrary object fields. If the built-in authorization options don't meet your needs, [Authorization webhook](/docs/reference/access-authn-authz/webhook/) allows calling out to user-provided code to make an authorization decision.
|
||||
|
||||
|
||||
### Dynamic Admission Control
|
||||
|
||||
@@ -39,7 +39,7 @@ namespace.
|
||||
|
||||
DNS queries may be expanded using the pod's `/etc/resolv.conf`. Kubelet
|
||||
sets this file for each pod. For example, a query for just `data` may be
|
||||
expanded to `data.test.cluster.local`. The values of the `search` option
|
||||
expanded to `data.test.svc.cluster.local`. The values of the `search` option
|
||||
are used to expand queries. To learn more about DNS queries, see
|
||||
[the `resolv.conf` manual page.](https://www.man7.org/linux/man-pages/man5/resolv.conf.5.html)
|
||||
|
||||
|
||||
@@ -550,7 +550,7 @@ The default is `ClusterIP`.
|
||||
* `ClusterIP`: Exposes the Service on a cluster-internal IP. Choosing this value
|
||||
makes the Service only reachable from within the cluster. This is the
|
||||
default `ServiceType`.
|
||||
* [`NodePort`](#nodeport): Exposes the Service on each Node's IP at a static port
|
||||
* [`NodePort`](#type-nodeport): Exposes the Service on each Node's IP at a static port
|
||||
(the `NodePort`). A `ClusterIP` Service, to which the `NodePort` Service
|
||||
routes, is automatically created. You'll be able to contact the `NodePort` Service,
|
||||
from outside the cluster,
|
||||
|
||||
@@ -71,7 +71,7 @@ volume mount will not receive updates for those volume sources.
|
||||
|
||||
## SecurityContext interactions
|
||||
|
||||
The [proposal for file permission handling in projected service account volume](https://github.com/kubernetes/enhancements/pull/1598)
|
||||
The [proposal for file permission handling in projected service account volume](https://github.com/kubernetes/enhancements/tree/master/keps/sig-storage/2451-service-account-token-volumes#token-volume-projection)
|
||||
enhancement introduced the projected files having the the correct owner
|
||||
permissions set.
|
||||
|
||||
@@ -100,6 +100,8 @@ into their own volume mount outside of `C:\`.
|
||||
By default, the projected files will have the following ownership as shown for
|
||||
an example projected volume file:
|
||||
```powershell
|
||||
PS C:\> Get-Acl C:\var\run\secrets\kubernetes.io\serviceaccount\..2021_08_31_22_22_18.318230061\ca.crt | Format-List
|
||||
|
||||
Path : Microsoft.PowerShell.Core\FileSystem::C:\var\run\secrets\kubernetes.io\serviceaccount\..2021_08_31_22_22_18.318230061\ca.crt
|
||||
Owner : BUILTIN\Administrators
|
||||
Group : NT AUTHORITY\SYSTEM
|
||||
|
||||
@@ -470,14 +470,14 @@ This internal provisioner of OpenStack is deprecated. Please use [the external c
|
||||
|
||||
There are two types of provisioners for vSphere storage classes:
|
||||
|
||||
- [CSI provisioner](#csi-provisioner): `csi.vsphere.vmware.com`
|
||||
- [CSI provisioner](#vsphere-provisioner-csi): `csi.vsphere.vmware.com`
|
||||
- [vCP provisioner](#vcp-provisioner): `kubernetes.io/vsphere-volume`
|
||||
|
||||
In-tree provisioners are [deprecated](/blog/2019/12/09/kubernetes-1-17-feature-csi-migration-beta/#why-are-we-migrating-in-tree-plugins-to-csi). For more information on the CSI provisioner, see [Kubernetes vSphere CSI Driver](https://vsphere-csi-driver.sigs.k8s.io/) and [vSphereVolume CSI migration](/docs/concepts/storage/volumes/#csi-migration-5).
|
||||
|
||||
#### CSI Provisioner {#vsphere-provisioner-csi}
|
||||
|
||||
The vSphere CSI StorageClass provisioner works with Tanzu Kubernetes clusters. For an example, refer to the [vSphere CSI repository](https://raw.githubusercontent.com/kubernetes-sigs/vsphere-csi-driver/master/example/vanilla-k8s-file-driver/example-sc.yaml).
|
||||
The vSphere CSI StorageClass provisioner works with Tanzu Kubernetes clusters. For an example, refer to the [vSphere CSI repository](https://github.com/kubernetes-sigs/vsphere-csi-driver/blob/master/example/vanilla-k8s-RWM-filesystem-volumes/example-sc.yaml).
|
||||
|
||||
#### vCP Provisioner
|
||||
|
||||
|
||||
@@ -811,7 +811,7 @@ For more details, see the [Portworx volume](https://github.com/kubernetes/exampl
|
||||
### projected
|
||||
|
||||
A projected volume maps several existing volume sources into the same
|
||||
directory. For more details, see [projected volumes](/docs/concepts/storage/projected-volumes/)
|
||||
directory. For more details, see [projected volumes](/docs/concepts/storage/projected-volumes/).
|
||||
|
||||
### quobyte (deprecated) {#quobyte}
|
||||
|
||||
|
||||
@@ -250,7 +250,7 @@ back-off count is reset when a Job's Pod is deleted or successful without any
|
||||
other Pods for the Job failing around that time.
|
||||
|
||||
{{< note >}}
|
||||
If your job has `restartPolicy = "OnFailure"`, keep in mind that your container running the Job
|
||||
If your job has `restartPolicy = "OnFailure"`, keep in mind that your Pod running the Job
|
||||
will be terminated once the job backoff limit has been reached. This can make debugging the Job's executable more difficult. We suggest setting
|
||||
`restartPolicy = "Never"` when debugging the Job or using a logging system to ensure output
|
||||
from failed Jobs is not lost inadvertently.
|
||||
@@ -346,6 +346,25 @@ If the field is set to `0`, the Job will be eligible to be automatically deleted
|
||||
immediately after it finishes. If the field is unset, this Job won't be cleaned
|
||||
up by the TTL controller after it finishes.
|
||||
|
||||
{{< note >}}
|
||||
It is recommended to set `ttlSecondsAfterFinished` field because unmanaged jobs
|
||||
(Jobs that you created directly, and not indirectly through other workload APIs
|
||||
such as CronJob) have a default deletion
|
||||
policy of `orphanDependents` causing Pods created by an unmanaged Job to be left around
|
||||
after that Job is fully deleted.
|
||||
Even though the {{< glossary_tooltip text="control plane" term_id="control-plane" >}} eventually
|
||||
[garbage collects](/docs/concepts/workloads/pods/pod-lifecycle/#pod-garbage-collection)
|
||||
the Pods from a deleted Job after they either fail or complete, sometimes those
|
||||
lingering pods may cause cluster performance degradation or in worst case cause the
|
||||
cluster to go offline due to this degradation.
|
||||
|
||||
You can use [LimitRanges](/docs/concepts/policy/limit-range/) and
|
||||
[ResourceQuotas](/docs/concepts/policy/resource-quotas/) to place a
|
||||
cap on the amount of resources that a particular namespace can
|
||||
consume.
|
||||
{{< /note >}}
|
||||
|
||||
|
||||
## Job patterns
|
||||
|
||||
The Job object can be used to support reliable parallel execution of Pods. The Job object is not
|
||||
|
||||
@@ -128,8 +128,8 @@ The "intended" number of pods is computed from the `.spec.replicas` of the workl
|
||||
that is managing those pods. The control plane discovers the owning workload resource by
|
||||
examining the `.metadata.ownerReferences` of the Pod.
|
||||
|
||||
PDBs cannot prevent [involuntary disruptions](#voluntary-and-involuntary-disruptions) from
|
||||
occurring, but they do count against the budget.
|
||||
[Involuntary disruptions](#voluntary-and-involuntary-disruptions) cannot be prevented by PDBs; however they
|
||||
do count against the budget.
|
||||
|
||||
Pods which are deleted or unavailable due to a rolling upgrade to an application do count
|
||||
against the disruption budget, but workload resources (such as Deployment and StatefulSet)
|
||||
|
||||
@@ -26,6 +26,7 @@ Each day in a week-long shift as PR Wrangler:
|
||||
- If you need to verify content, comment on the PR and request more details.
|
||||
- Assign relevant `sig/` label(s).
|
||||
- If needed, assign reviewers from the `reviewers:` block in the file's front matter.
|
||||
- You can also tag a [SIG](https://github.com/kubernetes/community/blob/master/sig-list.md) for a review by commenting `@kubernetes/<sig>-pr-reviews` on the PR.
|
||||
- Use the `/approve` comment to approve a PR for merging. Merge the PR when ready.
|
||||
- PRs should have a `/lgtm` comment from another member before merging.
|
||||
- Consider accepting technically accurate content that doesn't meet the [style guidelines](/docs/contribute/style/style-guide/). Open a new issue with the label `good first issue` to address style concerns.
|
||||
|
||||
@@ -14,7 +14,7 @@ For additional information on creating new content for the Kubernetes
|
||||
documentation, read the [Documentation Content Guide](/docs/contribute/style/content-guide/).
|
||||
|
||||
Changes to the style guide are made by SIG Docs as a group. To propose a change
|
||||
or addition, [add it to the agenda](https://docs.google.com/document/d/1ddHwLK3kUMX1wVFIwlksjTk0MsqitBnWPe1LRa1Rx5A/edit) for an upcoming SIG Docs meeting, and attend the meeting to participate in the
|
||||
or addition, [add it to the agenda](https://bit.ly/sig-docs-agenda) for an upcoming SIG Docs meeting, and attend the meeting to participate in the
|
||||
discussion.
|
||||
|
||||
<!-- body -->
|
||||
|
||||
@@ -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:
|
||||
|
||||
@@ -79,7 +79,7 @@ If systemd doesn't use cgroup v2 by default, you can configure the system to use
|
||||
# dnf install -y grubby && \
|
||||
sudo grubby \
|
||||
--update-kernel=ALL \
|
||||
--args=”systemd.unified_cgroup_hierarchy=1"
|
||||
--args="systemd.unified_cgroup_hierarchy=1"
|
||||
```
|
||||
|
||||
To apply the configuration, it is necessary to reboot the node.
|
||||
|
||||
@@ -383,6 +383,12 @@ Run 'kubectl get nodes' on control-plane to see this machine join.
|
||||
A few seconds later, you should notice this node in the output from `kubectl get
|
||||
nodes` when run on the control-plane node.
|
||||
|
||||
{{< note >}}
|
||||
As the cluster nodes are usually initialized sequentially, the CoreDNS Pods are likely to all run
|
||||
on the first control-plane node. To provide higher availability, please rebalance the CoreDNS Pods
|
||||
with `kubectl -n kube-system rollout restart deployment coredns` after at least one new node is joined.
|
||||
{{< /note >}}
|
||||
|
||||
### (Optional) Controlling your cluster from machines other than the control-plane node
|
||||
|
||||
In order to get a kubectl on some other computer (e.g. laptop) to talk to your
|
||||
|
||||
@@ -76,7 +76,7 @@ then paging can slow down performance.
|
||||
You can place bounds on memory use for workloads using the kubelet
|
||||
parameters `--kubelet-reserve` and/or `--system-reserve`; these account
|
||||
for memory usage on the node (outside of containers), and reduce
|
||||
[NodeAllocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable)).
|
||||
[NodeAllocatable](/docs/tasks/administer-cluster/reserve-compute-resources/#node-allocatable).
|
||||
As you deploy workloads, set resource limits on containers. This also subtracts from
|
||||
`NodeAllocatable` and prevents the scheduler from adding more pods once a node is full.
|
||||
|
||||
|
||||
@@ -158,7 +158,7 @@ Install-WindowsFeature -Name containers
|
||||
```
|
||||
|
||||
Install Docker
|
||||
Instructions to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://hub.docker.com/editions/enterprise/docker-ee-server-windows).
|
||||
Instructions to do so are available at [Install Docker Engine - Enterprise on Windows Servers](https://docs.microsoft.com/en-us/virtualization/windowscontainers/quick-start/set-up-environment?tabs=Windows-Server#install-docker).
|
||||
|
||||
#### Install wins, kubelet, and kubeadm
|
||||
|
||||
|
||||
@@ -150,13 +150,12 @@ you need is an existing `docker-compose.yml` file.
|
||||
```
|
||||
|
||||
```bash
|
||||
kubectl apply -f frontend-service.yaml,redis-master-service.yaml,redis-slave-service.yaml,frontend-deployment.yaml,
|
||||
kubectl apply -f frontend-service.yaml,redis-master-service.yaml,redis-slave-service.yaml,frontend-deployment.yaml,redis-master-deployment.yaml,redis-slave-deployment.yaml
|
||||
```
|
||||
|
||||
The output is similar to:
|
||||
|
||||
```none
|
||||
redis-master-deployment.yaml,redis-slave-deployment.yaml
|
||||
service/frontend created
|
||||
service/redis-master created
|
||||
service/redis-slave created
|
||||
|
||||
@@ -11,7 +11,11 @@ communication.
|
||||
|
||||
## {{% heading "prerequisites" %}}
|
||||
|
||||
{{< include "task-tutorial-prereqs.md" >}}
|
||||
You need to have a Kubernetes cluster, and the kubectl command-line tool must
|
||||
be configured to communicate with your cluster. It is recommended to run this
|
||||
tutorial on a cluster with at least two nodes that are not acting as control
|
||||
plane hosts. If you do not already have a cluster, you can create one by using
|
||||
[minikube](https://minikube.sigs.k8s.io/docs/tutorials/multi_node/).
|
||||
|
||||
<!-- steps -->
|
||||
|
||||
|
||||
@@ -162,9 +162,19 @@ Events: <none>
|
||||
|
||||
## Get the Certificate Signing Request Approved
|
||||
|
||||
Approving the certificate signing request is either done by an automated
|
||||
approval process or on a one off basis by a cluster administrator. More
|
||||
information on what this involves is covered below.
|
||||
Approving the [certificate signing request](/docs/reference/access-authn-authz/certificate-signing-requests/)
|
||||
is either done by an automated approval process or on a one off basis by a cluster
|
||||
administrator. If you're authorized to approve a certificate request, you can do that
|
||||
manually using `kubectl`; for example:
|
||||
|
||||
```shell
|
||||
kubectl certificate approve my-svc.my-namespace
|
||||
```
|
||||
|
||||
```none
|
||||
certificatesigningrequest.certificates.k8s.io/my-svc.my-namespace approved
|
||||
```
|
||||
|
||||
|
||||
## Download the Certificate and Use It
|
||||
|
||||
|
||||
@@ -16,7 +16,7 @@ If you have an alias for kubectl, you can extend shell completion to work with t
|
||||
|
||||
```zsh
|
||||
echo 'alias k=kubectl' >>~/.zshrc
|
||||
echo 'complete -F __start_kubectl k' >>~/.zshrc
|
||||
echo 'compdef __start_kubectl k' >>~/.zshrc
|
||||
```
|
||||
|
||||
After reloading your shell, kubectl autocompletion should be working.
|
||||
|
||||
@@ -894,8 +894,7 @@ Use this command to get the nodes in your cluster.
|
||||
kubectl get nodes
|
||||
```
|
||||
|
||||
Use [`kubectl cordon`](/docs/reference/generated/kubectl/kubectl-commands/#cordon) to
|
||||
cordon all but four of the nodes in your cluster.
|
||||
This tutorial assumes a cluster with at least four nodes. If the cluster has more than four, use [`kubectl cordon`](/docs/reference/generated/kubectl/kubectl-commands/#cordon) to cordon all but four nodes. Constraining to four nodes will ensure Kubernetes encounters affinity and PodDisruptionBudget constraints when scheduling zookeeper Pods in the following maintenance simulation.
|
||||
|
||||
```shell
|
||||
kubectl cordon <node-name>
|
||||
|
||||
Reference in New Issue
Block a user