一、K8S简述
K8S是Kubernetes的简称，其是基于谷歌的Borg系统开发的。
K8S主要功能：
K8s是用来对docker容器进行管理和编排的工具，其是一个基于docker构建的调度服务，提供资源调度、均衡容灾、服务注册、动态扩容等功能套件，其作用如下所示：
（1）数据卷：pod中容器之间数据共享，可以使用数据卷
（2）应用程序健康检查：容器内服务可能发生异常导致服务不可用，可以使用健康检查策略保证应用的健壮性。
（3）复制应用程序实例：控制器维护着pod的副本数量，保证一个pod或者一组同类的pod数量始终可用。
（4）弹性伸缩：根据设定的指标（CPU利用率等）动态的自动缩放pod数
（5）负载均衡：一组pod副本分配一个私有的集群IP地址，负载均衡转发请求到后端容器，在集群内布，其他pod可通过这个Cluster IP访问集群。
（6）滚动更新：更新服务不中断，一次更新一个pod，而不是同时删除整个服务
（7）服务编排：通过文件描述部署服务，使的程序部署更高效。
（8）资源监控：Node节点组件集成cAdvisor资源收集工具，可通过Heapster汇总整个集群节点资源数据，然后存储到InfluxDB时序数据库，再由Grafana展示
（9）提供认证和授权：支持属性访问控制、角色访问控制等认证授权策略。
K8S的架构图如下所示：
从上图可以看到，K8S提供了：
web browsers提供可视化操作
kubectl来接收Docker镜像进行部署
scheduler进行任务调度
Controller进行请求控制
API Server进行请求的统一网关处理
etcd用于存储集群中的网络及状态信息
Kubelet来接收控制器的处理任务
Container Registry用来存储镜像仓库
二、K8S集群
（一）集群概述
一个K8S集群包含一个master节点和一群node节点，Mater节点负责管理和控制，Node节点是工作负载节点，里面是具体的容器，容器中部署的是具体的服务。
Mater节点包括API Server、Scheduler、Controller Manager、etcd。
API Server：整个集群的对外接口，供客户端和其他组件调用。
Scheduler：负责集群内部资源调度
Controller Manager：负责管理控制器。
etcd：用于保存集群中所有网络配置和对象状态信息。
node节点包括Docker、kubelet、kube-proxy、Fluentd、kube-dns（可选）、pod
（二）Mater节点
上面已经提到，Mater节点包括API Server、Scheduler、Controller Manager、etcd。
1、API Server
API Server是整个集群的统一入口，各组件的协调者，以HTTP的形式对外提供服务，所有对象资源的增删改查和监听操作都交给API Server处理后再提交给etcd进行存储。
2、Scheduler
Scheduler负责集群内部资源调度，其会根据调度算法为新创建的pod选择一个node节点，Scheduler在整个集群中起到了承上启下的重要功能，承上是指她负责接收Controller Manager创建的新的pod，为其安排一个node节点，启下指的是当为pod选定node节点后，目标Node上的kubelet服务进程会接管该pod。
这里就要提一下创建Pod的流程：
（1）kubectl发送创建pod的请求，此时这个命令被apiserver拦截，把创建的pod存储到etcd的podQueue
（2）Scheduler发起调用请求，此时这个命令被apiserver拦截，获取etcd中podQueue.NodeList，使用调度算法（调度算法：预选调度、优选策略）选择一个合适的node节点
（3）把选择合适的pod、node存储到etcd中
（4）node节点上的Kubelet进程，发送请求获取pod、node对应创建资源
（5）此时node发现pod是本node需要创建的，kubelet就开始创建pod
3、Controller Manager
每个资源都对应一个控制器（Kubernets Controller），其用来处理集群中常规的后台任务，而Controller Manager是用来负责管理控制器的。
K8S集群有以下控制器：
（1）Replication Controller：保证Replication Controller中定义的副本数量与实际运行的pod数量一致。
（2）Node Controller：管理维护Node，定期检查Node节点的健康状态，标识出失效和未失效的Node节点。
（3）Namespace Controller：管理维护Namespace，定期清理无效的Namespace，包括Namespace下的API对象，例如pod和service等
（4）Service Controller：管理维护Service，提供负载以及服务代理。
（5）Endpoints Controller：管理维护Endpoints，即维护关联service和pod的对应关系，其对应关系通过Label来进行关联的
（6）Service Account Controller：管理维护Service Account，为每个Namespace创建默认的Service Account，同时为Service Account创建Service Account Secret。
（7）Persistent Volume Controller：持久化数据控制器，用来部署有状态服务
（8）Deamon Set Controller：让每一个Node节点都运行相同的服务
（9）Deployment Controller：无状态服务部署控制器
（10）Job Controller：管理维护Job，为Job创建一次性任务Pod，保证完成Job指定完成的任务数目。
（11）Pod Autoscaler Controller：实现pod的自动伸缩，定时获取监控数据，进行策略匹配，当满足条件时执行pod的伸缩动作。
4、etcd
etcd是一个第三方服务，分布式键值对存储系统，用于保存网络配置、集群状态等信息，例如service、pod等对象的信息。
K8S中一共有两个服务需要用到etcd来协调和存储数据，分别是网络插件flannel和K8S本身，其中flannel使用etcd存储网络配置信息，K8S本身使用etcd存储各种对象的状态和元信息配置。
（三）Node节点
上面提到，node节点包括Docker、kubelet、kube-proxy、Fluentd、kube-dns（可选）、pod等信息。
1、kubelet
kubelet是Mater在Node节点上的代理，每个Node节点都会启动一个kubelet进程，用来处理Mater节点下发到Node节点的任务，管理本机运行容器的生命周期，比如创建容器、Pod挂载数据卷、下载secret、获取容器和节点的状态等工作，kubelet将每个pod转换成一组容器。
kubelet默认监听四个端口：10250、10255、10248、4194
10250端口：kubelet API的端口，也就是kubelet server与api server的通讯端口，定期请求apiserver获取自己所应当处理的任务，通过该端口可以访问和获取node资源及状态。
10248端口：健康检查的端口，通过访问该端口可以判断kubelet是否正常工作，可以通过 kubelet 的启动 参数 --healthz-port 和 --healthz-bind-address 来指定监听的地址和端口
4194端口：kubelet通过该端口可以获取到该节点的环境信息以及node上运行的容器状态等内容，访问 http://localhost:4194 可以看到 cAdvisor 的管理界面,通过 kubelet 的启动参 数 --cadvisor-port 可以指定启动的端口。
10255端口：提供了pod和node的信息，接口以只读形式暴露出去，访问该端口不需要认证和鉴权。
2、kube-proxy
在Node节点上实现Pod网络代理，维护网络规则和四层负载均衡工作，kube-proxy本质上类似于一个反向代理，我们可以把每个节点上运行的kube-proxy看作是service的透明代理兼LB。
kube-proxy监听apiserver中service与endpoints的信息，配置iptables规则，请求通过iptables直接转发给pod。
3、docker
运行容器的引擎，pod内部运行的都是容器，这个容器是由Docker引擎创建的，Docker引擎是node节点的基础服务。
4、pod
pod是最小的部署单元，一个pod由一个或多个容器组成，pod中共享存储和网络，在同一个Docker主机上运行。pod内部可以运行一个或多个容器，一般情况下，为了便于管理，一个pod下只运行一个容器。
（四）Pod
pod就是一个容器，内部封装了docker容器，同时拥有自己的ip地址，也有用自己的HostName，Pod就像一个物理机一样，实际上Pod就是一个虚拟化的容器（进程），pod中运行的是一个或者多个容器。
pod是一个大的容器，由K8S创建，pod内部的是docker容器，由Docker引擎创建。K8S不会直接管理容器，而是管理Pod。
pod的作用是管理线上运行的应用程序，在通常情况下，在服务上线部署的时候，pod通常被用来部署一组相关的服务。而一个调用链上的服务就叫做一组相关的服务。但是实际生产上一般是一个Pod对应一个服务，不会在一个Pod上部署太多的服务。
pod的具体结构如下图所示，一个Node中有很多pause容器，这些pause容器和pod是一一对应的，每个Pod里面运行着一个特殊的被称为Pause的容器，其他的容器则为业务容器，这些容器共享Pause容器的网络和存储，因此他们之间的通信更高效，在同一个pod里面的容器之间仅需要通过localhost就可以通信。
K8S中的pause容器主要为每个业务容器提供以下功能，从而对各个Pod进行了隔离：
PID命名空间隔离：pod中不同的应用程序可以看到其他应用程序的进程ID
网络命名空间隔离：Pod中多个容器能够访问同一个IP和端口范围
IPC命名空间隔离：Pod中多个容器能够使用System VIPC或POSIX消息队列进行通信
UTS命名空间隔离：pod中多个容器共享一个主机名和挂在卷
Pod中各个容器可以访问在Pod级别定义的Volumes
一个Pod创建的过程：首先kubelet会先创建一个pod，然后立马会创建一个pause容器，pause容器是默认创建的，然后再创建内部其他的业务容器。
三、核心组件及原理
1、RC控制器（ReplicationController）
用来确保容器应用的副本数始终与用户定义的副本数一致，如果有副本由于异常退出，Replication Pod会自动创建新的Pod来替代，而如果出现多余的pod，控制器也会自动将其回收。
在新版的K8S中，建议使用ReplicaSet来取代Replication Controller
2、RS控制器（ReplicaSet）
ReplicaSet和Replication Contreoller并没有本质上的区别，ReplicaSet支持集合式的选择器。
虽然ReplicaSet可以独立使用，但一般情况下还是建议使用Deployment来自动管理ReplicaSet，这样就无需担心跟其他机制的不兼容问题。
RC和RS的区别是RC只支持单个标签选择器，不支持复合标签选择器；而RS同时支持单个和复合选择器。
3、label（标签）
label用于区分对象，例如区分是service还是pod，以键值对的形式存在，每个对象可以有多个标签，可以通过标签关联对象。
label是replication Controller和Service运行的基础，二者是通过label来进行关联Node上运行的Pod。我们可以通过给指定的资源对象捆绑一个或多个不同的Label来实现多维度资源分配管理功能，一些常用的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"
label就类似与标签，给某个对象定义了一个label就相当于给对象定义了一个标签。
如果多个pod拥有相同的标签，就说明这是一组pod。
4、selector
标签选择器是K8S非常重要的一环，其用来查询和筛选某些拥有具体标签的对象，K8S也是使用这种方式进行对象的查询。
Label Selector在K8S中的应用有以下几个场景：
Kube-Controller进程通过资源对象RC上定义的Label Selector来筛选要监控的Pod的副本数量，从而实现副本数量与用户定义的副本数量保持一致。
Kube-proxy进程通过Service的Label Selector来筛选对应的Pod，自动建立起每个Service到对应Pod的请求链路表，从而实现Service的负载均衡。
Kube-Scheduler通过对某些Pod的自定义Label，并且在pod定义文件中使用Node Selector这种标签的调度策略，从而实现了Pod定向调度的特性。
例如上面Label的例子中，如果服务中既有环境Label又有版本Label，使用RC只能对同一个版本标签或者同一个环境标签的Pod进行选择，不能同时对版本和环境两个维度进行筛选，而RS可以对两个维度同时进行筛选。
5、Deployment
RS虽然可以控制副本的数量，但是单独的RS部署却不能滚动更新。因此衍生了Deployment组件，其支持滚动更新，其会先创建新版本的pod容器，然后再删除老旧版本的pod容器。
滚动发布：滚动发布有金丝雀发布和灰度发布，该种发布一般是以25%的模式进行发布，也就是先删除25%旧版本，在部署对应数量的新版本Pod，然后再删除25%旧版本，这样以此滚动更新。
因此实际生产中一般都是用RS和Deployment的组合来进行发布服务。
总体来说，Deployment是用来管理RS，RS来管理Pod，deployment支持动态更新，也就是在更新时动态的创建一个新的RS，然后由新RS创建新版本的Pod，然后将旧版本RS中的Pod进行删除。如果发生回滚，就是一个逆向操作，产生一个旧版本的RS，用来生成旧版本的Pod。
在滚动发布过程中，对于流量是转发到新版本还是老版本的Pod中，是由商城的Service进行转发的。
Deployment为Pod和ReplicaSet提供了一个声明式定义方法，典型的应用场景：
定义Deployment来创建Pod和ReplicaSet
滚动升级和回滚应用
扩容和缩容
暂停和继续Deployment
6、HPA（HorizontalPodAutoScale）
HPA仅适用于Deployment和ReplicaSet，在V1.0版本中，仅支持根据pod的CPU利用率进行扩容缩容，在新版本中，支持根据内存和用户自定义的metric进行扩容缩容。说的通俗一点，就是在流量突然增大，可以自动扩容，流量降下后，可以自动缩容。
7、StatefullSet
deployment和StatefullSet都是用来进行服务部署的，但是这两个组件各自使用的场景不一样，deployment是用来部署无状态服务的，而StatefullSet是用来部署有状态服务的。
这里说明一下有状态服务和无状态服务，有状态服务指的是需要进行实时的数据更新和存储的服务，如果将某个服务抽离，再加入进来就没办法进行正常工作，例如mysql、redis等；无状态服务指的是没有对应数据进行更新和存储的服务，如果将某个服务抽离，再加入进来依然可以提供服务，我们常用的业务服务一般都是无状态服务，而docker业主要是为了无状态服务提供部署的。
StatefullSet应用场景包括：
（1）稳定的持久化存储，即pod重新调度后仍然可以访问相同的持久化数据，基于PVC实现
（2）稳定的网络标志，即pod重新调度后，podName和HostName不变，基于Headless Service来实现
（3）有序部署&有序扩展，即pod是有顺序的，在部署或者扩展的时候要依据定义的顺序依次进行，也就是说，从0到N-1，在下一个pod运行前，所有之前的pod都处于running和ready状态。基于init contains实现。
（4）有序收缩&有序删除，即从N-1到0进行回收或删除
总体来说，Pod是可能随时删除或者新增的，一个pod也是有自己的网络和存储的，对于例如Mysql这类的Pod，可能不能发生网络和存储上的变化，StatefullSet就是为了解决这个问题而产生的。
8、DaemonSet
DaemonSet确保全部Node上运行一个Pod副本，当有Node加入集群时，也会为他们新增一个pod，当有Node从集群中被移除时，这些pod也会被回收，删除DaemonSet将会删除其创建的所有pod。最典型的场景就是每个Pod里面都有服务在运行，需要收集服务运行日志，但是Pod是由K8S自动创建或删除的，因此需要使用DaemonSet来设定在每一个Pod中进行日志收集。
DaemonSet的一些典型用法：
（1）运行集群存储Daemon，例如在每个Node上运行glustered、ceph
（2）在每个Node上运行日志收集Daemon，例如fluentd、logstash
（3）在每个Node上运行监控Daemon，例如Prometheus Node Exporter
Job负责批处理任务，即仅执行一次的任务，他保证批处理任务的一个或多个pod成功结束。
9、Volume
数据卷，共享pod中容器使用的数据。