1.三种不同场景下的依依赖 Kubernetes 服务调试方法
2.实战！用Bazel来管理iOS程序
3.Kubernetes —— Pod 自动水平伸缩源码剖析（上）
4.k8s emptyDir 源码分析
5.pod的赖源工作原理
6.client-go 源码分析（4） - ClientSet客户端 和 DynamicClient客户端
三种不同场景下的 Kubernetes 服务调试方法
在开发和调试 Kubernetes 生产环境下的服务时，会遇到各种调试需求。依依赖本文将介绍三种不同场景下的赖源解决方案和相应的工具。基本配置
假设我们有三个服务：service-front 面向外部，依依赖通过服务暴露；service-front 后端是赖源php在线监控源码 service-middle，后者又依赖 service-back。依依赖通信通过 Kubernetes 服务进行。赖源安装配置如下： 源代码可在：github.com/erkanerol/se...工具1：kubectl port-forward
场景：开发者希望在不影响其他服务的依依赖情况下，通过 service-back 直接发送请求并查看结果，赖源但 service-back 不对外公开。依依赖 解决方案：使用 kubectl 的赖源 port-forward 功能创建本地到集群的隧道。 步骤：在终端运行：kubectl port-forward service-back: localhost:
在另一个终端中，依依赖尝试用 curl 访问 localhost: 来验证连接。赖源
工具2：kubefwd
场景：开发者希望在本地 IDE 中设置断点调试 service-front，依依赖但 service-front 和依赖服务难以本地模拟。 解决方案：kubefwd 可以批量端口转发并管理本地 DNS，简化配置。 步骤：运行：kubefwd service-front:
使用 sudo，配置 KUBECONFIG，运行本地 front 应用并设置断点。
在集群中测试服务交互。
工具3：telepresence
场景：开发者需要在本地调试 service-middle，同时 service-middle 依赖 service-back，并且集群环境不易模拟。 解决方案：telepresence 提供双向通道，支持本地服务与集群服务间的调试。 步骤：删除集群中的轻商城小店源码 service-middle，运行 telepresence。
本地运行 middle 应用并设置断点。
通过集群临时 Pod 发送请求到 service-front。
总结：对于不暴露服务的访问，kubectl port-forward 足够。
本地调试时，kubefwd 管理 DNS，提供单向通道。
需要双向通道和依赖服务调试时，使用 telepresence。
实战！用Bazel来管理iOS程序
在探索Bazel作为iOS项目管理工具的过程中，我总结了以下几点原因促使我选择Bazel而非Xcode：
首先，Bazel提供更好的代码审查和依赖管理。Xcode的编译设置分散在多个文件中（xcscheme、pbxproj和xcconfig），使得代码审查变得困难。相反，Bazel的配置统一且可追踪，有利于代码审查流程。
其次，Bazel具有高效的缓存机制和快速增量编译能力。Xcode的编译缓存管理效率低下，即使是细微的设置改动也可能导致全量编译。相比之下，Bazel仅对发生变化的文件或依赖进行编译，切换分支也不会显著影响编译速度。坚果云源码安装
此外，Bazel支持远程缓存，这在项目规模增大时能显著提高编译效率。它还提供了更多模块化实践的友好环境，支持Swift等语言的大型项目开发。
选择迁移Bazel的时机因工程团队规模和需求而异。在感受到Xcode编译系统的不足（如长时间编译时间、单体大项目或持续集成工具频繁报错）时，迁移可能需要几个月的时间。而对于小型团队，迁移Bazel可能不是当前的首要任务。
配置阶段涉及安装工具（如Bazelisk和Tulsi）和调整文件结构。在源码库中创建WORKSPACE文件以整合规则，使用generate_xcodeproj.sh脚本生成Xcode项目。同时，通过PodToBUILD项目自动将CocoaPods依赖转换为Bazel兼容的格式。
处理CocoaPods依赖时，利用PodToBUILD将现有项目的依赖转换为Bazel格式，然后通过特定命令将依赖复制到源码库中。对于某些依赖，如Google的Protobuf，可以将官方的BUILD文件替换原有的CocoaPods配置。其他依赖通常通过Bazel的编译规则进行导入。
在处理C++支持时，需要手动创建自定义的toolchain并将其集成到本地项目中，以确保使用C++。此外，源码查找任务计划还需要关注Bridging header的配置、Provisioning文件、entitlement设置、以及手机测试和打包的相关步骤。
在Bazel下进行单元测试时，注意区分Hosted Tests与ios_unit_test的使用场景。对于大多数测试应转换为单元测试，而对于依赖特定环境的测试（如SnapshotTesting），则保持Hosted Tests的使用。
将Bazel集成至持续集成系统中，如Bitrise，可以简化测试和打包流程。通过共享缓存，可以进一步提升持续集成的编译速度。同时，使用Bazel的select_a_variant函数选择性地编译不同版本的程序，如针对Apple的提交版本。
随着项目的深入使用Bazel，可以探索更多的代码生成技术，例如自动将配置文件（如JSON文件）生成固定Swift文件，直接嵌入程序中，减少加载步骤。
迁移Bazel虽然需要一定的前期投入，但相对于之前的切换经验（如从Xcode Workspace到Buck），过程变得更加顺畅。对于大型依赖复杂的项目，迁移工作量也相对较小，劳动仲裁项目源码通常只需几天时间。
尽管Bazel已提供了良好的基础支持，仍有改进空间，尤其是在工具集成与代码生成的自动化方面。此外，社区的反馈和讨论对于进一步优化迁移过程和利用Bazel的潜力至关重要。
Kubernetes —— Pod 自动水平伸缩源码剖析（上）
ReplicaSet 控制器负责维持指定数量的 Pod 实例正常运行，这个数量通常由声明的工作负载资源对象如 Deployment 中的.spec.replicas字段定义。手动伸缩适用于对应用程序进行预调整，如在电商促销活动前对应用进行扩容，活动结束后缩容。然而，这种方式不适合动态变化的应用负载。
Kubernetes 提供了 Pod 自动水平伸缩（HorizontalPodAutoscaler，简称HPA）能力，允许定义动态应用容量，容量可根据负载情况变化。例如，当 Pod 的平均 CPU 使用率达到 %，且最大 Pod 运行数不超过 个时，HPA 会触发水平扩展。
HPA 控制器负责维持资源状态与期望状态一致，即使出现错误也会继续处理，直至状态一致，称为调协。控制器依赖 MetricsClient 获取监控数据，包括 Pod 的 CPU 和内存使用情况等。
MetricsClient 接口定义了获取不同度量指标类别的监控数据的能力。实现 MetricsClient 的客户端分别用于集成 API 组 metrics.k8s.io，处理集群内置度量指标，自定义度量指标和集群外部度量指标。
HPA 控制器创建并运行，依赖 Scale 对象客户端、HorizontalPodAutoscalersGetter、Metrics 客户端、HPA Informer 和 Pod Informer 等组件。Pod 副本数计算器根据度量指标监控数据和 HPA 的理想资源使用率，决策 Pod 副本容量的伸缩。
此篇介绍了 HPA 的基本概念和相关组件的创建过程，后续文章将深入探讨 HPA 控制器的调协逻辑。感谢阅读，欢迎指正。
k8s emptyDir 源码分析
在Kubernetes的Pod资源管理中，emptyDir卷类型在Pod被分配至Node时即被分配一个目录。该卷的生命周期与Pod的生命周期紧密关联，一旦Pod被删除，与之相关的emptyDir卷亦会随之永久消失。默认情况下，emptyDir卷采用的是磁盘存储模式，若用户希望改用tmpfs（tmp文件系统），需在配置中添加`emptyDir.medium`的定义。此类型卷主要用于临时存储，常见于构建开发、日志记录等场景。
深入源码探索，`emptyDir`相关实现位于`/pkg/volume/emptydir`目录中，其中`pluginName`指定为`kubernetes.io/empty-dir`。在代码中，可以通过逻辑判断确定使用磁盘存储还是tmpfs模式。具体实现中包含了一个核心方法`unmount`，该方法负责处理卷的卸载操作，确保资源的合理释放与管理，确保系统资源的高效利用。
综上所述，`emptyDir`卷作为Kubernetes中的一种临时存储解决方案，其源码设计简洁高效，旨在提供灵活的临时数据存储空间。通过`unmount`等核心功能的实现，有效地支持了Pod在运行过程中的数据临时存储需求，并确保了资源的合理管理和释放。这种设计模式不仅提升了系统的灵活性，也优化了资源的利用效率，为开发者提供了更加便捷、高效的工具支持。
pod的工作原理
1、所有的开源三方库，都会把框架的.spec文件添加到CocoaPods远程索引库中，而每一个.spec文件中都包含三方库的作者名称、版本号和源码的地址
2、执行pod setup
远程索引库中所有的.spec都会被拷贝到本地索引库
3、执行pod search
会从本地检索索引文件中去查询所查询的库
4、执行pod install
当查询到后会从索引文件中对应的源码地址中下载代码集成到项目中
5、当我们要做一个公开库的时候，只需要编写好源码，并且把源码的.spec文件添加到CocosPods远程索引库
相反，当我们要做一个私有库的时候，只需要编写好源码，并且把源码的.spec文件添加到我们自己的远程索引库中
client-go 源码分析（4） - ClientSet客户端 和 DynamicClient客户端
本篇文章主要探讨ClientSet客户端与DynamicClient客户端的特性差异。ClientSet以其类型安全的优势，专门操作内置的Kubernetes资源，如Pods。其核心在于通过clientset.CoreV1()获取到的corev1.CoreV1Client，这个对象实现了PodsGetter接口，进而执行Pods方法，如查询default namespace下的所有Pod。
示例代码展示了如何通过CoreV1Client获取Pods，实际上是通过调用restclient客户端的List方法。ClientSet的CRUD操作均基于已知的结构化数据。相比之下，DynamicClient更为灵活，它不仅能操作内置资源，还能处理CRD自定义资源，因为其内部使用了Unstructured，以适应非结构化数据的处理。
DynamicClient与ClientSet的差异在于，它支持动态操作任何Kubernetes资源，包括CRD。使用DynamicClient时，如删除、创建资源，也是通过底层的RESTClient客户端实现。调用DynamicClient时，会先通过Runtime将响应体转换为非结构化的数据，然后利用DefaultUnstructuredConverter将其转换为Kubernetes资源对象。
值得注意的是，与ClientSet一样，DynamicClient客户端也支持ResetClient，只是在处理非结构化数据时有所不同。关注“后端云”微信公众号，获取更多技术资讯和教程。
KubeVirt网络源码分析
本文深入剖析KubeVirt网络架构中的关键组件与流程。KubeVirt的网络架构中，每个Kubernetes工作节点上运行的Pod，对应着一台Pod内的虚拟机。我们专注于网络组件，而非Kubernetes网络层面。
核心组件包括：Kubernetes工作节点、Pod、以及运行于Pod内的虚拟机（VM）。网络架构由三层组成，从外部到内部依次是：Kubernetes网络、libvirt网络、虚拟机网络。此文章仅聚焦于libvirt网络与虚拟机网络。
在`kubevirt/pkg/virt-launcher/virtwrap/manager.go`中，`func (l *LibvirtDomainManager) preStartHook(vm *v1.VirtualMachine, domain *api.Domain)`函数调用`SetupPodNetwork`方法，为虚拟机准备网络环境。
`SetupPodNetwork`方法主要执行三项任务，对应以下三个函数：`discoverPodNetworkInterface`、`preparePodNetworkInterfaces`、`StartDHCP`。
`discoverPodNetworkInterface`收集Pod接口信息，包括容器的IP和MAC地址。`preparePodNetworkInterfaces`对容器原始网络进行配置调整，确保DHCP服务能够正确地提供给虚拟机一个IP地址，以及网关和路由信息。此过程由`SingleClientDHCPServer`启动，该服务仅提供给虚拟机一个DHCP客户端。
以上描述基于KubeVirt 0.4.1版本的源码。对于后续版本的网络部分，将进行持续分析。
对于更深入的了解，推荐查阅QEMU创建传统虚拟机及其网络流程的相关资料。如有兴趣，欢迎关注微信公众号“后端云”。
