一个人短时间吃不完，放的住吗

1. 因为 http header 就是设计成了这样的结构，值可以是数组。但并不代表所有 header 的值都必须支持数组配置，有些 header key 设计出来就只有一个字符串值
2. 基于上述设计理念，go header 结构体的辅助方法就很好理解了，Add 的场景就是为了给数组型 value 使用的，Set 是给字符串型 value 使用的，Get 也是
3. 在实际使用过程中，需要使用者明白当前你想使用的 header key 支持什么类型的 value ，假如是数组，那么就遍历，假如是字符串，那么直接用辅助方法 Get 就好

自己学习用的集群不看配置，能跑 docker 就行，推荐 kind

怎么都戾气这么重，一句“宇宙的尽头是编制”戳到你们肺管子了？

看完了，建议锁死

建议直接用 containerd ，如果要用 docker 也尽量用新版本，docker 的问题还是挺多的

@mmuggle #2 我这边没有升级系统，而是卡了半天以后自己好的......

同样问题

@ra4 #22 “其他一切问题，不过是游戏” 并不是书中原话。在我看来这句话中隐含某种消极的意味，加缪并不赞成用消极对抗荒诞，哪怕是用宗教信仰对抗荒诞，在他看来都算是哲学自杀，或者叫思想自杀。

建议一步到位，直接陶片放逐吧

提交尽量保证原子性原则，也就是一次提交是尽可能少量且不可分割的整体。好处就是 code review 更加简单，代码更容易回滚，更易于追踪变化等等。——《 Pro Git 》
合入主干可以用 squash ，这样能够保证主干 commits 信息更加清晰，有利于项目整体性进度追踪。

描述：为 x 组件增加了 y 特性，修复了 3 个 z 组件的 bug ，摸鱼了三天

这周的工作：

1. 为 x 组件增加了 y 特性：
- 分析 x 组件的功能，设计并实现了 y 特性
- 完成了 y 特性的单元测试，保证了稳定性
- 预备发布 y 特性

2. 修复了 3 个 z 组件的 bug:
- 重现了 3 个 z 组件的 bug ，并调试定位到根本原因，
- 修复了 3 个 z 组件的 bug ，保证系统稳定性
- 单元测试，确认 bug 修复

3. 摸鱼了三天:
- 摸鱼三天，放松心情，缓解工作压力
- 利用盛夏时节，出去旅游，放空自己

可以的，摸鱼还有正当理由

《怦然心动》

长文确实有点长，总结一下，楼主想问的是：在 8 小时规定劳动时间内摸鱼（休息）的合理性与正当性

软件的可维护性也是工作的一部分，这是软件研发团队需要明白的一点，研发团队也需要为此与其他团队抗争，来保证这一点。同时这也是作为软件开发人员职责的一部分，如果忽视软件可维护性的价值，那么系统将会越来越难以维护，总有一天会变得无法维护，如果系统变成这样，那么说明你没尽到责任。

这是我从《 Clean Architecture 》这本书中学到的，也一直在用其要求自己。虽然不太符合大多数公司的现状，但也可以尽量让其他人或团队明白软件架构和代码整洁的必要性。

metrics-server 的这种问题特别常见，这个报错代表无法访问它的 api 了，多数常见于 `kubelet-preferred-address-types` 参数配置有问题，或 tls 也有可能 `--kubelet-insecure-tls`。

虽然 HTTP 协议是基于 RESTful 风格设计的，但不是用了 HTTP 协议的 API 就能叫做 REST API 。
Fielding 一直都不承认现在的 REST API ，认为它们只能叫做 HTTP API 或是 JSON RPC ，还曾经点名过微软的 REST API 。

文章里提到的超媒体驱动是我认为现在 REST API 最难达到的一点，Github 的 REST API 是我认为最接近的，但它仍然需要文档的帮助。
在 Fielding 的理念中，难道你访问一个网页，还需要有个网页使用手册来帮助你理解吗？网页有变更，难道要通知用户去查看新的手册吗？这些都是现在 API 的问题。
在我看来，目前（好几年没关注了，认知停留在 2019 年）的 OpenAPI 或者是 JSON Schema 这些规范提供的描述性格式都不足以达到文档的效果，所以也很难去掉文档的辅助，更别提客户端动态适应 API 的修改了。