文章

使用 Shell Operator + CRD 恢复被暂停的 Argo Workflow

上一篇讲到,使用 Kyverno 通过对特定标签的识别,让每个步骤进入自动暂停的状态,实现逐步骤运行。留了个尾巴,怎样才能快速的恢复被暂停步骤的运行? TL;DR; 随便

用 Kyverno 让 Argo Workflow 单步执行

AWS 的 SSM Automation 中,有个有趣的特性就是单步执行,在编写自动化脚本的时候,这个功能对调试非常有帮助。Argo Workflow 也有个暂停特性,官网给出的例子是这样的:

介绍一个小工具:Terranetes

IaC 不只是 Terraform 虽然几年前的一次讨论中,我嘲讽过某同事说,Terraform 目前最靠谱的 Provider,也就只有 Kubernetes 一个而已,相对于顾头不顾尾的 Provider

使用 Argo Workflow 组织跨云运维的可能性

在微服务、容器化和 IaC 等概念普及之前,自动化通常是使用过程性操作进行的,例如摘流——升级——恢复的过程。为了运维方便,通常这些操作序列会由所谓

Kubernetes 的小秘密——从 Secret 到 Bank Vault

Kubernetes 提供了 Secret 对象用于承载少量的机密/敏感数据,在实际使用中,有几种常规或者非常规的方式能够获取到 Secret 的内容: Pod 加载(自己的或者不是自己的)Sec

不用 API Server 也能运行 Pod?

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

Thinking in Promises Ch01.with a License to Intend

【译】《Thinking in Promises》第一章 承诺和强加

想象有这样一组原则,这些原则可以帮助你理解部分如何结合成为整体,以及每个部分如何从自己的角度看待整体。如果这些原则是有效的,那么用这些原则进

试译:Thinking in Promises

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

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

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