一、Kubernetes架构图
二、各组件的介绍
2.1 Kube-Apiserver
Kubernetes API Server的核心功能是提供Kubernetes各类资源对象（如Pod、 RC、 Service等） 的增、 删、 改、 查及Watch等
HTTP Rest接口，成为集群内各个功能模块之间数据交互和通信的中心枢纽，是整个系统的数据总线和数据中心。 除此之外，它还有以下一些功能特性。
（1）是集群管理的API入口。
（2）是资源配额控制的入口。
（3）提供了完备的集群安全机制。
2.2 Controller Manager
Kubernetes里所有资源对象的自动化控制中心，可以将其理解为资源对象的“大总管”。
Controller Manager内部包含Replication Controller、Node Controller、ResourceQuota Controller、Namespace Controller、 ServiceAccount Controller、Token Controller、 Service
Controller及Endpoint Controller这8种Controller，每种Controller都负责一种特定资源的控制流程，而Controller Manager正是这些Controller的核心管理者。
2.3 Scheduler
Kubernetes Scheduler的作用是将待调度的Pod（API新创建的Pod、 Controller Manager为补足副本而创建的Pod等） 按照特定的调度算法和调度策略绑定（Binding）到集群中某个合适的Node上，并将绑定信息写入etcd中。在整个调度过程中涉及三个对象，分别是待调度Pod列表、可用Node列表，以及调度算法和策略。简单地说，就是通过调度算法调度为待调度Pod列表中的每个Pod从Node列表中选择一个最适合的Node
2.4 ETCD
Etcd的官方将它定位成一个可信赖的分布式键值存储服务，它能够为整个分布式集群存储一些关键数据，协助分布式集群的正常运行。
2.5 Kubelet
在Kubernetes集群中，在每个Node（又称Minion）上都会启动一个kubelet服务进程。 该进程用于处理Master下发到本节点的任务，管理Pod及Pod中的容器。 每个kubelet进程都会在API Server上注册节点自身的信息，定期向Master汇报节点资源的使用情况，并通过cAdvisor监控容器和节点资源。
会和CRI （docker容器引擎）进行交互，操作docker创建对应的容器，kubelet会维护pod的生命周期。
2.6 Kube-Proxy
在Kubernetes集群的每个Node上都会运行一个kube-proxy服务进程，可以把这个进程看作Service的透明代理兼负载均衡器，其核心功能是将到某个Service的访问请求转发到后端的多个Pod实例上。
2.7 NameSpace
Namespace（命名空间） 是Kubernetes系统中的另一个非常重要的概念，Namespace在很多情况下用于实现多租户的资源隔离。
Namespace通过将集群内部的资源对象“分配”到不同的Namespace中，形成逻辑上分组的不同项目、小组或用户组，便于不同的分组在共享使用整个集群的资源的同时还能被分别管理。用以存放集群所使用的默认 Pods、Services 和 Deployments 集合。
初始状态下，kubernetes默认的命名空间
default：无命名空间对象默认命名空间
kube-system：由 Kubernetes 系统创建的对象的命名空间
kube-public：自动创建且被所有用户可读的命名空间（包括未经身份认证的）。此命名空间通常在某些资源在整个集群中可见且可公开读取时被集群使用。此命名空间的公共方面只是一个约定，而不是一个必要条件。
kube-node-lease：对于提升 Kubernetes 集群规模来说，NodeLease 是一个非常重要的 Feature 。在没有开启 NodeLease 之前，Kubelet 会使用 Update Node Status 的方式更新节点心跳，而一次这样的心跳会向 API Server 发送大约10 KB数据量。
在大规模场景下，API Server 处理心跳请求是非常大的开销。而开启 NodeLease 之后，Kubelet 会使用非常轻量的 NodeLease 对象(0.1 KB)更新请求替换老的 Update Node Status 方式，这大大减轻了 API Server 的负担。在上线NodeLease 功能之后，集群API Server 开销的 CPU 大约降低了一半。
2.8 Labels
Label（标签） 是Kubernetes系统中另外一个核心概念。一个Label是一个key=value的键值对， 其中key与value由用户自己指定。
Label可以被附加到各种资源对象上，例如Node、Pod、Service、RC等，一个资源对象可以定义任意数量的Label，同一个Label也可以被添加到任意数量的资源对象上。Label通常在资源对象定义时确定，也可以在对象创建后动态添加或者删除。随后可以通过Label Selector（标签选择器） 查询和筛选拥有某些Label的资源对象
版本标签："release":"stable"、 "release":"canary"
环境标签： "environment":"dev"、 "environment":"qa"、 "environment":"production"
架构标签： "tier":"frontend"、 "tier":"backend"、 "tier":"middleware"
分区标签： "partition":"customerA"、 "partition":"customerB"
质量管控标签： "track":"daily"、 "track":"weekly"
2.9 Service
Service定义了一个服务访问的入口，会根据标签匹配到不同的pod中，把pod信息记录到svc的信息中，通过标签进行匹配一组pod的方式 ，每个SVC可以理解成一个微服务。
ClusterIP：虚拟的服务IP地址，该地址用于k8s集群内部的pod访问，在node上kube-proxy通过设置iptables转发，新版本为lvs
NodePort：使用宿主机的端口，使能够访问各Node的外部客户端通过Node的IP地址和端口号（30000-32767）就能访问服务
LoadBalancer：使用外接负载均衡器完成到服务的负载分发，需要在spec.status.loadBalancer字段指定外部负载均衡器的IP地址，并同时定义nodePort和clusterIP，用于公有云环境
2.10 ConfigMap
ConfigMap通过Volume映射的方式变成目标Pod内的配置文件，不管目标Pod被调度到哪台服务器上，都会完成自动映射。进一步地，如果ConfigMap中的key-value数据被修改， 则映射到Pod中的“配置文件”也会随之自动更新。于是， Kubernetes ConfigMap就成了分布式系统中最为简单（使用方法简单，但背后实现比较复杂）且对应用无侵入的配置中心。
