医疗网站的建设设计要注意什么问题,河南做网站汉狮,网站建设费计入无形资产,成品源码1988为什么需要数据卷#xff1f; 容器中的文件在磁盘上是临时存放的#xff0c;这给容器中运行比较重要的应用程序带来一些问题问题1#xff1a;当容器升级或者崩溃时#xff0c;kubelet会重建容器#xff0c;容器内文件会丢失问题2#xff1a;一个Pod中运行多个容器并需要共… 为什么需要数据卷 容器中的文件在磁盘上是临时存放的这给容器中运行比较重要的应用程序带来一些问题 问题1当容器升级或者崩溃时kubelet会重建容器容器内文件会丢失 问题2一个Pod中运行多个容器并需要共享文件 kubenetes卷Volume这一抽象概念能够解决这两个问题 常用的数据卷 • 节点本地hostPath emptyDir • 网络NFS Ceph GlusterFS • 公有云AWS EBS • K8S资源configmap secret emptyDir卷 是一个临时存储卷与Pod生命周期绑定一起如果Pod删除了卷也会被删除。 应用场景 Pod中容器之间数据共享 案例 apiVersion: v1
kind: Pod
metadata:name: pod-emptydir
spec:containers:- image: centoscommand: [bash,-c,for i in {1..100};do echo $i /data/hello;sleep 1;done]name: writevolumeMounts:- mountPath: /dataname: cache-volume- image: centoscommand: [bash,-c,tail -f /data/hello]name: readvolumeMounts:- mountPath: /dataname: cache-volumevolumes:- name: cache-volumeemptyDir: {} 节点数据卷 hostPath hostPath卷 挂载Node文件系统Pod所在节点上文件或者目录到Pod中的容器。 应用场景 Pod中容器需要访问宿主机文件 案例 apiVersion: v1
kind: Pod
metadata:name: pod-emptydir
spec:containers:- image: centoscommand: [bash,-c,for i in {1..100};do echo $i /data/hello;sleep 1;done]name: writevolumeMounts:- mountPath: /dataname: cache-volume- image: centoscommand: [bash,-c,tail -f /data/hello]name: readvolumeMounts:- mountPath: /dataname: cache-volumevolumes:- name: cache-volumeemptyDir: {} 网络数据卷 NFS NFS卷 提供对NFS挂载支持可以自动将NFS共享路径 挂载到Pod中 NFS 是一个主流的文件共享服务器。 # yum install nfs-utils #设置用于同步数据的目录读写权限 # vi /etc/exports /ifs/kubernetes *(rw,no_root_squash) # mkdir -p /ifs/kubernetes # systemctl start nfs # systemctl enable nfs 注每个Node上都要安装nfs-utils包因为会使用到某些依赖。 示例将Nginx网站程序根目录持久化到 NFS存储为多个Pod提供网站程序文件 apiVersion: apps/v1
kind: Deployment
metadata:labels:app: webname: web-nfs
spec:replicas: 3selector:matchLabels:app: webstrategy: {}template:metadata:labels:app: webspec:containers:- image: nginxname: nginxvolumeMounts:- name: datamountPath: /usr/share/nginx/htmlvolumes:- name: datanfs:server: 192.168.40.132path: /ifs/kubernetes 持久数据卷概述 PersistentVolumePV 对存储资源创建和使用的抽象使得存储作为集群中的资源管理 PersistentVolumeClaimPVC 让用户不需要关心具体的Volume实现细节 pvc申请容量 pv提供存储 1、pvc与pv的匹配策略 pvc匹配最接近的大于自己申请容量的pv如果满足不了pod处于pending Pod申请PVC作为卷来使用 Kubernetes通过PVC查找绑定的PV并Mount给Pod。 PV与PVC使用流程 PV生命周期 AccessModes访问模式 AccessModes是用来对PV进行访问模式的设置用于描述用户应用对存储资源的访问权限访问权限包括下面几种方式 •ReadWriteOnceRWO读写权限但是只能被单个节点挂载 •ReadOnlyManyROX只读权限可以被多个节点挂载 •ReadWriteManyRWX读写权限可以被多个节点挂载 RECLAIM POLICY回收策略 目前PV支持的策略有三种 •Retain保留保留数据需要管理员手工清理数据 •Recycle回收清除PV中的数据效果相当于执行rm-rf /ifs/kuberneres/* •Delete删除与PV相连的后端存储同时删除 STATUS状态 一个PV的生命周期中可能会处于4中不同的阶段 •Available可用表示可用状态还未被任何PVC绑定 •Bound已绑定表示PV已经被PVC绑定 •Released已释放PVC被删除但是资源还未被集群重新声明 •Failed失败表示该PV的自动回收失败 目前PV使用方式称为静态供给需要K8s运维工程师提前创建一堆PV供开发者使用。 PV 动态供给StorageClass PV静态供给明显的缺点是维护成本太高了因此 K8s开始支持PV动态供给使用StorageClass对象实现。 K8s默认不支持NFS动态供给需要单独部署社区开发的插件。 项目地址 GitHub - kubernetes-sigs/nfs-subdir-external-provisioner: Dynamic sub-dir volume provisioner on a remote NFS server. 部署 cd deploy
kubectl apply -f rbac.yaml # 授权访问apiserver
kubectl apply -f deployment.yaml # 部署插件需修改里面NFS服务器地址与共享目录
kubectl apply -f class.yaml # 创建存储类
kubectl get sc # 查看存储类 StorageClass测试案例在创建pvc时指定存储类名称 基于NFS实现PV动态供给流程图 StatefulSet 控制器介绍 无状态与有状态 Deployment控制器设计原则管理的所有Pod一模一样提供同一个服务也不考虑在哪台Node运 行可随意扩容和缩容。这种应用称为“无状态”例如Web服务 在实际的场景中这并不能满足所有应用尤其是分布式应用会部署多个实例这些实例之间往往有依赖关系例如主从关系、主备关系这种应用称为“有状态”例如MySQL主从、 Etcd集群 StatefulSet控制器用于部署有状态应用满足一些有状态应用的需求 • Pod有序的部署、扩容、删除和停止 • Pod分配一个稳定的且唯一的网络标识 • Pod分配一个独享的存储 StatefulSet 部署应用实践 • 稳定的网络ID域名 使用Headless Service相比普通Service只是将spec.clusterIP定义为None来维护Pod网络身份。 并且添加serviceName: “nginx” 字段指定StatefulSet控制器要使用这个Headless Service。 DNS解析名称 statefulsetName-index.service-name .namespace-name.svc.cluster.local • 稳定的存储 StatefulSet的存储卷使用VolumeClaimTemplate创建称为卷申请模板当StatefulSet使用VolumeClaimTemplate创建 一个PersistentVolume时同样也会为每个Pod分配并创建一个编号的PVC。 StatefulSet与Deployment区别 有身份的 身份三要素 • 域名 • 主机名 • 存储PVC 应用程序数据存储 • ConfigMap存储配置文件 • Secret存储敏感数据 ConfigMap 存储应用配置 创建ConfigMap后数据实际会存储在K8s中Etcd然后通过创建Pod时引用该数据。 应用场景应用程序配置 Pod使用configmap数据有两种方式 • 变量注入 • 数据卷挂载 ConfigMap 存储应用配置 Secret 存储敏感信息 与ConfigMap类似区别在于Secret主要存储敏感数据所有的数据要经过base64编码。 应用场景凭据 kubectl create secret 支持三种数据类型 • docker-registry存储镜像仓库认证信息 • generic存储用户名、密码 • tls存储证书 Secret 存储敏感信息案例 当创建容器时出现Pending状态可以通过以下命令查看 kubectl describe pod pod名称 1、pvc与pv匹配条件 主要参考存储容量和访问模式 2、pvc与pv的关系 一对一 3、存储容量能限制嘛 目前不能主要用于匹配限制主要取决于后端存储。 存储类型 1、共享存储例如NFS直接能多台机器挂载 2、块存储例如硬盘、Ceph只能挂载到单个机器上并且需要先格式化 3、对象存储例如阿里云OSS通过API访问 每个pod不等对怎么体现的不对等角色 配置文件节点标识、IP唯一、数据存储 部署一个etcd3个pod肯定是一个镜像。 如何区分3个pod的角色 启动容器时候启动不同的配置文件并且这一步是自动化的。 自动化如何去做如何自适应k8s机制 主要是连接另一个pod的域名、决定自身角色的条件 怎么决定自身角色 可以根据pod主机名决定编号。 假设当前起的第一个pod编号肯定是0容器启动时执行自动化脚本脚本就可以根据编号角色启动的配置。