Обновление развертывания, использующего том ReadWriteOnce, не будет выполнено при монтировании - PullRequest
Новая
       19

Обновление развертывания, использующего том ReadWriteOnce, не будет выполнено при монтировании

0 голосов
/ 23 января 2019

В моем развертывании используется пара томов, каждый из которых определен как ReadWriteOnce.

При применении развертывания к чистому кластеру модуль успешно создается.

Однако, если я обновлю свое развертывание (то есть обновим образ контейнера), то, когда новый модуль будет создан для моего развертывания, он всегда потерпит неудачу при монтировании тома: 

/Mugen$ kubectl get pods
NAME                            READY     STATUS              RESTARTS   AGE
my-app-556c8d646b-4s2kg         5/5       Running             1          2d
my-app-6dbbd99cc4-h442r         0/5       ContainerCreating   0          39m

/Mugen$ kubectl describe pod my-app-6dbbd99cc4-h442r
      Type     Reason                  Age                 From                                             Message
      ----     ------                  ----                ----                                             -------
      Normal   Scheduled               9m                  default-scheduler                                Successfully assigned my-app-6dbbd99cc4-h442r to gke-my-test-default-pool-671c9db5-k71l
      Warning  FailedAttachVolume      9m                  attachdetach-controller                          Multi-Attach error for volume "pvc-b57e8a7f-1ca9-11e9-ae03-42010a8400a8" Volume is already used by pod(s) my-app-556c8d646b-4s2kg
      Normal   SuccessfulMountVolume   9m                  kubelet, gke-my-test-default-pool-671c9db5-k71l  MountVolume.SetUp succeeded for volume "default-token-ksrbf"
      Normal   SuccessfulAttachVolume  9m                  attachdetach-controller                          AttachVolume.Attach succeeded for volume "pvc-2cc1955a-1cb2-11e9-ae03-42010a8400a8"
      Normal   SuccessfulAttachVolume  9m                  attachdetach-controller                          AttachVolume.Attach succeeded for volume "pvc-2c8dae3e-1cb2-11e9-ae03-42010a8400a8"
      Normal   SuccessfulMountVolume   9m                  kubelet, gke-my-test-default-pool-671c9db5-k71l  MountVolume.SetUp succeeded for volume "pvc-2cc1955a-1cb2-11e9-ae03-42010a8400a8"
      Normal   SuccessfulMountVolume   9m                  kubelet, gke-my-test-default-pool-671c9db5-k71l  MountVolume.SetUp succeeded for volume "pvc-2c8dae3e-1cb2-11e9-ae03-42010a8400a8"
      Warning  FailedMount             52s (x4 over 7m)    kubelet, gke-my-test-default-pool-671c9db5-k71l  Unable to mount volumes for pod "my-app-6dbbd99cc4-h442r_default(affe75e0-1edd-11e9-bb45-42010a840094)": timeout expired waiting for volumes to attach or mount for pod "default"/"my-app-6dbbd99cc4-h442r". list of unmounted volumes=[...]. list of unattached volumes=[...]

Какова лучшая стратегия для применения изменений в таком развертывании? Должен ли быть какой-то сбой в обслуживании, чтобы использовать те же постоянные тома? (Я не хотел бы создавать новые тома - данные должны поддерживать)

Ответы [ 3 ]

0 голосов
/ 30 января 2019

Вам нужно будет терпеть сбой здесь из-за режима доступа.Это приведет к удалению существующих модулей (размонтированию томов) перед созданием новых.

Стратегия развертывания - .spec.strategy.type - «Восстановить» поможет достичь этого: https://github.com/ContainerSolutions/k8s-deployment-strategies/blob/master/recreate/README.md

0 голосов
/ 10 июня 2019

Я закончил с лучшим решением, где все мои клиентские модули являются только читателями контента, и у меня есть независимый процесс CI, пишущий контент, я делаю следующее:

  • Из CI:Записать содержимое в корзину Google Cloud Storage: gs://my-storage, затем перезапустить все модули внешнего интерфейса
  • При определении развертывания я синхронизирую (загружаю) весь блок в энергонезависимое хранилище и обслуживаю его из файловой системы с наилучшей производительностью.

Как этого добиться: В образе внешнего интерфейса я добавил установочный блок gcloud из https://github.com/GoogleCloudPlatform/cloud-sdk-docker/blob/master/debian_slim/Dockerfile: 

ARG CLOUD_SDK_VERSION=249.0.0
ENV CLOUD_SDK_VERSION=$CLOUD_SDK_VERSION
ARG INSTALL_COMPONENTS
ENV PATH "$PATH:/opt/google-cloud-sdk/bin/"
RUN apt-get update -qqy && apt-get install -qqy \
        curl \
        gcc \
        python-dev \
        python-setuptools \
        apt-transport-https \
        lsb-release \
        openssh-client \
        git \
        gnupg \
    && easy_install -U pip && \
    pip install -U crcmod && \
    export CLOUD_SDK_REPO="cloud-sdk-$(lsb_release -c -s)" && \
    echo "deb https://packages.cloud.google.com/apt $CLOUD_SDK_REPO main" > /etc/apt/sources.list.d/google-cloud-sdk.list && \
    curl https://packages.cloud.google.com/apt/doc/apt-key.gpg | apt-key add - && \
    apt-get update && apt-get install -y google-cloud-sdk=${CLOUD_SDK_VERSION}-0 $INSTALL_COMPONENTS && \
    gcloud config set core/disable_usage_reporting true && \
    gcloud config set component_manager/disable_update_check true && \
    gcloud config set metrics/environment github_docker_image && \
    gcloud --version
VOLUME ["/root/.config"]

И в развертывании модуля frontend.yamlЯ добавил следующее lifecycle событие: 

...
spec:
  ...
  containers:
  ...
    lifecycle:
    postStart:
      exec:
       command: ["gsutil", "-m", "rsync", "-r", "gs://my-storage", "/usr/share/nginx/html"]

Чтобы «обновить» модули внешнего интерфейса при обновлении содержимого корзины, я просто запускаю следующее из моего CI:

kubectl set env deployment/frontend K8S_FORCE= date+% s``

0 голосов
/ 24 января 2019

Это похоже на ошибку из-за режима доступа ReadWriteOnce . Помните, что при обновлении развертывания создаются новые модули, а затем уничтожаются старые. Итак, возможно, новый модуль попытается смонтировать уже смонтированный том, и именно поэтому вы получаете это сообщение.

Вы пытались использовать том, который позволяет нескольким читателям / писателям? Вы можете увидеть список текущих томов в документации Kubernetes Volumes .

...