[系统运维]k8s-集群资源介绍及管理

k8s集群资源介绍及管理

1.k8s中的资源

K8s 中所有的内容都抽象为资源， 资源实例化之后，叫做对象

在k8s中,任何可以被申请、分配，最终被使用的对象，都是 kubernetes 中的资源，比如 CPU、内存。

1.1集群资源分类

1.1.1名称空间级别资源

仅在此名称空间下生效，如k8s的系统组件是默认放在kube-system名称空间下的，而kubectl get pod等价于kubectl get pod -n default，因此查看不到k8s的系统组件。

1.工作负载型资源(workload）：Pod【k8s最小组成部分，共享网络栈共享存储卷】、ReplicaSet【RS，调度器、控制器，通过标签去控制pod的创建、副本数量】、Deployment【控制器，通过控制RS的创建去创建pod】、StatefulSet【为有状态服务所建立的管理器】、DaemonSet【可以在每一个节点都运行一个pod的组件】、Job【工作、任务】、CronJob【轮询工作、轮询任务，为批处理而生的】（ReplicationController在v1.11版本被废弃）

2.服务发现及负载均衡型资源（ServiceDiscovery LoadBalance):Service【简称svc，服务，将服务暴露出去】、Ingress【将服务暴露出去】、…

3.配置与存储型资源：Volume（存储卷）【给pod提供持久化的能力】、CSI（容器存储接口，可以扩展各种各样的第三方存储卷)

4.特殊类型的存储卷：ConfigMap（当配置中心来使用的资源类型）【一般用来存储配置文件达到热更新的状态】、Secret（保存敏感数据）【加密方案存储数据，一般用来保存密码文件、密钥等等】、DownwardAPI（把外部环境中的信息输出给容器）【类似于CSI，】

利用KUBERNETES名称空间来管理内存和CPU资源

1.1.2集群级别资源

全集群可见可调用,不属于任何名称空间，因此资源对象的名称必须全局唯一。

不管在任何名称空间下定义，在其他的名称空间下都能看得到，在定义的时候无需指定名称空间.例如：Namespace【名称空间】、Node【节点】、Role【角色】、ClusterRole、RoleBinding、ClusterRoleBinding

1.1.3元数据型

可以通过指标进行操作。

提供一个指标，不像是名称空间类型又不像集群级别，本质上更像是在两者之间，但是它有自己的特点，所以更应该作为一个单独的分类，例如HPA【通过cpu的利用率进行平滑扩展】就是一个很明显的元数据类型，通过指标进行操作。根据一些指标去进行对应的操作.例如：HPA、PodTemplate【pod模板】、LimitRange【资源限制】.

如HPA,可以通过CPU当前利用率进行平滑扩展

1.2资源介绍

1.2.1 Pod

Pod是Kubernetes调度的最小单元。一个Pod可以包含一个或多个容器，因此它可以被看作是内部容器的逻辑宿主机。Pod的设计理念是为了支持多个容器在一个Pod中共享网络和文件系统 因此处于一个Pod中的多个容器共享以下资源：

PID命名空间：Pod中不同的应用程序可以看到其他应用程序的进程ID。

network命名空间：Pod中多个容器处于同一个网络命名空间，因此能够访问的IP和端口范围都是相同的。也可以通过localhost相互访问。

IPC命名空间：Pod中的多个容器共享Inner-process Communication命名空间，因此可以通过SystemV IPC或POSIX进行进程间通信。
UTS命名空间：Pod中的多个容器共享同一个主机名。

Volumes：Pod中各个容器可以共享在Pod中定义分存储卷（Volume）。

Pod好处:

Pod做为一个可以独立运行的服务单元，简化了应用部署的难度，以更高的抽象层次为应用部署管提供了极大的方便。

Pod做为最小的应用实例可以独立运行，因此可以方便的进行部署、水平扩展和收缩、方便进行调度管理与资源的分配。

Pod中的容器共享相同的数据和网络地址空间，Pod之间也进行了统一的资源管理与分配。

Pod，容器与Node（工作主机）之间的关系如下图所

K8S集群内POD/容器创建的过程：

apiVersion: v1
kind: Pod
metadata:
  name: nginx1
  labels:
    app: web
spec:
  containers:
    \- name: front-end
      image: nginx
      ports:
        \- containerPort: 80

1.2.2Label（标签）

在为对象定义好Label后，其他对象就可以通过Label来对对象进行引用。Label的最常见的用法便是通过spec.selector来引用对象。

apiVersion: v1
kind: ReplicationController
metadata:
name: nginx
spec:
replicas: 3
selector:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: nginx
ports:
- containerPort: 80

关于Label的用法重点在于这两步：

通过template.metadata.labels字段为即将新建的Pod附加Label。在上面的例子中，新建了一个名称为nginx的Pod，它拥有一个键值对为app:nginx的Label。

通过spec.selector字段来指定这个RC管理哪些Pod。在上面的例子中，新建的RC会管理所有拥有app:nginxLabel的Pod。这样的spec.selector在Kubernetes中被称作Label Selector。

使用Label可以给对象创建一组或多组标签，Service，ReplicationController ReplicaSet,Deployment等组件则通过Label Selector来定位需要管理的对象，Label和Label Selector共同构成了Kubernetes系统中最核心的应用模型，使得对象能够精细分组，同时实现了集群的高可用性。

1.2.3 Deployment

Deployment一般使用的场景都是和RS一起使用，那它们的具体原理是怎样的呢？
先看一下Deployment、RS、Pod它们三者之间的关系：

RS负责控制副本数量，由Deployment来创建具体的Pod，但是如果遇到版本更新的操作会怎样呢？

Deployment控制器支持两种更新策略：滚动更新（rolling update）和重新创建（recreate），默认为滚动更新。

Kubernetes之Deployment详解

1.2.4 Replication Controller

在旧版本的Kubernetes中，只有ReplicationController对象。它的主要作用是确保Pod以你指定的副本数运行，即如果有容器异常退出，会自动创建新的 Pod 来替代；而异常多出来的容器也会自动回收。可以说，通过ReplicationController，Kubernetes实现了集群的高可用性。

Replication Controller已经过期,建议使用使用 Deployment 配合ReplicaSet.

RC只支持基于等式的Selector，而RS两种Selector都支持。而RC是很早版本就建议弃用的特征,因此实际项目中强烈建议使用Deployment来代替Repliation Controller (RC)

1.2.5 Replica Set

在新版本的 Kubernetes 中建议使用 ReplicaSet（简称为RS ）来取代 ReplicationController。ReplicaSet 跟 ReplicationController 没有本质的不同，只是名字不一样，并且 ReplicaSet 支持集合式的 selector（ReplicationController 仅支持等式）。

由于Replication Controller与Kubernetes代码中的模块Replication Controller同名，同时这个词也无法准确表达它的意思，所以从Kubernetes v1.2开始，它就升级成了另外一个新的对象——Replica Set，官方解释为“下一代的RC”。它与RC当前存在的唯一区别是：Replica Set支持基于集合的Label selector（Set-based selector），而RC只支持基于等式的Label selector（equality-based selector），所以Replica Set的功能更强大。

Replica Set很少单独使用，它主要被Deployment这个更高层的资源对象所使用，从而形成一整套Pod创建、删除、更新的编排机制。RC和RS的特性与作用如下：

在大多情况下，我们通过定义一个RC实现Pod的创建过程及副本数量的自动控制。

RC里包括完整的Pod定义模板。

RC通过Label Selector机制实现对Pod副本的自动控制。

通过改变RC里的Pod副本数量，可以实现Pod的扩容或缩容功能。

通过改变RC里Pod模板中的镜像版本，可以实现Pod的滚动升级功能。

1.2.6 Horizontal Pod Autoscaler(HPA)

Kubernetes有一个HPA(Horizontal Pod Autoscaler)的资源，可以实现基于CPU使用率的Pod自动伸缩的功能.
注意从kubernetes1.11开始Heapster被废弃不在使用，metrics-server 替代了heapster
实现HPA首先需要部署metrics-server，一个集群级别的资源利用率数据的聚合器

Horizontal Pod Autoscaler 根据观察到的CPU利用率（或在支持自定义指标的情况下，根据其他一些应用程序提供的指标）自动伸缩 replication controller, deployment, replica set, stateful set 中的pod数量。注意，Horizontal Pod Autoscaling不适用于无法伸缩的对象，例如DaemonSets。

Horizontal Pod Autoscaler 被实现作为Kubernetes API资源和控制器。该资源决定控制器的行为。控制器会定期调整副本控制器或部署中副本的数量，以使观察到的平均CPU利用率与用户指定的目标相匹配。

Horizontal Pod Autoscaler 由一个控制循环实现，循环周期由 controller manager 中的–horizontal-pod-autoscaler-sync-period标志指定（默认是 30 秒）。

在每个周期内，controller manager 会查询 HorizontalPodAutoscaler 中定义的 metric 的资源利用率。Controller manager 从 resource metric API（每个 pod 的 resource metric）或者自定义 metric API（所有的metric）中获取 metric。

每个 Pod 的 resource metric（例如 CPU），controller 通过 resource metric API 获取 HorizontalPodAutoscaler 中定义的每个 Pod 中的 metric。然后，如果设置了目标利用率，controller 计算利用的值与每个 Pod 的容器里的 resource request 值的百分比。如果设置了目标原始值，将直接使用该原始 metric 值。然后 controller 计算所有目标 Pod 的利用率或原始值（取决于所指定的目标类型）的平均值，产生一个用于缩放所需 replica 数量的比率。 请注意，如果某些 Pod 的容器没有设置相关的 resource request ，则不会定义 Pod 的 CPU 利用率，并且 Aucoscaler 也不会对该 metric 采取任何操作。

对于每个 Pod 自定义的 metric，controller 功能类似于每个 Pod 的 resource metric，只是它使用原始值而不是利用率值。

对于 object metric，获取单个度量（描述有问题的对象），并与目标值进行比较，以产生如上所述的比率。

HorizontalPodAutoscaler 控制器可以以两种不同的方式获取 metric ：直接的 Heapster 访问和 REST 客户端访问。

当使用直接的 Heapster 访问时，HorizontalPodAutoscaler 直接通过 API 服务器的服务代理子资源查询 Heapster。需要在集群上部署 Heapster 并在 kube-system namespace 中运行。

Autoscaler 访问相应的 replication controller，deployment 或 replica set 来缩放子资源。

Scale 是一个允许您动态设置副本数并检查其当前状态的接口。

http://carey.akhack.com/2019/05/28/kubernetes-hpa/

1.2.7 StatefulSet

使用Deployment创建的Pod是无状态的，当挂在Volume之后，如果该Pod挂了，Replication Controller会再run一个来保证可用性，但是由于是无状态的，Pod挂了的时候与之前的Volume的关系就已经断开了，新起来的Pod无法找到之前的Pod。但是对于用户而言，他们对底层的Pod挂了没有感知，但是当Pod挂了之后就无法再使用之前挂载的磁盘了。

StatefulSet: 是一种给Pod提供唯一标志的控制器，它可以保证部署和扩展的顺序。

实现原理:

与 ReplicaSet 和 Deployment 资源一样，StatefulSet 也使用控制器的方式实现，它主要由 StatefulSetController、StatefulSetControl 和 StatefulPodControl 三个组件协作来完成 StatefulSet 的管理，StatefulSetController 会同时从 PodInformer 和 ReplicaSetInformer 中接受增删改事件并将事件推送到队列中：

控制器 StatefulSetController 会在 Run 方法中启动多个 Goroutine 协程，这些协程会从队列中获取待处理的 StatefulSet 资源进行同步.

https://blog.51cto.com/u_14320361/2470549

1.2.8 Service（服务）

发现后端pod服务,为一组具有相同功能的容器应用提供一个统一的入口地址,将请求进行负载分发到后端的各个容器应用上的控制器。

访问service的请求来源有两种：k8s集群内部的程序（Pod）和 k8s集群外部的程序。

https://zhuanlan.zhihu.com/p/39909011

1.2.9 Ingress

Ingress 简单的理解就是你原来需要改 Nginx 配置，然后配置各种域名对应哪个 Service，现在把这个动作抽象出来，变成一个 Ingress 对象，你可以用 yaml 创建，每次不要去改 Nginx 了，直接改 yaml 然后创建/更新就行了；那么问题来了：”Nginx 该怎么处理？”

Ingress Controller 这东西就是解决 “Nginx 的处理方式” 的；Ingress Controoler 通过与 Kubernetes API 交互，动态的去感知集群中 Ingress 规则变化，然后读取他，按照他自己模板生成一段 Nginx 配置，再写到 Nginx Pod 里，最后 reload 一下

https://www.cnblogs.com/linuxk/p/9706720.html

1.2.10 Volume（存储卷）

? Volume是k8s抽象出来的对象，用于解决Pod中的容器运行时，文件存放的问题以及多容器数据共享的问题。Kubernetes 卷具有明确的生命周期——与包裹它的 Pod 相同。卷比 Pod 中运行的任何容器的存活期都长，在容器重新启动时数据也会得到保留。 当然，当一个 Pod 不再存在时，卷也将不再存在。

更重要的是，Kubernetes 可以支持许多类型的卷，Pod 也能同时使用任意数量的卷。卷的核心是包含一些数据的目录，Pod 中的容器可以访问该目录。 特定的卷类型可以决定这个目录如何形成的，并能决定它支持何种介质，以及目录中存放什么内容。使用卷时, Pod 声明中需要提供卷的类型 (.spec.volumes 字段)和卷挂载的位置 (.spec.containers.volumeMounts 字段)。

? kubelet创建Pod时，会先创建一个基础容器pause，Pod里面所有的容器共享一个网络名称空间和文件系统。挂载卷的工作就是由基础容器pause来完成的。

在K8S中，数据卷是通过Pod实现持久化的，如果Pod删除，数据卷也会一起删除，k8s的数据卷是docker数据卷的扩展，K8S适配各种存储系统，包括本地存储EmptyDir,HostPath,网络存储NFS,GlusterFS,PV/PVC等

1.2.11 Persistent Volume

上面提到的Volume是定义在Pod上的，属于“计算资源”的一部分，而实际上，“网络存储”是相对独立于“计算资源”而存在的一种实体资源。比如在使用云主机的情况下，我们通常会先创建一个网络存储，然后从中划出一个“网盘”并挂载到云主机上。Persistent Volume（简称PV）和与之相关联的Persistent Volume Claim（简称PVC）实现了类似的功能。PV与Volume的区别如下：

PV只能是网络存储，不属于任何Node，但可以在每个Node上访问。

PV并不是定义在Pod上的，而是独立于Pod之外定义。

PersistentVolume（PV）用于为用户和管理员提供如何提供和消费存储的API，PV由管理员在集群中提供的存储。它就像Node一样是集群中的一种资源。PersistentVolume 也是和存储卷一样的一种插件，但其有着自己独立的生命周期。PersistentVolumeClaim (PVC)是用户对存储的请求，类似于Pod消费Node资源，PVC消费PV资源。Pod能够请求特定的资源(CPU和内存)，声明请求特定的存储大小和访问模式。PV是一个系统的资源，因此没有所属的命名空间。

https://www.kubernetes.org.cn/4069.html

1.2.12 Namespace（命名空间）

Kubernetes中提供了命名空间（Namespaces），是Kubernetes提供的一种组织资源机制，用于给集群中的任何对象组进行分类、筛选和管理。 但是如果你的团队规模比较小并且集群规模也不大，完全可以不用Namespaces而使用labels来区分不同的资源，随着项目增多、集群规模扩大、人员的增加，你才需要使用Namespaces，通过namespace你可以创建多个虚拟的集群。

Namespaces提供了一种在不同用户间分隔集群资源的方法，未来Kubernetes可能会提供基于命名空间的权限控制。

命名空间的一些重要作用:

1.使用同一个命名空间帮助pod到pod的通信。

\2. 充当驻留在同一个理集群上的虚拟集群。

\3. 在团队及其环境之间提供了逻辑隔离。

Kubernetes默认有三个命名空间

default: 默认的命名空间

kube-system: 由Kubernetes系统对象组成的命名空间

kube-public: 该空间由系统自动创建并且对所有用户可读性，做为集群公用资源的保留命名空间。

1.2.13 Annotation（注解）

Annotation与Label类似，也使用key/value键值对的形式进行定义。不同的是Label具有严格的命名规则，它定义的是Kubernetes对象的元数据（Metadata），并且用于Label Selector。而Annotation则是用户任意定义的“附加”信息，以便于外部工具进行查找，很多时候，Kubernetes的模块自身会通过Annotation的方式标记资源对象的特殊信息。

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

build信息、release信息、Docker镜像信息等，例如时间戳、release id号、PR号、镜像hash值、docker registry地址等。

日志库、监控库、分析库等资源库的地址信息。

程序调试工具信息，例如工具、版本号等。

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

1.2.14 DaemonSet

DaemonSet确保集群中每个（部分）node运行一份pod副本，当node加入集群时创建pod，当node离开集群时回收pod。如果删除DaemonSet，其创建的所有pod也被删除，DaemonSet中的pod覆盖整个集群。

当需要在集群内每个node运行同一个pod，使用DaemonSet是有价值的，以下是典型使用场景：

运行集群存储守护进程，如glusterd、ceph。

运行集群日志收集守护进程，如fluentd、logstash。

运行节点监控守护进程，如Prometheus Node Exporter, collectd, Datadog agent, New Relic agent, or Ganglia gmond。

https://www.cnblogs.com/tylerzhou/p/11007427.html

2.资源管理

资源管理方式有三种

#命令式对象管理：直接用命令操作kubernetes资源

kubectl run nginx --image=nginx:1.17.1 --port=80

#命令式对象配置：通过命令配置和配置文件去操作kubernetes资源

kubectl cteate/patch -f nginx-pod.yaml

#声明式对象配置：通过apply命令和配置文件去操作kubernetes资源

kubectl apply -f nginx-pod.yaml

2.1命令式对象管理

kubectl命令

kubectl是kubernetes集群的命令行工具，通过它能够对集群本身进行管理，并能够在集群上进行容器化应用的安装部署。kubectl命令的语法如下:

kubectl [command] [type][name] [flags]

comand:指定要对资源执行的操作，例如create、get、delete

type:指定资源类型，比如deployment、pod、service

name:指定资源的名称，名称大小写敏感

flags:指定额外的可选参数

*#查看所有pod
*kubectl get pod
*#查看某个pod
*kubectl get pod pod_name
*#查看某个pod,l以yaml格式展示结果
*kubectl get pod pod_name -o yaml

*#可以查看命令的简写
*kubectl api-resources
*#创建一个namespace名声空间 namespace=ns
*kubectl create ns dev
*#查看ns名声空间
*kubectl get ns
*#在名声空间创建并运行一个nginx的pod
*kubectl run pod --image=nginx -n dev
*#查看创建的pod
*kubectl gte pod -n dev
*#删除创建的pod
*kubectl delete pod xxx 或者 kubectl delete pod pod -n dev
*#删除名声空间
*kubectl delete ns dev
*#详细查询
*kubectl get pod -n dev -o wide
*#详细查询pod信息
*kubectl describe pod mysql -n dev
*#查看deployment
*kubectl get deployment -n dev
*#打标签
*kubectl label pod nginx -n dev nginx:1.0
*#更新标签
*kubectl label pod nginx -n dev nginx:2.0 --overwrite
*#删除标签
*kubectl label pod nginx -n dev nginx-
*#声明式对象配置(只能安装与更新)
*kubectl apply -f nginxpod.yaml

2.2命令式对象配置

apiVersion: v1
kind: Namespace
metadata:
name: dev

—

apiVersion: v1
kind: pod
metadata:
name: nginxpod
namespace: dev
spec:
containers:
- name: nginx-containers
image: nginx:1.17.1

*#执行create命令，创建资源
*kubectl create -f nginxpod.yaml
namespace / dev created
pod/ nginxpod created
此创建的两个资源对象，分别是namespace和pod
*#执行gte命令，查看资源
*mubectl get -f nginxpod.yaml

2.3声明式对象配置(只能安装与更新)

kubectl apply -f nginxpod.yaml

2.4管理方式总结

其实声明式对象配置就是使用apply描述一个资源最终的状态（在yaml中定义状态）

apply操作资源:

如果资源不存在,就创建,相当于kubectl create.

如果资源已存在，就更新，相当于kubectl patch

kubectl的运行是需要进行配置的，它的配置文件是$HOME/.kube，如果想要在node节点运行此命令，需要;naster上的.kube文件复制到node节点上,即在master节点上执行下面操作：

scp-rHOME/ .kube node1 : HOME/

使用推荐:三种方式应该怎么用?

创建/更新资源 使用声明式对象配置 kubectl apply -f xXX.yaml

删除资源 使用命令式对象配置 kubectl delete -f xX.yaml

查询资源 使用命令式对象管理 kubectl get(describe)资源名称

3.资源清单

资源清单是K8S的一种yml格式文件，按照这种文件，可以自定义的去创建K8S的资源。

k8s一般都是通过定义资源清单的方式去创建资源.资源清单等价于剧本，写好了每一步应该如何去做.

在k8s中，一般使用yaml格式的文件来创建符合我们预期期望的资源，这样的yaml文件我们一般称为资源清单.

3.1资源清单常用的字段

3.1.1必须存在的属性

【创建资源清单的时候没有这些属性的存在它是不允许被执行的】

3.1.2主要属性

【这些属性比较重要，如果不指定的话系统会自动补充默认值】

3.1.3额外的参数项

查看资源有那些资源清单属性，使用以下命令

kubectl explain pod

查看属性说明，使用以下命令

kubectl explain pod.apiVersion

3.2资源清单格式

apiVersion: group/apiversion #如果没有给定group名称，那么默认为core，可以使用kubectlapi-versions命令获取当前k8s版本上所有的apiversion版本信息（每个版本可能不同）kind: #资源类别 metadata: #资源元数据 name: namespace: lables: annotations: #主要目的是方便用户阅读查找 spec: #期望的状态（disired state) status: #当前状态，本字段由Kubernetes自身维护，用户不能去定义

3.4资源清单的常用命令

1.获取apiVersion版本信息

kubectl api-versions

2.获取资源的apiVersion的版本信息(以pod为例)，该命令同时输出属性设置帮助文档

kubectl explain pod

*字段配置格式

3.5 通过定义清单文件创建Pod

3.5.1 YAML语法规则：

大小写敏感

使用缩进表示层级关系

缩进时不允许使用Tal键，只允许使用空格

缩进的空格数目不重要，只要相同层级的元素左侧对齐即可

”#” 表示注释，从这个字符一直到行尾，都会被解析器忽略

apiVersion: v1
kind: Pod
metadata:
name: k8stomcat
labels:
app: web
spec:
containers:
- name: k8stomcat
image: hub.c.163.com/library/alpine
ports:
- containerPort: 80

通过yaml文件创建pod

kubectl create -f xxx.yaml

获取资源的资源配置文件

#使用 -o 参数 加 yaml，可以将资源的配置以yaml的格式输出出来，也可以使用json，输出为json格式

kubectl get pod {podName} -o yaml

3.5.2 kubernetes yaml文件解析

*#test-pod 
*apiVersion: v1 *#指定api版本，此值必须在kubectl apiversion中   
*kind: Pod *#指定创建资源的角色/类型   
*metadata: *#资源的元数据/属性   
\*  name: test-pod *#资源的名字，在同一个namespace中必须唯一   
\*  labels: *#设定资源的标签 
\*    k8s-app: apache
    version: v1
    kubernetes.io/cluster-service: "true"
  annotations:            *#自定义注解列表   
\*    - name: String        *#自定义注解名字   
*spec: *#specification of the resource content 指定该资源的内容   
\*  restartPolicy: Always *#表明该容器一直运行，默认k8s的策略，在此容器退出后，会立即创建一个相同的容器   
\*  nodeSelector:     *#节点选择，先给主机打标签kubectl label nodes kube-node1 zone=node1   
\*    zone: node1
  containers:
    \- name: test-pod *#容器的名字   
\*      image: 10.192.21.18:5000/test/chat:latest *#容器使用的镜像地址   
\*      imagePullPolicy: Never *#三个选择Always、Never、IfNotPresent，每次启动时检查和更新（从registery）images的策略， 
\*        *# Always，每次都检查 
\*        *# Never，每次都不检查（不管本地是否有） 
\*      *# IfNotPresent，如果本地有就不检查，如果没有就拉取 
\*      command: ['sh'] *#启动容器的运行命令，将覆盖容器中的Entrypoint,对应Dockefile中的ENTRYPOINT   
\*      args: ["$(str)"] *#启动容器的命令参数，对应Dockerfile中CMD参数   
\*      env: *#指定容器中的环境变量   
\*        - name: str *#变量的名字   
\*          value: "/etc/run.sh" *#变量的值   
\*      resources: *#资源管理 
\*        requests: *#容器运行时，最低资源需求，也就是说最少需要多少资源容器才能正常运行   
\*          cpu: 0.1 *#CPU资源（核数），两种方式，浮点数或者是整数+m，0.1=100m，最少值为0.001核（1m） 
\*          memory: 32Mi *#内存使用量   
\*        limits: *#资源限制   
\*          cpu: 0.5
          memory: 1000Mi
      ports:
        \- containerPort: 80 *#容器开发对外的端口 
\*          name: httpd  *#名称 
\*          protocol: TCP
      livenessProbe: *#pod内容器健康检查的设置 
\*        httpGet: *#通过httpget检查健康，返回200-399之间，则认为容器正常   
\*          path: / *#URI地址   
\*          port: 80
          *#host: 127.0.0.1 #主机地址   
\*          scheme: HTTP
        initialDelaySeconds: 180 *#表明第一次检测在容器启动后多长时间后开始   
\*        timeoutSeconds: 5 *#检测的超时时间   
\*        periodSeconds: 15  *#检查间隔时间   
\*        *#也可以用这种方法   
\*        *#exec: 执行命令的方法进行监测，如果其退出码不为0，则认为容器正常   
\*        *#  command:   
\*        *#    - cat   
\*        *#    - /tmp/health   
\*        *#也可以用这种方法   
\*        *#tcpSocket: //通过tcpSocket检查健康    
\*        *#  port: number    
\*      lifecycle: *#生命周期管理   
\*        postStart: *#容器运行之前运行的任务   
\*          exec:
            command:
              \- 'sh'
              \- 'yum upgrade -y'
        preStop:#容器关闭之前运行的任务
        exec:
          command: ['service httpd stop']
      volumeMounts:  *#挂载持久存储卷 
\*        - name: volume *#挂载设备的名字，与volumes[\*].name 需要对应     
\*          mountPath: /data *#挂载到容器的某个路径下   
\*          readOnly: True
  volumes: *#定义一组挂载设备   
\*    - name: volume *#定义一个挂载设备的名字   
\*      *#meptyDir: {}   
\*      hostPath:
        path: /opt *#挂载设备类型为hostPath，路径为宿主机下的/opt,这里设备类型支持很多种 
\*      *#nfs*