docs: make healthcheck page top level doc #6898
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
gsquared94
force-pushed
the
update-status-check-docs
branch
from
6e35d3d
to
0e7f9b7
Compare
gsquared94
changed the title
gsquared94
added
the
docs-modifications
|
Please visit http://35.236.115.106:1313 to view changes to the docs. |
container-tools-bot
removed
the
docs-modifications
There was a problem hiding this comment.
I know you are just moving an existing section, but we should clean up terminology here: Kubernetes uses "health checks" not the compound form ("healthchecks"). But IMHO we should never have used healthcheck as it is is very confusing with our existing use of "--status-checks" on the command-line. And since Skaffold doesn't watch liveness, we're not really doing health checks. I think we should use "status checks" throughout.
Co-authored-by: Brian de Alwis <bsd@acm.org>
Co-authored-by: Brian de Alwis <bsd@acm.org>
Co-authored-by: Brian de Alwis <bsd@acm.org>
Co-authored-by: Brian de Alwis <bsd@acm.org>
gsquared94
added
the
docs-modifications
|
Please visit http://34.94.139.93:1313 to view changes to the docs. |
container-tools-bot
removed
the
docs-modifications
briandealwis
approved these changes
Nov 23, 2021
| @@ -12,7 +12,7 @@ When Skaffold deploys your application to Kubernetes, it (usually) goes through | |||
| * the Skaffold deployer _renders_ the final Kubernetes manifests: Skaffold replaces untagged image names in the Kubernetes manifests with the final tagged image names. | |||
| It also might go through the extra intermediate step of expanding templates (for helm) or calculating overlays (for kustomize). | |||
| * the Skaffold deployer _deploys_ the final Kubernetes manifests to the cluster | |||
| * the Skaffold deployer waits for the deployed resources to stabilize. See [healthchecks]({{< relref "/docs/workflows/ci-cd.md#waiting-for-skaffold-deployments-using-healthcheck" >}}). | |||
| * the Skaffold deployer waits for the deployed resources to stabilize. See [status-check]({{< relref "/docs/pipeline-stages/status-check" >}}). | |||
There was a problem hiding this comment.
WDYT
Suggested change
| * the Skaffold deployer waits for the deployed resources to stabilize. See [status-check]({{< relref "/docs/pipeline-stages/status-check" >}}). | |
| * the Skaffold deployer performs [status checks]({{< relref "/docs/pipeline-stages/status-check" >}}) and waits for the deployed resources to stabilize. |
| @@ -152,4 +152,4 @@ deploy: | |||
| containerName: hooks-example* # use a glob pattern to prefix-match the container name and pod name for deployments, stateful-sets, etc. | |||
| podName: hooks-example-deployment* | |||
| ``` | |||
| This config snippet defines a simple `echo` command to run inside the containers that match `podName` and `containerName`, before and after each `kubectl` deploy. The `after` container commands are only run post [healthchecks]({{< relref "/docs/workflows/ci-cd.md#waiting-for-skaffold-deployments-using-healthcheck" >}}) on the deployment are complete. Also, unlike the `sync` container hooks, skaffold cannot determine the target container from just the config definition, and needs the `podName` and `containerName`. | |||
| This config snippet defines a simple `echo` command to run inside the containers that match `podName` and `containerName`, before and after each `kubectl` deploy. The `after` container commands are only run post [status-check]({{< relref "/docs/pipeline-stages/status-check" >}}) on the deployment are complete. Also, unlike the `sync` container hooks, skaffold cannot determine the target container from just the config definition, and needs the `podName` and `containerName`. | |||
There was a problem hiding this comment.
Suggested change
| This config snippet defines a simple `echo` command to run inside the containers that match `podName` and `containerName`, before and after each `kubectl` deploy. The `after` container commands are only run post [status-check]({{< relref "/docs/pipeline-stages/status-check" >}}) on the deployment are complete. Also, unlike the `sync` container hooks, skaffold cannot determine the target container from just the config definition, and needs the `podName` and `containerName`. | |
| This config snippet defines a simple `echo` command to run inside the containers that match `podName` and `containerName`, before and after each `kubectl` deploy. The `after` container commands are only run after the [deployment status checks]({{< relref "/docs/pipeline-stages/status-check" >}}) are complete. Also, unlike the `sync` container hooks, skaffold cannot determine the target container from just the config definition, and needs the `podName` and `containerName`. |
| * [`Stateful Sets`](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/): check the output of `kubectl rollout status statefulset` command | ||
| * [`Google Cloud Config Connector resources`](https://cloud.google.com/config-connector/docs/overview): check that the resource state has a `Ready` condition set to `True`. | ||
|
|
||
| {{<alert title="Note">}} |
There was a problem hiding this comment.
This doesn't seem like it needs a call-out?
| * [`Google Cloud Config Connector resources`](https://cloud.google.com/config-connector/docs/overview): check that the resource state has a `Ready` condition set to `True`. | ||
|
|
||
| {{<alert title="Note">}} | ||
| * `status-check` is enabled by default; it can be disabled with the `--status-check=false` |
There was a problem hiding this comment.
Replace "status-check" with "status checking"?
Suggested change
| * `status-check` is enabled by default; it can be disabled with the `--status-check=false` | |
| * Status checking is enabled by default; it can be disabled with the `--status-check=false` |
| Deployments stabilized in 2.168799605s | ||
| ``` | ||
|
|
||
| ### Configuring timeout for `status-check` |
There was a problem hiding this comment.
Suggested change
| ### Configuring timeout for `status-check` | |
| ### Configuring timeout for status checking |
| FATA[0006] 1/1 deployment(s) failed | ||
| ``` | ||
|
|
||
| ### Configuring `status-check` for multiple deployers or multiple modules |
There was a problem hiding this comment.
Suggested change
| ### Configuring `status-check` for multiple deployers or multiple modules | |
| ### Configuring status checking for multiple deployers or multiple modules |
Comment on lines
+106
to
+108
| If you define multiple deployers, say `kubectl`, `helm`, and `kustomize`, all in the same skaffold config, or compose a multi-config project by importing other configs as dependencies, then the `status-check` can be run in one of two ways: | ||
| - _Single status check after all deployers are run_. This is the default and it runs a single `status-check` at the end for resources deployed from all deployers across all skaffold configs. | ||
| - _Per-deployer status check_. This can be enabled by using the `--iterative-status-check=true` flag. This will run a `status-check` iteratively after every individual deployer runs. This can be especially useful when there are startup dependencies between services, or you need to strictly enforce the time and order in which resources are deployed. |
There was a problem hiding this comment.
Suggested change
| If you define multiple deployers, say `kubectl`, `helm`, and `kustomize`, all in the same skaffold config, or compose a multi-config project by importing other configs as dependencies, then the `status-check` can be run in one of two ways: | |
| - _Single status check after all deployers are run_. This is the default and it runs a single `status-check` at the end for resources deployed from all deployers across all skaffold configs. | |
| - _Per-deployer status check_. This can be enabled by using the `--iterative-status-check=true` flag. This will run a `status-check` iteratively after every individual deployer runs. This can be especially useful when there are startup dependencies between services, or you need to strictly enforce the time and order in which resources are deployed. | |
| If you define multiple deployers, say `kubectl`, `helm`, and `kustomize`, all in the same skaffold config, or compose a multi-config project by importing other configs as dependencies, then the status check can be run in one of two ways: | |
| - _Single status check after all deployers are run_. This is the default and it runs a single status check at the end for resources deployed from all deployers across all skaffold configs. | |
| - _Per-deployer status check_. This can be enabled by using the `--iterative-status-check=true` flag. This will run a status check after every individual deployer runs. This can be especially useful when there are startup dependencies between services, or you need to strictly enforce the time and order in which resources are deployed. |
| @@ -175,7 +75,7 @@ Skaffold allows separating the generation of fully-hydrated Kubernetes manifests | |||
| `skaffold render` builds all application images from your artifacts, templates the newly-generated image tags into your Kubernetes manifests (based on your project's deployment configuration), and then prints out the final hydrated manifests to a file or your terminal. | |||
| This allows you to capture the full, declarative state of your application in configuration, such that _applying_ the changes to your cluster can be done as a separate step. | |||
|
|
|||
| `skaffold apply` consumes one or more fully-hydrated Kubernetes manifests, and then sends the results directly to the Kubernetes control plane via `kubectl` to create resources on the target cluster. After creating the resources on your cluster, `skaffold apply` uses Skaffold's built-in health checking to monitor the created resources for readiness. See [resource health checks]({{<relref "/docs/workflows/ci-cd#waiting-for-skaffold-deployments-using-healthcheck">}}) for more information on how Skaffold's resource health checking works. | |||
| `skaffold apply` consumes one or more fully-hydrated Kubernetes manifests, and then sends the results directly to the Kubernetes control plane via `kubectl` to create resources on the target cluster. After creating the resources on your cluster, `skaffold apply` uses Skaffold's built-in health checking to monitor the created resources for readiness. See [resource health checks]({{<relref "/docs/pipeline-stages/status-check">}}) for more information on how Skaffold's resource health checking works. | |||
There was a problem hiding this comment.
Suggested change
| `skaffold apply` consumes one or more fully-hydrated Kubernetes manifests, and then sends the results directly to the Kubernetes control plane via `kubectl` to create resources on the target cluster. After creating the resources on your cluster, `skaffold apply` uses Skaffold's built-in health checking to monitor the created resources for readiness. See [resource health checks]({{<relref "/docs/pipeline-stages/status-check">}}) for more information on how Skaffold's resource health checking works. | |
| `skaffold apply` consumes one or more fully-hydrated Kubernetes manifests, and then sends the results directly to the Kubernetes control plane via `kubectl` to create resources on the target cluster. After creating the resources on your cluster, `skaffold apply` uses Skaffold's built-in health checking to monitor the created resources for readiness. See [deployment status checking]({{<relref "/docs/pipeline-stages/status-check">}}) for more information on how Skaffold's resource health checking works. |
gsquared94
added a commit
to gsquared94/skaffold
that referenced
this pull request
Nov 23, 2021
gsquared94
added a commit
that referenced
this pull request
Nov 24, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
http://35.236.115.106:1313/docs/pipeline-stages/healthcheck/http://34.94.139.93:1313/docs/pipeline-stages/status-check/