github.com/GoogleContainerTools/skaffold/v2@v2.13.2/docs-v2/content/en/docs/status-check.md (about)

     1  ---
     2  title: "Deploy Status Checking"
     3  linkTitle: "Deploy Status Checking"
     4  weight: 45
     5  featureId: deploy.status_check
     6  aliases: [/docs/how-tos/status-check, /docs/pipeline-stages/status-check]
     7  ---
     8  
     9  This page describes how Skaffold's _deployment status checking_ waits for deployed resources to become ready, and reports errors if they fails to stabilize within a certain time period.
    10  
    11  ### Overview
    12  
    13  Commands that trigger a deployment, like `skaffold dev`, `skaffold deploy`, `skaffold run`, and `skaffold apply`, monitor select Kubernetes resources and wait for them to become ready.
    14  
    15  Skaffold monitors the status of the following resource types:
    16  * [`Pod`](https://kubernetes.io/docs/concepts/workloads/pods/): check that the pod and its containers are in a `Ready` state.
    17  * [`Deployment`](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/): check the output of `kubectl rollout status deployment` command 
    18  * [`Stateful Sets`](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/): check the output of `kubectl rollout status statefulset` command
    19  
    20  {{<alert title="Note">}}
    21  * Status checking is enabled by default; it can be disabled with the `--status-check=false`
    22  flag, or by setting the `statusCheck` field of the deployment config stanza in
    23  the `skaffold.yaml` to false.
    24  
    25  * If there are multiple skaffold `modules` active, then setting `statusCheck` field of the deployment config stanza will only disable status-check for that config. However using the `--status-check=false` flag will disable it for all modules.
    26  
    27  * Deployed resource logs are suppressed until status-check passes. If you need the detailed logs to diagnose a status failure then rerun with the `--status-check=false` flag.
    28  {{</alert>}}
    29  
    30  ```bash
    31  Waiting for deployments to stabilize
    32   - default:deployment/leeroy-app Waiting for rollout to finish: 0 of 1 updated replicas are available...
    33   - default:deployment/leeroy-web Waiting for rollout to finish: 0 of 1 updated replicas are available...
    34   - default:deployment/leeroy-web is ready. [1/2 deployment(s) still pending]
    35   - default:deployment/leeroy-app is ready.
    36  Deployments stabilized in 2.168799605s
    37  ```
    38  
    39  ### Configuring timeout for `status-check`
    40  
    41  You can also configure the time for deployments to stabilize with the `statusCheckDeadlineSeconds` config field in the `skaffold.yaml`.
    42  
    43  For example, to configure deployments to stabilize within 5 minutes:
    44  {{% readfile file="samples/deployers/status-check.yaml" %}}
    45  
    46  With the `--status-check` flag, for each `Deployment` resource, `skaffold deploy` will wait for
    47  the time specified by [`progressDeadlineSeconds`](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#progress-deadline-seconds)
    48  from the deployment configuration.
    49  
    50  If the `Deployment.spec.progressDeadlineSeconds` is not set, Skaffold will either wait for
    51  the time specified in the `statusCheckDeadlineSeconds` field of the deployment config stanza in the `skaffold.yaml`, or
    52  default to 10 minutes if this is not specified.
    53  
    54  In the case that both `statusCheckDeadlineSeconds` and `Deployment.spec.progressDeadlineSeconds` are set, precedence
    55  is given to `Deployment.spec.progressDeadline` **only if it is less than** `statusCheckDeadlineSeconds`.
    56  
    57  For example, the `Deployment` below with `progressDeadlineSeconds` set to 5 minutes,
    58  
    59  ```yaml
    60  apiVersion: apps/v1
    61  kind: Deployment
    62  metadata:
    63    name: getting-started
    64  spec:
    65    progressDeadlineSeconds: 300
    66    template:
    67      spec:
    68        containers:
    69        - name: cannot-run
    70          image: gcr.io/k8s-skaffold/getting-started-foo
    71  ```
    72  
    73  if the `skaffold.yaml` overrides the deadline to make sure deployment stabilizes in a 60 seconds,
    74  
    75  ```yaml
    76  apiVersion: skaffold/v1
    77  deploy:
    78    statusCheckDeadlineSeconds: 60
    79    kubectl:
    80      manifests:
    81      - k8s-*
    82  ```
    83  
    84  Running `skaffold deploy`
    85  
    86  ```code
    87  skaffold deploy --status-check
    88  ```
    89  will result in an error after waiting for 1 minute:
    90  
    91  ```bash
    92  Tags used in deployment:
    93  Starting deploy...
    94  kubectl client version: 1.11+
    95  kubectl version 1.12.0 or greater is recommended for use with Skaffold
    96   - deployment.apps/getting-started created
    97  Waiting for deployments to stabilize
    98   - default:deployment/getting-started Waiting for rollout to finish: 0 of 1 updated replicas are available...
    99   - default:deployment/getting-started failed. Error: received Ctrl-C or deployments could not stabilize within 1m: kubectl rollout status command interrupted.
   100  FATA[0006] 1/1 deployment(s) failed
   101  ```
   102  
   103  
   104  ### Configuring failure behavior for `status-check`
   105  You can also configure status checking's failure tolerance with the `tolerateFailuresUntilDeadline` config field in the `skaffold.yaml` as well as the flag `--tolerate-failures-until-deadline`.
   106  
   107  The `tolerateFailuresUntilDeadline` modifies the status check to no longer exit when a single deployment fails (desired for local dev) but to instead tolerate failures
   108  until the status check deadline is reached (either default 10 minute deadline or specified via `statusCheckDeadlineSeconds`). As such it should normally be used with the `statusCheckDeadlineSeconds` option so that the deadline is known/set by the user.  This is useful in CI/CD use cases where deployments may fail/flap for a time period while different services initialize but eventually are healthy and stable.  Using this command essentially makes it so that skaffold waits for all deployed resources to be successful or times out, not exiting on any single deployment failure (which might go away) as the status check does by default.
   109  
   110  For example, to configure deployments to stabilize within 5 minutes AND TO NOT FAIL UNTIL the time period is reached:
   111  {{% readfile file="samples/deployers/status-check-tolerateFailuresUntilDeadline.yaml" %}}
   112  
   113  ### Configuring `status-check` for multiple deployers or multiple modules
   114  
   115  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:
   116  - _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.
   117  - _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.