Implementing GitOps CI/CD Pipelines for Kubernetes using Terraform

In traditional cloud operations, infrastructure is provisioned by operations teams, while application deployment code is managed by developers. This separation often results in mismatched configurations, deployment bottlenecks, and difficulty auditing who changed what.

By applying **GitOps** principles, we treat infrastructure and deployment configurations identically to source code.

The GitOps Architecture Pattern

The GitOps workflow follows three core rules:

2. **Single Source of Truth**: Git is the only authority. No developer or administrator changes live resources via a GUI or CLI manually.

3. **Software Agents**: Active agents in the cluster constantly pull target configurations from git, comparing them with the live state and auto-syncing differences.

Phase 1: Provisioning with Terraform

We use Terraform to define the VPC network, Subnets, and IAM roles, plus the Kubernetes cluster itself (like AWS EKS or Azure AKS):

# main.tf
module "eks" {
  source  = "terraform-aws-modules/eks/aws"
  version = "~> 20.0"

  cluster_name    = "sanjeev-prod-cluster"
  cluster_version = "1.29"

  vpc_id     = module.vpc.vpc_id
  subnet_ids = module.vpc.private_subnets

  eks_managed_node_groups = {
    general = {
      min_size     = 2
      max_size     = 5
      desired_size = 3
      instance_types = ["t3.medium"]
    }
  }
}

Phase 2: GitOps sync with ArgoCD

Once the cluster is running, we deploy ArgoCD into the cluster. ArgoCD watches a specific repository folder containing Kubernetes manifests (Helm charts or Kustomize files) and applies them.

When a developer merges code:

2. The pipeline updates the image tag inside the git deployment manifest.

3. ArgoCD detects the change in the manifest and rolls out the new image to Kubernetes.

This process eliminates the need to expose Kubernetes cluster credentials to CI pipelines, making the setup exceptionally secure.