什么是kubernetes？
- kubernetes是Google 开源的容器集群管理系统，是大规模容器应用编排系统，是在众多容器之上的又一抽象层
- 它支持自动部署，大规模可伸缩，应用容器化管理
- kubernetes是Google 开源的一个容器编排引擎，它支持自动化部署，大规模可伸缩，应用容器化管理
- 在kubernetes中部署应用是一件容易的事，因其有着弹性伸缩，横向扩展的优势并同时提供负载均衡能力以及良好的自愈性（自动部署，自动重启，自动复制，自动扩展等）
优质扫盲博文：
主要功能包括：
- 基于容器的应用部署，维护和滚动升级
- 负载均衡和服务发现
- 跨机器和跨地区的集群调度
- 自动伸缩
- 无状态服务和有状态服务
- 插件机制保证扩展性
kubernetes特点：
- 可移植性：支持公有云，私有云，混合云，多重云
- 可扩展性：模块化，插件化，可挂载，可组合
- 自动化：自动部署，自动重启，自动复制，自动扩展/伸缩
kubernetes 核心组件：
1. master组件
- kube-apiserver 提供了资源操作的唯一入口，任何资源的请求/调用操作都是通过它，并提供认证，授权，访问控制，API 注册和发现机制
- kube -controller-manager 集群控制器，负责维护集群的状态，比如故障检测，自动扩展，滚动更新等
- kube- scheduler 负责资源的调度，按照预定的调度策略将pod调度到相应的机器上，为pod选择一个node
- etcd 保存了整个集群的状态信息，分布式键值对（k/v）存储服务
- core DNS 第三方插件，提供集群的dns服务，实现服务注册和服务发现，为service提供dns记录
2.Node 组件
- kubelet 负责维护容器的生命周期，同时也负责volume（CVI )和网络（CNI ）的管理
- kube- proxy 负责为service提供cluster内部的服务发现和负载均衡（负责将后端pod访问规则具体为节点上的iptables/ipvs规则）
- container runtime （docker）负责镜像管理以及pod和容器的真正运行（CRI)
kubernetes中的负载均衡的主要两种机制：
- Service：使用service提供集群内部的负载均衡，kube-proxy负责将service请求负载均衡到后端pod中（体现为iptables/ipvs规则）
- Ingress controller：使用ingress提供集群外部的负载均衡，将集群内部服务开放到集群外部访问
（1）常用的ingress controller：nginx，traefik，kong，openresty
Job & CronJob 任务和定时任务
- Job负责批量处理短暂的一次性任务（short lived>CronJob即定时任务，就类似于linux的定时任务cronntab任务，在指定时间内周期运行指定的任务
kubernetes工作流：
- 提交请求：用户通常是提交一个yaml文件，向api server发送请求创建一个pod，yaml文件含有此pod的详细信息，包含此pod运行的副本数，镜像，labels，名称，端口暴露情况等。API server接收到请求后将yaml文件中的spec数据存入etcd中
- 资源状态同步：这一步涉及到Replication组件，Replication组件监控着数据库中的数据变化，对已有的pod进行数量上的同步
- 资源分配：Scheduler会检查etcd数据库中记录的没有被分配的pod，将此类pod分配到具有运行能力的node节点上，并更新etcd数据库中的该pod分配情况
- 新建容器：kubernetes集群node节点中的kubelet通过api server对etcd数据库中的pod部署状态进行同步，目标node节点上的kubelet将pod相关yaml文件中spec（期望状态）数据递给后端容器运行引擎（如docker等容器）后者负责pod容器的运行停止和更新；kubelet会通过容器运行时引擎获取pod的状态信息并将此信息通过api server更新写入到etcd中；
- 节点通讯：kube-proxy负责各节点中pod网络通讯，负责服务发现和负载均衡
集群核心组件详述：
1. API Server
- 组件在pod工作流中的功能
- 为整个pod工作流提供了资源对象（pod，deployment，service等）的增删改查操作以及集群管理的rest api接口，集群管理主要包括认证授权准入控制，集群状态管理和数据校验等
- 提供集群中各组件的通信以及交互功能
- 提供资源配额控制入口功能
- 安全的访问控制机制
- 在kubernetes集群中，API Server运行在Master节点上，默认开放两个端口，分别是本地端口的8080（非认证或授权的kttp请求通过该端口访问api server）和安全加密端口6443（该端口用于接收https请求并且用于token文件或客户端证书及http basic的认证同时用于基于策略的授权）， kubernetes中默认不启动https安全访问控制
- 集群组件间通讯：API server在整个pod工作流中主要负责各个组件间通信，Scheduler,Controller Manager,Kubelet通过API Server将资源对象信息存入etcd中，当各组件需要这些数据时又通过API Server的Rest接口来实现信息交换，以下分别说明。
>>>>
1-1. Kubelet与API Server
在Pod工作流中，位于集群中每个Node节点上的Kubelet会定期调用API Server的Rest接口去告知当前自身状态，API Sever接收到状态信息后，将其更新至Etcd中，Kubelet也同时通过API Server的Watch接口去监听Pod信息，从而对各个Node节点上的Pod进行管理，主要监听信息如表1所示：
表1:
|
监听信息
|
Kubelet 执行
|
|
是否有新的Pod被绑定到Node节点
|
执行Pod对应容器的创建和启动
|
|
是否有Pod对象被删除
|
删除Node上相应Pod容器
|
|
是否有修改Pod信息
|
修改Node上Pod的信息
|
>>>>
1-2. kube-controller-manager与API Server
Controller Manager包含许多控制器，例如Endpoint Controller、Replication Controller、Service Account Controller等, 具体会在后面Controller Manager部分说明，这些控制器通过API Server提供的接口去实时监控当前kubernetes集群中每个资源对象的状态变化并将最新的信息保存在Etcd中，当集群中发生各种故障导致系统发生变化时，各个控制器会从Etcd中获取资源对象信息并尝试将系统状态修复至理想状态。
>>>>
1-3. kube-scheduler与API Server
Scheduler通过API Server的Watch接口监听Master节点新建的Pod副本信息并检索所有符合该Pod要求的Node列表同时执行调度逻辑，成功后将Pod绑定在目标节点处。由于在集群中各组件频繁对API Server进行访问，各组件采用了缓存机制来缓解请求量，各组件定时从API Server获取资源对象信息并将其保存在本地缓存中，所以组件大部分时间是通过访问缓存数据来获得信息的。
2.Controller Manager
Controller Manager在pod工作流中起着管理和控制整个集群的作用，主要对资源对象进行管理，当node节点中运行的pod对象或是node自身发生意外或故障时，Controller Manager会及时发现并处理，以确保整个集群处于理想工作状态。核心逻辑就是和解循环；控制器负责创建kubernetes集群上的具体对象，并确保其当前状态status与用户自定的期望状态spec保持相同
>>>>
2-1. Replication Controller
Replication Controller称为副本控制器，在Pod工作流中主要用于保证集群中Replication Controller所关联的Pod副本数始终保持在预期值，比如若发生节点故障的情况导致Pod被意外杀死，Replication Controller会重新调度保证集群仍然运行指定副本数，另外还可通过调整Replication Controller中spec.replicas属性值来实现扩容或缩容。
>>>>
2-2. Endpoint Controller
Endpoint用来表示kubernetes集群中Service对应的后端Pod副本的访问地址，Endpoint Controller则是用来生成和维护Endpoints对象的控制器，其主要负责监听Service和对应Pod副本变化。如果监测到Service被删除，则删除和该Service同名的Endpoints对象；如果监测到新的Service被创建或是被修改，则根据该Service信息获得相关的Pod列表，然后创建或更新对应的Endpoints对象；如果监测到Pod的事件，则更新它对应的Service的Endpoints对象。图5所示为Service、Endpoint、Pod的关系：
3.Scheduler
Scheduler在整个pod工作流中负责调度pod到具体的node节点，Scheduler通过api server监听pod状态，如果有待调度的pod，则根据Scheduler Controller中预选策略和优选策略给各个预备node节点打分排序，最后将pod调度到分数最高的node上，然后由node中的kubelet组件启停pod。当然如果部署pod指定了NodeName属性，Scheduler会根据该属性指调度到指定node节点上。
整个调度流程分两步：
第一步预选策略（Predicates）
预选策略的主要工作机制是遍历所有当前kubernetes集群中的Node，按照具体的预选策略选出符合要求的Node列表;如果没有符合的Node节点，则该Pod会被暂时挂起，直到有Node节点能满足条件。通用的预选策略筛选规则有：
PodFitsResources、PodFitsHostPorts、HostName、MatchNodeSelector。
第二步优选策略（Priorities）
有了第一步预选策略的筛选后，再根据优选策略给待选Node节点打分，最终选择一个分值最高的节点去部署 Pod。kubernetes 用一组优先级函数处理每一个待选的主机。每一个优先级函数会返回一个0-10的分数，分数越高表示节点越适应需求，同时每一个函数也会对应一个表示权重的值。最终主机的得分用以下公式计算得出：
FinalScoreNode = (weight1 priorityFunc1) + (weight2 priorityFunc2) + … + (weightn * priorityFuncn)
4.Kubelet
kubelet在pod工作流中是为保证它所在的节点pod能够正常工作，核心为监听API server，当发现节点的pod配置发生变化则根据最新的配置执行相应的动作，保证pod在理想的预期状态，其中对pod进行启停更新操作用到的是容器运行时。另外kubelet也负责volume（cvi）和网络（cni）管理。