How do deployments happen in your Kubernetes environment, and what CI/CD tools do you use to deploy to Kubernetes clusters?
Quick Answer
Most production Kubernetes environments use a CI/CD pipeline (Jenkins, GitHub Actions, ArgoCD) that builds container images, pushes them to a registry, and either applies manifests directly or uses GitOps to reconcile desired state. The choice between push-based (kubectl apply in pipeline) and pull-based (ArgoCD watching git) defines the deployment model.
Detailed Answer
Think of a restaurant kitchen with a ticket system. In a push model, the waiter walks the order directly to the chef. In a pull model, the chef watches a ticket board and picks up new orders as they appear. Both get the food made, but the pull model means the chef always knows the current state of all orders without anyone having to push each one individually.
In Kubernetes, deployments typically follow one of two patterns. Push-based CI/CD tools like Jenkins or GitHub Actions run kubectl apply or helm upgrade as a pipeline step, directly sending manifests to the cluster API server. Pull-based GitOps tools like ArgoCD or Flux watch a Git repository and automatically reconcile the cluster state with what is declared in the repo. Many teams use a hybrid: CI builds and pushes images, then updates a Git repo, which triggers ArgoCD to deploy.
Internally, a typical pipeline has stages: code checkout, unit tests, Docker build with a tagged image (using git SHA or semantic version), image push to ECR or another registry, manifest update (either in-pipeline or via a Git commit to an infra repo), and deployment to the target cluster. For Kubernetes specifically, the Deployment controller handles rolling updates by creating a new ReplicaSet, scaling it up, and scaling the old one down. The pipeline may also run integration tests, smoke tests, or canary analysis after deployment.
At production scale, teams separate their CI (build and test) from CD (deploy). The CI pipeline produces a versioned artifact. The CD pipeline or GitOps controller handles promotion across environments: dev, staging, UAT, production. Environment-specific values are managed through Helm values files, Kustomize overlays, or ArgoCD ApplicationSets. Teams monitor deployment success through rollout status checks, readiness probe results, and automated rollback on failure.
The non-obvious gotcha is that push-based deployments can drift from the declared state if someone makes manual kubectl changes. GitOps tools detect and correct this drift automatically, but they add complexity around secret management and multi-cluster configuration. Teams that start with push-based pipelines often migrate to GitOps as the number of clusters and services grows beyond what manual pipeline management can handle reliably.