本文主要是介绍k8s 总结,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
扫盲
首先强调一点,k8s集群可以在集群中各节点上对容器进行管理。不仅支持对docker容器的管理,还支持对lxd ,rkt的管理。
我们平时对docker的管理,如使用Dockerfile打镜像,使用 dockerCompose 批量启动容器。但是他们只是在一台机器上进行操作,不能跨机器。 例如我们平时的微服务想做负载均衡就得部署到多台机器上,而此时一个一个部署docker也是很费事的操作。而且负载均衡还需要自己配置nginx等;如果运行中一个节点挂掉、怎么监听到并在另一台机器再部署一个同样的服务?对于双十一如何动态增加机器节点或者动态减少节点?如何保证重新部署服务的过程中 访问不中断?等等,这些问题 最终总结起来就是:在多台机器上自动化管理容器。
而k8s就可以做到自动化(注意不是全部自动化,如docker镜像还是要自己通过dockerfile打包的)
k8s 类似于Docker Swarm
k8s能做什么
根据机器负载-跨机器自动部署容器
若部署一个应用2份,则会根据各机器节点的负载 来确定部署到哪台机器。
服务发现/负载均衡
自愈
重新启动失败的容器,在节点不可用时,替换和重新调度节点上的容器,对用户定义的健康检查不响应的容器会被中止,并且在容器准备好服务之前不会把其向客户端广播。
弹性伸缩
通过监控容器的cpu的负载值,如果这个平均高于80%,增加容器的数量,如果这个平均低于10%,减少容器的数量
服务的自动发现和负载均衡:
不需要修改您的应用程序来使用不熟悉的服务发现机制,Kubernetes 为容器提供了自己的 IP 地址和一组容器的单个 DNS 名称,并可以在它们之间进行负载均衡。
滚动升级和一键回滚
Kubernetes 逐渐部署对应用程序或其配置的更改,同时监视应用程序运行状况,以确保它不会同时终止所有实例。 如果出现问题,Kubernetes会为您恢复更改,利用日益增长的部署解决方案的生态系统。
k8s架构/各组件描述
1. k8s/kubernetes
Kubernetes 源于希腊语,意为 “舵手” 或 “飞行员”, 且是英文governor
和 cybernetic
的词根。 K8s 是通过将 8 个字母ubernete
替换为 8 而导出的缩写。
k8s
是谷歌在2014年发布的一个开源项目,其主要用途就是用来管理大量的容器。Kubernetes 建立在 Google 公司超过十余年的运维经验基础之上,Google 所有的应用都运行在容器上。在谷歌内部,使用的容器管理系统叫Borg
,现在已经改名叫Omega
。(就是数学里面经常用到的那个欧米茄符合的读音)所以k8s
其实相当于是Borg
的开源版本。
我们再来看一下k8s官网的说法:
Kubernetes 是一个跨主机集群的 开源的容器调度平台,它可以自动化应用容器的部署、扩展和操作 , 提供以容器为中心的基础架构。
Kubernetes 具有如下特点:
- 便携性: 无论公有云、私有云、混合云还是多云架构都全面支持
- 可扩展: 它是模块化、可插拔、可挂载、可组合的,支持各种形式的扩展
- 自修复: 它可以自保持应用状态、可自重启、自复制、自缩放的,通过声明式语法提供了强大的自修复能力
2. Cluster
Cluster就是集群的意思,即整个k8s管理的所有机器和容器等等的总称。它是计算、存储和网络资源的集合,k8s利用这些资源运行各种基于容器的应用。
3. Master
Master是Cluster中的管理者,即该集群中所有节点的老大或老大们,因为Master可能不止一个,如果是有多个Master节点的集群我们一般称之为高可用集群。它的主要职责是调度,即决定将应用放在哪里运行。
4. Node
Node的职责是运行容器应用。Node由Master管理,Node负责监控并汇报容器的状态,同时根据Master的要求管理容器的生命周期。
5. Pod
Pod是Kubernetes的最小工作单元。每个Pod包含一个或多个容器。Pod中的容器会作为一个整体被Master调度到一个Node上运行。这意味着,即使是只有一个容器,Master也是要把它作为一个Pod调度运行的。
Kubernetes 引入Pod主要基于下面两个目的:
(1)可管理性。
有些容器天生就是需要紧密联系,一起工作。Pod提供了比容器更高层次的抽象,将它们封装到一个部署单元中。Kubernetes以Pod为最小单位进行调度、扩展、共享资源、管理生命周期。
(2)通信和资源共享。
Pod 中的所有容器使用同一个网络namespace,即相同的IP地址和Port空间。它们可以直接用localhost通信。同样的,这些容器可以共享存储,当Kubernetes挂载 volume到Pod,本质上是将volume挂载到Pod中的每一个容器。
6. namespace
Kubernetes支持由同一物理集群支持的多个虚拟集群。这些虚拟集群称为namespace。
namespace旨在用于多个用户分布在多个团队或项目中的环境中。对于具有几个到几十个用户的集群,您根本不需要创建或考虑名称空间。当您需要它们提供的功能时,请开始使用命名空间。
- namespace提供名称范围。
- 资源名称在namespace中必须是唯一的,但是在不同的namespace中不必唯一。
- namespace不能彼此嵌套,并且每个Kubernetes资源只能位于一个namespace中。
- namespace是一种在多个用户之间划分群集资源的方法(通过资源配额)。
- 在Kubernetes的未来版本中,默认情况下,同一namespace中的对象将具有相同的访问控制策略。
- 没有必要使用多个namespace来分隔略有不同的资源,例如同一软件的不同版本:可以使用标签来区分同一namespace中的资源。
Services
Services也是Kubernetes的基本操作单元,是真实应用服务的抽象,每一个服务后面都有很多对应的容器来支持,通过Proxy的port和服务selector决定服务请求传递给后端提供服务的容器,对外表现为一个单一访问接口,外部不需要了解后端如何运行,这给扩展或维护后端带来很大的好处。
Replication Controllers
Replication Controller确保任何时候Kubernetes集群中有指定数量的pod副本(replicas)在运行, 如果少于指定数量的pod副本(replicas),Replication Controller会启动新的Container,反之会杀死多余的以保证数量不变。Replication Controller使用预先定义的pod模板创建pods,一旦创建成功,pod 模板和创建的pods没有任何关联,可以修改pod 模板而不会对已创建pods有任何影响,也可以直接更新通过Replication Controller创建的pods。对于利用pod 模板创建的pods,Replication Controller根据label selector来关联,通过修改pods的label可以删除对应的pods。Replication Controller主要有如下用法:
1)Rescheduling
如上所述,Replication Controller会确保Kubernetes集群中指定的pod副本(replicas)在运行, 即使在节点出错时
2) Scaling
通过修改Replication Controller的副本(replicas)数量来水平扩展或者缩小运行的pods。
3) Rolling updates
Replication Controller的设计原则使得可以一个一个地替换pods来rolling updates服务。
4) Multiple release tracks
如果需要在系统中运行multiple release的服务,Replication Controller使用labels来区分multiple release tracks。
Labels
Labels是用于区分Pod、Service、Replication Controller的key/value键值对,Pod、Service、 Replication Controller可以有多个label,但是每个label的key只能对应一个value。Labels是Service和Replication Controller运行的基础,为了将访问Service的请求转发给后端提供服务的多个容器,正是通过标识容器的labels来选择正确的容器。同样,Replication Controller也使用labels来管理通过pod 模板创建的一组容器,这样Replication Controller可以更加容易,方便地管理多个容器,无论有多少容器。
Master节点
Master 组件提供的集群控制。Master 组件对集群做出全局性决策(例如:调度),以及检测和响应集群事件(副本控制器的replicas
字段不满足时,启动新的副本)。
Master 组件可以在集群中的任何节点上运行。然而,为了简单起见,设置脚本通常会启动同一个虚拟机上所有 Master 组件,并且不会在此虚拟机上运行用户容器。
kube-apiserver
kube-apiserver
对外暴露了Kubernetes API。它是的 Kubernetes 前端控制层。它被设计为水平扩展,即通过部署更多实例来缩放。
API Server 提供HTTP/HTTPS
RESTful
API,即Kubernetes API。API Server是Kubernetes Cluster的前端接口,各种客户端工具(CLI或UI)以及Kubernetes其他组件可以通过它管理Cluster的各种资源。
etcd
etcd
用于 Kubernetes 的后端存储。etcd 负责保存Kubernetes Cluster的配置信息和各种资源的状态信息,始终为 Kubernetes 集群的 etcd 数据提供备份计划。当数据发生变化时,etcd 会快速地通知Kubernetes相关组件。
kube-controller-manager
kube-controller-manager
运行控制器,它们是处理集群中常规任务的后台线程。逻辑上,每个控制器是一个单独的进程,但为了降低复杂性,它们都被编译成独立的可执行文件,并在单个进程中运行。
这些控制器包括:
- 节点控制器(
Node Controller
): 当节点移除时,负责注意和响应。 - 副本控制器(
Replication Controller
): 负责维护系统中每个副本控制器对象正确数量的 Pod。 - 端点控制器(
Endpoints Controller
): 填充 端点(Endpoints) 对象(即连接 Services & Pods)。 - 服务帐户和令牌控制器(
Service Account & Token Controllers
): 为新的namespace创建默认帐户和 API 访问令牌.
kube-scheduler
kube-scheduler监视没有分配节点的新创建的 Pod,选择一个节点供他们运行。Scheduler在调度时会充分考虑Cluster的拓扑结构,当前各个节点的负载,以及应用对高可用、性能、数据亲和性的需求。
Pod 网络
Pod 要能够相互通信,Kubernetes Cluster必须部署Pod网络,flannel是其中一个可选方案。
Node节点
节点组件在每个节点上运行,维护运行的 Pod 并提供 Kubernetes 运行时环境。
kubelet
kubelet是Node的agent,当Scheduler确定在某个Node上运行Pod后,会将Pod的具体配置信息(image、volume等)发送给该节点的kubelet,kubelet根据这些信息创建和运行容器,并向Master报告运行状态。
kubelet是主要的节点代理,它监测已分配给其节点的 Pod(通过 apiserver 或通过本地配置文件),提供如下功能:
- 挂载 Pod 所需要的数据卷(Volume)。
- 下载 Pod 的 secrets。
- 通过 Docker 运行(或通过 rkt)运行 Pod 的容器。
- 周期性的对容器生命周期进行探测。
- 如果需要,通过创建 镜像 Pod(Mirror Pod) 将 Pod 的状态报告回系统的其余部分。
- 将节点的状态报告回系统的其余部分。
kube-proxy
kube-proxy 通过维护主机上的网络规则并执行连接转发,实现了Kubernetes服务抽象。
service在逻辑上代表了后端的多个Pod,外界通过service访问Pod。service接收到的请求就是通过kube-proxy转发到Pod上的。
每个Node都会运行kube-proxy服务,它负责将访问service的TCP/UDP数据流转发到后端的容器。如果有多个副本,kube-proxy会实现负载均衡
docker或rocket
容器引擎,运行容器
组件的区别
pod/Deployment/ReplicationController
pod
可以通过kind: pod 创建pod,不过这种只创建一个pod;
pod就是一个容器组,里面可以包含一个或者多个容器
ReplicationController
Replication Controller也是创建pod;
kind:ReplicationController
主要的功能如下:
- 确保pod数量:它会确保Kubernetes中有指定数量的Pod在运行。如果少于指定数量的pod,Replication Controller会创建新的,反之则会删除掉多余的以保证Pod数量不变。
- 确保pod健康:当pod不健康,运行出错或者无法提供服务时,Replication Controller也会杀死不健康的pod,重新创建新的。
- 弹性伸缩 :在业务高峰或者低峰期的时候,可以通过Replication Controller动态的调整pod的数量来提高资源的利用率。同时,配置相应的监控功能(Hroizontal Pod Autoscaler),会定时自动从监控平台获取Replication Controller关联pod的整体资源使用情况,做到自动伸缩。
- 滚动升级:滚动升级为一种平滑的升级方式,通过逐步替换的策略,保证整体系统的稳定,在初始化升级的时候就可以及时发现和解决问题,避免问题不断扩大。
Deployment
也是创建Pod.
主要职责同样是为了保证pod的数量和健康,90%的功能与Replication Controller完全一样,可以看做新一代的Replication Controller。但是,它又具备了Replication Controller之外的新特性:
- Replication Controller全部功能:Deployment继承了上面描述的Replication Controller全部功能。
- 事件和状态查看:可以查看Deployment的升级详细进度和状态。
- 回滚:当升级pod镜像或者相关参数的时候发现问题,可以使用回滚操作回滚到上一个稳定的版本或者指定的版本。
- 版本记录: 每一次对Deployment的操作,都能保存下来,给予后续可能的回滚使用。
- 暂停和启动:对于每一次升级,都能够随时暂停和启动。
- 多种升级方案:Recreate:删除所有已存在的pod,重新创建新的; RollingUpdate:滚动升级,逐步替换的策略,同时滚动升级时,支持更多的附加参数,例如设置最大不可用pod数量,最小升级间隔时间等等。
k8s各组件使用
参考 https://www.jianshu.com/p/f5efc53ced5d
3:k8s常用的资源
3.1 创建pod资源
k8s yaml的主要组成
apiVersion: v1 api版本
kind: pod 资源类型
metadata: 属性
spec: 详细k8s_pod.yaml
apiVersion: v1
kind: Pod
metadata:name: nginxlabels:app: web
spec:containers:- name: nginximage: 10.0.0.11:5000/nginx:1.13ports:- containerPort: 80pod资源:至少由两个容器组成,pod基础容器和业务容器组成
pod配置文件2:
apiVersion: v1
kind: Pod
metadata:name: testlabels:app: web
spec:containers:- name: nginximage: 10.0.0.11:5000/nginx:1.13ports:- containerPort: 80- name: busyboximage: 10.0.0.11:5000/busybox:latestcommand: ["sleep","10000"]pod是k8s最小的资源单位
3.2 ReplicationController资源
rc:保证指定数量的pod始终存活,rc通过标签选择器来关联pod
k8s资源的常见操作:
kubectl create -f xxx.yaml
kubectl get pod|rc
kubectl describe pod nginx
kubectl delete pod nginx
或者
kubectl delete -f xxx.yaml
kubectl edit pod nginx创建一个rc
apiVersion: v1
kind: ReplicationController
metadata:name: nginx
spec:replicas: 5selector:app: mywebtemplate:metadata:labels:app: mywebspec:containers:- name: mywebimage: 10.0.0.11:5000/nginx:1.13ports:- containerPort: 80rc的滚动升级 新建一个nginx-rc1.15.yaml
升级 kubectl rolling-update nginx -f nginx-rc1.15.yaml --update-period=10s
回滚 kubectl rolling-update nginx2 -f nginx-rc.yaml --update-period=1s
3.3 service资源
service帮助pod暴露端口
创建一个service
apiVersion: v1
kind: Service
metadata:name: myweb
spec:type: NodePort #ClusterIPports:- port: 80 #clusterIPnodePort: 30000 #nodeporttargetPort: 80 #podportselector:app: myweb2修改nodePort范围
vim /etc/kubernetes/apiserver
KUBE_API_ARGS="--service-node-port-range=3000-50000"</pre>
service默认使用iptables来实现负载均衡, k8s 1.8新版本中推荐使用lvs(四层负载均衡)
3.4 deployment资源
有rc在滚动升级之后,会造成服务访问中断,于是k8s引入了deployment资源
创建deployment
apiVersion: extensions/v1beta1
kind: Deployment
metadata:name: nginx-deployment
spec:replicas: 3template:metadata:labels:app: nginxspec:containers:- name: nginximage: 10.0.0.11:5000/nginx:1.13ports:- containerPort: 80resources:limits:cpu: 100mrequests:cpu: 100m
deployment升级和回滚
命令行创建deployment
kubectl run nginx --image=10.0.0.11:5000/nginx:1.13 --replicas=3 --record
命令行升级版本
kubectl set image deploy nginx nginx=10.0.0.11:5000/nginx:1.15
查看deployment所有历史版本
kubectl rollout history deployment nginx
deployment回滚到上一个版本
kubectl rollout undo deployment nginx
deployment回滚到指定版本
kubectl rollout undo deployment nginx --to-revision=2
3.5 tomcat+mysql练习
在k8s中容器之间相互访问,通过VIP地址!
4:k8s的附加组件
4.1 dns服务
安装dns服务
1:下载dns_docker镜像包
wget [http://192.168.12.201/docker_image/docker_k8s_dns.tar.gz](http://192.168.12.201/docker_image/docker_k8s_dns.tar.gz)
2:导入dns_docker镜像包(node2节点)
3:修改skydns-rc.yaml
spec:nodeSelector:kubernetes.io/hostname: 10.0.0.13containers:4:创建dns服务kubectl create -f skydns-rc.yaml5:检查kubectl get all --namespace=kube-system6:修改所有node节点kubelet的配置文件vim /etc/kubernetes/kubeletKUBELET_ARGS="--cluster_dns=10.254.230.254 --cluster_domain=cluster.local"systemctl restart kubelet
4.2 namespace命令空间
namespace做资源隔离
4.3 健康检查
4.3.1 探针的种类
livenessProbe:健康状态检查,周期性检查服务是否存活,检查结果失败,将重启容器
readinessProbe:可用性检查,周期性检查服务是否可用,不可用将从service的endpoints中移除
4.3.2 探针的检测方法
* exec:执行一段命令
* httpGet:检测某个 http 请求的返回状态码
* tcpSocket:测试某个端口是否能够连接
4.3.3 liveness探针的exec使用
vi nginx_pod_exec.yaml
apiVersion: v1
kind: Pod
metadata:name: exec
spec:containers:- name: nginximage: 10.0.0.11:5000/nginx:1.13ports:- containerPort: 80args:- /bin/sh- -c- touch /tmp/healthy; sleep 30; rm -rf /tmp/healthy; sleep 600livenessProbe:exec:command:- cat- /tmp/healthyinitialDelaySeconds: 5periodSeconds: 5
4.3.4 liveness探针的httpGet使用
vi nginx_pod_httpGet.yaml
apiVersion: v1
kind: Pod
metadata:name: httpget
spec:containers:- name: nginximage: 10.0.0.11:5000/nginx:1.13ports:- containerPort: 80livenessProbe:httpGet:path: /index.htmlport: 80initialDelaySeconds: 3periodSeconds: 3
4.3.5 liveness探针的tcpSocket使用
vi nginx_pod_tcpSocket.yaml
apiVersion: v1
kind: Pod
metadata:name: tcpSocket
spec:containers:- name: nginximage: 10.0.0.11:5000/nginx:1.13ports:- containerPort: 80livenessProbe:tcpSocket:port: 80initialDelaySeconds: 3periodSeconds: 3
4.3.6 readiness探针的httpGet使用
vi nginx-rc-httpGet.yaml
apiVersion: v1
kind: ReplicationController
metadata:name: readiness
spec:replicas: 2selector:app: readinesstemplate:metadata:labels:app: readinessspec:containers:- name: readinessimage: 10.0.0.11:5000/nginx:1.13ports:- containerPort: 80readinessProbe:httpGet:path: /qiangge.htmlport: 80initialDelaySeconds: 3periodSeconds: 3
4.4 dashboard服务
1:上传并导入镜像,打标签
2:创建dashborad的deployment和service
3:访问[http://10.0.0.11:8080/ui/](http://10.0.0.11:8080/ui/)
4.5 通过apiservicer反向代理访问service
第一种:NodePort类型
type: NodePortports:- port: 80targetPort: 80nodePort: 30008
第二种:ClusterIP类型type: ClusterIPports:- port: 80targetPort: 80</pre>
5: k8s弹性伸缩
k8s弹性伸缩,需要附加插件heapster监控
5.1 安装heapster监控
1:上传并导入镜像,打标签ls *.tar.gz for n in `ls *.tar.gz`;do docker load -i $n ;done docker tag docker.io/kubernetes/heapster_grafana:v2.6.0 10.0.0.11:5000/heapster_grafana:v2.6.0 docker tag docker.io/kubernetes/heapster_influxdb:v0.5 10.0.0.11:5000/heapster_influxdb:v0.5 docker tag docker.io/kubernetes/heapster:canary 10.0.0.11:5000/heapster:canary2:上传配置文件,kubectl create -f .3:打开dashboard验证
5.2 弹性伸缩
1:修改rc的配置文件
containers:- name: mywebimage: 10.0.0.11:5000/nginx:1.13ports:- containerPort: 80resources:limits:cpu: 100mrequests:cpu: 100m
2:创建弹性伸缩规则
kubectl autoscale -n qiangge replicationcontroller myweb --max=8 --min=1 --cpu-percent=8
3:测试
ab -n 1000000 -c 40 [http://172.16.28.6/index.html](http://172.16.28.6/index.html)
ab -n 300000 -c 100 [http://172.16.23.14/index.html](http://172.16.23.14/index.html)
扩容截图
image.png
image.png
缩容:
image.png
image.png
image.png
6:持久化存储
pv: persistent volume 全局的资源 pv,node
pvc: persistent volume claim 局部的资源(namespace)pod,rc,svc
6.1:安装nfs服务端(10.0.0.11)
yum install nfs-utils.x86_64 -y (所有节点)
mkdir /data
vim /etc/exports
/data 10.0.0.0/24(rw,async,no_root_squash,no_all_squash)
systemctl start rpcbind
systemctl start nfs
6.2:在node节点安装nfs客户端
yum install nfs-utils.x86_64 -y
showmount -e 10.0.0.11
6.3:创建pv和pvc
上传yaml配置文件,创建pv和pvc
6.4:创建mysql-rc,pod模板里使用volume
volumeMounts:
- name: mysql mountPath: /var/lib/mysql
volumes:
- name: mysql persistentVolumeClaim: claimName: tomcat-mysql
6.5: 验证持久化
验证方法1:删除mysql的pod,数据库不丢
kubectl delete pod mysql-gt054
验证方法2:查看nfs服务端,是否有mysql的数据文件
image.png
6.6: 分布式存储glusterfs
image.png
- a: 什么是glusterfs
Glusterfs是一个开源分布式文件系统,具有强大的横向扩展能力,可支持数PB存储容量和数千客户端,通过网络互
联成一个并行的网络文件系统。具有可扩展性、高性能、高可用性等特点。
- b: 安装glusterf
所有节点:
yum install centos-release-gluster -y
yum install glusterfs-server -y
systemctl start glusterd.service
systemctl enable glusterd.service
mkdir -p /gfs/test1
mkdir -p /gfs/test2
- c: 添加存储资源池
master节点:
gluster pool list
gluster peer probe k8s-node1
gluster peer probe k8s-node2
gluster pool list
- d: glusterfs卷管理
创建分布式复制卷
gluster volume create qiangge replica 2 k8s-master:/gfs/test1 k8s-master:/gfs/test2 k8s- node1:/gfs/test1 k8s-node1:/gfs/test2 force
启动卷
gluster volume start qiangge
查看卷
gluster volume info qiangge
挂载卷
[root@glusterfs01 ~]# mount -t glusterfs 10.0.0.14:/qiangge /mnt
[root@glusterfs01 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 48G 1.8G 47G 4% /
/dev/sdb 10G 33M 10G 1% /gfs/test1
/dev/sdc 10G 33M 10G 1% /gfs/test2
10.0.0.14:/qiangge 30G 404M 30G 2% /mnt
- e: 分布式复制卷讲解
image.png
- f: 分布式复制卷扩容
扩容前查看容量:
df -h
扩容命令:
gluster volume add-brick qiangge k8s-node2:/gfs/test1 k8s-node2:/gfs/test2 force
扩容后查看容量:
[root@glusterfs01 ~]# df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda2 48G 1.8G 47G 4% /
/dev/sdb 10G 33M 10G 1% /gfs/test1
/dev/sdc 10G 33M 10G 1% /gfs/test2
10.0.0.14:/qiangge 30G 404M 30G 2% /mnt
6.7 k8s 对接glusterfs存储
- a:创建endpoint
vi glusterfs-ep.yaml
apiVersion: v1
kind: Endpoints
metadata:name: glusterfsnamespace: default
subsets:
- addresses:- ip: 10.0.0.11- ip: 10.0.0.12- ip: 10.0.0.13ports:- port: 49152protocol: TCP
- b: 创建service
vi glusterfs-svc.yaml
apiVersion: v1
kind: Service
metadata:name: glusterfsnamespace: default
spec:ports:- port: 49152protocol: TCPtargetPort: 49152sessionAffinity: Nonetype: ClusterIP
- c: 创建gluster类型pv
apiVersion: v1
kind: PersistentVolume
metadata:name: glusterlabels:type: glusterfs
spec:capacity:storage: 50GiaccessModes:- ReadWriteManyglusterfs:endpoints: "glusterfs"path: "qiangge"readOnly: false
- d: 创建pvc
vim gluster_pvc.yaml
kind: PersistentVolumeClaim
apiVersion: v1
metadata:name: gluster
spec:selector:matchLabels:type: glusterfsaccessModes:- ReadWriteManyresources:requests:storage: 10Gi
- e:在pod中使用gluster
vi nginx_pod.yaml
……
volumeMounts:- name: nfs-vol2mountPath: /usr/share/nginx/htmlvolumes:- name: nfs-vol2persistentVolumeClaim:claimName: gluster
这篇关于k8s 总结的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!