Create images reference list after each CI deployment run

What does this MR do and why?

closes #2073 (closed)

Based on work done by @aseitz in MR !2506 (closed) and function wrote by @alain.thioliere, this new MR add a python script that should be executed after cluster deployment in order to produce a JSON file with a list of images used for that deployment.

Key Features:

• Image Tracking: Collects and lists all images utilized across pods.
• Dependency Mapping: Identifies and maps the dependencies of each pod, providing insights into the relationships between resources.
• Output Structure: The generated JSON file includes the following fields:

  • images: Images used in the deployment.

  • units_per_image: Mapping of units to their respective images.

  • images_per_unit: Mapping of images to their respective units.

  • image_with_unknown_unit: List of images without associated units.

  • pod_image_dependencies: Detailed dependencies for each image used in pods. Example:

    "pod_image_dependencies": {
        "quay.io/minio/operator:v5.0.15": {
        "Kustomization/sylva-system/minio-monitoring-tenant": {
            "HelmRelease/sylva-system/minio-monitoring-tenant": {
                "Pod/minio-monitoring-tenant/monitoring-pool-0-0": {
                    "containers": [
                        "sidecar",
                        "validate-arguments"
                    ]
                },
                "Pod/minio-monitoring-tenant/monitoring-pool-0-1": {
                    "containers": [
                        "sidecar",
                        "validate-arguments"
                    ]
                }
            }
        },
        ...
    }

Usage:

• The script should be executed post-cluster deployment to gather the image data.

• Example command:

  # Get image list for a management cluster:
  python get_image_refs.py --output image_refs.json --kubeconfig /path/to/kubeconfig
  # Generates a JSON report for workload clusters:
  python get_image_refs.py --output image_refs.json --kubeconfig /path/to/kubeconfig --workload-cluster-name <workload-cluster-name>

Note:

We had different approaches: listing images from pods, nodes, hosts container runtime (with crictl). It turns out that the "node" objects in the Kubernetes API contain 50 images by default (this can be modified in the kubelet config, but it might impact scheduling). Therefore, listing images from nodes is quite inefficient. Using crictl lists images that are present in the host's container runtime registry but may not be used in the deployment, leading to potential 'false positives'. We should not spend time managing these images, as they are not actively used. Ideally, these images should be removed from the OS images. The most effective solution to this day is, still, to retrieve the list of images directly from the pods.

A JSON report will be generated for each deployment. When a new release is tagged, the results from multiple reports will be aggregated (excluding the pod_image_dependencies section) to create a more exhaustive list of images across deployments.

The current implementation:

• does not account for mutable tags or image hashes. Enhancements to include these features may be considered in subsequent updates.
• does not retrieve images from crictl. The script includes a function that attempts to collect images from crictl, but it is poorly implemented. It could serve as a foundation if needed.
• we still miss images like: kindest/node (for example, this image is pulled by the boostrap machine and does not end up on the cluster) or even registry.gitlab.com/sylva-projects/sylva-elements/container-images/sylva-toolbox

Nevertheless, this addition aims to improve visibility into the images deployed in Sylva clusters and their interdependencies, facilitating better management and tracking of resources.

Related reference:

A script that aggregate mulitple "images refs" reports !3384 (merged)

Closes #1371 (closed)