为什么写这篇文章 看到这个标题后，大家可能会问“都已经 2020 年了，Kubernetes 开源有 6 年时间了，为什么还要写一篇 Kubernetes 入门的文章？”我想说的是，Kubernetes 还远远没有达到我们想象的那么普及。众多的开发者，平时忙于各自的业务开发，学习新技术的时间有限；还有大量的学生群体，可能还仅仅停留在“知道有这门技术”的阶段，远远没有入门。这篇文章将助于各位有志于从

Redis 是一个高性能的 key-value 存储系统，被广泛用于微服务架构中。如果我们想要使用 Redis 集群模式提供的高级特性，则需要对客户端代码进行改动，这带来了应用升级和维护的一些困难。利用 Istio 和 Envoy ，我们可以在不修改客户端代码的前提下实现客户端无感知的 Redis Cluster 数据分片，并提供读写分离、流量镜像等高级流量管理功能。 Redis Cluster

本期是 Envoy 系列分享的第一期，在本次分享开始前云原生社区中进行了关于 Envoy 的问卷调查，从问卷结果来看大多数同学都希望了解调试流量这个主题，所以就选了这个主题作为第一次分享。而且大多数同学都是刚开始看 Envoy，所以本次分享也会涉及到很多 Envoy 入门的内容，未来我也会在社区中给大家分享更多 Envoy 的内容。视频回放见 B 站。 Envoy 直播回放地址 此次分享由三部分组

本文译自 NGINX Steps into the Service Mesh Fray Promising a Simpler Alternative。 本月初，NGINX 推出 了 一款服务网格 NGINX Service Mesh（NSM）。它使用了开源 NGINX 代理的商业版本 NGINX Plus 驱动其数据平面。尽管许多服务网格都是基于完全开源的组件构建的，但 NGINX 营销副总裁

本文译自 Zero Trust Cybersecurity:‘Never Trust, Always Verify’。 啊？什么？这是我第一次听到零信任网络安全这个词时候的反应，我是从 2018 年秋天开始在国家标准技术研究所 (NIST) 的国家网络安全中心部门 (NCCoE) 开始工作的。值得注意的是，我有了一个新的开始，同时也是一个巨大的转变，即从通常意义上讲的软件开发工程师转变为网络安全工

由来 和我博客前一篇文章 银河麒麟 arm64 系统上 k8s 集群跨节点不通的一次排查 不一样，从来没遇到过这样的问题，这里记录下。实施在客户那边部署业务后，业务在浏览器上无法访问，我远程上去查看日志发现 pod 内部无法 DNS 无法解析，nginx 连不上 upsteam 报错而启动失败，实际上也是跨节点不通。实际排查过程也有往错误的方向浪费了一些时间和尝试，就不写进来了，以正确的角度写下排

本文译自 Helm Chart Repository Deprecation Update 在 2019 年，当 Helm v2 的支持时间表和 终止计划 被宣布的时候，helm/charts GitHub 仓库 的弃用也同时被宣布。对于弃用的最主要原因是 仓库维护人员 的维护成本显著增加。在过去的几年里，受维护的 charts 数量从约 100 增加到 300 个以上，这也导致了对于仓库的拉取请

本文译自 Istio 官方博客 Expanding into New Frontiers - Smart DNS Proxying in Istio。 DNS 解析是 Kubernetes 上任何应用基础架构的重要组成部分。当你的应用代码试图访问 Kubernetes 集群中的另一个服务，甚至是互联网上的服务时，在发起与服务的连接之前，它必须首先查找服务主机名对应的 IP 地址。这个名称查找过程通

1.8 是 Istio 在 2020 年发布的最后一个版本，按照 Istio 社区在今年初设定的目标继续推进，该版本主要有以下更新： 支持使用 Helm 3 进行安装和升级 正式移除了 Mixer 新增了 Istio DNS proxy，透明地拦截应用程序的 DNS 查询，实现智能应答 新增了 WorkloadGroup 以简化对虚拟机的引入 WorkloadGroup 是一个新的 API 对象，

本文译自：Guidance for Building a Control Plane to Manage Envoy Proxy at the edge, as a gateway, or in a mesh。 这篇文章我看了之后非常想翻译，为什么呢？一方面我也在学习 Envoy，并且在公司的实际项目中使用 Envoy，另一方面，我确实也在设计一个控制管理端来统一管控多个集群的所有流量，没错我说的

今天，我们发布了 Amazon EKS Distro（EKS-D），这是一个基于 Amazon Elastic Kubernetes Service（Amazon EKS）的 Kubernetes 发行版，并由 Amazon EKS 用于创建可靠和安全的 Kubernetes 集群。通过 EKS-D，你可以依赖 EKS 部署的相同版本的 Kubernetes 及其依赖项。这包括最新的上游更新以及扩

本文译自 Envoy 官方文档 What is Envoy Envoy 是为面向大型现代服务架构而设计的 L7 代理和通信总线。该项目源于以下理念： 对于应用来说网络应该是透明的。当网络和应用出现故障时，应该非常容易定位问题发生的根源。 事实上，实现上述的目标非常困难。Envoy 试图通过提供以下高级功能来实现这一目标： 进程外架构：Envoy 是一个独立进程，伴随每个应用服务运行。所有的 Env

Kubernetes 不再是（只是）好玩的游戏了。它正在被用于生产；它是关键任务；所有旧有的安全和合规规则和法规都需要以某种方式加装到 Kubernetes 上。不幸的是，像 RBAC 这样的旧的访问控制工具根本无法应对挑战。 概述 Kubernetes API 的设计与大多数现代 API 不同。 它是基于意图的，这意味着使用 API 的人考虑的是他们想要 Kubernetes 做什么，而不是如何

本文译自 Contributing to the Development Guide 我猜大多数人提到为开源项目做贡献，他们想到的是贡献代码变更、新的功能以及修复缺陷。作为一个长期使用开源应用并贡献了很多代码的软件开发工程师来说，我也确实是这么想的。尽管我已经在同的工作流中贡献了大量的文档，但这么大的 Kubernetes 社区对我来说仍然是个新工作对象。当 Google 要求我的同胞和我在 Li

本文译自 Creating a Cloud Security Policy 任何想要保护他们自己云资产的公司都需要云安全策略。安全策略有助于保持云数据的安全，且能赋予快速应对威胁和挑战的能力。 文章将解释云安全策略的价值。请继续阅读来了解这些策略都包含什么、它们能够带来什么收益以及如何为你的业务作出正确的选择。 什么是云安全策略？ 云安全策略是公司在云运营过程中的一些正式准则。这些指导定义了安全策

在 Envoy 网关和 Service Mesh 服务网格落地过程中，大部分组织和公司几乎不可避免的需要对 Envoy 做一些二次开发和功能增强，以应对自身的个性化需求，只是或多或少的问题。虽然 Envoy 本身基于 L4/L7 Filter 提供了非常灵活可扩展性，可以让开发者在各个层级对 Envoy 进行扩展。然而以现有的 Filter 开发流程太过繁琐沉重。一个简单的功能扩展都需要重新构建整

直到最近，最流行的授权方法是基于角色的访问控制（RBAC）。这种解决方案涉及到创建一套角色，定义组织内所有的工作描述和功能，然后给用户分配角色，决定他们可以访问的内容（例如，文件、网络、应用程序、网页上的一个字段），以及他们可以执行的操作。 当使用 RBAC 时，系统管理员可以控制用户可以对特定的 IT 资源做什么，以及他们可以访问哪些区域。它的实现很简单，因为只有三个基本原则需要牢记，角色是基于

在任何公司，网络用户必须经过认证和授权，才能访问系统中可能导致安全漏洞的部分。获得授权的过程称为访问控制。在本指南中，我将讨论管理系统访问控制的两种主要方法 —— 基于角色的访问控制（RBAC）和基于属性的存取控制（ABAC）它们的差异，以及使用访问权限管理工具的重要性。 认证和授权 安全的两个基本方面是认证和授权。在您输入凭证登录电脑或登录应用程序或软件后，设备或应用程序会进行身份验证，以确定您

本文译自 Envoy 官方文档 HTTP connection management HTTP 连接管理 HTTP 是现代面向服务体系架构的重要组成部分，Envoy 实现了大量的 HTTP 特定功能。Envoy 内置了一个叫 HTTP 连接管理器 的网络层过滤器。 此过滤器将原始字节转换为 HTTP 协议的消息和事件，例如，请求头接收、请求体数据接收、请求标尾 (trailers) 接收等。 过滤

非常有幸参加了云原生社区 Meetup 北京站，有机会和众多业内的大牛一起讨论云原生相关的技术和应用，本次 Meetup 上我和大家分享了关于云原生下的可观测性相关的议题，相关的视频可以移步《B 站视频回放：云原生下的可观测性》回看，本篇文章主要是视频的文字性总结，欢迎大家留言讨论。 可观测性的由来 可观测性最早来自于电气工程领域，主要原因是随着系统发展的逐步复杂，必须要有一套机制用来了解系统内部