2022 年底，InfoQ 发了一篇爆款文，《DevOps 已死，平台工程才是未来》，这里总结了一个太长不看版：

对于 AI 我从来没有研究过，只是 ChatGPT 的用户而已，对于 AI 发展的判断我更是个小白。但是 Google 这篇 “We Have No Moat， And Neither Does OpenAI” 文章的中几个观点非常有意思，我也想说几句表达一下个人的看法。

这次阅读的是第一部分第 2 章 - 开发者关系的定位，通读下来觉得这里所说的开发者关系定位，只是指在一个企业中开发者关系的业务归属，汇报层级和部门之间合作的方式等等。

大概是 2014 年，在老东家搞了一阵 DevOps 工具的设计开发，出了一个蛮有意思的设计：以 Pull/Merge Request 为模型枢纽，把需求、代码、构建、发布以及可观测性都关联起来，用一个 Dashboard 观测一个需求从提出到发布以及运行的的所有生命周期内容。那时候大概是 Jenkins 最后辉煌的年代，我第一次接触了 Infrastructrue as Code 的概念，从 Kubernetes 的状态机制、到 Jenkins 的 Pipeline as code，当然还有让我踏进 Kubernetes 门槛的 Ansible，以及可以直接合并到代码仓里面的 Grafana Template，都给刚脱离业务代码不久的我带来很大触动。（最近会上听说这个产品还活着，老怀大慰 :D），后面的日子里因为一直在跟各种 YAML 打交道，可以说 As Code 的概念已经成了我的思维习惯。

第二篇读书笔记贴到 Facebook 账号后，有朋友来问怎么都是序，我承认读书太慢，这次出差到南京的火车上再次拿起随行的这本书，把第一部分形成广泛的共识的第 1 章开发者关系基本概念读完了，现在感觉这本书不是一本讲道理的书，而是一本给项目经理的手册。

还是像上一篇序一样，所有的阅读、思考和文字都是在移动的过程中产生。在北京飞深圳的差旅起点读完序 2 - 5 并做完笔记，在差旅的最后一站长沙将文字敲到电脑上，通过博客 和云原生喝酒 SIG 发起人老崔的公众号伪架构师发出来。

我有一个非常不好的习惯，看书的时候先看各种序、读一下文章目录，每章看个开头，然后就扔在那里等什么时候需要的时候再去翻。所以再大部头的书到我手里也是分分钟的就扫了一遍，扔到书架上去吃灰。这次下定决心把每个段落都认真的读一下，通过笔记的方式强迫自己把思考的内容记录下来。另外也是正用 Rust 开发的新版本管理系统，这是一个必须依赖开发者生态的开源项目，如何针对这个特别的人群做好产品和服务成为最近思考的焦点，也算是强迫认真读这本书的一个动力。

在任何组织结构中，一旦你把常规工作分解成过于琐碎的任务，并把它们委托给太多的人，他们的信息传递很快就会变得无法管理，组织也会停止发展。 去年 3 月 22 日，亚马逊 Prime Video 的工程师在一篇几周内未被注意的博文中报告说，他们在微服务平台上创建的，为确定流媒体视频的服务质量（QoS）水平而构建的服务质量监控应用程序，在低于 10% 负载情况下也会失败。

生娃和进厂之后，个人独处时间越发金贵，随之而来的问题就是阅读量难于保障了。过去我的阅读流程是浏览邮件列表、固定的播客、推特等信息源头，根据喜好情况搜集到 Pocket 之类的 Read it later 工具里面。但是现在因为缺乏连续时间，待读列表越来越长。想了下也就是跑步和开车的时候耳朵是比较清闲的——灵机一动：“给自己做个播客吧”。

最近在和同事讨论一个非典型的云原生应用更新场景。目标应用是一系列有状态的 Statefulset，其中的实例用类似投票的机制对外提供服务，这意味着始终有一部分实例是处于待命状态的。由此情况，这个应用在虚拟化时期，会提供一个仲裁服务，每次对实例进行更新时，首先要从这个仲裁服务查出可以更新的摸鱼实例，然后仅仅对这些空闲实例进行升级。

这次介绍的是在 SPIRE Server 和 Vault Server 之间建立 OIDC 联邦的方法。设置联邦之后，SPIRE 认证的工作负载就能使用 JWT-SVID 来通过 Vault Server 的认证。这样工作负载就无需使用 AppRole 或者用户名密码的方式来进行认证了。

前面关于 SPIRE 的内容中，介绍了使用 JOIN Token 证实节点身份的方法。这种方法比较简易，但是完全依赖 SPIRE Server/Agent 的“内循环”，并不利于外部管理，同时每次节点更新，都要照本宣科的重来一遍。对于动态集群来说，这种方式并不理想，SPIRE 包含了面向 OpenStack、几大公有云以及 TPM 等的花钱证实节点身份的方案；除了这些之外，还有个经济型的证实方法——使用 SSH。

SPIRE 的容量是有限的，随着工作负载强度的不同，需要有不同的规模。一套 SPIRE 中的 Server 部分，可能由一或多个共享数据存储的 SPIRE Server 组成；还可以是同一信任域的多个 SPIRE Server；至少有一个 SPIRE Agent，当然，多数时候是多个 Agent。 部署规模和负载规模相关。单个 SPIRE Server 能够承载一定数量的 Agent 和注册项。SPIRE Server 负责管理和签发注册项的身份，因此它的内存和 CPU 消耗是随着负载注册条目的数量线性增长的。单一的 SPIRE Server 部署还可能导致单点失败。

之前对 SPIFFE 和 SPIRE 进行了一个相对全面/啰嗦的介绍，这一篇就反过来，用一个简单的例子来展示 SPIRE 的基本用法，本文中会以 NGINX 作为服务生产方，使用 Ghostunnel 当做 NGINX 的反向代理，把原有的 HTTP 通信升级为支持定期正顺轮转的双向 TLS 认证协议，并且用 CURL 使用客户端证书来通过 Ghostunnel 安全地访问背后的 NGINX。这里为 CURL 和 NGINX 提供证书以及轮转的，就是 SPIRE 的 Server 和 Agent。

eBPF 给云原生世界带来了很多变化。感谢 Cilium 之类的新技术，eBPF 已经成为了 Kubernetes CNI 的一个流行选择。Linkerd 这样的服务网格产品也经常会和 Cilium 或类似的 CNI 产品协同工作，从而同时在 7 层和 3/4 层分别得到 Linkderd 和 Cilium 的强大处理能力。但是 eBPF 的网络技术到底多强大？会强大到——例如替换 Linkerd 的 Sidecar Proxy，从而能在内核里完成所有操作吗？

大概很多人和我一样，是从 Istio 那里听说 SPIFFE（读音 Spiffy [ˈspɪfi]） 的，Istio 中用 SPIFFE 方式为微服务提供身份。SPIFFE 全称为 Secure Production Identity Framework For Every one，顾名思义，这是一个解决身份问题的框架；而 SPIRE 则是 SPIFFE 的一个实现，全称为 SPIFFE Runtime Environment。

Argon（现在是 Aqua Security 的一部分）曾经联系 CIS（Center for Internete Security），建议为软件供应链安全开发一种 CIS 基线。多年以来，CIS 开发并发布了很多安全配置指南，但是软件供应链安全方面还是一个空白。现代软件开发过程中会涉及大量的平台和技术，软件供应链安全的工作范围应该有多大？如何保证基线能够在多种平台中保持一致？

前些天阅读 Istio 文档的时候发现个语焉不详的东西：Metrics Merging，原文如下：

Prometheus 是为 Kubernetes 这样的动态环境而生的。它的服务发现能力和查询语言非常强大，Kubernetes 运维过程中，用户可以借 Prometheus 解决监控问题。

本文中我们会试着解释，在 Kubernetes API Server 上如何对用户和工作负载进行认证的问题。