從0到1使用Kubernetes系列（六）：數據持久化實戰

時間  2019-11-06
標籤 使用 kubernetes 系列 數據 持久 實戰 简体版
原文   原文鏈接

本文是從0到1使用Kubernetes系列第六篇，上一篇《從0到1使用Kubernetes系列（五）：Kubernetes Scheduling》介紹了Kubernetes調度器如何進行資源調度，本文將爲你們介紹幾種經常使用儲存類型。html

默認狀況下Pod掛載在磁盤上的文件生命週期與Pod生命週期是一致的，若Pod出現崩潰的狀況，kubelet 將會重啓它，這將會形成Pod中的文件將丟失，由於Pod會以鏡像最初的狀態從新啓動。在實際應用當中，開發者有不少時候須要將容器中的數據保留下來，好比在Kubernetes中部署了MySql，不能由於MySql容器掛掉重啓而上面的數據所有丟失；其次，在 Pod 中同時運行多個容器時，這些容器之間可能須要共享文件。也有的時候，開發者須要預置配置文件，使其在容器中生效，例如自定義了mysql.cnf文件在MySql啓動時就須要加載此配置文件。這些都將是今天將要實戰解決的問題。mysql

今天這篇文將講解下面幾種經常使用存儲類型：nginx

  • secret
  • configMap
  • emptyDir
  • hostPath
  • nfs
  • persistentVolumeClaim

SECRET

Secret對象容許您存儲和管理敏感信息，例如密碼，OAuth令牌和ssh密鑰。將此類信息放入一個secret中能夠更好地控制它的用途，並下降意外暴露的風險。git

▌使用場景github

鑑權配置文件掛載redis

▌使用示例sql

在CI中push構建好的鏡像就能夠將docker鑑權的config.json文件存入secret對象中，再掛載到CI的Pod中，從而進行權限認證。docker

  • 首先建立secret
$ kubectl create secret docker-registry docker-config  --docker-server=https://hub.docker.com --docker-username=username --docker-password=password
secret/docker-config created
  • 新建docker-pod.yaml文件，粘貼如下信息：
apiVersion: v1
kind: Pod
metadata:
  name: docker
spec:
  containers:
  - name: docker
    image: docker
    command:
      - sleep
      - "3600"
    volumeMounts:
    - name: config
      mountPath: /root/.docker/
  volumes:
  - name: config
    secret:
      secretName: docker-config
      items:
      - key: .dockerconfigjson
        path: config.json
        mode: 0644
  • Docker Pod掛載secret
$ kubectl apply -f docker-pod.yaml
pod/docker created
  • 查看掛載效果
$ kubectl exec docker -- cat /root/.docker/config.json
{"auths":{"https://hub.docker.com":{"username":"username","password":"password","auth":"dXNlcm5hbWU6cGFzc3dvcmQ="}}}
  • 清理環境
$ kubectl delete pod docker
$ kubectl delete secret docker-config

ConfigMap

許多應用程序會從配置文件、命令行參數或環境變量中讀取配置信息。這些配置信息須要與docker image解耦ConfigMap API給咱們提供了向容器中注入配置信息的機制，ConfigMap能夠被用來保存單個屬性，也能夠用來保存整個配置文件。json

▌使用場景後端

配置信息文件掛載

▌使用示例

使用ConfigMap中的數據來配置Redis緩存

  • 建立example-redis-config.yaml文件，粘貼如下信息：
apiVersion: v1
kind: ConfigMap
metadata:
  name: example-redis-config
data:
  redis-config: |
    maxmemory 2b
    maxmemory-policy allkeys-lru
  • 建立ConfigMap
$ kubectl apply -f example-redis-config.yaml
configmap/example-redis-config created
  • 建立example-redis.yaml文件，粘貼如下信息：
apiVersion: v1
kind: Pod
metadata:
  name: redis
spec:
  containers:
  - name: redis
    image: kubernetes/redis:v1
    env:
    - name: MASTER
      value: "true"
    ports:
    - containerPort: 6379
    resources:
      limits:
        cpu: "0.1"
    volumeMounts:
    - mountPath: /redis-master-data
      name: data
    - mountPath: /redis-master
      name: config
  volumes:
    - name: data
      emptyDir: {}
    - name: config
      configMap:
        name: example-redis-config
        items:
        - key: redis-config
          path: redis.conf
  • Redis Pod掛載ConfigMap測試
$ kubectl apply -f example-redis.yaml
pod/redis created
  • 查看掛載效果
$ kubectl exec -it redis redis-cli
$ 127.0.0.1:6379> CONFIG GET maxmemory
1) "maxmemory"
2) "2097152"
$ 127.0.0.1:6379> CONFIG GET maxmemory-policy
1) "maxmemory-policy"
2) "allkeys-lru"
  • 清理環境
$ kubectl delete pod redis
$ kubectl delete configmap example-redis-config

EmptyDir

當使用emptyDir卷的Pod在節點建立時，會在該節點建立一個新的空目錄，只要該Pod運行在該節點，該目錄會一直存在，Pod內的全部容器能夠將改目錄掛載到不一樣的掛載點，但均可以讀寫emptyDir內的文件。當Pod不論什麼緣由被刪除，emptyDir的數據都會永遠被刪除（一個Container Crash 並不會在該節點刪除Pod，所以在Container crash時，數據不會丟失）。默認狀況下，emptyDir支持任何類型的後端存儲：disk、ssd、網絡存儲。也能夠經過設置 emptyDir.medium 爲Memory，kubernetes會默認mount一個tmpfs（RAM-backed filesystem），由於是RAM Backed,所以 tmpfs 一般很快。可是會在容器重啓或者crash時，數據丟失。

▌使用場景

同一Pod內各容器共享存儲

▌使用示例

在容器a中生成hello文件，經過容器b輸出文件內容

  • 建立test-emptydir.yaml文件，粘貼如下信息：
apiVersion: v1
kind: Pod
metadata:
  name: test-emptydir
spec:
  containers:
  - image: alpine
    name: container-a
    command:
      - /bin/sh
    args:
      - -c
      - echo 'I am container-a' >> /cache-a/hello && sleep 3600
    volumeMounts:
    - mountPath: /cache-a
      name: cache-volume
  - image: alpine
    name: container-b
    command:
      - sleep
      - "3600"
    volumeMounts:
    - mountPath: /cache-b
      name: cache-volume
  volumes:
  - name: cache-volume
    emptyDir: {}
  • 建立Pod
kubectl apply -f test-emptydir.yaml
pod/test-emptydir created
  • 測試
$ kubectl exec test-emptydir -c container-b -- cat /cache-b/hello
I am container-a
  • 清理環境
$ kubectl delete pod test-emptydir

HostPath

將宿主機對應目錄直接掛載到運行在該節點的容器中。使用該類型的卷，須要注意如下幾個方面：

  1. 使用同一個模板建立的Pod，因爲不一樣的節點有不一樣的目錄信息，可能會致使不一樣的結果
  2. 若是kubernetes增長了已知資源的調度，該調度不會考慮hostPath使用的資源
  3. 若是宿主機目錄上已經存在的目錄，只能夠被root能夠寫，因此容器須要root權限訪問該目錄，或者修改目錄權限

▌使用場景

運行的容器須要訪問宿主機的信息，好比Docker內部信息/var/lib/docker目錄，容器內運行cadvisor，須要訪問/dev/cgroups

▌使用示例

使用Docker socket binding模式在列出宿主機鏡像列表。

  • 建立test-hostpath.yaml文件，粘貼如下信息：
apiVersion: v1
kind: Pod
metadata:
  name: test-hostpath
spec:
  containers:
  - image: docker
    name: test-hostpath
    command:
      - sleep
      - "3600"
    volumeMounts:
    - mountPath: /var/run/docker.sock
      name: docker-sock
  volumes:
  - name: docker-sock
    hostPath:
      path: /var/run/docker.sock
      type: Socket
  • 建立test-hostpath Pod
$ kubectl apply -f test-hostpath.yaml
pod/test-hostpath created
  • 測試是否成功
$ kubectl exec test-hostpath docker images
REPOSITORY      IMAGE ID        CREATED         SIZE
docker          639de9917ae1    13 days ago     171MB
...

NFS存儲卷

NFS 卷容許將現有的 NFS（網絡文件系統）共享掛載到您的容器中。不像 emptyDir，當刪除 Pod 時，nfs 卷的內容被保留，卷僅僅是被卸載。這意味着 nfs 卷能夠預填充數據，而且能夠在 pod 之間共享數據。 NFS 能夠被多個寫入者同時掛載。

  • 重要提示：您必須先擁有本身的 NFS 服務器而後才能使用它。

▌使用場景

不一樣節點Pod使用統一nfs共享目錄

▌使用示例

  • 建立test-nfs.yaml文件，粘貼如下信息：
apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-nfs
spec:
  selector:
    matchLabels:
      app: store
  replicas: 2
  template:
    metadata:
      labels:
        app: store
    spec:
      volumes:
      - name: data
        nfs:
          server: nfs.server.com
          path: /
      affinity:
        podAntiAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
          - labelSelector:
              matchExpressions:
              - key: app
                operator: In
                values:
                - store
            topologyKey: "kubernetes.io/hostname"
      containers:
      - name: alpine
        image: alpine
        command:
          - sleep
          - "3600"
        volumeMounts:
        - mountPath: /data
          name: data
  • 建立測試deployment
$ kubectl apply -f test-nfs.yaml
deployment/test-nfs created
  • 查看pod運行狀況
$ kubectl get po -o wide
NAME                        READY     STATUS    RESTARTS   AGE       IP              NODE      NOMINATED NODE
test-nfs-859ccfdf55-kkgxj   1/1       Running   0          1m        10.233.68.245   uat05     <none>
test-nfs-859ccfdf55-aewf8   1/1       Running   0          1m        10.233.67.209   uat06     <none>
  • 進入Pod中進行測試
# 進入uat05節點的pod中
$ kubectl exec -it test-nfs-859ccfdf55-kkgxj sh
# 建立文件
$ echo "uat05" > /data/uat05
# 退出uat05節點的pod
$ edit
# 進入uat06節點的pod中
$ kubectl exec -it test-nfs-859ccfdf55-aewf8 sh
# 查看文件內容
$ cat /data/uat05
uat05
  • 清理環境
$ kubectl delete deployment test-nfs

PersistentVolumeClaim

上面全部例子中咱們都是直接將存儲掛載到的pod中，那麼在kubernetes中如何管理這些存儲資源呢？這就是Persistent Volume和Persistent Volume Claims所提供的功能。

● PersistentVolume 子系統爲用戶和管理員提供了一個 API，該 API 將如何提供存儲的細節抽象了出來。爲此，咱們引入兩個新的 API 資源：PersistentVolume 和 PersistentVolumeClaim。

  • PersistentVolume（PV）是由管理員設置的存儲，它是羣集的一部分。就像節點是集羣中的資源同樣，PV 也是集羣中的資源。 PV 是 Volume 之類的卷插件，但具備獨立於使用 PV 的 Pod 的生命週期。此 API 對象包含 Volume 的實現，即 NFS、iSCSI 或特定於雲供應商的存儲系統。
  • PersistentVolumeClaim（PVC）是用戶存儲的請求。它與 Pod 類似。Pod 消耗節點資源，PVC 消耗 PV 資源。Pod 能夠請求特定級別的資源（CPU 和內存）。聲明能夠請求特定的大小和訪問模式（例如，能夠以讀/寫一次或 只讀屢次模式掛載）。雖然 PersistentVolumeClaims 容許用戶使用抽象存儲資源，但用戶須要具備不一樣性質（例如性能）的 PersistentVolume 來解決不一樣的問題。集羣管理員須要可以提供各類各樣的 PersistentVolume，這些PersistentVolume 的大小和訪問模式能夠各有不一樣，但不須要向用戶公開實現這些卷的細節。對於這些需求，StorageClass 資源能夠實現。

● 在實際使用場景裏，PV 的建立和使用一般不是同一我的。這裏有一個典型的應用場景：管理員建立一個 PV 池，開發人員建立 Pod 和 PVC，PVC 裏定義了Pod所需存儲的大小和訪問模式，而後 PVC 會到 PV 池裏自動匹配最合適的 PV 給 Pod 使用。

▌使用示例

  • 建立PersistentVolume
apiVersion: v1
kind: PersistentVolume
metadata:
  name: mypv
spec:
  capacity:
    storage: 5Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: slow
  mountOptions:
    - hard
    - nfsvers=4.0
  nfs:
    path: /tmp
    server: 172.17.0.2
  • 建立PersistentVolumeClaim
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: myclaim
spec:
  accessModes:
    - ReadWriteOnce
  volumeMode: Filesystem
  resources:
    requests:
      storage: 5Gi
  volumeName: mypv
  • 建立Pod綁定PVC
kind: Pod
apiVersion: v1
metadata:
  name: mypod
spec:
  containers:
    - name: myfrontend
      image: nginx
      volumeMounts:
      - mountPath: "/var/www/html"
        name: mypd
  volumes:
    - name: mypd
      persistentVolumeClaim:
        claimName: myclaim
  • 查看pod運行狀況驗證綁定結果
$ kubectl get po -o wide
NAME    READY     STATUS    RESTARTS   AGE       IP              NODE      NOMINATED NODE
mypod   1/1       Running   0          1m        10.233.68.249   uat05     <none>
$ kubectl exec -it mypod sh
$ ls /var/www/html
  • 清理環境
$ kubectl delete pv mypv
$ kubectl delete pvc myclaim
$ kubectl delete po mypod

總結

本次實戰中使用了secret存儲docker認證憑據，更好地控制它的用途，並下降意外暴露的風險。

使用configMap對redis進行緩存配置，這樣即便redis容器掛掉重啓configMap中的配置依然會生效。接着又使用emptyDir來使得同一Pod中多個容器的目錄共享，在實際應用中開發者一般使用initContainers來進行預處理文件，而後經過emptyDir傳遞給Containers。而後再使用hostPath來訪問宿主機的資源，當網路io達不到文件讀寫要求時，可考慮固定應用只運行在一個節點上而後使用hostPath來解決文件讀寫速度的要求。

NFS和PersistentVolumeClaim的例子實質上都是試容器掛載的nfs服務器共享目錄，但這些資源通常都只掌握在了管理員手中，開發人員想要獲取這部分資源那麼就不是這麼友好了，動態存儲類（StorageClass）就能很好的解決此類問題。

更多關於Kubernetes系列的文章：

關於Choerodon豬齒魚

Choerodon豬齒魚開源多雲集成平臺，基於開源技術Kubernetes，Istio，knative，Gitlab和Spring Cloud來實現本地和雲端環境的集成，實現企業多雲/混合雲應用環境的一致性。平臺經過提供精益敏捷、持續交付、容器環境、微服務、DevOps等能力來幫助組織團隊來完成軟件的生命週期管理，從而更快、更頻繁地交付更穩定的軟件。

你們也能夠經過如下社區途徑瞭解豬齒魚的最新動態、產品特性，以及參與社區貢獻：

相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程