背景

在全文检索的场景下，经常会有text类型的字段存储的数据量比较大，比如一个pdf文档或者是一本书的内容，可能会有几兆，几十兆，上百兆的大小，单个字段的内容过大，会对集群性能以及稳定性造成比较大的影响，因此本文档针对该场景给出优化建议。

背景

最近打算自己写一个运维管理平台，给我们内部使用，对于一个运维+后端程序员来说，写前端无疑是最大的挑战了，前端的知识栈真是庞大又杂乱，只掌握了最基础的html+css+js来说是远远不够的，前端发展了这么几十年，每一个领域都有一大堆的标准、组件、框架，比如css有less、sass等扩展，js领域又有react, vue等框架，还有typescript这种带类型的js，光ts的语法就可以复杂到令人发指，此外，还有很多现成的ui库，像阿里的antd，国外的mui，本以为react就已经是学习的终点了，但是还有umi这种基于react的前端框架，这还没完，还有再上一层的基于umi的antd pro框架，一层接一层，而且很多公司还在热衷于创造新的框架，这些各个方面各个维度的框架组件，多到让新踏入这个领域的小白无所适从。然而虽然学习成本增加了，但是这种越来越上层的框架组件，是无数前辈大佬的经验总结，能够让前端开发变得快速高效标准，尤其是对我这种小白来说，遵循这些优秀的框架标准，就可以继承这些经验，少走很多弯路，专注于做业务逻辑的开发。

社区目标

每个Release，社区都会定义几个社区目标，期望所有项目能够实现，这有利于对OpenStack下众多的项目能够有统一整体性，而不是各自发展各自的。OpenStack 从Ussuir到Victoria到Wallaby版本，社区定义了如下几个社区目标：

• Drop Python 2.7 Support
• Migrate RBAC Policy Format from JSON to YAML
• Migrate from oslo.rootwrap to oslo.privsep

社区目标

每个Release，社区都会定义几个社区目标，期望所有项目能够实现，这有利于对OpenStack下众多的项目能够有统一整体性，而不是各自发展各自的。OpenStack Stein到Train版本，社区定义了如下几个社区目标：

在CSI之前，Kubernetes本身就内置了很多插件去对接第三方存储，如果内置插件不满足需求，还可以通过FlexVolume机制，去编写自己的存储插件，然后被动态的加载到Kubernetes中，也就是说Kubernetes并不存在像对接容器运行时那种代码侵入性不好维护的问题，那为什么还要再制定一套CSI机制去对接第三方存储呢？其实CSI是一个更通用的存储对接方案，它不仅仅是针对Kubernetes的，而是针对所有的容器编排系统，比如Mesos也支持CSI，而且CSI是通过RPC机制进行交互的，跟语言无关，这样就给存储厂商带来极大的便利，写一次CSI插件，就可以适配到各种容器编排系统，不用为每种容器编排系统单独开发存储插件，这在CSI协议的目标中做了清晰的描述：

CNI简介

这里说Kubelet CNI，其实说法有些不准确，在Kubernetes Kubelet机制概述中就介绍过，Kubelet并没有直接跟CNI交互，而是通过容器运行时跟外部网络进行交互的，换句话说，CNI解决的是容器网络插件化的问题，跟Kubernetes这种容器编排系统并没有直接关系，但是有很多文章都说Kubelet支持了CNI，包括Kubernets官方的文档Network Plugins，其实这里是特指的Docker，因为Docker本身并不支持CNI，kubelet将对Docker网络环境的创建和删除，通过CNI的方式，放在了dockershim中，如果Kubernetes移除了对Docker的支持，就会移除dockershim，那么kubelet对CNI的支持也就会移除，这样两者就完全没有关系了。

CRI机制简介

CRI机制早在2016年的1.5版本就发布出来了，官方在这篇博文中做了介绍，引入CRI的目的是为了让Kubernetes能够对接多种Container Runtime，而不仅限于Docker这一种。我们知道Docker曾经是容器领域的王者，它的出现开启了容器化时代，紧随其后，又出了很多种其他的容器技术，并且随着容器技术的流行，自然而然产生了对容器编排的需求，于是又涌现了一批容器编排的技术，而Kubernetes就是其中的佼佼者，凭借其强大的社区力量和先进的设计理念，很快独领风骚，在众多竞争者中脱颖而出。

距离上一篇文章，已经过去了将近9个月的时间，2021年第一篇文章，竟然是到8月份了，真没想到这个kubelet竟然拖了我这么长时间。研究api以及scheduler的日夜还历历在目，不知不觉就过了这么长时间，现在突然写起来，恍如隔世的感觉，这一方面说明kubelet相比其他组件确实要更复杂一些，另一方面说明最近这一段时间我有些懈怠了，感觉有50%的时间在忙其他事情，25%的时间在研究kubelet，然后25%的时间在懈怠。不过还好，经过这么长时间断断续续的研究，记了很多笔记，梳理清楚了其大致脉络，对kubelet有了一个比较全面的认知，尤其是跟框架有关的，比如CRI，CNI，CSI等各种Plugin机制，知道了这些框架的原理，不论是做插件开发还是运维，都能够按图索骥，快速找到问题所在，然后再深入到具体的细节中。

简介

在Kubernetes Scheduler机制概览中就介绍过Scheduling Framework这个新的调度框架，它通过Plugins以及Extension Points的方式对调度框架进行了重构，通过在各个预定义的扩展点，插入Plugin的方式，扩展Scheduler的功能，核心的调度算法逻辑，也都放到了Plugin中，如果默认的调度器中的Plugin不能满足需求，可以自己写插件，但是要重新编译代码。

背景

在Kubernetes Scheduler机制概览中就介绍过Cache的作用，它的主要作用是加速调度过程中查询pod和node等信息的速度，此外，还有Snapshot机制，即为了保持调度时数据的一致性，对缓存打的快照。