K8S集群组件

master节点主要由apiserver、controller-manager和scheduler三个组件，以及一个用于集群状态存储的etcd存储服务组成，而每个node节点则主要包含kubelet、kube-proxy及容器引擎等组件。此外，完整的集群服务还依赖于一些附加组件，如kubedns等。

一、master组件

1、apiserver

apiserver负责输出restful风格的kubernetes api，它是发往集群的所有rest操作命令的接入点，并负责接收、校验并响应所有的rest请求，结果状态被持久存储于etcd中，因此，apiserver是整个集群的网关。

2、cluster state store

kubernetes集群的所有状态信息都需要持久存储于存储系统etcd中，不过，etcd是由coreos基于raft协议开发的分布式键值存储，可用于服务发现、共享配置以及一致性保障（如数据库主节点选择、分布式锁等）。因此，etcd是独立的服务组件，并不隶属于kubernetes集群自身。生产环境中应该以etcd集群的方式运行以确保其服务可用性。

etcd不仅能够提供键值数据存储，而且还为其提供了监听（watch）机制，用于监听和推送变更。k8s集群系统中，etcd中的键值发生变化时会通知到apiserver，并由其通过watch api向客户端输出。基于watch机制，k8s集群的个组件实现了高效协同。

3、controller manager

k8s中，集群级别的大多数功能都是由几个被称为控制器的进程执行实现的，这几个进程被集成于kube-controller-manager守护进程中。由控制器完成的功能主要包括生命周期功能和api业务逻辑，具体如下：

生命周期功能：包括namespace创建和生命周期、event垃圾回收、pod终止相关的垃圾回收、级联垃圾回收及node垃圾回收等

api业务逻辑：例如，由replicaset执行的pod扩展等。

4、scheduler

k8s是用于部署和管理大规模容器应用的平台，根据集群规模的不同，其托管运行的容器很有可能会数以千计甚至更多。apiserver确认pod对象的创建请求之后，便需要由scheduler根据集群内各节点的可用资源状态，以及要运行的容器的资源需求做出调度决策。

二、node组件

1、kubelet

kubelet是运行于工作节点之上的守护进程，是node的核心代理程序，它从apiserver接收关于pod对象的配置信息并确保它们处于期望的状态（desired state，也是目标状态）。kubelet会在apiserver上注册当前工作节点，定期向master汇报节点资源使用情况，并通过cadvisor监控容器和节点的资源占用状况。

2、container runtime

每个node都要提供一个容器运行时环境，它负责下载镜像并运行容器。kubelet并未固定链接至某容器运行时环境，而是以插件的方式载入配置的容器环境，这种方式清晰地定义了各组件的边界。目前k8s支持的容器运行环境包括docker、rkt、cri-o、fraki等。

3、kube-proxy

每个工作节点都需要运行一个kube-proxy守护进程，它能够按需为service资源对象生成iptables或ipvs规则，从而捕获访问当前service的clusterip的流量并将其转发至正确的后端pod对象。

三、核心组件

k8s集群还依赖于一组成为“组件”（add-ons）的组件以提供完整的功能，它们通常是由第三方提供的特定应用程序，并且托管运行于k8s集群之上。

kubedns：在k8s集群中调度运行提供dns服务的pod，同一集群中的其他pod可使用此dns服务器解决主机名。k8s自1.11版本开始默认使用coredns项目为集群提供服务注册和服务发现的动态名称解析服务，之前的版本中用到的是kube-dns和skydns项目。

dashboard：kubernetes集群的全部功能都要基于web的UI来管理集群中的应用甚至是集群自身。

heapster：容器和节点的性能监控与分析系统，它手机并解析多种指标数据，如资源利用率、生命周期事件等。新版本的k8s中，其功能会逐渐由prometheus结合其他组件所取代。

ingress controller：service是一种工作于传统层的负载均衡器，而ingress是在应用层实现的http(s)负载均衡机制。不过，ingress资源自身并不能进行“流量穿透”，它仅是一组路由规则的集合，这些规则需要通过ingress控制器（ingress controller）发挥作用。目前，此类的可用项目有nginx、traefik、envoy及haproxy等。