如何构建k8s中稳定运行的有状态服务部署基石？
- 内容介绍
- 文章标签
- 相关推荐
本文共计2399个文字，预计阅读时间需要10分钟。
PVPVCHeadlessService4.1简介：无状态/有状态服务无状态服务：
1.没有实时的数据需求，不需要存储（即时数据或静态数据）。
2.服务集群网络中，移除一个服务后，一段时间后可自动加入。
PV&PVC&HeadlessService 4.1、什么是无状态/有状态服务？无状态服务：
1、没有实时的数据需要存储 （即使有，也是静态数据）
2、服务集群网络中，拿掉一个服务后，一段时间后，加入这个服务，对服务集群没有任何影响。
比如：
目前开发应用程序（Java代码）
有状态服务：
1、有实时的数据需要存储
2、服务集群网络中，拿掉一个服务后，一段时间后，加入这个服务，对服务集群有一定的影响（数据完整性，一致性）
比如：
关系型数据库（mysql、sqlserver）
kubernetes部署无状态服务，部署架构，形态：对于无状态服务部署的几个关键对象：Deployment、ReplicaSet、Pod.
在kubernetes中，服务部署的最小单元都是POD；对于部署有状态服务，必须对POD容器的数据存储做持久化处理。需要引入PV(persistent volume）PVC(persistent volume claim)、磁盘等存储器。
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内部容器中）
- 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
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
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可以是字符串，也可以是一个文件内容。
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、根据目录创建
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
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
经过测试：发现成功的把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
查看容器内部是否挂载成功：
my-config-2中的4个文件都挂载成功。
修改ConfigMap中的数据，pod服务能够马上察觉到。
4.4、Secret 4.4.1 Secret是什么？Secret是kubernetes本地数据卷的一种，secret提供存储敏感数据的一种服务，用来把敏感存储secret对象中，保证服务的安全性。
具体作用：防止一些敏感数据直接保证服务镜像中；例如：token, 秘钥，密码等等。当pod需要这些数据的时候，动态的从secret资源对象中加载即可。
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鉴权。
[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=
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
验证：进入容器/etc/secrets目录下，打印username, password属性
确实是我们进行加密后的2个源字符串。
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存储块？
Pvc(persistent volume claim) 持久化的数据卷声明卷，代理pod发送请求，帮助pod匹配一个合适的pv对象；
疑问：pvc是如何找到合适的pv资源对象?
创建pod服务的时候，存储数据，绑定一合适的pv对象：
1、向pvc发出请求，让pvc帮助我们选择一个合适的pv存储块
2、pvc发送申请请求，请求匹配一个合适的pv存储对象，匹配方式如下：
1）、访问大小
2）、访问方式
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
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
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
4.6.3 创建pvc对象
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
accessModes:
- ReadWriteMany
resources:
request:
storage: 5Gi
4.6.4 挂载流程
HeadlessService : 字面意思： 无头服务，内涵含义：没有ip地址的Service; 也就是说对于有状态服务部署来说，使用的是headlessService, 不会给service分配ip地址;
HeadlessService作用就是把后端服务的ip地址暴露给前端，便于客户端使用。
根据需求： 创建pv存储块对象，可以想象：在开发中，需要大量的存储块，如果使用人工创建，非常低效，且没有含金量。
因此根据解放生产力指标：让pv按需动态创建，再也不需要人为的方式创建。使用storageclass实现pv对象动态创建。
Storageclass 动态创建pv存储块实现的部署方案：
要想实现pv按需动态创建,那必须先完成环境配置：
1、安装storageclass
2、安装persistent volume provisioner
本文共计2399个文字，预计阅读时间需要10分钟。
PVPVCHeadlessService4.1简介：无状态/有状态服务无状态服务：
1.没有实时的数据需求，不需要存储（即时数据或静态数据）。
2.服务集群网络中，移除一个服务后，一段时间后可自动加入。
PV&PVC&HeadlessService 4.1、什么是无状态/有状态服务？无状态服务：
1、没有实时的数据需要存储 （即使有，也是静态数据）
2、服务集群网络中，拿掉一个服务后，一段时间后，加入这个服务，对服务集群没有任何影响。
比如：
目前开发应用程序（Java代码）
有状态服务：
1、有实时的数据需要存储
2、服务集群网络中，拿掉一个服务后，一段时间后，加入这个服务，对服务集群有一定的影响（数据完整性，一致性）
比如：
关系型数据库（mysql、sqlserver）
kubernetes部署无状态服务，部署架构，形态：对于无状态服务部署的几个关键对象：Deployment、ReplicaSet、Pod.
在kubernetes中，服务部署的最小单元都是POD；对于部署有状态服务，必须对POD容器的数据存储做持久化处理。需要引入PV(persistent volume）PVC(persistent volume claim)、磁盘等存储器。
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内部容器中）
- 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
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
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可以是字符串，也可以是一个文件内容。
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、根据目录创建
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
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
经过测试：发现成功的把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
查看容器内部是否挂载成功：
my-config-2中的4个文件都挂载成功。
修改ConfigMap中的数据，pod服务能够马上察觉到。
4.4、Secret 4.4.1 Secret是什么？Secret是kubernetes本地数据卷的一种，secret提供存储敏感数据的一种服务，用来把敏感存储secret对象中，保证服务的安全性。
具体作用：防止一些敏感数据直接保证服务镜像中；例如：token, 秘钥，密码等等。当pod需要这些数据的时候，动态的从secret资源对象中加载即可。
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鉴权。
[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=
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
验证：进入容器/etc/secrets目录下，打印username, password属性
确实是我们进行加密后的2个源字符串。
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存储块？
Pvc(persistent volume claim) 持久化的数据卷声明卷，代理pod发送请求，帮助pod匹配一个合适的pv对象；
疑问：pvc是如何找到合适的pv资源对象?
创建pod服务的时候，存储数据，绑定一合适的pv对象：
1、向pvc发出请求，让pvc帮助我们选择一个合适的pv存储块
2、pvc发送申请请求，请求匹配一个合适的pv存储对象，匹配方式如下：
1）、访问大小
2）、访问方式
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
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
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
4.6.3 创建pvc对象
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
accessModes:
- ReadWriteMany
resources:
request:
storage: 5Gi
4.6.4 挂载流程
HeadlessService : 字面意思： 无头服务，内涵含义：没有ip地址的Service; 也就是说对于有状态服务部署来说，使用的是headlessService, 不会给service分配ip地址;
HeadlessService作用就是把后端服务的ip地址暴露给前端，便于客户端使用。
根据需求： 创建pv存储块对象，可以想象：在开发中，需要大量的存储块，如果使用人工创建，非常低效，且没有含金量。
因此根据解放生产力指标：让pv按需动态创建，再也不需要人为的方式创建。使用storageclass实现pv对象动态创建。
Storageclass 动态创建pv存储块实现的部署方案：
要想实现pv按需动态创建,那必须先完成环境配置：
1、安装storageclass
2、安装persistent volume provisioner