Kubernetes: поведение при сбое вызова Attach.Должны ли мы повторить Прикрепить вечно, или мы должны Вечно? - PullRequest
0 голосов
/ 23 октября 2018

У меня есть вопрос о поведении Kubernetes при работе с приложением тома на новом узле после переназначения модуля.

Обычное поведение, которое мы имеем в нашем кластере:

  1. Узел n1 становится недоступным

  2. Модуль A с томом v1 перенесен на узел n2

  3. Том v1 равенбудучи отсоединенным от узла n1, это займет несколько секунд

  4. Кублет на узле n2 пытается подключить том v1 к модулю A

  5. Потому что том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)"
    
  6. После этой ошибки 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

1 Ответ

0 голосов
/ 24 октября 2018

На мой взгляд, это зависит от:

  1. Имеет смысл продолжать пытаться подключаться бесконечно, а не отказывать и пытаться монтировать бесконечно, если вы хотите создать поставщика томов (который может бытьEBS, Cinder, GCP, Ceph и т. Д.), Отвечающие за ответ на API присоединения.Может случиться так, что провайдер выполняет какое-то обслуживание, а API временно не работаютЭто если вы хотите сделать ваши системы более автоматизированными.

  2. Имеет смысл подключить -> не работать и монтировать бесконечно, если по причине вы хотите, чтобы пользователь вручную подключил том и имелпоследующее монтирование прошло успешно.На мой взгляд, это следует сделать опцией, а 1. должно быть по умолчанию.

...