DEV Community

Syed Omair
Syed Omair

Posted on

Creating Pods Without Deployment or Service: The Bare-Metal Kubernetes Experience

#kubernetes

Introduction

In Kubernetes, while Deployments and Services are the recommended approach for managing applications, there are legitimate scenarios where you might want to create a Pod directly without these abstractions. This "bare-metal" approach to Pod management gives you maximum control but comes with important trade-offs. Let's explore when, why, and how to use standalone Pods in Kubernetes.

Creating a Standalone Pod: Basic Examples

Example 1: The Simplest Pod Definition

# simple-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: standalone-nginx
  labels:
    app: nginx
spec:
  containers:
  - name: nginx-container
    image: nginx:latest
    ports:
    - containerPort: 80
Enter fullscreen mode Exit fullscreen mode

Create and verify the pod:

kubectl apply -f simple-pod.yaml
kubectl get pods
kubectl describe pod standalone-nginx
Enter fullscreen mode Exit fullscreen mode

Example 2: A Batch Job Pod (Without Job Controller)

# batch-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: data-processor
spec:
  restartPolicy: OnFailure  # Note: Not "Always"
  containers:
  - name: processor
    image: busybox
    command: ["/bin/sh"]
    args: ["-c", "echo 'Processing data...'; sleep 30; echo 'Done!'"]
Enter fullscreen mode Exit fullscreen mode

Create and verify the pod:

kubectl apply -f batch-pod.yaml
kubectl get pods
kubectl describe pod data-processor
Enter fullscreen mode Exit fullscreen mode

Why Create Pods Without Deployments or Services?

1. One-Off Tasks and Ephemeral Workloads

# cleanup-job.yaml
apiVersion: v1
kind: Pod
metadata:
  name: temp-cleanup
spec:
  restartPolicy: Never  # We don't want this to restart
  containers:
  - name: cleaner
    image: busybox
    command: ["/bin/sh"]
    args: ["-c", "rm -rf /tmp/old-files/*"]
Enter fullscreen mode Exit fullscreen mode

Use Case: Cleaning up temporary files, running database migrations, or executing a single batch operation where automatic restart would be harmful.

2. Debugging and Troubleshooting

# network-debug-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: network-tester
spec:
  containers:
  - name: tester
    image: nicolaka/netshoot  # Popular network troubleshooting image
    command: ["sleep", "infinity"]
Enter fullscreen mode Exit fullscreen mode

Create and debug:

kubectl apply -f network-debug-pod.yaml
kubectl exec -it network-tester -- bash
Enter fullscreen mode Exit fullscreen mode

Now you can run curl, dig, ping, tcpdump, etc.
Advantage: Quick spin-up without deployment overhead. Perfect for temporary diagnostic tools.

3. Init Containers (Within Pods)

# init-container-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: app-with-init
spec:
  containers:
  - name: main-app
    image: myapp:latest
    ports:
    - containerPort: 8080
  initContainers:
  - name: init-db
    image: busybox
    command: ['sh', '-c', 'until nslookup database-service; do echo waiting for database; sleep 2; done;']
Enter fullscreen mode Exit fullscreen mode

Note: Init containers are part of Pod spec, not separate resources.

4. Learning and Experimentation

# learning-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: learning-experiment
spec:
  containers:
  - name: experiment
    image: nginx
    env:
    - name: LEARNING_MODE
      value: "true"
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m"
Enter fullscreen mode Exit fullscreen mode

Benefit: Direct exposure to Pod lifecycle without controller abstractions.

5. Specialized Node Operations

# node-specific-pod.yaml
apiVersion: v1
kind: Pod
metadata:
  name: node-maintenance
spec:
  nodeName: node-01  # Direct node assignment
  containers:
  - name: maintenance
    image: ubuntu
    command: ["/bin/bash"]
    args: ["-c", "apt-get update && apt-get upgrade -y"]
Enter fullscreen mode Exit fullscreen mode

Use Case: Node-specific maintenance tasks where you need to target a specific node.

Advantages of Standalone Pods

  1. Simplicity and Clarity
  2. Direct Control
  3. Quick Iteration
  4. Explicit Failure Handling
  5. Resource Efficiency
    • No deployment controller overhead:
    • No reconciliation loops
    • No status tracking
    • Less etcd traffic

Disadvantages and Production Concerns

  1. No Self-Healing
  2. No Rolling Updates
  3. No Scaling Capabilities
  4. Limited Service Integration
  5. Manual Lifecycle Management

When to Use (and When Not to Use)

Use Standalone Pods When:

  • Temporary debugging or troubleshooting
  • One-off batch jobs (though consider Job resource)
  • Learning and experimentation
  • Init containers within other pods
  • Simple, stateless utilities with no HA requirements
  • Node-specific operations requiring direct assignment

Avoid Standalone Pods When:

  • Production applications requiring high availability
  • Services needing load balancing
  • Applications requiring zero-downtime updates
  • Workloads that need automatic scaling
  • Stateful applications (use StatefulSet instead)
  • Long-running services accessed by other pods

Conclusion

Standalone Pods in Kubernetes serve an important niche in the container orchestration ecosystem. They provide the raw, unabstracted access to container execution that's essential for debugging, one-off tasks, and learning. However, they lack the robustness and automation features that make Kubernetes powerful for production workloads.

Key Takeaways:
Use standalone Pods strategically for their intended purposes
Understand the trade-offs between control and automation
Know when to graduate to Deployments and Services
Always clean up temporary standalone Pods
Document the purpose of each standalone Pod for team clarity

Remember: Kubernetes is about abstraction and automation. While standalone Pods give you escape hatches from these abstractions, they should be the exception rather than the rule in a well-architected Kubernetes environment.

Top comments (0)