EKS — Pod имеет несвязанные немедленные претензии PersistentVolumeClaims в экземплярах t2.large (t2.large, ОС Bottlerocket)

я просмотрел несколько решений, но не смог найти ответ, поэтому я пытаюсь запустить набор с отслеживанием состояния в кластере, но модуль не запускается из-за несвязанного требования. Я использую машины t2.large с хостами типа Bottlerocket.

kubectl получить события

28m         Warning   FailedScheduling         pod/carabbitmq-0                              pod has unbound immediate PersistentVolumeClaims (repeated 3 times)
28m         Normal    Scheduled                pod/carabbitmq-0                              Successfully assigned default/carabbitmq-0 to ip-x.compute.internal
28m         Normal    SuccessfulAttachVolume   pod/carabbitmq-0                              AttachVolume.Attach succeeded for volume "pvc-f6e8ec20-4bc1-4539-8d11-2dd1b3dbd4d7"
28m         Normal    Pulled                   pod/carabbitmq-0                              Container image "busybox:1.30.1" already present on machine

kubectl получить pv,pvc + описать

NAME                                      STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/data-carabbitmq-0   Bound    pvc-f6e8ec20-4bc1-4539-8d11-2dd1b3dbd4d7   30Gi       RWO            gp2            12m

NAME                                                        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                        STORAGECLASS   REASON   AGE
persistentvolume/pvc-f6e8ec20-4bc1-4539-8d11-2dd1b3dbd4d7   30Gi       RWO            Retain           Bound    rabbitmq/data-carabbitmq-0   gp2                     12m

опишите пв:

Name:              pvc-f6e8ec20-4bc1-4539-8d11-2dd1b3dbd4d7
Labels:            failure-domain.beta.kubernetes.io/region=eu-west-1
                   failure-domain.beta.kubernetes.io/zone=eu-west-1b
Annotations:       kubernetes.io/createdby: aws-ebs-dynamic-provisioner
                   pv.kubernetes.io/bound-by-controller: yes
                   pv.kubernetes.io/provisioned-by: kubernetes.io/aws-ebs
Finalizers:        [kubernetes.io/pv-protection]
StorageClass:      gp2
Status:            Bound
Claim:             rabbitmq/data-carabbitmq-0
Reclaim Policy:    Retain
Access Modes:      RWO
VolumeMode:        Filesystem
Capacity:          30Gi
Node Affinity:     
  Required Terms:  
    Term 0:        failure-domain.beta.kubernetes.io/zone in [eu-west-1b]
                   failure-domain.beta.kubernetes.io/region in [eu-west-1]
Message:           
Source:
    Type:       AWSElasticBlockStore (a Persistent Disk resource in AWS)
    VolumeID:   aws://eu-west-1b/vol-xx
    FSType:     ext4
    Partition:  0
    ReadOnly:   false
Events:         <none>

описание ПВХ:

Name:          data-carabbitmq-0
Namespace:     rabbitmq
StorageClass:  gp2
Status:        Bound
Volume:        pvc-f6e8ec20-4bc1-4539-8d11-2dd1b3dbd4d7
Labels:        app=rabbitmq-ha
               release=rabbit-mq
Annotations:   pv.kubernetes.io/bind-completed: yes
               pv.kubernetes.io/bound-by-controller: yes
               volume.beta.kubernetes.io/storage-provisioner: kubernetes.io/aws-ebs
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:      30Gi
Access Modes:  RWO
VolumeMode:    Filesystem
Mounted By:    carabbitmq-0
Events:
  Type    Reason                 Age   From                         Message
  ----    ------                 ----  ----                         -------
  Normal  ProvisioningSucceeded  36m   persistentvolume-controller  Successfully provisioned volume pvc-f6e8ec20-4bc1-4539-8d11-2dd1b3dbd4d7 using kubernetes.io/aws-ebs

Тип хранилища — gp2.

Name:                  gp2
IsDefaultClass:        Yes
Annotations:           storageclass.kubernetes.io/is-default-class=true
Provisioner:           kubernetes.io/aws-ebs
Parameters:            encrypted=true,type=gp2
AllowVolumeExpansion:  <unset>
MountOptions:
  debug
ReclaimPolicy:      Retain
VolumeBindingMode:  Immediate
Events:             <none>

Я не уверен, что мне не хватает, та же конфигурация работала, пока я не переключился на тип «t» EC2.

Можете ли вы отредактировать вопрос, включив в него спецификацию YAML для StatefulSet, который вы отправляете в кластер, и любые другие важные детали для минимального воспроизводимого примера?

David Maze 26.12.2020 19:43

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

ArielB 27.12.2020 13:14

@ArielB, можете ли вы предоставить свое решение с описанием в качестве ответа? Это может помочь другим пользователям с похожей проблемой.

PjoterS 28.12.2020 10:32

Готово, надеюсь кому-нибудь поможет

ArielB 30.12.2020 15:51
Развертывание модели машинного обучения с помощью Flask - Angular в Kubernetes
Развертывание модели машинного обучения с помощью Flask - Angular в Kubernetes
Kubernetes - это портативная, расширяемая платформа с открытым исходным кодом для управления контейнерными рабочими нагрузками и сервисами, которая...
0
4
249
1
Перейти к ответу Данный вопрос помечен как решенный

Ответы 1

Ответ принят как подходящий

Итак, это было странно, но у меня был какой-то зонд готовности, который не прошел проверку работоспособности, я думал, что это было из-за того, что том был неправильно смонтирован.

Проверка работоспособности в основном выполняла некоторый запрос к локальному хосту, с которым у нее были проблемы (не знаю, почему) - изменение на 127.0.0.1 сделало проверку успешной, а затем ошибка объема исчезла.

Итак, если у вас есть эта странная проблема (тома были смонтированы, но вы все еще получаете эту ошибку) - проверьте зонды модуля.

Другие вопросы по теме