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

clh899

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定期读取信息，并做如下处理：
  
  
  • Controller Manager在启动时如果设置了--cluster-cdir参数，则每个设置了spec.PodCIDR的Node生成一个CIDR地址
    
  • 逐个读取节点信息，将节点信息和Node Controller的nodeStatusMap中保存的节点信息做比较。
    
    
    
    • 没收到节点信息、第一次收到节点信息、处理过程中节点状态变成非健康状态、在指定时间内收到新节点信息且节点状态发生变化，用Master节点的系统时间作为探测时间和节点状态变化时间
      
    • 在指定时间内收到新的节点信息，但节点状态没改变，用Master节点的系统时间作为探测时间，用上次节点信息中的节点状态状态改变时间作为该节点的状态改变时间
      
    
    
  • 如果某一段时间内没有收到节点状态信息，则置该节点状态为“未知”
    
  • 如果节点状态为非就绪状态，则将节点加入到待删除队列否则从该队列中删除。如果系统指定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提供的默认调度流程：
  
  
  • 预选调度过程，遍历所有目标Node，筛选出符合要求的候选节点
    
  • 确定最优点，基于候选节点，采用优选策略计算出每个候选节点的积分，积分最高者获胜
    
  
  
• 预选策略
  
  
  
  • NoDiskConflict，判断备选Pod的GCEPersistentDisk或AWSElasticBloackStore和备选的节点中已存的Pod是否存在冲突
    
  • PodFitsResources，判断节点的资源是否满足Pod的需求
    
  • PodSelectorMatches，节点是否包含备选pod的标签选择器指定的标签
    
  • PodFitsHost，判断备选Pod的spec.nodeName所指定的节点名称和备选节点名称是否一致
    
  • CheckNodeLabelPresence，判断策略列出的标签在备选节点中存在时，是否选择该备选节点
    
  • CheckServiceAffinity，判备选节点是否包含策略指定的标签或包含和备选Pod在相同Service和Namespace下的Pod所在节点的标签列表
    
  • PodFitsPorts，判断备选Pod所用端口列表中的端口是否在备选节点中已被占用
    
  
  
• 优选策略，每个节点通过优选策略都会算出一个得分，计算各项总分，分值最大的最优
  
  
  
  • LeastRequestedPriority，从备选节点列表中选出资源消耗最小的节点
    
  • CalculateNodeLabelPriority，判断策略列出的标签在备选节点中存在时，是否选择该备选节点
    
  • BalancedResourceAllocation，从备选节点列表中选出各项资源使用率最均衡的节点