Coverage Matrix

Chkk Curated Release Notesv1.1.0 to latest
Private RegistriesCovered
Custom Built ImagesCovered
Preflight/Postflight Checks (Safety, Health, and Readiness)v1.2.1 to latest
Supported PackagesHelm, Kustomize, Kube
End-Of-Life(EOL) InformationCovered
Version Incompatibility InformationCovered
Upgrade TemplatesIn-Place, Blue-Green
PreverificationCovered

Crossplane Overview

Crossplane is a Kubernetes add-on 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 Kubernetes 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 Kubernetes 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 Kubernetes 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

Was this page helpful?