master组件
master组件提供集群controlPlane，为集群做所有决定，并且观测和响应集群时间。 配置脚本通常会启动所有master组件在单个机器上，并且不在这台机器上运行业务容器。
kube-apiserver
master上暴露k8s-API的组件，他是k8s控制运行的前端，旨在水平缩放(通过部署更新的实例扩容)
etcd
用来作为k8s后端存储所有集群数据的 一致且高可用 的键值存储系统。如果你的K8s系统使用etcd作为他的后端存储，确保对于其他数据有备份。关于etcd详细信息关注https://etcd.io/docs/
kube-scheduler
观察 新创建但还未分配node 的Pod，并为它选择一个node去启动。调度决策考虑到的因素包括个人和集体资源要求，硬件/软件/政策限制，亲和力和反亲和力规范，数据定位，工作负载和最后期限
(Factors taken into account for scheduling decisions include individual and collective resource requirements, hardware/software/policy constraints, affinity and anti-affinity specifications, data locality, inter-workload interference and deadlines)
kube-controller-manager
逻辑上来说，每个controller是一个单独的进程，为了降低复杂度，他们被编译成一整个二进制文件并在单个进程上运行，这些controller包括：
- Node Controller: 负责在节点故障时关注并响应
- Replication Controller: 负责为系统中每个replication Controller维护正确的Pod数量
- EndPoint Controller: 填充endPoint对象
- Service Account & Token Controller: 为新命名空间创建默认账号和API访问令牌
cloud-controller-manager
运行一个与底层云提供商相关联的控制器。是k8s1.6引入的alpha功能。他仅运行云提供商特定的controller loop控制器循环,你必须在kube-controller-manager中禁用这一项，通过设置 --cloud-provider=external 来禁用
cloud-controller-manager允许云供应商的代码和k8s代码独立发展，核心K8s代码依赖于特定云提供商的功能代码，在未来版本中，特定云提供商的代码将由云提供商自己维护，并在运行k8s时连接到cloud-cotroller-manager
它包含以下：
- Node Controller: 检查并确定node停止响应后是否被从云上删除
- Route Controller: 在底层云基础架构上设置路由
- Service Controller: 增删改云提供的LB
- Volumne Controller: 与云厂商交互去编排volume卷
Node 组件
运行在每个node上，维护运行的Pod和k8s运行时环境
kubelet
采用通过各种机制提供来的一套podSpec 去确保podSpec中描述的容器是健康运行的，kubelet不管理那些由非K8s创建的容器。
kube-proxy
这是运行在每个节点上的网络代理，是k8s Service实现的一部分。它在node上维护网络协议，这些网络规则允许通过集群内外的网络会话与你的Pod进行交流.kube-proxy使用操作系统数据包过滤层，否则，他转发流量本身(？)
container runtime
容器运行时是负责运行容器的软件，k8s提供一些例如：docker、containerd、cri-o、rktlet及k8s容器运行时API
addons
插件使用K8s资源(DaemonSet、Deployment、etc)来实现集群功能，因为是集群级别的功能，所以他们的命名空间属于kube-system，插件实例如下：
DNS
集群内必须安装有集群DNS，这是一个DNS服务器，能够为k8s service提供DNS记录，由k8s创建容器将自动将这个DNS服务器包含在他们的DNS-searched中
Dashboard
K8s集群基于web的通用UI界面，提供基础信息查看设置等功能
Container Resource Monitoring
提供UI浏览监控数据
Cluster-level logging
负责保存容器日志，搜索/查看日志
网友评论