Fix command descriptions to match new cluster validation behavior

This commit is contained in:
John Gardiner Myers 2020-03-15 17:21:06 -07:00
parent e7846fd0db
commit 2e920d75c1
6 changed files with 6 additions and 6 deletions

View File

@ -52,7 +52,7 @@ var (
If rolling-update does not report that the cluster needs to be rolled, you can force the cluster to be
rolled with the force flag. Rolling update drains and validates the cluster by default. A cluster is
deemed validated when all required nodes are running and all pods in the kube-system namespace are operational.
deemed validated when all required nodes are running and all pods with a critical priority are operational.
When a node is deleted, rolling-update sleeps the interval for the node type, and then tries for the same period
of time for the cluster to be validated. For instance, setting --master-interval=3m causes rolling-update
to wait for 3 minutes after a master is rolled, and another 3 minutes for the cluster to stabilize and pass

View File

@ -32,7 +32,7 @@ var (
1. All k8s masters are running and have "Ready" status.
2. All k8s nodes are running and have "Ready" status.
3. Component status returns healthy for all components.
4. All pods in the kube-system namespace are running and healthy.
4. All pods with a critical priority are running and healthy.
`))
validateExample = templates.Examples(i18n.T(`

View File

@ -15,7 +15,7 @@ To perform a rolling update, you need to update the cloud resources first with t
If rolling-update does not report that the cluster needs to be rolled, you can force the cluster to be
rolled with the force flag. Rolling update drains and validates the cluster by default. A cluster is
deemed validated when all required nodes are running and all pods in the kube-system namespace are operational.
deemed validated when all required nodes are running and all pods with a critical priority are operational.
When a node is deleted, rolling-update sleeps the interval for the node type, and then tries for the same period
of time for the cluster to be validated. For instance, setting --master-interval=3m causes rolling-update
to wait for 3 minutes after a master is rolled, and another 3 minutes for the cluster to stabilize and pass

View File

@ -15,7 +15,7 @@ To perform a rolling update, you need to update the cloud resources first with t
If rolling-update does not report that the cluster needs to be rolled, you can force the cluster to be
rolled with the force flag. Rolling update drains and validates the cluster by default. A cluster is
deemed validated when all required nodes are running and all pods in the kube-system namespace are operational.
deemed validated when all required nodes are running and all pods with a critical priority are operational.
When a node is deleted, rolling-update sleeps the interval for the node type, and then tries for the same period
of time for the cluster to be validated. For instance, setting --master-interval=3m causes rolling-update
to wait for 3 minutes after a master is rolled, and another 3 minutes for the cluster to stabilize and pass

View File

@ -12,7 +12,7 @@ This commands validates the following components:
1. All k8s masters are running and have "Ready" status.
2. All k8s nodes are running and have "Ready" status.
3. Component status returns healthy for all components.
4. All pods in the kube-system namespace are running and healthy.
4. All pods with a critical priority are running and healthy.
### Examples

View File

@ -12,7 +12,7 @@ This commands validates the following components:
1. All k8s masters are running and have "Ready" status.
2. All k8s nodes are running and have "Ready" status.
3. Component status returns healthy for all components.
4. All pods in the kube-system namespace are running and healthy.
4. All pods with a critical priority are running and healthy.
```
kops validate cluster [flags]