Kubernetes CI/CD Pipelines: 8 Best Practices and Tools

CI/CD pipelines automate testing, security scanning, and deployment, so every change passes through the same set of steps. That consistency is what lets you ship faster without lowering your standards.

Kubernetes raises the stakes. Your pipeline needs credentials for a production cluster, and a failed rollout can leave workloads stuck between two versions. Combining the right tools for your team matters more here than it does elsewhere, and there is no shortage of platforms competing for the job.

In this article, you’ll learn eight best practices for running CI/CD pipelines with Kubernetes, plus five tools that put them into practice. You can use these strategies to automate deployments straight to your production clusters.

Kubernetes is commonly used to support CI/CD processes by automating the deployment, scaling, and management of containerized applications. It allows development teams to continuously deliver updates with minimal downtime, making it ideal for modern DevOps workflows. In a CI/CD pipeline, Kubernetes can orchestrate environments dynamically, ensuring consistency and efficiency from testing to production.

Kubernetes does not provide CI/CD functionality itself. It hosts the tools that do, and it runs the workloads they deploy. Kubernetes handles scaling, health checks, and rolling updates, whereas your CI/CD platform decides what to build, what to test, and when to ship it.

Using Kubernetes with CI/CD pipelines helps you automatically deploy applications whenever your source code changes. You can improve the Kubernetes management experience by automating key tasks. CI/CD also provides an opportunity to verify new deployments meet the standards you expect, such as passing your test suite and being free from security issues.

Nonetheless, integrating Kubernetes into CI/CD workflows can create new problems. Cluster administrators lose visibility into what is actually running, and debugging a failed deployment means correlating pipeline logs, controller events, and cluster state across three different tools. Integrations are also potential security risks, as compromising your CI/CD provider could let attackers access your clusters.

Below are some tips on how you can address these drawbacks by confidently combining CI/CD and Kubernetes.

The combination works well once it is set up correctly, and it fails in confusing ways when it is not. These eight practices cover the failure modes that cost the most time to diagnose.

The best practices for CI/CD and Kubernetes include:

1. Make GitOps the only way into your cluster
2. Scan container images before they reach your cluster
3. Package deployments with Helm or Kustomize
4. Ensure there’s a rollback mechanism
5. Use immutable image tags
6. Give your pipeline the narrowest Kubernetes access that works
7. Use pull-based workflows so credentials never leave the cluster
8. Automate drift detection

The term GitOps refers to the practice of keeping your infrastructure configuration as files in your source control repository. Managing everything with Git ensures every essential resource is versioned. It also means you can reference any resource within your pipelines, so you can check the validity of your config and quickly identify any errors.

Manually triggering pipelines from external systems is unreliable and error-prone. Using Git to run a pipeline each time you commit ensures changes can’t slip through to production unnoticed. If you need to revert a deployment, you can check out an older commit and replay the pipeline.

Popular GitOps tools for Kubernetes include Argo CD and Flux, both CNCF Graduated projects widely adopted for production GitOps workflows. On the infrastructure side, Spacelift applies the same Git-based workflow to Kubernetes and to your infrastructure as code (IaC) tooling, so clusters, cloud resources, and policies all move through one review path.

See how to manage and automate Kubernetes deployments in GitOps and the top GitOps tools to use for your workflows.

Deploying container images straight to Kubernetes is a security risk. Your images could include zero-day vulnerabilities, accidentally hardcoded secrets, or a malicious package that’s infiltrated your supply chain.

Trivy, Grype, and Snyk all run as a single CLI step and return a non-zero exit code when they find something above your severity threshold, which is what lets you fail the build. Docker’s own scanner is Docker Scout, which replaced the old docker scan command. docker scan is gone, not just deprecated, so pipelines that still call it fail outright.

Whichever scanner you pick, pin the CI action or image by commit SHA rather than a floating tag. Scanners run with registry credentials and repository access, which makes them a high-value target: Trivy itself had its repository and its GitHub Actions compromised twice in early 2026, and a malicious release shipped before Homebrew rolled it back. Your scanner is part of your supply chain too.

You can use tools such as Snyk to generate your reports. Snyk also powers the docker scan command that’s integrated into Docker’s CLI.

Applying Kubernetes manifests individually is problematic because files can get overlooked. Packaging your applications as Helm charts lets you version your manifests and easily repeat deployments into different environments. Helm tracks the state of each deployment as a “release” in your cluster.

Helm also simplifies configuration management. When you install your charts, you can easily supply variables, either using YAML files or as command-line arguments. This lets you conveniently override specific variables within your pipeline scripts.

Check out this Kustomize vs. Helm comparison.

Continuous delivery pipelines are fine until one breaks, and a stalled rollout is less dramatic than people assume. With the default RollingUpdate strategy, maxUnavailable and maxSurge are both 25%, and the controller will not kill old Pods to make room for new ones that never become ready. At least 75% of your replicas keep serving: you are stuck, not down. Only Recreate or maxUnavailable near 100% takes you offline.

progressDeadlineSeconds defaults to 600, but it measures time without progress, so a slow rollout that keeps advancing never trips it. When it fires, the controller marks Progressing as False with reason ProgressDeadlineExceeded. Kubernetes neither rolls back nor stops: the new ReplicaSet keeps creating crashlooping Pods until you intervene. Gate your pipeline on the exit code of kubectl rollout status, never on kubectl apply, which returns 0 the moment the API server accepts your manifest.

kubectl rollout undo is immediate and puts your cluster ahead of Git. Argo CD will not revert your fix unless selfHeal: true, which is off by default, so the application sits OutOfSync until an unrelated merge triggers a sync: a landmine rather than a visible revert. Flux is the opposite and corrects Kustomization drift by default. Never set revisionHistoryLimit to 0, which deletes the ReplicaSets undo needs.

Reverting the commit keeps Git authoritative and is the right GitOps default. A webhook removes the polling delay; what remains is CI build time plus the rollout’s own duration, so measure it in staging first. For stateful workloads, write migrations the previous version can still run against. Then ship a deliberately broken image to staging and time the recovery.

Image tag immutability makes your deployments reproducible and helps enable resilient rollbacks. Always deploying my-app:latest is dangerous because the exact image that’s selected could change each time.

It’s much safer to tag each image you build uniquely. Using a truncated commit SHA is a popular strategy, resulting in tags like my-app:0ab43f. This allows you to easily cross-reference commits against the image artifacts and deployments they create. If you need to roll back, you can modify your Kubernetes deployment to refer to the image built from the previous commit.

Unique tags get you most of the way, and digests get you the rest. A tag is a mutable pointer by default. Whoever can push to your registry can move my-app:0ab43f to different bytes, and your cluster will pull them on the next Pod restart. A digest reference like my-app@sha256:9f86d0... names the content itself and cannot be repointed.

The practical compromise most teams land on is tagging by commit SHA for humans and resolving to a digest in the manifest your pipeline actually applies. Your build step already knows the digest, so pass it forward rather than re-resolving the tag at deploy time. Enabling immutable tags in your registry, where supported, closes the same hole from the other direction.

It’s important to keep following standard Kubernetes security best practices when you’re integrating your clusters with CI/CD platforms: 

• Harden your environment by enabling etcd encryption. 
• Set up precise RBAC permissions for your CI/CD user accounts.
• Ensure any sensitive config values are added to Secrets instead of plain ConfigMaps.

Check that your CI/CD platform only exposes your cluster connections to projects and users you’ve specifically authorized. Remember that anyone who can commit to your project could send malicious code through the pipeline into your Kubernetes cluster.

SLSA covers the half of this problem that cluster hardening does not touch. Its Build track runs from L0 to L3 and describes how much you can trust an artifact’s provenance: L1 means provenance exists, L2 means a hosted platform generates and signs it, and L3 means the build platform is hardened against tampering between runs. It says nothing about what happens after the artifact reaches your cluster.

That split is the useful part. SLSA tells you whether the image you are about to deploy was built by the pipeline you think built it. Kubernetes RBAC, admission control, and your CI runner’s permissions govern what happens next. You need both, and conflating them leaves a gap at the handoff.

There are two main ways to connect CI/CD systems to Kubernetes:

• Push-based workflows rely on the CI/CD platform being provided with certificates and credentials that let it reach out to your Kubernetes cluster. You then use familiar tools such as kubectl and Helm to push changes into Kubernetes from the outside.
• Pull-based workflows run an agent utility inside the cluster. The agent is given credentials for your source-control system. Its access should be scoped to just the projects it needs to deploy. The agent periodically looks for changes and pulls them into the cluster. This inverts the push-based model.

Pull-based CI/CD is increasingly popular because it provides stronger protection for your cluster. To be effective, push-based workflows require privileged Kubernetes credentials to be stored on your source control server. If the server’s compromised, attackers could steal the credentials, access your cluster, and perform arbitrary actions. 

With a pull-based workflow, attacks against the CI/CD platform won’t grant access to your entire cluster.

In any Kubernetes environment, the state you declared and the state actually running need to match. Over time, this consistency can break down due to what’s known as configuration drift. 

Drift occurs when changes are made directly to the cluster, perhaps via kubectl, hotfixes, or a third-party tool, without those changes being reflected in version control. This can lead to fragile deployments, security vulnerabilities, and unexpected behavior that’s difficult to troubleshoot.

To mitigate this risk, it’s important to automate drift detection. That means regularly comparing the live state of your cluster with the declared state in Git or your infrastructure-as-code setup. This way, you can catch any differences early and either alert the team or automatically correct them.

Spacelift runs scheduled plan operations against your declared state and either flags drift or remediates it automatically. This covers Kubernetes stacks and cloud resources in one place, which matters because drift in an EKS node group and drift in the workloads running on it usually show up together.

Beyond GitOps tools, you can also integrate drift detection at the infrastructure level using something like Terraform (or OpenTofu). For example, you can run automated terraform plan checks on a schedule or as part of your CI pipeline to see if anything’s changed outside of the expected workflow.

Terraform doesn’t directly manage Kubernetes resources inside the cluster, unless you’re using providers like kubernetes or helm, but it remains the right tool for the cloud infrastructure your workloads depend on, including networking, databases, and storage.

None of these best practices needs to be difficult. You should aim to create a toolchain that helps you run CI/CD pipelines efficiently in Kubernetes while avoiding security issues and common mistakes. 

Here are five CI/CD Kubernetes tools you can try out.

GitLab

GitLab is one of the most popular all-in-one software delivery platforms. It includes source management and CI/CD functions with excellent Kubernetes integration.

GitLab gives you two distinct paths through its agent for Kubernetes, and the difference matters more than the docs make obvious.

The CI/CD workflow runs kubectl from inside your pipeline. Your job still pushes changes, but it reaches the cluster through the agent’s outbound tunnel instead of a stored kubeconfig, so no cluster credentials sit in GitLab. Each agent gets its own kubecontext, and only the projects you explicitly authorize can use it.

The GitOps workflow is genuinely pull-based, and GitLab now delegates it to Flux rather than the agent’s own reconciler. GitLab recommends running both: Flux keeps cluster state synchronized with the source, whereas the agent simplifies the Flux setup, manages cluster-to-GitLab access, and surfaces cluster state in the GitLab UI.

If you built on the agent’s original GitOps support, GitLab publishes a migration path to Flux.

GitHub Actions

GitHub Actions is GitHub’s CI/CD solution. You can use it to run automated tasks each time you change your code. 

GitHub Actions has no built-in Kubernetes integration. Most teams reach for Azure’s Deploy to Kubernetes Cluster action, which supports canary and blue-green strategies but needs k8s-set-context and setup-kubectl alongside it. Note that it is community-maintained and explicitly outside Microsoft’s Azure support policy, so factor that into anything production-critical.

Use OIDC federation rather than a stored kubeconfig. Your workflow exchanges a short-lived token for cluster access at run time, which removes the long-lived credential that makes push-based workflows risky in the first place.

Read more: How to deploy Kubernetes with GitHub Actions?

Argo CD

Argo CD is a continuous delivery tool purpose-built for Kubernetes. It ships as part of the Argo project, which reached CNCF Graduated status in December 2022.

Argo CD runs in your cluster as a Kubernetes controller. It watches your applications, compares live state against your source control repository, and resynchronizes automatically when the two diverge by pulling your manifests and updating cluster resources. Sync waves and health checks let you order dependent resources rather than applying everything at once.

Read more about this tool in our ArgoCD – Practical Tutorial With Kubernetes article.

Kubectl and Helm

You can use existing Kubernetes CLIs such as Kubectl and Helm within your own CI/CD scripts. You will need to supply credentials that let the CLIs authenticate with your cluster, creating a push-based workflow.

This method can be more approachable and easier to set up than using a dedicated tool, especially if you’re only experimenting with Kubernetes. It lets you use the same commands you run on your workstation to roll out changes within your pipelines.

Spacelift

Spacelift is an infrastructure orchestration platform purpose-built for infrastructure as code — including Kubernetes. 

Kubernetes stacks give you a GitOps workflow where manifests are synced from Git, with kubectl-based previews on pull requests and policy-as-code controls on every change. 

Because Spacelift supports Terraform, OpenTofu, Terragrunt, Pulumi, CloudFormation, Ansible, and Kubernetes, you can wire cluster provisioning and workload deployment into one dependency graph and manage clusters alongside the cloud resources underneath them with a single tool.

Despite some initial complexity, integrating Kubernetes with your CI/CD workflows offers a range of practical benefits that align well with modern DevOps practices:

• Automated, scalable deployments – Kubernetes streamlines the deployment process by automating routine tasks and enabling dynamic workload scaling, reducing manual intervention and the potential for errors.
• Consistent environments – Kubernetes uses infrastructure as code (IaC) to help maintain consistency across development, staging, and production environments, minimizing environment-specific issues.
  Controlled updates and rollbacks – Built-in support for rolling updates and automated rollbacks enables smoother deployments and faster recovery from issues, improving release stability.
• Parallel processing for faster delivery – CI/CD pipelines can leverage Kubernetes’ distributed architecture to run tasks in parallel, which can significantly reduce build, test, and deployment times.
• Security and access management – Kubernetes offers fine-grained access control through features like RBAC, namespaces, and network policies, supporting better isolation and governance within your CI/CD workflows.

Using CI/CD with Kubernetes allows you to automate deployments, rapidly scale your services, and be confident that all live code has passed your test suite. The two technologies pair well if you follow the best practices we’ve explored.

When selecting a CI/CD pipeline solution for Kubernetes, assess the integration’s depth and consider its security model, rollback mechanisms, and support for your source management system.

You can use CI/CD to apply infrastructure changes using IaC techniques, either to Kubernetes or other tools such as Ansible and Terraform. Check out Spacelift to collaborate on infrastructure with full control and flexibility. It includes role-based security policies, detailed usage insights, and full visibility into everything running in your cloud accounts.