thatmlopsguy commented on PR #24:
URL: https://github.com/apache/tika-helm/pull/24#issuecomment-3152392664
Example:
```
topologySpreadConstraints:
- maxSkew: 1
topologyKey: kubernetes.io/hostname
whenUnsatisfiable: DoNotSchedule
labelSelector:
matchLabels:
app.kubernetes.io/name: tika-helm
app.kubernetes.io/instance: my-release
- maxSkew: 1
topologyKey: topology.kubernetes.io/zone
whenUnsatisfiable: ScheduleAnyway
labelSelector:
matchLabels:
app.kubernetes.io/name: tika-helm
app.kubernetes.io/instance: my-release
```
First Constraint (Node-level distribution):
- maxSkew: 1: Maximum allowed difference in pod count between any two nodes
- topologyKey: kubernetes.io/hostname: Distribute pods across different
nodes (hostnames)
- whenUnsatisfiable: DoNotSchedule: If constraint can't be satisfied, don't
schedule the pod
- labelSelector: Only consider pods with these labels when calculating
distribution
Second Constraint (Zone-level distribution):
- maxSkew: 1: Maximum allowed difference in pod count between any two zones
- topologyKey: topology.kubernetes.io/zone: Distribute pods across different
availability zones
- whenUnsatisfiable: ScheduleAnyway: If constraint can't be satisfied,
schedule anyway (soft constraint)
- labelSelector: Same label selector to identify relevant pods
Real-world Scenarios
Scenario 1: 3 Replicas, 3 Nodes
With maxSkew: 1 and topologyKey: kubernetes.io/hostname:
✅ Good: Node1(1 pod), Node2(1 pod), Node3(1 pod) - perfectly balanced
(maxSkew=0)
❌ Violates:: Node1(2 pods), Node2(1 pod), Node3(0 pods) - maxSkew=2
❌ Violates: Node1(0 pods), Node2(3 pods), Node3(0 pods) - maxSkew=3
Scenario 2: Multi-Zone Deployment with 6 replicas across 3 zones:
✅ Good: Zone-A(2), Zone-B(2), Zone-C(2) - maxSkew=0
❌ Violates: Zone-A(3), Zone-B(2), Zone-C(1) - maxSkew=2
❌ Violates: Zone-A(4), Zone-B(1), Zone-C(1) - maxSkew=3
Benefits for Tika Deployment
- High Availability: If one node/zone fails, other instances continue running
- Load Distribution: Prevents all pods from running on the same node
- Resource Utilization: Better use of cluster resources across nodes/zones
- Fault Tolerance: Reduces blast radius of infrastructure failures
Configuration Options
DoNotSchedule: Hard constraint - pod won't be scheduled if constraint is
violated
ScheduleAnyway: Soft constraint - scheduler prefers to satisfy but will
schedule anyway if needed
This makes your Tika deployment more resilient and better distributed across
your Kubernetes cluster infrastructure.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: dev-unsubscr...@tika.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
