A deployment descriptor is a configuration file that tells an execution environment which workload to run and how to run it. For a Kubernetes deployment, it can identify the container image, replica count, rolling-update behavior, resource requests and limits, environment variables, ports, and image-pull secrets. A descriptor becomes a deployable artifact when its image reference is filled with the version produced by CI. section 8.5.7
Prepare descriptors alongside container images so a release is traceable: the descriptor should reference the exact image tags published for that release. Keep a template in the repository, replace version tokens after images are built and scanned, then attach the completed YAML files to the release. The deployment workflow retrieves those files rather than reconstructing them or downloading images; Kubernetes pulls the referenced images from the registry. section 8.5.7 section 9.1.3
A Kubernetes deployment descriptor can specify:
- Workload identity and targeting: API version, Deployment kind, name, namespace, and labels. section 8.5.7
- Availability behavior: replica count plus a RollingUpdate strategy with maxSurge and maxUnavailable settings. section 8.5.7
- Container execution: registry image and tag, CPU and memory requests and limits, environment variables, exposed ports, image-pull policy, and pull secret. section 8.5.7
- Release linkage: replacement markers whose values come from the image versions generated during the pipeline. section 8.5.8
Versioned frontend deployment
A frontend Deployment template uses ghcr.io/vriesmarcel/frontend:#{Build.version}# as its image. A replacement step supplies FRONTED_VERSION as Build.version, producing a descriptor tied to the built image. The same template requests 500Mi memory and 250m CPU, limits memory to 1Gi and CPU to 750m, deploys three replicas through a rolling update, and uses a pullsecret for registry access. section 8.5.7 section 8.5.8
Treat the release as the handoff containing deployment deliverables. A release workflow can trigger when a tagged container package is published, retrieve image versions, patch descriptors for multiple services, and attach the resulting files. Restrict who can review and accept this release path, and use an appropriate secret-backed token when publication must trigger a downstream deployment workflow. Other deployment files, including an SBOM, can also be attached. section 8.5.8 section 8.8
Listing 8.15 Kubernetes template deployment file
apiVersion: apps/v1
# Kubernetes deployment specification. We want to deploy our
# container frontend to the cluster, in the namespace globoticket.
kind: Deployment
metadata:
name: frontend
namespace: globoticket
labels:
app: frontend
# We want to deploy 3 replicas of the frontend and deploy
# them with a rolling update strategy
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 2
maxUnavailable: 0
selector:
matchLabels:
app: frontend
template:
metadata:
labels:
app: frontend
Inspect the Deployment template’s metadata, replica and rolling-update settings before its container details and version token are completed. section 8.5.7
