CI/CD Pipelines in k8or Orbit

By Anna V. April 1, 2025. Revised. Version: 0.0.03

1. Introduction

The CI/CD pipeline is a critical part of software development, facilitating continuous integration (where code changes are frequently merged and tested) and continuous delivery (where tested code is automatically or semi-automatically released to production). In the k8or Orbit ecosystem—comprising an Orbit Plane for management and a Cluster Plane for runtime—CI/CD ensures that your container images, Helm charts, and environment configurations are consistently built, tested, and deployed to K3s clusters.

This document presents a holistic view of how you might set up a CI/CD pipeline for Kubernetes in k8or Orbit using various open-source products, including Jenkins, GitLab CI, Tekton, GitHub Actions, Argo CD, and more. It also outlines where and how these products integrate with k8or Orbit’s components (CodeSource, ChartStore, AccessPoint, etc.) to form a robust, adaptable pipeline.

2. Why CI/CD Pipelines Matter in k8or Orbit

  1. Faster Releases: Automate repetitive tasks (builds, tests, packaging, scans) to release features and fixes rapidly.

  2. Consistency & Reliability: Standard pipelines ensure that all changes are tested and validated before hitting production.

  3. Visibility & Collaboration: Team members see real-time build/test results, improving collaboration and reducing misunderstandings.

  4. Integration with Kubernetes: CI/CD ties code commits to container images and chart deployments, bridging code merges to actual cluster updates in a controlled manner.

3. Stages of a Typical CI/CD Pipeline

  1. Code Commit & Version Control

    • Developers push changes to a Git repository (e.g., GitLab, GitHub).

    • A commit or pull request triggers the pipeline.

  2. Build & Test

    • The pipeline fetches the source code and builds container images or binaries.

    • Unit tests, integration tests, and security scans (e.g., image vulnerability scans) are run.

  3. Packaging & Artifact Storage

    • Container images are tagged and pushed to a registry (DockerHub or a private registry).

    • Helm charts or other manifests may be stored in a ChartStore (C20) or commit references in a Git repo.

  4. Deployment (CD) to Kubernetes

    • Tools like Argo CD watch a Git repo or ChartStore for new versions, automatically applying them to the target cluster.

    • Alternatively, a pipeline stage can directly apply manifests via kubectl or via a wrapper microservice.

  5. Validation & Observability

    • Cluster health and logs are monitored (via K8rix, ClusterWatch, HelloScope).

    • If acceptance or canary steps fail, an automated rollback or manual intervention can happen.

4. Possible CI/CD Tools & Their Role

4.1 Jenkins

  • Overview: A well-established Java-based CI server with a plugin ecosystem.

  • Integration with k8or Orbit:

    • Jenkins pipeline scripts can build container images, push to DockerHub (C96), store chart references in ChartStore (C20), and then notify Argo CD or apply them directly to the cluster.

    • Jenkins can be run in the Orbit Plane or externally, with AccessPoint bridging cluster interactions.

4.2 GitLab CI

  • Overview: Native CI solution integrated with GitLab repositories.

  • Integration with k8or Orbit:

    • Upon merges, GitLab CI runs jobs that build images, test code, and push results to CodeSource (C96).

    • The final stage might commit updated Helm charts to a Git repo, which Argo CD in the Orbit Plane uses for deployment.

4.3 Tekton

  • Overview: A Kubernetes-native CI/CD framework that runs pipelines as CRDs in the cluster.

  • Integration with k8or Orbit:

    • Tekton tasks and pipelines can exist in the dev or staging cluster.

    • Orbit Plane components like K8Rngr can spin up ephemeral clusters for Tekton-based testing or handle multi-cluster Tekton pipeline expansions.

4.4 GitHub Actions

  • Overview: GitHub’s built-in CI/CD runner environment with a large marketplace for actions.

  • Integration with k8or Orbit:

    • The pipeline runs in GitHub’s environment, building containers and pushing them to CodeSource or DockerHub (C96).

    • On success, the pipeline can call Argo CD’s API or commit updates to a Git repo, triggering an Argo CD sync.

4.5 Argo CD (Continuous Delivery)

  • Overview: A GitOps tool that automatically reconciles cluster state with a Git repository.

  • Integration with k8or Orbit:

    • Argo CD typically runs in the Orbit Plane and monitors environment repos.

    • Once your CI tool publishes Helm charts or updated manifests, Argo CD notices and deploys them to the target K3s cluster(s).

5. Detailed Flow Example

Here is a typical end-to-end pipeline scenario using GitLab CI for build/test, DockerHub for images, ChartStore for chart data, and Argo CD for deployments:

  1. Code Commit

    • A developer pushes code to GitLab (C100).

    • PID: dev-local-c100-e05 (indicating the push event from local dev environment to GitLab).

  2. GitLab CI Pipeline

    • GitLab triggers a pipeline that:

      1. Builds the Docker image (tag = commit SHA).

      2. Runs unit/integration tests.

      3. Pushes the image to DockerHub (C96).

      4. Updates Helm chart references (or partial manifests) in a repo or in ChartStore (C20).

    • PID: c100-ci-c96-e10 for image push, c100-ci-c20-e15 for chart metadata.

  3. Argo CD Auto-Sync

    • Argo CD (C108) detects the updated chart repo or ChartStore entry.

    • PID: c108-sync-c20-e20 for Argo CD retrieving new chart version.

    • Argo CD deploys the new chart to the K3s cluster in the cluster plane.

  4. Validation & Monitoring

    • K8rix (C84) shows updated pods, while Prometheus & HelloScope confirm resource usage.

    • If errors are found, the pipeline or a canary check might roll back to the previous version.

6. Customizing Your CI/CD

  1. Multi-Stage Builds

    • For large microservices, you might use multi-stage Dockerfiles to reduce image size or embed scanning steps for security compliance.

  2. Advanced Testing

    • Integrate ephemeral test clusters. Tools like k3d or ephemeral K3s clusters can be spun up in pipeline stages to run integration tests.

  3. Security & Policy Checks

    • Insert security scanning (Aqua Trivy or Clair) in the pipeline.

    • Lint or policy checks on Helm charts or Kustomize overlays using open source tools like Helm Lint or Conftest.

  4. Deployment Strategies

    • With Argo CD, set up canary or blue-green deployments for critical changes.

    • K8Rngr can spin up separate staging or ephemeral clusters for pre-production validation.

7. Collaboration with k8or Orbit Contributors

When it comes to building or enhancing your CI/CD pipeline:

  1. Assessment & Architecture

    • Contributors can review your existing tools (e.g., Jenkins, GitLab CI) and design a pipeline architecture aligned with k8or Orbit’s recommended patterns.

  2. Implementation & Scripting

    • They can write or refine your pipeline scripts, including advanced steps like scanning, ephemeral cluster creation, and multi-cluster deployment logic.

  3. Integration with AccessPoint

    • If direct cluster commands are needed (e.g., dynamic “kubectl apply”), the pipeline must pass through AccessPoint. Contributors can configure tokens and RBAC safely.

  4. Best Practices

    • They offer guidance on versioning container images, naming conventions, using environment variables, and storing pipeline logs for audit.

8. Example Use Cases

  1. Enterprise Microservices

    • Microservices are built in parallel. Each triggers a pipeline that:

      1. Builds the service’s Docker image.

      2. Scans it for vulnerabilities.

      3. Updates the Helm chart in ChartStore.

      4. Argo CD auto-deploys or does canary deployment.

  2. Monorepo with Multiple Apps

    • A single GitLab or GitHub monorepo hosts multiple microservices.

    • The pipeline runs a matrix job building each sub-project, pushing images, and generating partial Helm overlays.

  3. Regulated Industry

    • Additional steps for compliance scanning, artifact signing, and mandatory review gates are inserted into the pipeline.

    • Argo CD merges changes only after an authorized sign-off.

PreviousContributorsNextCustomization via Bootstrap Scripts for Base K8s Cluster

Last updated