A media platform producing visual explainers for life and career growth.
GROWTH FEELS brings short, sharp, smarter visuals, mental models, and real life tools
First edition of the video and newsletter out tomorrow.
Grow wider. Think better. Handle life with clarity.

🛠️ TOOL OF THE DAY

terranetes controller - Manages the lifecycle of an OpenTofu or Terraform resource, allowing developers to self-serve dependencies in a controlled manner.

🧠 USE CASE

Kubernetes Pod vs Container Security Contexts

For someone new to Kubernetes Security Context, it’s what lets you control which user your containers run as and how they access the file system. Think of it like setting Linux user permissions, but now, inside a Kubernetes cluster.

You can apply it:

Pod level: Affects all containers in the pod.
Container level: Set individually per container and overrides pod level settings.
Pod + Container: Uses pod level defaults unless a container explicitly overrides them.

Let’s walk through the three types using real world situations.

1. Pod level Security Context

spec:
  securityContext:
    runAsUser: 3000
    fsGroup: 4000

This setting is inherited by all containers unless overridden at container level. Useful when all containers share the same user or group ID context.

Don’t assume it applies everywhere. If a container explicitly defines its own runAsUser, it will take precedence.

Use case: A log processor pod where both Fluentd and a custom metrics container access shared volumes, and you want them to operate under the same user and file group.

2. Container level Security Context

containers:
  - name: app-container
    securityContext:
      runAsUser: 3000
  - name: log-container
    securityContext:
      runAsUser: 5000

Each container has its own runAsUser. This is precise and flexible and ideal when containers need different privileges.

Note: Container level security context does not use any pod level runAsUser. Define all required security fields explicitly per container if you skip pod level.

Use case: A main Redis app container and a sidecar logging container, they serve different functions, so they should run under different OS users for audit and isolation.

3. Pod + Container – With Override

spec:
  securityContext:
    runAsUser: 3000
  containers:
    - name: app-container
      securityContext:
        runAsUser: 5000

Here, app-container overrides the pod level value. Only containers without their own setting will fall back to the pod-level configuration.

In mixed setups, audit security context at container level first. What’s defined there always wins.

Use case: You set a default runAsUser for consistency, but need a specific container to run as root (e.g., an init container performing privileged setup).

My 2 cents:

Use Pod level when all containers share the same identity.
Use Container level for fine grained privilege control.
Container level always overrides Pod level (know what takes effect).

No one is immune to OOM, throttling alerts and k8s clusters downtime.

We brought PERFECTSCALE, the best Automated Kubernetes Optimization and Management Platform that can Continuously and autonomously optimize your K8s environment for peak performance at the lowest possible cost.

✅ Install in minutes

✅ Get instant actionable insights

✅ Free for up to 200K vCPU Hours!

Try for free now!

Kubernetes Ingress Vs Gateway API 👇
Most Kubernetes deployments today use Ingress to expose HTTP(S) traffic.
It works, but it has notable caveats:
Tied to HTTP
Cluster scoped
Limited Extensibility
No Fine grained Routing Control
and so on.,
If haven’t explored the
— Govardhana Miriyala Kannaiah (@govardhana_mk)
3:00 PM • Mar 26, 2025

Looking to promote your company, product, service, or event to 42,000+ Cloud Native Professionals? Let's work together.