# Kubernetes / OpenShift readiness checklist

Sample deliverable · SynapseTel Cloud
Source: https://synapsetel.com/en/delivery-standards#assessment-summary

> Technical guidance and sample checklists on this site are educational reference material. They are not a supported-version list, an executable vendor procedure or a customer result. Validate every step against your installed release, deployment model and the applicable vendor documentation before a production change.

## Scope

Clusters, workloads, owners, and platform dependencies.

- **Environment / release / date:** _Complete for the agreed engagement_
- **Accountable owner:** _Complete for the agreed engagement_

## Prerequisites

- [ ] Inventory clusters, versions, Operators, workloads, network and storage dependencies. Check lifecycle compatibility and identify application owners.

## Checklist

- [ ] Review identity, RBAC, secrets, policy, delivery pipelines, capacity and observability. Test representative workloads and document unresolved risks.
- [ ] Rehearse backup restoration and workload recovery in an agreed test environment. Record measured recovery results against agreed objectives, upgrade checks and handover ownership.
- [ ] Review access, capacity, policy, and observability.
- [ ] Test workload recovery against agreed objectives.

## Pre-flight verification

Record pass, fail or not applicable in the status column and attach the evidence reference for every row before the change window opens.

| Check | Method / role | Pass criteria | Stop condition | Status |
| --- | --- | --- | --- | --- |
| Control plane, nodes and add-ons inside the supported version skew | Platform engineer, cluster version and node version report against the skew policy | Every node and add-on runs a combination the policy and the distribution support | Any node or add-on outside the supported skew for the target release |  |
| Operator compatibility with the target release | Platform engineer, Operator lifecycle review and update channel check | Every installed Operator has a supported channel and path to the target release | An Operator without a supported path or with an unreviewed manual approval pending |  |
| Capacity and disruption budgets | Platform engineer, node capacity report and PodDisruptionBudget review | Nodes can drain one at a time without leaving pods unschedulable | A PodDisruptionBudget that can never be satisfied or no spare capacity for a drain |  |
| Identity, RBAC and secret handling | Security reviewer, role binding review and secret storage check | No application identity holds cluster-wide write access and secrets follow the agreed storage policy | An application identity with cluster-wide write access or a secret committed in plain text |  |
| Backup freshness and restore rehearsal | Platform engineer, control-plane backup from the installed release and an application restore in the test environment | Backup taken on the installed release and a complete application restore measured within the agreed objectives | Backup from another release or a restore slower than the agreed objectives |  |
| Alert routing and delivery pipeline | Platform engineer and application owner, alert test and pipeline dry run | A test alert reaches the on-call route and the pipeline promotes a test change without manual cluster access | A silent alert path or a pipeline step that needs manual cluster credentials |  |

## Stop conditions

- A pre-flight row fails or its evidence reference is missing.
- A cluster operator reports degraded or progressing when the window opens.
- A node drain leaves workloads pending beyond the time the plan allows.
- An application owner needed for validation is not reachable.

## Rollback triggers

- An application restore fails its validation checks in the test environment.
- The cluster stays degraded past the time the plan allows for stabilisation.
- Persistent application data is missing after the change and cannot be restored from its own backup.
- The accountable owner withdraws approval on a stop condition the plan names.

## Acceptance

**Expected result / acceptance threshold**

> Illustrative expected result: Platform and application restore evidence recorded separately; measured recovery meets the agreed objectives.

**Observed result / evidence reference**

_Complete for the agreed engagement_

**Exception / decision / follow-up owner**

_Complete for the agreed engagement_

## Sign-off

| Role | Name | Date |
| --- | --- | --- |
| Prepared by |  |  |
| Reviewed by |  |  |
| Approved by (accountable owner) |  |  |
| Operations handover accepted by |  |  |

## Reference disclaimer

Technical guidance and sample checklists on this site are educational reference material. They are not a supported-version list, an executable vendor procedure or a customer result. Validate every step against your installed release, deployment model and the applicable vendor documentation before a production change.

Technology names describe the environments we work in. They do not imply vendor partnership, certification or authorization. Vendor licenses and support entitlements remain yours; our engineering assistance does not replace them.

Support hours, emergency coverage and response, restoration and resolution targets are stated beside each engagement option and in your agreement. Read them there rather than in a general note.