GitLab Cloud NativeGitLab KubernetesKubernetes DeploymentRelease Automation

Article & Tutorial

Deploy to Kubernetes with GitLab CI/CD

Deploy immutable application images from GitLab CI/CD to Kubernetes with scoped identity, protected environments, rollout verification, health checks, approvals, and rollback.

Approved container image passing a deployment gate into a resilient Kubernetes cluster
Approved container image passing a deployment gate into a resilient Kubernetes cluster
Contents

A GitLab-to-Kubernetes deployment should promote a verified image into a protected environment using a narrowly scoped identity. The pipeline must confirm rollout health and preserve enough evidence to identify exactly what was deployed, by whom, and from which commit.

Deployment prerequisites

  • A tested image exists in an approved registry under an immutable digest.
  • Kubernetes manifests or a packaging layer are version controlled.
  • The deployment identity is limited to required namespaces and resources.
  • Production environments and branches are protected.
  • Readiness, liveness, startup, and resource settings are defined.
  • Rollback and database compatibility have been planned.

Identity and cluster access

Prefer short-lived workload identity or an agent-based connection over long-lived administrative kubeconfig data. If a credential file is unavoidable, scope it tightly, protect the variable, restrict runner access, and rotate it regularly. Never grant cluster-admin to routine deployment jobs.

Safe deployment flow

  1. Resolve the approved image digest.
  2. Render and validate the intended manifests.
  3. Run policy and security checks.
  4. Record a diff against the current cluster state.
  5. Require approval for sensitive environments.
  6. Apply the change with the scoped identity.
  7. Wait for rollout status and health checks.
  8. Run a bounded smoke test.
  9. Record the release and notify owners.

GitLab environments

Environments provide deployment history and status. Use environment protection to control who can deploy, define clear staging and production boundaries, and avoid using a single credential across unrelated environments.

Rollout and rollback

SignalResponse
Rollout completes and smoke tests passMark release successful
Pods fail readinessInspect events, configuration, and dependencies
Error rate risesPause or roll back according to policy
Schema incompatibilityUse the application’s tested database recovery plan
Pipeline times outCheck actual cluster state before retrying

Common mistakes

  • Deploying a moving image tag without recording the digest.
  • Giving the CI identity broad cluster permissions.
  • Running production deployment on shared untrusted runners.
  • Treating a successful apply command as proof of application health.
  • Retrying after timeout without checking whether the first action succeeded.
  • Changing application and irreversible schema behavior without coordinated rollback.

GitLab Kubernetes integration documentation

Did this help?

Yes No

Join the discussion

0 Comments

Ask questions, add context, or share what worked.

Sign in to join the discussion

No comments yet. Start the discussion.

More from Melochip Editorial

Related articles

Stay in the loop. Get new Melochip articles

Receive Melochip article updates when new articles are available. Explicit opt-in only.

No pre-checked boxes. Unsubscribe support is part of the subscriber foundation.