一文讲明白K8S各核心架构组件

一、写在前面

K8S的文章很多人都写过，若要想好好研读，系统的学习，真推荐去看官方文档。但是若是当上下班路上的爽文，可以看下我的笔记，我也会尽力多写点自己的理解进来。

二、K8S为我们提供了怎样的能力

大家都知道Docker，我们可以将自己的应用打包制作成Image，然后通过docker run命令将Image启动成Container对外提供服务。

基于此，K8S不仅能将用户提供的单个容器运行起来，将其对外暴露出去提供服务。还提供了：路由网关、集群监控、灾难恢复，以及应用的水平扩展等能力。

大家常听过一个词：微服务、云原生应用，如何理解这个词自然也是见仁见智。

如下图是SpringCloud的架构图：

在SpringCloud中有不同的组件，诸如提供服务发现能力的：Eureka、提供负载均衡机制的Ribbon、以及微服务的统一入口Zuul， 基于这套框架做过开发的同学都知道，无论是Eureka还是Zuul，无论开发量大小，都需要程序员开发相应的代码，即使这些代码和业务本身并没有什么关系。

而在K8S中，像Eureka的服务发现能力，Zuul的网关能力、以及Ribbon的负载均衡能力，K8S都是原生支持的，开发人员只需要写好自己的业务代码，提供一个可执行的jar包，或者二进制文件即可部署进K8S中就行

当然不仅于此，K8S的服务网格组件如：Istio还提供了流量治理能力，比如按不同的请求头做不同比例的流量分发调度、亦或者是金丝雀发布。

说起容器编排，像Docker的Compose或者是Docker-Swarm都提供了简单的容器编排的能力。

像Docker-Compose或者Docker-Swarm的通病就是过于以Docker核心，提供的能力也过于简单比如定义谁先启动谁后启动。无法满足比较复杂的场景

而K8S的容器编排设计是站在更高的维度，Docker对于K8S而言只是运行它编排产出的介质，K8S针对不同的编排场景提供了不同的编排资源对象，如提供Deployment编排无状态应用，提供了Cronjob编排定时任务，提供了StatefulSet编排ES、Redis集群这种有状态应用等等，这都是前者所不能及的....

三、架构

K8S架构简图如上，分为MasterNode、WorkNode两大部分和五大组件，一开始接触这些概念难免会有些陌生，但是本质上这些组件都是K8S的开发者对各种能力的抽象和封装

3.1、MasterNode

和Redis或者Nginx这种由二进制文件启动后得到一个对外提供服务的守护进程不同，K8S中的MasterNode其实并不是一个二进制文件启动后得到的对外提供服务的守护进程，它本质上是一个抽象的概念。

MasterNode包含3个程序，分别是：

• ApiServer
  • 提供HTTP Rest接口，是集群中各种核心资源的CRUD的统一入口，是集群中各个组件交互的核心枢纽
  • 集群资源配额的统一入口
  • 提供了完备的集群安全机制
• ControllerManager
  • 实时监控集群中如Service等各种资源的状态变化，不断尝试将它们的副本数量维持在一个期望的状态。
• Scheduler：
  • 负责调度功能，如：为Pod找到一个合适的宿主机器

3.2、WorkerNode

和MasterNode类似，WorkerNode本质也并不是一个独立的应用程序，它包含两个组件，如下

• kubelet
  • Node节点管理
  • Pod管理，同容器运行时交互下发容器的创建/关闭命令
  • 容器健康状态检查
• kube-proxy
  • 通过为Service资源的ClusterIP生成iptable或ipvs规则，实现将K8S内部的服务暴露到集群外面去

既然WorkNode也是抽象的概念，那么若在MasterNode启动kube-proxy和kubelet进程，那么MasterNode也会拥有WorkNode的能力，双重角色，但生产环境不推荐这样搞。

四、核心组件

4.1、ApiServer

4.1.1、概述

APIServer有完备的集群安全验证机制，提供了对K8S中如Pod、Service等资源CRUD等HttpRest接口，是集群中各个组件之间数据交互的核心枢纽。

4.1.2、是集群管理API的统一入口

为了更好的理解这个概念可以看如下图