k8s组件架构说明

高可用集群副本数据最好是 >= 3 奇数个

（也就是下面第一张图片的BorgMaster的个数，下面的是5个）

下面的是谷歌公司的borg架构

下面的是k8s架构

​​​​​​​

 

上图是我们的k8smaster和node节点的相关组件，由上图可知，我们的node节点需要安装kubelet，kube proxy和docker 。。。。

分析一下上面的图片把，我们kubelet的作用就是，它会跟我们的CRI（容器运行接口），说白了就是我们的docker在这里的表现形式，也就是说我们的kubelet会跟我们的docker去交互，操作我们的docker去创建对应的容器，也就是说我们的kubelet维持我们pod的生命周期。。。

kube proxy的功能就是实现我们的pod与pod之间的访问，包括负载均衡，需要借助到我们的kube proxy，它的默认操作是去操作防火墙去实现pod的映射，当然我们的新版本还支持ipvs，也就是我们的lvs组件。。。。。

节点上面有个kube-proxy进程，这个进程从master apiserver获取信息，感知service和endpoint的创建，然后做两个事： 1.为每个service 在集群中每个节点上面创建一个随机端口，任何该端口上面的连接会代理到相应的pod 2.集群中每个节点安装iptables/ipvs规则，用于clusterip + port路由到上一步定义的随机端口上面， 所以集群中每个node上面都有service的转发规则:iptables -L -n -t filter

APISERVER:所有服务的访问统一入口（如上面的箭头，也包括kube proxy和kubelet）

ControllerManager：负责容器编排及Kubernetes集群状态的维护，例如故障检测、自动扩展、滚动更新等。

Scheduler：我们的调度器，负责接收任务，选择合适的节点进行分配任务（合适的节点：就是我们的节点有足够的资源供给pod去运行，例如我们想要这个节点有什么的固态硬盘，或者带宽比较高，cpu比较大啊等特殊的资源分配给我们的pod，都是由它来完成的）

etcd:键值对数据库，存储k8s集群的所有重要持久化的信息（也就意味这某一天我们想要恢复我们的k8s集群的话，我们只需要对我们的etcd进行还原即可）

上面的是我们master组件中有的，下面的是当我们的node节点中有的

kubelet:直接跟容器引擎（也就是docker）交互实现容器的生命周期管理

（也就时说，我们的kubelet接收到指令之后，先把我们k8s发过来的指令进行理解，理解完成之后就把对应的指令直接转化成为我们的container能够听懂的命令，达到这么一个创建pod的流程）

• 通过CRI(Container Runtime Interface)远程接口同容器运行时（如Docker）进行交互，对容器生命周期进行维护。其中CRI接口会定义了容器运行时的各项核心操作，例如启动容器所需的命令及参数等。
• 通过GRPC协议同Device Plugin插件交互，实现Kubernetes对宿主机物理设备的管理。
• 此外kubelet另一个重要的功能则是通过CNI（Container Networking Interface）来调用网络插件为容器配置网络，以及通过CSI（Container Storage Interface）和存储插件交互为容器配置持久化存储。

kube-proxy：负责写入规则至IPTABLES或者IPVS实现服务映射（也叫做端口转发）访问的。

上面的是官方比较重要的组件，下面的是其他的一些插件：

CoreDNS:这是cores公司 的一个DNS服务器，它主要实现的是可以为集群中的SVC创建一个域名ip对应域名关系解析，也就是我们以后在集群中访问我们的一些其他的pod的时候，我们完全不需要通过这个pod的IP地址，可以通过coreDNS给它生成的这个域名去实现访问。。。。这个是我们实现负载均衡的一个重要的组件。。。

DASHBOARD：给k8s集群提供一个B/S结构的访问体系。。。。

INGRESS CONTROLLER：官方k8s集群只能实现四层代理，INGRESS 可以实现七层代理（也就是可以根据我们的主机名根据我们的域名去负载均衡）

FEDERATION：提供一个可以跨集群中心多K8S统一管理功能

PROMETHEUS：提供K8S集群的监控能力

ELK：提供 K8S 集群日志统一分析介入平台