kubernetes有状态

无状态
与无状态相反,有状态服务在服务端保留之前请求的信息,用以处理当前请求。例如:MySQL
Volume
K8s 抽象的数据存储对象,volume 数据卷会把存储介质(网络存储,磁盘)中的数据挂载到容器中;
声明在 Pod 中的容器可以访问文件目录的,一个卷可以被挂载在 Pod 中一个或者多个容器的指定路径下面。
- 容器宕机,volume 数据不会丢失,一直存在
- pod 宕机,volume 就会消失,因此 volume 数据卷生命周期是和 pod 一致的;
数据卷的类型: - 本地卷 :emptyDir
- 网络卷 :NFS,ClusterFs,Ceph
- 云盘 :AWS,微软(azuredisk)
- k8s 自身的资源 : secret,configmap,downwardAPI
PV & PVC (容器存储的编排)
管理存储
和管理计算
有着明显的不同。PersistentVolume
给用户和管理员提供了一套 API,抽象出存储
是如何提供和消耗的细节
。在这里,我们介绍两种新的 API 资源:PersistentVolume(简称PV)
和PersistentVolumeClaim(简称PVC)
。
PersistentVolume(持久卷,简称 PV)
是集群内,由管理员提供的网络存储的一部分。就像集群中的节点一样,PV 也是集群中的一种资源。它也像 Volume 一样,是一种 volume 插件,但是它的生命周期却是和使用它的 Pod 相互独立的。
PersistentVolumeClaim(持久卷声明,简称 PVC)
是用户的一种存储请求。它和 Pod 类似,Pod 消耗 Node 资源,而 PVC 消耗 PV 资源。Pod 能够请求特定的资源(如 CPU 和内存)。PVC 能够请求指定的大小和访问的模式(可以被映射为一次读写或者多次只读);
pod 绑定 pvc pv
cat > my-pv.yaml << EOF
# 创建 PV1
apiVersion: v1
kind: PersistentVolume
metadata:
name: my-pv
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteMany
nfs:
path: /opt/k8s/demo
server: 192.168.66.13
EOF
cat > my-pvc.yaml << EOF
# 创建一个PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 5Gi
EOF
cat > my-nginx.yaml << EOF
# ngxin pod
apiVersion: v1
kind: Pod
metadata:
name: nginx-pod
spec:
containers:
- name: nginx
image: nginx:latest
ports:
- containerPort: 80
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumes:
- name: www
persistentVolumeClaim:
claimName: my-pvc
EOF
kubectl apply -f my-pv.yaml
kubectl apply -f my-pvc.yaml
kubectl apply -f my-nginx.yaml
kubectl get pv
kubectl get pvc
kubectl get pods -o wide
StatefulSet
本质上是 Deployment 的一种变体,它为了解决有状态服务的问题,它所管理的 Pod 拥有固定的 Pod 名称,启停顺序,在 StatefulSet 中,Pod 名字称为网络标识(hostname),还必须要用到共享存储。
在 Deployment 中,与之对应的服务是 service,而在 StatefulSet 中与之对应的 headless service,headless service,即无头服务,与 service 的区别就是它没有 Cluster IP,解析它的名称时将返回该 Headless Service 对应的全部 Pod 的 Endpoint 列表。
除此之外,StatefulSet 在 Headless Service 的基础上又为 StatefulSet 控制的每个 Pod 副本创建了一个 DNS 域名。
创建 5 个 pv 数据卷
cat > pv001-005.yaml << EOF
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv001
labels:
name: pv001
spec:
nfs:
path: /opt/k8s/v1
server: 192.168.66.13
accessModes: ["ReadWriteMany", "ReadWriteOnce"]
capacity:
storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv002
labels:
name: pv002
spec:
nfs:
path: /opt/k8s/v2
server: 192.168.66.13
accessModes: ["ReadWriteOnce"]
capacity:
storage: 2Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv003
labels:
name: pv003
spec:
nfs:
path: /opt/k8s/v3
server: 192.168.66.13
accessModes: ["ReadWriteMany", "ReadWriteOnce"]
capacity:
storage: 3Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv004
labels:
name: pv004
spec:
nfs:
path: /opt/k8s/v4
server: 192.168.66.13
accessModes: ["ReadWriteMany", "ReadWriteOnce"]
capacity:
storage: 1Gi
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv005
labels:
name: pv005
spec:
nfs:
path: /opt/k8s/v5
server: 192.168.66.13
accessModes: ["ReadWriteMany", "ReadWriteOnce"]
capacity:
storage: 1Gi
EOF
kubrctl apply -f pv001-005.yaml
详情
cat > nginx.yaml << EOF
apiVersion: v1
kind: Service
metadata:
name: nginx
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: web
spec:
selector:
matchLabels:
app: nginx
serviceName: "nginx"
replicas: 3
template:
metadata:
labels:
app: nginx
spec:
terminationGracePeriodSeconds: 10
containers:
- name: nginx
image: k8s.gcr.io/nginx-slim:0.8
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumes:
- name: www
persistentVolumeClaim:
claimName: my-pvc
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: my-pvc
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 5Gi
EOF
kubectl create -f nginx.yaml
configmap(配置中心)
用来存储一些配置文件,或者是环境变量;
例如: 部署 redis ,可以 redis.conf 配置存储在 configmap 对象中,部署 mysql ,可以把 my.cnf 存储在 configmap 中;
configmap 资源对象存储数据结构: key:value ,value 值可以是单个字符串,也可以是文件内容
Kubenetes 云原生架构体系中提供的一套配置中心对象;使得配置和服务进行解耦,一旦配置发生变化,就不需要重新打包,重新部署,服务立马感知到配置文件变化,立马做出调整;
# 创建命令
kubectl create configmap test-config --from-literal=db.host=10.5.10.116 --from-listeral=db.port='3306'
# 以文件创建key默认是文件名,value默认为文件内容
kubectl create configmap test-config2 --from-file=./app.properties
# 查看创建的test-config
kubectl get configmap test-config -o yaml
Secret
Secret 对象也是一种存储数据的资源对象,但是 Secret 仅仅是被用来存储敏感数据;具有安全的作用: 例如:秘钥,密码,token 等等这些数据信心都需要存储在 secret 资源对象中;
当 POD 需要或者这些敏感的数据的时候,只需要从 Secret 中获取即可(使用数据卷的挂载的方式,动态的从 secret 资源对象中获取数据),这样防止直接把敏感数据暴露在镜像中,这样的可以提高服务安全性
Secret 对象类型:
- Service Account
用来访问 Kubernetes API,由 Kubernetes 自动创建,并且会自动挂载到 Pod 的/run/secrets/kubernetes.io/serviceaccount 目录中; - Opaque
base64 编码格式的 Secret,用来存储密码、密钥、信息、证书等,类型标识符为 generic; - kubernetes.io/dockerconfigjson
用来存储私有 docker registry 的认证信息,类型标识为 docker-registry。 - kubernetes.io/tl
用于为 SSL 通信模式存储证书和私钥文件,命令式创建类型标识为 tls。
StorageClass
什么是 StorageClass
Kubernetes提供了一套可以自动创建PV的机制,即:Dynamic Provisioning.而这个机制的核心在于:StorageClass这个API对象.
StorageClass对象会定义下面两部分内容:
1,PV的属性.比如,存储类型,Volume的大小等.
2,创建这种PV需要用到的存储插件
有了这两个信息之后,Kubernetes就能够根据用户提交的PVC,找到一个对应的StorageClass,之后Kubernetes就会调用该StorageClass声明的存储插件,进而创建出需要的PV.
但是其实使用起来是一件很简单的事情,你只需要根据自己的需求,编写YAML文件即可,然后使用kubectl create命令执行即可
为什么需要 StorageClass
在一个大规模的Kubernetes集群里,可能有成千上万个PVC,这就意味着运维人员必须实现创建出这个多个PV,此外,随着项目的需要,会有新的PVC不断被提交,那么运维人员就需要不断的添加新的,满足要求的PV,否则新的Pod就会因为PVC绑定不到PV而导致创建失败.而且通过 PVC 请求到一定的存储空间也很有可能不足以满足应用对于存储设备的各种需求
而且不同的应用程序对于存储性能的要求可能也不尽相同,比如读写速度、并发性能等,为了解决这一问题,Kubernetes 又为我们引入了一个新的资源对象:StorageClass,通过 StorageClass 的定义,管理员可以将存储资源定义为某种类型的资源,比如快速存储、慢速存储等,用户根据 StorageClass 的描述就可以非常直观的知道各种存储资源的具体特性了,这样就可以根据应用的特性去申请合适的存储资源了。
运行原理及部署流程
要使用 StorageClass,我们就得安装对应的自动配置程序,比如我们这里存储后端使用的是 nfs,那么我们就需要使用到一个 nfs-client 的自动配置程序,我们也叫它 Provisioner,这个程序使用我们已经配置好的 nfs 服务器,来自动创建持久卷,也就是自动帮我们创建 PV。
1.自动创建的 PV 以${namespace}-${pvcName}-${pvName}这样的命名格式创建在 NFS 服务器上的共享数据目录中
2.而当这个 PV 被回收后会以archieved-${namespace}-${pvcName}-${pvName}这样的命名格式存在 NFS 服务器上。
搭建 StorageClass+NFS,大致有以下几个步骤:
- 创建一个可用的 NFS Server
- 创建 Service Account.这是用来管控 NFS provisioner 在 k8s 集群中运行的权限
- 创建 StorageClass.负责建立 PVC 并调用 NFS provisioner 进行预定的工作,并让 PV 与 PVC 建立管理
- 创建 NFS provisioner.有两个功能,一个是在 NFS 共享目录下创建挂载点(volume),另一个则是建了 PV 并将 PV 与 NFS 的挂载点建立关联
实战
# rbac.yaml:#唯一需要修改的地方只有namespace,根据实际情况定义
apiVersion: v1
kind: ServiceAccount
metadata:
name: nfs-client-provisioner
namespace: default
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: nfs-client-provisioner-runner
rules:
- apiGroups: [""]
resources: ["persistentvolumes"]
verbs: ["get", "list", "watch", "create", "delete"]
- apiGroups: [""]
resources: ["persistentvolumeclaims"]
verbs: ["get", "list", "watch", "update"]
- apiGroups: ["storage.k8s.io"]
resources: ["storageclasses"]
verbs: ["get", "list", "watch"]
- apiGroups: [""]
resources: ["events"]
verbs: ["create", "update", "patch"]
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: run-nfs-client-provisioner
subjects:
- kind: ServiceAccount
name: nfs-client-provisioner
namespace: default
roleRef:
kind: ClusterRole
name: nfs-client-provisioner-runner
apiGroup: rbac.authorization.k8s.io
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: leader-locking-nfs-client-provisioner
namespace: default
rules:
- apiGroups: [""]
resources: ["endpoints"]
verbs: ["get", "list", "watch", "create", "update", "patch"]
---
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
name: leader-locking-nfs-client-provisioner
subjects:
- kind: ServiceAccount
name: nfs-client-provisioner
namespace: default
roleRef:
kind: Role
name: leader-locking-nfs-client-provisioner
apiGroup: rbac.authorization.k8s.io
# 创建NFS资源的StorageClass
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
name: managed-nfs-storage
provisioner: qgg-nfs-storage
parameters:
archiveOnDelete: "false"
# 创建NFS provisioner
apiVersion: apps/v1
kind: Deployment
metadata:
name: nfs-client-provisioner
labels:
app: nfs-client-provisioner
namespace: default
spec:
replicas: 1
selector:
matchLabels:
app: nfs-client-provisioner
strategy:
type: Recreate
selector:
matchLabels:
app: nfs-client-provisioner
template:
metadata:
labels:
app: nfs-client-provisioner
spec:
serviceAccountName: nfs-client-provisioner
containers:
- name: nfs-client-provisioner
image: hub.kaikeba.com/library/nfs-client-provisioner:v1
volumeMounts:
- name: nfs-client-root
mountPath: /persistentvolumes
env:
- name: PROVISIONER_NAME
value: qgg-nfs-storage
- name: NFS_SERVER
value: 192.168.66.13
- name: NFS_PATH
value: /opt/k8s
volumes:
- name: nfs-client-root
nfs:
server: 192.168.66.13
path: /opt/k8s
# 创建pod进行测试
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: test-claim
annotations:
volume.beta.kubernetes.io/storage-class: "managed-nfs-storage"
spec:
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Mi
# 创建测试pod,查看是否可以正常挂载
kind: Pod
apiVersion: v1
metadata:
name: test-pod
spec:
containers:
- name: test-pod
image: busybox:1.24
command:
- "/bin/sh"
args:
- "-c"
- "touch /mnt/SUCCESS && exit 0 || exit 1" #创建一个SUCCESS文件后退出
volumeMounts:
- name: nfs-pvc
mountPath: "/mnt"
restartPolicy: "Never"
volumes:
- name: nfs-pvc
persistentVolumeClaim:
claimName: test-claim #与PVC名称保持一致
# Statefulset+volumeClaimTemplates自动创建PV
---
apiVersion: v1
kind: Service
metadata:
name: nginx-headless
labels:
app: nginx
spec:
ports:
- port: 80
name: web
clusterIP: None
selector:
app: nginx
---
apiVersion: apps/v1beta1
kind: StatefulSet
metadata:
name: web
spec:
serviceName: "nginx"
replicas: 2
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: ikubernetes/myapp:v1
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
annotations:
volume.beta.kubernetes.io/storage-class: "managed-nfs-storage"
spec:
accessModes: [ "ReadWriteOnce" ]
resources:
requests:
storage: 1Gi