Kubernetes Kernel
设计思想:
与传统架构区别:
更关注业务模块
不在费心与负载均衡的选项和部署实施问题
不在考虑引入或自研一个复杂的治理框架
不在头疼服务监控和故障处理模块的开发
节省30%的开发成本
自动化机制, 大幅降低系统后期的运维难度和成本
服务跨平台, 无语言限制
K编程框架,中间件没有任何侵入性, 现有服务更容易迁移到该平台
完全屏蔽底层网络的细节,基于Service的虚拟IP(Cluster IP)的设计思路,让架构与底层的硬件拓扑无关
Master
分支三进程: 实现了整个集群的资源管理, Pod调度, 弹性伸缩, 安全控制, 系统监控和纠错等管理功能, 且为自动完成.
高可用部署建议3台服务器互备, 集群首脑.
Kube-apiserver
提供Http Rest接口的关键服务进程, 是K里所有资源的增删改查等操作的唯一入口,也是集群控制的入口进程.
Kube-controller-manager
K里所有资源对象的自动化控制中心,可以理解为资源对象的"大总管"
Kube-scheduler
负责资源调度(Pod调度)的进程, 相当于公交公司的"调度室"
etcd
K-V数据库
存储K里所有资源对象的数据
Node
早期版本叫Minion, 可以是一台物理机或虚拟机
Node故障, Master会将工作调度到其他Node
作为集群工作节点, 运行真正的应用程序, 最小单元为Pod.
俩服务进程Kubelet&Kube-proxy,主要负责Pod的创建,启动,监控,重启,销毁,以及实现软件模式的负载均衡器.
Node可以再运行期间动态 Add到K集群中, 前提是这个节点上已经正确安装,配置和启动了上述关键进程, 默认情况下Kubelet会向Master注册自己, 这也是K推荐的Node管理方式, 一旦Node被纳入集群管理范围, Kubelet进程会定时向Master汇报自身情况, 包括操作系统,Docker版本,机器的CPU和内存, 以及那些Pod再运行等, 这样Master可以获知每个Node的资源使用情况, 并实现高效均衡的资源调度策略, 如果Node指定时间内不上报信息, 会被Master判定为"失联", Node会被标记为不可用(Not Ready), 随后Master会触发"工作负载大转移"的自动流程.
Kubelet
负责Pod对应的容器的创建,启停等任务,同时与Master密切协作,实现集群管理的基本功能
Kube-proxy
实现K Service的通信与负载均衡机制的重要组件
Docker Engine(docker)
Docker引擎, 负责本机的容器创建和管理工作
