У меня есть вопрос о поведении Kubernetes при работе с приложением тома на новом узле после переназначения модуля.
Обычное поведение, которое мы имеем в нашем кластере:
Узел n1 становится недоступным
Модуль A с томом v1 перенесен на узел n2
Том v1 равенбудучи отсоединенным от узла n1, это займет несколько секунд
Кублет на узле n2 пытается подключить том v1 к модулю A
Потому что томv1 еще не отсоединен от узла n1, вызов Attach завершается неудачно с:
Sep 27 11:43:24 node n2 kubelet-wrapper[787]: E0927 11:43:24.794713 787 nestedpendingoperations.go:263] Operation for "\"kubernetes.io/cinder/volume_v1_id\"" failed. No retries permitted until 2018-09-27 11:43:25.294659022 +0000 UTC m=+1120541.835247469 (durationBeforeRetry 500ms). Error: "AttachVolume.Attach failed for volume \"volume v1\" (UniqueName: \"kubernetes.io/cinder/volume_2_id\") from node \"node n2\" : disk volume_v2_id path /dev/vdc is attached to a different instance (pod node n1)"
После этой ошибки Attach, кублет будет вечно пытаться смонтировать том v1 (который завершится неудачно, потому чтоТом не подключен)
Sep 27 11:43:26 node n2 kubelet-wrapper[787]: E0927 11:43:26.870106 787 attacher.go:240] Error: could not find attached Cinder disk "volume_v1_id" (path: ""): <nil>
Мой вопрос: почему k8s не пытается подключиться снова перед попыткой монтировать?
Проблема здесь в том, что когдаотсоединение делается достаточно быстро, у нас нет никаких проблем, но если отсоединение еще несделано, когда Attach вызван kubelet, мы застряли.
При копании в коде кажется, что поведение WaitForAttachAndMount.Это будет: 1 / Try Attach 2 / независимо от результата подключения, цикл на Try Mount.
Если ожидаемое поведение будет 1 / loop на Try Attach 2 / Если в какой-то момент Attach является успешным, циклon Try Mount?
Этот вопрос относится к https://github.com/kubernetes/kubernetes/issues/69158