Gloo Edge OSS

​

Coverage Matrix

​

Gloo Edge OSS Overview

Gloo Edge OSS is an Envoy-based gateway that manages traffic routing, transforms, and integrations across Kubernetes 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 Kubernetes 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
• Gloo Edge OSS Releases