Master kubectl: Essential Commands and Pod Lifecycle Explained

kubectl Overview

kubectl is the command‑line tool for interacting with a Kubernetes cluster via the API server, allowing users to create, read, update, and delete cluster resources.

Key kubectl Commands

kubectl get pods

kubectl get deployment

kubectl get service

kubectl describe <resource> <name>

kubectl logs <pod>

kubectl edit <resource> <name>

kubectl delete <resource> <name>

kubectl exec -it <pod> -- /bin/bash

kubectl apply -f <file.yaml>

kubectl explain pods

kubectl run nginx --image=nginx

Understanding Pods

A pod is the smallest deployable unit in Kubernetes, consisting of one or more containers that share storage, network, and namespace. Pods act as logical hosts; containers inside a pod are always scheduled together and can communicate via localhost.

Pods share a Linux namespace, cgroup, and may share volumes. Each pod receives a unique UID and is scheduled onto a node until it is terminated. Pods are typically managed by higher‑level controllers (Deployments, ReplicaSets, etc.) to provide self‑healing and scaling.

Pod API Objects

The main fields of a pod manifest are:

apiVersion : version of the API schema (e.g., v1).

kind : the type of resource, here Pod.

metadata : name, namespace, labels, and other identifying data.

spec : desired state, including container specifications.

status : current observed state reported by the kubelet.

Creating a Pod with YAML

A typical pod definition looks like this:

apiVersion: v1
kind: Pod
metadata:
  name: web
  namespace: default
  labels:
    web1: tomcat
    web2: nginx
spec:
  containers:
  - name: tomcat1
    image: tomcat:latest
  - name: nginx
    image: nginx:latest

Apply the manifest with kubectl apply -f pod.yaml and delete it with kubectl delete -f pod.yaml. Pods created directly are “stand‑alone” and lack the self‑healing features of controller‑managed pods.

Pod Lifecycle and Hooks

Pod startup proceeds through Init containers followed by the main containers. Init containers run sequentially and must complete before the main containers start.

Containers support lifecycle hooks:

postStart : executed immediately after a container is created.

preStop : executed before a container is terminated.

Pod Health Probes

Kubernetes can probe containers to determine their health:

livenessProbe : if it fails, the kubelet kills the container and applies the restart policy.

readinessProbe : if it fails, the pod is removed from service endpoints.

Common Pod Statuses

Pending : the pod has been accepted but not yet scheduled.

Running : the pod is bound to a node and all containers are started.

Failed : one or more containers terminated with failure.

Succeeded : all containers terminated successfully.

Unknown : the node’s status cannot be obtained.

Pod Creation Phases and Restart Policies

The creation flow is essentially Init containers → main containers. Restart policies control container restarts:

Always (default): restart on any exit.

OnFailure : restart only if the container exits with a non‑zero status.

Never : do not restart the container.