kubectl get pods

kubectl describe pod

kubectl logs pod

Ans: Deploying additional Pods is the right approach. Deploying more containers is not right option because all the containers within the pod use same network and same resources. so when you add more containers, they still use the same resources in the pod.

Why adding more containers to pod usually doesn’t work

1. All containers in a Pod share resources of the Pod and node

   • You can technically give each container more CPU/RAM, but the Pod itself is scheduled onto a single node.
   • That means all containers compete for the same node resources, and Kubernetes cannot distribute them across other nodes.

2. Scaling containers in a Pod doesn’t improve load balancing

   • Requests hitting the Pod go to one network endpoint.
   • If your app is slow due to too many requests, adding more containers in the same Pod doesn’t split traffic.
   • All new containers in the same Pod are essentially invisible to the Service load balancer — the traffic still goes through the Pod’s single IP.

3. Fault tolerance gets worse

   • If the Pod fails, all containers die together.
   • Adding more containers increases risk of resource contention or a crash.

4. CPU/RAM limits and throttling

   • Even if you give each container a higher CPU/memory request, the Kubernetes scheduler may throttle them if the node cannot provide enough resources.

The right approach

Instead of adding containers inside the same Pod:

1. Add more Pods (Horizontal Pod Autoscaler)

   • Each Pod has your 3 containers.
   • Kubernetes can schedule Pods across nodes.
   • Service load balancer spreads traffic across all Pods.
   • You now actually scale horizontally.

2. Optional: Vertical Pod Scaling (less common)

   • Increase resources of existing Pod (CPU/RAM) using Vertical Pod Autoscaler.
   • Only useful if app is CPU/memory bound, but still doesn’t help with load balancing.

Rule of thumb:

More containers in the same Pod = doesn’t increase throughput for stateless apps.

More Pods = scales properly and balances traffic across nodes.

run kubectl describe deployment deployment-name command

under rollingupdatestrategy value we can see how many pods can be updated in percentage values

edit the running deployment: kubectl edit deployment frontend

Under the strategy section, change type to recreate and remove any blocks for rollingupdate

A Service or ReplicaSet is linked to Pods using labels and selectors.

Pods are assigned labels in their metadata, and the Service or ReplicaSet defines selectors that match those labels. When the labels match the selectors, Kubernetes automatically connects the Service or ReplicaSet to the appropriate Pods.

Explanation:
Labels act as identifiers for Pods, while selectors are used by Services and ReplicaSets to find and manage the correct set of Pods. This matching mechanism allows Kubernetes to dynamically associate resources without requiring manual connections.

Example:

• Pod labels:

1
2
3

metadata:
  labels:
    app: my-app

• Service selector:

1
2
3

spec:
  selector:
    app: my-app

• ReplicaSet selector:

1
2
3
4

spec:
  selector:
    matchLabels:
      app: my-app

As long as the labels match the selectors, the Service and ReplicaSet will correctly identify and manage the Pods.