k8s下的应用架构图 k8s 架构

K8s将集群中的机器划分为一个主节点和一群工作节点，在主节点上运行着集群管理相关的一组进程kube-apiserver、kube-controller-manager 和 kube-scheduler，这些进程实现了整个集群的资源管理、pod 调度、弹性伸缩、安全控制、系统监控和纠错等管理功能，并且都是全自动完成的。集群中的工作节点运行真正的应用程序，各自又通过若干组件的组合来实现。在节点上，K8s管理的最小运行单元是pod。负载均衡模式需要通过kubelet、kube-proxy等这些服务进程实现，下图是K8s的整体架构：

K8s的整体架构

 主节点即中央控制节点是K8s 集群的管理节点，管理集群当中数据的接口、状态监测和回滚、状态更新、调度等功能，kubectl是K8s的命令行工具集，用于通过命令行与API server进行交互，而对K8s进行操作，实现在集群中进行各种资源的管理控制等操作，通过节点控制器来与工作节点交互。主节点内部架构如下图所示：

主节点内部架构

 上图可以看出主节点的核心组件以及内部的交互流程，主节点提供的核心组件如下。

1. etcd 是集群的状态， K8s 默认使用分布式的etcd集群整体存储用来实现发现服务和共享配置集群的所有状态都存储在etcd 实例中，并具有监控的能力，因此当etcd中的信息发生变化时，能够快速地通知集群中相关的组件。
2. API server提供了集群网关，API server在客户端对集群进行访问， 客户端需要通过认证， 并使用API server作为访问节点和 pod （以及服务）的堡垒和代理/通道。
3. Scheduler主要功能是资源调度，讲pod调度到对应的主机上。依据请求资源的可用性、服务请求的质量等约束条件，K8s也支持用户自己提供的调度器。

（4）controller负责维护集群的状态，比如故障检测、内存垃圾回收、滚动更新等，也执行API业务逻辑；K8s默认提供replication controller、controller、daemonset controller等控制器。

（5）kube-ui为可选组件，自带的一套用来查看集群状态的Web界面。

（6）kube-dns 为可选组件，记录启动的pod和服务地址，提供域名到地址的转换映射。

（7）其他组件包括容器资源使用监控、日志记录等。这些管理组件可以任意部署在相同或者不同的机器上，只要可以通过标准的HTTP接口相互访问即可。这意味着K8s的管理组件进行扩展将变得十分简单。在创建K8s集群过程中，都要预装一些必要的软件来响应主节点的管理，另外还有负责网络和负载均衡的接入代理。节点具体负责真正的容器的启停、状态监测、执行结果上报等工作。工作节点内部组件如下图所示：

工作节点内部组件

 工作节点主要由以下核心组件组成：

（1）本地的容器运行时环境，负责镜像管理以及pod和容器的真正运行。K8s本身并不提供容器运行时环境，但提供了接口，可以插入所选择的容器运行时环境，目前支持Docker和rkt。

（2）kubelet是节点上最主要的工作代理，用于汇报节点状态并负责维护pod的生命周期，也负责volume（CVI）和网络（CNI）的管理。kubelet是pod和节点API的主要实现者，负责驱动容器执行层。作为基本的执行单元，pod可以拥有多个容器和存储卷，能够方便地在每个容器中打包一个单一的应用，从而解耦了应用构建时和部署时所关心的事项，方便在物理机或虚拟机之间进行迁移。

（3）kube-proxy代理对抽象的应用地址的访问，服务提供了一种访问一群pod的途径， kube-proxy负责为服务提供集群内部的服务发现和应用的负载均衡（通常利用iptables规则），实现服务到pod的路由和转发。此方式通过创建一个虚拟的IP来实现，客户端能够访问此IP，并能够将服务透明地代理至pod。

（4）辅助组件，可选，Supervisord用来保持kubelet和Docker进程运行，Fluentd用来转发日志等。节点的重要属性有地址信息、状态、资源容量、节点信息。这些属性用来标识节点的运行状态，并可以被外部组件访问识别。

基本上这4类服务就能涵盖所有的在线交易类业务场景。