How SREWorks Transforms Image Building with Cloud‑Native CI/CD and Kaniko

Background

In application operations, CI/CD has evolved into three core stages—Continuous Integration, Continuous Delivery, and Continuous Deployment—to support increasingly complex large‑scale systems. CI still represents developers' automated development, testing, and merging, while CD splits into delivery and deployment, offering more operational flexibility in cloud‑native environments.

The delivery stage can be divided into three factual standards: the On‑Machine stage, the On‑Container stage, and the current On‑CloudNative stage.

SREWorks implements a cloud‑native solution for image building during continuous delivery: when building an image, it launches a Pod on demand to execute the task.

1.1 Development Stages

On‑Machine : delivery consists of compiled language packages such as JAR files.

On‑Container : container images become the final delivery artifact, eliminating language‑specific runtime dependencies.

On‑CloudNative : builds on the container stage, adding operational features to support container orchestration and other cloud‑native scenarios.

1.2 Cloud‑Native Continuous Delivery

Cloud‑native architecture imposes standardized requirements on traditional CI/CD. The goal is elastic building from a shared resource pool—launching a build Pod on demand and releasing it after completion, avoiding a permanently allocated build machine.

SREWorks identified four key characteristics for cloud‑native continuous delivery:

Resource Elasticity : request CPU and other resources from the pool as needed, improving utilization.

Security : execute build tasks dynamically with clear ownership and permission isolation.

No‑Ops : eliminate the need to manage dedicated build machines; the underlying cluster handles management.

Fast Delivery : the cluster schedules build containers, automatically avoids faulty nodes, and responds quickly to build requests.

2 Architecture Evolution

2.1 Docker Build Mechanism

Docker consists of a Client, Host, and Registry. The client communicates with the host via a C/S architecture. The host processes client requests and manages backend modules, while the Registry stores images. The docker build command triggers the Docker daemon on the host, which may pull base images from a remote registry and store the built image locally.

The Docker daemon requires root privileges, preventing it from running natively inside another container and creating challenges for cloud‑native image building.

2.2 Initial State: Docker out of K8S

Initially, image builds were performed on a machine outside the Kubernetes cluster (an ECS instance) by connecting directly to a Docker daemon. This approach suffered from poor security and low efficiency due to resource contention.

2.3 Transition State: Docker out of Docker (DooD)

In the DooD model, each build Pod connects to the Docker daemon on the node to perform image builds, distributing tasks across nodes to avoid congestion. However, DooD incurs high implementation cost, security risks, and resource waste because each node must run a Docker daemon continuously.

2.4 Final State: Docker in Docker (DinD)

DinD runs the Docker daemon inside the build container itself, allowing on‑demand Pods to execute image builds and release resources after completion. This architecture provides:

Elastic builds managed by the cluster.

Secure, permission‑controlled build Pods.

Serverless execution without dedicated machines.

Rapid, scalable delivery.

3 Design and Implementation Based on Kaniko

Among container‑based image builders, Kaniko (an official Google open‑source solution) is the most popular and lightweight, executing Docker‑like build jobs without a privileged daemon. SREWorks adopted Kaniko for cloud‑native image building.

The AppManager service orchestrates build Pods via the Kubernetes API server. Key modules include:

Provider : handles client requests.

ComponentPackageTaskStateActionManager : monitors build task state changes and invokes appropriate handlers.

RunningState, FailureState, SuccessState : process tasks at different stages.

ComponentPackageBuilderService : performs the actual image build and Pod management.

The build workflow:

Decompose application components into container build tasks.

Start a build‑Pod informer.

Download source code and render Dockerfiles.

Generate and submit Pod YAML, then monitor Pod status.

When the Pod reaches a terminal state, generate the component package and clean up resources.

4 Design Reflections

Dynamic Dockerfile parameter rendering provides operational flexibility.

With CRI‑compatible runtimes, the DinD approach is more accurately described as DinC (Container‑in‑Container).

The elastic architecture applies even when delivery artifacts evolve beyond images.

Shared PVCs can deliver build tarballs, but lack of RWX support on some clusters disables this feature.

Build Pods remain preferred over Jobs due to lightweight nature and full control by AppManager.

5 Thoughts on Cloud‑Native Construction

Most modern cloud products are cloud‑native, embracing microservices, containers, continuous delivery, and DevOps. However, true cloud‑native practice must also achieve reusability, zero‑ops, and resource pooling. According to CNCF, cloud‑native technologies enable elastic, scalable applications across public, private, and hybrid clouds.

In the author's view, cloud‑native is a product‑capability‑driven best‑practice approach. Without a product focus, cloud‑native efforts lack meaning; with continuous iteration, they become the optimal path for building and operating applications.