kubectl is the command-line client for managing a Kubernetes cluster. Paired with a kubeconfig file, it connects to the Kubernetes API so you can inspect nodes, deploy containers, manage Services, and restart Deployments. Unlike the Kubernetes Dashboard, it works directly in a terminal and can be used in scripts and CI/CD workflows. section 8.1.3 section 8.2.1
Get connected before deploying anything:
- Install kubectl using Homebrew on macOS, Chocolatey on Windows, or a downloaded binary on Linux. Check the installation with kubectl version --client --output=yaml. A localhost connection error at this stage is expected if no cluster is configured. section 8.2.2
- Download your cluster’s kubeconfig file. Put it at ~/.kube/config, or set KUBECONFIG to its absolute path. The environment variable makes it easier to switch between projects; treat the file as a secret and never commit it to Git. section 8.2.3 section 8.1.3
- Run kubectl get nodes to check that the configured client can reach the cluster. section 8.2.3
Create and inspect a first Pod
Save a Pod manifest as my-first-pod.yaml, then run kubectl apply -f my-first-pod.yaml. Run kubectl get pods to check its status. If it does not start, try kubectl describe pod <pod-name> or kubectl logs <pod-name>. To remove the resource, run kubectl delete -f my-first-pod.yaml. Keeping the intended resource in YAML makes it easier to apply the same configuration again; apply creates it or updates it when the manifest changes. section 8.3.1
Listing 8.3 K8s YAML manifest for an NGINX Pod
apiVersion: v1
kind: Pod
metadata:
name: first-pod-nginx
spec:
containers:
- name: nginx
image: nginx
This small NGINX Pod manifest gives kubectl apply a concrete resource definition: a name and a container image. section 8.3.1
The same pattern extends beyond one Pod. For related ConfigMap, Deployment, and Service manifests, you can apply files individually or apply their folder with kubectl apply -f custom-nginx/. Name dependent files in the required provision order. For quick experiments, a temporary Pod created directly with kubectl can help test container images, configuration, or communication inside the cluster; manifests remain the preferred long-term approach. section 8.3.4 section 8.4.3
In GitHub Actions, a workflow can install kubectl, provide a service-account kubeconfig, inspect Pods and Deployments, apply manifests, and run kubectl rollout restart deployment for applications using unchanged manifests with :latest image tags. This takes the same terminal commands into an automated deployment, provided the cluster, client, credentials, and permissions are available. section 8.5.2
