Support fetching resources from Kubernetes

[tazjin]

Adds support for a getResource(namespace, kind, name) template function which can insert the last applied configuration of a resource in a template.

This is useful for doing things like this:

---
kind: ConfigMap
metadata:
  name: some-config
# <snip! Imagine some data here.>
---
kind: Deployment
# <stuff>
template:
  metadata:
    annotations:
      some-config-hash: '{{ getResource "default" "configmap" "some-config" | sha256sum }}'

which will cause rolling updates based on the current configmap configuration.

Another useful effect of this is that this can be used even if the dependent resource is not managed by Kubernetes, for example a certificate Secret created by kubernetes-letsencrypt.

[tazjin]

Consideration before merging: getResource is kind of non-descriptive. What this does specifically is use kubectl apply get-last-applied to fetch the last applied configuration of a resource.

This is also only supported in kubectl > 1.6.

I'm wondering if it makes sense to use kubectl get $kind $name -o yaml --export instead, but I have no clue if the key ordering of that is stable (it'd have to be in order to use these for hashes).

Maybe the function should also be called getKubernetesResource or something similar.

[tazjin]

This implements #45, by the way.

[tazjin]

FYI this is waiting on me figuring out which kubectl outputs can actually be considered stable.

Most things seem to go through a Go map at some point, which means the key order may change arbitrarily.

[FaKod]

That's not merged, right? Are there plans to do so?

[tazjin]

@FaKod I haven't looked at this in a long time. Back when I originally wrote it I abandoned it because the output of kubectl was unstable, maybe that has changed now?

If not kontemplate would need some implementation of a normalised form for all the possible resources. Maybe such a thing exists in the k8s codebase itself but I haven't gone looking.

[FaKod]

@tazjin What do you mean with normalized?

My use case f.e. is, that I have to retrieve API servers root CA. I solved it with {env "CA_BUNDLE"}} and:

$ CA_BUNDLE=$(kubectl get cm -n kube-system extension-apiserver-authentication -o=jsonpath='{.data.client-ca-file}' | base64 | tr -d '\n') \
kontemplate apply s4.yaml

So in my case a getResource(namespace, kind, name, jsonpath) is sufficient, because

• I do not know why the whole resource object should be used
• a mandatory jsonpath returns a simple string (like the api server authentication)

What do you (or others) think?

[tazjin]

@FaKod Ah interesting, that's a use-case I hadn't actually considered. The original idea here was to be able to eventually get a stable hash of a resource in-cluster so that, for example, pods could contain a hash of configmaps or whatever to trigger updates.

This JSON-path based implementation could be useful for other cases!