从0到1使用Kubernetes系列(六):数据持久化实战
本文是从0到1使用Kubernetes系列第六篇,上一篇《从0到1使用Kubernetes系列(五):Kubernetes Scheduling》介绍了Kubernetes调度器如何进行资源调度,本文将为大家介绍几种常用储存类型。
默认情况下Pod挂载在磁盘上的文件生命周期与Pod生命周期是一致的,若Pod出现崩溃的情况,kubelet 将会重启它,这将会造成Pod中的文件将丢失,因为Pod会以镜像最初的状态重新启动。在实际应用当中,开发者有很多时候需要将容器中的数据保留下来,比如在Kubernetes中部署了MySql,不能因为MySql容器挂掉重启而上面的数据全部丢失;其次,在 Pod 中同时运行多个容器时,这些容器之间可能需要共享文件。也有的时候,开发者需要预置配置文件,使其在容器中生效,例如自定义了mysql.cnf文件在MySql启动时就需要加载此配置文件。这些都将是今天将要实战解决的问题。
今天这篇文将讲解下面几种常用存储类型:
- secret
- configMap
- emptyDir
- hostPath
- nfs
- persistentVolumeClaim
SECRET
Secret对象允许您存储和管理敏感信息,例如密码,OAuth令牌和ssh密钥。将此类信息放入一个secret中可以更好地控制它的用途,并降低意外暴露的风险。
▌使用场景
鉴权配置文件挂载
▌使用示例
在CI中push构建好的镜像就可以将docker鉴权的config.json文件存入secret对象中,再挂载到CI的Pod中,从而进行权限认证。
- 首先创建secret
$ kubectl create secret docker-registry docker-config --docker-server=https://hub.docker.com --docker-username=username --docker-password=password secret/docker-config created
- 新建docker-pod.yaml文件,粘贴以下信息:
apiVersion: v1 kind: Pod metadata: name: docker spec: containers: - name: docker image: docker command: - sleep - "3600" volumeMounts: - name: config mountPath: /root/.docker/ volumes: - name: config secret: secretName: docker-config items: - key: .dockerconfigjson path: config.json mode: 0644
- Docker Pod挂载secret
$ kubectl apply -f docker-pod.yaml pod/docker created
- 查看挂载效果
$ kubectl exec docker -- cat /root/.docker/config.json {"auths":{"https://hub.docker.com":{"username":"username","password":"password","auth":"dXNlcm5hbWU6cGFzc3dvcmQ="}}}
- 清理环境
$ kubectl delete pod docker $ kubectl delete secret docker-config
ConfigMap
许多应用程序会从配置文件、命令行参数或环境变量中读取配置信息。这些配置信息需要与docker image解耦ConfigMap API给我们提供了向容器中注入配置信息的机制,ConfigMap可以被用来保存单个属性,也可以用来保存整个配置文件。
▌使用场景
配置信息文件挂载
▌使用示例
使用ConfigMap中的数据来配置Redis缓存
- 创建example-redis-config.yaml文件,粘贴以下信息:
apiVersion: v1 kind: ConfigMap metadata: name: example-redis-config data: redis-config: | maxmemory 2b maxmemory-policy allkeys-lru
- 创建ConfigMap
$ kubectl apply -f example-redis-config.yaml configmap/example-redis-config created
- 创建example-redis.yaml文件,粘贴以下信息:
apiVersion: v1 kind: Pod metadata: name: redis spec: containers: - name: redis image: kubernetes/redis:v1 env: - name: MASTER value: "true" ports: - containerPort: 6379 resources: limits: cpu: "0.1" volumeMounts: - mountPath: /redis-master-data name: data - mountPath: /redis-master name: config volumes: - name: data emptyDir: {} - name: config configMap: name: example-redis-config items: - key: redis-config path: redis.conf
- Redis Pod挂载ConfigMap测试
$ kubectl apply -f example-redis.yaml pod/redis created
- 查看挂载效果
$ kubectl exec -it redis redis-cli $ 127.0.0.1:6379> CONFIG GET maxmemory 1) "maxmemory" 2) "2097152" $ 127.0.0.1:6379> CONFIG GET maxmemory-policy 1) "maxmemory-policy" 2) "allkeys-lru"
- 清理环境
$ kubectl delete pod redis $ kubectl delete configmap example-redis-config
EmptyDir
当使用emptyDir卷的Pod在节点创建时,会在该节点创建一个新的空目录,只要该Pod运行在该节点,该目录会一直存在,Pod内的所有容器可以将改目录挂载到不同的挂载点,但都可以读写emptyDir内的文件。当Pod不论什么原因被删除,emptyDir的数据都会永远被删除(一个Container Crash 并不会在该节点删除Pod,因此在Container crash时,数据不会丢失)。默认情况下,emptyDir支持任何类型的后端存储:disk、ssd、网络存储。也可以通过设置 emptyDir.medium 为Memory,kubernetes会默认mount一个tmpfs(RAM-backed filesystem),因为是RAM Backed,因此 tmpfs 通常很快。但是会在容器重启或者crash时,数据丢失。
▌使用场景
同一Pod内各容器共享存储
▌使用示例
在容器a中生成hello文件,通过容器b输出文件内容
- 创建test-emptydir.yaml文件,粘贴以下信息:
apiVersion: v1 kind: Pod metadata: name: test-emptydir spec: containers: - image: alpine name: container-a command: - /bin/sh args: - -c - echo 'I am container-a' >> /cache-a/hello && sleep 3600 volumeMounts: - mountPath: /cache-a name: cache-volume - image: alpine name: container-b command: - sleep - "3600" volumeMounts: - mountPath: /cache-b name: cache-volume volumes: - name: cache-volume emptyDir: {}
- 创建Pod
kubectl apply -f test-emptydir.yaml pod/test-emptydir created
- 测试
$ kubectl exec test-emptydir -c container-b -- cat /cache-b/hello I am container-a
- 清理环境
$ kubectl delete pod test-emptydir
HostPath
将宿主机对应目录直接挂载到运行在该节点的容器中。使用该类型的卷,需要注意以下几个方面:
- 使用同一个模板创建的Pod,由于不同的节点有不同的目录信息,可能会导致不同的结果
- 如果kubernetes增加了已知资源的调度,该调度不会考虑hostPath使用的资源
- 如果宿主机目录上已经存在的目录,只可以被root可以写,所以容器需要root权限访问该目录,或者修改目录权限
▌使用场景
运行的容器需要访问宿主机的信息,比如Docker内部信息/var/lib/docker目录,容器内运行cadvisor,需要访问/dev/cgroups
▌使用示例
使用Docker socket binding模式在列出宿主机镜像列表。
- 创建test-hostpath.yaml文件,粘贴以下信息:
apiVersion: v1 kind: Pod metadata: name: test-hostpath spec: containers: - image: docker name: test-hostpath command: - sleep - "3600" volumeMounts: - mountPath: /var/run/docker.sock name: docker-sock volumes: - name: docker-sock hostPath: path: /var/run/docker.sock type: Socket
- 创建test-hostpath Pod
$ kubectl apply -f test-hostpath.yaml pod/test-hostpath created
- 测试是否成功
$ kubectl exec test-hostpath docker images REPOSITORY IMAGE ID CREATED SIZE docker 639de9917ae1 13 days ago 171MB ...
NFS存储卷
NFS 卷允许将现有的 NFS(网络文件系统)共享挂载到您的容器中。不像 emptyDir,当删除 Pod 时,nfs 卷的内容被保留,卷仅仅是被卸载。这意味着 nfs 卷可以预填充数据,并且可以在 pod 之间共享数据。 NFS 可以被多个写入者同时挂载。
- 重要提示:您必须先拥有自己的 NFS 服务器然后才能使用它。
▌使用场景
不同节点Pod使用统一nfs共享目录
▌使用示例
- 创建test-nfs.yaml文件,粘贴以下信息:
apiVersion: apps/v1 kind: Deployment metadata: name: test-nfs spec: selector: matchLabels: app: store replicas: 2 template: metadata: labels: app: store spec: volumes: - name: data nfs: server: nfs.server.com path: / affinity: podAntiAffinity: requiredDuringSchedulingIgnoredDuringExecution: - labelSelector: matchExpressions: - key: app operator: In values: - store topologyKey: "kubernetes.io/hostname" containers: - name: alpine image: alpine command: - sleep - "3600" volumeMounts: - mountPath: /data name: data
- 创建测试deployment
$ kubectl apply -f test-nfs.yaml deployment/test-nfs created
- 查看pod运行情况
$ kubectl get po -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE test-nfs-859ccfdf55-kkgxj 1/1 Running 0 1m 10.233.68.245 uat05 <none> test-nfs-859ccfdf55-aewf8 1/1 Running 0 1m 10.233.67.209 uat06 <none>
- 进入Pod中进行测试
# 进入uat05节点的pod中 $ kubectl exec -it test-nfs-859ccfdf55-kkgxj sh # 创建文件 $ echo "uat05" > /data/uat05 # 退出uat05节点的pod $ edit # 进入uat06节点的pod中 $ kubectl exec -it test-nfs-859ccfdf55-aewf8 sh # 查看文件内容 $ cat /data/uat05 uat05
- 清理环境
$ kubectl delete deployment test-nfs
PersistentVolumeClaim
上面所有例子中我们都是直接将存储挂载到的pod中,那么在kubernetes中如何管理这些存储资源呢?这就是Persistent Volume和Persistent Volume Claims所提供的功能。
● PersistentVolume 子系统为用户和管理员提供了一个 API,该 API 将如何提供存储的细节抽象了出来。为此,我们引入两个新的 API 资源:PersistentVolume 和 PersistentVolumeClaim。
- PersistentVolume(PV)是由管理员设置的存储,它是群集的一部分。就像节点是集群中的资源一样,PV 也是集群中的资源。 PV 是 Volume 之类的卷插件,但具有独立于使用 PV 的 Pod 的生命周期。此 API 对象包含 Volume 的实现,即 NFS、iSCSI 或特定于云供应商的存储系统。
- PersistentVolumeClaim(PVC)是用户存储的请求。它与 Pod 相似。Pod 消耗节点资源,PVC 消耗 PV 资源。Pod 可以请求特定级别的资源(CPU 和内存)。声明可以请求特定的大小和访问模式(例如,可以以读/写一次或 只读多次模式挂载)。虽然 PersistentVolumeClaims 允许用户使用抽象存储资源,但用户需要具有不同性质(例如性能)的 PersistentVolume 来解决不同的问题。集群管理员需要能够提供各种各样的 PersistentVolume,这些PersistentVolume 的大小和访问模式可以各有不同,但不需要向用户公开实现这些卷的细节。对于这些需求,StorageClass 资源可以实现。
● 在实际使用场景里,PV 的创建和使用通常不是同一个人。这里有一个典型的应用场景:管理员创建一个 PV 池,开发人员创建 Pod 和 PVC,PVC 里定义了Pod所需存储的大小和访问模式,然后 PVC 会到 PV 池里自动匹配最合适的 PV 给 Pod 使用。
▌使用示例
- 创建PersistentVolume
apiVersion: v1 kind: PersistentVolume metadata: name: mypv spec: capacity: storage: 5Gi volumeMode: Filesystem accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Recycle storageClassName: slow mountOptions: - hard - nfsvers=4.0 nfs: path: /tmp server: 172.17.0.2
- 创建PersistentVolumeClaim
kind: PersistentVolumeClaim apiVersion: v1 metadata: name: myclaim spec: accessModes: - ReadWriteOnce volumeMode: Filesystem resources: requests: storage: 5Gi volumeName: mypv
- 创建Pod绑定PVC
kind: Pod apiVersion: v1 metadata: name: mypod spec: containers: - name: myfrontend image: nginx volumeMounts: - mountPath: "/var/www/html" name: mypd volumes: - name: mypd persistentVolumeClaim: claimName: myclaim
- 查看pod运行情况验证绑定结果
$ kubectl get po -o wide NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE mypod 1/1 Running 0 1m 10.233.68.249 uat05 <none> $ kubectl exec -it mypod sh $ ls /var/www/html
- 清理环境
$ kubectl delete pv mypv $ kubectl delete pvc myclaim $ kubectl delete po mypod
总结
本次实战中使用了secret存储docker认证凭据,更好地控制它的用途,并降低意外暴露的风险。
使用configMap对redis进行缓存配置,这样即使redis容器挂掉重启configMap中的配置依然会生效。接着又使用emptyDir来使得同一Pod中多个容器的目录共享,在实际应用中开发者通常使用initContainers来进行预处理文件,然后通过emptyDir传递给Containers。然后再使用hostPath来访问宿主机的资源,当网路io达不到文件读写要求时,可考虑固定应用只运行在一个节点上然后使用hostPath来解决文件读写速度的要求。
NFS和PersistentVolumeClaim的例子实质上都是试容器挂载的nfs服务器共享目录,但这些资源一般都只掌握在了管理员手中,开发人员想要获取这部分资源那么就不是这么友好了,动态存储类(StorageClass)就能很好的解决此类问题。
更多关于Kubernetes系列的文章:
- 从0到1使用Kubernetes系列(五):Kubernetes Scheduling
- 从0到1使用Kubernetes系列(四):搭建第一个应用程序
- 从0到1使用Kubernetes系列(三):使用Ansible安装Kubernetes集群
- 从0到1使用Kubernetes系列(二)——安装工具介绍
- 从0到1使用Kubernetes系列——Kubernetes入门
关于Choerodon猪齿鱼
Choerodon猪齿鱼开源多云集成平台,基于开源技术Kubernetes,Istio,knative,Gitlab和Spring Cloud来实现本地和云端环境的集成,实现企业多云/混合云应用环境的一致性。平台通过提供精益敏捷、持续交付、容器环境、微服务、DevOps等能力来帮助组织团队来完成软件的生命周期管理,从而更快、更频繁地交付更稳定的软件。
大家也可以通过以下社区途径了解猪齿鱼的最新动态、产品特性,以及参与社区贡献:
- 官网:http://choerodon.io
- 论坛:http://forum.choerodon.io
- Github:https://github.com/choerodon
- 微信公众号:Choerodon猪齿鱼
- 微博:Choerodon猪齿鱼

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
基于oauth 2.0 实现第三方开放平台
本文单纯从简单的技术实现来讲,不涉及开放平台的多维度的运营理念。 什么是开放平台 通过开放自己平台产品服务的各种API接口,让其他第三方开发者在开发应用时根据需求直接调用,例如微信登录、QQ登录、微信支付、微博登录、热门等。 让第三方应用通过开发平台,使得自身海量数据资源得到沉淀(变现) 目前国内主流的网站的的开放平台,都是基于oauth2.0 协议进行做的开放平台 微信开放平台授权机制流程图 微博开放平台授权机制流程图 oauth2.0 授权码模式 授权码模式(authorization code)是功能最完整、流程最严密的授权模式。 它的特点就是通过客户端的后台服务器,与"服务提供商"的认证服务器进行互动,能够满足绝大多数开放平台认证授权的需求。 引入相关依赖 <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-oauth2</artifactId> </dependency> &l...
- 下一篇
关于零拷贝的一点认识
前言 从字面意思理解就是数据不需要来回的拷贝,大大提升了系统的性能;这个词我们也经常在java nio,netty,kafka,RocketMQ等框架中听到,经常作为其提升性能的一大亮点;下面从I/O的几个概念开始,进而在分析零拷贝。 I/O概念 1.缓冲区 缓冲区是所有I/O的基础,I/O讲的无非就是把数据移进或移出缓冲区;进程执行I/O操作,就是向操作系统发出请求,让它要么把缓冲区的数据排干(写),要么填充缓冲区(读);下面看一个java进程发起read请求加载数据大致的流程图: 进程发起read请求之后,内核接收到read请求之后,会先检查内核空间中是否已经存在进程所需要的数据,如果已经存在,则直接把数据copy给进程的缓冲区;如果没有内核随即向磁盘控制器发出命令,要求从磁盘读取数据,磁盘控制器把数据直接写入内核read缓冲区,这一步通过DMA完成;接下来就是内核将数据copy到进程的缓冲区; 如果进程发起write请求,同样需要把用户缓冲区里面的数据copy到内核的socket缓冲区里面,然后再通过DMA把数据copy到网卡中,发送出去; 你可能觉得这样挺浪费空间的,每次都需要...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库
- Red5直播服务器,属于Java语言的直播服务器
- Eclipse初始化配置,告别卡顿、闪退、编译时间过长
- SpringBoot2全家桶,快速入门学习开发网站教程
- CentOS7设置SWAP分区,小内存服务器的救世主
- CentOS7安装Docker,走上虚拟化容器引擎之路
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- CentOS8安装Docker,最新的服务器搭配容器使用
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程