前言 内部有非 K8S 环境上需要类似 SVC 的负载实现，一开始是用 NGINX 做的，所有 SVC 域名都解析成一个 dummy IP ，然后 NGINX 根据 server_name 去 proxy 不同的 upstream 。 开始还是能用的，但是后面结果后面很多服务依赖 host 这个 header ，报错签名错误，而且毕竟这样是在用户态，效率不如内核态高。于是打算搞下之前的打算：把 I

1. 边缘计算专家长成计划 云原生社区边缘计算SIG从2021年4月成立以来，就定位为学习性边缘计算小组，为培养更多的边缘计算专家而奋斗着。到目前为止我们已经有200多位小伙伴，为KubeEdge、SuperEdge、EdgeX Foundry、Karmada等开源项目先后贡献了40多个Commits。我们的开发者也快突破30人，来自不同公司，不同岗位，贡献着不同的开源项目。我们一块在此学习 -&

前言 前段时间我写了一篇文章《如何用研发效能搞垮一个团队》引起了业界同行大量的讨论与关注，今天想继续聊聊研发效能提升过程中另一个敏感话题：“度量”。讨论度量的目的不是争论对错，而是希望能够引发大家对这一话题的深入思考。 度量失败的案例 首先来看一些由于度量体系设计不当而引发“内卷”等不良行为的案例。 比如以“点击量”来度量自媒体运营的成果，那么就有可能出现点击量显著提升，但是公众号的关注人数却下降

编者按 本文译自 Cloudflare 出品的白皮书 Can ZTNA replace your VPN? Compare 3 remote access approaches，本文对比了VPN和ZTNA远程访问解决方案，阐明了它们的好处和局限性，同时阐明了迁移项目的最重要考虑因素。同时给出了 Cloudflare 的解决方案及迁移到 ZTNA 的步骤建议。 简介 安全、无缝的远程访问是一个业务促

本文针对 Kong 的启动流程、插件机制、缓存机制和请求的生命周期做了详细的阐述。 1. 概述 本文针对的是 Kong 2.1 版本（Stable）。 我阅读并作出中文注释的 Commits 可以在这里看到： https://github.com/mayocream/kong/commits?author=mayocream Kong（OpenResty）的执行阶段： Kong 的插件机制也是基于

目前，容器的存储大多支持Docker或Kubernetes的Volume（数据卷），因此我们下文先介绍这两种Volume的原理。 Docker的容器卷插件 Docker V1.8正式发布了容器卷插件 (Volume Plugin) 的规范，允许第三方厂商的数据卷在Docker引擎中提供数据服务，使得外置存储可以超过容器的生命周期而独立存在。这意味着各种存储设备只要满足接口API的标准，就可以接入D

Chaos Mesh 是由 TiDB 背后的 PingCAP 公司开发，运行在 Kubernetes 上的混沌工程（Chaos Engineering）系统。简而言之，Chaos Mesh 通过运行在 K8s 集群中的“特权”容器，依据 CRD 资源中的测试场景，在集群中制造浑沌（模拟故障）1。 本文探索混沌工程在 Kubernetes 集群上的实践，基于源码分析了解 Chaos Mesh 的工作

在Rancher中，由于Kubernetes是基于Cattle引擎来部署，所以在Kubernetes部署完成之后，我们可以通过Link Graph来很清晰地看到整体的部署情况。 既然基于Cattle引擎部署，也就是说需要两个compose文件，k8s引擎的compose文件放在https://github.com/rancher/rancher-catalog/tree/master/templa

本文基于 APISIX 2.6 版本进行源码分析，源码阅读注释仓库: review，分析主要流程以及核心机制。 1. APISIX 概述 APISIX 与 Kong 类似，是一个基于 OpenResty 构建的 API 网关，如果你熟悉 OpenResty，你大概能猜到本文会讲述 APISIX 在 OpenResty 的几大生命周期中， 做了什么动作来进行路由匹配、服务发现、负载均衡以及加载插件。

概述 Harbor使用了基于角色的访问控制策略，当从Harbor中拉去镜像的时候，首先要进行身份认证，认证通过后才可以拉取镜像。在命令行模式下，需要先执行docker login，登陆成功后，才可以docker pull。通常情况下，在私有云环境中使用kubernetes时，我们要从docker registry拉取镜像的时候，都会给docker daemo配置–insecure-registry

本文分析 Istio 安全认证体系与加密通信的源码，介绍 Istio 是如何构建集群内部 PKI 证书基础设施和实施安全通信的。 分析过程的代码注释在我的 Github 仓库 mayocream/istio 的 citadel-review 分支。 1. 身份模型 零信任架构下，需要严格区分工作负载的识别和信任，而签发 X.509 证书是推荐的一种认证方式1。在 Kubernetes 集群中，服务

我们在进行生产环境部署时得到的一个明确的需求，是Kubernetes用户希望服务部署能够zone、跨区域、跨集群甚至跨云边界（译者：如跨云供应商）。相比单集群多zone部署，跨集群服务提供按地域分布，支持混合云、多云场景，提升高可用等级。客户希望服务能够跨一到多个集群（可能是本地或者远程集群），并希望这些集群无论内部或外部都有一致稳定的连接。 在Kubernetes 1.3版本，我们希望降低跨集群

背景 随着云原生概念的普及，服务网格技术的流行以及 Istio 的成熟，使用Istio 进行服务治理的实践也越来越多，正成为服务治理的趋势。 在这样的背景下，我们也加入到 Istio 的研究中，希望初期通过 Istio 实现公司产品迭代版本的灰度发布，后续基于 Istio 为业务产品提供更多的流量管理及观测追踪能力。 一开始设计 Istio 部署方案时，基于当时对公司产品部署方式的了解，每款产品独

apiserver的list-watch代码解读 list-watch，作为k8s系统中统一的异步消息传递方式，对系统的性能、数据一致性起到关键性的作用。今天我想从代码这边探究一下list-watch的实现方式。并看是否能在后面的工作中优化这个过程。 0. list-watch的需求 上图是一个典型的Pod创建过程，在这个过程中，每次当kubectl创建了ReplicaSet对象后，control

编者按 本文英文原文发布在 CNCF 官方博客 Dapr (Distributed Application Runtime) joins CNCF Incubator 上，译者敖小剑，宋净超参与了审校。另外云原生社区中也成立了 Dapr 小组，欢迎各位爱好者加入。 正文 CNCF 技术监督委员会（TOC）已经投票决定接受 Dapr 作为 CNCF 的孵化项目。 Dapr 是一套使开发者能够轻松编写

作者：Carlos Santana (IBM)、Omer Bensaadon (VMware)、Maria Cruz (Google)，原文发布于 Knative 官方博客。 今天我们发布了 Knative 1.0，达到了一个重要的里程碑，这要归功于 600 多名开发者的贡献和合作。Knative 项目是由谷歌在 2018 年 7 月发布的，并与 VMWare、IBM、Red Hat 和 SAP

模型和动机 Kubernetes从Docker默认的网络模型中独立出来形成一套自己的网络模型。该网络模型的目标是：每一个pod都拥有一个扁平化共享网络命名空间的IP，通过该IP，pod就能够跨网络与其它物理机和容器进行通信。一个pod一个IP模型创建了一个干净、反向兼容的模型，在该模型中，从端口分配、网络、域名解析、服务发现、负载均衡、应用配置和迁移等角度，pod都能够被看成虚拟机或物理机。 另一

本文译自 Istio 官方博客。这是 Istio 在 2021 年发布的最后一个版本，也是本年度发布的第四个版本，Istio 依然在按照它既定的发布节奏发展。 WebAssembly API WebAssembly 是一个重要的项目，开发了 3 年多，为 Istio 带来了先进的可扩展性，允许用户在运行时动态加载自定义构建的扩展。然而，直到现在，配置 WebAssembly 插件一直是实验性的，而

背景资料 在Kubernetes架构图中可以看到，节点（Node）是一个由管理节点委托运行任务的worker。 它能运行一个或多个Pods，节点（Node）提供了运行容器环境所需要的所有必要条件，在Kubernetes之前版本中叫做Minion。 相关结构体 通过下面这张图可以看到在Kubernetes中节点（Node）的相关结构体信息： • 结构体Node：表示Kubernetes中的节点，在节

（一）背景资料 在Kubernetes1.2中这个第三方组件就是go-dockerclient，这是一个GO语言写的docker客户端，支持Dockerremote API，这个项目在https://github.com/fsouza/go-dockerclient中。 在Kubernetes1.3中直接使用docker公司提供的client来实现，通过这个client可以实现同DockerDea