Kubernetes 1.30 Quick Reference


## Quick Overview

Kubernetes (K8s) is an open-source container orchestration system for automating deployment, scaling, and management of containerized applications. It groups containers into logical units for easy management and discovery, providing a platform to run workloads reliably at scale. You'd reach for Kubernetes to manage complex microservice architectures, ensure high availability, enable continuous deployment, and efficiently utilize infrastructure.

Current stable version covered: Kubernetes 1.30.

Local installation for quick testing (e.g., Minikube):
```bash
# Install minikube (macOS example, adapt for your OS)
# brew install minikube
# minikube start

Getting Started

This section assumes you have kubectl installed and configured to connect to a Kubernetes cluster (e.g., Minikube, Kind, or a cloud-managed cluster).

Verify Cluster Connection:

# Check current context and connection
kubectl config current-context
# Verify nodes are ready
kubectl get nodes

Deploy a Simple Nginx Application:

# my-nginx-deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.25.4 # Specify a stable version
        ports:
        - containerPort: 80

# Apply the deployment manifest
kubectl apply -f my-nginx-deployment.yaml
# Check the status of the deployment
kubectl get deployment nginx-deployment
# Check the running pods
kubectl get pods -l app=nginx

Expose the Application with a Service:

# my-nginx-service.yaml
apiVersion: v1
kind: Service
metadata:
  name: nginx-service
spec:
  selector:
    app: nginx
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: LoadBalancer # Use NodePort for local/Minikube, LoadBalancer for cloud

# Apply the service manifest
kubectl apply -f my-nginx-service.yaml
# Check the service status and external IP (if LoadBalancer is supported)
kubectl get service nginx-service
# If using Minikube and NodePort/LoadBalancer, get the service URL
# minikube service nginx-service --url

Core Concepts

Concept	Description
Pod	The smallest deployable unit in Kubernetes, encapsulating one or more containers, storage resources, a unique network IP, and options that govern how the containers run. All containers in a Pod share the same network namespace and storage.
Deployment	Manages a set of identical Pods. It defines how many replicas of a Pod should run and how updates (like rolling updates) should be performed. Deployments manage ReplicaSets, which in turn manage Pods.
Service	An abstract way to expose an application running on a set of Pods as a network service. Services can have a stable IP address and DNS name, allowing Pods to be ephemeral. Types include ClusterIP, NodePort, LoadBalancer, and ExternalName.
Namespace	Provides a mechanism for scoping resources within a cluster. Names of resources need to be unique within a namespace but not across namespaces. Used for organizational, security, and resource isolation.
Node	A worker machine in Kubernetes, which can be a virtual or physical machine. Each Node contains the necessary components to run Pods, including the container runtime (e.g., containerd), kubelet, and kube-proxy.
ReplicaSet	Ensures that a specified number of Pod replicas are running at any given time. Usually managed by Deployments; you rarely interact with them directly.
StatefulSet	Used for managing stateful applications. It provides guarantees about the ordering and uniqueness of Pods, stable network identifiers, and stable persistent storage. Useful for databases or message queues.
DaemonSet	Ensures that all (or some) Nodes run a copy of a Pod. Useful for cluster-level operations like log collectors, monitoring agents, or storage daemons.
ConfigMap	Used to store non-confidential configuration data as key-value pairs. Pods can consume ConfigMaps as environment variables, command-line arguments, or as files in a volume.
Secret	Similar to ConfigMap but designed for sensitive data like passwords, tokens, and keys. Data is base64 encoded by default (not encrypted at rest without additional configuration).
PersistentVolume (PV)	A piece of storage in the cluster that has been provisioned by an administrator or dynamically provisioned. It’s a resource in the cluster, independent of a Pod’s lifecycle.
PersistentVolumeClaim (PVC)	A request for storage by a user. It consumes PV resources. Pods request storage through PVCs.
Ingress	Manages external access to services in a cluster, typically HTTP/S. Ingress provides load balancing, SSL termination, and name-based virtual hosting. Requires an Ingress Controller (e.g., Nginx, Traefik).
Helm	A package manager for Kubernetes. Helm Charts help you define, install, and upgrade even the most complex Kubernetes applications. (Not a core K8s resource, but essential for advanced use).
kubeconfig	A file used to organize information about clusters, users, namespaces, and authentication mechanisms. `kubectl` uses this file to find the information it needs to choose a cluster and communicate with its API server.
Kustomize	A tool for customizing Kubernetes configurations without modifying the original YAML files. It uses a declarative approach to merge base configurations with overlay files. (Built into `kubectl` as `kubectl apply -k`).

Essential Commands / API / Syntax

All commands below use kubectl, the command-line tool for Kubernetes.

General Operations

# Get resources (pods, deployments, services, nodes, namespaces, pv, pvc, cm, secret, ingress, hpa, crd)
kubectl get <resource-type>
kubectl get pods
kubectl get deployments -n my-namespace # Get resources in a specific namespace
kubectl get all -A # Get all common resources across all namespaces
kubectl get pod <pod-name> -o yaml # Get detailed YAML output for a resource
kubectl get pod <pod-name> -o json # Get detailed JSON output for a resource
kubectl get pod <pod-name> -w # Watch for changes to a resource
kubectl get pods --field-selector=status.phase=Running # Filter by field selector

# Describe resources (detailed information, events, status)
kubectl describe pod <pod-name>
kubectl describe deployment <deployment-name> -n my-namespace

# Apply/Update resources from a file
kubectl apply -f <file.yaml>
kubectl apply -f <directory-with-yaml-files>
kubectl apply -k <kustomization-directory> # Apply a Kustomization

# Edit resources in place
kubectl edit deployment <deployment-name> # Opens default editor to modify live resource

# Delete resources
kubectl delete -f <file.yaml>
kubectl delete deployment <deployment-name>
kubectl delete pod <pod-name> --grace-period=0 --force # Force delete (use with caution)

# Explain resource fields (useful for YAML authoring)
kubectl explain deployment.spec.template.spec.containers.image

Pod & Container Management

# View logs from a container in a pod
kubectl logs <pod-name>
kubectl logs -f <pod-name> # Follow logs
kubectl logs <pod-name> -c <container-name> # Specify container in a multi-container pod
kubectl logs <pod-name> --tail=100 # Show last 100 lines
kubectl logs <pod-name> --since=1h # Show logs from the last hour

# Execute a command in a running container
kubectl exec -it <pod-name> -- /bin/bash # Interactive shell
kubectl exec <pod-name> -c <container-name> -- ls -l /app # Run a command without interactive shell

# Copy files to/from a container
kubectl cp <local-path> <pod-name>:/<container-path>
kubectl cp <pod-name>:/<container-path> <local-path>

# Port-forward to a pod or service
kubectl port-forward pod/<pod-name> 8080:80 # Forward local 8080 to pod's 80
kubectl port-forward service/<service-name> 8080:80 # Forward to a service

# Debugging (new in K8s 1.25, in-place debugging with ephemeral containers)
kubectl debug -it pod/<pod-name> --image=ubuntu --target=<container-name> # Attach an ephemeral debug container

Deployment & Scaling

# Scale a deployment
kubectl scale deployment <deployment-name> --replicas=5
kubectl autoscale deployment <deployment-name> --min=2 --max=10 --cpu-percent=80 # Set up Horizontal Pod Autoscaler

# Rollout status
kubectl rollout status deployment/<deployment-name>

# Rollout history
kubectl rollout history deployment/<deployment-name>

# Undo a rollout to a previous revision
kubectl rollout undo deployment/<deployment-name> --to-revision=2

# Pause/Resume a rollout (useful for making multiple changes before resuming)
kubectl rollout pause deployment/<deployment-name>
kubectl rollout resume deployment/<deployment-name>

Configuration & Secrets

# Create a ConfigMap from literal values
kubectl create configmap my-config --from-literal=key1=value1 --from-literal=key2=value2

# Create a ConfigMap from files
kubectl create configmap my-config --from-file=/path/to/my-config.txt

# Create a Secret from literal values
kubectl create secret generic my-secret --from-literal=username=admin --from-literal=password=s3cr3t

# Create a Secret from files
kubectl create secret generic my-secret --from-file=username.txt --from-file=password.txt

# Create a Secret for Docker registry authentication
kubectl create secret docker-registry my-regcred --docker-server=<your-registry> --docker-username=<username> --docker-password=<password> --docker-email=<email>

# Decode a Secret (data is base64 encoded)
kubectl get secret my-secret -o jsonpath='{.data.username}' | base64 --decode

Networking (Services & Ingress)

# Get details about services
kubectl get svc
kubectl describe svc <service-name>

# Get details about ingress
kubectl get ingress
kubectl describe ingress <ingress-name>

# Get endpoint IPs for a service (the Pod IPs it routes to)
kubectl get endpoints <service-name>

Cluster Information

# Get cluster information
kubectl cluster-info

# Check the Kubernetes API server version
kubectl version --short

# List available API resources
kubectl api-resources

# List events in the current namespace
kubectl get events

Common Patterns

1. Multi-Container Application with Persistent Storage and Ingress

This pattern deploys a web application (e.g., WordPress) requiring a database (e.g., MySQL), persistent storage, and external access via Ingress.

# wordpress-full-stack.yaml
apiVersion: v1
kind: Secret
metadata:
  name: wordpress-mysql
stringData:
  password: "your_strong_mysql_password"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-pv-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress-mysql
spec:
  selector:
    matchLabels:
      app: wordpress
      tier: mysql
  template:
    metadata:
      labels:
        app: wordpress
        tier: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8.0.36 # Specific version
        env:
        - name: MYSQL_ROOT_PASSWORD
          valueFrom:
            secretKeyRef:
              name: wordpress-mysql
              key: password
        ports:
        - containerPort: 3306
          name: mysql
        volumeMounts:
        - name: mysql-persistent-storage
          mountPath: /var/lib/mysql
      volumes:
      - name: mysql-persistent-storage
        persistentVolumeClaim:
          claimName: mysql-pv-claim
---
apiVersion: v1
kind: Service
metadata:
  name: wordpress-mysql
spec:
  selector:
    app: wordpress
    tier: mysql
  ports:
  - port: 3306
    targetPort: 3306
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: wordpress-pv-claim
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: wordpress
spec:
  selector:
    matchLabels:
      app: wordpress
      tier: frontend
  template:
    metadata:
      labels:
        app: wordpress
        tier: frontend
    spec:
      containers:
      - name: wordpress
        image: wordpress:6.5.2-php8.3 # Specific version
        env:
        - name: WORDPRESS_DB_HOST
          value: wordpress-mysql
        - name: WORDPRESS_DB_USER
          value: root
        - name: WORDPRESS_DB_PASSWORD
          valueFrom:
            secretKeyRef:
              name: wordpress-mysql
              key: password
        ports:
        - containerPort: 80
          name: wordpress
        volumeMounts:
        - name: wordpress-persistent-storage
          mountPath: /var/www/html
      volumes:
      - name: wordpress-persistent-storage
        persistentVolumeClaim:
          claimName: wordpress-pv-claim
---
apiVersion: v1
kind: Service
metadata:
  name: wordpress
spec:
  selector:
    app: wordpress
    tier: frontend
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: wordpress-ingress
  annotations:
    nginx.ingress.kubernetes.io/rewrite-target: / # Example Nginx Ingress annotation
spec:
  rules:
  - host: wordpress.example.com
    http:
      paths:
      - path: /
        pathType: Prefix
        backend:
          service:
            name: wordpress
            port:
              number: 80
``````bash
# Apply the entire stack
kubectl apply -f wordpress-full-stack.yaml
# Ensure an Ingress Controller is running in your cluster (e.g., Nginx Ingress)
# You might need to update your /etc/hosts file if testing locally, e.g. <ingress-ip> wordpress.example.com

2. Rolling Updates and Rollbacks

Deployments inherently support rolling updates. When you update the image tag or other spec changes, Kubernetes creates new Pods with the new configuration, gradually replacing old ones, ensuring zero downtime.

# Update the image in your existing deployment YAML or patch it directly
# kubectl edit deployment nginx-deployment
# Change image: nginx:1.25.4 to image: nginx:1.26.0

# Or, patch directly:
kubectl set image deployment/nginx-deployment nginx=nginx:1.26.0
# Watch the rollout progress
kubectl rollout status deployment/nginx-deployment
# Check the rollout history
kubectl rollout history deployment/nginx-deployment
# If there's an issue, roll back to the previous stable version
kubectl rollout undo deployment/nginx-deployment
# To roll back to a specific revision (e.g., revision 1)
kubectl rollout undo deployment/nginx-deployment --to-revision=1

3. Using Kustomize for Configuration Overlays

Kustomize allows you to customize raw, template-free YAML files for multiple environments without forking.

# Create a base directory with your common manifests
mkdir base
cat <<EOF > base/deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: myapp
spec:
  replicas: 1
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: myapp-container
        image: myapp:1.0.0
EOF

cat <<EOF > base/service.yaml
apiVersion: v1
kind: Service
metadata:
  name: myapp
spec:
  selector:
    app: myapp
  ports:
  - port: 80
    targetPort: 80
EOF

cat <<EOF > base/kustomization.yaml
resources:
- deployment.yaml
- service.yaml
EOF

# Create an overlay for 'production' environment
mkdir overlays/production
cat <<EOF > overlays/production/kustomization.yaml
resources:
- ../../base # Point to the base directory
patches:
- patch: |-
    - op: replace
      path: /spec/replicas
      value: 5
  target:
    kind: Deployment
    name: myapp
images:
- name: myapp:1.0.0
  newName: myapp
  newTag: 1.1.0-prod
EOF

# Build and apply the production configuration
kubectl apply -k overlays/production
# Or just build to see the merged YAML
# kubectl kustomize overlays/production

Gotchas & Tips

Resource Limits & Requests: Always define resources.limits and resources.requests for CPU and memory in your Pod specs. This helps the scheduler place Pods effectively and prevents noisy neighbors from hogging resources.
- requests: Guarantees a minimum amount of resources.
- limits: Sets an upper bound, preventing a container from using more than specified.
- Tip: Start with requests and then tune limits based on observed usage.
Liveness & Readiness Probes: Essential for robust applications.
- livenessProbe: Determines if a container is still running. If it fails, Kubelet restarts the container.
- readinessProbe: Determines if a container is ready to serve traffic. If it fails, the Pod is removed from Service endpoints.
- Tip: Use HTTP or TCP probes for most apps, exec for more complex health checks. Don’t make probes too aggressive.
Namespace Best Practices:
- Use namespaces to logically separate environments (dev, staging, prod) or teams.
- Limit resource access between namespaces using NetworkPolicies and RBAC.
- Gotcha: kubectl commands operate in the current context’s default namespace unless -n or --namespace is specified.
Debugging CrashLoopBackOff:
- This usually means your application inside the container is exiting unexpectedly.
- Check kubectl logs <pod-name> first.
- kubectl describe pod <pod-name> for events (e.g., image pull errors, OOMKilled).
- Try kubectl exec -it <pod-name> -- /bin/bash (if the pod briefly starts) to manually inspect.
ImagePullBackOff:
- Common causes: incorrect image name/tag, private registry credentials missing (or Secret not linked to Pod’s ServiceAccount), network issues accessing the registry.
- Check kubectl describe pod <pod-name> for details on the pull error.
- Ensure imagePullSecrets are configured on the Pod’s ServiceAccount or directly on the Pod spec for private registries.
Contexts & Kubeconfig:
- Manage multiple clusters/environments with kubectl config.
- kubectl config get-contexts: List available contexts.
- kubectl config use-context <context-name>: Switch to a different cluster/user/namespace.
- kubectl config view: View the merged kubeconfig.
- Tip: Use tools like kubectx and kubens for faster switching.
API Deprecations: Kubernetes API versions evolve. Always check the official documentation for deprecations when upgrading your cluster version. As of K8s 1.30, networking.k8s.io/v1beta1 for Ingress is deprecated, use networking.k8s.io/v1. apps/v1 is the stable API for Deployments, StatefulSets, DaemonSets, ReplicaSets.
Immutable Infrastructure: Treat your containers and Pods as immutable. Don’t exec into a running container to make changes that aren’t also reflected in your deployment manifests. Redeploy instead.
Idempotency: All your Kubernetes manifest files (.yaml) should be idempotent, meaning applying them multiple times produces the same desired state. kubectl apply is designed for this.

Next Steps

Official Kubernetes Documentation: The ultimate source for in-depth understanding and API reference: https://kubernetes.io/docs/
Helm: Learn how to package and deploy complex applications using Helm Charts: https://helm.sh/
Operators: Explore the Operator Framework for managing complex stateful applications: https://operatorframework.io/
Service Mesh (e.g., Istio, Linkerd): For advanced traffic management, observability, and security at the service level: https://istio.io/ or https://linkerd.io/
CI/CD with Kubernetes (e.g., Argo CD, Jenkins X): Automate your deployments and operations: https://argoproj.github.io/cd/

Source: z2h.fyi/cheatsheets/kubernetes-quick-reference — Zero to Hero cheatsheets for developers.