PV与PVC之subPath（容器根目录设置） 在某些应用中，同一个Volume可能会被多个Pod或者一个Pod中的多个容器共享。此时可能存在个应用需要不同子目录的需求，可以通过Pod中volumeMounts定义的subPath字段进行设置。通过对subPath的设置，容器将以subPath设置的目录而不是Volume中提供的默认根目录作为根目录。subPath中的路径名称不能以“/”开头，需要使用相对路径的形式。如果希望通过环境变量的形式来设置subPath路径，可以通过subPathExpr字段来实现。subPath和subPathExpr字段是互斥的，不能同时使用。示例{tabs}{tabs-pane label="subPath"}--- apiVersion: v1 kind: Pod metadata: name: mysql spec: containers: - name: mysql image: mysql env: - name: MYSQL_ROOT_PASSWORD volue: "rootpassword" volumeMounts: - mountPath: /var/lib/mysql name: site-data subPath: mysql - name: php image: php volumeMounts: - mountPath: /var/www/html name: site-data subPath: html volumes: - name: site-data persitentVolumeClaim: claimName: site-data-pvc{/tabs-pane}{tabs-pane label="subPathExpr"}--- apiVersion: v1 kind: Pod metadata: name: pod1 spec: containers: - name: containers1 image: busybox command: ["sh","-c","sleep 6000"] env: - name: POD_NAME volueFrom: fieldRef: apiVersion: v1 FilePath: metadata.name volumeMounts: - name: workdir1 mountPath: /logs subPathExpr: $(POD_NAME) restartPolicy: Never volumes: - name: workdir1 hostpath: path: /var/log/pods {/tabs-pane}{/tabs}

集群存储之PV与PVC PVPV：Persistent Volume 持久卷。资源提供者，根据集群的基础设施变化而变化，由集群管理员进行配置管理。PV将存储定义为一种容器应用可以使用的资源。PV由管理员创建和配置，它与存储资源提供者的具体实现直接相关。不同提供者提供的PV类型包括NFS、iSCSI、RBD或者由公有云提供的共享存储。PV与普通的临时卷一样，也是通过插件机制进行实现的，只是PV的生命周期独立于使用它的Pod。PV并不直接属于某个Pod。如果某个Pod想要使用PV，需要使用PVC来完成申请。随后Kubernetes会完成从PVC到PV的绑定。之后被绑定的PV就可以被申请的Pod使用了。一个PV只能被一个PVC绑定，被绑定的PV不能再被其他PVC绑定。 PART.01 PV详解 PV作为对存储资源的定义，主要涉及存储能力，访问模式，存储类型，回收策略，后端存储类型等关键信息的设置。不同类型的PV是以不同的插件进行设计和实现的，主要包括以下几类：CSI：CSI容器存储借口，由存储资源提供者提供驱动程序和存储管理程序FC（Fibre channel）：光纤存储设备hostPath：宿主机目录，仅供单Node测试iSCSI：iSCSI存储设备Local：本地持久化存储NFS：基于NFS协议的网络文件系统# 示例 apiVersion：v1 kind: PersistentVolume metadata: name: pv1 spec: capacity: storage: 5Gi volumeMode: Filesystem accesModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Recycle storageOptions: - hard - nfsvers=4.1 nfs: path: /tmp server: 10.15.55.55 存储容量（capacity）存储容量用于描述存储的容量，目前仅支持对存储空间的设置（storage=XX）。存储卷模式（volumeMode）可选性只有两个：Filesystem（文件系统，默认值）和Block（块设备）。文件系统模式的PV将以目录（Directory）形式被挂载到Pod内。访问模式ReadWriteOnce（RWO）：读写权限，只能被单个Node挂载（单用户读写）ReadOnlyMany（ROX）：只读权限，允许被多个Node挂载（多用户只读）ReadWriteMany（RWX）：读写权限，允许被多个Node挂载（多用户读写）ReadWriteOncePod（RWOP）：可以被单个Pod以读写方式挂载，仅支持CSI存储卷，用于集群中只有一个Pod时以读写方式使用这种模式的PVC。某些PV可能同时支持多种访问模式，但PV在挂载时只能使用一种访问模式，多种访问模式不能同时生效。节点亲和性（nodeAffinity）PV可以通过设置节点亲和性来实现只能通过某些Node访问Valume，这可以在PV定义的nodeAffinity字段中进行设置。使用这些Volume的Pod将被调度到满足亲和性要求的Node上。大部分存储驱动提供的volume都已自动完成亲和性的设置，通常无需用户手动设置。对于Local类型的PV，需要手动设置。apiVersion: v1 kind: PersistentVolume metadata: name: local-pv spec: capacity: storage: 5Gi accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Delete storageClassName: local-storage local: path: /mnt/disks/ssd1 nodeAffinity: required: nodeSelectorterms: - matchExpressions: - key: kubernetes.io/hostname operator: In volues: - my-nodePV生命周期Available：可用状态，还未与某个PVC绑定Bound：以与某个PVC绑定Released：与之绑定的PVC已被删除，但未完成资源回收，不能被其他PVC使用Failed：自动资源回收失败 PART.01 PVC详解 PVC：PersistentVolumeClaim 持久卷声明。资源的使用着，根据业务的需求变化来配置，用户无需知道PV的技术细节，只需要声明你需要什么样的资源资源即可。apiVersion: v1 kind: PersistentVolumeClaim metadata: name: myclaim spec: accessModes: - ReadWriteOnce volumeMode: Filesystem resources: requests: storage: 8Gi storageClassName: slow selector: matchLabels: release: "stable" matchExpressions: - { key: environment, operator: In, values: [dev] } 说明resources：资源请求，描述对存储资源的请求，通过resources.requests.storage字段设置需求的存储空间的大小accessModes：访问模式，PVC也可以设置访问模式，用于描述用户应用对存储资源的访问权限volumeMode：存储卷模式，用于描述希望使用的PV存储卷模式，包括文件系统和块设备。PVC设置的存储卷模式最好与PV存储卷模式相同，以实现绑定。如果不同可能会出现无法绑定的结果。selector：PV选择条件，通过设置Label Selector，可以使PVC对于系统中已经存在的各种PV进行筛选。系统将根据标签选出合适的PV与该PVC进行绑定。对于选择条件，可以通过matchLabels和matchExpressions进行设置。如果两个字段都已设置，则Selector要同时满足才能完成匹配。Clas：存储类别，在定义PVC时可以设定需要的后端存储类别（通过storageClassName字段进行指定），以减少对后端存储特性的详细信息的依赖。只有设置了Class的PV才能被系统筛选出来，与该PV进行绑定。PVC也可以不设置Class需求，如果storageClassName字段的值被设置为空（storageClassName=""）,则表示该PVC不需求特定的Class，系统只选择未设定Class的PV与之绑定。PVC也可以完成不设置storageClassName字段，此时将根据系统是否启用了名为DefaultStorageClass的Admission Controller进行相应的操作。{mtitle title="PV和PVC的工作原"/}1.资源供应Kubernetes支持两种资源供应模式：静态（static）和动态（Dynamic）模式。资源供应的结果就是将适合的PV与PVC成功绑定。静态模式：集群管理员预先创建若干PV，在PV的定义中能够体现存储资源的特征。动态模式：集群管理员无需预先创建PV，而是通过StorageClass的设置对后端存储资源进行描述，标记存储的类型和特征。用户通过创建的PVC对存储类型进行申请。之后，StorageClass中的驱动提供者将自动完成PV的创建工作，并将创建出的PV与PVC进行绑定。如果PVC声明的Class为空，则说明PVC不适用动态模式。Kubernetes支持设置集群范围内默认的StorageClass，为用户创建的PVC设置一个默认的存储类StrongClass。2.资源绑定在用户定义好PVC后，系统将根据PVC对存储资源的请求（存储空间和访问模式），在已存在的PV中选择一个满足PVC要求的PV。一旦找到，就将该PV与用户定义的PVC进行绑定，用户的应用就可以使用这个PVC了。如果系统中没有满足PVC要求的PV，那么PVC会无限期处在pending状态，直到系统为其创建了一个满足要求的PV。PV一旦与某个PVC完成绑定，就会被这个PVC独占，不能再与其他的PVC绑定。PVC与PV的绑定关系是一对一的，不会存在一对多的情况。但是同一个PVC可以被多个Pod同时挂载（应用需要处理完成多个进程访问同一个存储的问题）。如果PVC申请的存储空间比PV拥有的存储空间少，则整个PV的空间都能为PVC所用。但是这可能造成一定的资源浪费。如果资源供应使用的是动态模式，那么系统在为PVC找到合适的StorageClass后，将自动创建一个PV并完成与PVC的绑定。3.资源使用当Pod需要使用存储资源时，需要在Volume的定义中引用PVC类型的Volume，将PVC挂载到容器内的某个路径下进行使用。Volume的类型字段为“persistentVolumeClaim”。Pod在被挂载了PVC后，就可以使用存储资源了。4.资源回收用户使用完存储资源后，可以删除PVC。与该PVC绑定的PV会被标记为“已释放”，但它还不能立刻与其他PVC绑定。Pod在该PVC中生成的数据可能还被保留在PV对应的存储设备上。只有在清楚了这些数据后，才能再次使用该PV。PV的回收策略Retain（保留）Delete（删除）Retain策略 表示在删除PVC后，与之绑定的PV不会被删除，仅被标记为已释放（released）。PV中的数据仍然存在，在清空数据之前不能被新的PVC使用，需要管理员手动清理之后才能继续使用。清理步骤：删除PV资源对象，此时与该PV关联的某些外部存储资源提供者的后端存储资产（Asset）中的数据仍然存在。手动清理PV后端存储资产中的数据。手动删除后端存储资产。如果希望重用该资产，可以创建一个新的PV与之关联。Delete策略 表示自动删除PV资源对象和相关后端存储资产，同时会删除与该PV关联的后端存储资产。但并不是所有类型的存储资源都支持Delete策略。通过动态供应机制创建的PV将继承StorageClass的回收策略，默认为delete策略。管理员应该基于用户的需求来设置StorageClass的回收策略，或者在创建出PV后手动更新其回收策略。存储对象保护机制存储资源（PV、PVC）相对于容器应用（Pod）是可以独立管理的资源，可以单独将其删除。在执行删除操作时，系统会检测存储资源当前是否正在被使用，如果仍被使用，则相关资源对象的删除操作会被推迟，直到没有被使用才会执行删除操作。这样可以确保资源在仍被使用的情况下，不会被直接删除而导致数据丢失，这个机制被称为使用中的存储对象的保护机制（Storage Object in Use Protection）。对于PVC的删除操作将等到使用它的Pod被删除后再执行。当用户删除一个正在使用中的PVC时，PVC资源对象不会被立即立即删除，查看PVC资源对象的状态，可以看到其为“Terminating”，以及系统为其设置的Finalizer为“kubernetes.io/pvc-protection”，说明PVC资源对象处于被保护状态。对PV的删除操作将等到绑定的PVC删除之后再执行。当用户删除一个仍被PVC绑定的PV时，PV对象不会立即被删除，查看PV资源对象的状态，可以看到其为“Terminating”，以及系统为其设置的Finalizer为“kubernetes.io/pv-protection”，说明PV资源对象处于被保护状态。总的来说，PV与PVC的删除顺序是这样的：先删除正在使用PVC的Pod，再删除PVC，最后删除PV。

集群存储之持久卷介绍 Kubernetes支持的内置（in-tree）持久卷类型包括hostPath（宿主机目录）、FC（fibre Channel）、iSCSI(iSCSI存储设备)、Local（本地持久化存储）、NFS（基于NFS协议的网络文件系统）等资源。它们不作为PV资源对象被创建，而是直接在Pod的Volume字段被设置和使用。下面就常用的hostPath和NFS做简要介绍。hostPathhostPath类型的Volume用于将Node文件系统的目录或文件挂载到容器内部，并且在Pod删除后数据仍然被保留。由于hostPath直接使用宿主机的文件系统，无法被Kubernetes直接管理，因此存在很多安全风险，建议尽量不要使用。在必须要用时尽量以只读的方式将其挂载到容器内，以尽量减少对容器应用可能造成的破坏。使用场景容器应用的关键数据需要持久化保存到宿主机上；需要使用docker中的某些内部机制，可以将主机的/var/lib/docker目录挂载到容器内；监控系统，例如cAdvisor需要采集宿主机/sys/目录下的内容；Pod的启动依赖于宿主机上的某个目录或文件就绪。hostPath的主要配置参数为path，表示宿主机目录或文件路径；还可以设置一个可选的参数type，表示路径的操作类型。type的配置参数如下：type参数检校规则空默认值，系统在挂载path时不做任何检校DirectoryOrCreatepath指定的路径必须是目录，如果不存在系统将自动创建该目录，并将目录的权限设置为0755，具有与Kubelet相同的owner和groupDirectorypath指定的路径必须是目录，否则挂载失败FileOrCreatepath指定的路径必须是文件，如果不存在，系统将自动创建该文件，并将文件的权限设置为0644，具有与Kubelet相同的owner和groupFilepath指定的路径必须是文件，否则挂载失败SocketPath指定的UNIX Socket必须存在，否则挂载失败CharDevicepath指定的字符设备必须存在，否则挂载失败BlockDevicepath指定的块设备必须存在，否则挂载失败对于type为FileOrCreate模式的情况，如果挂载文件有上层目录，则系统不会自动创建上层目录，当上层目录不存在时，Pod启动失败。在这种情况下，可以将上层目录也设置为一个hostPath类型的Volume，并且设置type为DirectoryOrCreate，确保当目录不存在时，系统会自动创建出来。注意事项通过hostPath可能会将宿主机的某些具有特殊权限的文件挂载到容器内，例如Kubelet和容器运行时的Socket，使得容器的进程也能够越权对宿主机进行某些操作；对具有相同hostPath设置的多个Pod来说，可能会被master调度到多个Node上运行，但如果这些Node上的hostPath中的文件夹的内容（如配置文件这些）不同，则各个Pod的运行结果可能会出现差异；如果管理员设置了某些基于存储资源情况的调度策略，则hostPath目录下的磁盘空间将无法计入Node的可用资源范围内，可能出现与预期不同的调度结果；如果是之前不存在的路径，由Kubelet自动创建的文件或目录的owner和group将是root。这意味着如果容器内运行的用户（user）不是root，则将无法对该目录进行写操作，除非将容器设置为特权容器，或者由管理员修改hostPath的权限；hostPath设置的宿主机目录或文件不会随着Pod的销毁而被删除，而是在Pod被销毁之后，由管理员手动删除。NFSNFS类型的Volume用于将基于NFS协议的网络网络文件系统中的目录或文件挂载到容器内使用，并且在Pod被删除后数据仍然被保留。在Pod使用NFS协议的Volume之前，需要确保NFS服务正常运行。另外，也不能像PV那样使用mountOptions字段来定义挂载项。NFS卷可以在不同节点的Pod间共享数据。本地NFS客户端可以透明的读写位于远端NFS服务器上的 文件，就像访问本地文件一样。

集群存储之临时卷介绍 Volume在集群中也是一种资源，Pod通过挂载（Mount）的方式来使用一个或多个Volume。某些类型的Volume具有与Pod相同的生命周期，被称为“临时卷”。emptyDIr该类型的Volume在Pod被调度到Node时由Kubelet进行创建，在初始状态下是个空目录，被命名为“空目录”（Empty DIrectory）。它与Pod具有相同的生命周期，当Pod被销毁时，emptyDir对应的目录也会被删除。同一个Pod中的多个容器都可以挂载这种类型的Volume。使用场景基于磁盘进行合并排序操作时需要的暂存空间；长时间计算任务的中间检查点文件；为某个Web服务提供的临时网站内容文件。同一个Pod中容器共享数据使用内存提供存储服务emptyDir可以通过medium字段设置存储介质为“Memory”，表示使用基于内存的文件系统。需要注意的是，在主机重启后，内存中存储的信息会被清空。写入内存的数据将被计入容器的内存使用量，受到容器级别内存资源上限（Memory Resource Limit）的限制。示例{tabs}{tabs-pane label="示例1"}--- apiVersion: v1 kind: pod metadata: name: pod1 spec: containers: - image: busybox name: test1 volumeMounts: - mountPath: /cache name: cache-volume volumes: - name: cache-volume emptyDir: {}{/tabs-pane}{tabs-pane label="示例2"}#设置emptyDir使用内存 apiVersion: v1 kind: pod …… volumes: - name: cache-volume emptyDir: medium: "Memory"{/tabs-pane}{tabs-pane label="示例3"}#设置emptyDir使用内存,并设置可使用的内存上限 #需要开启SizeMemoryBackedVolumes apiVersion: v1 kind: pod …… volumes: - name: cache-volume emptyDir: medium: "Memory" sizeLimit: 500Mi{/tabs-pane}{/tabs}Generic EphemeralGeneric Ephemeral类型的Volume（通用临时卷）与emptyDir的功能相似，但更加灵活，有以下特性:后端的存储既可以是本地磁盘，也可以是网络存储；可以为Generic Ephemeral设置容量上限；在Generic Ephemeral内可以有一些初始数据。在驱动支持的情况下，Generic Ephemeral支持快照、克隆、调整大小、容量跟踪等标准的卷操作。示例--- apiVersion: v1 kind: pod metadata: name: my-app spec: containers: - name: my-frontend image: busybox command: [ "sleep", "1000" ] volumeMounts: - mountPath: "/scratch" name: scratch-volume volumes: - name: scratch-volume ephemeral: volumeClaimTemplate: matedata: labels: type: my-frontend-volume spec: accessModes: [ "ReadWriteOnce" ] storageClassName: "scratch-storage-class" resources: requests: storage: 1Gi 说明： 上面的示例中，Generic Ephemeral类型的Volume的参数设置需要从storageClass"scratch-storage-class"中申请1GiB的存储空间。根据volumeClaimTemplate的配置，系统将自动创建一个对应的PVC，并确保在删除Pod时自动删除这个PVC。这个PVC会以Pod的名称和Volume的名称的组合为其命名，中间以“-”连接，本例中PVC的名称是“my-app-scratch-volume”。某些情况下，这种命名机制可能会引起冲突，在部署Pod时需要注意。在安全方面，当用户有权限创建Pod的时候，Generic Ephemeral会隐式地创建一个PVC（即使用户没有创建PVC的权限），这可能不符合安全要求。{mtitle title="其他类型临时卷"/}Kubernetes的一些内部资源对象也可以通过Volume的形式挂载为容器的目录或文件，包括configMap、Secret、Downward API等，这些类型的Volume也是临时卷，会随着Pod的销毁而被系统删除。ConfigMapConfigMap主要保存应用所需的配置文件，并且通过Valume的形式挂载到容器内的文件系统中，以供容器内的应用读取。这样就可以做到配置文件与镜像的分离，使容器具有可移植性。ConfigMap在使用之前需要先创建它，ConfigMap不能用来保存大量的数据，其中保存的数据不可以超过1MIB。ConfigMap主要用来生成容器内的环境变量，设置容器启动命令的命令行参数（需要设置为环境变量），以Volume的形式挂载为容器内的文件或目录等。由于ConfigMap受限于命名空间，所以要引用ConfigMap的Pod必须与ConfigMap处于相同的命名空间中才能被成功引用。静态Pod因为不受master管理，无法引用ConfigMap。创建ConfigMap的方式ConfigMap中不存在spec字段，它通过data或binaryData字段定义配置数据。data字段用于保存经过utf-8编码的字符串，binaryData字段用于保存经过Base64编码的二进制数据。ConfigMap中有个immutable字段，用于设置配置数据不可更改。即ConfigMap一旦创建成功后就不可修改。设置这个字段可以防止意外更新ConfigMap对应用带来的异常影响，减少API Server监控ConfigMap的变化带来的性能损耗。1.基于本地配置文件--- apiVersion: v1 kind: ConfigMap metadata: name: cm-appvare data: apploglevel: info appdatadir: /var/data#通过kubectl创建这个ConfigMap kubectl apply -f cm-appvare.yaml2.基于kubectl命令行 可以直接通过kubectl create configmap 命令创建ConfigMap，支持通过下面三种参数来指定不同类型的数据源创建ConfigMap。--from-file：基于指定的文件或目录创建ConfigMap--from-env-file：基于指定的env文件创建ConfigMap--from-literal：基于指定的键值对创建ConfigMap--from-file 如果基于指定文件创建ConfigMap，默认情况下key的值会被设置为文件名，value的值会被设置为问几点内容。也可以通过命令行参数指定key名，不将文件名作为key名。如果基于指定的目录创建ConfigMap，则目录下的每个文件都会被创建为data中的一个key:value键值对。参数--from-file可以多次出现，用于在一个kubectl create命令行中将多个文件或目录创建到一个ConfigMap中。用文件名作为key值时需要注意文件名要符合key的命名规范，否则命令将运行失败。名称中只能使用这些字符：[a-z] [A-Z] [0-9] - _ .#在当前目录下存在server.xml文件，创建一个只包含该文件内容的ConfigMap kubectl create configmap server-config --from-file=server.xml #在当前目录下有个configs子目录，里面有两个配置文件，创建一个包含这两个配置文件内容的ConfigMap kubectl create configmap app-config --from-file=./configs #创建ConfigMap时指定key的名字为mykey kubectl create configmap server-config --from-file=mykey=server.xml #多次使用--from-file参数，创建一个包含多个配置文件内容的ConfigMap kubectl create configmap app-config --from-file=server.xml --from-file=logging.properties--from-env-file--from-env-file同样支持多次使用该参数创建一个包含多个源配置文件的ConfigMap。 env文件包含一组环境变量的配置数据，其内容遵循如下语法规则：每行文本都为VAR=VALUE的格式，等号两边不能有空格忽略以“#”开头的注释行忽略空行对文本中的引号不做转义处理，即保留原始文本并将其作为value的值#环境变量文件示例 cat log.properties level=FINE directory="${catalina.base}/logs" prefix=catalina. #通过kubectl create命令进行创建 kubectl create configmap log-env-config --from-env-file=log.properties --from-literal --from-literal可以多次使用从而生成多个ConfigMap的数据内容。使用该参数时只能直接从命令行输入键值对，适用于简单的环境变量或少量键值对。该参数生成的ConfigMap无法动态更新。kubectl create configmap appenv --from-literal=loglevel=info --from-literal=appdatadir=/var/data在Pod中使用ConfigMap容器应用通过以下两种方式使用ConfigMap将ConfigMap中的内容设置为容器的环境变量通过volume将ConfigMap中的内容挂载为容器内的文件或目录{tabs}{tabs-pane label="ConfigMap文件示例"}cat cm-appvars apiVersion: v1 kind: ConfigMap metadata: name: cm-appvars data: apploglevel: info appdatadir: /var/data{/tabs-pane}{tabs-pane label="挂载示例1"}apiVersion: v1 kind: Pod metadata: name: cm-test-pod spec: containers: - name: cm-test image: busybox command: [ "/bin/sh", "-c", "env | grep APP" ] env: - name: APPLOGLEVEL #定义环境变量的名称 valueFrom: #key"APPLOGLEVEL"对应的值 configMapKeyRef: name: cm-appvars #环境变量的值取自cm-appvars key: apploglevel #key为apploglevel - name: APPDATADIR #定义环境变量的名称 valueFrom: #key"APPDATADIR"对应的值 configMapKeyRef: name: cm-appvars #环境变量的值取自cm-appvars key: appdatadir #key为appdatadir restartPolicy: Never kubectl create -f cm-test-pod.yaml kubectl logs cm-test-pod APPDATADIR=/var/data APPLOGLEVEL=info{/tabs-pane}{tabs-pane label="挂载示例2"}--- apiVersion: v1 kind: Pod metadata: name: cm-test-pod spec: containers: - name: cm-test image: busybox command: [ "/bin/sh", "-c", "env" ] envFrom: - configMapRef: name: cm-appvars restartPolicy: Never kubectl apply -f cm-test-pod2.yaml kubectl logs cm-test-pod2 apploglevel=info appdatadir=/var/data{/tabs-pane}{/tabs}示例2中通过envFrom字段，实现了在Pod环境下将ConfigMap中的所有key:value键值对都自动生成环境变量。环境变量的命名受POSIX命名规范约束（a-zA-Z_*）,不能以数字开头。如果包含非法字符，则系统将挑过该环境变量的创建，并记录一个Event来提示环境变量无法生成，但并不阻止Pod的启动。通过Volume将ConfigMap中的内容挂载为容器内的文件或目录 {tabs}{tabs-pane label="configmap文件内容"}--- apiVersion: v1 kind: ConfigMap metadata: name: cm-appconfigfiles data: key-serverxml: | <?xml version='1.0' encoding='utf-8'?> <Server port="8005" shutdown="SHUTDOWN"> <Listener className="org.apache.catalina.startup.VersionLoggerListener" /> …… …… </Service> </Server> key-loggingproperties: "handlers = 1catalina.org.apache.juli.FileHandler, 2localhost.org.apache.juli.FileHandler, …… …… = 4host-manager.org.apache.juli.FileHandler\r\n\r\n"{/tabs-pane}{tabs-pane label="示例1"}--- apiVersion: v1 kind: Pod metadata: name: cm-test-app spec: containers: - name: cm-test-app image: kubeguide/tomcat-app:v1 ports: - containerPort: 8080 volumeMounts: - name: serverxml #引用Volume的名称 mountPath: /configfiles #挂载到容器内该目录下 volumes: - name: serverxml #定义Volume的名称 configMap: name: cm-appconfigfiles #指定ConfigMap的名称 items: - key: key-serverxml #ConfigMap中key的名称 path: server.xml #key对应的值（value）将以server.xml文件名挂载 - key: key-loggingproperties #ConfigMap中key的名称 path: logging.properties #key对应的值（value）将以logging.properties文件名挂载到容器内 kubectl exec -it cm-test-app --bash ls /configfiles sserver.xml logging.properties{/tabs-pane}{tabs-pane label="示例2"}#如果在引用ConfigMap时不指定items，则通过volumeMount方式在容器内的目录下为每个item都生成一个名为“key”的文件，文件的内容为key的值。 --- apiVersion: v1 kind: Pod metadata: name: cm-test-app spec: containers: - name: cm-test-app image: kubeguide/tomcat-app:v1 imagePullPolicy: Never ports: - containerPort: 8080 volumeMounts: - name: serverxml #引用Volume的名称 mountPath: /configfiles #挂载到容器的该目录下 volumes: - name: serverxml #定义Volume的名称 configMap: name: cm-appconfigfiles #使用ConfigMap“cm-appconfigfiles” kubectl exec -it cm-test-app --bash ls /configfiles key-loggingproperties key-serverxml {/tabs-pane}{/tabs}ConfigMap可选设置在Pod的定义中，可以将对ConfigMap的引用设置为是否可选（optional），若设置为可选（optional=true），则表示如果ConfigMap不存在，或者引用的数据项在ConfigMap中不存在，那么目标数据将被设置为空值。当ConfigMap被设置为Volume存储卷时，表示当ConfigMap不存在时，目标挂载的文件内容是空的。{tabs}{tabs-pane label="示例1"}--- apiVersion: v1 kind: Pod metadata: name: cm-test-pod-cm-env-optional spec: containers: - name: cm-test image: busybox command: [ "/bin/sh", "-c", "env | grep APP" ] env: - name: APPLOGLEVEL valueFrom: configMapKeyRef: name: cm-appvars key: apploglevel optional: true #设置为可选 - name: APPDATADIR valueFrom: configMapKeyRef: name: cm-appvars key: appdatadir optional: true #设置为可选 restartPolicy: Never kubec logs cm-test-pod-cm-env-optional [结果为空]{/tabs-pane}{tabs-pane label="示例2"}--- apiVersion: v1 kind: Pod metadata: name: cm-test-app-cm-volume-optional spec: containers: - name: tomcat image: busybox command: [ "/bin/sh", "-c", "tail -f /dev/null" ] volumeMounts: - name: serverxml mountPath: /configfiles volumes: - name: serverxml configMap: name: cm-appconfigfiles optional: true kubectl exec -it cm-test-app-cm-volume-optional --bash ls /configfiles [结果为空]{/tabs-pane}{/tabs}SecretSecret专门用于保存机密数据。在设置Secret.data字段时，所有键值都必须是经过base64编码的字符串。Secret主要用来为容器配置环境变量，挂载配置文件/目录到容器。此外，由Kubelet为Pod拉取镜像时，在需要登录仓库的时候使用。Downward API通过Downward API 可以将Pod或者Container的某些元数据信息（如Pod名称、Pod IP、Node Ip、Label、Annotation、容器资源限制等）以文件的形式挂载到容器内，以供容器内的应用使用。Downward API可以通过两种方式将Pod和容器的元数据信息注入到容器内。环境变量方式：将Pod或container的配置信息设置为容器内的环境变量Volume挂载方式：将Pod或container的配置信息以文件的形式挂载到容器内Downward API支持设置的Pod和Container信息可以通过fieldRef设置的字段字段名说明metadata.namePod名称metadata.namespacePod所在名称空间的名称metadata.uidPod的UIDmetadata.labels['']Pod的某个Label的值，通过引用metadata.annotations['']Pod某个Annotation的值，通过引用Pod的以下元数据信息可以被设置为容器内的环境变量，但在设置downwardAPI为存储卷类型时不能再设置filedRef字段的内容字段名说明spec.serviceAccountNamePod使用的ServiceAccount名称spec.nodeNamePod所在的Node的名称status.hostIPPod所在Node的IP地址status.hostIPsPod所在Node的IPv4和IPv5双栈地址status.podIPPod的IP地址status.podIPsPod的IPv4和IPv5双栈地址在设置downwardAPI为存储卷类型时，可以在其fieldRef字段设置以下信息，但不能通过环境变量的方式设置。mmetadata.lables：Pod的Label列表，每个Lable都以key为文件名，value为文件的内容，每个Label各占一行metadata.annotation：Pod的Annotation列表，每个Annotation都以key为文件名，value为文件的内容，每个Annotation各占一行可以通过resourceFieldRef设置的字段字段名说明limits.cpuContainer级别的CPU Limitrequests.cpuContainer级别的CPU Requestlimits.memoryContainer级别的Memory Limitrequests.memoryContainer级别的Memory Requestlimits.hugepages-*Container级别的HugePage（巨页）Limitrequests.hugepages-*Container级别的HugePage（巨页）Requestlimits.ephemeral-storageContainer级别的临时存储空间Limitrequests.ephemeral-storageContainer级别的临时存储空间RequestProjected VolumeProjected Volume是一种特殊的Volume类型，用于将一个或多个资源对象（ConfigMap、Secret、Downward API）一次性挂载到容器内的同一个目录下。常见应用场景通过Pod的标签生成不同的配置文件，需要使用配置文件及用户名和密码时，需要使用3种资源：ConfigMap、Secret、Downward API。在自动化运维应用中使用配置文件和帐号信息时，需要使用ConfigMap、Secret。在配置文件中使用Pod名称（metadata.name）记录日志时，需要使用ConfigMap、Downward API。使用某个Secret对Pod所在的命名空间（metadata.namespace）进行加密时，需要使用Secret、Downward API。Project Volume在Pod的Volume定义中类型为projected，通过sources字段来设置一个或多个的ConfigMap、Secret、Downward API、Service Account Token等资源。各种类型的资源配置内容与单独设置为Volume时基本一致，需要注意以下两个不同点：对于Secret类型的Volume，字段名“secretName”在projected.sources.secret中被改为“name”；Volume的挂载模式“defaultMode”只可以设置为projected级别。对于各子项，仍然可以设置各自的挂载模式，使用的字段名为“mode”。

对容器进行资源限额的几种方式 在一个集群内如何更合理的为大量容器分配有限的资源，是需要重点运维和管理的工作。