so2bin

资料 https://medium.com/@sanilkhurana7/understanding-the-go-scheduler-and-looking-at 1-how-it-works-e431a6daacf https://segmentfault.com/a/1190000041860912/en 结构原理 G：协程，P：processor，M：系统线程，M绑定一个P才能执行G； P的数据是控制着Go的并发能力，由环境变量GOMAXPROCESS控制数量，线程数一般不配置，但也有一个底层的函数可设置（SetMaxThreads），M默认上限是10000； P的存在是为了实现G的调度和M/G之间M:N的关系； P有一个local queue，无锁，当P的local queue无G时，会从Global queue取，此时需要用锁，而如果Global queue也无G时，会走work stealing，尝试从其它P的local queue上找G运行； G的抢占调度是基于时间片，即如果G长时间连续运行超过10ms，则会通过系统信号SIGURG强制调度该协程；...

Go1.5 标记删除(Mark and Sweep)原理 进入STW(Stop The World)阶段 遍历整个heap，排查未被引用的对象，并标记； 暂停STW 执行Sweep清除 缺点 STW会让Go程序暂停，程序出现卡顿 标记需要扫描整个heap 清除数据会产生heap碎片 Go1.8 三色标记法 + 写入屏障三色标记法原理 维护三个标记表：白色，灰色，黑色 程序初始时，所有对象标记为白色 从Root Set开发，每次只遍历一层，标记该层的对象为灰色（对象从白色表中移到灰色表） 然后，以灰色标记表开始，遍历该表中的对象，将从这些对象开始的可达到对象（走一步），标记为灰色，同时灰色表中已经遍历过的对象，标记为黑色（对象从灰色表中移到黑色表） 循环上一步，继续遍历灰色表，直到灰色表中无任何对象 剩下的白色即为需要删除的对象 上述过程，仍然需要STW，否则会出现并发导致的引用关系错乱，导致资源被错误的GC删除 写入屏障原理 三色标记被破坏的情况有两种： 一个白色对象被黑色对象引用 灰色对象与它的可达白色对象关系遭到破坏（灰色同时丢失了该白色） 谷歌提出了两个...

架构分层架构 Go的页单元大小 ：8KB，linux操作系统：4KB； 如下图所示，分了三层来管理 mcache: 每个P一个，为每个mspan额外缓存了一个，无锁； mcentral: 分了67个span，从8B-32B，细粒度锁； mheap: 全局唯一； 三类对象 tiny 微对象，<=8B，通过P的专属tinyAllocator分配，依次从：mcache tiny -> mcache span -> mcentral -> mheap -> VM分配； small 小对象，<=32KB， 依次从：mcache span -> mcentral -> mheap -> VM分配； large 大对象，>32KB，依次从：mcentral -> mheap -> VM分配；

CNCF视频清单 FederaHPA on Karmada Serverless AIGC平台 Vocalno with AI workload Dragonfly for AI model Distribution SIG kube-scheduler controller-runtime新特性 Prometheus Deep Dive containerd Prometheus高性能远程存储 多集群流量调度based on eBPF 服务网格负载均衡 k8s + RoCEv2构建AI训练集群 基于WASM部署轻量级AI服务 CubeFS with AI new with GRPC

init节点环境准备 关闭swap# 查看sudo swapon --show# 关闭sudo swapoff -a 配置其它：# sudo vim /etc/sysctl.d/k8s.conf# 添加： net.ipv4.ip_forward = 1# 导出配置containerd config default > /etc/containerd/config.toml# 修改配置[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc] ... [plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options] SystemdCgroup = true# 执行命令sudo modprobe br_netfiltersudo systemctl restart containerd 按正常流程安装完docker, containerd组件 默认安装 kubeadm初始化# 以co...

资料 kubefed v2 Kubernetes 多集群管理：Kubefed vivo Karmada实践 背景 karmada是由华为开源的云原生多集群容器编排平台，在kubernetes Federation v1, v2（kubefed）的基础上发展而来，吸取了其经验和教训，kubefed项目目前已经被放弃； 其特点是在保存原有k8s资源定义API不变的情况下，通过添加与多云应用资源编排相关的一套新的API和控制面板组件，为用户提供多云/多集群容器部署，实现扩展、高可用等目标； 如下图所示为kubefed v2接入vs时需要定义的CRD，因此接入kubefed是需要对原始k8s资源进行改造，对用户不友好：apiVersion: types.kubefed.io/v1beta1kind: FederatedVirtualServicemetadata: name: service-route namespace: defaultspec: placement: clusters: - name: cluster1 - name: clust...

资料 https://github.com/containerd/containerd/blob/main/docs/historical/design/architecture.md https://blog.frognew.com/2021/05/relearning-container-08.html https://blog.frognew.com/2021/06/relearning-container-09.html https://blog.mobyproject.org/where-are-containerds-graph-drivers-145fc9b7255 高层架构 概念联合挂载 由overlay filesystem提供的能力，支持将多个文件系统层叠加在一起，且只显示最顶层的文件和目录，OverlayFS是其实现，docker当前默认存储驱动为overlay2，就是基于该文件系统； 在contaierd中这个联合挂载的roofs视图是由snapshotter准备的snapshots； filesystem 在容器生态中，有两种类型的文件...

论文粗读：Slacker: Fast Distribution with Lazy Docker Containers阅读目标 了解docker容器启动过程的数据特性，以及slacker的设计思路，不对该存储驱动做过细了解。 介绍 开发了名为HelloBench的工具来分析57个不同的容器应用，分析容器启动过程的IO数据特性和镜像可压缩性，得出结论：在容器的启动过程中，镜像的拉取占76%的时间，但仅读了6.4%的数据。 基于这些发现，作者设计开发了一种新的docker存储驱动：Slacker，可以用于加速容器的启动速度。 Slacker采用中心化存储思路，所有的docker workers和registries都共享这些数据。 Container的启动主要慢在文件系统的瓶颈，相对而言，network, compute, memory资源更快且简单，容器应用需要一个完整的初始化文件系统，包括应用binary，完整的linux系统和依赖包； 在谷歌的研究论文中，容器应用启动延时变化秀大，中间值一般为25s，且package installation占了80%，其中的一个瓶颈为并发写...

OCI镜像规范资料 https://arkingc.github.io/2017/05/05/2017-05-05-docker-filesystem-overlay/ https://docs.docker.com/storage/storagedriver/overlayfs-driver/ https://github.com/containers/skopeo/blob/main/install.md https://www.rectcircle.cn/posts/oci-image-spec/ https://github.com/opencontainers/distribution-spec OCI镜像格式标准 https://www.rectcircle.cn/posts/oci-image-spec/https://github.com/opencontainers/image-spec OCI定义了镜像的格式规范：即镜像的文件和目录结构，相关的配置协议格式等； 如下图为一demo示图： 下图为容器层和镜像层的关系图： 可以通过skopeo工具...

资料 官方技术博客介绍 容器技术之容器镜像篇 Dragonfly 发布 Nydus 容器镜像加速服务 Toward Next Generation Container Image 特点 镜像lazy加载，按需下载镜像blob数据，容器启动速度更快； blobs级别的镜像数据去重，节省空间； 提供用户态文件系统Fuse，兼容OCI分发标准，和artifacts标准（lazy加载就是基于该fuse实现）； 支持镜像存储backend，镜像数据可以放registry或对象存储上； 与Dragonfly P2P系统集成； 架构 主要包括一种新的镜像格式和一个负责解析容器镜像的FUSE用户态文件系统进程； nydus可以配置一个本地缓存（local cache）用来缓存镜像数据，避免每次都从远端数据源拉取数据； nydus Rafs vs OCIv1镜像格式 如下图所示，Rafs镜像格式是分了两块：元数据(bootstrap)、镜像数据块(blobs)； OCI下的镜像层文件tar.gz变成了只存储文件数据块，文件以chunk为粒度进行切割和去重； Rafs用户态FUSE缺陷和解决...

资料 Toward Next Generation Container Image 这项目名字取的好，按阿里武侠的风格，应该翻译为技能：飞龙在天 价值 提供集群内的P2P文件分发能力，可以用于加速文件分发和镜像分发，源支持OSS, S3等云存储类型，也支持OCI镜像仓库； 组件间通信协议为GRPC； 可以与nydus结合，作为containerd与nydus的中间层，为集群提供nydus镜像格式的文件加速分发和加速镜像启动，如下图所示： 架构 如下图所示，为其架构图： dragonfly包含的核心三部分：Manager, Schduler, Seed Peer以及Peer组成的P2P下载网络，Dfdaemon可以作为Seed Peer和Peer； Manager：维护P2P集群的关联关系，动态配置，用户态以及权限管理； Scheduler：为下载节点选择最优下载父节点，异常情况控制Dfaaemon回源； Seed Peer：Dfdaemon开启Seed Peer模式可以作为P2P集群中回源节点，即整个下载的根节点，与后端存储/镜像仓库交互； Peer：通过Df...

资料 [xDS与配置推送]https://blog.fatedier.com/2022/06/01/istio-control-plane-config-push-optimization/#xds-%E6%A6%82%E5%BF%B5%E8%AF%B4%E6%98%8E 背景 云原生拓荒者-Netflix: 性能Performance，扩容Scalability，可用性Availability 提升可用性（反脆弱性），可通过 弹性处理局部故障： 快速失败(fail fast)与故障转移(failover)：超时并重新请求，将流量调度到其它副本 优雅降级：所有副本都出现故障时，熔断上游服务，当前应用以降级形式继续提供服务 金丝雀发布：变更是导致脆弱性的重要原因，任何形式的上线新版本都应该基于灰度部署 将服务治理下沉到基础设施中：service mesh Service Mesh技术标准 UDPA(Universal Data Plane API) 统一数据平台API, Envoy就是该标准的实现 SMI(Service Mesh Interface) 控制平面规范，如do...

概念分布式服务治理 服务治理：对服务不断增长的复杂度的管理与管理 服务拓扑变化，网络，安全 API网关，服务发现，服务容错，部署，调用，追踪 Service Mesh Linkerd, Envoy, Istio 起源于：”What’s a service mesh? And do I need one?” 指专注于服务之间通信的基础设施，负责在现代云原生应用的复杂网络拓扑中可靠的传递请求； 除了基本网络通信的基础功能外，还需要包括分布式应用程序之间通信应该具备的功能，如熔断，限流，trace, metrics, 服务发现，负载均衡； 即微服务业务程序独立于网络通信proxy组件运行，proxy提供服务间的通信，以及熔断、限流、trace, metrcis, 服务发现，安全，LB，超时，mirror，认证和授权等功能，这就是Service Mesh； 数据平面 + 控制平面 数据平面：䚣及系统中的每个数据包或请求，完成网络相关功能； 控制平面：为网络中的数据平台提供策略和配置，其不接触系统中的数据包或请求； 开启Service Mesh后的服务通信逻辑： 微服务间不直接通信，...