Use a pod template file in a Deployment

Question

I've been looking at Deployments descriptions in Kubernetes. In the tutorials I've found, the definition of the replicated pods are always a copy-paste of a pod template file.

Is it possible to rather use a reference to the yaml file (or an url) defining a pod (I didn't found any resource telling so)?

If yes, should it be avoided (in order to keep label/selector in the same file for example)?

If no, is there a reason (because Kubernetes wouldn't know if you modified the pod template file for example)?

Answer 1

the definition of the replicated pods are always a copy-paste of a pod template file

This behavior is implemented by Kubernetes itself: it takes the template part of the deployment spec and creates replicas identical pods.

The corollary to this is that you don't need to manually write out the pod spec as a separate object. Including it in the template part of a deployment (job, statefulset, daemonset) is enough.

Is it possible to rather use a reference to the yaml file (or an url) defining a pod

No, individual Kubernetes objects must be self-contained (except where there are facilities to do things like inject Secret values into environment variables). The Kubernetes server doesn't know about your local file system.

Using one of the templating systems out there (Helm is more-or-less standard but not the only choice) could help reduce this duplication, if you really need near-identical deployments and also bare pods. You could write something like

---
apiVersion: v1
kind: Pod
{{ template "pod-spec" . }}
---
apiVersion: apps/v1
kind: Deployment
spec:
  template:
{{ include "pod-spec" . | trim | indent 4 }}

Answer 2

Yes you can create resources (including pods) from a url yaml using kubectl. However, just because you pointed to a remote url does not mean that the resource will automatically update. You will need to either re-deploy when the remote yaml is updated, develop/integrate with a service that handles this, or look into using a tool such as helm to help manage changes.

It does not need to be avoided, you just need to know that it will not automatically update if the source changes.