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

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

原文：Scaling SPIRE SPIRE 的容量是有限的，随着工作负载强度的不同，需要有不同的规模。一套 SPIRE 中的 Server 部分，可能由一或多个共享数据存储的 SPIRE Server 组成；还

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

原文：eBPF, sidecars, and the future of the service mesh 作者：William Morgan eBPF 给云原生世界带来了很多变化。感谢 Cilium 之类的新技术，eBPF 已经成为了 Kubernetes CNI 的一个流行选择

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

读大纲都觉得没啥养料的一篇东西，大概不适合进到 CIS 的 Benchmark 吧。。

前些天阅读 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

原文：Use Prometheus Vector Matching to get Kubernetes Utilization across any Pod Label 作者：Johannes Ziemke 注：这里实际上涉及到两种标签，一个是 Pod 的，一个是 Metrics 的，非常容易混淆，所以会分别写成

原文：User and workload identities in Kubernetes 作者：Arthur Chiao 本文中我们会试着解释，在 Kubernetes API Server 上如何对用户和工作负载进行认证的问题。 Kubernetes API Server 开放了 HTTP API 接口，让最终

手把手快速入门 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版本，对内容进行了大幅修订。