Kubernetes clusters are generally administrated with
kubectl, which communicates with the cluster's API Server to perform operations. It can work either imperatively, acting immediately upon commands, or statefully, where the desired state of the cluster is modified to trigger controllers which act on the actual state of the cluster.
Connecting to a cluster
kubectl allows switching between multiple Kubernetes contexts:
kubectl config get-contextslists all configured contexts.
kubectl config use-context docker-desktopswitches to the Docker Desktop context.
kubectl versionlists client and server versions.
kubectl cluster-infoprovides high-level cluster configuration information.
kubectl api-resourceslists all resource types known to the cluster.
kubectl explain podyields the description of the root of the pod resource, and can optionally recurse further into the schema with
kubectl explain pod.spec.containers
To determine the version of the running etcd cluster, first locate the pod, then
exec into it to run
kubectl get po -n kube-system kubectl exec \ -it -n kube-system \ etcd-minikube -- etcd --version
More detail on etcd in its page.
kubectl get alllists all objects.
kubectl get podlists all pods.
kubectl get pod hello-worldgets a specific pod. Use
-o widefor more fields, or
-o yamlfor a full definition.
kubectl describe pod hello-worlddescribes a specific pod in detail.
Launching bare pods is a one-time event and doesn't take advantage of any of Kubernetes's useful behaviours, but it can be useful for letting us test that the cluster is functioning correctly.
kubectl run nginx --image nginx:latestlaunches a pod named
latesttag of the
kubectl port-forward pod/nginx 8080:80forwards traffic on the client's port 8080 to the pod's port 80.
kubectl expose service/nginx --type LoadBalancer --name nginxcreates a LoadBalancer service for the specified deployment.
set allows modifying individual fields.
edit opens a manifest in
Resources can be created imperatively with
create or statefully from a manifest with
--dry-run prints the changes that would have been applied.
--validate (true by default) validates the request against the schema before submission.
Nodes and pods are commonly labelled for scheduling and matching purposes. Labels can be added like so:
kubectl label node node0 example.com/location=ldn-2
Labels can be removed by specifying the key name with a trailing dash (
kubectl label node node0 example.com/location-
Labels can be printed out with the
kubectl get --show-labels switch.
Many events in Kubernetes generate Event objects which can be watched:
kubectl get events --watch
Note that since events are namespaced and termination of a namespace makes it read-only Events stop being logged. If you're troubleshooting termination issues, don't delete the namespace.
For application-level problems, dig into logs.
-p shows logs from previous instances of the container if it was restarted, and
-f follows the log:
kubectl logs -f podName [containerName]
As a last resort, get a shell to the container:
kubectl exec -it podname [-c container] -- sh