kubernetes有状态

知识库大约 9 分钟

无状态

与无状态相反,有状态服务在服务端保留之前请求的信息,用以处理当前请求。例如：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/dockerconfigjsonopen in new window

用来存储私有 docker registry 的认证信息，类型标识为 docker-registry。
kubernetes.io/tlopen in new window

用于为 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

kubernetes有状态

# 无状态

# Volume

# PV & PVC (容器存储的编排)

# StatefulSet

# configmap（配置中心）

# Secret

# StorageClass

无状态