Kubelet

CNI (Container Network Interface)

CNI 定义了实现容器之间网络连通性和释放网络资源等相关操作的接口规范。

CSI (Container Storage Interface)

CSI 的设计思想是将存储管理和容器编排系统解耦，使得新的存储系统可以通过实现一组标准化的接口来与 Kubernetes 进行集成，而无需修改 Kubernetes 的核心代码。

CRI

容器运行接口 Container Runtime Interface (CRI): a plugin interface which enables kubelet to use a wide variety of container runtimes, without the need to recompile. CRI consists of a protocol buffers and gRPC API, and libraries, with additional specifications and tools under active development.

CR

容器运行时 Container Runtime(CR): 它负责拉取并运行容器镜像。

CR: Docker

Docker曾是流行的容器运行时。常见的容器运行时还有containerd 和 CRI-O等。

Docker的优缺点分析
优点：

• 快：容器的启停、重启以秒或毫秒为单位。
• 敏捷： 像虚拟机一样敏捷。
• 轻量：一台服务器可以部署100~1000个container。

Module: WebAssembly

它相对于容器体积更小、速度更快、安全性更强和可移植性更高。

WebAssembly与Container比较

简介
github

CR: Containerd

Ctr和CriCtl的区别

• Ctr是Containerd自带的CLI命令行工具
• Crictl是k8s中CRI(容器运行时接口)的客户端，k8s使用该客户端和containerd进行交互。

# 查看运行的容器
ctr task ls 
ctr container ls
crictl ls
# 查看镜像
ctr image ls
crictl images
# 查看容器日志
ctr 没有
crictl logs
# 查看容器数据信息
ctr container info
crictl inspect
# 查看容器资源
crictl stats
# 启动、关闭已有的容器
ctr task start/kill
crictl start/stop
# 运行一个新的容器
ctr run
crictl运行的最小单元为pod
# 修改镜像标签
ctr image tag
# 创建一个新的容器
ctr container create
crictl create
# 导入镜像
ctr image import
# 导出镜像
ctr image export
# 删除容器
ctr container rm
crictl rm
# 删除镜像
ctr image rm 
crictl rmi 
# 拉取镜像
ctr image pull
crictl pull
# 推送镜像
ctr image push

CR: CRI-O

Pod生命周期

• Pending：挂起。Pod已被Kubernetes系统接受，但有一个或者多个容器镜像尚未创建。等待时间包括调度Pod的时间和通过网络下载镜像的时间，这可能需要花点时间。
• Running: 运行中。该Pod已经绑定到了一个节点上，Pod中所用的容器都已被创建（而非运行）。至少有一个容器正在运行，或者正处于启动或重启状态。
• Succeeded: 成功。Pod中的所用容器都被成功终止，并且不会再重启。
• Failed: 失败。Pod中的所用容器都已终止了，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或者被系统终止。
• Unknown: 未知。因为某些原因无法取得Pod的状态，通常是因为与Pod的所在主机通信失败。

PodConditions

• PodScheduled: Pod已经被调度到某节点。
• ContainersReady: Pod中所有容器都已就绪。
• Initialized: 所有的init容器都已成功完成。
• Ready: Pod可以为请求提供服务，并且应该被添加到对应服务的负载均衡池中。

容器状态

• Waiting: 此状态的容器仍在运行它完成启动所需要的操作：例如，从某个容器镜像仓库拉取容器镜像，或者向容器应用Secret数据等等。当你使用kubectl来查询包含Waiting状态的容器的Pod时，其中的Reason字段给出了容器处于等待状态的原因。
• Running: 此状态表明容器正在执行状态并且没有问题发生。如果配置了postStart回调，那么该回调已经执行且已完成。你可以使用kubelet来查询包含Running状态的容器Pod，其中的Reason字段给出了容器进入Running状态的信息。
• Terminated: 此状态的容器已经开始执行并且或者正常结束或者因为某些原因失败。你可以使用kubelet来查询包含Terminated状态的容器Pod，其中Reason字段给出了容器进入此状态的原因、退出代码以及容器执行期间的起止时间。

Pod容器组成

• Infra/Pause Container: 基础容器。Pod中所有容器的父容器，为其他容器提供共享的命名空间和网络空间。
  • 用户不可见，无需感知。
  • kubelet的启动命令选项中，通过"–pod-infra-container-image=registry.aliyuncs.com/google_containers/pause:3.7"指定基础容器。
  • 启动PID命名空间，它在每个Pod中都作为PID为1的进程，并回收僵尸进程。
• Init Containers: 初始化容器。一般用于服务等待处理以及注册Pod信息等。
  • 先于业务容器开始运行。
  • 顺序执行，执行成功退出（exit 0），全部执行成功后开始启动业务容器。
• Containers: 业务容器。
  • 并行启动，启动成功后一直Running。

生命周期的流程

• 用户通过UI或CLI提交一个Pod创建请求给Kubernetes集群的控制面（HTTP:8080/HTTPS:6443）。
• API Server接收到请求后进行验证身份和鉴权，写入存储系统etcd。
• Scheduler通过API Server的watch，或者叫做notification的机制得到这个信息。
• Scheduler接收到Pod创建请求后，会根据集群各节点的内存状态进行一次调度决策，
• Scheduler在完成调度之后，它会向API Server返回可调度的节点的信息。
• API Server接收到这次操作之后，会把调度决策的结果再次写到etcd，然后通知相应的节点去真正的执行Pod的启动。
• 相应节点的kubelet接收到创建Pod的请求后通过调用Container runtime去配置容器及其运行环境，并调度Storage Plugin进行容器存储的配置，并调度Network Plugin进行容器网络的配置。

如果容器中的进程能够在遇到问题或者不健康的情况下自行崩溃，kubelet将根据Pod的restartPolicy自动执行修复操作。

Kube-Proxy

ipvs 和 iptables的区别

iptables和ipvs都是基于Netfilter实现的，iptables是为防火墙而设计的；ipvs是为高性能负载设计的，并且使用更高效的数据结构（Hash表），允许几乎无限的规模扩张。

• 为大型集群提供了更好的可扩展性和性能
• 支持比iptables更复杂的负载均衡算法（最小负载、最少链接、加权等）
• 支持服务器健康检查和连接重试等功能。
• 可以动态修改ipset的集合，即使iptables的规则正在使用这个集合。