A Git repository is a versioned data store for files and their change history. In Kubernetes configuration practice, it becomes the authoritative home for deployment YAML, allowing configuration changes to follow the same review and approval process as code. section 11.2
A practical layout uses one repository for the objects deployed to a cluster, with a directory for each namespace. This creates a direct mapping: applying a directory deploys its environment, while copying the directory can create another environment. section 11.2
The folder structure makes the relationship between repository directories and Kubernetes namespaces explicit. section 11.2
Use the repository as the control point for deployment changes:
- Commit configuration changes instead of modifying the live cluster directly. section 11.3.1
- Trigger a deployment pipeline when the repository changes; the pipeline can run kubectl apply -f . against the cluster. section 11.3.1 section 11.3.2
- Use a GitOps operator such as Flux when continuous reconciliation is needed after configuration and cluster state diverge. section 11.3.2
Cloud Build deployment
A repository push can trigger Cloud Build, which runs kubectl apply with a configured folder against a named GKE cluster. The deployment file supplies the cluster, region, and apply arguments. section 11.3.2
