Golang (GO语言)

需求 👀 与其重要的，是对 kubernetes 资源的收集。 ⚠️ 所有资源均是采用外链连接，书本资源或不放连接，其他均为自己感受和总结。如有侵权请联系删除。 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; 推荐的学习资源整理：...

OpenIM 跨平台源代码类型检查工具 开始 问题 在 OpenIM 的自动化道路中，涉及到越来越全面的自动化设计和测试，在这个过程中，我遇到了一个问题，于是完成了从 go 语言类型检测再到集成本地以及 CI 的全套体验。 问题是这个 issue：https://github.com/openimsdk/open-im-server/issues/1807 我们的 Go 代码在 32 位系统（linux/386）上运行时遇到了整数溢出问题。出现这个问题的原因是 Go 中的 int 类型随体系结构的不同而大小不同：在 32 位系统上相当于 int32，而在 64 位系统上相当于 int64。 恰好在 64 位机器上正常运行，但是在 32 位机器上会出现溢出的问题，于是想着去做一套检测的工具，来解决各个平台的类型检测。 第一部分：Go 语言基础回顾 在深入探讨代码之前，让我们回顾一下 Go 语言的一些基本概念，特别是包管理、并发编程和类型系统。这些概念是理解和使用 Go 语言进行有效编程的基础。 包管理 包的概念 Go 语言中的每一个文件都属于一个包，包是多个 Go 文件的集合。 包用于组织代码，防止命名冲突，并提高代码复用性。 导入包 使用 import 语句来导入其他包。 可以导入标准库包、第三方包，或自定义包。 创建自定义包 在项目中创建一个新的目录，该目录下的 Go 文件属于同一个包。 包名通常与目录名相同，但不是强制性的。 并发编程 Goroutine Go 语言的并发单元称为 goroutine。 使用 go 关键字来启动一个新的 goroutine。 Goroutine 比线程更轻量，能有效利用多核处理器。 Channel Channel 是用于在 goroutines 之间传递消息的管道。 可以是带缓冲的或无缓冲的。 通过 channel 进行数据传递可以避免竞态条件。 类型系统 类型声明 Go 是一种静态类型语言，每个变量都有一个明确的类型。 支持基本类型（如 int, float, bool），复合类型（如 struct, slice），以及用户定义的类型。 接口 接口类型是一种抽象类型，它指定了一组方法，但不实现这些方法。 任何具有这些方法的类型都可以实现该接口。 接口提供了一种方式来指定对象的行为。 类型断言和反射 类型断言用于检查接口值的动态类型。 反射是一种检查、修改变量类型和值的方法。 类型声明 在 Go 语言中，类型声明是定义新类型的方式。Go 支持多种类型，包括基本类型（如 int、float64、bool）、复合类型（如 array、slice、map、struct），以及接口类型。通过类型声明，你可以创建自定义的类型，这对于编写清晰、易于维护的代码非常重要。...

Kubelet组件解析 理解 kubelet Kubelet组件运行在Node节点上，维持运行中的Pods以及提供kuberntes运行时环境，主要完成以下使命： １．监视分配给该Node节点的pods ２．挂载pod所需要的volumes ３．下载pod的secret ４．通过docker/rkt来运行pod中的容器 ５．周期的执行pod中为容器定义的liveness探针 ６．上报pod的状态给系统的其他组件 ７．上报Node的状态 kubelet 管理Pod的核心流程主要包括三个步骤。首先，kubelet获取Pod清单，可以通过文件、HTTP endpoint、API Server和HTTP server等方式获取。其次，节点管理主要是节点自注册和节点状态更新，Kubelet在启动时通过API Server注册节点信息，并定时向API Server发送节点新消息，API Server在接收到新消息后，将信息写入etcd。最后，Pod启动流程主要包括镜像拉取、容器启动、探针监控以及状态汇报等步骤。 kubelet是Kubernetes中的一个节点代理程序，负责维护本节点上Pod的生命周期。kubelet是Kubernetes中非常重要的组件之一，它在Kubernetes集群中扮演着非常重要的角色。kubelet可以在每个节点上运行，它监视分配给该Node节点的pods，并执行各种管理容器的操作，如挂载pod所需要的volumes、下载pod的secret等。 kubelet的核心流程主要包括获取Pod清单、节点管理和Pod启动流程。其中，获取Pod清单的方式包括文件、HTTP endpoint、API Server和HTTP server等方式。节点管理主要包括节点自注册和节点状态更新，而Pod启动流程主要包括镜像拉取、容器启动、探针监控以及状态汇报等步骤。 在节点管理方面，kubelet可以通过设置启动参数-register-node来确定是否向API Server注册自己。如果kubelet没有选择自注册模式，则需要用户自己配置Node资源信息，同时需要告知kubelet集群上的API Server的位置。在启动时，kubelet会通过API Server注册节点信息，并定时向API Server发送节点新消息，API Server在接收到新消息后，将信息写入etcd。 在Pod管理方面，kubelet可以通过文件、HTTP endpoint、API Server和HTTP server等方式获取Pod清单。文件方式主要用于static pod，而HTTP和API Server方式则是Kubernetes中常用的方式。HTTP server主要用于kubelet侦听HTTP请求，并响应简单的API以提交新的Pod清单。 在Pod启动流程方面，kubelet会执行各种管理容器的操作，包括镜像拉取、容器启动、探针监控以及状态汇报等步骤。镜像拉取是Pod启动过程中的一项重要工作，kubelet可以通过imageManager模块来管理镜像。容器启动是Pod启动过程的下一步，kubelet通过container runtime来启动容器。探针监控是Pod启动过程中一项非常重要的工作，kubelet会周期性地执行pod中为容器定义的liveness探针，并将结果上报给系统的其他组件。状态汇报是kubelet的一个重要功能，它会上报pod和Node的状态给系统的其他组件，以及上报节点自身的状态和资源使用情况给API Server。 总之，kubelet是Kubernetes中非常重要的组件之一，它负责维护本节点上Pod的生命周期，并执行各种管理容器的操作。kubelet的核心流程包括获取Pod清单、节点管理和Pod启动流程。在节点管理方面，kubelet通过设置启动参数-register-node来确定是否向API Server注册自己。在Pod管理方面，kubelet可以通过文件、HTTP endpoint、API Server和HTTP server等方式获取Pod清单。在Pod启动流程方面，kubelet会执行各种管理容器的操作，包括镜像拉取、容器启动、探针监控以及状态汇报等步骤。 kubelet 架构 每个节点上都运行一一个 kubelet 服务进程，默认监听 10250 端口。 接收并执行 master 发来的指令; 管理 Pod 及 Pod 中的容器; 每个 kubelet 进程会在 API Server上注册节点自身信息，定期向 master 节点汇报节点的资源使用情况，并通过 cAdvisor 监控节点和容器的资源。 kubelet 架构如下图所示：...

容器运行时 容器运行时(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 几乎是必然的选择。因此在对容器运行时的选择上，主要是聚焦于上层运行时的选择。...

GoReleaser 的目标是自动化发布软件时的大部分繁琐工作，通过使用合理的默认值并使最常见的用例变得简单。 准备工作： .goreleaser.yaml 文件：包含所有配置信息。（有关更多信息，请参阅 自定义） 干净的工作树：确保代码是最新的，并且已经提交了所有改动。 符合 SemVer 的版本号（例如 10.21.34-prerelease+buildmeta） GoReleaser 的运行步骤： GoReleaser 的运行主要分为以下四个步骤： defaulting：为每个步骤配置合理的默认值 building：构建二进制文件、档案、包、Docker 镜像等 releasing：将版本发布到配置的 SCM、Docker 注册表、blob 存储等 announcing：向配置的频道宣布您的发布 使用 -like 标志可能会跳过某些步骤，如 --skip-foo 快速开始 首先，运行 init 命令来创建示例的 .goreleaser.yaml 文件： goreleaser init 然后，我们运行一个“仅限本地”版本，看看它是否可以使用 release 命令运行： goreleaser release --snapshot --rm-dist 此时，您可以 自定义 生成的 .goreleaser.yaml 文件，或保持原样，这取决于您。最佳做法是将 .goreleaser.yaml 文件放入版本控制系统中。 您还可以使用 GoReleaser 为给定的 GOOS/GOARCH 构建二进制文件，这对于本地开发非常有用： goreleaser build --single-target 准备 GitHub 的 Token： export GITHUB_TOKEN="YOUR_GH_TOKEN" GoReleaser 将使用您存储库的最新 Git 标签。...

准备 这篇文章等的太久了，大致 四个月了把，也是自己经历 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工作流中定义。确保根据需要查看和更新工作流。 确保在单独的分支或环境中测试此过程，以避免中断。