GitOps upholds the principle that Git is the primary source of truth for a system, so the git version history becomes the entire audit trail of changes to that system. All changes to the system’s state are fully traceable commits with the associated information, like committer information and change timestamp. If a commit is made that breaks a cluster, the cluster can be rolled back to the desired state merely by reverting back to the previous working commit.
With GitOps, we define our expected system (for example, a Kubernetes cluster) end state in declarative configuration, store it in Git, and follow a pull-request workflow for changes which are then tracked and audited. A declarative configuration should specify the intent of the end state while controllers reconcile any divergent state. If the system is not in the intended state, controllers will detect the difference and make the necessary changes to fulfill the intent. Controllers may also be layered in stages (so one controller’s output is input to other controller) to accomplish the end state goal. This enables you to test all changes (for example, OS patches) before pushing them to production.
Why choose Solo.io for GitOps
Document, expose, compose, and share APIs for use in your continuous integration/continuous delivery (CI/CD) pipelines. All of our products at Solo.io use a declarative configuration and controller approach and lend themselves very nicely to GitOps. For our Gloo Mesh product, we’ve built a set of controllers that greatly simplify configuring and managing Istio service meshes at scale across multiple clusters. In Gloo Mesh, we opt to federate multiple clusters by exposing services in remote clusters explicitly.
Solo has built controllers and high-level APIs exactly for this reason: to abstract away a lot of the detail of the lower-level Istio resources and focus on the intention of the traffic and security postures. The Gloo Mesh TrafficPolicy resource specifies routing and resilience rules between services while the AccessPolicy resource specifies security rules. Another resource, the VirtualDestination, defines globally routable services.
These higher-level resources are what should be stored into Git and applied to the Gloo Mesh management controllers. The Gloo Mesh management controllers run in a separate “meta” cluster that’s responsible for taking these higher-level resources and translating them to the correct lower-level Istio resources and orchestrating the configuration with the nuance, dependency, and context awareness to each cluster.
- Canary Upgrades
You can upgrade your Gloo deployments with a canary model. In the canary model, you have two different deployments in your data plane and can check that the deployment at the latest version handles traffic as you expect before upgrading to run at the latest version. Read more about canary updates. - Federate configuration as code
Manage application networking with common policies implemented consistently everywhere. Developers and operators can use declarative CRDs, as part of a DevOps or GitOps process, to route traffic, implement security policy, and configure observability. - A/B and blue/green deployments
Use GitOps to seamlessly apply application changes to development and production Kubernetes clusters and empower your developers to rapidly roll-out new services. Improve their developer experience and increase team velocity have chosen Flagger, Flux, and Argo to accelerate application delivery with reduced risk. - Last known good configuration
Upgrading your control plane configuration shouldn’t be scary, but when you are directing mission-critical traffic through your Envoy API gateways it’s good to be cautious. Solo has implemented the xDS replicas as an option in your Helm chart to safeguard your configuration changes and give you the ability to roll-back to the last known good configuration if necessary.
