带你玩转kubernetes-k8s（第八篇：k8s-Persisten Volume、Namespace、Annotation、ConfigMap概念及其实例）

最新推荐文章于 2024-08-22 14:20:51 发布

坚持的道路注定孤独

最新推荐文章于 2024-08-22 14:20:51 发布

阅读量1.3k

点赞数

分类专栏： kubernetes 带你玩转kubernets-k8s

本文链接：https://blog.csdn.net/qq_31136839/article/details/94762459

版权

kubernetes 同时被 2 个专栏收录

64 篇文章 49 订阅

订阅专栏

带你玩转kubernets-k8s

64 篇文章 63 订阅

订阅专栏

今天为大家讲解Persisten Volume （PV），挺重要的一个概念，希望大家可以好好看哦。

Persisten Volume

Volume 是被定义在Pod上的，属于计算资源的一部分，而实际上，网络存储是相对独立于计算资源而存在的一种实体资源。

Persisten Volume(PV)和与之相关联的Persistent Volume Claim(PVC)也起到了类似的作用。

PV可以被理解成Kuberetes集群中的某个网络存储对应的一块存储，它与Volume类似，但有以下区别。

◎　PV只能是网络存储，不属于任何Node，但可以在每个Node上访问。
◎　PV并不是被定义在Pod上的，而是独立于Pod之外定义的。

◎ PV目前支持的类型包括：gcePersistentDisk、AWSElasticBlockStore、AzureFile、AzureDisk、FC（Fibre Channel）、Flocker、NFS、iSCSI、RBD（Rados BlockDevice）、CephFS、Cinder、GlusterFS、VsphereVolume、Quobyte Volumes、VMware Photon、Portworx Volumes、ScaleIO Volumes和HostPath（仅供单机测试）。

下面给出了NFS类型的PV的一个YAML定义文件，声明了需要5Gi的存储空间：

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv003
spec: 
  capacity:
    storage: 5Gi
  accessMondes:
  - ReadWriteOnce       #读写权限，允许被一个Node挂载
  nfs:
    path: /somepath     #网络磁盘中的路径
    server: 172.17.0.2  #nfs的地址

比较重要的是PV的accessModes属性，目前有以下类型。

◎　ReadWriteOnce：读写权限，并且只能被单个Node挂载。
◎　ReadOnlyMany：只读权限，允许被多个Node挂载。
◎　ReadWriteMany：读写权限，允许被多个Node挂载。

如果某个Pod想申请某种类型的PV，则首先需要定义一个PersistentVolumeClaim对象：

apiVersion: v1
kind： PersistentVolumeClaim
metadata:
  name: myclaim
spec:
  accessModes:
  - ReadWriteOnce
  resources:
    requests:
      storage: 8Gi

之后，在Pod的Volume定义中引用上述PVC即可：

volumes:
- name: mypd
  PersistentVolumeClaim:
    cliaimName: myclaim

最后说说PV的状态。PV是由状态的对象，它的状态有以下几种。
◎　Available：空闲状态。
◎　Bound：已经绑定到某个PVC上。
◎　Released：对应的PVC已经被删除，但资源还没有被集群收回。
◎　Failed：PV自动回收失败。

共享存储的基本原理我们暂时想讲到这里，这里只是让大家有一个基本的了解，具体的原理解析和实践我们后面会讲到的。

Namespace

Namespace(命名空间)是k8s系统中的另一个非常重要的概念。Namespace在很多情况下用于实现多租户的资源隔离。Namespace通过集群内部的资源对象“分配”到不同的Namespace中，形成逻辑上分组不同的项目、小组或用户组，从而使不同的分组在共享整个集群的资源，同时还能被k8s分别管理。

k8s集群在启动后会创建一个名为default的Namespace,通过kubectl命令可以查看：

kubectl get namespace

如果不特别指明Namespace,用户创建的Pod，RC,Service都将被系统创建到这个default的Namespace中。顺便说下

kubectl get pods #查看命名空间为default的pod

Namesoace的定义比较简单。如下所示的YAML定义了名为development的Namespace.

apiVersion: v1
kind: Namespace
metadata:
  name: development

一旦创建了Namespave,我们在创建资源对象时就可以指定这个资源对象属于哪个Namespace.下面我们定义一个busybox的Pod，并将其放入development这个Namespace里：

apiVersion: v1
kind: Pod
metadata:
  name: busybox
  namespace: development
spec:
  containers:
  - image: busybox
    command:
    - sleep
    - "3600"
    name: busybox

查看namespace 为development空间中的对象。

-n: development等于（--namespace=development）

当给每个租户创建一个Namespace来实现多租户的资源隔离时，还能结合Kubernetes的资源配额管理，限定不同租户能占用的资源，例如CPU使用量、内存使用量等。关于资源配额管理的问题，在后面的章节中会详细介绍。

Annotation

Annotation(注解)与Label类似，也使用key/value键值对的形式进行定义。不同的是Label具有严格的命名规范，它定义的是k8s对象的元数据（Metadata）,并且用于Label Selector。

Annotation则是用户任意定义的附加信息，以便于外部工具查找。在很多时候，k8s的模块自身会通过Annotation标记资源对象的一些特殊信息。

通常来说，用Annotation来记录的信息如下：

◎　build信息、release信息、Docker镜像信息等，例如时间戳、release id号、PR号、镜像Hash值、Docker Registry地址等。
◎　日志库、监控库、分析库等资源库的地址信息。
◎　程序调试工具信息，例如工具名称、版本号等。

◎ 团队的联系信息，例如电话号码、负责人名称、网址等。

ConfigMap

为了能够准确和深刻理解Kubernetes ConfigMap的功能和价值，我们需要从Docker说起。

我们知道，Docker通过将程序、依赖库、数据及配置文件“打包固化”到一个不变的镜像文件中的做法，解决了应用部署的难题，但这同时带来棘手的问题，即配置文件中的参数在运行期间如何修改的问题。

我们不可能在启动Docker容器后再修改容器里的配置文件，然后用新的配置文件重启容器里的用户主进程。为了解决这个问题，Docker提供了两种方式：

◎　在运行时通过容器的环境变量来传递参数；
◎　通过Docker Volume将容器外的配置文件映射到容器内。

这两种方式都有各自的优缺点，在大多数情况下，后一种方式更适合我们的系统，因为大多数应用通常从一个或多个配置文件中读取参数。但是这种方式也有明显的缺陷：我们必须在目标主机上创建好对应的配置文件，然后才能映射到容器里。

这些缺陷在分布式情况下变得更为严重，因为无论采用哪种方式，修改多台服务器上的某个指定文件，并确保这些文件保持一致，都是一个很难完成的目标。

在大多数情况下，我们都希望能看到集中管理系统的配置参数，而不是管理一堆配置文件。针对这些问题，k8s给出了一个很巧妙的设计实现：

首先，把所有的配置项都当作key-value字符串，当然value可以来自某个文本文件，比如配置项password=123456、user=root、host=192.168.1.2用于表连接FTP服务器的配置参数。这些配置项可以作为Map（k-v）表中的一个项，整个Map的数据可以被持久化存储在k8s的Etcd数据库中，然后提供API以方便k8s相关组件或客户应用CRUD操作这些数据，上述专门用来保存配置参数的Map就是Kubernetes ConfigMap资源对象。

接下来，k8s提供了一种内建机制，将存储在etcd中的ConfigMap通过Volume映射方式变成目标Pod内的配置文件，不管目标Pod被调度到哪台服务器上，都会自动映射。如果ConfigMap的key-value数据被修改，则映射到目标Pod中的“配置文件”也会随之自动更新。于是，Kubernetes ConfigMap就成了分布式系统中最为简单且对应用无侵入的配置中心。

小结：

到这里我们讲解了Master、Node、Pod、Label、Replication Controller、Deploymetn、Horizontal Pod Autoscaler、StatefulSet、Service、Job、Volume、Persistent Volume、Namespace、Annotation、ConfigMap这些组件。

这些组件是k8s系统中的核心组件，他们共同构成了k8s系统的框架和计算模型。通过对他们进行灵活组合，用户可以快速，方便地对容器集群进行配置，创建和管理。

除了上述的核心组件，在k8s系统中海油很多辅助配置的资源对象，例如LimitRange、ResourceQuota。另外，对一些系统内部使用的对象Binding、Event等可以参考Kubernetes的API文档。

大家看到这里，我相信大家对k8s框架的了解有了更清楚的理解和认知。也会有很多不懂的地方，没有关系，这些概念只是为了让大家对k8s整个框架有一个大概的了解。后面我们会更深入的讲解并实践k8s的各种使用技巧。

谢谢大家的支持！