8 GitOps: Configuration as Code
This chapter covers:
- Using namespaces and configuration to replicate environments
- Benefits of treating Kubernetes deployment configuration like source code
- Using git pull (merge) requests to drive operations
- Handling secrets without storing them in plain text in version control
You may have noticed in this book so far that we’ve been writing a lot of YAML configuration. It is possible to interact with most Kubernetes objects without writing configuration files (using imperative kubectl commands), and these are arguably easier to learn. So why did I exclusively use the declarative configuration-based approach? One reason is so that now as we take the app to production, we can treat our configuration like we do our code.
Another reason is it allows us to easily spin up multiple environments with the same configuration. Let’s say you want a staging and a production environment that are close to identical. With your deployment represented in configuration files it’s possible to replicate the environments easily. Kubernetes has a namespaces feature which makes this possible without needing to worry about name collisions.
8.1 Production and Staging Environments using Namespaces
As you prepare your application for production, you’ll likely want to create a staging environment where changes can be tested before the live production application is updated. Kubernetes makes this easy with namespaces.