Мягкая непринадлежность
Однако обычно нас больше заботит наличие достаточного числа реплик, чем их максимально равномерное распределение. Жесткое правило не совсем то, что нам надо в данной ситуации. Немного изменим его, превратив в мягкую непринадлежность:
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 1
podAffinityTerm:
labelSelector:
- matchExpressions:
- key: app
operator: In
values: ["server"]
topologyKey: kubernetes.io/hostname
kubectl get pods --selector app=demo
NAME READY STATUS RESTARTS AGE
demo-54df94b7b7-qgtc6 1/1 Running 1 22h
Теперь остановите Pod-объект с помощью следующей команды:
kubectl delete pods --selector app=demo
pod "demo-54df94b7b7-qgtc6" deleted
Снова выведите список pod-оболочек:
kubectl get pods --selector app=demo
NAME READY STATUS RESTARTS AGE
demo-54df94b7b7-hrspp 1/1 Running 0 5s
demo-54df94b7b7-qgtc6 0/1 Terminating 1 22h
Вы можете видеть, что оригинальная pod-оболочка останавливается (со статусом Terminating), но ее место уже занимает новая, которой всего пять секунд. Так работает цикл согласования.
Создав развертывание, вы сообщили Kubernetes о том, что pod-оболочка demo должна работать всегда. Система ловит вас на слове, и, даже если вы сами удалите этот Pod-объект, она посчитает, что вы наверняка ошиблись, и услужливо запустит замену.
Закончив экспериментировать с развертыванием, остановите и уничтожьте его с помощью такой команды:
kubectl delete all --selector app=demo
pod "demo-54df94b7b7-hrspp" deleted
service "demo" deleted
deployment.apps "demo" deleted
Этот процесс называют циклом согласования, поскольку он все время повторяется в попытке согласовать текущее состояние с желаемым.