# Concepts
Source: https://docs.chkk.io/knowledge-graph/concepts
Core concept definitions for Chkk's Knowledge Graph.
## Project
A ***Project*** is software that provides some functionality.
The term "project" was chosen to align with a similar [deps.dev](https://deps.dev) concept.
Each Project has a ProjectType. Valid ProjectTypes include:
* *platform*: The Project represents a software platform, such as the Cloud Native Project itself.
* *addon*: The Project represents a Cloud Native Project, which is defined as some software that extends the functionality of the Platform it is running on.
* *application-service*: The Project represents application code that provides essential services to the rest of the application stack.
* *control-plane-provider*: The Project represents a control plane service, such as GKE, EKS, or NKP.
* *application*: The Project represents customer-specific or internal code.
***Important***: A Project is *not* the packaging of that software. Packaging of Projects (e.g. Helm, Kustomize, etc.) is described by the Package model–see below.
Chkk collects a variety of raw information about hundreds of Projects, including:
* Versioning scheme and release cadence
* Licensing and support models
* Source code locations
* Releases and release artifacts
* Components and images
* Dependencies
* Bugs, issues and risk assessments
* Changelogs, upgrade considerations, and migration guides
* Related packages–Helm charts, Kustomize Overlay Directories, etc.
* Version compatibility matrices
* Deprecation and end-of-life schedules
* Service health and readiness checks
## Project Component
A ***Project Component*** is a separate binary, daemon, or subsystem of a Project.
Chkk's Knowledge Graph stores a wealth of information about the component breakdown of a Project.
We track changes to a Project's component breakdown over time, allowing us to provide highly-contextual answers to questions like "At what version of ArgoCD was the ApplicationSet controller bundled with the ArgoCD project as a core component?" (hint: the answer is ArgoCD 2.3). This gives Chkk's Knowledge Graph time-machine superpowers!
## Project Release and Release Series
A Project may have one or more ***Project Releases***. A Project Release is the versioned publication of a Project and typically has one or more release artifacts tagged with the Project Release's version.
A Project Release is always associated with a single Project Release Series. The Project Release Series' version will depend on the versioning scheme the Project uses. For example, if a Project uses Semantic Versioning, the Project Release Series will be the major and minor version number.
## Change
A Project Release can have many ***Changes***. A Change describes a change that was made to some code, configuration default or configuration structure. Changes are typically listed in changelogs or release note collections.
Changes can add new functionality, remove functionality, and potentially break customer environments.
A Change can have many ***Change Enrichments***. A Change Enrichment is any refinement or modification made to the original content of the Change record. AI agents enrich a Change record, for example, by adding classification labels, researching the accuracy of a release note, and rewriting it using additional context (e.g. GitHub Issues / PRs).
## Package
A ***Package*** is a named bundle of software that is bundled (and identified) in the format of a specific PackageSystem.
The term "package" was chosen to align with an identical [deps.dev](https://deps.dev) concept.
A Package has a ***Package System*** which indicates the format of the Package. Chkk supports two package systems:
* *helm*: Helm Charts
* *kube*: Raw manifests, including Kustomize overlays
**Note**: Helm is both a Package System and a Deployment System. The Helm Chart is a Package whereas the helm install CLI command is the Deployment System.
## Package Component
A Package has zero or more **Package Components**. For Packages using the *helm* or *kube* Package System, these Package Components represent a Resource (Deployment, DaemonSet or StatefulSet) that is installed by the Package.
Package Components include one or more Project Components. For Packages using the *helm* or *kube* PackageSystem, these Project Components represent a Docker Image that is in the `spec.templates.spec.containers` field of the Package Component's Resource definition.
Thus, the Package itself is associated with one or more Projects via these Project Component -> Package Component -> Package relationships.
Like Project Components, Chkk tracks changes to the composition of a Package and its configuration over time, giving us an ability to view the evolution of a Package.
## Service Health & Readiness Checks
**Service Health & Readiness Checks** are diagnostic entities that validate project health through **validation relationships** before, during, and after upgrades. These checks are curated for specific project versions and deployment patterns, providing automated validation of upgrade success and system stability.
# Coverage
Source: https://docs.chkk.io/knowledge-graph/coverage
Current coverage metrics for Chkk's Knowledge Graph data.
Last Updated: October 18, 2025
| Data Type | Count |
| -------------------------------------------- | --------- |
| Cloud Native Projects | 318 |
| Project Components | 614 |
| Project Releases | 45,570 |
| Project Release Series | 13,153 |
| Packages | 424 |
| Package Components | 720 |
| Package Releases | 35,102 |
| Package-Project Relationships | 26,323 |
| Version Compatibility Matrices | 1,274 |
| Enriched Changelog Records | 47,233 |
| OCI Artifacts | 3,265,122 |
| OCI-Project Relationships | 738,241 |
| OCI Tags | 921,662 |
| OCI Repositories | 1,717 |
| Project Releases with Safety & Health Checks | 6778 |
# Overview
Source: https://docs.chkk.io/knowledge-graph/overview
The foundation of Chkk's Collective Learning Technology — an AI-curated knowledge system about the Cloud Native ecosystem.
The **Chkk Knowledge Graph** models the Cloud Native ecosystem — capturing how projects evolve, depend on one another, and interact at runtime. It provides the contextual intelligence required for **safe, automated lifecycle decisions** across hundreds of Cloud Native Projects.
Unlike static metadata stores, the Knowledge Graph is actively constructed and maintained by task-specific AI agents operating on a source-grounded foundation. All authoritative sources are integrated into a **Grounding Layer** that is both **AI-curated and subject to human oversight**. This layer models and organizes the data required to reliably identify and relate Cloud Native projects, releases, and components across the ecosystem. The **Chkk Research Team** reviews and validates every source incorporated into this layer to ensure ongoing trustworthiness. Agents, workflows, and tools rely on this curated corpus to prevent AI hallucinations and uphold the accuracy of knowledge attributes — enabling **planet-scale operations without human bottlenecks**.
Within this governed system, Chkk’s task-specific agents operate in a continuous cycle of learning and validation. They **collect** raw data from authoritative sources, **curate** and normalize it into canonical object models, **link** related entities to form a connected topology, **refine** previously discovered facts through validation pipelines, and **enrich** the resulting relationships with higher-order context such as version compatibilities, upgrade paths, and health signals. Together, these stages ensure the Knowledge Graph remains accurate, explainable, and continuously up to date.
The Chkk Knowledge Graph serves as the **foundation for all agentic reasoning** within the platform — powering automated upgrade planning, version recommendations, changelog intelligence, and pre- and post-flight validation. It transforms fragmented upstream data into a **cohesive, evolving system of lifecycle intelligence**, enabling both humans and AI agents to operate Cloud Native software safely, predictably, and with full context.
## Explore the Knowledge Graph
Dive deep into the core concepts, data models, and AI systems that power the Knowledge Graph.
Explore the current scale and metrics showing our comprehensive ecosystem coverage.
# How it Works
Source: https://docs.chkk.io/overview/how-it-works
Watch Chkk in action and explore its end-to-end workflow from cluster registration to automated IaC PR generation.
80% of Cloud Native lifecycle management work happens before you deploy your changes—inventory, dependency mapping, risk analysis, compatibility analysis and planning. Chkk automates that front-loaded toil and then generates environment-aware IaC PRs you can review and merge."
**What happens**: Chkk's Connector discovers resources, versions, and packaging patterns—forming the inventory foundation for all follow-on analysis.
**What happens**: Get a targeted view of upgrade candidates, EOLs, incompatibilities, and recommended paths so teams know where to focus first.
**What happens**: Ask Chkk for a Project-specific Upgrade Template (e.g., cert-manager, ExternalDNS). Templates encode the safe path—including guardrails, checks, and strategy (in-place, canary/blue-green).
**What happens**: Designated owners review and approve before anything becomes actionable, ensuring single-threaded, accountable governance.
**What happens**: From the approved Template, create a Plan scoped to a specific cluster/env. The Plan becomes the source of truth for the upcoming change.
**What happens**: See the rationale (EOL, breaking changes, bug/security fixes, notable features) and the precise steps the agent will take—so reviewers understand scope and risk up front.
**What happens**: In your IDE, the Upgrade Agent fetches Upgrade Context from the Plan via the MCP server, detects your IaC pattern, applies targeted diffs (Helm/Kustomize/YAML), and prepares a ready-to-review PR.
**What happens**: Execute SHARC—safety, health and readiness checks directly in your environment that smoke test cloud native project functionality and performance pre- and post-upgrade.
# Installation
Source: https://docs.chkk.io/overview/installation
Install the Chkk CLI, Cluster Connector, and MCP servers (Cursor, Claude Code).
export const cursorDeeplink = "cursor://anysphere.cursor-deeplink/mcp/install?name=Chkk%20Upgrade%20Context%20MCP&config=eyJjb21tYW5kIjoiZG9ja2VyIHJ1biAtaSAtLXJtIC1lIENIS0tfQUNDRVNTX1RPS0VOIHB1YmxpYy5lY3IuYXdzL2Noa2svY2hray1tY3AtdXBncmFkZS1jb250ZXh0OmxhdGVzdCIsImVudiI6eyJDSEtLX0FDQ0VTU19UT0tFTiI6IjxBREQgVE9LRU4%252BIn19";
Install a pre-built binary on Linux using the following instructions.
```bash theme={"dark"}
# For AMD64 / x86_64
[ $(uname -m) = x86_64 ] && curl -Lo ./chkk https://cli.chkk.io/download/latest/chkk-linux-amd64
# For ARM64
[ $(uname -m) = aarch64 ] && curl -Lo ./chkk https://cli.chkk.io/download/latest/chkk-linux-arm64
chmod +x ./chkk
sudo mv ./chkk /usr/local/bin/chkk
```
Or using Brew with a single command.
```bash theme={"dark"}
brew install chkk-io/cli/chkk
```
Install using Homebrew on MacOS.
```bash theme={"dark"}
brew install chkk-io/cli/chkk
```
Or install a pre-built binary using the following instructions.
```bash theme={"dark"}
# For Intel Macs
[ $(uname -m) = x86_64 ] && curl -Lo ./chkk https://cli.chkk.io/download/latest/chkk-darwin-amd64
# For M1 / ARM Macs
[ $(uname -m) = arm64 ] && curl -Lo ./chkk https://cli.chkk.io/download/latest/chkk-darwin-arm64
chmod +x ./chkk
mv ./chkk /some-dir-in-your-PATH/chkk
```
Install a pre-built binary on Windows in PowerShell.
```
curl.exe -Lo chkk-windows-amd64.exe https://cli.chkk.io/download/latest/chkk-windows-amd64
Move-Item .\chkk-windows-amd64.exe c:\some-dir-in-your-PATH\chkk.exe
```
Run the interactive starter to authenticate and optionally register clusters:
```bash theme={"dark"}
chkk start
```
Supported install modes: Helm, K8s YAML, Terraform. See the full Connector page for requirements and configuration examples.
Visit **[https://app.chkk.io](https://app.chkk.io)** and sign in using one of the given methods.
In the Chkk Dashboard, go to **Risk Ledger → Clusters** and click **Add Cluster**, located at the top right.
You have the option to onboard a cluster either using Helm, Kubernetes YAML, or Terraform.
Make sure outbound access to `chkk.io` and `s3.amazonaws.com` is allowed.
Follow the step-by-step flow for your chosen install method to install the Chkk Kubernetes Connector.
Ensure that all the pods in the `chkk-system` namespace are in a healthy state and that the `chkk-agent` pod runs to completion.
On the Chkk Dashboard, you will see a Cluster card get created in the **Risk Ledger → Clusters** view.
Once the scan completes, you will be able to see all the Operational Risks detected in your environment, broken by risk categories.
## Prerequisites
1. [Install Docker](https://docs.docker.com/get-docker/): Required to run the Chkk-Upgrade-Context-MCP Server.
2. [Install Cursor](/resources/installation-guides/cursor): Required to begin generating environment-aware pull requests.
1) In the **Chkk Dashboard**, expand **Configure** on the left menu and click **Settings**.
2) Select the **Tokens** tab. Here you'll see a list of all your active tokens (if any), along with options to create new ones or revoke existing ones.
3) Click on the **clipboard** icon next to a token to copy it.
Click the card below to install the Chkk Upgrade Context MCP Server in Cursor.
Click here to add Chkk to your Cursor
Paste your Chkk Access Token in the `CHKK_ACCESS_TOKEN` environment variable
in the **MCP Tool Settings** opened via the deeplink in the previous step.
Verify in **MCP Tool Settings** that Chkk Upgrade Context MCP Server is
successfully installed and enabled. 
## Prerequisites
1. [Install Docker](https://docs.docker.com/get-docker/): Required to run the Chkk-Upgrade-Context-MCP Server.
2. [Install Claude Code](/resources/installation-guides/claude-code): Required to begin generating environment-aware pull requests.
3. A [Claude.ai](https://claude.ai/) (recommended) or [Anthropic Console](https://console.anthropic.com/) account
1) In the **Chkk Dashboard**, expand **Configure** on the left menu and click **Settings**.
2) Select the **Tokens** tab. Here you'll see a list of all your active tokens (if any), along with options to create new ones or revoke existing ones.
3) Click on the **clipboard** icon next to a token to copy it.
Install the `Chkk-Upgrade-Context-MCP` using the Claude Code CLI:
```bash theme={"dark"}
claude mcp add Chkk-Upgrade-Context-MCP --env CHKK_ACCESS_TOKEN="" -- docker run -i --rm -e CHKK_ACCESS_TOKEN public.ecr.aws/chkk/chkk-mcp-upgrade-context:latest
```
Replace `` with your Chkk Access Token.
Verify via CLI that the server is registered:
```bash theme={"dark"}
claude mcp get Chkk-Upgrade-Context-MCP
```
The command should return server details indicating it is installed and enabled.
Download the latest Risk Feed MCP Server binary for your platform:
Apple Silicon
M1/M2/M3 and newer
ARM 64-bit servers
Intel/AMD 64-bit PCs
After downloading:
1. Unzip the downloaded binary
2. (macOS/Linux) Make the binary executable:
```bash theme={"dark"}
chmod +x ./chkk-mcp-*
```
In your repo, create or edit .cursor/mcp.json (example for macOS Apple Silicon):
```json theme={"dark"}
{
"mcpServers": {
"chkk-mcp-stdio": {
"command": "./bin/chkk-mcp-darwin-arm64",
"args": ["serve"]
}
}
}
```
Cursor will launch the server automatically and prompt you to enable the tool. Start a chat and try a simple risk lookup to confirm.
# Welcome to Chkk
Source: https://docs.chkk.io/overview/introduction
Agentic Upgrades for Cloud Native Software. Built for 100s of Cloud Native Projects like Istio, Keycloak, Consul, Cilium, and many more.
## What is Chkk?
Chkk automates every phase of your upgrade cycle — from **parsing release notes** and **diffing Helm charts** to **mapping CRD**, dependency, and config changes. Our agent flags breaking changes, EOL risks, and critical defects early and identifies incompatible components and API deprecations. It then couples these insights with **parameter-driven Blueprints**, orchestrated by **durable Workflows**, and executed through purpose-built Action Engines to deliver **safe, predictable upgrades** at scale for **100s of Cloud Native Projects**. Chkk accelerates upgrade execution by **more than 10×** while eliminating last-minute surprises.
## Why Chkk?
* **Pre-Verified, Safe Upgrade Workflows** - Chkk generates on-demand, agentic workflows that are tested and structured to eliminate risks.
* **Purpose‑Built Action Engines** – Convert high‑level intent into precise, auditable infrastructure changes across code, clusters, and collaboration systems.
* **AI-Powered Insights** - Uses up-to-date data from breaking changes, deprecated APIs, and dependency shifts to create a highly contextualized upgrade plan.
* **Lifecycle Management Agents** – Includes the **Upgrade Agent** for IDE integration (Cursor, Claude Code) that turns Upgrade Plans into environment‑aware IaC diffs and opens ready‑to‑merge pull requests.
* **Durable & Repeatable Execution** - Backed by a workflow engine that ensures safe, structured, and repeatable upgrades.
* **Broad Ecosystem Compatibility** - Works across cloud and on-prem environments and supports EKS, GKE, AKS, and hundreds of Cloud Native Projects. Check [Support](/overview/support-compatibility) for details.
## Safe Upgrades with Curated Workflows
Traditional runbooks and best practices quickly become outdated or inconsistently applied, leading to operational drift. Chkk Upgrade Copilot solves this by enabling teams to generate **Highly Contextualized, Agentic, Long-Running, Safe Upgrade workflows** on demand—ensuring every upgrade is structured, tested, and risk-free.
When a user initiates a request, Chkk Upgrade Copilot dynamically generates a contextualized **Upgrade Template**, tailored to their specific infrastructure. Behind the scenes, Chkk:
* **Reviews all release notes** to identify relevant breaking changes.
* **Analyzes dependencies and incompatibilities** to generate a pre-verified upgrade sequence, mitigating risks.
* **Tracks deprecated APIs, configurations, and features** to ensure compliance and stability.
* **Executes Actions** via Action Engines—applying IaC patches, creating pull requests, opening Jira tickets, running pre-/post-flight validations, and more.
* **Provides real-time visibility and actionable insights**, as a sequence of steps so teams can execute upgrades with confidence.
* **Continuously Governs & Closes**-the Workflow monitors until success criteria are met and emits audit-ready reports.
By transforming upgrade research, validation, and execution into **sequenced, repeatable workflows**, Chkk ensures that operational knowledge isn't just documented—it's **standardized, executed, and scaled across the organization**.
## How to Use This Documentation
Navigate to the following guides to quickly get hands-on with Chkk:
CLI to onboard clusters and request upgrade assessments from your terminal; ideal for local and CI use.
Web UI to onboard clusters, view risks, and generate upgrade assessments, templates, and plans.
Apply Upgrade Plans from your IDE and open safe, ready-to-merge PRs.
To Learn More:
Learn how Chkk identifies risks and generates safe upgrade paths.
Learn about Chkk's use cases.
With Chkk, Platform, DevOps, and SRE teams can confidently upgrade faster, avoid unnecessary risks, and stay ahead of compliance, [**Extended Support**](https://www.chkk.io/eks-extended-support), and [**Forced Upgrade**](https://www.chkk.io/blog/why-forced-eks-gke-upgrades-are-a-business-continuity-risk) deadlines.
Let's get started.
# Quickstart Chkk CLI
Source: https://docs.chkk.io/overview/quickstart-chkk-cli
Get started in minutes with the Chkk CLI. Local dry run. Free to use.
The chkk command-line interface (CLI) offers a developer-first way to explore the Chkk universe.
Follow the steps in the [Installation](/overview/installation) guide to download the Chkk CLI.
Run the interactive starter to authenticate and register clusters:
```bash theme={"dark"}
chkk start
```
The `chkk start` command will get you started in the Chkk universe.
The command will lead you through registering one or more clusters
with Chkk and request a Chkk upgrade assessment for those registered
clusters.
Registering a cluster with Chkk is the process of collecting
resources from the cluster and submitting those collected results to
Chkk.
Type `chkk start` in a terminal to begin.
```text theme={"dark"}
> chkk start
__ __ __
.----| |--| |--| |--.
| __| | <| <
|____|__|__|__|__|__|__|
Welcome to Chkk!
This command will help you get started with Chkk.
It will guide you through the process of logging in to your Chkk account and
registering any clusters if desired.
You may also request an upgrade assessment for any of your registered
clusters.
────────────────────────────────────────────────────────────────────────────────────────────────────────
Let's get you logged in to your Chkk account.
please confirm the code LCZS-DKDB at https://auth.chkk.io/activate?user_code=LCZS-DKDB
```
Click on the link and a browser window will appear asking you to confirm a
code.
**After clicking "Confirm"**, in your terminal you will see a successful login
message and a prompt to register a cluster with Chkk:
```
successfully logged in as "Jane Doe" (jane.doe@example.com) into organization "demo-org" (org_3c2732f7-9328-477d-910b-54cd94ade5c0).
Do you want to register any Kubernetes Clusters with Chkk? (Y/n)
```
**Hit Enter or "Y"** to start the registration process. We will look in your
kubeconfig for Cloud Native Clusters and ask you to select one or more of those
Kubernetes Clusters to register with Chkk.
```
Found 1 total Kubernetes Clusters in your kubeconfig.
Select the clusters you would like to register. Resources from the selected
clusters will be collected and submitted to Chkk for analysis.
Use the arrow keys to navigate: ↓ ↑ → ←
Select "Submit" to submit choices.
Submit
→ ✔ kind-charlie (https://127.0.0.1:39775)
```
Use the arrow keys to navigate, **hit Enter to select one or more** of the
clusters and navigate up to the Submit line and hit Enter again.
We will ask you to confirm your selection:
```
You made the following 1 selections:
1: kind-charlie (https://127.0.0.1:39775)
Are you sure you want to submit these? Enter 'n' to select again. (Y/n)
```
**Hit Enter or "Y" to collect resources** from the selected clusters and
register them with Chkk.
```
Registering 1 Kubernetes Cluster(s) with Chkk...
registering kind-charlie (https://127.0.0.1:39775)...
✅ cluster "kind-charlie" resource collection successful. 49 resource groups collected.
To view information about your cluster, do:
chkk cluster get k8scl_13673ce4-1cbd-454a-aa31-67b722fadc99
```
**Your newly-registered** cluster will then be displayed along with a
prompt asking if you would like to request a Chkk upgrade assessment for this
cluster:
```
The following 1 Kubernetes Clusters are active in your Chkk account:
┌────────────────────────────────────────────┬──────────────┬────────┬─────────────┬──────────┬──────────────┬──────────┐
│ ID │ NAME │ STATUS │ ENVIRONMENT │ PROVIDER │ KUBE VERSION │ # NODES │
├────────────────────────────────────────────┼──────────────┼────────┼─────────────┼──────────┼──────────────┼──────────┤
│ k8scl_13673ce4-1cbd-454a-aa31-67b722fadc99 │ kind-charlie │ active │ │ KinD │ 1.28 │ 2 │
└────────────────────────────────────────────┴──────────────┴────────┴─────────────┴──────────┴──────────────┴──────────┘
showing 1-1 of 1 records.
Would you like to request an upgrade assessment for any of these Kubernetes Clusters? (Y/n)
```
A Chkk upgrade assessment is a report that alerts you to potential issues with
an upgrade of your cluster and recommends upgrade versions for your
Cloud Native Projects and Application Services.
**Hit Enter or "Y"** to select one or more clusters for an upgrade
assessment.
```
Use the arrow keys to navigate: ↓ ↑ → ←
? Select a cluster to request an upgrade assessment for:
▸ kind-charlie (1.28) (KinD)
```
select a cluster and hit Enter.
```focus={1,6-7} theme={"dark"}
You selected "kind-charlie (1.28) (KinD)". Is this correct? Enter 'n' to select again. (Y/n)
Requesting upgrade assessment for kind-charlie (1.28) (KinD)...
(required) enter the name for the upgrade assessment
charlie
✅ request for upgrade assessement for cluster "k8scl_13673ce4-1cbd-454a-aa31-67b722fadc99" successful.
... waiting for upgrade assessment to complete. this will take a few minutes ...
```
The upgrade assessment will take a few minutes to generate and then you will see:
```focus={5,7} theme={"dark"}
completed!
To view your upgrade assessment, do:
chkk upgradeassessment get ua_a59a7fff-f3c2-4443-9f26-fe97cd187def
Learn more about Chkk upgrade assessments at: https://docs.chkk.io/product/upgrade-copilot/assessments
```
***
### Need Help?
Email us at **[support@chkk.io](mailto:support@chkk.io)** for assistance.
# Quickstart Chkk Dashboard
Source: https://docs.chkk.io/overview/quickstart-chkk-dashboard
Get started in minutes with the Chkk Dashboard. No installation needed. Free to use.
The Chkk Dashboard is a web-based interface that allows you to manage your Chkk account and clusters, view detected Operational Risks,
and request Upgrade Assessments, Upgrade Templates, and Upgrade Plans via the Upgrade Copilot.
Visit **[https://app.chkk.io](https://app.chkk.io)** and sign in using one of the given methods.
Interested in upgrading? View our [Pricing](https://chkk.io/pricing) page to compare plans, or email us at **[support@chkk.io](mailto:support@chkk.io)** for assistance.
Installing the [**Chkk Kubernetes Connector**](/connectors/kubernetes) on your clusters enables **real-time risk detection, artifact tracking, and upgrade planning**.
Follow the steps in the [Installation](/overview/installation) guide to install the Chkk Kubernetes Connector.
#### *What Happens Next?*
* **Automated Risk Scan:** A [**Risk Ledger**](/product/risk-ledger) **scan** runs immediately upon onboarding. Within **15 minutes**, the scan will be completed and by clicking on the Cluster card, you will be able to see all the Operational Risks detected in your environment, broken by risk categories.
* **Cluster Insights:**
* [**Risk Ledger**](/product/risk-ledger): View all **Operational Risks** detected in your clusters.
* [**Artifact Register**](/product/artifact-register): Get a **version-first inventory** of the control-planes, Projects, application services, and operators running in your fleet.
Once your cluster has been successfully onboarded, you can generate an Upgrade Assessment to understand the changes involved in upgrading your cluster.
To request an Upgrade Assessment:
1. Navigate to **Upgrade Copilot → Upgrade Assessments** in the left-hand sidebar.
2. Click **Request Upgrade Assessment**.
3. Select the cluster to generate the Upgrade Assessment for.
You will only be able to request Upgrade Assessments after a cluster has been onboarded.
#### *What Happens Next?*
* **Upgrade Assessment Generation**: After a few minutes, the [**Upgrade Assessment**](/product/upgrade-copilot) will be generated and appear with a status of **Available**.
* **Review the Upgrade Assessment**: Click the assessment row to review the control-plane version changes, required Project upgrades, and any potential breaking changes.
* **Download the Upgrade Assessment**: You can also download the [**Upgrade Assessment**](/product/upgrade-copilot) as a Markdown file to share with your team.
Chkk integrates with your **AWS, GCP, and Azure** Cloud Accounts to facilitate in the creation of holistic [Upgrade Template and Upgrade Plans](/product/upgrade-copilot) that are tailored to your environment.
Once you have connected your Cloud Accounts, you can generate an Upgrade Template to understand the changes involved in upgrading your clusters.
To generate an Upgrade Template:
1. Navigate to **Upgrade Copilot → Upgrade Templates** in the left-hand sidebar.
2. Click **Generate Upgrade Template**.
3. Select the cluster to generate the Upgrade Template for.
***
### Need Help?
Email us at **[support@chkk.io](mailto:support@chkk.io)** for assistance.
# Quickstart Upgrade Agent
Source: https://docs.chkk.io/overview/quickstart-upgrade-agent
Get started in minutes with Upgrade Agent. Runs locally in Cursor and Claude Code. Free to use.
export const cursorDeeplink = "cursor://anysphere.cursor-deeplink/mcp/install?name=Chkk%20Upgrade%20Context%20MCP&config=eyJjb21tYW5kIjoiZG9ja2VyIHJ1biAtaSAtLXJtIC1lIENIS0tfQUNDRVNTX1RPS0VOIHB1YmxpYy5lY3IuYXdzL2Noa2svY2hray1tY3AtdXBncmFkZS1jb250ZXh0OmxhdGVzdCIsImVudiI6eyJDSEtLX0FDQ0VTU19UT0tFTiI6IjxBREQgVE9LRU4%252BIn19";
Chkk **Upgrade Agent** connects Chkk **Upgrade Plans** to your **MCP-compatible AI coding agent** (e.g., Cursor, Claude Code),
turning approved plans into environment-aware diffs and precise edits to your IaC (Helm/Kustomize/Jsonnet/Terraform).
The agent changes only what's required, preserves your customizations, and produces a focused PR you can review,
validate, and merge with confidence.
## Prerequisites
1. [Install Docker](https://docs.docker.com/get-docker/): Required to run the Chkk-Upgrade-Context-MCP Server.
2. [Install Cursor](/resources/installation-guides/cursor): Required to begin generating environment-aware pull requests.
Agent Responses on this page are illustrative. Exact phrasing from your AI
model may vary depending on the model, settings, and repository context.
For the best experience, it is recommended to use the **claude-4-sonnet** model with the Chkk-Upgrade-Context-MCP Server.
Run the following command to clone the sample Chkk IaC repo and open it in Cursor:
```bash theme={"dark"}
git clone git@github.com:chkk-io/upgrade-playground.git && \
cd upgrade-playground && \
cursor .
```
1. In the **Chkk Dashboard**, expand **Configure** on the left menu and click **Settings**.
2. Select the **Tokens** tab. Here you'll see a list of all your active tokens (if any), along with options to create new ones or revoke existing ones.
3. Click on the **clipboard** icon next to a token to copy it.
Click the card below to install the Chkk Upgrade Context MCP Server in Cursor.
Click here to add Chkk to your Cursor
Paste your Chkk Access Token in the `CHKK_ACCESS_TOKEN` environment variable
in the **MCP Tool Settings** opened via the deeplink in the previous step.
Verify in **MCP Tool Settings** that Chkk Upgrade Context MCP Server is
successfully installed and enabled.
1. In the **left-hand column** of the **Chkk Dashboard**, expand **Upgrade Copilot**.
2. Under **Upgrade Plans** select **Add-on & App Services**.
3. On the **Middle Right** corner of the page, enable the **Show Example Data** toggle, as shown in the image below.
4. This will switch the view to only show example data and displays a confirmation banner.
5. In the table below, you will see a list of Add-on and Application Service **Example Upgrade Plans**.
6. Select any Upgrade Plan from the table that has the **AI Context Generated** badge, as shown in the image below.
The **AI Context Generated** badge indicates that these Upgrade Plans are supported by the **Chkk-Upgrade-Context-MCP Server**.
7. At the top of the page, under the name of the Upgrade Plan, you will see the **Upgrade ID**.
8. Click the **clipboard** icon to copy the Upgrade ID to your clipboard.
Paste and send the following Prompt in the Cursor chat:
You're in a K8s repo. Fetch "addon-upgrade-agent" from Chkk MCP and upgrade the package listed in the upgrade plan. Start by asking for the upgrade ID.
Your opening prompt is flexible, but it **must** explicitly instruct the agent to **fetch "addon-upgrade-agent" from Chkk MCP**.
**Agent Response:**
Paste your **upgrade ID** (from your instantiated [Add-on or Application Service Upgrade Plan](/resources/glossary#cloud-native-project-and-application-service-upgrade-plan)), for example:
upgr\_ea53db65-3d8d-4744-b8b7-92e3c7552932
**Agent Response:**
Cursor will fetch Upgrade Context, stage artifacts in a local **Scratchpad** (`.chkk/scratchpad/upgrade-agent/` in the current working directory),
apply targeted edits (`Chart.yaml`, `values.yaml`, minimal templates), and summarize the changes it has made.
**Agent Response:**
To ensure your model is not overwhelmed by the task scope, any modifications are processed in batches of 5 files at a time.
You can now review the changes made within each file, which you would have
otherwise would have had to do manually.
## Prerequisites
1. [Install Docker](https://docs.docker.com/get-docker/): Required to run the Chkk-Upgrade-Context-MCP Server.
2. [Install Claude Code](/resources/installation-guides/claude-code): Required to begin generating environment-aware pull requests.
3. A [Claude.ai](https://claude.ai/) (recommended) or [Anthropic Console](https://console.anthropic.com/) account
Agent Responses on this page are illustrative. Exact phrasing from your AI
model may vary depending on the model, settings, and repository context.
For the best experience, it is recommended to use the **claude-4-sonnet** model with the Chkk-Upgrade-Context-MCP Server.
Run the following command to clone the sample Chkk IaC repo:
```bash theme={"dark"}
git clone git@github.com:chkk-io/upgrade-playground.git && \
cd upgrade-playground
```
1. In the **Chkk Dashboard**, expand **Configure** on the left menu and click **Settings**.
2. Select the **Tokens** tab. Here you'll see a list of all your active tokens (if any), along with options to create new ones or revoke existing ones.
3. Click on the **clipboard** icon next to a token to copy it.
Install the `Chkk-Upgrade-Context-MCP` using the Claude Code CLI:
```bash theme={"dark"}
claude mcp add Chkk-Upgrade-Context-MCP --env CHKK_ACCESS_TOKEN="" -- docker run -i --rm -e CHKK_ACCESS_TOKEN public.ecr.aws/chkk/chkk-mcp-upgrade-context:latest
```
Replace `` with your Chkk Access Token.
Verify via CLI that the server is registered:
```bash theme={"dark"}
claude mcp get Chkk-Upgrade-Context-MCP
```
The command should return server details indicating it is installed and enabled.
1. In the **left-hand column** of the **Chkk Dashboard**, expand **Upgrade Copilot**.
2. Under **Upgrade Plans** select **Add-on & App Services**.
3. On the **Middle Right** corner of the page, enable the **Show Example Data** toggle, as shown in the image below.
4. This will switch the view to only show example data and displays a confirmation banner.
5. In the table below, you will see a list of Add-on and Application Service **Example Upgrade Plans**.
6. Select any Upgrade Plan from the table that has the **AI Context Generated** badge, as shown in the image below.
The **AI Context Generated** badge indicates that these Upgrade Plans are supported by the **Chkk-Upgrade-Context-MCP Server**.
7. At the top of the page, under the name of the Upgrade Plan, you will see the **Upgrade ID**.
8. Click the **clipboard** icon to copy the Upgrade ID to your clipboard.
From inside the `upgrade-playground` directory, start Claude Code.
```bash theme={"dark"}
claude
```
Open a chat in Claude Code and send:
You're in a K8s repo. Fetch "addon-upgrade-agent" from Chkk MCP and upgrade the package listed in the upgrade plan. Start by asking for the upgrade ID.
Your opening prompt is flexible, but it **must** explicitly instruct the assistant to **fetch "addon-upgrade-agent" from Chkk MCP**.
**Agent Response:**
Paste your **upgrade ID** (from your instantiated [Add-on or Application Service Upgrade Plan](/resources/glossary#cloud-native-project-and-application-service-upgrade-plan)), for example:
upgr\_ea53db65-3d8d-4744-b8b7-92e3c7552932
**Agent Response:**
The assistant will fetch Upgrade Context, stage artifacts in a local **Scratchpad** (`.chkk/scratchpad/upgrade-agent/` in the current working directory),
apply targeted edits (`Chart.yaml`, `values.yaml`, minimal templates), and summarize the changes it has made.
**Agent Response:**
To ensure your model is not overwhelmed by the task scope, any modifications are processed in batches of 5 files at a time.
You can now review the changes made within each file, which you would have
otherwise would have had to do manually.
**Agent Response:**
Learn more in the [Upgrade Agent guide](/ai/upgrade-agent).
***
### Need Help?
Email us at **[support@chkk.io](mailto:support@chkk.io)** for assistance.
# Technology
Source: https://docs.chkk.io/overview/technology
## Collective Learning
Collective Learning is Chkk's always-on knowledge refinery. Its purpose is to capture insights from across the open-source ecosystem—hundreds of Cloud Native Projects, applications, and services—and convert that raw change stream into source-grounded, machine-actionable knowledge. Every downstream function—classification, risk scanning, upgrade planning, automated actions—depends on the accuracy, freshness, and auditability of this layer.
Continuously running **Source Feeds** harvest upstream signals from release notes, official documentation, GitHub issues, container registries, cloud bulletins, and official blog posts. These incoming events are routed into highly specialized, **Task-Specific AI Agents**. Each agent is responsible for a distinct artifact type—such as a breaking change or OS compatibility—and executes a deterministic, **AI-driven ETL** pipeline: extract the relevant fragment, transform it to Chkk’s canonical schema, and load the candidate fact for validation.
All authoritative sources used by the Knowledge Engine are integrated into a **Grounding Layer** that is both AI-curated and subject to human oversight. This Grounding Layer models and organizes all required inputs to reliably identify clouds, Cloud Native Projects, and application services in a customer's environment. The **Chkk Research Team** actively reviews and validates every source incorporated into this layer, ensuring ongoing trustworthiness. Agents, workflows, and tools then rely on this curated corpus to prevent AI hallucinations and uphold the accuracy of knowledge attributes.
Curated facts are written to two data stores. The first is the **Risk Signature Database (RSig DB)**, which houses every Risk Signature (RSig)—complete with severity, trigger conditions, and mitigations. The second is the **Knowledge Graph**, which encodes compatibility edges, version metadata, packaging information, component hierarchies, end-of-life schedules, and safety guardrails for the Cloud Native ecosystem.
Whenever Chkk onboards a new Cloud Native Project or cloud distribution, Collective Learning automatically extends coverage across changelogs, compatibility timelines, image registries, package systems, and upstream GitHub activity. This ensures that the moment a community, cloud or vendor discloses a breaking change, publishes a versioned artifact or posts changelogs, they are ingested, verified, tagged, curated and made available for downstream reasoning within minutes.
## Artifact Collection
Artifact Collection involves the retrieval of raw customer configuration and metadata. Because this metadata is private to a customer, it is stored separately from any data refined through the Collective Learning systems.
Configuration and metadata are collected on a continuous basis. These periodic collections form an auditable timeline of snapshots that enable Chkk to detect changes to the customer’s infrastructure configuration and risk profile.
## Classification
Classification connects collected customer configuration and metadata to Chkk’s Collective Learning corpus, enabling the platform to richly contextualize and reason about every inventory object. Upon ingest, each resource arrives unclassified—identified only by its raw coordinates: cluster ID, namespace, kind, name, and hash.
A multi-stage classification pipeline then resolves these opaque blobs into fully enriched inventory records. Classifiers systematically detect and assign properties, including Deployment System (e.g., Terraform, ArgoCD, FluxCD, Helm, kubectl), Project, Project Release, Project Component, Package System (e.g., Helm, Kustomize, Kube, Terraform), Package, Package Release, Package Component, OCI Registry, OCI Repository, OCI Tag, and OCI Artifact.
The pipeline supports custom overrides to accommodate customer-specific realities—such as private registries, internal charts, or hardened AMIs—ensuring that even bespoke infrastructure components are correctly identified and reasoned over.
## Contextualization
Contextualization begins once classification has pinned every inventory object to its exact Project, Package, Release, and deployment metadata. Contextualizers layer situational intelligence onto those links—pruning changelogs to only the deltas that affect the customer, composing readiness probes that reflect the cluster’s actual topology, flagging pre-upgrade actions for client teams, and generating upgrade steps that align with the specific Deployment System, Package version, and OCI artifacts in play. By translating canonical release knowledge into environment-aware instructions, contextualization turns abstract matches into clear, executable guidance operators can trust.
## Deep Analysis
Deep Analyzers use the output of Contextualizers to run cross-layer, cross-component impact analysis. Once Contextualization has narrowed the changes that matter to you, Deep Analysis walks the full dependency graph—cloud control plane / nodes, Cloud Native Projects, and application services—to expose downstream blast-radius effects. It correlates contextualized breaking changes, version drifts, API deprecations, IAM mutations, OS/kernel swaps, and configuration shifts to determine how a change in one component impacts others, such as a changed kernel parameter degrading a load balancer or a new IAM tag stalling node autoscaling. The result is a single, holistic impact analysis that prioritizes risks, pinpoints affected components, and informs the safest remediation and upgrade sequence.
## Reasoning and Generation Engines
Reasoning and Generation Engines power Chkk’s core reasoning modules—Upgrade Copilot, Artifact Register, and Risk Ledger. Together they reconcile two parallel truths: the classified inventory of what is currently running and the knowledge from Collective Learning. This is the platform’s decision cortex, converting source-grounded intelligence into production-safe change artefacts for the Action Engines to execute.
## Action Engines
Action Engines convert high-level intent—"mitigate this risk," "upgrade that Project," "snooze for 30 days"—into precise, auditable changes across code, infrastructure, and collaboration systems. Each engine is a purpose-built, domain-specific workflow.
These engines span multiple functional categories—from planning and preverification to remediation, validation, collaboration, monitoring, and reporting. They generate Upgrade Plans and readiness reports, Preverify upgrades in a Digital Twin, apply temporary safeguards or permanent fixes, verify change safety, manage workflow ownership, enforce SLAs, and produce governance-ready audit reports.
## Workflows
Actions are stitched into durable workflows that orchestrate every operational objective end-to-end. Chkk ships a library of workflow Blueprints—spanning planning, mitigation, remediation, preverification, and reporting—running on the Durable Workflow Fabric. For instance, a “Fix Misconfigured PDBs” workflow assigns the owner, defines fix criteria (e.g., making sure allowedDisruptions > 0), sets a need-by date with an SLA timer, schedules Slack or email reminders, opens a Jira ticket if one doesn’t exist, monitors continuously until the condition is fully remediated, auto-closes the ticket upon verification, and notifies stakeholders when the mitigation is complete.
## Blueprints
A Blueprint is a reusable, parameter-driven recipe that compiles one or more canonical Actions into a fully wired workflow on Chkk's Durable Workflow Fabric. Chkk ships Blueprints spanning 100s of Cloud Native Project change lifecycles and lets enterprises author custom Blueprints to encode their own governance, approval, and remediation processes.
# Understanding Chkk
Source: https://docs.chkk.io/overview/understanding-chkk
Upgrading Cloud Native infrastructure is complex, error-prone, and time-consuming. The process is highly manual, with teams sifting through scattered release notes and documentation for every component. Small changes in one layer can introduce hidden incompatibilities in another, risking outages and forcing expert-level troubleshooting at every step. Because it's so complex, it can't be easily delegated or automated, creating bottlenecks, long delays, and added costs—including extended support fees and mounting technical debt.
Chkk is an **Agentic Operational Safety Platform** designed to solve this problem for the Cloud Native ecosystem. It leverages Knowledge Graphs, Risk Signature Databases, and Agentic AI systems to proactively identify hidden dependencies, unknown incompatibilities, and potential risks before they cause failures. By generating pre-verified, agentic upgrade workflows on demand, Chkk Upgrade Copilot provides teams with structured, safe, and efficient upgrade plans—speeding up the upgrades by 3x to 5x while eliminating last-minute surprises and disruptions.
**Two complementary paths:** Use a **Rapid Upgrade Assessment** for a fast, zero‑install, planning‑grade read on scope/targets/risks; when you’re close to execution, switch to **Upgrade Templates** and cluster‑specific **Upgrade Plans** for preverified, impact‑free workflows.
## Building Blocks
### Upgrade Assessments
#### What it is
A fast, zero‑install, **CLI‑first** assessment that summarizes **scope, recommended target versions, and early risks** across clusters, nodes, and key Cloud Native Projects in minutes. Output is Markdown today; JSON schema + flags are coming to wire into CI/dashboards.
#### When to use
* **Months ahead** to T‑shirt‑size effort, choose “next versions,” and generate app‑team work (API deprecations/removals, misconfigured PDBs).
* **Weekly** in CI to track readiness and make visibility/escalation machine‑driven (publish to dashboards/wikis).
#### How it works
Multiple agents classify environment artifacts (e.g. EKS clusters, Istio, cert‑manager versions), query Chkk's **Knowledge Graph**, and compute recommended targets and notable risks **without a preverification pass**—that's why it's fast and **planning‑grade**. Use Templates/Plans when you're close to execution.
#### Accuracy & Expectations
Skipping preverification means **rare** recommendations can be incomplete if upstream context is missing; coverage improves continuously. For impact‑free execution, generate a **Template** and **Plan**.
### Upgrade Templates
**When you're near execution:** For early planning and weekly readiness, start with an Upgrade Template.
An **Upgrade Template** is an agentic workflow containing a tested and structured sequence of steps and stages to safely upgrade your clusters. An Upgrade Template is generated on-demand and is scoped to an Environment (e.g. dev, staging or prod). Upgrade Templates support three commonly-used upgrade patterns: In-Place, Blue-Green, and Rolling/Surge.
Upgrade Templates answer all the questions that Platform Teams have to address in an upgrade:
1. It starts with **Deep Analysis & Research**:
* What versions and configuration of control planes, nodes, Cloud Native Projects, and applications are running?
* Have any of these versions reached **EOL**?
* Are any of these versions **incompatible** with each other?
* What Operational Risks should I be aware of before upgrading?
* Are there open **defects** in specific versions that have caused breakages or disruptions?
* Are there any **misconfigurations** that I should fix prior to upgrading?
* Which version of control planes and Projects should we upgrade to?
* What's the version matrix where all Projects are **compatible** with the next cluster version?
* What **breaking changes** (CRDs, configuration, features, behavioral changes,…) will we encounter when executing the upgrade?
* Are there any **hidden dependencies** that can break Projects or applications?
* Can I upgrade Projects to the desired version directly or do we need to do it as a sequence of **upgrade hops** to avoid schema breakages and/or incompatibilities?
2. Then comes **Preparation**:
* What **Helm chart and CRD changes** must be catered for before executing upgrades?
* What **preflight checks** should be run for control plane and Projects to ensure it's safe to execute upgrades?
* What **code diffs** should be applied to upgrade Projects, control plane, and nodes, and in which order?
* What **postflight checks** should be run to ensure everything is healthy after the upgrade is complete?
An **Upgrade Template** answers all the above questions and its entire workflow of steps and stages is pre-verified to work without failures on a **Digital Twin** of your environment.
While simple Projects (e.g. VPC CNI, cert-manager, External Secrets Operator, etc.) can be upgraded with the cluster, complex Projects (e.g. Istio, Contour, Consul, etc.) generally require a dedicated **Project Upgrade Template** with steps and stages specific to that Project. Project (or Application Service) Upgrade Templates ensure upgrade safety by enabling you to manage complex Projects' upgrades independently of your cluster upgrade lifecycle.
Your team reviews and customizes an Upgrade Template by collaborating through comments inside the Template, adding your own custom steps, and finally approving the Upgrade Template for execution.
3. And now you are ready for **Upgrade Execution**:
This is where you instantiate **Upgrade Plans** for each cluster in the Environment. The instantiated Upgrade Plans inherit all the information present in Upgrade Templates + additional cluster-specific information like:
* Which applications are using **deprecated/removed APIs**?
* Are there any **application client changes** in Cloud Native Projects or Application Services?
* Are there any **application misconfigurations**-like incorrect Pod Disruption Budgets (PDBs)-that can cause the upgrade to fail?
Chkk recommends you to run an **Upgrade Assessment** first to surface early work
(API deprecations/removals, PDB misconfigurations) and agree target
versions—so Plans focus on verified execution.
All activities performed on the Upgrade Templates and Upgrade Plans are stored in long-running, durable workflows, ensuring safe, structured, and repeatable upgrades.
Upgrade Templates get all the information they need from two foundational technology components: **Risk Signature Database (RSig DB)** and **Knowledge Graph**.
### Operational Risks
Operational Risk refers to any known or potential defect, misconfiguration, or incompatibility in Cloud Native infrastructure that can cause incidents, disruptions, or breakages. These risks, which may include known defects or issues stemming from unsupported versions, deprecated APIs, and software nearing end-of-life, are categorized by severity—Critical, High, Medium, or Low. An Operational Risk is detected by scanning for at-risk components, identifying trigger conditions, and assessing availability impact, root cause, remediation steps, and possible mitigations. In Chkk, these risks are codified as Risk Signatures (RSigs) that continuously scan customer environments to proactively uncover and address Operational Risks before they cause breakages or outages.
## Chkk Service
Chkk is a secure, scalable multi-regional solution offered in the US and EU. It is built using a cell-based architecture and supports multi-tenant and single tenant instances. It comprises multiple services that run APIs and microservices to serve product modules and maintain inventory records. At the heart of the Chkk Service are Classifiers and Engines, working in tandem to provide real-time insights and operational resilience for Cloud Native environments.
Classifiers leverage references from the Knowledge Graph and RSigDB, either extracting image digests (hash-based) or applying RuleSets (rule-based) to identify resources and their relationships. Engines then use these classification results to detect latent Operational Risks, ensure guardrail conformance, and generate Upgrade Templates. They also create digital twins to preverify proposed Upgrade Plans, helping ensure that all steps can be executed without failures, and enabling smoother, more reliable operations.
**Rapid path:** on demand, agents classify your environment (cluster / Cloud Native Project versions), query the **Knowledge Graph**, and compute recommended targets + notable risks—**without** running the deep preverification loop—so results land in minutes. Use the preverified path (Templates/Plans) for go‑time.
## Risk Signature Database (RSig DB)
RSig DB takes inspiration from cybersecurity, where security vulnerabilities are reported publicly in the CVE Database. We extended this idea to operational safety: If there's an Operational Risk (e.g. an error, failure, or disruption) that has happened anywhere in the world, Chkk AI aggregators and data connectors learn about it, convert it into a Risk Signature-similar to a virus signature-and store it in the RSig DB. Any new Risk Signature is streamed to all our customers, where it is scanned in their environments. That way, our customer can proactively detect, identify, and remediate Operational Risks before they cause breakages and disruptions, much like antivirus software detects and removes viruses before they start causing harm.
RSigDB's AI aggregators and data connectors scour Operational Risks from the following sources of information:
* Release schedules
* Upstream Tickets / Issues
* Release notes / Changelogs
* Pull Requests
* Cloud provider knowledge basis and issue trackers
Customers can also voluntarily opt-in to share Operational Risks with Chkk-we don't learn anything from the customer directly.
RSig DB also codifies Guardrails which represent operational best practices from across the Cloud Native ecosystem (upstream communities, cloud providers, and vendors). Platform Teams use these Guardrails to ensure Application developers are conforming to their Platform's operational excellence standards.
## Knowledge Graph
Knowledge Graph stores agentic data and relationships across hundreds of Cloud Native Projects in the ecosystem, modeling their impact and identifying the safest upgrade paths. Oversight is provided for agentic data and relationships by the Chkk Research Team.
Knowledge Graph covers releases of all major clouds and distributions: EKS, GKE, AKS, VMware Tanzu, OpenShift, Rancher RKE1/RKE2, Nutanix. We also support DIY and self-hosted clusters. Chkk also covers 300+ Projects, and coverage for a new Project or application service can be extended within 48hrs.
Coverage Extension is done on a continual basis by an agentic AI architecture, with multiple task-specific AI agents identifying and curating information from the following sources:
* Release Notes are curated with emphasis on breaking changes and upgrade considerations
* Image hashes from upstream registries
* Components are modeled, where a Project or application service may package other Projects (e.g. Redis-OSS is packaged inside ArgoCD)
* Package Systems (Helm, Kustomize, etc.)
* Package Sources (HelmCharts, KustomizeSources, KubeSources, etc.)
* Deployment Modes (e.g. Istio has two Deployment Modes: Sidecar, Ambient)
* EOL policies
* Version Compatibility:
* With upstream cluster versions
* With the cloud substrate (e.g. Amazon EKS versions and Amazon AMI versions), and
* With other Projects (e.g. a Contour version being compatible with certain Envoy versions)
* Safety, Health and Readiness Checks, which include per-version preflight, inflight and postflight checks packaged in single-click, ready-to-run containers
Using the Knowledge Graph, Chkk identifies the safest Upgrade Paths for clusters and Cloud Native Projects. This path discovery, at times, contains multiple upgrade hops.
## Chkk Dashboard
Chkk Dashboard is a UI for you to interact with Chkk-this interaction includes, but isn't limited to, the following actions:
* Onboarding clusters, managing access tokens
* Inviting team members
* Operational Risks: latent in clusters, reading Knowledge Base articles about these Risks, and performing actions (like Ignoring a risk or leaving comments for team members)
* Guardrails: that are not followed, reading Knowledge Base articles about these Guardrails, and exposing these Guardrails to Application Teams through an API integration
* Upgrade Templates: Requesting, customizing, reviewing and approving Upgrade Templates.
* Upgrade Plans: instantiating and executing Upgrade Plans.
* Artifacts: inventory extracted from running components, container images, repositories, and tools across multiple clusters, clouds and layers of infrastructure.
* Integrations: with internal tools like GitHub, Slack, etc. Also includes SSO integration.
## A Simple Operational Recipe
* **Month −3 to −2:** Run an Upgrade Assessment to scope effort (Platform T‑shirt size + App work).
* **Month −2 to 0 (weekly):** Automate a weekly Assessment → publish to dashboards/wikis → app teams burndown risks; leadership reviews trends.
* **D‑30:** Generate an Upgrade Template for target versions; validate in sandbox.
* **D‑7:** Create a cluster‑specific Upgrade Plan; promote dev → staging → prod.
* **Go‑time:** Execute with high confidence.
# Chkk Operational Safety Platform
Source: https://docs.chkk.io/product/introduction
Chkk Operational Safety Platform is the **Agentic Upgrade Copilot** for managing the lifecycle of Cloud Native infrastructure—including clusters, ecosystem components (Istio, Cilium,...), and application services (Redis, Keycloak,...).
Chkk frees expert engineers from the endless cycle of upgrades. It enables teams to delegate and parallelize tasks more effectively by standardizing workflows, simplifying reuse, and promoting knowledge sharing.
Chkk automates every phase of your upgrade cycle — from parsing release notes and diffing Helm charts to mapping CRD, dependency, and config changes. It flags breaking changes, EOL risks, and critical defects early, and identifies incompatible components and deprecated APIs. Chkk also provides pre-, in-, and post-flight validation checks, delivering ready-to-apply IaC automation code.
Enterprises across financial services, healthcare, media, and other industries use Chkk to cut upgrade preparation time by 80%, avoid 500% Extended Support fees for EKS, GKE, and AKS, and prevent accidental forced upgrades. They rely on Chkk to upgrade smoothly—eliminating disruptions and last-minute scrambles.
Chkk supports both cloud and on-prem environments, including EKS, GKE, AKS, VMware Tanzu, OpenShift, Rancher, Nutanix, and other distributions. It integrates seamlessly with existing tools, workflows, and management platforms, scaling across your entire fleet to give you the confidence to upgrade safely.
# Upgrade Assessments
Source: https://docs.chkk.io/product/upgrade-copilot/assessments
Foundational reports that map scope, risk, and dependencies of Cloud Native upgrades.
## What are Chkk Upgrade Assessments?
Chkk Upgrade Assessments are **high-level reports** that map the scope, impact, and dependencies of upgrading a cluster—along with its Cloud Native Projects and application services—to the next minor version. They serve as the foundational analysis that helps teams understand what's involved in an upgrade before creating detailed execution plans.
### Key Characteristics
**1. Comprehensive Mapping**
* **Scope Analysis**: Identifies all components that need to be upgraded (control plane, nodes, Cloud Native Projects, application services, operators)
* **Impact Assessment**: Evaluates the potential effects of upgrading each component
* **Dependency Mapping**: Maps relationships and dependencies between different infrastructure layers
**2. Early Risk Identification**
Upgrade Assessments surface critical information including:
* **Required version hops**: Which components need multi-step upgrades
* **Deprecated APIs**: Applications using APIs that will be removed
* **Potential blockers**: Issues that could prevent successful upgrades
* **Breaking changes**: Configuration or behavioral changes to expect
* **EOL risks**: Components approaching end-of-life status
**3. Multi-Layer Analysis**
Upgrade Assessments analyze dependencies across:
* **Platform Layer**: Control plane and nodes
* **Application Layer**: Cloud Native Projects, application services, and operators
* **Cross-layer compatibility**: How changes in one layer affect others
### How Upgrade Assessments Work
**1. Generation Process**
* Assessments can be requested for specific clusters through the **Chkk Dashboard**
* Or via [CLI (local mode)](/product/chkkcli/overview): device‑code login; **no in‑cluster install**; request and view an Upgrade Assessment from the terminal (use when you want a quick read without installing anything)
* They analyze the current state of your infrastructure
* Agentic analysis identifies upgrade requirements and potential issues
**2. Status Lifecycle**
* **Waiting for Assessment** → Being generated
* **Available** → Ready for review and download
**3. Output and Usage**
* Assessments can be downloaded as Markdown files for team sharing
* CLI output is Markdown today; JSON schema and flags are available/coming for automation and dashboards
* They provide the foundation for requesting Upgrade Templates
* Teams can use them to gauge upgrade readiness and remediate issues early
**4. Operationalization (when to run):**
* **Planning (months ahead):** T‑shirt size platform work; decide what’s delegable vs. needs Staff/Principal review; create app‑team work items (e.g., remove deprecated/removed APIs, fix PDBs)
* **Readiness tracking (weekly):** run a CI/cron job to generate a fresh Upgrade Assessment and publish to team dashboards/Wikis for continuous visibility
**5. Expectations**
Upgrade Assessments optimize for speed and planning‑grade signal (**no pre‑verification**). Use an [Upgrade Template](/product/upgrade-copilot/templates) or [Upgrade Plan](/product/upgrade-copilot/plans) for execution‑grade workflows.
### Key Benefits
**1. Early Planning**
* Allows teams to understand upgrade complexity before starting
* Helps with resource allocation and timeline planning
* Enables proactive issue resolution
**2. Risk Mitigation**
* Identifies potential blockers before they cause problems
* Surfaces deprecated APIs that need attention
* Highlights compatibility issues between components
**3. Team Coordination**
* Provides a shared understanding of upgrade scope
* Enables delegation of upgrade tasks across Platform Team members
* Facilitates proactive, frictionless coordination with Application Teams
### Integration with Chkk Upgrade Copilot
Upgrade Assessments are one of the three complementary capabilities of Chkk Upgrade Copilot:
1. **Upgrade Assessments** → Map scope, impact, and dependencies
2. [Upgrade Templates](/product/upgrade-copilot/templates) → Provide detailed, pre-verified workflows
3. [Upgrade Plans](/product/upgrade-copilot/plans) → Instantiate templates for specific cluster execution
Upgrade Templates/Plans are preverified against a [Digital Twin](/resources/glossary/#digital-twin) of your running configuration and take longer to generate; use them closer to execution.
This comprehensive approach ensures teams can scope effort and delegate work early, making upgrades faster, safer, and more predictable.
# Overview
Source: https://docs.chkk.io/product/upgrade-copilot/overview
Your Upgrade Copilot for 100s of Cloud Native Projects and clusters.
Chkk Upgrade Copilot automates every phase of your upgrade cycle — from parsing release notes and diffing Helm charts to mapping CRD, dependency, and config changes. Our agent flags breaking changes, EOL risks, and critical defects early and identifies incompatible components and API deprecations. It then couples these insights with parameter‑driven Blueprints, orchestrated by durable Workflows, and executed through purpose‑built Action Engines to deliver safe, predictable upgrades at scale for 100s of Cloud Native Projects. Chkk accelerates upgrade execution by more than 10× while eliminating last‑minute surprises.
Upgrade Copilot delivers three complementary capabilities:
1. [Upgrade Assessments](/product/upgrade-copilot/assessments) map the scope, impact, and dependencies of a Cloud Native upgrade so teams can scope effort and delegate work early.
2. [Upgrade Templates](/product/upgrade-copilot/templates) provide a detailed, pre-verified workflow tested on a digital twin of your infrastructure. Templates can be generated directly or derived from an Assessment.
3. [Upgrade Plans](/product/upgrade-copilot/plans) instantiate a Template for a specific cluster, orchestrating each verified step while tracking progress, rollbacks, and post-flight checks.
Platform, DevOps and SRE Teams use Chkk Upgrade Copilot to stay ahead of Cloud Native upgrades and:
* Upgrade their fleets 8-10x faster and without any breakages
* Prevent errors, breakages and failures by deploying critical bugs are deployed in their Cloud Native environment
* Ensure security and compliance by patching CVEs and avoiding EOL versions running in prod environments
* Avoid "forced upgrades" by cloud providers (EKS, GKE, AKS) [Blog: Forced Upgrades](https://www.chkk.io/blog/why-forced-eks-gke-upgrades-are-a-business-continuity-risk)
* Avoid 500% EKS Extended Support, GKE Extended Support, and AKS Long-Term Support Fees [Blog: EKS Extended Support](https://www.chkk.io/blog/amazon-eks-extended-support), [Blog: GKE Extended Support](https://www.chkk.io/blog/gke-extended-support), [Blog: AKS Long-Term Support](https://www.chkk.io/blog/aks-long-term-support-and-eks-extended-support-similarities-differences)
* Standardize and delegate upgrades process, minimize errors, and free up time for expert team members
* Publish Preverified Upgrade Plans to application teams so they can upgrade their own clusters
* Unlock innovation by delivering new infrastructure features to application developers
# Alertmanager
Source: https://docs.chkk.io/projects/alertmanager
Chkk coverage for Alertmanager. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v0.20.0"
export const ChecksMinVer_0 = "v0.22.2"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Alertmanager Overview
Alertmanager handles alert deduplication, routing, silencing, and inhibition for Prometheus. It ensures that alerts reach the right destinations while preventing unnecessary noise. Upgrades can introduce breaking changes, impact notification routing, or remove deprecated APIs, requiring careful preparation. Recent updates have removed long-standing APIs, enforced stricter configuration validation, and patched security vulnerabilities. Chkk helps platform engineers by automating upgrade checks, highlighting impactful changes, and providing structured upgrade guidance.
## Chkk Coverage
### Curated Release Notes
Chkk extracts key updates from Alertmanager release notes, filtering out minor details and focusing on breaking changes, security patches, and new features. It flags major API removals, such as the elimination of the v1 API in v0.27, so engineers can prepare configurations in advance. Important security patches, like the XSS fix in v0.26, are surfaced for prioritization. Configuration shifts, such as stricter UTF-8 validation for labels, are highlighted to prevent unexpected failures.
### Preflight & Postflight Checks
Chkk preflight checks validate configuration syntax, detect deprecated fields, and confirm compatibility with the new version before upgrading. It ensures HA setups are correctly configured, cluster communication is functional, and notification endpoints are reachable. After the upgrade, postflight checks verify that Alertmanager joins clusters successfully, continues processing alerts, and logs notifications without errors. Any misconfigurations or alert delivery failures are flagged immediately for resolution.
### Version Recommendations
Chkk continuously monitors Alertmanager's support lifecycle, highlighting when a deployed version is nearing EOL or poses security risks. Engineers receive recommendations for stable versions that align with Prometheus and ensure long-term support. If a release introduces significant deprecations, Chkk warns about potential issues before an upgrade. This ensures that platform teams stay on a supported version without disruption.
### Upgrade Templates
Chkk provides **Upgrade Templates** for both in-place and blue-green strategies, ensuring controlled and reliable upgrades. Each template includes pre-upgrade backups, step-by-step instructions, and health checks to minimize alerting disruptions. In-place upgrades update HA instances sequentially, maintaining continuity in smaller clusters. Blue-green upgrades reduce risk by deploying a parallel Alertmanager instance, validating alert processing, cutting over to the updated instance. These templates ensure smooth upgrades, whether for a small development cluster or a large-scale production environment.
### Preverification
Chkk runs a dry-run upgrade in an isolated environment, replicating existing configurations to detect errors before changes are applied in production. It validates configuration syntax, identifies incompatibilities, and simulates alert routing behavior to catch failures early. This helps teams proactively address issues such as deprecated fields, notification mismatches, or breaking API changes before deployment.
### Supported Packages
Chkk supports Alertmanager installations via Helm, Kustomize, and manifests, adapting its validation and upgrade checks accordingly. It seamlessly integrates with Prometheus Operator deployments, standalone setups, and custom-built images. Regardless of the deployment method, Chkk ensures a safe and reliable upgrade process without requiring modifications to existing workflows.
## Common Operational Considerations
* **High Availability & Clustering**: For redundancy, deploy Alertmanager in HA mode and configure Prometheus to send alerts to all instances. Ensure all replicas run the same version and share identical configurations to avoid inconsistencies in alert processing.
* **State Persistence (Silences)**: Alertmanager stores silences and notifications in memory, meaning a full restart will erase active silences. Use persistent storage for long-term state retention or export silences before upgrading to reapply them after deployment.
* **Configuration and Templates**: Validate alerting configuration before deploying updates to prevent notification failures. Use amtool check-config to catch errors, and ensure custom notification templates work correctly after an upgrade.
* **Post-Upgrade Verification**: After upgrading, send a test alert to confirm routing works as expected. Monitor logs and metrics like alertmanager\_notifications\_failed\_total to detect delivery issues and address misconfigurations promptly.
* **Capacity & Performance**: Tune Alertmanager's memory and CPU resources based on alert volume to prevent processing slowdowns. Adjust grouping and throttling settings to control notification frequency and avoid overwhelming alerting channels.
## Additional Resources
* [Alertmanager Documentation](https://prometheus.io/docs/alerting/latest/alertmanager/)
* [Alertmanager Releases](https://github.com/prometheus/alertmanager/releases)
# Amazon VPC CNI
Source: https://docs.chkk.io/projects/amazon-vpc-cni
Chkk coverage for Amazon VPC CNI. We provide curated release notes, preflight/postflight checks, and Upgrade Templates—all tailored to your environment.
export const ReleaseNotesMinVer_0 = "v1.7.1"
export const ChecksMinVer_0 = "v1.11.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Amazon VPC CNI Overview
Amazon VPC CNI (Amazon VPC Container Network Interface plugin) is the default networking plugin for AWS Kubernetes clusters (EKS). It runs on every node and creates Elastic Network Interfaces (ENIs) to assign VPC IP addresses to pods. This direct integration with AWS networking provides high-performance, low-latency pod connectivity on EKS. However, managing and upgrading the VPC CNI can be challenging - misconfigurations or unplanned changes could lead to IP exhaustion or network outages.
## Chkk Coverage
### Curated Release Notes
Chkk tracks official VPC CNI release notes and flags updates that matter, such as IP allocation changes or new prerequisites. Instead of combing through upstream change logs, operators see the changes that matter most for running clusters. By focusing on operational impact, these curated notes help you quickly identify shifts in IP management behavior, required configuration updates, or potential upgrade pitfalls.
### Preflight & Postflight Checks
Upgrading the VPC CNI without proper checks can result in pod networking failures or downtime. Chkk runs preflight checks to ensure your environment meets all requirements before an upgrade. It verifies Kubernetes version compatibility and checks for known prerequisites - for instance, AWS notes that to upgrade to VPC CNI v1.12.0+ you must first be on v1.7.0, so Chkk will warn you if an intermediate upgrade is needed. After the upgrade, postflight checks confirm everything is healthy: Chkk verifies that all nodes are running the new CNI version, pods are receiving IPs normally, and there are no abnormal CNI pod logs or performance regressions.
### Version Recommendations
Chkk continuously monitors Amazon VPC CNI's release cycle and support timeline to keep you on a stable, supported version. It tracks which plugin releases are recommended for each Kubernetes version and flags any end-of-life (EOL) or out-of-support versions running in your clusters. You'll get guidance on safe upgrade targets, ensuring you stay ahead of deprecations and security fixes before support lapses.
### Upgrade Templates
Chkk provides **Upgrade Templates** for both in-place updates and blue-green rollout strategies. For an in-place upgrade, Chkk walks you through updating the CNI DaemonSet or EKS add-on step by step while maintaining network availability. For a more blue-green approach, Chkk can assist in setting up a parallel environment to test the new CNI version: for instance, bringing up a new set of nodes (or a staging cluster) with the updated CNI, moving a portion of workloads for validation, and then migrating traffic fully. Each template includes safety checkpoints and rollback instructions, so you can confidently promote the new CNI once it's verified, or quickly revert if needed.
### Preverification
By simulating the entire upgrade in an isolated "digital twin," Chkk detects conflicts—like IP exhaustion or IAM permission gaps—before they hit production. For example, if the new version changes how IP addresses are allocated or introduces stricter requirements for custom networking (ENIConfig) or security group per pod features, those incompatibilities or errors will surface in the simulation. Any anomalies like IP assignment failures, excessive latency, or configuration warnings are flagged early. This means you only proceed with the real upgrade once it's been proven safe in a replica of your environment.
### Supported Packages
Whether you install the Amazon VPC CNI via Helm, Kustomize, or raw manifest, Chkk automatically detects your installation method and adapts its plan accordingly. Regardless of your packaging method (self-managed or EKS-managed add-on), Chkk's checks and recommendations adapt accordingly. It also supports custom images or private registries - ensuring that even if you're using a forked CNI build or an air-gapped registry, the upgrade workflow and validation checks still function seamlessly for your setup.
## Common Operational Considerations
* **IP Allocation Challenges:** Each node has a finite pool of IPs based on how many ENIs it can attach, so running out of available addresses will halt pod scheduling. Adjusting instance sizes, using warm IP targets, or enabling prefix delegation helps avoid IP exhaustion.
* **Scaling Considerations:** As clusters grow, VPC-level IP space can become a bottleneck if subnets run out of capacity. Monitoring IP usage at scale and tuning the warm IP pool protect against AWS API throttling and networking delays.
* **Security Best Practices:** Ensure your nodes have the correct IAM roles (e.g., AmazonEKS\_CNI\_Policy) and consider using NetworkPolicies to enforce zero-trust. Regularly update the CNI for security patches and keep security groups aligned with least-privilege principles.
* **Compatibility Issues:** VPC CNI is tightly integrated with EKS, so chaining other CNIs or supporting Windows nodes requires matching versions.
* **Monitoring & Troubleshooting:** Pod IP assignment errors often surface in the aws-node logs or as failed scheduling events. Collecting Prometheus metrics and leveraging CloudWatch alarms allow quick detection of IP exhaustion or ENI attachment failures.
## Additional Resources
* [Amazon VPC CNI Documentation](https://docs.aws.amazon.com/eks/latest/userguide/managing-vpc-cni.html)
* [Amazon VPC CNI Releases](https://github.com/aws/amazon-vpc-cni-k8s/releases)
# Apache Kafka
Source: https://docs.chkk.io/projects/apache-kafka
Chkk coverage for Apache Kafka. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
export const ReleaseNotesMinVer_0 = "v2.5.1"
export const ChecksMinVer_0 = "v2.6.3"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Apache Kafka Overview
Apache Kafka is a distributed event streaming platform designed to handle real-time data pipelines and event-driven applications at scale. It uses a partitioned, replicated broker architecture to deliver high throughput, durability, and fault tolerance. Kafka relies on ZooKeeper or its newer KRaft quorum for metadata management and partition leadership coordination, making the health of these components critical to cluster stability. Producers write records to Kafka topics, while consumers subscribe to specific partitions to read data. Kafka's proven scalability and flexibility have made it essential for modern infrastructure teams managing complex data workflows.
## Chkk Coverage
### Curated Release Notes
Chkk consolidates official Kafka release notes and KIPs, highlighting only impactful changes such as new configurations, defaults adjustments, or API deprecations affecting your clusters. Instead of manually parsing upstream notes, you receive targeted updates relevant to production environments. For example, Chkk alerts you if a Kafka update changes replication defaults or removes legacy consumer configurations, ensuring you're not caught off guard. Summaries link directly to detailed upstream documentation for further reference. Chkk's tailored notifications streamline operational awareness and minimize unexpected disruptions.
### Preflight & Postflight Checks
Chkk performs thorough preflight checks before Kafka upgrades, verifying broker compatibility, ZooKeeper (or KRaft) health, and configuration readiness to prevent upgrade issues. Post-upgrade, it validates partition leadership, consumer group offsets, broker synchronization, and replication health. Any anomalies, such as increased consumer lag or under-replicated partitions, are quickly flagged for immediate action. These automated checks help ensure upgrade consistency, minimize downtime, and reduce manual troubleshooting. Platform engineers rely on Chkk's checks for confidence during Kafka maintenance.
### Version Recommendations
Chkk tracks Kafka's support lifecycle and proactively alerts you about upcoming or past EOL versions, helping mitigate security and stability risks. It recommends stable Kafka versions based on community feedback, known issues, and compatibility with your Kubernetes clusters. When your Kafka release approaches end-of-life or carries known vulnerabilities, Chkk provides actionable upgrade paths tailored to your environment. This proactive approach simplifies upgrade planning, reducing reactive firefighting from unexpected CVEs or version incompatibilities. With Chkk's recommendations, you maintain stable, secure Kafka deployments.
### Upgrade Templates
Chkk offers detailed Kafka **Upgrade Templates** for in-place upgrades or blue-green deployments, aligning with common GitOps and CI/CD practices. These upgrade templates guide you step-by-step through broker restarts, inter-broker protocol adjustments, and partition reassignments. Upgrade Templates also include recommended pre-upgrade validations (e.g., verifying cluster health, ISR status, and resource availability) and rollback procedures if issues arise post-upgrade. This structured approach removes guesswork, enabling predictable, repeatable Kafka upgrades. You can confidently manage upgrades without compromising data availability.
### Preverification
Chkk provides preverificaton in a controlled, sandboxed environment before applying changes to your production clusters. It replicates broker configurations, topic layouts, and workloads to identify hidden risks such as resource constraints, configuration mismatches, or protocol incompatibilities. Any upgrade issues detected during this simulation—like partition replication failures or consumer connectivity problems—are flagged early for remediation. By catching potential problems upfront, Chkk's preverification significantly reduces the risk and uncertainty of live Kafka upgrades, ensuring smooth deployments.
### Supported Packages
Chkk supports Kafka deployments across multiple installation methods, including Helm charts, Kustomize overlays, and plain manifests. It automatically recognizes your deployment type, ensuring upgrade instructions match your operational patterns. Customizations such as private registries, bespoke image builds, or specialized patches remain intact throughout upgrades. Chkk's compatibility across installation methods means you can maintain Kafka consistently alongside other critical components without changing your preferred workflows. This flexibility streamlines Kafka management regardless of how it's deployed.
## Common Operational Considerations
* **Broker Quorum Stability:** Ensure a replication factor of at least 3, enforce `min.insync.replicas`, and perform controlled shutdowns to prevent data loss or unstable leader elections.
* **ZooKeeper Dependencies:** Maintain ZooKeeper in a resilient quorum (3+ nodes) with careful latency monitoring, or plan structured migrations to Kafka's KRaft to avoid irreversible metadata issues.
* **ISR and Under-Replicated Partitions:** Actively monitor under-replicated partitions and use replication throttles during maintenance; consistent ISR health ensures reliable real-time message handling.
* **Consumer Lag Management:** Scale consumer instances or optimize processing when lag increases, regularly tracking offsets to maintain real-time data consumption.
* **Rolling Upgrades and Downgrades:** Upgrade Kafka brokers sequentially, verifying partition synchronization after each upgrade, and avoid premature inter-broker protocol version upgrades to retain rollback capabilities.
* **Security and Authentication Pitfalls:** Enforce SASL and TLS authentication on brokers, implementing precise ACLs; misconfigurations in certificates or ACL rules can disrupt client connections and security.
* **Networking and Load Balancing Issues:** Kafka clients connect directly to partition leaders, requiring partition-aware connectivity instead of traditional load balancers; use rack awareness and leader balancing to prevent bottlenecks.
## Additional Resources
* [Apache Kafka Documentation](https://kafka.apache.org/documentation/)
* [Apache Kafka Releases](https://github.com/apache/kafka/tags)
# Apache Zookeeper
Source: https://docs.chkk.io/projects/apache-zookeeper
Chkk coverage for Apache Zookeeper. We provide curated release notes, preflight/postflight checks, and Upgrade Templates—all tailored to your environment.
export const ReleaseNotesMinVer_0 = "v3.5.8"
export const ChecksMinVer_0 = "v3.7.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Apache ZooKeeper Overview
Apache ZooKeeper is a distributed coordination service for managing application configurations, leader election, and synchronization. It uses a quorum-based approach, replicating data across nodes to ensure high availability. A single leader processes writes, and followers replicate changes to maintain consistency. Many systems (e.g., Kafka, Hadoop) depend on ZooKeeper to track essential metadata. By providing robust primitives like locks and watches, ZooKeeper simplifies the complexity of distributed coordination.
## Chkk Coverage
### Curated Release Notes
Chkk closely tracks official ZooKeeper updates and extracts only the changes that matter to your environment. You'll receive concise, actionable briefs on new features, security patches, or deprecations. It flags changes that might affect configurations or break existing setups. Chkk also highlights when certain dependencies (like Java versions) change. This saves you time by filtering through Apache's upstream details for operational relevance.
### Preflight & Postflight Checks
Before upgrading, Chkk's preflight checks confirm that your ZooKeeper cluster is healthy and that your target version is compatible with existing configurations. It scans for deprecated settings, ensures each node is in sync, and verifies that you aren't skipping required upgrade paths. After the upgrade, postflight checks confirm that quorum is established, nodes are on the correct version, and logs show no critical errors. If issues arise, Chkk pinpoints them immediately for quick remediation.
### Version Recommendations
Chkk maps ZooKeeper's official support timelines and flags EOL versions in use. It tracks which versions align with critical bug fixes, stable patches, and security updates. If a newly released version contains regressions or doesn't yet have community consensus, Chkk advises a safer path. This guidance ensures your cluster stays in a healthy support window, balancing features and stability. It also helps align upgrades with internal compliance and Kubernetes version constraints.
### Upgrade Templates
Chkk provides **Upgrade Templates** for both in-place and blue-green upgrades of ZooKeeper. In-place upgrades guide you through safely updating nodes one at a time while maintaining quorum, whereas blue-green upgrades deploy a parallel ZooKeeper ensemble to test stability before switching traffic. Each procedure includes clear rollback steps and recommended monitoring checkpoints. They align with ZooKeeper community best practices to minimize service disruption. By systematically following each upgrade phase, platform teams significantly reduce the risk of downtime.
### Preverification
Chkk's preverification feature simulates the upgrade on a sandbox digital twin, mirroring your production configuration. It flags conflicts such as parameter deprecations or resource limits that might cause downtime in production. By iterating in a safe environment, you can update configs, address performance issues, and validate the process before going live. This workflow significantly reduces the odds of discovering breaking changes mid-upgrade. Once preverification is successful, you can confidently apply the final plan.
### Supported Packages
Chkk supports Apache ZooKeeper deployments across multiple installation methods, including Helm charts, Kustomize overlays, and standard manifests. It automatically recognizes your ZooKeeper deployment method, ensuring upgrade instructions align seamlessly with your existing operations. Customizations such as private registries, custom-built images, or specialized patches are fully supported during upgrades. Chkk's broad compatibility ensures that you can manage ZooKeeper consistently alongside other infrastructure components without altering established workflows. This flexibility simplifies ZooKeeper lifecycle management regardless of your chosen deployment approach.
## Common Operational Considerations
* **Quorum and Leader Election Issues:** Use an odd number of nodes to maintain a clear majority, and ensure each node has consistent network connectivity to avoid election delays. Tuning `initLimit` and `syncLimit` is critical so that leader/follower negotiations complete promptly without premature node removal.
* **Data Consistency and Syncing:** Use autopurge to remove old transaction logs and snapshots, preventing disk bloat and speeding up node recovery. Watch for lagging followers that might drop from quorum or cause consistency drift if they can't catch up quickly.
* **Latency and Performance Tuning:** Keep `tickTime` and session timeouts at sensible defaults; overly aggressive settings can trigger false timeouts. Allocate enough JVM heap to avoid swapping and consider dedicating disks for transaction logs to minimize I/O latencies.
* **Rolling Upgrades with Minimal Downtime:** Upgrade one node at a time, waiting for re-sync and stable quorum before moving to the next. Confirm leader re-election events are smooth and track client connections if the leader is temporarily offline.
* **Handling Zookeeper Node Failures:** Replace crashed nodes quickly and ensure each new node rejoins with a consistent data directory. Monitor logs using the `stat` command and confirm nodes return to following or leading states without extended election times.
* **ACL and Security Management:** Enable authentication schemes (e.g., SASL or digest) and lock down sensitive znodes with ACLs. Consider encrypting inter-node and client-server traffic (TLS) to protect data in transit and restrict unauthorized access.
## Additional Resources
* [Apache Zookeepers Documentation](https://zookeeper.apache.org/doc/current/)
* [Apache Zookeepers Releases](https://zookeeper.apache.org/releases.html)
# Argo CD
Source: https://docs.chkk.io/projects/argo-cd
Chkk coverage for Argo CD. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v1.8.0"
export const ChecksMinVer_0 = "v2.0.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Argo CD Overview
Argo CD is a declarative GitOps continuous deployment tool that manages Cloud Native applications by keeping all definitions in Git and automatically syncing the cluster state to match. It runs as a controller, detecting and optionally correcting drift between the live state and the desired configuration. This approach keeps workloads aligned with Git, supporting Helm charts, Kustomize overlays, and other packaging tools for flexible declarative management. Argo CD also offers robust rollback capabilities, allowing teams to revert to any previous version. Its web UI, CLI, SSO integration, and multi-cluster support make Argo CD a powerful engine for continuous delivery.
## Chkk Coverage
### Curated Release Notes
Chkk tracks the official Argo CD release notes and change logs to produce curated summaries for operators. This means you get highlights of upgrade changes, security patches, and new features from each Argo CD release that are relevant to your deployments. By offloading the research work of combing through release notes (Chkk Operational Safety Platform), Chkk's curated notes ensure you're aware of any changes (for example, deprecated APIs or config keys) that could impact your Argo CD installation before you upgrade.
### Preflight & Postflight Checks
Chkk performs automated preflight and postflight checks around Argo CD upgrades to catch issues early. Before an upgrade, Chkk runs validations to identify potential problems such as deprecated APIs (or Argo CD CRD changes) that the new version might use, configuration settings that need updating, and any drift between the Git declarative state and the live cluster state. After the upgrade, Chkk's postflight checks verify that Argo CD is healthy and behaving as expected - for instance, all Argo CD components are running, applications remain in sync, and no new errors or warnings appear. These pre/post-flight checks help detect misconfigurations or regressions early, ensuring the upgrade was successful.
### Version Recommendations
Chkk continuously monitors ArgoCD's support lifecycle and known compatibility issues to provide version recommendations. It flags when you are running an outdated or end-of-life Argo CD version and suggests a stable version for upgrade. This recommendation is based on the latest patches and security updates, as well as compatibility with your Kubernetes cluster version. In practice, Chkk's Upgrade Copilot identifies the "correct next version" of Argo CD to upgrade to - one that resolves known vulnerabilities or deprecations - and it alerts you if your current Argo CD release is approaching EOL or has known incompatibilities.
### Upgrade Templates
Chkk provides proven **Upgrade Templates** for Argo CD, supporting both in-place and blue-green deployment strategies. In an in-place upgrade, it orchestrates the correct sequence of component updates to minimize downtime. For blue-green, Chkk helps spin up a parallel "green" instance, switch over once validated, and then retire the old "blue" deployment. It also determines when to pick one method over the other, aiming to keep GitOps services running smoothly. Throughout either approach, Chkk preserves application synchronization and state, ensuring upgrades do not disrupt managed apps.
### Preverification
Before upgrading Argo CD in production, Chkk conducts a preverification in a controlled environment to validate compatibility with your current configuration. It performs dry-run checks, detecting any issues with Helm charts, Kustomize overlays, or custom resources like Applications and AppProjects. Chkk also confirms that your RBAC configurations remain valid and that repo server integrations (Helm, Git, etc.) continue functioning. If the new version needs additional permissions, Chkk highlights these before proceeding. By verifying all upgrade steps in advance, Chkk ensures you encounter fewer risks during the actual production upgrade.
### Supported Packages
Chkk's Argo CD Project works with all common installation methods—Helm, Kustomize, or raw YAML. Whether you installed it via the official Helm chart, a Kustomize overlay, or direct manifests, Chkk automatically detects and manages your deployment. In practice, it tailors checks and upgrades to fit your approach, preserving GitOps workflows for Argo CD itself. This includes suggesting updated Helm chart versions, patching manifests, and validating across all package types to ensure continued compatibility. By covering every packaging method, Chkk keeps Argo CD running smoothly and aligned with your desired state.
## Common Operational Considerations
* **Repository Sync Failures:** Often caused by incorrect credentials or invalid manifests. Monitor repo-server logs and Argo CD UI events to pinpoint the issue.
* **RBAC Misconfigurations:** Can lock users out or grant excessive privileges. Double-check ArgoCD's internal roles and cluster RBAC rules to ensure correct access levels.
* **Reconciliation Delays:** Large installations may see slower sync times if the controller is overloaded. Tune ArgoCD's concurrency settings and watch out for apps with constantly flapping differences.
* **API Server Load:** Argo CD can make frequent API calls in big clusters; consider reducing polling intervals, adjusting client QPS/burst, or sharding Argo CD instances if API requests spike.
* **Secrets Management:** Use tools like Sealed Secrets or SOPS to avoid storing raw secrets in Git. Secure ArgoCD's service accounts, storage, and logs to prevent unauthorized exposure of sensitive data.
## Additional Resources
* [Argo CD Documentation](https://argo-cd.readthedocs.io/en/stable/)
* [Argo CD Releases](https://github.com/argoproj/argo-cd/releases)
# Argo Rollouts
Source: https://docs.chkk.io/projects/argo-rollouts
Chkk coverage for Argo Rollouts. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
export const ReleaseNotesMinVer_0 = "v0.10.2"
export const ChecksMinVer_0 = "v1.0.3"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Argo Rollouts Overview
Argo Rollouts is a controller that enables advanced deployment strategies such as blue-green, canary, and experiment-driven progressive delivery. It introduces custom resource definitions (CRDs) to manage these rollouts, integrating with ingress controllers and service meshes to gradually shift traffic between versions. Argo Rollouts can automatically analyze metrics and perform automated promotions or rollbacks based on health criteria. These capabilities provide fine-grained control over deployments, allowing teams to limit the blast radius of changes and safely introduce new application versions even in high-traffic production environments.
## Chkk Coverage
### Curated Release Notes
Chkk filters Argo Rollouts release notes, highlighting features, deprecations, and breaking changes impacting your environment. This eliminates manual tracking and flags shifts like default behavior changes in auto-promotion. Deprecations in CRDs and major API changes are surfaced before they cause issues. Security patches and lifecycle support updates are flagged to ensure compliance. These insights help teams stay ahead of potential disruptions.
### Preflight & Postflight Checks
Preflight checks validate Kubernetes version compatibility, detect deprecated Rollout fields, and assess rollout strategy correctness before an upgrade. Chkk scans your existing Rollout custom resources for deprecated fields or incompatible spec usages that the upcoming version would no longer support. Postflight checks confirm the new Rollouts controller is healthy and existing Rollout objects function correctly. It flags failed rollouts, stuck resources, or unexpected behavior. This prevents unnoticed failures and keeps deployments reliable.
### Version Recommendations
Chkk tracks Argo Rollouts' support lifecycle, flagging EOL risks and version incompatibilities. It helps teams avoid known-bugged releases and recommends the safest upgrade paths. Chkk prioritizes stability, guiding upgrades based on support timelines and community feedback. Historical issue tracking prevents adopting versions with recurring performance or reliability problems. This ensures that deployments remain on supported, stable builds.
### Upgrade Templates
Chkk provides structured in-place and blue-green upgrade templates tailored for Argo Rollouts. In-place upgrades guide step-by-step controller updates while ensuring availability. Blue-green upgrades deploy a new Rollouts instance in parallel before fully switching over, allowing controlled migration. These templates integrate with GitOps pipelines and include rollback plans for quick recovery. They minimize human error and simplify controlled updates.
### Preverification
Chkk pre-verifies upgrades by simulating them in an isolated digital twin environment before production rollout. This detects CRD conflicts, configuration mismatches, and potential resource regressions early. Sample rollouts validate that canary steps, analysis, and rollback conditions work as expected. Performance metrics are analyzed to prevent unexpected controller load increases. This process eliminates surprises and enables safer upgrades.
### Supported Packages
Chkk supports Argo Rollouts deployments through Helm, Kustomize, and raw manifests. It detects installation methods and aligns upgrade guidance accordingly. Private registry and custom-built image compatibility are maintained without forcing external dependencies. Chkk validates custom configurations, ensuring security and compliance. This ensures seamless integration with existing CI/CD pipelines and infrastructure tooling.
## Common Operational Considerations
* **Rollback Triggers & Stability Criteria:** Rollbacks rely on analysis templates; poorly defined conditions can cause premature failures. Configure thresholds to prevent flapping, require multiple failed intervals before rollback, and use consecutive success criteria for safe promotions.
* **Ingress Controller & Service Mesh Compatibility:** Different ingress solutions handle traffic shifting differently, which may cause unexpected routing behavior. Ensure your ingress/service mesh is compatible with Argo Rollouts and prevent sync conflicts in GitOps-managed environments.
* **Resource Consumption & Performance:** High deployment frequency can lead to excessive AnalysisRuns, increasing controller CPU and memory load. Monitor Rollouts controller resource usage and prune old analysis objects to prevent unnecessary overhead.
* **Multi-Cluster Rollout Coordination:** Argo Rollouts operates per cluster and does not natively sync rollouts across multiple clusters. Use CI/CD workflows to coordinate staged deployments and enforce consistency across environments.
## Additional Resources
* [Argo Rollouts Documentation](https://argoproj.github.io/argo-rollouts/)
* [Argo Rollouts Releases](https://github.com/argoproj/argo-rollouts/releases)
# Argo Workflows
Source: https://docs.chkk.io/projects/argo-workflows
Chkk coverage for Argo Workflows. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v2.5.1"
export const ChecksMinVer_0 = "v2.11.1"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Argo Workflows Overview
Argo Workflows is a Cloud Native workflow engine that uses CRDs to define multi-step processes as directed acyclic graphs. It's widely adopted for automating CI/CD pipelines, ML tasks, and data processing at scale. By offloading orchestration logic to the cluster, Argo Workflows simplifies operational overhead. Its design allows dynamic scaling, native container isolation, and extensive integration with CNCF projects. As a CNCF graduated project, it adheres to Cloud Native best practices for performance and reliability.
## Chkk Coverage
### Curated Release Notes
Staying on top of Argo Workflows release changes is critical, especially since Argo does not strictly adhere to semantic versioning and even minor releases may introduce breaking changes. Chkk curates the upstream Argo Workflows release notes into an actionable summary for your team. This means you'll see highlights of new features, critical bug fixes, security patches, and any breaking changes or deprecations that could affect your workflows. This flags new features, critical fixes, or removed APIs that could impact your workflow executions.
### Preflight & Postflight Checks
Upgrading Argo Workflows can be risky without thorough validation. Chkk performs automated preflight checks to ensure your environment is ready for the new version. After the upgrade, postflight checks confirm that the Argo Workflows controller and related components are healthy and functioning. Chkk will verify that the new controller pod is running with the expected version, all CRDs have been upgraded successfully, and existing workflows (including any cron schedules) continue to run without errors.
### Version Recommendations
Chkk continuously monitors Argo Workflows release cycles and support timelines to help you stay on a safe version. The Argo project maintains active support only for the most recent two minor releases, which means running an older version could leave you without patches or security fixes. Chkk keeps track of when your current Argo Workflows version is approaching end-of-life. It will alert you if you're on an outdated release stream and recommend a target version to upgrade to that is both stable and compatible with your Kubernetes cluster.
### Upgrade Templates
To simplify the upgrade process, Chkk provides **Upgrade Templates** for Argo Workflows. For in-place upgrades, Chkk walks you through each step in the sequence: applying CRD updates, upgrading the controller deployment, and restarting the Argo server/UI if present. For a blue-green upgrade, Chkk helps you deploy a new instance of Argo Workflows (a "green" controller) alongside the old ("blue") one. The goal is to run the old and new versions in parallel, allowing you to gradually direct non-critical workflows to the new controller and observe results. Once the new version is proven stable (i.e., workflows are running successfully under the new controller), you can promote it to replace the old version for all workflows. In both scenarios, Chkk's templates build safety checks and rollback procedures at each stage.
### Preverification
One of Chkk's most powerful features is the ability to simulate an Argo Workflows upgrade in a digital twin environment before it goes to the production cluster. Chkk runs an isolated instance that mirrors your cluster's Argo Workflows setup - including the same cluster version and similar Argo configurations - and then applies the upgrade there first. During this simulation, Chkk checks for any compatibility problems. By catching CRD conflicts, performance regressions, or logic changes in this sandbox environment, Chkk ensures you only proceed with the real upgrade once you have certainty that it will succeed.
### Supported Packages
It has built-in support for deployments via Helm charts, Kustomize overlays, or plain YAML manifests. Upon connecting to your cluster, Chkk auto-detects the installation method and tracks the current Argo Workflows version and manifest source. It preserves custom configurations, images, and private registry references within your workflows.
## Common Operational Considerations
* **Workflow Execution Performance:** Large, concurrent workflow runs can overload the Cloud Native API and the workflow controller. Offloading logs and status, plus careful resource tuning, helps maintain stability at scale.
* **CRD Scaling & Persistence:** High-volume or resource-intensive workflows can surpass etcd capacity and cause performance issues. Persisting workflow data to an external database ensures smooth operation under heavy loads.
* **Version Mismatches:** Using different releases of the controller, UI, and CLI can lead to incompatible API calls and random failures. Align all components to the same supported version to avoid unexpected errors.
* **RBAC in Multi-Tenant Clusters:** Multi-team environments often need isolation through separate namespaces and controllers. Clear roles, permissions, and namespace boundaries prevent unauthorized access or workflow overlap.
* **Namespace & Template Best Practices:** Duplicating workflow definitions in multiple namespaces can lead to version drift. Reusing standardized templates and storing them in a central repository keeps definitions consistent.
* **Workflow Failures from Dependency Changes:** Shifts in external services or system settings can break previously functional tasks. Monitoring upstream dependencies and updating workflow steps accordingly prevents unplanned downtime.
## Additional Resources
* [Argo Workflows Documentation](https://argo-workflows.readthedocs.io/en/latest/)
* [Argo Workflows Releases](https://github.com/argoproj/argo-workflows/releases)
# Bitbucket
Source: https://docs.chkk.io/projects/bitbucket
Chkk coverage for Bitbucket. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v1.0.1"
export const ChecksMinVer_0 = "v1.0.4"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Bitbucket Overview
Bitbucket Cloud is Atlassian’s managed Git-based source control and CI/CD service, providing seamless integration with tools like Jira and Trello. It supports pull requests, code reviews, branch permissions, and integrated CI/CD pipelines, streamlining development workflows without additional infrastructure management. Bitbucket Data Center is Atlassian’s self-hosted edition that runs natively, providing clustered high-availability, smart-mirror geo-caching, zero-downtime rolling upgrades, and full control over data residency, encryption, and custom plugins.
## Chkk Coverage
### Curated Release Notes
Chkk monitors Bitbucket release notes, highlighting critical updates, API changes, and deprecations affecting your workflows. It proactively identifies impacts such as changes to API rate limits or discontinued features, providing clear, actionable alerts. For self-hosted instances, Chkk flags essential upgrade considerations and configuration changes, ensuring platform teams avoid unexpected operational disruptions.
### Preflight & Postflight Checks
Before upgrades, Chkk performs preflight checks to confirm compatibility, including supported Java/database versions, plugin statuses, and configurations. It ensures that upgrades do not skip required intermediate versions, helping avoid failures due to incompatible jumps. Post-upgrade checks verify cluster health, application functionality, and integration stability, promptly highlighting issues like plugin failures or repository indexing errors.
### Version Recommendations
Chkk actively tracks Atlassian’s support timelines, alerting you when Bitbucket versions approach end-of-life or face critical vulnerabilities. It recommends stable upgrade targets, often prioritizing Long Term Support (LTS) releases, balancing new features with proven stability. For Bitbucket Cloud, Chkk advises on critical upcoming changes, ensuring API migrations and security adjustments are handled smoothly and proactively.
### Upgrade Templates
Chkk provides detailed templates for in-place and blue-green Bitbucket upgrades, incorporating Atlassian’s best practices. Rolling upgrades maintain zero downtime by sequentially updating nodes in clusters, while blue-green strategies involve parallel environments and gradual traffic migration. These templates integrate seamlessly into GitOps and CI/CD workflows, significantly reducing the risk of errors during upgrade procedures.
### Preverification
Chkk’s preverification process simulates upgrades in isolated staging environments, identifying issues like database migration problems, plugin incompatibilities, or performance bottlenecks. It validates the entire upgrade path, including integrations and pipeline runners, allowing adjustments before production deployments. For Bitbucket Cloud, Chkk utilizes available Atlassian preview environments to preemptively address impacts from upcoming cloud-side updates.
### Supported Packages
Chkk fully supports various deployment approaches, including Helm, Kustomize, and direct YAML, ensuring compatibility with your existing infrastructure management tools. It respects custom images, private registries, and specialized configurations, seamlessly adapting to hybrid or traditional VM-based deployments. This comprehensive package support ensures smooth transitions and consistent management across different deployment scenarios.
## Common Operational Considerations
* **Self-Hosted Runner Connectivity:** Ensure Bitbucket Pipelines runners behind firewalls or proxies have proper egress to Atlassian endpoints. Misconfigurations cause pipeline connection failures, impacting continuous integration workflows.
* **API Rate Limits:** Bitbucket Cloud’s API limits (default 1,000 requests/hour) require careful integration design with caching and batching. Monitor usage closely and prefer Workspace Access Tokens to mitigate throttling issues.
* **Large Repositories & Git LFS:** Large repositories (>1 GB) degrade performance; adopt Git LFS for large binaries and regularly prune obsolete data. Monitor storage closely, especially in Data Center, to maintain efficiency.
* **Search Service and Indexing:** Data Center requires dedicated search (Elasticsearch/OpenSearch); ensure resilience and exclude unnecessary repositories from indexing. Regularly verify indexing health to maintain reliable code search.
* **Access Tokens and Security:** Regularly rotate and scope workspace/repo tokens tightly, utilizing expiration and IP allowlisting. Audit permissions frequently to minimize security risks from unauthorized code access.
* **Cloud vs. Data Center Considerations:** Cloud offers convenience and managed updates; Data Center provides control but requires significant infrastructure maintenance. Assess feature gaps, cost implications, and operational overhead carefully before migrations.
## Additional Resources
* [Bitbucket Documentation](https://confluence.atlassian.com/bitbucketserver)
* [Bitbucket Release Notes](https://confluence.atlassian.com/bitbucketserver/release-notes-872139866.html)
# Botkube
Source: https://docs.chkk.io/projects/botkube
Chkk coverage for Botkube. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v0.15.0"
export const ChecksMinVer_0 = "v1.0.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Botkube Overview
Botkube is an open-source ChatOps tool that integrates Kubernetes clusters with popular messaging platforms such as Slack, Mattermost, and Discord. It automatically provides contextual alerts, status updates, and actionable recommendations directly in chat channels. Users can execute Kubernetes commands (kubectl, helm) within these channels, enabling real-time troubleshooting without direct cluster access. Its extensible plugin architecture supports custom sources (Kubernetes events, Prometheus alerts) and executors (commands/actions), enhancing operational collaboration and incident response.
## Chkk Coverage
### Curated Release Notes
Chkk continuously monitors Botkube's official release notes, highlighting critical new features, configuration adjustments, and deprecations relevant to your environment. It provides concise summaries of impactful changes, such as altered default notification behaviors or discontinued integrations, allowing immediate operational awareness. Chkk identifies precisely how these upstream changes might affect your specific configuration. Clear guidance is provided to ensure your environment remains stable and aligned with best practices post-upgrade.
### Preflight & Postflight Checks
Chkk conducts preflight checks verifying compatibility between your cluster's Kubernetes version, Botkube plugins, and required outbound connectivity for integrations. These checks highlight potential configuration mismatches, deprecated fields, or network constraints to prevent upgrade-related issues. Postflight checks confirm Botkube pods are running healthily post-upgrade, reviewing logs for errors or connectivity issues. Chkk ensures notifications function correctly, immediately identifying misconfigurations or plugin compatibility problems.
### Version Recommendations
Chkk actively tracks Botkube's release lifecycle, alerting you when your installed version approaches end-of-life or presents known stability issues. Recommendations consider compatibility with your Cloud Native environment and critical security or functionality fixes in newer versions. By evaluating community feedback and release stability, Chkk advises when to upgrade or delay based on operational impact. This approach ensures continuous observability coverage while minimizing disruptions.
### Upgrade Templates
Chkk provides structured Upgrade Templates covering both in-place and blue-green methodologies, aligned with Botkube's best practices. In-place templates guide seamless upgrades by verifying configurations, ensuring pod health, and checking connectivity post-update. Blue-green templates facilitate parallel deployment of new versions in isolated channels, minimizing disruption while verifying functionality before a full switch. Each template clearly defines rollback points and integrates seamlessly with GitOps or CI/CD pipelines, reducing human error.
### Preverification
Chkk employs preverification to simulate the Botkube upgrade within an isolated staging environment mirroring your actual configuration. This "digital twin" approach proactively detects potential configuration errors, plugin incompatibilities, or resource consumption issues. By resolving these issues before production deployment, teams avoid unforeseen disruptions. Preverification ensures upgrades proceed smoothly, significantly increasing operational confidence and stability.
### Supported Packages
Chkk supports various Botkube deployment mechanisms, including Helm charts, Botkube CLI, and manifests. It adapts upgrade recommendations and templates to match your deployment method and configuration specifics, such as private registries or custom plugins. Chkk integrates seamlessly with existing workflows (Kustomize, Argo CD), maintaining operational consistency. Teams can confidently manage Botkube upgrades without altering established processes or tooling.
## Common Operational Considerations
* **Network Access for Integrations:** Ensure your egress rules permit Botkube's required connections to Slack APIs or GitHub for plugins. Restricted environments should explicitly whitelist these endpoints or use proxies.
* **Plugin Version Compatibility:** Always update Botkube's plugin index to match the agent version during upgrades. Mismatched plugins cause crash loops and halt notifications.
* **RBAC and Permissions Issues:** Regularly review Botkube's RBAC permissions, ensuring access to required resources and consistent mapping between RBAC and Botkube configurations. Misconfigured permissions cause missed events or failed command executions.
* **Tuning Alerts:** Customize Botkube alerts to balance actionable information versus noise. Begin with critical notifications, incrementally adding lower-level alerts only where needed.
* **Air-Gapped Environments:** Mirror Botkube images and plugins internally, and prefer self-hosted integrations (like Mattermost). Without this, air-gapped clusters experience startup failures or stalled deployments.
* **Config Persistence:** Manage Botkube configurations via version-controlled Helm values or manifests rather than direct ConfigMap edits. Verify Botkube properly reloads configurations after changes to avoid silent misconfigurations.
## Additional Resources
* [Botkube Documentation](https://docs.botkube.io/)
* [Botkube Releases](https://github.com/kubeshop/botkube/releases)
# Bottlerocket Update Operator
Source: https://docs.chkk.io/projects/bottlerocket-update-operator
Chkk coverage for Bottlerocket Update Operator. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v0.2.1"
export const ChecksMinVer_0 = "v1.2.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Bottlerocket Update Operator Overview
Bottlerocket Update Operator (Brupop) automates OS updates for Bottlerocket nodes. It comprises a controller, per-node agents, and an API server for secure coordination. Brupop orchestrates gradual node updates via native draining and rebooting, reducing operational risk. Communication is secured using TokenReview and certificates managed by cert-manager. Platform teams gain automated, secure, and reliable OS patching without manual node intervention.
## Chkk Coverage
### Curated Release Notes
Chkk continuously tracks Brupop’s release notes, highlighting impactful features or breaking changes relevant to your clusters. Crucial modifications, such as node label changes or deprecated CRDs, are clearly flagged. This approach allows engineers to quickly grasp operational implications without unnecessary detail. Chkk ensures you're prepared for updates affecting your cluster configuration or OS upgrade processes.
### Preflight & Postflight Checks
Chkk's preflight checks verify your cluster’s readiness, proper node labeling, and compatibility between OS versions. It flags issues like missing labels or risky large version jumps to avoid upgrade failures. Postflight checks validate Brupop’s controller and agents, ensuring successful node updates and reconnections. Logs and BottlerocketShadow resources are scanned for anomalies, enabling rapid identification and resolution of update issues.
### Version Recommendations
Chkk monitors the support timelines for Bottlerocket OS and Brupop, alerting you when nearing end-of-life versions. Notifications explain potential risks, such as lacking security patches or compatibility with Kubernetes versions. Chkk advises stable, supported upgrade paths based on AWS’s recommendations and community insights. Custom version tracking aligns with your internal policies if you manage tailored Bottlerocket builds.
### Upgrade Templates
Chkk provides structured Upgrade Templates for in-place updates with Brupop and blue-green node replacement strategies. Templates include clear instructions and rollback points, aligning with GitOps or CI/CD workflows. The templates incorporate best practices like sequential node updates, health verification, and incremental AMI rollouts. Platform teams confidently manage OS updates, significantly reducing error risk.
### Preverification
Chkk’s Preverification simulates your upgrade process in an isolated environment, revealing issues like CRD conflicts or resource constraints. By rehearsing node draining and OS updates, it exposes potential blockers or configuration mismatches. Detected issues can be resolved proactively, ensuring a smoother production upgrade. Many teams integrate Preverification as a gating step within CI workflows, enhancing operational safety.
### Supported Packages
Chkk supports multiple deployment methods for Brupop, including Helm charts, raw YAML manifests, and GitOps approaches. It identifies customizations like private registries or tuned pod resources, ensuring upgrade guidance maintains existing configurations. Differences between current and target configurations are clearly outlined to minimize operational impact. Platform engineers retain their preferred tools and workflows with seamless Chkk integration.
## Additional Resources
* [Bottlerocket Update Operator Docs](https://bottlerocket.dev/en/brupop/)
* [Bottlerocket Update Operator Releases](https://github.com/bottlerocket-os/bottlerocket-update-operator/releases)
# Calico
Source: https://docs.chkk.io/projects/calico
Chkk coverage for Calico. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v3.14.1"
export const ChecksMinVer_0 = "v3.18.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Calico Overview
Calico is an open-source networking and security solution for container platforms, providing policy-driven controls to secure workloads. It can leverage layer 3 routing with BGP or encapsulation (VXLAN, IP-in-IP) for flexible deployment across cloud or on-premises environments. Calico supports advanced features like eBPF for improved performance and integrates with cluster APIs for network policy enforcement. It scales with large clusters using components like Typha to reduce load on the datastore. Calico's breadth of features makes it a popular CNI choice for production-grade environments that require robust security and dynamic routing.
## Chkk Coverage
### Curated Release Notes
Chkk consolidates Calico release notes into a concise summary of relevant changes—highlighting major updates, security patches, and deprecations that directly affect your clusters. You no longer need to comb through every upstream note; Chkk filters the noise to provide tailored impact analysis. For instance, if a new Calico version requires updated IP pool settings or changes a default BGP parameter, you receive a targeted alert. This ensures platform engineers stay on top of key operational shifts without wading through less pertinent details. Chkk also calls out new features worth exploring, like eBPF improvements or helm chart modifications.
### Preflight & Postflight Checks
Chkk's preflight checks confirm your environment meets the new Calico version's prerequisites, such as supported Kubernetes versions and no deprecated fields in your Calico CRDs. They also validate network configuration—e.g., ensuring IP pools don't overlap and that BGP or VXLAN settings won't break under new defaults. After the upgrade, Chkk's postflight checks verify that calico-node DaemonSet, kube-controllers, and Typha (if present) are running correctly and that network connectivity remains intact. These checks also look for anomalies in policy enforcement, such as unexpected traffic blocks. By rapidly diagnosing upgrade issues, Chkk saves time and reduces risk in production.
### Version Recommendations
Chkk tracks Calico's support timeline and notifies you when a release is nearing or past EOL, mitigating security and compatibility risks. It also correlates which Calico versions best pair with your Kubernetes version—helping avoid combos that break key features like network policy or eBPF data-plane. If you're on a release series with known vulnerabilities or performance problems, Chkk flags a safer, more stable upgrade target. You can rely on this guidance to plan proactive upgrades, rather than reacting to urgent CVEs or operator surprises. This keeps clusters secure while ensuring the networking stack remains aligned with upstream support.
### Upgrade Templates
Chkk provides step-by-step templates for Calico upgrades tailored to each packaging method (Helm, operator, or manifest). You can choose in-place updates, which automatically roll out new DaemonSet pods, or a blue-green approach that deploys a parallel Calico version before switching traffic. Each template includes recommended pre-upgrade tasks like snapshotting CRDs, verifying BGP sessions, or ensuring no IP pool exhaustion. Chkk also outlines rollback points in case new configurations create unexpected connectivity issues. This workflow reduces guesswork and ensures a consistent, repeatable upgrade process.
### Preverification
Before rolling changes to production, Chkk tests the entire Calico upgrade in a controlled environment or via dry-run checks. It simulates applying the new CRDs, verifying network policies, and updating calico-node on a subset of nodes. If any conflicts arise—like unsupported config parameters or IP pool overlaps—Chkk flags them early so you can adjust. This "practice run" is especially valuable when enabling advanced features like eBPF or altering core networking modes. By catching issues ahead of time, preverification minimizes downtime and operational surprises.
### Supported Packages
Chkk supports all major Calico installation methods: Helm, operator-based installs, and direct manifests. It respects your existing GitOps or CI/CD workflows and makes minimal, targeted changes to upgrade manifests or chart values. That means your custom images, private registries, and any additional patches remain intact after an upgrade. Even if you switch between manifest-based and operator-based management, Chkk tracks your resources consistently across the lifecycle. This flexibility helps you standardize Calico lifecycle tasks alongside other cluster components.
## Common Operational Considerations
* **BGP Peering Failures:** If you're using Calico in BGP mode, ensure node IP autodetection is correct and TCP port 179 is open between all peers. Misconfigured ASNs, firewall restrictions, or missing route reflectors can disrupt peering sessions and lead to traffic blackholes.
* **IP Pool Exhaustion:** Large or dense clusters can quickly run out of available pod IP addresses when IP pools are too small or fragmented. Adding new pools, increasing block sizes, or enabling IPAM garbage collection helps maintain a healthy pool allocation.
* **eBPF Mode Stability:** Calico's eBPF data plane can boost throughput and reduce latency, but it requires a modern Linux kernel (5.3+ recommended) and does not support IP-in-IP. Thorough testing is essential to confirm kernel compatibility and ensure stable operation under real workloads.
* **Scaling (Large Clusters):** For clusters above 100 nodes, deploying Typha reduces load on the datastore by batching updates to calico-node. Monitoring Typha's resource usage and ensuring sufficient capacity for policy processing are key to preventing performance bottlenecks.
* **Multi-Cluster Networking:** Calico supports cluster mesh for cross-cluster communication via BGP or overlay tunnels, but each cluster must have unique IP pools and correct route exports. Careful coordination of routes, policies, and potential IP pool overlaps is crucial to avoid connectivity conflicts.
* **Policy Enforcement Pitfalls:** Calico's network policies default to a deny-all stance once any policy is applied, requiring explicit allow rules for essential traffic like DNS. Overlapping global or tiered policies can override local settings, making periodic policy audits important for consistent security.
## Additional Resources
* [Calico Documentation](https://docs.tigera.io/)
* [Calico Releases](https://github.com/projectcalico/calico/releases)
# Calico Operator
Source: https://docs.chkk.io/projects/calico-operator
Chkk coverage for Calico Operator. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v3.2.8"
export const ChecksMinVer_0 = "v3.23.1"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Calico Operator Overview
Calico is an open-source Cloud Native networking and security solution that provides high-performance pod networking and policy enforcement. The Tigera Calico Operator simplifies Calico management through a declarative CRD-based interface, automating BGP peering, IP pool management, and policy lifecycles. Calico supports multiple dataplanes, including standard Linux networking, overlay modes (VXLAN, IP-in-IP), and advanced eBPF acceleration. It enables robust zero-trust network segmentation using NetworkPolicy and Calico's GlobalNetworkPolicy resources. The operator-driven approach reduces manual intervention, ensuring consistent configuration and seamless upgrades.
## Chkk Coverage
### Curated Release Notes
Chkk delivers curated summaries of official Calico Operator releases, highlighting impactful changes like IP pool updates, BGP enhancements, security fixes, and critical CRD modifications. Instead of reviewing extensive upstream notes, platform engineers receive targeted alerts relevant to their deployments. For instance, if default IP pool settings or global policy handling change, Chkk clearly explains the operational implications, allowing proactive adjustments ahead of upgrades. This reduces risks during upgrades and prevents unforeseen networking disruptions.
### Preflight & Postflight Checks
Chkk conducts thorough preflight validations before Calico upgrades, confirming Kubernetes version compatibility, CRD correctness, and absence of risky configurations like overlapping IP pools or deprecated fields. Postflight checks verify the health and consistency of Calico nodes, network policies, and pod connectivity immediately after upgrades. This proactive approach swiftly identifies lingering nodes or incomplete rollouts, reducing troubleshooting overhead. Such rigorous validation ensures seamless upgrades and maintains network stability.
### Version Recommendations
Chkk continuously tracks Calico's lifecycle, alerting platform teams when deployed versions near end-of-life or critical updates become available. It offers context-specific guidance tailored to compatibility and operational considerations. Recommendations highlight known risks, like dropping security patch support or significant BGP bug fixes, and suggest stable upgrade targets backed by community feedback. This guidance ensures environments remain secure, stable, and supported without unnecessary disruptions.
### Upgrade Templates
Chkk provides detailed Upgrade Templates for both in-place upgrades and blue-green deployments. In-place upgrades utilize a controlled rollout strategy, updating nodes incrementally to minimize disruption. Blue-green templates deploy parallel Calico installations, enabling controlled workload migration and extensive testing before full transition. Templates integrate seamlessly with GitOps/CI-CD workflows, reducing human error and enabling predictable, safe upgrades.
### Preverification
Chkk's preverification feature rehearses upgrades in an isolated "digital twin" cluster replicating production Calico configurations. This process uncovers potential issues such as CRD conflicts, IP pool overlaps, and resource constraints before affecting production. By simulating real-world upgrades, platform engineers can proactively resolve issues identified during rehearsals. Preverification significantly reduces upgrade risks, ensuring smooth transitions in live environments.
### Supported Packages
Chkk supports Calico installations via the official operator, Helm charts, Operator Lifecycle Manager (OLM), or direct YAML manifests. It fully respects custom configurations, private registries, and vendor-specific builds without forcing workflow changes. If using GitOps for Calico manifests, Chkk precisely identifies required updates, preserving custom resources and minimizing disruption. This flexibility ensures consistent upgrades regardless of deployment method.
## Additional Resources
* [Calico Operator Documentation](https://docs.tigera.io/)
* [Calico Operator Releases](https://github.com/projectcalico/calico/releases)
# Data Jobs Projects
Source: https://docs.chkk.io/projects/categories/data-jobs
Explore All the Data Jobs Projects Chkk Covers
These Projects are responsible for scheduling, orchestrating, and scaling batch processing,
ETL pipelines, and machine learning workloads, including workflow engines and autoscalers
that respond to event-driven or time-based triggers.
Get a quick overview of every Project Chkk covers, complete with
curated release notes, private registry and custom image coverage, pre- and
post-flight checks, and comprehensive EOL and version compatibility details.
Dive deeper into each Project to see supported upgrade templates
(in-place, blue-green) and preverification. Simply select a card below to learn
more about that specific Project.
| | | |
| ------------------------------------------ | -------------- | ------- |
| [Argo Workflows](/projects/argo-workflows) | Apache Airflow | Jenkins |
| Spark Operator | Ververica | |
# Data Streams Projects
Source: https://docs.chkk.io/projects/categories/data-streams
Explore All the Data Streams Projects Chkk Covers
These Projects are responsible for delivering high-throughput, low-latency messaging
for real-time data movement, enabling publish/subscribe patterns, event-driven architectures,
and stream processing pipelines.
Get a quick overview of every Project Chkk covers, complete with
curated release notes, private registry and custom image coverage, pre- and
post-flight checks, and comprehensive EOL and version compatibility details.
Dive deeper into each Project to see supported upgrade templates
(in-place, blue-green) and preverification. Simply select a card below to learn
more about that specific Project.
| | | |
| ---------------------------------------------- | ---------------------------------------------- | -------------------------------------------------------------- |
| [Apache Kafka](/projects/apache-kafka) | [Apache Zookeeper](/projects/apache-zookeeper) | [Confluent Platform Kafka](/projects/confluent-platform-kafka) |
| [Knative Eventing](/projects/knative-eventing) | [RabbitMQ](/projects/rabbitmq) | Argo Events |
| NATS | Strimzi Kafka Operator | |
# Databases & Datastores Projects
Source: https://docs.chkk.io/projects/categories/databases-and-datastores
Explore All the Databases & Datastores Projects Chkk Covers
These Projects are responsible for storing, replicating, and serving application data,
including relational and NoSQL engines, in-memory caches, search indexes, and the platforms
or orchestration layers that provide persistent block, file, or object storage.
Get a quick overview of every Project Chkk covers, complete with
curated release notes, private registry and custom image coverage, pre- and
post-flight checks, and comprehensive EOL and version compatibility details.
Dive deeper into each Project to see supported upgrade templates
(in-place, blue-green) and preverification. Simply select a card below to learn
more about that specific Project.
| | | |
| ------------------------------------------------------ | ------------------------------------ | ------------------------------------------ |
| [Clickhouse Operator](/projects/clickhouse-operator) | [CockroachDB](/projects/cockroachdb) | [MinIO Operator](/projects/minio-operator) |
| [PgBouncer](/projects/pgbouncer) | [PostgreSQL](/projects/postgresql) | [Redis](/projects/redis) |
| ACK S3 Controller | Adminer | Amazon EBS CSI Driver |
| Amazon EFS CSI Driver | Apache Cassandra | Apache Cassandra Reaper |
| Azure Disk CSI Driver | CSI External Attacher | CSI External Provisioner |
| CSI External Resizer | CSI External Snapshotter | CSI Liveness Probe |
| CSI Node Driver Registrar | etcd | GCP Cloud SQL Auth Proxy |
| Google Compute Engine (GCE) Persistent Disk CSI Driver | GCP Filestore CSI Driver | GCP GCS FUSE CSI Driver |
| Longhorn | Meilisearch | MinIO |
| MongoDB | MySQL | Mountpoint for AWS S3 CSI Driver |
| OpenEBS | Portworx | Portworx Operator |
| Rook | Spilo | |
# Network & Connectivity Projects
Source: https://docs.chkk.io/projects/categories/networking-and-connectivity
Explore All the Network & Connectivity Projects Chkk Covers
These Projects are responsible for managing how traffic flows within and between systems,
handling network routing, load balancing, service discovery, ingress/egress, and API
gateway functions to ensure reliable and secure communication.
Get a quick overview of every Project Chkk covers, complete with
curated release notes, private registry and custom image coverage, pre- and
post-flight checks, and comprehensive EOL and version compatibility details.
Dive deeper into each Project to see supported upgrade templates
(in-place, blue-green) and preverification. Simply select a card below to learn
more about that specific Project.
| | | |
| ------------------------------------------------- | ------------------------------------------------------ | -------------------------------------------------------------- |
| [Amazon VPC CNI Plugin](/projects/amazon-vpc-cni) | [Calico](/projects/calico) | [Calico Operator](/projects/calico-operator) |
| [Cilium](/projects/cilium) | [Cilium Operator](/projects/cilium-operator) | [Cloudflared](/projects/cloudflared) |
| [Contour](/projects/contour) | [CoreDNS](/projects/coredns) | [External DNS](/projects/external-dns) |
| [Gloo Edge OSS](/projects/gloo-edge-oss) | [Hashicorp Consul OSS](/projects/hashicorp-consul-oss) | [Ingress NGINX Controller](/projects/ingress-nginx-controller) |
| [Istio](/projects/istio) | [Kong Gateway OSS](/projects/kong-gateway-oss) | [kube-proxy](/projects/kube-proxy) |
| Ambassador Edge Stack | Antrea | Apache HTTP Server |
| Apollo Router | AWS Load Balancer Controller | AWS Network Policy Agent |
| Azure IP Masquerade Agent | Azure Network Policy Manager | Buoyant Enterprise for Linkerd |
| Envoy Proxy | GKE Egress NAT Controller | Gloo Edge Enterprise |
| Ingress GCE Controller | Istio CNI Node Agent | Kong Ingress Controller |
| kube-vip | Kubernetes DNS | Linkerd OSS |
| MetalLB | netd | NGINX |
| NodeLocal DNS Cache | Traefik | Tailscale |
| Thanos | Varnish Cache | |
# Node Lifecycle & AutoScaling Projects
Source: https://docs.chkk.io/projects/categories/node-lifecycle-and-autoscaling
Explore All the Node Lifecycle & AutoScaling Projects Chkk Covers
These Projects are responsible for managing the provisioning, scaling, updating,
and maintenance of compute resources, tuning performance, handling upgrades,
and ensuring capacity matches demand.
Get a quick overview of every Project Chkk covers, complete with
curated release notes, private registry and custom image coverage, pre- and
post-flight checks, and comprehensive EOL and version compatibility details.
Dive deeper into each Project to see supported upgrade templates
(in-place, blue-green) and preverification. Simply select a card below to learn
more about that specific Project.
| | | |
| ---------------------------------------------------------------------- | -------------------------------------------------- | ------------------------------------------------------------ |
| [Bottlerocket Update Operator](/projects/bottlerocket-update-operator) | [Cluster Autoscaler](/projects/cluster-autoscaler) | [Karpenter](/projects/karpenter) |
| [KEDA](/projects/keda) | [kube-green](/projects/kube-green) | [Vertical Pod Autoscaler](/projects/vertical-pod-autoscaler) |
| Addon Resizer | AWS Node Termination Handler | Azure Cloud Node Manager |
| Cluster Proportional Autoscaler | Cluster Proportional Vertical Autoscaler | GKE TPU Device Plugin |
| Inspektor Gadget | Kured | Node Feature Discovery |
| Nvidia Device Plugin for Kubernetes | Nvidia GPU Operator | OneAgent |
| Velero | | |
# Observability & Monitoring Projects
Source: https://docs.chkk.io/projects/categories/observability-and-monitoring
Explore All the Observability & Monitoring Projects Chkk Covers
These Projects are responsible for collecting, processing, and visualizing metrics,
logs, and traces, helping teams detect issues, analyze system behavior, and track
performance, availability, and cost.
Get a quick overview of every Project Chkk covers, complete with
curated release notes, private registry and custom image coverage, pre- and
post-flight checks, and comprehensive EOL and version compatibility details.
Dive deeper into each Project to see supported upgrade templates
(in-place, blue-green) and preverification. Simply select a card below to learn
more about that specific Project.
| | | |
| ------------------------------------------------------------ | ---------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| [Alertmanager](/projects/alertmanager) | [Datadog Agent](/projects/datadog-agent) | [Datadog Operator](/projects/datadog-operator) |
| [Dynatrace Operator](/projects/dynatrace-operator) | [Elasticsearch](/projects/elasticsearch) | [Elasticsearch (ECK) Operator](/projects/eck-operator) |
| [FluentBit](/projects/fluent-bit) | [Grafana](/projects/grafana) | [Grafana Loki](/projects/grafana-loki) |
| [kube-state-metrics](/projects/kube-state-metrics) | [Kubernetes Metrics Server](/projects/kubernetes-metrics-server) | [Prometheus](/projects/prometheus) |
| [Prometheus Adapter](/projects/prometheus-adapter) | [Prometheus Blackbox Exporter](/projects/prometheus-blackbox-exporter) | [Prometheus Cloudwatch Exporter](/projects/prometheus-blackbox-exporter) |
| [Prometheus JMX Exporter](/projects/prometheus-jmx-exporter) | [Prom2Teams](/projects/prom2teams) | Active Monitor |
| Azure Monitor | cAdvisor | Elastic Beats (Filebeat, Metricbeat) |
| FluentBit GKE Exporter | Fluentd | Fluentd Plugin Splunk HEC |
| GCP Prometheus Engine | GKE Events Exporter | GKE Metadata Server |
| GKE Metrics Agent | GKE Metrics Collector | GKE Stackdriver Logging Agent |
| Grafana Agent | Kubecost | OpenTelemetry (OTEL) Operator |
| Prometheus Node Exporter | Prometheus Operator | Prometheus PostgreSQL Exporter |
| Prometheus Operator | Prometheus PostgreSQL Exporter | Prometheus Redis Metrics Exporter |
| Splunk OpenTelemetry (OTEL) Collector | Sumo Logic Distribution for OpenTelemetry Collector | Vector |
# Platform Ops & Developer Tooling Projects
Source: https://docs.chkk.io/projects/categories/platform-ops-and-developer-tooling
Explore All the Platform Ops & Developer Tooling Projects Chkk Covers
These Projects are responsible for supporting platform engineering and developer
productivity with dashboards, CI/CD and GitOps tooling, application rollout
controllers, and utilities that enhance application delivery and operations.
Get a quick overview of every Project Chkk covers, complete with
curated release notes, private registry and custom image coverage, pre- and
post-flight checks, and comprehensive EOL and version compatibility details.
Dive deeper into each Project to see supported upgrade templates
(in-place, blue-green) and preverification. Simply select a card below to learn
more about that specific Project.
| | | |
| ---------------------------------- | -------------------------------------------- | ------------------------------------------------------ |
| [Argo CD](/projects/argo-cd) | [Argo Rollouts](/projects/argo-rollouts) | [Bitbucket](/projects/bitbucket) |
| [Botkube](/projects/botkube) | [Chaos Mesh](/projects/chaos-mesh) | [Crossplane](/projects/crossplane) |
| [Directus](/projects/directus) | [jsreport](/projects/jsreport) | [Kafka UI](/projects/kafka-ui) |
| [Kargo](/projects/kargo) | [Kiali](/projects/kiali) | [Kiali Operator](/projects/kiali-operator) |
| [Kibana](/projects/kibana) | [Knative Serving](/projects/knative-serving) | [Kubernetes Dashboard](/projects/kubernetes-dashboard) |
| Actions Runner Controller | Atlassian Jira | Edge Delta |
| Flagger | FluxCD | Harbor |
| Harness Delegate | JFrog Artifactory | Kubernetes Dashboard Metrics Scraper |
| Kubeshark | Rancher Fleet | Redpanda Console |
| SonarQube | Stakater Reloader | Telepresence |
| Upbound Universal Crossplane (UXP) | | |
# Security & IAM Projects
Source: https://docs.chkk.io/projects/categories/security-and-iam
Explore All the Security & IAM Projects Chkk Covers
These Projects are responsible for protecting workloads through policy enforcement,
certificate and secret management, vulnerability scanning, and identity or access
control, including authentication and authorization systems.
Get a quick overview of every Project Chkk covers, complete with
curated release notes, private registry and custom image coverage, pre- and
post-flight checks, and comprehensive EOL and version compatibility details.
Dive deeper into each Project to see supported upgrade templates
(in-place, blue-green) and preverification. Simply select a card below to learn
more about that specific Project.
| | | |
| ---------------------------------------- | -------------------------------------------------------------------- | ------------------------------------------------ |
| [cert-manager](/projects/cert-manager) | [Cloudflare Origin CA Issuer](/projects/cloudflare-origin-ca-issuer) | [Connaisseur](/projects/connaisseur) |
| [Dex](/projects/dex) | [External Secrets Operator](/projects/external-secrets-operator) | [Hashicorp Vault](/projects/hashicorp-vault) |
| [JFrog Xray](/projects/jfrog-xray) | [Keycloak](/projects/keycloak) | [Keycloak Operator](/projects/keycloak-operator) |
| [Kyverno](/projects/kyverno) | [Ory Hydra](/projects/ory-hydra) | [Pomerium](/projects/pomerium) |
| [Prisma Cloud](/projects/prisma-cloud) | [Vault Secrets Operator](/projects/vault-secrets-operator) | ACK IAM Controller |
| Azure Active Directory Workload Identity | Azure Key Vault Provider for Secrets Store CSI Driver | Azure Key Vault to Kubernetes |
| Google CAS Issuer for Cert Manager | Hashicorp Vault Agent Injector | Istio CSR |
| Kube RBAC Proxy | Kubernetes External Secrets | Kubernetes Reflector |
| Kubernetes Replicator | Kubernetes Secret Generator | Secrets Store CSI Driver |
| Kyverno Policy Reporter | Nevis | OAuth2 Proxy |
| Open Policy Agent | Open Policy Agent Gatekeeper | Sealed Secrets |
| Step Issuer | Teleport | Trivy |
| Trivy Operator | Trust Manager | Wiz Runtime Sensor |
# cert-manager
Source: https://docs.chkk.io/projects/cert-manager
Chkk coverage for cert-manager. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
export const ReleaseNotesMinVer_0 = "v0.14.3"
export const ChecksMinVer_0 = "v1.1.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## cert-manager Overview
cert-manager is a Cloud Native Project that automates issuing and renewing TLS certificates for your workloads. It integrates with multiple CAs (including ACME providers like Let's Encrypt) to streamline certificate requests and validation. The project provides CRDs for defining issuers and certificates, along with a webhook for enforcing policy. By continuously monitoring and renewing certificates before they expire, cert-manager significantly reduces manual overhead. With proper resource tuning, it scales in both small and large clusters.
## Chkk Coverage
### Curated Release Notes
Chkk tracks cert-manager release notes to highlight new features, breaking changes, or CRD updates relevant to your environment. It alerts you to shifts like a renamed API group or removed fields so you can adapt configurations before upgrading. Each curated summary points to potential operational impacts, saving teams from combing through long changelogs. You stay focused on what matters, avoiding unexpected downtime.
### Preflight & Postflight Checks
Chkk's preflight checks validate Kubernetes version, CRDs, and webhook readiness before any cert-manager upgrade. They also spot deprecated API usage that could fail in the new release. Postflight checks confirm healthy controller pods, functioning webhooks, and successful certificate issuance after the upgrade. This ensures certificate renewals continue uninterrupted. By quickly catching anomalies, teams can address issues early with Chkk.
### Version Recommendations
Chkk continuously tracks cert-manager's support timeline and flags EOL risks or security patches for your version. It factors in compatibility to help you pick stable, fully-supported releases. Alerts arrive well before your version becomes unsafe or unmaintained. You also get suggestions on the best minor version to minimize breakage. By following these recommendations, you stay ahead of critical updates.
### Upgrade Templates
Chkk provides step-by-step templates for either in-place or blue-green cert-manager upgrades. In-place workflows update CRDs and the controller in sequence, while blue-green approaches deploy a parallel cert-manager instance before switching over. Both methods include rollback points and checks to ensure healthy certificate issuance. Automation is straightforward via Helm, Kustomize, or kubectl. Each template simplifies the overall upgrade experience.
### Preverification
Chkk can simulate each cert-manager upgrade in a test environment to identify issues early. It applies your Issuer and Certificate configurations, runs the new controller, and checks for ACME or webhook errors. This dry-run approach lets you fix problems before rolling out to production. By validating your exact setup, preverification reduces downtime risk. Quick feedback loops give you confidence for a trouble-free upgrade.
## Common Operational Considerations
* **Webhook Availability & Readiness:** The cert-manager webhook must be reachable by the API server to approve certificate-related custom resources. Downtime or misconfiguration can halt certificate issuance across the cluster.
* **ACME Challenges:** Ensure proper DNS and ingress settings for HTTP-01 or DNS-01 challenge methods. Misconfigurations can cause certificates to remain pending or fail to renew.
* **Certificate Expiration Monitoring:** cert-manager auto-renews certificates, but it's critical to monitor expiring certificates and observe renewal events. Prompt alerts prevent overlooked renewals and outage risks.
* **Issuer & CA Rotation:** Rotating CAs or issuers requires re-issuing certificates with the new trust chain. Plan overlapping trust windows and verify the new CA is correctly propagated to workloads.
* **Performance Tuning:** Large volumes of certificates can strain the controller. Allocate adequate CPU/memory, monitor queue lengths, and scale replicas if issuance throughput is impacted.
## References
* [cert-manager Documentation](https://cert-manager.io/docs/)
* [cert-manager Releases](https://github.com/cert-manager/cert-manager/releases)
# Chaos Mesh
Source: https://docs.chkk.io/projects/chaos-mesh
Chkk coverage for Chaos Mesh. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v2.2.0"
export const ChecksMinVer_0 = "v2.1.7"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Chaos Mesh Overview
Chaos Mesh is an open-source chaos engineering tool enabling controlled fault injections like pod crashes, network latency, and resource stress tests. It orchestrates chaos experiments via CustomResourceDefinitions (CRDs) and controllers, allowing realistic resilience testing. Chaos Mesh uses a central controller manager and node-level Chaos Daemon agents (privileged DaemonSets) to manage experiment execution. Its user-friendly Chaos Dashboard simplifies experiment design and impact analysis, facilitating adoption across engineering teams.
## Chkk Coverage
### Curated Release Notes
Chkk continuously tracks Chaos Mesh releases, highlighting significant operational changes such as CRD updates, compatibility adjustments, or feature enhancements affecting your environment. Important release impacts—like mandatory CRD migrations or dropped Kubernetes version support—are clearly flagged. This ensures teams anticipate and smoothly integrate necessary adjustments into their upgrade planning. Chkk's targeted summaries eliminate the need to manually parse extensive upstream release notes, allowing rapid identification of critical operational considerations.
### Preflight & Postflight Checks
Chkk executes preflight checks before upgrading Chaos Mesh, verifying compatibility, CRD readiness, and proper permissions for Chaos Daemon components. These checks detect issues like incompatible upgrade paths or deprecated experiment definitions, preventing operational disruptions. Postflight checks confirm successful upgrades by ensuring the health of Chaos Controller Manager and Daemon pods, verifying proper communication, and validating running experiments. This structured validation quickly identifies potential upgrade issues, ensuring consistency in chaos experiment operations.
### Version Recommendations
Chkk closely monitors Chaos Mesh's supported version timelines, proactively alerting teams when deployed versions approach end-of-life or require Kubernetes version alignment. Recommendations include stable upgrade targets informed by community feedback and known operational issues, balancing new functionality and stability. By clearly articulating version risks and compatibility, Chkk enables platform engineers to maintain compliant and operationally effective Chaos Mesh installations. Custom version policies or forked builds can also be accommodated, aligning upgrade paths with unique organizational requirements.
### Upgrade Templates
Chkk provides detailed Chaos Mesh Upgrade Templates for both in-place and blue-green strategies, capturing project-recommended best practices. Templates offer structured, step-by-step upgrade paths with integrated checkpoints and rollback instructions, compatible with Helm and manifest-based deployments. Although upstream recommends pausing active experiments during any upgrade, Chkk's Blue-green guidance targets cluster-level cut-overs: you bring up the new Chaos Mesh version in a parallel green cluster, validate it, then migrate experiments and workloads. This structured upgrade approach integrates seamlessly into GitOps and CI/CD workflows, significantly reducing operational risk.
### Preverification
Chkk's preverification process simulates Chaos Mesh upgrades in isolated environments, identifying issues such as schema conflicts or insufficient resource allocations before production deployment. By recreating realistic cluster configurations and experiments, preverification ensures any critical issues surface early, avoiding live disruptions. Common problems, like stricter CRD validations or newly required privileges, are caught and resolved in advance. Incorporating preverification into upgrade workflows provides platform engineers greater confidence and stability during live upgrades.
### Supported Packages
Chkk supports multiple Chaos Mesh installation methods, including Helm charts and direct YAML manifests. Custom images, private registries, and tailored builds are fully supported, ensuring seamless consistency during upgrades. Chkk analyzes existing configuration-as-code manifests or Helm values files, recommending precise, minimal changes required for upgrades. This comprehensive support enables Chaos Mesh upgrades within familiar operational frameworks without disrupting established workflows.
## Common Operational Considerations
* **Experiment Selector Precision:** Ensure chaos experiments have narrowly defined selectors to prevent unintended impacts. Broad selectors can inadvertently disrupt critical infrastructure or essential services.
* **Controller-Daemon Connectivity:** Verify network policies and permissions allow controller-manager communication with chaos-daemons. Misconfigurations can cause failures in applying chaos experiments.
* **RBAC in Managed Environments:** Set explicit RBAC roles for Chaos Mesh operations, especially in managed Cloud Native environments like GKE. Improper permissions can silently block chaos experiments.
* **Pod Security Constraints:** Allow required privileged operations in restrictive environments (e.g., OpenShift's SCC) by adjusting security contexts specifically for Chaos Mesh components. Restrictive security settings can prevent chaos experiments from executing.
* **CRI and Kernel Compatibility:** Ensure container runtimes and kernel versions align with Chaos Mesh requirements. Mismatches can cause injection errors or failures in chaos-daemon functionality.
* **Scaling and Performance:** Monitor Chaos Mesh resource usage in large clusters or intensive experiment scenarios. Allocate appropriate resources to prevent API server overload and ensure smooth operational performance.
## Additional Resources
* [Chaos Mesh Documentation](https://chaos-mesh.org/docs/)
* [Chaos Mesh Releases](https://github.com/chaos-mesh/chaos-mesh/releases)
# Cilium
Source: https://docs.chkk.io/projects/cilium
Chkk coverage for Cilium. We provide curated release notes, preflight/postflight checks, and Upgrade Templates—all tailored to your environment.
export const ReleaseNotesMinVer_0 = "v1.7.0"
export const ChecksMinVer_0 = "v1.10.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Cilium Overview
Cilium is a Cloud Native networking and security solution that uses eBPF (Extended Berkeley Packet Filter) to dynamically program the Linux kernel. By doing so, it achieves highly efficient network routing, identity-aware policy enforcement, and fine-grained observability through Hubble. This approach avoids the overhead of traditional iptables-based CNIs, delivering better performance at scale. With Cilium, platform teams can seamlessly enforce zero-trust policies, enable transparent encryption of pod-to-pod traffic, and gain deep insights into network flows without needing application-level instrumentation.
## Chkk Coverage
### Curated Release Notes
Chkk tracks official Cilium release notes and distills them into briefings that highlight key updates, new features, security advisories, and deprecations. Rather than sifting through every upstream change, you get a concise overview of what has changed and how it might affect your clusters. For example, if Cilium removes the deprecated `cidrs` field from the `CiliumLoadBalancerIPPool` CRD, Chkk flags any IP pool definitions still using that field and helps you transition to the new `blocks` syntax before it impacts IP allocation.
### Preflight & Postflight Checks
Before upgrading Cilium, Chkk runs preflight checks to verify kernel capabilities, ensure your Kubernetes version is compatible, and identify any usage of deprecated APIs. It validates that key components like Hubble, Cilium DaemonSet configurations, and network policies meet the new version's requirements. After the upgrade, postflight checks confirm your pods are using the correct Cilium agents, check for datapath errors, and ensure that all cluster nodes remain reachable. This extra validation step catches issues (e.g., resource constraints or leftover pods on outdated sidecar versions) that might otherwise cause intermittent downtime.
### Version Recommendations
Chkk continuously monitors the Cilium support matrix, pointing out when your current version is nearing EOL or has known issues impacting stability. By cross-referencing upstream release notes and compatibility, it suggests stable upgrade targets that reduce risk. Instead of blindly picking the newest release, operators can rely on Chkk's recommendations for a version that aligns with long-term support guidelines, ensuring you maintain a secure and reliable platform.
### Upgrade Templates
Chkk provides two main upgrade paths for Cilium: in-place and blue-green. With an in-place upgrade, the existing Cilium DaemonSet is updated sequentially across all nodes. This minimalistic approach is straightforward but demands careful monitoring to avoid disruption. The blue-green method, on the other hand, stands up a second Cilium deployment in parallel. Operators can progressively migrate workloads to the new version, verifying stability before retiring the old. Chkk's templates for both approaches define step-by-step commands, rollback options, and best practices—helping to minimize downtime if an unexpected issue arises mid-upgrade.
### Preverification
For major Cilium upgrades or large multi-cluster environments, Chkk's preverification feature offers a risk-free way to test changes. It spins up a temporary environment mirroring your current configuration—complete with your Cilium CustomResourceDefinitions, network policies, and Hubble settings—and applies the new Cilium version. The simulator checks for configuration conflicts, resource bottlenecks, or datapath issues triggered by new eBPF features. This helps ensure that the real upgrade will roll out smoothly, saving you from surprises in production.
### Supported Packages
Chkk integrates seamlessly with whatever installation method you use—Helm, Kustomize, or plain manifests—so you can continue managing Cilium in your existing GitOps or CI/CD pipelines. It also supports private registries and custom-built images, ensuring you maintain consistency with your organization's security and compliance mandates. Whether you apply a standard Helm chart or maintain your own patched Cilium container images, Chkk can parse your manifests or values files, detect your current version, and propose an optimized upgrade plan.
## Common Operational Considerations
* **Gradual Node Upgrades:** Avoid upgrading all nodes simultaneously; instead, update Cilium on a subset of nodes, validate performance, then proceed to the rest.
* **Preserve Custom Configurations:** If you have custom Helm values or YAML overrides for encryption, policy settings, or L7 proxies, merge those carefully when moving to a new chart or manifest.
* **Kernel & eBPF Requirements:** Verify that your kernel version includes the eBPF features required by the new release. Missing modules or too-strict sysctl settings can cause failures in Cilium's datapath.
* **Policy Testing:** After each upgrade, test ingress and egress rules to confirm enforcement. Subtle changes in how Cilium interprets policy CRDs can disrupt traffic if you rely on advanced features like L7 filtering.
* **Hubble Observability:** Watch Hubble flows and metrics for anomalies. If flow logs suddenly drop or specific flows are denied, it may indicate CRD or agent misconfigurations post-upgrade.
* **Track Resource Usage:** Large-scale clusters running eBPF programs can stress node resources. Monitor CPU and memory usage on worker nodes, especially if you enable additional Cilium features like kube-proxy replacement.
## Additional Resources
* [Cilium Documentation](https://docs.cilium.io/en/stable/)
* [Cilium Releases](https://github.com/cilium/cilium/releases)
* [Hubble UI Documentation](https://docs.cilium.io/en/stable/observability/hubble/hubble-ui/index.html)
# Cilium Operator
Source: https://docs.chkk.io/projects/cilium-operator
Chkk coverage for Cilium Operator. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v1.11.10"
export const ChecksMinVer_0 = "v1.12.8"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Cilium Operator Overview
Cilium provides Kubernetes clusters with efficient networking, security, and observability using eBPF technology embedded in the Linux kernel. It enables identity-based network policies, fine-grained control, and layer 7 visibility directly at the kernel level. The Cilium Operator complements node-level Cilium agents by managing global tasks such as IP address assignment, identity cleanup, and distributing network policy updates. Its central role simplifies cluster-wide networking management without per-application changes. The integrated Hubble component offers real-time observability into network flows and policy enforcement, facilitating streamlined troubleshooting.
## Chkk Coverage
### Curated Release Notes
Chkk monitors official Cilium Operator releases, highlighting critical changes like deprecated APIs or altered defaults directly impacting your clusters. Teams receive concise summaries pinpointing actions needed for smooth upgrades, avoiding manual parsing of extensive release logs. Chkk specifically flags configuration shifts, such as IP masquerading defaults or kernel version requirements, to prevent unanticipated disruptions. This focused approach ensures operational teams address only relevant, actionable changes in their networking setups.
### Preflight & Postflight Checks
Chkk's preflight checks ensure your environment meets prerequisites, verifying kernel versions, resource availability, and deprecated CRD usage before upgrades. It flags risky upgrade paths, such as skipping multiple versions, mitigating potential failures. Post-upgrade, Chkk confirms that the new Cilium Operator components function correctly by validating agent health, IP assignments, policy enforcement, and connectivity. Immediate reporting on issues like kernel incompatibilities or misconfigured settings significantly reduces upgrade-related incidents.
### Version Recommendations
Chkk actively tracks Cilium Operator’s lifecycle, alerting when your deployed version approaches or surpasses end-of-life status, crucial for maintaining security compliance. Recommendations incorporate cluster-specific details, like cluster and kernel compatibility, guiding you toward stable and supported upgrade targets. This strategic approach prevents inadvertent adoption of untested releases, balancing feature updates against operational risk. Custom EOL policies for forked or enterprise distributions can also be integrated into Chkk’s recommendations.
### Upgrade Templates
Chkk provides detailed Upgrade Templates for both in-place and blue-green strategies tailored to Cilium deployments. In-place templates guide node-by-node upgrades with integrated checks and clear rollback procedures to minimize disruptions. Blue-green templates offer parallel deployments, facilitating gradual traffic migration with defined validation checkpoints. These GitOps-compatible templates encapsulate best practices, significantly reducing human error during upgrades.
### Preverification
Chkk conducts simulated "digital twin" upgrades, replicating your production cluster’s environment to proactively identify issues like CRD conflicts, kernel incompatibilities, or policy misconfigurations. Issues surface safely within this sandbox environment, allowing resolution before impacting live traffic. Detailed anomaly reports from preverification guide configuration adjustments, making actual upgrades predictable and reliable. This rehearsal significantly reduces risk and enhances upgrade confidence for platform teams.
### Supported Packages
Chkk seamlessly integrates with your existing Cilium Operator deployment methods, including Helm charts, static manifests, and GitOps workflows. It accurately identifies and adapts to your custom image setups and private registry configurations. Chkk parses current manifests, pinpointing only necessary configuration changes for a successful upgrade. Its flexible compatibility ensures consistent Cilium Operator management across diverse deployment scenarios, including enterprise-specific distributions.
## Additional Resources
* [Cilium Operator Documentation](https://docs.cilium.io/en/stable/)
* [Cilium Operator Releases](https://github.com/cilium/cilium/releases)
# Clickhouse Operator
Source: https://docs.chkk.io/projects/clickhouse-operator
Chkk coverage for Clickhouse Operator. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v0.18.5"
export const ChecksMinVer_0 = "v0.23.2"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## ClickHouse Operator Overview
ClickHouse Operator is an open-source controller for managing ClickHouse clusters declaratively. It provides storage, services, and configs from Custom Resources and automates day-2 ops such as rolling upgrades, scaling, and user management. Built-in Prometheus exporters expose database metrics, while optional ZooKeeper / ClickHouseKeeper integration enables high-availability replication. By centralizing these tasks, the operator enforces consistent configs and removes the need for bespoke scripts.
## Chkk Coverage
### Curated Release Notes
Chkk filters official ClickHouse Operator release notes, surfacing only changes that can impact your clusters. It flags new CR fields, deprecated options, and behavioral shifts—such as the 0.24.0 ClickHouseKeeper overhaul—so you can prepare in advance. Contextual summaries save you from parsing every upstream commit.
### Preflight & Postflight Checks
Before an upgrade, Chkk’s preflight checks verify cluster and ClickHouse versions, validates CRDs, and scans existing ClickHouseInstallation manifests for deprecated fields. It ensures required CRD are updated first, preventing reconciliation errors. After the upgrade, Chkk’s postflight checks confirm the operator pod is healthy, CHI resources reconcile, and no ClickHouse pods crash or stall. Rapid feedback lets you remediate while the change window is still open.
### Version Recommendations
Chkk tracks the operator’s release and support timeline, warning when your version nears end-of-life or misses critical fixes. It cross-checks compatibility with your Kubernetes version and ClickHouse server build. Guidance includes a stable target version plus the risks of staying put, helping you weigh security patches against upgrade effort.
### Upgrade Templates
Upgrade Templates give step-by-step instructions for in-place and blue-green upgrades. They cover CRD application ordering, pausing reconciliations, image swaps, and health verification. For breaking releases, templates include extra tasks such as migrating Keeper data or updating config syntax. Each step is CI/CD-friendly with clear rollback points, cutting human error.
### Preverification
Chkk can rehearse the entire upgrade in an isolated twin of your cluster. It applies the new CRDs and operator, then runs all reconciliations, exposing CRD conflicts, stricter validations, or resource spikes before they hit prod. Findings let you adjust manifests or resources ahead of time, ensuring the live rollout is drama-free.
### Supported Packages
Whether you install via Helm, plain YAML, or OLM, Chkk parses your manifests and respects custom images or private registries. It can generate GitOps diffs or PR templates that show the exact manifest changes required. Even with a vendor-customized build, Chkk adapts its checks and guidance so upgrades integrate cleanly with your workflow.
## Additional Resources
* [ClickHouse Operator Documentation](https://docs.altinity.com/altinitykubernetesoperator/)
* [ClickHouse Operator Releases](https://github.com/Altinity/clickhouse-operator/releases)
# Cloudflare Origin CA Issuer
Source: https://docs.chkk.io/projects/cloudflare-origin-ca-issuer
Chkk coverage for Cloudflare Origin CA Issuer. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v0.6.1"
export const ChecksMinVer_0 = "v0.10.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Cloudflare Origin CA Issuer Overview
Cloudflare Origin CA Issuer is a cert-manager extension that automates issuance and renewal of TLS certificates signed by Cloudflare's Origin CA. It facilitates secure communication between Cloudflare's edge network and workloads, eliminating the need for manual certificate management. Certificates issued by Origin CA are specifically trusted by Cloudflare, optimizing secure, rapid TLS deployment between Cloudflare and origin servers. Integrating directly with cert-manager, it ensures seamless certificate lifecycle management within Cloud Native environments. This simplifies TLS configuration, reduces administrative overhead, and maintains secure communications exclusively through Cloudflare's infrastructure.
## Chkk Coverage
### Curated Release Notes
Chkk continuously tracks official Cloudflare Origin CA Issuer updates, summarizing essential operational changes and improvements. Significant alterations, such as mandatory manifest adjustments or new CRD fields, are clearly highlighted. Chkk also indicates API behavior changes impacting your deployment and any compatibility updates required with cert-manager versions. This precise reporting ensures engineers can promptly adapt configurations and maintain stable certificate issuance workflows without extensively reviewing all upstream notes.
### Preflight & Postflight Checks
Chkk performs detailed preflight validations, verifying cert-manager version compatibility and detecting deprecated fields or CRD mismatches. Issues such as outdated issuer references or improperly scoped API tokens are identified ahead of deployment. Postflight checks ensure the Issuer controller is healthy, certificate requests are succeeding, and Cloudflare API interactions are error-free. Automated detection of these critical issues significantly reduces downtime risks associated with certificate issuance.
### Version Recommendations
Chkk monitors Origin CA Issuer versions and proactively recommends upgrades when your deployment nears end-of-life or encounters known reliability issues. Recommendations highlight compatibility with cert-manager and Cloudflare API versions and flag missing essential features or critical bug fixes. Chkk bases upgrade guidance on community feedback, official stability indicators, and operational best practices. This targeted guidance helps platform teams balance maintaining stability and keeping up with important updates.
### Upgrade Templates
Chkk provides structured Upgrade Templates for both in-place and blue-green deployment strategies. Templates detail CRD updates, issuer controller deployment, verification checkpoints, and rollback procedures. Blue-green templates outline strategies to validate a new issuer version gradually without risking ongoing certificate operations. These templates integrate smoothly into GitOps or CI/CD workflows, simplifying repeatable and safe upgrades.
### Preverification
Chkk’s preverification process simulates the complete upgrade path in a controlled test environment using representative configurations and credentials. This simulation identifies configuration conflicts, CRD validation errors, or API credential issues before affecting production. Resource consumption and log analysis are also conducted to anticipate potential performance or operational regressions. This ensures that actual production upgrades proceed smoothly and predictably, minimizing disruptions.
### Supported Packages
Chkk supports multiple deployment approaches, including Helm, Kustomize, and plain YAML manifests. It accurately recognizes issuer installations from custom namespaces, private registries, or forked repositories, providing consistent operational support. Engineers managing deployments through GitOps or CI/CD pipelines can seamlessly leverage Chkk's precise version mappings and upgrade recommendations. This flexibility allows teams to retain existing deployment practices while benefiting from Chkk's insights.
## Common Operational Considerations
* **Scoped API Credentials:** Ensure Cloudflare API tokens have strictly limited permissions (Zone SSL and Certificates edit only). Regularly rotate tokens to maintain secure and continuous certificate operations.
* **Domain and Zone Alignment:** Verify requested certificate domains exactly match those in your Cloudflare zone configuration. Incorrect alignment will result in issuance failures without clear errors in cert-manager.
* **Limited Trust Scope:** Cloudflare Origin CA certificates are not publicly trusted. Services must be exclusively accessed via Cloudflare's proxies to avoid client-side TLS errors.
* **Cloudflare API Connectivity:** The issuer requires uninterrupted outbound connectivity to Cloudflare's API. Configure firewall rules or egress proxies to prevent controller startup and issuance disruptions.
* **Required Certificate Fields:** Always specify `issuerRef.group` as `cert-manager.k8s.cloudflare.com` to avoid certificate processing errors post-upgrade.
* **CRD and Field Renames:** Regularly review issuer CRD changes, as deprecated or renamed fields must be updated promptly. Misalignment will cause ignored or rejected certificate requests.
* **Certificate SAN Limitations:** Origin CA restricts certificates to DNS-based SANs and simple wildcards. Avoid IP addresses and complex wildcards to ensure certificates issue correctly.
## Additional Resources
* [Cloudflare Origin CA Issuer Documentation](https://developers.cloudflare.com/ssl/origin-configuration/origin-ca/)
* [Cloudflare Origin CA Issuer Releases](https://github.com/cloudflare/origin-ca-issuer/releases)
# Cloudflared
Source: https://docs.chkk.io/projects/cloudflared
Chkk coverage for Cloudflared. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v2022.8.4"
export const ChecksMinVer_0 = "v2023.6.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Cloudflared Overview
Cloudflared is an open-source tunneling daemon that securely connects your Kubernetes cluster or services to Cloudflare’s global network, enabling secure external access without opening inbound firewall ports. It establishes outbound-only, encrypted connections to Cloudflare's edge, enabling Zero Trust security principles by limiting ingress exposure. Traffic routed through Cloudflare’s edge network benefits from built-in security services such as DDoS mitigation, WAF, and identity verification through Cloudflare Access. Cloudflared eliminates the need for traditional load balancers or ingress controllers when publishing external services while preserving existing application and network architecture.
## Chkk Coverage
### Curated Release Notes
Chkk tracks Cloudflared releases, highlighting relevant new features, critical fixes, and breaking changes that could impact your infrastructure. Important updates—such as deprecated flags, new logging mechanisms, or OS compatibility changes—are specifically flagged to simplify operational oversight. Instead of parsing lengthy upstream changelogs, Chkk provides concise summaries of version-specific impacts, allowing for proactive cluster management and upgrade planning.
### Preflight & Postflight Checks
Chkk’s preflight checks verify Cloudflared configurations, credential validity, resource allocations, and compatibility with the intended upgrade version. Postflight checks confirm stable tunnel re-establishment, monitor logs for connectivity errors, and validate the uniformity of deployed versions. This structured validation ensures predictable upgrades, immediately identifying issues like authentication problems or mixed-version deployments before they affect service availability.
### Version Recommendations
Chkk proactively identifies Cloudflared versions approaching end-of-life or known operational issues, referencing Cloudflare’s official support policy. Recommendations balance stability and feature availability, advising platform teams to select versions proven reliable by community experience and official guidance. Chkk clearly communicates compatibility considerations, ensuring clusters avoid deploying unsupported versions or configurations incompatible with specific hardware architectures.
### Upgrade Templates
Chkk provides comprehensive Upgrade Templates for both in-place rolling updates and blue-green deployments. Rolling update templates focus on seamless pod transitions to avoid downtime, while blue-green strategies facilitate parallel deployments, verifying stability before traffic cutover. Each template details explicit steps, rollback procedures, and best practices for safely updating Cloudflared instances within Cloud Native environments.
### Preverification
Chkk’s Preverification simulates Cloudflared upgrades in an isolated environment mirroring production configurations, identifying potential issues such as configuration mismatches, credential problems, or resource constraints. This dry-run ensures issues surface in pre-production testing, enabling adjustments before applying changes to live environments. Platform engineers can thus confidently execute upgrades, significantly reducing risk during production rollouts.
### Supported Packages
Chkk supports Cloudflared deployments across manifests, Helm charts, container images, and standalone binary packages, accommodating diverse operational workflows. Custom images, private registries, and GitOps or Terraform-managed configurations are fully compatible, ensuring consistency across various management practices. Chkk's analysis directly aligns with existing deployment methods, suggesting targeted manifest changes required for safe version upgrades.
## Common Operational Considerations
* **Firewall Egress Requirements:** Ensure outbound connectivity on TCP/UDP port 7844 (QUIC/HTTP2) is permitted to Cloudflare endpoints to prevent tunnel connection issues.
* **Multiple Instances for High Availability:** Deploy multiple Cloudflared instances per tunnel to prevent single points of failure, ensuring continuous traffic flow during updates or instance failures.
* **Auto-Update Control:** Disable automatic updates (`--no-autoupdate`) to maintain version control within Cloud Native environments-managed deployments and avoid unexpected service interruptions.
* **Graceful Termination:** Configure proper termination grace periods using `terminationGracePeriodSeconds` to ensure Cloudflared instances close tunnels gracefully during restarts.
* **Ingress Rule Precedence:** Arrange Cloudflared ingress rules from most specific to general, always including a final catch-all rule to ensure correct traffic routing and avoid unintended request handling.
* **Credential Management:** Securely manage and rotate Cloudflared tunnel credentials using Secrets, ensuring updates propagate cluster-wide to prevent unauthorized access or tunnel disruptions.
## Additional Resources
* [Cloudflared Documentation](https://developers.cloudflare.com/cloudflare-one/connections/connect-networks/)
* [Cloudflared Releases](https://github.com/cloudflare/cloudflared/releases)
# Cluster Autoscaler
Source: https://docs.chkk.io/projects/cluster-autoscaler
Chkk coverage for Cluster Autoscaler. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v1.19.0"
export const ChecksMinVer_0 = "v1.21.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Cluster Autoscaler Overview
The Cluster Autoscaler automatically adjusts your worker nodes to match demand, adding nodes when resources are scarce and removing them when they're underutilized. It integrates deeply with the scheduler, simulating how pods would fit on current or potential nodes. With provider-specific implementations, it manages resources on AWS, Azure, GCP, and more. Version alignment with your cluster release is critical to avoid simulation mismatches. Proper configuration can optimize both performance and cost efficiency, making the autoscaler indispensable for production-grade clusters.
## Chkk Coverage
### Curated Release Notes
Chkk constantly scans Cluster Autoscaler's upstream releases and consolidates the findings into concise updates for your specific environment. These updates highlight critical features, deprecations, and bug fixes without forcing you to sift through raw GitHub logs. Each note is contextualized against your current setup, making it easy to see potential impacts. You'll know immediately if new flags, provider integrations, or default behaviors could affect your clusters. This targeted approach helps you prioritize important patches and coordinate safe rollouts.
### Preflight & Postflight Checks
Before upgrades, Chkk performs thorough preflight checks to confirm that credentials, autoscaling ranges, and provider-specific configurations align with the new release. These checks catch issues—like missing IAM roles or malformed node pool tags—before they can disrupt cluster operations. After deployment, postflight checks validate if the autoscaler handles real scale-up and scale-down events without errors. Should logs or metrics indicate issues, Chkk alerts you right away. This end-to-end validation drastically reduces unexpected downtime.
### Version Recommendations
Chkk tracks the autoscaler's compatibility matrix to ensure you run a version that matches your cluster release. It alerts you when your current autoscaler build enters end-of-life or has known security flaws, prompting a timely upgrade. By monitoring both community support cycles and practical runtime feedback, Chkk avoids recommending a version that's either too cutting-edge or already obsolete. It also factors in existing cluster size, workload patterns, and provider constraints to guide your choice. With Chkk's version picks, you maintain alignment with best practices and stable operation.
### Upgrade Templates
Chkk provides **Upgrade Templates** for safely upgrading the Cluster Autoscaler using either in-place or blue-green strategies. Each template spells out prerequisite checks, step-by-step rollout instructions, and clear rollback procedures to mitigate risk. By embedding these templates in your CI/CD pipeline, you enforce consistent processes across multiple clusters. This standardization reduces manual errors and ensures a defined path to revert if something goes wrong. Overall, it's a systematic way to keep your autoscaler current without sacrificing service continuity.
### Preverification
Through preverification, Chkk simulates the entire upgrade process in a controlled environment, mirroring your real cluster as closely as possible. It installs and tests the new autoscaler version, triggers scale-up/down actions, and monitors for errors or unexpected behavior. Issues like broken flags, slower-than-expected provisioning, or changes in default thresholds are detected before they hit production. You can then refine your configurations or resource allocations with minimal risk. By revealing potential pitfalls early, preverification streamlines your production rollout.
### Supported Packages
Chkk supports multiple installation methods—Helm charts, Kustomize overlays, or plain YAML manifests—to accommodate diverse infrastructure needs. It recognizes official builds, forks, and private registry images alike, mapping each to relevant checks and release notes. This means you won't miss critical updates just because you use a custom image or a GitOps-driven workflow. Chkk adapts seamlessly to your deployment model, preserving consistency across all clusters. The end result is complete autoscaler coverage, regardless of how you package it.
## Common Operational Considerations
* **Scale-down Disruptions:** Use PodDisruptionBudgets to ensure critical workloads aren't over-evicted, and only label pods as non-evictable when truly necessary. This guards against unexpected downtime or lost replicas when nodes are removed.
* **Resource Fragmentation:** Configure the autoscaler's expander (e.g., "least-waste") to avoid leaving half-empty nodes. Regularly tune pod resource requests and pick instance types that align with average workload footprints.
* **Cloud Provider Limitations:** Adjust poll intervals and keep node group sizes within your API limits to avoid throttling. Monitor resource quotas so the autoscaler isn't blocked by capacity constraints in your account or region.
* **Priority Expansions:** Configure node group priority expanders to ensure high-priority workloads always get capacity first. Set expendable cutoff for low-priority pods that shouldn't trigger large and costly scale-ups.
* **Graceful Termination:** Check that your workload containers handle SIGTERM properly and complete shutdown before autoscaler timeouts. Use terminationGracePeriodSeconds aligned with the autoscaler's max drain interval to prevent forced kills.
## Additional Resources
* [Node Autoscaling Documentation](https://kubernetes.io/docs/concepts/cluster-administration/node-autoscaling/)
* [Kubernetes Autoscaler Releases](https://github.com/kubernetes/autoscaler/releases)
# CockroachDB
Source: https://docs.chkk.io/projects/cockroachdb
Chkk coverage for CockroachDB. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v23.1"
export const ChecksMinVer_0 = "v24.2"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## CockroachDB Overview
CockroachDB is a distributed, horizontally scalable SQL database designed for resilience and high availability. It automatically shards and replicates data across nodes using Raft consensus, enabling seamless recovery from node or datacenter failures. CockroachDB provides PostgreSQL compatibility, supporting ACID transactions and consistent, low-latency reads globally. Its geo-distribution capabilities, including geo-partitioning and follower reads, allow a single logical database across multiple regions or clouds, enhancing user proximity and performance. The architecture simplifies operational complexity, eliminating manual sharding or complex failover setups.
## Chkk Coverage
### Curated Release Notes
Chkk monitors CockroachDB’s official release notes, highlighting relevant features, breaking changes, and configuration deprecations that affect your clusters. Platform teams receive contextual summaries focused on operational impacts, such as changes in default GC settings or new mandatory operator flags. Chkk ensures you stay informed about essential upgrades without unnecessary details, identifying only the most critical adjustments required for seamless operations.
### Preflight & Postflight Checks
Chkk’s preflight checks validate your cluster state and prerequisites, ensuring nodes are healthy, within supported upgrade paths, and free of under-replicated data. It detects deprecated SQL features or configurations needing updates before upgrades. Postflight checks verify that all nodes run the new version smoothly, confirming successful cluster finalization and identifying any performance or replication anomalies quickly.
### Version Recommendations
Chkk continuously tracks CockroachDB’s version lifecycle, alerting when your version approaches end-of-life or poses known risks. Recommendations are based on official support timelines, community feedback, and documented compatibility issues. Chkk explicitly suggests stable, vetted upgrade targets to balance feature urgency with cluster stability, helping avoid problematic releases.
### Upgrade Templates
Chkk provides detailed templates for both rolling in-place upgrades and blue-green migrations, incorporating CockroachDB’s best practices. Rolling upgrade templates guide node-by-node updates with careful quorum management, ensuring minimal disruption. Blue-green templates detail parallel cluster setups, controlled workload migrations, and built-in rollback points, reducing upgrade risks and downtime.
### Preverification
Preverification rehearses CockroachDB upgrades in isolated test environments mirroring your production setup. Chkk identifies issues such as incompatible schema changes, performance regressions, and resource constraints before they impact your live environment. This "dry run" approach ensures adjustments can be made proactively, significantly reducing risks during actual upgrades.
### Supported Packages
Chkk supports deployment via CockroachDB Operator, Helm charts, and standard YAML manifests. It integrates seamlessly with existing customizations, including private registries and bespoke builds. Chkk intelligently identifies and recommends only necessary configuration changes for each package format, preserving consistency across deployments and simplifying upgrades.
## Common Operational Considerations
* **Quorum Requirements:** Always maintain quorum (majority of nodes alive) to ensure cluster availability. Plan maintenance carefully to avoid accidental quorum loss, especially in smaller clusters.
* **Clock Sync:** Ensure strict clock synchronization across nodes, ideally using NTP or Chrony. Excessive clock drift beyond default limits (500ms) will cause automatic node shutdown to prevent inconsistency.
* **Disk Capacity Management:** Proactively monitor and maintain sufficient disk space, ideally below 85% usage. Disk exhaustion triggers automatic node shutdown; regular monitoring prevents unexpected downtime.
* **Time-Series Data Overhead:** Internal telemetry storage consumes significant disk space over time. Regularly review and tune retention settings to manage this overhead effectively.
* **MVCC Garbage Collection:** Deleted data isn't immediately reclaimed due to MVCC version retention. Adjust garbage collection TTL or manually trigger compaction to quickly free space after bulk deletions.
* **Proper Node Decommissioning:** Always use the official decommissioning procedure to safely remove nodes. This process ensures data is replicated properly elsewhere, maintaining cluster health and availability.
## Additional Resources
* [CockroachDB Documentation](https://www.cockroachlabs.com/docs/stable/)
* [CockroachDB Releases](https://www.cockroachlabs.com/docs/releases/)
# Confluent Platform Kafka
Source: https://docs.chkk.io/projects/confluent-platform-kafka
Chkk coverage for Confluent Platform Kafka. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v1.9.0"
export const ChecksMinVer_0 = "v2.1.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Confluent Platform Kafka Overview
Confluent Platform Kafka is an enterprise-ready distribution of Apache Kafka designed for high-throughput, scalable event streaming and real-time data pipelines in modern cloud environments. It enhances open-source Kafka with advanced security, schema management, and operational tools. Kafka's distributed brokers ensure durability and fault tolerance through partition replication. Producers and consumers interact via decoupled topics, simplifying the architecture for microservices and analytics workloads. Chkk provides automation and insights to help manage Kafka's lifecycle and configuration safely, minimizing risks during upgrades and operational changes.
## Chkk Coverage
### Curated Release Notes
Chkk curates Kafka release notes and Kafka Improvement Proposals (KIPs), highlighting critical updates such as configuration changes, deprecated APIs, or default behavior alterations that impact your clusters. It streamlines upgrade awareness by contextualizing operational impacts, eliminating manual parsing. Each summarized update includes direct links to detailed upstream resources for further reference. This targeted information helps platform teams proactively manage potential disruptions caused by Kafka updates.
### Preflight & Postflight Checks
Chkk performs rigorous preflight checks verifying compatibility with the targeted Kafka version, including broker, Java, ZooKeeper or KRaft quorum, and deprecated configurations. It proactively flags issues such as under-replicated partitions or insufficient ISR settings before upgrades. Postflight checks confirm broker health, balanced partition leadership, consumer group offset integrity, and proper replication synchronization. These comprehensive checks greatly reduce upgrade risks and maintain cluster performance.
### Version Recommendations
Chkk monitors Kafka’s official support lifecycle and security advisories to proactively alert you about versions approaching end-of-life or containing critical vulnerabilities. It provides actionable recommendations, highlighting stable, well-supported Kafka versions for upgrades based on community feedback and compatibility. Chkk helps platform engineers plan upgrades effectively, avoiding exposure to known security risks and maintaining operational stability. This foresight ensures Kafka clusters remain secure, compliant, and reliable.
### Upgrade Templates
Chkk provides detailed Upgrade Templates supporting both in-place rolling upgrades and blue-green deployment strategies. In-place templates detail broker rollouts and manage inter.broker.protocol.version compatibility. Blue-green templates guide setting up parallel clusters, mirroring data, and gradually migrating workloads, minimizing operational risk. These structured playbooks integrate seamlessly with GitOps and CI/CD pipelines, ensuring predictable and repeatable Kafka upgrades.
### Preverification
Chkk’s preverification feature simulates Kafka upgrades in an isolated "digital twin" environment, replicating your configurations, topics, and workloads. It detects hidden upgrade issues, including configuration incompatibilities, resource constraints, or replication failures before they impact production. Early identification of these challenges enables proactive remediation, significantly reducing uncertainty during actual upgrades. Preverification ensures confidence and safety in production Kafka upgrades.
### Supported Packages
Chkk seamlessly supports Kafka deployments via Helm charts, operators (like Confluent for Cloud Native), Kustomize, or standard YAML manifests. It automatically recognizes your specific setup, including custom images and private registries, tailoring recommendations accordingly. Chkk integrates smoothly with existing GitOps workflows, preserving your deployment methodologies and customization. This flexibility allows platform engineers to manage Kafka consistently within their established practices.
## Common Operational Considerations
* **Broker Quorum Stability:** Maintain at least three brokers with proper ISR configurations to avoid leader quorum issues. Schedule broker maintenance carefully to prevent quorum disruption.
* **ZooKeeper Dependencies:** Keep ZooKeeper clusters highly available and monitor performance closely, as Kafka metadata operations heavily rely on ZooKeeper responsiveness. During KRaft migrations, proceed carefully to prevent irreversible data issues.
* **ISR and Under-Replicated Partitions:** Regularly monitor ISR metrics and quickly address under-replicated partitions to maintain data durability. Use replication throttling and manage broker downtime cautiously.
* **Consumer Lag Management:** Actively monitor consumer lag and scale consumer groups proactively if lag grows significantly. Address persistent lag to maintain real-time processing and prevent hidden backlogs.
* **Rolling Upgrades and Downgrades:** Perform Kafka upgrades incrementally, broker by broker, and avoid skipping multiple major versions. Maintain rollback capability by managing feature flags and protocol compatibility carefully.
* **Security and Authentication Pitfalls:** Enforce consistent SASL/SSL configurations and ACLs for all clients to prevent connectivity failures. Verify new security features and TLS settings thoroughly in staging environments.
* **Networking and Load Balancing Issues:** Configure Kafka-aware load balancing correctly, ensuring proper broker address advertisements (advertised.listeners). Use dedicated services or headless DNS services to facilitate direct client-to-broker connections.
## Additional Resources
* [Confluent Platform Kafka Documentation](https://docs.confluent.io/)
# Connaisseur
Source: https://docs.chkk.io/projects/connaisseur
Chkk coverage for Connaisseur. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v2.5.0"
export const ChecksMinVer_0 = "v2.8.1"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Connaisseur Overview
Connaisseur is an admission controller designed to ensure that only container images signed by trusted sources are deployed. It intercepts pod creation requests, verifies digital signatures against pre-defined trust keys, and enforces strict container provenance by pinning images to immutable digests. Compatible with Docker Content Trust (Notary v1) and Sigstore Cosign, Connaisseur integrates seamlessly with various CI/CD pipelines. Platform teams can centrally enforce container image security policies without requiring modifications to application workloads, significantly strengthening supply chain security and compliance.
## Chkk Coverage
### Curated Release Notes
Chkk tracks official Connaisseur releases, highlighting critical features, breaking changes, and key updates relevant to your operational environment. Important items like changes in supported signing backends, webhook configurations, or mandatory Helm chart parameters are clearly identified. Chkk’s targeted summaries help platform teams rapidly assess and address operational impacts of updates, reducing upgrade-related risks. Additionally, security patches and vulnerability mitigations are emphasized to maintain the integrity of container image validation.
### Preflight & Postflight Checks
Chkk runs comprehensive pre-flight checks to confirm cluster compatibility and to verify that the admission webhook, policy definitions, validator configuration, and all associated ConfigMaps, Secrets, and trusted signing keys are present and valid. These checks prevent compatibility issues like deprecated API versions or skipped intermediate upgrades. Post-upgrade, the postflight checks validate the admission webhook health, proper digest enforcement, and operational logging for verification failures. This proactive approach significantly reduces operational disruption by identifying potential issues before they impact your cluster.
### Version Recommendations
Chkk monitors Connaisseur’s release cadence, notifying teams when their deployed version falls behind or becomes vulnerable. Chkk aligns Connaisseur versions with compatibility, community feedback, and known issues to recommend stable upgrade targets. This helps avoid operational pitfalls associated with outdated Connaisseur instances, including potential security vulnerabilities and compatibility breakages. Custom or forked deployments with specific support timelines are fully accommodated within Chkk’s recommendations.
### Upgrade Templates
Chkk offers structured Upgrade Templates covering both in-place and blue-green upgrade strategies using Helm or raw YAML. These templates detail precise steps for safely transitioning webhook configurations, minimizing operational risk during upgrades. Templates include rollback points and contingency steps for high-availability environments, such as temporarily switching webhook admission policy modes. Integration-friendly, they support standard GitOps and CI/CD workflows, ensuring repeatable and reliable Connaisseur upgrades.
### Preverification
Chkk’s preverification feature simulates Connaisseur upgrades within an isolated replica of your production environment. It proactively detects potential problems like schema mismatches, missing or misconfigured keys, or resource allocation issues. This digital twin approach ensures operational readiness by verifying successful signature validation and webhook admission policies before actual production deployment. Preverification significantly reduces the likelihood of encountering unexpected issues during live upgrades.
### Supported Packages
Chkk supports Connaisseur deployments through Helm, Kustomize, or plain YAML manifests, ensuring flexibility in package management approaches. It respects customized forks, private registries, and specialized deployment configurations, preserving consistency during upgrades. Chkk can directly parse and adjust GitOps-managed deployments, accurately mapping existing configurations to new releases. This comprehensive package support simplifies operational maintenance across diverse deployment methodologies.
## Common Operational Considerations
* **Admission Webhook Availability:** Run multiple replicas for high availability; temporarily set webhook policy to fail-open only during planned maintenance to balance security with uptime.
* **Network Access to Trust Sources:** Ensure clusters have reliable connectivity to external signature repositories or configure internal mirrors to avoid admission delays or failures.
* **Key & Certificate Rotation:** Regularly rotate trust keys and webhook TLS certificates proactively; schedule updates during maintenance windows to prevent unexpected deployment blocks.
* **Digest vs Tag Visibility:** Connaisseur pins images to digests, altering tag visibility in Cloud Native environments resources; ensure operational tooling and debugging processes accommodate digest identification.
* **Gradual Enforcement and Namespaces:** Initially deploy Connaisseur in audit mode or limited namespaces to identify unsigned workloads, then progressively enforce policies to avoid broad deployment disruptions.
* **Performance and Caching:** Enable Redis caching in high-deployment-frequency environments to reduce verification latency; scale webhook instances appropriately to maintain operational responsiveness.
## Additional Resources
* [Connaisseur Documentation](https://sse-secure-systems.github.io/connaisseur/latest/)
* [Connaisseur Releases](https://github.com/sse-secure-systems/connaisseur/releases)
# Contour
Source: https://docs.chkk.io/projects/contour
Chkk coverage for Contour. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v1.2.1"
export const ChecksMinVer_0 = "v1.17.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Contour Overview
Contour is an ingress controller that uses Envoy as the data plane, allowing dynamic routing and real-time updates. It introduces the HTTPProxy CRD for advanced capabilities, including path rewrites, TLS configuration, and delegation. Contour separates the control plane (Contour) from the data plane (Envoy) so configuration changes do not require restarts. It is a CNCF Incubating project that stresses performance, multi-tenancy, and security. Recent releases add deeper Gateway API support and refined CRDs, making it easier to modernize ingress traffic management.
## Chkk Coverage
### Curated Release Notes
Chkk tracks and summarizes official Contour releases, highlighting critical changes, deprecations, and feature updates. It saves time by providing an actionable overview of new config requirements, resource shifts, or potential security implications. Contextual flags help you quickly identify if older CRDs like IngressRoute are no longer supported. The release notes also warn you if Envoy defaults have changed, potentially altering routing or TLS behavior. This means you won't have to read every upstream release detail to spot what impacts your clusters.
### Preflight & Postflight Checks
Chkk runs automated checks before and after a Contour upgrade to confirm version compatibility, CRD alignment, and resource health. Preflight checks validate cluster readiness, required CRDs, and any deprecated objects, while postflight confirms that the new Contour and Envoy instances are functioning correctly. This approach proactively catches common problems, such as invalid certificate setups or leftover outdated configurations. It also monitors logs, traffic, and workload states, ensuring your routes remain healthy. As a result, you can upgrade with confidence knowing each stage was validated.
### Version Recommendations
Chkk continuously monitors Contour's lifecycle to warn you of any EOL versions or upcoming support drops. It suggests stable, compatible releases that align with your Cloud Native environment and security requirements, referencing official support timelines. You can rely on its guidance to upgrade at the right time without skipping critical patches. The platform pinpoints known issues or deprecated CRDs, helping you focus your efforts on necessary migrations. This balance of proactive alerts and curated recommendations streamlines upgrade planning.
### Upgrade Templates
Chkk provides in-place or blue-green upgrade templates, each detailing best-practice steps to reduce downtime. These templates walk you through CRD updates, rolling out new Contour pods, and verifying Envoy connections. In-place upgrades preserve the existing deployment, while blue-green deploys a new version in parallel, letting you switch traffic when ready. Both approaches include rollback paths in case of unexpected errors or misconfigurations. By following these structured plans, you minimize disruptions to external traffic during Contour upgrades.
### Preverification
Chkk offers a dry-run "digital twin" of your Contour upgrade in an isolated environment. This simulated deployment uncovers resource conflicts, CRD migration issues, or Envoy filter mismatches before affecting production. If anomalies are detected—like broken routes or high resource usage—you can adjust configurations early. This proactive rehearsal helps reduce rollbacks and downtime. Ultimately, it provides an extra layer of certainty when deploying new Contour versions in production.
### Supported Packages
Chkk works with common Contour deployment methods, including Helm charts, Kustomize, and raw manifests. It detects which approach you're using and tailors upgrade commands, patch files, or Helm steps accordingly. Private registries and custom builds are also supported, with checks to ensure images are tagged and available. This flexibility means you won't have to change your existing workflows or repository structure. The result is a consistent upgrade experience regardless of how Contour is managed.
## Common Operational Considerations
* **Sequential Upgrades:** Avoid skipping minor versions to ensure CRD changes and config migrations run smoothly. This reduces unexpected incompatibilities and makes rollback safer if issues arise.
* **DaemonSet Resource Usage:** Envoy typically runs as a DaemonSet with hostPorts on each node, so plan rolling updates carefully. Conflicts can arise if the new version tries to bind ports before the old Envoy pod is terminated.
* **CRD Deprecation:** Watch for deprecated or removed objects like IngressRoute, and migrate them to HTTPProxy. Keeping CRDs up to date avoids validation failures and controller errors in new Contour releases.
* **Envoy/Contour Certificates:** Ensure TLS certificates for Contour-Envoy communication and ingress workloads remain valid and updated. A mismatch can break traffic or block new pods from registering properly.
* **Monitoring & Metrics:** Contour and Envoy both provide metrics that should be scraped by Prometheus or equivalent. Monitor these for signs of configuration errors, traffic anomalies, or resource saturation after upgrades.
* **Ingress Class:** If you run multiple ingress controllers or parallel Contour versions, use distinct ingress classes or namespaces. This prevents conflicting status updates and helps isolate troubleshooting when testing new releases.
## Additional Resources
* [Contour Documentation](https://projectcontour.io/docs/1.30/)
* [Contour Releases](https://github.com/projectcontour/contour/releases)
# CoreDNS
Source: https://docs.chkk.io/projects/coredns
Chkk coverage for CoreDNS. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v1.6.7"
export const ChecksMinVer_0 = "v1.7.1"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## CoreDNS Overview
CoreDNS is a lightweight, extensible DNS server for modern deployments. It uses a plugin-based model, enabling quick customization and dynamic updates based on cluster state. As the default DNS and service discovery component in Cloud Native environments, CoreDNS integrates tightly with the Cloud Native API. In addition to scalability, it offers a consistent interface for managing DNS-based traffic policies. CoreDNS's design helps teams efficiently handle large-scale DNS requests with minimal overhead.
## Chkk Coverage
### Curated Release Notes
Chkk monitors official CoreDNS release notes and flags new features, plugin changes, or deprecations relevant to your clusters. This helps avoid unexpected DNS failures caused by removed directives. Chkk prioritizes details that could break upgrade paths in your environment. It streamlines discovery of known issues, so you can plan updates effectively. Each alert includes step-by-step guidance for mitigating potential risks.
### Preflight & Postflight Checks
Chkk performs preflight scans to detect incompatible Corefile directives, ensuring your config is ready for an upgrade. After upgrading, postflight checks verify that new CoreDNS pods are healthy and serving DNS correctly. This reduces risk by catching syntax errors, plugin mismatches, or resource constraints early. You'll receive alerts if pods fail readiness probes or crash-loop. That way, you can correct issues before affecting critical workloads.
### Version Recommendations
Chkk tracks CoreDNS versions and correlates them with Kubernetes versions, highlighting when your current DNS version is at risk. The tool factors in security patches and plugin maturity to suggest stable upgrade paths. This keeps you aligned with actively maintained CoreDNS releases while accounting for real-world usage. If you've pinned an outdated version, you'll see clear warnings about EOL or security vulnerabilities. You get peace of mind knowing your DNS stack remains fully supported.
### Upgrade Templates
Chkk offers in-place and blue-green upgrade guides for CoreDNS, detailing each step to avoid downtime. An in-place upgrade updates existing pods in a rolling manner with minimal disruption. Blue-green provides a parallel deployment for canary testing before switching all traffic, giving you a safer fallback. These templates integrate with Helm, Kustomize, or raw YAML flows. Automated checks during each phase help prevent mistakes and ease rollback if necessary.
### Preverification
Preverification executes a dry-run of your CoreDNS upgrade in a controlled environment, validating your Corefile against the new release. This process proactively detects plugin incompatibilities and configuration errors before they affect production. By simulating the upgrade, it surfaces potential bottlenecks and service disruptions early, enabling you to proceed with confidence. With preverification, your upgrade path is both tailored and tested for your specific configuration, minimizing risk and ensuring a smooth transition.
### Supported Packages
Chkk is compatible with Helm, Kustomize, and plain YAML distributions of CoreDNS. It recognizes custom images, private registries, and alternative configurations. This allows you to maintain consistency in your existing deployment pipelines. Chkk's intelligence adapts to your chosen method, providing targeted guidance for upgrades. Regardless of how you deploy CoreDNS, you get curated checks and detailed recommendations.
## Common Operational Considerations
* **Plugin Compatibility Issues:** When upgrading CoreDNS, ensure your Corefile removes deprecated plugins or syntax. Failing to do so can cause pods to crash and break DNS resolution.
* **Configuration Pitfalls:** Typos in the Corefile or invalid upstream DNS entries can lead to immediate failures. Always validate config changes in a non-production environment to avoid cluster-wide impact.
* **Performance Tuning:** Right-size CoreDNS resources and replica counts, especially in large clusters to maintain stability, scalability, and performance. Monitoring query times and memory usage helps you adjust replicas or enable caching plugins.
* **Debugging Failures:** Use logs to trace DNS errors or crashes, and confirm pods are healthy and Ready. Triage with test pods (e.g., dnsutils) to confirm end-to-end name resolution functionality.
## Additional Resources
* [CoreDNS Documentation](https://coredns.io/tags/documentation/)
* [CoreDNS Releases](https://github.com/coredns/coredns/releases)
# Crossplane
Source: https://docs.chkk.io/projects/crossplane
Chkk coverage for Crossplane. We provide curated release notes, preflight/postflight checks, and Upgrade Templates—all tailored to your environment.
export const ReleaseNotesMinVer_0 = "v1.1.0"
export const ChecksMinVer_0 = "v1.2.1"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Crossplane Overview
Crossplane is a Cloud Native Project that manages external infrastructure via K8s-native APIs. Instead of separate dashboards, teams declare cloud resources (e.g., S3 buckets, databases) using CRDs and controllers. Providers connect clusters to AWS, GCP, or Azure, while Compositions bundle multiple resources into user-friendly composite objects (e.g., kind: XPostgresInstance). Since everything is declared in YAML, GitOps flows naturally: changing manifests in Git triggers Crossplane to reconcile real-world infrastructure.
## Chkk Coverage
### Curated Release Notes
Chkk continuously monitors Crossplane releases, summarizing new features, security patches, and breaking changes relevant to cloud resource management. You see concise highlights—like provider enhancements, CRD deprecations, or EOL warnings—without digging into raw changelogs. This streamlined view helps you quickly assess upgrade impact (e.g., if Composition fields changed or a provider plugin requires new RBAC permissions).
### Preflight & Postflight Checks
Chkk's preflight checks ensure your Crossplane environment and CRDs are compatible with an upcoming version, verifying that providers aren't on an unsupported API and that your cluster meets the new release's cluster requirements. Post-upgrade and Postflight checks confirm the new Crossplane controller and providers are healthy, scanning logs for errors and verifying managed resources continue reconciling without breakage. This two-phase validation reduces risk by detecting issues—like a missing CRD field or outdated provider image—early in the process.
### Version Recommendations
Chkk tracks Crossplane's support milestones, alerting you when you're on a release nearing end-of-life or missing critical patches. It notes known incompatibilities with certain Cloud Native environments versions or provider releases. This approach prevents teams from unexpectedly hitting unsupported Crossplane features or security gaps. By following Chkk's guidance, you stay on stable releases aligned with your broader cluster roadmap.
### Upgrade Templates
Chkk provides in-place and blue-green upgrade playbooks for Crossplane. In-place upgrades your existing deployment, typically via rolling updates or Helm chart bumps. Minimal overhead, but a small risk if changes break the controller mid-upgrade. Blue-green spins up a parallel "green" Crossplane instance (in a staging namespace or cluster), validates it, then cuts over once stable. This strategy ensures near-zero downtime, with an easy rollback if the new version misbehaves.
Both methods include rollback instructions, recommended checks, and best practices for CRD updates, ensuring safe transitions with minimal disruption to managed infrastructure.
### Preverification
For major version jumps or critical environments, Chkk's preverification simulates a Crossplane upgrade in a safe sandbox. It applies your actual CRDs, Providers, and Compositions to the new version, checking for schema conflicts, API deprecations, or updated RBAC needs. Any mismatch—like a provider that can't load its resources—appears in a detailed report, letting you fix problems before going live. This rehearsal significantly reduces the likelihood of unexpected production breakage.
### Supported Packages
Chkk recognizes Helm, Kustomize, and raw YAML deployments of Crossplane. If you install via Helm, Chkk patches chart values and uses Helm upgrade; for Kustomize or YAML, it generates updated manifests that match your current approach. Private registries, custom images, and organization-specific security requirements are also respected. This ensures you don't have to refactor your workflow—Chkk fits seamlessly whether you're using GitOps, plain YAML, or hybrid setups.
## Common Operational Considerations
* **Provider Credential Collisions:** Multiple teams may share the same ProviderConfig secret, so a single compromise or misconfiguration affects all Crossplane-managed resources. Assign unique provider credentials per namespace or team and restrict secret access via RBAC so only Crossplane can read them.
* **Overly Broad XRD Schemas:** Exposing too many raw provider fields lets users override critical settings (like subnets or firewall rules). Keep Crossplane APIs minimal and validated, then patch in safe defaults in the Composition to avoid unintended or malicious config changes.
* **Controller Overload:** Each Crossplane provider polls external APIs on a schedule, so hundreds of managed resources can trigger rate limits or overwhelm the control plane. Increase poll intervals (--poll-interval) and split large deployments across multiple providers to prevent reconcile bottlenecks.
* **Security Leakage in Connection Secrets:** Connection details (DB passwords, tokens) often appear in namespace Secrets, risking exposure if the namespace is unprotected. Use dedicated secret managers (Vault, AWS Secrets Manager) or enforce strict RBAC and access policies to safeguard these credentials.
## Additional Resources
* [Crossplane Documentation](https://docs.crossplane.io/latest/)
* [Crossplane Releases](https://github.com/crossplane/crossplane/releases)
# Datadog Agent
Source: https://docs.chkk.io/projects/datadog-agent
Chkk coverage for Datadog Agent. We provide curated release notes, preflight/postflight checks, and Upgrade Templates—all tailored to your environment.
export const ReleaseNotesMinVer_0 = "v6.19.0"
export const ChecksMinVer_0 = "v7.23.1"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Datadog Agent Overview
Datadog Agent collects metrics, logs, and traces from clusters, running as a DaemonSet on each node. It integrates with the Cloud Native API and workloads to provide observability, forwarding data to Datadog for monitoring. The Cluster Agent coordinates metadata collection and reduces API load, improving efficiency in large clusters. Datadog Agent supports auto-discovery, integrations, and security monitoring, making it a flexible solution for infrastructure visibility. Chkk ensures its seamless deployment, monitoring, and upgrade safety.
## Chkk Coverage
### Curated Release Notes
Chkk curates Datadog Agent release notes, highlighting new features, breaking changes, and operational impacts. Instead of parsing every upstream detail, engineers receive targeted insights on critical changes, deprecated configurations, and feature adjustments. If an update requires RBAC changes or introduces new API dependencies, Chkk flags it beforehand. Release summaries also assess potential resource impact and performance shifts. This approach streamlines decision-making and prevents misconfigurations.
### Preflight & Postflight Checks
Before upgrades, Chkk runs preflight checks to verify Kubernetes version compatibility, deprecated fields, and required permissions. It ensures configuration changes (e.g., log collection toggles, new API calls) won't disrupt monitoring. Post-upgrade, Chkk confirms Agent pods are healthy, data is flowing, and no unexpected failures have occurred. It detects memory spikes, missing logs, or CRD issues early, preventing monitoring blind spots. These validations reduce risk and improve upgrade confidence.
### Version Recommendations
Chkk monitors Datadog Agent's lifecycle, notifying teams of security risks and upcoming EOL versions. It suggests stable upgrade paths based on support status and community-reported issues, ensuring compatibility and reliability. If a version has known bugs, Chkk recommends skipping or waiting for a fix. It also tracks API changes that might impact older Agent versions. This proactive approach minimizes unplanned outages and ensures ongoing support.
### Upgrade Templates
Chkk provides **Upgrade Templates** for in-place rolling updates and blue-green deployments. In-place upgrades roll out Agents node by node while monitoring resource impact. Blue-green strategies deploy a parallel Agent set for validation before cluster-wide adoption. Chkk includes rollback steps, ensuring quick recovery if issues arise. These templates integrate with GitOps workflows and reduce manual intervention risks. Teams gain predictable, controlled upgrades with minimal downtime.
### Preverification
**Preverification** simulates Datadog Agent upgrades in an isolated environment before live deployment. This dry-run detects configuration conflicts, RBAC gaps, or API incompatibilities without affecting production. If a new Agent version crashes due to missing dependencies, Chkk flags it early. Engineers can iterate on fixes before rolling out the upgrade. This process enhances stability and prevents production incidents.
### Supported Packages
Chkk supports Helm, Datadog Operator, YAML, and Kustomize-based deployments. It tracks Helm chart versions, validates Operator CRs, and ensures static manifests stay in sync. Custom Agent images and private registries are fully supported, ensuring consistency across environments. If integrations like kube-state-metrics are used, Chkk verifies their compatibility with Agent versions. This flexibility allows seamless adoption across different setups.
## Common Operational Considerations
* **Configuration Pitfalls:** Features like log collection and APM tracing must be explicitly enabled; default settings might leave critical data unmonitored. Always review datadog.yaml settings to ensure required integrations and logs are correctly configured.
* **Resource Utilization & Tuning:** The Agent can consume significant CPU/memory in large clusters, often due to frequent metric polling. Tune min\_collection\_interval and filter unnecessary logs to optimize resource usage.
* **Integration & Autodiscovery:** Properly annotate pods for Autodiscovery to automatically enable monitoring for services like Redis or NGINX. Running kube-state-metrics alongside the Agent ensures full cluster observability.
* **Cluster Agent Usage:** The Datadog Cluster Agent offloads metadata collection, reducing API server strain. Large clusters should deploy it for improved efficiency and scalability.
* **Kubernetes Compatibility:** API changes (e.g., EndpointSlices replacing Endpoints) may require Agent updates and RBAC adjustments. Always verify Kubernetes version compatibility before upgrading.
* **Staying Up-to-Date:** Monthly Agent updates are recommended for security and stability. Avoid deploying versions with known issues, and test in a canary environment before full rollout.
## Additional Resources
* [Datadog Agent Documentation](https://docs.datadoghq.com/agent/)
* [Datadog Agent Releases](https://github.com/DataDog/datadog-agent/releases)
# Datadog Operator
Source: https://docs.chkk.io/projects/datadog-operator
Chkk coverage for Datadog Operator. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v0.8.0"
export const ChecksMinVer_0 = "v1.1.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Datadog Operator Overview
Datadog Operator is a controller that automates deployment and lifecycle management of Datadog Agents within clusters. It streamlines agent setup by allowing platform engineers to use a single DatadogAgent custom resource to define cluster-wide agent configurations, replacing manual DaemonSet or Helm management. The operator handles dynamic agent rollout, version upgrades, and configuration updates through reconciliation loops. By encapsulating complex integrations for metrics, logs, and APM, it ensures consistent observability across nodes without manual intervention.
## Chkk Coverage
### Curated Release Notes
Chkk monitors official Datadog Operator release notes, highlighting changes like deprecated CRDs or altered defaults that impact your clusters. It contextualizes these details so engineers can quickly identify critical updates, such as mandatory migrations from v1alpha1 to v2alpha1 CRDs. By providing targeted briefings on configuration impacts or admission webhook changes, Chkk reduces the overhead of parsing lengthy upstream release notes. This ensures upgrades are predictable, preventing unexpected monitoring disruptions.
### Preflight & Postflight Checks
Before upgrading, Chkk validates Kubernetes version compatibility, ensures appropriate CRD migrations (e.g., conversion webhooks for v1alpha1 resources), and detects deprecated configuration fields. After upgrades, it verifies operator health, confirms successful rollout of agent pods, and inspects CR statuses for errors like misconfigured API keys. By automating these checks, Chkk quickly identifies and helps engineers remediate issues such as stuck pods or incomplete rollouts. This proactive approach minimizes monitoring gaps post-upgrade.
### Version Recommendations
Chkk tracks Datadog Operator versions against compatibility and support timelines, alerting teams when their current version approaches end-of-life or poses compatibility risks. It specifically highlights critical issues, such as upcoming CRD removals or incompatibilities with older Kubernetes versions. Chkk’s recommendations include stable, community-validated upgrade paths, balancing the need for new features against operational stability. Engineers can confidently plan upgrades without risking monitoring reliability.
### Upgrade Templates
Chkk offers detailed Upgrade Templates covering necessary steps like CRD conversions and required preparation tasks. These templates provide step-by-step instructions for safely upgrading the operator, including rollback points and validation checks suitable for GitOps or CI/CD pipelines. They ensure essential procedures—such as enabling conversion webhooks or managing operator Deployment upgrades—are not missed. This reduces operational complexity and prevents monitoring outages during upgrades.
### Preverification
Chkk’s preverification simulates Datadog Operator upgrades in isolated environments mirroring your production setup. It tests the entire upgrade sequence, revealing potential issues like increased resource usage or stricter validation rules that may block deployment. Engineers can proactively address these issues by adjusting manifests or resource allocations before production rollout. Preverification substantially reduces the likelihood of surprise failures, making upgrades safe and predictable.
### Supported Packages
Chkk supports Datadog Operator deployments via Helm charts, OperatorHub (OLM), Kustomize, or plain YAML manifests. It seamlessly manages upgrades regardless of your chosen installation method, preserving customizations such as private registries or tailored node selectors and tolerations. Chkk identifies relevant changes between operator versions—such as updated RBAC rules or container images—and provides minimal required edits for safe upgrades. This flexibility allows engineers to integrate Chkk smoothly into existing deployment workflows.
## Additional Resources
* [Datadog Operator Documentation](https://docs.datadoghq.com/containers/datadog_operator/)
* [Datadog Operator Releases](https://github.com/DataDog/datadog-operator/releases)
# Dex
Source: https://docs.chkk.io/projects/dex
Chkk coverage for Dex. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v0.28.0"
export const ChecksMinVer_0 = "v2.35.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Dex Overview
Dex is an open-source identity provider using the OpenID Connect (OIDC) protocol, allowing Kubernetes clusters and applications to delegate authentication to external services like LDAP, GitHub, Google, or Active Directory. It centralizes user logins and single sign-on, simplifying identity management without embedding custom authentication logic into individual apps. API servers interact with Dex as an OIDC endpoint, obtaining JWT tokens containing identity claims and group data for RBAC policies. Deploying Dex enables consistent authentication policies, leveraging existing IdP infrastructure for multi-factor authentication and centralized identity governance.
## Chkk Coverage
### Curated Release Notes
Chkk curates official Dex release notes, emphasizing new features, breaking changes, or critical updates directly relevant to your authentication environment. It flags impactful changes such as stricter LDAP validations, new connector APIs, or storage schema updates. Platform engineers receive targeted, contextual summaries to avoid surprises during upgrades. Even subtle changes like updated token algorithms or TLS configurations are clearly communicated, ensuring operational continuity.
### Preflight & Postflight Checks
Chkk performs preflight checks to confirm your cluster meets Dex’s upgrade requirements, validating API server settings, CRD compatibility, and connector configurations. Deprecated settings or incompatible connector configurations are identified in advance, enabling proactive remediation. Postflight checks verify Dex’s health, confirm successful connector initializations, and perform test authentication flows against the Cloud Native API server. This thorough validation helps detect and address upgrade-related authentication issues quickly.
### Version Recommendations
Chkk continuously monitors Dex’s release lifecycle and security advisories, alerting you when your deployed version nears end-of-life or becomes vulnerable. Version alerts include context on critical patches, known vulnerabilities, and compatibility with your Kubernetes cluster version. Chkk provides concrete upgrade recommendations, balancing stability, compatibility, and security requirements. This proactive approach prevents security gaps and minimizes disruptive forced upgrades.
### Upgrade Templates
Chkk offers structured Upgrade Templates for Dex, supporting both in-place updates and blue-green deployments. Templates include clearly documented steps to update Dex container images, validate readiness, and safely manage persistent storage. For blue-green deployments, the templates outline deploying parallel Dex instances, testing functionality, and gracefully transitioning clients. This structured guidance ensures smooth upgrades and straightforward rollback procedures integrated into your CI/CD or GitOps workflows.
### Preverification
Preverification by Chkk simulates Dex upgrades in isolated environments, replicating your configuration and connectors. Automated tests validate server startup, connector functionality, and successful OIDC authentication flows before production deployment. This simulation uncovers issues like stricter configuration validations, connector errors, or compatibility problems, providing an opportunity to resolve them safely. Preverification ensures high confidence in Dex upgrades, significantly reducing risk.
### Supported Packages
Chkk integrates seamlessly with common Dex deployment methods, including Helm charts, static manifests, and Kustomize. It recognizes standard configurations and handles custom or vendor-specific Dex builds hosted in private registries. Chkk's recommendations are tailored to your deployment approach, outputting precise configuration diffs compatible with your existing management tools. This flexibility ensures Dex version management fits seamlessly into your existing DevOps practices.
## Common Operational Considerations
* **Issuer URL Mismatch:** The API server’s `--oidc-issuer-url` must exactly match Dex’s configured issuer URL. Any discrepancy causes token rejections without explicit errors.
* **Certificate Trust:** Dex must serve HTTPS using certificates trusted by the Cloud Native API server. Incorrect or expired certificates result in rejected tokens.
* **Connector Errors:** Connector outages or misconfigurations lead to failed user authentications. Monitor Dex logs for connector errors and maintain redundancy for critical connectors.
* **Session Storage:** Ephemeral storage results in lost sessions upon Dex restarts or upgrades. Use persistent storage (e.g., PostgreSQL, CRDs) to retain user sessions.
* **High Availability:** Multiple Dex replicas must share consistent backend storage and may require sticky sessions. Misconfigured HA setups risk token validation issues.
* **Break-Glass Access:** Maintain alternative emergency credentials independent of Dex to prevent lockouts during Dex outages. Regularly validate this access method.
## Additional Resources
* [Dex Documentation](https://dexidp.io/docs/)
* [Dex Releases](https://github.com/dexidp/dex/releases)
# Directus
Source: https://docs.chkk.io/projects/directus
Chkk coverage for Directus. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v10.1.0"
export const ChecksMinVer_0 = "v10.11.1"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Directus Overview
Directus is an open-source headless CMS that layers REST, GraphQL, and WebSocket APIs over popular SQL engines (PostgreSQL, MySQL/MariaDB, SQLite, etc.). A no-code admin interface streamlines data modeling, content management, and granular permission control, while the built-in Flows automation engine orchestrates event-driven workflows. Its container-friendly architecture integrates smoothly, enabling platform teams to manage content and metadata without backend overhead or vendor lock-in. Directus also supports custom extensions, single sign-on, and various storage adapters, offering flexible, production-ready deployments.
## Chkk Coverage
### Curated Release Notes
Chkk curates Directus release notes, highlighting critical operational changes like API deprecations or significant permission model updates. Platform teams receive targeted insights instead of manually parsing lengthy changelogs, enabling proactive preparation for essential configuration adjustments. Important breaking changes, such as major authentication model shifts or integration removals, are flagged explicitly. This focused approach ensures timely and smooth upgrades.
### Preflight & Postflight Checks
Chkk performs preflight checks validating database and Node.js runtime compatibility, schema integrity, and deprecated configurations before Directus upgrades. Postflight checks confirm successful database migrations, healthy container status, and consistent API behavior immediately after upgrades. These comprehensive checks proactively identify migration failures or configuration issues, reducing production impact. This structured validation streamlines Directus version transitions, enhancing reliability.
### Version Recommendations
Chkk continuously monitors Directus version lifecycles, identifying risks associated with running outdated or unsupported versions. Alerts are generated when versions near end-of-life, highlighting potential security and compatibility issues. Chkk suggests stable and community-vetted upgrade paths, factoring known issues and community feedback. This guidance helps platform engineers strategically time upgrades for optimal stability and support.
### Upgrade Templates
Chkk provides detailed templates covering both in-place and blue-green upgrades for Directus deployments via Docker, Helm, or manifests. In-place templates address straightforward container updates and automated database migrations, minimizing downtime. Blue-green upgrade templates outline parallel deployments, schema validation, and incremental traffic migration strategies. These best-practice guides integrate seamlessly with GitOps and CI/CD pipelines, reducing operational risk during upgrades.
### Preverification
Chkk’s preverification simulates Directus upgrades in isolated environments, replicating database migrations and configuration application processes. It identifies issues such as schema conflicts, extension incompatibilities, or resource constraints prior to actual production deployments. By validating upgrade scenarios beforehand, platform engineers can address potential problems early. This proactive testing significantly improves upgrade reliability and operational confidence.
### Supported Packages
Chkk supports multiple Directus deployment methods, including Helm charts, YAML manifests, and Docker-based setups. It respects custom configurations, private registries, and extension integrations to preserve environment consistency. Chkk seamlessly interfaces with existing GitOps-managed repositories, providing targeted manifest updates and version-aligned recommendations. This ensures flexibility without disrupting established deployment workflows.
## Common Operational Considerations
* **Cache and Session Consistency:** Deploy a shared Redis instance for multi-instance setups to ensure synchronized caches and consistent user sessions. Without Redis, instances risk inconsistent data or event states.
* **Database Migration Backups:** Always back up your database before upgrading Directus, as automated migrations may partially fail or produce unexpected outcomes. Test migrations against a staging database copy first.
* **Extensions and API Changes:** Review and update custom Directus extensions before upgrading, as internal APIs and required Node.js versions frequently change. Neglecting this may cause extensions or features to malfunction.
* **Configuration Changes:** Regularly review Directus environment variables during upgrades, as missing or changed variables can disrupt essential functionality. Maintain version-controlled configurations to prevent deployment inconsistencies.
* **File Storage Migration:** Use persistent or externalized file storage (S3 or Persistent Volume) to retain media files across Directus upgrades or migrations. Failing to preserve file storage can result in broken media links.
* **Resource Allocation:** Ensure adequate CPU and memory allocations, especially for high-load operations or after feature-heavy updates. Under-provisioning resources can cause performance degradation or application crashes.
## Additional Resources
* [Directus Documentation](https://directus.io/)
* [Directus Releases](https://github.com/directus/directus/releases)
# Dynatrace Operator
Source: https://docs.chkk.io/projects/dynatrace-operator
Chkk coverage for Dynatrace Operator. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v0.9.1"
export const ChecksMinVer_0 = "v0.12.1"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Dynatrace Operator Overview
Dynatrace Operator automates deployment and lifecycle management of Dynatrace monitoring components—OneAgent and ActiveGate—within Cloud Native environments. By introducing the DynaKube custom resource, the operator uniformly instruments workloads and nodes, consolidating metrics, logs, and traces. It supports both host-level monitoring through daemonsets and application-level injection directly into pods, eliminating manual instrumentation overhead. Additionally, ActiveGate acts as a local proxy, enabling API monitoring and efficient metrics routing. Overall, Dynatrace Operator provides automated, scalable observability with minimal operational overhead.
## Chkk Coverage
### Curated Release Notes
Chkk monitors official Dynatrace Operator release notes, highlighting critical operational changes such as metric renaming, CRD updates, and known upgrade issues. Instead of reviewing all upstream details, Chkk provides targeted summaries specific to your environment. For instance, it alerts you if upcoming releases alter cluster metric dimensions or update DynaKube CRDs requiring configuration adjustments. Chkk also flags known bugs—like past CSI driver termination issues—ensuring proactive remediation. This curated guidance reduces surprises and streamlines operator updates.
### Preflight & Postflight Checks
Chkk’s preflight checks validate cluster readiness, ensuring compatibility, proper CRD versions, and correct prerequisites (network egress, RBAC, SCC). It identifies deprecated fields in your existing DynaKube resources, preventing configuration mismatches during upgrades. Postflight checks confirm successful upgrades by monitoring operator and component pod health, verifying full OneAgent deployment, and detecting residual issues like orphaned pods. This thorough process maintains consistent monitoring coverage before and after upgrades, significantly reducing operational risk.
### Version Recommendations
Chkk proactively tracks Dynatrace Operator’s lifecycle, notifying you when versions approach end-of-life or fall behind recommended releases. It provides targeted upgrade suggestions based on stability, community feedback, and Dynatrace’s official support matrix. If your current operator version lacks critical patches or becomes incompatible with newer APIs, Chkk clearly communicates associated risks. Furthermore, Chkk accommodates custom support policies, allowing tailored recommendations aligned with your organization's needs. This approach ensures you balance upgrade urgency against operational stability.
### Upgrade Templates
Chkk supplies detailed Upgrade Templates outlining clear, repeatable steps for both in-place and blue-green (canary) upgrade strategies, aligned with Dynatrace best practices. Templates include precise commands, validation checkpoints, and rollback instructions, suitable for GitOps or CI/CD integration. For conservative deployments, blue-green templates guide staged rollouts with built-in rollback points, ensuring minimal disruption. By providing structured upgrade paths, Chkk reduces human error and operational uncertainty, enabling confident, safe operator updates.
### Preverification
Chkk’s Preverification simulates Dynatrace Operator upgrades in isolated environments to detect potential issues like CRD schema conflicts or resource constraints. It mirrors your existing DynaKube configuration, performing dry-run upgrades and monitoring closely for runtime errors or resource usage spikes. Issues identified—such as stricter CRD validations or RBAC permission changes—are reported before production impact occurs, allowing timely remediation. Preverification significantly reduces upgrade risk by ensuring operational readiness before live deployments.
### Supported Packages
Chkk seamlessly integrates with all common Dynatrace Operator deployment methods, including Helm, YAML manifests, and OperatorHub installations. It respects your customizations, such as private registry images, tailored RBAC permissions, and specific CRD configurations, ensuring smooth transitions during upgrades. If configurations differ between clusters (e.g., Helm vs. OperatorHub), Chkk consistently supports each scenario without imposing workflow changes. This flexibility ensures operational consistency, minimizing friction across heterogeneous cluster environments.
## Additional Resources
* [Dynatrace Operator Documentation](https://dynatrace.com/support/help/shortlink/dynakube-operator)
* [Dynatrace Operator Releases](https://github.com/Dynatrace/dynatrace-operator/releases)
# Elasticsearch (ECK) Operator
Source: https://docs.chkk.io/projects/eck-operator
Chkk coverage for Elasticsearch (ECK) Operator. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v2.1.0"
export const ChecksMinVer_0 = "v2.8.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Elasticsearch (ECK) Operator Overview
Elasticsearch (ECK) Operator is Elastic's official operator for managing Elasticsearch, Kibana, and other Elastic Stack components. It automates stateful operations using custom resource definitions (CRDs), ensuring consistent deployment, scaling, and upgrades. Platform engineers benefit from built-in best practices, such as automatic TLS certificate management, RBAC setup, and rolling upgrades. The operator proactively monitors cluster health, managing tasks like node replacement or shard reallocation without manual intervention. By simplifying the Elastic lifecycle, ECK reduces operational overhead while ensuring reliability and consistency in large environments.
## Chkk Coverage
### Curated Release Notes
Chkk provides curated summaries of ECK release notes, highlighting critical operational impacts like compatibility changes, new features, or deprecated configurations. If ECK removes support for older Elasticsearch versions or introduces mandatory configuration changes, Chkk clearly flags these details. Engineers receive targeted notifications—such as required Kubernetes version upgrades or new CRDs—allowing proactive maintenance. This streamlined insight prevents platform engineers from manually parsing lengthy upstream release logs, focusing instead on actionable information.
### Preflight & Postflight Checks
Chkk performs preflight checks prior to upgrades, validating Elastic versions, CRD compatibility, and deprecated configurations. It warns of unsupported multi-version jumps and identifies potential resource conflicts. Post-upgrade, Chkk verifies operator health, checks Elasticsearch cluster statuses, and detects stalled pod restarts. Automated issue detection like webhook validation errors or resource constraints helps engineers address upgrade anomalies swiftly, minimizing downtime.
### Version Recommendations
Chkk monitors ECK’s support lifecycle, proactively alerting engineers as their installed version nears end-of-life or loses security patch support. It references Elastic’s official support matrix and compatibility guidelines, suggesting stable upgrade paths that balance new features and operational reliability. For example, Chkk warns if your current ECK version lacks support for an upcoming cluster release. Custom support timelines for vendor-specific or forked ECK versions are also respected, ensuring alignment with internal policies.
### Upgrade Templates
Chkk supplies detailed templates for both in-place and blue-green upgrades, embedding Elastic’s recommended best practices. In-place upgrades outline necessary steps like CRD updates, operator deployment changes, and post-upgrade validations. Blue-green upgrades detail dual-operator deployments, namespace isolation strategies, and incremental migration plans for cautious rollouts. Templates explicitly include rollback points and compatibility checks, reducing human error during complex upgrades.
### Preverification
Chkk’s preverification simulates ECK upgrades within a safe staging environment, surfacing conflicts or errors without impacting production. By recreating representative Elastic resources, Chkk identifies potential issues such as CRD mismatches, pod scheduling failures, or RBAC conflicts. Issues encountered during simulation—like resource overconsumption or webhook connectivity failures—are clearly reported. This proactive testing significantly reduces unknown risks in live upgrade scenarios.
### Supported Packages
Chkk seamlessly integrates with various ECK deployment methods, including Helm charts, OperatorHub/OLM, or plain manifests. It adapts upgrade instructions based on your existing deployment, preserving custom configurations and image registries. Whether using cluster-wide or namespace-scoped operators, Chkk provides precise upgrade guidance without disrupting existing workflows. Integration into GitOps or CI/CD pipelines ensures engineers apply upgrade recommendations consistently and efficiently.
## Additional Resources
* [ECK Documentation](https://www.elastic.co/guide/en/cloud-on-k8s/current/index.html)
* [ECK Releases](https://github.com/elastic/cloud-on-k8s/releases)
# Elasticsearch
Source: https://docs.chkk.io/projects/elasticsearch
Chkk coverage for Elasticsearch. We provide curated release notes, preflight/postflight checks, and Upgrade Templates—all tailored to your environment.
export const ReleaseNotesMinVer_0 = "v6.8.3"
export const ChecksMinVer_0 = "v7.9.1"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Elasticsearch Overview
Elasticsearch is a distributed search and analytics engine built on Apache Lucene, widely used for indexing, full-text search, and log aggregation. It organizes data across multiple nodes for horizontal scalability and resilience, automatically replicating and distributing shards to handle node failures. Elasticsearch is typically deployed using operators or Helm/Kustomize, enabling easy scaling and updates in a containerized environment. Thanks to its scale-out design, it can index large data volumes while delivering near real-time query performance.
## Chkk Coverage
### Curated Release Notes
Chkk continuously reads Elasticsearch release notes, highlighting the updates that matter most—such as breaking changes, security patches, or performance enhancements. Operators see a concise, actionable summary rather than combing through lengthy upstream docs. This ensures your team remains aware of potential disruptions or improvements to your environment well in advance.
### Preflight & Postflight Checks
Before any upgrade, Chkk's preflight checks spot deprecated APIs or config changes that could break the cluster. Postflight checks ensure everything is healthy afterward, monitoring cluster status, shard allocation, and performance metrics to confirm no regressions or drift have appeared. By catching issues early and validating cluster state post-upgrade, Chkk prevents prolonged downtime and unexpected data loss.
### Version Recommendations
Chkk tracks ElasticSearch's support lifecycle and alerts you when a version nears end-of-life or has known vulnerabilities. It also considers compatibility, recommending stable, fully supported releases that integrate seamlessly with your cluster. Staying on a tested, up-to-date version helps prevent security gaps and performance bottlenecks from unmaintained code.
### Upgrade Templates
Chkk offers in-place and blue-green upgrade paths, helping you minimize downtime and ensure data integrity. In-place rolling updates sequentially upgrade pods, preserving cluster availability. Blue-green deploys a parallel cluster, letting you cut over once the new version is validated and data is synchronized. This flexible approach accommodates both minor version bumps and major structural changes with minimal risk.
### Preverification
For major or complex upgrades, Chkk's preverification feature tests the process in a controlled environment. It checks your plugins, ingest pipelines, and other integrations against the new version, catching potential incompatibilities before you update the live cluster. This safety net helps teams proceed confidently, knowing the upgrade has been validated for their unique setup.
### Supported Packages
Whether you deploy Elasticsearch via Helm, Kustomize, or raw manifests, Chkk recognizes and manages it. By parsing your existing setup, it ensures that recommended changes and rollouts align with your preferred tooling and that custom images or registries remain compatible. This integration lets you maintain standardized workflows while benefiting from Chkk's automated checks and curated guidance.
## Common Operational Considerations
* **Shard Hotspotting:** If shards aren't balanced across nodes, one node can become overloaded, leading to high latency or node failures. Use allocation awareness (e.g. by zone) and shard routing constraints to distribute load evenly, and periodically check `_cat/shards` for uneven distribution.
* **Slow Queries & Cache Misses:** Complex aggregations or wildcard searches can cause high CPU and slow responses. Enable slow logs to pinpoint problem queries, leverage filters where possible for caching, and avoid repetitive "now" time ranges that invalidate cache.
* **JVM Heap Pressure:** Elasticsearch relies heavily on heap for indexing, caching, and aggregations. Over-allocating heap (e.g., >30 GB) disables compressed object pointers, increasing GC overhead. Monitor old-gen usage and tune circuit breakers to prevent out-of-memory incidents.
* **Snapshot & Disk Constraints:** Snapshots consume I/O, often evicting data from the OS cache, which can degrade search performance. Keep disk usage below watermark thresholds (e.g., \< 85%) to prevent shard relocation or write blocks, and schedule snapshots during lower traffic if possible.
* **Master Node Quorum:** Running fewer than three dedicated master nodes risks split-brain events during network partitions. Always configure quorum-based election (e.g., set `discovery.zen.minimum_master_nodes`) and avoid simultaneous restarts of multiple masters to keep the cluster stable.
## Additional Resources
* [Elasticsearch Documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/index.html)
* [Elasticsearch Releases on GitHub](https://github.com/elastic/elasticsearch/releases)
# External DNS
Source: https://docs.chkk.io/projects/external-dns
Chkk coverage for External DNS. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
export const ReleaseNotesMinVer_0 = "v0.7.3"
export const ChecksMinVer_0 = "v0.8.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## External DNS Overview
External DNS automatically manages DNS records for Services and Ingresses, eliminating the need for manual updates whenever an IP address or hostname changes. By watching the cluster's API for resource changes, External DNS updates records on external providers (e.g. AWS Route 53, Google Cloud DNS, Azure DNS, Cloudflare) in real time. This ensures services remain accessible under consistent domain names without manual intervention, reducing configuration drift and minimizing downtime from outdated DNS entries.
## Chkk Coverage
### Curated Release Notes
Chkk tracks official External DNS releases and distills changes into concise summaries. Operators see highlights of breaking changes, security fixes, and new features relevant to DNS automation, rather than combing through lengthy changelogs. This helps teams quickly assess whether an upgrade might impact configuration flags, provider APIs, or critical security patches.
### Preflight & Postflight Checks
Before an upgrade, preflight checks verify that External DNS is set up correctly—ensuring provider credentials are valid, domain filters or annotations remain compatible, and resource limits are adequate. After the upgrade, postflight checks confirm DNS records synchronize properly and that no new error messages (e.g. API rate limits or authentication failures) appear. This validation guards against misconfigurations that could break record updates.
### Version Recommendations
Chkk continuously monitors External DNS's lifecycle, flagging older releases as they near end-of-life or become incompatible with newer APIs. It suggests stable releases that align with your cluster version and known provider constraints, helping you avoid versions with critical bugs or deprecations. Staying on recommended releases ensures reliable DNS management and reduces the risk of unsupported features.
### Upgrade Templates
Chkk offers two strategies for upgrading External DNS: in-place and blue-green. In-place applies rolling updates to the existing deployment, leveraging rolling strategies to maintain uptime. Blue-green spins up a parallel External DNS deployment, tests it against DNS providers, and cuts over traffic after validation. This method offers near-zero downtime and a straightforward rollback if unexpected issues arise.
### Preverification
For major changes or critical environments, Chkk's preverification simulates the upgrade in a sandbox. It checks whether your DNS provider credentials, flags, or domain filters remain valid on the new version. It also evaluates whether DNS updates succeed without hitting rate limits or lingering propagation delays. This catch-issues-early approach reduces production surprises.
### Supported Packages
No matter if External DNS was deployed with Helm, Kustomize, or raw YAML, Chkk aligns its upgrade steps with your current method. It supports private registries and custom-built images, ensuring that your images, security settings, and Helm/Kustomize overlays remain intact throughout the upgrade. This integration keeps your workflow consistent while benefitting from Chkk's checks and recommendations.
## Common Operational Considerations
* **Ownership Conflicts:** TXT-based ownership prevents ExternalDNS from altering records it doesn't "own." Manually added DNS entries or multiple ExternalDNS instances using the same TXT owner ID can cause record flapping or collisions.
* **RBAC and IAM Gaps:** Missing permissions in RBAC or cloud provider IAM can silently block record changes. Audit the ServiceAccount and associated roles—particularly in multi-tenant, production-grade setups.
* **Garbage Collection Issues:** In "upsert-only" mode, ExternalDNS won't remove obsolete records. Switch to "sync" (with caution), or manually clean DNS zones to avoid stale entries exposing decommissioned services.
* **Large-Cluster Overheads:** ExternalDNS scales poorly if it must track thousands of Services or Ingresses. Use --provider-cache-time and consider filtering by domain, zone ID, or namespace to reduce API calls and memory usage.
* **Multi-Cluster Collisions:** Multiple clusters writing to the same zone must use unique TXT owner IDs or separate subdomains. Otherwise, they risk overwriting each other's records and causing unpredictable DNS behavior.
## Additional Resources
* [External DNS Documentation](https://kubernetes-sigs.github.io/external-dns/latest/)
* [External DNS Releases](https://github.com/kubernetes-sigs/external-dns/releases)
# External Secrets Operator
Source: https://docs.chkk.io/projects/external-secrets-operator
Chkk coverage for External Secrets Operator. We provide curated release notes, preflight/postflight checks, and Upgrade Templates—all tailored to your environment.
export const ReleaseNotesMinVer_0 = "v0.3.0"
export const ChecksMinVer_0 = "v0.4.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## External Secrets Operator Overview
External Secrets Operator (ESO) helps Kubernetes clusters automatically fetch and update secrets from external secret managers such as AWS Secrets Manager, HashiCorp Vault, Azure Key Vault, and others. Rather than storing sensitive data directly in-cluster, platform teams keep passwords and tokens in a secure external store. ESO periodically syncs these values into Kubernetes Secret objects, ensuring applications always have the latest credentials while reducing the risk of accidental exposure. By leveraging custom resources—like ExternalSecret and SecretStore—the operator seamlessly fits into Kubernetes workflows and centralizes secret management practices.
## Chkk Coverage
### Curated Release Notes
Chkk consolidates ESO release notes into concise summaries, highlighting critical changes like new provider integrations, deprecated CRD fields, or security patches. Instead of combing through lengthy changelogs, platform teams see only what matters most—such as API shifts that could break existing ExternalSecret configurations. If a version includes urgent bug fixes or vulnerability patches, Chkk flags those immediately so you can prioritize upgrades accordingly.
### Preflight & Postflight Checks
Before upgrading, Chkk scans your current ESO deployment to detect deprecated fields, validate provider permissions, and confirm CRD compatibility. This proactive check prevents downtime caused by missing credentials or removed APIs. Once the upgrade is complete, Chkk runs postflight checks to ensure the new operator is healthy, verifying that all ExternalSecret resources still reconcile properly. By reviewing logs, events, and status conditions, it alerts you to any remaining issues—like secrets stuck in an error state or misconfigured SecretStores—enabling quick remediation.
### Version Recommendations
Chkk continuously tracks ESO's release cadence and support timelines, surfacing which versions are nearing end-of-life or have known issues. It compares your existing deployment against official EOL announcements and CVE reports, then suggests a stable target release. Chkk balances adopting the latest features with maintaining operational stability, guiding you away from risky versions and steering you to secure, fully supported upgrades.
### Upgrade Templates
For an efficient transition, Chkk provides two upgrade pathways: in-place and blue-green. In-place updates the existing ESO instance directly, minimizing resource overhead but requiring careful monitoring to catch potential regressions. Blue-green, on the other hand, deploys a parallel ESO instance first, letting you verify it before switching over. Both templates include rollback instructions and recommended checks, helping maintain uninterrupted secret synchronization even if unexpected issues arise.
### Preverification
Chkk's preverification feature simulates the upgrade in a controlled environment, applying your actual ExternalSecret and SecretStore definitions against the new ESO version. This dress rehearsal pinpoints schema conflicts, missing permissions, or other incompatibilities before you touch production. With a detailed report of any errors or warnings, you can fix problems and rerun tests until everything works, drastically reducing the risk of failures during live upgrades.
### Supported Packages
No matter how you've installed ESO—via Helm, Kustomize, or raw YAML—Chkk adapts to your existing workflow. It parses Helm values, merges Kustomize overlays, or patches manifests to align with private registries, custom images, and organizational security policies. By automating version bumps and CRD updates within your chosen toolchain, Chkk ensures the entire upgrade process stays consistent, secure, and compliant with your established deployment practices.
### Common Operational Considerations
* **Least-Privilege Credentials:** Restrict ESO's service account to only the external secrets needed. Overly broad permissions can expose sensitive data across the cluster.
* **Validate Secret Syncing:** After upgrades or config changes, confirm each ExternalSecret transitions to Ready. Check events for "Access Denied" or "UpdateFailed" errors.
* **Avoid Overlapping Secrets:** Two ExternalSecrets writing to the same Secret can cause conflicts. Use unique naming or scope secret references carefully.
* **Keep ESO Updated:** New releases often fix provider-specific issues or introduce vital security patches. Chkk flags older versions nearing EOL to prevent running unmaintained code.
* **Network Policy Enforcement:** If you're using Cilium or another CNI with network policies, limit ESO's egress to recognized secret manager endpoints to minimize attack surface.
## Additional Resources
* [External Secrets Documentation](https://external-secrets.io/latest/)
* [External Secrets Releases](https://github.com/external-secrets/external-secrets/releases)
# Fluent Bit
Source: https://docs.chkk.io/projects/fluent-bit
Chkk coverage for Fluent Bit. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
export const ReleaseNotesMinVer_0 = "v1.4.4"
export const ChecksMinVer_0 = "v1.7.9"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Fluent Bit Overview
Fluent Bit is a lightweight log processor and forwarder that ingests logs from multiple sources and routes them to various backends. Written in C, it's highly efficient in CPU and memory usage, which is ideal for large clusters or edge environments. Deployed typically as a DaemonSet, it ensures cluster-wide log collection with minimal overhead. It comes with robust plugin support for filtering, parsing, and outputting logs to systems like Elasticsearch or S3. Since Fluent Bit's defaults can shift between releases, careful upgrades are key to uninterrupted logging.
## Chkk Coverage
### Curated Release Notes
Chkk filters Fluent Bit's upstream release notes to highlight critical fixes, newly deprecated features, and behavior changes affecting your cluster. This helps you quickly identify potential issues like renamed configuration directives, changed default behaviors, or plugin removals. By surfacing only the relevant details, you avoid scanning lengthy upstream logs yourself. Chkk also flags security patches and CVEs tied to new versions. This targeted insight ensures you never miss important updates.
### Preflight & Postflight Checks
Chkk runs preflight checks before you upgrade Fluent Bit to confirm your configuration, plugins, and resource allocations match the requirements for the new release. It looks for deprecated parameters, plugin conflicts, or version gaps that could break logging. Once upgraded, Chkk verifies through postflight checks that the DaemonSet is stable, logs are still flowing, and no errors appear in Fluent Bit metrics or logs. If anything deviates, you get actionable rollback or remediation steps. This two-phase process prevents unnoticed log disruptions.
### Version Recommendations
Chkk continually tracks Fluent Bit's release cycle and flags when your current version nears end-of-life or has security advisories. Suggestions are grounded in proven stability data, rather than just pointing to the latest build. This is critical if certain releases introduce known memory leaks or CPU spikes that haven't been patched yet. By checking multiple sources, Chkk picks the most reliable upgrade path for your environment. You can then align with Fluent Bit's support window and avoid guesswork.
### Upgrade Templates
Chkk offers in-place and blue-green **Upgrade Templates** to preserve logging continuity. An in-place upgrade leverages rolling updates to sequentially replace pods, while blue-green spins up a parallel DaemonSet for canary testing. Both approaches include pause points to validate logs, plus clear rollback procedures if the new version fails. This structured method reduces risk by ensuring no node runs without a collector. It also fits seamlessly with GitOps, letting you keep audit trails for each step.
### Preverification
Chkk's digital twin concept simulates your Fluent Bit upgrade in a controlled sandbox. It replicates your config, plugins, and resource usage to expose issues like changed defaults, plugin mismatches, or performance bottlenecks before they hit production. You can then address errors and retest until the upgrade path is clean. This preverification significantly boosts confidence for major version jumps or complex deployments. By tackling pitfalls in test, you minimize disruptions and quickly revert if unexpected conflicts arise.
### Supported Packages
Whether you deploy Fluent Bit via Helm, Kustomize, or raw manifests, Chkk identifies your current version, suggests an appropriate target, and generates manifest patches. It respects private registries, custom images, and internal forks. For GitOps workflows, changes are surfaced as minimal diffs that you can version-control. This approach keeps your Fluent Bit installation method consistent and reduces manual overhead in switching tooling.
## Common Operational Considerations
* **High Log Volume & Resource Tuning:** Enable disk-based buffering and configure Mem\_Buf\_Limit if logs spike to avoid data loss or node pressure. Multi-worker outputs and tuned flush intervals can also manage throughput more efficiently.
* **Plugin & Configuration Compatibility:** New Fluent Bit releases can rename or remove config keys, so always review release notes or perform a dry-run before going live. Plugins built for previous versions may break if underlying APIs changed.
* **Monitoring & Troubleshooting:** Expose Fluent Bit metrics to detect bottlenecks, high retries, or memory leaks. Check logs and readiness/liveness probes for early signs of a stalled or misconfigured log pipeline.
## Additional Resources
* [Fluent Bit Documentation](https://docs.fluentbit.io/manual)
* [Fluent Bit Releases](https://github.com/fluent/fluent-bit/releases)
# Gloo Edge OSS
Source: https://docs.chkk.io/projects/gloo-edge-oss
Chkk coverage for Gloo Edge OSS. We provide curated release notes, preflight/postflight checks, and Upgrade Templates—all tailored to your environment.
export const ReleaseNotesMinVer_0 = "v1.13.0"
export const ChecksMinVer_0 = "v1.14.19"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Gloo Edge OSS Overview
Gloo Edge OSS is an Envoy-based gateway that manages traffic routing, transforms, and integrations across clusters and legacy systems. It unifies API gateway capabilities (like authentication and rate-limiting) with flexible route configuration. By aggregating services and functions under one control plane, Gloo Edge streamlines operations in modern app environments. It can also handle secure east-west traffic between microservices. Operators use Gloo Edge to future-proof their architectures while maintaining low latency and high extensibility.
## Chkk Coverage
### Curated Release Notes
Chkk surfaces the most critical changes from Gloo Edge release notes so you can quickly see new features, fixes, or major shifts. It flags relevant deprecations or default behavior changes that might affect your clusters. These curated notes cut through the noise and focus on operational impact. They also map each item to your environment for direct relevance. As a result, you're never caught off guard when a key config field or CRD is updated.
### Preflight & Postflight Checks
Before upgrading Gloo Edge, Chkk's preflight checks examine your cluster, CRDs, and configurations for compatibility and deprecations. After upgrading, postflight checks confirm the new control plane is healthy, routes are correct, and no Envoy rejections have occurred. This reduces the risk of sudden downtime or unexpected traffic behavior. By automating this validation, you gain a quick turnaround on identifying issues. The checks provide step-by-step guidance to fix them before they become production outages.
### Version Recommendations
Chkk tracks Gloo Edge release schedules and support timelines, notifying you when your current version goes EOL or loses patch coverage. It provides guidance on stable upgrade targets, matching your Kubernetes version and other dependencies. This avoids unsupported states or risky leaps between releases. Chkk's recommendations are continually updated so you can plan upgrades proactively. That way, you stay current with minimal disruption.
### Upgrade Templates
Chkk provides in-place and blue-green upgrade templates for Gloo Edge that build on official best practices and incorporate safety checkpoints and rollbacks. With in-place upgrades, you sequentially update the Gloo Edge control plane, validate cluster health, then roll out Envoy data planes to minimize traffic disruption. Meanwhile, blue-green upgrades guide you to deploy a parallel set of Gloo Edge components (control plane and proxies) on the new version and migrate traffic gradually, ensuring the older version remains available if issues arise. These automated workflows catch configuration drift and errors early, so you can revert smoothly when needed. By standardizing each step of the upgrade, Chkk removes guesswork and helps maintain consistent results across large environments.
### Preverification
With **Preverification**, Chkk simulates your Gloo Edge upgrade in a staging environment, using the same CRDs and configs as production. This reveals any blockers—like incompatible fields or resource constraints—before the real deployment. It also estimates the potential runtime impact in terms of CPU, memory, or performance. If errors appear, you can fix them well ahead of time. **Preverification** essentially de-risks large environment changes by surfacing issues in a controlled test run.
### Supported Packages
Chkk supports Gloo Edge installed via Helm, Kustomize, or plain manifests, automatically detecting your deployment method. It adapts its checks and upgrade flow to match how you're currently managing Gloo Edge—be it GitOps-based YAML or a Helm chart in a private registry. Custom-built or vendor-specific images are also recognized and tracked during upgrades. This flexibility ensures you can maintain your existing provisioning workflow while gaining consistent oversight from Chkk.
## Common Operational Considerations
* **Running Supported Versions:** Gloo Edge typically supports the current release plus three prior minor versions. Plan upgrades to avoid losing security patches or hitting deprecated APIs without warning.
* **Upgrading Glooctl:** Always match glooctl with your Gloo Edge version so new features or fields don't break older CLI commands. This prevents deployment of invalid configs and reduces friction when debugging.
* **Parallel Deployments:** If you choose a canary rollout, run a second Gloo Edge instance in parallel. Migrate traffic incrementally, observe for errors, and revert if needed.
* **CRD Changes:** Watch for CRD schema updates that may invalidate existing configuration. Ensure custom fields or deprecated routes aren't left behind, which can stop traffic flows or break routing rules.
* **HA Configurations:** Maintain multiple replicas of key components to minimize downtime during rolling upgrades. Check for correct leader-election settings and confirm Envoy pods are gradually updated.
* **Post-Upgrade Verification:** After upgrading, confirm that VirtualServices, RouteTables, and AuthConfigs all have "Accepted" statuses. Monitor logs and metrics (e.g., 5xx spikes) and be ready to roll back if you see critical errors.
## Additional Resources
* [Gloo Edge OSS Documentation](https://github.com/solo-io/workshops/blob/master/gloo-edge/README.md)
* [Gloo Edge OSS Releases](https://github.com/solo-io/gloo/releases)
# Grafana
Source: https://docs.chkk.io/projects/grafana
Chkk coverage for Grafana. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
export const ReleaseNotesMinVer_0 = "v7.1.2"
export const ChecksMinVer_0 = "v7.4.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Grafana Overview
Grafana is an open-source observability platform used for visualizing metrics, logs, and traces from various backends. It provides an interactive UI for creating dashboards, setting alerts, and correlating data across multiple sources. With its extensible plugin system, Grafana connects to a wide array of databases and services. High availability, scalability, and role-based access controls make it suitable for large production environments. Frequent releases introduce new features, security patches, and occasional breaking changes.
## Chkk Coverage
### Curated Release Notes
Chkk keeps watch over Grafana's upstream releases to highlight security patches, deprecated APIs, and new features relevant to your clusters. It condenses verbose changelogs into key operational insights, so you can quickly see what requires attention. Any known issues or breaking changes are flagged early, helping you plan upgrades with minimal guesswork. By highlighting direct impacts to your environment, Chkk takes the guesswork out of tracking Grafana upgrades.
### Preflight & Postflight Checks
Before upgrading, Chkk automatically inspects your Kubernetes version, Grafana config, dashboards, and plugins to confirm compatibility with the new release. It warns you if specific flags, authentication settings, or dependencies will break. Post-upgrade, it verifies that Grafana is fully operational, including data source connectivity and alert rules. These checks reduce the risk of discovering issues only after the change has taken effect.
### Version Recommendations
When your current Grafana version nears end-of-life, Chkk proactively recommends stable upgrade paths, weighing factors like recent security advisories and known bugs. It accounts for the maturity of new features, ensuring you don't jump prematurely to versions lacking broad community validation. Urgent patches are flagged separately if they address critical vulnerabilities. This data-driven approach balances novelty against reliability, giving you a well-rounded upgrade strategy.
### Upgrade Templates
Chkk provides repeatable **Upgrade Templates** for both in-place and blue-green strategies. Each template includes pre-upgrade backups, step-by-step instructions, and health checks to minimize downtime. In-place upgrades streamline the process on smaller clusters, while canary deployments reduce risk by running two versions in parallel. These templates enable a smooth experience whether you're updating a small Dev cluster or a global production environment.
### Preverification
Chkk can perform a full test run of your Grafana upgrade in a representative "digital twin" environment. It copies your configuration, dashboards, and data sources to detect any plugin or schema issues before touching production. Failures in the simulated upgrade guide you to fix configurations or resource constraints. By isolating possible pitfalls early, you avoid disruptive surprises on live clusters.
### Supported Packages
Chkk accommodates Grafana deployments via Helm, Kustomize, or straight manifests. It understands custom images, private registries, and specialized builds, so you can maintain existing workflows without compromise. If using GitOps, Chkk can analyze your manifests and automatically propose changes needed for safe upgrades. This unified approach helps ensure consistency and compliance across all environments you manage.
## Common Operational Considerations
* **Performance Optimization:** Use caching or downsampling to prevent slow queries, and allocate sufficient CPU/memory to Grafana. Monitor its internal metrics to detect bottlenecks early.
* **Plugin & Data Source Management:** Keep plugins updated to compatible versions and restrict who can install them. Validate connectivity and credentials periodically, especially after upgrades.
* **Alerting Best Practices:** Create clear alert rules with meaningful thresholds to avoid noise. Ensure redundant notification channels and apply silences during maintenance windows.
* **Storage & Retention:** Use MySQL/PostgreSQL in production for Grafana's database, and back it up routinely. Align retention policies with your observability stack to avoid data mismatches.
* **Scaling Strategies:** Deploy multiple Grafana instances with a shared database for HA, and shard heavy queries or dashboards if needed. Use load balancing to distribute user sessions effectively.
* **Security & RBAC:** Integrate with SSO to enforce centralized authentication, and limit admin roles. Secure data source credentials and network access to protect sensitive observability data.
## References
* [Grafana Documentation](https://grafana.com/docs/)
* [Grafana Releases](https://github.com/grafana/grafana/releases)
# Grafana Loki
Source: https://docs.chkk.io/projects/grafana-loki
Chkk coverage for Grafana Loki. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v2.4.0"
export const ChecksMinVer_0 = "v1.6.1"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Grafana Loki Overview
Grafana Loki is a cost-effective, multi-tenant log aggregation system that indexes only metadata (labels). It uses microservices (distributor, ingester, querier, etc.) that can scale horizontally to handle high-ingestion environments. Logs are compressed and stored in an object store (S3, GCS, etc.), making Loki cheaper to operate than most traditional logging solutions. Deployed alongside Promtail or other agents, Loki can unify and centralize logs across clusters. With minimal indexing overhead and flexible queries via LogQL, it's ideal for large-scale log monitoring.
## Chkk Coverage
### Curated Release Notes
Chkk distills Loki's official release notes into actionable insights for your team. Instead of wading through every detail, you'll get a curated summary highlighting changes that matter most. Critical bug fixes, new features, and security patches are called out clearly. Chkk also flags any deprecations, like removed config fields or schema changes, to show potential impacts on your environment. Crucial end-of-life announcements and support policy shifts are included as well.
### Preflight & Postflight Checks
Chkk mitigates upgrade risks by running thorough preflight checks before any Loki version upgrade. It verifies compatibility, ensures resources meet new Loki's requirements, and flags deprecated fields. After applying the new version, Chkk's postflight checks confirm that log ingestion, storage, and alert rules remain healthy. Any anomalies, such as data corruption or mismatched config keys, are flagged for quick remediation. This automated process acts as a safety net to prevent downtime and missing logs.
### Version Recommendations
Chkk tracks Loki's release lifecycle and identifies stable, well-supported production versions. It alerts you when your current Loki version is risky or nearing EOL, suggesting a suitable upgrade target. By balancing feature adoption with known issues, Chkk helps avoid blindly jumping to releases that may be unstable. These recommendations ensure you stay within official support timelines without missing critical patches. Chkk acts like a watchdog, guiding you to the best version for your cluster.
### Upgrade Templates
Chkk offers detailed **Upgrade Templates** for in-place and blue-green upgrades, each with step-by-step instructions. In-place upgrades roll your existing deployment forward, while blue-green runs a new Loki version in parallel. Both methods include hold points for validation and explicit rollback steps if ingestion or queries fail. This process integrates with your GitOps or CI/CD flow, reducing human error and streamlining major transitions. By following these templates, you can manage Loki upgrades confidently with minimal downtime risk.
### Preverification
Chkk's preverification simulates your Loki upgrade in a staging environment, using your actual config and sample data. It detects schema conflicts, index format mismatches, or increased resource demands before impacting production. By surfacing errors in a digital twin, you can address them early and refine your upgrade plan. This no-surprises approach reduces downtime and ensures a smoother transition when you finally upgrade in production.
### Supported Packages
Chkk supports Loki deployments through Helm, Kustomize, or plain manifests, adapting checks to your chosen method. If using Helm, it highlights changes in values.yaml; if using raw YAML, it identifies which specs to modify. Chkk also accommodates private registries and custom images, preserving consistency across environments. This flexibility ensures you can manage Loki upgrades without restructuring your existing workflows.
## Common Operational Considerations
* **Scaling & Performance:** Deploy distributed Loki components for high ingestion loads. Regularly check ingester capacity and replicate logs to avoid data loss.
* **Storage Optimization:** Use object storage with a suitable backend and retention period. Limit label cardinality to keep indexes efficient.
* **Query Performance:** Encourage narrow LogQL queries and deploy a query frontend for caching and parallelization. Monitor slow queries and adjust resources accordingly.
* **Alerting & Observability:** Keep the Ruler healthy by offloading heavy queries to the query-frontend. Continuously track ingestion, memory usage, and log pipeline errors.
* **Security & Multi-Tenancy:** Enable auth and multi-tenant headers to isolate logs per team. Encrypt data in transit and lock down object store permissions.
## Additional Resources
* [Grafana Loki Documentation](https://grafana.com/docs/loki/latest/)
* [Grafana Loki Releases](https://github.com/grafana/loki/releases)
# HashiCorp Consul OSS
Source: https://docs.chkk.io/projects/hashicorp-consul-oss
Chkk coverage for HashiCorp Consul OSS. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
export const ReleaseNotesMinVer_0 = "v1.8.5"
export const ChecksMinVer_0 = "v1.9.4"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## HashiCorp Consul OSS Overview
HashiCorp Consul OSS provides a distributed service mesh and registry, securing and discovering services across multiple environments. It uses lightweight agents on each node to register local services, perform health checks, and join a cluster of server nodes that maintain global state. Consul offers an optional mTLS mesh (Consul Connect) that centralizes zero-trust policies and traffic encryption without requiring code changes. It also includes a simple key-value store for storing and synchronizing configuration data across the cluster. Overall, Consul helps unify service discovery, security, and configuration into a single platform that scales well in both Cloud Native and traditional data center setups.
## Chkk Coverage
### Curated Release Notes
Chkk analyzes Consul's official release notes and flags only the changes relevant to your cluster's configuration, ACLs, or service catalog. This ensures you catch significant updates (like new Connect features, breaking config changes, or policy shifts) without parsing every minor fix. The curated feed also highlights deprecations, so you can address them before they cause production regressions. Ultimately, this saves time and cuts down the risk of missing critical release info.
### Preflight & Postflight Checks
Chkk's preflight checks validate your cluster's readiness for a new Consul version by confirming server quorum, analyzing deprecated config fields, and verifying the required OS/TLS settings. During upgrades, it ensures you follow best practices (like upgrading servers first in small batches). Postflight checks confirm that all servers re-formed consensus, agents reconnected, and each service's health checks remain green. Together, these guardrails minimize downtime and highlight issues (e.g., misconfigured gossip encryption) before they become incidents.
### Version Recommendations
Consul's support lifecycle can be short, so Chkk actively monitors EOL timelines to recommend safe upgrade targets. It weighs factors like your current version, upcoming patch availability, and known plugin or Envoy compatibility. If you're multiple versions behind, it suggests a stable upgrade path rather than a risky jump to the latest. These recommendations focus on security patch continuity and smooth operational transitions, keeping Consul stable and secure.
### Upgrade Templates
Chkk provides in-place and blue-green upgrade templates that follow HashiCorp's documented steps but integrate safety checkpoints and rollbacks. With in-place upgrades, you update one server at a time, confirm cluster health, then proceed to agents. For blue-green, Chkk helps provision a parallel Consul cluster on the new version and migrate data, letting you switch over incrementally and revert if problems surface. These automated workflows reduce human error and standardize the approach for enterprise-scale Consul deployments.
### Preverification
Chkk can run a simulated Consul upgrade in a test environment that mirrors your production cluster's configurations and data. This "digital twin" quickly exposes issues with agent compatibility, ACL replication, or resource usage that standard checks might miss. By spotting breakages in a safe sandbox, teams can fix them before scheduling the real upgrade. This approach reduces last-minute surprises and dramatically increases confidence in each Consul release.
### Supported Packages
Chkk supports Consul installed via Helm, Kustomize, or plain manifests, automatically detecting your deployment method. It adapts its checks and upgrade flow to match how you're currently managing Consul, whether that's GitOps-based YAML or a Helm chart in a private registry. Custom-built or vendor-specific images are also recognized and tracked during upgrades. This flexibility ensures you can keep your existing provisioning workflow while gaining consistent oversight from Chkk.
## Common Operational Considerations
* **Multi-Datacenter Consistency:** Ensure WAN federation and peering are carefully planned to avoid latency or partition issues, and configure ACL replication at the start if you use Consul Enterprise. Regularly test failover scenarios, especially if services depend on cross-DC discovery.
* **Agent Lifecycle Management:** Automate the joining and removal of Consul client agents to maintain an accurate service registry. Keep configurations consistent (retry\_join, TLS config) so new nodes seamlessly enter the cluster.
* **Service Mesh & mTLS Overheads:** Enable Consul Connect for zero-trust security, but plan for increased CPU usage on Envoy sidecars. Regularly rotate certificates (potentially via Vault) to maintain security compliance.
* **ACL Governance:** Keep policies in version control, and automate token distribution for agents and services. Monitor ACL replication or manually sync across datacenters if relying on OSS-only functionality.
* **KV Store Usage:** Use Consul's key-value store for configs and coordination, but avoid storing large or high-throughput data. Access can be controlled with ACL policies, so confirm your tokens match the intended write/read paths.
## Additional Resources
* [HashiCorp Consul OSS Documentation](https://developer.hashicorp.com/consul/docs)
* [HashiCorp Consul OSS Releases](https://github.com/hashicorp/consul/releases)
# HashiCorp Vault
Source: https://docs.chkk.io/projects/hashicorp-vault
Chkk coverage for HashiCorp Vault. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v1.7.3"
export const ChecksMinVer_0 = "v1.8.6"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## HashiCorp Vault Overview
HashiCorp Vault is a secrets management platform that securely stores credentials, issues dynamic, short-lived secrets, and offers encryption as a service. Fine-grained ACLs dictate who can access or create secrets, with audit logs capturing every request. It provides automatic secret injection, and supports multi-node high availability, plus enterprise-level disaster recovery and replication.
## Chkk Coverage
### Curated Release Notes
Chkk monitors official Vault releases, summarizing essential changes that affect secret storage, auth methods, or policy behavior. This helps teams quickly see whether an update fixes critical security issues, alters CLI flags, or deprecates a particular secrets engine. If a version includes major feature additions—like a new database engine or dynamic secrets capability—Chkk flags those so you can decide whether to adopt them.
### Preflight & Postflight Checks
Before a Vault upgrade, Chkk's preflight checks confirm your setup meets the new version's requirements—validating storage backends, reviewing TLS configs, and checking if currently used secrets engines or auth methods face deprecation. After upgrading, postflight checks verify that Vault is unsealed, auth workflows succeed, and no errors appear in logs. This automation catches common pitfalls (e.g., missed config changes) that can leave Vault sealed or break tokens.
### Version Recommendations
Chkk continuously watches Vault release lifecycles, warning you when your deployed version approaches end-of-life or lacks current security patches. It compares official guidance with your environment—like your Kubernetes version or provider integrations—to recommend stable releases. By following Chkk's prompts, you stay current on security updates and avoid unsupported features that might endanger your secrets.
### Upgrade Templates
For robust Vault upgrades, Chkk supports two upgrade paths: in-place and blue-green. In-place upgrade performs a rolling updates of existing Vault nodes, often done in HA mode. One node is upgraded and joined back to the cluster at a time, preserving active services. Blue-green spins up a parallel Vault cluster (green) at the new version, replicates or copies data, and switches clients once stable. This method keeps downtime near zero and simplifies rollback if issues arise.
Both templates detail steps for backing up data, unsealing nodes, verifying health, and rolling back in case of unexpected regressions.
### Preverification
For major or sensitive updates, Chkk's preverification simulates the Vault upgrade in a safe environment. It replicates your Vault config—auth backends, secrets engines, policies—and applies the new version to spot potential incompatibilities (e.g., a deprecated config parameter, plugin mismatch). This preview helps fix issues early (like adjusting a configuration for a changed API) rather than encountering them mid-upgrade in production.
### Supported Packages
No matter if Vault is installed via Helm, Kustomize, or raw YAML, Chkk parses your manifests (and values) to orchestrate upgrades. It respects private registries, custom Vault images, and organizational security constraints. This ensures Vault's new version is deployed cleanly without requiring you to switch from your preferred packaging approach.
## Common Operational Considerations
* **Unseal & Key Management:** Prefer auto-unseal with a cloud KMS or HSM to eliminate manual key handling delays; if manual unseal is used, securely distribute key shards. Regularly test unseal and rekey procedures to ensure swift recovery during outages.
* **Access Control & Policy Enforcement:** Enforce least privilege with finely scoped ACL policies and retire the root token immediately after initialization. Regularly audit token permissions to prevent over-privileged access and reduce insider risk.
## Additional Resources
* [HashiCorp Vault Documentation](https://developer.hashicorp.com/vault/docs)
* [HashiCorp Vault Releases](https://github.com/hashicorp/terraform/releases)
# Ingress NGINX Controller
Source: https://docs.chkk.io/projects/ingress-nginx-controller
Chkk coverage for Ingress NGINX Controller. We provide curated release notes, preflight/postflight checks, and Upgrade Templates—all tailored to your environment.
export const ReleaseNotesMinVer_0 = "v2.11.0"
export const ChecksMinVer_0 = "v3.15.1"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Ingress NGINX Controller Overview
Ingress NGINX Controller provides a production-ready reverse proxy for Ingress resources, built on the NGINX web server. It dynamically configures routes based on Ingress objects, supporting host, path, and TLS-based routing. Platform teams rely on it to centralize external access, implement custom traffic rules, and perform SSL termination. This controller is known for high performance, flexibility through annotations, and seamless integration with cluster networking. Its active community ensures timely updates and consistent feature enhancements.
## Chkk Coverage
### Curated Release Notes
Chkk filters official release notes to highlight only critical changes like deprecated annotations, default behavior shifts, and new configuration flags. This saves time by consolidating key operational details into a concise summary. It flags changes like stricter path validation rules or security improvements that might require advanced planning. Platform teams can quickly see which features are relevant and how they impact existing setups. By focusing on actionable insights, Chkk helps avoid risks when new versions are adopted.
### Preflight & Postflight Checks
Preflight checks confirm that your Kubernetes version, CRDs, and Ingress configurations remain compatible with the upcoming NGINX release. Chkk identifies any deprecations or upgrades that risk causing downtime. Postflight checks verify whether the new controller is healthy and all Ingress routes function as expected. It detects misconfigurations by examining controller logs, readiness endpoints, and resource usage. This proactive approach avoids rollout failures and quickly flags any lingering issues.
### Version Recommendations
Chkk evaluates each Ingress NGINX release against your cluster's Kubernetes version and usage patterns. It warns when your current version is nearing or past community support, and provides guidance on stable upgrade targets. If a new version introduces security fixes or performance benefits, Chkk highlights these improvements for informed decision-making. It also accounts for real-world feedback on known bugs or regressions. By monitoring EOL dates and new features, Chkk ensures you're on a safe, reliable version.
### Upgrade Templates
Chkk publishes step-by-step procedures for both in-place and blue-green upgrades of the controller. In-place upgrades guide you through a safe rolling update, while blue-green approaches spin up a parallel controller revision for canary testing. These templates include clear rollback steps and recommended monitoring checkpoints. They align with community best practices to minimize disruption. By systematically walking through each stage, platform teams reduce the chance of downtime.
### Preverification
**Preverification** simulates the entire Ingress NGINX upgrade in a dedicated test environment mirroring production. It evaluates whether older Ingress rules, annotations, or resource constraints clash with the new release. Chkk exposes any issues—like invalid config or broken CRDs—before traffic is impacted. This rehearsal approach gives teams the confidence to fix problems early. It's particularly valuable when introducing major changes or toggling advanced NGINX features.
### Supported Packages
Chkk recognizes Ingress NGINX whether deployed via Helm charts, Kustomize overlays, or plain YAML. It aligns checks and upgrades with your specific packaging method, ensuring minimal friction. Custom images or private registries are fully supported, including specialized vendor builds. Chkk also tracks Helm chart versions to verify compatibility with corresponding controller releases. This broad support lets platform teams maintain their preferred deployment strategy without losing coverage.
## Common Operational Considerations
* **Performance and Scalability:** Tune worker processes, keepalive settings, and concurrency limits for high-traffic environments. Scale horizontally with multiple controller replicas and ensure node-level resources support peak throughput.
* **Security and TLS Configuration:** Enforce strong TLS ciphers and upgrade regularly for security fixes. Integrate with cert-manager or external certificate automation to eliminate expired cert risks.
* **Advanced Routing and Configuration:** Use separate IngressClasses for distinct traffic patterns, and carefully handle regex paths and rewrites. Combine custom annotations, ConfigMap overrides, or carefully managed snippets for specialized NGINX settings.
* **Monitoring and Troubleshooting:** Scrape ingress-nginx metrics for real-time insights and set up meaningful alerts. Consult logs for 4xx/5xx error patterns, keep track of pod restarts, and ensure readiness/liveness endpoints are functioning.
* **Multiple Ingress Controllers or Canary Testing:** Split public vs. private traffic across separate controllers for tighter security boundaries. Leverage canary deployments to test new versions or features on a subset of routes before a full rollout.
## Additional Resources
* [Ingress NGINX Controller Documentation](https://docs.nginx.com/nginx-ingress-controller/)
* [Ingress NGINX Releases](https://github.com/kubernetes/ingress-nginx/releases)
# Istio
Source: https://docs.chkk.io/projects/istio
Chkk coverage for Istio. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v1.12.0"
export const ChecksMinVer_0 = "v1.17.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Istio Overview
Istio is an open-source service mesh built on Envoy proxies that manage critical operational features like routing, mutual TLS encryption, and policy controls. By injecting an Envoy sidecar with each workload, Istio allows platform teams to standardize traffic management, security rules, and observability without altering microservices code. Advanced traffic shaping tactics, including canary releases and fault injection, are possible at layer 7, which L3/L4-only networking solutions cannot match. Because Istio centralizes configuration and enforcement, it lets organizations apply zero-trust security policies (such as mTLS by default) and uniform telemetry collection in large-scale clusters without requiring one-off efforts in each application.
## Chkk Coverage
### Curated Release Notes
Chkk monitors and curates the official Istio release notes, flagging new features, breaking changes, or API/CRD deprecations that are specifically relevant to your clusters. Rather than manually parsing every upstream detail, platform teams receive a contextualized briefing focused on operational impact. For example, if Istio 1.24 removes a default behavior—such as retries on HTTP 503 errors—Chkk highlights how this change might alter traffic patterns in your environment. Similarly, if a particular version introduces new CRDs or requires a configuration shift, Chkk pinpoints exactly where your environment could be affected.
### Preflight & Postflight Checks
Before an Istio upgrade, Chkk runs preflight checks that examine your cluster's Kubernetes version, relevant CRDs, EnvoyFilters, and resource constraints to confirm that you are within Istio's official support range. This ensures you do not jump more than one minor release in a single upgrade—a scenario that could lead to unpredictable behavior. The checks also detect deprecated fields—such as older syntax in VirtualService or DestinationRule objects—so you can address them before applying new manifests. After the upgrade, Chkk's postflight checks verify that the new istiod is healthy, analyze Istio injection logs for errors, and monitor for traffic anomalies or pods running mismatched sidecars. This approach simplifies large fleet operations by quickly identifying issues (such as leftover pods running the old proxy version) that could undermine mesh consistency.
### Version Recommendations
Chkk constantly monitors Istio's support timeline and flags when your current version is nearing or has passed its end-of-life. This is crucial for platform engineers who must ensure compliance and maintain up-to-date security patches. By referencing Istio's official support matrix, Chkk explains why certain versions are considered risky—whether due to dropping out of patch availability or incompatibility with specific cluster releases—helping you avoid unplanned downtime caused by outdated APIs. Beyond notifications, Chkk even suggests a stable upgrade target that aligns with both community feedback and Istio's known issues, enabling platform teams to balance the urgency of new features with operational stability.
If you've forked Istio and follow a custom support policy, Chkk accommodates
custom end-of-life (EOL) policies.
### Upgrade Templates
Chkk delivers detailed **Upgrade Templates** for both in-place and blue-green (canary) upgrade methods, reflecting the best practices documented by the Istio project. An in-place upgrade updates the existing control plane directly, followed by rolling restarts of sidecar proxies. In contrast, a blue-green (canary) strategy deploys a new istiod revision, gradually migrates workloads, and retires the old control plane only after verifying stability. These templates integrate seamlessly with GitOps or CI/CD pipelines by providing a clear, step-by-step process complete with rollback points. This approach allows platform teams to confidently adopt either method while reducing the risk of human error that could compromise mesh traffic flows.
### Preverification
**Preverification** is Chkk's "digital twin" approach to rehearsing the entire Istio upgrade in an isolated environment before any production deployment. It spins up a representative cluster—including your existing Istio configurations—and runs every upgrade command in sequence. This detects complications such as CRD conflicts, EnvoyFilter breakages, or resource overconsumption in the new istiod. Because these issues appear during the simulated upgrade rather than in production, you can adjust configurations or resource allocations in advance. Many organizations utilize preverification into their process to ensure each upgrade step passes automated checks, making live deployments more safe.
### Supported Packages
Chkk supports multiple packaging formats for Istio—Helm, Kustomize, or plain YAML—allowing platform engineers to manage Istio just as they do other cluster resources. It respects custom images, private registries, and specialized vendor builds, ensuring your environment remains consistent when transitioning between Istio versions. If you already maintain a GitOps repository for Istio, Chkk can parse those manifests, map them to the appropriate target version, and suggest only the changes necessary for a safe upgrade.
## Common Operational Considerations
* **Traffic Routing Mismatches:** VirtualService and Gateway hosts must align precisely. A mismatch often results in traffic never reaching the intended service, with no obvious error.
* **Sidecar Injection Failures:** Label conflicts or multiple admission webhooks can prevent pods from being injected with Envoy. Watch istiod logs and use istioctl commands to detect any pods that lack a sidecar.
* **Strict mTLS Rollout:** Enabling strict mTLS cluster-wide without verifying all services can block traffic to unmeshed workloads. Use permissive mode first, then tighten once all workloads comply.
* **EnvoyFilter Limitations:** Since EnvoyFilter depends on implementation details, upgrades can break custom filters. Prefer stable APIs like WasmPlugin or Telemetry whenever possible.
* **Resource Overhead:** Each sidecar consumes CPU and memory. For large clusters, use the Sidecar resource to limit which hosts Envoy must watch, and tune requests/limits for both sidecars and istiod.
* **Canary Upgrades:** Minimize downtime by running multiple Istio revisions in parallel. Canary releases reduce the blast radius if new configuration or CRD changes cause unexpected behavior.
## Additional Resources
* [Istio Documentation](https://istio.io/latest/docs/)
* [Istio Releases](https://github.com/istio/istio/releases)
# JFrog Xray
Source: https://docs.chkk.io/projects/jfrog-xray
Chkk coverage for JFrog Xray. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v3.17.4"
export const ChecksMinVer_0 = "v3.27.3"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## JFrog Xray Overview
JFrog Xray is an enterprise-grade software composition analysis (SCA) tool tightly integrated with JFrog Artifactory, enabling continuous artifact and container image scanning for vulnerabilities and license compliance. Xray centralizes vulnerability data and enforces compliance policies at the artifact repository level, allowing proactive risk management across your software supply chain. Supporting various package formats, including Docker, Helm, Maven, and npm, it provides comprehensive visibility into open-source risks. By automatically identifying and mitigating threats, Xray ensures only verified components move through your CI/CD pipeline.
## Chkk Coverage
### Curated Release Notes
Chkk continuously monitors official JFrog Xray release notes, highlighting critical updates, breaking changes, and new features relevant to your environment. Instead of manual parsing, Chkk delivers concise, context-aware summaries, such as compatibility impacts between Xray and Artifactory. This tailored information helps your team anticipate configuration changes and prioritize timely upgrades, avoiding integration disruptions.
### Preflight & Postflight Checks
Chkk runs comprehensive preflight checks, verifying compatibility between your current Xray and Artifactory versions, detecting deprecated configurations, and confirming resource requirements like storage, memory, and database compatibility. Post-upgrade, Chkk validates service health, confirms artifact scanning resumes correctly, and monitors integration with Artifactory. These automated checks immediately surface issues, such as database migration errors or scanning backlogs, ensuring reliable upgrade outcomes.
### Version Recommendations
Chkk tracks JFrog Xray's official support timeline, alerting you proactively when your deployed version approaches end-of-life or lacks critical security updates. Based on JFrog's guidelines and community feedback, Chkk recommends stable target versions balancing new features and operational stability. This approach helps platform teams avoid running unsupported or incompatible Xray-Artifactory pairs, maintaining compliance and security.
### Upgrade Templates
Chkk provides detailed Upgrade Templates for both in-place and blue-green strategies, outlining best practices for single-node (in-place) and HA (rolling upgrade) deployments. These templates include step-by-step instructions, validation checkpoints, and rollback procedures, minimizing downtime and reducing human error. Whether performing straightforward upgrades or rolling updates in high-availability clusters, these templates integrate smoothly with your existing GitOps or CI/CD pipelines.
### Preverification
Chkk's Preverification runs a full rehearsal of the Xray upgrade process in an isolated environment mirroring your configuration and data. This digital-twin approach detects issues like database migration failures, configuration incompatibilities, or unexpected resource usage before production deployment. By proactively addressing these issues, your team can ensure a smooth and predictable upgrade experience.
### Supported Packages
Chkk supports multiple installation methods for JFrog Xray, including Helm charts, Docker containers, and native OS packages, aligning with your existing infrastructure practices. It recognizes custom setups like air-gapped deployments or internal registries, ensuring upgrade recommendations and checks respect your specific environment. This flexibility allows platform engineers to maintain consistent Xray management without significant operational changes.
## Common Operational Considerations
* **Artifactory Integration:** Ensure exact version compatibility between Xray and Artifactory to prevent scanning failures. Regularly validate connectivity, especially after upgrades or network changes, to promptly detect integration issues.
* **Indexing Backlogs:** Monitor RabbitMQ queues and Xray logs for indexing backlogs that stall artifact scanning. Address bottlenecks promptly by restarting affected services or scaling analysis workers.
* **Storage Thresholds:** Track disk usage closely; exceeding the default 80% threshold stops artifact indexing. Plan storage capacity accordingly, adjust usage thresholds, and regularly clear unused data.
* **Initial Sync and Updates:** Ensure sufficient resources and internet connectivity during Xray’s initial vulnerability database sync. Avoid scanning artifacts until initial sync completion to prevent resource contention and synchronization issues.
* **Data Retention:** Configure data retention policies to manage database size and performance effectively. Balance historical insight needs with storage costs and performance considerations.
* **High Availability & Upgrades:** Execute rolling upgrades carefully in HA setups, upgrading nodes individually and verifying each step to prevent conflicts or data corruption. Test upgrades in staging to estimate timing and resource impact accurately.
## Additional Resources
* [JFrog Xray Documentation](https://jfrog.com/help/p/security-home)
* [JFrog Xray Release Notes](https://jfrog.com/help/r/xray-release-information/xray-release-notes)
# jsreport
Source: https://docs.chkk.io/projects/jsreport
Chkk coverage for jsreport. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v2.7.0"
export const ChecksMinVer_0 = "v3.1.1"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## jsreport Overview
jsreport is an open-source reporting server enabling teams to create, generate, and distribute dynamic reports (PDF, Excel, Word, HTML) using web technologies. Developers define report templates with HTML/CSS and JavaScript, supported by an embedded web-based designer (jsreport Studio). Running on Node.js, jsreport offloads document rendering from applications, ensuring consistent reporting across services. Its modular architecture, headless browser rendering, and scripting support make it flexible and powerful in modern cloud environments, integrating smoothly into modern CI/CD pipelines.
## Chkk Coverage
### Curated Release Notes
Chkk curates jsreport release notes to highlight relevant new features, breaking changes, and deprecated functionalities affecting your deployments. Instead of manual checks, platform teams receive targeted summaries, such as sandbox security improvements or deprecated configuration fields. Chkk clearly flags changes, like new sandboxing behavior replacing older libraries, ensuring smooth transitions between versions. This reduces the risk of overlooked details impacting template rendering or system compatibility.
### Preflight & Postflight Checks
Chkk performs preflight checks ensuring your Kubernetes cluster and Node.js versions meet new jsreport prerequisites and flags necessary intermediate upgrades. It also detects deprecated extensions or configuration issues, allowing preemptive corrections. Post-upgrade, Chkk validates deployment health by verifying pods' updated versions, analyzing logs for new errors, and performing sample report renderings. These proactive measures help platform engineers quickly address issues without user impact.
### Version Recommendations
Chkk continuously monitors jsreport releases, advising when versions approach end-of-support. It evaluates your deployment against known vulnerabilities and compatibility issues, recommending stable upgrade paths with clear justifications, like outdated Chrome engines or Node.js runtimes. For customized jsreport forks, Chkk adapts its recommendations to match your specific support policies, ensuring consistent operational stability.
### Upgrade Templates
Chkk provides detailed Upgrade Templates for both in-place and blue-green upgrades aligned with jsreport best practices. In-place upgrades include explicit pre-upgrade backups, configuration adjustments, and rolling restart strategies. Blue-green deployments involve parallel installations to gradually test and validate new versions before switching production traffic. These structured templates integrate seamlessly into GitOps and CI/CD pipelines, minimizing upgrade risks.
### Preverification
Chkk’s preverification creates a realistic rehearsal environment replicating your production jsreport setup, including configurations and templates. Automated upgrade simulations identify potential migration or compatibility issues early, such as resource constraints or template execution errors. This proactive validation allows engineers to refine configurations and resources in staging environments, significantly reducing the risk of production issues.
### Supported Packages
Chkk supports multiple jsreport deployment methods, including Docker images, Helm charts, manifests, Node.js library integrations, and custom binaries. It intelligently analyzes your existing configuration and deployment method, offering precise upgrade instructions and image recommendations. Chkk also accommodates specialized or vendor-specific jsreport versions, ensuring upgrade guidance remains accurate and practical for your environment.
## Common Operational Considerations
* **Persistent Storage:** Use PersistentVolumes or external databases for jsreport storage to maintain templates and reports across pod restarts and upgrades. Shared storage is critical for consistency when scaling multiple instances.
* **Scaling and Load Balancing:** jsreport instances must use identical configurations and shared storage when horizontally scaling behind load balancers. Optimize internal worker threads and monitor CPU; scale horizontally if CPU limits become saturated.
* **Headless Chrome Resources:** Allocate adequate memory and CPU for jsreport's Chrome-based rendering to prevent pod evictions or slowdowns. Consider dedicated Chrome pools or docker-worker extensions for high-volume render environments.
* **Configuration via Environment Variables:** Translate jsreport JSON configuration keys to environment variable formats (e.g., `extensions_fsStore_dataDirectory`). Incorrect formatting can lead to defaults being silently applied.
* **Licensing Management:** Manage jsreport licenses via Secrets or environment variables, ensuring compliance with multi-instance licensing terms. Use `license.development=true` for non-production environments to avoid licensing conflicts.
* **Ingress Path Configuration:** Configure jsreport’s `appPath` correctly when exposing services via an Ingress or reverse proxy at a subpath. Misconfigurations may cause broken URLs and interface issues.
* **Template Compatibility:** Proactively review templates for compatibility issues with new jsreport versions, especially changes in sandbox security or APIs. Test upgrades in staging environments to identify necessary adjustments early.
## Additional Resources
* [jsreport Documentation](https://jsreport.net/learn)
* [jsreport Releases](https://github.com/jsreport/jsreport/releases)
# Kafka UI
Source: https://docs.chkk.io/projects/kafka-ui
Chkk coverage for Kafka UI. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v0.2.1"
export const ChecksMinVer_0 = "v0.3.2"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Kafka UI Overview
Kafka UI is an open-source web interface for monitoring and managing Apache Kafka clusters, providing real-time visibility into brokers, topics, partitions, producers, and consumers. It simplifies common Kafka tasks, such as message inspection, topic management, and consumer group monitoring, without relying on CLI tools. Kafka UI supports multi-cluster management, enabling a unified view of multiple Kafka clusters from a single dashboard. Platform teams benefit from centralized administration, streamlined troubleshooting, and improved operational efficiency.
## Chkk Coverage
### Curated Release Notes
Chkk continuously monitors Kafka UI release notes, highlighting critical updates that impact your clusters. Rather than manually reviewing release details, teams receive concise briefings on relevant enhancements or breaking changes, such as RBAC improvements or critical security patches (e.g., CVE fixes). Chkk also flags subtle adjustments, like configuration property renames or default behavior shifts. This ensures teams remain informed about operational impacts without extensive manual analysis.
### Preflight & Postflight Checks
Chkk's preflight checks verify your Kafka UI deployment is upgrade-ready by identifying deprecated configurations, unsupported version jumps, and connectivity prerequisites. Postflight checks confirm new Kafka UI instances connect successfully to Kafka clusters, inspecting logs for authentication or connectivity issues. This validation process promptly identifies upgrade-related issues, allowing timely remediation.
### Version Recommendations
Chkk tracks Kafka UI releases and triggers alerts when a deployed version slips beyond the recommended production support window. As part of recommendations, Chkk surfaces all the security and operational considerations present in upcoming versions, highlighting key details such as CVE patches and breaking changes. Chkk also flags community or maintainer shifts (e.g., forks or project transitions), ensuring teams select stable upgrade targets. Customized internal support policies or forks can also be integrated into Chkk's recommendations.
### Upgrade Templates
Chkk provides structured Upgrade Templates for Kafka UI, detailing step-by-step procedures for in-place and blue-green upgrade strategies. In-place templates guide straightforward upgrades through Helm charts or container deployments, emphasizing configuration backups and low-impact rollout schedules. Blue-green templates facilitate parallel deployments, enabling comprehensive validation of new Kafka UI instances before transitioning traffic. These templates integrate smoothly with GitOps and CI/CD pipelines, reducing operational risk and minimizing human error.
### Preverification
Preverification involves Chkk’s "digital twin" method, performing Kafka UI upgrades in isolated test environments that mirror production settings. This rehearsal identifies configuration, connectivity, or resource issues before live deployment, such as misconfigured environment variables or insufficient resource limits. Preverification highlights errors (e.g., API incompatibilities or deserialization problems) that could disrupt production environments. Teams can proactively address issues discovered during preverification, significantly reducing upgrade risk.
### Supported Packages
Chkk supports diverse Kafka UI deployment methods, including Helm charts, Docker containers, and plain manifests. It adapts seamlessly to your existing deployment configuration, identifying precise image tags, ConfigMaps, or Helm values requiring updates. Chkk respects customizations like private registries or vendor-specific builds, ensuring compatibility and consistency across Kafka UI upgrades. This flexibility enables teams to manage Kafka UI efficiently within their existing operational frameworks.
## Common Operational Considerations
* **Cluster Connection Configurations:** Misconfigured Kafka endpoints or credentials in Kafka UI cause clusters to appear offline or crash the UI. Always validate connections through Kafka UI’s built-in checks before saving configurations.
* **Authentication and Access Control:** Running Kafka UI without authentication is insecure; implement OAuth/OIDC, LDAP, or basic authentication. After upgrades, carefully verify authentication and RBAC settings, as property names may have changed.
* **Network & TLS Connectivity:** Incorrectly configured TLS certificates or missing CA truststores often prevent Kafka UI from connecting to secured Kafka brokers. Confirm Kafka UI’s cluster status after network or security updates to quickly identify issues.
* **Large Cluster Performance:** Kafka UI can slow down when handling clusters with many topics or high message volumes. Regularly monitor resource usage and optimize performance by hiding internal topics or limiting message-fetching operations.
* **Audit Logging:** Enable Kafka UI's audit logging in multi-user environments to maintain a secure record of user actions. Ensure logs are securely stored and retained appropriately for compliance and troubleshooting.
* **High Availability:** Deploy Kafka UI with multiple replicas behind a load balancer to prevent downtime. Avoid public internet exposure; restrict access to secure internal networks or VPNs to safeguard administrative operations.
## Additional Resources
* [Kafka UI Documentation](https://github.com/provectus/kafka-ui)
* [Kafka UI Releases](https://github.com/provectus/kafka-ui/releases)
# Kargo
Source: https://docs.chkk.io/projects/kargo
Chkk coverage for Kargo. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v0.2.0"
export const ChecksMinVer_0 = "v0.3.1"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Kargo Overview
Kargo is a GitOps-focused orchestration tool enhancing Argo CD by automating multi-stage deployments. It uses custom resources (CRDs) like `Project`, `Warehouse`, `Stage`, and `PromotionTask` to enforce controlled promotion policies across environments. Platform teams define promotion rules declaratively, eliminating manual scripts and enabling consistent, reliable deployments from development through production. By coordinating promotions and integrations with Argo CD and Argo Rollouts, Kargo ensures stable, auditable, and automated software delivery.
## Chkk Coverage
### Curated Release Notes
Chkk monitors Kargo releases, highlighting critical changes, new features, and API deprecations relevant to your environment. It summarizes key impacts, such as CRD migrations or webhook introduction for artifact discovery. This approach allows platform engineers to quickly assess and manage necessary adjustments, ensuring smooth transitions and avoiding disruptions due to overlooked details.
### Preflight & Postflight Checks
Chkk performs preflight checks verifying Kargo dependencies, ensuring version compatibility and highlighting necessary intermediate upgrades or deprecated API usage. Postflight checks validate that Kargo components and promotion workflows operate correctly post-upgrade, quickly identifying issues such as stuck promotions or CRD conflicts. This comprehensive verification approach ensures operational stability across environments.
### Version Recommendations
Chkk proactively flags outdated Kargo versions, recommending stable upgrades based on community feedback and release cadence. It highlights risks associated with unsupported or legacy features, suggesting optimal target versions to maintain reliability and avoid production issues. This guidance helps platform teams balance adopting new features with maintaining operational stability.
### Upgrade Templates
Chkk provides detailed, step-by-step Upgrade Templates for Kargo, supporting both in-place and blue-green upgrade methods. These templates integrate seamlessly with existing GitOps or CI/CD workflows, incorporating rollback steps and validation points. Platform engineers can confidently manage upgrades with minimal risk, ensuring continuity and reliability in deployment operations.
### Preverification
Chkk's Preverification simulates Kargo upgrades in isolated environments, detecting issues like CRD conflicts, resource misconfigurations, or unexpected pipeline behaviors before production deployment. This "digital twin" strategy identifies upgrade pitfalls early, enabling corrective actions to be taken safely in advance. It significantly reduces the risk and complexity of actual production upgrades.
### Supported Packages
Chkk supports various installation methods for Kargo, including Helm, Kustomize, and raw YAML manifests. It respects custom configurations such as private registries or tailored Helm charts, accurately mapping required changes for safe upgrades. This flexibility allows platform engineers to seamlessly integrate Kargo upgrades into their existing management processes.
## Common Operational Considerations
* **Argo Rollouts Integration:** Ensure Argo Rollouts is deployed when using Kargo's analysis-based promotions; missing components can silently skip critical verification steps.
* **Warehouse Polling vs. Webhooks:** To prevent registry strain and promotion delays, prefer webhook-driven artifact discovery complemented by reduced polling intervals.
* **Project Deletion Cleanup:** Deleting a `Project` also removes its namespace; use the namespace retention option in critical environments to avoid unintended downtime.
* **Project CR Requirement:** Kargo requires a `Project` CR for promotions; missing this CR will halt all automated promotion activity.
* **Warehouse Configuration Errors:** Verify Warehouse configurations carefully, as misconfigured repo URLs or tag filters prevent artifact detection and halt promotions silently.
* **Argo CD Authorization:** Kargo-driven Argo CD syncs require explicit annotations (`kargo.akuity.io/authorized-stage`) to prevent unauthorized deployment errors.
## Additional Resources
* [Kargo Documentation](https://docs.kargo.io/)
* [Kargo Releases](https://github.com/akuity/kargo/releases)
# Karpenter
Source: https://docs.chkk.io/projects/karpenter
Chkk coverage for Karpenter. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
export const ReleaseNotesMinVer_0 = "v0.21.0"
export const ChecksMinVer_0 = "v0.24.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Karpenter Overview
Karpenter is a flexible, high-performance autoscaling solution designed to optimize pod scheduling and node provisioning. Developed with Cloud Native principles, it uses real-time data from pending pods to create or scale nodes that precisely match workload requirements. By leveraging cloud provider APIs directly (e.g., AWS EC2), Karpenter can provision compute resources with minimal startup delays, reducing both over-provisioning and under-utilization. Platform teams benefit from the dynamic nature of Karpenter: as workloads fluctuate, it scales just enough capacity to maintain performance without driving up unnecessary cloud costs. Karpenter's approach also supports spot instances, custom AMIs, and advanced scheduling rules that integrate seamlessly with existing cluster configurations.
## Chkk Coverage
### Curated Release Notes
Chkk tracks official Karpenter release notes, aggregating crucial new features, bug fixes, and deprecations. Instead of manually reviewing each release, platform engineers receive a summary of changes likely to affect day-to-day operations—such as newly introduced provisioner fields, improvements in startup latency, or modifications to AWS-specific node templates. Chkk also flags any deprecated APIs (for example, if certain spec fields are removed in later versions) so that you can adjust your cluster configuration before issues arise.
### Preflight & Postflight Checks
Before upgrading Karpenter, Chkk runs preflight checks that validate whether your cluster and cloud environment meet the new version's requirements. It inspects any Karpenter-specific CRDs, verifying that your provisioner configurations, constraints, and cloud credentials align with the upgrade. For example, if a new release enforces stricter node label formats or changes default instance types, Chkk identifies these configurations in your cluster.
After upgrading, postflight checks confirm the new Karpenter controller is healthy, verify that node provisioning logic is working correctly, and look for any pending pods that remain unscheduled due to misconfigurations. This helps ensure you don't discover broken autoscaling behavior only after hitting production load.
### Version Recommendations
Chkk tracks Karpenter's release cadence and support windows, highlighting versions nearing end-of-life or known to conflict with certain Cloud Native environments releases. By mapping your current cluster environment—Kubernetes version, node OS images, or usage of spot vs. on-demand nodes—Chkk suggests a stable upgrade path. It also flags urgent security or performance fixes that may justify moving up in minor versions sooner rather than later. Chkk Upgrade Copilot keeps your autoscaling system modern and secure without the guesswork.
### Upgrade Templates
Chkk provides a structured guide for upgrading Karpenter, offering two primary strategies: in-place or blue-green. With an in-place upgrade, you update the Karpenter controller and relevant CRDs in place, then closely monitor provisioning logs and cluster metrics to ensure it's functioning well. If you prefer a more conservative approach, the blue-green strategy spins up a new Karpenter controller using a separate deployment or Helm release, allowing you to transition workload provisioning gradually. Chkk's templates detail the step-by-step workflow, roll-back instructions, and recommended checks (like verifying pending pods) at each stage.
### Preverification
For major Karpenter upgrades or large multi-node clusters, Chkk's preverification feature runs a simulated upgrade in a controlled environment. This includes reapplying your existing provisioner specs, checking if new or deprecated fields cause conflicts, and ensuring your cloud provider credentials and IAM roles are still valid. The simulation's feedback loop helps spot tricky scenarios—for example, if the new version relies on a capability your current AWS account setup doesn't grant. By exposing these issues in preverification, you can fix them ahead of time rather than struggling mid-upgrade in production.
### Supported Packages
Chkk supports installing and upgrading Karpenter via Helm, Kustomize, or raw YAML deployments. Whether you're using a private registry with custom-built Karpenter images or relying on public repositories, Chkk's automation can parse your manifests, confirm your current Karpenter version, and propose a precise upgrade plan. This ensures your GitOps or CI/CD pipeline remains intact—Chkk just enriches it with checks, recommended config changes, and best-practice guidance.
## Common Operational Considerations
* **IAM Role Configurations:** Ensure your AWS credentials allow full access to the needed APIs (e.g., EC2, Launch Templates, Auto Scaling). Missing permissions can lead to silent provisioning failures.
* **Right-Sizing Node Templates:** Karpenter thrives on accurate resource requests. Overly large or generic instance selections can rack up costs; overly small ones cause scheduling backlogs. Tune your provisioner and node templates to reflect actual workload needs.
* **Spot vs. On-Demand Balancing:** Karpenter can request spot instances for cost savings. However, be prepared for spot interruptions by configuring pod disruption budgets and ensuring you have an on-demand fallback for critical workloads.
* **Synchronized Scale-Downs:** If you're also using Cluster Autoscaler or other scaling logic, coordinate them carefully. Running multiple autoscaling solutions can create conflicting behaviors unless well-configured.
* **Validate CRDs & Constraints:** Upgrades often add or remove constraint fields (e.g., selecting instance families or specific zones). After upgrading, confirm your constraints still align with available instance types in your target region.
* **Monitor Pending Pods:** A sudden spike in unschedulable pods might indicate Karpenter config changes are out of sync with cluster demands. Use the Cloud Native events or Karpenter logs to debug insufficient instance capacity or misaligned node selectors.
## Additional Resources
* [Karpenter Documentation](https://karpenter.sh/docs/)
* [AWS Karpenter Provider Releases](https://github.com/aws/karpenter-provider-aws/releases)
* [Introducing Karpenter: An Open Source High-Performance Cluster Autoscaler](https://aws.amazon.com/blogs/aws/introducing-karpenter-an-open-source-high-performance-kubernetes-cluster-autoscaler/)
# KEDA
Source: https://docs.chkk.io/projects/keda
Chkk coverage for KEDA. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
export const ReleaseNotesMinVer_0 = "v1.4.1"
export const ChecksMinVer_0 = "v2.1.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## KEDA Overview
KEDA (Kubernetes Event-driven Autoscaler) extends the native Horizontal Pod Autoscaler (HPA) to scale workloads based on external events such as queue depth, database activity, or cloud metrics. By adding its own operator and metrics adapter, KEDA exposes these external metrics to the cluster, allowing pods to dynamically scale up—or even down to zero—when no events are pending. This approach optimizes resource usage, handling spikes automatically and freeing up capacity during idle periods. KEDA supports a wide range of event sources (e.g., Kafka, RabbitMQ, Azure Event Hubs), making it easy to integrate with diverse environments while retaining the standard scaling model.
## Chkk Coverage
### Curated Release Notes
Chkk curates official KEDA release notes, highlighting important updates, deprecations, and security advisories. Instead of going through every changelog, platform teams get a concise summary of changes—like dropped support for older Kubernetes versions or new scalers—that may affect autoscaling configurations. Chkk flags breaking changes and features, helping you prioritize upgrades aligned with your operational needs.
### Preflight & Postflight Checks
Before a KEDA upgrade, Chkk runs preflight checks to detect potential incompatibilities—such as renamed CRD fields, changed scaler parameters, or missing permissions. It also ensures your existing ScaledObjects and TriggerAuthentications will remain valid. After the upgrade, postflight checks confirm that the updated KEDA operator is healthy, verifying event triggers, metrics reporting, and successful pod scaling. Any issues—like broken triggers or pods stuck at zero replicas—are flagged for quick remediation.
### Version Recommendations
Chkk continuously monitors KEDA's release lifecycle and alerts you if your version is nearing end-of-life or has known vulnerabilities. It cross-references compatibility, patch availability, and bug reports to suggest the next stable version. By following Chkk's guidance, you can keep KEDA up to date without risking untested or unsupported releases.
### Upgrade Templates
Chkk offers two main upgrade strategies for KEDA: in-place and blue-green. In-place updates the existing operator, ensuring minimal downtime through a carefully orchestrated restart. Blue-green introduces a parallel "green" deployment of KEDA alongside the old "blue" one, then cuts over once validated—ideal for zero-downtime requirements or major version jumps. Both templates preserve your autoscaling configurations, preventing disruptions to event-driven scaling.
### Preverification
For major or potentially disruptive upgrades, Chkk conducts a preverification process in a controlled environment. It deploys the new KEDA version, applies your existing manifests, and simulates the scaling behavior. This test reveals any problems with event source compatibility, authentication, or changed CRD fields before production, allowing you to address them proactively and reduce deployment risks.
### Supported Packages
Chkk supports KEDA deployments via Helm, Kustomize, or plain YAML. Regardless of your chosen method, Chkk detects and manages the operator's current version, ensuring that upgrades respect custom images or private registries. This integration aligns with typical GitOps workflows, letting you maintain KEDA the same way you handle other cluster resources.
## Common Operational Considerations
* **Scale-to-Zero Latency:** KEDA polls external triggers (e.g., Kafka, Prometheus) every 30s by default. A too-long polling interval leads to cold-start delays. Lower it for latency-sensitive workloads, but watch out for excessive API calls.
* **Trigger Failures:** If a trigger source (like Azure Service Bus) is unreachable or slow, KEDA returns zero metrics. Configure fallback replicas to avoid unintentional scale-to-zero during outages. Monitor operator logs for repeated "failed to fetch metrics" errors.
* **HA Deployment:** Running multiple KEDA operator pods provides failover (single-active leader). The metrics server can also run multiple pods, but only one instance serves external metrics at a time. Give operator and adapter enough CPU/memory for high-volume events.
* **CRD & Config Pitfalls:** Old CRDs or typos in TriggerAuthentication can silently break autoscaling. Always update CRDs alongside the operator, and confirm ScaledObject status is Ready. Use KEDA's admission webhook to prevent duplicate HPAs or invalid triggers.
* **Upgrade Impact:** When jumping major versions (v1→v2), reapply updated CRDs and rewrite any old fields. For minor releases, watch for changes that might invalidate triggers (like renamed fields). Prefer a test cluster or Chkk's preverification feature before production.
## Additional Resources
* [KEDA Documentation](https://keda.sh/docs/latest/)
* [KEDA Releases](https://github.com/kedacore/keda/releases)
# Keycloak
Source: https://docs.chkk.io/projects/keycloak
Chkk coverage for Keycloak. We provide curated release notes, preflight/postflight checks, and Upgrade Templates—all tailored to your environment.
export const ReleaseNotesMinVer_0 = "v12.0.3"
export const ChecksMinVer_0 = "v16.1.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Keycloak Overview
Keycloak is an open-source Identity and Access Management (IAM) solution, providing single sign-on (SSO), identity brokering, and flexible authentication/authorization. It supports OAuth 2.0, OpenID Connect, and SAML 2.0, making it broadly compatible with modern applications and services. Administrators can centrally manage realms, clients, and user policies via a web console, reducing custom code and risk. Keycloak's Quarkus-based runtime simplifies Cloud Native deployments, with clustering support for high availability. Through integration with RBAC, it can secure not just apps but also cluster access.
## Chkk Coverage
### Curated Release Notes
Each Keycloak release often has lengthy notes covering new features, bug fixes, and breaking changes. Chkk curates these details into an operational summary, spotlighting security fixes, schema updates, and any removed features. Instead of parsing every upstream note, you receive quick pointers about potential breakage or critical vulnerabilities. This ensures you don't overlook subtle changes like updated hashing algorithms or token lifespans.
### Preflight & Postflight Checks
Chkk runs automated checks before and after a Keycloak upgrade to confirm version compatibility and overall system health. Preflight checks validate database readiness, any deprecated API usage, and operator or helm chart compatibility. After the upgrade, postflight confirms that the new Keycloak pods, realms, and user flows are functioning correctly. This approach proactively catches common issues—like incomplete schema migrations or leftover outdated configurations—by monitoring logs, session states, and access patterns. As a result, you can upgrade with confidence knowing each stage was thoroughly validated.
### Version Recommendations
Chkk tracks Keycloak's rapid release cadence and flags when your version falls behind on security patches or enters EOL. It references official support policies to warn you about major changes, deprecated features, or community support drop-offs. Chkk recommends stable versions that align with your environment, highlighting known issues. By mapping Keycloak's iteration cycles to your upgrade windows, Chkk keeps deployments secure and compliant.
### Upgrade Templates
Chkk provides **Upgrade Templates** for both in-place and blue-green upgrades, covering database backups, partial rollouts, and canary checks. These instructions include configuration updates, migration tasks, and post-upgrade verifications. Rollback guidelines—such as reverting images or restoring snapshots—are built in. By following these templates, you minimize human error and ensure a safer upgrade path.
### Preverification
Chkk's preverification simulates the upgrade in a separate environment, loading a mirrored database and matching realm configs. It catches issues like incompatible themes, outdated schemas, or broken SPIs before they affect production. The entire upgrade sequence is rehearsed so teams can fix problems in advance. This real-world testing boosts confidence that new Keycloak versions will run smoothly.
### Supported Packages
Chkk works with Helm charts, the Keycloak Operator, Kustomize, and raw manifests. It detects your chosen package method and tailors checks to ensure consistency across installation types. Custom builds and private registries are also recognized, preserving enterprise workflows. Whether official or custom images, Chkk tracks version compatibility and delivers precise upgrade guidance.
## Common Operational Considerations
* **Token Expiration & Refresh:** Configure token lifespans to balance security with usability, and ensure clients handle short-lived tokens appropriately. Monitor refresh rates for anomalies that may indicate client misconfiguration or a need to scale Keycloak.
* **Session Management & Clustering:** Always use shared databases or caches for session consistency across Keycloak pods, and confirm the cluster is healthy after rolling updates. Properly tune memory/CPU resources and session-cleanup intervals to reduce performance bottlenecks.
* **Configuring Realms:** Plan realm counts and structure from the start, avoiding unnecessary complexity or duplication. Consistently manage roles, groups, and policies at the realm level to maintain clarity and reduce upgrade friction.
* **Scaling & Performance:** Scale Keycloak horizontally to handle spikes in authentication load, and ensure the database is equally robust. Use health checks and resource monitoring (CPU/memory) to proactively address performance bottlenecks.
* **RBAC Integration:** Configure Keycloak as an OIDC provider for cluster authentication and map realm groups to K8s roles. Keep a fallback admin credential or separate auth flow to handle Keycloak downtime or misconfigurations.
## Additional Resources
* [Keycloak Documentation](https://www.keycloak.org/documentation)
* [Keycloak Releases](https://github.com/keycloak/keycloak/releases)
# Keycloak Operator
Source: https://docs.chkk.io/projects/keycloak-operator
Chkk coverage for Keycloak Operator. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v13.0.1"
export const ChecksMinVer_0 = "v15.1.1"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Keycloak Operator Overview
Keycloak Operator manages Keycloak instances, enabling automated deployments and configuration via Custom Resources. It simplifies provisioning, upgrades, and maintenance tasks by standardizing deployments through GitOps-friendly manifests. The operator handles persistent storage integration, external databases, custom images, and extensions, ensuring consistent and repeatable IAM management. Advanced lifecycle features include high availability setups, scheduled backups, and compatibility with OpenShift's Operator Lifecycle Manager (OLM). The Keycloak Operator streamlines identity infrastructure, enhancing operational efficiency for platform engineers.
## Chkk Coverage
### Curated Release Notes
Chkk filters Keycloak release notes to highlight impactful changes like new CRDs, breaking configuration updates, or critical operational adjustments. Engineers receive tailored insights on updates such as stricter default network policies or deprecated CR fields. This context-specific summary helps proactively address potential impacts before upgrades, ensuring smooth transitions between versions. It simplifies staying informed about critical shifts in configuration, defaults, and behaviors relevant to your deployments.
### Preflight & Postflight Checks
Chkk’s preflight checks verify compatibility, detect deprecated fields, and confirm upgrade paths align with supported intervals. These checks prevent unintended database migrations and ensure necessary preparation, such as handling CRD changes or schema adjustments. Postflight checks confirm operator health, Keycloak pod readiness, and successful schema migrations after upgrades. Automated log scans and CR status checks quickly surface any operational issues, enabling prompt resolution.
### Version Recommendations
Chkk continuously tracks Keycloak’s release and support lifecycles, notifying teams when current versions approach or reach end-of-life. It provides informed upgrade recommendations, highlighting critical factors like security patches, compatibility issues, or significant architecture changes. Contextual insights around community stability and known CVEs assist teams in proactive, informed upgrade decisions. Custom support policies, such as vendor-specific timelines, can also be integrated into Chkk’s recommendations.
### Upgrade Templates
Chkk delivers clear Upgrade Templates covering both in-place and blue-green upgrade strategies recommended by Keycloak. Templates detail preparatory steps like database backups, CRD updates, and anticipated downtime management. For blue-green approaches, guidance includes parallel deployments and incremental workload migration to validate new versions safely. Clearly defined phases and rollback points ensure controlled, low-risk upgrades aligned with CI/CD and GitOps workflows.
### Preverification
Preverification creates an isolated test environment to simulate and validate Keycloak upgrades prior to production deployment. It identifies compatibility issues, configuration conflicts, and resource utilization concerns early. Engineers receive detailed performance metrics and readiness assessments to proactively resolve potential problems. This process significantly reduces risks by ensuring upgrade reliability through comprehensive rehearsal scenarios.
### Supported Packages
Chkk supports various deployment methods, including Helm, Operator Lifecycle Manager (OLM), and direct manifests. It seamlessly integrates with custom Keycloak images, private registries, and vendor-specific distributions. GitOps-managed manifests are analyzed for necessary updates, simplifying version tracking and manifest maintenance. This flexibility maintains consistent upgrade management irrespective of your chosen deployment tools or methods.
## Additional Resources
* [Keycloak Operator Documentation](https://www.keycloak.org/operator)
* [Keycloak Releases](https://github.com/keycloak/keycloak/releases)
# Kiali
Source: https://docs.chkk.io/projects/kiali
Chkk coverage for Kiali. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v1.50.0"
export const ChecksMinVer_0 = "v1.58.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Kiali Overview
Kiali is an open-source observability console for Istio, providing comprehensive visualizations of service mesh topologies, traffic flows, and performance metrics. It integrates seamlessly with Prometheus for metrics and Jaeger for distributed tracing, enabling quick identification of issues and misconfigurations. Kiali validates Istio configurations in real-time and includes intuitive wizards to implement common traffic patterns like fault injection or traffic shifting. By centralizing mesh insights and operational controls in a single UI, Kiali significantly reduces debugging complexity, streamlines policy updates, and enhances visibility into microservice interactions.
## Chkk Coverage
### Curated Release Notes
Chkk monitors Kiali release notes, highlighting relevant new features, breaking changes, or deprecated settings impacting your environment. Platform teams receive concise briefings focused on essential operational impacts, such as changes to namespace visibility configurations or external URL setups introduced in Kiali 2.0. Chkk clearly outlines required adjustments, preventing unexpected issues like broken dashboards or configuration incompatibilities during upgrades. By contextualizing Kiali’s updates, Chkk ensures platform engineers remain informed without manual tracking efforts.
### Preflight & Postflight Checks
Chkk runs comprehensive preflight checks to verify cluster compatibility with targeted Kiali versions, including Istio version alignment and the availability of Prometheus metrics and tracing backends. Checks include scanning for deprecated configurations like old namespace selectors, authentication strategies, or removed CRD fields. Post-upgrade, Chkk postflight checks validate Kiali’s health by ensuring pod stability, functional metrics retrieval, and proper UI/API operations. This approach quickly identifies configuration and integration issues, ensuring a smooth upgrade experience.
### Version Recommendations
Chkk proactively identifies when your Kiali version approaches end-of-life or risks incompatibility with current Istio and Kubernetes versions. By referencing Kiali’s documented compatibility matrix, Chkk flags potential risks and recommends stable upgrade paths, avoiding operational disruptions from unsupported configurations. Recommendations balance immediate security needs, feature updates, and environment stability. Chkk also accommodates vendor-specific or custom Kiali deployments, ensuring tailored advice aligning precisely with your operational context.
### Upgrade Templates
Chkk offers detailed Kiali Upgrade Templates supporting both in-place and blue-green methods. In-place templates clearly outline configuration updates, pod validations, and rollback steps to minimize operational risks during direct upgrades. Blue-green templates guide parallel deployment validation, enabling thorough testing of the new Kiali version alongside the existing one, with clear instructions for transitioning user access safely. Both templates integrate seamlessly into GitOps or CI/CD workflows, providing structured and predictable upgrade paths.
### Preverification
Chkk’s Preverification capability simulates Kiali upgrades in isolated test environments replicating your production setup. By executing the upgrade process and thoroughly validating integration points, Chkk exposes potential issues like RBAC misconfigurations, integration failures with Prometheus or Jaeger, or UI performance degradations. Early identification allows platform teams to proactively address issues before they affect production. Preverification results in safer deployments and reduced risk during real-world upgrades.
### Supported Packages
Chkk supports multiple Kiali deployment methods, including Helm charts, Kiali Operator, and manifests. It ingests existing deployment configurations (Helm values, Operator CRs, YAML) to provide precise upgrade instructions, preserving customizations like namespace scoping, authentication methods, and custom images. Chkk’s GitOps-friendly approach generates targeted diffs or patches compatible with your repositories, reducing manual errors. This ensures consistency across upgrades, regardless of deployment method or environment customizations.
## Common Operational Considerations
* **Namespace Visibility and Scope:** Misconfigured namespace selectors can prevent Kiali from visualizing expected services or cause performance degradation when monitoring too broadly. Configure namespace selectors precisely to maintain UI responsiveness and accurate visibility.
* **Authentication and Authorization:** Incorrect OpenID Connect configurations or insufficient RBAC permissions frequently cause login issues or incomplete data views in Kiali. Regularly verify user roles and permissions, particularly after environment changes or Kiali upgrades.
* **Metrics and Tracing Integration:** Absent or misconfigured Prometheus or tracing backends result in empty dashboards or missing data in Kiali. Ensure metrics and tracing components are correctly configured, healthy, and aligned with Kiali’s query expectations.
* **Performance in Large Meshes:** Large service meshes can significantly impact Kiali UI responsiveness and usability due to heavy data rendering. Employ Kiali’s filtering and summarization views, adjust auto-refresh intervals, and allocate sufficient pod resources to maintain performance.
* **Multi-Cluster Configuration:** Kiali requires explicit multi-cluster configuration to visualize meshes spanning multiple clusters accurately. Always update Kiali’s configuration promptly when adding new clusters, ensuring connectivity, correct cluster credentials, and consistent service naming.
* **Istio Debug API Dependency:** Kiali depends on Istio’s debug interface (`istiod` port 8080) for proxy status and configuration data. Disabling Istio’s debug endpoint without adjusting Kiali’s settings results in missing data; ensure alignment of these configurations.
## Additional Resources
* [Kiali Documentation](https://kiali.io/docs/)
* [Kiali Releases](https://github.com/kiali/kiali/releases)
# Kiali Operator
Source: https://docs.chkk.io/projects/kiali-operator
Chkk coverage for Kiali Operator. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v1.46.0"
export const ChecksMinVer_0 = "v1.63.2"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Kiali Operator Overview
Kiali is an open-source observability console designed for Istio service meshes, providing real-time visualization and validation of microservices topology, health, and traffic flows. It integrates tightly with Prometheus, Grafana, and Jaeger for metrics, dashboards, and tracing. The Kiali Operator automates deployment and lifecycle management of Kiali using a Custom Resource (CR), streamlining installation and configuration updates. This operator-driven model reduces manual tasks, ensuring reliable and consistent observability across clusters without modifying application code.
## Chkk Coverage
### Curated Release Notes
Chkk curates Kiali Operator release notes, calling out breaking CRD or reconcile-logic changes, security patches, and new configuration fields that affect your manifests. Summaries highlight actionable item, so you can update Helm values or CRs before upgrading. Chkk also flags operator-specific fixes (e.g., hot-loop reconciliation bugs that previously caused pod restarts) to clarify the operational benefit of each release. By mapping every upstream note to the exact resources in your clusters, Chkk helps platform engineers prioritize what truly matters and ignore the noise.
### Preflight & Postflight Checks
Chkk executes preflight checks to validate cluster compatibility, including verifying Istio and Kubernetes version alignment with the Kiali Operator requirements. These checks detect deprecated configurations in your Kiali CR that could prevent a smooth upgrade. Postflight checks confirm successful operator and Kiali server deployment, monitor logs for integration errors (e.g., Prometheus connectivity issues), and flag leftover resources. Immediate feedback ensures observability continuity and quickly identifies upgrade-related issues.
### Version Recommendations
Chkk continuously tracks Kiali Operator support cycles, alerting teams when their version approaches end-of-life or incompatibility with current Istio deployments. Recommendations include rationale such as known vulnerabilities or compatibility gaps arising from untested version pairings. Chkk advises stable, tested upgrade targets that balance new features with operational stability. Platform engineers receive clear, actionable guidance rather than arbitrary version updates.
### Upgrade Templates
Chkk provides detailed Upgrade Templates covering both in-place and blue-green upgrade scenarios for the Kiali Operator, aligning closely with community best practices. In-place upgrade templates include critical checkpoints such as CR backups and CRD validation, clearly outlining anticipated downtime and rollback procedures. Blue-green templates guide parallel Kiali Operator deployments, allowing controlled migration with zero downtime. Both methods integrate seamlessly with GitOps and CI/CD pipelines, minimizing human error during upgrades.
### Preverification
Chkk's preverification simulates the Kiali Operator upgrade within an isolated, representative environment prior to production deployment. This dry run identifies potential CRD schema incompatibilities, authentication misconfigurations, and resource constraints before impacting live clusters. Simulated telemetry integrations with Prometheus and Jaeger further validate configuration correctness. Incorporating preverification into automated pipelines significantly reduces upgrade-related risks and ensures predictability.
### Supported Packages
Chkk fully supports multiple installation methods for Kiali Operator, including Helm charts, OperatorHub (OLM), and manifests. Custom setups—such as specialized vendor distributions or private image registries—are respected, ensuring consistency across upgrade processes. Chkk seamlessly integrates with existing GitOps workflows, parsing current manifests or Helm releases and recommending targeted adjustments. Platform teams benefit from unified lifecycle management regardless of the chosen installation path.
## Additional Resources
* [Kiali Documentation](https://kiali.io/documentation/)
* [Kiali Releases](https://github.com/kiali/kiali/releases)
# Kibana
Source: https://docs.chkk.io/projects/kibana
Chkk coverage for title: Kibana. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v7.17.5"
export const ChecksMinVer_0 = "v8.5.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Kibana Overview
Kibana is an open-source analytics and visualization platform designed to complement Elasticsearch, enabling real-time data insights through interactive dashboards. Serving as the primary UI for the Elastic Stack, Kibana simplifies log and metric analysis for platform engineers and developers. It facilitates the creation and sharing of dynamic dashboards without extensive query writing, supporting observability and security analytics in modern cloud environments. Kibana's intuitive, browser-based interface converts complex data into actionable operational intelligence.
## Chkk Coverage
### Curated Release Notes
Chkk actively monitors Kibana release notes, highlighting significant features, breaking changes, and deprecated settings relevant to your deployment. It flags updates that affect security defaults, authentication, configuration requirements, or plugin APIs. For instance, if a new Kibana version mandates TLS by default, Chkk alerts you to preempt configuration issues. This targeted approach allows platform engineers to anticipate and manage critical changes efficiently.
### Preflight & Postflight Checks
Chkk executes preflight checks to validate Elasticsearch version compatibility, detect unsupported upgrade paths, and identify deprecated settings. After the upgrade, postflight checks ensure Kibana’s health, successful Elasticsearch connectivity, and proper plugin functionality. Issues such as index migration failures or incompatible plugins are quickly flagged. This comprehensive checking process ensures reliable and smooth upgrades.
### Version Recommendations
Chkk tracks Kibana’s support lifecycle, alerting teams when their version approaches end-of-life or risks losing security updates. Recommendations emphasize stable upgrade paths based on community feedback, known issues, and Elasticsearch compatibility. Chkk balances the urgency of new features against operational stability, suggesting practical versions that minimize risk. This informed guidance supports compliance and operational continuity.
### Upgrade Templates
Chkk provides structured Upgrade Templates for both in-place and blue-green Kibana upgrades. Templates detail key upgrade steps, including resource backup, configuration updates, and rollback procedures, aligning closely with Elastic’s recommended practices. For major upgrades, Chkk advocates verifying new versions in controlled staging environments before production deployment. These templates integrate seamlessly into existing GitOps and CI/CD workflows, ensuring minimal disruption.
### Preverification
Chkk’s preverification feature rehearses Kibana upgrades in isolated environments mirroring your production setup. This "dry run" identifies potential startup errors, plugin conflicts, and migration issues before affecting live deployments. Platform engineers receive detailed anomaly reports, allowing them to adjust resources or configurations proactively. This reduces upgrade risk by ensuring issues are resolved preemptively.
### Supported Packages
Chkk supports various Kibana deployment methods, including Helm charts, Elastic Cloud on Cloud Native platforms (ECK), and standard manifests. It accurately recognizes custom Docker images, private registries, and vendor-specific configurations, preserving operational consistency. Chkk also integrates with existing GitOps and configuration management processes, streamlining manifest updates and version synchronization. This comprehensive support maintains deployment flexibility without sacrificing upgrade reliability.
## Common Operational Considerations
* **Elasticsearch Version Alignment:** Ensure Kibana’s version matches Elasticsearch precisely to avoid startup failures and compatibility errors.
* **Resource Allocation:** Monitor Kibana’s memory and CPU use, scaling horizontally if necessary to maintain performance and availability.
* **Saved Objects Migration:** Back up Kibana indices before upgrades and verify migrations complete fully to prevent data corruption.
* **Plugin Compatibility:** Check plugin compatibility before upgrading, updating or removing incompatible plugins to ensure seamless operation.
* **Authentication & Connectivity:** Verify Kibana’s Elasticsearch credentials and TLS settings, particularly when enabling X-Pack security, to avoid connectivity issues.
* **High Availability Setup:** Configure consistent encryption keys and session settings across multiple Kibana instances to ensure session persistence and seamless load balancing.
## Additional Resources
* [Kibana Documentation](https://www.elastic.co/docs/reference/kibana)
* [Kibana Releases](https://github.com/elastic/kibana/releases)
# Knative Eventing
Source: https://docs.chkk.io/projects/knative-eventing
Chkk coverage for Knative Eventing. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v1.7.4"
export const ChecksMinVer_0 = "v1.8.6"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Knative Eventing Overview
Knative Eventing is an open-source framework enabling event-driven architectures. It provides custom APIs to route events from producers (sources) to consumers (sinks) using standard HTTP and CloudEvents protocols. The framework decouples event publishers from subscribers, allowing event distribution without predetermined endpoints. Knative supports multiple backing channels, such as Kafka, to ensure reliability and scalability. It seamlessly integrates with Knative Serving and standard services to trigger serverless functions and microservices.
## Chkk Coverage
### Curated Release Notes
Chkk monitors official Knative Eventing releases, highlighting features, breaking changes, and deprecated APIs relevant to your deployments. It provides concise summaries, such as Kubernetes version requirements or newly introduced event types, allowing proactive configuration adjustments. By emphasizing operational impacts, Chkk helps prevent upgrade-related disruptions. This curated approach enables teams to act quickly on important changes, ensuring stable event pipelines.
### Preflight & Postflight Checks
Before upgrades, Chkk runs comprehensive checks to validate compatibility, detect deprecated APIs, and identify resource constraints. These preflight checks help avoid known pitfalls like unsupported version jumps or CRD schema conflicts. After upgrades, postflight checks confirm that all Knative Eventing pods are healthy, and verify normal event flow and delivery. Chkk quickly identifies problems such as failing webhooks, broker misconfigurations, or dropped events, ensuring smooth upgrades.
### Version Recommendations
Chkk continuously tracks Knative Eventing support timelines, alerting when your current version approaches or surpasses end-of-life. Leveraging official community guidance, it flags risks associated with outdated versions, including lack of security patches or incompatibility with cluster updates. Chkk recommends stable upgrade targets based on known issues and community feedback. Custom vendor builds or support timelines can also be integrated, ensuring your event infrastructure remains compliant and reliable.
### Upgrade Templates
Chkk offers structured Upgrade Templates covering both in-place and blue-green upgrade strategies aligned with Knative’s best practices. In-place upgrades directly update existing deployments, minimizing complexity but briefly impacting event handling. Blue-green upgrades involve parallel deployments and gradual traffic shifting, significantly reducing event loss risk when migrating to the freshly provisioned green cluster as part of a cluster-wide Blue-green upgrade. Each template includes detailed, step-by-step instructions with rollback points, ideal for integrating into CI/CD or GitOps workflows to reduce operational errors.
### Preverification
Chkk's Preverification creates a simulated environment mirroring your current Knative Eventing deployment to rehearse upgrades safely. This dry-run approach identifies issues like webhook failures, CRD incompatibilities, or unexpected resource consumption before impacting production. By proactively resolving these findings, you reduce upgrade risks and downtime. Incorporating Preverification into your upgrade workflow ensures greater predictability and reliability of event-driven infrastructure changes.
### Supported Packages
Chkk supports multiple installation methods including Helm, Kustomize, Operator-based installs, and standard YAML manifests. It seamlessly integrates with existing GitOps and CI/CD workflows, understanding custom images, private registries, and vendor-specific configurations. Chkk precisely identifies necessary manifest changes, avoiding unintended defaults. This flexibility maintains consistency across upgrades and simplifies event-driven infrastructure management.
## Common Operational Considerations
* **In-Memory Broker Limitations:** The default in-memory channel risks event loss during restarts. For production-grade reliability, implement a durable broker (e.g., Kafka) and monitor its health closely.
* **Event Delivery Failures:** Misconfigured or unavailable sinks cause events to accumulate or disappear unnoticed. Always configure Dead Letter Sinks and regularly verify trigger sink URIs to avoid silent failures.
* **Cross-Namespace Isolation:** Knative restricts event routing to single namespaces by default. Explicitly configure permissions or deploy producers and consumers in shared namespaces if cross-namespace routing is needed.
* **Service Mesh & mTLS Compatibility:** Strict mTLS policies in service meshes like Istio can block event deliveries. Label eventing namespaces for sidecar injection or explicitly configure mesh policies to allow Knative Eventing traffic.
* **Resource Footprint at Scale:** Eventing components scale resource use proportionally with event volume and complexity. Set appropriate resource requests/limits and utilize multi-tenant broker configurations to manage resource overhead efficiently.
* **Observability and Debugging:** Tracing event flow issues requires detailed logging and tracing. Enable Knative’s built-in tracing, aggregate logs centrally, and proactively monitor key metrics like event delivery rates and dead-letter events.
## Additional Resources
* [Knative Eventing Documentation](https://knative.dev/docs/eventing/)
* [Knative Eventing Releases](https://github.com/knative/eventing/releases)
# Knative Serving
Source: https://docs.chkk.io/projects/knative-serving
Chkk coverage for Knative Serving. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v0.23.2"
export const ChecksMinVer_0 = "v1.2.5"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Knative Serving Overview
Knative Serving is a Cloud Native serverless platform that simplifies containerized application deployments using custom resources like Service, Route, Configuration, and Revision. It automates network routing, dynamic autoscaling—including scale-to-zero—and revision-based deployments, enabling blue-green or canary rollouts effortlessly. Knative integrates seamlessly with ingress controllers such as Istio, Kourier, and Contour, allowing platform engineers to leverage existing networking infrastructure. Each application change generates an immutable Revision object, facilitating precise version tracking and traffic management without manual intervention.
## Chkk Coverage
### Curated Release Notes
Chkk curates Knative Serving release notes, highlighting new features, breaking changes, or deprecated APIs specifically relevant to your clusters. Instead of parsing exhaustive upstream notes, engineers receive concise summaries of impactful changes, such as the removal of older API versions or modifications to default behaviors. If an update introduces autoscaling algorithm adjustments or config-map changes, Chkk explicitly flags these details. This targeted curation helps you proactively adapt configurations and prevents unexpected operational disruptions.
### Preflight & Postflight Checks
Chkk performs preflight checks to ensure your cluster’s Kubernetes version, Knative CRDs, and configurations meet upgrade prerequisites, preventing common pitfalls such as version mismatches or deprecated field usage. It enforces sequential upgrades, avoiding unpredictable behavior from skipped minor versions. After upgrading, postflight checks validate Knative component health (e.g., controllers, activator) and readiness status of user services. Any anomalies, like revisions failing readiness or traffic routing issues, are immediately flagged, reducing downtime and operational risk.
### Version Recommendations
Chkk continuously monitors Knative Serving versions, clearly recommending stable, supported upgrades aligned with community feedback and compatibility with your Kubernetes clusters. It warns proactively when your current version approaches end-of-life or misses critical security patches. By aligning recommendations with Knative’s official support matrix and known issues, Chkk helps platform engineers balance adopting new features against operational stability. This prevents security vulnerabilities and compatibility problems from impacting production deployments.
### Upgrade Templates
Chkk provides structured Upgrade Templates supporting both in-place and blue-green upgrade methods. Templates include step-by-step guidance on applying Knative Serving manifests, sequencing CRD updates, and controlled pod restarts to minimize downtime. For higher-risk environments, Chkk outlines blue-green approaches, such as deploying a parallel Knative setup for phased traffic shifting and rollback safety. Clearly defined rollback points and best practices from official Knative documentation reduce the complexity and risk of manual upgrades.
### Preverification
Chkk’s Preverification feature simulates Knative Serving upgrades in isolated environments before applying them in production. This process identifies issues such as incompatible fields, CRD conflicts, or autoscaling anomalies. By running test traffic and configuration checks against a representative cluster, preverification uncovers issues like deprecated annotations or performance regressions early. This practice significantly improves upgrade reliability, allowing platform teams to confidently execute production upgrades.
### Supported Packages
Chkk supports Knative Serving deployments across multiple installation methods including YAML manifests, the Knative Operator, and Helm charts. It intelligently adapts upgrade guidance based on your chosen packaging method, accommodating vendor-specific builds and private registries. Chkk integrates with existing GitOps workflows, preserving consistency in image versions and custom configurations. This flexibility ensures upgrade recommendations remain relevant regardless of your deployment practices.
## Common Operational Considerations
* **Default Domain Configuration:** Knative’s default wildcard domain requires explicit DNS and TLS configuration. Without properly updating `config-domain`, services will report URLs but remain externally inaccessible.
* **Networking Layer Mismatch:** Incorrect or missing ingress configurations cause silent routing failures. Always verify Knative’s `config-network` settings align precisely with installed ingress components (Istio, Kourier, etc.).
* **mTLS and Authorization Policies:** Strict mTLS or NetworkPolicies can unintentionally block Knative components (e.g., activator) from scaling workloads. Ensure authorization rules explicitly allow necessary system-level traffic from `knative-serving`.
* **Cold Starts and Scale-to-Zero Tuning:** Knative’s scale-to-zero reduces resource consumption but introduces cold-start latency. Adjust readiness probes and the `scale-to-zero-grace-period` config parameter (optionally `minScale` if you want to keep a warm replica) to optimize user experience and avoid rapid pod flapping.
* **Revision Bloat & Garbage Collection:** Accumulation of inactive Revisions increases resource overhead and object clutter. Configure Knative’s garbage collection (`config-gc`) to retain a sensible number of revisions, regularly auditing unused references.
* **Resource Overhead and Limits:** Knative’s queue-proxy sidecar introduces non-trivial resource overhead at scale. Carefully configure container resource requests/limits and activator autoscaling to ensure cluster stability under traffic bursts.
* **Gradual Upgrades & Compatibility:** Knative upgrades require sequential, incremental steps to avoid CRD and schema incompatibilities. Carefully review intermediate upgrade notes, verify dependency compatibility, and maintain clear rollback plans.
## Additional Resources
* [Knative Serving Documentation](https://knative.dev/docs/serving/)
* [Knative Serving Releases](https://github.com/knative/serving/releases)
# Kong Gateway OSS
Source: https://docs.chkk.io/projects/kong-gateway-oss
Chkk coverage for Kong Gateway OSS. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v1.2.0"
export const ChecksMinVer_0 = "v1.3.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Kong Gateway OSS Overview
Kong Gateway OSS is an open-source, Cloud Native API gateway offering centralized control for service traffic, authentication, rate limiting, and request transformations. Its plugin-based architecture enables platform teams to enforce consistent API policies without modifying upstream applications. Kong supports DB-backed or DB-less (declarative) deployments, providing flexibility for both simple and complex environments. Integrated natively via an official ingress controller, Kong ensures scalable and robust traffic management across multi-cloud setups. Its hybrid deployment mode further facilitates geographically distributed or multi-cluster architectures.
## Chkk Coverage
### Curated Release Notes
Chkk reviews official Kong Gateway OSS release notes, highlighting key changes like new features, deprecated configurations, and critical bug fixes. Engineers receive tailored summaries emphasizing operational impacts, such as the removal of Cassandra DB support in Kong 3.4 or introduction of Kong Manager OSS GUI. By clearly outlining necessary configuration adjustments, Chkk ensures teams proactively address potential breaking changes. These curated notes help platform teams maintain uninterrupted service during upgrades, avoiding common pitfalls.
### Preflight & Postflight Checks
Chkk conducts thorough preflight validations, checking Kong configurations, database compatibility, and deprecated parameters to confirm upgrade readiness. These checks highlight issues such as outdated database connections or removed configuration fields before upgrades are executed. Post-upgrade, Chkk confirms successful rollout by verifying pod health, migrations status, and operational consistency in configured routes and plugins. This comprehensive approach ensures early detection and rapid remediation of upgrade-related anomalies.
### Version Recommendations
Chkk proactively tracks Kong Gateway OSS support timelines, alerting engineers to upcoming EOL dates or critical security patches. Recommendations balance stability with feature updates, suggesting the most suitable Kong versions based on your database dependencies. Chkk clearly communicates reasoning behind each version suggestion, such as approaching end-of-life deadlines or essential security updates. Customized policies are supported for teams managing forks or vendor-specific Kong editions.
### Upgrade Templates
Chkk provides detailed, Kong-specific Upgrade Templates for both in-place and blue-green deployments, aligning with official best practices. Templates guide teams through essential database migrations, schema updates, and configuration management steps with clearly defined rollback points. Blue-green upgrade guidance includes parallel cluster deployment strategies, incremental traffic shifting, and validation procedures. Integrating seamlessly with GitOps or CI/CD pipelines, these templates reduce operational risk and simplify Kong upgrades.
### Preverification
Chkk’s preverification process creates a controlled upgrade simulation mirroring your Kong production environment, including databases, declarative configs, and custom plugins. This simulated upgrade uncovers potential issues such as plugin incompatibilities, configuration parsing errors, or resource utilization spikes. Identifying these problems beforehand allows proactive adjustments, significantly reducing upgrade risks in production. Preverification ensures upgrade reliability, enabling confident, issue-free rollouts.
### Supported Packages
Chkk supports Kong Gateway OSS across Helm charts, Kustomize, manifests, and other deployment methods. It respects custom images, private registries, and vendor-specific builds, adapting upgrade recommendations to your existing setup seamlessly. Engineers can leverage existing GitOps workflows without modification, as Chkk suggests precise configuration changes directly within your established management tools. This compatibility ensures consistent operational practices during Kong version transitions.
## Common Operational Considerations
* **Backup and Migration Planning:** Always perform backups before running database migrations, as Kong’s migration steps are irreversible. Maintain declarative configuration snapshots in DB-less setups to enable rapid rollback if necessary.
* **Breaking Changes & Deprecations:** Regularly review Kong’s documented breaking changes between releases to identify configuration fields or plugins requiring updates. Proactively update or remove deprecated settings to avoid post-upgrade failures.
* **Admin API Security:** Restrict Admin API exposure to internal networks with appropriate firewall rules or NetworkPolicies. Enable RBAC to prevent unauthorized configuration modifications that can compromise cluster integrity.
* **Performance and Resource Tuning:** Monitor and tune Kong’s resource settings such as Nginx worker processes, buffer sizes, and connection limits based on traffic patterns. Proper resource allocation prevents performance bottlenecks and unexpected pod terminations.
* **Hybrid Mode Synchronization:** Always upgrade control plane nodes first in hybrid mode deployments, ensuring data planes never run newer versions than the control plane. Maintain consistent custom plugin versions across control and data planes to prevent synchronization issues.
* **Observability and Logging Overhead:** Configure logging plugins for asynchronous or buffered output to minimize performance impact during high traffic. Monitor key metrics like HTTP status codes, latency, and resource usage to quickly detect and address operational anomalies.
## Additional Resources
* [Kong Gateway OSS Documentation](https://docs.konghq.com/gateway/)
* [Kong Gateway OSS Releases](https://github.com/Kong/kong/releases)
# kube-green
Source: https://docs.chkk.io/projects/kube-green
Chkk coverage for kube-green. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v0.3.0"
export const ChecksMinVer_0 = "v0.4.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Kube-green Overview
Kube-green is an open-source operator designed to optimize energy efficiency by automatically scaling down workloads during off-peak hours. It introduces the SleepInfo custom resource to schedule downtime for Deployments, StatefulSets, and CronJobs, saving their state in Secrets to ensure accurate restoration. This reduces cloud costs and environmental impact by eliminating idle resource usage overnight or during weekends. Kube-green centralizes and automates these actions, providing consistent enforcement of energy-saving policies without manual intervention. It ensures smooth operation continuity when workloads are reactivated.
## Chkk Coverage
### Curated Release Notes
Chkk tracks and summarizes kube-green release notes, highlighting changes relevant to your deployments. Updates such as the removal of Kubernetes version support or new CRD fields are clearly flagged, enabling quick, informed actions. For example, Chkk highlights significant updates like kube-green v0.6.0's introduction of StatefulSet support. This proactive summary ensures engineers are aware of impactful changes without needing to manually review upstream release notes.
### Preflight & Postflight Checks
Chkk’s preflight checks verify cluster compatibility with kube-green’s version requirements, such as minimum supported Kubernetes versions, and detect deprecated fields or APIs in your `SleepInfo` configurations. Postflight checks confirm the successful upgrade by validating operator health, proper reconciliation, and correct execution of scheduled actions. They ensure no disruptions occur, such as missed sleep/wake events or incorrectly restored replica counts. These automated checks significantly reduce risks associated with kube-green updates.
### Version Recommendations
Chkk advises when your kube-green version approaches end-of-life or becomes incompatible with newer cluster releases. Chkk analyses upstream release cadence, change-logs, and real-world production mileage reported by the community, to recommend specific stable and tested upgrade paths. For instance, if your kube-green version lacks critical bug fixes or has compatibility risks with current cluster releases, Chkk provides clear guidance on selecting a suitable target version. This targeted advice helps maintain operational stability and support coverage.
### Upgrade Templates
Chkk offers structured Upgrade Templates for kube-green, clearly outlining in-place and blue-green upgrade methods. Templates provide step-by-step procedures tailored for installations via Helm, plain manifests, or GitOps practices, including critical verification steps and rollback instructions. They detail safeguards like pausing schedules during upgrades to avoid unintended downtime. This structured approach minimizes human error, ensuring smooth, controlled kube-green upgrades.
### Preverification
Chkk’s preverification process rehearses kube-green upgrades in an isolated test environment, using real configurations and workloads. This approach identifies potential issues such as webhook validation errors, resource changes, or altered scheduling logic. It also verifies accurate execution of sleep/wake cycles, ensuring the upgrade won't disrupt production workloads. Integrating preverification into deployment pipelines provides confidence and reduces risks during actual upgrades.
### Supported Packages
Chkk supports kube-green across multiple installation methods, including Helm, plain YAML manifests, Kustomize, and Operator Lifecycle Manager. It respects customizations like private registries, specific namespaces, and GitOps-managed deployments, suggesting precise, minimal changes necessary for upgrades. Chkk seamlessly integrates with existing deployment strategies, ensuring continuity and consistency throughout upgrade processes.
## Common Operational Considerations
* **GitOps Sync Conflicts:** Configure GitOps tools like Argo CD to recognize kube-green scaling actions, preventing repeated automatic rollbacks. Consider sync windows or ignoring replica count changes during scheduled downtimes.
* **Autoscalers and Scale-To-Zero:** Align Horizontal Pod Autoscaler (HPA) minimum replicas with kube-green schedules. Set HPA minimum replicas to zero or disable autoscaling on workloads managed by kube-green to prevent conflicts.
* **Excluding Essential Components:** Explicitly exclude critical infrastructure pods and deployments from kube-green schedules using `SleepInfo`'s `excludeRef`. Accidental inclusion can result in unintended outages or lost monitoring data.
* **Scheduled CronJobs vs. Sleeping Pods:** Synchronize CronJob execution with kube-green's sleep windows. Suspend jobs during downtime or adjust schedules to ensure essential tasks run successfully when services are active.
* **Time Zones and Sleep Accuracy:** Always specify `timeZone` explicitly in `SleepInfo` resources to avoid scheduling errors caused by defaults or daylight savings shifts. Verify initial executions closely to confirm accurate timing.
* **Manual Overrides and Wake-Up Gaps:** Avoid manual scaling during scheduled downtimes to prevent state inconsistencies upon wake-up. Ensure `SleepInfo` resources have defined wake-up times to avoid indefinitely scaled-down states requiring manual intervention.
## Additional Resources
* [kube-green Documentation](https://kube-green.dev/docs/getting-started/)
* [kube-green Releases](https://github.com/kube-green/kube-green/releases)
# kube-proxy
Source: https://docs.chkk.io/projects/kube-proxy
Chkk coverage for kube-proxy. We provide curated release notes, preflight/postflight checks, and Upgrade Templates—all tailored to your environment.
export const ReleaseNotesMinVer_0 = "v1.20.0"
export const ChecksMinVer_0 = "v1.20.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## kube-proxy Overview
kube-proxy manages network rules on each node, forwarding traffic to the correct backend pods for Cloud Native Services. It can run in iptables, IPVS, or userspace mode, with iptables and IPVS being the most common. IPVS performs better in larger clusters because of constant-time lookups, while iptables is generally sufficient for moderate environments. By abstracting the details of Service routing, kube-proxy simplifies application networking. This ensures highly available and scalable traffic distribution at the node level.
## Chkk Coverage
### Curated Release Notes
Chkk continuously monitors kube-proxy related cluster release notes and surfaces relevant performance, security, or deprecation changes. This means you get curated highlights on how upgrades or patches affect your iptables, IPVS configurations, or node-level networking features. Chkk also alerts you when key flags or config settings are removed or replaced. This avoids sifting through extensive cluster changelogs. You stay informed about precisely what matters to your cluster.
### Preflight & Postflight Checks
Chkk runs pre-upgrade checks to verify kernel modules for IPVS, correct iptables settings, and any deprecated kube-proxy flags that might break post-upgrade. After your rollout, Chkk's postflight checks confirm that the new kube-proxy pods are running, iptables or IPVS rules are accurate, and services remain reachable. If it detects anomalies—like iptables-restore errors or missing rules—it flags them early. This helps you address connectivity gaps before they escalate. The result is safer, more predictable kube-proxy updates across all nodes.
### Version Recommendations
Chkk tracks kube-proxy versions in tandem with cluster releases, ensuring you don't run end-of-life or unsupported combinations. It compares your current version against known advisories, highlighting critical security patches or incompatibilities. If you're trailing behind, Chkk provides a stable upgrade target aligned with both your Kubernetes version and the broader community's feedback. This reduces risk of unexpected downtime from outdated iptables or networking behavior. You stay aligned with best practices for node-level proxying.
### Upgrade Templates
Chkk provides in-place and blue-green templates for kube-proxy upgrades, guiding you through a node-by-node rollout or parallel DaemonSet deployments. Each step includes draining or cordoning to avoid traffic disruption and verifying new rules are applied before moving on. Rollback guidance is included if any node runs into problems with iptables or IPVS. By following these clear instructions, your team can adopt a consistent and low-risk approach to network updates. You combine automation with real-world best practices around incremental changes.
### Preverification
Chkk's preverification rehearses your exact kube-proxy upgrade plan in an isolated environment, detecting kernel module, iptables, or config errors before production. It ensures the new configuration can properly set up rules and handle your existing Services without triggering outages. If issues arise—like a missing IPVS module—Chkk highlights them so you can fix them first. This drastically reduces the risk of network disruptions during real rollouts. Teams gain confidence by testing all aspects of the new kube-proxy version ahead of time.
### Supported Packages
Whether you manage kube-proxy via Helm, Kustomize, or raw manifests, Chkk seamlessly integrates with your workflow. It locates the kube-proxy image, command-line flags, and config data within your chosen package format. This ensures every recommendation, check, and upgrade template matches your setup. Private registries and custom builds are fully supported, so no special steps are needed to stay aligned with best practices. Chkk helps you maintain a standardized pipeline regardless of how you package kube-proxy.
## Common Operational Considerations
* **Performance Tuning Considerations:** If iptables becomes too large or slow, switch to IPVS, which uses constant-time lookups. Monitor kube-proxy CPU usage and sync times to avoid performance bottlenecks.
* **Impact on Network Latency and Scalability:** IPVS typically offers lower latency under heavy loads and large service counts. iptables remains sufficient for smaller clusters but scales less effectively in massive environments.
* **Handling Rule Inconsistencies and Troubleshooting:** Inconsistencies can arise from manual iptables changes or reboots; restarting kube-proxy can fix stale or missing rules. Check kube-proxy logs and use iptables or ipvsadm commands to validate correct forwarding.
* **Ensuring Kube-Proxy High Availability and Redundancy:** Each node runs kube-proxy, so a single failure typically doesn't cause cluster-wide disruptions. DaemonSet rolling updates, combined with liveness probes, ensure each node's proxy stays functional.
* **Security Considerations for Kube-Proxy:** Kube-proxy doesn't enforce network policies, so rely on CNI-based NetworkPolicies for pod-to-pod restrictions. Keep kube-proxy images up to date and secure NodePorts at the host or cloud firewall level.
## Additional Resources
* [kube-proxy Command Line Tools Reference](https://kubernetes.io/docs/reference/command-line-tools-reference/kube-proxy/)
* [Kubernetes Releases](https://github.com/kubernetes/kubernetes/releases)
# kube-state-metrics
Source: https://docs.chkk.io/projects/kube-state-metrics
Chkk coverage for kube-state-metrics. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
export const ReleaseNotesMinVer_0 = "v1.9.2"
export const ChecksMinVer_0 = "v2.2.4"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## kube-state-metrics Overview
kube-state-metrics (KSM) listens to the Cloud Native API and generates metrics about the state of cluster objects, such as pods and deployments. It presents these metrics in a Prometheus-friendly format, offering granular visibility into workloads and resource objects. This data complements the Cloud Native Metrics Server by focusing on object states rather than resource utilization. Many organizations pair KSM with Prometheus and Grafana to get clear dashboards of key cluster metrics. Because it's lightweight and widely adopted, KSM is a core tool for platform observability and troubleshooting.
## Chkk Coverage
### Curated Release Notes
Chkk continuously scans official KSM releases, identifying metric additions, deprecations, and critical bug fixes. It highlights changes that could break existing Prometheus queries or dashboards, preventing alert failures. In other words, you get a direct heads-up if a particular metric has been removed or altered. Chkk thereby streamlines the process of tracking upstream changes. You see only the details that matter rather than sifting through lengthy release notes.
### Preflight & Postflight Checks
Chkk's preflight checks confirm that your KSM version is compatible with your cluster release and that it has the correct RBAC permissions. It flags any metrics that are likely to disappear or change when you move to a new KSM version. After the upgrade, postflight checks ensure the new KSM is healthy, exposing all expected metrics with no major variance from the baseline. This approach reduces the risk of missing critical data and shortens recovery time if something goes off track.
### Version Recommendations
Chkk reads the release notes for KSM and alerts you when your version nears end-of-life or lacks compatibility with your Kubernetes cluster. It recommends a stable release that aligns with your Prometheus stack and avoids known issues. As new versions emerge, Chkk points out compelling updates (like performance improvements) or necessary security fixes. By following these pointers, you ensure continuous, reliable upgrades. This proactive approach helps you stay aligned with best practices.
### Upgrade Templates
Chkk provides both in-place and blue-green upgrade templates tailored for KSM deployments. An in-place approach updates the existing KSM, typically with a rolling restart that minimizes downtime. A blue-green strategy runs two KSM versions in parallel, switching traffic only after verifying the new version is producing correct metrics. These templates cover image tags, resource requests, and recommended gating checks. They integrate easily with GitOps flows, giving you a consistent procedure every time you upgrade.
### Preverification
Chkk's preverification ensures a smooth and reliable KSM upgrade by testing it in a controlled environment before deployment. It compares key metrics between your current and new versions, identifying renamed or removed series and changes in label formats that could break queries. By proactively surfacing these differences, you can adjust dashboards and alerts ahead of time, preventing disruptions. With Chkk's preverification as a safety net, you can upgrade with confidence, minimizing downtime and ensuring a seamless transition to production.
### Supported Packages
Chkk accommodates multiple packaging methods for KSM—Helm, Kustomize, and plain manifests. It respects private registries and custom-built images, so you can maintain your own hardened version of KSM. The system automatically parses your chosen deployment format to detect required changes and check for known pitfalls. If you've rolled out KSM via GitOps, Chkk integrates seamlessly with that pipeline. In every scenario, coverage remains consistent and thorough.
## Common Operational Considerations
* **Scaling & Resource Usage:** KSM's CPU/memory usage grows with cluster objects. Size or shard KSM appropriately to avoid performance issues and scraped metric delays.
* **High-Cardinality Metrics & Filtering:** Some labels can explode time-series counts in Prometheus. Use allowlists or denylists to reduce unnecessary data that can overload your monitoring stack.
* **RBAC Permissions:** KSM requires broad read access to various objects. Missing permissions can silently drop metrics, so validate role bindings and watch for incomplete data sets.
* **Monitor KSM Itself:** Scrape KSM's internal metrics for watch failures and memory usage. Early detection of restarts or scrape errors ensures continuous, correct monitoring coverage.
## Additional Resources
* [kube-state-metrics Documentation](https://github.com/kubernetes/kube-state-metrics/blob/main/docs/README.md)
* [kube-state-metrics Releases](https://github.com/kubernetes/kube-state-metrics/releases)
# Kubernetes Dashboard
Source: https://docs.chkk.io/projects/kubernetes-dashboard
Chkk coverage for Cloud Native Dashboard. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v2.0.3"
export const ChecksMinVer_0 = "v2.4.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Kubernetes Dashboard Overview
Kubernetes Dashboard is a web-based UI that helps you view, manage, and troubleshoot workloads. It allows real-time monitoring of Pods, Deployments, and other resources with minimal overhead. Combining resource visualization with RBAC-based access control, platform teams gain a convenient method of cluster management. Whether used for quick troubleshooting or routine maintenance, the Dashboard offers a straightforward alternative to CLI-based operations. With broad support for modern cluster releases, it remains a staple for rapid cluster visibility.
## Chkk Coverage
### Curated Release Notes
Chkk automatically tracks upstream Kubernetes Dashboard releases and flags relevant changes. This saves time spent combing through raw release notes for bug fixes, new UI features, and security patches. If a release modifies RBAC requirements or drops a feature, Chkk highlights that in context. It then provides a concise summary tailored to your cluster's current usage. That way, you never miss critical shifts that could affect operations.
### Preflight & Postflight Checks
Before you upgrade, Chkk's preflight checks confirm that your cluster meets all prerequisites for the new Dashboard release, including Kubernetes version compatibility. It inspects the existing Dashboard deployment and flags any deprecated configs or missing roles. After deployment, Chkk's postflight checks verify that the UI is accessible and logs reveal no issues. By automating these checks, you minimize risks like sudden access failures or broken permissions. The outcome is a seamless transition with immediate confirmation of success.
### Version Recommendations
Chkk monitors which Dashboard versions are actively maintained and highlights any release nearing end-of-life. It compares your installed version against known stable lines to guide timely upgrades. If upstream support is dropping, you'll see clear alerts about potential security gaps and missing patches. Chkk also factors in your Kubernetes version to ensure tested compatibility. This proactive approach secures continuity and helps plan your upgrade roadmap effectively.
### Upgrade Templates
Chkk provides step-by-step procedures for upgrading the Dashboard either in-place or via a blue-green strategy. The in-place approach updates the same Deployment while preserving minimal downtime. Blue-green deploys a new Dashboard in parallel so you can verify functionality before decommissioning the old version. Both templates include rollback points and recommended resource modifications to maintain continuity. By removing guesswork, these templates streamline each step and reduce the risk of breakage.
### Preverification
Chkk offers a simulated "digital twin" environment to validate your Dashboard upgrade before affecting production. It recreates your cluster's resources and applies the new version, watching for RBAC conflicts or other errors. If the new Dashboard fails to load or triggers issues, you learn in the sandbox rather than production. You can then adjust configurations or patch manifests prior to the real rollout. This approach protects uptime and adds confidence to any upgrade.
### Supported Packages
Kubernetes Dashboard can be installed via Helm, plain YAML, or Kustomize, and Chkk supports all of these. It detects your package method and tailors its recommendations accordingly. Helm users see guided `helm upgrade` instructions, while manifest-based users see updated YAML diffs. If you rely on a private registry or custom images, Chkk respects those references for consistent usage. In every case, you gain a single interface for analyzing, planning, and executing Dashboard updates.
## Common Operational Considerations
* **Authentication and Single Sign-On (SSO):** If you're integrating the Dashboard with an external identity provider (e.g., OIDC or LDAP), ensure your cluster's API server and Dashboard configuration sync properly. Any misalignment between OIDC claims and Dashboard roles can lock out or overprivilege users, so validate tokens carefully and audit RBAC mappings for SSO groups.
* **Namespace-Scoped Dashboards:** For large environments, consider deploying multiple Dashboards restricted to distinct namespaces or teams. This reduces cross-namespace congestion in the UI, lowers resource overhead in massive clusters, and tightens permissions so users only see relevant workloads.
* **Metrics Scraper Efficiency:** The Dashboard often relies on an accompanying metrics scraper to collect CPU/memory data. In bigger clusters, the scraper can become a performance bottleneck if it polls too frequently, so tune scrape intervals or disable unused resource views to avoid flooding the API server.
* **Auditing and Log Review:** Because the Dashboard aggregates sensitive operations into a single interface, turn on Cloud Native platforms API audit logging and compare them with the Dashboard's logs. Look for anomalies such as repeated failed logins, unusual PUT/DELETE actions, or tokens being used across unexpected namespaces.
## Additional Resources
* [Kubernetes Dashboard Documentation](https://kubernetes.io/docs/tasks/access-application-cluster/web-ui-dashboard/)
* [Kubernetes Dashboard Releases](https://github.com/kubernetes/dashboard/releases)
# Kubernetes Metrics Server
Source: https://docs.chkk.io/projects/kubernetes-metrics-server
Chkk coverage for Cloud Native Metrics Server. We provide curated release notes, preflight/postflight checks, and Upgrade Templates—all tailored to your environment.
export const ReleaseNotesMinVer_0 = "v0.4.0"
export const ChecksMinVer_0 = "v0.5.1"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Kubernetes Metrics Server Overview
Kubernetes Metrics Server is a lightweight aggregator for resource usage metrics (CPU and memory), exposing them to the Kubernetes API. By default, it scrapes kubelets at short intervals and provides "current" usage metrics for HPA and kubectl top. It's designed for minimal resource overhead, while still supporting clusters of thousands of nodes. Because it does not store historical data, it's best paired with full-fledged monitoring solutions for long-term metrics. Metrics Server is a critical Cloud Native Project for autoscaling, granting platform engineers real-time resource snapshots without invasive instrumentation.
## Chkk Coverage
### Curated Release Notes
Chkk regularly scans Metrics Server releases for new features, deprecations, and breaking changes impacting cluster operations. By highlighting only the most relevant updates—like new resource flags or security patches—teams avoid sifting through extensive upstream notes. If a new Metrics Server version changes default CPU requests, Chkk calls out this change so cluster administrators can plan accordingly. Chkk's curated summaries help you rapidly assess upgrade impacts. This streamlined insight reduces the risk of downtime during deployment.
### Preflight & Postflight Checks
Chkk's preflight checks validate that a new Metrics Server version is compatible with your cluster's API configuration, RBAC, and resource constraints. They verify kubelet ports, aggregator settings, and any new flags needed by the upgrade. After deployment, postflight checks confirm that Metrics Server is serving metrics accurately and all HPAs remain functional. This ensures critical autoscaling mechanisms continue working as expected. Any anomalies—like missing metrics or errors in the Metrics API—are promptly surfaced.
### Version Recommendations
Chkk tracks Metrics Server support timelines and flags when your current release is nearing or past end-of-life. Its guidance considers Kubernetes version compatibility and known upstream issues, recommending stable versions that won't disrupt cluster autoscaling. If your setup relies on a custom build or private registry, Chkk provides tailored advice while aligning with official support guidelines. This prevents running outdated, unsupported versions that could break production workloads. As updates roll out, Chkk consistently highlights safe upgrade targets.
### Upgrade Templates
Chkk's **Upgrade Templates** provide step-by-step instructions for in-place or blue-green rollouts of Metrics Server. The in-place approach replaces pods with minimal disruption, while the blue-green method creates a parallel deployment for a seamless transition. Both methods address health checks, aggregator API settings, and potential resource usage spikes. By detailing each step (including rollbacks), Chkk reduces manual errors. These repeatable processes simplify upgrades across multiple clusters or environments.
### Preverification
Chkk's preverification simulates the entire Metrics Server upgrade in a controlled environment. This helps detect issues like missing RBAC permissions, incorrect flags, or network blocks prior to live rollout. When the real upgrade happens, there's higher confidence that metrics collection will remain stable. **Preverification** also pinpoints necessary config adjustments for large-scale clusters. This approach prevents production disruptions and shortens troubleshooting time.
### Supported Packages
Chkk works seamlessly with any Metrics Server installation method—Helm, Kustomize, or raw manifests—without forcing you to change existing workflows. It respects custom images and private registries so you can enforce internal security standards. Chkk detects your Metrics Server deployment and correlates it with upstream versions to provide relevant checks. This consistency allows teams to manage upgrades across different cluster setups. By avoiding lock-in, you can maintain the same operational patterns for all environments.
## Common Operational Considerations
* **Aggregation Latency Impact on Autoscaling:** If scrape intervals are too long, HPAs will scale based on stale usage data. Ensure interval settings and resource allocations keep the latency within acceptable bounds.
* **Resource Requests & Limits:** Under-provisioning can lead to missing metrics or slow responses, so allocate sufficient CPU/memory based on cluster size. Regularly review usage to adjust resource settings when the cluster grows.
* **RBAC & API Access Considerations:** Metrics Server must have appropriate permissions to fetch node data and serve the metrics.k8s.io API. Recheck roles and aggregator settings after major cluster updates or changes.
* **Handling Large-Scale Clusters:** When node counts are high, consider tuning scrape intervals or running multiple replicas. Monitor performance so that neither kubelet nor Metrics Server becomes overloaded.
* **TLS & Secure Communications:** Use proper certificates to avoid insecure skip-flags, which expose the cluster to possible man-in-the-middle attacks. Ensure your aggregator and kubelets are configured with trusted CA certificates.
* **Known Conflicts with Other Monitoring Solutions:** Conflicting API registrations (e.g. dual metrics providers) can break the metrics.k8s.io endpoint. Integrate Metrics Server with Prometheus or custom adapters by separating responsibilities and verifying no overlap.
## Additional Resources
* [Metrics Server Documentation](https://kubernetes-sigs.github.io/metrics-server/)
* [Metrics Server Releases](https://github.com/kubernetes-sigs/metrics-server/releases)
# Kyverno
Source: https://docs.chkk.io/projects/kyverno
Chkk coverage for Kyverno. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
export const ReleaseNotesMinVer_0 = "v1.1.7"
export const ChecksMinVer_0 = "v1.3.1"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Kyverno Overview
Kyverno is a Cloud Native policy engine for security, compliance, and governance. Rather than requiring a new policy language, it uses standard CRDs/YAML to validate, mutate, and generate resources. Common use cases include enforcing best practices (e.g., image registry checks), injecting default labels, and automatically creating network policies when namespaces appear. By integrating with admission controls, Kyverno intercepts changes before they're stored, blocking or adjusting disallowed requests. This approach standardizes configurations, reduces drift, and maintains consistent security across workloads.
## Chkk Coverage
### Curated Release Notes
Chkk continuously scans Kyverno's release notes and distills the updates into concise briefs, highlighting critical changes—like new policy rule types, security patches, or deprecated fields. If a release includes new validation capabilities (e.g., advanced JSON path matching) or modifies default webhook behavior, Chkk flags it to help you plan accordingly. This allows operators to see at-a-glance if an upgrade might affect existing policies or require reconfiguration.
### Preflight & Postflight Checks
Chkk's preflight checks verify that your Kyverno installation and policies remain compatible before upgrading. This includes detecting any API or CRD changes that might break existing configurations and ensuring the cluster meets new version requirements. After the upgrade, postflight checks confirm Kyverno's admission webhooks are running smoothly, policies are enforced correctly, and no unexpected errors appear in the logs. These checks significantly reduce the risk of policy enforcement gaps during an upgrade window.
### Version Recommendations
Chkk monitors Kyverno's releases, comparing each version's support timeline and known compatibility issues. You'll receive alerts when your deployed version nears end-of-life or lacks key security fixes. This ensures your policy engine keeps pace with the broader Cloud Native ecosystem, avoiding outdated features or unpatched vulnerabilities.
### Upgrade Templates
Chkk provides two primary templates for upgrading Kyverno, in-place and blue-green. In-place updates your existing Kyverno deployment in a rolling fashion, typically leveraging a Helm chart or new manifests. Minimal overhead, though any unexpected policy conflicts might appear mid-process. Blue-green stands up a separate Kyverno instance in parallel, letting you test the new version and gradually shift admission controls. This approach offers near-zero downtime and simpler rollback if the new version introduces issues.
Both methods include built-in safety checks, rollback guidance, and recommended validation steps—ensuring your cluster's policies stay effective throughout the transition.
### Preverification
For major version changes or large-scale policy sets, Chkk's preverification simulates the Kyverno upgrade in a controlled environment. It applies your current policy definitions to the new version and runs tests to detect CRD conflicts, policy logic errors, or altered behaviors. This proactive approach often catches hidden issues (like a generate rule failing) well before production, reducing disruptions to day-to-day operations.
### Supported Packages
Chkk adapts to the way you install Kyverno—Helm, Kustomize, or raw YAML. It orchestrates the appropriate upgrades, managing CRDs and manifests so you don't have to change your existing deployment practices. If you rely on private registries or custom images, Chkk respects those references, ensuring consistent security policies across your enterprise environment.
### Common Operational Considerations
* **Mutation Pitfalls:** Mutate rules can alter existing workloads, which might trigger rollouts or restarts. Test in audit mode, review Kyverno logs for unexpected patches, and avoid conflicting patches by combining or tightly scoping mutate rules.
* **Multi-Tenancy Considerations:** Designate global policies as ClusterPolicies and allow teams to manage namespace-scoped ones, ensuring they don't override org-wide mandates. Use PolicyException resources for nuanced waivers and rely on label or namespace selectors to prevent overlap.
* **Race Conditions with Controllers:** Kyverno might collide with GitOps or other controllers, causing endless revert loops or double mutations. Coordinate with these systems—either encode Kyverno mutations in Git or exclude resources from certain controllers—to prevent tug-of-war scenarios.
* **Namespace vs. Cluster-Scope:** Leverage cluster-scoped policies for organization-wide rules and namespaced ones for delegated control. Keep in mind that namespaced policies can't override cluster rules, so carefully define scope to avoid unexpected enforcement overlaps.
## Additional Resources
* [Kyverno Documentation](https://kyverno.io/)
* [Kyverno Releases](https://github.com/kyverno/kyverno/releases)
# MinIO Operator
Source: https://docs.chkk.io/projects/minio-operator
Chkk coverage for MinIO Operator. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v4.4.15"
export const ChecksMinVer_0 = "v5.0.5"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## MinIO Operator Overview
MinIO Operator automates deployment and management of MinIO object storage clusters. It introduces CustomResourceDefinitions (CRDs) for defining MinIO tenants, simplifying the provisioning of S3-compatible storage. The operator handles complex tasks like stateful set orchestration, TLS certificates, and dynamic scaling. Platform teams benefit from standardized, "as-code" storage management, streamlining both initial deployment and day-2 operations such as scaling or upgrading. MinIO Operator effectively provides Cloud Native storage manageability across on-premises and multi-cloud environments.
## Chkk Coverage
### Curated Release Notes
Chkk tracks MinIO Operator release notes, highlighting significant features, breaking changes, and deprecations relevant to your clusters. It specifically flags critical updates like CRD schema migrations or component removals (e.g., Operator Console deprecation in v6.0.0). This contextualized briefing helps platform engineers proactively manage upgrades without reviewing entire upstream changelogs. Changes impacting tenant specifications are explicitly called out to prevent operational disruption.
### Preflight & Postflight Checks
Chkk conducts thorough preflight checks validating Kubernetes version compatibility, CRD states, and resource readiness before operator upgrades. It ensures incremental version steps are followed, preventing unsupported direct jumps (e.g., from 4.x directly to 6.x). Post-upgrade, Chkk verifies operator pod health, reconciles tenant pods, and identifies orphaned resources resulting from component deprecations. These automated checks minimize upgrade risks and maintain storage cluster consistency.
### Version Recommendations
Chkk continuously evaluates MinIO Operator versions, highlighting stability, compatibility, and security considerations. It provides explicit recommendations, guiding teams to upgrade paths proven stable and free of significant issues. Detailed alerts highlight critical intermediate upgrade requirements or version constraints due to significant CRD changes or compatibility issues. Chkk’s proactive advisory ensures informed upgrade decisions aligned with operational stability and compliance.
### Upgrade Templates
Chkk provides detailed Upgrade Templates supporting both in-place and blue-green upgrade methodologies. In-place templates guide step-by-step operator upgrades, including CRD backup, tenant updates, and checkpoint validations. Blue-green templates offer strategies for zero downtime, utilizing parallel deployments with data replication before cutover. All templates incorporate rollback instructions and best practices aligned with official MinIO guidance, significantly reducing upgrade complexity and operational risk.
### Preverification
Chkk’s preverification capability simulates MinIO Operator upgrades in an isolated environment replicating production configurations. This process identifies potential upgrade issues such as invalid CRDs, resource spikes, or compatibility conflicts before actual deployment. Comprehensive reports generated post-simulation detail encountered issues, allowing engineers to proactively address problems. Preverification significantly enhances upgrade predictability and reduces risk during live deployments.
### Supported Packages
Chkk integrates seamlessly with common deployment methods for MinIO Operator, including Helm, Kustomize, OperatorHub, and YAML manifests. It respects custom images, private registries, and tailored configurations, preserving existing operational practices. Recommendations provided by Chkk align directly with your specific deployment tooling and practices. This ensures operational continuity while leveraging Chkk’s proactive upgrade and management features.
## Additional Resources
* [MinIO Operator Documentation](https://min.io/docs/minio/kubernetes/upstream/index.html)
* [MinIO Operator Releases](https://github.com/minio/operator/releases)
# Ory Hydra
Source: https://docs.chkk.io/projects/ory-hydra
Chkk coverage for Ory Hydra. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
export const ReleaseNotesMinVer_0 = "v1.5.1"
export const ChecksMinVer_0 = "v1.9.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Ory Hydra Overview
Ory Hydra is an open-source OAuth 2.0 and OpenID Connect server designed for cloud-native, containerized environments. It securely handles authentication flows by issuing and validating access, refresh, and ID tokens, integrating seamlessly with external identity providers via login and consent applications. This decoupling allows platform teams to enforce consistent security policies across microservices without modifying application code. Proven in high-scale production setups, Hydra emphasizes security and scalability, capable of handling thousands of token requests per second efficiently.
## Chkk Coverage
### Curated Release Notes
Chkk curates Hydra release notes, highlighting impactful changes such as stricter compliance requirements, critical database schema updates, or new API endpoints. Platform teams receive targeted summaries explaining how updates directly affect operational deployments, ensuring critical modifications—like mandatory configuration changes—aren’t overlooked. This approach simplifies staying current without sifting through extensive changelogs.
### Preflight & Postflight Checks
Chkk performs detailed preflight checks ensuring your deployment is within supported Hydra upgrade paths and meets necessary prerequisites like database compatibility and configuration correctness. It alerts you about deprecated settings or potential database migration issues upfront. Postflight checks confirm successful upgrades by validating pod health, endpoint reachability, migration outcomes, and consistent versions across instances, promptly identifying any rollout issues.
### Version Recommendations
Chkk monitors Hydra's version lifecycles, alerting teams when deployed versions fall behind the project's release cadence or pose security risks due to lack of maintenance. Recommendations clearly identify stable upgrade targets based on Hydra community insights, known issues, and patch histories. This proactive guidance helps maintain compliance, avoid vulnerabilities, and balance new features with operational stability.
### Upgrade Templates
Chkk provides proven Upgrade Templates for in-place and blue-green upgrades. Templates detail steps such as database backups, schema migrations, dual deployments, and traffic cutovers, clearly outlining rollback procedures. Designed for easy integration with GitOps and CI/CD workflows, these templates enable teams to execute Hydra upgrades confidently with minimal downtime and risk.
### Preverification
Chkk’s Preverification creates a "digital twin" of your Hydra environment, rehearsing upgrades to detect potential problems such as migration failures or resource issues before production deployment. It validates each upgrade step against a representative snapshot of your setup, identifying complications early. This approach ensures smoother live upgrades by enabling teams to address issues proactively.
### Supported Packages
Chkk supports Hydra deployments via Helm charts, Kustomize, YAML manifests, and custom images or registries. It directly integrates with existing GitOps-managed environments, accurately identifying and recommending configuration updates and minimal required changes. Platform teams retain their preferred deployment tools and workflows, with Chkk providing precise, actionable upgrade insights.
## Common Operational Considerations
* **Schema Migrations:** Avoid concurrent migrations by performing database schema updates through a single controlled process. Always back up databases and upgrade sequentially without skipping major Hydra versions to ensure compatibility.
* **Admin API Security:** Hydra’s admin API lacks built-in authentication; restrict access strictly via network policies or API gateways. Regularly audit endpoint accessibility to prevent unauthorized administrative control.
* **Persistent Secrets:** Maintain consistent `SECRETS_SYSTEM` environment variables securely stored in secrets or vaults. Changes or losses to this secret invalidate existing sessions and tokens irrecoverably.
* **Expired Token Cleanup:** Hydra open-source editions require manual cleanup of expired OAuth2 tokens and consents using periodic CronJobs. Without regular cleanup, database performance and storage efficiency degrade significantly.
* **Database Performance:** Hydra’s performance depends heavily on database efficiency; insufficient DB resources or inadequate indexing can create request bottlenecks. Monitor DB metrics, implement recommended tuning, and proactively address contention issues by regularly archiving old data.
* **Login/Consent Endpoint Alignment:** Hydra relies on external login and consent apps; misalignment of endpoint URLs causes authentication failures. Ensure consistent domain names, correct environment variables (`URLS_LOGIN`, `URLS_CONSENT`, `URLS_SELF_ISSUER`), and operational monitoring of these critical components.
## Additional Resources
* [Ory Hydra Documentation](https://www.ory.sh/docs/hydra/)
* [Ory Hydra Releases](https://github.com/ory/hydra/releases)
# PgBouncer
Source: https://docs.chkk.io/projects/pgbouncer
Chkk coverage for PgBouncer. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
export const ReleaseNotesMinVer_0 = "v1.10.0"
export const ChecksMinVer_0 = "v1.16.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## PgBouncer Overview
PgBouncer is a lightweight PostgreSQL connection pooler that optimizes database performance by managing and reusing database connections efficiently. Deployed as a proxy, PgBouncer prevents connection spikes from overwhelming databases by pooling connections and supports multiple pooling modes—session, transaction, and statement—to balance compatibility and performance. Its minimal resource usage (approximately 2kB per connection) allows handling thousands of client connections simultaneously, offering significant efficiency gains in Cloud Native microservices architectures. PgBouncer provides fine-grained control over connection limits, online configuration reloads, and seamless upgrades, making it vital for maintaining database reliability and performance at scale.
## Chkk Coverage
### Curated Release Notes
Chkk curates PgBouncer release notes, highlighting changes relevant to your deployment, such as default configuration adjustments and critical security patches. Instead of manually parsing lengthy changelogs, you'll receive a targeted summary emphasizing practical impacts. For example, Chkk flags important default-setting changes like enabling prepared-statement caching or adjustments in authentication mechanisms, enabling proactive configuration updates. This allows platform teams to quickly assess upgrade risks and identify required operational changes without missing critical details.
### Preflight & Postflight Checks
Chkk performs preflight checks to validate your current environment's compatibility before a PgBouncer upgrade, such as verifying supported configuration parameters and compatibility with PostgreSQL versions. It flags issues like deprecated options or TLS configuration changes (e.g., default SSL modes) that could impact upgrade success. Post-upgrade, Chkk verifies instance health, connection acceptance, and identifies anomalies like increased connection wait times or authentication failures. These automated checks significantly reduce the risk of issues surfacing only after production deployment.
### Version Recommendations
Chkk continuously tracks PgBouncer's releases, security updates, and known issues to recommend optimal versions tailored to your environment. It proactively alerts when deployed versions are outdated, insecure, or missing key performance improvements. Version recommendations are backed by real-world usage insights, community feedback, and alignment with PostgreSQL compatibility, ensuring your environment remains secure and efficient. Chkk also considers vendor-packaged versions and custom builds, helping you maintain consistency and security across diverse deployments.
### Upgrade Templates
Chkk provides structured Upgrade Templates supporting both in-place and blue-green strategies for PgBouncer upgrades, adhering to community best practices. In-place templates guide you through graceful rolling restarts using connection-draining methods (PAUSE and SHUTDOWN commands) to avoid disruptions. Blue-green templates outline parallel deployments of new PgBouncer instances, allowing traffic shifts after validating stability. Clear rollback points and automation-friendly workflows ensure minimal downtime and streamlined integration with GitOps or CI/CD pipelines.
### Preverification
Chkk’s Preverification simulates PgBouncer upgrades within a controlled, representative environment before production rollout, catching potential configuration or operational problems early. It replicates current settings, validates authentication methods, and checks for incompatibilities such as deprecated configuration options or TLS misconfigurations. Any detected issues—from query failures to connection errors—are highlighted, allowing adjustments before impacting live environments. Incorporating preverification dramatically increases upgrade confidence and reduces production risks.
### Supported Packages
Chkk supports various PgBouncer deployment methods—including Helm charts, manifests, operators, and custom container images—ensuring seamless integration with your existing workflows. It intelligently parses and maps configurations across deployment types, maintaining consistency and accuracy across diverse environments. Whether managed via container orchestration, system packages, or custom builds, Chkk's insights and recommendations adapt accordingly. This flexibility enables smooth adoption of Chkk's operational best practices without changing your established automation processes.
## Common Operational Considerations
* **Zero-Downtime Upgrades:** Avoid deprecated online restart (`--reboot`) methods by leveraging rolling or parallel upgrade strategies using connection-draining commands (PAUSE and SHUTDOWN). Deploy multiple instances using `so_reuseport` to achieve upgrades without connection drops.
* **Pooling Mode Compatibility:** Ensure your application fully supports PgBouncer's chosen pooling mode (transaction, session, or statement), as transaction pooling can disrupt session-specific database features. Utilize settings like `track_extra_parameters` to preserve essential session parameters across pooled connections.
* **Authentication Pitfalls:** Align PgBouncer’s authentication methods precisely with PostgreSQL’s, especially SCRAM-SHA-256 compatibility, to prevent connection failures. Regularly synchronize custom `auth_query` configurations with database authentication changes, particularly after version upgrades.
* **Connection Pool Sizing:** Properly tune `pool_size` and `max_client_conn` to match PostgreSQL’s capacity, balancing between handling peak client connections and avoiding database saturation. Monitor PgBouncer metrics for connection queuing or database resource exhaustion, adjusting limits proactively.
* **TLS Configuration Surprises:** Explicitly define PgBouncer’s TLS modes (`disable`, `allow`, `prefer`, or `require`) to avoid unexpected connection behavior during upgrades. Regularly verify certificates and TLS performance overhead, enabling TLS 1.3 where appropriate to improve efficiency.
* **Single-Threaded Bottleneck:** Recognize PgBouncer’s single-threaded nature, which may limit throughput to a single CPU core, causing potential bottlenecks under high load. Scale horizontally by deploying multiple parallel PgBouncer instances or utilize `so_reuseport` to distribute traffic across cores.
## Additional Resources
* [PgBouncer Documentation](https://www.pgbouncer.org/)
* [PgBouncer Releases](https://github.com/pgbouncer/pgbouncer/releases)
# Pomerium
Source: https://docs.chkk.io/projects/pomerium
Chkk coverage for Pomerium. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
export const ReleaseNotesMinVer_0 = "v0.18.0"
export const ChecksMinVer_0 = "v0.19.1"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Pomerium Overview
Pomerium is an open-source identity-aware proxy implementing zero-trust security principles inspired by Google's BeyondCorp model. Acting as a gateway in front of internal services, it continuously verifies user identity, device state, and request context. Without client software, Pomerium enforces granular access policies centrally at the proxy layer, enabling seamless single sign-on (SSO). This simplifies secure access management across environments (on-premises, cloud, hybrid) and eliminates complex VPNs. By enforcing dynamic, identity-driven policies, Pomerium significantly enhances security and user experience.
## Chkk Coverage
### Curated Release Notes
Chkk monitors official Pomerium release notes, highlighting new features, breaking changes, or deprecations impacting your clusters. Instead of manually reviewing upstream changelogs, Chkk provides a concise operational summary relevant to your environment. Critical changes, such as tracing subsystem replacements (OpenCensus to OpenTelemetry) or removal of legacy "forward-auth" modes, are clearly flagged with remediation guidance. This proactive notification ensures platform teams are prepared for impactful changes before upgrades.
### Preflight & Postflight Checks
Chkk performs preflight checks to ensure your clusters and configurations meet Pomerium’s compatibility requirements before upgrades. It identifies deprecated settings like old policy fields or required datastore dependencies, preventing disruptive upgrade issues. Postflight checks confirm successful version transitions, verify pod health, detect leftover resources from previous versions, and inspect logs for identity provider connection errors or misconfigured policies. This structured approach significantly reduces operational risks during upgrades.
### Version Recommendations
Chkk actively tracks Pomerium versions and support timelines, alerting you when your deployed version falls out of the maintenance window or becomes vulnerable. It references official advisories and known issues, providing clear justifications for recommended upgrades. Chkk suggests stable, vetted upgrade targets based on community feedback, helping platform teams balance feature urgency with operational stability. Custom versioning and support policies, including enterprise editions or forks, are fully accommodated.
### Upgrade Templates
Chkk offers detailed Upgrade Templates for both in-place and blue-green upgrades, aligning with Pomerium best practices. In-place upgrade templates cover incremental pod rollouts, checkpoint configurations, and DNS or side-component reloads. Blue-green strategies allow parallel testing of new versions in controlled subsets, outlining rollback points for safe transitions. These templates integrate smoothly with GitOps or CI/CD pipelines, minimizing human error and downtime.
### Preverification
Chkk's preverification simulates the entire upgrade process in an isolated environment, replicating your production configurations and infrastructure. This identifies configuration conflicts, increased resource consumption, or identity provider integration issues before production deployment. Detected issues like stricter policy parsing or resource spikes can be proactively addressed. Preverification significantly reduces upgrade risk by validating steps safely before real-world application.
### Supported Packages
Chkk supports multiple Pomerium deployment methods, including Helm, Kustomize, and raw YAML manifests. It identifies specific configuration changes required by new versions, respecting custom builds, private registries, and enterprise variations. Chkk provides precise upgrade diffs tailored to your deployment format, simplifying updates in existing workflows. This flexible support helps maintain consistency across your managed resources.
## Common Operational Considerations
* **Ingress Class & TLS Enforcement:** Ensure Pomerium's ingress class (`spec.ingressClassName: pomerium`) and TLS are explicitly defined. Misconfiguration leads to silent request failures without clear error logs.
* **Identity Provider Dependencies:** Pomerium depends directly on your IdP for authentication; outages or performance degradation can halt application access. Monitor IdP availability and plan contingencies for peak loads.
* **Authorization Policy Pitfalls:** Mistakes in Pomerium Policy Language (PPL), like incorrect logical operators or overly broad patterns, can lead to unintended access. Always test new policies thoroughly and audit decisions.
* **Session & Token Management:** Balance session durations and JWT expiry to avoid user frustration and excessive IdP load. Monitor token refresh behaviors closely, especially after upgrades impacting OAuth mechanisms.
* **Scaling & State:** Pomerium requires shared databroker storage for consistent session state across scaled replicas. Use supported backends (e.g., PostgreSQL) and tune CPU/memory allocations proactively.
* **Forward-Auth Removal:** `forward-auth` was dropped in Pomerium v0.21, so newer images no longer expose the `/verify` endpoint. Replace any NGINX/Traefik forward-auth integrations with the Pomerium Ingress Controller.
* **Operator Deprecation:** The original `pomerium-operator` relies on the removed `extensions/v1beta1` Ingress API and breaks on Cloud Native platforms 1.22+. Migrate to the Helm-based Pomerium Ingress Controller before upgrading clusters.
## Additional Resources
* [Pomerium Documentation](https://www.pomerium.com/docs)
* [Pomerium Releases](https://github.com/pomerium/pomerium/releases)
# PostgreSQL
Source: https://docs.chkk.io/projects/postgresql
Chkk coverage for PostgreSQL. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
export const ReleaseNotesMinVer_0 = "v9.4.25"
export const ChecksMinVer_0 = "v9.5.23"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## PostgreSQL Overview
PostgreSQL is an advanced open-source relational database known for robustness, extensibility, and compliance with SQL standards. Widely used in cloud-native environments, PostgreSQL provides reliable transactional storage, high availability via streaming replication, and point-in-time recovery. Platform teams often deploy PostgreSQL using operators or managed services, benefiting from tailored features such as PostGIS extensions. However, major version upgrades require careful planning and configuration adjustments to maintain performance and availability. Regular monitoring and tuning are essential to adapt to evolving workload demands.
## Chkk Coverage
### Curated Release Notes
Chkk curates PostgreSQL release notes, emphasizing operationally relevant updates like removed configuration parameters or altered defaults. Platform teams receive focused summaries highlighting critical changes, such as PostgreSQL 14's switch from MD5 to SCRAM-SHA-256 for password encryption, requiring client adjustments. This approach ensures essential upgrade impacts aren't overlooked.
### Preflight & Postflight Checks
Chkk runs preflight checks to confirm version compatibility, deprecated settings removal, and proper replication configurations. After upgrading, postflight checks validate replication health, extension loading, and database performance, recommending essential maintenance like optimizer statistics updates (`ANALYZE`). These checks proactively detect common pitfalls, reducing risk and downtime.
### Version Recommendations
Chkk continuously monitors PostgreSQL support timelines, alerting you before versions approach end-of-life, thus preventing exposure to vulnerabilities. Recommendations prioritize stable, community-tested versions to balance reliability with feature availability. Chkk's tailored suggestions incorporate compatibility considerations specific to your managed service or deployment strategy.
### Upgrade Templates
Chkk provides detailed templates for in-place and blue-green upgrade methods, clearly outlining pre-upgrade preparations, execution steps, rollback procedures, and post-upgrade validations. These structured workflows integrate seamlessly with GitOps and CI/CD pipelines, ensuring safe, repeatable upgrades.
### Preverification
Chkk’s preverification simulates PostgreSQL upgrades in isolated environments, detecting issues like incompatible extensions, schema anomalies, or performance regressions before production deployment. Automated reporting identifies potential blockers, enabling proactive adjustments and significantly reducing production upgrade risks.
### Supported Packages
Chkk supports multiple PostgreSQL deployment methods, including Helm charts, operators, custom container images, and cloud-managed services. It respects your existing operational workflows, parsing configurations and providing context-aware upgrade recommendations without disrupting established practices.
## Common Operational Considerations
* **Replication Lag & Failover:** Monitor replication lag closely; significant delays can cause data loss upon failover. Use synchronous replication for critical workloads requiring zero data loss, despite increased write latency.
* **Connection Pooling & Limits:** Implement connection pooling (PgBouncer, PgPool) to prevent resource exhaustion from too many connections. Tune `max_connections` and associated memory parameters carefully to maintain stable performance.
* **Autovacuum and Table Bloat:** Adjust autovacuum settings proactively to avoid table and index bloat, which degrades performance. Regularly monitor vacuum metrics and schedule occasional manual vacuums or reindexing during maintenance.
* **Transaction ID Wraparound:** Ensure autovacuum is enabled and monitored to prevent transaction ID wraparound, which can halt database operations. Set alerts for transaction age thresholds to trigger timely vacuum actions.
* **Extension and Compatibility:** Keep extensions up-to-date and compatible with PostgreSQL upgrades, performing necessary version checks before upgrading. Treat extensions as managed infrastructure components, pinning versions and updating them systematically.
* **WAL Archiving & Disk Space:** Implement robust WAL archiving and monitor disk usage to prevent outages from accumulated WAL files. Configure alerts for WAL directory growth and ensure archiving commands are reliable.
## Additional Resources
* [PostgreSQL Documentation](https://www.postgresql.org/docs/)
* [PostgreSQL Releases](https://www.postgresql.org/support/versioning/)
# Prisma Cloud
Source: https://docs.chkk.io/projects/prisma-cloud
Chkk coverage for Prisma Cloud (formerly Twistlock). We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
export const ReleaseNotesMinVer_0 = "v33.00.169"
export const ChecksMinVer_0 = "v33.02.134"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Prisma Cloud Overview
Prisma Cloud (formerly Twistlock) is a Cloud Native security platform designed to protect containerized workloads throughout their lifecycle. It deploys a lightweight Defender agent on each node to enforce vulnerability scanning, runtime threat detection, compliance policies, and admission controls via Open Policy Agent (OPA). Prisma Cloud integrates directly into CI/CD pipelines to provide shift-left security, ensuring consistent enforcement of image assurance and runtime defense without altering application code. Platform engineers benefit from centralized security management, real-time detection of anomalies, and automated threat mitigation, streamlining operational security across all clusters.
## Chkk Coverage
### Curated Release Notes
Chkk continuously tracks and curates Prisma Cloud release notes, highlighting changes specifically relevant to your environment, such as updated vulnerability scanning rules or altered Defender permissions. Platform teams receive tailored notifications about new security defaults, deprecated APIs, and dropped support for specific versions or container runtimes. By providing targeted summaries, Chkk ensures engineers stay informed of critical operational impacts without having to parse extensive changelogs manually. This reduces the risk of unforeseen upgrade complications or configuration incompatibilities.
### Preflight & Postflight Checks
Chkk executes preflight checks before Prisma Cloud upgrades to validate version compatibility, supported environments, and Defender deployment status. These checks identify problematic configurations, outdated API endpoints, or unsupported upgrade paths (beyond Prisma Cloud's n-2 version policy), allowing remediation prior to the upgrade. Postflight checks verify successful Defender registration, Console health, and policy enforcement consistency across upgraded nodes. This ensures immediate detection and resolution of issues such as failed Defender connections or incomplete Console migrations.
### Version Recommendations
Chkk proactively monitors Prisma Cloud’s release timelines, flagging when your current Console or Defender versions approach end-of-life or support expiry. It recommends stable upgrade targets based on known issues, compatibility requirements, and community feedback, balancing stability with the urgency of security updates. By aligning version recommendations with Prisma Cloud’s official support matrix, Chkk enables platform teams to schedule timely, risk-informed upgrades. This approach prevents downtime caused by outdated or unsupported components.
### Upgrade Templates
Chkk provides detailed Upgrade Templates covering both in-place and blue-green upgrades, aligning with Prisma Cloud’s best practices. In-place upgrades outline steps for backing up Console data, updating Console images, and coordinating Defender rollout to avoid version mismatches. Blue-green upgrade templates offer guidance for deploying a new Console instance temporarily alongside existing deployments, enabling gradual Defender migration and verification. These structured templates integrate seamlessly with GitOps or CI/CD pipelines, ensuring predictable upgrade processes with clear rollback points.
### Preverification
Chkk’s preverification simulates Prisma Cloud upgrades in an isolated environment replicating your current configurations and policies. This digital twin approach uncovers potential upgrade complications, such as schema migration issues, Defender resource constraints, or integration conflicts, before production deployment. Engineers can proactively adjust configurations or resources based on simulation feedback, preventing real-world disruptions. Preverification effectively acts as a rehearsed upgrade, greatly reducing unforeseen operational risks.
### Supported Packages
Chkk supports multiple Prisma Cloud deployment methods—including Helm charts, Prisma Cloud Operator, and Terraform—allowing seamless integration with existing workflows. It analyzes current deployment manifests or GitOps repositories, automatically adapting upgrade guidance to your installation mode and customizations, such as private registries or custom-built Defenders. Whether using self-hosted Console deployments or SaaS-managed solutions, Chkk ensures consistent upgrade practices. This flexibility maintains operational continuity and reduces friction during Prisma Cloud version transitions.
## Common Operational Considerations
* **Console–Defender Version Alignment:** Upgrade Prisma Cloud Console before upgrading Defenders to prevent registration or enforcement failures caused by version mismatches.
* **Defender DaemonSet Coverage:** Ensure the Defender DaemonSet configuration covers all nodes, including tainted or newly provisioned node pools, to avoid unmonitored workloads.
* **Admission Controller Policies:** Initially run Prisma Cloud’s admission controller in alert mode to validate policy rules, preventing unintended blocking of critical pods after upgrades.
* **Resource Allocation & Overhead:** Properly allocate CPU and memory to the Prisma Cloud Console and Defender agents, scaling resources to accommodate cluster density and prevent resource starvation.
* **Network Connectivity & TLS:** Confirm secure Defender-to-Console communication after upgrades by verifying proxies, certificates, and network settings to avoid silent Defender disconnections.
* **RBAC and Permissions:** Regularly review and adjust RBAC permissions and Pod Security Standards to ensure Prisma Cloud components have required privileges, avoiding enforcement gaps during incidents.
## Additional Resources
* [Prisma Cloud Documentation](https://docs.prismacloud.io/en)
* [Prisma Cloud Releases](https://docs.prismacloud.io/en/compute-edition/32/admin-guide/welcome/releases)
# Prom2Teams
Source: https://docs.chkk.io/projects/prom2teams
Chkk coverage for Prom2Teams. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
export const ReleaseNotesMinVer_0 = "v3.2.0"
export const ChecksMinVer_0 = "v3.3.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Prom2Teams Overview
Prom2Teams is an open-source webhook receiver bridging Prometheus Alertmanager and Microsoft Teams, enabling real-time delivery of monitoring alerts directly into Teams channels. It converts Alertmanager JSON payloads into formatted Teams messages, grouping multiple alerts and filtering unnecessary details. Prom2Teams manages alert retries automatically, ensuring reliable notifications even under intermittent connectivity issues. This centralized integration simplifies the alerting pipeline, removing the need for custom scripts or plugins in your observability stack.
## Chkk Coverage
### Curated Release Notes
Chkk curates Prom2Teams release notes, highlighting significant updates, deprecated features, and critical configuration changes relevant to your deployment. It flags essential updates such as Teams webhook schema changes—like the transition to Adaptive Card workflows—that could impact alert delivery. Chkk provides concise insights, enabling quick assessment of operational impacts without needing to parse through extensive GitHub logs. By contextualizing updates, Chkk ensures you know exactly when and why an upgrade matters.
### Preflight & Postflight Checks
Chkk runs preflight checks on your Prom2Teams setup before upgrades, verifying compatibility with the target version and ensuring key configurations—such as webhook endpoints—are correct. It alerts you to deprecated fields or misconfigured connector URLs that could disrupt alert flow. Post-upgrade checks validate successful notification routing, scanning logs and metrics for delivery failures or formatting issues. These automated validations help identify critical issues immediately, minimizing downtime and ensuring alerts reliably reach Teams.
### Version Recommendations
Chkk tracks Prom2Teams versions and proactively alerts you when your deployed version falls out of maintenance—particularly around events like Microsoft’s deprecation of legacy webhook formats. It recommends stable upgrade paths, aligning version suggestions with community feedback and known operational stability. This approach ensures your Prom2Teams deployment consistently supports required features, such as adaptive card workflows, to maintain uninterrupted alerting. Custom internal builds or forks are also supported, allowing tailored guidance based on your specific environment.
### Upgrade Templates
Chkk provides detailed Upgrade Templates covering both in-place and blue-green upgrade strategies for Prom2Teams. In-place templates guide you step-by-step through safely updating your existing deployment while ensuring alert continuity. Blue-green templates detail running parallel Prom2Teams instances, enabling gradual validation of the new deployment with low-risk alerts before switching fully. These templates integrate seamlessly into your existing GitOps or CI/CD workflows, ensuring consistent upgrades with built-in rollback points.
### Preverification
Preverification simulates Prom2Teams upgrades in an isolated environment, mirroring your actual setup to detect potential issues before production deployment. Chkk tests alert processing, payload compatibility, and endpoint connectivity with representative alert payloads. By surfacing configuration or connectivity problems early—such as schema mismatches or endpoint changes—preverification ensures issues are resolved beforehand. This process significantly reduces production risks, ensuring smooth Prom2Teams upgrades with minimal operational impact.
### Supported Packages
Chkk supports all common Prom2Teams deployment methods, including Helm charts, manifests (YAML/Kustomize), and standalone Docker deployments. It seamlessly integrates into your existing deployment approach, adapting upgrade recommendations to your specific packaging and repository management practices. Custom configurations, such as private container registries, or modified Helm values, are recognized and incorporated. This flexibility allows Chkk to deliver accurate, actionable upgrade guidance tailored specifically to your Prom2Teams environment.
## Common Operational Considerations
* **Alertmanager Webhook Mismatch:** Incorrect webhook URLs (e.g., old "Connector" endpoint) cause silent notification failures. Always update Alertmanager receiver URLs to match Prom2Teams connector paths precisely.
* **Teams Connector Deprecation:** Legacy Teams webhooks are deprecated; versions below Prom2Teams 5.0.0 fail silently. Upgrade promptly to ensure compatibility with Microsoft’s new Adaptive Card-based workflow.
* **Single-Instance Risk:** A single Prom2Teams instance creates a critical failure point; use at least two replicas behind a Service. Load balancing ensures continuous alert delivery even if one instance fails.
* **Custom Template Compatibility:** After upgrades, custom Jinja2 templates may become outdated, causing missing or malformed fields in Teams messages. Review templates against new release notes and test alerts thoroughly.
* **Monitoring Delivery Failures:** Prom2Teams metrics should be monitored closely for increased HTTP errors or dropped alerts. Set Prometheus alerts to detect and respond proactively to Teams webhook delivery issues.
* **Alert Volume and Rate Limits:** Large alert bursts can trigger Teams webhook rate limits or truncated messages. Tune Alertmanager grouping and routing rules to aggregate alerts effectively and avoid notification throttling.
## Additional Resources
* [Prom2Teams Documentation](https://github.com/idealista/prom2teams)
* [Prom2Teams Releases](https://github.com/idealista/prom2teams/releases)
# Prometheus
Source: https://docs.chkk.io/projects/prometheus
Chkk coverage for Prometheus. We provide curated release notes, preflight/postflight checks, and Upgrade Templates—all tailored to your environment.
export const ReleaseNotesMinVer_0 = "v2.19.1"
export const ChecksMinVer_0 = "v2.25.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Prometheus Overview
Prometheus is a CNCF-graduated, open-source monitoring system that scrapes metrics from targets via HTTP endpoints. It stores time-series data locally and supports fast, flexible queries through PromQL. With service discovery, Prometheus detects relevant components and application pods automatically. Alertmanager integration adds powerful alerting capabilities, triggering escalations based on custom rules. This seamless observability stack equips platform teams with deep insights into system performance and reliability.
## Chkk Coverage
### Curated Release Notes
Chkk filters Prometheus release notes to highlight critical changes—like deprecated flags, shifting defaults, or newly required configs. By focusing on operationally relevant updates, it lets you quickly see which releases might affect your custom alerts or exporter configurations. Chkk also flags important EOL notices, ensuring you don't unknowingly rely on an unsupported version.
### Preflight & Postflight Checks
Before upgrading Prometheus, Chkk's preflight checks confirm your existing setup won't break due to incompatible flags or insufficient resource allocations. It inspects manifests (Helm, Kustomize, or raw YAML) for any known pitfalls and references Prometheus' official support details. Postflight checks then verify that upgraded instances are scraping all targets, that recorded rules remain valid, and that no silent failures have occurred in logs or Alertmanager alerts.
### Version Recommendations
Chkk tracks Prometheus' release notes and recommends safe upgrade targets based on LTS availability, community feedback, and alignment with your cluster's Kubernetes version. It identifies upcoming EOL milestones to help you plan timely upgrades, avoiding last-minute scrambles for security patches. If you're multiple versions behind, Chkk surfaces a path that balances new features with proven stability.
### Upgrade Templates
Chkk's **Upgrade Templates** detail two primary approaches for Prometheus upgrades—in-place and blue-green. In an in-place scenario, Chkk outlines rolling updates across HA pairs to preserve continuous scraping. For a blue-green strategy, it offers guidance on spinning up a parallel deployment, comparing scraped data between old and new versions, and gradually cutting over to the updated instance.
### Preverification
Through preverification, Chkk simulates your Prometheus upgrade in a controlled environment using copies of existing configs and metrics data. This process uncovers issues like deprecated syntax, unexpected performance overhead, or storage format mismatches before impacting production. It's a practical safeguard that reduces the risk of losing visibility or encountering runtime errors during real upgrades.
### Supported Packages
Chkk works with various packaging methods, including Helm charts (such as the Prometheus Operator), Kustomize overlays, and standard manifests. It respects custom images, private registries, or custom build requirements, so you can maintain consistency with your existing CI/CD pipelines. This unified approach ensures you don't need to change tooling to leverage Chkk's upgrade intelligence.
## Common Operational Considerations
* **Avoiding Monitoring Gaps:** For minimal downtime, upgrade Prometheus in an HA pair or use a staggered approach in single-instance deployments. Ensure time-series data and configuration backups are taken to prevent loss during rollouts.
* **Maintaining Exporter Compatibility:** Verify that all exporters produce valid metrics adhering to updated content-type requirements. Automate checks to flag exporters likely to fail under stricter parsing or deprecated protocols.
* **Cleaning Deprecated Flags:** Removed command-line flags or configuration fields can break Prometheus startup after an upgrade. Review release notes thoroughly and replace obsolete flags with supported syntax to avoid unexpected crashes.
* **Integration Updates:** If Prometheus relies on older discovery APIs, a new release may drop that support. Follow official migration guides and switch to supported API versions to maintain stable service discovery.
## Additional Resources
* [Prometheus Documentation](https://prometheus.io/docs/introduction/overview/)
* [Prometheus Releases](https://github.com/prometheus/prometheus/releases)
# Prometheus Adapter
Source: https://docs.chkk.io/projects/prometheus-adapter
Chkk coverage for Prometheus Adapter. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
export const ReleaseNotesMinVer_0 = "v0.8.2"
export const ChecksMinVer_0 = "v0.10.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Prometheus Adapter Overview
Prometheus Adapter provides Kubernetes clusters with resource, custom, and external metrics APIs, enabling Horizontal Pod Autoscalers (HPAs) to leverage Prometheus-collected metrics beyond basic CPU and memory. By regularly querying Prometheus, the adapter exposes metrics through Kubernetes API endpoints (`custom.metrics.k8s.io` and `external.metrics.k8s.io`) for advanced autoscaling scenarios. Platform teams already using Prometheus can optionally replace Metrics Server entirely, streamlining metrics collection and reducing complexity. This integration unlocks highly granular, application-specific scaling policies directly driven by Prometheus data, significantly enhancing autoscaling effectiveness.
## Chkk Coverage
### Curated Release Notes
Chkk curates Prometheus Adapter release notes, highlighting only the most relevant changes for your environment, such as new metric discovery formats or required RBAC updates. It surfaces critical bug fixes, like query timeouts or certificate handling improvements, clarifying their operational impacts. If configuration syntax adjustments or API changes occur, Chkk explicitly calls out their significance to your deployment. This focused summary enables platform engineers to understand upgrade implications quickly and accurately, without sifting through irrelevant details.
### Preflight & Postflight Checks
Chkk’s preflight checks validate Kubernetes version compatibility, adapter configuration correctness, Prometheus connectivity, and RBAC permissions before upgrades. They proactively identify issues such as deprecated configuration syntax or unreachable Prometheus endpoints. After upgrading, postflight checks confirm the adapter’s operational health, API service availability, and HPA metric retrieval. Any issues, like failed metrics queries or adapter pod errors, are promptly flagged, ensuring quick resolution and minimal disruption.
### Version Recommendations
Chkk continuously monitors Prometheus Adapter versions, alerting teams when their deployment falls outside the community maintenance support window. By referencing release history and community feedback, Chkk highlights risks in older adapter versions, such as memory leaks or compatibility gaps. It suggests stable, tested upgrade targets aligned with Kubernetes versions and community best practices, balancing new features and proven stability. This approach ensures upgrades maintain operational reliability without introducing unforeseen problems.
### Upgrade Templates
Chkk provides structured Upgrade Templates for safe, repeatable Prometheus Adapter upgrades. Templates clearly document each step, including Helm or manifest updates, rollback instructions, and key checkpoints like API service availability validation. Though in-place upgrades are common, Chkk also supports blue-green testing with parallel adapter deployments in staging environments. Integrated seamlessly into GitOps and CI/CD workflows, these templates significantly reduce human error and enhance deployment confidence.
### Preverification
Chkk’s preverification simulates Prometheus Adapter upgrades in isolated environments, proactively surfacing configuration or compatibility issues like malformed queries or RBAC permission mismatches. By testing adapter deployments against representative Prometheus data, platform engineers can identify and resolve issues before production upgrades. Preverification provides detailed reports on adapter startup health, metric availability, query performance, and warnings. This "dry run" strategy ensures real upgrades proceed smoothly, minimizing risk and downtime.
### Supported Packages
Chkk supports diverse Prometheus Adapter deployment methods, including official Helm charts, Kustomize, static manifests, and packaged distributions like kube-prometheus. It fully respects custom images, private registries, or forks, ensuring precise upgrade recommendations tailored to your specific configuration. Chkk generates accurate manifests, Helm diffs, or Kustomize patches based on your existing management approach. Thus, teams maintain workflow consistency without modifying their established deployment practices.
## Common Operational Considerations
* **Aggregated API Certificates:** Misconfigured or invalid TLS certificates cause the API service to be unavailable, breaking metric collection. Automate certificate management (e.g., via cert-manager) to maintain valid certificates and avoid outages.
* **Metrics Server Replacement:** When using Prometheus Adapter to replace Metrics Server, ensure Prometheus scrapes core metrics (CPU/memory) and adapter rules expose them. Otherwise, HPAs relying on resource metrics may break unexpectedly.
* **Misconfigured Metric Rules:** Incorrect or overly broad PromQL queries in the adapter configuration lead to missing metrics or adapter startup failures. Validate queries externally first, and review adapter logs regularly to catch issues early.
* **Multi-Tenant Isolation:** The adapter’s global metrics exposure can cause cross-tenant metric leaks. Deploy separate adapter instances per tenant or enforce namespace-specific label filters within queries to maintain strict isolation.
* **Query Load and Performance:** Excessive or high-cardinality metric queries increase adapter and Prometheus resource usage, causing query delays or timeouts. Optimize PromQL queries, limit metric exposure, and monitor adapter resource utilization closely.
* **HPA Scaling Issues:** HPAs failing to scale typically indicate adapter configuration or metric availability issues. Verify metrics directly via API endpoints and closely monitor adapter health to ensure autoscaling remains reliable.
## Additional Resources
* [Prometheus Adapter Documentation](https://github.com/kubernetes-sigs/prometheus-adapter)
* [Prometheus Adapter Releases](https://github.com/kubernetes-sigs/prometheus-adapter/releases)
# Prometheus Blackbox Exporter
Source: https://docs.chkk.io/projects/prometheus-blackbox-exporter
Chkk coverage for Prometheus Blackbox Exporter. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
export const ReleaseNotesMinVer_0 = "v0.17.0"
export const ChecksMinVer_0 = "v0.20.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Prometheus Blackbox Exporter Overview
Prometheus Blackbox Exporter is an open-source synthetic monitoring tool for checking the availability and performance of endpoints over protocols such as HTTP/S, TCP, DNS, and ICMP. It runs probes externally against specified targets and exposes results as Prometheus metrics, enabling proactive uptime and latency monitoring. Platform teams leverage Blackbox Exporter to detect network outages, SSL certificate issues, DNS failures, and endpoint unresponsiveness early. Its external probing mechanism helps ensure services are reliably reachable, complementing traditional internal monitoring solutions.
## Chkk Coverage
### Curated Release Notes
Chkk curates Prometheus Blackbox Exporter release notes, highlighting critical operational changes and new probe features relevant to your deployments. Instead of manually parsing each update, Chkk provides concise briefs about impactful updates like TLS version deprecations or new gRPC probe types. This targeted insight ensures platform teams promptly identify and address potential configuration issues introduced by new exporter versions. Chkk also flags deprecated configurations, ensuring smooth and predictable upgrades.
### Preflight & Postflight Checks
Chkk executes preflight checks to verify compatibility of current configurations with the intended Blackbox Exporter version, highlighting deprecated or modified module settings. Post-upgrade, Chkk’s postflight checks confirm that probes remain operational, scraping metrics correctly and validating probe success rates. Automated checks detect anomalies like increased probe failures or exporter errors immediately after upgrades, enabling quick remediation. This comprehensive verification reduces upgrade risks and ensures monitoring continuity.
### Version Recommendations
Chkk tracks Blackbox Exporter releases, proactively alerting platform engineers when deployed versions approach the end of their community-supported lifecycle or contain known issues. Version advisories are accompanied by context-specific explanations, detailing critical bugs, security vulnerabilities, or compatibility concerns. Recommendations include stable upgrade targets balancing new functionality and reliability. Organizations with custom or forked Blackbox Exporter builds can configure Chkk to respect specific support and lifecycle policies.
### Upgrade Templates
Chkk provides structured Upgrade Templates covering in-place and blue-green deployment strategies for the Blackbox Exporter, aligning with Prometheus community best practices. Templates outline clear, step-by-step instructions including critical checkpoints such as configuration preservation and verification of metrics scraping post-deployment. They also incorporate rollback procedures to quickly revert problematic changes. This structured process reduces operational risk and ensures predictable outcomes.
### Preverification
Chkk offers a preverification capability that simulates the Blackbox Exporter upgrade process in an isolated testing environment mirroring production configurations. This "dry run" identifies issues such as configuration incompatibilities, probe failures, or increased resource usage before production impact occurs. By addressing discovered issues proactively, platform teams confidently execute production upgrades. Preverification thus significantly enhances operational safety and reliability.
### Supported Packages
Chkk supports multiple Blackbox Exporter deployment methods including Helm, Kustomize, and YAML manifests, seamlessly integrating with your existing workflows. It accommodates custom images and private registries, preserving configuration consistency across upgrades. Chkk’s capability extends to monitoring configurations defined via Prometheus Operator’s `Probe` custom resources and GitOps repositories. This flexibility ensures comprehensive upgrade management regardless of deployment strategy.
## Common Operational Considerations
* **Probe Timeout and Interval Mismatch:** Align the probe module timeout with Prometheus scrape intervals to prevent false-negative probe failures. Carefully balance timeout durations to avoid overlapping scrapes.
* **DNS and Network Access:** Ensure Blackbox Exporter pods have proper network and DNS permissions to prevent widespread probe failures. ICMP probes require `CAP_NET_RAW` privileges to function correctly.
* **High Probe Volume & Resource Use:** Monitor resource usage closely if managing many frequent probes, and scale exporter replicas or allocate sufficient CPU/memory resources accordingly. Evaluate exporter metrics to detect resource bottlenecks early.
* **Labeling and Relabeling Pitfalls:** Correctly configure Prometheus relabeling rules to attribute probe metrics accurately to target endpoints, preventing metrics aggregation errors. Misconfigured relabeling can obscure outage sources.
* **Configuration Reloading:** After updating `blackbox.yml`, restart the exporter or trigger configuration reloads using tools like configmap-reload. Failure to reload can cause unnoticed discrepancies between configurations and running probes.
* **HTTPS and TLS Pitfalls:** Explicitly define `tls_config` in probe modules to support legacy TLS versions or custom CA certificates, avoiding unintended TLS handshake failures. Monitor certificate expiry metrics (`probe_ssl_earliest_cert_expiry`) proactively to prevent unexpected downtime.
## Additional Resources
* [Prometheus Blackbox Exporter Documentation](https://github.com/prometheus/blackbox_exporter)
* [Prometheus Blackbox Exporter Releases](https://github.com/prometheus/blackbox_exporter/releases)
# Prometheus JMX Exporter
Source: https://docs.chkk.io/projects/prometheus-jmx-exporter
Chkk coverage for Prometheus JMX Exporter. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
export const ReleaseNotesMinVer_0 = "v0.14.0"
export const ChecksMinVer_0 = "v0.16.1"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Prometheus JMX Exporter Overview
Prometheus JMX Exporter collects metrics from Java applications using Java Management Extensions (JMX) and exposes them in a Prometheus-friendly format. Deployed either as a Java agent within JVMs or as a standalone service, it efficiently monitors applications such as Kafka or Cassandra. The Java agent mode is typically preferred in Cloud Native deployments due to its simpler networking model compared to standalone mode. The exporter supports essential observability standards, including OpenTelemetry integration, enabling comprehensive monitoring for JVM-based workloads.
## Chkk Coverage
### Curated Release Notes
Chkk provides concise, curated summaries of Prometheus JMX Exporter release notes, focusing on critical new features, breaking changes, or significant fixes impacting your environment. For instance, Chkk flags changes like metric endpoint paths or altered naming conventions from new releases. It highlights the introduction of security features such as HTTPS or BasicAuth and informs about deprecated support for older Java versions. This targeted approach ensures platform engineers quickly understand relevant upgrade impacts without parsing detailed upstream notes.
### Preflight & Postflight Checks
Chkk performs preflight checks before upgrading the JMX Exporter, validating Java version compatibility and configuration file correctness. These checks identify issues such as deprecated YAML syntax or unsupported JVM versions, preventing upgrade failures. Post-upgrade, Chkk verifies metrics availability, ensures successful Prometheus scrapes, and analyzes exporter logs for errors or metric collection issues. This proactive validation helps engineers swiftly address potential issues and maintain continuous monitoring reliability.
### Version Recommendations
Chkk continuously tracks Prometheus JMX Exporter releases, alerting when your deployed version falls out of the maintenance window or misses critical updates. It flags key improvements, like standardized metric endpoints and security patches, guiding you towards safer upgrade paths. Chkk considers community feedback and stability reports when recommending optimal upgrade versions, balancing new features against operational reliability. This approach helps teams proactively maintain exporter health, reducing unexpected issues from running obsolete or unstable releases.
### Upgrade Templates
Chkk provides detailed Upgrade Templates, outlining best practices for both in-place and blue-green upgrades of the JMX Exporter. The templates include clear, sequential steps such as incrementally updating Java agents or sidecar deployments, verifying metrics, and ensuring compatibility with Prometheus configurations. Canary templates guide phased rollouts, facilitating side-by-side comparisons of metrics and performance between exporter versions, along with rollback procedures. These structured playbooks significantly reduce risk and streamline integration into GitOps or CI/CD pipelines.
### Preverification
Chkk offers a preverification environment for rehearsing JMX Exporter upgrades, effectively simulating the upgrade process in isolation. This practice identifies configuration issues, compatibility errors, and metric discrepancies before they affect production systems. Platform teams can proactively adjust exporter configurations or address resource allocation issues surfaced during preverification. By validating each upgrade step beforehand, engineers confidently execute production upgrades, minimizing downtime or monitoring gaps.
### Supported Packages
Chkk fully supports common deployment methods for the Prometheus JMX Exporter, including Helm charts, plain YAML manifests, and direct Java agent configurations. It accommodates custom builds, private registries, and vendor-specific variations, ensuring compatibility with diverse infrastructure setups. Chkk integrates seamlessly with GitOps workflows, accurately mapping existing configurations to recommended upgrade targets. This flexibility allows engineers to maintain established deployment practices while leveraging Chkk’s version analysis and upgrade guidance.
## Common Operational Considerations
* **Standalone Mode Pitfalls:** JMX Exporter standalone mode requires complex RMI port configuration and may conflict with cluster networking. Prefer Java agent mode for simpler deployments.
* **Exporter Overload:** Excessive scrape frequencies or concurrent Prometheus scrapes can overwhelm the exporter. Maintain moderate scrape intervals and consider thread pool tuning.
* **Metric Filtering & Cardinality:** Unfiltered metric collection can overwhelm Prometheus with excessive or dynamic metrics. Regularly refine exporter rules to expose only necessary metrics.
* **Resource Usage:** JMX Exporter can increase JVM CPU and memory overhead, especially with extensive metrics. Monitor resource consumption and adjust scrape intervals or metric scope accordingly.
* **Metrics Endpoint Security:** The exporter’s HTTP metrics endpoint is unsecured by default. Consider enabling HTTPS and authentication or restrict access via network policies.
* **Scrape Configuration Alignment:** Prometheus scrape configurations must match exporter deployments, particularly regarding endpoint paths and ports. Confirm scrape alignment after deploying or upgrading the exporter.
## Additional Resources
* [Prometheus JMX Exporter Documentation](https://github.com/prometheus/jmx_exporter)
* [Prometheus JMX Exporter Releases](https://github.com/prometheus/jmx_exporter/releases)
# RabbitMQ
Source: https://docs.chkk.io/projects/rabbitmq
Chkk coverage for RabbitMQ. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
export const ReleaseNotesMinVer_0 = "v3.8.12"
export const ChecksMinVer_0 = "v3.9.1"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## RabbitMQ Overview
RabbitMQ is a message broker that uses the AMQP protocol to enable asynchronous communication among distributed services. It relies on queues for storage and buffering, ensuring that producers and consumers remain decoupled. Clustering, mirroring, and quorum queues support high availability, while exchange types and routing keys offer flexible messaging patterns. RabbitMQ also supports multiple protocols such as MQTT, STOMP, and AMQP 1.0, making it a versatile solution for many use cases. Security features include TLS encryption, authentication mechanisms, and policy-based access controls.
## Chkk Coverage
### Curated Release Notes
Chkk filters official RabbitMQ release notes to spotlight relevant new features, security updates, and deprecations. It identifies policy or queue-type changes that could affect your environment, saving you from tracking every update. Each note includes recommended actions for addressing potential issues like plugin or Erlang version mismatches. Chkk's summaries focus on operational impact, helping you plan more effectively. This prevents surprises caused by overlooked upstream changes.
### Preflight & Postflight Checks
Chkk scans your RabbitMQ clusters and configurations to confirm compatibility before you upgrade. It flags potential downtime risks, like deprecated queue types or insufficient resource allocations. Post-upgrade, it verifies cluster health by checking node status, alarms, and queue synchronization. This automated process quickly uncovers misconfigurations, allowing you to remedy them before they escalate. The result is more reliable and consistent RabbitMQ deployments.
### Version Recommendations
Chkk tracks RabbitMQ's support lifecycle and warns you when your version nears end-of-life. It draws on the official compatibility matrix, ensuring your Erlang and RabbitMQ versions align. If you're on a risky or deprecated release, Chkk suggests a stable upgrade target and justifies that choice based on known issues. Recommendations account for your current plugin ecosystem and resource constraints. This context-driven approach helps you plan upgrades confidently.
### Upgrade Templates
Chkk's **Upgrade Templates** provide guided workflows for both in-place and blue-green RabbitMQ upgrades. In-place upgrades focus on sequential node updates with minimal impact on ongoing traffic. Blue-green strategies spin up a parallel cluster or revision, easing the transition for mission-critical data. Each template includes automated checks and clear rollback instructions in case of failure. This reduces human error and helps maintain seamless messaging operations.
### Preverification
To avoid breaking production, Chkk can simulate the entire upgrade in a digital twin environment. It uses your current configuration, queue definitions, and plugins to test the next RabbitMQ version. This reveals issues with memory usage, queue compatibility, or conflicting policies before changes go live. Test results guide any adjustments needed to ensure a smoother production upgrade. By addressing these risks in advance, you maintain a stable messaging layer during real deployments.
### Supported Packages
Chkk recognizes that organizations package RabbitMQ using Helm, Kustomize, or plain manifests. It accommodates these approaches by adjusting its workflows, commands, and validations accordingly. This includes working with custom or private images, as well as specialized vendor forks of RabbitMQ. Chkk tracks and catalogs image references, ensuring your deployments stay consistent across versions. In this way, it fits into your existing GitOps or CI/CD pipeline seamlessly.
## Common Operational Considerations
* **Queue Mirroring and High Availability:** Classic mirrored queues can suffer split-brain if not carefully configured; quorum queues offer more robust replication. Always run an odd number of nodes for reliable majority-based fault tolerance.
* **Persistent vs. Transient Messages:** Durable queues and persistent messages protect against data loss but reduce throughput. Use transient messages for less critical data to optimize performance.
* **Resource Limits and Memory Watermarks:** RabbitMQ stops accepting new messages if it hits its memory or disk threshold. Set memory alarms and resource limits in alignment to avoid OOM kills and blocked publishers.
* **Connection Handling and Load Balancing:** Large numbers of client connections can overwhelm file descriptors; raise OS limits if needed. Distribute connections across nodes and prefer connection reuse over frequent opens.
* **Shovel and Federation:** Shovel replicates messages from one broker to another; plan for throughput and network issues. Federation links exchanges across clusters, but be mindful of potential duplicates or latency under network stress.
* **Erlang and RabbitMQ Version Compatibility:** Each RabbitMQ release supports specific Erlang versions, so mismatched upgrades can break clusters. Check the official compatibility matrix and upgrade Erlang in sync with RabbitMQ.
## Additional Resources
* [RabbitMQ Documentation](https://www.rabbitmq.com/docs)
* [RabbitMQ Releases](https://github.com/rabbitmq/rabbitmq-server/releases)
# Redis
Source: https://docs.chkk.io/projects/redis
Chkk coverage for Redis. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v6.0.14"
export const ChecksMinVer_0 = "v6.2.5"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Redis Overview
Redis is a high-performance, in-memory key-value store widely used for caching, session management, and real-time analytics. It supports various data structures (strings, hashes, sets, sorted sets, streams) and can store data in memory with optional persistence to disk. Replication and clustering features help achieve high availability and horizontal scaling, while integration with operators or Helm/Kustomize deployments ensures automated failover and easier lifecycle management.
## Chkk Coverage
### Curated Release Notes
Chkk condenses official Redis release notes into highlights of breaking changes, security fixes, and newly introduced capabilities that may affect your caching or replication setup. For instance, if a version modifies RDB/AOF persistence or patch addresses a CVE, Chkk flags it to ensure teams stay informed about potential impacts and urgent fixes.
### Preflight & Postflight Checks
Before upgrading Redis, Chkk runs preflight checks to detect deprecated commands, outdated configurations, and resource constraints that may cause disruption. Afterward, postflight checks validate that replication or cluster operations are intact and that performance metrics remain stable. This two-step process prevents unexpected downtime and verifies the cluster's health once the new version is in place.
### Version Recommendations
Chkk continuously monitors Redis's support lifecycle to recommend stable releases that align with security patches, feature maturity, and cluster compatibility. It also tracks EOL milestones, alerting you when your current version will soon lack upstream support. This proactive approach helps you plan upgrades before you encounter unmaintained or vulnerable builds.
### Upgrade Templates
Chkk offers two upgrade strategies for Redis: in-place and blue-green. In-place performs a rolling upgrade on each node or replica in sequence, maintaining availability for read/write operations. Blue-green spins up a new Redis deployment in parallel, syncing data and cutting over once validated. This method aims for near-zero downtime and provides a straightforward rollback if issues arise.
### Preverification
For risky or complex upgrades, Chkk's preverification simulates the Redis upgrade in a test environment. It replicates your persistent storage and configuration, then applies the new version to spot any compatibility or performance issues. This dry-run approach means you can address mismatches (e.g., changed AOF/RDB formats) safely before deploying to production.
### Supported Packages
Regardless of how you install Redis—Helm, Kustomize, or raw manifests—Chkk recognizes and supports it. This ensures custom images, private registries, and operator-based deployments all benefit from Chkk's checks, curated release info, and automated upgrade processes without requiring you to switch tools.
## Common Operational Considerations
* **Replication Conflicts:** Redis Sentinel or Cluster mode auto-promotes a replica if the master fails, but async replication can lose writes if the master dies pre-propagation. Use min-replicas-to-write/min-replicas-max-lag to reduce data loss, and always run at least three Sentinels (or multiple Cluster replicas) to avoid split-brain.
* **Persistence Gaps:** RDB captures point-in-time data, while AOF logs every write; a crash during a 5-minute snapshot can lose nearly 5 minutes of data.\*\* Appendfsync everysec narrows that gap at higher I/O cost, and tuning AOF rewrite frequency balances performance with durability.
* **Blocking Commands:** Redis is single-threaded, so commands like KEYS \* or large LRANGE scans can stall operations; track slow queries via SLOWLOG. Use SCAN or smaller queries, and offload heavy tasks to replicas or application logic to avoid cluster-wide latency spikes.
* **Eviction Storm:** When maxmemory is reached, Redis evicts keys based on its policy (e.g., allkeys-lru); sudden write spikes can cause eviction storms and boost CPU usage. Keep the working set in memory, set proper TTLs, and tune maxmemory-samples to balance eviction accuracy with performance.
* **Cluster Slot Imbalances:** In Redis Cluster, uneven hashing or distribution can create hot shards; check slot allocation and re-shard if usage or load skews. For multi-key operations, use hash tags ({key}) to keep related keys in the same slot and prevent cross-slot errors.
## Additional Resources
* [Redis Documentation](https://redis.io/docs/latest/)
* [Redis Releases](https://github.com/redis/redis/releases)
# Vault Secrets Operator
Source: https://docs.chkk.io/projects/vault-secrets-operator
Chkk coverage for Vault Secrets Operator. We provide version recommendations, preflight/postflight checks, and Upgrade Templates—ensuring worry-free operations.
export const ReleaseNotesMinVer_0 = "v1.12.0"
export const ChecksMinVer_0 = "v1.16.4"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Vault Secrets Operator Overview
Vault Secrets Operator (VSO) manages secrets by continuously synchronizing them from HashiCorp Vault. It injects Vault data into Secrets, supports automatic rotation, and audits changes for compliance. Platform engineers benefit from centralized policy controls in Vault while apps consume secrets via native K8s workflows. The operator reduces duplication, increases security, and automates secret lifecycle tasks. It's deployable across multiple distributions and works with a range of Vault secret engines.
## Chkk Coverage
### Curated Release Notes
Chkk curates official VSO release notes into short, actionable updates, flagging features like dynamic secret engine support or new CRDs. It calls out deprecations, patches, or behavior shifts—so you know exactly what might affect your existing VaultSecret definitions. Instead of sifting through every upstream detail, you get streamlined highlights and a clear sense of operational impact. This allows you to proactively address changes in roles, policies, or secret formats.
### Preflight & Postflight Checks
Before each upgrade, Chkk's preflight checks scan for CRD compatibility, Kubernetes version support, and potential Vault auth misconfigurations. It detects outdated fields in your VaultSecret resources, ensuring you don't encounter sync failures or unresolved references post-upgrade. Afterward, the postflight checks inspect operator logs and secret rotation status to confirm a healthy deployment. This prevents hidden issues—like leftover pods or stale secrets—from lingering unnoticed.
### Version Recommendations
Chkk constantly tracks Vault Secrets Operator releases and monitors upstream known issues or EOL announcements. If your current version is nearing end-of-support or is incompatible with your Vault version, you receive timely alerts and stable upgrade paths. This ensures you maintain critical security fixes and functional parity with new cluster releases. Chkk also factors in feedback from similar environments to suggest the most reliable target version.
### Upgrade Templates
Chkk delivers structured procedures for both in-place and blue-green operator upgrades, mapping out each CRD update, operator pod replacement, and rollback checkpoint. In an in-place scenario, you'll apply updated manifests or Helm charts, then verify secret injections are proceeding correctly. A blue-green deployment spins up a parallel operator instance with the new version, letting you shift secret management gradually. These templates reduce risk and help ensure continuous secure secret delivery during version transitions.
### Preverification
Chkk can simulate each step of the upgrade in a test environment, applying your exact VaultSecrets and CRD definitions to confirm they're recognized by the new operator. This dry-run identifies mismatches—like changed default secret paths or required Vault policy updates—long before you touch production. By pinpointing collisions or resource limits in advance, you can adjust configurations or fix them before they disrupt critical apps. This approach is particularly valuable in regulated or large-scale contexts.
### Supported Packages
Whether you use Helm, Kustomize, or an Operator Lifecycle Manager (OLM) workflow, Chkk analyzes your manifests and tailors upgrade steps accordingly. It supports custom images from private registries or specialized builds, providing the same safety checks and validations regardless of deployment method. Chkk also recognizes if you're using a multi-namespace or single-tenant operator model and accounts for that in its analysis. This flexibility ensures a consistent experience across diverse environments.
## Common Operational Considerations
* **Vault Authentication & Roles:** Maintain tightly scoped Vault policies, and ensure the operator's service account has only the minimal required access. Monitor token expiration logs and renewals to prevent sync interruptions.
* **Multi-Cluster & Namespaces:** Decide whether a single operator instance or multiple namespace-scoped instances best fits your security and tenancy needs. Restrict each operator's reach via RBAC so it manages only relevant secrets.
* **Secret Rotation Behavior:** Short TTLs can lead to frequent pod restarts, so validate rotation strategies against application-level reload requirements. When using mounted secrets, confirm your app processes re-read updated files.
* **Vault Outages & Operator Failover:** Any Vault downtime or network disruption can halt secret updates, so use HA Vault deployments and robust retry settings in VSO. Keep an eye on operator logs to spot connectivity issues early.
* **CRD Updates & Backward Compatibility:** Validate CRD changes against your existing VaultSecret definitions prior to upgrading. Keep backups of your operator and CRDs in case you need a quick rollback.
## Additional Resources
* [Vault Secrets Operator Repository](https://github.com/ricoberger/vault-secrets-operator)
* [Vault Secrets Operator Releases](https://github.com/ricoberger/vault-secrets-operator/releases)
# Vertical Pod Autoscaler
Source: https://docs.chkk.io/projects/vertical-pod-autoscaler
Chkk coverage for Vertical Pod Autoscaler. We provide preflight/postflight checks, curated release notes, and Upgrade Templates—designed for seamless upgrades.
export const ReleaseNotesMinVer_0 = "v0.8.0"
export const ChecksMinVer_0 = "v0.9.0"
## Coverage Matrix
| | |
| --------------------------------------- | ---------------------------------------- |
| **Generate IaC Pull Requests** | Available (Request Preview in Free Tier) |
| **Curated Release Notes** | {ReleaseNotesMinVer_0} to latest |
| **Guided & Automated Safety Checks** | {ChecksMinVer_0} to latest |
| | |
| **Rapid Upgrade Assessments** | Available |
| **Upgrade Templates & Plans** | In-Place, Blue-Green |
| **Upgrade Advisories** | Available |
| **Preverification** | Available |
| | |
| **End-Of-Life (EOL) Information** | Available |
| **Version Incompatibility Information** | Available |
| **Operational Risk Detection** | Available |
| | |
| **Supported Packages** | Helm, Kustomize, Kube |
| **Private Registries** | Covered |
| **Custom Built Images** | Covered |
## Vertical Pod Autoscaler Overview
Vertical Pod Autoscaler (VPA) automatically adjusts the CPU and memory requests of workloads based on real-time usage patterns. It analyzes historical metrics to right-size resources, reducing the risk of OOM kills and preventing excessive over-provisioning. By dynamically evicting and recreating pods with updated resource requests, it helps maintain efficient cluster utilization. Since VPA acts as an admission webhook, it integrates seamlessly with the Cloud Native control plane while requiring careful coordination if other autoscalers are in use. Overall, VPA provides a hands-off way to continuously match resource consumption to actual demand.
## Chkk Coverage
### Curated Release Notes
Chkk continuously monitors the official release notes and changelogs for the Vertical Pod Autoscaler. It distills these into actionable insights—highlighting any breaking changes, deprecated APIs/CRDs, and important operational impacts in each release. Instead of wading through raw upstream notes, you get a curated summary focused on what matters for your clusters. For example, if a new VPA version removes a beta API or changes how recommendations are calculated, Chkk will flag this prominently so you can prepare in advance. This saves time and ensures you don't miss critical changes when planning an upgrade.
### Preflight & Postflight Checks
Upgrading VPA without proper checks can lead to misconfigurations or downtime. Chkk performs preflight validations to ensure your environment is ready for the new VPA version. These preflight checks catch issues like missing Metrics Server, outdated VPA CRDs, or insufficient cluster resources, preventing a failed rollout due to configuration mismatches. After the upgrade, Chkk runs postflight checks to confirm everything is working correctly. It ensures the new VPA components are running healthy and that your workloads are receiving recommendations as expected. Together, the pre- and postflight checks provide a safety net around the upgrade, ensuring any problems are identified and addressed either before changes are applied or immediately after the new VPA is in place.
### Version Recommendations
Chkk's platform keeps track of VPA release milestones and end-of-life (EOL) information. It will proactively alert you if the VPA version you're running is approaching EOL or has become outdated. Chkk suggests safe upgrade paths to a supported version. These version recommendations are tailored to your environment - for example, if you're on a legacy 0.x or 1.x VPA release, Chkk will identify a stable newer release that is compatible with your current Kubernetes cluster version and VPA configuration. Chkk helps you plan upgrades ahead of time so you're never caught running an unsupported VPA.
### Upgrade Templates
Upgrading the Vertical Pod Autoscaler can involve multiple steps (updating CRDs, deploying new controller components) in a live cluster, so Chkk provides **Upgrade Templates** for two strategies: in-place upgrades and blue-green (canary) upgrades. The in-place template guides you through backing up current VPA configurations, applying new CRDs, and updating the recommender, updater, and admission webhook with safety checks and rollback points to ensure high availability. The blue-green template runs a new VPA version in parallel (for example, in a separate namespace), letting you gradually migrate VPA objects and observe behavior on subsets of workloads. It ensures only one VPA actively adjusts a given workload at a time and offers a clear path to fully cut over or roll back if issues arise.
### Preverification
One of Chkk's most powerful capabilities is preverification - essentially a dry-run of your VPA upgrade in a controlled environment. Before you ever apply changes to your production cluster, Chkk can simulate the upgrade in an isolated cluster that mirrors your production setup. In this preverification phase, Chkk deploys the target version of the Vertical Pod Autoscaler along with your current VPA configuration to see how they interact. This process can catch a range of potential issues early. Chkk will report any detected anomalies during this dry-run. This feature gives platform engineers a chance to test-drive the VPA upgrade safely, ensuring that by the time you perform the real upgrade, you've already resolved the major risks in a sandbox.
### Supported Packages
It has built-in support for VPA deployments via Helm charts, Kustomize overlays, plain YAML manifests, or package managers. Upon connecting to your cluster, Chkk auto-detects your current VPA version and manifest source. It highlights changes in Helm chart values, provides manifest patches or overlay updates, and verifies operator version requirements while preserving custom configurations, images, and private registry references. Even if you use a custom-built VPA image, Chkk can still track version parity with the upstream project.
## Common Operational Considerations
* **Coordinate VPA with HPA carefully** - Avoid running both on the same resource metric, as VPA adjusts CPU/memory requests while HPA scales replicas. If both target CPU, VPA changes may confuse HPA's calculations, causing oscillations; isolate metrics or use custom ones.
* **Expect and manage pod restarts** - VPA updates require pod restarts, making it a disruptive event. Use Pod Disruption Budgets (PDBs) and rollout strategies to prevent downtime, ensuring pods don't restart simultaneously or move unpredictably between nodes.
* **Ensure cluster capacity for scaling** - VPA may suggest resources beyond what the cluster can provide, causing pods to remain unschedulable. Use Cluster Autoscaler with VPA and enforce resource limits to prevent excessive recommendations that outpace hardware.
* **Update CRDs and handle API deprecations** - VPA CRDs and API versions evolve, so always upgrade them before updating VPA. Failure to migrate deprecated API versions can break VPA functionality; review release notes and apply the latest manifests to avoid issues.
* **Mind admission webhook interactions** - VPA acts as an admission controller, and conflicts can arise with other webhooks like OPA or PSPs. Verify that VPA's webhook is still applying resource updates correctly after upgrades or adding new admission controllers.
## Additional Resources
* [Vertical Pod Autoscaler Documentation](https://github.com/kubernetes/autoscaler/tree/master/vertical-pod-autoscaler)
* [Vertical Pod Autoscaler Releases](https://github.com/kubernetes/autoscaler/releases)
# Access Tokens
Source: https://docs.chkk.io/administration/access-tokens
Administration instructions for using and managing Access Tokens
Access Tokens are required for Chkk Kubernetes Connector auth.
## Managing Tokens
Below are the steps to access, create, revoke, and copy tokens in the Chkk Dashboard.
1. In the **Chkk Dashboard**, expand **Configure** on the left menu.
2. Click **Settings**, then select the **Tokens** tab.
3. Here you'll see a list of all your active tokens (if any), along with options to create new ones or revoke existing ones.
1. Click the **Add Token** button to open the token creation page.
2. **NameYour Token**: Provide a meaningful label for the token (e.g., `deployment-token`).
3. Click **Mark as Done** to generate a new token.
4. You can click on the code-block or the "clipboard" icon to copy the token.
5. Additionally, you can click the "eye" icon next to the "clipboard" to unhide the token
1. In the **Tokens** list, find the token you want to revoke.
2. Click the **x** icon next to that token.
3. A confirmation modal will appear requesting your confirmation; confirm you want to revoke it.
4. Once revoked, the token is no longer valid for future requests.
1. From the **Tokens** tab, locate the token whose value you wish to copy.
2. Click the **clipboard icon** next to the Token name to copy the token
string.
1. From the **Tokens** tab, locate the token whose name you wish to edit.
2. Click the **pencil icon** next to the Token name to edit the token name.
3. A modal will appear where you can edit the token name.
4. Click **Save** after re-naming the token to update the token name.
# Multi-Org Support
Source: https://docs.chkk.io/administration/multi-org-support
Administration instructions for managing users in multiple Organizations
**Multi-Org Support** lets you create and manage multiple, distinct Organizations—whether for dev, staging, and production environments or to separate different teams under their own tenants. You can administer each Organization individually, view and control resources in context, maintain unique settings, and switch between them as needed.
## Switch Between Orgs
Follow these steps to switch between organizations in the **Chkk Dashboard**.
1. In the top-right corner of the **Chkk Dashboard**, click your **organization name**.
2. A dropdown will appear with a list of available organizations.
3. Select the organization you want to switch to.
4. The page will refresh, and you'll now be operating under the newly selected organization.
# Organization Settings
Source: https://docs.chkk.io/administration/organization-settings
Administration instructions for managing Organization Settings
A **Chkk Organization** groups together one or more **Chkk Accounts** under a common ownership. Within each account, users organize clusters, Cloud Native Projects, application services, operators, risks, etc.
## Change Organization Settings
Follow the steps below to change your organization settings:
1. In the top-right corner of the Chkk Dashboard, click on your **organization name**.
2. Select **Organization Settings** from the dropdown.
1. On the **Organization Settings** page, you will see:
* **Organization Slug**: A unique identifier for your organization (read-only).
* **Display Name**: A user-friendly name for your organization.
* **Created Time**: The date when your organization was created (read-only).
2. These details help you quickly reference and organize your account information.
1. In the **Display Name** field, type the new name you want for your organization.
2. Click **Save Changes** to confirm and update the organization name.
# Plan and Usage
Source: https://docs.chkk.io/administration/plan-and-usage
Administration instructions for plan usage management
Chkk offers two main plans—**Business** (for startups and scaleups) and **Enterprise** (for mission-critical workloads). For pricing and a complete breakdown of features, refer to [Pricing and Plans](https://chkk.io/pricing).
The Chkk Dashboard shows subscription status and usage metrics, and will display a badge whenever you near plan thresholds.
## View Subscription usage and limits
Follow these steps to view the status and usage limits of your Subscription:
1. In the **Chkk Dashboard**, expand **Configure** on the left menu.
2. Select **Billing & Subscriptions** to open your billing details and plan information.
1. In this tab, you will see:
* **Plan Summary**: Displays your **current plan**, the **start date**, and **activation date**.
* **Usage**: Indicates your **Monthly Node Count** and **Upgrade Templates** usage.
2. There will also be a **Contact Us** button if you need to purchase more nodes or upgrade templates.
1. Here, you will see different **plan tiers** (e.g., Business, Enterprise), each with a feature breakdown.
2. This section compares available features (like **Clusters**, **Users**, **Nodes**, **Cloud Providers**, etc.) across different subscription levels.
3. Use this tab to gauge which tier meets your operational requirements and to explore upgrade possibilities.
1. In the **FAQs** tab, you'll find common questions regarding **Chkk**'s billing model:
* **Definition of a node**
* **Pricing for serverless Kubernetes clusters**
* **Handling unexpected node increases**
* **Purchase options and volume discounts**
2. This tab addresses specific billing scenarios and clarifies how usage calculations or price adjustments occur.
# User Management
Source: https://docs.chkk.io/administration/user-management
Administration instructions for managing users
Chkk supports user management through **Teams**, which are groups of users within a Chkk Account. Team members share a common set of permissions and can manage resources within that account. You can also invite additional team members to join, ensuring straightforward collaboration and secure access control.
## Steps to perform User Management
Below are the steps to manage your team members in Chkk—covering how to access Teams, invite users, manage pending invites, remove users, leave an organization, and utilize the search feature.
1. In the **Chkk Dashboard**, go to the left navigation panel.
2. Under **Configure**, click **Teams** to open the user management page.
1. The **Members** tab displays all existing team members, showing:
* **Name**
* **Email**
* **Date Added**
2. This page lets you see who currently has access to your Chkk organization.
1. Select **Invite Team Member** (top-right on the Teams page).
2. A **modal** will appear prompting you to enter the **email address** of the person you want to invite.
3. Click **Send Invite** in the modal to send an invitation email.
4. The sent invitation and its status can be found in the **Pending** tab next to **Members**.
1. Go to the **Pending** tab.
2. You'll see the status of all the **Pending** invites alongside additional details:
* **Email**: Email of the person invited to join the Organization
* **Inviter**: Email of the person who sent the invite
* **Status**: Status of the invite (Pending/Expired)
* **Expiry**: Date of Expiry of the invite
1. In the **Pending** tab, locate the expired or pending invite.
2. Click **Resend Invite**, which opens a **modal** to confirm the re-invite action.
3. Click **Send Invite** (or equivalent) in the modal to issue a new invitation link.
1. In the **Members** tab, find your own **Name**.
2. Click the **arrow icon** to the right of your **Name**.
3. A **confirmation modal** will appear.
4. Confirm to **Leave** the organization.
1. In the **Members** tab, locate the user you want to remove.
2. Click the **trash icon** to the right of the user's name.
3. A **confirmation modal** will appear.
4. Select **Remove** to remove the user.
# Claude Code + Chkk
Source: https://docs.chkk.io/ai/claude-code-plus-chkk
A walkthrough of using Claude Code with Chkk Upgrade Agent to produce environment-aware IaC pull requests
Agent Responses on this page are illustrative. Exact phrasing from your AI
model may vary depending on the model, settings, and repository context.
For the best experience, it is recommended to use the **claude-4-sonnet** model with the Chkk-Upgrade-Context-MCP Server.
This guide shows how to use **Claude Code** with the **Chkk-Upgrade-Context-MCP** to generate precise, environment-aware diffs and apply them to your Cloud Native Project IaC (e.g., Helm).
For a deep conceptual overview of how the Upgrade Agent works (powered by the Upgrade Context MCP server), see **[Upgrade Agent](/ai/upgrade-agent)** first.
## Prerequisites
1. [Install Docker](https://docs.docker.com/get-docker/): Required to run the Chkk-Upgrade-Context-MCP Server.
2. [Install Claude Code](/resources/installation-guides/claude-code): Required to begin generating environment-aware pull requests.
3. A [Claude.ai](https://claude.ai/) (recommended) or [Anthropic Console](https://console.anthropic.com/) account
## Initialization of Chkk Upgrade Agent
Run the following command to clone the sample Chkk IaC repo:
```bash theme={"dark"}
git clone git@github.com:chkk-io/upgrade-playground.git && \
cd upgrade-playground
```
1. In the **Chkk Dashboard**, expand **Configure** on the left menu and click **Settings**.
2. Select the **Tokens** tab. Here you'll see a list of all your active tokens (if any), along with options to create new ones or revoke existing ones.
3. Click on the **clipboard** icon next to a token to copy it.
Install the `Chkk-Upgrade-Context-MCP` using the Claude Code CLI:
```bash theme={"dark"}
claude mcp add Chkk-Upgrade-Context-MCP --env CHKK_ACCESS_TOKEN="" -- docker run -i --rm -e CHKK_ACCESS_TOKEN public.ecr.aws/chkk/chkk-mcp-upgrade-context:latest
```
Replace `` with your Chkk Access Token.
Verify via CLI that the server is registered:
```bash theme={"dark"}
claude mcp get Chkk-Upgrade-Context-MCP
```
The command should return server details indicating it is installed and enabled.
1. In the **left-hand column** of the **Chkk Dashboard**, expand **Upgrade Copilot**.
2. Under **Upgrade Plans** select **Add-on & App Services**.
3. On the **Middle Right** corner of the page, enable the **Show Example Data** toggle, as shown in the image below.
4. This will switch the view to only show example data and displays a confirmation banner.
5. In the table below, you will see a list of Add-on and Application Service **Example Upgrade Plans**.
6. Select any Upgrade Plan from the table that has the **AI Context Generated** badge, as shown in the image below.
The **AI Context Generated** badge indicates that these Upgrade Plans are supported by the **Chkk-Upgrade-Context-MCP Server**.
7. At the top of the page, under the name of the Upgrade Plan, you will see the **Upgrade ID**.
8. Click the **clipboard** icon to copy the Upgrade ID to your clipboard.
* Open Claude Code and start a new chat from your IaC repo root.
Open a chat in Claude Code and send:
You're in a K8s repo. Fetch "addon-upgrade-agent" from Chkk MCP and upgrade the package listed in the upgrade plan. Start by asking for the upgrade ID.
Your opening prompt is flexible, but it **must** explicitly instruct the assistant to **fetch "addon-upgrade-agent" from Chkk MCP**.
**Agent Response:**
Paste your **upgrade ID** (from your instantiated [Add-on or Application Service Upgrade Plan](/resources/glossary#cloud-native-project-and-application-service-upgrade-plan)), for example:
upgr\_ea53db65-3d8d-4744-b8b7-92e3c7552932
**Agent Response:**
## Upgrade Agent Workflow
Connect your environment to Chkk and generate an Upgrade Plan. From the Claude Code IDE, ask the
Chkk Upgrade MCP to fetch Upgrade Context from that plan for the Cloud Native Project you're about to
change—say cert-manager or External Secrets Operator. The assistant retrieves the recommended target
version and rationale, detects your IaC pattern, identifies which files need to be updated,
creates an environment-specific diff, and attaches the notes reviewers want (deprecations, critical fixes, notable features).
Your IDE applies the diff and opens the PR, with optional preflight and postflight checks to keep code and running state aligned.
The entire flow happens in your Claude Code editor chat, end-to-end. Below is exactly what you'll see, phase by phase,
using a live example that upgrades **cert-manager** from **v1.14.4 → v1.17.2** with a forked Helm chart.
**What you do:** You connect Chkk-Upgrade-Context-MCP server to Claude Code. In chat, you invoke the PR creation workflow (e.g., *"Use the Chkk upgrade agent to apply the IaC changes. Start by asking for the upgrade ID."*).
**What you see:** The assistant asks you for the **upgrade\_id**—a single natural key that ties your request to a Chkk **Upgrade Plan** (precomputed for your environment).
**Why it matters:** The **upgrade\_id** is how the assistant fetches the precise context—including resources, subagents and diffs—for *your* cluster constraints, not "generic upstream."
**What you do**: Provide the upgrade\_id.
**What you see**: The assistant resolves plan metadata immediately (package name and from/to versions) and prepares a safe workspace:
* Confirms the **package** (e.g., `cert-manager`) and version span (`1.14.4 → 1.17.2`).
* Creates a project-local scratchpad (e.g., `.chkk/scratchpad/`) which enables workflow tracing and checkpointing.
**Why it matters**: This isolates automation artifacts from your source tree while keeping a local, inspectable record of every change.
**What you do**: Nothing; the assistant drives.
**What you see**: A short progress line—"Now fetching the context". The Context contains:
* The **authoritative Upgrade Plan** for `cert-manager`.
* Exact **file artifacts** to add and **unified diff** files to apply.
**What you do**: Nothing; the assistant reads the plan.
**What you see**: Compact, human-readable instructions from the plan:
* **Upgrade Details**: `cert-manager v1.14.4 → v1.17.2`
* **Reasons**: e.g., "1.14.4 is EOL/Unsupported" and "1.14.4 incompatible with Kubernetes 1.32."
* **Inventory**: **Added: 2 files, Modified: 23 files, Deleted: 0** (your counts will vary by package).
**Why it matters**: This is the first concrete signal that the plan is **environment-aware**
(incompatible K8s version, distro nuances, etc.) and scoped to what you actually run.
**What you do:** Nothing, unless you have multiple candidates.
**What you see:** The assistant identifies your IaC repo pattern and locates the exact **Helm chart root**
for the package/version you're on (e.g., `.../helm/cert-manager/`) by scanning for **Chart.yaml** where
`name == cert-manager` and `version == 1.14.4` (exact, case-sensitive).
**Edge cases you might see:**
* **Multiple matches:** You'll get a list of absolute paths and a prompt to choose one—no guessing.
* **No match:** The assistant asks for an explicit absolute path (it won't "best-effort" a wrong chart).
**What you do:** Review pass/fail lines.
**What you see:** Two precise checks with ✅❌ outcomes:
* **Chart Name & Version Match** — confirms **Chart.yaml** matches the *current* package & version.
* **Upgrade Plan Metadata Match** — confirms the plan's **from/to** are consistent with resolved metadata.
**Why it matters:** Preflight checks safeguard against pointing the patcher at the wrong subtree
or the wrong plan. Any failure **stops the run** until fixed.
**What you do:** Skim.
**What you see:** The assistant surfaces the "**why**"—the exact notes reviewers care about:
* **Critical drivers** (e.g., EOL, K8s version compatibility).
* **Breaking changes** (e.g., structured logging, stricter Helm schema validation, API removals).
* **Security & bug fixes** (e.g., DoS mitigations, renewal logic).
* **Notable features** (e.g., Gateway API support, metrics exposure).
**Why it matters:** Your future PR will **inherit** these callouts so reviewers don't need to hunt docs to understand risk, scope and impact.
**What you do:** Watch the live counter; no prompts needed.
**What you see:** A strict, linear, and **complete** application of the plan:
* **Full inventory printout:**
*"Processing 25 total files: 2 added, 23 modified, 0 deleted"*
* **Adds:** Each source file from the context is copied to the correct relative target (e.g.,\
`templates/cainjector-service.yaml`, `templates/extras-objects.yaml`) with immediate ✅ **Added** confirmations.
* **Mods:** Every single `*.diff` is applied **one-by-one** with a visible sequence:\
*"Processing diff 1 of 23: Chart.yaml … ✅ Modified"*\
*"Processing diff 2 of 23: README.md … ✅ Modified"*\
…through to the last template/value file.
* **Deletions:** If any exist, they're backed up to `.bak`, then removed with ✅ **Deleted** confirmations.
**What you do:** Nothing.
**What you see:** If the context includes CRDs, the assistant copies them into the target CRD directory and prints the exact path used.
**Why it matters:** Reviewers see CRD changes alongside template and values edits.
**What you do:** Nothing.
**What you see:** If the plan includes Custom Resources, they're edited based on the changes in the CRD schema.
**Why it matters:** Custom Resources are validated against their CRDs; migrating specs to the new schema
(handling renamed/deprecated fields and default changes) prevents admission failures,
reconcile churn, and subtle behavior drift during rollout.
**What you do:** Review.
**What you see:** Two final gates:
* **Chart version updated** — `Chart.yaml version == to_version` (e.g., `v1.17.2`) → ✅❌
* **All planned changes applied** — match exactly and all items carry ✅ → ✅❌
**Any failure here stops the flow** and lists the exact mismatches.
**What you do:** Read once; this becomes your PR body.
**What you see:** A concise, celebratory completion message (never "upgraded," always "IaC updated"), plus reviewer-focused details:
* **Completion:** 🎉 `cert-manager` IaC Successfully Updated — `v1.14.4 → v1.17.2.`
* **Reasons** (EOL, K8s compatibility) and **most-critical notes** (breaking changes, security fixes).
* **Applied changes** (counts + important files).
* **CRD location** (exact path).
* **Next step:** *"Create a Pull Request to review and apply these IaC changes."*
## Review and commit
* Use your editor's Source Control panel to inspect the diff.
* Verify `Chart.yaml`, `values.yaml`, and any template updates.
Use your normal Git flow (Git UI or terminal) to commit on a branch and open a PR for review.\
Chkk's MCP server is read-only; your IDE/assistant holds the pen and performs edits locally.
# Cursor + Chkk
Source: https://docs.chkk.io/ai/cursor-plus-chkk
A walkthrough of using Cursor with Chkk Upgrade Agent to produce environment-aware IaC pull requests
export const cursorDeeplink = "cursor://anysphere.cursor-deeplink/mcp/install?name=Chkk%20Upgrade%20Context%20MCP&config=eyJjb21tYW5kIjoiZG9ja2VyIHJ1biAtaSAtLXJtIC1lIENIS0tfQUNDRVNTX1RPS0VOIHB1YmxpYy5lY3IuYXdzL2Noa2svY2hray1tY3AtdXBncmFkZS1jb250ZXh0OmxhdGVzdCIsImVudiI6eyJDSEtLX0FDQ0VTU19UT0tFTiI6IjxBREQgVE9LRU4%252BIn19";
Agent Responses on this page are illustrative. Exact phrasing from your AI
model may vary depending on the model, settings, and repository context.
For the best experience, it is recommended to use the **claude-4-sonnet** model with the Chkk-Upgrade-Context-MCP Server.
This guide shows how to use **Cursor** with the **Chkk-Upgrade-Context-MCP** to generate precise, environment-aware diffs and apply them to your Cloud Native Project IaC (e.g., Helm).
For a deep conceptual overview of how the Upgrade Agent works (powered by the Upgrade Context MCP server), see **[Upgrade Agent](/ai/upgrade-agent)** first.
## Prerequisites
1. [Install Docker](https://docs.docker.com/get-docker/): Required to run the Chkk-Upgrade-Context-MCP Server.
2. [Install Cursor](/resources/installation-guides/cursor): Required to begin generating environment-aware pull requests.
## Initialization of Chkk Upgrade Agent
Run the following command to clone the sample Chkk IaC repo and open it in Cursor:
```bash theme={"dark"}
git clone git@github.com:chkk-io/upgrade-playground.git && \
cd upgrade-playground && \
cursor .
```
1. In the **Chkk Dashboard**, expand **Configure** on the left menu and click **Settings**.
2. Select the **Tokens** tab. Here you'll see a list of all your active tokens (if any), along with options to create new ones or revoke existing ones.
3. Click on the **clipboard** icon next to a token to copy it.
Click the card below to install the Chkk Upgrade Context MCP Server in Cursor.
Click here to add Chkk to your Cursor
Paste your Chkk Access Token in the `CHKK_ACCESS_TOKEN` environment variable
in the **MCP Tool Settings** opened via the deeplink in the previous step.
Verify in **MCP Tool Settings** that Chkk Upgrade Context MCP Server is
successfully installed and enabled.
1. In the **left-hand column** of the **Chkk Dashboard**, expand **Upgrade Copilot**.
2. Under **Upgrade Plans** select **Add-on & App Services**.
3. On the **Middle Right** corner of the page, enable the **Show Example Data** toggle, as shown in the image below.
4. This will switch the view to only show example data and displays a confirmation banner.
5. In the table below, you will see a list of Add-on and Application Service **Example Upgrade Plans**.
6. Select any Upgrade Plan from the table that has the **AI Context Generated** badge, as shown in the image below.
The **AI Context Generated** badge indicates that these Upgrade Plans are supported by the **Chkk-Upgrade-Context-MCP Server**.
7. At the top of the page, under the name of the Upgrade Plan, you will see the **Upgrade ID**.
8. Click the **clipboard** icon to copy the Upgrade ID to your clipboard.
* In Cursor (top-left), click **View → Command Palette**.
* Make sure the chat is opened **from your IaC repo root**.
Paste and send the following Prompt in the Cursor chat:
You're in a K8s repo. Fetch "addon-upgrade-agent" from Chkk MCP and upgrade the package listed in the upgrade plan. Start by asking for the upgrade ID.
Your opening prompt is flexible, but it **must** explicitly instruct the agent to **fetch "addon-upgrade-agent" from Chkk MCP**.
**Agent Response:**
Paste your **upgrade ID** (from your instantiated [Add-on or Application Service Upgrade Plan](/resources/glossary#cloud-native-project-and-application-service-upgrade-plan)), for example:
upgr\_ea53db65-3d8d-4744-b8b7-92e3c7552932
**Agent Response:**
## Upgrade Agent Workflow
Connect your environment to Chkk and generate an Upgrade Plan. From the Cursor IDE, ask the
Chkk Upgrade MCP to fetch Upgrade Context from that plan for the Cloud Native Project you're about to
change—say cert-manager or External Secrets Operator. The agent retrieves the recommended target
version and rationale, detects your IaC pattern, identifies which files need to be updated,
creates an environment-specific diff, and attaches the notes reviewers want (deprecations, critical fixes, notable features).
Your IDE applies the diff and opens the PR, with optional preflight and postflight checks to keep code and running state aligned.
The entire flow happens in your Cursor editor chat, end-to-end. Below is exactly what you'll see, phase by phase,
using a live example that upgrades **cert-manager** from **v1.14.4 → v1.17.2** with a forked Helm chart.
**What you do:** You connect Chkk-Upgrade-Context-MCP server to Cursor. In Cursor Chat, you invoke the PR creation workflow (e.g., *"Use the Chkk upgrade agent to apply the IaC changes. Start by asking for the upgrade ID."*).
**What you see:** The agent asks you for the **upgrade\_id**—a single natural key that ties your request to a Chkk **Upgrade Plan** (precomputed for your environment).
**Why it matters:** The **upgrade\_id** is how the agent fetches the precise context—including resources, subagents and diffs—for *your* cluster constraints, not "generic upstream."
**What you do**: Provide the upgrade\_id.
**What you see**: The agent resolves plan metadata immediately (package name and from/to versions) and prepares a safe workspace:
* Confirms the **package** (e.g., `cert-manager`) and version span (`1.14.4 → 1.17.2`).
* Creates a project-local scratchpad (e.g., `.chkk/scratchpad/`) which enables workflow tracing and checkpointing.
**Why it matters**: This isolates automation artifacts from your source tree while keeping a local, inspectable record of every change.
**What you do**: Nothing; the agent drives.
**What you see**: A short progress line—"Now fetching the context". The Context contains:
* The **authoritative Upgrade Plan** for `cert-manager`.
* Exact **file artifacts** to add and **unified diff** files to apply.
**What you do**: Nothing; the agent reads the plan.
**What you see**: Compact, human-readable instructions from the plan:
* **Upgrade Details**: `cert-manager v1.14.4 → v1.17.2`
* **Reasons**: e.g., "1.14.4 is EOL/Unsupported" and "1.14.4 incompatible with Kubernetes 1.32."
* **Inventory**: **Added: 2 files, Modified: 23 files, Deleted: 0** (your counts will vary by package).
**Why it matters**: This is the first concrete signal that the plan is **environment-aware**
(incompatible K8s version, distro nuances, etc.) an**d scoped to what you actually run.**
**What you do:** Nothing, unless you have multiple candidates.
**What you see:** The agent identifies your IaC repo pattern and locates the exact **Helm chart root**
for the package/version you're on (e.g., `.../helm/cert-manager/`) by scanning for **Chart.yaml** where
`name == cert-manager` and `version == 1.14.4` (exact, case-sensitive).
**Edge cases you might see:**
* **Multiple matches:** You'll get a list of absolute paths and a prompt to choose one—no guessing.
* **No match:** The agent asks for an explicit absolute path (it won't "best-effort" a wrong chart).
**What you do:** Review pass/fail lines.
**What you see:** Two precise checks with ✅❌ outcomes:
* **Chart Name & Version Match** — confirms **Chart.yaml** matches the *current* package & version.
* **Upgrade Plan Metadata Match** — confirms the plan's **from/to** are consistent with resolved metadata.
**Why it matters:** Preflight checks safeguard against pointing the patcher at the wrong subtree
or the wrong plan. Any failure **stops the run** until fixed.
**What you do:** Skim.
**What you see:** The agent surfaces the "**why**"—the exact notes reviewers care about:
* **Critical drivers** (e.g., EOL, K8s version compatibility).
* **Breaking changes** (e.g., structured logging, stricter Helm schema validation, API removals).
* **Security & bug fixes** (e.g., DoS mitigations, renewal logic).
* **Notable features** (e.g., Gateway API support, metrics exposure).
**Why it matters:** Your future PR will **inherit** these callouts so reviewers don't need to hunt docs to understand risk, scope and impact.
**What you do:** Watch the live counter; no prompts needed.
**What you see:** A strict, linear, and **complete** application of the plan:
* **Full inventory printout:**
*"Processing 25 total files: 2 added, 23 modified, 0 deleted"*
* **Adds:** Each source file from the context is copied to the correct relative target (e.g.,\
`templates/cainjector-service.yaml`, `templates/extras-objects.yaml`) with immediate ✅ **Added** confirmations.
* **Mods:** Every single `*.diff` is applied **one-by-one** with a visible sequence:\
*"Processing diff 1 of 23: Chart.yaml … ✅ Modified"*\
*"Processing diff 2 of 23: README.md … ✅ Modified"*\
…through to the last template/value file.
* **Deletions:** If any exist, they're backed up to `.bak`, then removed with ✅ **Deleted** confirmations.
**What you do:** Nothing.
**What you see:** If the context includes CRDs, the agent copies them into the target CRD directory and prints the exact path used.
**Why it matters:** Reviewers see CRD changes alongside template and values edits.
**What you do:** Nothing.
**What you see:** If the plan includes Custom Resources, they're edited based on the changes in the CRD schema.
**Why it matters:** Custom Resources are validated against their CRDs; migrating specs to the new schema
(handling renamed/deprecated fields and default changes) prevents admission failures,
reconcile churn, and subtle behavior drift during rollout.
**What you do:** Review.
**What you see:** Two final gates:
* **Chart version updated** — `Chart.yaml version == to_version` (e.g., `v1.17.2`) → ✅❌
* **All planned changes applied** — match exactly and all items carry ✅ → ✅❌
**Any failure here stops the flow** and lists the exact mismatches.
**What you do:** Read once; this becomes your PR body.
**What you see:** A concise, celebratory completion message (never "upgraded," always "IaC updated"), plus reviewer-focused details:
* **Completion:** 🎉 `cert-manager` IaC Successfully Updated — `v1.14.4 → v1.17.2.`
* **Reasons** (EOL, K8s compatibility) and **most-critical notes** (breaking changes, security fixes).
* **Applied changes** (counts + important files).
* **CRD location** (exact path).
* **Next step:** *"Create a Pull Request to review and apply these IaC changes."*
## Review and commit
* Open the **Source Control** panel (left sidebar) to inspect the diff.
* Verify `Chart.yaml`, `values.yaml`, and any template updates.
Use your normal Git flow (Cursor's Git UI or terminal) to commit on a branch and open a PR for review.\
Chkk's MCP server is read-only; your IDE/agent holds the pen and performs edits locally.
# llms.txt
Source: https://docs.chkk.io/ai/llms-txt
Allow your LLMs to read and index Chkk context
export const PreviewButton = ({children, href}) => {
return
{children}
;
};
The [llms.txt file](https://llmstxt.org) is an industry standard that helps LLMs index content more efficiently, similar to how a sitemap helps search engines.
Chkk hosts an `llms.txt` file at the root documentation site. AI tools can use this file to understand the documentation structure and find relevant content to user prompts.
Open the llms.txt for Chkk docs site
## llms.txt structure
An `llms.txt` file is a plain Markdown file that contains:
* **Site title** as an H1 heading. This is the only required section of an `llms.txt`.
* **Structured content sections** with descriptive links to key pages.
This structured approach allows LLMs to quickly process Chkk documentation hierarchy and locate relevant content for user queries, improving the accuracy and speed of AI-assisted documentation searches.
## llms-full.txt
The `llms-full.txt` file combines entire Chkk documentation site into a single file as context for AI tools and is indexed by LLMs. Users can paste a single URL as context for AI tools for more relevant and accurate responses.
Chkk hosts an `llms-full.txt` file. View Chkk `llms-full.txt` by appending `/llms-full.txt` to Chkk documentation site's URL.
Open the llms-full.txt for this site
Chkk's `llms-full.txt` is always up to date and requires zero maintenance.
# Risk Feed MCP Server
Source: https://docs.chkk.io/ai/risk-feed-mcp
Connect MCP Clients (e.g., Cursor, Claude Desktop) to Chkk Risk Analysis
This is a **preview-only** version of the Risk Feed MCP Server. Features and supported platforms will be enhanced as we iterate.
***
## What is the Risk Feed MCP Server?
The **Risk Feed MCP Server** lets you use natural language in any [MCP client](https://github.com/cursor-so/mcp) (such as [Cursor](https://www.cursor.so/) or [Claude Desktop](https://claude.ai/download)) to:
* List and analyze Operational Risks in your infrastructure
* Fetch all affected resources identified by an Operational Risk so you can prioritize tasks, assign owners and plan effectively.
* Trigger mitigation and remediation workflows
The server authenticates using a machine principal (e.g. Cloud Identity), which must be registered with Chkk. You can add your Cloud Identities to a Chkk Team.
This guide uses Cursor as an example MCP client, but the Risk Feed MCP Server works with any compatible MCP client, including tools like Claude Desktop.
***
## Prerequisites
* Download a supported Risk Feed MCP Server binary for your platform (see instructions below)
* Access to your Chkk API URL (if unsure, please contact Chkk Support)
***
## Cloud Credentials Required
The Risk Feed MCP Server requires valid cloud account credentials to be configured on your machine. Currently, only AWS is supported. These credentials are used to authenticate with Chkk using presigned STS URLs. Before using the server:
* Verify that your Cloud Machine Identity is registered with Chkk (please contact Chkk Support is assisstance is required)
* Ensure you have valid AWS credentials of the registered Cloud Machine Identity configured locally
If you encounter authentication errors, see the [Troubleshooting](/resources/troubleshooting#16-how-do-i-troubleshoot-common-issues-with-the-chkk-mcp-server) section.
***
## Step 1: Download the Risk Feed MCP Server
Download the latest Risk Feed MCP Server binary for your platform:
Apple Silicon
M1/M2/M3 and newer
ARM 64-bit servers
Intel/AMD 64-bit PCs
After downloading:
1. Unzip the downloaded binary
2. (macOS/Linux) Make the binary executable:
```bash theme={"dark"}
chmod +x ./chkk-mcp-*
```
## Step 2: Configure your Cursor instance to use the Risk Feed MCP Server
Create (or modify) the `.cursor/mcp.json` file in your project folder using the binary relevant to your platform.
This guide assumes that the unzipped binary is located in the `./bin/` directory of your Cursor project. Update the path if the unzipped binary is located elsewhere.
```json macOS (Apple Silicon) theme={"dark"}
{
"mcpServers": {
"chkk-mcp-stdio": {
"command": "./bin/chkk-mcp-darwin-arm64",
"args": ["serve"]
}
}
}
```
```json Linux (arm64) theme={"dark"}
{
"mcpServers": {
"chkk-mcp-stdio": {
"command": "./bin/chkk-mcp-linux-arm64",
"args": ["serve"]
}
}
}
```
```json Windows (amd64) theme={"dark"}
{
"mcpServers": {
"chkk-mcp-stdio": {
"command": "./bin/chkk-mcp-windows-amd64.exe",
"args": ["serve"]
}
}
}
```
***
## Step 3: Start the Server
Cursor will launch the server automatically and prompt you to enable the MCP tool.
Or, if you use your own custom MCP client, you can run it manually as well:
```bash theme={"dark"}
./bin/chkk-mcp serve --mode stdio
```
***
## Step 4: Run the Prompt
Open Cursor and try a natural-language request:
> list risks for cluster k8scl\_1234abcd-5678-efgh-9012-3456789abcde
>
> list risks for cluster k8scl\_1234abcd-5678-efgh-9012-3456789abcde in category "guardrail"
Cursor will reply with a concise summary of each risk—plus the affected resources—right inside your editor.
Supported categories are `guardrail`, `api-deprecation`, and `misconfiguration`.
***
# Upgrade Agent
Source: https://docs.chkk.io/ai/upgrade-agent
Part of Chkk's Lifecycle Management Agents. Generates precise, environment-aware IaC diffs and PRs in your IDE. Powered by the Upgrade Context MCP server.
**Public Preview.** Initial support focuses on **Helm-based IaC** across **300+ Cloud Native Projects**. Initial IDE integrations: **Cursor** and **Claude Code**.
## What is the Upgrade Agent?
Upgrading a Cloud Native Project or application service is rarely a simple version bump. Between releases, Helm charts evolve, `values.yaml` options change, CRDs rotate, and templates shift. Manually diffing upstream and stitching edits into your IaC is slow and error-prone.
The **Upgrade Agent** is one of Chkk’s **Lifecycle Management Agents**. It runs inside your IDE (Cursor, Claude Code) to apply upgrade workflows to your IaC.
It is powered by the **Chkk Upgrade Context Server (MCP)** which connects your **Chkk Upgrade Plan** (grounded in your environment and policies) to your IDE via the Model Context Protocol. The server vends **just‑enough, just‑in‑time context**: compatible target versions, environment‑specific diffs, and reviewer notes (breaking changes, security fixes, notable features). The Upgrade Agent consumes that context and applies the required edits to your IaC (Helm today), preserving your customizations and opening a focused PR you can review and merge.
**Why it matters**
* **Choose versions that hold in prod.** Targets are computed against your constraints and policies—not simply "latest."
* **Edits are environment-aware and deterministic.** Diffs are scoped to **what you actually run**, ordered for safe apply, and auditable.
* **Reviewer context is built-in.** Breaking changes, compatibility notes, and critical fixes appear next to the change.
## How it fits with Templates & Plans
Chkk lets you **request an Add-on or Application Service Upgrade Template**—a curated, pre-verified upgrade workflow that captures exact steps, constraints, and diffs for your environment. Create/approve a template in the Chkk Dashboard (see [Requesting an Upgrade Template](/features/request-upgrade-template#cloud-native-project-upgrade-template)), then instantiate a [Add-on or Application Service Upgrade Plan](/resources/glossary#cloud-native-project-and-application-service-upgrade-plan).
The **Upgrade Context MCP server** turns that **Upgrade Plan** into actionable context (specifications, diffs, and reviewer notes) for the **Upgrade Agent** running in your IDE.
## Supported today (Public Preview)
* **IaC format:** Helm charts (templates, values, chart metadata, CRDs). Terraform, Kustomize, raw YAML, Jsonnet and others are on the roadmap.
* **IDE / Coding assistant:** Cursor and Claude Code (MCP). GitHub Copilot and other MCP-capable IDEs coming soon.
* **Ecosystem coverage (examples):** Networking (Istio, Cilium), Databases (PostgreSQL, Redis), Batch/Data Jobs (Argo Workflows, Jenkins), Streams (Kafka, RabbitMQ), Observability (Datadog, Grafana), Security (cert-manager, Kyverno), Autoscaling (Karpenter, KEDA), Dev Tooling (Argo CD, Bitbucket), and more.
## FAQs
**What is an Add-on or Application Service Upgrade Plan?**
An AI-curated workflow for a specific [Cloud Native Project](#cloud-native-project), [Application Service](#application-service), or [Operator](#operator) across one or more clusters, instantiated from an [Upgrade Template](/resources/glossary#cloud-native-project-and-application-service-upgrade-template). See [Glossary](/resources/glossary#cloud-native-project-and-application-service-upgrade-plan).
**What is the `upgrade_id` and why does the agent need it?**
`upgrade_id` is the natural key for your Upgrade Plan. The agent uses it to fetch the exact, environment-specific context (target version, diffs, artifacts, reviewer notes) for your cluster(s)—not generic upstream guidance.
**Which IDEs and coding assistants are supported?**
Cursor and Claude Code are available in Public Preview. Support for GitHub Copilot and other MCP-capable IDEs is coming soon.
**Which IaC patterns/formats are supported?**
Helm charts are supported today (templates, values, chart metadata, CRDs). We're expanding to Terraform, Kustomize overlays, raw YAML, Jsonnet, and others.
**Where does temporary data go, and can I delete it?**
Into the **Scratchpad** (by default under `.chkk/scratchpad/` in the repo). It's ignored by Git and safe to delete at any time.
**Does the agent change my running cluster?**
No. It edits your IaC locally and opens a PR. Any apply/rollout steps are up to your CI/CD and change-management process.
**Do I have to use a specific "first prompt"?**
No—use natural language. In your IDE (Cursor or Claude Code), instruct your assistant to **use the Chkk upgrade agent** and **ask you for the `upgrade_id`** to begin.
## Common Variations & Edge Cases
* **Multiple charts** matching the same name/version → you choose explicitly (no guessing).
* **Missing or read-only files** → the agent fails fast with a complete list; nothing partial is committed.
* **Network issues** → the agent stops early; no edits attempted.
* **Unsupported IaC patterns** → Helm is supported today; other formats are on the way.
## Getting started
1. **Create an Upgrade Plan.** Instantiate a [Add-on or Application Service Upgrade Plan](/resources/glossary#cloud-native-project-and-application-service-upgrade-plan) from an approved Template ([how-to](/features/instantiate-template-to-plan)). If needed, request a new Template ([instructions](/features/request-upgrade-template#cloud-native-project-upgrade-template)).
2. **Enable the MCP server in your IDE.** In Cursor or Claude Code, add the **Chkk-Upgrade-Context-MCP** server (see [Cursor guide](/resources/installation-guides/cursor) or [Claude Code guide](/resources/installation-guides/claude-code)).
3. **Run the workflow with the Upgrade Agent.** In your editor chat: "Use the Chkk Upgrade Agent to apply the IaC changes. Start by asking for the upgrade ID." Provide the `upgrade_id` when prompted, review the preflight, and let the agent apply the plan and generate the PR summary.
# Upgrade Planning
Source: https://docs.chkk.io/ai/upgrade-planning
Find and plan upgrades for Cloud Native Projects and application services in your clusters—directly from your IDE.
**Public Preview.** Helps you identify what needs to be upgraded and prepare a reviewable upgrade plan for your **IaC** across **300+ Cloud Native Projects**. Works with **Cursor** and **Claude Code**.
To apply changes to your IaC and open a PR, use the companion **[Upgrade Agent](/ai/upgrade-agent)**.
## What is Upgrade Planning?
**Upgrade Planning** combines multiple agents and tools to give engineers a structured and reliable way to prepare for upgrades. The process produces three artifacts:
* **Upgrade Assessments**: High-level reports that map the scope, impact, and dependencies of upgrades. Assessments identify control plane, nodes, and Cloud Native Projects that require attention, flag deprecated APIs or breaking changes, and surface potential blockers across platform and application layers.
* **Upgrade Plans**: Environment-specific workflows that provide step-by-step instructions for safely upgrading Cloud Native Projects and application services. Plans include justifications from authoritative sources, explicit breaking-change notes, application-client impacts, and previews of IaC diffs.
* **Upgrade Context**: Minimal, environment-aware details that power execution by the Upgrade Agent. Context includes compatible target versions, environment-specific diffs, reviewer notes, security fixes, notable features, and application-client changes.
Together, these artifacts make upgrades predictable, reviewable, and tied back to authoritative sources.
## When to use Upgrade Planning
* You want a cluster-scoped inventory of Cloud Native Projects/application services that should be upgraded, with reasons.
* You need justification tied to compatibility, support windows, security advisories, and stability fixes.
* You want a reviewable plan and change preview for your IaC across 300+ Cloud Native Projects.
* You prefer to plan in your IDE (Cursor or Claude Code) before any repo changes.
* You intend to hand the outputs (Plans and Context) to the **Upgrade Agent** (or other automation) to open a PR.
## What it does
* Analyzes the selected cluster to identify Projects and application services that require an upgrade.
* Evaluates each candidate against compatibility requirements, support timelines, security advisories, and notable bug fixes; explains the "why."
* Produces structured, reviewable artifacts: **Assessments, Plans, and Context**.
* Optionally hands off to the **Upgrade Agent** to update charts/values while preserving customizations and open a focused PR.
## Getting started
1. **Enable Chkk in your IDE.** Follow the setup guides for [Cursor](/resources/installation-guides/cursor) or [Claude Code](/resources/installation-guides/claude-code).
2. **Open your IaC repo** and ask your assistant, for example:
* "Check what needs upgrading in the cluster 'prod-vas-01'."
3. **Select a Cloud Native Project or application service** from the results and ask:
* "Upgrade cert-manager."
### Examples
#### Ask: What needs to be updated and why?
```
You're in a k8s IaC repo. Run the upgrade-planning from Chkk MCP against cluster "prod-vas-01". What needs to be updated and why?
```
| Name | Namespace(s) | Current | Suggested | Priority | Why |
| ------------ | ------------ | ------- | --------- | ---------- | ----------------------------------------------------------------------------- |
| cert-manager | cert-manager | 1.14.4 | 1.18.2 | Required | Incompatible with upcoming Kubernetes version; current version is end of life |
| CoreDNS | kube-system | 1.11.3 | 1.12.3 | Optional | Current version is outside maintainers' support window |
| Kube Proxy | kube-system | 1.32.8 | - | Not needed | Compatible and supported |
#### Ask: Which version of a project should I upgrade to and why?
```
For "cert-manager" in cluster "prod-vas-01", which version should I upgrade to and why? Include compatibility and notable changes that might affect our IaC.
```
##### Why `cert-manager` must be upgraded
* Incompatible with Kubernetes 1.33 (supported: 1.17–1.18)
* v1.14 is End‑of‑Life (since Oct 2024)
##### Impact Preview: cert-manager 1.14.4 → 1.18.2
* Private key rotation now defaults to "always rotate" on renewal
* Revision history limit defaults to 1 (automatic cleanup)
* Ingress `PathType` change: `ImplementationSpecific` → `Exact`
* Structured logging (may break string-based log parsers)
* Venafi TPP: API Key removed; OAuth required
#### Ask: Which one should I upgrade first and why?
```
Prioritize the recommended upgrades for cluster "prod-vas-01". Which should be upgraded first and why?
```
* cert-manager — Required now (Kubernetes 1.33 incompatibility; current version EOL)
* CoreDNS — Optional; outside maintainers' support window
* Kube Proxy — No action; compatible and supported
#### Ask: Generate an Upgrade Plan for me
```
Generate a Chkk Upgrade Plan to upgrade "cert-manager" in cluster "prod-vas-01".
```
An upgrade plan to update **cert-manager** from **v1.14.4** to **v1.18.2** in cluster **prod-vas-01** is now available.
The plan ID is: `upgr_1d04e00a-4976-421b-b0c9-91ccb1215d48`.
You can view the plan in **Chkk UI** under: *Upgrade Copilot → Upgrade Plans → Add-ons & Application Services*.
**What you'll review:**
* Chkk Upgrade Plan for the selected Cloud Native Project or application service
* Important notes: breaking changes, compatibility, and notable fixes
#### Ask: Generate the Upgrade Context for the Upgrade Agent so it can open precise environment‑aware IaC pull requests
```
Generate the Upgrade Context for the Upgrade Agent based on the current Chkk Upgrade Plan for "cert-manager" in cluster "prod-vas-01". Ensure it is environment‑aware so the agent can open precise IaC pull requests.
```
A new upgrade context snapshot for **cert-manager** from **v1.14.4** to **v1.18.2** has been generated.
It has been saved at: `.chkk/scratchpad/downloads/`.
#### What to do next
* Hand off to the **Upgrade Agent** to update Helm charts/values, preserve customizations, and open a focused PR
## FAQs
**Does the Planning Agent change my repo?**
No. It does not modify or commit code. It generates a reviewable Chkk Upgrade Plan and a change preview in your IDE session. Only the **Upgrade Agent**, when you ask it to, updates your IaC and opens a PR.
**Can I select a different Cloud Native Project or application service?**
Yes. The agent lists Cloud Native Projects and application services with upgrade recommendations; you can pick any (or filter by priority/security) and ask it to create a plan.
**How is this different from the Upgrade Agent?**
The Planning Agent discovers, analyzes, and prepares a reviewable plan plus impact/change preview. The **Upgrade Agent** applies the plan to your IaC, preserves customizations, and opens a PR.
**Which IDEs are supported?**
Cursor and Claude Code.
# Introduction
Source: https://docs.chkk.io/api-reference/introduction
Welcome to the Chkk API — a REST interface that lets you query the Chkk resources surfaced by the Chkk Operational Safety Platform.
The v2 API is available to Enterprise customers only. Contact us to request access.
## Pagination
Bulk‑fetch methods in Chkk use cursor‑based pagination. Two parameters control the flow:
| Parameter | Type | Default | Max | Description |
| ------------------- | ------- | ------- | ---- | --------------------------------------------------- |
| page\_size | integer | 100 | 1000 | Maximum number of objects to return |
| continuation\_token | string | — | — | Cursor pointing to where the next page should start |
Typical sequence
1. **First page** – Omit continuation\_token (and optionally set page\_size).
2. **Next page** – Pass the continuation\_token returned in the prior response.
3. **Done** – When the response no longer includes continuation\_token, you have reached the end.
Example
```
GET /risks?page_size=100&filter=cluster_id:k8scl_a1b2c3
→ 200 OK
{
"data": [ /* up to 100 RiskSummary objects */ ],
"continuation_token": "eyJ2IjoxLCJ..."
}
GET /risks?page_size=100&continuation_token=eyJ2IjoxLCJ...
→ 200 OK
{
"data": [ /* next set of RiskSummary objects */ ]
}
```
If page\_size exceeds 1000, Chkk returns HTTP 400 with an error object.
***
## Errors
Chkk uses standard HTTP response codes to indicate the outcome of an API request. Codes in the 2xx range indicate a successful request. Codes in the 4xx range indicate a client error, such as a missing required parameter. Codes in the 5xx range indicate a server error on Chkk’s end (these are uncommon).
| Code | Meaning |
| ----------------------- | ---------------------------------------------------------------------------- |
| `200 OK` | Request succeeded. |
| `400 Bad Request` | Malformed filters, missing parameters. |
| `401 Unauthorized` | Missing/invalid bearer token. |
| `404 Not Found` | Resource does not exist or is out of scope. |
| `429 Too Many Requests` | Rate-limit exceeded. Retrying after the `Retry-After` header is recommended. |
| `5xx` | Temporary service error on Chkk’s side. |
## API Usage Examples
The Go program below:
1. Calls **`GET /risks`** to collect every detected Risk instance in a cluster.
2. For each Risk, calls **`GET /risks/{id}/resources`** to enumerate affected resources.
3. **Optionally** shows **only** the resources that live in the namespace you pass with `-namespace`.
4. Prints output to `stdout` and writes a CSV file called `risks.csv` to the current working directory with the output.
### Prerequisites
| Requirement | Notes |
| --------------- | ------------------------------------------------------------------- |
| Go 1.20 + | No third-party dependencies. |
| Outbound HTTPS | Script contacts `https://api.us.chkk.io/v1` |
| AWS credentials | Script uses AWS STS to generate a presigned URL for authentication. |
### Example script
```go theme={"dark"}
package main
import (
"context"
"encoding/csv"
"encoding/json"
"flag"
"fmt"
"net/http"
"os"
"time"
"github.com/aws/aws-sdk-go-v2/config"
"github.com/aws/aws-sdk-go-v2/service/sts"
"github.com/pkg/errors"
)
type loginResponse struct {
AccessTokens map[string]map[string]struct {
AccessToken string `json:"access_token"`
} `json:"access_tokens"`
}
type riskSummary struct {
ID string `json:"id"`
Signature struct {
ID string `json:"id"`
} `json:"signature"`
}
type listRisksResponse struct {
Data []riskSummary `json:"data"`
}
type riskResource struct {
Kind string `json:"kind"`
Name string `json:"name"`
Namespace string `json:"namespace"`
}
type listRiskResourcesResponse struct {
Data []riskResource `json:"data"`
}
var (
clusterID = flag.String("cluster-id", "", "Chkk cluster ID (required)")
namespace = flag.String("namespace", "", "Namespace filter (optional)")
outFile = flag.String("out", "risks.csv", "CSV output filename")
apiBase = "https://api.us.chkk.io/v1"
httpClient = &http.Client{Timeout: 15 * time.Second}
)
func main() {
flag.Parse()
if *clusterID == "" {
exitErr(errors.New("flag -cluster-id is required"))
}
ctx := context.Background()
token, err := authenticate(ctx)
if err != nil {
exitErr(err)
}
risks, err := listRisks(ctx, token, *clusterID)
if err != nil {
exitErr(err)
}
if err := printSummary(ctx, token, risks); err != nil {
exitErr(err)
}
if err := writeCSV(ctx, token, risks); err != nil {
exitErr(err)
}
}
func printSummary(ctx context.Context, token string, risks []riskSummary) error {
for _, rs := range risks {
res, err := listRiskResources(ctx, token, rs.ID)
if err != nil {
return err
}
count := filterByNamespace(res, *namespace)
if *namespace != "" {
fmt.Printf("%s, %s: %d affected resources in namespace %s\n", *clusterID, rs.Signature.ID, count, *namespace)
} else {
fmt.Printf("%s, %s: %d affected resources\n", *clusterID, rs.Signature.ID, count)
}
}
return nil
}
func writeCSV(ctx context.Context, token string, risks []riskSummary) error {
file, err := os.Create(*outFile)
if err != nil {
return errors.Wrap(err, "create CSV file")
}
defer file.Close()
cw := csv.NewWriter(file)
defer cw.Flush()
if err := cw.Write([]string{"Cluster", "SignatureID", "Kind", "Name", "Namespace"}); err != nil {
return errors.Wrap(err, "write CSV header")
}
for _, rs := range risks {
resources, err := listRiskResources(ctx, token, rs.ID)
if err != nil {
return err
}
for _, r := range resources {
if *namespace != "" && r.Namespace != *namespace {
continue
}
if err := cw.Write([]string{
*clusterID,
rs.Signature.ID,
r.Kind,
r.Name,
r.Namespace,
}); err != nil {
return errors.Wrap(err, "write CSV row")
}
}
}
return nil
}
func filterByNamespace(resources []riskResource, ns string) int {
if ns == "" {
return len(resources)
}
count := 0
for _, r := range resources {
if r.Namespace == ns {
count++
}
}
return count
}
func authenticate(ctx context.Context) (string, error) {
url, err := presignSTS(ctx)
if err != nil {
return "", errors.Wrap(err, "generate presigned STS URL")
}
req, err := http.NewRequestWithContext(ctx, http.MethodPost, apiBase+"/login", nil)
if err != nil {
return "", errors.Wrap(err, "construct login request")
}
req.Header.Set("Authorization", "AWS "+url)
resp, err := httpClient.Do(req)
if err != nil {
return "", errors.Wrap(err, "perform login request")
}
defer resp.Body.Close()
if resp.StatusCode != 200 {
data, err := io.ReadAll(resp.Body)
if err != nil {
return "", errors.Wrap(err, "failed to read response body")
}
return "", errors.Errorf("Received Login Error. Code: %d Body: %s", resp.StatusCode, string(data))
}
var lr loginResponse
if err := json.NewDecoder(resp.Body).Decode(&lr); err != nil {
return "", errors.Wrap(err, "decode login response")
}
for _, acct := range lr.AccessTokens {
for _, bundle := range acct {
return bundle.AccessToken, nil
}
}
return "", errors.New("no access tokens returned")
}
func listRisks(ctx context.Context, token, cluster string) ([]riskSummary, error) {
url := fmt.Sprintf("%s/risks?filter=cluster_id:%s", apiBase, cluster)
req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
if err != nil {
return nil, errors.Wrap(err, "construct list risks request")
}
req.Header.Set("Authorization", "Bearer "+token)
resp, err := httpClient.Do(req)
if err != nil {
return nil, errors.Wrap(err, "perform list risks request")
}
defer resp.Body.Close()
var lr listRisksResponse
if err := json.NewDecoder(resp.Body).Decode(&lr); err != nil {
return nil, errors.Wrap(err, "decode list risks response")
}
return lr.Data, nil
}
func listRiskResources(ctx context.Context, token, riskID string) ([]riskResource, error) {
url := fmt.Sprintf("%s/risks/%s/resources", apiBase, riskID)
req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
if err != nil {
return nil, errors.Wrap(err, "construct list risk resources request")
}
req.Header.Set("Authorization", "Bearer "+token)
resp, err := httpClient.Do(req)
if err != nil {
return nil, errors.Wrap(err, "perform list risk resources request")
}
defer resp.Body.Close()
var r listRiskResourcesResponse
if err := json.NewDecoder(resp.Body).Decode(&r); err != nil {
return nil, errors.Wrap(err, "decode list risk resources response")
}
return r.Data, nil
}
func presignSTS(ctx context.Context) (string, error) {
cfg, err := config.LoadDefaultConfig(ctx)
if err != nil {
return "", errors.Wrap(err, "load AWS config")
}
cfg.Region = "us-east-1"
stsClient := sts.NewFromConfig(cfg)
sign := sts.NewPresignClient(stsClient)
identity, err := sign.PresignGetCallerIdentity(ctx, &sts.GetCallerIdentityInput{})
if err != nil {
return "", errors.Wrap(err, "failed to create presigned URL")
}
return identity.URL, nil
}
func exitErr(err error) {
fmt.Fprintf(os.Stderr, "ERROR: %+v\n", err)
os.Exit(1)
}
```
# Get Access Token
Source: https://docs.chkk.io/api-reference/v1/login/get-access-token
post /login
Authenticate and obtain access credentials for authorized operations.
# Get a specific Risk
Source: https://docs.chkk.io/api-reference/v1/risk/get-a-specific-risk
get /risks/{riskId}
Returns the full details of a single Risk.
# List resources for a specific Risk
Source: https://docs.chkk.io/api-reference/v1/risk/list-resources-for-a-specific-risk
get /risks/{riskId}/resources
Returns a paginated list of resources that are associated with the specified Operational Risk.
# List Risks
Source: https://docs.chkk.io/api-reference/v1/risk/list-risks
get /risks
List Risks matching one or more filter parameters.
# Create Account
Source: https://docs.chkk.io/api-reference/v2/account/create-account
post /accounts
Create a new Account
An Account is a container for resource ownership. Organizations can
have multiple Accounts, each representing a department or division of the
Organization that has ownership over some segment of the Organization's
resources.
Accounts are uniquely identified by a UUID, prefixed with the string
ac_, for example ac_c42014e7-baf5-4ec6-a502-858f98dca7c8
# Delete Account
Source: https://docs.chkk.io/api-reference/v2/account/delete-account
delete /accounts/{account}/
Delete a Account
An Account is a container for resource ownership. Organizations can
have multiple Accounts, each representing a department or division of the
Organization that has ownership over some segment of the Organization's
resources.
Accounts are uniquely identified by a UUID, prefixed with the string
ac_, for example ac_c42014e7-baf5-4ec6-a502-858f98dca7c8
# Get Account
Source: https://docs.chkk.io/api-reference/v2/account/get-account
get /accounts/{account}/
Gets a single Account
An Account is a container for resource ownership. Organizations can
have multiple Accounts, each representing a department or division of the
Organization that has ownership over some segment of the Organization's
resources.
Accounts are uniquely identified by a UUID, prefixed with the string
ac_, for example ac_c42014e7-baf5-4ec6-a502-858f98dca7c8
# List Accounts
Source: https://docs.chkk.io/api-reference/v2/account/list-accounts
get /accounts
List multiple Accounts
An Account is a container for resource ownership. Organizations can
have multiple Accounts, each representing a department or division of the
Organization that has ownership over some segment of the Organization's
resources.
Accounts are uniquely identified by a UUID, prefixed with the string
ac_, for example ac_c42014e7-baf5-4ec6-a502-858f98dca7c8
# Update Account
Source: https://docs.chkk.io/api-reference/v2/account/update-account
put /accounts/{account}/
Update an existing Account
An Account is a container for resource ownership. Organizations can
have multiple Accounts, each representing a department or division of the
Organization that has ownership over some segment of the Organization's
resources.
Accounts are uniquely identified by a UUID, prefixed with the string
ac_, for example ac_c42014e7-baf5-4ec6-a502-858f98dca7c8
# Create Container
Source: https://docs.chkk.io/api-reference/v2/kubecluster/create-container
post /kubeclusters/{cluster}/resources/{resource}/containers
Create a new KubeClusterResourceContainer
A KubeClusterResource can have many KubeClusterResourceContainers.
When a KubeClusterResource refers to a Resource that is comprised of
one or more ContainerSpecs, we create a KubeClusterResourceContainer
corresponding to that ContainerSpec. This allows us to have fine-grained
knowledge of the specific Images referenced in all Resources in the
KubeCluster.
A KubeClusterResourceContainer may be associated with a known Project.
When the KubeClusterResourceContainer's Project field is empty, that means that
the classification process was unable to determine a matching Project for the
discovered Resource Container.
A KubeClusterResourceContainer may be associated with a known
ProjectContainer. When the KubeClusterResourceContainer's ProjectContainer
field is empty, that means that the classification process was unable to
determine a matching ProjectContainer for the discovered Resource
Container.
# Create KubeCluster
Source: https://docs.chkk.io/api-reference/v2/kubecluster/create-kubecluster
post /kubeclusters
Create a new KubeCluster
A KubeCluster describes a single cluster provisioned by a
KubePlatform.
A KubeCluster is uniquely identified by slugified name that is unique within
the set of KubeCluster name for an Account, e.g. cluster1 or
k8scl_552fb09a-5a6a-4530-86d3-bcc0a770024d.
KubeClusters always have an Environment tag that is defined by the
customer and allows the customer to categorize their KubeClusters.
The Version field of a KubeCluster indicates the current
control plane version.
# Delete Container
Source: https://docs.chkk.io/api-reference/v2/kubecluster/delete-container
delete /kubeclusters/{cluster}/resources/{resource}/containers/{container}/
Delete a KubeClusterResourceContainer
A KubeClusterResource can have many KubeClusterResourceContainers.
When a KubeClusterResource refers to a Resource that is comprised of
one or more ContainerSpecs, we create a KubeClusterResourceContainer
corresponding to that ContainerSpec. This allows us to have fine-grained
knowledge of the specific Images referenced in all Resources in the
KubeCluster.
A KubeClusterResourceContainer may be associated with a known Project.
When the KubeClusterResourceContainer's Project field is empty, that means that
the classification process was unable to determine a matching Project for the
discovered Resource Container.
A KubeClusterResourceContainer may be associated with a known
ProjectContainer. When the KubeClusterResourceContainer's ProjectContainer
field is empty, that means that the classification process was unable to
determine a matching ProjectContainer for the discovered Resource
Container.
# Delete KubeCluster
Source: https://docs.chkk.io/api-reference/v2/kubecluster/delete-kubecluster
delete /kubeclusters/{cluster}/
Delete a KubeCluster
A KubeCluster describes a single cluster provisioned by a
KubePlatform.
A KubeCluster is uniquely identified by slugified name that is unique within
the set of KubeCluster name for an Account, e.g. cluster1 or
k8scl_552fb09a-5a6a-4530-86d3-bcc0a770024d.
KubeClusters always have an Environment tag that is defined by the
customer and allows the customer to categorize their KubeClusters.
The Version field of a KubeCluster indicates the current
control plane version.
# Get Container
Source: https://docs.chkk.io/api-reference/v2/kubecluster/get-container
get /kubeclusters/{cluster}/resources/{resource}/containers/{container}/
Gets a single KubeClusterResourceContainer
A KubeClusterResource can have many KubeClusterResourceContainers.
When a KubeClusterResource refers to a Resource that is comprised of
one or more ContainerSpecs, we create a KubeClusterResourceContainer
corresponding to that ContainerSpec. This allows us to have fine-grained
knowledge of the specific Images referenced in all Resources in the
KubeCluster.
A KubeClusterResourceContainer may be associated with a known Project.
When the KubeClusterResourceContainer's Project field is empty, that means that
the classification process was unable to determine a matching Project for the
discovered Resource Container.
A KubeClusterResourceContainer may be associated with a known
ProjectContainer. When the KubeClusterResourceContainer's ProjectContainer
field is empty, that means that the classification process was unable to
determine a matching ProjectContainer for the discovered Resource
Container.
# Get KubeCluster
Source: https://docs.chkk.io/api-reference/v2/kubecluster/get-kubecluster
get /kubeclusters/{cluster}/
Gets a single KubeCluster
A KubeCluster describes a single cluster provisioned by a
KubePlatform.
A KubeCluster is uniquely identified by slugified name that is unique within
the set of KubeCluster name for an Account, e.g. cluster1 or
k8scl_552fb09a-5a6a-4530-86d3-bcc0a770024d.
KubeClusters always have an Environment tag that is defined by the
customer and allows the customer to categorize their KubeClusters.
The Version field of a KubeCluster indicates the current
control plane version.
# Get Namespace
Source: https://docs.chkk.io/api-reference/v2/kubecluster/get-namespace
get /kubeclusters/{cluster}/scans/{scan}/namespaces/{namespace}/
Gets a single KubeClusterScanNamespace
A KubeClusterScan can have many KubeClusterScanNamespaces. Each unique
namespace discovered for a KubeClusterScan is represented by a
unique KubeClusterScanNamespace record.
# Get Resource
Source: https://docs.chkk.io/api-reference/v2/kubecluster/get-resource
get /kubeclusters/{cluster}/resources/{resource}/
Gets a single KubeClusterResource
A KubeCluster can have many KubeClusterResources. Each time a
KubeCluster's inventory is scanned, one or more KubeClusterResources are
created for the KubeCluster and scan date.
KubeClusterResource represents a single Resource (Deployment,
Daemonset, StatefulSet, etc) installed in a specific namespace in
the KubeCluster.
A KubeClusterResource may be assigned a known KubeDeploymentSystem.
When the KubeClusterResource's DeploymentSystem field is empty, that means that
the classification process was unable to determine a matching
KubeDeploymentSystem for the discovered Resource.
A KubeClusterResource may be assigned a known PackageSystem. When the
KubeClusterResource's PackageSystem field is empty, that means that the
classification process was unable to determine a matching PackageSystem for the
discovered Resource.
A KubeClusterResource may be associated with a known Package. When the
KubeClusterResource's Package field is empty, that means that the
classification process was unable to determine a matching Package for the
discovered Resource.
A KubeClusterResource may be associated with a known PackageComponent.
When the KubeClusterResource's PackageComponent field is empty, that means that
the classification process was unable to determine a matching PackageComponent
for the discovered Resource.
# List Containers
Source: https://docs.chkk.io/api-reference/v2/kubecluster/list-containers
get /kubeclusters/{cluster}/resources/{resource}/containers
List multiple KubeClusterResourceContainers
A KubeClusterResource can have many KubeClusterResourceContainers.
When a KubeClusterResource refers to a Resource that is comprised of
one or more ContainerSpecs, we create a KubeClusterResourceContainer
corresponding to that ContainerSpec. This allows us to have fine-grained
knowledge of the specific Images referenced in all Resources in the
KubeCluster.
A KubeClusterResourceContainer may be associated with a known Project.
When the KubeClusterResourceContainer's Project field is empty, that means that
the classification process was unable to determine a matching Project for the
discovered Resource Container.
A KubeClusterResourceContainer may be associated with a known
ProjectContainer. When the KubeClusterResourceContainer's ProjectContainer
field is empty, that means that the classification process was unable to
determine a matching ProjectContainer for the discovered Resource
Container.
# List KubeClusters
Source: https://docs.chkk.io/api-reference/v2/kubecluster/list-kubeclusters
get /kubeclusters
List multiple KubeClusters
A KubeCluster describes a single cluster provisioned by a
KubePlatform.
A KubeCluster is uniquely identified by slugified name that is unique within
the set of KubeCluster name for an Account, e.g. cluster1 or
k8scl_552fb09a-5a6a-4530-86d3-bcc0a770024d.
KubeClusters always have an Environment tag that is defined by the
customer and allows the customer to categorize their KubeClusters.
The Version field of a KubeCluster indicates the current
control plane version.
# List Namespaces
Source: https://docs.chkk.io/api-reference/v2/kubecluster/list-namespaces
get /kubeclusters/{cluster}/scans/{scan}/namespaces
List multiple KubeClusterScanNamespaces
A KubeClusterScan can have many KubeClusterScanNamespaces. Each unique
namespace discovered for a KubeClusterScan is represented by a
unique KubeClusterScanNamespace record.
# List Resources
Source: https://docs.chkk.io/api-reference/v2/kubecluster/list-resources
get /kubeclusters/{cluster}/resources
List multiple KubeClusterResources
A KubeCluster can have many KubeClusterResources. Each time a
KubeCluster's inventory is scanned, one or more KubeClusterResources are
created for the KubeCluster and scan date.
KubeClusterResource represents a single Resource (Deployment,
Daemonset, StatefulSet, etc) installed in a specific namespace in
the KubeCluster.
A KubeClusterResource may be assigned a known KubeDeploymentSystem.
When the KubeClusterResource's DeploymentSystem field is empty, that means that
the classification process was unable to determine a matching
KubeDeploymentSystem for the discovered Resource.
A KubeClusterResource may be assigned a known PackageSystem. When the
KubeClusterResource's PackageSystem field is empty, that means that the
classification process was unable to determine a matching PackageSystem for the
discovered Resource.
A KubeClusterResource may be associated with a known Package. When the
KubeClusterResource's Package field is empty, that means that the
classification process was unable to determine a matching Package for the
discovered Resource.
A KubeClusterResource may be associated with a known PackageComponent.
When the KubeClusterResource's PackageComponent field is empty, that means that
the classification process was unable to determine a matching PackageComponent
for the discovered Resource.
# List Scans
Source: https://docs.chkk.io/api-reference/v2/kubecluster/list-scans
get /kubeclusters/{cluster}/scans
List multiple KubeClusterScans
A KubeClusterScan represents a single scan of a cluster.
# Update Container
Source: https://docs.chkk.io/api-reference/v2/kubecluster/update-container
put /kubeclusters/{cluster}/resources/{resource}/containers/{container}/
Update an existing KubeClusterResourceContainer
A KubeClusterResource can have many KubeClusterResourceContainers.
When a KubeClusterResource refers to a Resource that is comprised of
one or more ContainerSpecs, we create a KubeClusterResourceContainer
corresponding to that ContainerSpec. This allows us to have fine-grained
knowledge of the specific Images referenced in all Resources in the
KubeCluster.
A KubeClusterResourceContainer may be associated with a known Project.
When the KubeClusterResourceContainer's Project field is empty, that means that
the classification process was unable to determine a matching Project for the
discovered Resource Container.
A KubeClusterResourceContainer may be associated with a known
ProjectContainer. When the KubeClusterResourceContainer's ProjectContainer
field is empty, that means that the classification process was unable to
determine a matching ProjectContainer for the discovered Resource
Container.
# Update KubeCluster
Source: https://docs.chkk.io/api-reference/v2/kubecluster/update-kubecluster
put /kubeclusters/{cluster}/
Update an existing KubeCluster
A KubeCluster describes a single cluster provisioned by a
KubePlatform.
A KubeCluster is uniquely identified by slugified name that is unique within
the set of KubeCluster name for an Account, e.g. cluster1 or
k8scl_552fb09a-5a6a-4530-86d3-bcc0a770024d.
KubeClusters always have an Environment tag that is defined by the
customer and allows the customer to categorize their KubeClusters.
The Version field of a KubeCluster indicates the current
control plane version.
# Create KubePlatform
Source: https://docs.chkk.io/api-reference/v2/kubeplatform/create-kubeplatform
post /kubeplatforms
Create a new KubePlatform
A KubePlatform describes things like the cloud infrastructure provider and the
control plane provider.
An Organization can have one or more KubePlatforms.
# Delete KubePlatform
Source: https://docs.chkk.io/api-reference/v2/kubeplatform/delete-kubeplatform
delete /kubeplatforms/{platform}/
Delete a KubePlatform
A KubePlatform describes things like the cloud infrastructure provider and the
control plane provider.
An Organization can have one or more KubePlatforms.
# Get KubePlatform
Source: https://docs.chkk.io/api-reference/v2/kubeplatform/get-kubeplatform
get /kubeplatforms/{platform}/
Gets a single KubePlatform
A KubePlatform describes things like the cloud infrastructure provider and the
control plane provider.
An Organization can have one or more KubePlatforms.
# List KubePlatforms
Source: https://docs.chkk.io/api-reference/v2/kubeplatform/list-kubeplatforms
get /kubeplatforms
List multiple KubePlatforms
A KubePlatform describes things like the cloud infrastructure provider and the
control plane provider.
An Organization can have one or more KubePlatforms.
# Update KubePlatform
Source: https://docs.chkk.io/api-reference/v2/kubeplatform/update-kubeplatform
put /kubeplatforms/{platform}/
Update an existing KubePlatform
A KubePlatform describes things like the cloud infrastructure provider and the
control plane provider.
An Organization can have one or more KubePlatforms.
# Create Artifact
Source: https://docs.chkk.io/api-reference/v2/oci/create-artifact
post /ociartifacts
Create a new OCIArtifact
An OCIArtifact is a single OCI Artifact (manifest) that describes an OCI
Image or other OCI Artifact.
OCIArtifacts have a MediaType that informs you what the OCIArtifact
contains. For OCIArtifacts with a MediaType of
application/vnd.oci.image.manifest.v1+json or
application/vnd.docker.container.image.v1+json, the Architecture
field will show the compute architecture that the OCI Image was built for (e.g.
"amd64")
OCIArtifacts can be associated with zero or more ProjectReleases and
PackageReleases.
# Create Reference
Source: https://docs.chkk.io/api-reference/v2/oci/create-reference
post /ocireferences
Create a new OCIReference
An OCIReference represents a relationship between an OCITag and an
OCIArtifact.
When attempting to match a customer's container image to a known
OCIArtifact, we look up an OCITag that matches a particular digest. For
mutable OCITags, that digest association, however, changes over time. Until
OCIReference was introduced, we were only storing the first known
digest for these mutable tags, which ended up introducing a lot of stale
data into the digest classification process: the classifiers were not able
to find OCITags that match newer digests for these mutable tags and
therefore less accurate classifiers like ruleset and deduction classifier
needed to try and classify the cluster inventory record.
For OCITags that are mutable -- e.g. "latest" or "stable" or "v1" -- there
can be many digests that an OCITag has previously pointed to.
Previously-referred digests for an OCITag are made available through the
OCIReference object model. You may be wondering why we don't have an
References field on OCITag that just returns the digests that have been
previously associated with this OCITag. The reason for that is because the
list of previously-known digest associations can be very long (it's
unbounded) and so having this information in a separately-fetched object
model that can be paginated/controlled seemed like a better design.
# Delete Artifact
Source: https://docs.chkk.io/api-reference/v2/oci/delete-artifact
delete /ociartifacts/{artifact}/
Delete a OCIArtifact
An OCIArtifact is a single OCI Artifact (manifest) that describes an OCI
Image or other OCI Artifact.
OCIArtifacts have a MediaType that informs you what the OCIArtifact
contains. For OCIArtifacts with a MediaType of
application/vnd.oci.image.manifest.v1+json or
application/vnd.docker.container.image.v1+json, the Architecture
field will show the compute architecture that the OCI Image was built for (e.g.
"amd64")
OCIArtifacts can be associated with zero or more ProjectReleases and
PackageReleases.
# Get Artifact
Source: https://docs.chkk.io/api-reference/v2/oci/get-artifact
get /ociartifacts/{artifact}/
Gets a single OCIArtifact
An OCIArtifact is a single OCI Artifact (manifest) that describes an OCI
Image or other OCI Artifact.
OCIArtifacts have a MediaType that informs you what the OCIArtifact
contains. For OCIArtifacts with a MediaType of
application/vnd.oci.image.manifest.v1+json or
application/vnd.docker.container.image.v1+json, the Architecture
field will show the compute architecture that the OCI Image was built for (e.g.
"amd64")
OCIArtifacts can be associated with zero or more ProjectReleases and
PackageReleases.
# Get Reference
Source: https://docs.chkk.io/api-reference/v2/oci/get-reference
get /ocireferences/{reference}/
Gets a single OCIReference
An OCIReference represents a relationship between an OCITag and an
OCIArtifact.
When attempting to match a customer's container image to a known
OCIArtifact, we look up an OCITag that matches a particular digest. For
mutable OCITags, that digest association, however, changes over time. Until
OCIReference was introduced, we were only storing the first known
digest for these mutable tags, which ended up introducing a lot of stale
data into the digest classification process: the classifiers were not able
to find OCITags that match newer digests for these mutable tags and
therefore less accurate classifiers like ruleset and deduction classifier
needed to try and classify the cluster inventory record.
For OCITags that are mutable -- e.g. "latest" or "stable" or "v1" -- there
can be many digests that an OCITag has previously pointed to.
Previously-referred digests for an OCITag are made available through the
OCIReference object model. You may be wondering why we don't have an
References field on OCITag that just returns the digests that have been
previously associated with this OCITag. The reason for that is because the
list of previously-known digest associations can be very long (it's
unbounded) and so having this information in a separately-fetched object
model that can be paginated/controlled seemed like a better design.
# List Artifacts
Source: https://docs.chkk.io/api-reference/v2/oci/list-artifacts
get /ociartifacts
List multiple OCIArtifacts
An OCIArtifact is a single OCI Artifact (manifest) that describes an OCI
Image or other OCI Artifact.
OCIArtifacts have a MediaType that informs you what the OCIArtifact
contains. For OCIArtifacts with a MediaType of
application/vnd.oci.image.manifest.v1+json or
application/vnd.docker.container.image.v1+json, the Architecture
field will show the compute architecture that the OCI Image was built for (e.g.
"amd64")
OCIArtifacts can be associated with zero or more ProjectReleases and
PackageReleases.
# List Tags
Source: https://docs.chkk.io/api-reference/v2/oci/list-tags
get /ocireferences
List multiple OCITags
An OCIReference represents a relationship between an OCITag and an
OCIArtifact.
When attempting to match a customer's container image to a known
OCIArtifact, we look up an OCITag that matches a particular digest. For
mutable OCITags, that digest association, however, changes over time. Until
OCIReference was introduced, we were only storing the first known
digest for these mutable tags, which ended up introducing a lot of stale
data into the digest classification process: the classifiers were not able
to find OCITags that match newer digests for these mutable tags and
therefore less accurate classifiers like ruleset and deduction classifier
needed to try and classify the cluster inventory record.
For OCITags that are mutable -- e.g. "latest" or "stable" or "v1" -- there
can be many digests that an OCITag has previously pointed to.
Previously-referred digests for an OCITag are made available through the
OCIReference object model. You may be wondering why we don't have an
References field on OCITag that just returns the digests that have been
previously associated with this OCITag. The reason for that is because the
list of previously-known digest associations can be very long (it's
unbounded) and so having this information in a separately-fetched object
model that can be paginated/controlled seemed like a better design.
# Update Artifact
Source: https://docs.chkk.io/api-reference/v2/oci/update-artifact
put /ociartifacts/{artifact}/
Update an existing OCIArtifact
An OCIArtifact is a single OCI Artifact (manifest) that describes an OCI
Image or other OCI Artifact.
OCIArtifacts have a MediaType that informs you what the OCIArtifact
contains. For OCIArtifacts with a MediaType of
application/vnd.oci.image.manifest.v1+json or
application/vnd.docker.container.image.v1+json, the Architecture
field will show the compute architecture that the OCI Image was built for (e.g.
"amd64")
OCIArtifacts can be associated with zero or more ProjectReleases and
PackageReleases.
# Chkk + EKS Auto Mode
Source: https://docs.chkk.io/chkk-eks-automode
Do EKS Auto Mode clusters need Chkk Upgrade Copilot?
## What is Amazon EKS Auto Mode?
Amazon EKS Auto Mode streamlines Kubernetes cluster management by automating infrastructure provisioning, compute instance selection, resource scaling, and core Cloud Native Project management. It reduces operational overhead, allowing users to focus on application development rather than cluster management. Key features include automated compute, auto scaling, upgrades, load balancing, storage, and networking.
## What is Chkk Upgrade Copilot?
Chkk Upgrade Copilot is your trusted expert that provides a comprehensive set of recommendations, stateful workflows, and safety tooling to help you upgrade cloud substrate, control plane, nodes, Cloud Native Projects, application services, and applications in your infrastructure. Chkk Upgrade Copilot gives the peace of mind that your upgrades are verified to succeed, while saving months of effort spent on preparing, staging, and executing upgrades.
## Do EKS Auto Mode clusters need Chkk Upgrade Copilot?
While EKS Auto Mode automates many aspects of Kubernetes cluster management, it does not eliminate the need for tools like Chkk Upgrade Copilot in all cases. Here's a breakdown of which Auto Mode clusters benefit most from Chkk Upgrade Copilot:
### EKS Auto Mode clusters that NEED Chkk Upgrade Copilot:
* **Clusters with Cloud Native Projects that aren't EKS Managed:** EKS Auto Mode does not manage all Cloud Native Projects and application services. You are responsible for installing, managing, and upgrading Cloud Native Projects like Istio, Cert-Manager, Nginx, ArgoCD, External Secrets Operator, External DNS, CrossPlane, KEDA, Prometheus, Alertmanager, Fluentd, Grafana, Loki, Keycloak, Contour, Cilium, Calico, Argo Rollouts, and Vault Secrets Operator. Chkk Upgrade Copilot helps verify compatibility and uncover hidden dependencies before upgrades.
* **Clusters Requiring Custom AMIs:** Auto Mode only supports EKS AMIs. If you need custom AMIs, you won't be able to use Auto Mode.
* **Clusters with Specific CNI Requirements:** EKS Auto Mode restricts the underlying CNI to AWS' VPC CNI plug-in. If your organization requires a different CNI (e.g., Calico, Cilium) for enhanced observability or advanced networking policies, Auto Mode may not be suitable.
* **Clusters with API Deprecations and Application Dependencies:** You are still responsible for migrating applications off deprecated APIs and fixing misconfigured Pod Disruption Budgets (PDBs) before an Auto Mode upgrade. Chkk helps ensure application teams update workloads and PDBs before upgrades.
* **Clusters that must maintain Compliance and Improve Security Posture:** Chkk maintains an accurate inventory of all clusters and Cloud Native Projects, alerting you to existing and upcoming End-of-Life (EOL) software so you perform timely upgrades, avoid vulnerabilities, ensure vendor support, and save significant costs.
* **When you want to Delegate and Parallelize Work:** Chkk's detailed Upgrade Plans standardize workflows, making it easy to delegate tasks to any team member confidently, simplify reuse and share knowledge, reduce the chances of human errors and omissions, enabling your experts to focus on what they do best.
* **Organizations that want Standardization of Workflows, Knowledge Sharing, and Reuse of Best Practices:** Chkk ensures that institutional knowledge is retained and accessible, which is crucial during reorganizations or team changes, simplifies audits, enhances safety, and reduces time-to-find knowledge, minimizing context switching, and improving productivity.
### EKS Auto Mode clusters that may NOT need Chkk Upgrade Copilot:
* **Simple Container Workloads:** If you are running simple containerized workloads without Datapath or Stateful Cloud Native Projects or application services, you might not need Chkk Upgrade Copilot.
* **Clusters Running CI Jobs:** Clusters running CI jobs that do not require special care and attention to Cloud Native Project or application service dependencies may not need Chkk.
## Summary
* Use Chkk Upgrade Copilot with Auto Mode when clusters have non-EKS Cloud Native Projects and application services. EKS Auto Mode does not manage the maintenance and upgrades of these Projects and application services, so Chkk is crucial in these scenarios.
* Consider Chkk when custom AMIs or specific CNI requirements are present. Auto Mode might not accommodate these needs.
* Chkk is valuable because organizations are responsible for addressing API deprecations and application dependencies. Chkk can assist in ensuring timely updates of workloads and Pod Disruption Budgets (PDBs).
* If compliance and security are paramount, Chkk assists by providing an inventory of clusters and Cloud Native Projects, and alerting to end-of-life software.
* Chkk is helpful when you want to standardize workflows to enable task delegation, knowledge sharing, error reduction, and improved productivity.
# Chkk + EKS Upgrade Insights
Source: https://docs.chkk.io/chkk-eks-upgrade-insights
How Chkk Upgrade Copilot uses Amazon EKS Upgrade Insights
## What is Chkk Upgrade Copilot?
Chkk Upgrade Copilot is your trusted expert that provides a comprehensive set of recommendations, stateful workflows, and safety tooling to help you upgrade cloud substrate, control plane, nodes, Cloud Native Projects, application services, and applications in your infrastructure. Chkk Upgrade Copilot gives the peace of mind that your upgrades are verified to succeed, while saving months of effort spent on preparing, staging, and executing upgrades.
## What is the Chkk Upgrade Agent?
The **Upgrade Agent** is part of Chkk’s **Lifecycle Management Agents**. It runs in your IDE and applies environment‑aware upgrade workflows to your IaC. The agent is powered by the **Upgrade Context MCP server**, which connects your **Upgrade Plans** to your IDE by providing precise, just‑in‑time context for safe software upgrades.
You can integrate the Upgrade Agent (via the Upgrade Context MCP server) into existing IDEs like Cursor and Claude Code (GitHub Copilot and others coming soon).
## What is Amazon EKS Upgrade Insights?
Upstream releases come 2-3 times every year. APIs continue to get deprecated and removed in each release. Any application using a removed API risks disruption if it's not upgraded to supported APIs before cluster upgrade. EKS Upgrade Insights highlights deprecated and removed APIs being used by applications.
According to [AWS](https://docs.aws.amazon.com/eks/latest/userguide/cluster-insights.html): "Upgrade insights scans cluster's audit logs for events related to APIs that have been deprecated. These events include information about who initiated it (i.e., the caller) and the Cloud Native resource(s) that it was initiated against. Upgrade Insights presents this information to you in a concise and easily consumable way so you can identify and remediate the appropriate resources before executing the upgrade."
The information can also be retrieved programmatically using the Amazon EKS API or the AWS Command Line Interface (AWS CLI). Insight statuses:
* **Error**: Impacted in the next version (N+1).
* **Warning**: Impacted in a future version (N+2 or more).
* **Passing**: No issues detected.
* **Unknown**: Unable to determine impact.
## How does Chkk Upgrade Copilot use Amazon EKS Upgrade Insights?
For EKS customers, Chkk uses EKS Upgrade Insights to detect APIs that have been deprecated and can cause application failures. Chkk also uses EKS Insights about version skew between control plane and kubelet versions in it's Upgrade Plans.
While API deprecations/removals and version skew are critical to identify and address before an upgrade, there are many other dependencies, incompatibilities, and safety/availability risks across layers of infrastructure (cloud substrate, control plane, nodes, Cloud Native Projects, application services, and applications) that must be addressed to derisk upgrades.
For reference, a typical cluster Upgrade Plan from Chkk comprises 80+ steps. API deprecations/removals and version skew are only relevant for a handful of these steps.
## Comparison Table
**Multi-layer Dependency Analysis**
| Cascading Incompatibilities, Misconfigurations, Coupled Changes | Chkk Upgrade Copilot | Amazon EKS Upgrade Insights |
| :-------------------------------------------------------------- | :------------------- | :-------------------------- |
| Application to Project Compatibility | ✅ | ❌ |
| Application to Application Service Compatibility | ✅ | ❌ |
| Application to Operator Compatibility | ✅ | ❌ |
| Application to Nodes Compatibility | ✅ | ❌ |
| Project to Control Plane Compatibility | ✅ | Limited |
| Application Service to Control Plane Compatibility | ✅ | Limited |
| Operator to Control Plane Compatibility | ✅ | Limited |
| Application to Control Plane (PDB, misconfigurations) | ✅ | ❌ |
| Application to Control Plane (API Deprecations) | ✅ | ✅ |
| Node to Control Plane | ✅ | ❌ |
| Project to Cloud Substrate Compatibility | ✅ | ❌ |
| Application Service to Cloud Substrate Compatibility | ✅ | ❌ |
| Operator to Cloud Substrate Compatibility | ✅ | ❌ |
| Project to Project Compatibility | ✅ | ❌ |
| Project to Application Service Compatibility | ✅ | ❌ |
| Project to Operator Compatibility | ✅ | ❌ |
| Application Service to Application Service Compatibility | ✅ | ❌ |
| Application Service to Operator Compatibility | ✅ | ❌ |
**Contextualized Release Notes**
| Breaking changes, EOL detection, Default value changes | Chkk Upgrade Copilot | Amazon EKS Upgrade Insights |
| :--------------------------------------------------------------------- | :------------------- | :-------------------------- |
| Clusters | ✅ | ❌ |
| Nodes | ✅ | ❌ |
| Projects | ✅ | ❌ |
| Application Services | ✅ | ❌ |
| Operators | ✅ | ❌ |
| Cloud Substrate (IAM, LB, etc.) | ✅ | ❌ |
**Upgrade Version Recommendations**
| Next Version Recommendations & Upgrade Considerations | Chkk Upgrade Copilot | Amazon EKS Upgrade Insights |
| :--------------------------------------------------------------- | :------------------- | :-------------------------- |
| Projects | ✅ | ❌ |
| Application Services | ✅ | ❌ |
| Operators | ✅ | ❌ |
| Nodes (Rolling vs Blue/Green) | ✅ | ❌ |
| Clusters (In-place vs Blue/Green) | ✅ | ❌ |
**Safety, Health, and Readiness Checks**
| Preflight, Inflight, Postflight Checks | Chkk Upgrade Copilot | Amazon EKS Upgrade Insights |
| :--------------------------------------------------------------------------------------- | :------------------- | :-------------------------- |
| Project Preflight/Postflight Checks | ✅ | ❌ |
| Application Services Preflight/Postflight Checks | ✅ | ❌ |
| Operators Preflight/Postflight Checks | ✅ | ❌ |
| Control Plane Preflight/Postflight Checks | ✅ | ✅ |
| Node Preflight/Postflight Checks | ✅ | ✅ |
| Support for Custom Checks | ✅ | ❌ |
**Multi-cloud Support**
| Clouds | Chkk Upgrade Copilot | Amazon EKS Upgrade Insights |
| :-------------------------------------------------------------------------------------------------- | :------------------- | :-------------------------- |
| EKS | ✅ | ✅ |
| GKE | ✅ | ❌ |
| AKS | ✅ | ❌ |
**Additional Capabilities**
| Other Features | Chkk | Amazon EKS Upgrade Insights |
| :--------------------------------------------------------------------------------------------- | :--- | :-------------------------- |
| Preverification on a Digital Twin | ✅ | ❌ |
| Stateful Workflow | ✅ | ❌ |
| Activity Stream | ✅ | ❌ |
| Upgrade Context MCP Server | ✅ | ❌ |
| Upgrade Agent | ✅ | ❌ |
## Summary
* **EKS Upgrade Insights** focuses on detecting API deprecations/removals and ControlPlane-to-Node version skew.
* **Chkk Upgrade Copilot** provides a complete upgrade solution by identifying hidden dependencies, unknown incompatibilities, misconfigurations, and breaking changes across all infrastructure layers.
* Chkk includes preflight/postflight checks, contextual release notes, preverification on a digital twin, and stateful workflows to ensure upgrade success.
* Chkk supports multi-cloud environments (EKS, GKE, AKS), while EKS Upgrade Insights is specific to AWS.
# Cloud Connector
Source: https://docs.chkk.io/connectors/cloud
An overview of the Chkk Cloud Connector
## Overview
### What is a Chkk Cloud Connector?
**Chkk Cloud Connector** is a secure, read-only integration that fetches relevant resource data from your cloud environment and correlates it with your Kubernetes clusters. By focusing on resources that affect — or are affected by — your clusters (e.g., security groups, IAM roles, networking settings), the Connector facilitates a unified view of your infrastructure. This insight helps detect potential incompatibilities and misconfigurations early, resulting in a more stable and secure environment.
### Supported Cloud Service Providers
Chkk supports connecting to the following major CSPs:
* **AWS** (Amazon Web Services)
* **GCP** (Google Cloud Platform)
* **Azure** (Microsoft Azure)
## Permissions
Chkk Cloud Connector operates under the principle of least privilege, utilizing read-only credentials to access only the necessary metadata in your cloud environment. This restricted, non-intrusive access allows Chkk to accurately map your configurations and deliver tailored guidance for upgrades and operational best practices. By granting the minimal permissions required, you maintain a strong security posture while benefiting from insights that reflect the actual state of your environment.
All IAM policies and service accounts associated with the Chkk Cloud Connector remain under your direct control. You can modify, revoke, or remove these permissions at any time to align with your organization's security and compliance requirements.
## Setup Guide
This guide walks you through installing a Chkk Cloud Connector for **AWS**, **GCP**, or **Azure**.
1. In the **left-hand column** of the **Chkk Dashboard**, expand **Configure** and click **Cloud Accounts**.
2. In the top-right corner, click **Add Cloud Account**.
3. From the dropdown, select **AWS**, **GCP**, or **Azure**.
Once you've selected your provider, follow the relevant instructions in the tabs below to set up and verify the Cloud Connector.
1. **AWS Account ID**: Provide the 12-digit AWS Account ID (e.g., `123456789012`).
2. **AWS Region**: Specify your primary region (e.g., `us-east-1`).
3. *(Optional)* **Account Name**: Provide a name to reference this AWS Account in the Chkk Dashboard. (e.g., `production-account`)
4. Click **Mark as done**.
1. In **Setup Environment**, choose how you want to create the **read-only IAM Role** (CloudFormation, Console, CLI, or Terraform).
2. Follow the steps mentioned under the selected method to set up the IAM Role in your AWS account.
3. Once set up, click **Mark as done**.
1. Wait until the IAM Role is fully created in AWS.
2. Chkk attempts to assume the newly created role to confirm connectivity.
3. Once the connection is verified, you'll see a success message on the Chkk Dashboard.
4. The **Redo** button allows you to retry the connection if needed.
1. A success message indicates Chkk can now access your AWS account.
2. Your AWS account will appear in the **Cloud Accounts** list with **Connected** status in the **Configure -> Cloud Accounts** view.
1. **GCP Project ID**: Provide the ID for the GCP project you want to connect (e.g., `gcp-proj-example`).
2. *(Optional)* **Account Name**: Provide a name to reference this project in the Chkk Dashboard (e.g., `staging-project`).
3. Click **Mark as done**.
1. Under **Setup Environment**, choose your preferred method (e.g., **Manual (CLI)** or **Terraform**) to grant the Chkk service account **read-only** (`roles/viewer`) access to your project.
2. Follow the steps mentioned under the selected method.
3. After configuring your IAM policy, click **Mark as done**.
1. Once you finish creating the policy bindings in GCP, Chkk will attempt to connect using the newly granted service account permissions.
2. A success message indicates that Chkk can now retrieve data from your GCP project.
3. If needed, click **Redo** to retry or refresh the connection.
1. A final message confirms that your GCP project is **Connected**.
2. In the **Cloud Accounts** list (under **Configure** -> **Cloud Accounts**), your GCP project appears with a **Connected** status.
1. **Account Name**: Provide a name to reference this Azure account in the Chkk Dashboard (e.g., `production-account`).
2. Click **Mark as done** when finished.
1. **Azure Subscription ID(s)**: Enter one or more Subscription IDs (e.g., `b6cbec...97995d`).
2. Click **Add** to include multiple subscription IDs if needed.
3. Click **Mark as done**.
1. Open a terminal and log in to your Azure account using the CLI.
```bash theme={"dark"}
az login
```
2. Once logged in, click **Mark as done**.
1. Run the following command to create a Service Principal that has the **Reader** role, scoped to your subscription:
```bash theme={"dark"}
az ad sp create-for-rbac \
--display-name "chkk-cloud-connect-example" \
--role Reader \
--scopes /subscriptions/
```
2. **Note the output** of this command—it includes your **tenant**, **appId** (client ID), and **password** (client secret).
3. Click **Mark as done**.
1. Copy and paste the **Tenant ID**, **Client ID**, and **Client Secret** from the output of the previous command into the respective fields.
2. Click **Mark as done**.
1. After providing your Service Principal details, Chkk attempts to authenticate with Azure.
2. A success message indicates that your Azure account is now connected.
3. Use the **Redo** button if you need to retry or refresh the connection.
1. Navigate back to **Configure** -> **Cloud Accounts**.
2. Your Azure account appears in the list with a **Connected** status.
# Kubernetes Connector
Source: https://docs.chkk.io/connectors/kubernetes
An overview of Chkk Kubernetes Connector — what it is, why you need it, and how to install and configure it.
## Overview
### Key Components
The Chkk Kubernetes Connector is composed of two main components:
1. Chkk Operator
2. Chkk Agent
Working together, these components periodically (or on-demand) extract cluster metadata and ingest it into the Chkk SaaS platform. Once ingestion is complete, Chkk scans and analyzes your environment for potential risks or helpful insights (e.g., Cloud Native Project, application service, and operator instances running in your cluster).
***
### Chkk Operator
The Chkk Operator is a Kubernetes Operator that manages and configures the Chkk Kubernetes Connector. It deploys Chkk Agent through a single Custom Resource Definition (CRD) and simplifies configurations by:
* Providing a single source of truth (the CRD) for your Connector.
* Reporting deployment status, health, and errors in the CRD's status.
* Limiting the risk of potential misconfigurations by enforcing higher-level settings.
Once deployed, the Operator:
* Validates your Chkk Connector configurations.
* Keeps the Connector aligned with your CRD-based configuration.
* Orchestrates creation and updates of the Connector resources.
* Reports the Connector's status in the Operator's CRD.
### Chkk Agent
Chkk Agent is a Kubernetes Custom Resource managed by the Operator. It defines how and when to collect data from your cluster. Some key features include:
* Manages the Agent CronJob: Schedules periodic scans of your cluster to keep you informed of the latest known risks.
* Resource Filtering: Allows you to include or exclude specific namespaces or resource types.
***
## Setup
### Prerequisites
Before installing the Chkk Kubernetes Connector, ensure the following:
1. Allowlisted Access
* You must be allowlisted to access the Chkk SaaS. Contact us to get a dedicated Chkk Organization provisioned for you: [chkk.io](https://www.chkk.io/).
2. Network Firewall Rules
* If your cluster is in a restricted network, allow outbound connections to:
* `chkk.io` and its subdomains
* `s3.amazonaws.com` and its subdomains
3. Proxy Settings
* If you use a proxy server, you will be required to configure the `HTTP_PROXY`, `HTTPS_PROXY`, and `NO_PROXY` environment variables at the time of installation.
4. Image Hosting
* The Chkk Kubernetes Connector container images are hosted publicly on the [Amazon ECR Public Registry](https://gallery.ecr.aws/chkk/). Ensure your cluster can pull images from this registry.
* Chkk supports custom registries. If you host all images in a private registry, detailed configuration instructions will be provided during installation.
### Resource Requirements
Below are the baseline resource requests for each component of the Chkk Kubernetes Connector. Actual usage varies by cluster size and scan frequency.
| Component | CPU | Memory |
| ------------------ | ---- | ------ |
| Chkk Operator | 100m | 256Mi |
| Chkk Agent | 500m | 1024Mi |
| Chkk Agent Manager | 50m | 128Mi |
### Supported Kubernetes Distributions
The Chkk Kubernetes Connector is compatible with all Kubernetes providers that are compliant with the upstream API. For the list of supported Kubernetes providers and versions, refer to [Support and Compatibility](/overview/support-compatibility)
### Installation Modes
There are three deployment methods available for installing the Chkk Kubernetes Connector:
* Helm
* K8s YAML
* Terraform
### System Requirements
Before installing the Chkk Kubernetes Connector, please ensure that your system meets the minimum requirements for the selected deployment method:
- Kubernetes >= v1.19 (tested on EKS, GKE, AKS)
- OS/Architecture: linux/amd64, linux/arm64
- kubectl: >= v1.19
- Helm: >= version 2
- Kubernetes >= v1.19 (tested on EKS, GKE, AKS)
- OS/Architecture: linux/amd64, linux/arm64
- kubectl: >= v1.19
- Kubernetes >= v1.19 (tested on EKS, GKE, AKS)
- OS/Architecture: linux/amd64, linux/arm64
- hashicorp/helm: >= version 2
- gavinbunney/kubectl: >= v1.19
***
## Installation & Validation
1. Log in to the Chkk Dashboard: [chkk.io](https://www.chkk.io/).
2. In the left-hand sidebar, navigate to **Risk Ledger** → **Clusters**.
3. Click **Add Cluster** in the top-right corner.
4. Follow the step-by-step instructions and select your preferred deployment mode.
## Configuration
#### Configuration Parameters
The table below lists the configurable parameters for installing the Chkk Operator.
| Parameter | Description | Sample Default |
| -------------------------- | ------------------------------------------------------------------------------------------------ | ----------------------------------- |
| `image.repository` | Image repository | `public.ecr.aws/chkk/operator` |
| `image.tag` | Image tag | `v0.0.14` |
| `image.pullPolicy` | Image pull policy | `Always` |
| `replicaCount` | Number of replicas | `1` |
| `revisionHistoryLimit` | Revision history limit | `2` |
| `secret.create` | Create a new secret | `true` |
| `secret.chkkAccessToken` | Chkk access token | `CHKK-ACCESS-TOKEN` |
| `secret.ref.secretName` | Name of an existing Secret with the Chkk access token (only used if `secret.create=false`) | `chkk-operator` |
| `secret.ref.keyName` | Key in the existing Secret's `data` that contains the token (only used if `secret.create=false`) | `CHKK_ACCESS_TOKEN` |
| `serviceAccount.create` | Create a service account | `true` |
| `serviceAccount.name` | Service account name | `chkk-operator-sa` |
| `podAnnotations` | Annotations applied to the Chkk Operator Pod | `{ chkk.io/name: "chkk-operator" }` |
| `disableAnalytics` | Disable analytics data collection | `false` |
| `proxy.http_proxy` | HTTP proxy | `""` |
| `proxy.https_proxy` | HTTPS proxy | `""` |
| `proxy.no_proxy` | No proxy | `""` |
| `tolerations` | Node tolerations | See `values.yaml` |
| `nodeSelector` | Node labels for scheduling | `{}` |
| `affinity` | Pod scheduling affinity | See `values.yaml` |
| `securityContext` | Pod-Level Security Context | See `values.yaml` |
| `containerSecurityContext` | Container-Level Security Context | See `values.yaml` |
#### Configuration Examples
If you prefer to manage the secret externally, set `secret.create` to false and reference your secret in the `values.yaml` file:
```yaml theme={"dark"}
secret:
create: false
ref:
secretName: my-secret
keyName: CHKK_ACCESS_TOKEN
```
To customize the RBAC settings, modify the serviceAccount parameters in the `values.yaml` file. You can specify whether to create a new service account and provide a custom name.
```yaml theme={"dark"}
serviceAccount:
create: false
name: chkkagent-custom-sa
```
To use a custom image, update the `image.repository` and `image.tag` fields in the `values.yaml` file. You can also set the `image.pullPolicy` to control when the image is pulled.
```yaml theme={"dark"}
image:
repository: custom-repo/chkk/operator
tag: v0.0.14
pullPolicy: IfNotPresent
```
To schedule the Chkk Operator on nodes with specific taints, configure the tolerations section in the `values.yaml` file. You can specify the key, operator, value, and effect for each toleration.
```yaml theme={"dark"}
tolerations:
- key: "example.com/special-taint"
operator: "Equal"
value: "true"
effect: "NoSchedule"
```
When configuring the Chkk Connector to run behind a proxy, set the following fields in your `values.yaml` to ensure proper connectivity and to disable telemetry reporting.
You **must** set `disableAnalytics: true` when defining proxy settings.
```yaml theme={"dark"}
proxy:
http_proxy: "http://your-proxy.example.com:3128"
https_proxy: "http://your-proxy.example.com:3128"
no_proxy: "localhost,127.0.0.1,.svc,.cluster.local"
disableAnalytics: true
```
This ensures the Chkk Operator and Agent operate correctly within your network environment.
***
The `ChkkAgent` Custom Resource (CR) tells the Operator how the cluster scanning, and cluster context ingestion should function.
When you apply a `ChkkAgent` resource, the Operator:
1. Creates or updates a CronJob resource to run scans on a schedule.
2. Handles resource filtering (which namespaces or resource types to include/exclude).
3. Informs the **Chkk Agent Manager** about on-demand re-scan triggers from the Chkk Dashboard.
#### Specification Overview
```yaml theme={"dark"}
apiVersion: k8s.chkk.io/v1beta1
kind: ChkkAgent
metadata:
name: chkk-agent
namespace: chkk-system
spec:
global:
clusterName: "my-cluster"
clusterEnvironment: "production"
# ...
agentOverride:
name: chkk-cj
image:
name: public.ecr.aws/chkk/chkk-agent:v0.1.14
managerImage:
name: public.ecr.aws/chkk/chkk-agent-manager:v0.1.14
# ...
```
#### Spec Fields
##### agentOverride
| Field | Description |
| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `activeDeadlineSeconds` | Time (in seconds) after which the job is terminated if it hasn't finished. |
| `backoffLimit` | Maximum number of retries for failed jobs before considering them permanently failed. |
| `completions` | Number of pods that must successfully complete for the job to finish. |
| `completionMode` | Method for tracking pod completions (`NonIndexed` or `Indexed`). |
| `concurrencyPolicy` | Defines concurrency handling for the job (`Allow`, `Forbid`, or `Replace`). |
| `createRbac` | Automatically create the necessary RBAC resources (Roles/ClusterRoles). |
| `failedJobsHistoryLimit` | Number of failed job executions to keep for reference. |
| `image` | Configuration for the Chkk Agent container image (repository, tag, etc.). |
| `managerImage` | Configuration for the Chkk Agent Manager container image (repository, tag, etc.). |
| `name` | Overrides the default name for the resource. Must be 1-65 characters if set. |
| `schedule` | Cron expression defining how often the job runs. For example, `0 2 * * *` would run daily at 02:00. |
| `serviceAccountName` | ServiceAccount used by this job. Ignored if `createRbac` is `true`. If you're manually managing RBAC, set this to reference your custom ServiceAccount. |
| `template` | Pod template for the Chkk Agent, enabling detailed security, resource settings, etc. |
| Field | Description |
| ---------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `manualSelector` | When `true`, allows you to manually control pod labels and pod selectors. Typically leave this `false` or unset so the system manages labels uniquely. |
| `parallelism` | The maximum number of pods the job can run in parallel at one time. |
| `selector` | A label query used to match pods to the job. Normally left unset so the system generates unique labels automatically. |
| `startingDeadlineSeconds` | A deadline in seconds for starting the job if a scheduled run is missed. Missed runs are counted as failures. |
| `successfulJobsHistoryLimit` | The number of successful job runs to retain. Older completions are cleaned up if you exceed this limit. |
| `suspend` | When `true`, no pods are created and active pods are terminated. This effectively pauses the job. |
| `template` | Defines the pod template for the Chkk Agent. You can customize security contexts, resource requests, environment variables, etc. |
| `timeZone` | Time zone name for interpreting the `schedule`. Defaults to the kube-controller-manager's time zone if unspecified. (Requires the `CronJobTimeZone` feature gate to be enabled in Cloud Native environments.) |
| `ttlSecondsAfterFinished` | Time (in seconds) after the job finishes (Complete or Failed) before it's eligible for garbage collection (auto-deletion). A value of `0` deletes the job immediately upon completion. |
***
##### global
| Field | Description |
| ---------------------- | ------------------------------------------------------------------------------------ |
| `clusterEnvironment` | Environment name (e.g., `production`, `development`). |
| `clusterName` | Unique identifier for your cluster. |
| `credentials` | API credentials for authenticating the agent with Chkk. |
| `endpoint` | URL of the Chkk API. |
| `filter` | Rules for including or excluding resources during scans. |
| `logLevel` | Level of logging verbosity (e.g., `trace`, `debug`, `info`, `warn`, `error`, `off`). |
| `podAnnotationsAsTags` | Maps selected Kubernetes pod annotations to Chkk tags for better traceability. |
| `podLabelsAsTags` | Maps selected Kubernetes pod labels to Chkk tags. |
| `tags` | Custom tags to apply across clusters/resources (e.g., `team:alpha`). |
| `updates` | Controls agent auto-updates, specifying update frequency or behavior. |
***
##### Status Fields
| Field | Description |
| ------------------- | -------------------------------------------------------------------------------------------- |
| `agent` | Indicates the current state of the associated CronJob (e.g., `Active`, `Suspended`). |
| `conditions` | List of conditions describing the ChkkAgent's state (e.g., `Ready`, `Reconciling`). |
| `lastScanTime` | Timestamp of the most recent scan performed by the agent. |
| `latestUpdateState` | Reflects the status of the last update applied to the ChkkAgent (e.g., `Success`, `Failed`). |
#### Configuration Examples
The following example shows a basic deployment of the `ChkkAgent` resource:
```yaml theme={"dark"}
apiVersion: k8s.chkk.io/v1beta1
kind: ChkkAgent
metadata:
name: chkk-agent
namespace: chkk-system
```
Setting the `spec.global.clusterName` and `spec.global.clusterEnvironment` fields in the `ChkkAgent` resource allows you to customize the cluster name and environment displayed in the Chkk Dashboard:
```yaml theme={"dark"}
apiVersion: k8s.chkk.io/v1beta1
kind: ChkkAgent
metadata:
name: chkk-agent
namespace: chkk-system
spec:
global:
clusterName: "my-cluster"
clusterEnvironment: "production"
```
Note: This can also be done manually through the Chkk Dashboard itself.
If you host the `public.ecr.aws/chkk/chkk-agent` and `public.ecr.aws/chkk/chkk-agent-manager` images in a private registry, or if you want to override the default versions of these images, you can do so by setting `spec.agentOverride.image.name` and `spec.agentOverride.managerImage.name` in the `ChkkAgent` resource:
```yaml theme={"dark"}
apiVersion: k8s.chkk.io/v1beta1
kind: ChkkAgent
metadata:
name: chkk-agent
namespace: chkk-system
spec:
agentOverride:
image:
name: public.ecr.aws/chkk/chkk-agent:v0.1.12
managerImage:
name: public.ecr.aws/chkk/chkk-agent-manager:v0.1.12
```
To customize the security context for the Chkk Agent, you can set the `spec.agentOverride.template.securityContext` field and/or the `spec.agentOverride.template.container.securityContext` field in the `ChkkAgent` resource:
```yaml theme={"dark"}
apiVersion: k8s.chkk.io/v1beta1
kind: ChkkAgent
metadata:
name: chkk-agent
namespace: chkk-system
spec:
agentOverride:
template:
securityContext:
runAsNonRoot: true
runAsUser: 12000
runAsGroup: 12000
fsGroup: 12000
seccompProfile:
type: RuntimeDefault
container:
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop:
- ALL
readOnlyRootFilesystem: true
runAsNonRoot: true
```
To use an existing Secret for the Chkk Agent's credentials, set the `spec.global.credentials.accessTokenSecret` field in the `ChkkAgent` resource:
```yaml theme={"dark"}
apiVersion: k8s.chkk.io/v1beta1
kind: ChkkAgent
metadata:
name: chkk-agent
namespace: chkk-system
spec:
global:
credentials:
accessTokenSecret:
secretName: chkk-agent-token
keyName: CHKK_ACCESS_TOKEN
```
If you want to use a custom Service Account for the Chkk Agent, set the `spec.agentOverride.serviceAccountName` field in the `ChkkAgent` resource:
```yaml theme={"dark"}
apiVersion: k8s.chkk.io/v1beta1
kind: ChkkAgent
metadata:
name: chkk-agent
namespace: chkk-system
spec:
agentOverride:
createRbac: false
serviceAccountName: chkk-agent-custom-sa
```
If you supply a custom ServiceAccount, ensure the associated ClusterRole has the following RBAC permissions:
```yaml theme={"dark"}
- apiGroups: ["batch"]
resources: ["jobs", "cronjobs"]
verbs: ["get", "create", "list", "update"]
- apiGroups: [""]
resources: ["nodes"]
verbs: ["get", "list", "watch"]
```
To include or exclude specific namespaces or resource types during scans, set the `spec.global.filter` field in the `ChkkAgent` resource. By default, the following filter is applied:
```yaml theme={"dark"}
apiVersion: k8s.chkk.io/v1beta1
kind: ChkkAgent
metadata:
name: chkk-agent-1
namespace: chkk-system
spec:
global:
credentials:
accessToken:
filter: |-
rules:
- exclude:
- path: $.metadata.name
match: ^chkk
- include:
- path: $.kind
match: ^DaemonSet|Deployment|Pod|PodTemplate|ReplicationController|StatefulSet$
- include:
- path: $.kind
match: ^NetworkPolicy|CronJob|Namespace|Service|Job|Ingress|Node$
- include:
- path: $.kind
match: ^CSIStorageCapacity|PriorityLevelConfiguration|HorizontalPodAutoscaler|EndpointSlice$
- include:
- path: $.kind
match: ^PodDisruptionBudget|PodSecurityPolicy|RuntimeClass|ValidatingWebhookConfiguration|CustomResourceDefinition$
- include:
- path: $.kind
match: ^TokenReview|LocalSubjectAccessReview|SelfSubjectAccessReview|CertificateSigningRequest|Lease|ClusterRole$
- include:
- path: $.kind
match: ^ClusterRoleBinding|Role|RoleBinding|Ingress|IngressClass|PriorityClass$
- include:
- path: $.kind
match: ^CSIDriver|CSINode|StorageClass|VolumeAttachment$
- include:
- path: $.kind
match: ^ConfigMap$
- path: $.metadata.name
match: ^*dns*$
```
The Chkk Agent CronJob runs every 12 hours by default.
To customize how frequently the Chkk Agent runs, set the `spec.agentOverride.schedule` field in the `ChkkAgent` custom resource. The schedule follows standard Kubernetes CronJob format.
```yaml theme={"dark"}
apiVersion: k8s.chkk.io/v1beta1
kind: ChkkAgent
metadata:
name: chkk-agent
namespace: chkk-system
spec:
agentOverride:
schedule: "0 */6 * * *" # Every 6 hours
```
If you prefer to manage your Cloud Native environment with Terraform, Chkk provides a **Terraform module** for deploying the Chkk Kubernetes Connector. This module automates creation of the Chkk Operator and Chkk Agent, handling secret management, RBAC, and other necessary resources.
#### Providers
The Terraform module relies on the following providers:
| Name | Version |
| ------------------- | --------: |
| helm | >= 2.10.0 |
| gavinbunney/kubectl | >= 1.7.0 |
Ensure these versions (or newer) are installed and configured in your Terraform environment.
***
#### Usage
Below are several usage examples showing how to configure secrets, override Service Accounts, or set the cluster name and environment. For all these examples, set `source` to point to the appropriate Git repository and tag (e.g., `ref=v0.1.6`).
This snippet deploys the Chkk Operator with a newly created Secret containing your Chkk access token. The Operator and Agent resources will be installed in the `chkk-system` namespace.
```hcl theme={"dark"}
module "chkk_k8s_connector" {
source = "git::https://github.com/chkk-io/terraform-chkk-k8s-connector.git?ref=v0.1.6"
create_namespace = true
namespace = "chkk-system"
chkk_operator_config = {
secret = {
chkkAccessToken = ""
}
}
}
```
If you already have a Secret named `chkk-operator-secret` containing your Chkk access token, you can reference it directly instead of creating a new one.
```hcl theme={"dark"}
module "chkk_k8s_connector" {
source = "git::https://github.com/chkk-io/terraform-chkk-k8s-connector.git?ref=v0.1.6"
create_namespace = true
namespace = "chkk-system"
chkk_operator_config = {
secret = {
create = false
ref = {
secretName = "chkk-operator-secret"
keyName = "accessToken"
}
}
}
}
```
You can also configure separate secrets for the Operator and the Agent. The Operator references `chkk-operator-secret`, while the Agent references `chkk-agent-secret`.
```hcl theme={"dark"}
module "chkk_k8s_connector" {
source = "git::https://github.com/chkk-io/terraform-chkk-k8s-connector.git?ref=v0.1.6"
create_namespace = true
namespace = "chkk-system"
chkk_operator_config = {
secret = {
create = false
ref = {
secretName = "chkk-operator-secret"
keyName = "accessToken"
}
}
}
chkk_agent_config = {
secret = {
secretName = "chkk-agent-secret"
keyName = "accessToken"
}
}
}
```
Use a custom Service Account name and let the module create it for you:
```hcl theme={"dark"}
module "chkk_k8s_connector" {
source = "git::https://github.com/chkk-io/terraform-chkk-k8s-connector.git?ref=v0.1.6"
create_namespace = true
namespace = "chkk-system"
chkk_operator_config = {
secret = {
chkkAccessToken = ""
}
serviceAccount = {
create = true
name = "chkk-operator-custom-sa"
}
}
}
```
In this scenario, both Operator and Agent have their own existing Service Accounts (no new Service Accounts are created):
```hcl theme={"dark"}
module "chkk_k8s_connector" {
source = "git::https://github.com/chkk-io/terraform-chkk-k8s-connector.git?ref=v0.1.6"
create_namespace = true
namespace = "chkk-system"
chkk_operator_config = {
secret = {
chkkAccessToken = ""
}
serviceAccount = {
create = false
name = "chkk-operator-custom-sa"
}
}
chkk_agent_config = {
serviceAccount = {
create = false
name = "chkk-agent-custom-sa"
}
}
}
```
You can override the default cluster name and environment in the Chkk Dashboard by setting `cluster_name` and `cluster_environment`. In this example, a new secret is created for the Operator and Agent using ``.
```hcl theme={"dark"}
module "chkk_k8s_connector" {
source = "git::https://github.com/chkk-io/terraform-chkk-k8s-connector.git?ref=v0.1.6"
create_namespace = true
namespace = "chkk-system"
chkk_operator_config = {
secret = {
chkkAccessToken = ""
}
}
# Override cluster name and environment displayed in Chkk
cluster_name = "eks-prod-uswest2"
cluster_environment = "prod"
}
```
When configuring the Chkk Connector to run behind a proxy using the Terraform module, define the following fields in your module configuration to ensure proper connectivity and to disable telemetry reporting.
You **must** set `disableAnalytics = true` when defining proxy settings.
```hcl theme={"dark"}
module "chkk_k8s_connector" {
source = "git::https://github.com/chkk-io/terraform-chkk-k8s-connector.git?ref=v0.1.6"
create_namespace = true
namespace = "chkk-system"
chkk_operator_config = {
secret = {
chkkAccessToken = ""
}
proxy = {
http_proxy = ""
https_proxy = ""
no_proxy = ""
}
disableAnalytics = true
}
}
```
This ensures the Chkk Operator and Agent operate correctly within your network environment.
If you host the `public.ecr.aws/chkk/chkk-agent`, `public.ecr.aws/chkk/chkk-agent-manager`, or the `public.ecr.aws/chkk/operator` images in a private registry, or if you want to override the default versions of these images, you can do so by updating the Terraform module with the following fields:
```hcl theme={"dark"}
module "chkk_k8s_connector" {
source = "git::https://github.com/chkk-io/terraform-chkk-k8s-connector.git?ref=v0.1.6"
create_namespace = true
namespace = "chkk-system"
chkk_agent_config = {
agent_image = {
repository = "public.ecr.aws/chkk/cluster-agent:v0.1.10"
}
manager_image = {
name = "public.ecr.aws/chkk/cluster-agent-manager:v0.1.10"
}
}
chkk_operator_config = {
secret = {
chkkAccessToken =
}
image = {
repository = "public.ecr.aws/chkk/operator"
tag = "v0.0.10"
}
}
}
```
The Chkk Agent CronJob runs every 12 hours by default.
To customize how frequently the Chkk Agent runs, you can set a custom schedule in the `chkk_agent_config` section. The schedule follows standard Kubernetes CronJob format.
```hcl theme={"dark"}
module "chkk_k8s_connector" {
source = "git::https://github.com/chkk-io/terraform-chkk-k8s-connector.git?ref=v0.1.6"
create_namespace = true
namespace = "chkk-system"
chkk_operator_config = {
secret = {
chkkAccessToken = ""
}
}
chkk_agent_config = {
schedule = "0 */6 * * *" # Every 6 hours
}
}
```
***
#### Inputs
Below is a reference of the module's input variables:
| Name | Description | Type | Default | Required |
| ----------------------------------------------------- | --------------------------------------------------------------------------------------------- | ------ | ------------------ | :------: |
| `release_name` | The name of the Helm release. | string | `chkk-operator` | no |
| `namespace` | The namespace where resources are deployed. | string | `chkk-system` | no |
| `chart_version` | Version of the Helm chart to deploy. | string | `n/a` | no |
| `create_namespace` | Whether to create the namespace if it doesn't exist. | bool | `true` | no |
| `filter` | Override the default filter for the ChkkAgent. | string | `n/a` | no |
| `cluster_name` | Override the default cluster name for the ChkkAgent. | string | `n/a` | no |
| `cluster_environment` | Override the default cluster environment for the ChkkAgent. | string | `n/a` | no |
| `chkk_operator_config` | Values for configuring the Chkk Operator Helm chart. | map | `{}` | no |
| `chkk_operator_config.secret` | Details on how to set up the Secret for the Chkk Operator (create new or reference existing). | map | `{}` | no |
| `chkk_operator_config.secret.create` | Whether to create a new Secret resource or use an existing one. | bool | `true` | no |
| `chkk_operator_config.secret.chkkAccessToken` | If `create` is `true`, this token is stored in the new Secret. | string | `""` | no |
| `chkk_operator_config.secret.ref.secretName` | If `create` is `false`, the name of an existing Secret containing the token. | string | `""` | no |
| `chkk_operator_config.secret.ref.keyName` | If `create` is `false`, the key name inside the existing Secret that stores the token. | string | `""` | no |
| `chkk_operator_config.serviceAccount` | Configure a dedicated Service Account for the Chkk Operator. | map | `{}` | no |
| `chkk_operator_config.serviceAccount.create` | Whether to create a new Service Account or use an existing one. | bool | `true` | no |
| `chkk_operator_config.serviceAccount.name` | Name of the Service Account (if `create` is `true`) or the existing SA name. | string | `chkk-operator-sa` | no |
| `chkk_agent_config` | Configuration overrides for the ChkkAgent. | map | `{}` | no |
| `chkk_agent_config.secret` | Secret object used by the ChkkAgent. | string | `""` | no |
| `chkk_agent_config.secret.accessToken` | If the ChkkAgent is to create/use a new secret, specify the token here. | string | `""` | no |
| `chkk_agent_config.secret.secretName` | Name of the existing Secret that the ChkkAgent should use (if not creating a new one). | string | `""` | no |
| `chkk_agent_config.secret.keyName` | Key inside that Secret for the token. | string | `""` | no |
| `chkk_agent_config.serviceAccount` | Configure a dedicated Service Account for the ChkkAgent. | map | `{}` | no |
| `chkk_agent_config.serviceAccount.create` | Whether to create or reuse an existing Service Account for the ChkkAgent. | bool | `true` | no |
| `chkk_agent_config.serviceAccount.serviceAccountName` | If `create = false`, name of the existing Service Account the agent should use. | string | `""` | no |
| `chkk_agent_config.agent_image` | Agent Image object for ChkkAgent | map | `{}` | no |
| `chkk_agent_config.agent_image.name` | Full image name for the agent image (repository:tag) | string | `""` | no |
| `chkk_agent_config.manager_image` | Manager Image object for ChkkAgent | map | `{}` | no |
| `chkk_agent_config.manager_image.name` | Full image name for the manager image (repository:tag) | string | `""` | no |
| `chkk_agent_config.schedule` | Cron schedule for ChkkAgent CronJob execution. | string | `""` | no |
#### Outputs
Currently, this module does not produce any outputs.
## Upgrade
```bash theme={"dark"}
helm list -n chkk-system -o json
```
Sample output:
```json theme={"dark"}
[{
"name": "chkk-operator",
"namespace": "chkk-system",
"revision": "1",
"chart": "chkk-operator-0.0.9",
"app_version": "0.0.9"
}]
```
Update the Helm repository to fetch latest chart
```bash theme={"dark"}
helm repo update chkk
```
Replace `` with your Chkk ingestion token, which you can copy from the Chkk Dashboard under **Settings → Tokens**.
```bash theme={"dark"}
helm upgrade chkk-operator chkk/chkk-operator \
--namespace chkk-system \
--set secret.chkkAccessToken=
```
```bash theme={"dark"}
kubectl get secret chkk-operator-token -n chkk-system
```
Sample output:
```bash theme={"dark"}
NAME TYPE DATA AGE
chkk-operator-token Opaque 1 10m
```
```bash theme={"dark"}
helm upgrade chkk-operator chkk/chkk-operator \
--namespace chkk-system \
--set secret.ref.secretName=chkk-operator-token \
--set secret.ref.keyName= \
--set secret.create=false
```
1. Get the Secret:
```bash theme={"dark"}
kubectl get secret chkk-operator-token -n chkk-system
```
Sample output:
```bash theme={"dark"}
NAME TYPE DATA AGE
chkk-operator-token Opaque 1 10m
```
2. Get the ServiceAccount:
```bash theme={"dark"}
kubectl get serviceaccount chkk-operator -n chkk-system
```
Sample output:
```bash theme={"dark"}
NAME SECRETS AGE
chkk-operator 1 10m
```
```bash theme={"dark"}
helm upgrade chkk-operator chkk/chkk-operator \
--namespace chkk-system \
--set secret.ref.secretName=chkk-operator-token \
--set secret.ref.keyName= \
--set secret.create=false \
--set serviceAccount.create=false \
--set serviceAccount.name=
```
```bash theme={"dark"}
kubectl get deployment chkk-operator -n chkk-system -o json \
| jq '.spec.template.spec.containers[].image'
```
Sample output:
```bash theme={"dark"}
"public.ecr.aws/chkk/operator:v0.0.14"
```
Follow the given steps to Upgrade the Chkk Kubernetes Connector via Terraform
```hcl theme={"dark"}
module "chkk_k8s_connector" {
source = "git::https://github.com/chkk-io/terraform-chkk-k8s-connector.git?ref=v0.1.6"
create_namespace = true
namespace = "chkk-system"
chart_version = "v0.0.14"
chkk_operator_config = {
secret = {
create = true
chkkAccessToken =
}
}
```
```hcl theme={"dark"}
module "chkk_k8s_connector" {
source = "git::https://github.com/chkk-io/terraform-chkk-k8s-connector.git?ref=v0.1.6"
create_namespace = false
namespace = "chkk-system"
chart_version = "v0.0.14"
chkk_operator_config = {
secret = {
create = false
ref = {
secretName = "chkk-operator-token",
keyName = "CHKK_ACCESS_TOKEN"
}
}
}
chkk_agent_config = {
secret = {
secretName = "chkk-agent-token",
keyName = "CHKK_ACCESS_TOKEN"
}
}
}
```
```hcl theme={"dark"}
module "chkk_k8s_connector" {
source = "git::https://github.com/chkk-io/terraform-chkk-k8s-connector.git?ref=v0.1.6"
create_namespace = false
namespace = "chkk-system"
chart_version = "v0.0.14"
chkk_operator_config = {
secret = {
create = false
ref = {
secretName = "chkk-operator-token",
keyName = "CHKK_ACCESS_TOKEN"
}
}
serviceAccount = {
create = false
name = "chkk-operator"
}
}
chkk_agent_config = {
secret = {
secretName = "chkk-agent-token",
keyName = "CHKK_ACCESS_TOKEN"
}
serviceAccount = {
create = false
name = "chkk-agent"
}
}
}
```
```bash theme={"dark"}
kubectl get deployment chkk-operator -n chkk-system -o json \
| jq '.spec.template.spec.containers[].image'
```
Sample output:
```bash theme={"dark"}
"public.ecr.aws/chkk/operator:v0.0.14"
```
# Activity Feed
Source: https://docs.chkk.io/features/activity-feed
A brief description, use-case, and usage instructions of the Activity Feed feature
Chkk's **Activity Feed** feature provides a comprehensive, real-time record of all actions taken across your Upgrade Assessments, Upgrade Templates, and Upgrade Plans. It captures both high-level events—such as status updates and who requested them—and step-specific updates (e.g., adding or editing custom steps).
By centralizing each change and its context, the **Activity Feed** enhances collaboration, transparency, and auditability—making it easy to see what changed, who contributed, and when. This real-time visibility helps your team coordinate parallel upgrades with confidence, whether you're working on a single cluster or rolling out changes across multiple clusters simultaneously.
## Usage
The provided steps also apply to Cluster Upgrade Plans, Project Upgrade Plans, and Project Upgrade Templates.
Follow these steps to access the **Activity Feed** for both the entire **Cluster Upgrade Template** and for a specific step within that template.
1. In the **Chkk Dashboard**, expand **Upgrade Copilot** on the left menu.
2. Click **Upgrade Templates** and then **Clusters**.
3. You will see a list of all existing **Cluster Upgrade Templates**.
1. Select the **Cluster Upgrade Template** you want to examine.
2. Next to the **template name** at the top, click the **heartbeat icon**.
3. A **sidebar** will appear, showing the **Activity Feed** for the entire Upgrade Template.
1. Within the open **Upgrade Template**, navigate to a specific **step** of any **stage**.
2. Next to that step's name, click the **heartbeat icon**.
3. A **sidebar** will appear on the right, displaying the **Activity Feed** only for that step.
# Comments
Source: https://docs.chkk.io/features/add-comments
A brief description, use-case, and usage instructions of the Add Comments feature
Chkk's **Add Comments** feature allows teams to capture any additional context, internal guidelines, or unique considerations at every step of an Upgrade Assessment, Upgrade Template, or Upgrade Plan.
Each upgrade—whether for a cluster, a specific Cloud Native Project, application service, or operator—consists of multiple stages, and each stage can contain multiple steps.
By placing comments directly next to these steps, users can clarify decisions (e.g., why certain Cloud Native Projects are deferred) or highlight key compliance requirements.
They can also note any organization-wide policies—such as upgrading stateful Cloud Native Projects or application services separately—so that future recommendations reflect these preferences.
Centralizing comments at the step level **reduces guesswork**, **preserves institutional knowledge**, and **standardizes workflows**.
Team members can quickly see the rationale behind key decisions, while parallel upgrade efforts become more efficient thanks to clear documentation.
In short, adding comments fosters a transparent, collaborative, and consistent upgrade process for every environment.
* Upgrade Assessments and Upgrade Templates (Cluster and Project) let you leave comments for Chkk and the team.
* Upgrade Plans (Cluster and Project) let you leave comments for the team only.
## Usage
The provided steps also apply to Upgrade Assessments, Cluster Upgrade Plans, Project Upgrade Plans, and Project Upgrade Templates.
Below are the steps to **Add Comments** for both **Chkk** and **your team** on a specific step within a Cluster Upgrade Template.
1. In the **Chkk Dashboard**, expand **Upgrade Copilot** on the left menu.
2. Click **Upgrade Templates** and then **Clusters**.
3. You will see a list of all existing **Cluster Upgrade Templates**.
1. Locate the **step** you want to comment on.
2. Click the **heartbeat icon** next to that step to open the sidebar.
3. A sidebar will appear, showing the **Activity Feed** and comment sections.
1. Under **Leave Comment for your team**, type your message in the text area.
2. Click **Comment** to post it.
1. Under **Leave Comment for Chkk** in the same sidebar, enter your message or question for the Chkk team.
2. Click **Comment** to post it.
3. The Chkk team will be notified of your comment.
# Custom Steps
Source: https://docs.chkk.io/features/add-edit-delete-custom-steps
A brief description, use-case, and usage instructions of the Add/Edit/Delete Custom Steps feature
Chkk's **Add/Edit/Delete Custom Steps** feature lets users embed their organization's internal processes into any Upgrade Assessment, Upgrade Template, or Upgrade Plan. This ensures every upgrade—across one or multiple clusters—follows the same best practices, compliance checks, and change-management guidelines. Because these custom steps carry forward from the template to each new Upgrade Plan, your team can delegate tasks in parallel without recreating instructions. Plus, you can still tailor steps for specific clusters even after a plan is instantiated, making it easy to address unique requirements.
This flexible capability fosters the reuse of best practices, retains institutional knowledge, and standardizes workflows—allowing teams to align quickly on operational details and speed up upgrades across the environment.
## Usage
The provided steps also apply to Upgrade Assessments, Cluster Upgrade Plans, Project Upgrade Templates,
and Project Upgrade Plans.
Below are the instructions for **adding, editing, and deleting custom steps** in an Upgrade Template.
1. In the **Chkk Dashboard**, expand **Upgrade Copilot** on the left menu.
2. Click **Upgrade Templates** and then **Clusters**.
3. You will see a list of all existing **Cluster Upgrade Templates**.
1. Select the desired **Cluster Upgrade Template**.
2. Select the **three dots** icon on the right of any step to either **Add a step Before** or **Add a step After** the currently selected step.\
3. A **modal** will appear where you can fill in:
* **Title**: The name of the custom step.
* **Badge**: A tag or label displayed next to the step.
* **Required**: Checkbox to mark the step as **required** or **optional**.
* **Write/Preview**: Use the Markdown editor and preview window to craft the step's content.\
4. Click **Add Step** to confirm and insert the new custom step into the current stage.
1. Click the **three dots** icon on the right of the custom step you wish to modify.
* Select **Edit Step** from the dropdown.\
2. A modal appears with the current details of the step (title, badge, etc.).
3. Make the necessary changes and click **Update Step** to save your edits.\
1. Click the **three dots** icon on the right of the custom step you want to remove.
* Select **Delete Step** from the dropdown.\
2. A confirmation modal will prompt you to confirm the deletion.
3. Click **Delete Step** to permanently remove the custom step from the selected stage.
# Project Upgrade Recommendation
Source: https://docs.chkk.io/features/addon-upgrade-recommendation
A brief description and use-case of the Project Upgrade Recommendation feature
Chkk's **Project Upgrade Recommendation** feature identifies which Cloud Native Projects, application services, and operators in your clusters require upgrading, which upgrades are optional, and which can remain unchanged. Powered by Chkk's Collective Learning, the feature evaluates factors such as end-of-life (EOL) status, compatibility with your target Kubernetes version, known operational risks, and any enterprise policies you've defined (for example, preferring the latest version or sticking with stable releases).
Based on these assessments, Chkk classifies each Cloud Native Project, application service, and operator upgrade as ***Required***, ***Optional***, or ***Not Recommended***. A Project upgrade is deemed **Required** if it faces major compatibility concerns or presents critical risks. Optional upgrades are flagged when the Project remains compatible but may be outdated or has known issues. For each Required or Optional upgrade, Chkk recommends a target version that meets criteria such as compatibility, production mileage, and freedom from known risks.
If your organization's internal standards differ from Chkk's recommendations—whether you prefer to upgrade all Cloud Native Projects, application services, and operators or only those that are required—you can override the suggested version. Chkk will factor in your feedback during [Template Regeneration](/features/regenerate-template), producing updated recommendations tailored to your policies. By integrating these upgrade insights directly into your workflow, Chkk helps shorten research time, manage complex Cloud Native Project dependencies, and maintain smooth cluster operations with minimal disruptions.
The image below shows an example of a Cluster Upgrade Template with Project Upgrade Recommendations:
# Approve Upgrade Template
Source: https://docs.chkk.io/features/approve-upgrade-template
A brief description, use-case, and usage instructions for the Approve Upgrade Template feature
Chkk's **Approve Upgrade Template** feature ensures that each Upgrade Template is thoroughly reviewed, adjusted to align with organizational guidelines, and officially marked as ready for use. Once an Upgrade Template is **Available**, users can add custom steps, confirm which Cloud Native Project, application service, and operator versions to upgrade now versus later, and apply internal change-management standards.
After all necessary adjustments are in place, the user marks the upgrade template as **Approved for Use**. Chkk automatically logs who approved the upgrade template, giving the entire team visibility into its readiness. This standardized approach **reduces context switching**, **preserves knowledge**, and **promotes the reuse of best practices**—enabling faster upgrades across multiple clusters and ensuring **consistent workflows** organization-wide.
## Usage
The provided steps also apply to Project Upgrade Templates.
Follow the steps below to **Approve a Cluster Upgrade Template**:
1. In the **left-hand column** of the **Chkk Dashboard**, expand **Upgrade Copilot**.
2. Click **Upgrade Templates**, then select **Clusters**.
1. Navigate to the **Upgrade Template** you want to approve.
2. Click the **thumbs up** icon to approve it.
1. Once approved, the upgrade template's status changes to **Approved for
Use**. 2. The approval date appears under the **Approved** column, along with
any comments made by the approver.
1. After approval, a new **CTA Button** will appear, allowing you to [Instantiate Upgrade Plans](/features/instantiate-template-to-plan) from the approved Upgrade Template.
# Cancel an Upgrade Template or Plan
Source: https://docs.chkk.io/features/cancel-upgrade-template-plan
A brief description, use-case, and usage instructions of the Cancel Upgrade Template/Plan feature
The **Cancel an Upgrade Plan or Upgrade Template** feature allows you to stop an Upgrade Template or Upgrade Plan at any point in its execution, marking it with a **Canceled** status that remains visible in the dashboard. Once canceled, the workflow stops and the action cannot be undone—which means either a new Plan must be instantiated or a new Template must be requested. This is especially useful when a Template or Plan has become outdated, letting you formally indicate it shouldn't be used.
## Usage
The provided steps also apply to Cluster Upgrade Plans, Project Upgrade Plans, and Project Upgrade Templates.
Follow the steps below to **Cancel** a Cluster Upgrade Template:
1. In the **left-hand column** of the **Chkk Dashboard**, expand **Upgrade Copilot**.
2. Select **Upgrade Templates** -> **Clusters**.
1. Find the **Upgrade Template** you wish to cancel in the list.
2. Click the **three dots** icon (⋮) at the far right of the template's entry.
1. From the dropdown, select **Cancel Upgrade Template**.
2. A **modal** will appear asking for confirmation.
3. Click **Cancel Template** to confirm.
1. After cancellation, the template's **Status** will change to **Canceled**.
2. A **Canceled** template can no longer be used or executed.
# Captured Learnings
Source: https://docs.chkk.io/features/captured-learnings
A brief description and use-case of the Captured Learnings feature
Chkk's **Captured Learnings** feature automatically preserves and reuses the unique insights your team adds during each
upgrade—such as [Custom Steps](/features/add-edit-delete-custom-steps), guidelines, or specific version preferences.
Rather than continually updating external runbooks or tools, you simply embed these details
(e.g., always upgrading to the newest Cloud Native Project, application service, or operator release) into an Upgrade Assessment,
Upgrade Template, or Upgrade Plan. Chkk applies these insights—whether included in [Comments](/features/add-comments),
[Custom Steps](/features/add-edit-delete-custom-steps), or shared via feedback—during [Template Regeneration](/features/regenerate-template).
Additionally, on future upgrades, these policies and workflows are automatically included in newly generated recommendations, so your team can move faster while ensuring consistent, accurate upgrade practices across every cluster, Cloud Native Project, application service, and operator.
# Environment Upgraded
Source: https://docs.chkk.io/features/environment-upgraded
A brief description, use-case, and usage instructions of the Environment Upgraded feature
Chkk allows users to Mark a Cluster Upgrade Template as **Environment Upgraded**. This feature provides a clear way to indicate that every cluster in an environment (e.g., dev, staging, production) has been upgraded using a specific template. Each template corresponds to a "representative" cluster and can spawn multiple Upgrade Plans—one per cluster in that environment. Once those plans are carried out, marking the template as **Environment Upgraded** signals that all clusters are now running the recommended versions. This doesn't require each plan to be formally marked as **Completed**; rather, it serves as a high-level confirmation that the environment is fully upgraded. As a result, your team gains a concise view of upgrade status without needing to inspect individual clusters, helping prevent confusion about whether further actions are needed.
## Usage
Follow the steps below to mark a **Cluster Upgrade Template** as **Environment Upgraded**:
1. In the **left-hand column** of the **Chkk Dashboard**, expand **Upgrade Copilot**.
2. Select **Upgrade Templates** -> **Clusters**.
1. Locate the **Upgrade Template** you wish to mark as **Environment Upgraded** (it should already be marked as **Approved for Use**).
2. To the right of the template entry, select the **check mark** icon.
3. Select **Mark the Upgrade Template as Environment Upgraded** from the dropdown.
1. After confirmation, the **Status** of the upgrade template should have changed to: **Environment Upgraded**.
# Feedback Button
Source: https://docs.chkk.io/features/feedback-button
A brief description, use-case, and usage instructions of the Feedback Button feature
The **Feedback Button** provides a quick, frictionless way for users to engage directly with the platform's development, allowing them to report bugs, and request new features. It also lets users ask for help when something isn't clear, while capturing contextual data (such as the current page) to speed up troubleshooting.
## Usage
Follow the steps below to provide feedback using the **Feedback** button:
1. In the top-right corner of the **Chkk Dashboard**, click the **messaging icon** to open the feedback modal.
3. Enter your **feedback** or **query** in the text box provided.
4. Click **Submit** to send your feedback.
5. Upon submission, you will see a toast message confirming the submission of the feedback.
# Upgrade Plan Instantiation
Source: https://docs.chkk.io/features/instantiate-template-to-plan
A brief description, use-case, and usage instructions of the Upgrade Plan Instantiation feature
Chkk's **Upgrade Plan Instantiation** feature creates a tailored Upgrade Plan from an approved [Upgrade Template](/features/request-upgrade-template), whether you're upgrading a cluster or a specific Cloud Native Project. For clusters, the plan automatically incorporates details like the cluster name, region, node group configurations, and active applications. For Cloud Native Projects, instantiation takes a Cloud Native Project Upgrade Template and produces a plan tailored to a particular Cloud Native Project instance (e.g., same major.minor version) within a given cluster.
All Chkk-recommended steps—and any custom steps you've added—carry forward into each new plan, ensuring **standardized** and **reusable** processes across multiple clusters or environments. Once instantiated, each plan can be tracked through distinct stages such as "In Progress" or "Completed," making it easy to monitor overall progress. This structured, step-by-step approach also simplifies *delegation*, allowing senior engineers to assign upgrade tasks to less-experienced team members with confidence.
## Usage
Follow the steps below to **instantiate an Upgrade Plan** from an existing **Upgrade Template** in the Chkk Dashboard.
1. In the **left-hand column** of the **Chkk Dashboard**, expand **Upgrade Copilot**.
2. Select **Upgrade Templates** -> **Clusters**.
3. Locate the desired **Upgrade Template** that is **Approved for Use**.
1. Click the **Instantiate Plan** button next to the selected template.
2. You'll be taken to the **Instantiate Cluster Upgrade Plan** page, where the chosen template is preselected.
1. Under **Select Cluster to Upgrade**, pick the cluster you want to upgrade.
2. *(Optional)* Assign a **Cloud Account** if needed for your upgrade.
1. Click **Instantiate Upgrade Plan** button at the bottom to finalize and create your new plan.
2. You will be redirected to **Upgrade Plans** -> **Clusters** where you can see your newly instantiated Upgrade Plan with the status: **Waiting for Plan**.
1. In the **left-hand column** of the **Chkk Dashboard**, expand **Upgrade Copilot**.
2. Select **Upgrade Templates** -> **Projects**.
3. Locate the desired **Project Upgrade Template** that is **Approved for Use**.
1. Next to the **Approved** template, click **Instantiate Plan**.
2. The **Instantiate Project Upgrade Plan** screen will load, automatically highlighting the selected template.
1. Under **Select Project Instance to Upgrade**, pick the Cloud Native Project you want to instantiate the Upgrade Plan for.
1. Click **Instantiate Upgrade Plan** to finalize your choices.
2. You will be redirected to **Upgrade Plans** -> **Projects** where you can see your newly instantiated Upgrade Plan with the status: **Waiting for Plan**.
# Upgrade Plan Marked as Completed
Source: https://docs.chkk.io/features/mark-upgrade-plan-completed
A brief description, use-case, and usage instructions of the Upgrade Plan Marked as Completed feature
Chkk's **Upgrade Plan Marked as Completed** feature provides a clear way to finalize the upgrade for each individual cluster. Once all recommended and custom steps are done, a user can mark that cluster's plan as complete. Because each plan is tied to one cluster, completing one upgrade doesn't affect the status of the others.
By using this feature, your team can quickly see which clusters are fully upgraded and which still need attention, making it easier to coordinate parallel efforts, allocate resources effectively, and maintain a transparent view of your overall upgrade strategy.
## Usage
The provided steps also apply to Project Upgrade Plans.
Follow the steps below to **Mark an Upgrade Plan as Complete**:
1. In the **left-hand column** of the **Chkk Dashboard**, expand **Upgrade Copilot**.
2. Click **Upgrade Plans**, then select **Clusters**.
3. Identify the Upgrade Plan currently in **In Progress** status that you want to complete.
1. Next to the plan entry, click the **checkmark icon**.
2. A confirmation modal will appear once you click it.
1. *(Optional)* Add any **comments** you wish to include about the plan's outcome.
2. Click **Mark as Complete** to finalize the completion process.
1. Once marked complete, the Upgrade Plan becomes **read-only** and appears with a **Completed** status.
2. The **Marked Completed by** column updates to show the name of the user who completed the plan.
# Readiness Checks
Source: https://docs.chkk.io/features/readiness-checks
A brief description, use-case, and usage instructions of the Readiness Checks feature
Chkk's **Readiness Checks feature**—part of the *Upgrade Copilot*—verifies health and safety at each stage of an upgrade by running checks both before and after each change. These checks ensure that Cloud Native Projects, application services, operators, configurations, and workflows align with your organization's best practices. Chkk delivers them through two complementary methods:
1. **Guided Checks (Manual)**
Ideal for one-off or specialized validations, Guided Checks offer step-by-step instructions you can copy and run. This hands-on method ensures your team can inspect unique configurations on-demand without altering automated workflows.
2. **SHARC Checks (Automated)**
For recurring or broadly applicable validations, Chkk uses its SHARC (safety, health, and readiness checks) framework. SHARC Checks integrate seamlessly into Upgrade Plans, tracking each run with a unique flow ID and mapping results back to your upgrade workflow. You can also request new SHARC-supported checks for specific Cloud Native Projects, application services, operators, and configurations, tapping into Chkk's expansive library of SHARC packs.
By embedding these checks into each **preverified** upgrade plan—tested on a digital twin of your infrastructure—teams can identify potential issues early, reduce overall risk, and accelerate safe rollouts across single or multiple clusters.
# Template Regeneration
Source: https://docs.chkk.io/features/regenerate-template
A brief description, use-case, and usage instructions of the Template Regeneration feature
Chkk's **Template Regeneration** feature lets you quickly refresh an Upgrade Template that has grown stale or needs to reflect new enterprise-specific feedback.
If an existing template sits unused for too long—perhaps due to shifting priorities or postponed upgrades—Chkk
can generate a revised version aligned with the **constantly evolving Cloud Native ecosystem**.
Upon requesting regeneration, Chkk automatically re-analyzes the previous recommendations and publishes an updated
generation of the same template, ensuring you always benefit from the latest guidance.
Regeneration also comes into play when you override recommended versions for certain Cloud Native Projects, application services, and operators
based on internal policies. For example, if your organization requires upgrading all Cloud Native Projects, application services, and operators
to the latest release, you can provide that feedback to Chkk, then use **Template Regeneration** to produce a fresh set of recommendations
that blends your policies with Chkk's research. This way, your upgrade strategy remains consistent with your organization's rules while
still incorporating Chkk's continually refreshed insights.
The **Template Regeneration** option only appears after a user has used the [**Comments**](/features/add-comments) feature to leave a Comment for Chkk.
## Usage
The provided steps also apply to Project Upgrade Templates.
Follow the steps below to **regenerate** an Upgrade Template in the Chkk Dashboard.
1. In the **left-hand column** of the **Chkk Dashboard**, expand **Upgrade Copilot**.
2. Select **Upgrade Templates** -> **Clusters**.
3. Locate the desired **Upgrade Template** that you want to **Regenerate**.
1. Next to the template's entry, click the **Regenerate Template** button.
2. A modal will appear, informing you that the template will become read-only during regeneration.
1. (Optional) Add any relevant details or feedback in the **Additional Notes** field.
2. Click **Regenerate Template** to proceed.
1. A **toast message** will appear, indicating the template regeneration has been requested.
2. Once regeneration is complete, the template can be used or edited again if needed.
# Release Notes Curation
Source: https://docs.chkk.io/features/release-notes-curation
A brief description, use-case, and usage instructions of the Release Notes Curation feature
Chkk's **Release Notes Curation** feature drastically reduces the time spent researching and parsing raw upstream documentation by automatically collating, analyzing, and filtering only the most relevant release notes. Whether you're upgrading clusters, Cloud Native Projects, application services, operators, or the applications running on top of them, Chkk enriches each note with context-specific insights—from breaking changes and API deprecations to critical bug fixes—so your team knows exactly why a particular update matters.
Thanks to Chkk's AI-driven analysis and dedicated research team, these curated notes highlight hidden dependencies and incompatibilities well before they become problems. Where upstream documentation may be ambiguous, Chkk provides clarifying guidance and links back to original sources for those who want deeper details. You'll also find these curated notes integrated directly into your upgrade steps, ensuring you never have to jump between multiple tools or guess which updates warrant attention. By filtering out irrelevant information and spotlighting what truly impacts your environment, Chkk's Release Notes Curation cuts down on research time, reduces uncertainty, and helps teams move faster and more confidently with every upgrade.
# Upgrade Template Request
Source: https://docs.chkk.io/features/request-upgrade-template
A brief description, use-case, and usage instructions of the Upgrade Template Request feature
Chkk's **Upgrade Template Request** feature provides a flexible, preverified plan for upgrading entire clusters, individual Cloud Native Projects, application services, and operators—without scattering crucial details across multiple tools. When you need to upgrade a cluster, you can choose in-place, blue-green, rolling, or even skip versions. For Cloud Native Projects, application services, and operators, simply request an Upgrade Template tailored to that specific component (e.g., Istio v1.20.2). If you're unsure which approach is best, Chkk can recommend an in-place, blue-green, rolling, or custom path based on your environment, internal strategies, and organizational guidelines.
By centralizing all steps and recommendations in a single template, this feature gives teams a **single source of truth** for planning upgrades across multiple clusters, Cloud Native Projects, application services, and operators. You can easily delegate tasks with other Chkk features—such as **Add Comments** and **Add Custom Steps**—to embed internal guidelines, tools, and workflows into every Upgrade Plan. Chkk also uses **Captured Learnings** to track and reapply your organization's proven upgrade practices, ensuring that future templates and plans automatically inherit the same best-practice steps where applicable.
## Usage
Follow the steps below to **Request an Upgrade Template**:
1. In the **Chkk Dashboard**, expand **Upgrade Copilot** on the left menu.
2. Click **Upgrade Templates** and then **Clusters**.
3. You will see a list of all existing **Cluster Upgrade Templates**.
4. On the **Cluster Upgrade Templates** page, locate the **Request Cluster Upgrade Template** button (top-right).
1. Click **Request Cluster Upgrade Template**.
2. From the list presented, choose the **Cluster** that best represents the environment (e.g., dev, prod) for which you want to request a template.
1. Under **Select Upgrade Type**, choose one of the available Upgrade options (e.g., **Pick for me**, **In Place**, **Blue Green**, **Rolling**, etc.).
2. Each option specif ies a different upgrade strategy and approach for your cluster.
3. After selecting the Upgrade Type, you'll be redirected back to the **Cluster Upgrade Templates** page, where your newly requested template will appear with the status: **Waiting for Template**.
1. In the **Chkk Dashboard**, expand **Upgrade Copilot** on the left-hand menu.
2. Click **Upgrade Assessments**.
3. Locate the assessment whose **Status** is **Available**.
1. On the far-right of the assessment row, click the **Actions** dropdown (⋮).
2. Choose **Request Upgrade Template**.
1. The **Request Cluster Upgrade Template** wizard opens with the same cluster pre-selected.
2. *(Optional)* Use **Select Owner** to assign responsibility.
3. Under **Select Blueprint**, pick **Pick for me**, **In Place**, **Blue Green**, or **Rolling**—exactly as you would in a normal template request.
1. Click **Request Cluster Upgrade Template** to submit.
2. You'll be redirected to **Upgrade Templates → Clusters**, where the new entry shows **Waiting for Template**.
3. When generation completes, the status changes to **Available** and you can open the template just like any other.
1. In the **Chkk Dashboard**, expand **Upgrade Copilot** on the left menu.
2. Click **Upgrade Templates** and then **Projects**.
3. You will see a list of all existing **Project Upgrade Templates**.
4. On the **Project Upgrade Templates** page, locate and click the **Request Project Upgrade Template** button (top-right).
1. From the list of Cloud Native Projects, choose the instance that most accurately represents all of the other Cloud Native Project instances across your fleet.
2. This Cloud Native Project instance will be used to generate the upgrade template.
1. Review your selected Cloud Native Project details (e.g., tag, cluster, etc.).
2. Click **Request Project Upgrade Template** to finalize your request.
3. You'll be redirected back to the **Project Upgrade Templates** page, where your newly requested template will appear with the status: **Waiting for Template**.
# Upgrade Guidance
Source: https://docs.chkk.io/features/upgrade-guidance
A brief description, use-case, and usage instructions of the Upgrade Guidance feature
Chkk's **Upgrade Guidance** feature removes guesswork from each Upgrade Template by specifying which Cloud Native Projects, application services, and operators need upgrading—and which are optional—alongside clear, environment-specific instructions. Chkk highlights important breaking changes, configuration updates, and any key considerations, simplifying raw release notes with concise, curated explanations.
For each Cloud Native Project, application service, and operator, you'll also see a **Helm chart values diff**, annotated to clarify new or removed configurations and their impact. Chkk then provides tailored upgrade steps based on the tools and configurations you use—be it Helm, Argo CD, managed EKS node groups, Karpenter, or custom setups. By embedding this directly in your Upgrade Templates, Chkk saves you hours of manual research and trial-and-error, helping you roll out upgrades with ease and confidence.
# Upgrade Preverification
Source: https://docs.chkk.io/features/upgrade-preverification
A brief description, use-case, and usage instructions of the Upgrade Preverification feature
Chkk's **Upgrade Preverification** checks every aspect of your prospective upgrade before publishing an Upgrade Template, ensuring that all recommended steps are valid, safe, and ready for production. By analyzing release notes, Helm charts, CRDs, and more, Chkk identifies potential pitfalls and includes any necessary remediation steps directly in the template.
A key part of this process is the use of a **Digital Twin** of your representative cluster—a one-to-one replica that simulates real conditions and Cloud Native Project configurations. Alongside these simulations, Chkk runs pre-flight and post-flight checks to confirm health, safety, and functionality at each stage of the upgrade. If blockers or compatibility gaps are found, you'll see targeted fixes and workarounds embedded in the final Upgrade Template.
By surfacing problems early and providing explicit solutions, **Upgrade Preverification** frees your team from guesswork and time-consuming troubleshooting during live upgrades. Instead, you get clear, real-world tested instructions that streamline upgrades across your environment.
# Upgrade Template/Plan Ownership
Source: https://docs.chkk.io/features/upgrade-template-plan-ownership
A brief description, use-case, and usage instructions of the Upgrade Template/Plan Ownership feature
Chkk's Upgrade Template/Plan Ownership feature enables teams to assign clear responsibility to an individual for any Upgrade Template or Upgrade Plan. When an owner is assigned to a Template, only that person can approve it, ensuring that approval remains a single-threaded decision. Once approved, the owner is automatically carried forward to the Upgrade Plan that gets instantiated from that Template, though this can be changed as needed. Upgrade Plans can be marked as completed by any team member, regardless of who the owner is.
This feature supports reliable governance across teams that manage specific areas of platform infrastructure—such as service mesh, observability, networking, or IAM—by providing a mechanism to assign accountability for upgrade readiness. Ownership helps streamline approvals, support smoother handoffs during staffing transitions, and maintain continuity in large or distributed teams. If no owner is assigned, the approval process remains open to all users. Ownership can also be reassigned at any time, allowing teams to adapt quickly to changes without interrupting upgrade workflows.
## Usage
Follow the steps below to assign, re-assign, or remove an **Owner** for Upgrade Templates and Upgrade Plans:
This workflow applies to both Cluster and Project Upgrade Templates.
1. In the **left-hand column** of the **Chkk Dashboard**, expand **Upgrade Copilot → Upgrade Templates** and select either **Clusters** *or* **Projects**. Click **Request Upgrade Template**.
2. Choose the **representative resource** (cluster for Cluster templates, Project instance for Cloud Native Project templates) that will be used to generate the template.
3. In **Select Owner**, use the **search** bar to select an owner or choose **Owner Not Required** to leave the template ownerless.
4. Complete the remaining fields (Upgrade Type, etc.) and click **Request Upgrade Template**.
5. You'll be redirected back to the **Cluster** *or* **Project** **Upgrade Templates** view, where your newly requested template will be visible with the chosen owner shown in the **Owner** column.
This workflow applies to Cluster Upgrade Templates, Project Upgrade Templates, Cluster Upgrade Plans, and Project Upgrade Plans.
1. Navigate to **Upgrade Copilot → Upgrade Templates** and open the **Clusters** or **Projects** tab, depending on which template you need to modify.
2. Locate the desired **Upgrade Template** and click the **︙ (three-dots)** menu at the far right of its row.
3. Click on the **search** bar next to the **Change Owner** field to select a new owner or pick **Owner Not Required** to clear the field.
4. The table refreshes automatically, and the **Owner** column now reflects the updated value (or is blank if no owner is set).
# IaC Repo Field Guide
Source: https://docs.chkk.io/operations/iac-repo-patterns
Taxonomy of Helm, Kustomize, Terraform, Pulumi, and GitOps Patterns
### Forked Helm Chart (a.k.a. *Vendored Chart*)
* **What it is:** Copy the entire upstream chart into your repo; commit your own `values.yaml` (and sometimes template tweaks) in place. Upgrades are manual git merges from upstream.
* **Why teams pick it:** *Absolute control.* You can patch templates, lock dependencies, and vendor images. Regulated orgs like banks love this because every rendered manifest lives in their audit boundary.
* **Watch‑outs:** Upstream moves fast; your fork ages. Without automation, merges become thankless archaeology sessions.
### Helm Umbrella / Wrapper Chart
* **What it is:** Publish a thin “meta” chart that declares upstream charts as dependencies and ships a curated `values.yaml`. At deploy time, Helm pulls child charts from the registry.
* **Why teams pick it:** Centralizes *opinionated defaults* (network policy, storage class, TLS settings) while tracking upstream semantically—just bump the version pin. Keeps chart sources *out* of your repo, shrinking diff noise.
* **Watch‑outs:** Debugging flows through two layers of values. Newcomers often ask, “Which chart owns this resource?”—documentation matters.
### Kustomize Base + Overlay
* **What it is:** Common manifests live in a `base/` directory. Environment overlays (`overlays/dev`, `overlays/prod`, etc.) patch the base via strategic‑merge or JSON patches.
* **Why teams pick it:** *Zero templating.* Kustomize stays in pure YAML, aligns with “plain‑K8s‑manifest” purists, and keeps diffs minimal across environments.
* **Watch‑outs:** Large overlay hierarchies get deep—and brittle. Patching complex CRDs can be painful (looking at you, Istio).
### GitOps Monorepo
* **What it is:** One repo—often named `infra-live`—contains every cluster, environment, and app manifest. Argo CD / Flux watches sub‑paths.
* **Why teams pick it:** *Single source of truth.* Atomic PRs span environments; new developers grep once to find everything.
* **Watch‑outs:** Repo size explodes, CI gets chatty, and RBAC granularity is blunt (write access to prod YAML equals prod permissions). At \~50 engineers, most orgs feel the pain.
### Polyrepo Topologies
* **What it is:** *(Repo‑per‑team, Repo‑per‑app, or Repo‑per‑env)*
Split GitOps config across multiple repos. Security, networking, and each product team may own their own repo; prod sometimes earns a dedicated one.
* **Why teams pick it:** Maps cleanly to Conway’s Law and access control—platform SREs can approve cluster‑wide changes without granting frontend devs prod keys.
* **Watch‑outs:** Cross‑cutting upgrades (e.g., bumping Kubernetes minor) require N PRs. Consistency drifts unless you automate global migrations.
### Argo CD *App‑of‑Apps*
* **What it is:** A root Argo `Application` CR points at a folder of child `Application` CRs. Sync the root once; Argo instantiates the stack.
For bulk generation of child Applications, this is typically paired with `ApplicationSets` (e.g., [matrix](https://argo-cd.readthedocs.io/en/latest/operator-manual/applicationset/Generators-Matrix/) over clusters or services); App-of-Apps still handles composition/order.
* **Why teams pick it:** Cluster bootstrapping. Day‑0 you apply a single YAML and watch the platform assemble itself (ingress, cert manager, observability stack…).
* **Watch‑outs:** Two abstraction layers mean two places to misconfigure sync options. Disaster recovery docs must cover restoring both root and children.
### **ArgoCD *ApplicationSets* (Generator-Driven GitOps)**
* **What it is:** Author one ApplicationSet that emits many Argo CD Applications from generators (Git dirs, cluster list, matrix). The controller keeps the set in sync—add/remove a directory or cluster and the corresponding Applications appear/disappear.
For orchestration/dependencies across generated apps, the logic generally resides in the Applications or a parent App-of-Apps.
* **Why teams pick it:** Scales deployments across N environments/clusters/microservices without hand-writing N Application YAMLs. Plays nicely with both monorepos and polyrepos; reduces boilerplate and drift.
* **Watch-outs:** It generates apps; it doesn’t orchestrate dependencies—use sync waves/health gates in the generated apps. Review security if allowing teams to contribute to generators that create apps in the Argo CD namespace.
### **Programmatic IaC (Pulumi / CDK / Terraform CDK)**
* **What it is:** Define infra in TypeScript, Go, Python, or C#. Repos resemble regular software: `src/`, unit tests, modules. Deploy via `pulumi up` or `cdk deploy`.
* **Why teams pick it:** Loops, conditionals, and strongly‑typed components enable *true* code reuse (think: `for env in envs`). IDE autocompletion beats stringly‑typed YAML.
* **Watch‑outs:** Engineers must grok both the cloud provider and the SDK. Stateful back‑end (Pulumi stack or TF state) needs rigorous locking in CI.
### Micro‑Stacks / Project‑per‑Domain (Programmatic IaC Variant)
* **What it is:** Break a large Pulumi/Terraform CDK project into multiple smaller projects, each with its own state file. Network, database, and app infra evolve independently.
* **Why teams pick it:** Safer blast radius. A database change can roll out without risking the VPC. Also shortens preview times in CI.
* **Watch‑outs:** Inter‑stack dependencies become API contracts—publish outputs, import IDs, or wire them with Crossplane or Parameter Store.
### Kubernetes Operator Packaging
* **What it is:** Ship automation as a controller + CRD bundle (via Helm, OLM, or plain YAML). Ops teams deploy the operator once; developers create CRs to get complex services.
* **Why teams pick it:** Encapsulates *day‑2 logic*. Backups, fail‑over, and upgrades live inside the operator code instead of fragile Bash.
* **Watch‑outs:** You now depend on the operator’s maturity. Debugging a controller bug is harder than tailing a Pod log.
### Crossplane Composition (*Platform API* Pattern)
* **What it is:** Platform engineers author high‑level CRDs (e.g., `CompositeDatabase`) and map them to cloud primitives via Crossplane `Composition` templates. Developers request infra by committing YAML.
* **Why teams pick it:** Self‑service without giving devs cloud console keys. Enforces guardrails and tagging in one place.
* **Watch‑outs:** Operator team now owns a mini‑PaaS. Versioning compositions and breaking changes requires governance.
### **Grafana Tanka (Jsonnet-based Pattern)**
* **What it is:** A configuration tool using Jsonnet and the tk CLI to generate manifests. Supports rich abstractions, environment handling (dev/prod), and exact diffing before deployment.
* **Why teams pick it:** Much more concise than YAML or templated manifests; promotes library reuse; built‑in tk diff offers confidence in changes; and hermetic builds ensure deploy reproducibility.
* **Watch‑outs:** Jsonnet adds a learning curve; managing secrets is external to Tanka; and finding/managing Jsonnet libraries (like k8s‑libsonnet) can be awkward.
# Support and Compatibility
Source: https://docs.chkk.io/overview/support-compatibility
An overview of the cloud providers, Kubernetes distributions, Cloud Native Projects, Application Services, and Operators that Chkk supports
## Cloud Providers
Amazon Web Services
Google Cloud Platform
Microsoft Azure
***
## Kubernetes Providers
Amazon Elastic Kubernetes Service
Google Kubernetes Engine
Azure Kubernetes Service
Enterprise-grade Kubernetes powered by VMware.
Red Hat's Kubernetes platform.
Kubernetes distributions from Rancher.
Enterprise-grade Kubernetes powered by Nutanix.
Self-installed vanilla Kubernetes.
Fully on-premises Kubernetes deployments.
***
## Cloud Native Projects, Application Services, and Operators
Chkk provides coverage for 100s of Cloud Native Projects, application services, and operators—such as Istio, Cilium, NGINX Ingress Controller, Cert-Manager, Vault Secrets Operator and more. For each one, Chkk offers:
* Curated Release Notes
* Preflight/Postflight Checks (Safety, Health, and Readiness)
* End-Of-Life (EOL) Information
* Version Incompatibility Information
* On-demand, contextualized Upgrade Templates (In-Place, Blue-Green)
* Detection of Custom Built Images and Packages (Helm, Kustomize, Static Manifests etc)
* Preverification
# Overview
Source: https://docs.chkk.io/product/artifact-register/overview
Inventory of everything in a Cloud Native fleet
Chkk Artifact Register maintains an inventory of all components, container images, repositories, and tools across multiple clusters and clouds. It gives you visibility into what exists where, reducing the need for manual and error-prone tracking using spreadsheets and scripts that you currently use.
Platform, DevOps, and SRE Teams use Artifact Register to:
* Stay up to date with visibility across all infrastructure layers.
* Consolidate insights across clouds, on-prem, and edge.
* Get alerted about all EOL and incompatible versions.
* Avoid maintaining internal spreadsheets or custom scripts to manage Kubernetes components' inventory.
# Bitnami Alternatives Finder
Source: https://docs.chkk.io/product/chkkcli/bitnami
Identify alternatives for Bitnami-produced Docker images and Helm Charts
Effective September 29, 2025 Broadcom is restructuring distribution:
**production-grade** images and continued **chart updates** are provided under
**Bitnami Secure Images** (commercial), the **free** tier offers a limited set
of **latest-tag** hardened images for development, and **older/versioned**
images are archived to **Bitnami Legacy** and no longer maintained.
This change removes free access to most versioned images and halts updates to
already-packaged charts, breaking image and chart pulls unless repositories
are updated.
To assist users in remediating this risk, Chkk has published a
collection of known alternative Docker images and Helm Charts at
[chkk-io/bitnami-alternatives](https://github.com/chkk-io/bitnami-alternatives)
public source code repository.
The `chkk bitnami` command detects Bitnami artifacts running in a
cluster and lists known alternative artifacts.
The `chkk bitnami` command **does not require a Chkk account or login**.
[Download](https://docs.chkk.io/overview/installation#chkk-cli) the `chkk` CLI
tool and run `chkk bitnami`. The command will then ask you to select one or
more Kubernetes Clusters in which to detect Bitnami Docker images and Helm
Charts:
```
$ chkk bitnami
Found 1 total Kubernetes Clusters in your kubeconfig.
Use the arrow keys to navigate: ↓ ↑ → ← and / toggles search
Select the clusters in which to detect Bitnami Docker images and Helm Charts. Select "Submit" to submit choices.
→ Submit
kind-bitnami-demo (https://127.0.0.1:40081)
```
Once you have used the arrow keys to select the Clusters to inspect,
arrow up to the Submit line and hit Enter.
```
$ chkk bitnami
Found 1 total Kubernetes Clusters in your kubeconfig.
You made the following 1 selections:
1: kind-bitnami-demo (https://127.0.0.1:40081)
Are you sure you want to submit these? Enter 'n' to select again. (Y/n)
```
We will ask you to confirm your selected clusters. Hit Enter again to do so and
`chkk bitnami` will display any detected Bitnami artifacts and list any known
alternatives:
```
3 unique Bitnami Docker images detected in cluster "kind-bitnami-demo"
───────────────────────────────────────────────────────────────────────────────────────────────────
DOCKER.IO/BITNAMILEGACY/ARGO-CD:3.1.1-DEBIAN-12-R0
───────────────────────────────────────────────────────────────────────────────────────────────────
┌───────────────────┬────────────┬───────────┬───────────────────────────────┐
│ CLUSTER │ KIND │ NAMESPACE │ RESOURCE NAME │
├───────────────────┼────────────┼───────────┼───────────────────────────────┤
│ kind-bitnami-demo │ Deployment │ default │ argocd-argo-cd-app-controller │
│ kind-bitnami-demo │ Deployment │ default │ argocd-argo-cd-repo-server │
│ kind-bitnami-demo │ Deployment │ default │ argocd-argo-cd-server │
└───────────────────┴────────────┴───────────┴───────────────────────────────┘
⚠️ bitnamilegacy: archived/versioned images — no updates or support; security risk; temporary migration fallback only
Bitnami catalog: deletion Sep 29, 2025 - transient pull failures now; persistent failures after.
✅ Found 2 alternative images:
- docker.io/argoproj/argocd
- quay.io/argoproj/argocd
🔍 Detected: Project is installed via Helm.
✅ Found 5 alternative Helm charts:
- https://argoproj.github.io/argo-helm/argo-cd
- https://mesosphere.github.io/charts/stable/argo-cd
- https://charts.wener.tech/argo-cd
- https://charts.kubegems.io/kubegems/argo-cd
- https://marketplace.azurecr.io/helm/v1/repo/argo-cd
───────────────────────────────────────────────────────────────────────────────────────────────────
DOCKER.IO/BITNAMI/REDIS:8.2.1-DEBIAN-12-R0
───────────────────────────────────────────────────────────────────────────────────────────────────
┌───────────────────┬─────────────┬───────────┬─────────────────────┐
│ CLUSTER │ KIND │ NAMESPACE │ RESOURCE NAME │
├───────────────────┼─────────────┼───────────┼─────────────────────┤
│ kind-bitnami-demo │ StatefulSet │ default │ argocd-redis-master │
└───────────────────┴─────────────┴───────────┴─────────────────────┘
⚠️ Bitnami catalog: deletion Sep 29, 2025 - transient pull failures now; persistent failures after.
✅ Found 8 alternative images:
- docker.io/library/redis
- public.ecr.aws/ubuntu/redis
- gcr.io/google-containers/redis
- us.gcr.io/google-containers/redis
- asia.gcr.io/google-containers/redis
- eu.gcr.io/google-containers/redis
- public.ecr.aws/anomalo/tools/redis
- quay.io/akuity/redis
🔍 Detected: Project is installed via Helm.
❌ No alternative Helm charts found.
───────────────────────────────────────────────────────────────────────────────────────────────────
DOCKER.IO/BITNAMI/MYSQL:9.4.0-DEBIAN-12-R1
───────────────────────────────────────────────────────────────────────────────────────────────────
┌───────────────────┬─────────────┬───────────┬───────────────┐
│ CLUSTER │ KIND │ NAMESPACE │ RESOURCE NAME │
├───────────────────┼─────────────┼───────────┼───────────────┤
│ kind-bitnami-demo │ StatefulSet │ default │ mysql │
└───────────────────┴─────────────┴───────────┴───────────────┘
⚠️ Bitnami catalog: deletion Sep 29, 2025 - transient pull failures now; persistent failures after.
✅ Found 13 alternative images:
- docker.io/mysql
- public.ecr.aws/docker/library/mysql
- public.ecr.aws/ubuntu/mysql
- docker.io/circleci/mysql
- docker.io/ubuntu/mysql
- docker.io/cimg/mysql
- docker.io/rapidfort/mysql
- docker.io/linuxserver/mysql
- docker.io/docksal/mysql
- public.ecr.aws/lts/mysql
- public.ecr.aws/runecast/mysql
- docker.io/elestio/mysql
- docker.io/rapidfort/mysql-official
🔍 Detected: Project is installed via Helm.
✅ Found 1 alternative Helm chart:
- https://marketplace.azurecr.io/helm/v1/repo/mysql
```
## Additional Resources
**Glossary of Terms**
| Term | Definition |
| ------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **OCI Helm chart** | A Helm chart packaged and distributed as an OCI artifact (e.g., `oci://registry-1.docker.io/bitnamicharts/`). |
| **Bitnami Legacy** | A Docker Hub organization (`docker.io/bitnamilegacy`) that archives older/versioned Bitnami images with **no updates**; intended only for **temporary** migration. |
| **Bitnami Secure Images (BSI)** | Broadcom's commercial offering with hardened, continuously rebuilt images and maintained Helm charts, plus SBOM/VEX, compliance artifacts, and support. |
| **Free community tier** | A limited subset of **latest-tag** hardened images available for development use; not a production support channel. |
**References**
* [Broadcom Introduces Bitnami Secure Images](https://news.broadcom.com/app-dev/broadcom-introduces-bitnami-secure-images-for-production-ready-containerized-applications)
* [Upcoming changes to the Bitnami catalog](https://github.com/bitnami/charts/issues/35164)
* [Docker Hub — bitnamilegacy](https://hub.docker.com/u/bitnamilegacy)
* [Docker Hub — bitnamisecure](https://hub.docker.com/u/bitnamisecure)
# Cluster Resource Classification
Source: https://docs.chkk.io/product/chkkcli/cluster-resource-classification
Help Chkk classify Cloud Native Projects and Application Services running in your clusters
Chkk uses multiple methods of [Classification](/overview/technology#classification) to identify cluster resources. If Chkk is unable to determine what a resource is or how the resource has been deployed, the resource is marked as **unclassified**.
Reasons why Chkk may not be able to classify a cluster resource include:
* The resource deploys a project that is **not currently supported** by Chkk. Coverage extension may be requested (48hr premium SLA).
* The resource is part of an internal [Application](/resources/glossary#application) that should be ignored.
* Custom build processes or packaging may result in Docker image names and tags that Chkk cannot match to its [Knowledge Graph](/overview/understanding-chkk#knowledge-graph)
## Annotating Resources Manually
Cluster resources can be classified by adding the following annotations:
**Ignore a resource**: Add the annotation `chkk.io/classify=ignore` to tell Chkk to ignore the resource. Chkk recommends to add this annotation to any internal applications.
**Package**: Use the `chkk.io/package` annotation to specify a **Package identifier**. A Package identifier can be a Helm Chart URL, an OCI Repository URI, a source URL to a Kubernetes manifest, a Chkk Package UUID or a Chkk Package Alias.
**Package Version**: Use the `chkk.io/package-version` annotation to specify a **Package Version**. For Helm Charts, the package version must be a SemVer2-compatible version string. For manifests use the release tag of the source code project where the manifests are sourced.
**Project**: Use the `chkk.io/project` annotation to specify a **Project Identifier**. A Project Identifier can be a Docker/OCI repository URL, source code repository URL, Chkk Project UUID or Chkk Project Alias.
**Project Version**: Use the `chkk.io/project-version` annotation to specify the **Project Version**. A Project Version is either the release tag for the Project's source code or the Docker/OCI image tag associated with the Project's primary component.
As an example, assume you have a custom image build system that has rebuilt the Cert Manager Docker images and pushed tags to your private artifact repository. Chkk is unable to determine which release of Cert Manager your Docker images are associated with and cluster resources are marked unclassified. You can add the following annotations to tell Chkk exactly what version of Cert Manager and the Cert Manager Helm Chart you are using:
```
kind: Deployment
metadata:
annotations:
chkk.io/package: charts.jetstack.io/cert-manager
chkk.io/package-version: v1.14.4
chkk.io/project: cert-manager
chkk.io/project-version: v1.14.4
```
To tell Chkk to ignore a resource during classification, add the following annotation:
```
kind: Deployment
metadata:
annotations:
chkk.io/classify=ignore
```
## Annotating Resources via CLI
First run a cluster scan and request an upgrade assessment [here](/product/chkkcli/overview#quick-start)
Type `chkk cluster classify` in your terminal and select the cluster on which to perform custom image mapping
```text theme={"dark"}
$ chkk cluster classify
Starting interactive resource classification workflow...
Step 1: Select a Kubernetes cluster
eks-dev-1 (v1.33.1) (EKS)
✔ eks-prod-1 (v1.32.5) (EKS)
eks-stg-1 (v1.32.5) (EKS)
You selected "eks-prod-1 (v1.32.5) (EKS)". Is this correct? Enter 'n' to select again. (Y/n) y
Selected cluster: eks-prod-1 (k8scl_823b4agd-a784-4232-8670-10aple0281af)
```
Use the arrow keys to select all unclassified resources for classification. Selected resources may also be individually marked as ignored.
```text theme={"dark"}
Step 2: Select resources to classify
Fetching unclassified resources...
Found 4 unclassified resources.
Matching unclassified resources with cluster resources...
Select resources to classify:
Use the arrow keys to navigate: ↓ ↑ → ← and / toggles search
Select unclassified resources to classify. Select "Submit" to submit choices.
→ Submit
✔ Daemonset/log-collector (ns: monitoring)
Deployment/auth (ns: app-svc)
✔ Deployment/cm-controller (ns: cert)
✔ Deployment/cm-webhook (ns: cert)
✔ Deployment/cm-cainjector (ns: cert)
Deployment/login-ui (ns: app-svc)
Statefulset/cache (ns: app-db)
Statefulset/storage (ns: app-db)
You made the following 4 selections:
1: Daemonset/log-collector (ns: monitoring)
2: Deployment/cm-controller (ns: cert)
3: Deployment/cm-webhook (ns: cert)
4: Deployment/cm-cainjector (ns: cert)
Are you sure you want to submit these? Enter 'n' to select again. (Y/n)
```
(Optional) Mark all remaining resources to be ignored.
```text theme={"dark"}
There are 4 remaining unclassified resources that you didn't select.
Would you like to mark these remaining resources as ignored? (y/N)
```
(Optional) Any resources selected for classification may be individually marked as ignored:
```text theme={"dark"}
Step 4: Classify selected resources
───────────────────────────────────────────────────────────────────────────────────
RESOURCE 1 OF 4
───────────────────────────────────────────────────────────────────────────────────
Kind: Daemonset
Name: log-collector
Namespace: monitoring
───────────────────────────────────────────────────────────────────────────────────
Do you want to classify this resource? (Daemonset/log-collector) (Y/n) n
Would you like to mark Daemonset/log-collector (ns: monitoring) as ignored? (y/N) y
Marked Daemonset/log-collector as ignored
```
Any resources marked as ignored will automatically apply the `chkk.io/classify=ignore` to the resource manifest. This resource will no longer show up as unclassified.
To classify any resource, up to 5 different classification annotations may be applied:
**1. Package**
Package identifier (Helm chart URL, or package source URL) e.g.
* oci://registry-1.docker.io/bitnamicharts/cert-manager
* charts.jetstack.io/cert-manager
* github.com/cert-manager/cert-manager/tree/master/deploy/charts/cert-manager
```text theme={"dark"}
Package
(optional) Enter value for Package (leave empty to skip)
charts.jetstack.io/cert-manager
```
**2. Package Version**
Package version (Helm Chart's Chart.Version or, if not a Helm Chart, the release tag/name of the source code project where the package's artifacts are pulled)
```text theme={"dark"}
Package Version
(optional) Enter value for Package Version (leave empty to skip)
v1.14.4
```
**3. Project**
Primary Project (Docker/OCI repository URL or source code repository URL) e.g.
* cert-manager
* quay.io/jetstack/cert-manager-controller
* docker.io/bitnami/cert-manager
* github.com/cert-manager/cert-manager
```text theme={"dark"}
Project
(optional) Enter value for Project (leave empty to skip)
cert-manager
```
**4. Project Version**
Primary project version
```text theme={"dark"}
Project Version
(optional) Enter value for Project Version (leave empty to skip)
v1.14.4
```
**5. Deployment System**
Deployment tool used to deploy this resource e.g. helm., kubectl, argocd, flux
```text theme={"dark"}
Deployment System
(optional) Enter value for Deployment System (leave empty to skip)
helm
```
Submit the custom annotations to Chkk.
```text theme={"dark"}
Summary for Deployment/cm-controller:
Package Version: v1.14.4
Deployment System: helm
Submit classification data for Deployment/cm-controller? (Y/n)
Successfully classifed Deployment/cm-controller
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
✅ CLASSIFICATION COMPLETE!
Total resources: 4
Successfully classified: 3
Ignored: 1
Skipped: 0
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Successfully classified resources.
```
Submit the classified resources to Chkk.
```text theme={"dark"}
Would you like to submit the classified resources to Chkk for analysis? (This will run 'chkk cluster collect') (Y/n) y
✅ cluster "minikube" resource collection successful. 52 resource groups collected.
To view information about your cluster, do:
chkk cluster get k8scl_823b4abd-a954-4992-8670-10aaee0781af
✅ Cluster resources collected and submitted to Chkk successfully!
```
Execute `chkk upgradeassessment request
Would you like to request a new upgrade assessment for this cluster? (y/N) y
(optional) enter the name for the upgrade assessment
eks-prod-1-ua-2
✅ request for upgrade assessement for cluster "k8scl_823b4abd-a954-4992-8670-10aaee0781af" successful.
completed!
```
Execute `chkk upgrade assessment get ` to view the upgrade assessment and observe recommendations for any newly classified resources:
```text theme={"dark"}
chkk upgradeassessment get ua_548e6f64-b25a-40e4-b868-2146c46489d2
...
## Add-ons & Application Services Marked for Upgrade
Name │ Namespace(s) │ Current │ Upgrade │ Suggested │ Supported │ K8s … │ Age < 2yr
──────────────┼────────────────┼───────────┼──────────┼───────────┼─────────────────────────────────────────────────────────────────────────────────┼───────┼───────────
cert-manager │ cert │ v1.14.4 │ v1.18.2 │ Optional │ ❌ (Version 1.14 left upstream maintenance on 3 Oct 2024 and no longer receives │ ✅ │ ✅
...
```
# Overview
Source: https://docs.chkk.io/product/chkkcli/overview
A developer-first terminal UI to explore the Chkk universe
The `chkk` command-line interface (CLI) offers a developer-first way to explore
the Chkk universe.
## Install
Install a pre-built binary on Linux using the following instructions.
```bash theme={"dark"}
# For AMD64 / x86_64
[ $(uname -m) = x86_64 ] && curl -Lo ./chkk https://cli.chkk.io/download/latest/chkk-linux-amd64
# For ARM64
[ $(uname -m) = aarch64 ] && curl -Lo ./chkk https://cli.chkk.io/download/latest/chkk-linux-arm64
chmod +x ./chkk
sudo mv ./chkk /usr/local/bin/chkk
```
Or using Brew.
```bash theme={"dark"}
brew install chkk-io/cli/chkk
```
Install using Homebrew on MacOS.
```bash theme={"dark"}
brew install chkk-io/cli/chkk
```
Or install a pre-built binary using the following instructions.
```
# For Intel Macs
[ $(uname -m) = x86_64 ] && curl -Lo ./chkk https://cli.chkk.io/download/latest/chkk-darwin-amd64
# For M1 / ARM Macs
[ $(uname -m) = arm64 ] && curl -Lo ./chkk https://cli.chkk.io/download/latest/chkk-darwin-arm64
chmod +x ./chkk
mv ./chkk /some-dir-in-your-PATH/chkk
```
Install a pre-built binary on Windows in PowerShell.
```
curl.exe -Lo chkk-windows-amd64.exe https://cli.chkk.io/download/latest/chkk-windows-amd64
Move-Item .\chkk-windows-amd64.exe c:\some-dir-in-your-PATH\chkk.exe
```
## Quick Start
The `chkk start` command will get you started in the Chkk universe.
The command will lead you through registering one or more clusters
with Chkk and request a Chkk upgrade assessment for those registered
clusters.
Registering a cluster with Chkk is the process of collecting
resources from the cluster and submitting those collected results to
Chkk.
Type `chkk start` in a terminal to begin.
```text theme={"dark"}
> chkk start
__ __ __
.----| |--| |--| |--.
| __| | <| <
|____|__|__|__|__|__|__|
Welcome to Chkk!
This command will help you get started with Chkk.
It will guide you through the process of logging in to your Chkk account and
registering any Kubernetes Clusters if desired.
You may also request an upgrade assessment for any of your registered Kubernetes
Clusters.
────────────────────────────────────────────────────────────────────────────────────────────────────────
Let's get you logged in to your Chkk account.
please confirm the code LCZS-DKDB at https://auth.chkk.io/activate?user_code=LCZS-DKDB
```
Click on the link and a browser window will appear asking you to confirm a
code.
### Register a Cluster
**After clicking "Confirm"**, in your terminal you will see a successful login
message and a prompt to register a cluster with Chkk:
```
successfully logged in as "Jane Doe" (jane.doe@example.com) into organization "demo-org" (org_3c2732f7-9328-477d-910b-54cd94ade5c0).
Do you want to register any Kubernetes Clusters with Chkk? (Y/n)
```
**Hit Enter or "Y"** to start the registration process. We will look in your
kubeconfig for Cloud Native Clusters and ask you to select one or more of those
Kubernetes Clusters to register with Chkk.
```
Found 1 total Kubernetes Clusters in your kubeconfig.
Select the clusters you would like to register. Resources from the selected
clusters will be collected and submitted to Chkk for analysis.
Use the arrow keys to navigate: ↓ ↑ → ←
Select "Submit" to submit choices.
Submit
→ ✔ kind-charlie (https://127.0.0.1:39775)
```
Use the arrow keys to navigate, **hit Enter to select one or more** of the
clusters and navigate up to the Submit line and hit Enter again.
We will ask you to confirm your selection:
```
You made the following 1 selections:
1: kind-charlie (https://127.0.0.1:39775)
Are you sure you want to submit these? Enter 'n' to select again. (Y/n)
```
**Hit Enter or "Y" to collect resources** from the selected clusters and
register them with Chkk.
```
Registering 1 Kubernetes Cluster(s) with Chkk...
registering kind-charlie (https://127.0.0.1:39775)...
✅ cluster "kind-charlie" resource collection successful. 49 resource groups collected.
To view information about your cluster, do:
chkk cluster get k8scl_13673ce4-1cbd-454a-aa31-67b722fadc99
```
**Your newly-registered** cluster will then be displayed along with a
prompt asking if you would like to request a Chkk upgrade assessment for this
cluster:
```
The following 1 Kubernetes Clusters are active in your Chkk account:
┌────────────────────────────────────────────┬──────────────┬────────┬─────────────┬──────────┬──────────────┬──────────┐
│ ID │ NAME │ STATUS │ ENVIRONMENT │ PROVIDER │ KUBE VERSION │ # NODES │
├────────────────────────────────────────────┼──────────────┼────────┼─────────────┼──────────┼──────────────┼──────────┤
│ k8scl_13673ce4-1cbd-454a-aa31-67b722fadc99 │ kind-charlie │ active │ │ KinD │ 1.28 │ 2 │
└────────────────────────────────────────────┴──────────────┴────────┴─────────────┴──────────┴──────────────┴──────────┘
showing 1-1 of 1 records.
Would you like to request an upgrade assessment for any of these Kubernetes Clusters? (Y/n)
```
### Request an Upgrade Assessment
A Chkk upgrade assessment is a report that alerts you to potential issues with
an upgrade of your cluster and recommends upgrade versions for your
Cloud Native Projects and Application Services.
**Hit Enter or "Y"** to select one or more clusters for an upgrade
assessment.
```
Use the arrow keys to navigate: ↓ ↑ → ←
? Select a cluster to request an upgrade assessment for:
▸ kind-charlie (1.28) (KinD)
```
select a cluster and hit Enter.
```focus={1,6-7} theme={"dark"}
You selected "kind-charlie (1.28) (KinD)". Is this correct? Enter 'n' to select again. (Y/n)
Requesting upgrade assessment for kind-charlie (1.28) (KinD)...
(required) enter the name for the upgrade assessment
charlie
✅ request for upgrade assessement for cluster "k8scl_13673ce4-1cbd-454a-aa31-67b722fadc99" successful.
... waiting for upgrade assessment to complete. this will take a few minutes ...
```
The upgrade assessment will take a few minutes to generate and then you will see:
```focus={5,7} theme={"dark"}
completed!
To view your upgrade assessment, do:
chkk upgradeassessment get ua_a59a7fff-f3c2-4443-9f26-fe97cd187def
Learn more about Chkk upgrade assessments at: https://docs.chkk.io/product/upgrade-copilot/assessments
```
### View an Upgrade Assessment
You can view the upgrade assessment in your terminal using the `chkk
upgradeassessment get` command:
```focus={1,5,7-9} expandable theme={"dark"}
> chkk upgradeassessment get ua_a59a7fff-f3c2-4443-9f26-fe97cd187def
────────────────────────────────────────────────────────────────────────────────────────────────────────
ID: ua_a59a7fff-f3c2-4443-9f26-fe97cd187def
NAME: charlie
CLUSTER: k8scl_13673ce4-1cbd-454a-aa31-67b722fadc99
STATUS: ready
DESIRED VERSION: 1.29
UPGRADE STRATEGY: in-place
────────────────────────────────────────────────────────────────────────────────────────────────────────
REQUESTED BY
────────────────────────────────────────────────────────────────────────────────────────────────────────
USER ID: usr_c7081c76-7e9a-4e38-bbbd-0c7ba9722fa7
EMAIL: jane.doe@example.com
NAMES: Jane Doe
────────────────────────────────────────────────────────────────────────────────────────────────────────
REPORT
────────────────────────────────────────────────────────────────────────────────────────────────────────
1 Upgrade Assessment - charlie
────────────────────────────────────────────────────────────────────────────────────────────────────────
ID: ua_a59a7fff-f3c2-4443-9f26-fe97cd187def
Requested: 30 Jul 25 15:03 UTC by Jane Doe
────────────────────────────────────────────────────────────────────────────────────────────────────────
1.1 Metadata
┌──────────────────────────────┬─────────────┐
│ │ │
╞══════════════════════════════╪═════════════╡
│Cluster Name (Chkk) │kind-charlie │
├──────────────────────────────┼─────────────┤
│Current │1.28 │
├──────────────────────────────┼─────────────┤
│Recommended │1.29 │
├──────────────────────────────┼─────────────┤
│Provider │K8s │
├──────────────────────────────┼─────────────┤
│Region │local │
├──────────────────────────────┼─────────────┤
│Node Groups │0 │
├──────────────────────────────┼─────────────┤
│Nodes │2 │
├──────────────────────────────┼─────────────┤
│Blueprint │K8s, In-Place│
├──────────────────────────────┼─────────────┤
│Add-ons & Application Services│4 │
└──────────────────────────────┴─────────────┘
────────────────────────────────────────────────────────────────────────────────────────────────────────
1.2 Infrastructure Changes
┌─────────────┬───────┬───────────┐
│K8s │Current│Recommended│
╞═════════════╪═══════╪═══════════╡
│Control Plane│1.28 │1.29 │
└─────────────┴───────┴───────────┘
────────────────────────────────────────────────────────────────────────────────────────────────────────
1.3 Deprecations & Removals
```
# Marketplaces
Source: https://docs.chkk.io/product/marketplaces
Purchase Chkk from AWS Marketplace and GCP Marketplace
Chkk is available on the [Amazon Web Services (AWS) Marketplace](https://aws.amazon.com/marketplace/seller-profile?id=b4a9cf23-f6c9-48fe-bf73-e267f983ed27) and [Google Cloud Platform (GCP) Marketplace](https://console.cloud.google.com/marketplace/product/chkk-mp-public/chkk-business-edition).
Our marketplace listings make it easier for AWS and GCP customers to adopt Chkk's solution through their existing cloud accounts.
By being listed on AWS and Google Cloud Marketplaces, Chkk can be discovered and deployed with just a few clicks. You can leverage streamlined procurement including consolidated billing through your existing AWS and GCP subscriptions. AWS and GCP users can now integrate Chkk into their workflows faster and without the usual procurement hurdles, accelerating time-to-value.
Amazon Web Services
Google Cloud Platform
# Subscription Plans
Source: https://docs.chkk.io/product/pricing-plans
Business and Enterprise Plans
# Overview
Source: https://docs.chkk.io/product/risk-ledger/overview
Eliminate risks before they cause incidents
Chkk Risk Ledger is similar to security risk ledgers, but tailored specifically towards identifying contextualized Operational Risks in your Cloud Native infrastructures. It enables you to become proactive in addressing potential failures before they happen.
Platform, DevOps, and SRE Teams use Risk Ledger to:
* Eliminate risks before they cause incidents.
* Implement Guardrails to ensure Platform and App teams comply with Kubernetes best practices
* Better conformity, fewer incidents, lower operational toil, improved team productivity, and offsetting 1000s of hours of post-incident break-fix work
* Shift-left your Platform and application's availability by proactively catching and fixing safety, health and readiness risks.
* Prioritize top business-critical risks with clear and actionable insights.
* Continuously harden your Kubernetes availability.
* Learn from others and avoid repeating their mistakes.
# Upgrade Plans
Source: https://docs.chkk.io/product/upgrade-copilot/plans
Cluster-specific or Project-specific upgrade workflows instantiated from approved Templates.
## What are Chkk Upgrade Plans?
Chkk Upgrade Plans are instantiated, **cluster-specific workflows** that provide detailed, step-by-step instructions for safely upgrading individual clusters, Cloud Native Projects, application services, and operators. They are created from approved [Upgrade Templates](/product/upgrade-copilot/templates) and represent the execution phase of Chkk's upgrade process.
### Key Characteristics
**1. Instantiation from Templates**
Upgrade Plans are created by instantiating an approved [Upgrade Template](/product/upgrade-copilot/templates) for a specific cluster. They inherit all the information from the template plus additional cluster-specific details like:
* The cluster's name and region
* Node Group details
* Which applications are using **deprecated/removed APIs**
* **Application client changes** in running Cloud Native Projects
* **Application misconfigurations** (like incorrect Pod Disruption Budgets) that could cause upgrades to fail
**2. Types of Upgrade Plans**
* **Cluster Upgrade Plans**: For upgrading entire clusters
* **Project Upgrade Plans**: For upgrading specific Cloud Native Projects, application services, or operators within a cluster
**3. Lifecycle Statuses**
Upgrade Plans move through these statuses:
* **Waiting for Plan**: Being generated
* **In Progress**: Ready for execution
* **Completed**: Cluster upgraded successfully
* **Canceled**: User-initiated cancellation
**4. Key Features**
* **Standardized Workflows**: Ensure consistent upgrade processes across multiple clusters
* **Delegation Support**: Allow senior engineers to assign upgrade tasks to team members with confidence
* **Progress Tracking**: Monitor overall progress through distinct stages
* **Customization**: Can be tailored for specific clusters even after instantiation
* **Reusability**: Based on proven templates that can be used across multiple environments
### How They Work
1. **Creation**: Generated from approved Upgrade Templates through the instantiation process
2. **Customization**: Include cluster-specific information and can be further customized with additional steps
3. **Execution**: Provide a structured, step-by-step approach to performing upgrades
4. **Tracking**: Allow teams to monitor progress and mark completion
5. **Collaboration**: Support team coordination through features like comments and activity feeds
### Integration with Chkk Upgrade Copilot
Upgrade Plans are one of the three complementary capabilities of Chkk Upgrade Copilot:
1. [Upgrade Assessments](/product/upgrade-copilot/assessments) → Map scope, impact, and dependencies
2. [Upgrade Templates](/product/upgrade-copilot/templates) → Provide detailed, pre-verified workflows
3. **Upgrade Plans** → Instantiate templates for specific cluster execution
Upgrade Templates/Plans are preverified against a [Digital Twin](/resources/glossary/#digital-twin) of your running configuration and take longer to generate; use them closer to execution.
This comprehensive approach ensures teams can scope effort and delegate work early, making upgrades faster, safer, and more predictable.
# Upgrade Plans vs Templates
Source: https://docs.chkk.io/product/upgrade-copilot/plans-vs-templates
Understand the difference and relationship between Templates and Plans.
## Key Differences Between Upgrade Plans and Upgrade Templates
### Upgrade Templates
Upgrade Templates are **agentic, reusable workflows** that serve as blueprints for upgrades:
* **Purpose**: Generic, environment-scoped workflows that can be used across multiple clusters
* **Scope**: Generated for an entire environment (e.g., dev, staging, prod)
* **Content**: Contains tested sequences of steps and stages for safely upgrading clusters or Projects
* **Reusability**: Can be used to create multiple Upgrade Plans for different clusters
* **Customization**: Can be reviewed, customized with custom steps, and approved before use
* **Status Lifecycle**:
```mermaid theme={"dark"}
flowchart LR
A[Waiting for Template] --> B[Available]
B --> C[Approved for Use]
C --> D[Environment Upgraded]
```
### Upgrade Plans
Upgrade Plans are **instantiated, cluster-specific workflows** created from approved Templates:
* **Purpose**: Specific execution workflows tailored to individual clusters
* **Scope**: Generated for a specific cluster by instantiating an approved Template
* **Content**: Inherits all Template information PLUS cluster-specific details like:
* Cluster name and region
* Node Group details
* Which applications are using **deprecated/removed APIs**
* **Application client changes** in Projects
* **Application misconfigurations** (like incorrect Pod Disruption Budgets)
* **Execution**: Ready-to-execute workflows with step-by-step instructions
* **Status Lifecycle**:
```mermaid theme={"dark"}
flowchart LR
A[Waiting for Plan] --> B[In Progress]
B --> C[Completed or Canceled]
```
### The Relationship
1. Templates are created first - either requested directly or derived from [Upgrade Assessments](/product/upgrade-copilot/assessments)
2. Templates are reviewed and approved - teams can add custom steps, comments, and approve them
3. Plans are instantiated from approved Templates - each Plan is customized for a specific cluster
4. Plans are executed - providing the actual upgrade workflow for individual clusters
### Key Analogy
Think of Templates as recipes that can be used multiple times, while Plans are specific cooking instructions tailored to your particular kitchen and ingredients.
This approach allows teams to standardize upgrade processes across environments while still accommodating cluster-specific requirements and enabling safe delegation of upgrade tasks.
# Upgrade Templates
Source: https://docs.chkk.io/product/upgrade-copilot/templates
Reusable, agentic upgrade workflows for 100s of Cloud Native Projects and clusters.
## What are Chkk Upgrade Templates?
Chkk Upgrade Templates are **agentic, reusable workflows** that serve as standardized blueprints for safely upgrading clusters, Cloud Native Projects, application services, and operators. They represent the foundation of Chkk's upgrade management system.
### Key Characteristics
**1. Agentic Workflows**
* Templates are generated using AI to create tested sequences of steps and stages
* They incorporate best practices and proven upgrade methodologies
* Each template is tailored to specific components (clusters, Projects, operators, etc.)
**2. Reusable Blueprints**
* Templates are environment-scoped rather than cluster-specific
* A single template can be used to create multiple Upgrade Plans for different clusters
* They provide consistent upgrade processes across multiple environments
**3. Comprehensive Coverage**
* **Cluster Upgrade Templates**: For upgrading entire clusters
* **Project Upgrade Templates**: For upgrading specific Cloud Native Projects, application services, and operators
* Support for both **In-Place** and **Blue-Green** upgrade strategies
**4. Customizable and Reviewable**
* Teams can review templates before approval
* Custom steps can be added to align with organizational guidelines
* Internal change-management standards can be applied
* Teams can confirm which versions to upgrade now versus later
### Template Lifecycle
1. **Waiting for Template** → Template is being generated
2. **Available** → Template is ready for review and customization
3. **Approved** for Use → Template has been reviewed, customized, and officially approved
4. **Environment Upgraded** → Template has been used successfully
### Key Features
**1. Approval Process**
* Templates must be explicitly approved before use
* Chkk logs who approved each template for team visibility
* Approval includes the ability to add comments and custom steps
**2. Standardization Benefits**
* Reduces context switching between different upgrade processes
* Preserves knowledge by codifying best practices
* Promotes reuse of best practices across the organization
* Enables consistent workflows organization-wide
**3. Integration Support**
* Templates work with various deployment methods (Helm, Kustomize, YAML manifests)
* Support for private registries and custom images
* Compatible with GitOps and CI/CD workflows
### How Templates Work
* **Generation**: Templates are created either through direct requests or derived from Upgrade Assessments
* **Review & Customization**: Teams review the template, add custom steps, and adjust to organizational needs
* **Approval**: Templates are marked as "Approved for Use" with proper logging
* **Instantiation**: Approved templates are used to create cluster-specific Upgrade Plans
* **Reuse**: The same template can be instantiated multiple times for different clusters
### Benefits
* **Faster Upgrades**: Pre-tested workflows eliminate guesswork
* **Consistent Processes**: Standardized approaches across multiple clusters
* **Reduced Risk**: Proven methodologies minimize upgrade failures
* **Knowledge Preservation**: Best practices are captured and reused
* **Team Collaboration**: Clear approval processes and delegation support
Upgrade Templates essentially serve as the "recipes" that teams can customize and approve once, then use repeatedly to create specific "cooking instructions" ([Upgrade Plans](/product/upgrade-copilot/plans)) for individual clusters.
### Integration with Chkk Upgrade Copilot
Upgrade Templates are one of the three complementary capabilities of Chkk Upgrade Copilot:
1. [Upgrade Assessments](/product/upgrade-copilot/assessments) → Map scope, impact, and dependencies
2. **Upgrade Templates** → Provide detailed, pre-verified workflows
3. [Upgrade Plans](/product/upgrade-copilot/plans) → Instantiate templates for specific cluster execution
Upgrade Templates/Plans are preverified against a [Digital Twin](/resources/glossary/#digital-twin) of your running configuration and take longer to generate; use them closer to execution.
This comprehensive approach ensures teams can scope effort and delegate work early, making upgrades faster, safer, and more predictable.
# Glossary of Terms
Source: https://docs.chkk.io/resources/glossary
Definitions of key Chkk terms to help you navigate our platform and docs
## Account
A grouping of Chkk resources, such as clusters and subscriptions.
*Accounts* often map to a specific **billable entity boundary** in the your organization.
## Actions
An action is a single, side‑effect‑bearing operation executed by the Workflow—e.g., invoking a REST API, calling an internal micro‑service, running a shell command, or posting to Slack.
## Add-on and Application Service Upgrade Plan
Similar to a [Cluster Upgrade Plan](#cluster-upgrade-plan) but specific to a particular [Cloud Native Project](#cloud-native-project),
[Application Service](#application-service), or [Operator](#kubernetes-operator) instance in a given cluster.
Created from an approved [Add-on Upgrade Template](#add-on-upgrade-template).
## Add-on Upgrade Template
An agentic workflow for a specific [Cloud Native Project](#cloud-native-project), [Application Service](#application-service),
or [Operator](#kubernetes-operator) across multiple clusters.
While simpler Projects and Application Services can be upgraded as part of the Cluster Upgrade Template,
stateful or datapath Projects and Application Services have their own templates for specialized handling.
## AI Agent
A software entity that perceives its environment, reasons about what to do next, and autonomously executes actions (often by calling tools) to achieve a user-specified goal.
## Application
An *Application* is a type of [Project](#project) that **implements business logic or end-user-facing functionality** and is deployed on Cloud Native platforms as part
of an [Application Stack](#application-stack). It typically consists of one or more services and depends on both [Application Services](#application-service)
and [Cloud Native Projects](#cloud-native-project).
## Application Service
An **Application Service** is a type of Project that provides essential
services to the rest of an application stack. An application stack is one or
more Projects that provide related non-Kubernetes functionality -- in other
words, application-specific functionality.
Application Services do *not* extend or implement cluster-level Kubernetes
functionality.
Examples of Application Services include:
* `MySQL`,
`PostgreSQL` and
`Redis`
These provide database services to Application Stacks.
* `Kafka` and
`NATS`
These provide message queueing and event streaming services to Application
Stacks.
* `ArgoCD`,
`FluxCD`
Both are [Kubernetes Custom Controllers](/resources/glossary#kubernetes-custom-controller) that provide
provide GitOps and CI automation services to Application Stacks running on
Kubernetes.
* `ArgoRollouts` and
`Flagger`
Both are [Kubernetes Custom Controllers](/resources/glossary#kubernetes-custom-controller) that provide
progressive delivery services for Application Stacks.
* `Crossplane` and
`ACK S3 Controller`
Both are [Kubernetes Custom Controllers](/resources/glossary#kubernetes-custom-controller) that provide
cloud resources and service integrations to Application Stacks.
## Application Stack
An *Application Stack* is one or more [Projects](#project) that provide related
non-Kubernetes functionality -- in other words, application-specific
functionality.
## Blast Radius
The **potential scope of impact** an error, failure, or disruption may have on your system.
It represents how far negative consequences can propagate within your environment.
## Chkk Cloud Connector
*Chkk Cloud Connector* is a secure, read-only integration that fetches relevant resource data from your
cloud environment and correlates it with your [Kubernetes Clusters](#kubernetes-cluster). By focusing on resources that
affect — or are affected by — your clusters (e.g., security groups, IAM roles, networking settings), the Connector
facilitates a unified view of your infrastructure. Cloud Connector metadata is used to detect [Operational Risks](#operational-risk-or) that
span beyond the K8s layers. Examples of such cross-layer risks include security groups misconfigurations, risks that
are only latent for certain kernel versions, risks that only trigger when using certain AWS services
(e.g. Route53 records with external-dns), etc.
Details of Chkk Cloud Connector can be found [here](/connectors/cloud).
## Chkk Dashboard
Chkk Dashboard is a UI for you to interact with Chkk.
Details of Chkk Dashboard can be found [here](/overview/understanding-chkk).
## Chkk Integrations
A set of pre-built connectors which allow Chkk to fit smoothly with your existing tools.
Integrations include operational tools (GitHub, Jira, Slack, etc.) and SSO (Okta, PingIdentity).
## Chkk Kubernetes Connector
The *Chkk Kubernetes Connector* is composed of two main components:
* Chkk Operator
* Chkk Agent
Working together, these components periodically (or on-demand) extract cluster metadata and ingest it
into the Chkk SaaS platform. Once ingestion is complete, Chkk scans and analyzes your environment for
potential risks or helpful insights (e.g., Cloud Native Project instances running in your cluster).
Details of Chkk Kubernetes Connector can be found [here](/connectors/kubernetes)
## Chkk Proxy Filter
Redacts any private or sensitive data before it leaves your cluster. It automatically excludes Kubernetes
secrets and can be configured to exclude additional data as needed.
## Chkk Research Team
A dedicated team of Kubernetes experts that reviews and curates [Operational Risks](#operational-risk-or) to make them actionable.
## Cluster Metadata
Information about a [Kubernetes Cluster](#kubernetes-cluster)—versions, [Pods](#kubernetes-pod), [Cloud Native Projects](#cloud-native-project), cloud-provided components, node configs, etc.
Secrets and config maps are redacted by default, and additional filters can be configured.
## Cluster Upgrade Plan
An instantiation of a [Cluster Upgrade Template](#cluster-upgrade-template), customized for a specific [Kubernetes Cluster](#kubernetes-cluster).
The instantiated Upgrade Plans inherit all the information present in Upgrade Templates + additional cluster-specific information like:
* The cluster's name and region
* Node Group details
* Which [Applications](#application) are using deprecated/removed APIs?
* Are there any Application client changes in [Cloud Native Projects](#cloud-native-project)?
* Are there any Application misconfigurations-like incorrect Pod Disruption Budgets (PDBs)-that can cause the upgrade to fail?
Upgrade Plans move through these statuses:
1. **Waiting for Plan** - Being generated.
2. **In Progress** - Ready for execution.
3. **Completed** - Cluster upgraded successfully.
4. **Canceled** - User-initiated cancellation.
[More details here](/overview/understanding-chkk)
## Cluster Upgrade Template
A *Cluster Upgrade Template* is an agentic workflow containing a tested and structured sequence of steps and stages to
safely upgrade your [Kubernetes Clusters](#kubernetes-cluster). A Cluster Upgrade Template is generated on-demand and is scoped to an
Environment (e.g. dev, staging or prod). Cluster Upgrade Templates support three commonly-used upgrade patterns: In-Place, Blue-Green, and Rolling/Surge.
A template includes steps for each stage of an upgrade, preverified via a [Digital Twin](#digital-twin). Once an Upgrade Template is generated, you can perform
the following actions::
* **Action**: Add custom markdown steps before or after any step.
* **Action**: Request regenerations for refined versions.
* **Action**: Approve the template so other team members can instantiate it as an Upgrade Plan for specific
clusters.
Upgrade Templates move through these statuses:
1. **Waiting for Template** - Being generated.
2. **Available** - Ready for review/customization.
3. **Approved For Use** - May now be used to create Upgrade Plans.
4. **Environment Upgraded** - All clusters in the environment have used this template to upgrade.
[More details here](/overview/understanding-chkk)
## Collective Learning
Collective Learning comprises a suite of technologies that **codify operational wisdom to prevent incidents,
breakages, and disruptions.**
Collective Learning has two main parts:
1. [Operational Risk Signature Database (RSig DB)](#operational-risk-signature-database-rsig-db)
2. [Knowledge Graph](#knowledge-graph)
These components are defined on the [Understanding Chkk](/overview/understanding-chkk) page, with additional
etails provided on the [Technology](https://chkk.io/technology) page.
## Deactivated Clusters
[Kubernetes Clusters](#kubernetes-cluster) explicitly offboarded from Chkk via a **"Deactivate Cluster"** action in the
[Chkk Dashboard](#chkk-dashboard). Deactivation in the dashboard doesn't remove all Chkk components; you can find instructions for
complete removal in the [Troubleshooting](/resources/troubleshooting) page.
## Digital Twin
A *Digital Twin* is a virtual replica of your infrastructure, simulating how it runs and interacts.
There are four levels of Digital Twins:
* **Level 1**: Basic replica using the same cluster version, node versions, and [Cloud Native Project](#cloud-native-project) versions with default config.
* **Level 2**: Extends Level 1 by including custom configs of all [Cloud Native Projects](#cloud-native-project).
* **Level 3**: Adds dummy [Applications](#application) to emulate functionality on top of Level 2.
* **Level 4**: Fully functioning staging environment, an exact replica of your cluster (including real Applications), typically running within your own cloud account.
## Disconnected Clusters
[Kubernetes Clusters](#kubernetes-cluster) that have not been [Deactivated](#deactivated-clusters) but are not sending metadata to Chkk. They appear with an alert
icon in the [Chkk Dashboard](#chkk-dashboard) so you can diagnose why the [Chkk Kubernetes Connector](#kubernetes) isn't sending data.
## Grounding
Grounding constrains an AI system’s outputs to verifiable fact and policies.
## Grounding Layer
A curated corpus that integrates all authoritative sources consumed by the Chkk Knowledge Engine. AI pipelines ingest and normalize each source, while the Chkk Research Team continuously reviews and validates the content. The layer models clouds, Cloud Native Projects, and application services so that agents, workflows, and tools can reference the same trusted schema, avoid hallucinations, and maintain provable accuracy for every knowledge attribute.
## Guardrails
Rules and policies from a cloud provider, Cloud Native Project vendor, distribution, or the open source community.
Whether or not to follow a Guardrail is a business/team decision.
## Helm Chart
A *Helm Chart* is a type of [Package](#package) that uses the `helm` [Package System](#package-system) to format its artifacts (called "charts").
## Knowledge Base Article (KBA)
A single page explaining an [RSig](#operational-risk-signature-rsig) or [Guardrail](#guardrail)—covering its severity, impact,
trigger conditions, remediation steps, and potentially code snippets. All RSigs and Guardrails have an associated KBA.
KBAs support multiple actions on Operational Risks and Guardrails, such as:
1. **Action: Create Ticket** - Generates a Jira ticket for tracking.
2. **Action: Mark** - Mark as False Positive, By Design, or other reasons if not fixing.
3. **Action: Ignore** - Stop receiving notifications for this risk (optionally ignoring only specific resources).
## Knowledge Graph
*Knowledge Graph* models and stores AI-curated data and relationships across hundreds of [Cloud Native Projects](#project)
in the ecosystem, modeling their impact and identifying the safest upgrade paths.
Oversight is provided for AI-curated data and relationships by the Chkk Research Team.
Knowledge Graph covers Kubernetes releases of all major clouds and distributions:
EKS, GKE, AKS, VMware Tanzu, OpenShift, Rancher RKE1/RKE2, Nutanix. We also support DIY and Self-Hosted Kubernetes clusters.
Chkk also covers 300+ Projects, and coverage for a new Project can be extended within 48hrs.
## Cloud Native Project
A **Cloud Native Project** is a type of Project that **extends Kubernetes cluster
functionality but is not part of the Kubernetes core**. Cloud Native Projects
typically run inside the cluster as regular workloads (e.g., Deployments,
DaemonSets) and provide services like networking, monitoring, logging, and DNS.
Cloud Native Projects typically modify or enhance *cluster-level behavior*.
Examples of Cloud Native Projects include:
* `CoreDNS` and `kube-dns`
They provide cluster DNS services, a critical but optional functionality of
the Cloud Native cluster used for service discovery.
* `Amazon VPC CNI`, `Cilium` and
`Calico`
They provide implementations of Kubernetes data plane networking and
Container Networking Interface (CNI) plugins.
* `Amazon EBS CSI Driver` and
`AzureDisk CSI Driver`
They provide implementations of the Container Storage Interface (CSI)
plugin for plumbing Kubernetes Volumes to a cloud provider-specific storage
backend.
* `Ingress NGINX controller` and
`AWS Load Balancer Controller`
They provide implementations of Kubernetes Service and Ingress
functionality, which are core Kubernetes Resources.
* `Kubernetes Metrics Server` and
`kube-state-metrics`
They provide cluster-level aggregation of resource usage and resource health
metrics that are used by other Kubernetes components like Horizontal Pod
Autoscaler and Vertical Pod Autoscaler.
* `External Secrets Operator`
Despite being called an "Operator", the External Secrets Operator is *not* a
[Kubernetes Operator](#kubernetes-operator) because it does
not install or manage the lifecycle of some *other* Cloud Native Project or
Application Service. However, it *is* a Cloud Native Project because it implements
storage functionality for Cloud Native Secrets and therefore extends the
Kubernetes cluster's functionality.
## Kubernetes Cluster
A *Kubernetes Cluster* (or just "Cluster") is a group of physical of virtual
machines ([Kubernetes Nodes](#kubernetes-node)) that run containerized
applications.
## Kubernetes Controller
A *Kubernetes Controller* is software that follows the [controller design
pattern][kube-ctrl-pattern]. This design pattern features a control loop (also
called a "reconciliation loop") that repeatedly attempts to make the actual
state of some resource match the desired state of that resource.
## Kubernetes Custom Controller
A *Kubernetes Custom Controller* is a [Kubernetes
Controller](#kubernetes-controller) that tracks and reconcile [Kubernetes
Custom Resources](#kubernetes-custom-resource).
## Kubernetes Custom Resource
A *Kubernetes Custom Resource* is a special type of [Kubernetes
Resource](#kubernetes-resource) that falls outside of the core Kubernetes API
groups.
## Kubernetes DaemonSet
A *Kubernetes DaemonSet* (or just "DaemonSet") is a type of [Kubernetes
Resource](#kubernetes-resource) that describes a related set of
[Pods](#kubernetes-pod) that will run on every [Node](#kubernetes-node) in the
[Kubernetes Cluster](#kubernetes-cluster).
## Kubernetes Deployment
A *Kubernetes Deployment* (or just "Deployment") is a type of [Kubernetes
Resource](#kubernetes-resource) that describes a related set of
[Pods](#kubernetes-pod) that run an application workload.
## Kubernetes Deployment System
A *Kubernetes Deployment System* is something that manages the rollout of
[Kubernetes Resources](#kubernetes-resource) like
[Deployments](#kubernetes-deployment), [DaemonSets](#kubernetes-daemonset) and
[StatefulSets](#kubernetes-statefulset).
## Kubernetes Operator
A **Kubernetes Operator** is a type of Project that is responsible for
installing and **managing the lifecycle of another Cloud Native Project or
Application Service**.
Generally, Kubernetes Operators encode domain-specific knowledge to manage
complex stateful software on Cloud Native platforms.
A Kubernetes Operator is often confused with a [Kubernetes
Controller](#kubernetes-controller). Almost all Kubernetes
Operators use the Cloud Native Controller design pattern, but not all software
Projects that use the Cloud Native Controller design pattern are Kubernetes
Operators!
A Kubernetes Operator is sometimes mistakenly defined as a Kubernetes
Controller that uses Kubernetes Custom Resources. The more accurate term for
*that* concept is \["Kubernetes custom
controller"]\(#kubernetes-custom-controller]. What
differentiates a Kubernetes Operator is the focus on **managing complex
lifecycle operations for some *other* piece of software**.
Examples of Kubernetes Operators include:
* `Postgres Operator`
A [Kubernetes Custom Controller](#kubernetes-custom-controller)
that manages the installation and lifecycle of PostgreSQL database servers,
database schemas and database users.
* `Prometheus Operator`
Manages the installation and lifecycle of Prometheus metrics database and
associated Application Services like Prometheus Alertmanager.
* `OpenTelemetry (OTEL) Operator`
Manages the installation, lifecycle management and configuration of
OpenTelemetry collectors and auto-instrumentation libraries.
## Kubernetes Pod
A *Kubernetes Pod* (or just "Pod") is a type of [Kubernetes
Resource](#kubernetes-resource) that describes a group of containers with
shared storage and network resources.
## Kubernetes Node
A *Kubernetes Node* (or just "Node") is a physical or virtual machine that
comprises part of a [Kubernetes Cluster](#kubernetes-cluster).
## Kubernetes Resource
A *Kubernetes Resource* is a representation of the desired and observed state
of some object. Common Cloud Native platforms Resources are [Deployments](#kubernetes-deployment),
[DaemonSets](#kubernetes-daemonset) and [StatefulSets](#kubernetes-statefulset).
## Kubernetes StatefulSet
A *Kubernetes StatefulSet* (or just "StatefulSet") is a type of [Kubernetes
Resource](#kubernetes-resource) that describes a related set of
[Pods](#kubernetes-pod) that run an application workload. The difference
between a StatefulSet and a [Deployment](#kubernetes-deployment) is that the
Pods in a StatefulSet typically have an ordered initialization and the
application workload maintains some form of persistent state.
## Mitigation
Mitigation is a short‑term workaround that lowers the probability or impact
of a risk until full remediation can occur. Typical mitigations include disabling
a feature flag, throttling traffic, or rolling back a change.
## Mitigation Workflow
A mitigation workflow is a durable workflow that automates or guides the application of mitigations.
## Notifications
Inform about team invites, cluster onboarding, newly detected [Operational Risks](#operational-risk-or), or published
[Project Upgrade Templates](#project-upgrade-template), [Cluster Upgrade Templates](#cluster-upgrade-template),
[Project Upgrade Plans](#project-and-application-service-upgrade-plan), and [Cluster Upgrade Plans](#cluster-upgrade-plan).
Chkk supports Email, Slack, and in-app notifications.
## Operational Risk (OR)
*Operational Risk* refers to any known or potential defect, misconfiguration, or incompatibility in Cloud Native
infrastructure that can cause incidents, disruptions, or breakages. These risks, which may include known
defects or issues stemming from unsupported versions, deprecated APIs, and software nearing end-of-life, are
categorized by severity—Critical, High, Medium, or Low. An Operational Risk is detected by scanning for at-risk components,
identifying trigger conditions, and assessing availability impact, root cause, remediation steps, and possible mitigations.
In Chkk, these risks are codified as [Risk Signatures (RSigs)](#operational-risk-signature-rsig) that continuously scan customer environments to proactively
uncover and address Operational Risks before they cause breakages or outages.
## Operational Risk Signature (RSig)
An *RSig* is the logic used to detect the presence of a specific [Operational Risk](#operational-risk-or) in your environment.
## Operational Risk Signature Database (RSig DB)
*RSig DB* takes inspiration from cybersecurity, where security vulnerabilities are reported publicly in the CVE Database.
We extended this idea to operational safety: If there's an Operational Risk (e.g. an error, failure, or disruption)
that has happened anywhere in the world, Chkk AI aggregators and data connectors learn about it, convert it into a
[Operational Risk Signature](#operational-risk-signature-rsig)-similar to a virus signature-and store it in the RSig DB.
Any new Operational Risk Signature is streamed to all our customers, where it is scanned in their environments.
That way, our customer can proactively detect, identify, and remediate Operational Risks before they cause breakages and
disruptions, much like antivirus software detects and removes viruses before they start causing harm.
## Organization
A grouping of multiple Chkk Accounts under a common ownership, typically matching an entire company or large department.
## Package
A *Package* is a named bundle of software that is bundled (and identified) in
the format of a specific [Package System](#package-system).
## Package System
A *Package System* identifies of a packaging ecosystem.
## Preverification Engines
Preverification Engines create a [Digital Twin](#digital-twin) of your Cloud Native environment and simulate a
[Project Upgrade Template](#project-upgrade-template) or [Cluster Upgrade Template](#cluster-upgrade-template) before its published to you.
Ensuring that all steps are verified to execute without errors.
## Project
A *Project* is **software that provides some functionality**.
## Project Release Series
A [Project](#project) may have one or more *Project Release Series*. A Project
Release Series is a single release *series* for the Project.
Project Release Series are identified by a simple string that must be unique for the
Project. Typically the ProjectRelease Name will be a `major` or `major.minor`
version series, e.g. "4" or "1.28", however this is not universally true. Some
Projects use date-based names for the release series, like "2024.04".
## Project Release
A [Project](#project) may have one or more *Project Releases*. A Project
Release is the coordinated publication of one or more [Release
Artifacts](#release-artifact) for the Project having the same Version string.
[deps-dev]: https://docs.deps.dev/api/v3/
[kube-ctrl-pattern]: https://kubernetes.io/docs/concepts/architecture/controller/#controller-pattern
## Remediation
Remediation is the permanent correction of a defect or risk, aimed at eliminating the root cause rather than merely reducing impact. Remediation is the long-term fix.
## Remediation Workflow
The sequence of actions stitched together into a workflow to rollout remediations of a risk or a defect. For instance, code changes, or package upgrades, and validates success via post‑conditions and metrics.
## Revalidation
*Revalidation* starts as soon as a new cluster is onboarded. The first pass of Revalidation leverages multiple
[Classifiers](#classifiers) (part of [Collective Learning](#collective-learning)) to catalog what's running in your fleet and where.
Once Classifiers finish, a secondary pass is kicked off to extend coverage and remove false positives.
This process can take up to 24 hours. You can also report false positives via the **Action: Feedback**.
[Details of Chkk's coverage dimensions here](/overview/understanding-chkk)
## Risk Scan (aka RSig Scan)
An *RSig Scan* matches your running Cloud Native environment against relevant [RSigs](#operational-risk-signature-rsig) in the
[RSig DB](#operational-risk-signature-database-rsig-db).
Scanning an RSig has two stages:
1. **Contextualize** - Check if the RSig's components/versions are present in your environment.
2. **Test** - If the context is relevant, compare version numbers and conditions to determine if the RSig is present.
RSig Scans can be periodic (default: every 12 hours), on-demand, or event-driven (triggered by CI/CD).
You can also set the frequency of the scans--see instructions [here](/connectors/kubernetes#chkk-agent-helm-configuration)
## Scan Engines
Scan Engines identify [Operational Risks](#operational-risk-or) at various layers of Kubernetes and the underlying cloud infrastructure.
Multiple engines run in parallel, each focusing on a subset of risks.
## Source‑Grounded AI
Source‑grounded AI produces answers that link directly back to the underlying asset record or source, enabling users to verify every factual claim and trace the agent’s chain of thought.
## Task‑Specific AI Agent
A task‑specific AI agent is an agent pre‑loaded with exactly one core skill and an intentionally narrow toolset, making its behavior easier to predict, govern, and audit.
## Team
A group of users or Cloud Identities (such as AWS Accounts, IAM users, and IAM roles) within a [Chkk Organization](#organization).
Team members may be assigned ownership of certain resources, like clusters or certain Cloud Native Projects across the fleet of clusters.
## Tool
A tool is any external capability—software function, API endpoint, database query, CLI command, or workflow-that an AI Agent can invoke to extend its own reasoning and perception.
## Trigger
A trigger is the initiating event, schedule, or external signal that instantiates a workflow run. It can be time‑based (cron, interval), state‑based (configuration drift detected), or externally invoked.
## Upgrade Agent Scratchpad
A **Scratchpad** is a hidden, repo-scoped workspace where the agent stages transient artifacts during an upgrade—diffs, CRD archives, rendered manifests, logs, and small caches. It's **excluded from version control** and can be safely deleted at any time.
**Why the Scratchpad exists (server + agent perspective)**
* **Keep PRs focused.** Reasoning artifacts (diffs, logs, bundles) never land in commits—only the intended edits do.
* **Speed & reproducibility.** Per-run manifests and caches enable faster retries and leave an inspectable trail.
* **Right-sized context.** The MCP server streams structured context; large/ephemeral files live locally instead of over-stuffing prompts.
**Resolution order (where the agent looks)**
1. `CHKK_SCRATCHPAD_DIR` environment variable
2. `.chkk/scratchpad//` at the repository root
3. If none exist, the agent creates:
```text theme={"dark"}
.chkk/scratchpad/upgrade-agent/
```
**Typical contents**
* `*_diff.*` (e.g., `helm_values.diff`, template diffs)
* `crd_bundle.(json|tar.gz)` (when relevant)
* `APPLIED_CHANGES.md` and per-run logs
* Small caches for faster iterative runs
The MCP server streams context; your agent performs edits locally and uses the Scratchpad to stage transient state.
## Upgrade Assessment
An **Upgrade Assessment** is a high-level report that maps the scope, impact, and dependencies of upgrading a Kubernetes cluster—along with its Cloud Native Projects and application services—to the next minor version.
It surfaces required version hops, deprecated APIs, and other potential blockers across platform and application layers so teams can gauge readiness and remediate issues early.
## Workflow
A workflow is a sequence of coordinated steps that binds AI agents, tools, humans, and even nested workflows into a single deterministic process to achieve a defined operational outcome. Each step’s intent, inputs, outputs, and side-effects are durably recorded, so the entire flow can be replayed, resumed, or audited—guaranteeing that every decision and external action is applied exactly once, in order, and with full lineage.
## Workflow Engine
Workflow Engine persists state for long-running multi-step operations such as Upgrade Templates and Upgrade Plans.
Upgrade paths are pre-verified on a [Digital Twin](#digital-twin) of the underlying cluster, ensuring predictable and safe execution before changes are applied.\
After pre-verification, Workflow Engine generates long-running, durable upgrade workflows that are highly contextualized and pre-verified to prevent failures.
# Claude Code
Source: https://docs.chkk.io/resources/installation-guides/claude-code
This is a lightweight guide to walk you through the installation of Claude Code, an AI-powered coding environment by Anthropic.
Claude Code is an AI-powered coding environment that integrates Anthropic's Claude for fast code generation, refactoring, and explanation.
It brings conversational AI directly into your development workflow while working with your local files.
Agent Responses on this page are illustrative. Exact phrasing from your AI
model may vary depending on the model, settings, and repository context.
* Download Claude Code from the **[Claude Code installation page](https://claude.ai/claude-code/install)**
* Run the installer
* Once installed, open Claude Code
* Open your project folder
Claude may read files you open or reference to provide context for assistance. Avoid storing API keys, credentials, or other sensitive material in your project, and rotate any exposed secrets.
Start your first Claude chat with a simple, non-destructive query:
1. Open a new chat in Claude Code
2. In your new chat, try a quick repository overview:
```text theme={"dark"}
Explain this repository and list the top-level folders.
```
**Agent Response:**
In Claude Code, you can streamline everyday coding tasks with a few core concepts:
1. **Projects & Context:** Open a project folder so Claude can read the files you reference and provide grounded assistance.
2. **Chats:** Use chats to ask questions, generate or refactor code, and review suggested changes before applying them.
3. **Models:** Choose an available Claude model that fits your task. Higher‑capability models help with complex refactors; lighter models respond faster for quick iterations.
4. **MCP Tools:** Connect external tools and data sources via MCP for richer, task‑specific context.
5. **CLI:** Use the integrated terminal to run the Claude Code CLI for scripted flows and automation.
Explore **[Claude Code CLI Reference](https://docs.anthropic.com/en/docs/claude-code/cli-reference)** to learn available commands, and refer to product docs for current model options and guidance.
Claude Code supports the **Model Context Protocol (MCP)**, allowing it to connect to external tools and data sources for richer, task‑specific context.
Chkk’s **Upgrade Agent** integrates via the **Upgrade Context MCP server** to deliver **Minimal Relevant Context** (MRC) for safe Infrastructure‑as‑Code (IaC) upgrades. See the [Upgrade Agent guide](/ai/upgrade-agent).
See how Claude Code + Chkk Upgrade Agent can automatically generate ready‑to‑merge PRs to upgrade hundreds of Add‑ons, Application Services, and Cloud Native Projects—safely and at scale.
# Cursor
Source: https://docs.chkk.io/resources/installation-guides/cursor
This is a lightweight guide to walk you through the installation of Cursor, a powerful AI-powered code editor.
Cursor is an AI-powered code editor built on VS Code that integrates ChatGPT-like assistance directly into the development workflow.
It helps developers write, refactor, and understand code faster by combining an IDE with conversational AI.
Agent Responses on this page are illustrative. Exact phrasing from your AI
model may vary depending on the model, settings, and repository context.
* Download Cursor for your OS from the **[downloads
page](https://cursor.com/en/downloads)**
* Run the installer
* Once installed, open Cursor
* Open your project folder in Cursor
Cursor indexes your project folder by default to provide context for assistance. Avoid storing API keys, credentials, or other sensitive material in the folder, at risk of compromise.
Let's start our very first Cursor chat with a simple query that does not make any changes to your files:
1. Toggle the AI Pane to open a new Chat window
2. In your new chat, run a quick, non-destructive check:
```text theme={"dark"}
Explain this repository and list the top-level folders.
```
**Agent Response:**
Explore **[Cursor's Chat Overview](https://docs.cursor.com/chat/overview)** to discover the full extent of Cursor's capabilities.
In Cursor, you can switch between modes and models right from the IDE to best fit your use case.
1. **Modes:** Choose how Cursor works for you
* **Agent** (autonomous assistant, can propose or apply multi-file edits)
* **Ask** (read-only mode for exploration and Q\&A, without editing files)
* **Manual** (precise, targeted edits)
* **Custom** (user-defined workflows)
2. **Models:** Configure which AI model powers each mode to optimize for speed, accuracy, or cost depending on your task.
Explore [Cursor's Agent Overview](https://docs.cursor.com/agent) to learn how the agent operates during coding sessions depending on your choice of mode or model
While Cursor is powerful on its own, its capabilities expand further with **Model Context Protocol** (MCP). MCP allows Cursor to connect to external systems, tools, and data sources—bringing richer context into your development workflow.
Chkk’s **Upgrade Agent** integrates via the **Upgrade Context MCP server** to deliver the **Minimal Relevant Context** (MRC) needed to safely upgrade your Infrastructure‑as‑Code (IaC). See the [Upgrade Agent guide](/ai/upgrade-agent).
See how Cursor + Chkk Upgrade Agent can automatically generate ready‑to‑merge PRs to upgrade hundreds of Add‑ons, Application Services, and Cloud Native Projects—safely and at scale.
# Troubleshooting
Source: https://docs.chkk.io/resources/troubleshooting
Troubleshooting
**Answer:**
These errors typically indicate that your token is either invalid or missing. If you are using a secret-based approach, verify that the secret contains a valid token. If you are installing via Helm, ensure that the Helm chart is upgraded using a valid token.
Login to Chkk Dashboard and export a valid Access Token.
```
helm upgrade chkk-operator chkk/chkk-operator --namespace chkk-system --set secret.chkkAccessToken=
```
```
Release "chkk-operator" has been upgraded. Happy Helming!
NAME: chkk-operator
LAST DEPLOYED: Thu Aug 17 19:31:58 2023
NAMESPACE: chkk-system
STATUS: deployed
REVISION: 2
TEST SUITE: None
```
Use the command below to ensure the pod is running:
```
kubectl get pods -n chkk-system
```
```
NAME READY STATUS RESTARTS AGE
chkk-operator-chkk-agent-3kjfqe00fqpe-atpoiks 1/1 Running 0 4d13h
```
If these steps do not solve your issue, please reach out on your private Slack or MS Team Channel or email [support@chkk.io](mailto:support@chkk.io).
**Answer:**
Please refer to the [Chkk Kubernetes Connector documentation](/connectors/kubernetes) for instructions on how to use an existing Service Account.
**Answer:**
Please refer to the [Chkk Kubernetes Connector documentation](/connectors/kubernetes) for instructions on how to use an existing Secret.
**Answer:**
Make sure that the Jira project and issue type do not have any required custom fields. Chkk by default only supports providing the default fields to Jira. If you require the use of mandatory custom fields, contact us on Chkk support Slack/MS Team Channel or email us at [support@chkk.io](mailto:support@chkk.io).
**Answer:**
You can ignore Risks by adding the `chkk.io/ignore` annotation to your resources in your IaC.
Use a wildcard (`*`) in the annotation:
```
yaml
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
chkk.io/ignore: "*"
deployment.kubernetes.io/revision: "1"
meta.helm.sh/release-name: traefik-1
meta.helm.sh/release-namespace: traefik-ns
```
Specify the ARSig IDs you wish to ignore:
```
yaml
apiVersion: apps/v1
kind: Deployment
metadata:
annotations:
chkk.io/ignore: CHKK-K8S-1002,CHKK-K8S-602
deployment.kubernetes.io/revision: "1"
meta.helm.sh/release-name: traefik-1
meta.helm.sh/release-namespace: traefik-ns
```
**Answer:**
Please refer to the [Chkk Kubernetes Connector documentation](/connectors/kubernetes#configuration-examples-2) for guidance on configuring the Cluster Name and Environment using the ChkkAgent CRD.
Alternatively, you can update these settings via the Chkk Dashboard by navigating to `Risk Ledger > Clusters` and clicking **Edit** on the relevant cluster card, or by modifying the values in the cluster's Properties tab.
> **Note:** If the Cluster Name or Environment is defined through Infrastructure as Code (IaC), it cannot be modified from the Dashboard.
**Answer:**
Please refer to the [Chkk Kubernetes Connector documentation](/connectors/kubernetes#usage) for guidance on configuring the Cluster Name and Environment using the Chkk Kubernetes Connector Terraform Module.
Alternatively, you can update these settings via the Chkk Dashboard by navigating to `Risk Ledger > Clusters` and clicking **Edit** on the relevant cluster card, or by modifying the values in the cluster's Properties tab.
> **Note:** If the Cluster Name or Environment is defined through Infrastructure as Code (IaC), it cannot be modified from the Dashboard.
**Answer:**
When a custom resource is deleted, any configured finalizers must be cleared before the object is fully removed. If a finalizer is misconfigured or cannot complete its cleanup, the resource remains stuck in the terminating state. To force-remove the finalizer and allow the deletion to complete, run the following command:
```bash theme={"dark"}
kubectl patch chkkagent/chkk-agent -n chkk-system -p '{"metadata":{"finalizers":null}}' --type=merge
```
This command manually clears the finalizer from the metadata, allowing the resource to be removed successfully.
**Answer:**
This error commonly indicates that a proxy server or firewall is blocking requests to the Kube API Server. Verify that your Kube API Server address is allowlisted or permitted within your network's proxy/firewall configurations.
Example log snippet:
```
2024-06-26T18:19:47Z ERROR setup unable to start manager {"error": "failed to determine if *v1.ConfigMap is namespaced: failed to get restmapping: failed to get server groups: Get \"https://172.20.0.1:443/api\": Forbidden"}
```
**Answer:**
This error is likely caused by your proxy server or firewall blocking traffic to and from the "chkk.io" domain. The ChkkAgent needs to communicate with the Chkk API to sync the cluster state. To fix this issue, you need to allowlist the "chkk.io" domain and its subdomains in your proxy server or firewall.
**Answer:**
In the Dashboard, deactivate the cluster you want to remove.
1. List all `ChkkAgent` resources:
```
kubectl get chkkagent --all-namespaces
```
2. Delete all `ChkkAgent` resources:
```
kubectl delete chkkagent --all --all-namespaces
```
1. Check installed charts:
```
helm ls -n chkk-system
```
2. Uninstall the chart:
```
helm uninstall chkk-operator -n chkk-system
```
3. Delete the namespace:
```
kubectl delete ns chkk-system
```
1. List resources in `chkk-system`:
```
kubectl get all -n chkk-system
```
2. Delete Operator resources:
```
kubectl delete -f https://helm.chkk.io/chkk-operator/manifest.yaml
```
3. Delete the namespace:
```
kubectl delete ns chkk-system
```
Finally, remove the CRD:
```
kubectl delete crds chkkagents.k8s.chkk.io
```
**Answer:**
This can happen due to a few common misconfigurations: either the Chkk Agent RBAC is incomplete or incorrect, explicit filter rules (especially wildcard-based) are excluding key namespaces, or Chkk API endpoints are not reachable due to network restrictions.
ChkkAgent requires specific Kubernetes permissions to access resources for analysis.
Please ensure you are using the RBAC definitions provided with the official Chkk Operator Helm Chart or Kubernetes Manifests. Missing or custom-modified roles/clusterroles may cause incomplete onboarding.
If you have applied filter rules to exclude namespaces, review them carefully—especially if you're using a wildcard (e.g., \*).
Wildcard exclusions can unintentionally block all namespaces from being scanned, resulting in no or limited coverage.
The Chkk Agent must be able to communicate with Chkk's API services.
Ensure your firewall or proxy settings allowlist all the domains listed in the Chkk Operator prerequisites documentation.
Once any misconfigurations are resolved, the Chkk Agent will pick up the changes during the next scheduled scan. The cluster should then get onboarded.
If the issue persists after 24 hours, please reach out to your Chkk support contact for further investigation.
**Answer:**
This error often occurs when a **proxy in the network is intercepting HTTPS traffic**. Specifically, if you use **Squid Proxy with SSL Bump enabled**, the proxy acts as a proxy-in-the-middle and presents its own certificate instead of the actual server certificate. Since this certificate is not signed by a known Certificate Authority (CA), Chkk system refuses the connection due to failed certificate validation.
Squid Proxy with SSL Bump intercepts encrypted traffic and re-signs it with an internal/self-signed CA. Chkk system does not trust this certificate by default, which causes the error:
```
tls: failed to verify certificate: x509: certificate signed by unknown authority
```
To allow Chkk Operator to establish a secure connection without interference, please configure Squid Proxy to skip the SSL Bump. This will allow Chkk Operator to use its own certificates.
If this does not resolve the issue, please contact your internal network/security team to confirm whether SSL Bump is still affecting `.chkk.io` traffic, and reach out to [support@chkk.io](mailto:support@chkk.io) for further assistance.
**Answer:**
Both the Chkk Operator and the ChkkAgent Custom Resource Definition (CRD) support overriding default container images.
**Default Images**:
* **Chkk Operator**: `public.ecr.aws/chkk/operator:`
* **ChkkAgent**:
* Agent Manager: `public.ecr.aws/chkk/cluster-agent-manager:`
* Agent: `public.ecr.aws/chkk/cluster-agent:`
```
kubectl create ns chkk-system
```
```
helm repo add chkk https://helm.chkk.io
helm repo update chkk
```
```
helm install chkk-operator chkk/chkk-operator \
--namespace chkk-system \
--set secret.create=true \
--set secret.chkkAccessToken= \
--set image.repository= \
--set image.tag=
```
```
kubectl apply -f - <
managerImage:
name:
EOF
```
**Answer:**
1. Navigate to **Configure > Settings > Clusters > Deactivated Clusters** in your Chkk Dashboard.
2. Locate the cluster you wish to restore and select **Activate Cluster**.
3. After activation, the cluster will reappear in **Risk Ledger** and in the **Artifact Register**, allowing normal management.
**Answer:**
Here are solutions to the most common Chkk MCP Server issues:
* **Authorization error** (e.g., `Received Login Error. Code: 403 Body: {"error":"forbidden","message":"Not authorized"}`):
* Make sure your AWS credentials are valid and the associated IAM Role or User has been added to Chkk.
* Double-check that your AWS identity has been added to Chkk.
* **No risks returned:**
* Ensure your cluster ID is correct and you have access.
* **Still stuck?**
* Check logs in the Cursor output panel or run the server manually for debug output.
# Secure Architecture
Source: https://docs.chkk.io/security/architecture
Chkk's platform is designed with **security, scalability, and resilience** as core principles. Our architecture ensures **strong isolation, fault tolerance, and secure scalability** while maintaining enterprise-grade security controls.
Security is embedded at every level of our infrastructure, following a **defense-in-depth strategy** that applies multiple layers of protection. From the network to application layers, we employ **strict access controls, encryption, continuous monitoring, and automated remediation** to protect against unauthorized access and threats.
Our platform operates on a **Zero Trust security model**, where every request is authenticated and authorized before being granted access. This model ensures that access is continuously verified, reducing the attack surface and mitigating potential security risks. All service-to-service communication is secured with **mutual TLS (mTLS)** to ensure encrypted data exchange between internal components.
We maintain a **secure software development lifecycle (SDLC)**, integrating security best practices at every stage. All code changes undergo **thorough security reviews, automated vulnerability scanning, and rigorous testing** before deployment. Our infrastructure is regularly tested through **independent penetration testing and security audits** to validate our security posture and proactively identify potential threats.
Resilience and availability are critical components of our architecture. Our cloud infrastructure is deployed across multiple **geographically distributed regions**, ensuring high availability and disaster recovery readiness. Automated **backup and failover mechanisms** safeguard against data loss and ensure continuity of service, even in the event of an outage. We implement **real-time monitoring and threat detection** to continuously assess security risks and respond proactively to anomalies.
Our commitment to security extends beyond infrastructure. We enforce **strict access policies**, ensuring that only authorized personnel can access sensitive systems. All administrative actions are logged, monitored, and reviewed for compliance, further enhancing accountability and reducing the risk of unauthorized modifications.
Chkk's security architecture is **continuously evolving** to adapt to new threats and industry best practices. We leverage advanced security technologies and methodologies to provide **a highly secure and resilient platform** for our customers.
For a detailed breakdown of our architecture, including network segmentation, authentication mechanisms, and security best practices, visit the [**Chkk Trust Center**](/security/trust-center) to access full documentation and architectural diagrams.
# Compliance
Source: https://docs.chkk.io/security/compliance
Chkk is committed to upholding the highest standards in security and regulatory compliance. Chkk is **SOC 2 Type II** certified, demonstrating that our security, availability, and confidentiality controls are independently assessed and verified. This certification is renewed annually through rigorous audits, ensuring that our security practices remain effective and aligned with industry standards.
We conduct **regular penetration testing** and security assessments in partnership with trusted third-party firms. Our internal security team continuously monitors and enhances our security posture through **vulnerability scanning, patch management, and infrastructure hardening**. Additionally, we undergo annual third-party reviews to validate our security measures and identify areas for improvement.
Chkk also adheres to global data privacy regulations, including **GDPR and CCPA**, ensuring that our data handling practices align with stringent privacy requirements. We offer customers flexibility in **data residency**, allowing them to store and process data in compliance with regional regulations.
For a deeper understanding of our security and compliance commitments, visit the [**Chkk Trust Center**](/security/trust-center), where you can access **SOC 2 Type II reports, security documentation, penetration testing summaries, and compliance artifacts**. If your organization has specific compliance requirements, our team is available to provide additional documentation and support tailored to your needs.
# Security-First Culture
Source: https://docs.chkk.io/security/culture
Chkk has invested in a **security-first culture** since day one. Security is a **top-down priority**, with leadership ensuring that security remains central to our operations, engineering, and customer commitments. Having built **planet-scale, secure services** and run security programs at AWS—including the foundational controls behind some of AWS’ most fundamental security guarantees—our team also brings deep expertise designing and securing AWS networking for highly regulated financial institutions, U.S. Government (GovCloud), and intelligence-grade systems. We have built Chkk on these same security principles, and we believe that every individual—regardless of role—shares responsibility for safeguarding our systems and data. From the earliest design discussions to ongoing production operations, security underpins every decision we make.
We align our organization so security teams work hand-in-hand with product and engineering. Weekly reviews with executive leadership highlight key security metrics, connect them to business objectives, and ensure alignment on strategic priorities. This commitment sets the tone that security is never an afterthought—it's an accelerator for customer trust and innovation.
At Chkk, strong security practices include thorough threat modeling, well-defined secure development workflows, robust change management, and continuous testing. We operate under a **Zero Trust security model**, ensuring that every request for access is verified and continuously authenticated. Our policies enforce **least-privilege access** and rigorous security testing before new features are shipped. These same principles are applied to every dedicated deployment of Chkk, giving customers a consistent, defense-in-depth posture whether they run our SaaS platform or a private instance.
We also conduct **independent audits and penetration tests**, challenging our controls and validating our processes to continuously raise the bar. Security is not just a compliance requirement; it is an ongoing operational mandate. Our goal is to provide a platform where **reliability, confidentiality, and integrity** are woven into every layer.
If you have any questions, please reach out to our security team at [security@chkk.io](mailto:security@chkk.io), or explore the rest of our Security documentation to learn more about our [data handling](/security/data-handling), [third-party subprocessors](/security/subprocessors), [platform architecture](/security/architecture), and [Trust Center](/security/trust-center) resources.
# Data Protection & Handling
Source: https://docs.chkk.io/security/data-handling
At Chkk, we take a **privacy-first approach** to data protection, ensuring that customer data is safeguarded throughout its lifecycle. Our philosophy is simple: **collect only what is necessary, protect it at all costs, and provide transparency and control to our customers**.
### Data Collection & Minimization
We design our platform to minimize the data we collect. Chkk primarily analyzes **metadata and configurations** from Cloud Native environments—**not customer application data**. Our in-cluster connector gathers only essential information, such as cluster version details, configuration settings, and security events. By limiting data collection, we reduce risk and simplify compliance obligations.
### Encryption in Transit & At Rest
All data transmitted between customer environments and Chkk is encrypted using **TLS 1.2+**, ensuring end-to-end protection in transit. Data at rest is safeguarded with **AES-256 encryption**, applied across databases, file storage, and backups. Encryption keys are managed using strict security controls, including **regular key rotation** and storage in secure Key Management Services (KMS).
### Access Controls & Isolation
We enforce **least privilege access** across our platform, ensuring that only authorized users and services can access sensitive data. Role-based access control (RBAC) and multi-factor authentication (MFA) protect administrative access. Our **multi-tenant architecture** ensures complete logical separation of customer data, preventing any unauthorized cross-tenant access.
### Data Retention & Deletion
Customer data is retained only as long as necessary to deliver our services. We maintain **defined retention policies**, automatically purging outdated or unnecessary data. Upon customer request or contract termination, all associated data is securely deleted using cryptographic erasure techniques to ensure that no residual information remains.
### Customer Control & Transparency
We empower customers with full visibility into their data usage and provide mechanisms to support **data subject rights requests** under privacy regulations like **GDPR and CCPA**. Customers can access, export, and delete their data as needed, ensuring compliance with evolving privacy expectations.
Through these rigorous protections, Chkk ensures that customer data remains secure, private, and fully under your control.
For more details, visit the [**Chkk Trust Center**](/security/trust-center) to access FAQs, Security Documentation, Compliance Certificates, Penetration Testing reports, and other security resources.
# Privacy Policy
Source: https://docs.chkk.io/security/privacy-policy
Updated November 2022
At Chkk, Inc. ("Chkk" or "We"), the protection of your personal data is of particular importance to us. We protect your personal data in accordance with applicable data protection laws as well as this Privacy Policy. We have prepared this Privacy Policy to inform you of the manner in which we collect, use, disclose, and otherwise process the information we may collect about you from (a) your use of our Website, located at [https://chkk.io](https://chkk.io) and/or our products and services, (b) your interactions with us online and at in-person events, or (c) any other circumstances in which we provide you with a copy of this Privacy Policy.
## Definitions
Under this Privacy Policy:
* Personal data means any information relating to an identified or identifiable natural person (data subject); an identifiable natural person is one who can be identified, directly or indirectly, in particular by reference to an identifier such as a name, an identification number, location data, an online identifier or to one or more factors specific to the physical, physiological, genetic, mental, economic, cultural or social identity of that natural person.
* Processing means any operation or set of operations which is performed on personal data or on sets of personal data, whether or not by automated means, such as collection, recording, organization, structuring, storage, adaptation or alteration, retrieval, consultation, use, disclosure by transmission, dissemination or otherwise making available, alignment or combination, restriction, erasure or destruction.
* Controller means the natural or legal person, public authority, agency or other body which, alone or jointly with others, determines the purposes and means of the processing of personal data.
* Processor means a natural or legal person, public authority, agency or other body which processes personal data on behalf of the controller.
* Recipient means a natural or legal person, public authority, agency or another body, to which the personal data are disclosed, including both processors and controllers.
* Legal basis means a lawful ground for data processing under the GDPR or similar laws.
## Personal Data We Collect
We may collect your personal data when you:
* Contact us;
* Visit or register with our Website;
* Use our products, including by browsing the product, downloading content, or receiving a product demo;
* Apply for employment or other positions;
* Subscribe or request to attend our webinars, events or workshops, sign up for our slack channel or blog posts;
* Interact with us on our social media profiles (e.g., Facebook, Twitter, LinkedIn);
* Provide your personal data to our third party sources, including our service providers; or
* Interact with us or our personnel at in-person events.
### Personal Data You Provide to Us Directly
We may collect information provided by you directly, including from our Website; from your contacts with us, including through our webpage and on social media; by your creation of a user account; and from your use or trial of our products and services. This nformation may include your first and last name, email address, username, password, job title, phone number, country of residence, company name, payment information, profile picture and any other information provided by you.
We may also collect information provided by you in the course of evaluating or engaging you for employment or other positions. This information may include your first and last name, email address, CV, resume, cover letter and any other information provided by you.
### Personal Data We Collect through Automated Data Collection Technologies
We may collect information using Automated Data Collection Technologies from your use of our Website and products. This information may include your IP Address, Log Files, Referrer URL, Browser Information, Device Information, and Data and Time of user request, cookies, information reflecting how you searched, browsed, and were directed to the Website, including mouse movement, click, touch, scroll, and keystroke activity, and any other information provided by your use of our Website and products, as further explained in the "Use of Cookies and Other Web Technologies" section below.
### Personal Data We Obtain from Third Parties
We may collect information from third party sources such as lead generation companies, data sellers, advertising partners, and Service Providers. This information may include your first and last name, email address, phone number, company name, job title, and country, and other information.
## How We Use Your Personal Data
We may use your personal data:
* For your creation of a user account or profile to use our products and services;
* To provide, maintain, and improve our Website, products and services, including for collaboration within the product, to enhance your user experience, and to understand and save your preferences for future visits;
* To monitor our products' performance and implement security measures;
* For the performance or preparation of a contract to which you, our customer or service provider are a party;
* To communicate with our customers or clients;
* To establish and maintain our business relationship with you;
* To plan and host events, workshops, and webinars, including to manage our list of attendees;
* To send you marketing and other information about our products, services or offerings, including through our publications and on other websites and/or media channels;
* To advertise to you on other sites;
* To receive, process, and respond to your feedback, requests or queries through our products, Website, or social media;
* For compliance with our legal obligations and other internal legal compliance purposes;
* To evaluate your employment application and assess you as a candidate; and,
* For other purposes consistent with the context of the collection of your personal data, or as otherwise disclosed to you prior to the use of your personal data.
## Data Sharing
Personal data may be disclosed to third parties in the following circumstances:
### Processors, Service Providers and other companies that work with or on behalf of Chkk
Personal data may be disclosed to processors or service providers who act on our behalf in order to process personal data in accordance with the purposes outlined above. This includes the following categories of service providers:
* IT service providers
* Email marketing providers
* Administrative, billing, operations, and payment operators
* Cloud and other software service providers
Data access by processors or service providers is protected under our contracts with these entities, which limit the processing purposes. The agreement obliges the service providers to process your personal data only on our behalf and upon our instruction. They are prohibited to pass on your personal data to other parties without permission, unless this is required by law.
We may also share data with entities that are controllers, such as advertising partners, data sellers, and similar companies, in accordance with the "Use of Cookies and Other Web Technologies" Section below and other sections of this Privacy Policy.
### Sale of Business
If, in the future, we sell or transfer, or we consider selling or transferring, some or all of our business, shares or assets to a third party, we will disclose your personal data to such third party (whether actual or potential) in connection with the foregoing events. In the event that we are acquired by, or merged with, a third party entity, or in the event of bankruptcy or a comparable event, we reserve the right to transfer, disclose or assign your personal data in connection with the foregoing events.
### Legal Purposes
We may share your personal data with regulators, courts or competent authorities, to comply with applicable laws, regulations and rules (including, without limitation, federal, state or local laws), and requests of law enforcement, regulatory and other governmental agencies or if we have a good faith belief that the law requires it, such as in response to a search warrant, subpoena, or other legally valid inquiry, order, or process. We may also disclose information to assist us in collecting a debt, or as necessary to exercise our legal rights or defend claims brought against us.
### With Your Consent
We may share your personal data where you have provided your consent to us sharing or transferring your personal data (e.g., where you provide us with marketing consents or opt-in to optional additional services or functionality).
## Your Rights
Depending on the circumstances, you may be entitled to exercise some or all of the following rights:
* Obtain confirmation as to whether or not your personal data is being processed and access to copy of your personal data undergoing processing
* Require (i) access to and/or duplicates of your personal data retained, (ii) receive the personal data concerning you, which you have provided to us, in a structured, commonly used and machine-readable format and (iii) to transmit those personal data to another controller without hindrance from our side; where technically feasible you shall have the right to have the personal data transmitted directly from us to another controller
* Request rectification, removal or restriction of your personal data
* Where the data processing is based on your consent, refuse to provide and - without impact to data processing activities that have taken place before such withdrawal - withdraw your consent to processing of your personal data at any time
* Take legal actions in relation to any potential breach of your rights regarding the processing of your personal data, as well as to lodge complaints before the competent data protection regulators
* Not to be subject to any automated decision making, including profiling (automatic decisions based on data processing by automatic means, for the purpose of assessing several personal aspects) which produce legal effects on you or affect you with similar significance
Further, you may be entitled to object, out of grounds relating to your particular situation, at any time to processing of personal data concerning you, including object to direct marketing and automated individual decision-making including profiling. In this case, please provide us with information about your particular situation. After the assessment of the facts presented by you we will either stop processing your personal data or present you our compelling legitimate grounds for ongoing processing.
You can exercise your rights by submitting a request at priv. Subject to legal and other permissible considerations, we will make every reasonable effort to honor your request promptly in accordance with applicable law or inform you if we require further information in order to fulfill your request. When processing your request, we may ask you for additional information to confirm or verify your identity and for security purposes, before processing and/or honoring your request. We reserve the right to charge a fee where permitted by law, for instance if your request is manifestly unfounded or excessive. In the event that your request would adversely affect the rights and freedoms of others (for example, would impact the duty of confidentiality we owe to others) or if we are legally entitled to deal with your request in a different way than initial requested, we will address your request to the maximum extent possible, all in accordance with applicable law.
Please see the "California Residents" Section below for information on rights under California law.
## Legal Basis
Where applicable under the GDPR or similar laws, the legal basis for our collection and use of your personal data may include any of the following:
* Performance of a contractWe process your personal data as necessary to perform our obligations under any contract with you, such as to provide our Website or services to you or complete transactions.
* ConsentWe may ask for your consent to use your personal data, including if we need your consent to engage in certain marketing activities. If we obtain your consent as a legal basis for processing, you may withdraw your consent at any time.
* Legitimate interestsWe have a legitimate interest in using your personal data for our business purposes, including operating, improving, and marketing our business, Website and services.
* Compliance with a legal obligationWe may need to use your personal data to comply with applicable legal requirements.
## Data Storage and Transfers
Where applicable under the GDPR or similar laws, we have implemented appropriate cross-border transfer mechanisms when transferring your personal data to a country outside of your home jurisdiction, including, where relevant, the EU Standard Contractual Clauses.
## Interaction With Third Parties
We may link to or otherwise enable you to interact with a third party Website, mobile software applications and products or services that are not owned or controlled by us (each a "Third Party Service"). We are not responsible for the privacy practices or the content of such Third Party Services. Please be aware that Third Party Services can collect personal data from you. Accordingly, we encourage you to read the terms and conditions and privacy policies of each Third Party Service.
## Data Retention
We retain your personal data as long as reasonably necessary for the respective purpose. In determining the criteria by which to retain or dispose of your personal data, we consider the type, sensitivity, context, and purpose of collecting the information. Chkk may additionally delete your personal data in response to a valid data subject request, as described below.
## Security of Your Information
We maintain administrative, technical, and physical safeguards designed to protect against unauthorized access, use, modification, and disclosure of your personal data in our custody and control. No data, on the Internet or otherwise, can be guaranteed to be 100% secure. While we strive to protect your information from unauthorized access, use, or disclosure, Chkk cannot and does not ensure or warrant the security of your personal data.
## Children's Privacy
Chkk does not knowingly collect or process personal data from children under the age of 13. The Website is not directed at children under the age of 13. In the event that we learn that we have collected personal data of a child under the age of 13 without parental consent, we will promptly take steps to delete that information. If you believe that we may have collected personal data from a child under 13, please contact us using the contact details outlined in this policy.
## No Processing for Automated Individual Decision-making Including Profiling
We do not knowingly collect or process personal data for automated individual decision-making including profiling.
## Cookie Policy
### Use of Cookies and Other Web Technologies
If your browser is configured to accept cookies, we may collect non-personally identifiable information passively using "cookies" and "page tags".
It is Chkk's policy to respect your privacy regarding any information we may collect while operating our Website. Please read this policy carefully to understand how we handle and treat your personal data.
### Cookies
"Cookies" are small text files that can be placed on your computer or mobile device in order to identify your Web browser and the activities of your computer on the Chkk Service and other Websites.
We use cookies to personalize your experience on the Chkk Website (such as dynamically generating content on webpages specifically designed for you), to assist you in using the Chkk Service (such as saving time by not having to reenter your name each time you use the Chkk Service), to allow us to statistically monitor how you are using the Chkk Service so that we can improve our offerings, and to determine the popularity of certain content. By using cookies and page tags together, we are able to improve the Chkk Service and measure the effectiveness of our advertising and marketing campaigns.
### Page Tags
"Page tags," also known as web beacons or gif tags, are a web technology used to help track Website or email usage information, such as how many times a specific page or email has been viewed. Page tags are invisible to you, and any portion of the Chkk Service, including content, or email sent on our behalf, may contain page tags.
### Do I Have To Accept Them
You do not have to accept cookies to use the Chkk Website or services. If you reject cookies, certain features or resources of the Chkk Website may not work properly or at all and you may have a degraded experience.
Although most browsers are initially set to accept cookies, you can change your browser settings to notify you when you receive a cookie or to reject cookies generally. To learn more about how to control privacy settings and cookie management, click the link for your browser below.
* [Microsoft Internet Explorer](https://support.microsoft.com/en-us/windows/change-security-and-privacy-settings-for-internet-explorer-11-9528b011-664c-b771-d757-43a2b78b2afe)
* [Mozilla Firefox](https://support.mozilla.org/en-US/kb/delete-browsing-search-download-history-firefox#w_clear-cookies-and-data-for-a-specific-website)
* [Google Chrome](https://support.google.com/accounts/answer/61416)
* [Apple Safari](https://support.apple.com/en-us/105082)
To learn more about cookies; how to control, disable or delete them, please visit [http://www.aboutcookies.org](http://www.aboutcookies.org). Some third party advertising networks, like Google, allow you to opt out of or customize preferences associated with your internet browsing. For more information on how Google lets you customize these preferences, see their documentation.
All cookies, on our Website and everywhere else on the web, fall into one of five categories:
* Essential
* Advertising
* Analytics & Customization
* Performance & Functionality, and
* Social Networking
You are able to see the specific cookies we use and exercise choices about the types of cookies and other technologies you want to accept by selecting the "Manage Cookie Preferences" section of our website ([https://chkk.io](https://chkk.io)).
## Log Files
We collect non-personal data through our Internet log files, which record data such as browser types, domain names, and other anonymous statistical data involving the use of the Chkk services. This information may be used to analyze trends, to administer the Chkk services, to monitor the use of the Chkk services, and to gather general demographic information. We may link this information to personal data for these and other purposes such as personalizing your experience on the Chkk services and evaluating the Chkk services in general.
## Do Not Track (DNT) Settings
We do not currently respond or take any action with respect to web browser "do not track" signals or other mechanisms that provide consumers the ability to exercise choice regarding the collection of personally identifiable information about an individual consumer's online activities over time and across third-party web sites or online services. We may allow third parties, such as companies that provide us with analytics tools, to collect personally identifiable information about an individual consumer's online activities over time and across different websites when a consumer uses the Services.
## California Residents
If you are a California resident, your personal data may be covered by the California Consumer Privacy Act (CCPA). The below disclosures apply to the extent the CCPA applies to your personal data, subject to any applicable exemptions.
## "Personal Information" We Collect
The categories of "personal information," as defined in the CCPA, that we collect include:
Identifiers;
Personal information categories listed in the
California Customer Records statute (Cal. Civ. Code § 1798.80(e))
Commercial Information;
Internet or other electronic network activity information;
Audio, electronic, and visual information;
Professional or employment-related information; and
Inferences drawn from other personal information.
Chkk may obtain, use, and share these data categories as detailed in the "Personal Data We Collect," "How We Use Your Personal Data," and "Data Sharing" sections of this Privacy Policy, above.
## Data Subject Rights
You may be entitled to exercise some or all of the following rights under the CCPA:
### (i) Right to Know About Personal Data Collected, Disclosed, or Sold
You may have the right to request that we provide certain information to you about our collection and use of your personal data over the past twelve (12) months. Specifically, you may have the right to request disclosure of:
* The specific pieces of personal data we collected about you
* The categories of personal data we collected about you
* The categories of sources from which personal data was collected
* Our business or commercial purpose for collecting or disclosing personal data, and
* The categories of third parties with whom we shared personal data.
### (ii) Right to Request Deletion of Personal Data
You may also have the right to request that we delete any of your personal Data that we collected or maintain about you, subject to certain exceptions.
### (iii) Right to Correct Inaccurate Personal Data
You may also have the right to request that we correct inaccurate personal data we maintain.
### (iv) Right to Non-Discrimination for the Exercise of a Consumer's Privacy Rights
We will not unlawfully discriminate against you for exercising any of your applicable privacy rights.
### (v) Right to Opt Out of the Sale or Sharing of your Personal Data
Chkk uses third party cookies and similar technologies to deliver targeted advertisements, also known as data "sharing" and/or "selling" under the CCPA, as further detailed in the "Cookie Policy" section above. You can opt out of these practices by turning off advertising cookies in the "Manage Cookie Preferences" section of our website ( [https://chkk.io/](https://chkk.io/)).
## Exercise Your Rights
You can exercise your rights by submitting a request at [privacy@chkk.io](mailto:privacy@chkk.io) or modifying your cookie preferences on [https://chkk.io/](https://chkk.io/).
## Response Timing and Format
We will make our best effort to respond to a verifiable consumer request within 45 days of its receipt. If we require more time (up to 90 days), we will inform you of the reason and extension period in writing. Within ten (10) days of receiving the request, we will confirm receipt and provide information about its verification and processing of the request. Chkk will maintain records of consumer requests made pursuant to the CCPA as well as our response to said requests for a period of at least twenty-four (24) months.
## Your Rights Under Other California Statutes
In addition to your rights under the CCPA, California Civil Code Section 1798.83 permits California residents to request information regarding our disclosure, if any, of their personal data to third parties for their direct marketing purposes. If this applies, you may obtain the categories of personal data shared and the names and addresses of all third parties that received personal data for their direct marketing purposes during the immediately prior calendar year.
If you are a California resident under the age of 18 and a registered user, California Business and Professions Code Section 22581 permits you to remove content or personal data you have publicly posted. If you wish to remove such content or personal data please submit a request here and if you specify which content or personal data you wish to be removed, we will do so in accordance with applicable law. Please be aware that after removal you may not be able to restore removed content. In addition, such removal does not ensure complete or comprehensive removal of the content or personal data you have posted and that there may be circumstances in which the law does not require us to enable removal of content.
You may submit this request by contacting us at [privacy@chkk.io](mailto:privacy@chkk.io).
## Updates to This Policy
We may update this Privacy Policy from time to time. If we modify our Privacy Policy, we will post the revised version here, with an updated revision date. You may visit these pages periodically to be aware of and review any such revisions. If we make material changes to our Privacy Policy, we may also notify you by other means prior to the changes taking effect, such as by posting a notice on our Website or sending you a direct notification.
## Contact Us
Please feel free to contact us at any time if you have any questions or comments about this Privacy Policy.
Contact our Data Protection Officer at: [privacy@chkk.io](mailto:privacy@chkk.io)
Contact the Controller for the processing of this Website at: Chkk, 440 North Wolfe Drive, Sunnyvale, CA, 94085 ([privacy@chkk.io](mailto:privacy@chkk.io))
# Subprocessors and Third-Party Security
Source: https://docs.chkk.io/security/subprocessors
Chkk partners with carefully selected providers to deliver a high-quality, secure service. These subprocessors support various functions, including **infrastructure hosting, analytics, and payment processing**. Before onboarding any vendor that will store or process customer data, we conduct a rigorous due diligence process as outlined in our **Third-Party Management Policy**. This evaluation assesses the vendor's security measures, data protection capabilities, and compliance posture.
Once approved, each subprocessor signs a **Data Protection Agreement (DPA)** that defines their responsibilities regarding confidentiality and security. We continuously monitor our subprocessors to ensure they uphold our security standards. This includes reviewing their **certifications (such as ISO 27001 and SOC 2), assessing their internal security posture, and evaluating their incident response readiness**.
We also require subprocessors to implement **least-privilege access controls**, ensuring they only have access to the minimal data necessary for their function. Additionally, we encourage frequent security reviews and audits to quickly identify and mitigate potential vulnerabilities. Where feasible, we implement **data segregation measures** to limit third-party access to only the data required for their role.
For a comprehensive list of approved subprocessors and the services they provide, visit the [**Chkk Trust Center**](/security/trust-center). There, you will find details on their **geographic location, types of personal data processed, and relevant compliance credentials**. In the event of significant changes to our subprocessor list, we will notify customers promptly to maintain transparency and trust.
If you have any questions about a specific vendor or would like more details on our third-party risk management process, reach out to us at [privacy@chkk.io](mailto:privacy@chkk.io) or consult Chkk Trust Center.
# Terms of Service
Source: https://docs.chkk.io/security/tos
## Master Subscription Agreement
Updated October 2023
This Chkk Master Subscription Agreement ("MSA") is effective as of the effective date of an applicable signed order form ( "Order Form" and such date the "Effective Date") and is by and between Chkk Inc., a Delaware corporation with a place of business at 440 North Wolfe Road, Sunnyvale, CA, 94085 ("Chkk"), and the customer (i) set forth on the Order Form or (ii) who registers for the Services on a free trial basis ("Trial Services"), and in each case, accepts this MSA (each, a "Customer") (each a "Party" and together the "Parties"). In the event of any inconsistency or conflict between the terms of the MSA and the terms of any Order Form, the terms of the Order Form control. If Customer is provided with access to the Services on a free trial basis, the section of this Agreement entitled "Free Trial Services" will govern such access and, unless as otherwise indicated on an applicable Order Form, certain of Chkk's obligations under this MSA will not apply, as further described below.
### Section 1. Services
The "Services" mean the products and services that are ordered by Customer from Chkk in an Order Form referencing this MSA or, if applicable, the Trial Services that are made available to Customer. Services exclude any products or services provided by third parties, even if Customer has connected those products or services to the Services. Subject to the terms and conditions of this MSA, Chkk will make the Services available to Customer during the Term.
### Section 2. Fees and Payment.
**2.1. Fees.** Customer will pay the fees specified in the Order Form (the "Fees").
**2.2. Payment; Taxes.** Customer shall keep a payment method on file with Chkk for payment of Fees. Chkk shall invoice Customer for Fees, either within the Services or directly, within thirty (30) days of the Effective Date, the start of the Renewal Term (as defined below), or otherwise as specified in the Order Form. Customer shall pay all invoiced Fees (i) charged automatically via the payment method associated with Customer's account for the Services or (ii) if agreed otherwise in writing by both parties, upon receipt of such invoice. In the event of non-payment of Fees by Customer for thirty (30) days after the due date of an invoice, Customer's access to the Services may be immediately suspended and Customer must pay the entire remaining balance of Fees to regain access to the Services. Fees do not include local, state, or federal taxes or duties of any kind and any such taxes will be assumed and paid by Customer, except for taxes on Chkk based on Chkk's income or receipts.
**2.3. Price Changes.** Chkk may change prices for the Services from time to time, in its sole discretion. Any price changes will be effective upon the commencement of Customer's next Renewal Term; provided, that Chkk shall provide Customer with reasonable notice of any such fee increase prior to the expiration of the Term or any Renewal Term.
**2.4. Discounts and Promotional Pricing.** Prices specified in the Order Form may include discounts or promotional pricing. These discounts or promotional pricing amounts may be temporary and may expire upon the commencement of a Renewal Term, without additional notice. Chkk reserves the right to discontinue or modify any promotion, sale or special offer at its sole and reasonable discretion.
**2.5 Free Trial Services.** If Customer is granted access to Trial Services, Chkk will make the applicable Trial Services available to Customer pursuant to this MSA starting from the time that Customer registers and is approved for such Trial Services until the earlier of: (a) the end of the Trial Services period communicated to Customer; (b) the start date of any Order Form executed by Customer for Service(s) in exchange for payment; or (c) termination by Chkk in its sole discretion.
ANY CUSTOMER INFORMATION THAT CUSTOMER PROVIDES OR MAKES AVAILABLE TO CHKK DURING THE PROVISION OF TRIAL SERVICES MAY BE PERMANENTLY DELETED, AT CHKK'S DISCRETION, UNLESS CUSTOMER EXECUTES AN ORDER FORM FOR THE SAME SERVICES AS THOSE COVERED BY THE TRIAL SERVICES OR EXPORTS SUCH CUSTOMER INFORMATION BEFORE THE END OF THE TRIAL SERVICES PERIOD.
NOTWITHSTANDING THE "REPRESENTATIONS, WARRANTIES AND DISCLAIMERS" SECTION AND "INDEMNIFICATION" SECTION BELOW, FREE TRIAL SERVICES ARE PROVIDED "AS-IS" WITHOUT ANY WARRANTY AND CHKK SHALL HAVE NO INDEMNIFICATION OBLIGATIONS NOR LIABILITY OF ANY TYPE WITH RESPECT TO THE TRIAL SERVICES UNLESS SUCH EXCLUSION OF LIABILITY IS NOT ENFORCEABLE UNDER APPLICABLE LAW IN WHICH CASE CHKK'S LIABILITY WITH RESPECT TO THE TRIAL SERVICES SHALL NOT EXCEED \$1,000.00. NOTWITHSTANDING ANYTHING TO THE CONTRARY IN THE "LIMITATION OF LIABILITY" SECTION BELOW, CUSTOMER SHALL BE FULLY LIABLE UNDER THIS AGREEMENT TO CHKK AND ITS AFFILIATES FOR ANY DAMAGES ARISING OUT OF CUSTOMER'S USE OF THE TRIAL SERVICES, ANY BREACH BY CUSTOMER OF THIS AGREEMENT AND ANY OF CUSTOMER'S INDEMNIFICATION OBLIGATIONS HEREUNDER.
### Section 3. Term and Termination.
**3.1. Term and Renewal.** This MSA commences on the Effective Date and will remain in effect through the term specified in the Order Form (or, in the case of Trial Services, for the period of time as agreed upon between Chkk and Customer), and will renew as specified in the Order Form unless otherwise terminated in accordance with this Section (collectively the "Term"). If the Order Form does not specify, the Term will be one year and will automatically renew for successive one-year periods unless Customer provides Chkk with notice of termination at least thirty (30) days prior to the end of the Term (a "Renewal Term").
**3.2. Termination for Cause.** A Party may terminate this MSA for cause (a) immediately upon notice to the other Party of a material breach if such breach remains uncured after thirty (30) days from the date of the breaching Party's receipt of such notice; (b) immediately upon notice to the other Party if the other Party becomes the subject of a petition in bankruptcy or any other proceeding relating to insolvency, receivership, liquidation or assignment for the benefit of creditors; or (c) immediately upon written notice by Chkk to Customer for any use of the Services in violation of Section 4.5 (Prohibited Uses) below. Non-payment of Fees by Customer for sixty (60) days after issuance of an invoice, and any violation of the Prohibited Uses clause below will be considered material breaches of this MSA.
**3.2.A. Termination for Convenience During Initial Period.** Notwithstanding anything to the contrary in this Agreement, Customer may terminate this MSA for convenience within thirty (30) calendar days of the Effective Date (the "Initial Termination Period") by providing Chkk with written notice of termination. In such event: (a) Chkk shall refund to Customer the prepaid annual subscription fees less an amount equal to one (1) month of subscription fees, which amount shall be retained by Chkk as a non-refundable onboarding and administrative charge; and (b) any such refund shall be issued within sixty (60) calendar days following the effective date of termination.
For the avoidance of doubt, no refund shall be available after the Initial Termination Period, and this Section 3.2.A does not apply to any fees other than the annual subscription fees (e.g., fees for professional services, implementation, or third-party services, which shall be non-refundable unless otherwise agreed in writing).
**3.3. Effect of Termination and Survival.** Upon termination of an Order Form or this MSA (a) with respect to termination of the entire MSA, all Order Forms will concurrently terminate, (b) Customer will have no further right to, and shall cease and ensure its Authorized Users cease, use the Services under the terminated or cancelled Order Forms and Chkk will remove Customer's access to same, and (c) unless otherwise specified in writing, Customer will not be entitled to any refund of fees paid. The following Sections will survive termination: Section 2 (Fees and Payment), Section 4 (Ownership), Section 5 (Confidentiality), Section 7.3 (Disclaimers), Section 8 (Indemnification), Section 9 (Limitation of Liability), and Section 10 (Miscellaneous). Termination of this MSA will not limit a Party's liability for obligations accrued as of or prior to such termination or for any breach of this MSA.
### Section 4. Ownership, License, and Use of the Services.
**4.1. Ownership.** Each Party will retain all rights, title and interest in any of its patents, inventions, copyrights, trademarks, domain names, trade secrets, know-how and any other intellectual property and/or proprietary rights ("Intellectual Property Rights"). Chkk will retain Intellectual Property Rights in the Services and all components of, or used to, provide the Services or created by the Services or by Chkk in the course of providing the Services (the "Services Information"). Customer will retain Intellectual Property Rights in all information it provides to Chkk as part of this MSA (other than Feedback as described below), including but not limited to in the course of its use of the Services (the "Customer Information").
**4.2. Feedback.** Customer may, under this MSA, provide suggestions, enhancement requests, recommendations about the Services, or other feedback to Chkk (the "Feedback"). Customer provides Chkk a fully paid-up, royalty-free, worldwide, transferable, sub-licensable (through multiple layers), assignable, irrevocable and perpetual license to implement, use, modify, commercially exploit, incorporate into the Services, or otherwise use any Feedback. Chkk also reserves the right to seek intellectual property protection for any features, functionality or components that may be based on or that were initiated by such Feedback.
**4.3. Licenses.** Chkk hereby grants Customer a non-exclusive, non-transferable (except as set forth in Section 10.2), non-sublicensable right to and license during the Term to access and use, and permit Authorized Users to access and use, the Services as set forth in the Order Form or on a Trial Services basis all subject to the terms and conditions of this MSA and the Order Form (if applicable). Customer hereby grants Chkk a non-exclusive, non-transferable (except as set forth in Section 10.2) right and license to use, including through the use of subcontractors, the Customer Information solely to provide the Services to Customer.
**4.4. Authorized Users.** Customer may designate and provide access to the Services to employees, agents, or authorized contractors (each an "Authorized User"). Customer is responsible for all use and misuse of the Services by Authorized Users and for adherence to all terms of this MSA by any Authorized Users, and references to Customer herein will be deemed to apply to Authorized Users as necessary and applicable. Customer agrees to promptly notify Chkk of any unauthorized access or use of which Customer becomes aware. Authorized Users are strictly prohibited from sharing their accounts or account passwords and their doing so is a material breach of this MSA by Customer.
**4.5. Prohibited Uses.** Customer and Authorized Users will not: (a) "frame," distribute, resell, or permit access to the Services by any third party other than as allowed by the features and functionality of the Services; (b) use the Services in violation of applicable laws; (c) interfere with, disrupt, or gain unauthorized access to the Services; (d) successfully or otherwise, attempt to: decompile, disassemble, reverse engineer, discover the underlying source code or structure of, or copy the Services; (e) provide Chkk any Customer Information or Feedback that is unlawful, defamatory, harassing, discriminatory, or infringing of third party intellectual property rights; (f) transfer to the Services or otherwise use on the Services any code, exploit, or undisclosed feature that is designed to delete, disable, deactivate, interfere with or otherwise harm or provide unauthorized access to the Services; (g) use any robot, spider, data scraping, or extraction tool or similar mechanism with respect to the Services; (h) provide access to the Services to an individual associated with a Chkk Competitor (defined below); (i) extract information from the Services in furtherance of competing with Chkk; (j) encumber, sublicense, transfer, rent, lease, time-share or use the Services in any service bureau arrangement or otherwise for the benefit of any third party; (k) copy, distribute, manufacture, adapt, create derivative works of, translate, localize, port or otherwise modify any aspect of the Services; (l) introduce into the Services any software containing a virus, worm, "back door," Trojan horse or similarly harmful code; or (m) permit any third party to engage in any of the foregoing proscribed acts. A "Chkk Competitor" is any entity that provides the same or similar goods and services to those provided by Chkk, as would be determined by a commercially reasonable individual. Customer will promptly notify Chkk of any violations of the above prohibited uses by an Authorized User or a third party and require such Authorized User or third party to immediately cease any such use. Chkk reserves the right to suspend Customer and/or Authorized User's access to the Services in the event Chkk suspects Customer or an Authorized User is in breach of this MSA.
**4.6 Usage Data.** Chkk may collect Usage Data and use it to operate, improve, and support the Services, and for other lawful business practices; however, Chkk will not disclose Usage Data externally unless it is (a) de-identified so that it does not identify Customer, its Authorized Users or any other person and (b) aggregated with data across other customers. "Usage Data" means technical logs, metrics and performance data, which may be derived from or include Customer Information (or part thereof) relating to the operation, delivery and use of the Services.
### Section 5. Confidentiality.
"Confidential Information" of a Party (the "Disclosing Party") means all financial, technical, or business information of the Disclosing Party that the Disclosing Party designates as confidential at the time of disclosure to the other Party (the "Receiving Party") or that the Receiving Party reasonably should understand to be confidential based on the nature of the information or the circumstances surrounding its disclosure. For the avoidance of doubt, Confidential Information of: (1) Chkk shall include the Services Information, and (2) Customer shall include Customer Information. Except as expressly permitted in this MSA, the Receiving Party will not disclose, duplicate, publish, transfer or otherwise make available Confidential Information of the Disclosing Party in any form to any person or entity without the Disclosing Party's prior written consent. The Receiving Party will not use the Disclosing Party's Confidential Information except to perform its obligations under this MSA, such obligations including, in the case of Chkk, to provide the Services. Notwithstanding the foregoing, the Receiving Party may disclose Confidential Information to the extent required by law, provided that the Receiving Party: (a) gives the Disclosing Party prior written notice of such disclosure so as to afford the Disclosing Party a reasonable opportunity to appear, object, and obtain a protective order or other appropriate relief regarding such disclosure (if such notice is not prohibited by applicable law); (b) uses diligent efforts to limit disclosure and to obtain confidential treatment or a protective order; and (c) allows the Disclosing Party to participate in the proceeding. Further, Confidential Information does not include any information that: (i) is or becomes generally known to the public without the Receiving Party's breach of any obligation owed to the Disclosing Party; (ii) was independently developed by the Receiving Party without use or reference to the Disclosing Party's confidential information and without the Receiving Party's breach of any obligation owed to the Disclosing Party; or (iii) is received from a third party who obtained such Confidential Information without any third party's breach of any obligation owed to the Disclosing Party.
### Section 6. Privacy and Security Practices.
Chkk's current security practices (the "Security Statement), privacy, and data protection practices are set forth at [https://www.chkk.io/privacy-policy](https://www.chkk.io/privacy-policy) (the "Privacy Policy").
### Section 7. Representations, Warranties, and Disclaimers.
**7.1. Authority.** Each Party represents that it has validly entered into this MSA and has the legal power to do so.
**7.2. Warranties.** Chkk warrants that during an applicable Term (a) the Security Statement accurately describes the applicable administrative, physical, and technical safeguards for protection of the security, confidentiality, and integrity of Customer Information; and (b) the Services will perform materially in accordance with any applicable documentation provided to Customer. For any breach of a warranty in this section, Customer's sole and exclusive remedy is Customer's right to terminate this Agreement for Chkk's uncured materials breach in accordance with Section 3.2(a) (Term and Termination) herein.
**7.3. Disclaimers.** EXCEPT AS SPECIFICALLY SET FORTH IN THIS SECTION, THE SERVICES, INCLUDING ALL SERVER AND NETWORK COMPONENTS, ARE PROVIDED ON AN "AS IS" AND "AS AVAILABLE" BASIS, WITHOUT ANY WARRANTIES OF ANY KIND TO THE FULLEST EXTENT PERMITTED BY LAW, AND CHKK EXPRESSLY DISCLAIMS ANY AND ALL WARRANTIES, WHETHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, TITLE, FITNESS FOR A PARTICULAR PURPOSE, AND NON-INFRINGEMENT. CUSTOMER ACKNOWLEDGES THAT CHKK DOES NOT WARRANT THAT THE SERVICES WILL BE UNINTERRUPTED, TIMELY, SECURE, ERROR-FREE, OR FREE FROM VIRUSES OR OTHER MALICIOUS SOFTWARE, AND NO INFORMATION OR ADVICE OBTAINED BY CUSTOMER FROM CHKK OR THROUGH THE SERVICES SHALL CREATE ANY WARRANTY NOT EXPRESSLY STATED IN THIS MSA. THE PARTIES ADDITIONALLY AGREE THAT CHKK WILL HAVE NO LIABILITY OR RESPONSIBILITY FOR CLIENT'S VARIOUS COMPLIANCE PROGRAMS, AND THAT THE SERVICES, TO THE EXTENT APPLICABLE, ARE ONLY TOOLS FOR ASSISTING CLIENT IN MEETING THE VARIOUS COMPLIANCE OBLIGATIONS FOR WHICH IT SOLELY IS RESPONSIBLE.
### Section 8. Indemnification.
**8.1. Indemnification by Chkk.** Chkk will indemnify and hold Customer harmless from any third party claim against Customer alleging that Customer's use of the Services as authorized in this MSA infringe or misappropriate a third party's valid patent, copyright, trademark, or trade secret. Chkk will, at its expense, defend such claim and pay damages finally awarded against Customer in connection therewith, including the reasonable fees and expenses of the attorneys engaged by Chkk for such defense, provided that (a) Customer promptly notifies Chkk of the threat or notice of such claim (provided that, a delay in providing notice does not excuse the Chkk's obligations unless Chkk is prejudiced by such delay); (b) Chkk will have the sole and exclusive control and authority to select defense attorneys, and defend and/or settle any such claim (however, Chkk will not settle or compromise any claim that results in liability or admission of any liability by Customer without prior written consent); and (c) at Chkk's request and expense, Customer fully cooperates with Chkk in connection therewith. Customer may participate and retain its own counsel at its own expense. If use of a Service by Customer has become, or, in Chkk's opinion, is likely to become, the subject of any such claim, Chkk may, at its option and expense, (i) procure for Customer the right to continue using the Service(s) as set forth hereunder; (ii) replace or modify a Service to make it non-infringing; or (iii) if options (i) or (ii) are not commercially reasonable or practicable as determined by Chkk, terminate this MSA and repay, on a pro-rata basis, any Fees previously paid to Chkk for the corresponding unused portion of the Term for related Services. Chkk will have no liability or obligation under this Section with respect to any claim if such claim is caused in whole or in part by (x) compliance with designs, data, instructions or specifications provided by Customer; (y) modification of the Services by anyone other than Chkk; or (z) the combination, operation or use of the Services with other hardware or software where the Services would not otherwise be infringing. The provisions of this Section state the sole, exclusive, and entire liability of Chkk to Customer and constitute Customer's sole remedy with respect to an infringement claim brought by reason of access to or use of a Service by Customer or Authorized Users. Notwithstanding anything to the contrary herein, Chkk shall have no obligation under this Section 8.1 with respect to Trial Services.
**8.2. Indemnification by Customer.** Customer will indemnify and hold Chkk harmless against any third party claim arising out of (a) Prohibited Uses in breach of this MSA as set forth above; or (b) alleging that Customer Information infringes or misappropriates a third party's valid patent, copyright, trademark, or trade secret; provided (i) Chkk promptly notifies Customer of the threat or notice of such claim (provided that, a delay in providing notice does not excuse the Customer's obligations unless the Customer is prejudiced by such delay); (ii) Customer will have the sole and exclusive control and authority to select defense attorneys, and defend and/or settle any such claim (however, Customer will not settle or compromise any claim that results in liability or admission of any liability by Chkk without prior written consent); and (iii) at Customer's request and expense, Chkk fully cooperates in connection therewith. Chkk may participate and retain its own counsel at its own expense.
### SECTION 9. LIMITATION OF LIABILITY.
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, AND EXCEPT FOR A PARTY'S INDEMNIFICATION OBLIGATIONS AND DEFENSE OBLIGATIONS, BREACHES OF CONFIDENTIALITY, OR FOR DAMAGES DUE TO PROHIBITED USES (COLLECTIVELY, "EXCLUDED CLAIMS"), UNDER NO CIRCUMSTANCES AND UNDER NO LEGAL THEORY (WHETHER IN CONTRACT, TORT, NEGLIGENCE OR OTHERWISE) WILL EITHER PARTY TO THIS MSA, OR THEIR AFFILIATES, OFFICERS, DIRECTORS, EMPLOYEES, AGENTS, SERVICE PROVIDERS, SUPPLIERS OR LICENSORS BE LIABLE TO THE OTHER PARTY OR ANY AFFILIATE FOR ANY LOST PROFITS, LOST SALES OR BUSINESS, LOST DATA (BEING DATA LOST IN THE COURSE OF TRANSMISSION VIA CUSTOMER'S SYSTEMS OR OVER THE INTERNET THROUGH NO FAULT OF CHKK), BUSINESS INTERRUPTION, LOSS OF GOODWILL, COSTS OF COVER OR REPLACEMENT, OR FOR ANY TYPE OF INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, CONSEQUENTIAL OR PUNITIVE LOSS OR DAMAGES, OR ANY OTHER INDIRECT LOSS OR DAMAGES INCURRED BY THE OTHER PARTY OR ANY AFFILIATE IN CONNECTION WITH THIS MSA OR THE SERVICES REGARDLESS OF WHETHER SUCH PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF OR COULD HAVE FORESEEN SUCH DAMAGES. NOTWITHSTANDING ANYTHING TO THE CONTRARY IN THIS MSA, EITHER PARTY'S AGGREGATE LIABILITY TO THE OTHER PARTY OR ANY THIRD PARTY ARISING OUT OF THIS MSA OR THE SERVICES WILL IN NO EVENT EXCEED THE FEES PAID OR PAYABLE BY CUSTOMER DURING THE TWELVE (12) MONTHS PRIOR TO THE FIRST EVENT OR OCCURRENCE GIVING RISE TO SUCH LIABILITY; PROVIDED THAT A PARTY'S LIABILITY ARISING FROM EXCLUDED CLAIMS WILL NOT IN THE AGGREGATE EXCEED TWO TIMES THAT AMOUNT. FOR CLARITY, NOTHING IN THIS MSA WILL LIMIT OR EXCLUDE EITHER PARTY'S LIABILITY FOR GROSS NEGLIGENCE OR INTENTIONAL MISCONDUCT OF A PARTY. CUSTOMER ACKNOWLEDGES AND AGREES THAT THE ESSENTIAL PURPOSE OF THIS SECTION IS TO ALLOCATE THE RISKS UNDER THIS MSA BETWEEN THE PARTIES AND LIMIT POTENTIAL LIABILITY GIVEN THE FEES, WHICH WOULD HAVE BEEN SUBSTANTIALLY HIGHER IF CHKK WERE TO ASSUME ANY FURTHER LIABILITY OTHER THAN AS SET FORTH HEREIN. CHKK HAS RELIED ON THESE LIMITATIONS IN DETERMINING WHETHER TO PROVIDE CUSTOMER WITH THE RIGHTS TO ACCESS AND USE THE SERVICES PROVIDED FOR IN THIS MSA. THE DISCLAIMERS, EXCLUSIONS, AND LIMITATIONS OF LIABILITY UNDER THIS AGREEMENT WILL NOT APPLY TO THE EXTENT PROHIBITED BY APPLICABLE LAW.
### Section 10. Miscellaneous.
**10.1. Entire Agreement.** This MSA, any active Order Forms, if applicable, constitute the entire agreement, and supersedes all prior agreements, between Chkk and Customer regarding the subject matter hereof.
**10.2. Assignment.** Except as otherwise expressly permitted in this MSA, neither party may assign its rights or obligations under this MSA without the other party's prior written consent (not to be unreasonably withheld, conditioned or delayed. Either Party may, without the consent of the other Party, assign this MSA to any affiliate or in connection with any merger, change of control, or the sale of all or substantially all of such Party's assets provided that (1) the other Party is provided prior notice of such assignment and (2) any such successor agrees to fulfill its obligations pursuant to this MSA. Subject to the foregoing restrictions, this MSA will be fully binding upon, inure to the benefit of and be enforceable by the Parties and their respective successors and assigns. Any attempted assignment or transfer of this MSA in contravention of the foregoing shall be null and void.
**10.3. Severability.** If any provision in this MSA is held by a court of competent jurisdiction to be unenforceable, such provision will be modified by the court and interpreted so as to best accomplish the original provision to the fullest extent permitted by law, and the remaining provisions of this MSA will remain in effect.
**10.4. Relationship of the Parties.** The Parties are independent contractors. This MSA does not create a partnership, franchise, joint venture, agency, fiduciary, or employment relationship between the Parties.
**10.5. Notices.** All notices provided by Chkk to Customer under this MSA may be delivered in writing (a) by nationally recognized overnight delivery service ("Courier") or U.S. mail to the contact mailing address provided by Customer on the Order Form; or (b) electronic mail to the electronic mail address provided for Customer's account owner. Customer must give notice to Chkk either in writing by Courier or U.S. mail to 440 North Wolfe Road, Sunnyvale, CA, 94085 Attn: Legal Department or by email to [legal@chkk.io](mailto:legal@chkk.io). All notices shall be deemed to have been given immediately upon delivery by electronic mail; or, if otherwise delivered upon the earlier of receipt or two (2) business days after being deposited in the mail or with a Courier as permitted above.
**10.6. Governing Law, Jurisdiction, Venue.** This MSA will be governed by the laws of the State of California, without reference to conflict of laws principles. Any disputes under this MSA shall be resolved in a court of general jurisdiction in San Francisco County, California. Customer hereby expressly agrees to submit to the exclusive personal jurisdiction and venue of such courts for the purpose of resolving any dispute relating to this MSA or access to or use of the Services by Customer, its agents, or Authorized Users.
**10.7. Export Compliance.** The Services and other software or components of the Services that Chkk may provide or make available to Customer are subject to U.S. export control and economic sanctions laws as administered and enforced by the Office of Foreign Assets and Control of the United States Department of Treasury. Customer will not access or use the Services if Customer or any Authorized Users are located in any jurisdiction in which the provision of the Services, software, or other components is prohibited under U.S. or other applicable laws or regulations (a "Prohibited Jurisdiction") and Customer will not provide access to the Services to any government, entity, or individual located in any Prohibited Jurisdiction. Customer represents and warrants that (a) it is not named on any U.S. government list of persons or entities prohibited from receiving U.S. exports, or transacting with any U.S. person; (b) it is not a national of, or a company registered in, any Prohibited Jurisdiction; (c) it will not permit any individuals under its control to access or use the Services in violation of any U.S. or other applicable export embargoes, prohibitions or restrictions; and (d) it will comply with all applicable laws regarding the transmission of technical data exported from the United States and the countries in which it and Authorized Users are located.
**10.8. Anti-Corruption.** Customer represents and agrees that it has not received or been offered any illegal or improper bribe, kickback, payment, gift, or thing of value from any of Chkk's employees or agents in connection with this MSA. Reasonable gifts and entertainment provided in the ordinary course of business do not violate the above restriction. If Customer learns of any violation of the above restriction, Customer will use reasonable efforts to promptly give notice to Chkk.
**10.9. Publicity and Marketing.** Chkk may use Customer's name, logo, and trademarks solely to identify Customer as a client of Chkk on Chkk's website and other marketing materials and in accordance with Customer's trademark usage guidelines. Chkk may share aggregated and/or anonymized information regarding use of the Services with third parties for marketing purposes to develop and promote Services. Chkk never will disclose aggregated and/or anonymized information to a third party in a manner that would identify Customer or any identifiable individual as the source of the information.
**10.10. Amendments.** Chkk may amend this MSA from time to time, in which case the new MSA will supersede prior versions. Chkk will notify Customer not less than ten (10) days prior to the effective date of any such amendment and Customer's continued use of the Services following the effective date of any such amendment may be relied upon by Chkk as consent to any such amendment.
**10.11. Waiver.** Chkk's failure to enforce at any time any provision of this MSA does not constitute a waiver of that provision or of any other provision of this MSA.
# Trust Center and Transparency
Source: https://docs.chkk.io/security/trust-center
Chkk is committed to transparency in our security practices, ensuring customers have access to clear, comprehensive information about how we protect their data. The [**Chkk Trust Center**](https://trust.chkk.io/) serves as a central resource where customers can review security documentation, compliance reports, and details about our security programs.
We provide up-to-date **compliance certifications, penetration testing reports, and security questionnaires**, giving customers the assurance that our platform meets industry standards. Our commitment to transparency extends to **third-party security audits**, which validate our adherence to best practices and regulatory requirements.
Customers can access detailed documentation on **encryption practices, access controls, and incident response procedures**, ensuring they understand the security measures in place. Our Trust Center also offers **frequently asked questions (FAQs) and best practice guides**, providing guidance on securely integrating Chkk into enterprise environments.
For organizations with specific compliance requirements, we facilitate security assessments and provide necessary artifacts under appropriate agreements. Our security team is available to address concerns and collaborate on security reviews.
To explore the full range of security documentation, compliance resources, and best practices, visit the [**Chkk Trust Center**](https://trust.chkk.io/) for the latest updates and insights into our security posture. Our Trust Center provides customers with direct access to key security and compliance documents, offering a comprehensive view into our security posture. These include:
* **SOC 2 Type II Reports**
* **Penetration Testing Summary**
* **CAIQv4.0.3**
* **Product Security Overview Documents**
* **Chkk Architecture and Dataflow Diagram**
* **W9**
* **Certificate of Liability Insurance**
* *And more*
These resources provide customers with a transparent view into how Chkk safeguards data and upholds security best practices. Visit the [**Chkk Trust Center**](https://trust.chkk.io/) to explore these documents and stay informed on our latest security updates.
Chkk Trust Center is only accessible to existing and prospective customers.
# Avoid 6x Extended Support Fees
Source: https://docs.chkk.io/usecases/avoid-extended-support-fees
The 500% surcharge for running outdated cluster versions on services like EKS, AKS, and GKE can have a significant financial impact on organizations, and Chkk directly addresses this issue through its platform.
## Impact of the 500% Surcharge
* **Hefty cost increases**: Starting in 2024, organizations using services such as Amazon EKS, Google GKE, and Azure AKS are subject to surcharges of up to 500% for running outdated cluster versions. This means that if an organization fails to upgrade to the latest supported version, their costs can increase dramatically.
* **Compliance risk**: Outdated software versions pose security and operational safety risks, and can lead to non-compliance with industry standards.
* **Resource strain**: Upgrading clusters and tens of Cloud Native Projects, application services, and operators running in a cluster is a complex and resource-intensive task, and without proper tools, teams may struggle to keep up with the required upgrades, leading to higher costs.
## How Chkk Addresses the Surcharge Issue
Chkk's Operational Safety Platform is designed to help organizations avoid these surcharges and maintain their systems efficiently.
* **Streamlined upgrade process**: Chkk automates many tasks associated with Cloud Native upgrades, such as researching dependencies and release notes across hundreds of Cloud Native Project versions, which cuts down research and planning time by up to 8x. Chkk's Upgrade Copilot automates the tedious pre-work, delivers Preverified Upgrade Plans tested on a digital twin of the infrastructure, and provides detailed execution steps with automated checks.
* **Reduced effort and time**: By automating pre-work, Chkk reduces upgrade efforts from what could take 10 FTE-days over four weeks to less than 2 FTE-days over two weeks. This efficiency means that upgrades can be completed more quickly, preventing teams from falling behind and incurring surcharges.
* **Timely upgrades**: Chkk ensures that users perform timely upgrades, thus avoiding surcharges. It does this by providing a comprehensive technical roadmap for each cluster and delivering Preverified Upgrade Plans tailored to the current state of the system.
* **Proactive alerts**: Chkk maintains an accurate inventory of all clusters and Cloud Native Projects, and alerts users to existing and upcoming End-of-Life (EOL) software. By identifying outdated software, Chkk enables organizations to upgrade before incurring the 500% surcharge.
* **Cost savings**: By avoiding the surcharges and streamlining the upgrade process, Chkk can save organizations a significant amount of money. Chkk can save up to \$450,000 annually for every 100 clusters by avoiding these surcharges.
* **Enhanced compliance**: By performing timely upgrades, Chkk helps organizations avoid vulnerabilities, ensure vendor support, and stay compliant with industry standards, thus avoiding additional costs and risks.
Chkk directly addresses the financial impact of the 500% surcharge for outdated versions by providing tools and features that enable timely and efficient upgrades, thereby avoiding unnecessary costs, compliance issues, and operational risks. Chkk can save organizations considerable resources and help them stay ahead of upgrade deadlines.
# Delegate, Parallelize, and Standardize Workflows
Source: https://docs.chkk.io/usecases/delegate-parallelize-standardize-workflows
Delegate, Parallelize, and Standardize Workflows:
Standardization and delegation are critical for efficient Cloud Native operations, and Chkk's platform is designed to support these concepts, leading to enhanced organizational productivity and agility.
## The Importance of Standardization
* **Consistency and Reduced Errors**: Standardizing workflows and processes ensures that all teams use the same methods and tools, reducing the likelihood of errors and inconsistencies. When every team follows the same standardized procedures for upgrades, for example, there are fewer chances of human error, misconfigurations, or omissions
* **Knowledge Sharing and Reuse**: Standardization enables the sharing of best practices, templates, and knowledge across an organization. Chkk provides customized templates and contextualized insights that can be shared organization-wide, preventing redundant effort and ensuring that everyone is on the same page.
* **Efficiency**: With standardized processes, teams can execute tasks more efficiently. For instance, Chkk standardizes upgrade tooling and processes, leading to reduced research and planning time. This prevents the duplication of effort that often occurs when different teams work in isolation.
* **Centralized System of Record**: A standardized approach allows for the creation of a centralized system of record, where all work and knowledge are documented and easily accessible. This is crucial during reorganizations or team changes, as it helps to retain institutional knowledge and reduces the time required to find information, which minimizes context switching.
## The Importance of Delegation
* **Empowering Teams**: Delegation enables organizations to distribute tasks and responsibilities across different team members, thus empowering teams. When tasks are clearly defined, team members can take ownership and make decisions within their assigned roles, which enhances efficiency.
* **Focus on Strategic Initiatives**: By delegating routine tasks, experts can be freed up to focus on more strategic initiatives, which include innovation projects and problem-solving. Chkk's platform streamlines and simplifies complex tasks, allowing teams to delegate these tasks confidently.
* **Scalability**: Delegation is essential for scaling operations, as it allows organizations to handle a larger workload without overburdening their experts. Standardization creates repeatable workflows that are easier to delegate and scale.
* **Reduced bottlenecks**: When experts can delegate tasks, it reduces bottlenecks that can delay operations. Standardized processes make it possible for a larger number of team members to carry out upgrades and maintenance, which results in parallel workflows2....
## How Chkk's Platform Supports Standardization and Delegation
* **Upgrade Copilot**: Chkk's Upgrade Copilot provides preverified upgrade plans with detailed steps that are standardized and tested. These plans are tested on a digital twin of the infrastructure, which ensures that the upgrade process is consistent and safe. They include automated pre-flight and post-flight checks which standardize the execution and verification of the upgrade process. These plans can be used across teams, ensuring that all upgrades are performed in the same way.
* **Artifact Register**: Chkk's Artifact Register helps to standardize the way assets are tracked across different clusters and clouds. By providing a centralized view of all components, container images, repositories, and tools, it eliminates the need for manual and error-prone methods of tracking.
* **Knowledge Sharing**: Chkk facilitates knowledge sharing by providing a system of record for upgrades and maintenance. This helps to reduce context switching and improve productivity. Chkk captures best practices, release notes, and other relevant information in its Risk Signature Database, enabling the sharing of knowledge organization-wide.
* **Simplified Workflows**: The platform standardizes workflows, making it easier to delegate tasks to any team member. It simplifies complex tasks by automating tedious pre-work and providing step-by-step guidance, enabling the delegation of tasks that previously required expert knowledge.
* **Templates and Best Practices**: Chkk allows the sharing of customized templates and contextualized insights. This ensures that all teams adhere to the same best practices, improving overall operational safety and consistency.
* **Reduced Errors**: By standardizing tasks and delegating them to other team members, the likelihood of human errors is reduced. Chkk automates and verifies each step of the upgrade, which helps to prevent errors.
By supporting standardization and delegation, Chkk enhances organizational productivity and agility. Teams can work more efficiently, reduce the risk of errors, and focus on innovation, leading to better outcomes overall. Chkk's platform facilitates a more consistent and scalable approach to Cloud Native operations.
# Enhance Operational Safety
Source: https://docs.chkk.io/usecases/enhance-operational-safety
Chkk's Operational Safety Platform significantly enhances the operational safety posture of organizations using Cloud Native technologies by offering a range of tangible technical benefits. The platform is designed to proactively identify, manage, and remediate risks, ensuring a more stable, secure, and efficient operational environment.
## Key Technical Benefits for Enhanced Operational Safety
* **Proactive Risk Detection**: Chkk identifies operational risks before they cause breakages, moving from a reactive to a proactive approach. The platform scans environments for configuration mistakes, incompatibilities, deprecations, and other risk factors. By detecting issues like feature flag renames in Cloud Native Projects, application services, and operators, the platform alerts teams to potential problems before they escalate into incidents. This proactive identification is facilitated by Chkk's Risk Ledger, which is tailored specifically for identifying contextualized Operational Risks within Cloud Native infrastructures.
* **Risk Signature Database (RSig DB) and Knowledge Graph**: At the core of Chkk's proactive approach is the RSig DB, which acts like a CVE database for operational risks. This database, along with a Knowledge Graph, captures relationships across different artifacts like issues, release notes, and breaking changes. The platform continuously sources information from the internet, release notes, bug reports, and user feedback to populate the RSig DB, ensuring that customers learn from a wide array of sources and experiences. This enables Chkk to convert these learnings into "Risk Signatures" which are then streamed to customers to be scanned against their specific infrastructures, identifying potential risks before they cause disruptions.
* **Preverified Upgrade Templates and Plans**: Chkk provides preverified upgrade templates and plans that include a detailed sequence of steps for upgrades and remediations. These plans are tested on a digital twin of the customer's infrastructure to validate their effectiveness before implementation. By automating the pre-work, such as researching dependencies and curating release notes, Chkk cuts down research and planning time by up to 8x. These plans also include automated preflight and post-flight checks that enhance the safety and reliability of upgrades by validating system health at every stage.
* **Reduced Breakages and Downtime**: By identifying and fixing operational risks proactively, Chkk helps customers avoid costly downtime. The platform helps to offset 500+ breakages for every 100 clusters. This not only saves money but also maintains a high level of operational reliability and service availability.
* **Minimized Human Error**: Chkk reduces the chance of human errors and omissions through its standardized workflows and simplified tasks. By automating and verifying each step of the upgrade, Chkk ensures that upgrades are executed consistently. The platform's ability to delegate tasks to any team member further minimizes risks associated with the dependence on expert knowledge.
* **Compliance with Standards**: The platform helps in maintaining compliance by ensuring timely upgrades and avoiding outdated software versions. Chkk alerts users to existing and upcoming End-of-Life (EOL) software versions. This ensures that organizations adhere to industry standards and avoid vulnerabilities. Additionally, avoiding outdated Kubernetes versions helps prevent the hefty surcharges imposed by services like Amazon EKS, Google GKE, and Azure AKS.
* **Staying ahead with Collective Learning**: Chkk's platform uses Collective Learning, which is based on a large database of risks and their resolutions learned from many sources. By learning from incidents, reports, tickets, issues, and discussions from many sources, Chkk enhances its ability to identify and prevent future risks proactively. This means that by adopting Chkk, organizations are not just benefiting from the platform's existing capabilities, they are also continuously benefiting from the new learnings proactively preventing breakages.
## Impact on Operational Safety Posture
By integrating these technical benefits, Chkk enables organizations to operate Cloud Native environments more safely and efficiently. Chkk's platform allows organizations to achieve a higher degree of operational safety with less manual effort and reduced risk of downtime. The proactive risk detection, combined with preverified upgrade plans and a centralized view of assets, significantly enhances the operational safety posture of any organization leveraging Cloud Native technologies. By using Chkk, teams can move from reactive problem-solving to proactive risk management, resulting in improved system stability, minimized disruptions, and greater overall reliability.
***
Cloud Native upgrades introduce risk, but Chkk ensures you can detect and fix potential issues before they cause breakages. With Chkk's automated risk detection, teams can offset 500+ potential breakages annually for every 100 clusters, preventing disruptions before they happen. This proactive approach saves organizations 1000s of hours of break-fix effort, allowing teams to focus on innovation rather than firefighting issues post-upgrade.
***
# Improve Resource Efficiency
Source: https://docs.chkk.io/usecases/improve-resource-efficiency
Chkk enhances resource efficiency in Cloud Native environments by streamlining operations, reducing manual effort, and preventing costly issues. The platform's features and approach contribute to better resource utilization, cost savings, and improved productivity.\
Many organizations waste 1000s of hours on repetitive upgrade planning and research. Chkk eliminates this multiplicative effort by unifying tooling across teams, ensuring that insights and processes don't have to be reinvented every upgrade cycle. By consolidating upgrade workflows, organizations can recover 1000s of hours that would otherwise be lost to duplicate work.
## Key Ways Chkk Improves Resource Efficiency
* **Upgrade Assessments & Elimination of Redundant Work** - **Upgrade Assessments** map the scope, impact, and dependencies of a Cloud Native upgrade across Platform and Application layers, allowing experts to gauge upgrade readiness and remove blockers for clusters and Cloud Native Projects. By surfacing this insight upfront, Chkk eliminates redundant research and planning tasks that are often duplicated across teams. It provides standardized upgrade tooling and processes, ensuring everyone is on the same page and preventing unnecessary work. By sharing customized templates, insights, and best practices, Chkk saves time and ensures consistent processes.
* **Minimized Break-Fix Efforts** - By proactively identifying and resolving operational risks, Chkk helps to prevent breakages and costly downtime. This reduces the need for reactive problem-solving and saves thousands of hours of break-fix effort for modest-sized infrastructure. Chkk's proactive approach allows teams to focus on strategic initiatives rather than fighting fires.
* **Improved Team Productivity** - By standardizing workflows and simplifying tasks, Chkk enables organizations to delegate work and reduce the chances of human errors. This allows experts to focus on innovation rather than routine tasks. Chkk provides a system of record, maintaining the history of work, which facilitates knowledge sharing and reduces time-to-find information, improving productivity by over 20%.
* **Efficient Use of Expertise** - Chkk allows for the delegation of upgrade tasks, freeing up expert team members to focus on strategic projects. The platform's detailed upgrade templates standardize workflows, making it easy to assign tasks confidently to any team member.
* **Faster Innovation** - By streamlining upgrades and freeing up team resources, Chkk enables organizations to accelerate innovation and achieve business goals faster.
* **Reduced Operational Toil** - Chkk's standardization of workflows and upgrade planning reduces the repetitive and manual tasks that are the source of operational toil.
Chkk's features like the **Upgrade Copilot**, **Upgrade Assessments**, **Artifact Register**, and **Risk Ledger** help streamline operations and reduce wasted effort.
The platform's ability to automate, standardize, and provide proactive risk management helps organizations achieve greater efficiency and optimal use of their resources.
By preventing breakages, reducing cross-team frictions, and avoiding surcharges, organizations using Chkk can optimize their resource usage and minimize unnecessary expenditures.
Overall, Chkk enables teams to do more with less by freeing up resources for innovation, increasing productivity, and reducing the time and effort spent on routine tasks.
# Speedup and Derisk Upgrades
Source: https://docs.chkk.io/usecases/speed-derisk-upgrades
Upgrading Cloud Native infrastructure can be complex and time-consuming, but Chkk makes it faster and safer. For each cluster, Chkk generates a detailed Upgrade Plan that covers all components—control plane, node versions, Cloud Native Projects, application services, operators, and dependencies. It proactively highlights required changes, including recommended Project versions, application services, and operator versions, breaking changes, deprecated APIs that need updates, and misconfigured Pod Disruption Budgets. Instead of manually piecing together upgrade requirements from release notes, teams get a clear, actionable upgrade path with explanations. Chkk's automation cuts upgrade preparation time by 3x-5x, turning weeks of planning into just days.
# Create Repository
Source: https://docs.chkk.io/api-reference/v2/oci/create-repository
post /ocirepositories
Create a new OCIRepository
An OCIRepository represents a single namespace within an OCI Registry.
OCIRepositories are uniquely identified by a URI-like string where the final
path of the URI represents the OCIRepository Namespace and the part of the URI
before the Namespace is the Registry identifier.
Examples of OCIRepository identifiers:
* docker.io/istio/pilot: The pilot namespace in the docker.io/istio
registry.
* public.ecr.aws/bottlerocket/bottlerocket-operator: The
bottlerocket-operator namespace in the public.ecr.aws/bottlerocket
registry.
# Create Tag
Source: https://docs.chkk.io/api-reference/v2/oci/create-tag
post /ocitags
Create a new OCITag
An OCIRepository can publish zero or more OCITags. OCITags are names that
point to a unique OCIArtifact digest.
An OCITag's ID is comprised of the OCIRepository ID followed by a : and the
Tag name.
Examples of OCITag identifiers:
* docker.io/istio/pilot:1.3.0: The 1.3.0 tag on the docker.io/istio/pilot
OCIRepository.
* public.ecr.aws/bottlerocket/bottlerocket-operator:0.1: The 0.1 tag on the
public.ecr.aws/bottlerocket/bottlerocket-operator OCIRepository.
# Delete Reference
Source: https://docs.chkk.io/api-reference/v2/oci/delete-reference
delete /ocireferences/{reference}/
Delete an OCIReference
An OCIReference represents a relationship between an OCITag and an
OCIArtifact.
When attempting to match a customer's container image to a known
OCIArtifact, we look up an OCITag that matches a particular digest. For
mutable OCITags, that digest association, however, changes over time. Until
OCIReference was introduced, we were only storing the first known
digest for these mutable tags, which ended up introducing a lot of stale
data into the digest classification process: the classifiers were not able
to find OCITags that match newer digests for these mutable tags and
therefore less accurate classifiers like ruleset and deduction classifier
needed to try and classify the cluster inventory record.
For OCITags that are mutable -- e.g. "latest" or "stable" or "v1" -- there
can be many digests that an OCITag has previously pointed to.
Previously-referred digests for an OCITag are made available through the
OCIReference object model. You may be wondering why we don't have an
References field on OCITag that just returns the digests that have been
previously associated with this OCITag. The reason for that is because the
list of previously-known digest associations can be very long (it's
unbounded) and so having this information in a separately-fetched object
model that can be paginated/controlled seemed like a better design.
# Delete Repository
Source: https://docs.chkk.io/api-reference/v2/oci/delete-repository
delete /ocirepositories/{repository}/
Delete an OCIRepository
An OCIRepository represents a single namespace within an OCI Registry.
OCIRepositories are uniquely identified by a URI-like string where the final
path of the URI represents the OCIRepository Namespace and the part of the URI
before the Namespace is the Registry identifier.
Examples of OCIRepository identifiers:
* docker.io/istio/pilot: The pilot namespace in the docker.io/istio
registry.
* public.ecr.aws/bottlerocket/bottlerocket-operator: The
bottlerocket-operator namespace in the public.ecr.aws/bottlerocket
registry.
# Delete Tag
Source: https://docs.chkk.io/api-reference/v2/oci/delete-tag
delete /ocitags/{tag}/
Delete a OCITag
An OCIRepository can publish zero or more OCITags. OCITags are names that
point to a unique OCIArtifact digest.
An OCITag's ID is comprised of the OCIRepository ID followed by a : and the
Tag name.
Examples of OCITag identifiers:
* docker.io/istio/pilot:1.3.0: The 1.3.0 tag on the docker.io/istio/pilot
OCIRepository.
* public.ecr.aws/bottlerocket/bottlerocket-operator:0.1: The 0.1 tag on the
public.ecr.aws/bottlerocket/bottlerocket-operator OCIRepository.
# Get Repository
Source: https://docs.chkk.io/api-reference/v2/oci/get-repository
get /ocirepositories/{repository}/
Gets a single OCIRepository
An OCIRepository represents a single namespace within an OCI Registry.
OCIRepositories are uniquely identified by a URI-like string where the final
path of the URI represents the OCIRepository Namespace and the part of the URI
before the Namespace is the Registry identifier.
Examples of OCIRepository identifiers:
* docker.io/istio/pilot: The pilot namespace in the docker.io/istio
registry.
* public.ecr.aws/bottlerocket/bottlerocket-operator: The
bottlerocket-operator namespace in the public.ecr.aws/bottlerocket
registry.
# Get Tag
Source: https://docs.chkk.io/api-reference/v2/oci/get-tag
get /ocitags/{tag}/
Gets a single OCITag
An OCIRepository can publish zero or more OCITags. OCITags are names that
point to a unique OCIArtifact digest.
An OCITag's ID is comprised of the OCIRepository ID followed by a : and the
Tag name.
Examples of OCITag identifiers:
* docker.io/istio/pilot:1.3.0: The 1.3.0 tag on the docker.io/istio/pilot
OCIRepository.
* public.ecr.aws/bottlerocket/bottlerocket-operator:0.1: The 0.1 tag on the
public.ecr.aws/bottlerocket/bottlerocket-operator OCIRepository.
# List Repositories
Source: https://docs.chkk.io/api-reference/v2/oci/list-repositories
get /ocirepositories
List multiple OCIRepositories
An OCIRepository represents a single namespace within an OCI Registry.
OCIRepositories are uniquely identified by a URI-like string where the final
path of the URI represents the OCIRepository Namespace and the part of the URI
before the Namespace is the Registry identifier.
Examples of OCIRepository identifiers:
* docker.io/istio/pilot: The pilot namespace in the docker.io/istio
registry.
* public.ecr.aws/bottlerocket/bottlerocket-operator: The
bottlerocket-operator namespace in the public.ecr.aws/bottlerocket
registry.
# List Tags
Source: https://docs.chkk.io/api-reference/v2/oci/list-tags-1
get /ocitags
List multiple OCITags
An OCIRepository can publish zero or more OCITags. OCITags are names that
point to a unique OCIArtifact digest.
An OCITag's ID is comprised of the OCIRepository ID followed by a : and the
Tag name.
Examples of OCITag identifiers:
* docker.io/istio/pilot:1.3.0: The 1.3.0 tag on the docker.io/istio/pilot
OCIRepository.
* public.ecr.aws/bottlerocket/bottlerocket-operator:0.1: The 0.1 tag on the
public.ecr.aws/bottlerocket/bottlerocket-operator OCIRepository.
# Update Reference
Source: https://docs.chkk.io/api-reference/v2/oci/update-reference
put /ocireferences/{reference}/
Update an existing OCIReference
An OCIReference represents a relationship between an OCITag and an
OCIArtifact.
When attempting to match a customer's container image to a known
OCIArtifact, we look up an OCITag that matches a particular digest. For
mutable OCITags, that digest association, however, changes over time. Until
OCIReference was introduced, we were only storing the first known
digest for these mutable tags, which ended up introducing a lot of stale
data into the digest classification process: the classifiers were not able
to find OCITags that match newer digests for these mutable tags and
therefore less accurate classifiers like ruleset and deduction classifier
needed to try and classify the cluster inventory record.
For OCITags that are mutable -- e.g. "latest" or "stable" or "v1" -- there
can be many digests that an OCITag has previously pointed to.
Previously-referred digests for an OCITag are made available through the
OCIReference object model. You may be wondering why we don't have an
References field on OCITag that just returns the digests that have been
previously associated with this OCITag. The reason for that is because the
list of previously-known digest associations can be very long (it's
unbounded) and so having this information in a separately-fetched object
model that can be paginated/controlled seemed like a better design.
# Update Repository
Source: https://docs.chkk.io/api-reference/v2/oci/update-repository
put /ocirepositories/{repository}/
Update an existing OCIRepository
An OCIRepository represents a single namespace within an OCI Registry.
OCIRepositories are uniquely identified by a URI-like string where the final
path of the URI represents the OCIRepository Namespace and the part of the URI
before the Namespace is the Registry identifier.
Examples of OCIRepository identifiers:
* docker.io/istio/pilot: The pilot namespace in the docker.io/istio
registry.
* public.ecr.aws/bottlerocket/bottlerocket-operator: The
bottlerocket-operator namespace in the public.ecr.aws/bottlerocket
registry.
# Update Tag
Source: https://docs.chkk.io/api-reference/v2/oci/update-tag
put /ocitags/{tag}/
Update an existing OCITag
An OCIRepository can publish zero or more OCITags. OCITags are names that
point to a unique OCIArtifact digest.
An OCITag's ID is comprised of the OCIRepository ID followed by a : and the
Tag name.
Examples of OCITag identifiers:
* docker.io/istio/pilot:1.3.0: The 1.3.0 tag on the docker.io/istio/pilot
OCIRepository.
* public.ecr.aws/bottlerocket/bottlerocket-operator:0.1: The 0.1 tag on the
public.ecr.aws/bottlerocket/bottlerocket-operator OCIRepository.
# Create Organization
Source: https://docs.chkk.io/api-reference/v2/organization/create-organization
post /organizations
Create a new Organization
An Organization is the top-level object that models a Chkk customer.
Organizations are uniquely identified by a UUID, prefixed with the string
org_, for example org_c42014e7-baf5-4ec6-a502-858f98dca7c8
# Delete Organization
Source: https://docs.chkk.io/api-reference/v2/organization/delete-organization
delete /organizations/{organization}/
Delete a Organization
An Organization is the top-level object that models a Chkk customer.
Organizations are uniquely identified by a UUID, prefixed with the string
org_, for example org_c42014e7-baf5-4ec6-a502-858f98dca7c8
# Get Organization
Source: https://docs.chkk.io/api-reference/v2/organization/get-organization
get /organizations/{organization}/
Gets a single Organization
An Organization is the top-level object that models a Chkk customer.
Organizations are uniquely identified by a UUID, prefixed with the string
org_, for example org_c42014e7-baf5-4ec6-a502-858f98dca7c8
# List Organizations
Source: https://docs.chkk.io/api-reference/v2/organization/list-organizations
get /organizations
List multiple Organizations
An Organization is the top-level object that models a Chkk customer.
Organizations are uniquely identified by a UUID, prefixed with the string
org_, for example org_c42014e7-baf5-4ec6-a502-858f98dca7c8
# Update Organization
Source: https://docs.chkk.io/api-reference/v2/organization/update-organization
put /organizations/{organization}/
Update an existing Organization
An Organization is the top-level object that models a Chkk customer.
Organizations are uniquely identified by a UUID, prefixed with the string
org_, for example org_c42014e7-baf5-4ec6-a502-858f98dca7c8
# Create Component
Source: https://docs.chkk.io/api-reference/v2/package/create-component
post /packages/{package}/versionsets/{number}/components
Create a new PackageComponent
A Package has zero or more *PackageComponents*. A PackageComponent is a
separate Project, ProjectComponent, daemon, subsystem or binary distributed as
part of a PackageVersionSet.
A PackageComponent is uniquely identified by the combination of the
PackageVersionSet identifier and the Component name separated by a :
character. The Component name may be a Project identifier, a URL or
filepath-like identifier or just a string name.
Examples of PackageComponent identifiers:
* pkg_aae8471b-cf66-41d0-b72b-b44d3278d35a:1:agent: The agent Component of
the first versionset (:1) of the Cilium Helm Chart Package specified by
that Package's UUID.
* helm-kube-prometheus-stack:3:prometheus-operator: The prometheus-operator
Component of the third versionset (:3) of the Kube Prometheus Helm Chart
Package specified by that Package's Alias (helm-kube-prometheus-stack)
> **IMPORTANT**: For Packages using the helm or kube PackageSystem, these
> PackageComponents represent a Resource (Deployment, DaemonSet
> or StatefulSet) that is installed by the Package.
Simple examples of PackageComponents would be the Bitnami Cert-Manager Helm
Chart Package's controller Deployment, the webhook Deployment and the
cainjector Deployment.
More complex examples of PackageComponents might be the ArgoCD Official
Upstream Helm Chart Package's extensive collection of controllers, caches and
persistent database storage components installed in Deployment, Daemonset and
StatefulSet resources.
# Create Package
Source: https://docs.chkk.io/api-reference/v2/package/create-package
post /packages
Create a new Package
A Package is a named bundle of software that is bundled (and
identified) in the format of a specific PackageSystem.
A PackageSystem is an identifier of a packaging ecosystem.
Packages can use one of the following PackageSystems:
* helm for Helm charts
* kube for raw YAML manifests or Kustomize overlays that install one or
more resources
A Package is identified by a globally-unique ID field which is a UUID string
prefixed with the string 'pkg_', for example
'pkg_c42014e7-baf5-4ec6-a502-858f98dca7c8'.
A Package may be associated with one or more Projects and zero or more
ProjectComponents.
A Package may have one or more links associated with it. There are two types
of links that hold special significance to a package: 'package.archive' and
'package.source'. The 'package.archive' link is used to indicate the location
of the package's archive, which is the file that contains the package's
contents. The 'package.source' link is used to indicate a location on the web
where the package may be observed in an un-archived format. For example, the
cert-manager helm chart package can have the following links
- 'package.archive': https:charts.jetstack.io/cert-manager
- 'package.source': https:github.com/cert-manager/cert-manager/tree/master/deploy/charts/cert-manager
A Package may have zero or more aliases associated with it in the 'Aliases'
field. An alias for a Package is a human readable string that uniquely
identifies the Package.
A Package may be associated with one or more ProjectComponents. Packages with
PackageSystem helm or kube are associated with ProjectComponents
via the Package's collection of PackageComponents. A PackageComponent, which
corresponds to a specific Resource of Kind Deployment, DaemonSet or
StatefulSet, may reference one or more Docker Images. Those Docker Images
correspond to a ProjectComponent for one or more Projects.
# Create Release
Source: https://docs.chkk.io/api-reference/v2/package/create-release
post /packages/{package}/releases
Create a new PackageRelease
A Package may have one or more PackageReleases. A PackageRelease is
the coordinated publication of one or more Packages for the Package having the
same Version string.
A PackageRelease is uniquely identified by the combination of the Package UUID
or Package Alias and a version string separated by an @ character.
Example PackageRelease identifiers:
* helm-chkk-operator@0.0.13: the Chkk Operator Helm Chart Package Alias of
helm-chkk-operator with a version string of 0.0.13
* pkg_aae8471b-cf66-41d0-b72b-b44d3278d35a@1.24.12: the Package UUID of the
Cilium Helm Chart and the version string 1.24.12
* helm-kube-prometheus-stack@65.4.0: the Kube Prometheus Helm Chart Package
Alias of helm-kube-prometheus-stack with a version string of 65.4.0
A PackageRelease can have zero or more Changes associated with it that describe
the bug fixes and new features that were included in the PackageRelease.
# Create VersionSet
Source: https://docs.chkk.io/api-reference/v2/package/create-versionset
post /packages/{package}/versionsets
Create a new PackageVersionSet
A PackageVersionSet represents a configuration, layout or structure of
a Package that is consistent for a range of PackageReleases.
A PackageComponent is associated with a single PackageVersionSet. We track
changes to the componentry and structure of a Package over time using
PackageVersionSets.
PackageVersionSets are uniquely identified by the Package ID or Alias and
a simple integer, separated by a ':' character.
Examples of PackageVersionSet identifiers:
* argo-workflows:1: the first PackageVersionSet of the Argo Workflows
Package, using the "argo-workflows" Alias as the identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3 the third PackageVersionSet of
the Argo Workflows Package, using the Argo Workflow Package's UUID as the
identifier.
Each PackageVersionSet has a Constraint field that is a Semantic Versioning 2
Version Constraint, e.g. >=1.2.1 or <2.34.50. This Version Constraint
indicates which PackageReleases the PackageVersionSet describes.
# Delete Component
Source: https://docs.chkk.io/api-reference/v2/package/delete-component
delete /packages/{package}/versionsets/{number}/components/{component}/
Delete a PackageComponent
A Package has zero or more *PackageComponents*. A PackageComponent is a
separate Project, ProjectComponent, daemon, subsystem or binary distributed as
part of a PackageVersionSet.
A PackageComponent is uniquely identified by the combination of the
PackageVersionSet identifier and the Component name separated by a :
character. The Component name may be a Project identifier, a URL or
filepath-like identifier or just a string name.
Examples of PackageComponent identifiers:
* pkg_aae8471b-cf66-41d0-b72b-b44d3278d35a:1:agent: The agent Component of
the first versionset (:1) of the Cilium Helm Chart Package specified by
that Package's UUID.
* helm-kube-prometheus-stack:3:prometheus-operator: The prometheus-operator
Component of the third versionset (:3) of the Kube Prometheus Helm Chart
Package specified by that Package's Alias (helm-kube-prometheus-stack)
> **IMPORTANT**: For Packages using the helm or kube PackageSystem, these
> PackageComponents represent a Resource (Deployment, DaemonSet
> or StatefulSet) that is installed by the Package.
Simple examples of PackageComponents would be the Bitnami Cert-Manager Helm
Chart Package's controller Deployment, the webhook Deployment and the
cainjector Deployment.
More complex examples of PackageComponents might be the ArgoCD Official
Upstream Helm Chart Package's extensive collection of controllers, caches and
persistent database storage components installed in Deployment, Daemonset and
StatefulSet resources.
# Delete Package
Source: https://docs.chkk.io/api-reference/v2/package/delete-package
delete /packages/{package}/
Delete a Package
A Package is a named bundle of software that is bundled (and
identified) in the format of a specific PackageSystem.
A PackageSystem is an identifier of a packaging ecosystem.
Packages can use one of the following PackageSystems:
* helm for Helm charts
* kube for raw YAML manifests or Kustomize overlays that install one or
more resources
A Package is identified by a globally-unique ID field which is a UUID string
prefixed with the string 'pkg_', for example
'pkg_c42014e7-baf5-4ec6-a502-858f98dca7c8'.
A Package may be associated with one or more Projects and zero or more
ProjectComponents.
A Package may have one or more links associated with it. There are two types
of links that hold special significance to a package: 'package.archive' and
'package.source'. The 'package.archive' link is used to indicate the location
of the package's archive, which is the file that contains the package's
contents. The 'package.source' link is used to indicate a location on the web
where the package may be observed in an un-archived format. For example, the
cert-manager helm chart package can have the following links
- 'package.archive': https:charts.jetstack.io/cert-manager
- 'package.source': https:github.com/cert-manager/cert-manager/tree/master/deploy/charts/cert-manager
A Package may have zero or more aliases associated with it in the 'Aliases'
field. An alias for a Package is a human readable string that uniquely
identifies the Package.
A Package may be associated with one or more ProjectComponents. Packages with
PackageSystem helm or kube are associated with ProjectComponents
via the Package's collection of PackageComponents. A PackageComponent, which
corresponds to a specific Resource of Kind Deployment, DaemonSet or
StatefulSet, may reference one or more Docker Images. Those Docker Images
correspond to a ProjectComponent for one or more Projects.
# Delete Release
Source: https://docs.chkk.io/api-reference/v2/package/delete-release
delete /packages/{package}/releases/{release}/
Delete a PackageRelease
A Package may have one or more PackageReleases. A PackageRelease is
the coordinated publication of one or more Packages for the Package having the
same Version string.
A PackageRelease is uniquely identified by the combination of the Package UUID
or Package Alias and a version string separated by an @ character.
Example PackageRelease identifiers:
* helm-chkk-operator@0.0.13: the Chkk Operator Helm Chart Package Alias of
helm-chkk-operator with a version string of 0.0.13
* pkg_aae8471b-cf66-41d0-b72b-b44d3278d35a@1.24.12: the Package UUID of the
Cilium Helm Chart and the version string 1.24.12
* helm-kube-prometheus-stack@65.4.0: the Kube Prometheus Helm Chart Package
Alias of helm-kube-prometheus-stack with a version string of 65.4.0
A PackageRelease can have zero or more Changes associated with it that describe
the bug fixes and new features that were included in the PackageRelease.
# Delete VersionSet
Source: https://docs.chkk.io/api-reference/v2/package/delete-versionset
delete /packages/{package}/versionsets/{number}/
Delete a PackageVersionSet
A PackageVersionSet represents a configuration, layout or structure of
a Package that is consistent for a range of PackageReleases.
A PackageComponent is associated with a single PackageVersionSet. We track
changes to the componentry and structure of a Package over time using
PackageVersionSets.
PackageVersionSets are uniquely identified by the Package ID or Alias and
a simple integer, separated by a ':' character.
Examples of PackageVersionSet identifiers:
* argo-workflows:1: the first PackageVersionSet of the Argo Workflows
Package, using the "argo-workflows" Alias as the identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3 the third PackageVersionSet of
the Argo Workflows Package, using the Argo Workflow Package's UUID as the
identifier.
Each PackageVersionSet has a Constraint field that is a Semantic Versioning 2
Version Constraint, e.g. >=1.2.1 or <2.34.50. This Version Constraint
indicates which PackageReleases the PackageVersionSet describes.
# Get Component
Source: https://docs.chkk.io/api-reference/v2/package/get-component
get /packages/{package}/versionsets/{number}/components/{component}/
Gets a single PackageComponent
A Package has zero or more *PackageComponents*. A PackageComponent is a
separate Project, ProjectComponent, daemon, subsystem or binary distributed as
part of a PackageVersionSet.
A PackageComponent is uniquely identified by the combination of the
PackageVersionSet identifier and the Component name separated by a :
character. The Component name may be a Project identifier, a URL or
filepath-like identifier or just a string name.
Examples of PackageComponent identifiers:
* pkg_aae8471b-cf66-41d0-b72b-b44d3278d35a:1:agent: The agent Component of
the first versionset (:1) of the Cilium Helm Chart Package specified by
that Package's UUID.
* helm-kube-prometheus-stack:3:prometheus-operator: The prometheus-operator
Component of the third versionset (:3) of the Kube Prometheus Helm Chart
Package specified by that Package's Alias (helm-kube-prometheus-stack)
> **IMPORTANT**: For Packages using the helm or kube PackageSystem, these
> PackageComponents represent a Resource (Deployment, DaemonSet
> or StatefulSet) that is installed by the Package.
Simple examples of PackageComponents would be the Bitnami Cert-Manager Helm
Chart Package's controller Deployment, the webhook Deployment and the
cainjector Deployment.
More complex examples of PackageComponents might be the ArgoCD Official
Upstream Helm Chart Package's extensive collection of controllers, caches and
persistent database storage components installed in Deployment, Daemonset and
StatefulSet resources.
# Get Package
Source: https://docs.chkk.io/api-reference/v2/package/get-package
get /packages/{package}/
Gets a single Package
A Package is a named bundle of software that is bundled (and
identified) in the format of a specific PackageSystem.
A PackageSystem is an identifier of a packaging ecosystem.
Packages can use one of the following PackageSystems:
* helm for Helm charts
* kube for raw YAML manifests or Kustomize overlays that install one or
more resources
A Package is identified by a globally-unique ID field which is a UUID string
prefixed with the string 'pkg_', for example
'pkg_c42014e7-baf5-4ec6-a502-858f98dca7c8'.
A Package may be associated with one or more Projects and zero or more
ProjectComponents.
A Package may have one or more links associated with it. There are two types
of links that hold special significance to a package: 'package.archive' and
'package.source'. The 'package.archive' link is used to indicate the location
of the package's archive, which is the file that contains the package's
contents. The 'package.source' link is used to indicate a location on the web
where the package may be observed in an un-archived format. For example, the
cert-manager helm chart package can have the following links
- 'package.archive': https:charts.jetstack.io/cert-manager
- 'package.source': https:github.com/cert-manager/cert-manager/tree/master/deploy/charts/cert-manager
A Package may have zero or more aliases associated with it in the 'Aliases'
field. An alias for a Package is a human readable string that uniquely
identifies the Package.
A Package may be associated with one or more ProjectComponents. Packages with
PackageSystem helm or kube are associated with ProjectComponents
via the Package's collection of PackageComponents. A PackageComponent, which
corresponds to a specific Resource of Kind Deployment, DaemonSet or
StatefulSet, may reference one or more Docker Images. Those Docker Images
correspond to a ProjectComponent for one or more Projects.
# Get Release
Source: https://docs.chkk.io/api-reference/v2/package/get-release
get /packages/{package}/releases/{release}/
Gets a single PackageRelease
A Package may have one or more PackageReleases. A PackageRelease is
the coordinated publication of one or more Packages for the Package having the
same Version string.
A PackageRelease is uniquely identified by the combination of the Package UUID
or Package Alias and a version string separated by an @ character.
Example PackageRelease identifiers:
* helm-chkk-operator@0.0.13: the Chkk Operator Helm Chart Package Alias of
helm-chkk-operator with a version string of 0.0.13
* pkg_aae8471b-cf66-41d0-b72b-b44d3278d35a@1.24.12: the Package UUID of the
Cilium Helm Chart and the version string 1.24.12
* helm-kube-prometheus-stack@65.4.0: the Kube Prometheus Helm Chart Package
Alias of helm-kube-prometheus-stack with a version string of 65.4.0
A PackageRelease can have zero or more Changes associated with it that describe
the bug fixes and new features that were included in the PackageRelease.
# Get VersionSet
Source: https://docs.chkk.io/api-reference/v2/package/get-versionset
get /packages/{package}/versionsets/{number}/
Gets a single PackageVersionSet
A PackageVersionSet represents a configuration, layout or structure of
a Package that is consistent for a range of PackageReleases.
A PackageComponent is associated with a single PackageVersionSet. We track
changes to the componentry and structure of a Package over time using
PackageVersionSets.
PackageVersionSets are uniquely identified by the Package ID or Alias and
a simple integer, separated by a ':' character.
Examples of PackageVersionSet identifiers:
* argo-workflows:1: the first PackageVersionSet of the Argo Workflows
Package, using the "argo-workflows" Alias as the identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3 the third PackageVersionSet of
the Argo Workflows Package, using the Argo Workflow Package's UUID as the
identifier.
Each PackageVersionSet has a Constraint field that is a Semantic Versioning 2
Version Constraint, e.g. >=1.2.1 or <2.34.50. This Version Constraint
indicates which PackageReleases the PackageVersionSet describes.
# List Components
Source: https://docs.chkk.io/api-reference/v2/package/list-components
get /packages/{package}/versionsets/{number}/components
List multiple PackageComponents
A Package has zero or more *PackageComponents*. A PackageComponent is a
separate Project, ProjectComponent, daemon, subsystem or binary distributed as
part of a PackageVersionSet.
A PackageComponent is uniquely identified by the combination of the
PackageVersionSet identifier and the Component name separated by a :
character. The Component name may be a Project identifier, a URL or
filepath-like identifier or just a string name.
Examples of PackageComponent identifiers:
* pkg_aae8471b-cf66-41d0-b72b-b44d3278d35a:1:agent: The agent Component of
the first versionset (:1) of the Cilium Helm Chart Package specified by
that Package's UUID.
* helm-kube-prometheus-stack:3:prometheus-operator: The prometheus-operator
Component of the third versionset (:3) of the Kube Prometheus Helm Chart
Package specified by that Package's Alias (helm-kube-prometheus-stack)
> **IMPORTANT**: For Packages using the helm or kube PackageSystem, these
> PackageComponents represent a Resource (Deployment, DaemonSet
> or StatefulSet) that is installed by the Package.
Simple examples of PackageComponents would be the Bitnami Cert-Manager Helm
Chart Package's controller Deployment, the webhook Deployment and the
cainjector Deployment.
More complex examples of PackageComponents might be the ArgoCD Official
Upstream Helm Chart Package's extensive collection of controllers, caches and
persistent database storage components installed in Deployment, Daemonset and
StatefulSet resources.
# List Packages
Source: https://docs.chkk.io/api-reference/v2/package/list-packages
get /packages
List multiple Packages
A Package is a named bundle of software that is bundled (and
identified) in the format of a specific PackageSystem.
A PackageSystem is an identifier of a packaging ecosystem.
Packages can use one of the following PackageSystems:
* helm for Helm charts
* kube for raw YAML manifests or Kustomize overlays that install one or
more resources
A Package is identified by a globally-unique ID field which is a UUID string
prefixed with the string 'pkg_', for example
'pkg_c42014e7-baf5-4ec6-a502-858f98dca7c8'.
A Package may be associated with one or more Projects and zero or more
ProjectComponents.
A Package may have one or more links associated with it. There are two types
of links that hold special significance to a package: 'package.archive' and
'package.source'. The 'package.archive' link is used to indicate the location
of the package's archive, which is the file that contains the package's
contents. The 'package.source' link is used to indicate a location on the web
where the package may be observed in an un-archived format. For example, the
cert-manager helm chart package can have the following links
- 'package.archive': https:charts.jetstack.io/cert-manager
- 'package.source': https:github.com/cert-manager/cert-manager/tree/master/deploy/charts/cert-manager
A Package may have zero or more aliases associated with it in the 'Aliases'
field. An alias for a Package is a human readable string that uniquely
identifies the Package.
A Package may be associated with one or more ProjectComponents. Packages with
PackageSystem helm or kube are associated with ProjectComponents
via the Package's collection of PackageComponents. A PackageComponent, which
corresponds to a specific Resource of Kind Deployment, DaemonSet or
StatefulSet, may reference one or more Docker Images. Those Docker Images
correspond to a ProjectComponent for one or more Projects.
# List Releases
Source: https://docs.chkk.io/api-reference/v2/package/list-releases
get /packages/{package}/releases
List multiple PackageReleases
A Package may have one or more PackageReleases. A PackageRelease is
the coordinated publication of one or more Packages for the Package having the
same Version string.
A PackageRelease is uniquely identified by the combination of the Package UUID
or Package Alias and a version string separated by an @ character.
Example PackageRelease identifiers:
* helm-chkk-operator@0.0.13: the Chkk Operator Helm Chart Package Alias of
helm-chkk-operator with a version string of 0.0.13
* pkg_aae8471b-cf66-41d0-b72b-b44d3278d35a@1.24.12: the Package UUID of the
Cilium Helm Chart and the version string 1.24.12
* helm-kube-prometheus-stack@65.4.0: the Kube Prometheus Helm Chart Package
Alias of helm-kube-prometheus-stack with a version string of 65.4.0
A PackageRelease can have zero or more Changes associated with it that describe
the bug fixes and new features that were included in the PackageRelease.
# List VersionSets
Source: https://docs.chkk.io/api-reference/v2/package/list-versionsets
get /packages/{package}/versionsets
List multiple PackageVersionSets
A PackageVersionSet represents a configuration, layout or structure of
a Package that is consistent for a range of PackageReleases.
A PackageComponent is associated with a single PackageVersionSet. We track
changes to the componentry and structure of a Package over time using
PackageVersionSets.
PackageVersionSets are uniquely identified by the Package ID or Alias and
a simple integer, separated by a ':' character.
Examples of PackageVersionSet identifiers:
* argo-workflows:1: the first PackageVersionSet of the Argo Workflows
Package, using the "argo-workflows" Alias as the identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3 the third PackageVersionSet of
the Argo Workflows Package, using the Argo Workflow Package's UUID as the
identifier.
Each PackageVersionSet has a Constraint field that is a Semantic Versioning 2
Version Constraint, e.g. >=1.2.1 or <2.34.50. This Version Constraint
indicates which PackageReleases the PackageVersionSet describes.
# Update Component
Source: https://docs.chkk.io/api-reference/v2/package/update-component
put /packages/{package}/versionsets/{number}/components/{component}/
Update an existing PackageComponent
A Package has zero or more *PackageComponents*. A PackageComponent is a
separate Project, ProjectComponent, daemon, subsystem or binary distributed as
part of a PackageVersionSet.
A PackageComponent is uniquely identified by the combination of the
PackageVersionSet identifier and the Component name separated by a :
character. The Component name may be a Project identifier, a URL or
filepath-like identifier or just a string name.
Examples of PackageComponent identifiers:
* pkg_aae8471b-cf66-41d0-b72b-b44d3278d35a:1:agent: The agent Component of
the first versionset (:1) of the Cilium Helm Chart Package specified by
that Package's UUID.
* helm-kube-prometheus-stack:3:prometheus-operator: The prometheus-operator
Component of the third versionset (:3) of the Kube Prometheus Helm Chart
Package specified by that Package's Alias (helm-kube-prometheus-stack)
> **IMPORTANT**: For Packages using the helm or kube PackageSystem, these
> PackageComponents represent a Resource (Deployment, DaemonSet
> or StatefulSet) that is installed by the Package.
Simple examples of PackageComponents would be the Bitnami Cert-Manager Helm
Chart Package's controller Deployment, the webhook Deployment and the
cainjector Deployment.
More complex examples of PackageComponents might be the ArgoCD Official
Upstream Helm Chart Package's extensive collection of controllers, caches and
persistent database storage components installed in Deployment, Daemonset and
StatefulSet resources.
# Update Package
Source: https://docs.chkk.io/api-reference/v2/package/update-package
put /packages/{package}/
Update an existing Package
A Package is a named bundle of software that is bundled (and
identified) in the format of a specific PackageSystem.
A PackageSystem is an identifier of a packaging ecosystem.
Packages can use one of the following PackageSystems:
* helm for Helm charts
* kube for raw YAML manifests or Kustomize overlays that install one or
more resources
A Package is identified by a globally-unique ID field which is a UUID string
prefixed with the string 'pkg_', for example
'pkg_c42014e7-baf5-4ec6-a502-858f98dca7c8'.
A Package may be associated with one or more Projects and zero or more
ProjectComponents.
A Package may have one or more links associated with it. There are two types
of links that hold special significance to a package: 'package.archive' and
'package.source'. The 'package.archive' link is used to indicate the location
of the package's archive, which is the file that contains the package's
contents. The 'package.source' link is used to indicate a location on the web
where the package may be observed in an un-archived format. For example, the
cert-manager helm chart package can have the following links
- 'package.archive': https:charts.jetstack.io/cert-manager
- 'package.source': https:github.com/cert-manager/cert-manager/tree/master/deploy/charts/cert-manager
A Package may have zero or more aliases associated with it in the 'Aliases'
field. An alias for a Package is a human readable string that uniquely
identifies the Package.
A Package may be associated with one or more ProjectComponents. Packages with
PackageSystem helm or kube are associated with ProjectComponents
via the Package's collection of PackageComponents. A PackageComponent, which
corresponds to a specific Resource of Kind Deployment, DaemonSet or
StatefulSet, may reference one or more Docker Images. Those Docker Images
correspond to a ProjectComponent for one or more Projects.
# Update Release
Source: https://docs.chkk.io/api-reference/v2/package/update-release
put /packages/{package}/releases/{release}/
Update an existing PackageRelease
A Package may have one or more PackageReleases. A PackageRelease is
the coordinated publication of one or more Packages for the Package having the
same Version string.
A PackageRelease is uniquely identified by the combination of the Package UUID
or Package Alias and a version string separated by an @ character.
Example PackageRelease identifiers:
* helm-chkk-operator@0.0.13: the Chkk Operator Helm Chart Package Alias of
helm-chkk-operator with a version string of 0.0.13
* pkg_aae8471b-cf66-41d0-b72b-b44d3278d35a@1.24.12: the Package UUID of the
Cilium Helm Chart and the version string 1.24.12
* helm-kube-prometheus-stack@65.4.0: the Kube Prometheus Helm Chart Package
Alias of helm-kube-prometheus-stack with a version string of 65.4.0
A PackageRelease can have zero or more Changes associated with it that describe
the bug fixes and new features that were included in the PackageRelease.
# Update VersionSet
Source: https://docs.chkk.io/api-reference/v2/package/update-versionset
put /packages/{package}/versionsets/{number}/
Update an existing PackageVersionSet
A PackageVersionSet represents a configuration, layout or structure of
a Package that is consistent for a range of PackageReleases.
A PackageComponent is associated with a single PackageVersionSet. We track
changes to the componentry and structure of a Package over time using
PackageVersionSets.
PackageVersionSets are uniquely identified by the Package ID or Alias and
a simple integer, separated by a ':' character.
Examples of PackageVersionSet identifiers:
* argo-workflows:1: the first PackageVersionSet of the Argo Workflows
Package, using the "argo-workflows" Alias as the identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3 the third PackageVersionSet of
the Argo Workflows Package, using the Argo Workflow Package's UUID as the
identifier.
Each PackageVersionSet has a Constraint field that is a Semantic Versioning 2
Version Constraint, e.g. >=1.2.1 or <2.34.50. This Version Constraint
indicates which PackageReleases the PackageVersionSet describes.
# Create Component
Source: https://docs.chkk.io/api-reference/v2/project/create-component
post /projects/{project}/versionsets/{number}/components
Create a new ProjectComponent
A ProjectComponent is a separate binary, daemon, or subsystem of a
Project.
> **NOTE**: ProjectComponents that are associated with a PackageComponent for a
> Package with PackageSystem kube or helm can be thought of as
> roughly equivalent to OCI/Docker Images, since the ProjectComponent
> describes a container within a Resource described by that
> PackageComponent.
A ProjectComponent is uniquely identified by the combination of a
ProjectVersionSet identifier and the Component name separated by a :
character. The Component name is a simple name indicating the binary, daemon
or subsystem.
Examples of ProjectComponent identifiers:
* argo-workflows:1:workflow-controller: the
workflow-controller binary of the first versionset of the Argo Workflows
Project, using the argo-workflows Alias as the Project identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3:workflow-controller: the
workflow-controller binary of the third ProjectVersionSet of the Argo
Workflows Project, using the Argo Workflow Project's UUID as the identifier.
# Create Project
Source: https://docs.chkk.io/api-reference/v2/project/create-project
post /projects
Create a new Project
A Project is software that provides some functionality.
Projects are uniquely identified by a UUID, prefixed with the string
proj_, for example proj_c42014e7-baf5-4ec6-a502-858f98dca7c8
Projects can have zero or more Aliases. Aliases are completely free-form.
They can be a URL, like github.com/kubernetes/kubernetes or a short string
like k8s or kube.
Each Project has a ProjectType. Valid ProjectTypes include:
* platform: The Project represents a software platform, such as the
Project itself.
* kube-addon: The Project represents a Cloud Native Project, which is defined as
some software that extends the functionality of the cluster and
its API.
* kube-operator: The Project represents a Kubernetes [Operator][operator],
which is defined as software written specifically against the API
and is responsible for installing and managing the lifecycle of a Kubernetes
Addon or Application Service.
* kube-control-plane-provider: The Project represents a Kubernetes control
plane service, such as RKE, GKE or EKS.
* application-service: The Project represents application code that provides
essential services to the rest of the application stack.
* application: The Project represents customer-specific or internal code.
A Project is not the packaging of that software. Packaging of
Projects is described by the Package model.
# Create Release
Source: https://docs.chkk.io/api-reference/v2/project/create-release
post /projects/{project}/releases
Create a new ProjectRelease
A Project may have one or more ProjectReleases. A ProjectRelease is
the coordinated publication of one or more Packages for the Project having the
same Version string.
A ProjectRelease is always associated with a single ProjectRelease.
A ProjectRelease is uniquely identified by the combination of the Project
identifier and the Version string, separated by an '@' character, e.g.
proj_a858f4d4-6e5b-4ab5-8d92-e9715b584ec1@1.5.12
A ProjectRelease can have zero or more Changes associated with it that describe
the bug fixes and new features that were included in the ProjectRelease.
# Create ReleaseSeries
Source: https://docs.chkk.io/api-reference/v2/project/create-releaseseries
post /projects/{project}/releaseseries
Create a new ProjectReleaseSeries
A Project may have one or more ProjectReleaseSeries. A
ProjectReleaseSeries describes a single release series for a Project.
ProjectReleaseSeries are identified by a simple string that must be unique
for the Project. Typically the ProjectReleaseSeries Name will be a major or
major.minor version series, e.g. "4" or "1.28", however this is not
universally true. Some Projects use date-based names like "2024.04".
A ProjectReleaseSeries has a PublishedOn date which indicates when the
release was originally "cut".
# Create VersionSet
Source: https://docs.chkk.io/api-reference/v2/project/create-versionset
post /projects/{project}/versionsets
Create a new ProjectVersionSet
A ProjectVersionSet represents a configuration, layout or structure of
a Project that is consistent for a range of ProjectReleases.
A ProjectComponent is associated with a single ProjectVersionSet. We track
changes to the componentry and structure of a Project over time using
ProjectVersionSets.
ProjectVersionSets are uniquely identified by the Project ID or Alias and
a simple integer, separated by a ':' character.
Examples of ProjectVersionSet identifiers:
* argo-workflows:1: the first ProjectVersionSet of the Argo Workflows
Project, using the "argo-workflows" Alias as the identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3 the third ProjectVersionSet of
the Argo Workflows Project, using the Argo Workflow Project's UUID as the
identifier.
Each ProjectVersionSet has a Constraint field that is a Semantic Versioning 2
Version Constraint, e.g. >=1.2.1 or <2.34.50. This Version Constraint
indicates which ProjectReleases the ProjectVersionSet describes.
# Delete Component
Source: https://docs.chkk.io/api-reference/v2/project/delete-component
delete /projects/{project}/versionsets/{number}/components/{component}/
Delete a ProjectComponent
A ProjectComponent is a separate binary, daemon, or subsystem of a
Project.
> **NOTE**: ProjectComponents that are associated with a PackageComponent for a
> Package with PackageSystem kube or helm can be thought of as
> roughly equivalent to OCI/Docker Images, since the ProjectComponent
> describes a container within a Resource described by that
> PackageComponent.
A ProjectComponent is uniquely identified by the combination of a
ProjectVersionSet identifier and the Component name separated by a :
character. The Component name is a simple name indicating the binary, daemon
or subsystem.
Examples of ProjectComponent identifiers:
* argo-workflows:1:workflow-controller: the
workflow-controller binary of the first versionset of the Argo Workflows
Project, using the argo-workflows Alias as the Project identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3:workflow-controller: the
workflow-controller binary of the third ProjectVersionSet of the Argo
Workflows Project, using the Argo Workflow Project's UUID as the identifier.
# Delete Project
Source: https://docs.chkk.io/api-reference/v2/project/delete-project
delete /projects/{project}/
Delete a Project
A Project is software that provides some functionality.
Projects are uniquely identified by a UUID, prefixed with the string
proj_, for example proj_c42014e7-baf5-4ec6-a502-858f98dca7c8
Projects can have zero or more Aliases. Aliases are completely free-form.
They can be a URL, like github.com/kubernetes/kubernetes or a short string
like k8s or kube.
Each Project has a ProjectType. Valid ProjectTypes include:
* platform: The Project represents a software platform, such as the
Project itself.
* kube-addon: The Project represents a Cloud Native Project, which is defined as
some software that extends the functionality of the cluster and
its API.
* kube-operator: The Project represents a Kubernetes [Operator][operator],
which is defined as software written specifically against the API
and is responsible for installing and managing the lifecycle of a Kubernetes
Addon or Application Service.
* kube-control-plane-provider: The Project represents a Kubernetes control
plane service, such as RKE, GKE or EKS.
* application-service: The Project represents application code that provides
essential services to the rest of the application stack.
* application: The Project represents customer-specific or internal code.
A Project is not the packaging of that software. Packaging of
Projects is described by the Package model.
# Delete Release
Source: https://docs.chkk.io/api-reference/v2/project/delete-release
delete /projects/{project}/releases/{release}/
Delete a ProjectRelease
A Project may have one or more ProjectReleases. A ProjectRelease is
the coordinated publication of one or more Packages for the Project having the
same Version string.
A ProjectRelease is always associated with a single ProjectRelease.
A ProjectRelease is uniquely identified by the combination of the Project
identifier and the Version string, separated by an '@' character, e.g.
proj_a858f4d4-6e5b-4ab5-8d92-e9715b584ec1@1.5.12
A ProjectRelease can have zero or more Changes associated with it that describe
the bug fixes and new features that were included in the ProjectRelease.
# Delete ReleaseSeries
Source: https://docs.chkk.io/api-reference/v2/project/delete-releaseseries
delete /projects/{project}/releaseseries/{series}/
Delete a ProjectReleaseSeries
A Project may have one or more ProjectReleaseSeries. A
ProjectReleaseSeries describes a single release series for a Project.
ProjectReleaseSeries are identified by a simple string that must be unique
for the Project. Typically the ProjectReleaseSeries Name will be a major or
major.minor version series, e.g. "4" or "1.28", however this is not
universally true. Some Projects use date-based names like "2024.04".
A ProjectReleaseSeries has a PublishedOn date which indicates when the
release was originally "cut".
# Delete VersionSet
Source: https://docs.chkk.io/api-reference/v2/project/delete-versionset
delete /projects/{project}/versionsets/{number}/
Delete a ProjectVersionSet
A ProjectVersionSet represents a configuration, layout or structure of
a Project that is consistent for a range of ProjectReleases.
A ProjectComponent is associated with a single ProjectVersionSet. We track
changes to the componentry and structure of a Project over time using
ProjectVersionSets.
ProjectVersionSets are uniquely identified by the Project ID or Alias and
a simple integer, separated by a ':' character.
Examples of ProjectVersionSet identifiers:
* argo-workflows:1: the first ProjectVersionSet of the Argo Workflows
Project, using the "argo-workflows" Alias as the identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3 the third ProjectVersionSet of
the Argo Workflows Project, using the Argo Workflow Project's UUID as the
identifier.
Each ProjectVersionSet has a Constraint field that is a Semantic Versioning 2
Version Constraint, e.g. >=1.2.1 or <2.34.50. This Version Constraint
indicates which ProjectReleases the ProjectVersionSet describes.
# Get Component
Source: https://docs.chkk.io/api-reference/v2/project/get-component
get /projects/{project}/versionsets/{number}/components/{component}/
Gets a single ProjectComponent
A ProjectComponent is a separate binary, daemon, or subsystem of a
Project.
> **NOTE**: ProjectComponents that are associated with a PackageComponent for a
> Package with PackageSystem kube or helm can be thought of as
> roughly equivalent to OCI/Docker Images, since the ProjectComponent
> describes a container within a Resource described by that
> PackageComponent.
A ProjectComponent is uniquely identified by the combination of a
ProjectVersionSet identifier and the Component name separated by a :
character. The Component name is a simple name indicating the binary, daemon
or subsystem.
Examples of ProjectComponent identifiers:
* argo-workflows:1:workflow-controller: the
workflow-controller binary of the first versionset of the Argo Workflows
Project, using the argo-workflows Alias as the Project identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3:workflow-controller: the
workflow-controller binary of the third ProjectVersionSet of the Argo
Workflows Project, using the Argo Workflow Project's UUID as the identifier.
# Get Project
Source: https://docs.chkk.io/api-reference/v2/project/get-project
get /projects/{project}/
Gets a single Project
A Project is software that provides some functionality.
Projects are uniquely identified by a UUID, prefixed with the string
proj_, for example proj_c42014e7-baf5-4ec6-a502-858f98dca7c8
Projects can have zero or more Aliases. Aliases are completely free-form.
They can be a URL, like github.com/kubernetes/kubernetes or a short string
like k8s or kube.
Each Project has a ProjectType. Valid ProjectTypes include:
* platform: The Project represents a software platform, such as the
Project itself.
* kube-addon: The Project represents a Cloud Native Project, which is defined as
some software that extends the functionality of the cluster and
its API.
* kube-operator: The Project represents a Kubernetes [Operator][operator],
which is defined as software written specifically against the API
and is responsible for installing and managing the lifecycle of a Kubernetes
Addon or Application Service.
* kube-control-plane-provider: The Project represents a Kubernetes control
plane service, such as RKE, GKE or EKS.
* application-service: The Project represents application code that provides
essential services to the rest of the application stack.
* application: The Project represents customer-specific or internal code.
A Project is not the packaging of that software. Packaging of
Projects is described by the Package model.
# Get Release
Source: https://docs.chkk.io/api-reference/v2/project/get-release
get /projects/{project}/releases/{release}/
Gets a single ProjectRelease
A Project may have one or more ProjectReleases. A ProjectRelease is
the coordinated publication of one or more Packages for the Project having the
same Version string.
A ProjectRelease is always associated with a single ProjectRelease.
A ProjectRelease is uniquely identified by the combination of the Project
identifier and the Version string, separated by an '@' character, e.g.
proj_a858f4d4-6e5b-4ab5-8d92-e9715b584ec1@1.5.12
A ProjectRelease can have zero or more Changes associated with it that describe
the bug fixes and new features that were included in the ProjectRelease.
# Get ReleaseSeries
Source: https://docs.chkk.io/api-reference/v2/project/get-releaseseries
get /projects/{project}/releaseseries/{series}/
Gets a single ProjectReleaseSeries
A Project may have one or more ProjectReleaseSeries. A
ProjectReleaseSeries describes a single release series for a Project.
ProjectReleaseSeries are identified by a simple string that must be unique
for the Project. Typically the ProjectReleaseSeries Name will be a major or
major.minor version series, e.g. "4" or "1.28", however this is not
universally true. Some Projects use date-based names like "2024.04".
A ProjectReleaseSeries has a PublishedOn date which indicates when the
release was originally "cut".
# Get VersionSet
Source: https://docs.chkk.io/api-reference/v2/project/get-versionset
get /projects/{project}/versionsets/{number}/
Gets a single ProjectVersionSet
A ProjectVersionSet represents a configuration, layout or structure of
a Project that is consistent for a range of ProjectReleases.
A ProjectComponent is associated with a single ProjectVersionSet. We track
changes to the componentry and structure of a Project over time using
ProjectVersionSets.
ProjectVersionSets are uniquely identified by the Project ID or Alias and
a simple integer, separated by a ':' character.
Examples of ProjectVersionSet identifiers:
* argo-workflows:1: the first ProjectVersionSet of the Argo Workflows
Project, using the "argo-workflows" Alias as the identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3 the third ProjectVersionSet of
the Argo Workflows Project, using the Argo Workflow Project's UUID as the
identifier.
Each ProjectVersionSet has a Constraint field that is a Semantic Versioning 2
Version Constraint, e.g. >=1.2.1 or <2.34.50. This Version Constraint
indicates which ProjectReleases the ProjectVersionSet describes.
# List Components
Source: https://docs.chkk.io/api-reference/v2/project/list-components
get /projects/{project}/versionsets/{number}/components
List multiple ProjectComponents
A ProjectComponent is a separate binary, daemon, or subsystem of a
Project.
> **NOTE**: ProjectComponents that are associated with a PackageComponent for a
> Package with PackageSystem kube or helm can be thought of as
> roughly equivalent to OCI/Docker Images, since the ProjectComponent
> describes a container within a Resource described by that
> PackageComponent.
A ProjectComponent is uniquely identified by the combination of a
ProjectVersionSet identifier and the Component name separated by a :
character. The Component name is a simple name indicating the binary, daemon
or subsystem.
Examples of ProjectComponent identifiers:
* argo-workflows:1:workflow-controller: the
workflow-controller binary of the first versionset of the Argo Workflows
Project, using the argo-workflows Alias as the Project identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3:workflow-controller: the
workflow-controller binary of the third ProjectVersionSet of the Argo
Workflows Project, using the Argo Workflow Project's UUID as the identifier.
# List Projects
Source: https://docs.chkk.io/api-reference/v2/project/list-projects
get /projects
List multiple Projects
A Project is software that provides some functionality.
Projects are uniquely identified by a UUID, prefixed with the string
proj_, for example proj_c42014e7-baf5-4ec6-a502-858f98dca7c8
Projects can have zero or more Aliases. Aliases are completely free-form.
They can be a URL, like github.com/kubernetes/kubernetes or a short string
like k8s or kube.
Each Project has a ProjectType. Valid ProjectTypes include:
* platform: The Project represents a software platform, such as the
Project itself.
* kube-addon: The Project represents a Cloud Native Project, which is defined as
some software that extends the functionality of the cluster and
its API.
* kube-operator: The Project represents a Kubernetes [Operator][operator],
which is defined as software written specifically against the API
and is responsible for installing and managing the lifecycle of a Kubernetes
Addon or Application Service.
* kube-control-plane-provider: The Project represents a Kubernetes control
plane service, such as RKE, GKE or EKS.
* application-service: The Project represents application code that provides
essential services to the rest of the application stack.
* application: The Project represents customer-specific or internal code.
A Project is not the packaging of that software. Packaging of
Projects is described by the Package model.
# List Releases
Source: https://docs.chkk.io/api-reference/v2/project/list-releases
get /projects/{project}/releases
List multiple ProjectReleases
A Project may have one or more ProjectReleases. A ProjectRelease is
the coordinated publication of one or more Packages for the Project having the
same Version string.
A ProjectRelease is always associated with a single ProjectRelease.
A ProjectRelease is uniquely identified by the combination of the Project
identifier and the Version string, separated by an '@' character, e.g.
proj_a858f4d4-6e5b-4ab5-8d92-e9715b584ec1@1.5.12
A ProjectRelease can have zero or more Changes associated with it that describe
the bug fixes and new features that were included in the ProjectRelease.
# List ReleaseSeries
Source: https://docs.chkk.io/api-reference/v2/project/list-releaseseries
get /projects/{project}/releaseseries
List multiple ProjectReleaseSeries
A Project may have one or more ProjectReleaseSeries. A
ProjectReleaseSeries describes a single release series for a Project.
ProjectReleaseSeries are identified by a simple string that must be unique
for the Project. Typically the ProjectReleaseSeries Name will be a major or
major.minor version series, e.g. "4" or "1.28", however this is not
universally true. Some Projects use date-based names like "2024.04".
A ProjectReleaseSeries has a PublishedOn date which indicates when the
release was originally "cut".
# List VersionSets
Source: https://docs.chkk.io/api-reference/v2/project/list-versionsets
get /projects/{project}/versionsets
List multiple ProjectVersionSets
A ProjectVersionSet represents a configuration, layout or structure of
a Project that is consistent for a range of ProjectReleases.
A ProjectComponent is associated with a single ProjectVersionSet. We track
changes to the componentry and structure of a Project over time using
ProjectVersionSets.
ProjectVersionSets are uniquely identified by the Project ID or Alias and
a simple integer, separated by a ':' character.
Examples of ProjectVersionSet identifiers:
* argo-workflows:1: the first ProjectVersionSet of the Argo Workflows
Project, using the "argo-workflows" Alias as the identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3 the third ProjectVersionSet of
the Argo Workflows Project, using the Argo Workflow Project's UUID as the
identifier.
Each ProjectVersionSet has a Constraint field that is a Semantic Versioning 2
Version Constraint, e.g. >=1.2.1 or <2.34.50. This Version Constraint
indicates which ProjectReleases the ProjectVersionSet describes.
# Update Component
Source: https://docs.chkk.io/api-reference/v2/project/update-component
put /projects/{project}/versionsets/{number}/components/{component}/
Update an existing ProjectComponent
A ProjectComponent is a separate binary, daemon, or subsystem of a
Project.
> **NOTE**: ProjectComponents that are associated with a PackageComponent for a
> Package with PackageSystem kube or helm can be thought of as
> roughly equivalent to OCI/Docker Images, since the ProjectComponent
> describes a container within a Resource described by that
> PackageComponent.
A ProjectComponent is uniquely identified by the combination of a
ProjectVersionSet identifier and the Component name separated by a :
character. The Component name is a simple name indicating the binary, daemon
or subsystem.
Examples of ProjectComponent identifiers:
* argo-workflows:1:workflow-controller: the
workflow-controller binary of the first versionset of the Argo Workflows
Project, using the argo-workflows Alias as the Project identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3:workflow-controller: the
workflow-controller binary of the third ProjectVersionSet of the Argo
Workflows Project, using the Argo Workflow Project's UUID as the identifier.
# Update Project
Source: https://docs.chkk.io/api-reference/v2/project/update-project
put /projects/{project}/
Update an existing Project
A Project is software that provides some functionality.
Projects are uniquely identified by a UUID, prefixed with the string
proj_, for example proj_c42014e7-baf5-4ec6-a502-858f98dca7c8
Projects can have zero or more Aliases. Aliases are completely free-form.
They can be a URL, like github.com/kubernetes/kubernetes or a short string
like k8s or kube.
Each Project has a ProjectType. Valid ProjectTypes include:
* platform: The Project represents a software platform, such as the
Project itself.
* kube-addon: The Project represents a Cloud Native Project, which is defined as
some software that extends the functionality of the cluster and
its API.
* kube-operator: The Project represents a Kubernetes [Operator][operator],
which is defined as software written specifically against the API
and is responsible for installing and managing the lifecycle of a Kubernetes
Addon or Application Service.
* kube-control-plane-provider: The Project represents a Kubernetes control
plane service, such as RKE, GKE or EKS.
* application-service: The Project represents application code that provides
essential services to the rest of the application stack.
* application: The Project represents customer-specific or internal code.
A Project is not the packaging of that software. Packaging of
Projects is described by the Package model.
# Update Release
Source: https://docs.chkk.io/api-reference/v2/project/update-release
put /projects/{project}/releases/{release}/
Update an existing ProjectRelease
A Project may have one or more ProjectReleases. A ProjectRelease is
the coordinated publication of one or more Packages for the Project having the
same Version string.
A ProjectRelease is always associated with a single ProjectRelease.
A ProjectRelease is uniquely identified by the combination of the Project
identifier and the Version string, separated by an '@' character, e.g.
proj_a858f4d4-6e5b-4ab5-8d92-e9715b584ec1@1.5.12
A ProjectRelease can have zero or more Changes associated with it that describe
the bug fixes and new features that were included in the ProjectRelease.
# Update ReleaseSeries
Source: https://docs.chkk.io/api-reference/v2/project/update-releaseseries
put /projects/{project}/releaseseries/{series}/
Update an existing ProjectReleaseSeries
A Project may have one or more ProjectReleaseSeries. A
ProjectReleaseSeries describes a single release series for a Project.
ProjectReleaseSeries are identified by a simple string that must be unique
for the Project. Typically the ProjectReleaseSeries Name will be a major or
major.minor version series, e.g. "4" or "1.28", however this is not
universally true. Some Projects use date-based names like "2024.04".
A ProjectReleaseSeries has a PublishedOn date which indicates when the
release was originally "cut".
# Update VersionSet
Source: https://docs.chkk.io/api-reference/v2/project/update-versionset
put /projects/{project}/versionsets/{number}/
Update an existing ProjectVersionSet
A ProjectVersionSet represents a configuration, layout or structure of
a Project that is consistent for a range of ProjectReleases.
A ProjectComponent is associated with a single ProjectVersionSet. We track
changes to the componentry and structure of a Project over time using
ProjectVersionSets.
ProjectVersionSets are uniquely identified by the Project ID or Alias and
a simple integer, separated by a ':' character.
Examples of ProjectVersionSet identifiers:
* argo-workflows:1: the first ProjectVersionSet of the Argo Workflows
Project, using the "argo-workflows" Alias as the identifier.
* proj_dda0b12f-9a76-43ff-a024-9839ed3ee57b:3 the third ProjectVersionSet of
the Argo Workflows Project, using the Argo Workflow Project's UUID as the
identifier.
Each ProjectVersionSet has a Constraint field that is a Semantic Versioning 2
Version Constraint, e.g. >=1.2.1 or <2.34.50. This Version Constraint
indicates which ProjectReleases the ProjectVersionSet describes.
# Claude Code + Chkk in 5 minutes
Source: https://docs.chkk.io/lcm-agents/claude-code
Use Chkk to provide precise, environment-aware context to plan safe software upgrades and create pull requests with updated configuration files and manifests.
## Prerequisites
1. [Install Docker](https://docs.docker.com/get-docker/): Required to run the Chkk-Upgrade-Context-MCP Server.
2. [Install Claude Code](/resources/installation-guides/claude-code): Required to begin generating environment-aware pull requests.
3. A [Claude.ai](https://claude.ai/) (recommended) or [Anthropic Console](https://console.anthropic.com/) account
Agent Responses on this page are illustrative. Exact phrasing from your AI
model may vary depending on the model, settings, and repository context.
For the best experience, it is recommended to use the **claude-4-sonnet** model with the Chkk-Upgrade-Context-MCP Server.
Run the following command to clone the sample Chkk IaC repo:
```bash theme={"dark"}
git clone git@github.com:chkk-io/upgrade-playground.git && \
cd upgrade-playground
```
1. In the **Chkk Dashboard**, expand **Configure** on the left menu and click **Settings**.
2. Select the **Tokens** tab. Here you'll see a list of all your active tokens (if any), along with options to create new ones or revoke existing ones.
3. Click on the **clipboard** icon next to a token to copy it.
Install the `Chkk-Upgrade-Context-MCP` using the Claude Code CLI:
```bash theme={"dark"}
claude mcp add Chkk-Upgrade-Context-MCP --env CHKK_ACCESS_TOKEN="" -- docker run -i --rm -e CHKK_ACCESS_TOKEN public.ecr.aws/chkk/chkk-mcp-upgrade-context:latest
```
Replace `` with your Chkk Access Token.
Verify via CLI that the server is registered:
```bash theme={"dark"}
claude mcp get Chkk-Upgrade-Context-MCP
```
The command should return server details indicating it is installed and enabled.
1. In the **left-hand column** of the **Chkk Dashboard**, expand **Upgrade Copilot**.
2. Under **Upgrade Plans** select **Add-on & App Services**.
3. On the **Middle Right** corner of the page, enable the **Show Example Data** toggle, as shown in the image below.
4. This will switch the view to only show example data and displays a confirmation banner.
5. In the table below, you will see a list of Add-on and Application Service **Example Upgrade Plans**.
6. Select any Upgrade Plan from the table that has the **AI Context Generated** badge, as shown in the image below.
The **AI Context Generated** badge indicates that these Upgrade Plans are supported by the **Chkk-Upgrade-Context-MCP Server**.
7. At the top of the page, under the name of the Upgrade Plan, you will see the **Upgrade ID**.
8. Click the **clipboard** icon to copy the Upgrade ID to your clipboard.
From inside the `upgrade-playground` directory, start Claude Code.
```bash theme={"dark"}
claude
```
Open a chat in Claude Code and send:
You're in a K8s repo. Fetch "addon-upgrade-agent" from Chkk MCP and upgrade the package listed in the upgrade plan. Start by asking for the upgrade ID.
Your opening prompt is flexible, but it **must** explicitly instruct the assistant to **fetch "addon-upgrade-agent" from Chkk MCP**.
**Agent Response:**
Paste your **upgrade ID** (from your instantiated [Add-on or Application Service Upgrade Plan](/resources/glossary#cloud-native-project-and-application-service-upgrade-plan)), for example:
upgr\_ea53db65-3d8d-4744-b8b7-92e3c7552932
**Agent Response:**
The assistant will fetch Upgrade Context, stage artifacts in a local **Scratchpad** (`.chkk/scratchpad/upgrade-agent/` in the current working directory),
apply targeted edits (`Chart.yaml`, `values.yaml`, minimal templates), and summarize the changes it has made.
**Agent Response:**
To ensure your model is not overwhelmed by the task scope, any modifications are processed in batches of 5 files at a time.
You can now review the changes made within each file, which you would have
otherwise would have had to do manually.
**Agent Response:**
Learn more in the [Upgrade Agent guide](/ai/upgrade-agent).
## Next steps
* Add your own upgrade plans in Chkk and repeat the flow
* Enable auto-confirm in trusted repos for zero-click edits
# Cursor + Chkk in 5 minutes
Source: https://docs.chkk.io/lcm-agents/cursor
Use Chkk to provide precise, environment-aware context to plan safe software upgrades and create pull requests with updated configuration files and manifests.
export const cursorDeeplink = "cursor://anysphere.cursor-deeplink/mcp/install?name=Chkk%20Upgrade%20Context%20MCP&config=eyJjb21tYW5kIjoiZG9ja2VyIHJ1biAtaSAtLXJtIC1lIENIS0tfQUNDRVNTX1RPS0VOIHB1YmxpYy5lY3IuYXdzL2Noa2svY2hray1tY3AtdXBncmFkZS1jb250ZXh0OmxhdGVzdCIsImVudiI6eyJDSEtLX0FDQ0VTU19UT0tFTiI6IjxBREQgVE9LRU4%252BIn19";
## Prerequisites
1. [Install Docker](https://docs.docker.com/get-docker/): Required to run the Chkk-Upgrade-Context-MCP Server.
2. [Install Cursor](/resources/installation-guides/cursor): Required to begin generating environment-aware pull requests.
Agent Responses on this page are illustrative. Exact phrasing from your AI
model may vary depending on the model, settings, and repository context.
For the best experience, it is recommended to use the **claude-4-sonnet** model with the Chkk-Upgrade-Context-MCP Server.
Run the following command to clone the sample Chkk IaC repo and open it in Cursor:
```bash theme={"dark"}
git clone git@github.com:chkk-io/upgrade-playground.git && \
cd upgrade-playground && \
cursor .
```
1. In the **Chkk Dashboard**, expand **Configure** on the left menu and click **Settings**.
2. Select the **Tokens** tab. Here you'll see a list of all your active tokens (if any), along with options to create new ones or revoke existing ones.
3. Click on the **clipboard** icon next to a token to copy it.
Click the card below to install the Chkk Upgrade Context MCP Server in Cursor.
Click here to add Chkk to your Cursor
Paste your Chkk Access Token in the `CHKK_ACCESS_TOKEN` environment variable
in the **MCP Tool Settings** opened via the deeplink in the previous step.
Verify in **MCP Tool Settings** that Chkk Upgrade Context MCP Server is
successfully installed and enabled.
1. In the **left-hand column** of the **Chkk Dashboard**, expand **Upgrade Copilot**.
2. Under **Upgrade Plans** select **Add-on & App Services**.
3. On the **Middle Right** corner of the page, enable the **Show Example Data** toggle, as shown in the image below.
4. This will switch the view to only show example data and displays a confirmation banner.
5. In the table below, you will see a list of Add-on and Application Service **Example Upgrade Plans**.
6. Select any Upgrade Plan from the table that has the **AI Context Generated** badge, as shown in the image below.
The **AI Context Generated** badge indicates that these Upgrade Plans are supported by the **Chkk-Upgrade-Context-MCP Server**.
7. At the top of the page, under the name of the Upgrade Plan, you will see the **Upgrade ID**.
8. Click the **clipboard** icon to copy the Upgrade ID to your clipboard.
Paste and send the following Prompt in the Cursor chat:
You're in a K8s repo. Fetch "addon-upgrade-agent" from Chkk MCP and upgrade the package listed in the upgrade plan. Start by asking for the upgrade ID.
Your opening prompt is flexible, but it **must** explicitly instruct the agent to **fetch "addon-upgrade-agent" from Chkk MCP**.
**Agent Response:**
Paste your **upgrade ID** (from your instantiated [Add-on or Application Service Upgrade Plan](/resources/glossary#cloud-native-project-and-application-service-upgrade-plan)), for example:
upgr\_ea53db65-3d8d-4744-b8b7-92e3c7552932
**Agent Response:**
Cursor will fetch Upgrade Context, stage artifacts in a local **Scratchpad** (`.chkk/scratchpad/upgrade-agent/` in the current working directory),
apply targeted edits (`Chart.yaml`, `values.yaml`, minimal templates), and summarize the changes it has made.
**Agent Response:**
To ensure your model is not overwhelmed by the task scope, any modifications are processed in batches of 5 files at a time.
You can now review the changes made within each file, which you would have
otherwise would have had to do manually.
Learn more in the [Upgrade Agent guide](/ai/upgrade-agent).
## Next steps
* Add your own upgrade plans in Chkk and repeat the flow
* Enable auto-confirm in trusted repos for zero-click edits
# Lifecycle Management Agents
Source: https://docs.chkk.io/lcm-agents/guide
Use Chkk Upgrade Agent in Cursor and Claude Code to apply environment‑aware upgrade workflows to your IaC and open focused PRs.
Apply upgrades from Cursor using the Chkk Upgrade Agent.
Apply upgrades from Claude Code using the Chkk Upgrade Agent.
Apply upgrades from GitHub Copilot using the Chkk Upgrade Agent. (Coming Soon)
# I'm an agent
Source: https://docs.chkk.io/start/for-agents
Get hands-on with Chkk in minutes.
Use the **Upgrade Agent** (powered by the Upgrade Context MCP server) to connect Cursor or Claude Code and generate safe, environment‑aware diffs for your IaC. Open the quickstart to get set up in minutes.
[Open the Quickstart for Upgrade Agent](/overview/quickstart-upgrade-agent)
***
Questions or feedback? Email **[support@chkk.io](mailto:support@chkk.io)**
# I'm an engineer
Source: https://docs.chkk.io/start/for-engineers
Get hands-on with Chkk in minutes.
### Step 1: Download Chkk CLI
Install a pre-built binary on Linux using the following instructions.
```bash theme={"dark"}
# For AMD64 / x86_64
[ $(uname -m) = x86_64 ] && curl -Lo ./chkk https://cli.chkk.io/download/latest/chkk-linux-amd64
# For ARM64
[ $(uname -m) = aarch64 ] && curl -Lo ./chkk https://cli.chkk.io/download/latest/chkk-linux-arm64
chmod +x ./chkk
sudo mv ./chkk /usr/local/bin/chkk
```
Install using Homebrew on MacOS.
```bash theme={"dark"}
brew install chkk-io/cli/chkk
```
Or install a pre-built binary using the following instructions.
```bash theme={"dark"}
# For Intel Macs
[ $(uname -m) = x86_64 ] && curl -Lo ./chkk https://cli.chkk.io/download/latest/chkk-darwin-amd64
# For M1 / ARM Macs
[ $(uname -m) = arm64 ] && curl -Lo ./chkk https://cli.chkk.io/download/latest/chkk-darwin-arm64
chmod +x ./chkk
mv ./chkk /some-dir-in-your-PATH/chkk
```
Install a pre-built binary on Windows in PowerShell.
```
curl.exe -Lo chkk-windows-amd64.exe https://cli.chkk.io/download/latest/chkk-windows-amd64
Move-Item .\chkk-windows-amd64.exe c:\some-dir-in-your-PATH\chkk.exe
```
### Step 2: Run `chkk start` command
The `chkk start` command will get you started in the Chkk universe.
Type `chkk start` in a terminal to begin.
```sh theme={"dark"}
> chkk start
__ __ __
.----| |--| |--| |--.
| __| | <| <
|____|__|__|__|__|__|__|
Welcome to Chkk!
```
Follow the on-screen prompts to try out Chkk.
Need help? **[support@chkk.io](mailto:support@chkk.io)**
# I'm a manager
Source: https://docs.chkk.io/start/for-managers
Get hands-on with Chkk in minutes.
### Step 1: Sign in to the Chkk Dashboard
Head to **[https://app.chkk.io](https://app.chkk.io)** and sign in with Google, GitHub, Microsoft or email OTP.
### Step 2: Explore Example Data
We’ve pre-loaded an example cluster so you can:
* Browse the **Risk Ledger** for operational risks
* Inspect the **Artifact Register**
* Review sample Upgrade Plans, Templates and Assessments
No installation or onboarding required.
### Step 3: Talk to Us
Questions or feedback? Email **[support@chkk.io](mailto:support@chkk.io)**
# I've Only Got 5 Minutes
Source: https://docs.chkk.io/start/guide
Select your path — Engineer, Manager or Agent — and explore Chkk in under five minutes. Free to use, no credit card required.
Download the CLI, run chkk start, and see results in minutes.
Dive into a example data on Chkk dashboard: Upgrade Plans, Risks, ....
Leverage the relevant context to complete your lifecycle management tasks ...