比如，凡是调度、网络、存储，以及安全相关的属性，基本上是Pod 级别的。
这些属性的共同特征是，它们描述的是"机器"这个整体，而不是里面运行的"程序"。比如，配置这个"机器"的网卡（即：Pod的网络定义），配置这个"机器"的磁盘（即：Pod的存储定义），配置这个"机器"的防火墙（即：Pod的安全定义）。更不用说，这台"机器"运行在哪个服务器之上（即：Pod的调度）
- NodeSelector：是一个供用户将Pod与Node进行绑定的字段
- HostAliases：定义了Pod的hosts文件（比如/etc/hosts）里的内容
docker run里的-it（-i即stdin，-t即tty）参数。
如果你还是不太理解它们俩的作用的话，可以直接认为tty就是Linux给用户提供的一个常驻小程序，用于接收用户的标准输入，返回操作系统的标准输出。当然，为了能够在tty中输入信息，你还需要同时开启stdin（标准输入流）
- 凡是跟容器的Linux Namespace相关的属性，也一定是Pod 级别的，如：shareProcessNamespace=true
- 凡是Pod中的容器要共享宿主机的Namespace，也一定是Pod级别的定义
容器级别的字段：
- 首先，是ImagePullPolicy字段，ImagePullPolicy的值默认是Always，即每次创建Pod都重新拉取一次镜像，而如果它的值被定义为Never或者IfNotPresent，则意味着Pod永远不会主动拉取这个镜像，或者只在宿主机上不存在这个镜像时才拉取（如果镜像是latest，那么每次肯定是取最新的）
- 其次，是Lifecycle字段。它定义的是Container Lifecycle Hooks。顾名思义，Container Lifecycle Hooks的作用，是在容器状态发生变化时触发一系列"钩子"。
- Pod对象的Status字段，还可以再细分出一组Conditions。这些细分状态的值包括：PodScheduled、Ready、Initialized，以及Unschedulable。它们主要用于描述造成当前Status的具体原因是什么
Volumn
Volume，叫作Projected Volume，你可以把它翻译为"投射数据卷"，这些特殊Volume的作用，是为容器提供预先定义好的数据
到目前为止，Kubernetes支持的Projected Volume一共有四种：
Secret；
ConfigMap；
Downward API；
ServiceAccountToken。
- secret对象
Secret对象要求这些数据必须是经过Base64转码的，以免出现明文密码的安全隐患，在真正的生产环境中，你需要在Kubernetes中开启Secret的加密插件，增强数据的安全性
卷的核心是一个目录，其中可能包含一些数据，pod中的容器可以访问该目录。该目录的形成方式、支持它的介质以及它的内容由所使用的特定卷类型决定。
要使用卷，需要在.spec.volumes中指定要为pod提供的卷，并在.spec.containers[*].volumeMounts中声明加载这些卷到容器的位置。容器中的进程会看到一个文件系统视图，该视图由容器镜像的初始内容以及容器中装入的卷（如果已定义的话）组成。该进程会看到一个root文件系统，它最初与容器镜像的内容相匹配。如果允许，对该文件系统层次结构中的任何写入都会影响该进程在执行后续文件系统访问时查看的内容。在镜像中的指定路径上加载卷。对于pod中定义的每个容器，必须单独指定容器使用的每个卷的加载位置
与Secret类似的是ConfigMap，它与Secret的区别在于，ConfigMap保存的是不需要加密的、应用所需的配置信息。
-
获取pod信息
接下来是Downward API，它的作用是：让Pod里的容器能够直接获取到这个Pod API对象本身的信息，Downward API能够获取到的信息，一定是Pod里的容器进程启动之前就能够确定下来的信息
-
授权
像这样的Service Account的授权信息和文件，实际上保存在它所绑定的一个特殊的Secret对象里的。这个特殊的Secret对象，就叫作ServiceAccountToken。任何运行在Kubernetes集群上的应用，都必须使用这个ServiceAccountToken里保存的授权信息，也就是Token，才可以合法地访问API Server。
这种把Kubernetes客户端以容器的方式运行在集群里，然后使用default Service Account自动授权的方式，被称作"InClusterConfig"，也是我最推荐的进行Kubernetes API编程的授权方式。
-
健康检查
在Kubernetes中，你可以为Pod里的容器定义一个健康检查"探针"（Probe）。这样，kubelet就会根据这个Probe的返回值决定这个容器的状态，而不是直接以容器镜像是否运行（来自Docker返回的信息）作为依据。
在容器启动5 s后开始执行（initialDelaySeconds: 5），每5 s执行一次（periodSeconds: 5）
-
恢复机制
Pod的恢复过程，永远都是发生在当前节点上，而不会跑到别的节点上去，
Pod恢复机制，也叫restartPolicy。它是Pod的Spec部分的一个标准字段（pod.spec.restartPolicy），默认值是Always，即：任何时候这个容器发生了异常，它一定会被重新创建。
而如果你想让Pod出现在其他的可用节点上，就必须使用Deployment这样的"控制器"来管理Pod，哪怕你只需要一个Pod副本
readinessProbe的字段。虽然它的用法与livenessProbe类似，但作用却大不一样。readinessProbe检查结果的成功与否，决定的这个Pod是不是能被通过Service的方式访问到，而并不影响Pod的生命周期。
-
如何追加信息到Pod
比如，开发人员只需要提交一个基本的、非常简单的Pod YAML，Kubernetes就可以自动给对应的Pod对象加上其他必要的信息，比如labels，annotations，volumes等等。而这些信息，可以是运维人员事先定义好的。
运维人员就可以定义一个PodPreset对象。在这个对象中，凡是他想在开发人员编写的Pod里追加的字段，都可以预先定义好
PodPreset里定义的内容，只会在Pod API对象被创建之前追加在这个对象本身上，而不会影响任何Pod的控制器的定义