mirror of
https://github.com/ChristianLight/tutor.git
synced 2024-12-12 22:27:47 +00:00
78424776b6
When a Pod associated with a Deployment is updated (for example, due to a change to its ConfigMap, or an updated image reference), Kubernetes uses a ReplicaSet to spin up a Pod with the new configuration, and once it is up, it tears down the old one. In case of the Caddy Deployment, this is complicated by the fact that it uses a Persistent Volume Claim (PVC), whose corresponding volume uses a Read/Write-Once (RWO) configuration. This means that it can only be used by multiple Pods if all those Pods all run on the same Kubernetes worker node. In order to enable rolling upgrades for the Caddy Deployment, we need to ensure that its replacement Pod is scheduled on the same node as the original Pod. Thus, add a pod affinity rule that will force exactly that behavior. Reference: https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/ The other Tutor services that use volumes (MySQL, Redis, Elasticsearch and MongoDB) do not need this fix, since they all use the "Recreate" deployment strategy: their Pods are all automatically torn down before being replaced. This strategy is not needed for Caddy, and using a pod affinity rule is less disruptive to the learner experience. |
||
|---|---|---|
| .. | ||
| commands | ||
| hooks | ||
| plugins | ||
| templates | ||
| __about__.py | ||
| __init__.py | ||
| bindmounts.py | ||
| config.py | ||
| env.py | ||
| exceptions.py | ||
| fmt.py | ||
| images.py | ||
| interactive.py | ||
| jobs.py | ||
| serialize.py | ||
| types.py | ||
| utils.py | ||