CRI

简介

Kubernetes 运行时是支持容器运行时接口（CRI） 的高级容器运行时，CRI 在 Kubernetes 1.5 中引入，并且充当 kubelet 和容器运行时之间的桥梁，并且希望像 Docker、containerd 这样的高级容器运行时实现 CRI 接口。

预期容器运行时支持镜像管理并且支持 Kubernetes Pod，并管理各个容器，所以从要求中也能看出来 Kubernetes 运行时要求的必须是 high-level 运行时，low-level 运行时缺少必要的功能。

为了了解更多关于 CRI 的知识，有必要了解 Kubernetes 的架构，Kubelet 是一个位于 Kubernetes 集群中每个工作节点上的代理，Kubelet 负责管理节点的容器工作负载，在实际运行中，kubelet 使用 CRI 在同一节点上运行的容器运行时进行通信，有个 CRI 这个抽象层，我们可以随时将实际的容器运行时切换到其他实现了 CRI 接口的容器运行时，而不必局限某一种容器运行时，也不必内置于 kubelet 中。

kubernetes 中关于 CRI 架构图

High-level 容器运行时

简介

High-level 运行时相对于 Low-level 运行时处于较上层的位置，low-level 运行时负责实际运行容器，high-level 运行时负责传输和管理容器镜像，解压镜像并且传递给 low-level 运行时来运行容器。通常 high-level 运行时提供一个守护进程和一个 API，更上层的应用可以通过他们来运行容器，将实际工作指派给 low-level 运行时或者其他 high-level 运行时。

high-level 运行时还可以提供一些 low-level 运行时的功能，但是这些功能可以让主机上的各个容器使用，例如网络名称空间的管理，运行一个容器加入另一个容器的网络名称空间。

下面这个图表示了各个组件之间的关系。

Docker、containerd、runc 关联和区别

简介

关于 Docker 是什么大家可能并不陌生，但是对于 Docker 到底怎么运行的，内部包含的组件我们可能并不是特别清楚，这里我们要先引入一个概念-容器运行时

（容器运行时 == Docker）？

传统上，计算机程序员可能将“运行时”称为程序运行时的生命周期阶段，或者是支持其执行的语言的特定实现。Java HotSpot运行时就是一个例子。后一个含义最接近“容器运行时”。容器运行时负责运行容器的所有部分，而容器实际上并未在运行程序本身。正如我们将在本系列文章中看到的那样，运行时实现了各种级别的功能，但是实际上运行容器是调用容器运行时所需的全部。

准备

已经安装运行一个 Kubernetes 集群。

安装Helm Client

本来想用一键安装脚本安装的，无奈网络太慢

所以先下载 helm 的压缩包

1
2
3
4
5
6
7

wget https://get.helm.sh/helm-v2.14.0-linux-amd64.tar.gz

# 解压
tar -zxvf helm-v2.0.0-linux-amd64.tgz

# 移动到/usr/bin目录下
mv linux-amd64/helm /usr/local/bin/helm

持续集成

基本概念

• 持续集成(Continuous Integration)：频繁地(一天多次)将代码集成到主干。让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。“持续集成并不能消除 Bug，而是让它们非常容易发现和改正。
• 持续交付(Continuous Delivery)：频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。
• 持续部署(continuous Deployment)：代码通过评审以后，自动部署到生产环境。是持续部署是持续交付的下一步，持续部署的目标是，代码在任何时刻都是可部署的，可以进入生产阶段。

持续集成有哪些优点

• 每天集成变化的代码，尽早发现风险，尽早估量软件的质量
• 流程自动化，减少重复性劳动 自动化部署工作可以解放集成、测试、部署等重复性劳动
• 保持随时部署，能快速反馈bug的修改而不是每次都需要改一段时间之后重新打包部署验证

介绍

ThreadLocal 的初衷是用来解决线程并发的时候，解决变量共享的问题，但是因为过度设计，比如弱引用、哈希碰撞等原因，导致理解难度增大，使用成本高，反而容易出现内存泄露、脏数据、共享对象更新等问题。

简要言之：往ThreadLocal中填充的变量属于当前线程，该变量对其他线程而言是隔离的

##

Fork/Join 简介

Fork/Join 框架在 JDK1.7 引入，给我的感觉主要解决类似递归类任务，分而治之，最适合的是计算密集型任务。将一个大的任务拆分成多个小的任务，多个任务之间又有一些的关联和依赖关系，并行执行提高 CPU 的使用率。

ForkJoinPool采用分治+work-stealing的思想。可以让我们很方便地将一个大任务拆散成小任务，并行地执行，提高CPU的使用率。

我们通过 Fork 和 Join 这两个单词来理解下 Fork/Join 框架，Fork 就是把一个大任务切分为若干子任务并行的执行，Join 就是合并这些子任务的执行结果，最后得到这个大任务的结果。比如计算 1+2+。。＋10000，可以分割成 10 个子任务，每个子任务分别对 1000 个数进行求和，最终汇总这 10 个子任务的结果。Fork/Join 的运行流程图如下

线程池的优势

线程使应用更加充分利用 CPU、内存、IO 等资源，但是线程的创建需要开辟虚拟机栈、本地方法栈、程序计数器等线程私有的空间会带来额外的消耗，线程销毁的时候又要回收资源再次带来额外消耗，如果频繁的出线创建和销毁线程的操作浪费了大量的资源。

所以我们才需要使用线程池，线程池可以协调多个线程，主要优势如下几点：

• 线程池管理并复用线程，控制最大并发数
• 方便实现任务线程队列的缓存策略和拒绝机制
• 实现某些和时间相关的功能，比如定时任务
• 隔离线程环境，比如交易服务和搜索服务在一台服务器上，交易线程的资源消耗明显会更大，因此可以通过配置独立的线程池，将较慢的交易服务和搜索服务隔离开，避免各服务线程互相影响。比如 Hystrix线程池隔离就可以选择使用线程池隔离的方式来解决一个服务访问暴增炸了也不会影响其他俩服务。

并发编程的问题引入

原子性

原子性这个问题，聊得最多的demo还是 i++ 问题， i++ 看起来是一步操作，其实做了两个运算，先加1再重新赋值给i；如果多个线程都会来操作这个 i++ 操作的时候就很可能会出现线程 A 执行的时候 加了1但是还没赋值，然后B又来加了个1，最后A再运行赋值操作，这也就是天天挂在嘴边上的原子性的例子了，就不给demo举例了。

可见性

可见性是指当多个线程访问同一个变量时，一个线程修改了这个变量的值，其他线程能够立即看得到修改的值，必须把这个值刷新到内存里面区让其他线程更新。

在Java中，synchronized关键字、Lock对象和volatile关键字都可以实现共享变量的可见性。关于可见性的问题，这涉及到硬件的内存模型。

有序性

volatile 关键字可以保证一定的有序性，也可以通过使用 synchronized 和 Lock 来保证有序性， synchronized 和 Lock 保证了某个时刻只有一个线程在执行同步代码，相当于是让线程顺序执行同步代码，保证了可见性。

为什么会出现有序性问题？因为指令重排序。指令重排序即只要程序的最终结果与它顺序化情况的结果相等，那么指令的执行顺序可以和代码的顺序不一致，这个过程叫指令的重排序。

JVM 能根据处理器的特性对机器指令进行重排序，使机器指令的执行能更符合 CPU 的执行特性，最大限度的发挥机器性能。

并发和并行

并发指的是某个时间段内，多任务交替处理的能力，每个CPU不可能把一个任务执行完再执行下个任务，这样很多任务就会一直处于等待状态，所以CPU有个时间片的说法，每个任务执行完时间片的时间之后就会释放CPU的资源，其他任务就会来抢占CPU的资源。

并行指的是多核CPU可以同时进行多个任务的处理，它们是在同时执行的，而不是像并发那样，并发在某一个特定的时间点其实只有一个在运行。

并发和并行都是为了尽可能块地执行完所有的任务，比如两个医生都在坐诊给病人看病这就是并行，其中一个医生，一会回答病人问题，一会给病人开药，然后又继续回答病人问题，就是并发（虽然这个时间片可能有点长）。

并发的环境下程序的封闭性被打破，出现了以下特点：

• 并发程序之间的制约关系。直接制约为一个程序需要另一个程序的处理结果，简介制约为多个程序共享资源，比如处理器、缓冲区等。
• 并发程序是断断续续的，程序需要记忆现场指令和执行点。
• 并发数合理并且CPU处理能力足够的时候，并发会提高程序运行的效率。