When using drone-runner-kube, spawned worker pods have names like drone-92vh1e9hkicqtq8odvi3, and the containers inside them have similarly cryptic names (e.g. drone-kkj76c2asbkhyeg7jw2m).
These names are not especially helpful when trying to reverse associate a worker pod/container with a particular pipeline or stage, for example when debugging or tweaking resource consumption settings.
It's additionally difficult when monitoring the cluster with a tool like Prometheus, as there's no insight into which pipelines are behaving in certain ways. Although it is possible to see overall trends across all pipelines.
Some possible strategies to improve on this behavior:
Updating the naming scheme
Naming the pods after the spawning repository and/or pipeline, perhaps with a unique hashed identifier appended to provide uniqueness
Naming containers after the stage they correspond to
Expose for configuration the manner in which pods/containers are named, allowing users to modify this behavior
When using
drone-runner-kube, spawned worker pods have names likedrone-92vh1e9hkicqtq8odvi3, and the containers inside them have similarly cryptic names (e.g.drone-kkj76c2asbkhyeg7jw2m).These names are not especially helpful when trying to reverse associate a worker pod/container with a particular pipeline or stage, for example when debugging or tweaking resource consumption settings.
It's additionally difficult when monitoring the cluster with a tool like Prometheus, as there's no insight into which pipelines are behaving in certain ways. Although it is possible to see overall trends across all pipelines.
Some possible strategies to improve on this behavior: