Нужно ли повторять жесткие требования к кубинетам, если постоянный том удаляется и воссоздается?

Question

У меня есть следующий pvc (Persistent Volume Claim):

piVersion: v1 
kind: PersistentVolumeClaim 
metadata: 
    name: test-claim-web 
spec: 
    accessModes: 
    - ReadWriteOnce 
    resources: 
    requests: 
     storage: 10Gi 

и Google Cloud поддерживаемому pv (Persistent объем):

apiVersion: v1 
kind: PersistentVolume 
metadata: 
    name: test-pv-1 
spec: 
    capacity: 
    storage: 10Gi 
    accessModes: 
    - ReadWriteOnce 
    gcePersistentDisk: 
    pdName: test-1 
    fsType: ext4 

и диск в Google облако, которое существует.

Если я создаю сначала pv и после pvc, kubectl get pvc,pv покажет:

NAME        STATUS        VOLUME   CAPACITY  ACCESSMODES    AGE 
test-claim-web      Bound         test-pv-1   10Gi   RWO      15s 
NAME        CAPACITY        ACCESSMODES  STATUS  CLAIM     REASON AGE 
test-pv-1       10Gi         RWO    Bound  default/test-claim-web    25s 

Но если удалить и воссоздать pv, kubectl get pvc,pv покажет:

NAME        STATUS        VOLUME   CAPACITY  ACCESSMODES    AGE 
test-claim-web      Bound         test-pv-1   10Gi   RWO      3m 
NAME        CAPACITY        ACCESSMODES  STATUS  CLAIM     REASON AGE 
test-pv-1       10Gi         RWO    Available          18s 

• Почему pvc еще Bound?
• Не так ли связывается pvc (повторно)? (Я также заметил, что создание pv после pvc делает pvc ждать вечно с Pending статусом.)

Я использую следующую версию Kubernetes:

Client Version: version.Info{Major:"1", Minor:"2", GitVersion:"v1.2.4", GitCommit:"3eed1e3be6848b877ff80a93da3785d9034d0a4f", GitTreeState:"clean"} 
Server Version: version.Info{Major:"1", Minor:"2", GitVersion:"v1.2.4", GitCommit:"3eed1e3be6848b877ff80a93da3785d9034d0a4f", GitTreeState:"clean"} 

Answer 1

, если удалить и заново ФВ , kubectl get pvc, pv покажет [bound]. Почему все еще привязан к пвх?

Это ошибка в Kubernetes 1.2, она будет исправлена ​​в 1.3. И PV, и PVC должны в конечном итоге получить Bound.

Однако удаление связанного PV - очень плохая идея, так как ПВХ может использоваться в работающем контейнере, и стручок внезапно теряет под собой хранилище. Вы никогда не должны касаться связанных PV!

Я также заметил, что создание ФВ после пвх делает пвх ждать навсегда Pending статуса

Он не будет ждать вечно, она должна получить связаны через 10 минут. Используйте kube-controller-manager --pvclaimbinder-sync-period=15s, чтобы сократить его до 15 секунд. Опять же, это будет лучше в Kubernetes 1.3, 15 секунд будет по умолчанию там.