7.k8s存储
一、configmap
存储配置文件
ConfigMap 功能在kubernetes1.2版本中引入， 许多应用程序会从配置文件，命令行参数或环境变量中读取配置信息。 ConfigMap API 给我们提供了向容器中注入配置信息的机制， ConfigMap可以被用来保存单个属性， 也可以用来存储整个配置文件或者JSON二进制大对象
ConfigMap的创建
- 使用目录创建
$ ls docs/user-guide/configmap/kubectl/
game.properties
ui.properties
$ cat docs/user-guide/configmap/kubectl/game.properties
enemies=aliens
lives=3
enemies.cheat=true
enemies.cheat.level=noGoodRotten
secret.code.passphrase=UUDDLRLRBABAS
secret.code.allowed=true
secret.code.lives=30
$ cat docs/user-guide/configmap/kubectl/ui.properties
color.good=purple
color.bad=yellow
allow.textmode=true
how.nice.to.look=fairlyNice
$ kubectl create configmap game-config --from-file=docs/user-guide/configmap/kubectl
—from-file 指定在目录下的所有文件都会被用在 ConfigMap 里面创建一个键值对，键的名字就是文件名，值就 是文件的内容
II、使用文件创建
只要指定为一个文件就可以从单个文件中创建 ConfigMap
kubectl create configmap game-config-2 --from-file=docs/user-guide/configmap/kubectl/game.properties
kubectl get configmaps game-config-2 -o yaml
—from-file 这个参数可以使用多次，你可以使用两次分别指定上个实例中的那两个配置文件，效果就跟指定整个 目录是一样的
III、使用字面值创建
使用文字值创建，利用 —from-literal 参数传递配置信息，该参数可以使用多次，格式如下
kubectl create configmap special-config --from-literal=special.how=very --from-literal=special.type=charm
kubectl get configmaps special-config -o yaml
Pod中使用ConfigMap
-
使用ConfigMap来替代环境变量
apiVersion: v1 kind: ConfigMap metadata: name: special-config namespace: default data: special.how: very special.type: charmapiVersion: v1 kind: ConfigMap metadata: name: env-config namespace: default data: log_level: INFOapiVersion: v1 kind: Pod metadata: name: dapi-test-pod spec: containers: - name: test-container image: nginx command: [ "/bin/sh", "-c", "env" ] env: - name: SPECIAL_LEVEL_KEY valueFrom: configMapKeyRef: name: special-config key: special.how - name: SPECIAL_TYPE_KEY valueFrom: configMapKeyRef: name: special-config key: special.type envFrom: - configMapRef: name: env-config restartPolicy: NeverII、用 ConfigMap 设置命令行参数
apiVersion: v1 kind: ConfigMap metadata: name: special-config namespace: default data: special.how: very special.type: charmapiVersion: v1 kind: Pod metadata: name: dapi-test-pod2 spec: containers: - name: test-container image: nginx command: [ "/bin/sh", "-c", "echo $(SPECIAL_LEVEL_KEY) $(SPECIAL_TYPE_KEY)" ] env: - name: SPECIAL_LEVEL_KEY valueFrom: configMapKeyRef: name: special-config key: special.how - name: SPECIAL_TYPE_KEY valueFrom: configMapKeyRef: name: special-config key: special.type restartPolicy: NeverIII、通过数据卷插件使用ConfigMap
apiVersion: v1 kind: ConfigMap metadata: name: special-config namespace: default data: special.how: very special.type: charm在数据卷里面使用这个 ConfigMap，有不同的选项。最基本的就是将文件填入数据卷，在这个文件中，
键就是文 件名，键值就是文件内容
apiVersion: v1 kind: Pod metadata: name: dapi-test-pod spec: containers: - name: test-container image: nginx command: [ "/bin/sh", "-c", "cat /etc/config/special.how" ] volumeMounts: - name: config-volume mountPath: /etc/config volumes: - name: config-volume configMap: name: special-config restartPolicy: NeverConfigMap 的热更新
apiVersion: v1 kind: ConfigMap metadata: name: log-config namespace: default data: log_level: INFO --- apiVersion: apps/v1 kind: Deployment metadata: name: my-nginx spec: replicas: 1 selector: matchLabels: run: my-nginx template: metadata: labels: run: my-nginx spec: containers: - name: my-nginx image: nginx ports: - containerPort: 80 volumeMounts: - name: config-volume mountPath: /etc/config volumes: - name: config-volume configMap: name: log-configkubectl exec `kubectl get pods -l run=my-nginx -o=name|cut -d "/" -f2` cat /etc/config/log_level INFO修改 ConfigMap
$ kubectl edit configmap log-config修改 log_level 的值为 DEBUG 等待大概 10 秒钟时间，再次查看环境变量的值
$ kubectl exec `kubectl get pods -l run=my-nginx -o=name|cut -d "/" -f2` cat /tmp/log_level DEBUGConfigMap 更新后滚动更新 Pod
更新 ConfigMap 目前并不会触发相关 Pod 的滚动更新，可以通过修改 pod annotations 的方式强制触发滚动更新
kubectl patch deployment my-nginx --patch '{"spec": {"template": {"metadata": {"annotations": {"version/config": "20190411" }}}}}'这个例子里我们在 .spec.template.metadata.annotations 中添加 version/config ，每次通过修改 version/config 来触发滚动更新
!!! 更新 ConfigMap 后:
使用该 ConfigMap 挂载的 Env 不会同步更新
使用该 ConfigMap 挂载的 Volume 中的数据需要一段时间(实测大概10秒)才能同步更新
二、Secret
存储秘钥
Secret 存在意义
Secret 解决了密码、token、密钥等敏感数据的配置问题，而不需要把这些敏感数据暴露到镜像或者 Pod Spec
中。Secret 可以以 Volume 或者环境变量的方式使用
Secret 有三种类型:
- Service Account :用来访问 Kubernetes API，由 Kubernetes 自动创建，并且会自动挂载到 Pod 的 /run/secrets/kubernetes.io/serviceaccount 目录中
- Opaque :base64编码格式的Secret，用来存储密码、密钥等
- kubernetes.io/dockerconfigjson :用来存储私有 docker registry 的认证信息
Service Account
Service Account 用来访问 Kubernetes API，由 Kubernetes 自动创建，并且会自动挂载到 Pod的
/run/secrets/kubernetes.io/serviceaccount 目录中
$ kubectl run nginx --image nginx
deployment "nginx" created
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx-3137573019-md1u2 1/1 Running 0 13s
$ kubectl exec nginx-3137573019-md1u2 ls /run/secrets/kubernetes.io/serviceaccount
ca.crt
namespace
token
Opaque Secret
I、创建说明
Opaque 类型的数据是一个 map 类型，要求 value 是 base64 编码格式:
$ echo -n "admin" | base64
YWRtaW4=
$ echo -n "1f2d1e2e67df" | base64
MWYyZDFlMmU2N2Rm
secrets.yml
apiVersion: v1
kind: Secret
metadata:
name: mysecret
type: Opaque
data:
password: MWYyZDFlMmU2N2Rm
username: YWRtaW4=
II、使用方式
1、将 Secret 挂载到 Volume 中
apiVersion: v1
kind: Pod
metadata:
labels:
name: seret-test
name: seret-test
spec:
volumes:
- name: secrets
secret:
secretName: mysecret
containers:
- image: nginx:1.9.1
name: db
volumeMounts:
- name: secrets
mountPath: "/etc/secrets"
readOnly: true
2、将 Secret 导出到环境变量中
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: pod-deployment
spec:
replicas: 2
template:
metadata:
labels:
app: pod-deployment
spec:
containers:
- name: pod-1
image: hub.atguigu.com/library/myapp:v1
ports:
- containerPort: 80
env:
- name: TEST_USER
valueFrom:
secretKeyRef:
name: mysecret
key: username
- name: TEST_PASSWORD
valueFrom:
secretKeyRef:
name: mysecret
key: password
kubernetes.io/dockerconfigjson
使用 Kuberctl 创建 docker registry 认证的 secret
$ kubectl create secret docker-registry myregistrykey --docker-server=DOCKER_REGISTRY_SERVER --
docker-username=DOCKER_USER --docker-password=DOCKER_PASSWORD --docker-email=DOCKER_EMAIL
secret "myregistrykey" created.
实例
kubectl create secret docker-registry myregistrykey --docker-server=hub.syuee.com --
docker-username=admin --docker-password=Harbor12345 --docker-email=sivan@syuee.com
在创建 Pod 的时候，通过 imagePullSecrets 来引用刚创建的 myregistrykey
apiVersion: v1
kind: Pod
metadata:
name: foo
spec:
containers:
- name: foo
image: roc/awangyang:v1
imagePullSecrets:
- name: myregistrykey
三、Volume
共享存储如NFS，cephFS
容器磁盘上的文件的生命周期是短暂的，这就使得在容器中运行重要应用时会出现一些问题。首先，当容器崩溃 时，kubelet 会重启它，但是容器中的文件将丢失——容器以干净的状态(镜像最初的状态)重新启动。其次，在
Pod 中同时运行多个容器时，这些容器之间通常需要共享文件。Kubernetes 中的 Volume 抽象就很好的解决了 这些问题
背景
Kubernetes 中的卷有明确的寿命 —— 与封装它的 Pod 相同。所f以，卷的生命比 Pod 中的所有容器都长，当这 个容器重启时数据仍然得以保存。当然，当 Pod 不再存在时，卷也将不复存在。也许更重要的是，Kubernetes 支持多种类型的卷，Pod 可以同时使用任意数量的卷
卷的类型
Kubernetes 支持以下类型的卷:
- awsElasticBlockStore azureDisk azureFile cephfs csi downwardAPI emptyDir
- fc flocker gcePersistentDisk gitRepo glusterfs hostPath iscsi local nfs
- persistentVolumeClaim projected portworxVolume quobyte rbd scaleIO secret
- storageos vsphereVolume
emptyDir
当 Pod 被分配给节点时，首先创建 emptyDir 卷，并且只要该 Pod 在该节点上运行，该卷就会存在。正如卷的名 字所述，它最初是空的。Pod 中的容器可以读取和写入 emptyDir 卷中的相同文件，尽管该卷可以挂载到每个容 器中的相同或不同路径上。当出于任何原因从节点中删除 Pod 时， emptyDir 中的数据将被永久删除
emptyDir 的用法有:
- 暂存空间，例如用于基于磁盘的合并排序
- 用作长时间计算崩溃恢复时的检查点
- Web服务器容器提供数据时，保存内容管理器容器提取的文件
apiVersion: v1
kind: Pod
metadata:
name: test-pd
spec:
containers:
- image: nginx
name: test-container
volumeMounts:
- mountPath: /cache
name: cache-volume
volumes:
- name: cache-volume
emptyDir: {}
apiVersion: v1
kind: Pod
metadata:
name: test-pd2
spec:
containers:
- image: mysql
name: testcontainer
imagePullPolicy: IfNotPresent
command: ['/bin/sh','-c','sleep 6000s']
volumeMounts:
- mountPath: /cache
name: cache-volume
- image: busybox
name: testbusybox
imagePullPolicy: IfNotPresent
command: ['/bin/sh','-c','sleep 6000s']
volumeMounts:
- mountPath: /test
name: cache-volume
volumes:
- name: cache-volume
emptyDir: {}
hostPath
hostPath 卷将主机节点的文件系统中的文件或目录挂载到集群中
hostPath 的用途如下:
- 运行需要访问 Docker 内部的容器;使用 /var/lib/docker 的 hostPath
- 在容器中运行 cAdvisor;使用 /dev/cgroups 的 hostPath
- 允许 pod 指定给定的 hostPath 是否应该在 pod 运行之前存在，是否应该创建，以及它应该以什么形式存在
除了所需的 path 属性之外，用户还可以为 hostPath 卷指定 type
| 值 | 行为 |
|---|---|
| 空字符串（默认）用于向后兼容， 这意味着在挂载hostPath卷之前不会执行任何检查 | |
| DirectoryOrCcreate | 如果在给定的路径上没有任何东西存在， 那么将根据需要在那里创建一个空目录，权限设置为0755， 与kubelet具有相同的组和所有权 |
| Directory | 给定的路径下必须存在目录 |
| FileOrCreate | 如果在给定的路径上没有任何东西存在， 那么会根据需要创建一个空文件， 权限设置为0644， 与Kubelet具有相同的组合所有权 |
| File | 给定的路径下必须存在文件 |
| Socket | 给定的路径下必须存储UNIX套接字 |
| CharDevice | 给定的路径下必须存在字符设备 |
| BlokDevice | 给定的路径下必须存在块设备 |
使用这种卷类型是请注意，因为:
- 由于每个节点上的文件都不同， 具有相同配置（例如从podTemplate创建的）的pod在不同的节点上的行为可能会有所不同
- 当kubernetes按照计划添加资源感知调度时， 将无法考虑hostPath使用的资源
- 在底层主机上创建的文件或目录只能由root写入， 您需要在特权容器中以root身份运行进程， 或修改主机上的文件权限以便写入hostPath卷
apiVersion: v1
kind: Pod
metadata:
name: test-pd
spec:
containers:
- image: nginx
name: test-container
volumeMounts:
- mountPath: /test-pd
name: test-volume
volumes:
- name: test-volume
hostPath:
# directory location on host
path: /data
# this field is optional
type: Directory
四、PV-PVC
持久卷
概念
PersistentVolume (PV)
是由管理员设置的存储，它是群集的一部分。就像节点是集群中的资源一样，PV 也是集群中的资源。 PV 是 Volume 之类的卷插件，但具有独立于使用 PV 的 Pod 的生命周期。此 API 对象包含存储实现的细节，即 NFS、 iSCSI 或特定于云供应商的存储系统
PersistentVolumeClaim (PVC)
是用户存储的请求。它与 Pod 相似。Pod 消耗节点资源，PVC 消耗 PV 资源。Pod 可以请求特定级别的资源
(CPU 和内存)。声明可以请求特定的大小和访问模式(例如，可以以读/写一次或 只读多次模式挂载)
静态 pv
集群管理员创建一些 PV。它们带有可供群集用户使用的实际存储的细节。它们存在于 Kubernetes API 中，可用 于消费
动态
当管理员创建的静态 PV 都不匹配用户的 PersistentVolumeClaim 时，集群可能会尝试动态地为 PVC 创建卷。此 配置基于 StorageClasses :PVC 必须请求 [存储类]，并且管理员必须创建并配置该类才能进行动态创建。声明该 类为 "" 可以有效地禁用其动态配置
要启用基于存储级别的动态存储配置，集群管理员需要启用 API server 上的 DefaultStorageClass [准入控制器] 。例如，通过确保 DefaultStorageClass 位于 API server 组件的 --admission-control 标志，使用逗号分隔的 有序值列表中，可以完成此操作
绑定
master 中的控制环路监视新的 PVC，寻找匹配的 PV(如果可能)，并将它们绑定在一起。如果为新的 PVC 动态 调配 PV，则该环路将始终将该 PV 绑定到 PVC。否则，用户总会得到他们所请求的存储，但是容量可能超出要求 的数量。一旦 PV 和 PVC 绑定后， PersistentVolumeClaim 绑定是排他性的，不管它们是如何绑定的。 PVC 跟 PV 绑定是一对一的映射
持久化卷声明的保护
PVC 保护的目的是确保由 pod 正在使用的 PVC 不会从系统中移除，因为如果被移除的话可能会导致数据丢失
当启用PVC 保护 alpha 功能时，如果用户删除了一个 pod 正在使用的 PVC，则该 PVC 不会被立即删除。PVC 的 删除将被推迟，直到 PVC 不再被任何 pod 使用
持久化卷类型
PersistentVolume 类型以插件形式实现。Kubernetes 目前支持以下插件类型:
- GCEPersistentDisk AWSElasticBlockStore AzureFile AzureDisk FC (Fibre Channel)
- FlexVolume Flocker NFS iSCSI RBD (Ceph Block Device) CephFS
- Cinder (OpenStack block storage) Glusterfs VsphereVolume Quobyte Volumes
- HostPath VMware Photon Portworx Volumes ScaleIO Volumes StorageOS
持久卷演示代码
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv0003
spec:
capacity:
storage: 5Gi
volumeMode: Filesystem
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Recycle
storageClassName: slow
mountOptions:
- hard
- nfsvers=4.1
nfs:
path: /tmp
server: 172.17.0.2
PV 访问模式
PersistentVolume 可以以资源提供者支持的任何方式挂载到主机上。如下表所示，供应商具有不同的功能，每个 PV 的访问模式都将被设置为该卷支持的特定模式。例如，NFS 可以支持多个读/写客户端，但特定的 NFS PV 可能 以只读方式导出到服务器上。每个 PV 都有一套自己的用来描述特定功能的访问模式
- ReadWriteOnce——该卷可以被单个节点以读/写模式挂载
- ReadOnlyMany——该卷可以被多个节点以只读模式挂载
- ReadWriteMany——该卷可以被多个节点以读/写模式挂载
在命令行中，访问模式缩写为:
-
RWO - ReadWriteOnce
-
ROX - ReadOnlyMany
-
RWX - ReadWriteMany
回收策略
-
Retain(保留)——手动回收
-
Recycle(回收)——基本擦除( rm -rf /thevolume/* )
-
Delete(删除)——关联的存储资产(例如 AWS EBS、GCE PD、Azure Disk 和 OpenStack Cinder 卷) 将被删除
当前，只有 NFS 和 HostPath 支持回收策略。AWS EBS、GCE PD、Azure Disk 和 Cinder 卷支持删除策略
状态
卷可以处于以下的某种状态:
- Available(可用)——一块空闲资源还没有被任何声明绑定
- Bound(已绑定)——卷已经被声明绑定
- Released(已释放)——声明被删除，但是资源还未被集群重新声明
- Failed(失败)——该卷的自动回收失败
命令行会显示绑定到 PV 的 PVC 的名称
持久化演示说明 - NFS
I、安装 NFS 服务器
yum install -y nfs-common nfs-utils rpcbind
mkdir /nfs
chmod 755 /nfs
chown nfsnobody /nfs
cat /etc/exports
/nfs *(rw,no_root_squash,no_all_squash,sync)
systemctl start rpcbind
systemctl start nfs
showmount -e 192.168.31.100
sshpass -p 123456 ssh -o "StrictHostKeyChecking no" -l root 192.168.31.72 'yum install -y rpcbind nfs-utils '
sshpass -p 123456 ssh -o StrictHostKeyChecking=no -l root 192.168.31.73 'yum install -y rpcbind nfs-utils;mkdir /test ;mount -t nfs 192.168.31.100:/nfs /test'
sshpass -p 123456 ssh -o StrictHostKeyChecking=no -l root 192.168.31.74 'yum install -y rpcbind nfs-utils;mkdir /test ;mount -t nfs 192.168.31.100:/nfs /test'
sshpass -p 123456 ssh -o StrictHostKeyChecking=no -l root 192.168.31.71 'yum install -y rpcbind nfs-utils;mkdir /test ;mount -t nfs 192.168.31.100:/nfs /test'
II、部署 PV
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfspv1
spec:
capacity:
storage: 10Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain # 新版不支持Recycle
storageClassName: nfs
nfs:
path: /nfs
server: 192.168.31.100
创建多个pv
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfspv2
spec:
capacity:
storage: 5Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain # 新版不支持Recycle
storageClassName: nfs
nfs:
path: /nfs1
server: 192.168.31.100
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfspv3
spec:
capacity:
storage: 5Gi
accessModes:
- ReadOnlyMany
persistentVolumeReclaimPolicy: Retain # 新版不支持Recycle
storageClassName: nfs
nfs:
path: /nfs2
server: 192.168.31.100
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: nfspv4
spec:
capacity:
storage: 50Gi
accessModes:
- ReadWriteMany
persistentVolumeReclaimPolicy: Retain # 新版不支持Recycle
storageClassName: show
nfs:
path: /nfs3
server: 192.168.31.100
III、创建服务并使用 PVC
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:
containers:
- name: nginx
image: nginx-slim:0.8
ports:
- containerPort: 80
name: web
volumeMounts:
- name: www
mountPath: /usr/share/nginx/html
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: [ "ReadWriteOnce" ]
storageClassName: "nfs"
resources:
requests:
storage: 1Gi
关于 StatefulSet
- 匹配 Pod name ( 网络标识 ) 的模式为:\((statefulset名称)-\)(序号)，比如上面的示例:web-0，web-1， web-2
- StatefulSet 为每个 Pod 副本创建了一个 DNS 域名，这个域名的格式为: $(podname).(headless server name)，也就意味着服务间是通过Pod域名来通信而非 Pod IP，因为当Pod所在Node发生故障时， Pod 会 被飘移到其它 Node 上，Pod IP 会发生变化，但是 Pod 域名不会有变化
- StatefulSet 使用 Headless 服务来控制 Pod 的域名，这个域名的 FQDN 为:\((service name).\)(namespace).svc.cluster.local，其中，“cluster.local” 指的是集群的域名
- 根据 volumeClaimTemplates，为每个 Pod 创建一个 pvc，pvc 的命名规则匹配模式: (volumeClaimTemplates.name)-(pod_name)，比如上面的 volumeMounts.name=www， Pod name=web-[0-2]，因此创建出来的 PVC 是 www-web-0、www-web-1、www-web-2
- 删除 Pod 不会删除其 pvc，手动删除 pvc 将自动释放 pv
Statefulset的启停顺序:
- 有序部署:部署StatefulSet时，如果有多个Pod副本，它们会被顺序地创建(从0到N-1)并且，在下一个Pod运行之前所有之前的Pod必须都是Running和Ready状态。
- 有序删除:当Pod被删除时，它们被终止的顺序是从N-1到0。
- 有序扩展:当对Pod执行扩展操作时，与部署一样，它前面的Pod必须都处于Running和Ready状态。
StatefulSet使用场景:
- 稳定的持久化存储，即Pod重新调度后还是能访问到相同的持久化数据，基于 PVC 来实现。
- 稳定的网络标识符，即 Pod 重新调度后其 PodName 和 HostName 不变。
- 有序部署，有序扩展，基于 init containers 来实现。
- 有序收缩。
