无状态服务:
1、没有实时的数据需要存储 (即使有,也是静态数据)
2、服务集群网络中,拿掉一个服务后,一段时间后,加入这个服务,对服务集群没有任何影响。
比如:
目前开发应用程序(Java代码)
有状态服务:
1、有实时的数据需要存储
2、服务集群网络中,拿掉一个服务后,一段时间后,加入这个服务,对服务集群有一定的影响(数据完整性,一致性)
比如:
关系型数据库(mysql、sqlserver)
kubernetes部署无状态服务,部署架构,形态:对于无状态服务部署的几个关键对象:Deployment、ReplicaSet、Pod.
在kubernetes中,服务部署的最小单元都是POD;对于部署有状态服务,必须对POD容器的数据存储做持久化处理。需要引入PV(persistent volume)PVC(persistent volume claim)、磁盘等存储器。
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内部容器中)
- 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 挂载流程
4.7 headlessService
HeadlessService : 字面意思: 无头服务,内涵含义:没有ip地址的Service; 也就是说对于有状态服务部署来说,使用的是headlessService, 不会给service分配ip地址;
HeadlessService作用就是把后端服务的ip地址暴露给前端,便于客户端使用。
根据需求: 创建pv存储块对象,可以想象:在开发中,需要大量的存储块,如果使用人工创建,非常低效,且没有含金量。
因此根据解放生产力指标:让pv按需动态创建,再也不需要人为的方式创建。使用storageclass实现pv对象动态创建。
Storageclass 动态创建pv存储块实现的部署方案:
要想实现pv按需动态创建,那必须先完成环境配置:
1、安装storageclass
2、安装persistent volume provisioner