云原生 (Cloud Native)

需求 🔥 我们需要对 kubernetes 进一步的学习和深造，看源码是必须的道路。 👀 与其重要的，是对 kubernetes 资源的收集。 ⚠️ 所有资源均是采用外链连接，书本资源或不放连接，其他均为自己感受和总结。如有侵权请联系删除。 🚧 ⚠️ **注意，这篇文章将永久保存在 notion，将会不断地更新下去，提供了可写通道，如果你有更好的资源，欢迎补充在notion上 ~** CloudNative 学习途径 关于kubernetes： 官网 GitHub 社区维护的 kubernetes 学习资源合集 Kubernetes源码必读的 Google 大规模集群管理器 Borg etcd：从应用场景到实现原理的全方位解读 和 ZooKeeper典型应用场景一览 关于 CNCF 的贡献，你需要签署 CLA Kubernetes CLA 的签署流程 官方开发者向导 markdown 文件 Kubernetes ownes 所有者md介绍 自己写作的一些资源： 云原生学习 golang 学习 都收纳到 awesome 仓库中，覆盖 📚 菜鸟成长手册🚀 CS系列 、云原生系列、区块链系列、web3系列🔥、Golang系列💡…… 访问 GitHub👀 https://github.com/cubxxw/awesome-cs-cloudnative-blockchain ⏬⏬⏬ GitHub - cubxxw/awesome-cs-cloudnative-blockchain: 📚 菜鸟成长手册🚀 CS系列 、云原生系列、区块链系列、web3系列🔥、Golang系列💡…… 最好需要什么 如果说第一步的话，那必须要了解 docker 容器底层原理和 Linux 内核基础相关。 先理解理解完架构了，读起来就比较快了。 学会使用它，不会使用，永远无法理解它的设计理念。 读源码还得带着问题去读，不然会很枯燥。一定要带着问题去读，不然就会很枯燥，然后陷入细节中去 读源码还得有一定积累量，比如你已经读过很多基础包的源码比如 net/http grpc-go 等等 要尝试着调试，要尝试着练习，要尝试着理解和分析产品理念，更要学会自己设计。 Kubernetes 工程师的学习顺序推荐 graph LR; 微服务 --> Docker; Docker --> Kubernetes; Kubernetes --> Knative; Knative --> Prometheus; Knative --> Jaeger; Knative --> EFK; Knative --> DevOps; Prometheus --> KVM; Jaeger --> KVM; EFK --> KVM; DevOps --> KVM; KVM --> Istio; Istio --> Kafka; Kafka --> Etcd; Etcd --> Tyk; 推荐的学习资源整理：...

容器运行时 容器运行时(Container Runtime)，运行于Kubernetes (k8s)集群的每个节点中，负责容器的整 个生命周期。其中Docker是目前应用最广的。随着容器云的发展,越来越多的容器运行时涌现。为了 解决这些容器运行时和Kubernetes的集成问题，在Kubernetes 1.5版本中，社区推出了CRI ( Container Runtime Interface,容器运行时接口)以支持更多的容器运行时。 什么是 CRI CRI 是 Kubernetes 定义的一组 gRPC 服务。 kubelet 作为客户端，基于 gRPC 框架，通过 Socket 和容器运行时通信。它包括两类服务: 镜像服务(Image Service)：提供下载、检查和删除镜像的远程程序调用； 运行时服务(Runtime Service)：包含用于管理容器生命周期，以及与容器交互的调用(exec/ attach / port-forward)的远程程序调用。 运行时的层级 容器运行时可以分为高层和低层的运行时： Dockershime，containerd 和 CRI-O 都是遵循 CRI 的容器运行时，我们称之为 高级运行时。 OCI 定义了创建容器的格式和运行时的开源行业标准，包括 镜像规范（Image Specification) 和 容器运行时规范 （runtime specification） 镜像规范定义了 OCI 镜像标准，高层级运行时 将会下载一个 OCI 镜像，并且将它解压为 OCI 运行时文件系统包（file system bundle） 运行时规范描述了如何从 OCI 运行时文件系统包运行容器程序。并且定义它的配置，运行环境和生命周期。如何为新的容器设置命名空间（namespace）和控制组（cgroup) ，以及挂载根文件系统（rootfs）等等操作，都是在这里定义的。它的一个参考实现是 runc，我们称其为 低层级运行时（Low-level Runtime) 高层级运行时(High-level Runtime)：主要包括 Docker,containerd 和 CRI-O 低层级运行时(Low-level Runtime)：包含了 runc, kata,以及 gVisor。 低层运行时 kata 和 gVisor 都还处于小规模落地或者实验阶段，其生态成熟度和使用案例都比较欠缺，所以除非有特殊的需求，否则 runc 几乎是必然的选择。因此在对容器运行时的选择上，主要是聚焦于上层运行时的选择。...

准备 这篇文章等的太久了，大致 四个月了把，也是自己经历 docker 跨越到 Kubernetes 以及 CloudNative 生态的过程。 反过来再去理解开源、理解 sealos、 理解 Kubernetes，有种豁然开朗的视角。 这篇文章和其他文章不一样的是，这篇是按照自己现在的思路来写的，具体为什么，在以前的文章中能找到答案~ 从 CMD 角度上对接源码，从最开始出发： 不管是 sealer 还是 sealctl，都离不开 镜像的构建核心》 buildah： package main import ( "github.com/containers/buildah" "github.com/labring/sealos/cmd/sealctl/cmd" ) func main() { if buildah.InitReexec() { return } cmd.Execute() } 从 InitReexec 调用 buildah 初始化开始，进行走进 sealos 的大门：Execute 在 cobra 中，Execute 只会执行一次，不管是正确的还是失败的~ 在调用的时候，会先执行 init 初始化函数，它 定义了一些初始化工作以及标志： func init() { cobra.OnInitialize(func() { logger.CfgConsoleLogger(debug, showPath) }) rootCmd.PersistentFlags().BoolVar(&debug, "debug", false, "enable debug logger") rootCmd.PersistentFlags().BoolVar(&showPath, "show-path", false, "enable show code path") } 哈哈，sealos 对于日志包的封装，还是很让我惊喜的，使用了 zap 进行二次开发和封装，用于适合自己的业务需要，这对我是有参考意义的，包括 horizon，未来可能需要在 日志包和 错误码设计上进行改进，这是成就一个优秀的开源项目的必要条件~...

✨ 熟悉我的人都知道，我是一名不折不扣的开源爱好者，从大一开始接触到 GitHub 后，逐渐的沉迷于 开源世界 ~ 今天这篇文章很特别，算是自己参考并且总结出来的开源阶段，以及学习开源项目的步骤和心得。未来自己也是按照自己的规划来进行成长。 同学习 Kubernetes 的成长轨迹一样，这篇文章将会长期更新，也可以参与贡献 ~ 目前我是处于第一阶段，处于一种对开源世界和对知识的沉淀与积累的过程中，这个阶段的主要表现是我们开始学一些基础。但是我喜欢做笔记将它们记录下来，供自己日后翻阅和复习，当然也是制作自己的内容价值。 GitHub - cubxxw/awesome-cs-cloudnative-blockchain: 📚 菜鸟成长手册🚀 CS系列 、云原生系列、区块链系列、web3系列🔥、Golang系列💡…… 这一阶段，并不是意味着我开始迈入第二阶段，第一阶段就 come to an end. 我认为以下所讲的所有阶段就像是人生轨迹，并不是意味着你当爸爸了就不是父母的孩子，你依旧可以扮演着多种角色，并且不断完善和改进自己的角色。开源项目也是如此，类比我们的成长经历，在后一阶段我依旧会扮演好前一阶段的角色。所以我会坚持做自己的内容创作和知识共享 ~ ✨ 下面开始介绍适合大多数人的开源项目的不同阶段，为了方便定位，我将上面知识积累称呼为 0 阶段知识积累阶段。下面开始从第一阶段开始讲起~ 第一阶段：简单看源码阶段 💦 在这一个层次的我们，是一个刚毕业或者没毕业的大学生，又或者是刚刚踏入职场，我们是一个新手，对于开源项目保持一心热血但是不知道从何开始。 方法： 简单看源码 说明： 简单看源码、文档、跑跑样例代码 学习效果： 1 ~ 2 有产出： 没有产出 是否达成学习闭环： 尽量问题驱动看源码，从问题出发学源码回归问题，达成闭环 Get 到的技能点： 阅读源码的技能 案例： 阅读 sealer、sealos、Kubernetes、k3s、horizoncd 的源码，并且测试 阶段 第一阶段：简单看源码阶段 方法 简单看源码 说明 简单看源码、文档、跑跑样例代码 学习效果 1 ~ 2 有产出 没有产出 是否达成学习闭环 尽量问题驱动看源码，从问题出发学源码回归问题，达成闭环 技能点 阅读源码的技能 案例 阅读 sealer、sealos、Kubernetes、k3s、horizoncd 的源码，并且测试 第一阶段的建议是简单地看源码、文档、跑跑样例代码来学习。这个阶段的主要目的是积累基础知识，建议尽量问题驱动看源码，从问题出发学源码回归问题，达成闭环。阅读源码的技能是这个阶段最重要的技能点。建议阅读一些开源项目，例如 sealer、sealos、Kubernetes、k3s、horizoncd 等，并进行测试。...

自动化构建openkf的多架构镜像并推送到多个镜像仓库 https://github.com/openimsdk/openkf 描述： 为了满足各种用户的需求，我们的目标是自动化构建用于各种架构的openkf Docker镜像，并无缝地将它们推送到多个镜像仓库。 目标： 自动构建openkf的linux/amd64和linux/arm64架构的Docker镜像。 将镜像推送到Docker Hub、阿里云Docker Hub和GitHub容器仓库。 任务： 设置多架构构建系统 使用GitHub Actions，配合QEMU和Docker Buildx，支持linux/amd64和linux/arm64的多架构构建。 在每次新版本发布、提交到main分支或定期事件时，触发构建过程。 支持多个镜像仓库 Docker Hub：推送到openim/openkf-server。 阿里云Docker Hub：推送到registry.cn-hangzhou.aliyuncs.com/openimsdk/openkf-server。 GitHub容器仓库：推送到ghcr.io/openimsdk/openkf-server。 动态镜像标记 使用Docker Metadata Action，基于事件（如定期触发器、分支提交、拉取请求、语义版本控制和提交SHA）生成动态标签。 确保在拉取请求事件中不推送已构建的镜像。 身份验证和安全性 使用秘密配置Docker Hub、阿里云和GitHub容器仓库的身份验证。 确保每个仓库的推送操作都是安全且无缝的。 通知和日志 通过GitHub Actions，如果有任何构建或推送失败，向开发团队发送通知。 保留每次构建和推送操作的日志以供追踪。 验收标准： openkf镜像应该成功地为linux/amd64和linux/arm64架构构建。 在成功构建后，镜像应该在Docker Hub、阿里云Docker Hub和GitHub容器仓库上可用。 根据定义的事件和属性正确标记镜像。 整个过程中不需要人工干预。 附加说明： 自动化过程在GitHub Actions工作流中定义。确保根据需要查看和更新工作流。 确保在单独的分支或环境中测试此过程，以避免中断。