Hey everyone! I started documenting my new Kubernetes cluster and noticed that the names of the .yaml files for existing services like kubernetes-dashboard and ArgoCD are all over the place. I'm curious how others approach naming their YAML files, resources, and namespaces.
Here are my thoughts so far on file naming:
- RoleBinding: role-binding-.yaml
- ClusterRole: cluster-role-.yaml
- ServiceAccount: sa-.yaml
- Deployment: deploy-.yaml
For namespaces, I'm thinking of using:
- --
I'm also considering organizing the YAML files into folders in the git repository, like this:
- main-folder/application-name/deployments/.yaml
- main-folder/application-name/rbac/role-bindings/-.yaml
- main-folder/application-name/rbac/cluster-role/.yaml
I'm feeling a bit lost with this, so any tips or insights would be greatly appreciated! Am I overcomplicating things, or is there a better way to go about it?
5 Answers
I believe namespaces should be separate from the service definitions, so I don't include them in the filenames. This allows me to deploy testing copies of services to different namespaces when needed.
Honestly, it doesn't matter that much. For my small lab environment, I organize things by namespace. I'll put namespace-wide YAMLs in their own directory and application YAMLs in the respective application directory. You could even just dump everything in a single directory and be fine, depending on your setup.
We do it a bit differently—our format is -.yaml. It puts everything related to the same application close together in the filesystem, which I find helpful.
For naming conventions, I stick with using a structure like ..yaml. Everything is organized in a folder system sorted by clusters, environments, and applications. Although it’s not strictly DRY, this makes navigation much easier and allows for clear scaling due to the organized conventions.
Nice tidy setup! What's typically in each layer of your structure? How do you classify things like External Secrets or Prometheus?
I love that! Learning k8s with flux must be such an advantage!
I use this structure: ///manifests/-.yaml. This way, everything is neatly categorized by where it applies.
That’s a good point, but watch out for helm-releases that might delete the targetNamespace along with everything inside that isn’t part of the helm chart.