Pod name retains random segments from Deployments

[bendrucker]

We noticed that %{pod} is meant to be the "friendly" name of an app, stripping out the randomized parts added by different controllers. A pod created by a Deployment on Kubernetes@1.11 is named like this:

app-556455c97c-k8tdx

The plugin assumes the pod name has 2 random parts when the second to last part is a numeric string (is_number?(pod_parts[-2])). However, this has not been the case for several recent versions of Kubernetes.

ReplicaSets are named with a encoded version of the pod template hash, seemingly since k8s@1.8. Given our example above, there would be a ReplicaSet named app-556455c97c. Kubernetes is continuing to move forward in this direction and in a future release pod template hashes themselves will be encoded and no longer numeric.

We're still thinking about a better solution for stripping the dynamic parts with the metadata that the plugin receives but wanted to outline the problem in the mean time.

[rfein-hearst]

Just upgraded to 1.11 and also seeing this issue.

[frankreno]

@bendrucker yea this is a known issue we are aware and you are correct since about 1.8. The issue is determining the proper pod name from the data we get back from the plugin we use that hits the K8S API. Currently, the pod name as defined in the YAML is not made available in the API without this additional information we try to strip.

The current workaround is to use annotations to be able to explicitly set it, but this can be a pain as it's not global, you have to set it on all your k8s resource YAML files. There is a pending PR which I will merge soon that will enable you to use labels. This will offer some more capability here.

I spent quite a bit of time on this but failed to come up with a consistent way to strip of these bits. Any thoughts and ideas welcome. Will keep this open until I add a blurb to the README to explain this and possible workarounds.

[bendrucker]

Sergei and I worked together on #83 🙂

Kubernetes defines metadata.labels.pod-template-hash for pods so I think it would be ok to strip that out directly.

[nmohoric]

If anybody has a chance to take a look, #100 should address this issue.

[frankreno]

fixed in v2.1.0