目录

1、创建一个pod的工作流程:

2、Pod中影响调度的主要属性

调度图

资源限制:

写资源限制需要注意的问题:


1、创建一个pod的工作流程:

    Kubernetes基于list-watch机制的控制器架构,实现组件间交互的解耦。 其他组件监控自己负责的资源,当这些资源发生变化时,kubeapiserver会通知这些组件,这个过程类似于发布与订阅。
流程图
当用户用kubectl创建容器时,是kubectl向apiserver发送一个创建pod的请求,
apiserver会将数据放入etcd存储。scheduler收到未绑定pod资源,通过自身调度算法选择一个合适的node进行绑定,然后响应给apiserver。
kubelet收到分配到自己节点上pod,调用docker api创建容器,然后将容器状态响应给apiserver
controller-manager是负责控制deployment的,而上面例子是直接创建pod,所以不涉及这个组件

2、Pod中影响调度的主要属性

调度图

资源限制:

在默认不加资源限制的前提下,一个pod可以使用宿主机的全部资源,这也意味着,当某个pod有一段时间所需资源飙升时,可能会拖垮宿主机,就此情况,k8s在cpu与内存方面对pod做了可限制
容器资源限制(CPU单位:可以写m也可以写浮点数,例如0.5=500m,1=1000m): 
• resources.limits.cpu 
• resources.limits.memory 
容器使用的最小资源需求,作为容器调度时资 源分配的依据: 
• resources.requests.cpu 
• resources.requests.memory
例如以下yaml,即是给一个nginx设置了最大1cpu1Gi最小0.7cpu700Mi,在一般设置中,最小在哪用资源应该是最大占用资源的百分之七十即可
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
    run: pod2
  name: pod-limits
spec:
  containers:
  - image: nginx
    name: web
    resources:
      limits:
        cpu: 1
        memory: 1Gi
      requests:
        cpu: 0.7
        memory: 700Mi

写资源限制需要注意的问题:

      当你写的最大资源使用量大于你宿主机实际资源大小的时候。依旧可以创建成功,但限制无效,没有意义。即limits建议不能超出宿主机配置,否则没意义了,至少要低于宿主机配置的20%
     requests必须小于或等于limits,否则不可被创建成功
       k8s会根据requests的值去查找能满足该值的node进行调度,如果不满足,pod处于未分配创建。即当你最小资源限制大于现有各节点的资源,则pod会处于pending状态,pod无法被分配运行
       requests决定了一个节点分配的pod数量,所以不要设置太大,否则会造成node资源浪费,即跑的pod少,实际负载很低
Logo

开源、云原生的融合云平台

更多推荐