Search interest around Kubernetes as a whole dwarfs interest in specific tools like kubectl or “Kubernetes AI”, but related terms like deployment, pod, service, cluster, and docs drive most of that traffic. This tutorial covers all of them in one hands-on, code-first walkthrough, plus a bonus AI inference deployment.
Architecture Overview
The diagram above shows the request flow: kubectl → API Server → Deployment → Pods → Service, plus a dedicated AI inference Pod on a GPU-backed worker node.
Prerequisites
# Verify tooling
kubectl version --client
docker --version
minikube version
# Start a local cluster (skip if using a managed cluster)
minikube start --cpus=4 --memory=8192
Step 1: Containerize the App
# Dockerfile
FROM node:20-alpine
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
EXPOSE 3000
CMD ["node", "server.js"]
docker build -t kubezilla/web-app:1.0 .
docker push kubezilla/web-app:1.0
Step 2: Define the Deployment
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: web-app
labels:
app: web
spec:
replicas: 3
selector:
matchLabels:
app: web
template:
metadata:
labels:
app: web
spec:
containers:
- name: web
image: kubezilla/web-app:1.0
ports:
- containerPort: 3000
resources:
requests:
cpu: "100m"
memory: "128Mi"
limits:
cpu: "250m"
memory: "256Mi"
readinessProbe:
httpGet:
path: /healthz
port: 3000
initialDelaySeconds: 5
Step 3: Expose It With a Service
# service.yaml
apiVersion: v1
kind: Service
metadata:
name: web-app-svc
spec:
type: LoadBalancer
selector:
app: web
ports:
- port: 80
targetPort: 3000
Step 4: Apply and Verify With kubectl
kubectl apply -f deployment.yaml
kubectl apply -f service.yaml
kubectl get deployments
kubectl get pods -l app=web -o wide
kubectl get svc web-app-svc
kubectl rollout status deployment/web-app
Step 5: Scale and Self-Heal
# Manual scale
kubectl scale deployment/web-app --replicas=6
# Autoscale on CPU
kubectl autoscale deployment/web-app --min=3 --max=10 --cpu-percent=70
# Kill a pod and watch Kubernetes replace it
kubectl delete pod -l app=web --field-selector=status.phase=Running
kubectl get pods -l app=web -w
Bonus: Deploying an AI Inference Workload
“Kubernetes AI” is one of the fastest-rising related searches. Here’s the same pattern applied to a GPU-backed inference service:
# ai-inference-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: ai-inference
spec:
replicas: 1
selector:
matchLabels:
app: ai-inference
template:
metadata:
labels:
app: ai-inference
spec:
containers:
- name: triton
image: nvcr.io/nvidia/tritonserver:24.01-py3
args: ["tritonserver", "--model-repository=/models"]
resources:
limits:
nvidia.com/gpu: 1
ports:
- containerPort: 8000
kubectl apply -f ai-inference-deployment.yaml
kubectl get pods -l app=ai-inference
kubectl logs -l app=ai-inference -f
kubectl Cheat Sheet: Commands You’ll Use Daily
kubectl get nodes -o wide
kubectl describe pod POD_NAME
kubectl logs POD_NAME --previous
kubectl exec -it POD_NAME -- /bin/sh
kubectl rollout undo deployment/web-app
kubectl top pods
kubectl delete -f deployment.yaml
FAQ
Is kubectl the same as Kubernetes?
No. Kubernetes is the orchestration platform; kubectl is the command-line client used to talk to its API server.
Do I need a GPU for Kubernetes AI workloads?
Only for training or GPU-accelerated inference. CPU-based inference images run on standard nodes with no extra configuration.
What’s the fastest way to debug a failing Pod?
kubectl describe pod POD_NAME
kubectl logs POD_NAME
kubectl get events --sort-by=.lastTimestamp
Summary
You built an image, deployed it with a Deployment and Service, scaled it, and shipped a GPU-backed AI inference Pod, all through kubectl. Bookmark the cheat sheet above and re-run these manifests on any cluster.
