IaC 的起源 IaC 是配置管理领域的一种技术，全称 Infrastructure as Code，字面意义：基础设施即代码，是一种使用可读文本发放和管理基础设施资源的方法。通常情况下，

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

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

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

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

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

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

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

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

手把手快速入门 Service Mesh 和实践。

透过全新的视角，针对容器云领域现下的热点和技术难点，给出了基于Kubernetes的企业级容器云落地指南，为企业传统IT转型和业务上云提供助力。

本书是容器圈Kubernetes重磅开山作《Kubernetes木又威指南》的纪念版，内容更新到Kubernetes v1.6+版本。

本书是容器圈Kubernetes重磅开山作《从Docker到Kubernetes实践全接触》的升级版，书籍更新到2016.6 Kubernetes v1.3版本，包含从2015.7发布1.0版本之后v1.1、v1.2、v1.3版本的全部新特性，并根据第1版的读者反馈和全新的Kubernetes版本，对内容进行了大幅修订。