Skip to content
This repository has been archived by the owner on Oct 3, 2020. It is now read-only.

Question: alternative classification of pods #138

Open
recollir opened this issue Apr 6, 2020 · 1 comment
Open

Question: alternative classification of pods #138

recollir opened this issue Apr 6, 2020 · 1 comment

Comments

@recollir
Copy link

recollir commented Apr 6, 2020

Currently the pods are classified by "application" and "component". What would be required to instead go by "deployment" and "namespace"? Would this be a larger change?

Or would it "just" mean a change of get_application_from_labels and get component_from_labels into deployments and namespaces?

@hjacobs
Copy link
Owner

hjacobs commented Apr 29, 2020

I now added the option customize the Pod mapping (#160, released in v20.4.4), i.e. you can map anything into "application" or "component" via a custom Python hook function (--map-pod-hook=hooks.map_pod):

def map_pod(pod, mapped_pod: dict):
    # use the Pod's namespace as "application" (does not really make much sense...)
    mapped_pod["application"] = pod.namespace
    # use the controller name (e.g. ReplicaSet name) for "component"
    owner_names = []
    for ref in pod.metadata.get("ownerReferences", []):
        owner_names.append(ref["name"])
    mapped_pod["component"] = ",".join(sorted(owner_names))

You would need to add this function into a new file hooks.py and add the file to kube-resource-report (e.g. by creating a new Dockerfile or mounting the file as a volume).

See also https://github.com/hjacobs/kube-resource-report/blob/master/kube_resource_report/example_hooks.py

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants