serverless、k8s、container相关概念梳理
本文是使用ZhihuOnVSCode 创建和发布的。在为我的毕业项目进行初步研究时，我遇到了大量新概念，尤其是与无服务器相关的概念。
在解决这些概念的过程中，我发现了Serverless框架、k8s和容器之间的联系。
这是我理解这些概念的知识。
Serverless框架是最顶层的概念，它提供了RESTful API。
用户通过API提交要在框架中执行的云函数。
然后框架会调度这些函数并最终将它们放入容器中。
为了保证云函数之间的消息传递和相互调用，Serverless框架必须实现事件模型。
同时，他们还必须处理云功能的身份验证和自动扩展等关键功能。
通常，无服务器框架是基于k8（Kubernetes）实现的。
目前流行的无服务器框架包括 Knative（由 Google 主导）和 OpenWhisk（由 IBM 发起，现由 Apache 管理）。
个人认为Knative更有发展潜力。
k8s是一个容器编排管理工具，负责容器调度。
采用集中式设计，通过master管理多个节点。
可以通过kubectl命令来控制集群，在节点上启动kublet命令，在master上使用kubeadm命令启动控制平面。
CRI（ContainerRuntimeInterface）负责管理容器。
它管理容器镜像的分发、存储、快照和网络。
CRI 依赖 OCI（OpenContainerInitiative）来创建容器。
主要的 CRI 包括 Containerd 和 CRI-O，可以通过 crictl 命令行工具进行管理。
ctr工具还可以管理Containerd。
OCI（OpenContainerInitiative）负责创建和删除容器。
它分为两类：本机和沙盒。
流行的本地存储库包括：crio、runc、kata-containers。
Sandboxedruntime 包括：runc-sandbox、kata-containers。
NativeRuntime仅影响容器创建和删除阶段，一旦容器启动就不再影响性能。
沙盒运行时会影响整个容器生命周期的性能。
在探索Serverless、K8S和容器概念的过程中，关键是要了解它们的定位、功能以及如何在云计算领域协同工作。
这些概念为在云中构建灵活、高效和自动化的应用程序提供了坚实的基础。
k8s运维专家必备之containerd根下的run目录满了导致容器创建失败 源码排查
如何解决 Kubernetes 运维人员经常遇到的 Containerd 根目录下的 /run 目录已满导致容器创建失败的问题？ 背景：运维专家经常需要监控集群事件以确保服务正常运行。在某种情况下，我们发现由于 /run 目录空间不足，创建已停止的容器失败。
/run目录是一个临时文件系统，主要用于存储容器运行相关的临时数据，如socket、PID、运行状态信息等。
分析：/run目录的使用与Containerd密切相关。
正如 Containerd 官方文档中详细介绍的，该目录主要用于存储容器持久性和运行时数据。
其中，state目录值得特别关注，因为它包含运行时的临时数据。
通过测试发现状态目录使用率非常高，尤其是与运行容器相关的数据。
深入分析：深入探究/run目录满的原因，发现可能与Probe Pod执行错误有关。
分析log.json文件发现，特定容器的日志文件占用了3.2G空间，已成为/run分区使用的主要来源。
检查v2.taskIo中所有容器的日志文件大小，我们发现许多文件的大小相对较小，这是出乎意料的，这表明问题可能出在为特定容器创建或写入日志的方式上。
源码排查：通过查看containerd、runc、go-runc的源码，特别是任务目录下logging.json路径相关的部分，可以更深入的了解问题。
在这个过程中，发现runc的日志管理机制会导致某些日志难以在kubelet端完整显示，这可能是影响日志文件标志大小的一个主要因素。
总结及解决方案：排查结果表明，问题的根本原因可能是特定容器的日志创建或管理方式导致日志文件过大，占用大量空间。
要解决此问题，应采取以下措施： 01. 避免在没有 istio 环境的集群中使用 exec 探针。
探测器可能会导致不必要的日志创建并占用额外的空间。
通过调整容器设计或监控策略，可以最大限度地减少此类问题的发生。
k8s启用docker后的使用
K8s1.24版本忽略了docker-shim，简化了kubelet集成以使其与其他容器解决方案兼容。底层基于容器，优化了通信链，提升了K8的性能。
如果你想在 K8s 中继续使用 docker，则需要安装 cri-docker 适配器，但这会降低性能。
替代方案是 crictl、ctr、nerdctl。
crictl专门用于调试K8集群，对其他容器没有影响。
ctr 是 Containerd 专用工具，不使用 Containerd 加速器。
Nerdctl是一个包含容器的子项目客户端，使用加速器配置来提高镜像下载速度，并且符合docker命令语法。
下载nerdctl请访问github.com/containerd/nerdctl，提供简化版和完整版安装包。
nerdctl不仅复制了docker的功能，还实现了延迟拖拽、图片加密（imgcrypt）等功能。
StargzSnapshotter容器用于执行延迟签出并按需获取图像文件。
当你使用nerdctl启动容器服务时，服务器会创建一个虚拟网卡。
容器网络防火墙规则的优先级高于服务器设置。
即使防火墙开启，也无法完全控制端口的访问。
可以使用类似于docker的host网络模式（-net=host），但不支持端口映射。
安装nerdctl的步骤如下：下载并解压安装包，命名并推送镜像，安装buildkit以支持镜像创建。
构建工具包可以在 github.com/moby/buildkit 找到并下载 systemd 启动文件配置。
Buildkit 需要两个配置文件：/usr/lib/systemd/system/buildkit.socket 和 /usr/lib/systemd/system/buildkit.service。
安装后，请确保在未指定命名空间（-n）时，crictl 和 kubelet 无法识别 nerdctl。
镜像构建参数包括： -t 指定镜像名称，表示 。
到当前Dockerfile目录，-f指定Dockerfile路径，--no-cache表示不使用缓存。
此过程的重点是正确配置启动文件、执行繁重的启动测试以及在构建时了解关键参数。
