OCI Image Format Spec 解读
在 OCI 标准中，为描述 OCI Image规范包含了 image manifest,image index(optional),filesystem layers集合以及 configuration配置。通过如上描述使得对于 image 在异构场景下能够被构建、传输且可执行变的通用化。
站在上层应用的视角， image manifest 包含内容可寻址且解压可运行的filesystem layer。而 image configuration 包含例如应用参数、环境变量等。image index 则是对系列 manifest 和 descriptors 的描述指向，用于对不同镜像的补充，一般来说是对不同架构或者不同属性的描述。
Specification 解读OCI Image Media TypesOCI Image Media Types 定义了如下的格式：
application/vnd.oci.descriptor.v1+json: Content Descriptor
application/vnd.oci.layout.header.v1+json: OCI Layo ...
containerd存储驱动一探究竟
番外篇，简单讲讲容器镜像的存储驱动，为简单演示，以 overlay 存储驱动为例。
可以通过 Linux kennel 查看 Overlay Filesystem 的相关明细介绍，以下内容主要以演示为主，加深理解，且此内容的理解是对后续 Containerd 中 Snapshotter Service`` 和 DiffApplier Service` 必备的基础。
模拟[1-1] 模拟已经存在一个 layer 包含单一文件 file_a 的 snapshot。
12mkdir -p /tmp/a/1/fstouch /tmp/a/1/fs/file_a
[1-2] 如若这个时候接收到再创建 layer 的请求，具体内容如下：
12mkdir -p /tmp/a/2/fsmkdir -p /tmp/a/2/workdir
[1-3] 此时存储驱动 overlay 将进行如下处理，且将最终序列化好的 mount 进行返回，表意如下：
123456Type: OverlaySource: OverlayOptions: lowerdir=/tmp/a& ...
NRI:下一代节点细粒度资源控制方案
转载自 NRI:下一代节点细粒度资源控制方案
相关PR
KubeCon-NA-2022-NRI-presentation.pdf
背景为了满足不同业务应用场景的需求，特别是在在线任务与离线任务混布的场景下，在提高资源利用率的同时，也要保证延迟敏感服务可以得到充分的资源保证，这就需要Kubernetes提供更加细粒度的资源管理功能，增强容器的隔离性，减少容器之间的互相干扰。例如，CPU编排，内存分层，缓存管理，IO管理等。目前有很多方案，但是都有其一定的局限性。
截至目前，Kubernetes并没有提供一个非常完善的资源管理方案，很多Kubernetes周边的开源项目通过一些自己的方式修改Pod的部署和管理流程，实现资源分配的细粒度管理。例如CRI-RM，Koordinator，Crane等项目。
这些项目对Kubernetes创建和更新Pod的流程的优化可以大致分为两种模式，一种是 Proxy模式，一种是Standalone模式。
在目前的K8s架构中，如图a，Kubelet通过调用CRI兼容的容器运行时创建和管理Pod。CRI Runtime再通过调用OCI兼容的Low-lev ...
从0构建web测试框架
最近在做项目设计的时候，考虑到实际项目与传统意义上的测试有些现实的差距。目前CI部分并不是对每次的测试环境都有一个新环境的准备，在实际的自动化测试中会糅合一部分QA人工的操作，在此背景下需要在自动化测试代码层面中控制，需要注意的是，e2e测试最好的设计还是能够有个干净的单独环境用于随时拉起与清除资源，以避免不要的脏数据保证与实际功能迭代相匹配。
鉴于以上的上下文，顺便设计了个简单的可扩展的测试框架，便于项目集成。
功能拆分[package]core 设计关键元素拆分：
group：以功能组为最上层测试用例注册维度
1234567891011type BaseGroup struct { // group name Name string // group description Desc string // Reqs list of features interfaces Reqs []req.Req // rest api client Client *restclient.Client}
group 抽象接口的设计:
...
containerd源码分析-[2]cri插件
containerd-v1.7.0此篇正式开启插件启用流程分析。
源码分析初始化入口pkg/cri/cri.go:42
1234567891011121314151617181920// Register CRI service pluginfunc init() { // 默认配置 config := criconfig.DefaultConfig() // 必要信息注册 plugin.Register(&plugin.Registration{ // GRPC Plugin Type: plugin.GRPCPlugin, ID: "cri", Config: &config, // Requires 插件，对于顶层 `app.Run()` 中 Requires: []plugin.Type{ plugin.EventPlugin, plugin.ServicePlugin, plugin.NRIApiPlugin, }, ...
containerd源码分析-[1]启动流程
根据官网containerd.io的简介，可以得知 containerd 作为容器的生命周期管理。其在整个容器生态的组织架构中的职责如下:。
如下分析 containerd 的启动流程
基于 containerd-v1.7.0 版本分析
入口代码其实比较简单，具体如下:
12345678// cmd/containerd/main.gofunc main() { app := command.App() if err := app.Run(os.Args); err != nil { fmt.Fprintf(os.Stderr, "containerd: %s\n", err) os.Exit(1) }}
command.App 关键逻辑如下：
flags 构造
注册插件，重点在于 plugin.Init 初始化构造
启动 TCPServer、GCPServer、TTRPCServer
流程图大纲如下：
后续会结合具体的插件进行明细示例分析。
SR-IOV VF 网卡命名问题记录
SR-IOV VF 网卡命名问题简单记录下最近工作项目中通过 KVM + SR-IOV VF 来构建虚拟网关节点，在资源实施规划部署时需要对每个网络平面的网卡进行统一化的命名，具体形如Domain Node Name 和 Admin Node Name 网卡都有统一的命名规范。
通过业务脚本实现对应网卡及 Slot 配置文件通过 virsh atach 网卡。eg:
1virsh attach-device ${NODE_NAME} ${XML_CONFIG} --config
为了保证生效识别到，最好通过 virsh shutdown ${NODE_NAME} 及 virsh start ${NODE_NAME} 来拉起网卡。由于时间问题，具体的环境已经没有这里就不做贴图了。
这个时候通过 ip a 能够发现识别到网卡，此时借鉴如下 都不行。
通过自己的理解和调研，其实以上介绍的就是通过对 /etc/udev/rules.d 进行命名配置让 kennel 在系统启动引导阶段进行网卡重命名。
后面通过 ...
kubebuilder 去 kube-rbac-proxy 体验
安利一波广告，欢迎大家试用目前本人 maintain 的EMQX Kubernete Operator
最近在社区中接到用户反馈Release manifests has broken metrics描述如下：使用 release-1.1.5 版本，看到对于目前对于 Operatlr 的 metrics 保护机制是采用的 kube-rbac-proxy，此处相关的内容也可以通过查看 kubebuilder官方文档进行具体的阅读。
根据 Issue 反馈其实很快能定位到应该是 Service 没有匹配的 Container Port,看下 release-1.1.5 中的代码，如下可以看到 emqx-operator-controller-manager-metrics-service 中的内容如下：
1234567891011121314apiVersion: v1kind: Servicemetadata: labels: control-plane: controller-manager name: emqx-operator-controller-manager-met ...
通过 OPA 运行 Kubernetes Pod Security Policy
翻译自Kubernetes Pod Security Policies with Open Policy Agent
Kubernetes是当今云原生生态系统中最流行的容器编排平台。因此，Kubernetes的安全性也是一个越来越令人感兴趣和关注的领域。
在这篇博文中，首先我将讨论Pod安全策略准入控制器。然后我们将看到Open Policy Agent如何实现Pod安全策略。事实上，在Kubecon + CloudNaticeCon North America 2019的Kubernetes SIG Auth期间，Open Policy Agent / Gatekeeper被提及为Pod安全策略的潜在替代品。
首先，简要了解一下容器、安全和准入控制器。
容器和安全概述Kubernetes 中的容器是什么？容器是轻量级的，可移植的，易于管理。在同一主机上运行的容器没有单独的物理/虚拟机。换句话说，容器共享资源、硬件和它们所运行的主机的操作系统内核。因此，使用者围绕哪些进程可以在容器内运行、这些进程有哪些权限、容器是否允许权限升级、使用哪些镜像等问题拥有适当的安全性变得非常重要。
k ...
USING KUBE-RBAC-PROXY TO SECURE KUBERNETES WORKLOADS
翻译自USING KUBE-RBAC-PROXY TO SECURE KUBERNETES WORKLOADS
在使用Prometheus监控Kubernetes集群时，我注意到一个反复出现的问题：Prometheus检索的指标可能包含敏感信息（例如，Prometheus节点导出器暴露了主机的内核版本），潜在的入侵者可能利用这些信息在各自的Kubernetes集群中钻营。所以我问自己一个问题。如何认证和授权来自Prometheus的请求，以便Prometheus（只有Prometheus）能够从Pod中运行的应用程序中检索指标？
在Prometheus中验证和授权指标端点的默认答案是使用TLS客户端证书，然而，由于发行、验证和轮换客户端证书会变得相当复杂，因此，Prometheus请求在大多数情况下根本没有经过验证和授权。
我建立了kube-rbac-proxy，这是一个针对单一上游的小型HTTP代理，可以使用SubjectAccessReviews对Kubernetes API执行RBAC授权。在这篇文章中，我想解释一下，它是如何使用Kubernetes RBAC来完成这个任务的 ...