根据个人理解，可将kubernetes的各核心资源对象分为节点控制，网络，pod，请求转发，标签与注解，配置管理，权限管理，pod控制器，挂载，以下信息都是针对各资源对象做了最重要功能的介绍并不完全详细。
节点控制：
Master：是集群控制节点，每个kubernetes都需要一个master负责整个集群的管理和控制；master一般需要占据一个独立的服务器（高可用部署建议3台），当master宕机或者不可用，那么对集群内容器应用的管理都将失效。
Master运行着3个关键进程：
1、kubernetes API Server（kube-apiserver）：提供了HTTP Rest接口的关键服务进程，是kubernetes里所有资源的增，删，改，查等操作的唯一入口，也是集群控制的入口进程。
2、kubernetes Controller Manager（kube-controller-manager）：Kubernetes里所有资源对象的自动化控制中心，可以将其理解为资源对象的管理者。
3、Kubernetes Scheduler（kube-scheduler）：负责资源调度（Pod调度）的进程。
Node：是指在kubernetes集群内除master机器外其他机器都是Node；主要是负责在集群内接收调度负载，每个Node都会被master分配一些工作负载（也就是Docker容器），当某个Node宕机时，其上的工作负载会被master自动转移到其他节点上。
每个Node上运行着3个关键进程：
1、kubelet：负责Pod对应的容器的创建、启停等任务，同时与master密切协作，实现集群管理的基本功能。
2、kube-proxy：实现kubernetes Service的通信与负载均衡机制的重要组件。
3、Docker Engine：docker引擎，负责对本机容器的创建和管理工作。
网络：
Fannel：可以协助kubernetes，给每一个Node的Docker容器都分配互相不冲突的IP地址；可以在这些IP地址之间建立一个覆盖网络（Overlay Network），通过这个覆盖网络将数据包原封不动地传递到目标容器内。
CoreDNS：是使用GO语言实现的高性能，插件式，易扩展的DNS服务端。支持自定义DNS记录及配置upstream DNS Server，可以统一管理kubernetes基于服务的内部DNS和数据中心的物理DNS。
pod：
每个Pod都有一个特殊的被称为“根容器“的Pause容器。Pause容器对应的镜像属于kubernetes平台的一部分，除了Pause容器，每个Pod还包含一个或多个紧密相关的用户业务容器。
请求转发：
service：简单的说service就是通过Label Selector获取后端所需提供服务的Pod，然后定义了一个服务的访问入口地址，前端的应用（Pod）通过这个入口地址访问其背后的一组由Pod副本组成的集群实例。
ingress：用于将不同的URL访问请求转发到后端不同的Service，以实现HTTP层的路由机制。kubernetes使用了一个ingress策略定义和一个具体的Ingress Controller，两者相互配合才能实现一个完整的ingress负载均衡器。
标签与注解：
label：一个Label是一个key=value的键值对，其中key与value由用户自己指定。Label可以被附加到各种资源对象上，例如Node，Pod，Service，RC等，一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上。Label通常在资源对象定义时确定，也可以在对象创建后动态添加或删除。具有严格的命名规则，定义的是kubernetes对象的元数组（Metadata），并且用于Label Selector。
annotation：和Label类似，也使用key/value的方式定义。用于定义用户任意定义的附加信息，以便外部工具查找。
配置管理：
configMap：简单的理解就是将所需要的配置项用key/value以明文的方式通过Volume映射到目标Pod内
Secret：和configMap功能类似，但是是以密文的方式报错value信息。
权限管理：
RBAC：基于角色的访问控制；可以对集群中的资源和非资源权限完整的覆盖，整个RBAC完全由Role，ClusterRole，RoleBinding，ClusterRoleBinding对象完成。
ServiceAccount：是一个账号，是给运行在Pod里的进程使用的，它为Pod的进程提供了必要的身份证明。
pod控制器：
Replication Controller(RC)：较早的Pod控制器，用于确保Pod资源的不间断运行。
Replica Set(RS)：用于确保由其管控的Pod对象副本数在任一时刻都能精确满足期望的舒莱
Deployment：构建于ReplicaSet控制器之上，可为Pod和ReplicaSet资源提供声明式更新；相比较而言，Pod和ReplicaSet是较低级别的资源，很少被直接拿来使用；比RS更强大的功能有：
1、事件和状态查看：必要时可以查看Deployment对象升级的详细进度和状态
2、回滚：升级操作完成后发现问题时，支持使用回滚机制将应用返回到前一个或由用户指定的历史记录中的版本上。
3、版本记录：对Deployment对象的每一次操作都予以保存，以供后续可能执行的回滚操作使用。
4、暂停和启动：对于每一次升级，都能够随时暂停和启动。
5、多种自动更新方案：一是Recreate，即重建更新机制，全面停止、删除旧有的Pod后用新版本替代；另一个是RollingUpdate，即滚动升级机制，逐步替换旧有的Pod至新的版本。
DaemonSet：用于在集群中的全部节点上同时运行一份指定的Pod资源副本，后续新加入集群的工作节点也会自动创建一个相关的Pod对象，当从集群移除节点时，此类Pod对象也将被自动回收而无须重建。也可以使用节点选择器针对需要的节点运行Pod
Job：用于调配Pod对象运行一次性任务，容器中的进程在正常运行结束后不会对其进行重启，而是处于完成（Completed）状态
CronJob：用于管理Job控制器资源的运行时间。类似于Linux中的crontab
StatefulSet：用于部署和扩展有状态应用的Pod控制器，确保其运行顺序及每个Pod资源的唯一性。
挂载：
Volume：是指Pod中能够被多个容器访问的共享目录。当Volume被定义在Pod上，然后被一个Pod里的多个容器挂载到具体的文件目录下；Volume与Pod的生命周期相同，但与容器的生命周期不相关，当容器终止或者重启时，Volume中的数据也不好丢失。
Persistent Volume（pv）：可以被理解为kubernetes集群中的某个网络存储对应的一块存储，它与Volume类似，但有以下区别：
1、PV只能是网络存储，不属于任何Node，但可以在每个Node上访问。
2、PV并不是被定义在Pod上的，而是独立于Pod之外定义的。
3、PV支持的存储类型很多
Persistent Volume Claim(pvc)：作为用户对存储资源的需求申请，主要包括存储空间请求，访问模式，PV选择条件和存储类别等信息的设置。
storageclass：是对存储资源的抽象定义，对用户设置的PVC申请屏蔽后端存储的细节，一方面减少了用户对于存储资源细节的关注， 另一方面减轻了管理员手工管理PV的工作， 由系统自动完成PV的创建和绑定，实现了动态的资源供应。基于StorageClass的动态资源供应模式将逐步成为云平台的标准存储配置模式。
