本文译自 Service Mesh Comparison: Istio vs Linkerd。 根据 CNCF 的最新年度调查，很明显，很多人对在他们的项目中使用服务网格表现出了极大的兴趣，并且许多人已经在他们的生产中使用它们。将近 69％ 的人正在评估 Istio，64％ 的人正在研究 Linkerd。Linkerd 是市场上第一个服务网格，但是 Istio 的服务网格更受欢迎。这两个项目都是最

注：本文是本人在云原生社区直播分享的内容整理，视频见 B 站，PPT 可以在 GitHub 下载。 Slime是网易数帆微服务团队开源的服务网格组件，它可以作为Istio的CRD管理器，旨在通过更为简单的配置实现Istio/Envoy的高阶功能。目前slime包含三个非常实用的子模块： 配置懒加载: 无须手动配置SidecarScope，按需加载配置和服务发现信息 Http插件管理: 使用新的的C

很荣幸收到 CSDN 的邀请，接受” 云原生人物志 “专栏采访，其实我从 2017 年起就已经在撰写 Kubernetes 和云原生年度总结和新年展望，今天在此聊抒己见，欢迎大家讨论和指正。 云原生在演进 云原生是一种行为方式和设计理念，究其本质，凡是能够提高云上资源利用率和应用交付效率的行为或方式都是云原生的。云计算的发展史就是一部云原生化的历史。Kubernetes 开启了云原生 1.0 的序

Kubernetes 作为 eBay 的统一云平台，统管了在线业务、大数据、搜索后台等多种异构应用。集群数量高达上百，其中的大型集群中，单个集群运行数千个微服务，数十万 Pod。不同类型的应用，针对流量管控的需求也各有不同，如何用一套统一的模型将各种流量管控需求统一起来是 eBay 多年来一直面临的挑战。 以云应用为例，为实现跨数据中心高可用的需求，生产应用的网络拓扑可以简要描述如下： eBay

Problem 网易作为一家拥有众多互联网业务的公司，不同业务结合自身的业务特性、团队组成均有一些微服务技术栈选择、体系建设，这在业务发展初期并没有问题。当业务持续发展，不管业务规模、复杂度、团队的组成都发生了变化，这时候微服务架构就会遇到诸多问题： 各业务分别投入研发，研发成本高 网易集团技术资产无法沉淀 微服务框架对业务侵入性大，需要业务人员明显感知、学习、掌控和维护 升级周期长，即使是很小版

2020 年是云原生社区的起步之年，感谢所有云原生社区的参与者和合作伙伴们！在此新春佳节之际，祝大家新春快乐，万事如意！ 下面我们一起回顾下云原生社区在过去一年来的进展，同时感谢社区讲师、贡献者、志愿者、SIG 负责人和城市站站长。 城市站 云原生社区相继成立了北京站、上海站、成都站、深圳站、南京站、杭州站等 20 个城市站。 北京站 社区由核心成员罗广明、王殿进、王福印来组织与筹划社区发展与线下

本文为翻译文章，点击查看原文。 Istio 1.9 版本的重点是改善用户在生产中运行 Istio 的 Day2 操作。在用户体验工作组收集到的反馈意见的基础上，我们希望改善用户的稳定性和整体升级体验。稳定性的一个关键是明确 Istio 核心 API 和功能发布的功能状态，并增强它们的稳定性，使用户能够放心使用 Istio 的这些功能，这是 1.9 版本的另一个重点。 请关注我们的博客，了解我们的

背景 Istio 作为当前最活跃的 service mesh 项目，提供着众多的能力，流量管理，安全性，可观察性，每一项能力都是服务治理，运维所必需的。Istio 丰富的能力同时也带来一定性的复杂系统运维的挑战，但是相对于能力以及未来的扩展性，Istio 能力给服务治理带来了无限的想象，机遇同时充满着挑战。 当前涂鸦智能前端业务 Istio 控制面版本为 1.5.0，接入 Istio 控制面 70

前言 随着业务的快速发展，技术部门的组织架构在横向及纵向不断扩大和调整，与此同时，企业的生产资料：应用系统，也变得越来越庞大。为了让应用系统适配企业组织架构的调整，梳理组织架构对于应用权责的边界，大部分组织会选择使用“微服务”架构来对应用系统进行横向拆分，使得应用系统的维护边界适配组织架构的权责边界。 一般来说，越庞大的组织架构，应用系统会被拆分地越来越细，“微服务”的数量也变得越来越多。而在“微

本文为我跟 Ignasi Barrera 共同创作，本文英文版首发于 TheNewStack。 不同的公司或软件供应商已经设计了无数种方法来控制用户对功能或资源的访问，如酌情访问控制（DAC）、强制访问控制（MAC）、基于角色的访问控制（RBAC）和基于属性的访问控制（ABAC）。从本质上讲，无论何种类型的访问控制模型，都可以抽象出三个基本要素：用户、系统 / 应用和策略。 在本文中，我们将介绍

本文来自酷家乐先进技术工程团队，作者罗宁，酷家乐资深开发工程师。 公司背景 酷家乐公司以分布式并行计算和多媒体数据挖掘为技术核心，推出的家居云设计平台，致力于云渲染、云设计、BIM、VR、AR、AI 等技术的研发，实现“所见即所得”体验，5分钟生成装修方案，10秒生成效果图，一键生成 VR 方案的 SAAS 云端软件服务平台。 核心问题 公司快速增长的业务需求，使得支持各开发语言的 Serverl

Istio 是云原生世界中最受欢迎、发展最迅速的开源项目之一；虽然这种增长充分说明了用户从 Istio 中获得的价值，但其快速的发布节奏对于用户来说也是一种挑战，因为他们可能要同时管理多个不同版本的 Istio 集群，并为云平台手动配置 CA 证书。 概述 我们今天推出了一个名为 GetIstio 的新开源项目，为用户提供了安装和升级 Istio 的最简单方法。GetIstio 提供了一个经过审核

前言 2021 年伊始，如果你想要在生产环境中落地 Service Mesh，那 Istio 一定已经在你的考虑范围之内。 Istio 作为目前最流行的 Service Mesh 技术之一，拥有活跃的社区和众多的落地案例。但如果你真的想在你的生产环境大规模落地 Isito，这看似壮观美好的冰山下，却是暗流涌动，潜藏着无数凶险。 本文是笔者深度参与百亿量级流量生产环境研发和落地 Istio 两年来的

背景 要想深入学习 istio，还得学习下数据面的实现，istio 的数据面使用了 envoy，在 istio group 下有个叫 proxy 的仓库，包含了一些 istio 用到的一些 envoy 扩展，编译时将 envoy 代码作为库来引用，最终使用 bazel 编译出 istio 版本的 Envoy。 代码量非常庞大，如果没有智能的代码跳转、查找引用与实现，阅读和开发起来简直低效的要命。如

本文根据腾讯云赵化冰和知乎唐阳在 IstioCon 2021 中的演讲 “How to Manage Any Layer-7 Traffic in an Istio Service Mesh?” 整理而成。 大家好，今天我们想和大家分享的主题是如何扩展 Istio 以支持任何七层协议？作为云原生领域中一个人气非常高的开源项目， Istio 目前已经基本成为了 Service Mesh 的事实标准。

本文译自 Cloud-Native Is about Culture, Not Containers，文章洋洋洒洒上万字，作者总结了她见过的云原生失败的各种经验教训，还用生动的示例说明了什么不是云原生。译者是在周末闲暇时间仓促间翻译的，其中难免有不当之处，请读者指正。 本文主要观点： 不需要一味的微服务，就可以做到非常的云原生。 在开始云原生转型之前，必须明确云原生对你的团队意味着什么，以及要解决

近期，腾讯云 CODING DevOps 开源了云原生开发环境 - Nocalhost。 根据官方文档介绍，Nocalhost 来源于 No Localhost，其含义是开发者不再依赖本地计算机的编码、调试和测试过程。他是一个云原生开发环境，旨在解决云原生下开发难的问题。 例如，在 Kubernetes 环境下进行微服务开发，通常会面临以下问题： 每次修改代码，都需要经过构建映像->推送映像

本文译自 The Evolution of Distributed Systems on Kubernetes。 在 3 月份的 QCon 上，我做了一个关于 Kubernetes 的分布式系统进化的演讲。首先，我想先问一个问题，微服务之后是什么？我相信大家都有各自的答案，我也有我的答案。你会在最后发现我的想法是什么。为了达到这个目的，我建议大家看看分布式系统的需求是什么？以及这些需求在过去是如何

本文翻译自 To Multicluster, or Not to Multicluster: Inter-Cluster Communication Using a Service Mesh。Istio 服务网格是解决 Kubernetes 集群间通信的一个关键，虽然翻译这篇文章距离原文发表也有快 2 年时间了，但是其中的很多观点仍不过时。 主要观点 Kubernetes 已经成为容器编排的事实标

本文译自 Using Traefik Ingress Controller with Istio Service Mesh。 Istio 服务网格自带 ingress，但我们经常看到有要求使用非 Istio ingress 的客户。此前，我们已经介绍过将 NGINX 与 Istio 集成的情况。最近，我们一直在与使用 Traefik ingress 的客户合作。通过对我们之前建议的方法进行一些轻微