三、（2）Kubernetes基本概念和术语

泰勒熊_Hot

已于 2024-06-10 18:03:38 修改

阅读量816

点赞数 28

分类专栏： Kubernetes 文章标签： kubernetes 容器云原生

于 2024-06-10 17:57:38 首次发布

本文链接：https://blog.csdn.net/wqd2668359631/article/details/139574245

版权

Kubernetes 专栏收录该内容

4 篇文章 0 订阅

订阅专栏

Kubenetes的基本概念和术语（2）

1.4.4存储类

	存储类的资源对象的主要包括Volume、PV、PVC以及StorageClass。
	我们首先看一下熟知的存储类资源对象**Volume（存储卷）**。
	
	Volume是pod中能被多个容器访问的共享目录。k8s中的Volume概念，类似于docker中的Volume，但是并不完全相同。
	首先，k8s中的Volume被定义在pod上面，被pod里面多个容器挂载到具体的文件目录下；其次K8s中的Volume与pod的生命周期相同，但与容器的生命周期不相关，当容器停止或者重启时，Volume中的数据也不会丢失；最后，K8s支持多种类型的Volume，包括像Ceph、GlusterFS等分布式文件系统。
	怎样使用Volume呢? 在大多数情况下，我们需要先在pod上声明一个Volume，然后在容器里引用该Volume并将其挂载到容器里的某个目录下。举个例子，如果给之前的Tomcat Pod 增加一个名为data_vol的Volume，并将其挂载到容器的/mydata-data目录下，则只对Pod的定义文件，修改如下即可：

apiVersion: v1
kind: Pod
metadata:
  name: app-demo
  labels:
    app: app-demo
spec:
  containers: 
  - name: tomact-demo
    image: tomcat
    volumeMounts: 
    - mountPath: /mydata-data
      name: datavol
    imagePullPolicy: IfNotPresent
  volumes: 
    - name: datavol
      emptyDir: {}

K8s提供很多丰富的Volume类型供容器使用，例如临时的目录、宿主机目录、共享存储等，下面是一些常见类型说明：

1.emptyDir

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

临时空间，例如用于某些应用程序运行时所需的临时目录，而且不用做持久化存储。
长时间任务执行过程中使用的临时目录。
一个容器需要从另一个容器中获取数据的目录（多容器共享目录）

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

2.hostPath

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

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

在使用这种类型的Volume时，需要注意一下几点：
在不同的Node上具有相同配置的Pod，可能会因为宿主机上的目录和文件的不同，而导致对Volume上目录和文件访问结果不一致。
如果使用了资源配额管理，则k8s无法将hostPath在宿主机上使用的资源纳入管理。

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

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

3.公有云Volume

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

4.其他类型的Volume

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

动态存储管理
Volume属于静态管理的存储，就是我们需要事先定义一个Volume，然后将其挂载到Pod中去用，这种方式存在很对弊端，如：

配置参数繁琐，需要经常去手动修改配置文件，违背了K8s自动化的追求目标。
预定义的静态Volume可能不符合后续目标应用的需求，如：容量问题，性能问题等。

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

PV是由系统动态创建的一个存储卷，可以被理解成k8s集群中某个网络存储对应的一块存储，它与Volume类似，但PV并不是被定义在Pod上的（pod的yaml文件），它是单独的一个存储类的资源对象。独立于Pod之外定义。PV目前支持的类型有gcePersistentDisk.AWSElasticBlockStore、AzureFile、AzureDisk、FC (Fibre Channel)、NFS iSCSI、RBD( Rados Block Device )、CephFS、Cinder、GlusterFS、VsphereVolume、Quobyte Volumes 、VMware Photon、Portworx Volumes、ScalelO Volumes、HostPath、Local 等。

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

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

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

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

PVC正如其名，表示应用希望申请的 PV 规格，其中重要的属性包括 accessModes （存储访问模式）、storageClassName (用哪种 StorageClass 来实现动态创建）及 resouces （存储的具体规格)。
有了以 StorageC ss 为基 PV 管理制，我们就很容易管理和使用
Volume 了，只要在 Pod 里引用 PV 即可达到目的，如下面的例子所示：

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

1.4.5安全类

从本质上说，k8s可被看做是一个多用户共享资源的管理系统，这里的资源主要是各种k8s里的各类资源对象，比如Pod、Service、Deployment等。只有通过认证的用户才能通过ApiServer入口，进行查询、创建、维护集群等操作，理解这一点很重要。

Service Account

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

Role

首先我们要理解Role这个资源对象，包括Role和Cluster Role两种角色。角色是用来定义特定权限规则，比如可以操作某个资源对象，局限于某个命名空间的角色由Role对象定义，作用于整个K8s集群范围内的角色则通过Cluster Role对象定义。下面是Role的一个例子，表示在命名空间default中定义的一个Pod对象，用于授权对Pod资源的读访问权限，绑定到该Role的用户对Pod资源的get、watch、list权限：

kind: Role
apiVersion: rabac.authorizatino.k8s.io/v1
metadata:
  namespace: default
  name: pod-reader
rules:
- apiGroups: {""}  #空表示使用core API group
  resources: {"pods"}
  verbs: {"get","watch","list"}

RoleBinding

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

apiVerison: rabac.authorizatino.k8s.io/v1
kind: RoleBinding
metadata: 
  name:read-pods
  namespaces: 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(某个具体用户)和ServiceAccount(Pod应
用所使用的账号)。

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

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

参考： kubernetes权威指南第5版