k8s master 支持管理多少容器 k8s三个master工作原理

一、k8s的架构及工作原理

基本架构

1. Master

K8S中的Master是集群控制节点，负责整个集群的管理和控制，其中master节点的基本组件有：

• apiserver：提供了k8s各类资源对象（pod,RC,Service等）的增删改查及watch等HTTP Rest接口，是整个系统的数据总线和数据中心。
• controller-manager：负责对所有资源对象进行控制，通过 apiserver 监控整个集群的状态，并确保集群处于预期的工作状态。
• scheduler：负责资源调度的进程，通过API Server的Watch接口监听新建Pod副本信息，并通过调度算法为该Pod选择一个最合适的Node。
• etcd：负责保存k8s里的所有资源对象以及状态的数据。

2.Node

Node是k8s集群中的工作节点，每个Node都会被Master分配一些进程，当某个Node发生异常时，其上的工作负载会被Master自动转移到其他节点上，node节点的基本组件包括：

• kubelet：负责Pod对应的容器的创建等任务，同时与Master密切协作，实现集群管理的基本功能
• kube-proxy：实现svc的通信与负载均衡机制的重要组件。
• Docker Engine：就是docker，负责本node节点上的容器的创建与管理。

在默认情况下Kubelet会向Master注册自己，一旦Node被纳入集群管理范围，kubelet进程就会定时向Master汇报自身的信息（例如机器的CPU和内存情况以及有哪些Pod在运行等），这样Master就可以获知每个Node的资源使用情况，并实现高效均衡的资源调度策略。而某个Node在超过指定时间不上报信息时，会被Master判定为失败，Node的状态被标记为不可用，随后Master会触发工作负载转移的自动流程

工作原理

创建pod的过程

1. 用户通过kubectl命令行工具发送创建pod的请求
2. apiserver处理用户请求，并将pod数据存储到etcd
3. scheduler通过apiserver的watch机制，查看到新的pod，并为pod绑定node
4. 绑定过程中需要过滤掉有污点的node，污点包括主观上不想调用的node，一般会被用户主动打上污点，另外还有被自动打上的污点，包括资源被限制的node（内存或者磁盘不符合pod的标准，空间不足等），node状态异常的（Ready处于false或者unknown状态）等。
5. 在过滤后留下来的主机中选择最合适的node节点，比如负载最低的节点，将不同副本分布在不同节点上等等，最终得到最优化的节点，并将数据存入etcd
6. 之后kubelet根据调度结果执行Pod创建操作，在相应节点上，使用docker engine根据相应的镜像创建相对应的容器，产生所需的pod节点。
7. pod开始正常运行之后，由controller-manager来管理副本数等。
8. pod节点创建成功！

集群调度

简介

Scheduler 是 kubernetes 的调度器，主要的任务是把定义的 pod 分配到集群的节点上。听起来非常简单，但有很多要考虑的问题：

• 公平：如何保证每个节点都能被分配资源
• 资源高效利用：集群所有资源最大化被使用
• 效率：调度的性能要好，能够尽快地对大批量的 pod 完成调度工作
• 灵活：允许用户根据自己的需求控制调度的逻辑

Sheduler 是作为单独的程序运行的，启动之后会一直监听 API Server，获取Pod中Spec.NodeName为空的 pod，对每个 pod 都会创建一个 binding，表明该 pod 应该放到哪个节点上。

调度过程

调度分为几个部分：

1. 首先是过滤掉不满足条件的节点，这个过程称为predicate；
2. 然后对通过的节点按照优先级排序，这个是priority；
3. 最后从中选择优先级最高的节点。

如果中间任何一步骤有错误，就直接返回错误。

Predicate 有一系列的算法可以使用：

• PodFitsResources：节点上剩余的资源是否大于 pod 请求的资源
• PodFitsHost：如果 pod 指定了 NodeName，检查节点名称是否和 NodeName 匹配
• PodFitsHostPorts：节点上已经使用的 port 是否和 pod 申请的 port 冲突
• PodSelectorMatches：过滤掉和 pod 指定的 label 不匹配的节点
• NoDiskConflict：已经 mount 的 volume 和 pod 指定的 volume 不冲突，除非它们都是只读

如果在 predicate 过程中没有合适的节点，pod 会一直在pending状态，不断重试调度，直到有节点满足条件。

经过这个步骤，如果有多个节点满足条件，就继续 priorities 过程：

按照优先级大小对节点排序优先级由一系列键值对组成，键是该优先级项的名称，值是它的权重（该项的重要性）。这些优先级选项包括：

• LeastRequestedPriority：通过计算 CPU 和 Memory 的使用率来决定权重，使用率越低权重越高。换句话说，这个优先级指标倾向于资源使用比例更低的节点
• BalancedResourceAllocation：节点上 CPU 和 Memory 使用率越接近，权重越高。这个应该和上面的一起使用，不应该单独使用
• ImageLocalityPriority：倾向于已经有要使用镜像的节点，镜像总大小值越大，权重越高通过算法对所有的优先级项目和权重进行计算，得出最终的结果

节点亲和性

节点亲和性一般存放在pod的pod.spec.nodeAffinity中

• preferredDuringSchedulingIgnoredDuringExecution 软策略：指的是该pod最好要部署在某个node上，指的是优先级上的最高

apiVersion: v1
kind: Pod
metadata:
  name: affinity  
  labels:    
    app: node-affinity-pod
spec:
  containers:  
  - name: with-node-affinity    
    image: doggymo/myapp:v1  
  affinity:    
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1      
        preference:
          matchExpressions:          
          - key: source

• requiredDuringSchedulingIgnoredDuringExecution 硬策略： 指的是该pod一定要被部署在某个node上，指的是必须被部署到

apiVersion: v1
kind: Pod
metadata:
  name: affinity
  labels:
    app: node-affinity-pod
spec:
  containers:
  - name: with-node-affinity    
    image: doggymo/myapp:v1  
  affinity:
    nodeAffinity: 
      requiredDuringSchedulingIgnoredDuringExecution:   
        nodeSelectorTerms:
        - matchExpressions:        
          - key: kubernetes.io/hostname
            operator: NotIn  # 键值运算关系           
            values:            
            - k8s-node02

键值运算关系还包括：

• In：label 的值在某个列表中
• NotIn：label 的值不在某个列表中
• Gt：label 的值大于某个值
• Lt：label 的值小于某个值
• Exists：某个 label 存在
• DoesNotExist：某个 label 不存在

Pod 亲和性

pod亲和性定义在：pod.spec.affinity.podAffinity（pod亲和性）/podAntiAffinity（pod反亲和性）

• preferredDuringSchedulingIgnoredDuringExecution 软策略，指的是尽量可以和所选pod在同一拓扑域中
• requiredDuringSchedulingIgnoredDuringExecution 硬策略，指的是必须和所选pod处于同拓扑域。

为什么这里说的是拓扑域，在下图中，node1和node2其实就是属于同拓扑域。

污点与容忍

一个node可以设置多个污点，不容忍污点的pod不能调度到这个节点，容忍度设置给pod，这样的pod允许但不是必须调度到有这些污点的node。

污点的组成

使用kubectl taint命令可以给某个 Node 节点设置污点，Node 被设置上污点之后就和 Pod 之间存在了一种相斥的关系，可以让 Node 拒绝 Pod 的调度执行，甚至将 Node 已经存在的 Pod 驱逐出去每个污点的组成如下：key=value:effect包括以下三种 effect：

• NoSchedule：表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上
• PreferNoSchedule：表示 k8s 将尽量避免将 Pod 调度到具有该污点的 Node 上
• NoExecute：表示 k8s 将不会将 Pod 调度到具有该污点的 Node 上，同时会将 Node 上已经存在的 Pod 驱逐出去

忍受

设置了污点的 Node 将根据 taint 的 effect：NoSchedule、PreferNoSchedule、NoExecute 和 Pod 之间产生互斥的关系，Pod 将在一定程度上不会被调度到 Node 上。但我们可以在 Pod 上设置容忍 ( Toleration ) ，意思是设置了容忍的 Pod 将可以容忍污点的存在，可以被调度到存在污点的 Node 上。

tolerations:
- key: "key1"  
  operator: "Equal"  
  value: "value1"  
  effect: "NoSchedule"  
  tolerationSeconds: 3600
- key: "key1"  
  operator: "Equal"  
  value: "value1"  
  effect: "NoExecute"
- key: "key2"  
  operator: "Exists"  
  effect: "NoSchedule"

• 其中 key, vaule, effect 要与 Node 上设置的 taint 保持一致
• operator 的值为 Exists 将会忽略 value 值
• tolerationSeconds 用于描述当 Pod 需要被驱逐时可以在 Pod 上继续保留运行的时间

tolerations:
- operator: "Exists"

如果不设置key，表示容忍所有的污点

tolerations:
- key: "key"  
  operator: "Exists"

如果不设置effect值，表示可以容忍所有的污点作用。

2.k8s中的Qos

QoS简介

QoS（Quality of Service），大部分译为 “服务质量等级”，又译作 “服务质量保证”，是作用在 Pod 上的一个配置，当 Kubernetes 创建一个 Pod 时，它就会给这个 Pod 分配一个 QoS 等级，可以是以下等级之一：

• Guaranteed：Pod 里的每个容器都必须有内存/CPU 限制和请求，而且值必须相等。如果一个容器只指明limit而未设定request，则request的值等于limit值。
• Burstable：Pod 里至少有一个容器有内存或者 CPU 请求且不满足 Guarantee 等级的要求，即内存/CPU 的值设置的不同。
• BestEffort：容器必须没有任何内存或者 CPU 的限制或请求。

该配置不是通过一个配置项来配置的，而是通过配置 CPU/MEM的 limits 与 requests 值的大小来确认服务质量等级。

首先我们来看Qos为guaranteed的pod

然后我们来看Qos为brustable的pod

最后我们来看Qos为besteffort的pod

我们可以通过限制limits和需求requests的关系来改变Qos的状态

QoS 优先级

三种 QoS 优先级，从高到低（从左往右）

Guaranteed --> Burstable --> BestEffort

Kubernetes 资源回收策略

Kubernetes 资源回收策略：当集群监控到 node 节点内存或者CPU资源耗尽时，为了保护node正常工作，就会启动资源回收策略，通过驱逐节点上Pod来减少资源占用。

三种 QoS 策略被驱逐优先级，从高到低（从左往右）

BestEffort --> Burstable --> Guaranteed

优先级和抢占

首先需要明确的是：优先级和抢占机制，解决的是pod调度失败时该怎么办的问题。

正常情况下，当一个pod调度失败后，就会被暂时 “搁置”pending状态，直到pod被更新，或者集群状态发生变化，调度器才会对这个pod进行重新调度。

场景分析：当一个高优先级的pod调度失败后，该pod并不会被”搁置”，而是会”挤走”某个node上的一些低优先级的Pod。这样就可以保证高优先级pod的调度成功。

1. PriotityClass
   而在kubernetes中，优先级和抢占机制是在1.10版本后才逐步可用的。要使用这个机制，首先需要在kubernetes里提交一个PriotityClass的定义，如下所示：

apiVersion: scheduling.k8s.io/v1beta1
kind: PriorityClass
metadata:
  name: high-priority
value: 1000000
globalDefault: false
description: "This priority class should be used for high priority service pods only."

kubernetes规定，优先级是一个32bit的整数，最大值不超过1000000000（10亿），并且值越大优先级越高。

上述yaml文件中的globalDefault被设置成true的话，那就意味着这个PriorityClass的值会成为系统的默认值。false表示的是只希望声明使用该PriorityClass的Pod拥有值为1000000的优先级，而对于没有声明Priority的Pod来说，优先级就是0。

创建PriorityClass对象之后，Pod就可以声明使用它，如下：

apiVersion: v1
kind: Pod
metadata:
  name: nginx
  labels:
    env: test
spec:
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent
  priorityClassName: high-priority

pod通过priorityClassName字段，声明了要使用high-priority的PriorityClass。当pod提交给kubernetes之后，kubernetes的PriorityAdmissionController就会将这个pod的spec.priority字段设置为100000。

而当一个高优先级的pod调度失败的时候，调度器的抢占能力就会被触发。这时，调度器就会试图从当前集群里寻找一个节点，使得当这个节点上的一个或者多个低优先级pod被删除后，待调度的高优先级pod就可以被调度到这个节点上。这个过程，就是“抢占”在kubernetes中的主要体现。

对于两个需要同时被调度的pod来说，会首先调度优先级大的pod；当一个优先级低的pod01节点被调度成功之后（在node01上），一个优先级高的pod02由于node01节点资源不足出现调度失败的情况，这个时候会删除pod01，并把pod02部署到node01上，这个过程就叫抢占。

资源管理（cgroup树）

子系统（subsystem）实际上是cgroup对进程组进行资源控制的具体体现。子系统具有多种类型，每个类型的子系统都代表一种系统资源，比如CPU、memory等。当创建一个cgroup实例时，必须至少指定一种子系统。也就是说，这个新建的进程组在访问子系统对应的系统资源时就有了一些限制。

1. 系统中第一个被创建的cgroup被称为root cgroup，也就是cgroup树的根，该cgroup的成员包含系统中所有的进程。
2. 一个子系统只能位于一个层级中。
3. 每个层级中可以关联多个子系统。
4. 一个进程可以位于不同层级的cgroup中。
5. 一个进程创建了子进程后，该子进程默认为父进程所在cgroup的成员。子进程被创建后，继承父进程的cgroup，但是后续可根据需求将子进程移动到其他cgroup中。

Cgroup自身通过文件系统的形式在内核中实现，通过对子系统配置文件的读写即可完成对进程组资源的控制。不过，cgroup对各种资源的实际控制则分布到整个内核代码中。