原创

不用 API Server 也能运行 Pod?

遇到一个奇怪的需求:想复用 Pod 的 YAML,但是家境贫寒,不想搞个高可用 API Server;又惜字如金,不想上 Docker Compose。一顿 Google 猛如虎之后,得

试译:Thinking in Promises

前段时间在摸索配置管理问题时,偶然翻到了这本书,作者 Mark Burgess 是个会作曲会画画的理论物理学家,同时在管理一堆服务器的时候,编写了 CFEngine 这个鼻祖级的配置

用 KEDA 根据工作负载进行快速扩容

尽可能真实感知业务负载,尽可能快速扩缩全链路工作负载

持续监控集群中的镜像漏洞——Trivy Operator 简介

Trivy-Operator是一个实用的 Kubernetes 安全工具,能自动扫描容器镜像的已知漏洞和验证 Kubernetes 资源的最佳实践,确保集群安全。同时,它生成易于访问的报表,提供Prometheus 集成和可视化仪表盘,使您能快速识别并解决安全问题。

用 ChatGPT 写了一点代码

ChatGPT 发布之后,一直在半真半假的用着:有时候写一些代码片段,例如让他用 Python、Rust 分别帮我写一点方法级别的代码;有时候会跟他“探讨”一

在 SPIRE 中用 SSH 证实节点身份

前面关于 SPIRE 的内容中,介绍了使用 JOIN Token 证实节点身份的方法。这种方法比较简易,但是完全依赖 SPIRE Server/Agent 的“内循环”,并不利于外部管理,同时每次节点更新,都

用 SPIRE 为 Pod 提供身份

开始之前 SPIFFE 是一个认证框架,能为多种节点和工作负载类型提供证实能力,解决“我是我”的问题,前面文章演示过用 SPIRE 给类 Unix 进程提供身份的方法,今天这篇

用 Ghostunnel 和 SPIRE 为 NGINX 提供 SPIFFE 认证

之前对 SPIFFE 和 SPIRE 进行了一个相对全面/啰嗦的介绍,这一篇就反过来,用一个简单的例子来展示 SPIRE 的基本用法,本文中会以 NGINX 作为服务生产方,使用 Ghostunnel 当做 NGINX 的反

SPIFFE/SPIRE 从入门到入门

前言 大概很多人和我一样,是从 Istio 那里听说 SPIFFE(读音 Spiffy [ˈspɪfi]) 的,Istio 中用 SPIFFE 方式为微服务提供身份。SPIFFE 全称为 Secure Production

在 Istio 中合并监控指标

前些天阅读 Istio 文档的时候发现个语焉不详的东西:Metrics Merging,原文如下: This option is enabled by default but can be disabled by passing –set meshConfig.enablePrometheusMerge=false during installation. When enabled, appropriate prometheus.io annotations will be added to all data plane