当你部署完 Kubernetes, 即拥有了一个完整的集群。
一个 Kubernetes 集群由一组被称作节点的机器组成。这些节点上运行 Kubernetes 所管理的容器化应用。集群具有至少一个工作节点。
工作节点托管作为应用负载的组件的 Pod 。控制平面管理集群中的工作节点和 Pod 。 为集群提供故障转移和高可用性，这些控制平面一般跨多主机运行，集群跨多个节点运行。
本节概述了交付正常运行的 Kubernetes 集群所需的各种组件。
1、控制平面组件（Control Plane Components--master）
从上面的构架图可以看出来整个kubernetes集群分为control plane(master)和node节点两部份。master组件是集群的“脑力”输出者。它维护有kubernetesr 的所有对象记录，负责持续管理对象状态并响应集群中各种资源对象的管理操作，以及确保各资源对象的实际状态与所需状态相匹配。主要由API Server(kube-apiserver)、Control Manager(kube-controller-manager)和Scheduler(kube-scheduler)这3个组件。以及一个用于集群状态存储的etcd存储服务组成。
1.1 API Server（kube-apiserver）
API Server是 Kubernetes控制平台的前端。支持不同类型应用的生命周期编排，包括部署、缩放和滚动更新等。还是整个集群的网关接口,由kube-apiserver守护程序运行为服务。通过HTTP/HTTPS协议将RESTful API公开给用户。是发往集群的所有REST操作命令的接入点，并提供认证、授权、访问控制、API注册和发现等所有的REST请求。并将结果状态持久存储于集群状态存储系统(etcd)中。
kube-apiserver 支持同时提供 https（默认监听在 6443 端口）和 http API（默认监听在 127.0.0.1 的 8080 端口），其中 http API 是非安全接口，不做任何认证授权机制，不建议生产环境启用。两个接口提供的 REST API 格式相同
1.2 Control Manager(kube-controller-manager)
Control Manager负责实现用户通过API Server提交的终态声明。它通过一系列操作步骤驱动API对象的当前状态逼近或同于期望状态。Kubernetes提供了驱动Node、Pod、Server、Endpoint、ServiceAccount和Token等数十种类型的API对象的控制器。从逻辑上讲，每个控制器都是一个单独的进程， 但是为了降低复杂性，它们都被编译到同一个可执行文件，并在一个进程中运行。
控制器包括:
节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应
任务控制器（Job controller）: 监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service 与 Pod)
服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌
-
pod高可用机制
1、node moniter period节点监视5秒
Controller-manager控制器每间隔5秒检查一次节点的状态
如果controller-manager控制器没有收到节点的心跳，则将该node节点标记为不可达。
2、node monitor grace period:节点监视器宽限期为40秒
controller-manager将在标记为无法访问之前等待40秒;
3、pod eviction timeout: pod驱逐超时时间5分钟
如果该node节点被标记为无法访问后5分钟还没有恢复，controller-manager会删除当前node节点的所有pod并在其他节点重建这些pod.
1.3 kube-scheduler
Scheduler是指为API Server 接收到的每一个pod创建请求，并在集群中为其匹配出一个最佳的工作节点为。调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限等特性。
1.4 etcd
kubernetes集群的所有状态信息都需要持久存储于存储系统etcd中。etcd是由CoreOS基于Raft协议开发的分布式键值存储。可用于服务发现。共享配置以及一致性保障。生产环境中应该以etcd集群的方式运行以确保其服务可用性，并需要制周期备份策略以确保数据安全可靠。
etcd还为其存储的数据提供了监听（watch)机制。用于监视和推送变更，API Server是kubernetes集群中唯一能够与etcd通信的组件。封装了这种监听机制。并借此同其他各组件高效协同。
2、Node组件
Node组件是集群中的“体力”输出者，因而一个集群通常会有多个Node以提供足够的承载力来运行容器化应用和其他工作负载。
2.1 kubelet
kubelet是运行于每个node节点之上的“节点代理”服务，负责维护容器的生命周期，同时也负责Volume（CSI）和网络（CNI）的管理；其主要功能概括如下：
持续监听node的健康状态并向master汇报。
基于用户自定义的探针进行存活状态探测，并在任何Pod出现问题时将其重建为新实例。
准备pod所需的数据卷
返回pod的状态
在node节点执行容器的健康检测
2.2 容器运行时环境
Pod是一组容器组成的集合并包含这些容器的管理机制。安并未额外定义进程的边界或其他更多抽象，因此真正负责运行容器的依然是底层的容器运行时。kubelet通过CRI(容器运行时接口)可支持多种类型的OCI容器运行时，例如docker、 containerd、CRI-O、runC、fraki和kata Containers等
2.3 kube-proxy
kube-proxy也是需要运行于集群中每个节点之上的服务进程。它把API Server上的Service资源对象转换为当前节点上的iptables或与ipvs规则。这些规则能够将那些发往该Service对象ClusterIP的流量分发至它后端的Pod端点上。kube-proxy是kubernetes的核心网络组件。它本质上更象是Pod的代理及负载均衡器。负责确保集群中Node、Service和Pod对象之间的有效通信 。
kube-proxy 不同的版本可支持三种工作模式
UserSpace： kubernetes V1.1之前使用，V1.2及以后就已淘汰
IPtables: Kubernetes 1.1版本开始支持。1.2开始为默认
IPVS： kubernetes 1.9引入到1.11为正式版本，需要安装ipvadm、ipset工具包和加载ip_vs内核模块。
2.4 kubectl
是一个通过命令行对kubernetes集群管理的工具
kubectl [command] [TYPE] [NAME] [flags]
2.4 dashboard
基于Web的用户接口，用于可视化k8s集群。dashborad可用于获取集群中资源对象的详细信息，Dashboard提供GUI，作为运维人员，使用kubectl命令行工具管理足矣
2.5 coredns
CoreDNS负责为整个集群提供DNS服务，它自1.11版本起默认使用CoreDNS，一种灵活，可扩展的DNS服务，之前的版本用到的是kube-dns项目，SkyDNS则是更早一代的解决方案。
