目录
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少，实际负载很低
