AABDULRAHMAN.DEV
Cloud engineering portfolio
Home / Projects / Application delivery
Project 02 / Application delivery

Kubernetes CI/CD platform

A Dockerized Python web API with health endpoints, Kubernetes manifests generated by Helm, and an automated GitHub Actions quality pipeline.

DockerKubernetesHelmGitHub ActionsPythonFlask
Automatic CI checks, a separate manual release, and Service traffic to two Kubernetes API pods.
CI CHECKS · MANUAL RELEASE · TWO API REPLICASOpen full diagram ↗

The challenge

Reliable releases depend on more than containerizing an application. Teams also need repeatable quality checks, predictable deployment configuration, and a way to distinguish a container that is running from one that is ready to receive traffic.

This project packages a small Flask API, defines health endpoints, and captures the delivery workflow in GitHub Actions and Helm.

The architecture

Each source push or pull request starts an automated workflow that installs application dependencies, runs Python unit tests, builds a Docker image, validates the Helm chart, and renders Kubernetes YAML. A separate manual release workflow can publish the image to GHCR and use Helm to deploy it to a configured cluster.

The chart defines a two-replica Deployment and a private ClusterIP Service. Kubernetes readiness and liveness probes call separate endpoints on the API. Helm supplies versioned release configuration.

Engineering decisions

  • Principle of least privilege: containers run as non-root, drop Linux capabilities and do not mount a service-account token.
  • Traffic-aware rollouts: readiness probes help keep not-ready containers out of Service endpoints.
  • Small resource footprint: memory and CPU requests and limits are declared explicitly.
  • Portable design: local kind deployments use the same Helm chart as a cluster connected to a registry.
Inside the implementation

How the pieces fit together.

01

Package the API

Build the Flask web service in a small Python base image and expose port 8080.

02

Validate changes

Use GitHub Actions for unit tests, Docker builds, Helm checks and an optional manual GHCR-to-cluster release.

03

Describe the rollout

Helm defines replica count, resource limits, readiness and liveness probes.

Repository walkthrough

Architecture, expressed in code.

Rather than storing separate YAML copies for each environment, a Helm chart provides reusable templates. Container hardening and probes are defined as part of the Deployment.

charts/cloud-web-api/templates/deployment.yaml · probes
readinessProbe:
  httpGet:
    path: /readyz
    port: http
livenessProbe:
  httpGet:
    path: /healthz
    port: http
securityContext:
  allowPrivilegeEscalation: false
  readOnlyRootFilesystem: true

Browse app/ for the API, Dockerfile for the image, charts/cloud-web-api/ for Kubernetes templates, and .github/workflows/ for CI and the manually initiated release workflow.

Next project: Cloud monitoring & automation ↗