认识K8S集群资源时，不再按照传统方式以节点单元切分，笔者选择工作负载，存储以及网络这三个方面介绍资源类型，是基于K8S提供的核心资源对象Pod，PVC/PV以及Service/Ingress实现了最基本的集群资源管理与容器编排。
K8S通过Pod来管理一组容器组的生命周期，Pod是K8S调度的最小单元。应用服务部署与调度也是以Pod为单元，Pod也可称之为工作负载。对于无状态的应用部署，以ReplicaSet定义与管理；对于有依赖关系，有状态的应用部署，以StatefulSet定义与管理。ReplicaSet与StatefulSet又是一个有意思的话题，笔者会在后续系列详细介绍。应用所需的CPU/内存资源定义在Pod内，因为CPU/内存资源是容器级别的，由Pod的spec->containers->resources定义。
容器共享所在Pod的存储Volume，网络命名空间以及PID命名空间，容器拥有CPU/内存资源分配与资源额度。在进行资源管理时，要区分CPU/内存资源分配额度和工作负载实际的CPU/内存利用率。K8S集群信息控制台一般展示工作负载定义的CPU/内存分配额度。
看起来PV抽象就已足够解决K8S存储资源适配各个云厂商的IaaS存储资源，为什么还要再多此一举搞一个PVC资源对象抽象呢？PVC类似OOP中的抽象类。在开发中使用抽象类通常是想解耦对象调用与对象实现。Pod绑定PVC而非PV，是将Pod部署与PV资源分配解耦。
Pod部署一般属于研发团队应用部署的子环节，由开发人员控制。PV存储资源定义与分配则多属于devops团队，由集群管理员控制。
Pod和PVC是命名空间访问控制范围内的资源对象，PV则是集群访问控制范围内的资源对象。
PVC/PV模式解耦了存储资源与节点资源，即由PVC/PV定义的存储资源独立于节点资源，通过动态绑定方式随工作负载在节点资源间迁移。具体细节依赖于云厂商提供的存储插件的实现方式。
PVC/PV模式解耦了存储资源与节点资源，即由PVC/PV定义的存储资源独立于节点资源，通过动态绑定方式随工作负载在节点资源间迁移。具体细节依赖于云厂商提供的存储插件的实现方式。
Service实现了服务端自动发现机制，即提供应用服务的一组Pod可以通过同一个服务域名访问地址对外提供服务，Pod的新增或者销毁不会影响该服务整体服务性能。工作负载通过Service绑定了一个虚拟IP以及端口，对于Pod分配的节点资源并不敏感，解耦了Service与节点网络资源，使得整个集群具备负载迁移，故障自愈的能力。
Ingress与Service对象不同，是K8S对集群外部提供服务的一种资源对象。在K8S出现之前，我们对于负载与流量控制，多是采用Nginx反向代理和负载均衡，横向扩展服务端处理负载的能力。Ingress本质上就是一个NginxPod，这个Pod也是通过Service对象暴露出来，基于LoadBalancer模式对外提供反向代理与负载均衡。
Ingress很像一个集群的路由器和访问入口，通过在ingress配置路由规则绑定工作负载与对应域名解析路径，达到只使用一个外部IP就能将多个集群内部的服务暴露出来，从而节省IP资源。
