一个Kubernetes集群由多个工作节点(worker node)和一个或多个集群控制节点(Master)以及一个集群状态存储系(etcd)组成。

Master系统组件

Master主要负责整个集群的管理工作，为集群提供管理接口，并监控和编排集群中的各个工作节点。各节点负责以 Pod 形式运行Docker容器。
Master节点主要由apiserver、scheduler、contrller三个系统组件以及一个集群存储系统 etcd 组成。而API、UI、CLI则为管理员客户端操作方式。

API：Kubernetes的Master提供了API来用向Master内部调用操作，我们可以通过调用API来对Kubernetes集群进行操作。
UI：UI是Kubernetes提供的一个Web界面的操作接口，通过Web的UI界面即可进行对Kubernetes集群的控制操作。
CLI：CLI是Kuberntes提供的一个命令为 kuberctl 的客户端操作命令，通过此命令也可以完成对Kubernetes集群的控制操作，此命令就像是Docker中的客户端,Docker组件分为 Docker Daemon Docker Client还有Registry，CLI命令就如同 docker 客户端命令一样。

• API Server

  目前应用程序提供了共两种API方式，第一种为陈述式API，第二种为声明式API。
  举一个陈述式API例子：假如你要运行一个容器，你要指定运行什么容器，指定容器使用的镜像位置，指定通过怎么方式运行等等，陈述式API是需要你写清楚每一步的步骤，然后让运行容器的人按照你的步骤去做。
  而生明式API则是：你直接指定运行什么样的容器即可，剩下的全部交给运行容器的人去做。
  Kubernetes提供的API则为后者声明式API。Kubernetes中定义API的方式则在yaml文件中写入你想要的结果即可，然后Kubernetes将会执行相应操作，完成你的结果。
  API Server为唯一接受客户端组件请求的入口，无论我们使用API、UI、以及CLI方式操作的事件，都会发送给API Server，API Server进行接收并校验客户端请求。

• Scheduler

  Scheduler为调度器；假如你通过API或UI更或则是CLI方式运行一个容器(目前这里介绍为容器，后面将过Pod后将替换为Pod)，Scheduler用来计算将容器运行在哪个Node节点之上，这就需要Scheduler去进行评估哪台Node节点最适合运行你创建的容器。

• Controller

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

  Vim

  生命周期功能：包括 Namespace 创建和生命周期、Event 垃圾回收、Pod 终止相关的垃圾回收、及 Node 垃圾回收等。 API 业务逻辑：例如，由 RepliaSet 执行的 Pod 扩展等。

  1 2	生命周期功能：包括 Namespace 创建和生命周期、Event 垃圾回收、Pod 终止相关的垃圾回收、及 Node 垃圾回收等。 API 业务逻辑：例如，由 RepliaSet 执行的 Pod 扩展等。

• etcd

  etcd被称为集群状态存储(Cluster State Store)，Kubernetes集群的所有状态信息都需要持久存储到etcd系统中，不过，etcd是由 CoreOS 公司 基于 Raft 协议开发的分布式键值key=vaule存储，可用于服务发现、共享配置以及一致性保障。因此，etcd是独立的服务组件，并不属于Kubernetes集群自身组件。生产环境中应用以 etcd 集群的方式运行以确保其服务可用性。
  etcd不仅能够提供键值数据存储，而且还为其提供了监听 （watch）机制，用于监听和推送变更。Kubernetes集群系统中，etcd中的键值发生变化时会通知到 API Server，并由其通过 watch API向客户端输出。基于watch机制，Kubernetes集群的各个组件实现了高效协同。

Kubernetes Master节点的工作原理

1.我们使用客户端组件向API Server发出指令创建一个容器。

2.API Server收到客户端发送的指令后将会先进行校验你发出的指令，校验成功后将状态持久存储到 etcd 中。

3.API Server只提供接受客户端组件的指令并进行校验然后将数据持久存储到etcd中，那么谁来执行客户端组件发出的指令呢？

4.API Server校验成功后将状态持久存储到etcd的同时将会告知 Controller 控制器，Controller也会始终监听API Server的资源变动，一旦有了变动，Controller立刻执行相关的变动状态。Controller控制器将按照指令进行创建或则销毁容器。

5.如果是创建容器，那么Controller控制器要在哪台Node上进行创建呢？Scheduler 也与 Controller一样始终监听着 API Server的变化状态，这时候就需要 Scheduler 调度器进行评估直接在评估后的Node上创建，Scheduler也会将调度结果和创建状态存储到 etcd中。

6.在Kubernetes中有两种状态，第一种为客户端指令中期望的状态，例如我们期望创建一个NGINX容器，第二种状态为Controller执行后的状态，Controller将下载容器镜像并确保NGINX容器运行起来，这个是正真运行的容器，运行成功后Controller会将运行后容器的状态与用户期望的状态进行对比，如果状态不一致，Controller则重启或则重建容器等等方法，使运行后的容器与用户期望的容器状态一致。

Node系统组件

Node节点主要负责提供运行容器的各种依赖环境，并接受 Master 管理。每个Node主要由 Kubelet、容器、kube-proxy三个组件组成。

• kube-proxy

  每个Node节点都需要运行一个 kube-proxy 的守护进程，它能够按需为 Service(后面会讲Service是什么) 资源对象生成 iptables 或 ipvs 规则，从而捕获当前 Service的ClusterIP流量并将其转发至正确的后端 Pod 对象。

• kubelet

  kubelet时运行在Node节点之上的守护进程，kubelet也会始终监听着Master上 API Server组件的资源变动，如果发现 Master 上的Scheduler组件有调度到自身Node来的指令，Kubelet 将会调用自身的 Container Engine，Container Engine 将会寻找镜像仓库并执行操作。kubelet 也会在 API Server上注册当前工作节点，定期向 Master 汇报当前节点资源使用情况，并通过 cAdvisor 监控容器和节点的资源占用情况。

• Container Engine

  Container Engine为容器引擎，容器引擎有很多，如常用的 Docker 和RKT、cir-o 、Fraki等，这些都是容器引擎，都可以被Kubernetes锁托管，只是我们目前主流的为Docker，容器引擎负责接收来自kubelet的指令并执行它。

附加组件

Kubernetes集群还依赖于一组称为 “附件” 的组件以提供完整的功能，他们通常是由第三方提供的特定应用程序，且托管运行于 Kubernetes 集群之上，如上图中的 kube-system-namespace块中所示。

• DNS：在Kubernetes集群中调度运行提供DNS服务的 Pod，同一集群中的其它 Pod 可使用此 DNS 服务解决主机名，Kubernetes自 1.11 版本开始默认使用CoreDNS项目为集群提供服务注册和服务发现的动态名称解析服务，之前的版本中用到的是 KubeDNS 项目，而 SykDNS 则是更早一代的项目。

• Dashhoard：Kubernetes 集群的全部功能都要基于 Web 的 UI 来管理集群中的应用甚至集群自身。

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

• Ingress Controller：Service 是一种工作与传统的负载均衡器，而 Ingress 是在应用层实现的 HTTP/HTTPS负载均衡机制，不过 Ingress 资源自身并不能进行 “流量穿透”，它仅是一组路由规则的集合，这些规则需要通过 Ingress 控制器（Ingress Controller）发挥作用，目前，此类的可用项目用 Nginx、HAProxy、Traefik、Envoy等。