亚洲视频二区_亚洲欧洲日本天天堂在线观看_日韩一区二区在线观看_中文字幕不卡一区

目錄

• StatefulSet 對存儲狀態的管理機制
• 第一步：定義一個 PVC，聲明想要的 Volume 的屬性
• 第二步：在應用的 Pod 中，聲明使用這個 PVC
• 常見的 PV 對象的 YAML 文件

StatefulSet 對存儲狀態的管理機制

這個機制，主要使用的是一個叫作 Persistent Volume Claim 的功能。

要在一個 Pod 里聲明 Volume，只要在 Pod 里加上 spec.volumes 字段即可。然后，你就可以在這個字段里定義一個具體類型的 Volume 了，比如：hostPath。

可是，你有沒有想過這樣一個場景：如果你并不知道有哪些 Volume 類型可以用，要怎么辦呢？

更具體地說，作為一個應用開發者，我可能對持久化存儲項目（比如 Ceph、GlusterFS 等）一竅不通，也不知道公司的 Kubernetes 集群里到底是怎么搭建出來的，我也自然不會編寫它們對應的 Volume 定義文件。

這些關于 Volume 的管理和遠程持久化存儲的知識，不僅超越了開發者的知識儲備，還會有暴露公司基礎設施秘密的風險。

比如，下面這個例子，就是一個聲明了 Ceph RBD 類型 Volume 的 Pod：

apiVersion: v1
kind: Pod
metadata:
  name: rbd
spec:
  containers:
    - image: kubernetes/pause
      name: rbd-rw
      volumeMounts:
      - name: rbdpd
        mountPath: /mnt/rbd
  volumes:
    - name: rbdpd
      rbd:
        monitors:
        - '10.16.154.78:6789'
        - '10.16.154.82:6789'
        - '10.16.154.83:6789'
        pool: kube
        image: foo
        fsType: ext4
        readOnly: true
        user: admin
        keyring: /etc/ceph/keyring
        imageformat: "2"
        imagefeatures: "layering"

其一，如果不懂得 Ceph RBD 的使用方法，那么這個 Pod 里 Volumes 字段，你十有八九也完全看不懂。其二，這個 Ceph RBD 對應的存儲服務器的地址、用戶名、授權文件的位置，也都被輕易地暴露給了全公司的所有開發人員，這是一個典型的信息被“過度暴露”的例子。

這也是為什么，在后來的演化中，Kubernetes 項目引入了一組叫作 Persistent Volume Claim（PVC）和 Persistent Volume（PV）的 API 對象，大大降低了用戶聲明和使用持久化 Volume 的門檻。

舉個例子，有了 PVC 之后，一個開發人員想要使用一個 Volume，只需要簡單的兩步即可。

第一步：定義一個 PVC，聲明想要的 Volume 的屬性

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: pv-claim
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi

可以看到，在這個 PVC 對象里，不需要任何關于 Volume 細節的字段，只有描述性的屬性和定義。比如，storage: 1Gi，表示我想要的 Volume 大小至少是 1 GiB；accessModes: ReadWriteOnce，表示這個 Volume 的掛載方式是可讀寫，并且只能被掛載在一個節點上而非被多個節點共享。

第二步：在應用的 Pod 中，聲明使用這個 PVC

apiVersion: v1
kind: Pod
metadata:
  name: pv-pod
spec:
  containers:
    - name: pv-container
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: pv-storage
  volumes:
    - name: pv-storage
      persistentVolumeClaim:
        claimName: pv-claim

可以看到，在這個 Pod 的 Volumes 定義中，我們只需要聲明它的類型是 persistentVolumeClaim，然后指定 PVC 的名字，而完全不必關心 Volume 本身的定義。

這時候，只要我們創建這個 PVC 對象，Kubernetes 就會自動為它綁定一個符合條件的 Volume。可是，這些符合條件的 Volume 又是從哪里來的呢？

答案是，它們來自于由運維人員維護的 PV（Persistent Volume）對象。

常見的 PV 對象的 YAML 文件

kind: PersistentVolume
apiVersion: v1
metadata:
  name: pv-volume
  labels:
    type: local
spec:
  capacity:
    storage: 10Gi
  rbd:
    monitors:
    - '10.16.154.78:6789'
    - '10.16.154.82:6789'
    - '10.16.154.83:6789'
    pool: kube
    image: foo
    fsType: ext4
    readOnly: true
    user: admin
    keyring: /etc/ceph/keyring
    imageformat: "2"
    imagefeatures: "layering"

可以看到，這個 PV 對象的 spec.rbd 字段，正是我們前面介紹過的 Ceph RBD Volume 的詳細定義。而且，它還聲明了這個 PV 的容量是 10 GiB。這樣，Kubernetes 就會為我們剛剛創建的 PVC 對象綁定這個 PV。

所以，Kubernetes 中 PVC 和 PV 的設計，實際上類似于“接口”和“實現”的思想。開發者只要知道并會使用“接口”，即：PVC；而運維人員則負責給“接口”綁定具體的實現，即：PV。

這種解耦，就避免了因為向開發者暴露過多的存儲系統細節而帶來的隱患。此外，這種職責的分離，往往也意味著出現事故時可以更容易定位問題和明確責任，從而避免“扯皮”現象的出現。

而 PVC、PV 的設計，也使得 StatefulSet 對存儲狀態的管理成為了可能。

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.9.1
        ports:
        - containerPort: 80
          name: web
        volumeMounts:
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
  - metadata:
      name: www
    spec:
      accessModes:
      - ReadWriteOnce
      resources:
        requests:
          storage: 1Gi

這次，我們為這個 StatefulSet 額外添加了一個 volumeClaimTemplates 字段。從名字就可以看出來，它跟 Deployment 里 Pod 模板（PodTemplate）的作用類似。也就是說，凡是被這個 StatefulSet 管理的 Pod，都會聲明一個對應的 PVC；而這個 PVC 的定義，就來自于 volumeClaimTemplates 這個模板字段。更重要的是，這個 PVC 的名字，會被分配一個與這個 Pod 完全一致的編號。

這個自動創建的 PVC，與 PV 綁定成功后，就會進入 Bound 狀態，這就意味著這個 Pod 可以掛載并使用這個 PV 了。

如果你還是不太理解 PVC 的話，可以先記住這樣一個結論：PVC 其實就是一種特殊的 Volume。只不過一個 PVC 具體是什么類型的 Volume，要在跟某個 PV 綁定之后才知道。關于 PV、PVC 更詳細的知識，我會在容器存儲部分做進一步解讀。

當然，PVC 與 PV 的綁定得以實現的前提是，運維人員已經在系統里創建好了符合條件的 PV（比如，我們在前面用到的 pv-volume）；或者，你的 Kubernetes 集群運行在公有云上，這樣 Kubernetes 就會通過 Dynamic Provisioning 的方式，自動為你創建與 PVC 匹配的 PV。

所以，我們在使用 kubectl create 創建了 StatefulSet 之后，就會看到 Kubernetes 集群里出現了兩個 PVC

可以看到，這些 PVC，都以“<PVC 名字 >-<StatefulSet 名字 >-< 編號 >”的方式命名，并且處于 Bound 狀態。

我們前面已經講到過，這個 StatefulSet 創建出來的所有 Pod，都會聲明使用編號的 PVC。比如，在名叫 web-0 的 Pod 的 volumes 字段，它會聲明使用名叫 www-web-0 的 PVC，從而掛載到這個 PVC 所綁定的 PV。

所以，我們就可以使用如下所示的指令，在 Pod 的 Volume 目錄里寫入一個文件，來驗證一下上述 Volume 的分配情況

for i in 0 1; do kubectl exec web-$i — sh -c 'echo hello $(hostname) > /usr/share/nginx/html/index.html'; done

如上所示，通過 kubectl exec 指令，我們在每個 Pod 的 Volume 目錄里，寫入了一個 index.html 文件。這個文件的內容，正是 Pod 的 hostname。比如，我們在 web-0 的 index.html 里寫入的內容就是 "hello web-0"。

此時，如果你在這個 Pod 容器里訪問“http://localhost”，你實際訪問到的就是 Pod 里 Nginx 服務器進程，而它會為你返回 /usr/share/nginx/html/index.html 里的內容。這個操作的執行方法如下所示：

$ for i in 0 1; do kubectl exec -it web-$i -- curl localhost; done
hello web-0
hello web-1

如果你使用 kubectl delete 命令刪除這兩個 Pod，這些 Volume 里的文件會不會丟失呢？

可以看到，正如我們前面介紹過的，在被刪除之后，這兩個 Pod 會被按照編號的順序被重新創建出來。而這時候，如果你在新創建的容器里通過訪問“http://localhost”的方式去訪問 web-0 里的 Nginx 服務

就會發現，這個請求依然會返回：hello web-0。也就是說，原先與名叫 web-0 的 Pod 綁定的 PV，在這個 Pod 被重新創建之后，依然同新的名叫 web-0 的 Pod 綁定在了一起。對于 Pod web-1 來說，也是完全一樣的情況。

這是怎么做到的呢？

其實，我和你分析一下 StatefulSet 控制器恢復這個 Pod 的過程，你就可以很容易理解了。

首先，當你把一個 Pod，比如 web-0，刪除之后，這個 Pod 對應的 PVC 和 PV，并不會被刪除，而這個 Volume 里已經寫入的數據，也依然會保存在遠程存儲服務里（比如，我們在這個例子里用到的 Ceph 服務器）。

此時，StatefulSet 控制器發現，一個名叫 web-0 的 Pod 消失了。所以，控制器就會重新創建一個新的、名字還是叫作 web-0 的 Pod 來，“糾正”這個不一致的情況。

需要注意的是，在這個新的 Pod 對象的定義里，它聲明使用的 PVC 的名字，還是叫作：www-web-0。這個 PVC 的定義，還是來自于 PVC 模板（volumeClaimTemplates），這是 StatefulSet 創建 Pod 的標準流程。

所以，在這個新的 web-0 Pod 被創建出來之后，Kubernetes 為它查找名叫 www-web-0 的 PVC 時，就會直接找到舊 Pod 遺留下來的同名的 PVC，進而找到跟這個 PVC 綁定在一起的 PV。

這樣，新的 Pod 就可以掛載到舊 Pod 對應的那個 Volume，并且獲取到保存在 Volume 里的數據。

通過這種方式，Kubernetes 的 StatefulSet 就實現了對應用存儲狀態的管理。

看到這里，你是不是已經大致理解了 StatefulSet 的工作原理呢？現在，我再為你詳細梳理一下吧。

首先，StatefulSet 的控制器直接管理的是 Pod。這是因為，StatefulSet 里的不同 Pod 實例，不再像 ReplicaSet 中那樣都是完全一樣的，而是有了細微區別的。比如，每個 Pod 的 hostname、名字等都是不同的、攜帶了編號的。而 StatefulSet 區分這些實例的方式，就是通過在 Pod 的名字里加上事先約定好的編號。

其次，Kubernetes 通過 Headless Service，為這些有編號的 Pod，在 DNS 服務器中生成帶有同樣編號的 DNS 記錄。只要 StatefulSet 能夠保證這些 Pod 名字里的編號不變，那么 Service 里類似于 web-0.nginx.default.svc.cluster.local 這樣的 DNS 記錄也就不會變，而這條記錄解析出來的 Pod 的 IP 地址，則會隨著后端 Pod 的刪除和再創建而自動更新。這當然是 Service 機制本身的能力，不需要 StatefulSet 操心。

最后，StatefulSet 還為每一個 Pod 分配并創建一個同樣編號的 PVC。這樣，Kubernetes 就可以通過 Persistent Volume 機制為這個 PVC 綁定上對應的 PV，從而保證了每一個 Pod 都擁有一個獨立的 Volume。

在這種情況下，即使 Pod 被刪除，它所對應的 PVC 和 PV 依然會保留下來。所以當這個 Pod 被重新創建出來之后，Kubernetes 會為它找到同樣編號的 PVC，掛載這個 PVC 對應的 Volume，從而獲取到以前保存在 Volume 里的數據。

以上就是k8s編排之StatefulSet知識點詳解二的詳細內容，更多關于k8s編排StatefulSet的資料請關注其它相關文章！