Kubernetes for Developers: Pods, Services, and Deployments (2026)

At Viprasol, we've migrated numerous applications to Kubernetes, guided startups through containerized architectures, and built scalable systems that serve millions of users. Kubernetes has become the industry-standard platform for orchestrating containerized applications, but for developers accustomed to traditional hosting environments or even basic Docker containers, Kubernetes's complexity can feel overwhelming. However, understanding Kubernetes's core concepts—Pods, Services, and Deployments—demystifies the platform and enables developers to build applications that scale gracefully, recover from failures automatically, and deploy updates without downtime. This guide walks through these fundamental concepts, demonstrating how to use them effectively in practice.

Kubernetes Fundamentals

Kubernetes is an open-source container orchestration platform that automates deployment, scaling, and management of containerized applications across clusters of machines. Instead of managing individual servers or virtual machines, developers describe desired application state through configuration files, and Kubernetes continuously works toward achieving that state.

Containers package applications with their dependencies in isolated environments. Docker is the most popular containerization platform, allowing you to package an application, Python runtime, libraries, and configuration into a single image. This image runs identically on laptops, development servers, staging environments, and production clouds.

Orchestration involves scheduling container execution on appropriate machines, managing storage, networking, security, and handling failures. A cluster might have 10, 100, or 1000 nodes (machines), and orchestration involves deciding which node should run which container, ensuring containers have needed resources, and recovering when containers or nodes fail.

Kubernetes provides these orchestration capabilities through declarative configuration—you describe your desired state through YAML files, and Kubernetes works to maintain that state. This differs from imperative approaches where you provide step-by-step instructions.

Pods: The Smallest Kubernetes Unit

A Pod is the smallest deployable unit in Kubernetes, running one or more containers. In simple cases, a Pod contains a single container—your application. However, Pods can contain multiple containers that are tightly coupled and share resources.

Single-Container Pods are most common:

apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest
    ports:
    - containerPort: 80

This configuration creates a Pod running a single nginx container. The image field specifies which container image to use. The ports section exposes port 80, making it accessible to other services.

Multi-Container Pods run multiple containers in the same Pod. This pattern is useful when containers are tightly coupled—for example, an application container and a logging sidecar container that reads logs and sends them to centralized logging. Containers in the same Pod share:

• Network namespace (they can communicate via localhost)
• Storage volumes (they can access the same files)
• Other system resources

Containers in a Pod shouldn't share these resources unless they're tightly coupled, because scaling becomes complicated. Generally, keep Pods single-container unless there's a specific reason for coupling.

Pod Lifecycle matters for development. Pods are ephemeral—they can be created and destroyed at any time. Applications shouldn't rely on Pods lasting indefinitely or retaining local storage. When a Pod crashes, Kubernetes creates a new one, but the new Pod starts fresh without the previous Pod's data.

Services: Networking and Discovery

Kubernetes Services provide stable network endpoints for accessing Pods. Pods are ephemeral and their IP addresses change when Pods are recreated. Services abstract this volatility by providing a stable IP address and DNS name.

ClusterIP Services (the default type) expose Pods internally within the cluster. Other Pods can access the service by name (e.g., "my-service") or by the service's cluster IP address. ClusterIP Services don't expose applications outside the cluster.

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  type: ClusterIP
  selector:
    app: web
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

This Service provides access to Pods labeled with "app: web", listening on port 8080, and exposes them internally on port 80.

NodePort Services expose applications outside the cluster by opening ports on each node. Accessing the service from outside the cluster requires connecting to any node's IP address on the specified port. NodePort Services useful for small clusters or testing but not recommended for production applications.

LoadBalancer Services integrate with cloud provider load balancers (AWS ELB, Google Cloud Load Balancer, Azure Load Balancer). Creating a LoadBalancer Service automatically provisions a cloud load balancer and routes traffic to your Pods. This approach provides easy external access with automatic failover.

Service Discovery within Kubernetes uses DNS. When you create a Service, Kubernetes's DNS system automatically creates a DNS record. Other Pods can reach the service by its name (e.g., "web-service.default.svc.cluster.local"). This abstracts which specific Pods are running, allowing services to discover each other dynamically.

Deployments: Managing Application Instances

Deployments manage Pod replicas, handling creation, updates, and scaling. Rather than creating individual Pods, you create Deployments that ensure the desired number of Pod replicas are always running.

Basic Deployment Configuration:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: myapp:1.0
        ports:
        - containerPort: 8080

This Deployment ensures three Pods are running at all times. If any Pod crashes, Kubernetes creates a replacement. If you scale to 5 replicas, Kubernetes creates two additional Pods.

Rolling Updates allow updating applications with zero downtime. When you update the container image to "myapp:1.1", Kubernetes doesn't immediately replace all Pods. Instead, it:

1. Creates a new Pod with the new image
2. Routes traffic away from an old Pod
3. Terminates the old Pod
4. Repeats until all Pods run the new image

This rolling process ensures some Pods are always running, preventing service interruptions.

Scaling Deployments adjusts the number of replicas:

kubectl scale deployment web-deployment --replicas=10

This command increases replicas to 10. Kubernetes creates seven new Pods to match the desired state.

Resource Requests and Limits prevent Pods from consuming excessive resources. You can specify how much CPU and memory each Pod needs and its maximum usage:

containers:
- name: web
  image: myapp:1.0
  resources:
    requests:
      memory: "64Mi"
      cpu: "250m"
    limits:
      memory: "128Mi"
      cpu: "500m"

Kubernetes uses requests to schedule Pods on nodes with adequate available resources. Limits prevent Pods from exceeding these thresholds. If a Pod exceeds memory limit, Kubernetes terminates it.

StatefulSets and Persistent Storage

StatefulSets manage applications requiring stable network identities and persistent storage—databases, message queues, and distributed systems. Unlike Deployments where Pods are interchangeable, StatefulSet Pods have ordered, stable identities.

StatefulSet Pods have predictable names (e.g., "database-0", "database-1", "database-2") and persistent storage volumes that follow Pods even if they're rescheduled to different nodes. This predictability is essential for applications like databases where data integrity matters.

Persistent Volumes provide storage that persists across Pod restarts and rescheduling. PersistentVolumeClaims request storage from PersistentVolumes, abstracting underlying storage details. This allows Pods to request storage without knowing whether it's local disk, network storage, or cloud object storage.

Configuration Management

ConfigMaps store non-sensitive configuration data (connection strings to public services, feature flags, configuration files). ConfigMaps decouple configuration from container images, allowing the same image to be deployed in different environments with different configurations.

Secrets store sensitive data (database passwords, API keys, TLS certificates). Kubernetes encrypts Secrets at rest (when properly configured) and exposes them only to Pods that need them. At Viprasol, we always encrypt Secrets and implement strict RBAC policies controlling which services can access which Secrets.

Networking and Ingress

Network Policies control which Pods can communicate with which other Pods. By default, all Pods can communicate with all other Pods. Network policies restrict this, implementing security best practices like zero-trust networking.

Ingress exposes HTTP/HTTPS applications outside the cluster. Unlike Services which exist at the network layer, Ingress handles application-layer routing, allowing sophisticated routing rules:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: web-ingress
spec:
  rules:
  - host: example.com
    http:
      paths:
      - path: /api
        pathType: Prefix
        backend:
          service:
            name: api-service
            port:
              number: 80
      - path: /web
        pathType: Prefix
        backend:
          service:
            name: web-service
            port:
              number: 80

This Ingress routes requests to example.com/api to api-service and example.com/web to web-service, allowing multiple services to share a single external IP address.

Observability and Monitoring

Logs from containerized applications are typically written to stdout/stderr rather than files. Kubernetes captures these logs, making them available through kubectl logs commands or centralized logging systems (ELK Stack, Splunk, CloudWatch).

Metrics track resource usage, request rates, error rates, and custom application metrics. Prometheus is the de facto standard metrics platform, scraping metrics from applications and providing time-series storage and querying. Kubernetes clusters typically run Prometheus alongside applications.

Tracing tracks requests as they flow through systems. Distributed tracing tools like Jaeger and Datadog enable debugging complex microservice interactions by following a request from entry point through all services it touches.

Deployment Best Practices

Health Checks indicate whether Pods are healthy. Liveness probes detect when Pods should be restarted (they've deadlocked or crashed internally). Readiness probes indicate whether Pods are ready to receive traffic (they've finished initialization). Kubernetes automatically restarts unhealthy Pods and routes traffic only to ready ones.

Resource Limits and Requests are essential. Pods without resource requests can consume all available resources, starving other Pods. Pods without limits might consume excessive resources. Proper configuration ensures fair resource sharing and predictable performance.

Security Policies should restrict what containers can do. Containers shouldn't run as root when unnecessary. Pod Security Policies (or newer Pod Security Standards) enforce security baselines. Network policies restrict traffic. Role-Based Access Control (RBAC) limits which services can perform which operations.

At Viprasol, we implement these security practices across all deployments, ensuring applications are protected from common attack vectors.

Development Workflow

Local Development with Kubernetes is possible using Minikube or Docker Desktop's included Kubernetes. Developing locally allows testing before deploying to production, catching configuration errors early.

Continuous Integration/Continuous Deployment (CI/CD) automatically tests code, builds container images, and deploys to Kubernetes when code is committed. Tools like GitLab CI, GitHub Actions, or Jenkins automate this workflow, ensuring consistent, repeatable deployments.

Version Control for Kubernetes Manifests treats infrastructure as code. YAML configuration files describing Kubernetes resources are version controlled, audited, and reviewed like code. This practice provides change history and enables rollback if deployments cause problems.

Common Pitfalls and Solutions

Stateful Data in Containers causes loss when Pods restart. Containers are meant to be ephemeral. Data that matters should be stored in persistent volumes, databases, or external services.

Resource Requests Too High wastes resources and prevents scaling. Set realistic requests based on actual application needs, measured through monitoring.

No Health Checks leads to traffic being routed to unhealthy Pods. Implement liveness and readiness probes.

Insufficient Monitoring makes debugging production issues difficult. Invest in logging, metrics, and tracing from the beginning.

FAQ

What's the difference between Kubernetes and Docker? Docker packages applications in containers. Kubernetes orchestrates many containers across many machines. They're complementary—Docker is the packaging technology, Kubernetes is the orchestration platform.

Do I need Kubernetes for small applications? No, Kubernetes adds complexity that small applications don't benefit from. Single-server deployments or container services like AWS ECS work fine for simple cases. Consider Kubernetes when you need:

• Multi-server deployments
• Automatic scaling based on load
• Zero-downtime deployments
• Complex microservice architectures

How do I debug Kubernetes issues? kubectl provides powerful debugging tools:

• kubectl logs for viewing Pod logs
• kubectl describe for detailed resource information
• kubectl port-forward for accessing services locally
• kubectl exec for running commands inside containers

How much does Kubernetes cost? Kubernetes itself is free open-source software. Cloud Kubernetes services (AWS EKS, Google GKE, Azure AKS) charge for worker nodes (the machines running your containers). Costs depend on how many nodes you run and their size. Small production clusters typically cost $200-500/month, while larger ones cost thousands monthly.

How do I handle persistent data in Kubernetes? Use PersistentVolumes and StatefulSets for databases and similar stateful applications. For read-only data, use ConfigMaps or external storage services.

---

Related Services

At Viprasol, we provide comprehensive Kubernetes solutions:

• Cloud Solutions — Kubernetes cluster setup, optimization, and management
• Web Development — Building Kubernetes-native applications
• Trading Software — Deploying trading systems on Kubernetes infrastructure

External Resources

• Kubernetes Official Documentation
• Linux Foundation Kubernetes Training