DEV Community

Cover image for Handling EKS: kubectl, Namespaces, and CRDs
Tetiana Mostova for AWS Community Builders

Posted on • Updated on

Handling EKS: kubectl, Namespaces, and CRDs

Managing EKS clusters from the command line can seem daunting at first, but having a grasp of some key kubectl commands will make you an expert in no time. In this beginner's guide, I'll walk through the most useful CLI commands for inspecting and troubleshooting your EKS workloads, nodes, namespaces and CRDs.
Let's start by looking at namespaces - these allow you to logically organize your cluster resources. To see current namespaces:
kubectl get namespaces
You can then specify a namespace when running commands:
kubectl get rs -n prod # rs stands for replica-set
This isolates prod resources from dev and test. Handy for access control between teams!

Here's a trick to set a default namespace so you don't have to enter it each time:
kubectl config set-context --current --namespace=dev
This will set the default namespace going forward to "dev". Now all kubectl commands will apply to that namespace by default:
kubectl describe secrets aws-secret # Describes aws-secret in dev namespace
And you can still override the default when needed:
kubectl get pods -n kube-system
One specially important namespace is kube-system. This houses critical cluster services and addons like:

  • CoreDNS - Cluster DNS

  • VPC Networking plugins

  • Node Termination Handler

Observe but don't modify kube-system to avoid issues!
Now, let's inspect pod workloads, the basic building blocks of EKS services:
kubectl get pods -n dev
This lists all pods in dev namespace and their status. To get more info on a specific pod:
kubectl describe node <node-name>
See the pattern here? "Get" for an overview, and "describe" for the nitty gritty details. This works for all Kubernetes resource types (e.g. kubectl get nodes, kubectl describe node <name> etc)
Finally, you can actually shell into a container with exec:
kubectl exec -it <pod-name> -- bash
This drops you into a bash shell running inside the pod, where you can inspect files, env vars, check connections, and troubleshoot further.

Inspecting Custom Resources

Many EKS addons and controllers introduce their own CustomResourceDefinitions (CRDs) - custom Kubernetes object types defined by scripts rather than baked into the main codebase.
For example, the AWS Load Balancer Controller has a CRD for defining Application Load Balancers.
You can view custom resources by running:
kubectl get crds
This will list all CRDs registered on the cluster. You can then operate on the custom resources themselves:
kubectl get albingress -n app-ns`
Here we are listing ingresses from the Application Load Balancer CRD.
CRDs allow developers to extend Kubernetes functionality without having to rebuild the core API. This enables rapid innovation. Definitely important to be aware of CRDs when running addons that enhance EKS!

As you can see, kubectl makes it easy to unlock the power of EKS! With these basic commands, you'll gain visibility and control over your clusters. The official kubectl cheat sheet lists even more goodies to try out.

Happy Kubectl-ing!

Top comments (0)