I see two "styles" of Kubernetes manifest files.
First one is one Kubernetes manifest, one and only file, where the deployment, service, config map, etc..., and everything else is present in one same file, one after another.
The second one is where the resources has dedicated files. The deployment has a deployment.yml, the service has a service.yml, etc...
While Kubernetes supports both, may I ask what are the pros and cons of each. Also what situation the first option is preferred, what version the second option is preferred?
This question is not to create a debate solutionA versus/against solutionB. It is a question to state what are the pros and cons of each, what situation is the most suited, more a technical discussion.
Thank you.
In general, it's a best practice to group resource objects belonging to the same application/deployment in a single file (rather than having each object in a separate file).
From the Configuration Best Practices page of the Kubernetes docs:
Group related objects into a single file whenever it makes sense. One file is often easier to manage than several. See the guestbook-all-in-one.yaml file as an example of this syntax.
And from the Managing Resources page:
It is a recommended practice to put resources related to the same microservice or application tier into the same file, and to group all of the files associated with your application in the same directory.
The main advantage of this approach is as suggested in the above quotes: it's easier to manage a single file rather than many files, especially if these files are related and, for example, include identifiers that are shared across multiple resource objects.
Also it makes it clear at a single glance what components an application/deployment consists of, and which Kubernetes API objects belong together.