1、Master和Node1、MasterK8S中的Master是集群控制节点负责整个集群的管理和控制在Master上运行着以下关键进程kube-apiserver提供了HTTP Rest接口的关键服务进程是K8S里所有资源的增删改查等操作的唯一入口也是集群控制的入口进程kube-controller-managerK8S里所有资源对象的自动化控制中心集群内各种资源Controller的核心管理者针对每一种资源都有相应的Controller保证其下管理的每个Controller所对应的资源始终处于期望状态kube-scheduler负责资源调度Pod调度的进程通过API Server的Watch接口监听新建Pod副本信息并通过调度算法为该Pod选择一个最合适的NodeetcdK8S里的所有资源对象以及状态的数据都被保存在etcd中2、NodeNode是K8S集群中的工作负载节点每个Node都会被Master分配一些工作负载当某个Node宕机时其上的工作负载会被Master自动转移到其他节点上在每个Node上都运行着以下关键进程kubelet负责Pod对应的容器的创建、启停等任务同时与Master密切协作实现集群管理的基本功能kube-proxy实现Kubernetes Service的通信与负载均衡机制的重要组件Docker EngineDocker引擎负责本机的容器创建和管理工作在默认情况下Kubelet会向Master注册自己一旦Node被纳入集群管理范围kubelet进程就会定时向Master汇报自身的信息例如机器的CPU和内存情况以及有哪些Pod在运行等这样Master就可以获知每个Node的资源使用情况并实现高效均衡的资源调度策略。而某个Node在超过指定时间不上报信息时会被Master判定为失败Node的状态被标记为不可用随后Master会触发工作负载转移的自动流程。2、Pod每个Pod都有一个根容器的Pause容器还包含一个或多个紧密相关的用户业务容器Pod里的多个业务容器共享Pause容器的IP共享Pause容器挂接的Volume。在K8S里一个Pod里的容器与另外主机上的Pod容器能够直接通信Pod有两种类型普通的Pod及静态PodStatic Pod。后者并没被存放在K8S的etcd存储里而是被存放在某个具体的Node上的一个具体文件中并且只在此Node上启动、运行。而普通的Pod一旦被创建就会被放入etcd中存储随后会被K8S的Master调度到某个具体的Node上并进行绑定Binding随后该Pod被对应的Node上的kubelet进程实例化成一组相关的Docker容器并启动。在默认情况下当Pod里的某个容器停止时K8S会自动检测到这个问题并且重新启动这个Pod重启Pod里的所有容器如果Pod所在的Node宕机就会将这个Node上的所有Pod重新调度到其他节点上3、K8S创建一个Pod的流程1、用户提交创建Pod的请求可以通过API Server的REST API也可用Kubectl命令行工具2、API Server处理用户请求用户鉴权检查yaml文件格式存储Pod数据到etcd3、Schedule通过和API Server的watch机制查看到新的Pod尝试为Pod绑定Node4、过滤主机调度器用一组规则过滤掉不符合要求的主机比如Pod指定了所需要的资源那么就要过滤掉资源不够的主机5、主机打分对第一步筛选出的符合要求的主机进行打分在主机打分阶段调度器会考虑一些整体优化策略比如把一个Replication Controller的副本分布到不同的主机上使用最低负载的主机等6、选择主机选择打分最高的主机进行binding操作结果存储到etcd中7、Kubelet根据调度结果执行Pod创建操作 绑定成功后会启动containerScheduler会调用API在数据库etcd中创建一个bound pod对象描述在一个工作节点上绑定运行的所有Pod信息。运行在每个工作节点上的Kubelet也会定期与etcd同步bound pod信息一旦发现应该在该工作节点上运行的bound pod对象没有更新则调用Docker API创建并启动Pod内的容器在这期间Control Manager同时会根据K8S的mainfiles文件执行RC Pod的数量来保证指定的Pod副本数。而其他的组件比如Scheduler负责Pod绑定的调度从而完成整个Pod的创建。
k8s组件及pod的创建流程
1、Master和Node1、MasterK8S中的Master是集群控制节点负责整个集群的管理和控制在Master上运行着以下关键进程kube-apiserver提供了HTTP Rest接口的关键服务进程是K8S里所有资源的增删改查等操作的唯一入口也是集群控制的入口进程kube-controller-managerK8S里所有资源对象的自动化控制中心集群内各种资源Controller的核心管理者针对每一种资源都有相应的Controller保证其下管理的每个Controller所对应的资源始终处于期望状态kube-scheduler负责资源调度Pod调度的进程通过API Server的Watch接口监听新建Pod副本信息并通过调度算法为该Pod选择一个最合适的NodeetcdK8S里的所有资源对象以及状态的数据都被保存在etcd中2、NodeNode是K8S集群中的工作负载节点每个Node都会被Master分配一些工作负载当某个Node宕机时其上的工作负载会被Master自动转移到其他节点上在每个Node上都运行着以下关键进程kubelet负责Pod对应的容器的创建、启停等任务同时与Master密切协作实现集群管理的基本功能kube-proxy实现Kubernetes Service的通信与负载均衡机制的重要组件Docker EngineDocker引擎负责本机的容器创建和管理工作在默认情况下Kubelet会向Master注册自己一旦Node被纳入集群管理范围kubelet进程就会定时向Master汇报自身的信息例如机器的CPU和内存情况以及有哪些Pod在运行等这样Master就可以获知每个Node的资源使用情况并实现高效均衡的资源调度策略。而某个Node在超过指定时间不上报信息时会被Master判定为失败Node的状态被标记为不可用随后Master会触发工作负载转移的自动流程。2、Pod每个Pod都有一个根容器的Pause容器还包含一个或多个紧密相关的用户业务容器Pod里的多个业务容器共享Pause容器的IP共享Pause容器挂接的Volume。在K8S里一个Pod里的容器与另外主机上的Pod容器能够直接通信Pod有两种类型普通的Pod及静态PodStatic Pod。后者并没被存放在K8S的etcd存储里而是被存放在某个具体的Node上的一个具体文件中并且只在此Node上启动、运行。而普通的Pod一旦被创建就会被放入etcd中存储随后会被K8S的Master调度到某个具体的Node上并进行绑定Binding随后该Pod被对应的Node上的kubelet进程实例化成一组相关的Docker容器并启动。在默认情况下当Pod里的某个容器停止时K8S会自动检测到这个问题并且重新启动这个Pod重启Pod里的所有容器如果Pod所在的Node宕机就会将这个Node上的所有Pod重新调度到其他节点上3、K8S创建一个Pod的流程1、用户提交创建Pod的请求可以通过API Server的REST API也可用Kubectl命令行工具2、API Server处理用户请求用户鉴权检查yaml文件格式存储Pod数据到etcd3、Schedule通过和API Server的watch机制查看到新的Pod尝试为Pod绑定Node4、过滤主机调度器用一组规则过滤掉不符合要求的主机比如Pod指定了所需要的资源那么就要过滤掉资源不够的主机5、主机打分对第一步筛选出的符合要求的主机进行打分在主机打分阶段调度器会考虑一些整体优化策略比如把一个Replication Controller的副本分布到不同的主机上使用最低负载的主机等6、选择主机选择打分最高的主机进行binding操作结果存储到etcd中7、Kubelet根据调度结果执行Pod创建操作 绑定成功后会启动containerScheduler会调用API在数据库etcd中创建一个bound pod对象描述在一个工作节点上绑定运行的所有Pod信息。运行在每个工作节点上的Kubelet也会定期与etcd同步bound pod信息一旦发现应该在该工作节点上运行的bound pod对象没有更新则调用Docker API创建并启动Pod内的容器在这期间Control Manager同时会根据K8S的mainfiles文件执行RC Pod的数量来保证指定的Pod副本数。而其他的组件比如Scheduler负责Pod绑定的调度从而完成整个Pod的创建。