Learn Kubernetes with k3s - part3 - kubectl
This post is the continuation of part 2.
kubectl is a command line tool that allows users to run commands against Kubernetes clusters. Specifically, kubectl enables communication between users and the control plane via Kubernetes API. So the mastery of kubectl is essential for handling real-world cluster operations and troubleshooting.
Below is a table showing the common kubectl commands.
| Operation | Subcommand | Example |
|---|---|---|
| configuring access | kubectl config | set-cluster my-cluster |
| listing and reading resources | kubectl get kubectl describe kubectl logs |
pods -A pod/abc pod/abc |
| creating resources | kubectl create kubectl apply |
namespace abc -f my-manifest.yaml |
| updating resources | kubectl edit kubectl replace kubectl apply kubectl scale |
svc/docker-registry -f nginx-deployment.yaml -f my-manifest.yaml --replicas=3 rs/foo |
| deleting resources | kubectl delete | pod unwanted --now |
| running pods | kubectl run kubectl attach kubectl exec |
nginx --image=nginx my-pod -it my-pod -- ls / |
| connecting to resources | kubectl port-forward kubectl cp |
svc/my-service 5000 my-pod:/foo bar |
| check resource usage (requires metrics server) |
kubectl top | nodes |
Explanation
No doubt there is a lot to digest. I will explain some of the concepts involved here, and leave the rest for you to research about.
Namespace
A Kubernetes namespace provides a scope for names of resources within a Kubernetes cluster. It allows the isolation of groups of resources and management of cluster components like Pods, Services, and Deployments.
Namespaces are intended for use in environments with many users spread across multiple teams or projects. They prevent name collisions that can occur when different teams are using resources with the same name. Resources within one namespace are not visible to other namespaces unless steps are explicitly taken to allow that.
To get resources from all namespaces
$ kubectl get pods -A
Pod
A Kubernetes pod is the basic building block of applications in Kubernetes. It is a group of one or more containers (such as Docker containers), with shared storage/network resources, and a specification for how to run the containers.
Pods allow containers to run together on the same machine and share resources. This means containers within a pod can communicate easily using localhost.
Service
A Kubernetes service is an abstraction layer that defines a logical set of pods and enables external traffic exposure and load balancing to those pods, regardless of where on the cluster they are scheduled.
Services define rules about how groups of pods can be accessed (e.g. randomly, via round-robin load balancing). This provides a single IP address or DNS name endpoint for reaching multiple pods.
There are different types of services that support different methods of service discovery and load balancing: ClusterIP, NodePort, LoadBalancer.
Deployment
A Kubernetes deployment is an object that manages pods and replica sets in Kubernetes. It provides declarative updates for pods and replica sets.
Deployments are responsible for creating and updating pods based on the provided configuration. It helps in rolling out new updates or roll back to previous deployments.
It provides self-healing capabilities by automatically replacing pods that fail or are terminated. This ensures the application is always available.
Aliases
You can set aliases in ~/.zshrc or ~/.bashrc to make typing of kubectl commands a little bit faster. This is convenient for your work and passing CKA certification exam.
For examples
alias kc='kubectl'
alias kns='kubectl config set-context --current --namespace'
alias kbb='kubectl run busybox --image=busybox --restart=Never -it --'
So that we can do
$ kc get pods # get all pods
$ kns my-namespace # set default namespace
$ kbb ls -la # run ad hoc linux commands
Infrastructure as Code
Do we need to memorize all kubectl commands out there? Not necessarily. In fact, you are almost never going to use the resource creation/update/delete commands.
The best practice is to manage and provision resources through code, not imperative commands. This is known as infrastructure as code (IaC).
IaC allows infrastructure to be treated as software which can be developed, tested, and reviewed like any other code. Creating Kubernetes resources with kubectl create or kubectl apply goes against the spirit of IaC.
So you can think of certain kubectl commands as relics of the past, although CKA certification exams test for them. Still it's best to gain some exposure, who knows you might need them for troubleshooting one day.
To be continued in part 4, about Kubernetes services.