devops kubernetesk8scontainersorchestrationdeploymentgitopshelm

kubernetes

Deploy and operate applications on Kubernetes: workloads, services, config, scaling, and GitOps. Use for container orchestration at scale.

Quality 100% Code blocks 6 Sections 8 Lines 150 RU translation yes
view source
Models: sonnetopusgpt-6gemini-3glm-5

Kubernetes

Deploying and operating containerized applications with Kubernetes.

Quick Start

# Local cluster (kind or minikube)
kind create cluster
kubectl apply -f deploy.yaml
kubectl get pods

When to Use

  • Running many services that need automated scaling
  • Self-healing workloads (restarts, rescheduling)
  • Rolling deployments and canaries
  • Multi-environment consistency at scale

Best Practices

Workloads

  • Prefer Deployments (stateless); StatefulSets for databases
  • Define resources (requests/limits) on every container
  • Add liveness and readiness probes
  • Use ReplicaSets with at least 2 replicas for prod

Configuration

  • Put config in ConfigMaps; secrets in Secrets (base64, external for real secrets)
  • Inject via env, mounted volumes, or external secret operators
  • Use Helm for packaging; chart versioning matches app version
  • Never hardcode config in images

Networking & Security

  • Expose via Services (ClusterIP/NodePort/LoadBalancer)
  • Use Ingress for HTTP routing with TLS
  • Apply RBAC with least privilege; use NetworkPolicies
  • Set resource quotas and limits per namespace

Dependencies

# kubectl + a cluster (kind/minikube/cloud)
kubectl version --client
# Helm (optional)
helm version

Examples

# Deployment with probes, resources, and replicas
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels: { app: web }
  template:
    metadata:
      labels: { app: web }
    spec:
      containers:
        - name: web
          image: ghcr.io/org/myapp:1.0.0
          ports: [{ containerPort: 8080 }]
          resources:
            requests: { cpu: 100m, memory: 128Mi }
            limits: { cpu: 500m, memory: 512Mi }
          readinessProbe:
            httpGet: { path: /health, port: 8080 }
          livenessProbe:
            httpGet: { path: /health, port: 8080 }
# Service + Ingress
apiVersion: v1
kind: Service
metadata: { name: web }
spec:
  selector: { app: web }
  ports:
    - { port: 80, targetPort: 8080 }
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata: { name: web }
spec:
  rules:
    - host: app.example.com
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service: { name: web, port: { number: 80 } }
# ConfigMap + Secret
apiVersion: v1
kind: ConfigMap
metadata: { name: app-config }
data:
  LOG_LEVEL: info
---
apiVersion: v1
kind: Secret
metadata: { name: app-secret }
type: Opaque
stringData:
  API_KEY: change-me
# Rolling update and rollback
kubectl set image deploy/web web=ghcr.io/org/myapp:1.1.0
kubectl rollout status deploy/web
kubectl rollout undo deploy/web

Step-by-Step

1. Define the Deployment with resources, probes, and replicas.

2. Add a Service and Ingress for traffic routing.

3. Externalize config into ConfigMaps and Secrets.

4. Apply to a dev cluster first; validate with `kubectl get` and logs.

5. Add autoscaling (HPA) based on CPU/memory.

6. Package with Helm for reusable charts.

7. Adopt GitOps (ArgoCD/Flux) for declarative deploys.

8. Add NetworkPolicies, RBAC, and resource quotas before prod.

Validation

1. `kubectl apply` succeeds; pods reach Ready

2. Probes pass; rolling updates complete without downtime

3. `kubectl rollout status` shows fully available

4. Ingress routes to the service over HTTPS

5. `kubectl describe` shows no crash loops or OOMKills

Troubleshooting

  • CrashLoopBackOff: check logs and image tag.
  • ImagePullBackOff: verify image name, tag, and registry credentials.
  • Pending pods: insufficient resources or node pressure — check events.