k8s存储数据卷

k8s存储

在容器中的磁盘文件是短暂的，当容器挂掉时候，k8s会将它重启，而重启后容器文件会丢失，并且有的pod会有多容器进行文件交互。为了解决这个问题，k8s引入数据卷概念。
k8s中Volume提供在容器中挂在外部存储的能力。
Pod需要设置卷来源(spec.volume)和挂载点(spec.containers.volumeMounts)两个信息后才可以使用相应的Volume
常用数据卷：

本地：hostPath, emptyDir
网络：NFS, Ceph, GlusterFS
公有云：AWS EBS
k8s资源: configmap, secret

1.存储数据卷

1.1emptyDir

是一个临时存储卷。与pod生命周期绑定一起，如果pod删除卷也会被删除
主要应用：pod中容器之间数据共享（比如一个容器负责写，一个容器负责读的场景）。

示例：

# 在pod 中启动2个容器一个读一个写
apiVersion: v1
kind: Pod
metadata:
  name: volume1
spec:
  containers:
  - name: write
    image: centos
    command: ["bash", "-c", "for i in {1..100};do echo $i >> /data/hello;sleep 1;done"]
    volumeMounts:
      - name: data
        mountPath: /data
  - name: read
    image: centos
    command: ["bash", "-c", "tail -f /data/hello"]
    volumeMounts:
      - name: data
        mountPath: /data
  volumes:
  - name: data
    emptyDir: {}
# 如有启动异常可执行
[root@k8s-master ~]# kubectl logs <pod name> -c <容器name>
# 通过exec在容器执行shell命令，查看写的执行状态
kubectl exec volume1 -c write -- tail /data/hello
# 通过如下命令可以查看刚才部署的pod跑在哪个节点上
kubectl get pods -o wide
# 到相应节点过滤查看容器
docker ps | grep volume1
#刚才设置数据共享目录在宿主机
/var/lib/kubelet/pods/<NAME 的ID>/volumes/kubernetes.io~empty-dir/data/hello

1.2Hostpath

挂载node文件系统（pod所在节点）上文件或者目录到pod中的容器。
应用场景：pod中容器需要访问宿主机文件（比如应用程序读取宿主机的物理资源，日志）

示例：

apiVersion: v1
kind: Pod
metadata:
  name: pod-hostpath
spec:
  containers:
  - name: busybox
    image: busybox
    args:
    - /bin/sh
    - -c
    - sleep: 36000
    volumeMounts:
    - name: data
      mountPath: /data# 挂载容器中/data下
  volumes:
  - name: data
    hostPath:
      path: /tmp# 挂载宿主机的/tmp下
      type: Directory

# 进入容器往容器/data下新增文件
kubectl exec -it pod-hostpath -- sh
touch hahat.txt
# 查看pod运行的节点
kubectl get pods -o wide
# 在node01节点上查看/tmp目录下，可以查看新创建的haha.txt

1.3NFS

网络存储卷，NFS提供对NFS挂载支持，可以自动将NFS共享路径挂载到Pod中。

准备一台服务器安装NFS,注意：每个Node上都要安装nfs-utils：需要让节点pod挂载共享目录，需要linux支持nfs内部协议的模块

yum install -y nfs-utils

vi /etc/exports
	/ifs/kubernetes *(rw,no_root_squash)
	# /ifs/kubernetes 指定暴漏目录
	# * 表示暴漏的网段为所有，也可以设置
	# rw,no_root_squash 表示权限
# 创建文件夹
	mkdir -p /ifs/kubernetes
# 启动
	
	systemctl start nfs
	systemctl enable nfs
# 测试nfs是否能用,另一台机器
mount -t nfs 172.16.215.141:/ifs/kubernetes /mnt
cd /mnt


mount -t nfs 172.16.215.141:/ifs/kubernetes /mnt
cd /mnt
touch 111.txt
# 查看nfs服务器/ifs/kubernetes下是否存在111.txt

# 卸载nfs命令： mount /mnt/

1.4 ConfigMap

创建ConfigMap后，数据实际会存储在k8s中etcd，然后通过创建pod时引用该数据。
应用场景：应用程序配置文件
pod使用configmap数据有两种方式：
```
1.变量注入
2.数据卷挂载
```

示例：

[root@k8s-master ~]# vi configmap.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: configmap-demo
data:# 定义键值方式变量
  a: "123"
  b: "456"
  # 定义多行变量
  redis.properties: ｜ 
    port: 6379
    host: 192.168.31.10
# 将configmap保存到k8中etcd中
[root@k8s-master ~]# kubectl apply -f configmap

[root@k8s-master ~]# kubectl get configmap
NAME               DATA   AGE
configmap-demo     3      7s


# 定义一个pod

apiVersion: v1
kind: Pod
metadata: 
  name: configmap-demo-map
spec:
  containers:
    - name: demo
      image: nginx
      # 变量注入
      env:
        - name: ZZZ# 自定义变量
          value: "zzz"
        - name: ABCD# 变量名字
          valueFrom:
            configMapKeyRef:
              name: configmap-demo# 来自于configmap
              key: a
        - name: CDEF
          valueFrom: 
            configMapKeyRef:
              name: configmap-demo
              key: b
      # 数据卷挂载
      volumeMounts:
      - name: config
        mountPath: "/config"# 存放容器中/config目录下
        readOnly: true
  volumes:
    - name: config
      configMap:
        name: configmap-demo
        items:
        - key: "redis.properties"# key与对应configmap.yaml对应
          path: "redis.properties"# 保存在容器中路径
# 执行pod
[root@k8s-master ~]# kubectl apply -f pod-configmap.yaml
# 进入容器
[root@k8s-master ~]# kubectl exec -it configmap-demo-map -- bash

# 验证数据卷挂载
root@configmap-demo-map:/# cat config/redis.properties
port: 6379
host: 192.168.31.10

# 验证变量注入
root@configmap-demo-map:/# echo $CDEF
456

1.5 Secret

与ConfigMap类似，区别于Secret主要存储敏感数据，所有数据要经过base64编码。
应用场景:凭据
kubectl create secret 支持三种数据类型

docker-registry: 存储镜像仓库认证信息
generic:从文件，目录或者字符串创建，例如存储用户名，密码
tls:存储证书，例如HTTPS证书

示例

[root@k8s-master ~]# echo -n 'admin' | base64
[root@k8s-master ~]# echo -n '1f2d1e2e67df' | base64
[root@k8s-master ~]# vi secret.yaml
apiVersion: v1
kind: Secret
metadata:
  name: db-user-pass
type: Opaque
data:
  username: YWRtaW4=
  password: MWYyZDFlMmU2N2Rm

# 应用
[root@k8s-master ~]# kubectl apply -f secret.yaml 
# 查看secret
[root@k8s-master ~]# kubectl get secret
NAME                                 TYPE                                  DATA   AGE
db-user-pass                         Opaque                                2      12s
# 创建一个pod
[root@k8s-master ~]# vi pod-secret.yaml
apiVersion: v1
kind: Pod
metadata:
  name: secret-demo-pod
spec:
  containers:
    - name: demo
      image: nginx
      # 变量注入
      env:
        - name: USER
          valueFrom:
            secretKeyRef:
              name: db-user-pass
              key: username
        - name: PASS
          valueFrom:
            secretKeyRef:
              name: db-user-pass
              key: password
      # 数据卷方式
      volumeMounts:
      - name: config
        mountPath: "/config"
        readOnly: true
  volumes:
    - name: config
      secret:
        secretName: db-user-pass
        items:
        - key: username
          path: my-username
# 应用：
[root@k8s-master ~]# kubectl apply -f pod-secret.yaml 
# 进入pod中
[root@k8s-master ~]# kubectl exec -it secret-demo-pod -- bash
# 变量注入方式验证
root@secret-demo-pod:/# echo $USER
admin
root@secret-demo-pod:/# echo $PASS
1f2d1e2e67df
# 数据卷方式验证
root@secret-demo-pod:/# cat /config/my-username
admin

2.pv和pvc管理存储

PersistentVolume(PV):对存储资源创建和使用的抽象，使得存储作为集群中的资源管理。
PersistentVolumeClaim(PVC): 让用户不需要关系具体的Volume实现细节。
示例

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: deply-pvc
  name: deploy-pvc
spec:
  replicas: 2
  selector:
    matchLabels:
      app: deploy-pvc
  strategy: {}
  template:
    metadata:
      labels:
        app: deploy-pvc
    spec:
      containers:
      - image: nginx
        name: nginx
        resources: {}
        volumeMounts:
        - name: data
          mountPath: /usr/share/nginx/html
      volumes:
      - name: data
        persistentVolumeClaim:# 卷资源pvc
          claimName: my-pvc# 申请空间pvc名字
---
# pvc分配的存储资源
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1Gi
# 此时创建pod处于Pending状态 查看pod详情
kubectl describe pod deploy-pvc-6994b7ff4b-k8wgb
# Events报错：
Warning  FailedScheduling  7m27s  default-scheduler  0/2 nodes are available: 2 pod has unbound immediate PersistentVolumeClaims.
# 表示PVC没有绑定PV，需要创建一个PV
# 创建的PV,指定存储的资源
vi pv.yaml
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv00001
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  nfs:
    path: /ifs/kubernetes
    server: 172.16.215.141
# 应用:挂载存储
kubectl apply -f pv.yaml
# 此时刚才创建的pvc开始创建，运行。如何查看pv与pvc绑定
kubectl get pv,pvc

NAME                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM            STORAGECLASS   REASON   AGE
persistentvolume/pv00001   1Gi        RWX            Retain           Bound    default/my-pvc                           96s

NAME                           STATUS   VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
persistentvolumeclaim/my-pvc   Bound    pv00001   1Gi        RWX                           15m

# 可以看到pv与pvc已经进行绑定

当创建多个pv为保证多个pv之间数据隔离，会在nfs上创建多个目录

/ifs/
└── kubernetes
    ├── pv00001
    ├── pv00002
    └── pv00003

此时pv.yaml应该如下定义多个yaml块

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv00001
spec:
  capacity:
    storage: 1Gi
  accessModes:
    - ReadWriteMany
  nfs:
    path: /ifs/kubernetes/pv00001
    server: 172.16.215.141
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv00002
spec:
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteMany
  nfs:
    path: /ifs/kubernetes/pv00002
    server: 172.16.215.141
---
apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv00003
spec:
  capacity:
    storage: 3Gi
  accessModes:
    - ReadWriteMany
  nfs:
    path: /ifs/kubernetes/pv00003
    server: 172.16.215.141

当又创建一个应用。

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: deply-pvc
  name: deploy-pvc2
spec:
  replicas: 2
  selector:
    matchLabels:
      app: deploy-pvc
  strategy: {}
  template:
    metadata:
      labels:
        app: deploy-pvc
    spec:
      containers:
      - image: nginx
        name: nginx
        resources: {}
        volumeMounts:
        - name: data
          mountPath: /usr/share/nginx/html
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: my-pvc2
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc2
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1.5Gi

此时通过kubectl get pvc

[root@k8s-master ~]# kubectl get pvc
NAME      STATUS   VOLUME    CAPACITY   ACCESS MODES   STORAGECLASS   AGE
my-pvc    Bound    pv00001   1Gi        RWX                           32m
my-pvc2   Bound    pv00002   2Gi        RWX                           2m12s
# 可以看到创建第一个和第二个应用分别绑定了pv00001和pv00002

PV生命周期

accessModes:访问模式
	AccessModes是用来对PV进行访问模式的设置，用于描述用户应用对存储资源访问权限，访问权限包括下面几种。
		ReadWriteOnce(RWO): 读写权限，但是只能被单个节点挂载
		ReadOnlyMany(ROX): 只读权限，可以被多个节点挂载
		ReadWriteMany(RWX): 读写权限，可以被多个节点挂载
RECLAIM POLICY(回收策略)
	通过 kubectl get pv 命令，查看RECLAIM POLICY列，目前有3种策略
		Retain(保留)：保留数据，需要管理员手工清理数据
		Recycle(回收)：清除PV中的数据，效果相当于rm -rf
		Delete(删除): 与PV相连后端存储同时删除
STATUS 状态
	表示一个PV生命周期状态。
		Available(可用): 表示可用状态，还未被任何PVC绑定
		Bound(已绑定): 表示PV已经被PVC绑定
		Released(已释放): PVC被删除，但是资源还未被集群重新声明
		Failed(失败): 表示该PV的自动回收失败

PV与PVC常见问题

1.PV与PVC之间关系？
	一个PV对应一个PVC
2.PV与PVC怎么匹配？
	根据存储空间，访问模式进行匹配
3.容器匹配策略是什么样的？
	匹配最接近的PV容量，如果满足不了Pod会处于pending状态
4. 存储空间(1Gi,2Gi,...)字段限制使用容量？
	这个字段主要用于做匹配，实际的使用限制取决于后端存储。

现在我们在使用PV为静态供给，需要k8s工程师创建一大堆PV供开发者使用。PV静态供给维护成本过高，通过StorageClass动态进行PV供给可减少维护成本。

3.PV动态供给(StorageClass)

基于NFS实现PV动态供给流程图
NFS外部资源调配

GitHub复制文件class.yaml,deployment.yaml,rbac.yaml。yaml文件下载地址

class.yaml 用于存储类

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: managed-nfs-storage
provisioner: k8s-sigs.io/nfs-subdir-external-provisioner # or choose another name, must match deployment's env PROVISIONER_NAME'
parameters:
  archiveOnDelete: "false"

deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-client-provisioner
  labels:
    app: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: default
spec:
  replicas: 1
  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: lizhenliang/nfs-subdir-external-provisioner:v4.0.1
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: k8s-sigs.io/nfs-subdir-external-provisioner
            - name: NFS_SERVER
              value: 172.16.215.141# NFS服务器IP
            - name: NFS_PATH
              value: /ifs/kubernetes# 共享目录
      volumes:
        - name: nfs-client-root
          nfs:
            server: 172.16.215.141# NFS服务器IP
            path: /ifs/kubernetes# 挂载容器的目录

rbac.yaml为了连接k8s的api进行授权

apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-client-provisioner
  # replace with namespace where provisioner is deployed
  namespace: default
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: nfs-client-provisioner-runner
rules:
  - apiGroups: [""]
    resources: ["nodes"]
    verbs: ["get", "list", "watch"]
  - 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
    # replace with namespace where provisioner is deployed
    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
  # replace with namespace where provisioner is deployed
  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
  # replace with namespace where provisioner is deployed
  namespace: default
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
    # replace with namespace where provisioner is deployed
    namespace: default
roleRef:
  kind: Role
  name: leader-locking-nfs-client-provisioner
  apiGroup: rbac.authorization.k8s.io

目录结构

nfs-external-rpovisioner/
├── class.yaml
├── deployment.yaml
└── rbac.yaml

应用
```
kubectl apply -f .
```

查看存储类

[root@k8s-master nfs-external-rpovisioner]# kubectl get sc
NAME                  PROVISIONER                                   RECLAIMPOLICY   VOLUMEBINDINGMODE   ALLOWVOLUMEEXPANSION   AGE
managed-nfs-storage   k8s-sigs.io/nfs-subdir-external-provisioner   Delete          Immediate           false                  10s

查看pod

[root@k8s-master nfs-external-rpovisioner]# kubectl get pods
NAME                                      READY   STATUS              RESTARTS   AGE
nfs-client-provisioner-6f5bf84fc9-srrf8   0/1     Running   0          50s

创建一个deployment看是否能动态供给

# storageClassName 设置存储类名字，通过 kubectl get sc 获取存储类的名字。
vi deploy-storageclass.yaml 

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: deply-pvc
  name: deploy-storageclass
spec:
  replicas: 2
  selector:
    matchLabels:
      app: deploy-pvc
  strategy: {}
  template:
    metadata:
      labels:
        app: deploy-pvc
    spec:
      containers:
      - image: nginx
        name: nginx
        resources: {}
        volumeMounts:
        - name: data
          mountPath: /usr/share/nginx/html
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: my-sc
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-sc
spec:
  storageClassName: "managed-nfs-storage"
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 1.5Gi

创建pod

[root@k8s-master ~]# kubectl apply -f deploy-storageclass.yaml

在NFS服务器172.16.215.141可以看到/ifs/kubernetes目录下有default-my-sc-pvc-d94fb9a6-d6ed-4511-9077-18487bfd1985可以知道自动创建一个目录，这个目录就是PV动态供给创建目录

我们进入一个容器内

kubectl exec -it deploy-storageclass-7584589f8c-ltqg4 bash

cd /usr/share/nginx/html/
# 创建一个文件
touch 1.txt
# 此时查看NFS服务器上的default-my-sc-pvc-d94fb9a6-d6ed-4511-9077-18487bfd1985目录下也多了一个文件1.txt

动态供给分配的存储资源，是看你pod要求分配的是多少存储资源。
需要知道是动态存储的类不是一对一关系，可以重复使用，它就好像提供一个接口一样，重复调用。

4.有状态应用部署：StatefulSet控制器

Deployment控制器设计原则：管理所有pod一模一样，提供同一个服务，不需要考虑多副本之间的关系是否有独立存储，也不考虑在哪台Node运行，可随意扩容和缩容，这种应用称为‘无状态’，例如web服务。
在实际场景中，这并不能满足所有应用，尤其是分布式应用，会部署多个实例，这些实例之间往往有依赖关系，例如：主从关系，主备关系，这种应用称为‘有状态’，例如MySQL主从，Etcd集群。
StatefulSet
- 用于部署有状态应用
- 解决pod独立生命周期，保持pod启动顺序和唯一性。
```
1.稳定，唯一网络标识符，持久存储
2.有序, 优雅的部署和扩展，删除和终止。
3.有序，滚动更新
```
- 应用场景：分布式应用,数据库集群
稳定的网络ID
- 使用Headless Service (相比普通Service只是将spec.clusterIP定义为None)来维护Pod网络身份。并且添加ServiceName字段指定StatefulSet控制器要使用这个Headless Service。DNS解析名称：. , .svc.cluster.local
稳定的存储
- StatefulSet存储卷使用VolumeClaimTemplate创建，称为卷申请模版，当StatefulSet使用VolumeClaimTemplate创建一个PV(PersistentVolume)时，同样也会为每个pod分配并创建一个编号的PVC
如部署一个MySQL主从：
- 主从实例启动顺序
- 主从实例数据目录唯一
- 从连接主实例需要指定IP或主机名
这里拿nginx做实例，部署statefulSet

# 新增一个statefulSet的基本模版yaml文件
[root@k8s-master ~]# kubectl create deployment sts --image=nginx --dry-run=client -o yaml > sts.yaml

# 暴漏一个service
[root@k8s-master ~]# kubectl expose deployment deploy-pvc --port=80 --target-port=80 --dry-run=client -o yaml > svc.yaml

# 编写demployment的service为StatefulSet






# vi sts.yaml
apiVersion: apps/v1
kind: StatefulSet#设置StatefulSet控制器
metadata:
  labels:
    app: sts
  name: sts
spec:
  serviceName: "sts"# 指定serviceName，用户指定Headless Service
  replicas: 2
  selector:
    matchLabels:
      app: sts
  template:
    metadata:
      labels:
        app: sts
    spec:
      containers:
      - image: nginx
        name: nginx
        resources: {}
        volumeMounts:# 定义挂载目录
        - name: www
          mountPath: /usr/share/nginx/html
  volumeClaimTemplates:# volumeClaimTemplates 为每个pod分配独立pv。只支持StatefulSet
  - metadata:
      name: www
    spec:
      accessModes: [ "ReadWriteOnce" ]#单pod读写模式，一个pvc只能被一个pod独享，
      storageClassName: "managed-nfs-storage"# 存储类，为上面提前设置好的。
      resources:
        requests:
          storage: 1Gi
---
apiVersion: v1
kind: Service
metadata:
  labels:
    app: sts
  name: sts
spec:
  clusterIP: None# Headless Service是将clusterIP置为None,因为是一个有状态的service。
  ports:
  - port: 80
    protocol: TCP
    targetPort: 80
  selector:
    app: sts


# 应用
kubectl apply -f sts.yaml

# kubectl get pods 可以看到，pod进行有序的启动（部署）
sts-0                                    1/1     Running   0          10m
sts-1                                    1/1     Running   0          9m53s

# 为每个pod分配稳定身份
[root@k8s-master ~]# kubectl get ep
NAME                                          ENDPOINTS                                                        AGE
sts                                           10.244.85.204:80,10.244.85.205:80                                25m


[root@k8s-master ~]# kubectl get svc
NAME         TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)        AGE
sts          ClusterIP   None           <none>        80/TCP         27m



# 创建一个沙箱
[root@k8s-master ~]# kubectl run -it --rm --image=busybox:1.28.4 -- sh
# deploy-nfs 通过 CLUSTER-IP 进行解析
/ # nslookup deploy-nfs
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local
# 而sts并没有 CLUSTER-IP 通过pod IP进行解析
/ # nslookup sts
Server:    10.96.0.10
Address 1: 10.96.0.10 kube-dns.kube-system.svc.cluster.local

Name:      sts
Address 1: 10.244.85.205 sts-0.sts.default.svc.cluster.local
Address 2: 10.244.85.204 sts-1.sts.default.svc.cluster.local

当我们对sts.yaml进行升级时候比如nginx版本升级更高版本

# 重新apply
kubectl apply -f sts.yaml
# 升级的顺序是从后向前升级，也就是先sts-1再sts-0

StatefulSet和Deployment区别

主要是身份区别：
	域名
	主机名
	存储（PVC）

总结

1如果是不需额外数据依赖或者状态维护的部署，或者replicas是1，优先考虑使用Deployment；
2如果单纯的要做数据持久化，防止pod宕掉重启数据丢失，那么使用pv/pvc就可以了；
3如果要打通app之间的通信，而又不需要对外暴露，使用headlessService即可；
4如果需要使用service的负载均衡，不要使用StatefulSet，尽量使用clusterIP类型，用serviceName做转发；
5如果是有多replicas，且需要挂载多个pv且每个pv的数据是不同的，因为pod和pv之间是 一 一对应的，如果某个pod挂6掉再重启，还需要连接之前的pv，不能连到别的pv上，考虑使用StatefulSet
6能不用StatefulSet，就不要用

posted @ 2021-06-04 23:19 是阿凯啊阅读(663) 评论(0) 编辑收藏举报

刷新页面返回顶部

阿凯