2
votes

La mise à jour d'un déploiement qui utilise un volume ReadWriteOnce échouera lors du montage

Mon déploiement utilise quelques volumes, tous définis comme ReadWriteOnce .

Lors de l'application du déploiement à un cluster propre, le pod est créé avec succès.

Cependant, si je mets à jour mon déploiement (c'est-à-dire que je mets à jour l'image du conteneur), lorsqu'un nouveau pod est créé pour mon déploiement, il échouera toujours lors du montage du volume:

/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=[...]

Quelle est la meilleure stratégie pour appliquer des modifications à un tel déploiement alors? Devra-t-il y avoir une interruption de service pour utiliser les mêmes volumes de persistance? (Je ne voudrais pas créer de nouveaux volumes - les données devraient être conservées)

kubernetes google-kubernetes-engine kubernetes-deployment kubernetes-pvc

0 commentaires

3 Réponses :

-1
votes

Cela semble être une erreur en raison de ReadWriteOnce mode d'accès. N'oubliez pas que lorsque vous mettez à jour un déploiement, de nouveaux pods sont créés, puis les plus anciens sont supprimés. Alors, peut-être que le nouveau pod essaiera de monter un volume déjà monté et c'est pourquoi vous recevez ce message.

Avez-vous essayé d'utiliser un volume qui autorise plusieurs lecteurs / écrivains? Vous pouvez voir la liste des volumes actuels dans la documentation Kubernetes Volumes .

1 commentaires

Je pensais que c'était la raison de cette erreur. J'utilise gcePersistentDisk qui ne permet que RWO. Je ne peux pas croire que personne d'autre n'utilise RWO et n'a pas rencontré ce problème

6
votes

Vous devrez tolérer une panne ici, en raison du mode d'accès. Cela supprimera les pods existants (démontage des volumes) avant d'en créer de nouveaux.

Une stratégie de déploiement - .spec.strategy.type - de «Recreate» aidera à atteindre cet objectif: https://github.com/ContainerSolutions/k8s-deployment-strategies/blob/master/recreate/README.md

1 commentaires

Existe-t-il une approche différente dans GKE pour obtenir des volumes inscriptibles sans avoir besoin de recréer les déploiements?

0
votes

J'ai terminé avec une meilleure solution, où tous mes pods clients ne sont que des lecteurs du contenu, et j'ai un processus CI indépendant qui rédige le contenu, je fais ce qui suit:

Depuis CI: rédigez du contenu dans un bucket Google Cloud Storage: gs: // my-storage , puis redémarrez tous les pods frontend
Lors de la définition du déploiement, je synchronise (télécharge) l'intégralité du bucket avec le stockage volatile du pod et le sers à partir du système de fichiers avec les meilleures performances.

Comment y parvenir: Sur l'image du docker frontal, j'ai ajouté le bloc d'installation gcloud de https : //github.com/GoogleCloudPlatform/cloud-sdk-docker/blob/master/debian_slim/Dockerfile :

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

Et dans le déploiement du pod frontend.yaml J'ai ajouté l'événement lifecycle suivant:

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"]

Pour "actualiser" les pods frontend lorsque le contenu du bucket est mis à jour, je lancez simplement ce qui suit depuis mon CI:

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

0 commentaires