Navigating Kubernetes Deployments: A Guide to Fetching and Managing Images in Your Deployment

July 09, 2026 — LiveStream

Mastering container image management is crucial for robust Kubernetes deployments, and this guide walks you through essential techniques using Helm and kubectl to efficiently fetch and audit images across your cluster, ensuring visibility and control.

Chai pe charcha, my friend! You know, in the fast-paced world of Kubernetes deployments, merely getting your applications up and running isn't enough. As a DevOps engineer, you need to be in the know about every component, especially the container images powering your pods. Imagine trying to debug an issue, audit for security vulnerabilities, or plan an upgrade without knowing exactly which images are deployed where. Mushkil ho jayega, right?

This isn't just about curiosity; it's about control, security, and efficiency. Today, we're going to dive deep into some practical, battle-tested methods to fetch a comprehensive list of images from your Kubernetes platform. We'll explore various scenarios, from inspecting Helm charts before deployment to auditing live running pods. So, grab your cup, let's break down how to get a complete inventory of your Kubernetes image list using powerful tools like Helm and kubectl. This knowledge is fundamental for any serious container image management in Kubernetes strategy.

The Imperative of Image Visibility in Kubernetes Deployments

Dekho, boss, managing container images in a Kubernetes environment is more than just deploying them. It's about knowing precisely what's running, what could run, and what security posture those images represent. Why is this image visibility so important?

• Security Audits & Compliance: In regulated industries, knowing every image and its version is non-negotiable. You need to ensure no outdated or vulnerable images are lurking in your cluster. This helps with regular security scans and proving compliance during audits.
• Debugging & Troubleshooting: Ever had a mysterious bug that only appears in production? Often, it boils down to an unexpected image version. Quickly fetching the actual image name and tag helps pinpoint discrepancies between environments.
• Resource Planning & Optimization: Understanding the images in use helps you manage your image registries, plan for storage, and even optimize pull times if you're pulling large images from distant repositories.
• Dependency Management: Applications rarely run in isolation. They depend on various services, each with its own image. A clear picture of all images helps manage these interdependencies, especially during upgrades.
• Cost Management: While often overlooked, older, unused images in your registry can add to storage costs. Knowing what’s actively used helps you clean up effectively.
• Supply Chain Security: With increasing focus on software supply chain attacks, knowing the origin and integrity of every image is paramount.

Without these insights, you're essentially flying blind. So, let's arm ourselves with the right tools and techniques to shine a light on every nook and cranny of your Kubernetes deployments' image landscape.

Setting Up Your DevOps Toolkit: Prerequisites for Image Discovery

Before we roll up our sleeves and start typing commands, let's ensure our workbench is ready. For these operations, we'll primarily rely on two indispensable tools in the Kubernetes ecosystem: Helm and kubectl. Make sure you have them installed and configured correctly.

Helm: The Kubernetes Package Manager

Helm is often referred to as the "package manager for Kubernetes." It allows you to define, install, and upgrade even the most complex Kubernetes applications using charts. A Helm chart is a collection of files that describe a related set of Kubernetes resources. Think of it like a template for your applications.

• Why Helm? It simplifies deployments, manages application lifecycle, and makes configuration reproducible. For our purpose, it gives us a powerful way to inspect applications *before* they are deployed, showing us exactly which images they intend to use.
• Installation (Linux/macOS):

  curl https://raw.githubusercontent.com/helm/helm/master/scripts/get-helm-3 | bash

  Or using Homebrew on macOS:

  brew install helm

• Verification:

  helm version

kubectl: The Kubernetes Command-Line Tool

kubectl is the command-line tool for running commands against Kubernetes clusters. You use kubectl to deploy applications, inspect and manage cluster resources, and view logs. It's your primary interface to interact with your cluster, live and in action.

• Why kubectl? It's the direct way to communicate with the Kubernetes API server. We'll use it to query the current state of our cluster, including the images used by running pods.
• Installation (Linux/macOS): Follow the official Kubernetes documentation for the most up-to-date instructions. For many, it's as simple as:

  curl -LO "https://dl.k8s.io/release/$(curl -L -s https://dl.k8s.io/release/stable.txt)/bin/linux/amd64/kubectl"
  sudo install -o root -g root -m 0755 kubectl /usr/local/bin/kubectl

  Or using Homebrew on macOS:

  brew install kubectl

• Verification:

  kubectl version --client

• Configuration: Ensure your kubectl is configured to connect to your desired Kubernetes cluster. You can check your current context with:

  kubectl config current-context

With these two tools in your arsenal, you're all set to begin our image discovery journey. Chalo, aage badhte hain!

Unearthing Images: Practical Techniques for Your Kubernetes Cluster

Now, let's get to the core of it – how do we actually find those elusive container images? We'll cover three distinct but equally important methods, each serving a different purpose and giving you a different perspective on your Kubernetes deployments.

Method 1: Peeking into Helm Charts (Before Deployment)

This technique is fantastic for understanding what images a Helm chart *intends* to deploy. It's a "dry run" approach that allows you to inspect the rendered Kubernetes manifests without actually deploying anything to your cluster. This is extremely useful for pre-deployment audits, security checks, and understanding chart dependencies. The primary tool here is helm template.

The command looks a bit like this:

helm template --version YOUR_CHART_VERSION YOUR_CHART_NAME | grep "image: " | awk '{print $2}' | sort -u

Let's break down this powerful one-liner:

• helm template --version YOUR_CHART_VERSION YOUR_CHART_NAME:
  • helm template: This command renders the templates defined in a Helm chart locally, without installing anything onto the cluster. It essentially shows you the final Kubernetes YAML manifests that would be generated.
  • --version YOUR_CHART_VERSION: Specifies the exact version of the Helm chart you want to inspect. This is crucial for reproducibility and ensuring you're looking at the right configuration.
  • YOUR_CHART_NAME: This is the name of the chart you're interested in (e.g., astronomer/astronomer, stable/nginx-ingress). You might need to add the repository name if it's not a standard one.

  The output of this part is a verbose stream of Kubernetes YAML resources.

• | grep "image: ":
  • This pipes the output of helm template to grep.
  • grep "image: ": Filters this output, looking for lines that contain the string "image: ". This pattern typically appears in Deployment, StatefulSet, or Pod manifests to define the container image. We use "image: " (with space) to avoid partial matches.

  This significantly narrows down the output to just the lines mentioning image definitions.

• | awk '{print $2}':
  • This pipes the filtered lines from grep to awk.
  • awk '{print $2}': awk is a powerful text processing tool. Here, we're telling it to print the second field ($2) of each line, using space as the default delimiter. Since lines typically look like image: some/image:tag, the second field will be the image name and tag.

  Now we have a raw list of image names, potentially with duplicates.

• | sort -u:
  • Finally, we pipe the image list to sort.
  • sort -u: Sorts the list alphabetically and, crucially, removes any duplicate entries (-u stands for unique). This gives us a clean, distinct list of all images referenced by the chart.

Example Output Interpretation:

helm template --version 0.31.2 astronomer/astronomer | grep "image: " | awk '{print $2}' | sort -u

quay.io/astronomer/ap-alertmanager:0.25.0
quay.io/astronomer/ap-astro-ui:0.31.12
quay.io/astronomer/ap-base:3.16.3
...
quay.io/astronomer/ap-prometheus:2.37.5

This output clearly lists every unique image that version 0.31.2 of the astronomer/astronomer Helm chart would deploy, along with its specific tag. Notice the full registry path (quay.io/astronomer/), which is essential for accurate identification.

Method 2: Inspecting Live Pods (In a Running Cluster)

Sometimes, you need to know what's *actually* running in your cluster right now. Maybe a deployment failed, or you suspect someone manually tweaked an image tag. This method uses kubectl to query your live cluster and pull image information directly from running pods. This is invaluable for debugging, post-deployment verification, and real-time auditing.

The command looks like this:

kubectl get pods -n YOUR_NAMESPACE -o jsonpath="{..image}" | tr -s '[[:space:]]' '\n' | sort -u

Let's dissect this one:

• kubectl get pods -n YOUR_NAMESPACE:
  • kubectl get pods: Retrieves information about all pods in the current context.
  • -n YOUR_NAMESPACE: Specifies the namespace to query. Replace YOUR_NAMESPACE with the actual namespace (e.g., default, kube-system, astronomer). If omitted, it defaults to the current namespace.

  This part fetches all pod objects.

• -o jsonpath="{..image}":
  • -o jsonpath: This is where the magic happens. It tells kubectl to output the data in JSON format and then apply a JSONPath expression to extract specific fields.
  • "{..image}": This is a powerful JSONPath expression.
    • ..: The recursive descent operator. It searches for the specified field at all levels of the JSON hierarchy.
    • image: We're looking for any field named "image" within the pod's JSON definition. Pods' container specifications include an image field.

  This extracts all image values from all containers across all selected pods, outputting them as a space-separated string.

• | tr -s '[[:space:]]' '\n':
  • tr: The translate utility.
  • -s '[[:space:]]' '\n': This compact expression replaces sequences of whitespace ([[:space:]], like spaces, tabs, newlines) with a single newline character (\n). This effectively puts each image name on its own line, which is much easier to process.
• | sort -u:
  • Just like before, this sorts the list alphabetically and removes any duplicate entries, giving you a clean, unique list of images currently running in your cluster.

Example Output Interpretation:

kubectl get pods -n astronomer -o jsonpath="{..image}" | tr -s '[[:space:]]' '\n' | sort -u

docker.io/library/postgres:latest
postgres:latest
quay.io/astronomer/ap-alertmanager:0.26.0
quay.io/astronomer/ap-astro-ui:0.33.9
...
quay.io/astronomer/ap-curator:8.0

This output shows the images currently running in the astronomer namespace. You might notice differences from the helm template output – these are the *actual* images being used. Sometimes, latest tags might get pulled, or an image might be from a different registry if configurations were overridden. This command reveals the ground truth.

Method 3: Diving into Local Helm Chart Files (Offline Analysis)

What if you have the Helm chart source code locally, or you're working in an environment where direct internet access or cluster access is restricted? You can still discover images by inspecting the chart's files directly. This method is particularly useful for custom charts, air-gapped environments, or when you need a deep dive into the chart's internal structure.

Here’s the workflow:

1. Download the Helm chart (if not local):

   If the chart isn't already on your local machine, you'll need to download it. You can often find chart URLs on public repositories or get them from your internal sources.

   wget YOUR_HELM_CHART_URL

   For example, if it's a tarball from a Helm repository:

   helm pull YOUR_CHART_NAME --version YOUR_CHART_VERSION

   This will download the chart as a .tgz file.

2. Extract the Helm chart:

   Once you have the .tgz file, extract its contents:

   tar -zxvf YOUR_HELM_CHART_NAME.tgz

   This will create a directory containing the chart's structure (Chart.yaml, values.yaml, templates/, etc.).

3. Inspect values.yaml and other files:

   Helm charts typically define image repositories and tags in their values.yaml file (or other values*.yaml files if they use dependencies or overrides). We can use find and grep to locate these:

   find /path/to/your/chart -maxdepth 3 -type f -name 'values*' -exec grep -A1 'repository:' {} \; | awk '/repository:/ {printf "%s:", $2} /tag:/ {print $2}'

   Let's break down this command:

   • find /path/to/your/chart -maxdepth 3 -type f -name 'values*':
     • find /path/to/your/chart: Starts searching from the root directory of your extracted chart.
     • -maxdepth 3: Limits the search depth to 3 levels, preventing it from going too deep into subdirectories (charts usually define images at shallower levels).
     • -type f: Only looks for files.
     • -name 'values*': Targets files whose names start with "values" (e.g., values.yaml, values-production.yaml, etc.).
   • -exec grep -A1 'repository:' {} \;:
     • -exec ... {} \;: Executes a command on each found file.
     • grep -A1 'repository:' {}: Searches inside each file ({} placeholder) for lines containing "repository:". The -A1 flag tells grep to also print one line after the match. This is crucial because image tags are often defined on the line immediately following the repository.
   • | awk '/repository:/ {printf "%s:", $2} /tag:/ {print $2}':
     • This awk command processes the output of grep.
     • /repository:/ {printf "%s:", $2}: When awk encounters a line containing "repository:", it prints the second field (the repository URL) followed by a colon, but without a newline.
     • /tag:/ {print $2}: When awk encounters a line containing "tag:", it prints the second field (the image tag) and then a newline.
     • The combination stitches the repository and tag together on the same line.

This method gives you a highly detailed, offline view of the images as defined in the chart's source files. It’s perfect for ensuring that your locally managed charts adhere to your organization's image policies.

Navigating Version Compatibility and Advanced Helm Tricks

Now that you know the different ways to fetch images, let's talk about some real-world complexities, like Kubernetes version compatibility and getting more debugging insight from Helm.

Handling Incompatible Kubernetes Versions with Helm

Sometimes, you might encounter a situation where a Helm chart is designed for a specific Kubernetes version, and your cluster is running an older or newer one. Helm is smart enough to detect these incompatibilities and might refuse to render the chart. While it's always best practice to use charts compatible with your cluster, there are times (especially in development or testing) when you might need to force the issue.

Helm provides a way to override these checks using the forceIncompatibleKubernetes flag:

helm template --version YOUR_CHART_VERSION YOUR_CHART_NAME --set forceIncompatibleKubernetes=true --debug | grep "image: " | awk '{print $2}' | sort -u

A word of caution (thoda dhyaan se): Using --set forceIncompatibleKubernetes=true should be approached with extreme caution. This flag tells Helm to ignore Kubernetes version compatibility checks. While it might allow the template to render, there's no guarantee that the resulting manifests will actually work or behave as expected on your cluster. You might face runtime errors, missing features, or unexpected behaviors due to API version differences or removed functionalities. Always test thoroughly if you use this flag in a non-development environment.

The --debug flag is also very useful here. It provides verbose output during the templating process, including details about chart paths, values being used, and any warnings or errors that Helm encounters. This extra information can be invaluable for diagnosing why a chart might be failing or behaving unexpectedly.

Best Practice: Align Your Versions
The ideal scenario is to always ensure your Kubernetes version aligns with the supported versions of your applications and their Helm charts. Regularly updating both your cluster and applications is key to maintaining stability, security, and access to the latest features. Consider a proper versioning strategy for your Helm charts and Kubernetes clusters, perhaps using tools like Kubernetes version managers or automated testing pipelines to validate compatibility.

Decoding Helm Template Output: A Real-World Scenario

Let's look at the example outputs provided earlier and understand the differences when we change the chart version:

Scenario 1: Helm Chart Version 0.31.2

helm template --version 0.31.2 astronomer/astronomer | grep "image: " | awk '{print $2}' | sort -u

quay.io/astronomer/ap-alertmanager:0.25.0
quay.io/astronomer/ap-astro-ui:0.31.12
quay.io/astronomer/ap-base:3.16.3
...
quay.io/astronomer/ap-prometheus:2.37.5

Here, we see a specific set of images and their tags corresponding to version 0.31.2 of the Astronomer chart. Each component (alertmanager, astro-ui, base, etc.) has a precise image and tag. This is the blueprint for this particular application release.

Scenario 2: Helm Chart Version 0.33.1 with Debug Mode

helm template --version 0.33.1 astronomer/astronomer --debug | grep "image: " | awk '{print $2}' | sort -u

install.go:178: [debug] Original chart version: "0.33.1"
install.go:195: [debug] CHART PATH: /root/.cache/helm/repository/astronomer-0.33.1.tgz
quay.io/astronomer/ap-alertmanager:0.26.0
quay.io/astronomer/ap-astro-ui:0.33.5
quay.io/astronomer/ap-base:3.18.4
...
quay.io/astronomer/ap-prometheus:2.45.1

Notice a few things here:

• Debug Output: The --debug flag introduces lines like install.go:178: [debug] Original chart version: "0.33.1" and CHART PATH: /root/.cache/helm/repository/astronomer-0.33.1.tgz. This tells us which chart version Helm is actually processing and where it cached the chart locally. This can be super helpful for troubleshooting, samajh rahe ho?
• Image Version Bumps: Comparing the two outputs, you'll observe that many images have been updated to newer versions. For example, ap-alertmanager went from 0.25.0 to 0.26.0, and ap-prometheus from 2.37.5 to 2.45.1. This clearly indicates that the Helm chart update between 0.31.2 and 0.33.1 includes significant component updates.
• New Components: In the 0.33.1 output, we see quay.io/astronomer/ap-blackbox-exporter:0.24.0-1 which wasn't present in the 0.31.2 list. This signifies that the newer chart version might have introduced new services or components to the application stack.

This comparison is a perfect example of why having these image discovery techniques is crucial. It lets you understand the impact of upgrading a Helm chart *before* you apply it, preventing potential headaches down the line.

Beyond Discovery: Best Practices for Kubernetes Image Management

Fetching image lists is just the first step. True container image management in Kubernetes extends to broader strategies. Here are some best practices that every DevOps engineer should adopt:

Image Pull Policies

Kubernetes provides imagePullPolicy for containers, which dictates when the Kubelet should attempt to pull an image. Understanding these is vital:

• Always: The Kubelet pulls the image every time the pod starts. Useful for development or when you frequently update images with the same tag (like latest), but can cause delays.
• IfNotPresent (Default): The Kubelet pulls the image only if it is not already present on the node. This saves network bandwidth and speeds up pod startups. Ideal for stable images with immutable tags.
• Never: The Kubelet expects the image to be present on the node and never tries to pull it. Useful for air-gapped environments or pre-loaded images.

Always consider which policy makes sense for your specific deployment and environment.

Image Registries: Public vs. Private

Where do your images live?

• Public Registries (e.g., Docker Hub): Convenient but requires vetting images for security. Ensure you're pulling from trusted sources. Rate limits can also be an issue.
• Private Registries (e.g., Google Container Registry, AWS ECR, Azure Container Registry, Quay.io): Essential for proprietary images and stricter security controls. You'll need to configure image pull secrets in Kubernetes for authentication.

For most enterprise-grade Kubernetes deployments, using a private, secure image registry is a non-negotiable best practice.

Security Scanning

Integrate image vulnerability scanning into your CI/CD pipeline. Tools like Clair, Trivy, Snyk, or built-in registry scanners (e.g., GCR's Vulnerability Scanning) can identify known vulnerabilities in your images before they even reach your cluster. Don't let vulnerable images be deployed!

Automated Updates and Versioning

Manually tracking and updating image versions across many deployments is tedious and error-prone. Consider:

• Semantic Versioning: Use clear MAJOR.MINOR.PATCH tags instead of latest for production images. This ensures reproducible deployments.
• Immutable Tags (Digests): For ultimate immutability and reproducibility, reference images by their digest (e.g., myimage@sha256:abcdef...). This guarantees you're always pulling the exact same image content.
• Dependency Update Tools: Tools like Renovate or Dependabot can automatically scan your repositories for outdated dependencies (including Docker images in Helm charts or deployment YAMLs) and create pull requests to update them.

Troubleshooting Common Image-Related Issues

Despite all best practices, issues can still pop up. Here are some common image-related problems you might encounter in Kubernetes and how to start troubleshooting:

• ImagePullBackOff: This usually means the Kubelet tried to pull an image but failed and is retrying.
  • Check image name/tag: Is it spelled correctly? Does the tag exist in the registry?
  • Check registry accessibility: Can the Kubernetes node reach the image registry?
  • Check ImagePullSecrets: If using a private registry, are the secrets correctly configured and linked to the pod?
  • Docker daemon issues: On the node, check sudo systemctl status docker or sudo journalctl -u docker.
  • Network issues: Firewalls, proxy configurations.

  Use kubectl describe pod <pod-name> -n <namespace> to get detailed events.

• ErrImagePull: Similar to ImagePullBackOff, but indicates an error during the pull process itself. The same troubleshooting steps apply.
• Incorrect Image Tags: The pod is pulling an unexpected version of an image. This can happen if you use latest and the image in the registry gets updated, or if an imagePullPolicy allows an older image to persist on a node. Always use specific, immutable tags for production.
• Registry Authentication Failures: Your pod's ImagePullSecrets are incorrect, expired, or not correctly associated with the service account used by the pod. Ensure the secret exists, is of type kubernetes.io/dockerconfigjson, and is referenced in your deployment's pod spec.

Debugging Kubernetes can sometimes feel like finding a needle in a haystack, but with the right commands and a systematic approach, you'll get to the bottom of it. Our image fetching commands are your first line of defense in such scenarios.

Key Takeaways

• Image visibility is paramount for security, compliance, debugging, and efficient management of Kubernetes deployments.
• helm template allows you to inspect images that a Helm chart would deploy, great for pre-deployment audits.
• kubectl get pods -o jsonpath="{..image}" provides a live view of images currently running in your cluster.
• Local chart inspection through find and grep is valuable for offline analysis and custom charts.
• Always prioritize version compatibility between Helm charts and your Kubernetes cluster, using --set forceIncompatibleKubernetes=true only with extreme caution.
• Implement best practices like clear image pull policies, private registries, security scanning, and automated versioning for robust image management.

Frequently Asked Questions

Why can't I just list images from docker images on a Kubernetes node?

While docker images (or `crictl images` for containerd) on a node will show images locally cached, it doesn't give you a comprehensive, cluster-wide view of what's deployed, what *should* be deployed, or which pods are using which images. Kubernetes might schedule pods on different nodes, and an image present on one node might not be on another. The methods discussed here query the Kubernetes API or Helm charts, providing a logical, desired-state, or cluster-wide running-state view, which is far more useful for managing Kubernetes deployments.

What's the difference between fetching images from Helm charts vs. running pods?

Fetching from Helm charts (using helm template) shows you the *intended* images – what the chart is configured to deploy. This is useful for pre-deployment checks, audits of new charts, and understanding dependencies. Fetching from running pods (using kubectl get pods) shows you the *actual* images currently running in your cluster. This is crucial for debugging, verifying deployments, and real-time security audits, especially when configurations might have been overridden or latest tags have caused unexpected updates.

How do I ensure my images are secure in Kubernetes?

Ensuring image security involves several layers:

1. Use trusted base images: Start with official, minimal, and regularly updated base images.
2. Scan images: Integrate vulnerability scanners (Trivy, Clair, Snyk) into your CI/CD pipeline to detect known vulnerabilities before deployment.
3. Private registries: Store proprietary images in secure, private registries with proper access controls.
4. Least privilege: Run containers with non-root users and minimal necessary permissions.
5. Regular updates: Keep images and their components updated to patch vulnerabilities.
6. Image signing and verification: Implement mechanisms like Notary or Cosign to verify image integrity and origin.

Can I automate fetching images?

Absolutely! The commands we've discussed are perfectly suited for scripting. You can integrate them into:

• CI/CD Pipelines: As part of a deployment gate, script these commands to audit images before or after a release.
• Scheduled Jobs: Run these commands periodically (e.g., via a Kubernetes CronJob) to generate an inventory report of all images in your cluster, which can then be fed into a dashboard or alerting system for compliance and security teams.
• Custom Tools: Build internal tools or dashboards that leverage these commands to provide a user-friendly interface for image inventory.

Understanding and managing container images in your Kubernetes deployments is a critical skill for any DevOps professional. By leveraging Helm and kubectl, you gain unprecedented visibility and control over your application's components. Keep practicing these commands, and you'll master the art of fetching and managing images in Kubernetes like a pro!

For more insightful content and practical DevOps guides, make sure to check out the original video that inspired this deep dive. Don't forget to like, share, and subscribe to @explorenystream for more such valuable discussions. Milte hain agle video mein!