红红的晚霞

今日鸡汤：

山本耀司：
自己，这个东西，是看不见的，撞上一些别的什么，反弹回来，才会了解自己。

现在的你是什么样的呢？

使用锁保护共享数据

锁的原理：任何时间都只能有一个线程持有锁，只有持有锁的线程才能访问被锁保护的资源。

使用锁的代价？

1. 加锁和解锁都需要CPU时间，性能损失。锁等待是线程阻塞的，会降低程序性能。
2. 锁使用不当会死锁。

什么时候需要锁？
只有在1）并发环境下，2）共享资源不支持并发访问，或者说3）并发访问共享资源会导致系统错误的情况下，才需要锁。

锁的用法？
1） 访问共享资源前获取锁；
2）带锁访问共享资源；
3）释放锁。

死锁的原因？

1. 获取了锁之后没有释放。
2. 锁重入时这把锁不是可重入锁。
3. 多把锁互相锁住。

如何避免死锁？

1. 避免滥用锁；
2. 对同一个锁的加锁和解锁在同一个方法中；
3. 避免同时持有多把锁；
4. 解锁的顺序要和加锁顺序相反；

读写锁是什么？
所谓读写锁，即是读锁和写锁的统称，它是两种锁，但放在同一个对象里，通过两个方法分别获取。适用场景是读多写少的业务，比如缓存。
用法很简单，三原则：读读共享、读写互斥、写写互斥。换种说法：读锁是共享的，读锁允许其他线程的读操作，而写锁是互斥的，写锁不允许其他线程的读写操作。

Kubenetes和CRI-O

当容器启动时会发生什么？

1. 基于image创建出来一个容器；
2. 容器运行时从registry下载镜像；
3. 运行时将层次化的镜像解压到支持Copy on Write(CoW)的文件系统中；
4. 运行时实际执行容器。

什么是容器运行时(Container Runtime, CR)?
Kubenetes中负责管理镜像和容器的生命周期，Kubelet通过CRI与容器运行时交互，来管理镜像和容器。

什么是容器运行时接口(Container Runtime Interface, CRI)?
CRI是一个插件接口，使Kubelet能使用不同的OCI兼容容器运行时，当不用Docker换别的CR时不用重新编译Kubenetes，类似于JDBC。CRI包含Protocol Buffers、gRPC API、运行库支持以及开发中的标准规范和工具。

Kubelet使用gRPC框架通过Socket与CR进行通信。
Pod 由一组应用容器构成，包含共有环境和资源约束。在CRI里，该环境称为PodSandbox。

Open Container initiative (OCI)规定了什么?
OCI主要负责container runtime标准的制定和runc的开发。

• 镜像规范（OCI 1.0 images）: 定义了容器镜像的内容
• 运行时规范（CRI 1.0）：定义了容器的“配置、运行环境和生命周期”
• 容器网络接口（CNI）：描述了如何在容器内部配置网络接口

什么是CRI-O?
OCI,CRI,CRI-O,Containerd 名词解释
CRI-O是为了解决Docker平台太庞杂而出现的，它构建了一个更简单的运行时，为Kubenetes提供稳定可靠的容器运行时是CRI-O的唯一任务。

CRI-O使Kubernetes无需大量工具和代码即可直接运行容器。
1） 当 Kubernetes 需要运行容器时，它会与 CRI-O 进行通信，CRI-O 守护程序与 runc（或另一个符合 OCI 标准的运行时）一起启动容器。
2）当 Kubernetes 需要停止容器时，CRI-O 会来处理，它只是在幕后管理 Linux 容器，以便用户不需要担心这个关键的容器编排。

接下来会在ZCX里试一下build CRI-O，大神保佑，坑少少的好。