Latest Flux Updates Simplify Horizontal Controller Scaling
The maintainers of the open source Flux project have made available an update that adds horizontal scaling and sharding capabilities to the Flux controllers.
In addition, the Git bootstrap capabilities provided by the Flux command line interface (CLI) and by the Flux Terraform Provider are now considered stable in Flux v2.0.0. The GitRepository, Kustomization and Receiver APIs have all been made generally available.
Flux is also fully integrated with Kubernetes Workload Identity for AWS, Azure and Google Cloud to facilitate passwordless authentication to sources such as container images, artifacts and Helm charts that comply with the Open Container Initiative (OCI) format.
Flux alerting capabilities have been extended with PagerDuty and Google Pub/Sub support in beta to provide better control over events filtering and enable IT teams to enrich alerts with custom metadata.
Finally, the build, release and provenance portions of the Flux project supply chain provisionally meet the Build Level 3 requirements of the Supply-chain Levels for Software Artifacts (SLSA) framework.
Stefan Prodan, principal engineer for Weaveworks and a maintainer of Flux, said Flux v2.0.0 is now much less monolithic than it was previously as it becomes simpler to scale out using microservices.
Developed to manage the state of Kubernetes clusters, Flux is now being advanced under the auspices of the Cloud Native Computing Foundation (CNCF). Weaveworks relies on Flux to provide the foundation for a continuous delivery platform that makes it simpler to apply GitOps best practices to infrastructure provisioning and cloud-native application deployment.
As a more prescriptive approach to creating and managing DevOps workflows, GitOps shifts the control point away from a continuous integration/continuous delivery (CI/CD) platform toward a Git repository. The goal is to more loosely couple CI and CD processes to enable Kubernetes clusters to pull code from a repository at a DevOps team’s discretion versus attempting to push code from a CI/CD platform onto multiple systems at the same time.
Previously, it was too difficult to achieve that goal when every platform used to run software had a unique set of application programming interfaces (APIs). However, with the rise of Kubernetes, it is now possible to have a consistent set of APIs in place from the network edge to on-premises IT environments and the cloud. The challenge is too many organizations are relying on tools such as Helm to deploy applications instead of frameworks like Flux that make it easier to deploy applications at scale, noted Prodan.
It’s not clear how quickly organizations are embracing GitOps, but as more cloud-native applications are built and deployed, it presents an opportunity to revisit how DevOps workflows are constructed. The issue is the degree to which organizations are willing to embrace GitOps to deploy cloud-native applications while relying on legacy CI/CD platforms to build and deploy monolithic applications. Advocates of GitOps note that most organizations never really mastered CD using those legacy platforms, so GitOps based on Kubernetes represents a major advance when it comes to automating application deployment.
One way or another, as the volume of applications organizations are developing simultaneously increases, it’s apparent that the CD debate needs to be resolved sooner than later.
