gydtep

PVC/PV模式解耦了存储资源与节点资源，即由PVC/PV定义的存储资源独立于节点资源，通过动态绑定方式随工作负载在节点资源间迁移。具体细节依赖于云厂商提供的存储插件的实现方式。

gydtep

Service实现了服务端自动发现机制，即提供应用服务的一组Pod可以通过同一个服务域名访问地址对外提供服务，Pod的新增或者销毁不会影响该服务整体服务性能。工作负载通过Service绑定了一个虚拟IP以及端口，对于Pod分配的节点资源并不敏感，解耦了Service与节点网络资源，使得整个集群具备负载迁移，故障自愈的能力。

gydtep

Ingress与Service对象不同，是K8S对集群外部提供服务的一种资源对象。在K8S出现之前，我们对于负载与流量控制，多是采用Nginx反向代理和负载均衡，横向扩展服务端处理负载的能力。Ingress本质上就是一个NginxPod，这个Pod也是通过Service对象暴露出来，基于LoadBalancer模式对外提供反向代理与负载均衡。

gydtep

Ingress很像一个集群的路由器和访问入口，通过在ingress配置路由规则绑定工作负载与对应域名解析路径，达到只使用一个外部IP就能将多个集群内部的服务暴露出来，从而节省IP资源。

gydtep

Scheduler可以调度的资源配置是指节点可分配资源，也称节点容量。它的计算方式为：
Allocatable Capacity= Node Capacity - Kube-Reserved - System-Reserved
Allocatable Capacity为Scheduler可为应用服务Pod分配的节点资源

Node Capacity为节点资源总量

gydtep

Kube-Reserved为K8S的后台进程预留资源，例如Kubelet，CRI，CNI等组件

System-Reserved为节点的操作系统后台进程预留资源，例如sshd, udev等

gydtep

Limits定义了容器资源使用的上限，Requests定义了容器资源初始化配置，一般启动容器时按照requests分配资源。容器运行时，资源消耗一般比requests分配的少，

gydtep

这种金字塔型的资源分配方式存在着不小的资源碎片的情况。当工作负载竞争资源时，K8S提供了三种级别的服务质量保证。
Best-Effort：Pod不设置requests和limits。这种Pod的QOS优先级最低，当节点资源调度不足或者竞争冲突时，优先销毁或迁移该类Pod。

gydtep

Burstable：Pod设置requests和limits，但是requests小于limits。这种Pod具有最低的资源保证，即当节点资源竞争，不再有Best-Effort这种Pod时，优先销毁或迁移该类Pod。

gydtep

Pipcook 通过提供通用的模型能力，比如图片分类、目标检测、文本分类等，减少了在 imgcook 中从开发到上线这些模型的门槛，使得如此多的底层识别能力也具备快速迭代的可能性。imgcook 全链路的识别能力，如组件识别、Icon 识别、字段语义识别等都是基于 Pipcook 训练。