🚀 优质资源分享 🚀

PV&PVC&HeadlessService

4.1、什么是无状态/有状态服务？

无状态服务：
1、没有实时的数据需要存储 （即使有，也是静态数据）
2、服务集群网络中，拿掉一个服务后，一段时间后，加入这个服务，对服务集群没有任何影响。
比如：
目前开发应用程序（Java代码）
有状态服务：
1、有实时的数据需要存储
2、服务集群网络中，拿掉一个服务后，一段时间后，加入这个服务，对服务集群有一定的影响（数据完整性，一致性）
比如：
关系型数据库（mysql、sqlserver）

4.2、服务部署

4.2.1、无状态服务部署

kubernetes部署无状态服务，部署架构，形态：对于无状态服务部署的几个关键对象：Deployment、ReplicaSet、Pod.

4.2.2、有状态服务部署

在kubernetes中，服务部署的最小单元都是POD；对于部署有状态服务，必须对POD容器的数据存储做持久化处理。需要引入PV(persistent volume）PVC(persistent volume claim)、磁盘等存储器。

4.3、Volume 数据卷

https://kubernetes.io/zh-cn/docs/reference/kubernetes-api/config-and-storage-resources/volume/#local-temporary-directory

4.3.1 数据卷结构

Volume数据卷生命周期：（volume数据卷是kubernetes资源对象，本身并不存储数据，而仅仅是提供把数据挂载到容器中的能力）
1、pod内部容器宕机，volume数据卷及数据不会丢失；
2、pod宕机，此时volume数据卷消失了，数据也丢失了，重建的pod无法找回数据了。
Volume 数据卷是Kubernetes抽象出来的一个资源对象，它本身不存储数据，它主要实现数据挂载（把不同存储介质中的数据给挂载到pod内部容器中）

4.3.2 数据卷的类型


4.3.3 本地挂载卷

1. emptyDir 数据卷空挂载方式
   
   验证：进入容器内部，发现有/cache目录，但是没有数据
   
   2)hostpath 磁盘挂载方式：

apiVersion: v1
kind: Pod
metadata:
  name: test-pd
spec:
  containers:
  - image: k8s.gcr.io/test-webserver
    name: test-container
    volumeMounts:
    - mountPath: /test-pd
      name: test-volume
  volumes:
  - name: test-volume
    hostPath:
      # 宿主上目录位置
      path: /data
      # 此字段为可选
      type: Directory

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

4.3.4 网络存储卷

1）首先自行安装一台nfs服务器。
2）yaml文件

apiVersion: v1
kind: Pod
metadata:
  name: nfs
spec:
  containers:
  - image: harbor.hyz.com/library/mynginx:v1
    name: test-vo
    volumeMounts:
    - mountPath: /cache
      name: test-nfs
  volumes:
  - name: test-nfs
    nfs:
      server: 192.168.211.13
      path: /data/harbor

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

4.3、configmap

4.3.1 什么是configmap?

ConfigMap是k8s提供的一个配置中心，类似于微服务架构中（nacos,zookeeper）配置中心服务，用来存储一些配置文件。
例如：
1、部署Redis服务，可以把redis.conf配置文件存储在configmap资源对象中；
2、部署mysql服务，可以把my.cnf配置文件存储在configmap资源对象中。
ConfigMap资源对象存储结构：key-value模式，key是关键字符，value可以是字符串，也可以是一个文件内容。

4.3.2 创建configmap

Examples:
# Create a new configmap named my-config based on folder bar
kubectl create configmap my-config --from-file=path/to/bar

# Create a new configmap named my-config with specified keys instead of file basenames on disk
kubectl create configmap my-config --from-file=key1=/path/to/bar/file1.txt --from-file=key2=/path/to/bar/file2.txt

# Create a new configmap named my-config with key1=config1 and key2=config2
kubectl create configmap my-config --from-literal=key1=config1 --from-literal=key2=config2

# Create a new configmap named my-config from the key=value pairs in the file
kubectl create configmap my-config --from-file=path/to/bar

# Create a new configmap named my-config from an env file
kubectl create configmap my-config --from-env-file=path/to/bar.env

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

1、根据目录创建
kubect create cm my-config-1 --from-file=/data/config
2、根据文件创建
kubectl create cm my-config-2 --from-file=/data/config/application.yml
3、根据字面量（key-value）创建
kubectl create cm my-config-3 --from-literal=key=value1 --from-literal=key2=value2

4.3.3 Pod服务引用

1)使用单个 ConfigMap 中的数据定义容器环境变量

apiVersion: v1
kind: Pod
metadata:
  name: dapi-test-pod
spec:
  containers:
    - name: test-container
      image: harbor.hyz.com/library/mynginx:v1
      command: [ "/bin/sh", "-c", "env" ]
      env:
        # 定义环境变量
        - name: SPECIAL_LEVEL_KEY
          valueFrom:
            configMapKeyRef:
              # ConfigMap 包含你要赋给 SPECIAL_LEVEL_KEY 的值
              name: special-config
              # 指定与取值相关的键名
              key: special.how
  restartPolicy: Never

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

经过测试：发现成功的把configmap中数据引入到环境变量中；
2)volume方式挂载：

apiVersion: v1
kind: Pod
metadata:
  name: cm-volume
spec:
  containers:
  - image: harbor.hyz.com/library/mynginx:v1
    name: test-container
    command: [ "/bin/sh", "-c", "sleep 600s" ]
    volumeMounts:
      - name: config-volume
        mountPath: /etc/config
  volumes:
    - name: config-volume
      configMap:
        name: my-config-2

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

查看容器内部是否挂载成功：
my-config-2中的4个文件都挂载成功。

4.3.4 POD数据热更新

修改ConfigMap中的数据，pod服务能够马上察觉到。

4.4、Secret

4.4.1 Secret是什么？

Secret是kubernetes本地数据卷的一种，secret提供存储敏感数据的一种服务，用来把敏感存储secret对象中，保证服务的安全性。
具体作用：防止一些敏感数据直接保证服务镜像中；例如：token, 秘钥，密码等等。当pod需要这些数据的时候，动态的从secret资源对象中加载即可。

4.4.2 k8s认证方式

Secret有4种类型：

• Service Account ：用来访问Kubernetes API，由Kubernetes自动创建，并且会自动挂载到Pod的/run/secrets/kubernetes.io/serviceaccount目录中；
  
  
• Opaque ：base64编码格式的Secret，用来存储密码、密钥、信息、证书等，类型标识符为generic；
• kubernetes.io/dockerconfigjson ：用来存储私有docker registry的认证信息，类型标识为docker-registry。
• kubernetes.io/tls：用于为SSL通信模式存储证书和私钥文件，命令式创建类型标识为tls。

当我们采用rest风格访问k8s api时，需要携带一些鉴权信息，比如token\ca证书\账号密码等，之后每台Node节点会根据鉴权信息去master鉴权。

4.4.3 Secret使用

[root@k8s-master01 stateful]# echo -n "admin" | base64
YWRtaW4=
[root@k8s-master01 stateful]# echo -n "abcdefgh" | base64
YWJjZGVmZ2g=

apiVersion: v1
kind: Secret
metadata:
  name: mysecret
type: Opaque
data:
  password: YWJjZGVmZ2g=
  username: YWRtaW4=

1
2
3
4
5
6
7
8
9
10
11
12
13
14

4.4.4 pod服务引用

apiVersion: v1
kind: Pod
metadata:
  name: secret-test
  labels:
    name: secret-test
spec:
  volumes:
    - name: secrets
      secret:
        secretName: mysecret
  containers:
  - image: harbor.hyz.com/library/mynginx:v1
    name: test-container
    volumeMounts:
    - name: secrets
      mountPath: "/etc/secrets"
      readOnly: true

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

验证：进入容器/etc/secrets目录下，打印username, password属性
确实是我们进行加密后的2个源字符串。

4.5、PV(persistent volume)

4.5.1 PV是什么？

Pv持久化数据卷，是用来让服务和存储介质解耦（让volume数据卷和底层的存储介质进行解耦，volume数据卷消失了，但是pv不会消失，pv和pod没有强关联，当pod被重构后，根据hostname不变性，从而可以再次找回数据，保证数据的不丢失），因此为了部署有状态服务，kubernetes抽象出来了一个PV持久化数据资源对象，k8s可以自由的控制这个资源对象，其作用就是屏蔽掉底层复杂的存储介质的操作，使得kubernetes管理持久化的数据卷更加高效，简单。

4.5.2 pv原理

企业中服务部署需要存储数据：前期规划数据大小，需要多少存储空间？？ 然后由运维帮助创建持久化数据卷，根据需求大小进行创建.
可以把pv对象看做一个一个虚拟存储块，是一种虚拟化的概念，在逻辑上实现对物理资源隔离，同时实现对底层物理存储介质的抽象，使得k8s更加方便的管理存储空间，想使用哪个存储块，由k8s实现自由的调度。
Pv是k8s抽象出来的资源对象，k8s自由控制自己的资源对象
Pv存储块是根据业务需求，事先由运维先规划，创建好存储块，项目需要，从存储块中获取数据即可。
问题： 创建pod服务时候，需要存储数据，但是pv存储对象有上万个，pod应该是哪个pv存储块？

4.5.3 PVC匹配PV

Pvc(persistent volume claim) 持久化的数据卷声明卷，代理pod发送请求，帮助pod匹配一个合适的pv对象；
疑问：pvc是如何找到合适的pv资源对象?
创建pod服务的时候，存储数据，绑定一合适的pv对象：
1、向pvc发出请求，让pvc帮助我们选择一个合适的pv存储块
2、pvc发送申请请求，请求匹配一个合适的pv存储对象，匹配方式如下：
1）、访问大小
2）、访问方式

4.6 PV&PVC 案例

4.6.1 创建PV对象

1）创建Pv1

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv1
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteMany
  nfs:
    path: /opt/hyz
    server: 192.168.66.13

1
2
3
4
5
6
7
8
9
10
11
12
13

2)创建pv2

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv2
spec:
  capacity:
    storage: 7Gi
  accessModes:
    - ReadWriteMany
  nfs:
    path: /opt/hyz
    server: 192.168.66.13

1
2
3
4
5
6
7
8
9
10
11
12
13

4.6.2 创建Pod对象

apiVersion: v1
kind: Pod
metadata:
  name: pv-pod
spec:
  containers:
  - image: harbor.hyz.com/library/mynginx:v1
    name: test-container
    ports:
    - containerPort: 80
    volumeMounts:
      - name: www
        mountPath: /usr/share/nginx/html
  volumes:
    - name: www
      persistentVolumeClaim:
        claimName: my-pvc

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

4.6.3 创建pvc对象

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    request:
      storage: 5Gi

1
2
3
4
5
6
7
8
9
10
11

4.6.4 挂载流程


4.7 headlessService

HeadlessService : 字面意思： 无头服务，内涵含义：没有ip地址的Service; 也就是说对于有状态服务部署来说，使用的是headlessService, 不会给service分配ip地址;
HeadlessService作用就是把后端服务的ip地址暴露给前端，便于客户端使用。

4.8 storageClass

根据需求： 创建pv存储块对象，可以想象：在开发中，需要大量的存储块，如果使用人工创建，非常低效，且没有含金量。
因此根据解放生产力指标：让pv按需动态创建，再也不需要人为的方式创建。使用storageclass实现pv对象动态创建。
Storageclass 动态创建pv存储块实现的部署方案：
要想实现pv按需动态创建,那必须先完成环境配置：
1、安装storageclass
2、安装persistent volume provisioner