Viewing Cluster Resources with `kubectl get`

1. The "Read" Command: What is kubectl get?

At its core, kubectl get is a read-only command used to retrieve summary information about Kubernetes resources. Think of it as the Kubernetes equivalent of running az vm list in Azure, aws ec2 describe-instances in AWS, or even docker ps. It's your primary tool for listing resources and checking their high-level status.

When you run kubectl get, it communicates with the Kubernetes API server, fetches the current state of the requested resources, and presents it in a concise, tabular format.

To get a formal introduction to the command's purpose and key characteristics, please read the first few sections of the following article.

2. Basic Usage: Listing Common Resources

The basic syntax is straightforward: kubectl get <resource-type>. You can also provide an optional resource name to retrieve just a single object.

Let's look at some of the most common resource types you'll be listing.

• Pods (po): The fundamental unit of deployment.

  kubectl get pods
  

  The output will look something like this:

  NAME                              READY   STATUS      RESTARTS   AGE
  nginx-deployment-574d5d67c9-abcde   1/1     Running     0          2m10s
  nginx-deployment-574d5d67c9-fghij   1/1     Running     0          2m10s
  

  The columns are self-explanatory, but READY is particularly important: it shows how many containers in the Pod are ready versus the total number of containers. 1/1 is what you want to see.

• Deployments (deploy): Manages the lifecycle of your application Pods.

  kubectl get deployments
  

  NAME               READY   UP-TO-DATE   AVAILABLE   AGE
  nginx-deployment   2/2     2            2           5m
  

  Here, READY shows how many replicas are running versus the desired number.

• Services (svc): Exposes your application to network traffic.

  kubectl get services
  

• Nodes (no): The worker machines in your cluster.

  kubectl get nodes
  

This video from "TechWorld with Nana" demonstrates these basic get commands in a natural workflow, showing how they are used to check the status after creating resources.

3. Scoping Queries with Namespaces

Your experience with multi-tenant environments on AWS, Azure, and GCP has shown that resource organization is key. In Kubernetes, the primary tool for this is namespaces.

By default, kubectl commands operate on the default namespace. If you run kubectl get pods and see nothing, it might just mean there are no Pods in the default namespace. As a Platform Engineer, you'll constantly work across different namespaces (e.g., dev, staging, prod, kube-system).

Here are the essential flags for managing namespaces:

• -n <namespace-name>: List resources in a specific namespace. System components typically run in kube-system.

  # List pods in the kube-system namespace
  kubectl get pods -n kube-system
  

• -A or --all-namespaces: List resources across all namespaces in the cluster. This is extremely useful for getting a global overview.

  # List all pods in the entire cluster
  kubectl get pods -A
  

4. Customizing Output for Deeper Insights

While the default table view is great for a quick glance, you often need more information. kubectl get provides powerful output formatting options using the -o (or --output) flag.

More Columns with -o wide

The -o wide flag adds extra columns to the output. For Pods, this is incredibly useful as it shows the Pod's IP address and the Node it's scheduled on.

kubectl get pods -o wide

NAME                              READY   STATUS    RESTARTS   AGE     IP          NODE           NOMINATED NODE   READINESS GATES
nginx-deployment-574d5d67c9-abcde   1/1     Running   0          15m     10.244.1.5   worker-node-1   <none>           <none>
nginx-deployment-574d5d67c9-fghij   1/1     Running   0          15m     10.244.2.8   worker-node-2   <none>           <none>

This instantly tells you about your Pods' network identity and physical placement, which is invaluable for debugging connectivity or resource placement issues.

The Full Picture with -o yaml and -o json

Remember the YAML manifest files you used with kubectl apply to define the desired state? With -o yaml or -o json, you can ask the API server to give you the actual state of a resource in the same format.

# Get the full YAML definition of a specific pod
kubectl get pod nginx-deployment-574d5d67c9-abcde -o yaml

This is the ground truth. It shows the complete configuration of the live object, including fields that were defaulted or added by Kubernetes controllers (like status). Comparing this output to your original manifest is a powerful debugging technique.

This video provides a quick visual demonstration of these output flags.

For a more comprehensive overview of all the formatting options, including advanced ones like custom-columns and jsonpath that are great for scripting, the "Guide to kubectl Output Formatting" article is an excellent reference.

5. Hands-on Practice: Watch it Live

Let's tie this together with the nginx-deployment.yaml from our last lesson.

1. If you don't have it, create a file named nginx-deployment.yaml:

   apiVersion: apps/v1
   kind: Deployment
   metadata:
     name: nginx-deployment
   spec:
     replicas: 2
     selector:
       matchLabels:
         app: nginx
     template:
       metadata:
         labels:
           app: nginx
       spec:
         containers:
         - name: nginx
           image: nginx:1.21.0
           ports:
           - containerPort: 80
   

2. Apply the manifest:

   kubectl apply -f nginx-deployment.yaml
   

3. Now, use get to inspect what happened. First, check the Deployment:

   kubectl get deployment nginx-deployment
   

   You should see READY showing 2/2.

4. Next, check the Pods created by the Deployment:

   kubectl get pods -l app=nginx -o wide
   

   Here, we've combined -l (a label selector) to find only pods with the app=nginx label and -o wide to see their IPs and nodes.

5. Finally, let's watch a change happen in real-time. The -w (--watch) flag keeps the command running and streams updates. Open a new terminal and run:

   kubectl get pods -l app=nginx -w
   

6. In your original terminal, edit nginx-deployment.yaml and change replicas: 2 to replicas: 3, then apply it:

   kubectl apply -f nginx-deployment.yaml
   

   Switch back to the terminal with the watch command. You will see a new Pod appear and transition from Pending to ContainerCreating to Running. This is an incredibly powerful way to monitor rollouts or scaling events. Press Ctrl+C to exit the watch.

Conclusion

You now have a solid grasp of kubectl get, the essential command for observing the state of your Kubernetes cluster. It provides the quick feedback loop needed to verify your kubectl apply actions and is the first step in any troubleshooting process.

Key Takeaways:

• kubectl get is your primary read-only tool for listing resources and their summary status.
• You can get common resources like pods, deployments, services, and nodes.
• Always be mindful of namespaces. Use -n for a specific namespace and -A to view resources across the entire cluster.
• Use -o wide for more details like Pod IP and Node.
• Use -o yaml or -o json to see the full, live resource definition from the API server.
• Use -w to watch for real-time changes to resources.

You've learned how to get a summary view. But what if a Pod is stuck in Pending or CrashLoopBackOff? The summary from get tells you what is wrong, but not why. For that, you need a more detailed, human-readable view. In our next lesson, we'll dive into kubectl describe, the command that provides exactly that.