这周是小厂实习的第一周。因为周三才入职，所以实际上只上了三天班。时间虽然不长，但已经开始接触第一个内部项目；开源方面也有了一点小进展，第一次连续有几个 PR 被正式合并。
小厂实习的第一周
周三是入职第一天，整体还是比较轻松的。
上午主要是熟悉工位、配置电脑和开发环境，中午和 mentor 一起吃了饭。下午刚好赶上公司的下午茶，听说大概一周一次，没想到第一天就直接吃上了。
晚上还有一次免费的团建聚餐，吃的是海鲜自助，体验很不错。第一天基本没有什么工作压力，更多是在熟悉环境和认识同事。
到了周四和周五，我开始参与第一个内部小项目。
今天和 leader 做了一次 one-on-one。虽然我的岗位是全栈开发实习生，但这个项目从最开始的产品原型设计，到后续真正进入开发阶段，都会让我参与。团队分别安排了产品和开发两个方向的 mentor，所以这两天暂时还没有开始写前后端代码，主要是在和产品 mentor 沟通需求、梳理页面流程并设计产品原型。
原型页面前后做了两天。第一版完成后，我和几位同事开了一个短会，一起看了看整体效果。从反馈来看，完成得还不错，也算是入职之后的第一份正式产出。
不得不说，leader 对实习生还是挺照顾的，这几天经常主动来问我的适应情况和感受。虽然小厂实习的薪资不算高，但目前感受到的团队氛围很不错。
希望后面的实习也能顺利一点。
第一次连续有开源 PR 被合并
除了实习之外，这周在开源上也算有了一个小进展：第一次连续有几个 PR 被正式合并。
过程中当然少不了 AI 的辅助，不过 AI 给出实现之后，代码还是得自己认真看一遍，把涉及的逻辑和背景弄明白。否则维护者在 review 里追问为什么这么改，自己却答不上来，多少还是有点尴尬。
这周主要在 k8sgpt、KubeVela 和 k0smotron 做了一些贡献，一共有 5 个 PR 被合并。
这些改动的规模都不算大，主要是修复 bug、补充测试，以及完善已有功能的校验逻辑。
k8sgpt：三个 Analyzer 修复
这周在 k8sgpt 合并了三个 Analyzer 相关的修复。
#1722：扫描 init container 中的 ConfigMap 引用
这个 PR 补上了对 init container 中 ConfigMap 引用的扫描。
原来的 Analyzer 只检查普通 container，因此一个只被初始化容器使用的 ConfigMap，可能会被误报为“未使用”。修复之后，扫描逻辑会同时覆盖 init container，避免这类误报。
#1725：修复 Job Analyzer 的失败误报
Job 即使曾经产生过失败的 Pod，经过重试后仍然可能正常完成。
因此，不能只根据 status.failed > 0 就判断整个 Job 执行失败。这个 PR 调整了 Job Analyzer 的状态判断逻辑，避免已经成功完成的 Job 因为曾经发生过重试而被误报。
#1737：修复 Gateway 状态判断
原来的实现假设 conditions[0] 一定是 Accepted，但 Gateway API 并不保证 conditions 的固定顺序。
这个 PR 不再依赖数组位置，而是根据 condition type 分别查找并检查 Accepted 和 Programmed，让状态判断更加准确。
这几个问题本身都比较聚焦，不过为了确认它们确实是 bug，还是需要分别了解 init container 的 ConfigMap 引用方式、Job 的状态语义，以及 Gateway API 对 conditions 的定义。
带着具体问题去读代码和文档，我个人觉得比单独学习概念更容易理解，也更容易记住。
KubeVela：补齐 conflictsWith 校验
#7303：在 Admission 阶段执行 TraitDefinition conflictsWith 校验
在 KubeVela 中，TraitDefinition.spec.conflictsWith 字段已经存在于 API 和文档中，用于声明彼此冲突、不能同时使用的 traits。
但这个字段之前实际上没有被执行，因此即使两个 traits 被声明为互相冲突，它们仍然可以同时挂载到同一个 Application 上。
这个 PR 在 Admission 阶段补上了对应的冲突校验。
实现过程中还需要处理 namespace、revision、CRD、API group 和 label selector 等不同的匹配形式，并根据 review 意见调整错误处理方式和测试风格。
PR 合并后，项目还为 1.10 和 1.11 分支创建了对应的 backport。
相比前面几个比较集中的 Analyzer 修复，这个改动涉及的匹配场景更多，review 过程中需要考虑的边界情况也更多。
k0smotron：补充升级策略的 E2E 检查
#1542：为不同控制面升级策略增加 E2E 验证
这个 PR 为不同的控制面升级策略补充了 E2E 检查。
测试除了确认升级最终能够成功，还会进一步验证升级过程是否符合对应策略：
- 原地升级不应该重建 Machine；
- 重建升级应该替换旧 Machine；
RecreateDeleteFirst过程中，副本数量不应该超过期望值。
在 review 过程中，还发现了旧升级 Plan 和新 Plan 可能短暂交替存在的时序问题。后来调整了轮询逻辑，让测试能够兼容这种正常的中间状态，同时继续验证最终结果。
这次改动让我更直观地接触到了不同升级策略之间的差异，也让我意识到 E2E 测试不应该只验证“最后是否成功”，还应该检查中间过程是否符合预期。
为什么开始参与开源
我开始参与开源的目的其实比较实际。
一方面，我希望通过真实项目边做边学，补充 Kubernetes 和云原生相关的知识；另一方面，也希望积累一些能够写进简历，并且在面试时可以真正讲清楚的经历。
目前我还处在熟悉这些项目的阶段，所以会优先选择范围比较明确、自己能够理解和验证的问题。
这些改动可能都不算大，但每次都会接触到一点不同的内容，也能逐渐熟悉云原生项目的代码结构、测试方式、协作流程以及相关基础知识。
AI 可以帮助我更快地阅读代码、查找实现位置和整理思路，但最终还是需要自己确认问题是否存在、理解代码为什么这样修改，并且能够解释和验证修改后的行为。
希望后面可以在保证自己真正理解改动的前提下，逐渐尝试一些更深入的问题。
写在最后
这一周只有三个工作日，但无论是实习还是开源，都算是有了一个还不错的开始。
实习方面完成了第一版产品原型，也开始逐渐熟悉团队和项目；开源方面第一次连续有 5 个 PR 被合并，对参与开源项目的流程也比之前熟悉了一些。
接下来还是一步一步来，把手上的事情做好，也继续学习。