When a web request starts work that cannot finish inline, the application can place a task on a queue and respond without doing the work itself. A worker Pod is a continuously running workload instance that takes a queued input, performs the task, and waits for another. These Pods need not be exposed through a Service: they consume tasks rather than serve incoming requests. section 10.1 section 10.1.1
A small task-processing deployment has three parts:
- A producer adds tasks. In the example, a web application would enqueue them; a script stands in for it. section 10.1.1
- Redis holds pending tasks. RPUSH adds to the back of the queue; BLPOP takes from the front and waits when the queue is empty, avoiding a busy-wait loop. section 10.1.1
- A Deployment keeps worker Pods running. Its replica count controls how many Pods can take tasks, and the Deployment can be updated with new container versions. section 10.1
Two workers calculating pi
A Python worker connects to Redis using REDIS_HOST, blocks on the task queue, interprets each task as an iteration count, calculates pi, and prints the result. A Deployment starts two replicas. Run the task-adding script, then inspect worker logs to see tasks being taken and results printed. The example demonstrates consumption and processing; its worker prints outputs rather than showing a separate result store. section 10.1.1
Listing 10.2 Chapter10/pi_worker/pi_worker.py
import os
import redis
from pi import *
redis_host = os.environ.get('REDIS_HOST') #1
assert redis_host != None
r = redis.Redis(host=redis_host, #2
port='6379', #2
decode_responses=True) #2
print("starting")
while True:
task = r.blpop('queue:task') #3
iterations = int(task[1])
print("got task: " + str(iterations))
pi = leibniz_pi(iterations) #4
print (pi)
The worker loop shows where a Pod waits for a task and where it performs the calculation. section 10.1.1
Listing 10.5 Chapter10/10.1.1_TaskQueue/deploy_worker.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
name: pi-worker
spec:
replicas: 2
selector:
matchLabels:
pod: pi
template:
metadata:
labels:
pod: pi
spec:
containers:
- name: pi-container
image: docker.io/wdenniss/pi_worker:1 #1
env:
- name: REDIS_HOST
value: redis-0.redis-service #2
- name: PYTHONUNBUFFERED #3
value: "1"
The Deployment manifest shows two worker replicas and the Redis host setting they use. section 10.1.1
Scaling workers means choosing both Pod replicas and, where the application supports it, concurrent workers inside each Pod. Threads or forks can share memory and CPU efficiently, but packing too many workers into one Pod makes a Pod failure more costly. For 36 concurrent connections, two Pods with 18 workers each lose half their capacity if one Pod stops; six Pods with six workers each retain more capacity while keeping some internal concurrency. Choose a layout by asking how many workers users need and how many can be unavailable without a noticeable effect. section 5.2.4
For CPU-intensive tasks, a Horizontal Pod Autoscaler can adjust the Deployment’s replica count. The example targets 20% average utilization of requested CPU and permits two to ten Pods; adding tasks and checking Pods alongside the autoscaler makes the change visible. Replica scaling is not the same as increasing concurrency inside an existing Pod. section 10.1.3 section 5.2.4
In batch workloads, distinguish workers from coordinator Pods: coordinators schedule work; workers perform it and may come and go as capacity changes. If changes to worker nodes should not affect steadier coordinator nodes, node labels and selectors combined with taints and tolerations can place the roles on separate node groups. section 8.1.4
