I manage at least 10 Kubernetes clusters running Talos Linux. FluxCD handles deploying applications from a GitLab Cloud repository, but I also need a better way to run operational pipelines—for example, building and pushing container images, running tests, and periodically executing Ansible playbooks against selected clusters.
At the moment I use a basic Helm chart that creates many CronJobs from a `cronjobs:` configuration array. It works, but maintaining and expanding it feels awkward. I tried deploying Concourse with its official Helm chart, but its container runtime requirements conflicted with Talos security settings. Making the necessary privileged-workload adjustments and other workarounds production-ready seemed unnecessarily complicated.
I liked Concourse because its pipeline definitions seemed approachable for other teams, but I do not have much time to evaluate several new tools. What CI/CD or workflow platform would work reliably on Talos Linux and complement FluxCD, particularly for scheduled Ansible jobs and image-building pipelines?
5 Answers
For a more general orchestration platform, Kestra can run on Kubernetes and model scheduled or event-driven pipelines, including shell and Ansible steps. It is less common than Argo or Git-based runners, so I would choose it only if you want a broader workflow engine rather than a conventional CI/CD setup.
I would keep FluxCD for cluster state and use a Git-based runner for CI. GitLab pipelines or GitHub Actions with self-hosted Kubernetes runners can build and push images, run tests, and launch Ansible jobs without forcing the deployment tool to do everything. For Ansible specifically, AWX or Ascender is worth considering if you need scheduling, credentials, inventories, and run history instead of managing raw CronJobs.
Argo Workflows combined with Argo Events is probably the closest fit for this use case. Workflows can handle image builds, tests, and Ansible jobs, while Events can trigger them from schedules or repository events. FluxCD can remain responsible for deploying the resulting resources. It takes some effort to configure and the documentation can feel uneven, but the setup is reliable once established.
Tekton is another Kubernetes-native option to evaluate. It provides reusable Tasks and Pipelines and does not depend on a particular Git hosting provider. It is a better fit than a collection of CronJobs when you want pipeline status, reusable steps, and event-based execution, although it is more of a building block than a polished all-in-one platform.
The Talos issue is mainly about the workload security requirements rather than FluxCD. Tools that create nested containers or require broad privileged access can be troublesome on a hardened Kubernetes distribution. I would avoid weakening the security baseline just to accommodate one CI engine and instead choose runners or workflow controllers that use normal Kubernetes primitives wherever possible.
That is why Argo Workflows or Kubernetes-based GitLab/GitHub runners seem safer here: they can be configured around the cluster's security policies instead of depending on nested container behavior.