I need to reveal some ignorance here, but hopefully it’ll be a net win in the end.
We use the term “pod spec” quite heavily. I don’t know all of the history, but I assume that’s because it relates to the “spec” key of resource configuration files.
Does this mean that Juju can only model pods? What about Deployments, ReplicaSets and Services?
Are there any “pod spec” keys that don’t emerge from Kubernetes? Will Juju always be perceived as lagging features? For a lack of a better term, could we forward port some features from Juju onto k8s by adding vendor extensions to the pod spec?
The naming is confusing and will be changed in the near future.
The YAML is used to by the charm to inform the Juju controller what needs to be created in the cluster. It’s explained here
What the charm can ask for is workload “units” to be spun up, plus some other opinionated, curated k8s specific resources.
