英文介绍做美食视频网站,网站app建设需要资源,网站怎么做站群,企业网站的开发背景和概念 容器中的文件在磁盘上是临时存放的#xff0c;这给在容器中运行较重要的应用带来一些问题#xff1a; 当容器崩溃或停止时#xff0c;此时容器状态未保存#xff0c; 因此在容器生命周期内创建或修改的所有文件都将丢失。另外 在崩溃期间#xff0c;kubelet 会…背景和概念 容器中的文件在磁盘上是临时存放的这给在容器中运行较重要的应用带来一些问题 当容器崩溃或停止时此时容器状态未保存 因此在容器生命周期内创建或修改的所有文件都将丢失。另外 在崩溃期间kubelet 会以干净的状态重新启动容器。 当多个容器在一个 Pod 中运行并且需要共享文件时 跨所有容器设置和访问共享文件系统也有一定的挑战性 有docker使用经历的人应该知道docker内有一个数据卷的概念可以持久化容器内的文件数据同样在k8s体系内使用的也是卷的概念 Kubernetes 支持很多类型的卷。 Pod 可以同时使用任意数目的卷类型。 临时卷类型的生命周期与 Pod 相同 但持久卷可以比 Pod 的存活期长。 当 Pod 不再存在时Kubernetes 也会销毁临时卷不过 Kubernetes 不会销毁持久卷。 对于给定 Pod 中任何类型的卷在容器重启期间数据都不会丢失。 卷的核心是一个目录其中可能存有数据Pod 中的容器可以访问该目录中的数据。 所采用的特定的卷类型将决定该目录如何形成的、使用何种介质保存数据以及目录中存放的内容。 使用卷时, 在 .spec.volumes 字段中设置为 Pod 提供的卷并在 .spec.containers.volumeMounts 字段中声明卷在容器中的挂载位置。 容器中的进程看到的文件系统视图是由它们容器镜像的初始内容以及挂载在容器中的卷所组成的。 其中根文件系统同容器镜像的内容相吻合。 任何在该文件系统下的写入操作如果被允许的话都会影响接下来容器中进程访问文件系统时所看到的内容。 卷挂载在镜像中的指定路径下。 Pod 配置中的每个容器必须独立指定各个卷的挂载位置
常见的卷类型
常见的卷有如下几种类型
configMap configMap 卷提供了向 Pod 注入配置数据的方法。 ConfigMap 对象中存储的数据可以被 configMap 类型的卷引用然后被 Pod 中运行的容器化应用使用注意环境变量也可以使用configMap。hostPath将主机节点文件系统上的文件或目录挂载到你的 Pod 中但是官网现在不推荐使用这个了nfs将 NFS (网络文件系统) 挂载到你的 Pod 中。nfs 卷的内容在删除 Pod 时会被保存卷只是被卸载使用nfs可以可以在 Pod 之间做到数据共享。persistentVolumeClaim 简称PVC是用户在不知道特定云环境细节的情况下申领持久存储例如 iSCSI 卷的一种方法。secret用来给 Pod 传递敏感信息例如密码。你可以将 Secret 存储在 Kubernetes API 服务器上然后以文件的形式挂载到 Pod 中无需直接与 Kubernetes 耦合 当然也有其他类型的卷详细的可查阅k8s官网
案例
一、nfs原生方式挂载卷
企业级生产环境一般会由基础设施部门提供一个nfs地址和目录。受限于我本地测试环境的资源我只能在虚拟机上随意找一台节点来模拟nfs文件系统这里我使用了k8s集群的master节点模拟搭建一个nfs 这里解释一下nfs,他的全称就是网络共享文件系统他可以挂载到任何机器的磁盘目录下做到几台机器间的文件数据同步共享 步骤 1、在所有机器上安装nfs工具
#所有机器安装
yum install -y nfs-utils2、master主节点模拟配置为nfs服务端
#nfs主节点
echo /nfs/data/ *(insecure,rw,sync,no_root_squash) /etc/exportsmkdir -p /nfs/data
systemctl enable rpcbind --now
systemctl enable nfs-server --now
#配置生效
exportfs -r3、worker节点查询nfs服务
showmount -e nfs服务ip可以看到我上一个步骤创建的目录可以查到了 4、挂载到worker节点指定的目录下
# 创建/nfs/data目录执行以下命令挂载 nfs 服务器上的共享目录到本机路径 /nfs/data
mkdir -p /nfs/datamount -t nfs 192.168.xxx.xxx:/nfs/data /nfs/data
# 写入一个测试文件
echo hello nfs server /nfs/data/test2.txt查看同步的test2.txt文件 5、pod挂载nfs
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: nginx-pv-demoname: nginx-pv-demo
spec:replicas: 2selector:matchLabels:app: nginx-pv-demotemplate:metadata:labels:app: nginx-pv-demospec:containers:- image: nginxname: nginxvolumeMounts:- name: htmlmountPath: /usr/share/nginx/htmlvolumes:- name: htmlnfs:server: 192.168.xxx.xxxpath: /nfs/data/nginx-pv这里的意思就是将nfs的/nfs/data/nginx-pv目录挂载到容器内的/usr/share/nginx/html目录这样两边的目录文件就可以做到实时同步了无论任何一个地方的文件有变动对方的目录也会跟着一起变动并且数据始终一致 可以看到上边两个图片中两边目录中的文件已经同步了
二、PVPVC的使用 持久卷PersistentVolumePV 是集群中的一块存储可以由管理员事先制备 或者使用存储类Storage Class来动态制备。 持久卷是集群资源就像节点也是集群资源一样。PV 持久卷和普通的 Volume 一样 也是使用卷插件来实现的只是它们拥有独立于任何使用 PV 的 Pod 生命周期。 此 API 对象中记述了存储的实现细节无论其背后是 NFS、iSCSI 还是特定于云平台的存储系统; 持久卷申领PersistentVolumeClaimPVC 表达的是用户对存储的请求。概念上与 Pod 类似。 Pod 会耗用节点资源而 PVC 申领会耗用 PV 资源。Pod 可以请求特定数量的资源CPU 和内存。同样 PVC 申领也可以请求特定的大小和访问模式 例如可以挂载为 ReadWriteOnce、ReadOnlyMany、ReadWriteMany 或 ReadWriteOncePod) PV 卷的制备有两种方式静态制备或动态制备。静态制备是事先已经创建好的pv动态制备则是基于 StorageClass 来实现为 PVC 申领动态制备一个存储卷 本案例使用静态制备的方式
1、在模拟的nfs服务端创建几个静态的资源空间
#主节点
mkdir -p /nfs/data/01
mkdir -p /nfs/data/02
mkdir -p /nfs/data/032、创建PV分别使用上述的几个目录
apiVersion: v1
kind: PersistentVolume
metadata:name: pv01-10m
spec:capacity:storage: 10MaccessModes:- ReadWriteManystorageClassName: nfsnfs:path: /nfs/data/01server: 192.168.xxx.xxx
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv02-1gi
spec:capacity:storage: 1GiaccessModes:- ReadWriteManystorageClassName: nfsnfs:path: /nfs/data/02server: 192.168.xxx.xxx
---
apiVersion: v1
kind: PersistentVolume
metadata:name: pv03-3gi
spec:capacity:storage: 3GiaccessModes:- ReadWriteManystorageClassName: nfsnfs:path: /nfs/data/03server: 192.168.xxx.xxx3、创建PVC
kind: PersistentVolumeClaim
apiVersion: v1
metadata:name: nginx-pvc1
spec:accessModes:- ReadWriteManyresources:requests:storage: 200MistorageClassName: nfspvc会找到和所需容量相符的PV资源进行绑定并且这种绑定也是一对一的关系 可以看到我们申领的是200M的存储那最接近这个要求的就是pv02-1gi这个资源那此次申领就使用了这个pv卷 4、pod绑定pvc
apiVersion: apps/v1
kind: Deployment
metadata:labels:app: nginx-deploy-pvcname: nginx-deploy-pvc
spec:replicas: 2selector:matchLabels:app: nginx-deploy-pvctemplate:metadata:labels:app: nginx-deploy-pvcspec:containers:- image: nginxname: nginxvolumeMounts:- name: htmlmountPath: /usr/share/nginx/htmlvolumes:- name: htmlpersistentVolumeClaim:claimName: nginx-pvc这里pod是将容器内的/usr/share/nginx/html目录挂载到namehtml的卷内html卷使用的是我创建的nginx-pvc也就是/usr/share/nginx/html目录内的文件会同步到/nfs/data/02目录 从上述截图中可以看到容器内的目录下的文件在nfs中也有了
三、ConfigMap ConfigMap 是一种 API 对象用来将非机密性的数据保存到键值对中。使用时 Pod 可以将其用作环境变量、命令行参数或者存储卷中的配置文件。 ConfigMap 可以将你的环境配置信息和容器镜像解耦便于应用配置的修改。 ConfigMap 并不提供保密或者加密功能。 如果你想存储的数据是机密的请使用 Secret 或者使用其他第三方工具来保证你的数据的私密性 ConfigMap 在设计上不是用来保存大量数据的。在 ConfigMap 中保存的数据不可超过 1 MiB。如果你需要保存超出此尺寸限制的数据你可考虑挂载存储卷或者使用独立的数据库或者文件服务。 本案例使用configMap抽离容器的配置信息 1、创建一个配置文件名称为edis.conf查看该配置文件内的信息 2、基于此文件创建CM
kubectl create cm redis-conf --from-fileredis.conf3、创建pod,使用上述已经建好的configMap
apiVersion: v1
kind: Pod
metadata:name: redis
spec:containers:- name: redisimage: rediscommand:- redis-server- /redis-master/redis.conf #指的是redis容器内部的位置ports:- containerPort: 6379volumeMounts:- mountPath: /dataname: data- mountPath: /redis-mastername: configvolumes:- name: dataemptyDir: {}- name: configconfigMap:name: redis-confitems:- key: redis.confpath: redis.conf4、查看配置信息
# 登录redis,查看配置同步信息
kubectl exec -it redis -- redis-cli -a yes可以看到我CM中的配置已同步到了redis容器内并且登录redis也能看到配置的信息;
四、secret Secret 是一种包含少量敏感信息例如密码、令牌或密钥的对象。 这样的信息可能会被放在 Pod 规约中或者镜像中。 使用 Secret 意味着你不需要在应用程序代码中包含机密数据。 由于创建的Secret 可以独立于使用它们的Pod因此在创建、查看和编辑 Pod 的工作流程中暴露 Secret及其数据的风险较小。Kubernetes 和在集群中运行的应用程序也可以对 Secret 采取额外的预防措施例如避免将敏感数据写入非易失性存储。 Secret类似于ConfigMap但是前者专门用于保存机密数据 本案例使用阿里云作为镜像仓库来通过设置的secret登录阿里云并拉取镜像仓库的私有镜像 1、首先在阿里云服务中要先上传镜像文件并确保镜像文件是私有状态 2、拉取镜像时需要docker login命令登录阿里云服务涉及到账号和密码这里将登录账号信息存储在secret中
kubectl create secret docker-registry my-secret ----docker-serverregistry.cn-hangzhou.aliyuncs.com --docker-usernamealiyun88000000 --docker-password123456这里我创建了一个my-secret的对象在管理端查看效果如下 3、创建pod应用 apiVersion: v1
kind: Pod
metadata:name: my-pod
spec:containers:- name: my-containerimage: registry.cn-hangzhou.aliyuncs.com/wtl-test/test-nginx:1.0imagePullPolicy: AlwaysimagePullSecrets:- name: my-secret #登录密码从my-secret获取pod创建时指定了镜像的仓库地址和密码 4、检查pod启动情况 可以看到镜像已成功获取并启动了pod应用
