Kubernetes架构
根据如上架构对各组件进行讲解
etcd
etcd是CoreOS基于Raft开发的分布式key-value存储，可用于服务发现、共享配置以及一致性保障（如数据库选主、分布式锁等）。
- 基本的key-value存储；
- 监听机制
- key的过期及续约机制，用于监控和服务发现
- 原子CAS和CAD，用于分布式锁和leader选举
APIServer
kube-APIServer是Kubernetes最重要的核心组件之一，主要提供以下的功能：
- 提供集群管理的REST APi接口，包括：
- 认证 Authentication；
- 授权 Authorization；
- 准入 Admission（Mutating&Valiating）
- 提供其它模块之间的数据交互和通信的枢纽（其它模块通过API Server查询或修改数据，只有APi Server才直接操作etcd）。
- APIServer提供etcd数据缓存以减少集群对etcd的访问。
Controller Manager
- Controller Manager是集群的大脑，是确保整个集群动起来的关键
- 其作用是确保Kubernetes遵循声明式系统规范，确保系统的真实状态（Actual State）与用户定义的期望状态（Desired State一致）
- Controller Manager是多个控制器的组合，每个Controller事实上都是一个control loop，负责侦听其管控的对象，当对象发生变更时完成配置；
- Controller配置失败通常会触发自动重试，整个集群会在控制器不断重试的机制下确保最终一致性（Eventual Consistency）
Scheduler
特殊的Controller，工作原理与其他控制器无差别；
Scheduler的特殊职责在于监控当前集群所有未调度的Pod，并且获取当前集群所有节点的健康状态和资源使用情况，为待调度Pod选择最佳计算节点，完成调度。
调度阶段分为：
- Predict：过滤不能满足业务需求的节点，如资源不足，端口冲突等；
- Priority：按既定要素将满足调度需求的节点评分，选择最佳节点
- Bind：将计算节点与Pod绑定，完成调度。
Kubelet
Kubernetes的初始化系统（init system）
- 从不同源获取Pod清单，并按需求启停的核心组件：
- Pod清单可以从本地文件目录，给定的HTTPServer或KuberAPIServer等源头获取；
- Kubelet将运行时，网络或存储抽象成了CRI，CNI，CSI。
- 负责汇报当前节点的资源信息和健康状态
- 负责Pod的健康检查和状态汇报
Kube-Proxy
- 监控集群中用户发布的服务，并完成负载均衡配置。
- 每个节点的Kube-Proxy都会配置相同的负载均衡策略，使得整个集群的服务发现建立在分布式负载均衡器之上，服务调用无需经过额外的网络跳转（Network Hop）。
- 负载均衡配置基于不同插件实现：
- userspace
- 操作系统网络协议栈不同的Hooks点和插件；
- iptables
- ipvs
常用Kubernetes对象及其分组
核心对象间的关系图
Node
- Node是Pod真正运行的主机，可以物理机，也可以虚拟机。
- Node对象用来描述节点的计算资源；
- Capacity：计算能力，代表当前节点的所需资源；
- Allocatable：可分配资源，代表当前节点的可分配资源，通常是所有资源-预留资源-已分配资源
- Kubelet会按固定频率检查节点健康状态并上报给APIServer，该状态会记录在Node对象status中。
Pod
- Pod是一组紧密关联的容器集合，是Kubernetes调度的基本单位，容器进程运行在不同PID/IPC/Network和UTS namespace，并彼此之间共享网络。
- Pod的设计理念是支持多个容器在一个Pod中共享网络和文件系统，可以通过进程间通信和文件共享这种简单高效的方式组合完成服务。
ReplicaSet(副本集)
- Pod描述的是具体的应用实例，当Pod被删除后，就彻底消失了；
- 为了保证应用的高可用，引入副本集来确保应用的总副本数永远与期望一致；
- 若某个Pod隶属于某个副本集，若该Pod被删除，则ReplicaSet Controller会发现当前运行的副本数量与用户的期望不一致，则会创建新的Pod。
Deployment(部署)
- 部署表示用户对Kubernetes集群的一次更新操作
- 部署是一个比RS应用模式更广的API对象，可以是创建一个新的应用，更新一个已存在的应用，也可以是滚动升级一个应用
- 滚动升级一个服务，实际是创建一个的RS，然后逐渐将新RS中副本数量增加到理想状态，将旧RS中的副本数减少到0的复合操作；这样一个复合操作用一个RS是不太好描述的，所以用一个通用的Deployment来描述，以Kubernetes的发展方向，未来对所有长期伺服型的业务的管理，都会通过Deployment来管理。
Service(服务)
RC、RS和Deployment只是保证了支撑服务的微服务Pod的数量，但是没有解决如何访问这些服务的问题。一个Pod只是一个运行服务的实例，随时可能在一个节点上停止，在另一个节点以一个新的IP启动一个新的Pod，因此不能以确定的IP和端口号提供服务。要稳定的提供服务需要服务发现和负载均衡的能力。服务发现完成的工作，是针对客户端访问的服务，找到对应的后端服务实例。在Kubernetes集群中，客户端需要访问的服务就是Service对象。每个Service会对应一个集群内部有效的虚拟IP，集群内部通过虚拟IP访问一个服务。在Kubernetes集群中微服务的负载均衡是由Kube-proxy实现的。Kube-proxy是Kubernetes集群内部的负载均衡器。它是一个分布式代理服务器，在Kubernetes的每个节点上都有一个；这一设计体现了它的伸缩性优势，需要访问服务的节点越多，提供负载均衡能力的kube-proxy就越多；高可用节点也随之增多。与之相比，我们平时在服务器端使用反向代理作负载均衡，还要进一步解决方向代理的高可用问题。
Service是应用服务的抽象，通过labels为应用提供负载均衡和服务发现。匹配labels的Pod IP和端口列表组成endpoints，由Kube-proxy负责将服务IP负载均衡到这些endpoints上。
每个默认类型Service都会自动分配一个cluster IP(仅在集群内部可访问的虚拟地址)和DNS名，其他容器可以通过该地址或DNS来访问服务，而不需要了解后端容器的运行。
Namespace
- Namespace是对一组资源和对象的抽象集合，比如可以用来将系统内部的对象划分为不同的项目组或用户组。
- 从Namespace划分的维度看，Kubernetes对象分为两类：
- Non-namespaced object：
- 全局对象，这些对象不与任何Namespace绑定，属于集群范围的对象。如Node、PresistVolume，ClusterRole。
- Namespaced object：
- 与具体Namespace绑定对象，如Pod，Service。
- Non-namespaced object：
标签：负载,架构,Kubernetes,集群,服务,Pod,第二章,节点 From： https://www.cnblogs.com/weidongliu/p/16902559.html