kubernetes资源对象存储类

最新推荐文章于 2024-02-27 17:30:27 发布

xujingcheng123

最新推荐文章于 2024-02-27 17:30:27 发布

阅读量576

点赞数 1

分类专栏： k8s 文章标签： kubernetes docker 容器

本文链接：https://blog.csdn.net/xujingcheng123/article/details/128771208

版权

k8s 专栏收录该内容

14 篇文章 1 订阅

订阅专栏

kubernetes资源对象存储类

存储类

存储类的资源对象主要包括 Volume、Persistent Volume、PVC 和 StorageClass。

首先看看基础的存储类资源对象——Volume（存储卷）。

Volume 是 Pod 中能够被多个容器访问的共享目录。Kubernetes 中的 Volume 概念、用途和目的与 Docker 中的 Volume 比较类似，但二者不能等价。首先， Kubernetes 中的 Volume 被定义在 Pod 上，被一个 Pod 里的多个容器挂载到具体的文件目录下；其次，Kubernetes中的 Volume 与 Pod 的生命周期相同，但与容器的生命周期不相关，当容器终止或者重启时，Volume 中的数据也不会丢失；最后，Kubernetes 支持多种类型的 Volume，例如 GlusterFS、Ceph 等分布式文件系统。

Volume 的使用也比较简单，在大多数情况下，我们先在 Pod 上声明一个 Volume，然后在容器里引用该 Volume 并将其挂载（Mount）到容器里的某个目录下。举例来说，若我们要给之前的 Tomcat Pod 增加一个名为 datavol 的 Volume，并将其挂载到容器的 /mydata-data 目录下，则只对 Pod 的定义文件做如下修正即可（代码中的粗体部门）；

template:
  metadata:
    labels:
      app: app-demo
      tier: frontend
  spec:
    volumes:
    - name: datavol
      emptyDir: {}
    containers:
    - name: tomcat-demo
    image: tomcat
    volumeMounts:
    - mountPath: /mydata-data
      name: datavol
    imagePullPolicy: IfNotPresent

Kubernetes 提供了非常丰富的 Volume 类型供容器使用，例如临时目录、宿主机目录、共享存储等，下面对其中一些常见的类型进行说明。

1. emptyDir

一个 emptyDir 是在 Pod 分配到 Node 时创建的。从它的名称就可以看出，它的初始内容为空，并且无须指定宿主机上对应的目录文件，因为这是 Kubernetes 自动分配的一个目录，当 Pod 从 Node 上移除时，emptyDir 中的数据也被永久移除。emptyDir 的一些用途如下。

临时空间，例如用于某些应用程序运行时，所需的临时目录，且无须永久保留。
长时间任务执行过程中使用的临时目录。
一个容器需要从另一个容器中获取数据的目录（多容器共享目录）。

在默认情况下，emptyDir 使用的是节点的存储介质，例如磁盘或者网络存储。还可以使用 emptyDir 属性，把这个属性设置为“Memory”，就可以使用更快的基于内存的后端存储了。需要注意的是，这种情况下的 emptyDir 使用的内存会被计入容器的内存消耗，将受到资源限制和配额机制的管理。

2. hostPath

hostPath为在 Pod 上挂载宿主机上的文件或目录，通常可以用于以下几方面。

在容器应用程序生成的日志文件需要永久保存时，可以使用宿主机的高速文件系统对其进行存储。
需要访问宿主机上 Docker 引擎内部数据结构的容器应用时，可以通过定义 hostPath 为宿主机/var/lib/docker 目录，使容器内部的应用可以直接访问 Docker 的文件系统。

在使用这种类型的 Volume 时，需要注意以下几点。

在不同的 Node 上具有相同配置的 Pod，可能会因为宿主机上的目录和文件不同，而导致对 Volume 上目录和文件的访问结果不一致。
如果使用了资源配额管理，则 Kubernetes 无法将 hostPath 在宿主机上使用的资源纳入管理。

在下面的例子中使用了宿主机的 /data 目录定义了一个 hostPath 类型的 Volume：

volumes:
- name:
  hostPath:
    path: "/data"

3.公有云 Volume

公有云提供的 Volume 类型包括谷歌公有云提供的 GCEPersistentDisk、亚马逊公有云提供的 AWS Elastic Block Store（EBS Volume）等。当我们的 Kubernetes 集群运行在公有云上或者使用公有云厂家提供的 Kubernetes 集群时，就可以使用这类 Volume。

4.其他类型的 Volume

iscsi：将 iSCSI 存储设备上的目录挂载到 Pod 中。
nfs：将 NFS Server 上的目录挂载到 Pod 中。
glusterfs：将开源 GlusterFS 网络文件系统的目录挂载到 Pod 中。
rbd：将 Ceph 块设备共享存储（Rados Block Device）挂载到 Pod 中。
gitRepo：通过挂载一个空目录，并从 Git 库克隆（cone）一个 git repository 以供 Pod 使用。
configmap：将配置数据挂载为容器内的文件。
secret：将 Secret 数据挂载为容器内的文件。

动态存储管理

Volume 属于静态管理的存储，即我们需要事先定义每个 Volume ，然后将其挂载到 Pod 中去用，这种方式存在很多弊端，典型的弊端如下。

配置参数烦琐，存在大量手工操作，违背了 Kubernetes 自动化的追求目标。
预定义的静态 Volume 可能不符合目标应用的需求，比如容量问题、性能问题。

所以Kubernetes 后面就发展了存储动态化的新机制，来实现存储的自动化管理。相关的核心对象（概念）有三个：Persistent Volume（简称 PV ）、StorageClass、PVC。

PV 表示由系统动态创建（dynamically provisioned）的一个存储卷，可以被理解成 Kubernetes 集群中某个网络存储对应的一块存储，它与 Volume 类似，但 PV 并不是被定义在 Pod 上的，而是独立于 Pod 之外定义的。PV 目前支持的类型主要有 gecPersistentDisk、AWSElasticBlockStore、AzureFile、AzureDisk、FC（Fibre Channel）、NFS、iSCSI、RBD（Rados Block Device）、CephFS、Cinder、GlusterFS、VsphereVolume、Quobyte Volumes、VMware Photon、Portworx Volumes、ScaleIO Volumes、HostPath、Local等。

我们知道，Kubernetes 支持的存储系统有多种，那么系统怎么知道从哪个存储系统中创建什么规格的 PV 存储卷呢？这就涉及 StorageClass 与 PVC。StorageClass 用来描述定义某种存储系统的特征，下面给出一个具体的例子：

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: standard
provisioner: kubernetes.io/aws-abs
parameters:
  type: gp2
reclaimPolicy: Retain
allowVolumeExpansion: true
mountOptions:
- debug
volumeBindingMode: Immediate

从上面的例子可以看出，StorageClass 有几个关键属性：provisioner、parameters和reclaimPolicy，系统在动态创建 PV 时会用到这几个参数。简单地说，provisioner 代表了创建 PV 的第三方插件，parameters 是创建 PV 时的必要参数，reclaimPolicy 则表明了 PV 回收策略，回收策略包括删除或者保留。需要注意的是，StorageClass 的名称会在 PVC （PV Claim）中出现，下面就是一个典型的 PVC 定义：

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: claim1
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: standard
  resources:
    requests:
      storage: 30Gi

PVC 正如其名，表示应用希望申请的 PV 规格，其中重要的属性包括 accessModes （存储访问模式）、storageClassName （用哪种 StorageClass 来实现动态创建）及 resource （存储的具体规格）。

有了以 StorageClass 与 PVC 为基础的动态 PV 管理机制，我们就很容易管理和使用 Volume 了，只要在 Pod 里引用 PVC 即可达到目的，如下面的例子所示：

spec:
   containers:
   - name: myapp
   image: tomcat:8.5.38-jre8
   volumeMounts:
   - name: tomcatdata
     mountPath: "/data"
   volumes:
   - name: tomcatdata
     persistentVolumeClaim:
       claimName: claim1

除了动态创建 PV，PV 动态扩容、快照及克隆的能力也是 Kubernetes 社区正在积极研发的高级特性。

安全类

安全始终是 Kubernetes 发展过程中的一个关键领域。

从本质上来说，Kubernetes 可被看作一个多用户共享资源管理系统，这里的资源主要是各种Kubernetes 里的各类资源对象，比如 Pod、Service、Deployment 等。只有通过认证的用户才能通过 Kubernetes 的 API Server 查询、创建及维护相应的资源对象，理解这一点很重要。

Kubernetes 里的用户有两类：我们开发的运行在 Pod 里的应用；普通用户，如典型的 kubectl 命令行工具，基本上由指定的运维人员（集群管理员）使用。在更多的情况下，我们开发的 Pod 应用需要通过 API Server查询、创建及管理其他相关资源对象，所以这类用户才是 Kubernetes 的关键用户。为此，Kubernetes 设计了 Service Account 这个特殊的资源对象，代表 Pod 应用的账号，为 Pod 提供必要的身份认证。在此基础上，Kubernetes 进一步实现和完善了基于角色的访问控制权限系统——RBAC（Role-Based Access Control）。

在默认情况下，Kubernetes 在每个命令空间中都会创建一个默认的名称为 default 的 Service Account，因此 Service Account 是不能全局使用的，只能被它所在命令空间中的 Pod 使用。通过以下命令可以查看集群中的所有 Service Account：

kubectl get sa --all-namespaces

NAMESPACE	NAME	SECRETES	AGE
default	default	1	32d
kube-system	default	1	32d

Service Account 是通过 Secret 来保存对应的用户（应用）身份凭证的，这些凭证信息有 CA 根证书数据（ca.crt）和签名后的 Token 信息（Token）。在 Token 信息中就包括了对应的 Service Account 的名称，因此 API Server 通过接收到的 Token 信息就能确定 Service Account 的身份。在默认情况下，用户创建一个 Pod 时， Pod 会绑定对应命名空间中的 default 这个 Service Account 作为其“公民身份证”。当 Pod 里的容器被创建时，Kubernetes 会把对应的 Secret 对象中的身份信息（ca.crt、Token 等）持久化保存到容器被创建时，Kubernetes 会把对应的 Secret 对象中的身份信息文件，并将其附加到 HTTPS 请求中传递给 API Server 以完成身份认证逻辑。在身份认证通过以后，就涉及“访问授权”的问题，这就是 RBAC 要解决的问题了。

首先我们要学习的是 Role 这个资源对象，包括 Role 与 ClusterRole 两种类型的角色。角色定义了一组特定权限的规则，比如可以操作某类资源对象。局限于某个命名空间的角色由 Role 对象定义，作用于整个 Kubernetes 集群范围内的角色则通过 CLusterRole 对象定义。下面是 Role 的一个例子，表示在命名空间 default 中定义一个 Role 对象，用于授予对 Pod 资源的读访问权限，绑定到该 Role 的用户则具有对 Pod 资源的 get、watch 和 list 权限；

kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: [""] # 空字符串“”表明使用 core API group
  resources: ["pods"]
  verbs: ["get", "watch", "list"]

接下来就是如何将 Role 与具体用户绑定（用户授权）的问题了。我们可以通过 RoleBinding 来解决这个问题。下面是一个具体的例子，在命名空间 default 中将 “pod-reader” 角色授予用户 “Caden”，结合对应的 Role 的定义，表明这一授权将允许用户 “Caden” 从命名空间 default 中读取 Pod。

kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: read-pods
  namespace: default
subjects:
- kind: User
  name: Caden
  apiGroup: rbac.authorization.k8s.io
roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

在 RoleBinding 中使用 subjects（目标主体）来表示要授权的对象，这是因为我们可以授权三类目标账号：Group（用户组）、User（某个具体用户）和 Service Account （Pod 应用所使用的账号）。

在安全领域，除了以上针对 API Server 访问安全相关的资源对象，还有一种特殊的资源对象——NetworkPolicy（网络策略），它是网络安全相关的资源对象，用于解决用户应用之间的网络隔离和授权问题。NetworkPolicy 是一种关于 Pod 间相互通信，以及 Pod 与其他网络端点间相互通信的安全规则设定。

NetworkPolicy 资源使用标签选择 Pod ，并定义选定 Pod 所允许的通信规则。在默认情况下，Pod 间及 Pod 与其他网络端点间的访问时没有限制的，这假设了 Kubernetes 集群被一个厂商（公司/租户）独占，其中部署的应用都是相互可信的，无须相互防范。但是，如果存在多个厂商共同使用一个 Kubernetes 集群的情况，则特别是在公司的云环境中，不同厂商的应用要相互隔离以增加安全性，这就可以通过 NetworkPolicy 来实现了。