GitOps has continued in its popularity and has become the standard way to manage Kubernetes cluster configuration and applications. Red Hat continues to see the widespread adoption of the GitOps methodology across our portfolio as customers look for ways to bring increased efficiency to their operations and development teams.
Red Hat is pleased to announce that version 1.13 of OpenShift GitOps has been released, bringing with it some exciting new capabilities.
New in version 1.13
Rollouts is Generally Available (GA)
Argo Rollouts is now GA in OpenShift GitOps and can be used in Production scenarios. Rollouts is a drop-in replacement for the standard Kubernetes Deployment but provides additional capabilities to support advanced deployment strategies such as canary and blue-green. Additional features like testing via Analysis of Experiments are included to facilitate automated rollout/rollback decisions.
As part of the GA release, a new traffic manager has been added to support OpenShift Routes in addition to the existing traffic managers which included support for OpenShift Service Mesh. Previously only best effort could be used with the Canary strategy when using OpenShift Routes. With the new traffic manager traffic weighting can be precisely controlled as the canary progresses.
Additional information on Rollouts can be found in the OpenShift GitOps documentation here.
Applications In Any Namespace is Generally Available
By default, Argo CD requires that any Application Custom Resources must reside in the same namespace as the Argo CD instance that is managing the Application. This has implications in multi-tenant GitOps instances since it effectively prevents users from declaratively defining Application objects as they can bypass security measures simply by assigning the Application to another tenant’s Argo CD Project by directly modifying the yaml.
The feature Applications in any namespace resolves this issue by allowing Application resources to reside in alternate namespaces assigned to users. The Argo CD Project selection for these applications is enforced by Administrators by configuring specific Projects for specific namespaces.
In OpenShift GitOps 1.13 this feature is now Generally Available and can be used in Production environments. Note that ApplicationSets in any namespace remain Technical Preview.
Disable Default Cluster Scoped Roles
The Application in any namespace feature requires a cluster scoped instance of OpenShift GitOps since it needs to monitor multiple namespaces for Application objects. Previously with cluster scoped instances OpenShift GitOps would include additional capabilities by default to manage operators, storage and more as per the documentation. This was done with the intention that cluster scoped instances would be primarily used for cluster configuration.
However with the Application in any namespace feature there is a need to deploy cluster scoped instances for tenants who do not require these additional permissions. To support this, in OpenShift GitOps 1.13 these additional privileges can be disabled enabling administrators to better adjust the level of Kubernetes capabilities provided to meet the specific use cases being addressed.
apiVersion: argoproj.io/v1alpha1
kind: ArgoCD
metadata:
name: example-argocd
spec:
defaultClusterScopedRoleDisabled: true
...
Reencrypt is now the default TLS for the GitOps Route
In previous versions if no TLS configuration was specified in the Argo CD custom resource the operator would use Passthrough by default. This exposed the internal OpenShift certificate to users where they would be prompted in the browser to accept the unknown certification even if the OpenShift ingress itself was configured with a valid certificate. Switching to reencrypt as the default ensures that the default OpenShift ingress certificate will be used, providing a better user experience.
Important Note: If you want to continue using the previous default Passthrough TLS you will need to configure this in the Argo CD custom resource prior to upgrading.
Argo CD 2.11 Available
With this version, Argo CD has been upgraded to 2.11 which brings a number of new features and benefits including:
- Improved performance for mono-repositories using the generate-path annotation, while previously honored for web-hooks it is now also used when comparing for changes outside of web hooks.
- Improved support for Multiple Sources in the Argo CD CLI.
- Enabled Sharding by Application Information. When using multiple clusters with Argo CD sharding can be used to distribute the load across multiple Application Controllers. Sharding can now use the number of applications on each cluster to help determine the distribution of clusters across controllers.
- Pruning resources in reverse sync order. When using sync-waves and resources require pruning, Argo CD will now prune these resources in reverse order. Note that reverse sync order was already used when deleting an application.
A blog on the changes in Argo CD 2.11 is available here and a detailed list of all changes can be found here in the changelog with the release information.
Conclusion
OpenShift GitOps 1.13 is a significant update with many new features, to learn more about this update please review the official documentation and release notes.