Why use GitOps 

Some of Kubernetes' main advantages are its declarative resource model and the controllers' reconciliation loops. This allows you to define the desired state of your cluster, and the controllers attempt to bring the actual system environment in line with your defined configuration.

kubectl and tools like k9s and Lens are good for viewing cluster resources and making quick, ad-hoc changes. For defining and maintaining the desired state of a cluster over time, GitOps is a better fit.

GitOps answers a question that manual configuration and imperative scripting leave open: who made which changes and when (traceability and auditing). It keeps a transparent, auditable deployment process, tracks and applies changes automatically, and minimizes human error.

Following IaC principles, GitOps enables systematic and repeatable infrastructure configurations. This speeds up development cycles and better integrates with other DevOps tools and practices, making it an ideal fit for modern cloud-native environments. Learn more about Syself's GitOps deployment features.

Given that Syself Autopilot primarily interfaces with the Kubernetes API, you're free to pick any GitOps tool of your preference. Both Argo CD and Flux work well with Syself Autopilot.

Architecture 

You install your favorite GitOps tool responsible for continuous deployment in the workload cluster, with the Syself Autopilot management cluster being added as an external destination. This configuration lets the GitOps tool change the resources within Syself Autopilot, so the workload cluster matches the desired state defined in a Git repository. This is possible even for a previously created workload cluster, so you can bootstrap your cluster by manually applying it to Syself Autopilot and then pass the baton to your GitOps tool for ongoing management.

Fields Syself Autopilot sets for you 

Syself Autopilot fills in some parts of the Cluster object. The live object therefore always holds more than the manifest you keep in Git. Your GitOps setup has to tolerate that. Otherwise every sync reports drift on a field you never wrote.

spec.topology.version is the one to plan for. Syself Autopilot sets the Kubernetes version from the Cluster Stack release that spec.topology.class points at and rewrites it whenever you move the cluster to another release. Leave it out of your manifest and configure your tool to ignore it. The alternative is to keep setting it yourself and change it in the same commit as the class.

GitOps tools can exclude a field from their diff. In Argo CD it is ignoreDifferences. See Ignore the fields Syself Autopilot sets .

Installation and Configuration Guides 

The guides will cover the steps for basic installation and configuration of ArgoCD (Flux to come soon) to guarantee the best integration of these tools with Syself Autopilot. If you are new to the platform, you may also want to read the Concepts overview first.