《Kubernetes权威指南》——组件原理

1 API Server

1.1 提供集群管理的API接口

• API Server在kubernetes中的进程名为apiserver，运行在Master节点上
• apiserver开放两个端口
  • 本地端口，默认8080
  • 安全端口，默认6443，接受Https，用于基于Token以及策略的受权
• Kubectl Proxy做为API Server的反向代理，也能做为普通客户端访问API Server
• 命令行工具kubectl用来将API Server的API包装成建档的命令集

1.2 成为集群内各个功能模块之间数据交互和通讯的中心枢纽

• 集群内的功能模块经过API Server将信息存入etcd，其余模块经过API Server读取这些信息，从而实现模块之间的信息交互
• 为了缓解各模块对API Server的访问压力，各个功能模块都采用缓存的机制来缓存数据，各模块定时从API Server获取指定资源对象信息(list及watch方式)，功能模块不直接访问API Server

1.3 拥有完备的集群安全机制

后续安全章节

2 Controller Manager

其为集群内部的管理控制中心，负责集群内的Node、Pod副本、服务端点(Endpoint)、命名空间(Namespace)、服务账号(ServiceAccount)、资源定额(ResourceQuota)等的管理并执行自动化修复流程

2.1 Replication Controller

做用： 确保在任什么时候候集群中一个RC所关联的Pod都保持必定数量的Pod副本处于正常运行状态

• Pod对象被成功建立后不会消失，用户或RC会销毁Pod对象，惟一例外是当Pod处于succeeded或failed状态时间过程时，该Pod将被系统自动回收
• 当Pod状态编程failed或被删除，且其RestartPolicy=Always时，管理该Pod的副本控制器将在其余Node上从新建立运行该Pod
• Pod能够经过修改Label来实现脱离RC的管控，该方法能够用于将Pod从集群中迁移、数据修复等调试
• 经过调整RC的spec.replicas的属性来调整Pod的副本数量
• RC的使用模式：
  • 从新调度，保证Pod的副本数量
  • 弹性伸缩，手动或经过自动扩容代理修改RC的spce.replicas的值
    kubectl scale --replicas=3 replicationcontroller foo//设置foo的RC副本
  • 滚动更新，RC被设计成经过逐个替换Pod的方式来辅助服务的滚动更新

2.2 Node Controller

做用： 负责管理、发现和监控集群中的各个Node节点

• Kubelet在启动时经过API Server注册节点信息，并定时向API Server发送节点信息，API Server将接受的信息存入etcd
• Node Controller经过API Server按期读取信息，并作以下处理：
  1. Controller Manager在启动时若是设置了--cluster-cdir参数，则每一个设置了spec.PodCIDR的Node生成一个CIDR地址
  2. 逐个读取节点信息，将节点信息和Node Controller的nodeStatusMap中保存的节点信息作比较。
     • 没收到节点信息、第一次收到节点信息、处理过程当中节点状态变成非健康状态、在指定时间内收到新节点信息且节点状态发生变化，用Master节点的系统时间做为探测时间和节点状态变化时间
     • 在指定时间内收到新的节点信息，但节点状态没改变，用Master节点的系统时间做为探测时间，用上次节点信息中的节点状态状态改变时间做为该节点的状态改变时间
  3. 若是某一段时间内没有收到节点状态信息，则置该节点状态为“未知”
  4. 若是节点状态为非就绪状态，则将节点加入到待删除队列不然从该队列中删除。若是系统指定Cloud Provider则Node Controller调用Cloud Provider查看节点，发现节点故障则删除etcd中节点信息，并删除该节点相关的Pod等资源信息

2.3 ResourceQuota Controller

做用： 资源配置管理确保指定的对象在任什么时候候都不会超量占用系统资源

• 三个层次的资源配额管理：

  • 容器级别，对CPU与Memory进行限制
  • Pod级别，对一个Pod内全部容器的可用资源限制
  • Namespace级别，如今该Namespace下的Pod、Replication Controller、Service、ResourceQuota、Secret和可持有的PV(Persistent Volume)
• 配额管理经过准入机制(Admission Control)实现，与配额相关的两种准入控制器是LimitRanger与ResourceQuota，前者做用与Pod和Container后者做用于Namespace
• 全部Pod、Service、RC、Secret和Persistent Volume资源对象的实时状态经过API Server保存到etcd，ResourceQuota Controller在计算资源使用总量时会用到这些信息

• 用户经过API Server请求建立或修改资源时，API Server会调用Admission Controller的ResourceQuota插件，其将读取etcd中的统计结果，若是某项资源超出配额，则将拒绝执行

2.4 Namespace Controller

• 经过API Server建立Namespace并保存到etcd，Namespace Controller定时读取Namespace信息
• 当Namespace被标识为优雅删除(设置删除期限，DeletionTimestamp属性被设置)，则将其状态设置为Terminating，同时删除其下的全部对象
• 当状态为Terminating时由Adminssion Controller的NamespaceLifecycle插件阻止为该Namespace建立新资源
• Namespace Controller为其删除完全部资源对象后，将对其执行finalize操做，删除Namespace的spec.finalizers域中的信息

2.5 ServiceAccount Controller与Token Controller

ServiceAccount Controller 在Controller Manager启动时被建立，其监听Service Account的删除事件和Namespace的建立、修改事件

Token Controller 监听Service Account和Secret的建立、修改和删除事件，并根据事件的不一样作不一样处理

2.6 Service Controller与Endpoint Controller

Service 定义Pod集合的抽象，或者被访问者看做一个访问策略，也可称为微服务

Service Controller 监控Service的变化，若是是LoadBalancer类型则需确保外部LoadBalancer被相应建立与删除

Endpoint Controller 经过Store来缓存Service和Pod信息，监控Service和Pod的变化

• Kubernetes中Service是一种资源对象经过标签选择器选择Pod
• 若是Service指定了标签选择器，系统将自动建立一个和该Service同名的Endpoint资源对象，其包含一个地址和端口集合，地址与端口即被选择的Pod的
• 经过虚拟IP访问后端Pod
  • kube-proxy进程会观察Master上添加和删除Service和Endpoint的行为
  • kube-proxy为每一个Service在本地主机开一个端口，任何访问该端口的链接都被代理到相应的Pod(选择Pod依据Round Robin算法及Service的Session粘连决定)
  • kube-proxy在本机Iptables安装相应规则，将捕获的流量重定向到上一步中的随机端口
• Kubernetes会为Service制定一个集群Ip
• Kubernetes支持容器的Service环境变量和DNS两种形式来查找Service的集群IP
• Service暴露外网ip能够经过NodePort和LoadBalancer两种模式

3 Scheduler

做用： 在于将待调度的Pod经过一些复杂的调度流程绑定到某个合适的Node上，并写入etcd

• 主要涉及待调度Pod列表、可用Node列表和调度算法和策略
• Kubernetes提供的默认调度流程：
  1. 预选调度过程，遍历全部目标Node，筛选出符合要求的候选节点
  2. 肯定最优势，基于候选节点，采用优选策略计算出每一个候选节点的积分，积分最高者获胜
• 预选策略
  • NoDiskConflict，判断备选Pod的GCEPersistentDisk或AWSElasticBloackStore和备选的节点中已存的Pod是否存在冲突
  • PodFitsResources，判断节点的资源是否知足Pod的需求
  • PodSelectorMatches，节点是否包含备选pod的标签选择器指定的标签
  • PodFitsHost，判断备选Pod的spec.nodeName所指定的节点名称和备选节点名称是否一致
  • CheckNodeLabelPresence，判断策略列出的标签在备选节点中存在时，是否选择该备选节点
  • CheckServiceAffinity，判备选节点是否包含策略指定的标签或包含和备选Pod在相同Service和Namespace下的Pod所在节点的标签列表
  • PodFitsPorts，判断备选Pod所用端口列表中的端口是否在备选节点中已被占用
• 优选策略，每一个节点经过优选策略都会算出一个得分，计算各项总分，分值最大的最优
  • LeastRequestedPriority，从备选节点列表中选出资源消耗最小的节点
  • CalculateNodeLabelPriority，判断策略列出的标签在备选节点中存在时，是否选择该备选节点
  • BalancedResourceAllocation，从备选节点列表中选出各项资源使用率最均衡的节点