ConfigMap - 文件存储
许多应用程序会从配置文件、命令行参数或环境变量中读取配置信息。ConfigMap API 给我们提供了向容器中注入配置信息的机制，ConfigMap 可以被用来保存单个属性，也可以用来保存整个配置文件或者 JSON 二进制大对象.
使用键值创建ConfigMap。
$ kubectl create configmap my-env --from-literal=myenv.key=xiejunyou$ kubectlget configmaps my-en -o yaml
使用目录/文件创建ConfigMap，将目录中文件创建为键值对，文件名为建，文件内容为值。
$ kubectl create configmap my-nginx-config-file --from-file=/data/test/storage/config/demain.conf$ kubectlget configmaps my-nginx-config-file -o yaml
ConfigMap 作为脚本参数使用
apiVersion: v1kind: Podmetadata:name: my-cm-env-podspec:containers:- name: my-cm-envimage: busyboxcommand: ["/bin/sh","-c","env"]env:- name: MY_NAME_XIEJUNYOUvalueFrom:configMapKeyRef:name: my-envkey: myenv.keyrestartPolicy: Never
ConfigMap 挂载卷
apiVersion: v1kind: Podmetadata:name: my-cm-nginx-podspec:containers:- name: my-nginx-containerimage: k8s.gcr.io/busyboxcommand: [ "/bin/sh","-c","cat /etc/config/nginx.conf" ]volumeMounts:- name: config-volumemountPath: /etc/configvolumes:- name: config-volumeconfigMap:# ConfigMap 名称name: my-nginx-config-fileitems:# ConfigMap 建- key: demain.conf# 挂载的文件名path: nginx.confrestartPolicy: Never
热更新ConfigMap值
kubectl edit configmap my-nginx-config-file
设置pod滚动更新
$ kubectl patch deployment my-nginx --patch'{"spec": {"template": {"metadata": {"annotations":{"version/config": "20190411" }}}}}'
！！！更新 ConfigMap 后：
使用该 ConfigMap 挂载的 Env 不会同步更新
使用该 ConfigMap 挂载的 Volume 中的数据需要一段时间（实测大概10秒）才能同步更新
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 的认证信息
Volume - 本地存储
容器磁盘上的文件的生命周期是短暂的，这就使得在容器中运行重要应用时会出现一些问题。首先，当容器崩溃时，kubelet 会重启它，但是容器中的文件将丢失——容器以干净的状态（镜像最初的状态）重新启动。其次，在Pod中同时运行多个容器时，这些容器之间通常需要共享文件。Kubernetes 中的Volume抽象就很好的解决了这些问题
Kubernetes 中的卷有明确的寿命 —— 与封装它的 Pod 相同。所以，卷的生命比 Pod 中的所有容器都长，当这个容器重启时数据仍然得以保存。当然，当 Pod 不再存在时，卷也将不复存在。也许更重要的是，Kubernetes支持多种类型的卷，Pod 可以同时使用任意数量的卷
emptyDir 同一Pod中多个容器共享目录，Pod被删除时目录被删除 当 Pod 被分配给节点时，首先创建emptyDir卷，并且只要该 Pod 在该节点上运行，该卷就会存在。正如卷的名字所述，它最初是空的。Pod 中的容器可以读取和写入emptyDir卷中的相同文件，尽管该卷可以挂载到每个容器中的相同或不同路径上。当出于任何原因从节点中删除 Pod 时，emptyDir中的数据将被永久删除
emptyDir的用法有：
暂存空间，例如用于基于磁盘的合并排序
用作长时间计算崩溃恢复时的检查点
Web服务器容器提供数据时，保存内容管理器容器提取的文件 ```yaml apiVersion: v1 kind: Pod metadata: name: volume-emtydir-test spec: containers:- image: k8s.gcr.io/busybox
name: test1
command: [“/bin/sh”,”-c”,”sleep 6000”]
volumeMounts:
- mountPath: /test1 name: cache-volume
- image: k8s.gcr.io/busybox
name: test2
command: [“/bin/sh”,”-c”,”sleep 6000”]
volumeMounts:
- mountPath: /test2 name: cache-volume volumes:
- name: cache-volume emptyDir: {}
- image: k8s.gcr.io/busybox
name: test1
command: [“/bin/sh”,”-c”,”sleep 6000”]
volumeMounts:
2. hostPath 将node文件系统 挂载到机器内
hostPath的用途如下：<br /> 运行需要访问 Docker 内部的容器；使用/var/lib/docker的hostPath<br /> 在容器中运行 cAdvisor；使用/dev/cgroups的hostPath<br /> 允许 pod 指定给定的 hostPath 是否应该在 pod 运行之前存在，是否应该创建，以及它应该以什么形式存在<br /> 使用这种卷类型是请注意，因为：<br /> 由于每个节点上的文件都不同，具有相同配置（例如从 podTemplate 创建的）的 pod 在不同节点上的行为可能会有所不同<br /> 当 Kubernetes 按照计划添加资源感知调度时，将无法考虑hostPath使用的资源<br /> 在底层主机上创建的文件或目录只能由 root 写入。您需要在特权容器中以 root 身份运行进程，或修改主机上的文件权限以便写入hostPath卷
```yaml
apiVersion: v1
kind: Pod
metadata:
name: volume-hostpath-test
spec:
containers:
- image: k8s.gcr.io/busybox
name: test1
command: ["/bin/sh","-c","sleep 6000"]
volumeMounts:
- mountPath: /test-hostpath1
name: test-volume
volumes:
- name: test-volume
hostPath:
path: /data/data
type: Directory
PV/**PVC - 持久存储**
PersistentVolume（PV）是由管理员设置的存储，它是群集的一部分。就像节点是集群中的资源一样，PV 也是集群中的资源。 PV 是Volume 之类的卷插件，但具有独立于使用 PV 的 Pod 的生命周期。此 API 对象包含存储实现的细节，即 NFS、iSCSI 或特定于云供应商的存储系统
PersistentVolumeClaim（PVC）是用户存储的请求。它与 Pod 相似。Pod 消耗节点资源，PVC 消耗 PV 资源。Pod 可以请求特定级别的资源（CPU 和内存）。声明可以请求特定的大小和访问模式（例如，可以以读/写一次或只读多次模式挂载）
持久化卷声明的保护 PVC 保护的目的是确保由 pod 正在使用的 PVC 不会从系统中移除，因为如果被移除的话可能会导致数据丢失当启用PVC 保护 alpha 功能时，如果用户删除了一个 pod 正在使用的 PVC，则该 PVC 不会被立即删除。PVC 的删除将被推迟，直到 PVC 不再被任何 pod 使用
PV 访问模式
PersistentVolume 可以以资源提供者支持的任何方式挂载到主机上。如下表所示，供应商具有不同的功能，每个PV 的访问模式都将被设置为该卷支持的特定模式。例如，NFS 可以支持多个读/写客户端，但特定的 NFS PV 可能以只读方式导出到服务器上。每个 PV 都有一套自己的用来描述特定功能的访问模式
ReadWriteOnce(RWO) —— 该卷可以被单个节点以读/写模式挂载
ReadOnlyMany(ROX) —— 该卷可以被多个节点以只读模式挂载
ReadWriteMany(RWX) —— 该卷可以被多个节点以读/写模式挂载在命令行中
回收策略
Retain（保留）——手动回收
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
[root@k8s-master nfs]# yum install -y nfs-common nfs-utils rpcbind
[root@k8s-master nfs]# mkdir nfs1 nfs2
[root@k8s-master nfs]# chmod 666 nfs1/ nfs2/
[root@k8s-master nfs]# chown nfsnobody nfs1/ nfs2/
[root@k8s-master nfs]# cat /etc/exports
/data/devops/test/docker/nfs/nfs1 *(rw,no_root_squash,no_all_squash,sync)
/data/devops/test/docker/nfs/nfs2 *(rw,no_root_squash,no_all_squash,sync)
[root@k8s-master nfs]# systemctl start rpcbind
[root@k8s-master nfs]# systemctl start nfs
#客户端安装
[root@k8s-master storage]# yum install nfs-utils
创建PV
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-nfs1
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteOnce
persistentVolumeReclaimPolicy: Retain
storageClassName: nfs
nfs:
path: /python/devops/test/docker/nfs/nfs1
server: 192.168.200.147
---
apiVersion: v1
kind: PersistentVolume
metadata:
name: pv-nfs2
spec:
capacity:
storage: 1Gi
accessModes:
- ReadWriteMany
persistentVolumeReclaimPolicy: Retain
storageClassName: nfs
nfs:
path: /python/devops/test/docker/nfs/nfs2
server: 192.168.200.147
创建PVC
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: pvc-test
spec:
storageClassName: nfs
accessModes:
- ReadWriteMany
resources:
requests:
storage: 1Gi
PVC应用于多个Pod
apiVersion: v1
kind: Pod
metadata:
name: pod-pvc-test
spec:
volumes:
- name: pvc-test-storage
persistentVolumeClaim:
claimName: pvc-test
containers:
- name: pod-pvc-container
image: k8s.gcr.io/busybox
command: ["/bin/sh","-c","sleep 6000"]
volumeMounts:
- mountPath: "/opt"
name: pvc-test-storage
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: deployment-pvc-test
spec:
replicas: 2
template:
metadata:
labels:
app: nginx
spec:
volumes:
- name: pvc-test-storage
persistentVolumeClaim:
claimName: pvc-test
containers:
- name: nginx
image: nginx:1.7.9
ports:
- containerPort: 80
volumeMounts:
- mountPath: "/opt"
name: pvc-test-storage
PVC应用于StatefulSet
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: pvc-test
spec:
selector:
matchLabels:
app: nginx
replicas: 1
serviceName: "nginx"
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: pvc-test-containers
image: k8s.gcr.io/busybox
command: ["/bin/sh","-c","sleep 8000"]
volumeMounts:
- name: www
mountPath: /opt
volumeClaimTemplates:
- metadata:
name: www
spec:
accessModes: ["ReadWriteMany"]
storageClassName: "nfs"
resources:
requests:
storage: 200M
关于 StatefulSet
匹配 Pod name ( 网络标识 ) 的模式为：$(statefulset名称)-$(序号)，比如上面的示例：web-0，web-1，web-2
StatefulSet 为每个 Pod 副本创建了一个 DNS 域名，这个域名的格式为： $(podname).(headless servername)，也就意味着服务间是通过Pod域名来通信而非 Pod IP，因为当Pod所在Node发生故障时， Pod 会被飘移到其它 Node 上，Pod IP 会发生变化，但是 Pod 域名不会有变化
StatefulSet 使用 Headless 服务来控制 Pod 的域名，这个域名的 FQDN 为：$(servicename).$(namespace).svc.cluster.local，其中，“cluster.local” 指的是集群的域名
根据 volumeClaimTemplates，为每个 Pod 创建一个 pvc，pvc 的命名规则匹配模式：(volumeClaimTemplates.name)-(pod_name)，比如上面的 volumeMounts.name=www， Podname=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 来实现。
有序收缩。
若有收获，就点个赞吧
0 人点赞
