ArgoCD vs FluxCD: Why We’re Choosing Both?

 

ArgoCD: Empowering Developers

ArgoCD, a declarative, continuous delivery tool for Kubernetes applications, stands out with its GitOps approach to managing Kubernetes clusters and its distinctively user-friendly dashboard. The UI, arguably ArgoCD’s biggest selling point, visually displays the deployment status, allowing developers to grasp the state of their applications swiftly, including every single resource, and expedite the debugging of any issues. Furthermore, ArgoCD’s ability to display logs for developer workloads enhances its appeal. This feature offers detailed insights into the application stack and potential problems, proving crucial for quick debugging and efficient problem resolution.

The significant benefit of ArgoCD lies in its ability to eliminate the need for developers to have direct access to Kubernetes. Bringing unified workflow based on organization SSO auth, not only simplifies the development process but also enhances security, and allows to talk to predefined k8’s APIs and clusters, reducing potential attack surfaces.

 

FluxCD: The Ops’ Choice

FluxCD is similar, it synchronizes to Git repositories with the version and state of workloads in a cluster – much simpler to set up and without fancy UI, is an open-source tool offering a CLI-first approach, and it can also throw out manifests to apply them after. In contrast with ArgoCD, we do not have to define a bunch of additional CRDs, it relies 100% on Kubernetes API. It excels at orchestrating infrastructure workloads and managing clusters, RBAC, and controllers. KISS ( keep it super simple ) is particularly important to Ops, enabling them to manage infrastructure effectively.

 

The Workflow: Leveraging ArgoCD and FluxCD

At Kyotu Technology, we’ve woven both ArgoCD and FluxCD into our operational fabric to optimize our DevOps pipeline. The tools complement each other, catering to distinct parts of our workflow, enhancing our efficiency, and streamlining our operations.

 

FluxCD: Initiating the Process

Our journey commences with FluxCD, which sets up the initial structure for each project. It creates an organized and secure environment by establishing a new namespace, configuring RBAC for ArgoCD and Vault, and dealing with all necessary secret access and in general ACLs. These operations lay a robust groundwork for our deployment procedures.

 

ArgoCD: Deploying Applications

Following the initiation phase, ArgoCD takes over, focusing on application deployment. Here, ArgoCD shines with its ability to visualize and manage Helm charts for applications tied to a specific namespace. It integrates with our application repository which builds the app, manages Docker images, and updates Helm chart tags, ensuring a smooth and efficient deployment process.

 

Collaboration and synchronization:

In this environment where ArgoCD and FluxCD collaborate, our developers and Ops teams also work hand-in-hand, utilizing Git for effective collaboration and synchronization. This consistent alignment ensures that both application code and infrastructure evolve coherently, minimizing the likelihood of conflicts and errors, thereby maintaining an optimal and simple DevOps job.

 

xKyotu Project Operator – How do we do it?

The Kyotu Project Operator is a Kubernetes operator written in Rust using kube-rs. The operator’s role is to automate and manage the project lifecycle, namespace creation, and integration of ArgoCD applications. It is available for public use at https://github.com/Kyotu-Technology/kyotu-project-operator.

 

The Role of Kyotu Project Operator in the DevOps Workflow

The Kyotu Project Operator performs a range of functions upon creation or deletion of a Custom Resource Definition (CRD).

 

On CRD Creation

When a CRD is created, the Kyotu Project Operator initiates several operations:

1. Namespace Creation: A namespace for the project is created unless it already exists.
2. GitLab Group Generation: A dedicated GitLab group for the project is formed unless it already exists.
3. Group Access Token Management: A Group Access Token with access to the Docker registry is created or, if it already exists, rotated.
4. Kubernetes Pull Secret Production: A Kubernetes pull secret specific to the project is generated using the GitLab Group Access Token.
5. ArgoCD Application Integration: An ArgoCD application is added to the deployment repository.
6. RBACs Setup: Role-Based Access Controls (RBACs) for ArgoCD and Vault are created and checked into the Flux repository.

 

On CRD Deletion

When a CRD is deleted, the operator manages the following operations:

1. Namespace Removal: The namespace for the project is deleted, unless it was pre-existing.
2. Access Revocation: The Group Access Token and the Kubernetes pull secret for the project are deleted.
3. ArgoCD Application Removal: The ArgoCD application for the project is removed from the deployment repository.
4. RBACs Removal: The RBACs for ArgoCD and Vault are deleted from the Flux repository.

Note: The operator does not delete the GitLab group or the repositories.

 

Example CRD

Below is an example of how a Custom Resource Definition (CRD) for the operator is defined:

apiVersion: kyotu.tech/v1
 kind: Project
 metadata:
 name: test-project
 spec:
 projectId: test-project
 environmentType: dev
 googleGroup: [email protected]
 
 

Conclusion

In essence, our choice to integrate both ArgoCD and FluxCD into our workflow at Kyotu Technology has proven to be highly beneficial. By tapping into the unique strengths of each tool, we’ve achieved a comprehensive and efficient DevOps process that ensures smooth operations, enhanced productivity, and superior workflow efficiency.

The Kyotu Project Operator is an integral part of our DevOps workflow and showcases the effective use of ArgoCD and FluxCD. Automating crucial tasks using GitOps principles, it aids in creating an environment for collaboration, synchronization, and automation, which in turn enhances productivity and work quality. Stay tuned for more insights into our integrated DevOps approach.