深入剖析k8s中的存储

深入剖析k8s中的存储,第1张

本文是《深入剖析k8s》学习笔记的第四篇,主要对k8s中的存储数据卷进行分析和学习。

容器中的存储是不稳定的,一旦容器重启或者销毁,这些存储就都会丢失。所以真实使用场景下,都会以数据卷挂载的方式将外部存储应用到容器中,带来的好处就是:

在k8s中,如果要在容器中使用数据卷,需要像如下一个pod的yaml示例一样进行声明定义:

其中pod的定义中,声明使用了自定义名称为 my-volume 的数据卷,并且类型为emptyDir;k8s的volume支持多种数据类型,可以通过命令 kubectl explain podspecvolumes 来查看所有支持的volume类型,其中常用的类型及意义比较如下:

从工程分工角度上来说,存储的定义和声明应该由运维人员完成,开发人员只要使用即可。因此,为了避免将存储细节过度地暴露给开发人员,k8s才引进了Persistent Volume Claim(PVC)和Persistent Volume(PV)这两个API对象,同时也降低了开发人员使用存储卷的门槛。如此,开发人员只需要如下两步就能解决存储卷的使用问题:

那么开发人员声明的PVC到底使用的是什么存储卷呢,这个就由运维人员负责维护就行了,如下是一个PV的定义,开发人员了解即可:

为什么这个PV可以和上面的PVC绑定呢?只要符合如下的条件,k8s就会自动将它们绑定,绑定后,在PVC的配置文件中就能看到使用的数据卷就是该PV了。

总的来说,PVC和PV的关系就像是接口和实现的关系,PVC是接口定义,声明要使用什么,至于怎么实现,就是PV去完成的事情。如此解耦,使得开发和运维都能高效地搞定存储。

假设开发人员在创建好带有PVC的pod之后,且pod已经运行了,才发现运维还没有来得及创建对应的PVC或者PVC创建有问题,致使pod存储卷使用有问题该怎么办?只要运维及时创建对应的PV,k8s中的volume controller会循环遍历没有成功绑定PV的PVC,帮它们寻找合适的PV进行绑定。

一个k8s集群往往有很多开发团队在使用,开发会部署很多pod,如果这些pod都需要存储卷,运维人员就需要天天创建pv来满足开发人员pvc绑定的需求了,太浪费人力,所以这种重复工作就被k8s中的storageClass取代了。原先手动创建PV的方式被称为static provisioning,使用storageClass自动创建PV的方式被称为dynamic provisioning,storageClass其实就是PV的一个模板,其定义大致分为两个部分:

在开发人员创建PVC的时候,只要指定使用的storageClassName是如上定义和创建的my-storageclass,那么k8s就会根据该storageClass自动创建一个PV与该PVC绑定。

K8s在什么情况会杀掉服务?使用Rancher来运行Kubernetes有很多优势。大多数情况下能使用户和IT团队部署和管理工作更加方便。Rancher自动在Kubernetes后端实现etcd 的HA,并且将所需要的服务部署到此环境下的任何主机中。在设置访问控制,可以轻易连接到现有的LDAP和AD基础构架。Rancher还可以自动实现容器联网以及为Kubernetes提供负载均衡服务。通过使用Rancher,你将会在几分钟内有拥有Kubernetes的HA实现。命名空间现在我们的集群已经运行了,让我们进入并查看一些基本的Kubernetes资源吧。你可以访问Kubernetes集群也可以直接通过kubectl CLI访问,或者通过Rancher UI 访问。Rancher的访问管理图层控制可以访问集群,所以你需要在访问CLI前从Rancher UI那里生成API密匙。我们来看下第一个Kubernetes资源命名空间,在给定的命名空间中,所有资源名称必须有唯一性。此外,标签是用来连接划定到单个命名空间的资源。这就是为什么同一个Kubernetes集群上可以用命名空间来隔离环境。例如,你想为应用程序创建Alpha, Beta和生产环境,以便可以测试最新的更改且不会影响到真正的用户。最后创建命名空间,复制下面的文本到namespaceyaml文件,并且运行 kubectl -f namespaceyaml 命令,来创建一个beta命名空间。kind: NamespaceapiVersion: v1metadata:name: betalabels:name: beta当然你还可以使用顶部的命名空间菜单栏从Rancher UI上创建、查看和选择命名空间。你可以使用下面的命令,用kubectl来为CLI交互设置命名空间:$ kubectl config set-context Kubernetes --namespace=beta为了验证目前context是否已经被设置好,你可以使用config view命令,验证一下输出的命名空间是否满足你的期望。$ kubectl config view | grep namespace command namespace: betaPods现在我们已经定义好了命名空间,接下来开始创建资源。首先我们要看的资源是Pod。一组一个或者多个容器的Kubernetes称为pod,容器在pod 里按组来部署、启动、停止、和复制。在给定的每个主机种类里,只能有一个Pod,所有pod里的容器只能在同一个主机上运行,pods可以共享网络命名空间,通过本地主机域来连接。Pods也是基本的扩展单元,不能跨越主机,因此理想状况是使它们尽可能接近单个工作负载。这将消除pod在扩展或缩小时产生的副作用,以及确保我们创建pods不太耗资源而影响到主机。我们来给名为mywebservice的pod定义,在规范命名web-1-10中它有一个容器并使用nginx容器镜像,然后把端口为80下的文本添加至podyaml文档中。apiVersion: v1kind: Podmetadata:name: mywebservicespec:containers:- name: web-1-10image: nginx:110ports:- containerPort: 80使用kubetl create命令创建pod,如果您使用set-context command设置了您的命名空间,pods将会在指定命名空间中被创立。在通过运行pods命令去验证pod状态。完成以后,我们可以通过运行kubetl delete命令删除pod。$ kubectl create -f /podyamlpod "mywebservice" created$ kubectl get podsNAME READY STATUS RESTARTS AGEmywebservice 1/1 Running 0 37s$ kubectl delete -f podyamlpod "mywebservice" deleted在Rancher UI 中查看pod,通过顶端的菜单栏选择 Kubernetes > Pods 。


欢迎分享,转载请注明来源:内存溢出

原文地址: http://outofmemory.cn/zz/13243219.html

(0)
打赏 微信扫一扫 微信扫一扫 支付宝扫一扫 支付宝扫一扫
上一篇 2023-06-25
下一篇 2023-06-25

发表评论

登录后才能评论

评论列表(0条)

保存