基础知识之 PV PVC 理解

基础重要的服务介绍

---

Master 上运行的服务

• etcd 服务：

k8s 内部关系图：

image

k8s内对象名字	作用
daemonSet	用来描述每个宿主机上必须且只能运行一个副本的守护进程服务
Job	用来描述一次性运行的 Pod（比如，大数据任务）
CronJob	用于描述定时任务

==Kubernetes 项目如何启动一个容器化任务呢？==

实例：NGINX 负载

1. 定义一个 deployment yaml文件

apiVersion: apps/v1
kind: Deployment   #yaml类型名
metadata:
  name: nginx-deployment
  labels:
    app: nginx
spec:
  replicas: 2
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.7.9
        ports:
        - containerPort: 80

2. 创建这个yaml

$ kubectl create -f nginx-deployment.yaml

这样就创建了两个 NGINX 的 部署

---

kubeadm 集群构建命令：

# 创建一个 Master 节点
$ kubeadm init

# 将一个 Node 节点加入到当前集群中
$ kubeadm join 

==部署 kubeadm master 节点==

1. 安装 kubeadm

$ apt-get install kubeadm

2. 初始化master 节点

kubeadm init

static pod 的简介
[图片上传失败...(image-228f2-1541571599035)]

apiVersion: v1
kind: Pod
metadata:
  annotations:
    scheduler.alpha.kubernetes.io/critical-pod: ""
  creationTimestamp: null
  labels:
    component: kube-apiserver
    tier: control-plane
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-apiserver
    - --authorization-mode=Node,RBAC
    - --runtime-config=api/all=true
    - --advertise-address=10.168.0.2
    ...
    - --tls-cert-file=/etc/kubernetes/pki/apiserver.crt
    - --tls-private-key-file=/etc/kubernetes/pki/apiserver.key
    image: k8s.gcr.io/kube-apiserver-amd64:v1.11.1
    imagePullPolicy: IfNotPresent
    livenessProbe:
      ...
    name: kube-apiserver
    resources:
      requests:
        cpu: 250m
    volumeMounts:
    - mountPath: /usr/share/ca-certificates
      name: usr-share-ca-certificates
      readOnly: true
    ...
  hostNetwork: true
  priorityClassName: system-cluster-critical
  volumes:
  - hostPath:
      path: /etc/ca-certificates
      type: DirectoryOrCreate
    name: etc-ca-certificates
  ...

---

==PV &PVC==

目的：实现存储的持久化，在k8s中并非绑定宿主机的目录即为存储持久化

PV &PVC 的关联：

PVC 如果想要和pod结合起来需要与PV结合起来才能被使用

==创建PV==-->==开发声明PVC对象==--> ==确认PV的大小与PVC的spec字段，对比== --> ==storageClassName 字段要一致== -->绑定

创建PV示例 （示例为NFS网络存储类示例）

apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs
spec:
  storageClassName: manual
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  nfs:
    server: 10.244.1.4
    path: "/"

创建PVCyaml示例：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: manual
  resources:
    requests:
      storage: 1Gi

pod 绑定PVC 示例

apiVersion: v1
kind: Pod
metadata:
  labels:
    role: web-frontend
spec:
  containers:
  - name: web
    image: nginx
    ports:
      - name: web
        containerPort: 80
    volumeMounts:
        - name: nfs
          mountPath: "/usr/share/nginx/html"
  volumes:
  - name: nfs
    persistentVolumeClaim: ## <--这字段
      claimName: nfs

问题点：创建 Pod 的时候，系统里并没有合适的 PV 跟它定义的PVC绑定

所以就引进了k8s的 Volume Controller

==PersistentVolumeController== ：不断的查看当前每个PVC，确认他们是否处于bond状态，如果不是会遍历所有的PV并尝试将PVC与合适的PV进行绑定

PV生效阶段：

二段式：

1. attach： 即将块存储于宿主机进行接入
2. mount：将存储挂载至宿主机的某个目录用于容器进行映射持久化使用

这些二段式准备阶段在k8s中是依赖kubelet的主控制循环来实现的，分别是：

==AtttachDetachController(检查pod对应的宿主机与该pod的PV 的挂载情况)==

==VolumeManagerReconciler()==

==StorageClass==

就是创建PV的模板，包含两部分内容：PV属性 & 创建此PV所需要的插件

示例：Volume 的类型是GCE 的persistent DISK：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: block-service
provisioner: kubernetes.io/gce-pd  #k8s内置的GCE PD 存储插件的名字
parameters:   # PV参数字段
  type: pd-ssd   ##PV的类型，这里的类型是 SSD格式的GCE远程磁盘。

创建StorageClass 的命令：

$ kubectl create -f sc.yaml

接下来可以创建所需要的PVC ：

PVC 的yaml文件内容：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: claim1
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: block-service   ## 这个名字就是上面所创建的StorageClass的名字
  resources:
    requests:
      storage: 30Gi

创建PVC 的命令(示例)：

$ kubectl create -f pvc.yaml
$ kubectl describe pvc claim1
Name:           claim1
Namespace:      default
StorageClass:   block-service
Status:         Bound
Volume:         pvc-e5578707-c626-11e6-baf6-08002729a32b   ## 由storageClass创建的PV
Labels:         
Capacity:       30Gi
Access Modes:   RWO
No Events.

$ kubectl describe pv pvc-e5578707-c626-11e6-baf6-08002729a32b
Name:            pvc-e5578707-c626-11e6-baf6-08002729a32b
Labels:          
StorageClass:    block-service
Status:          Bound
Claim:           default/claim1
Reclaim Policy:  Delete
Access Modes:    RWO
Capacity:        30Gi
...
No events.

==疑问：创建的PV 具体位置在哪？实现存储的持久化 莫非需要PVC的名字一个pod唯一对应一个PVC？==

有了Dynamic Provisioning 机制，只需要在k8S中创建出数量有限的StoreageClass 的对象就可以了。当提交包含StorageClass 字段的PVC之后，k8s会根据这个StoreageClass 字段来创建出相应的PV 

---

注意：开头的PV PVC 示例中都声明了StoreageClassName=manual 的yaml, 这样做的，并不是集群中有一个名字叫manual的SC，而这个时候是k8s进行了 Static Provisioning ，这样做的好处就是 PV 与PVC 的关系掌控在自己手中。

PV、PVC 、 StorageClass 的关系：

[图片上传失败...(image-b2dfa1-1541571599035)]

如图关系：

• PVC：Pod 想要使用的持久化存储的属性，比如存储的大小、读写权限等。
• PV：一个具体volume 的属性，比如 volume的类型、挂载目录、远程存储服务地址等。
• StorageClass 的作用是：只有同属于一个StorageClass的PV和PVC才能绑定在一起。

心得：

==PV & PVC 关联有两种方式：静态&动态 静态的缺点是如果PVC需求的不存在需要人工确认==

==疑问：创建新的PV?还是如果有旧的StoreageClass de PV会进行绑定？==

==疑问：如何跟AWS 的块存储关联起来？（参照下面博客）==

==什么存储介质可以用作PV？（NFS、AWS的EBS）==

AWS EBS 创建PV

AWS 做PV国外博客

博友参考博客

---

Local Persistent Volume

即node节点上、宿主机自身的存储，类似于 docker 映射。

优点： 读写速度快

缺点：节点宕机且不能恢复时则存储消失。

==注意这个本地的PV 并不能等同于 hostPath的NodeAffinity==