index.json

[{"content":"Istio 兴趣小组主要关注 Istio 服务网格。\n参考资料 Istio 官方中文文档 Istio 大咖说（视频分享） Istio Workshop（视频教程） 负责人 宋净超 ","relpermalink":"/community/sig/istio/","summary":"Istio SIG.","title":"Istio 兴趣小组"},{"content":" 成员须知\n好的社区环境需要我们大家共同维护，请你在加入云原生社区后阅读本指南，将有助于你参与到社区中来。 社区指南 如何加入社区\n参与社区的方式\n社区守则\n云原生社区直播间\n投稿指南\n特别兴趣小组\n城市站\n联系我们\n加入社区 ","relpermalink":"/community/","summary":"本指南将指导你如何参与云原生社区。","title":"社区参与指南"},{"content":"云原生社区直播间经常进行云原生相关技术交流和分享。\n关注我们的直播间：\nBilibili：云原生社区 微信视频号：云原生社区 ","relpermalink":"/community/academy/","summary":"云原生社区直播间。","title":"云原生社区直播间"},{"content":"本节记录了 Istio 的版本变更。\n历史版本追踪 下面是对 Istio 历史版本发布的追踪表格。\n版本 发布时间 可用性 环境 API 性能 评论 0.1 2017-05-24 仅支持 HTTP，仅支持单 namespace，使用命令修改应用的 YAML 配置的方式注入 sidecar。 仅支持 Kubernetes 流量管理确立了 RoutingRule、DestinationPolicy。 无 正式开源，该版本发布时仅一个命令行工具。确立了功能范围和 sidecar 部署模式，确立的 Envoy 作为默认 sidecar proxy 的地位。 0.2 2017-10-10 支持 TCP，支持自动注入 sidecar，支持自定义 mixer 扩展，支持自定义秘钥和证书给 Istio CA，支持 WebSocket、MongoDB 和 Redis 协议。 支持 Nomad、Consul、Eureka、Cloud Foundry、Mesos，通过 Mesh expansion 的方式开始支持虚拟机 流量管理新增了 EgressRule。 无 近五个月时间才发布了新版本，对于一个新兴的开 …","relpermalink":"/community/sig/istio/release/","summary":"对 Istio 历史版本变更追踪的概述。","title":"Istio 版本变更"},{"content":"文章收录来源分为三类：原创、翻译、转载。\n原创：管理员会对投稿文章质量做一定的考察，必要的情况下，作者需要联系社区管理员提供相关个人背景信息；对于长期投稿或知名度较高的作者，我们将邀请成为社区的特邀作者，审核和评审流程时间会相应减短。 翻译：鼓励多提供高质量文章线索，管理员会简要浏览全文考察文章质量和讨论的话题，辨别并过滤掉低质量文章和广告软文；另外，管理员会尽量同原文作者取得联系，通知作者我们翻译了他的文章；避免翻译来自其它社区或科技媒体发表的文章，除非获得官方授权。 转载：个人博客博主和公众号可以对我们的微信公众号开通白名单，管理员会定期挑选转载相关文章；也可以通过 PR 提出相关文章转载请求。 向社区投稿前请先阅读下面的贡献者协议，一旦向社区提交 PR 代表您已同意该协议。\n贡献者协议 定义 “社区”是指云原生社区。 “文章”是指向云原生社区投稿的文章。 “作者”是指文章署名的作者。 “读者”是指阅读社区发布的文章的人。 “社区官网”是指 https://cloudnative.to。 “官网 Github”是指 cloudnativeto/cloudnative.to。 投稿原 …","relpermalink":"/community/contribute/","summary":"向社区投稿指南。","title":"投稿指南"},{"content":"特别兴趣小组（Special Interest Group，以下简称 SIG）为社区根据成员兴趣自发组织的学习小组，目前已成立的兴趣小组有：\nIstio SIG\n","relpermalink":"/community/sig/","summary":"云原生社区特别兴趣小组（SIG）。","title":"特别兴趣小组"},{"content":"为了方便云原生社区成员的线下交流以及后期本地站活动开展，云原生社区城市站计划在全球各地创建城市站长，站长负责本地活动组织，目前已创建的城市站及代理站长如上图，点击对应站的链接，可加入城市站。每个城市最多有 3 位站长，目前为代理站长，最终人选还待确定。还有其他城市的伙伴们想要担任各自城市的代理站长，可以联系 Jimmy。\n城市站列表 目前已正式成立的城市站有：\n北京站\n上海站\n广州站\n深圳站\n成都站\n大连站\n南京站\n杭州站\n合肥站\n济南站\n青岛站\n厦门站\n苏州站\n无锡站\n武汉站\n西安站\n长沙站\n郑州站\n重庆站\n珠海站\n","relpermalink":"/community/city/","summary":"云原生社区城市站信息。","title":"城市站"},{"content":"Istio（ISS-tee-oh）是由 Tetrate 创始人 Varun Talwar 和谷歌首席工程师 Louis Ryan 在 2017 年命名的，当时他们都在谷歌工作。\nIstio 在希腊语中是“sail”的意思，它（ιστίο）延用了 Kubernetes（在希腊语中是飞行员或舵手的意思）建立的希腊航海主题。Istio 和它的表亲 Istos（ιστός）（意思是桅杆、网）都来自古希腊词根 Istimi（ἵστημι），意思是“to make stand”。\n“为了取名，我们翻阅了三个小时希腊字典”Varun 说，“最终我们两人想到一起去了。帆船的理念不仅在于谁在控制船，而是没有船你哪儿也去不了。“\nVarun 回忆说 10 个候选名称最后被缩减到 3 个，但命名 Istio Github 仓库的实际需求要求他们快速做出最终决定。\nIstio 现在的网址是 istio.io，“io”的重复是值得商榷。就其本身而言，“io”有很多含义，包括 ionium（锾元素）的缩写、以古代宙斯的情人命名的木星卫星，以及得名于印度洋的互联网顶级域名。我们也注意到 io 是 Ino（奥德赛中的 …","relpermalink":"/community/sig/istio/how-istio-got-its-name/","summary":"本文将为大家介绍 Istio 名称的来历。","title":"Istio 名称的来历"},{"content":"北京站简介 北京站成立于 2020 年 8 月，社区成员数百人。北京站作为云原生总部分站，致力于汇聚北京当地优秀云原生人才，连接云原生开源社区与开发者，促进云原生技术的交流和推广！\n站长 罗广明 王殿进 北京站徽章 北京站徽章 北京站徽章来自于天坛与 Kubernetes Logo 的融合。天坛是北京的标志建筑，不仅具有丰厚的历史底蕴，还具有精神的象征。如今如火如荼的云原生技术也正值青春，活力尽现，两者结合相得益彰。我们社区将连接沟通北京的 IT 与云原生，共同促进云原生的落地与繁荣。\n","relpermalink":"/community/city/beijing/","summary":"云原生社区北京站。","title":"北京站"},{"content":"你有很多种方式（详见 参与社区的方式）参与社区，最直接的方式就是加入云原生社区微信群，本文将指导你如何加入社区群。\n加入社区微信群 入群须知\n加入社区，意味着您同意遵守 社区守则。 云原生社区微信群采取注册制，请转到腾讯问卷申请，或直接填写下面的问卷，进行实名登记 1 。\n腾讯问卷 请仔细填写下面的腾讯问卷，一次只能选择加入一个群。\n若本页中的腾讯问卷加载失败，请点击这里直接跳转到问卷页面。\n入群助手 填写问卷后请添加入群助手微信，微信搜索 yyssq1 或扫描下面的二维码添加。\n入群助手二维码 期待在社区群里与你相遇。\n备注 我们建议您实名登记，成员名单仅管理员可见，社区承诺不会将您的个人信息公开给任何第三方。 ↩︎\n","relpermalink":"/community/join/","summary":"本文将指导你加入云原生社区微信群。","title":"如何加入社区"},{"content":"云原生社区定期举办线上直播，邀请云原生技术大咖为大家分享。\n直播历史归档 以下是云原生社区在 B 站直播的历史视频回放。\n期数 日期 标题 讲师 回放 33 2022-07-12 新一代云原生分布式存储 Curve 李小翠 视频 32 2022-06-08 云原生日志采集系统 Loggie 设计与实现 郭琪文 视频 31 2022-05-27 eBPF 技术在云原生的应用 狄卫华 视频 30 2022-05-11 MetaFlow 高度自动化的可观测性平台 向阳 视频 29 2022-01-20 PPIO 边缘云的云原生应用实践 蒋鑫 视频 28 2022-01-19 云原生事件网格 Apache EventMesh（Incubating）入门 薛炜明 视频 27 2021-12-22 云原生产品与架构系列讲座第 4 讲：云原生赋能 AIoT 和边缘计算、云形态以及成熟度模型之道 高磊 视频 26 2021-12-21 FreeWheel 云原生应用实践 马若飞 视频 25 2021-12-08 云原生应用可观测性实践 向阳 视频 24 2021-12-01 云原生产品与架构系列第 3 …","relpermalink":"/community/academy/webinar/","summary":"云原生社区线上直播日程表。","title":"直播日程表"},{"content":"在用户将应用部署到 Kubernetes 上之后，如何管理容器之间的流量及确保应用的安全性，就成了突出问题，Service Mesh 的出现就是为了解决这一问题。在 Istio 开源之前，市场上只有创业公司 Buoyant 一家的 Service Mesh 产品 Linkerd，2017 年正值 Kubernetes 赢得容器编排之战，云原生社区中急需找到新的增长点，有人开始叫嚣“Kubernetes is becoming boring”，Service Mesh 开始抬头，Istio 的推出更使得该领域急剧升温。\n2017 年 5 月 24 日，Google、IBM 和 Lyft 发布了 Istio 0.1。Istio 基于 Envoy 构建，在开源之初就确立的链接、保护、控制和观测”微服务”的使命。（注意，“微服务”后来在 Istio 的官网描述中被改成了服务，）该版本只支持 Kubernetes 环境，并计划在接下来的几个月添加诸如虚拟机和 Cloud Foundry 等环境的支持。计划每三个月发布一个大版本。\n该版本发布时仅一个命令行工具 istioctl，但是它的意义是划时 …","relpermalink":"/community/sig/istio/release/01/","summary":"2017 年 5 月 24 日，Istio 正式开源。","title":"Istio 0.1——开启 Service Mesh 的新纪元"},{"content":"本指南为云原生社区博客风格指南。主要目的为：\n提高中文文案可读性 统一文档风格，保证社区投稿对外输出风格一致 避免不同的文档作者对同一问题反复作出决策，降低与文档相关的沟通成本 文件头 文件头部配置为 Hugo 静态网站编译所必须的，所有投稿文章都需要在投稿文件的头部添加文件头（文件头前后使用三个短横线“-”），例如：\n--- title: \u0026#34;文章标题\u0026#34; date: 2020-06-09T06:00:00+08:00 summary: \u0026#34;对本文的摘要或者描述。\u0026#34; authors: [\u0026#34;张三\u0026#34;,\u0026#34;李四\u0026#34;] translators: [\u0026#34;张三\u0026#34;,\u0026#34;李四\u0026#34;] categories: [\u0026#34;Kubernetes\u0026#34;] tags: [\u0026#34;Kubernetes\u0026#34;, \u0026#34;源码分析\u0026#34;] links: - icon: language icon_pack: fa name: 阅读英文版原文 url: https://www.example.com --- 其中：\ntitle: 表示投稿的标题，例如：社区投稿风格指南。 date: 表示投稿的时间，使用 RFC3999 格式，例 …","relpermalink":"/community/contribute/style/","summary":"本指南为社区投稿提供了一套风格指南规范。","title":"社区投稿风格指南"},{"content":"在此之前，Istio 官方文档已经进行了两轮中文翻译活动，第一轮是在 2018 年，基于 Istio 0.8，第二轮是在 2020 年，基于 Istio 1.5，截止目前 Istio 已发布了 1.9 版本，Istio 中文文档已经有长达一年的时间疏于维护，现在云原生社区 Istio SIG 决定重启中文文档的维护。\n常用链接 Istio 中文文档地址：https://istio.io/zh 登记及任务认领表：Google Spreadsheet Istio 官网 GitHub 仓库：https://github.com/istio/istio.io 负责人 下面是云原生社区 Istio Doc WG 的负责人：\n宋净超（@rootsongjc） 刘齐均（@kebe7jun） 殷龙飞（@loverto） 邱世达（@SataQiu） 刘训灼（@Xunzhuo） 在参与过程中有任何问题可以与他们联系。\n如何参与 本次活动由云原生社区 Istio Doc WG 主办，参与活动需要你准备以下内容。\n准备 GitHub 你需要一个 GitHub 账号，翻译文档需要通过 GitHub 提交 PR， …","relpermalink":"/community/sig/istio/istio-doc-translation/","summary":"本文将为指导你如何参与到 Istio 官方文档翻译活动中来。","title":"Istio 官方文档翻译活动"},{"content":"你有很多种方式参与社区，例如：\n浏览云原生社区官网（即本网站），评论 1 或转发到社交媒体； 加入社区微信群，选择你感兴趣的领域，与社区成员交流； 关注「云原生社区动态」微信公众号，点赞、评论、转发，让更多人看到我们社区； 关注云原生社区 B 站，观看直播和视频回放，点赞、评论、转发； 参与云原生社区组织的线下活动； 参与云原生社区组织的线上活动，例如征稿、翻译等； 成为云原生社区志愿者，一起参与到社区建设中来； 将云原生社区告诉你的同事、好友，一起参与进来； 备注 社区官网使用 giscus 评论系统，你需要使用 GitHub 账号登录才可以评论。 ↩︎\n","relpermalink":"/community/involve/","summary":"本文将指导你通过多种方式参与社区。","title":"参与社区的方式"},{"content":"上海站简介 云原生社区上海站成立于 2020 年 8 月，立足于上海国际金融中心，目前拥有本地成员 200 多人。我们致力于汇聚上海优秀云原生人才，连接云原生开源社区与开发者，通过丰富多样化的社区交流与线下互动活动，促进云原生技术知识的分享、推广和实践！同时我们热烈欢迎上海云原生技术企业的加入，积极参与云原生社区的建设、知识分享等。\n主要成员 郭旭东 张海立 申红磊 刘德涵 沈旭 任增刚 上海站徽章 上海站徽章 上海站专属 Logo 融合上海市地标“东方明珠“，寓意立足上海这个国际化金融中心，以社区化的方式布道云原生。整体形象是融合上海著名地标建筑东方明珠，本意立足上海，叠加 Kubernets、云等元素，寓意发挥上海云原生社区优势普及云原生技术并形成云原生技术的知识“辐射” 。\n","relpermalink":"/community/city/shanghai/","summary":"云原生社区上海站。","title":"上海站"},{"content":"本文面向直播间主持人及直播操作人员，将指导你如何在云原生社区中开展直播。\n准备 你需要准备以下设备、资源或账号：\n电脑 耳机 腾讯会议软件及账号（可以用微信登录） canva.cn 账号（用于编辑设计资源） OBS：用来做推流，到官网下载最新的版本 音频插件 Sunflower：点击跳转到下载页面，如果安装时遇到系统权限问题，在 macOS 中请在命令行中执行 sudo spctl --master-disable 并在电脑的 系统首选项 的 安全与隐私 中批准来自任意途径的软件安装，如果看到有详情页面，点击进去批准软件发行商 设计资源 直播前需要设置直播间封面，发送公众号直播预告推文。以下是所需的设计资源地址：\n公众号、B 站、直播预告推文、PPT 封面及封底 视频号直播间封面 OBS 直播底板 常用链接 云原生社区 B 站主页 视频号登录页面 互动问答腾讯文档 直播 PPT 归档地址 注意事项 关于 B 站、视频号的权限请联系 Jimmy 获取 在直播开始前需要设置好 B 站和视频号直播间的标题及封面 讲师的 PPT 需要增加社区指定封面及封底并在直播开始前上传到 GitHub 直 …","relpermalink":"/community/academy/manual/","summary":"云原生社区直播操作手册。","title":"直播操作手册"},{"content":"在等待了近 5 个月之久，Istio 0.2 版本终于面世。Istio 从 0.2 版本的发布开始支持虚拟机负载。初步支持将非 Kubernetes 服务（以 VM 或物理机的形式）添加到网格中。这是此功能的早期版本，存在一些限制（例如，要求在容器和 VM 之间建立扁平网络）。\n其他改进主要是关于可用性方面，例如支持 TCP，利用 Kubernetes 的 admission webhook（alpha 特性）支持自动注入 sidecar，支持自定义 mixer 扩展，支持自定义秘钥和证书给 Istio CA，支持 WebSocket、MongoDB 和 Redis 协议。\n参考 宣布 Istio 0.2——改善网格并支持多种环境 - istio.io ","relpermalink":"/community/sig/istio/release/02/","summary":"2017 年 10 月 10 日，Istio 0.2 发布，改善网格并支持多种环境。","title":"Istio 0.2——开始支持虚拟机"},{"content":"本指南为云原生社区成员参与官网投稿 Review 提供统一规范。主要目的为保证投稿质量，本规范主要从以下几方面规范投稿内容：\n专业性 准确性 可读性 排版统一 Reviewer 标准 所有投稿稿件的 Reviewer 需要为相关专业资深人士。 Reviewer 需要具备一定的技术写作经验，深谙技术文档规范，语言功底比较好。 Reviewer 具备了相应的经验、能力和意识。 当投稿人对 Reviewer 提出的评论有异议时，有权要求审查 Reviewer 的资格。\nReview 标准 稿件拒绝范围 云原生社区接受的文章投稿需要是与云原生技术相关的专业文章，不约束具体细分领域。\n除以下文章不接受投稿外，原则上不拒绝其他投稿：\n其他技术文章内容洗稿。 文章无实质内容，东拼西凑。 内容组织 正文内容是否与标题相符 结构上是否符合逻辑 结构上是否清晰明确、用户友好 结构上是否缺失必要的内容 结构上是否存在赘余 某部分正文是否可重新组织以更易用 不能包含明显的技术歧视和偏向，侧重阐述客观事实 提出引起思考的观点，回避可能引起争论的点 专业术语 专业术语符合行业通用准则 翻译文章的专业术语符合常用翻 …","relpermalink":"/community/contribute/review/","summary":"本指南为参与云原生社区投稿审阅提供统一规范。","title":"社区投稿审阅指南"},{"content":"《Istio 大咖说》是由企业级服务网格提供商 Tetrate 冠名的以 Istio 和服务网格为主题的在全球性直播节目《Istio Weekly》的一部分。《Istio 大咖说》旨在分享 Istio 相关的开源技术及实践，开播于 Istio 开源四周年之际（2021 年 5 月 25 日），本节目定期邀请 Istio 和服务网格领域的专家参加直播与观众互动。\n资源 直播间地址：Bilibili - 《Istio 大咖说》 历史视频回看：Bilibili - IstioServiceMesh 幻灯片归档地址：GitHub 第一期：Istio 开源四周年回顾与展望 时间：2021 年 5 月 25 日晚 8 点 嘉宾：马若飞（FreeWheel） 嘉宾介绍：《Istio 实战指南》作者、极客时间《Service Mesh 实战》专栏作者、AWS Container Hero 视频回放：《Istio 大咖说》第 1 期：Istio 开源四周年回顾与展望 想了解 Istio 的来历吗？想知道 Istio 自我救赎般的架构重构吗？想窥探 Istio 开发背后的趣事吗？想一起解读最新版本的新特性 …","relpermalink":"/community/sig/istio/istio-big-talk/","summary":"本文将为大家介绍 Istio 名称的来历。","title":"Istio 大咖说"},{"content":"广州站简介 广州站成立于 2020 年 8 月，社区成员 100 多人。我们致力于汇聚广州当地优秀云原生人才，连接云原生开源社区与开发者，通过举办丰富的线上和线下的活动，促进云原生技术交流和推广！同时我们欢迎广州云原生企业和开发者加入，积极参与共建社区。\n站长 张晓辉 周继海 韦正清 广州站徽章 广州站徽章 广州站专属 Logo 融合了地标建筑广州塔和 Kubernetes Logo。\n广州塔，广州新八景之一，也是广州精神的象征。寓意广州社区以开放、进取、拼搏的态度拥抱云原生，促进云原生的繁荣。\n","relpermalink":"/community/city/guangzhou/","summary":"云原生社区广州站。","title":"广州站"},{"content":"欢迎作为云原生社区的参与者，为了建立一个开放和受欢迎的社区，我们保证尊重所有通过报告问题、发布功能请求、更新文档、提交拉取请求或补丁以及其他活动做出贡献的人员。\n我们致力于让参与此社区的每个人都不受骚扰，无论其经验水平、性别、性别认同和表达、性取向、残疾、个人外貌、体型、人种、种族、年龄、宗教或国籍等。\n社区行为规范 您需要阅读并同意相关政策条款方可以加入社区，即加入社区意味着您同意本条款。\n您不得发布、传播含有下列内容的信息：\n反对宪法所确定的基本原则的； 危害国家安全，泄露国家秘密，颠覆国家政权，破坏国家统一的； 损害国家荣誉和利益的； 煽动民族仇恨、民族歧视，破坏民族团结的； 破坏国家宗教政策，宣扬邪教和封建迷信的； 散布谣言，扰乱社会秩序，破坏社会稳定的； 散布淫秽、色情、赌博、暴力、凶杀、恐怖或者教唆犯罪的； 侮辱或者诽谤他人，未经他人同意泄露他人隐私或个人信息，侵害他人合法权益的； 以侮辱、诽谤或者其他方式侵害英雄烈士的姓名、肖像、名誉、荣誉，歪曲、丑化、亵渎、否定英雄烈士事迹和精神的； 煽动非法集会、结社、游行、示威、聚众扰乱社会秩序的； 违反国家有关规定，发布系统漏洞、 …","relpermalink":"/community/policy/","summary":"云原生社区成员行为规范。","title":"社区守则"},{"content":"也许 Istio 团队意识到了从 0.1 到 0.2 版本的发布之间的时间跨度太久（近 5 个月），本次版本发布距离 0.2 版本仅 1 个多月时间，Istio 团队承诺接下来将每月发布一个版本，实际上在接下来的 8 个月里，Istio 一共发布了 6 个版本，基本实现了承诺。\n本次版本发布并没有什么重大更新。\n参考 Istio 0.3 发布公告——重大更新 - istio.io ","relpermalink":"/community/sig/istio/release/03/","summary":"2017 年 11 月 29 日，Istio 0.3 发布，改进发布节奏。","title":"Istio 0.3——改进发布节奏"},{"content":"深圳站简介 深圳站成立于 2020 年 8 月，社区成员近 300 人。我们致力于汇聚深圳当地优秀云原生人才，连接云原生开源社区与开发者，通过举办丰富的线上和线下的活动，促进云原生技术交流和推广！同时我们欢迎深圳云原生企业和开发者加入，积极参与共建社区。\n站长 厉辉 王炜 深圳站徽章 深圳站徽章 深圳站徽章来自于地王大厦与 Kubernetes Logo 的融合。\n地王大厦是深圳经济特区的标志性建筑，其建筑速度是深圳精神的象征，希望深圳站能够发挥特区精神，在云原生领域带领深圳技术人共建社区，连接深圳的技术和云原生，共同促进云原生技术繁荣。\n","relpermalink":"/community/city/shenzhen/","summary":"云原生社区深圳站。","title":"深圳站"},{"content":"距离上个版本发布仅 2 个多周，无重大更新，主要在平台和安装方式上增加了更多选项。支持 Helm Chart 安装和 Cloud Foundry 平台。\n参考 Istio 0.4 发布公告——重大更新 - istio.io ","relpermalink":"/community/sig/istio/release/04/","summary":"2017 年 12 月 18 日，Istio 0.4 发布，支持 Helm Chart 安装和 Cloud Foundry 平台。","title":"Istio 0.4——新增平台支持"},{"content":"成都站简介 云原生社区成都站成立于 2020 年 8 月，立足于成都高新区，目前拥有本地成员 200 多人。希望围绕云原生社区开展丰富多彩的互动活动。不管你从事何种行业、岗位，只要你爱好云原生技术，我们都热烈欢迎你加入成都站，让我们一起促进云原生技术知识的分享、推广和实践！\n主要成员/站长 粟伟 龙恒 成都站徽章 成都站徽章 成都站专属 Logo 融合国宝熊猫，寓意立足成都这个开放的国际城市，以社区化的方式布道云原生。\n整体形象是融合著名国宝熊猫，本意立足成都，叠加 Kubernets、云等元素，寓意发挥成都云原生社区希望与国际接轨，普及云原生技术。\n","relpermalink":"/community/city/chengdu/","summary":"云原生社区成都站。","title":"成都站"},{"content":"该版本主要增强易用性，相对于 Istio 初期一键安装所有组件的情况，现在 Istio 用户渐渐式采用，可以只安装 Istio 的部分组件。Istio 利用 Kubernetes 1.9 及以上版本的 muting webhook 特性，支持自动注入 sidecar。\n参考 Istio 0.5 发布公告——重大更新 - istio.io ","relpermalink":"/community/sig/istio/release/05/","summary":"2018 年 2 月 2 日，Istio 0.5 发布，支持渐渐式安装，支持使用 Kubernetes 的新特性实现 sidecar 自动注入。","title":"Istio 0.5——对用户采用更友好"},{"content":"大连站简介 大连站成立于 2020 年 9 月，有核心组织者 9 人，社区活跃人数数百人。曾多次举办各种线上线下活动。致力于汇聚优秀人才，活跃大连的 IT 氛围，推广云原生技术！\n主要成员/站长 马景贺 李震 大连站徽章 大连站徽章 大连站徽章既融合了大连特色，又包含云原生生态发展的多重寓意。\n整体形象是大连地标：星海 星海湾大桥（Bridge）：有链接的意思，寓意链接社区与开发者 Kubernetes 的 logo 和满天的繁星：寓意 Kubernetes 和其周边的生态 ","relpermalink":"/community/city/dalian/","summary":"云原生社区大连站。","title":"大连站"},{"content":"该版本主要是常规更新，无重大变更。\n参考 Istio 0.6 发布公告——重大更新 - istio.io ","relpermalink":"/community/sig/istio/release/06/","summary":"2018 年 3 月 8 日，Istio 0.6 发布，该版本主要是常规更新，无重大变更。","title":"Istio 0.6——常规更新"},{"content":"南京站简介 南京站成立于 2020 年 9 月，目前拥有本地社群成员 100 多人，聚集了一群对云原生技术感兴趣的朋友，线上我们一起讨论技术、交流想法，线下我们经常组织聚会活动。大家的目标是在娱乐中学习，在学习中进步。从而推广南京云原生技术社群，活跃的氛围，吸引更多热衷研究云原生技术的朋友，相继加入，让我们的队伍越来越壮大！\n主要成员/站长 金润森 朱慧君 南京站徽章 南京站徽章 南京站徽章来自于南京新地标“南京眼”与 Kubernetes Logo 的融合。\n“南京眼”步行桥源于青奥会，象征着青春与活力，如今如火如荼的云原生技术也正值青春，活力尽现，两者结合相得益彰。我们社区将起着南京眼一样的作用，连接沟通着南京的 IT 与云原生。\n","relpermalink":"/community/city/nanjing/","summary":"云原生社区南京站。","title":"南京站"},{"content":"该版本主要改进构建和测试基础架构并提高测试质量，并预告了 0.8 版本的重大更新，且是 API 层面的更新。\n参考 Istio 0.7 发布公告——重大更新 - istio.io ","relpermalink":"/community/sig/istio/release/07/","summary":"2018 年 3 月 28 日，Istio 0.7 发布，主要提供测试质量。","title":"Istio 0.7——改进测试质量"},{"content":"杭州站简介 云原生社区杭州站成立于 2020 年 6 月，目前社群成员 200 多人，大家拥有着共同对云原生技术的热情，一起讨论技术、行业发展，不定时组织聚会活动，加深交流，共同成长，共同进步，在学习中进步。不管你是已经在杭州，还是刚来杭州，只要你热爱云原生技术，就可以加入我们，加入杭州站！！！\n主要成员/站长 杨宙 杭州站徽章 杭州站徽章 ","relpermalink":"/community/city/hangzhou/","summary":"云原生社区杭州站。","title":"杭州站"},{"content":"该版本带来了重大的 API 级别的变更，新引进了 v1alpha3 路由 API，该 API 不向前兼容！确立了沿用至今的 Gateway（新引入，不在支持 ingress、egress 代理）、VirtualService（取代了原先的 RouteRule）、DestinationRule（取代了 DestinationPolicy）、ServiceEntry（取代了 EgressRule）等资源类型。重命名了安全模块，以前的 Istio-Auth 或者 Istio-CA 现在被统称为 Citadel。\n参考 Istio 0.8 发布公告——重大更新 - istio.io ","relpermalink":"/community/sig/istio/release/08/","summary":"2018 年 6 月 1 日，Istio 0.8 发布，API 级别的变更，堪称 1.0。","title":"Istio 0.8——1.0 的前奏"},{"content":"2 个月前发布的 0.8 版本已经为 1.0 的发布做好大量的前置工作，经过这 2 个月的时间，0.8 版本的众多 alpha 功能现在变成了 beta，新增了支持将多个 Kubernetes 集群添加到单个 mesh 集群中。\n在此之前社区对于 Istio 的性能质疑声不断，本版本对 Istio 的性能做了大量优化，虽然号称生产就绪，但是此时还没有充足的生产案例。\n参考 Istio 1.0 发布公告——Service Mesh 生产就绪 - istio.io ","relpermalink":"/community/sig/istio/release/10/","summary":"2018 年 7 月 31 日，Istio 1.0 发布，API 更加稳定，支持多 Kubernetes 集群。","title":"Istio 1.0——生产就绪"},{"content":"距离 1.0 版本发布已经过去快 7 个月了，虽然越来越多的公司在生产中使用 Istio，但是一些大型公司在尝试使用 Istio 的过程中，遇到了一些瓶颈。此版本主要是优化性能，新增配置管理组件 Galley，新增了 sidecar 资源，可以更精细地控制附加到命名空间中工作负载的 sidecar 代理的行为。使用 RedHat 开发的 Kiali 替换了 Istio 原先使用的 ServiceGraph 插件。\n参考 Istio 1.1 发布公告——Service Mesh 生产就绪 - istio.io ","relpermalink":"/community/sig/istio/release/11/","summary":"2019 年 3 月 19 日，Istio 1.1 发布，API 更加稳定，支持多 Kubernetes 集群。","title":"Istio 1.1——企业就绪"},{"content":"该版本属于常规发布，主要在测试和发布机制上进行了优化，重组了团队，新建了 GitHub Workflow、Source Organization、Testing Methodology 和 Build \u0026amp; Release Automation 团队，以方便度量每个团队的指标。\n参考 Istio 1.2 发布公告——重大更新 - istio.io ","relpermalink":"/community/sig/istio/release/12/","summary":"2019 年 6 月 18 日，Istio 1.2 发布，常规发布，主要聚焦在测试和发布机制。","title":"Istio 1.2——改进发布机制"},{"content":"Istio 1.3 主要着重于改善新用户使用 Istio 的体验，包括为 istioctl 增加更多调试功能，支持更多应用程序，无需任何其他配置。\n参考 Istio 1.3 发布公告——重大更新 - istio.io ","relpermalink":"/community/sig/istio/release/13/","summary":"2019 年 9 月 12 日，Istio 1.3 发布，该版本主要聚焦在用户体验上。","title":"Istio 1.3——改善用户体验"},{"content":"常规发布，继续致力于改善 Istio 的用户体验，并着重于简化使用方式，提高 Istio 的运行性能。\n新增了 Istio Operator 的安装方式。\n参考 Istio 1.4 发布公告——重大更新 - istio.io ","relpermalink":"/community/sig/istio/release/14/","summary":"2019 年 11 月 14 日，Istio 1.4 发布，该版本继续优化 Istio 的用户体验，提高 Istio 的性能。","title":"Istio 1.4——简化 Istio 的使用"},{"content":"作者：马若飞，审校：罗广明\nIstio 1.5 是一个具有重大变革的版本。长久以来，面对社区对 Istio 的性能和易用性的诟病，Istio 团队终于正视自身的问题，在当前版本中彻底推翻了原有控制平面的架构，完成了重建。正如 Simplified Istio 文中所说：\n复杂是万恶之源，让我们停止焦虑，爱上单体。\nIstio 1.5 回归单体，无论架构和使用方式都发生了巨大变化。因此笔者决定对 1.5 的变化内容做深入解读，以便开发者可以更好的理解和学习新版本，为使用和升级提供参考。\n架构调整 这部分主要分析 Istio 1.5 在架构上的调整，这也是该版本最核心的变化。主要包括重建了控制平面，将原有的多个组件整合为一个单体结构 istiod；同时废弃了被诟病已久的 Mixer 组件。还对是否向后兼容的部分也做了说明，如果你要从 1.4.x 版本升级到 1.5 必须知道这些变化。\n重建控制平面 官方使用的是重建（Restructuring）而不是重构（Refactoring）一词，可见其变化之大。在 Istio 1.5 中，控制平面将使用新的部署模式，将原有的各个组件整合在一起。 …","relpermalink":"/community/sig/istio/release/15/","summary":"2020 年 3 月 6 日，Istio 1.5 发布，有史以来最重大的一次变革。","title":"Istio 1.5——拥抱变化，回归单体"},{"content":"作者：马若飞，审校：罗广明\n从 1.2 版本开始，Istio 进入季度发布的节奏。5 月 21 日发布的 1.6 版本可以说是最准时的一次。我们是否可以理解 Istio 架构简化后的开发工作已经步入了正轨？这次的更新是否会带给我们惊喜？亦或是还有遗憾？让我们一一道来。\n加法和减法 Istio 1.6 的 Release note 开篇的标题用三个巨大的 Simplify 来表明态度：我们要把极简主义进行到底！其中最大的简化就是将原有组件的功能完全整合入 Istiod ，完成了悟天克斯们的合体过程，让 Istiod 更加完整，也彻底移除了 Citadel、Sidecar Injector 和 Galley。当然，你也可以理解为，这其实是对 1.5 版本未完成工作的收尾。\n第二项简化工作是添加 istioctl install 命令来替代 manifest apply 的安装过程，用更直观、更精简的命令改善安装过程的体验。当然，manifest 子命令依然保留，你还是可以通过清单方式进行部署。在 Change Notes 的三十多项更新中，有七个是removed，基本上都和安装有关，比如移 …","relpermalink":"/community/sig/istio/release/16/","summary":"2020 年 5 月 12 日，Istio 1.6 发布，迈向极简主义。","title":"Istio 1.6——迈向极简主义"},{"content":"作者：马若飞，审校：宋净超\n2020 年 8 月 21 日，Istio 发布了 1.7 版本。除了介绍新版本的主要更新内容外，本文会重点分析 Istio 团队在产品更新策略上的激进态度和举措。是稳扎稳打做好向后兼容，带给用户所承诺的易用性；还是快刀斩乱麻，做进击的追风少年，且听笔者慢慢道来。\n如约而至——Istio 1.7.0 发布 就在几天前，Istio 发布了 1.7 版本，和 1.6 版本的发布时间正好间隔三个月，完美的实现了季度发布的诺言。本次发布的口号是“伟大的 Istio 社区（Istio’s great community）”，因为有来自 40 多个公司的 200 多个开发者做出了贡献。Istio 官方是这样描述的：\n正是因为有如此令人惊羡（amazing）的社区，才让 Istio 能够在每个季度有如此多的改进。\nIstio 团队已经从上个月倒卖商标的麻烦中走了出来，看上去是想通过强调 Istio\u0026#39;s great community 这个理念来抚平社区开发者受伤的心灵？笔者认为，作为开发者和用户不必太在意 Google 的商业行为，至少现阶段 Istio 还在以开源的身份 …","relpermalink":"/community/sig/istio/release/17/","summary":"2020 年 8 月 21 日，Istio 1.7 发布，依然还是个少年。","title":"Istio 1.7——进击的追风少年"},{"content":"作者：宋净超，审校：马若飞\n今天 Istio 1.8 发布了，这是 Istio 在 2020 年发布的最后一个版本，按照 Istio 社区在今年初设定的目标继续推进，该版本主要有以下更新：\n支持使用 Helm 3 进行安装和升级 正式移除了 Mixer 新增了 Istio DNS proxy，透明地拦截应用程序的 DNS 查询，实现智能应答 新增了 WorkloadGroup 以简化对虚拟机的引入 WorkloadGroup 是一个新的 API 对象，旨在与虚拟机等非 Kubernetes 工作负载一起使用，模仿现有的用于 Kubernetes 工作负载的 sidecar 注入和部署规范模型来引导 Istio 代理。\n安装与升级 Istio 从 1.5 版本开始弃用了 Helm，使用 istioctl manifest 方式安装，后来又改成了 istioctl install，现在又重新回归了 Helm，Helm 作为 Kubernetes 环境下最常用的应用安装管理组件，此次回归也是倾听用户声音，优化安装体验的的反应吧，不过 Istio Operator 依然将是 Istio 安装的 …","relpermalink":"/community/sig/istio/release/18/","summary":"2020 年 11 月 18 日，Istio 1.8 发布，顺应用户呼声，对虚拟机的支持更进一步。","title":"Istio 1.8——用户至上的选择"},{"content":"2 月 9 日，Istio 宣布发布 Istio 1.9 版本。在这个版本中，我们可以看到虚拟机更广泛地被采用到服务服务网格中，而且对虚拟机的支持、对虚拟机的 cert 发放、对工作负载入口的健康检查也更加完善。Istio 最新的 1.7 和 1.8 两个版本，在让 VM 成为服务网格中一流的工作负载方面取得了很多进展，而 cert 发放则是最后需要弥补的缺口。\n服务网格中的虚拟机集成 虚拟机集成是 Istio 的核心功能之一，在这个版本中，它升级到了测试版，这意味着它可以用于生产，不再是玩具。\n在 Istio 服务网格中运行 Kubernetes 工作负载已经有一段时间了，在过去的几个 Istio 版本中，运行虚拟机工作负载也是如此。最新发布的 Istio 使得在服务服务网格中混合 Kubernetes 和 VM 工作负载更加容易。\n常见的用例包括在数据中心的虚拟机或云环境中的虚拟机上运行应用程序。这些虚拟机要么运行传统的，要么运行第三方应用 / 服务。其中一些应用 / 服务不会在短时间内消失–或者在某些情况下，永远不会消失！其中一些虚拟机工作负载是应用现代化历程的一部分，包括转向微 …","relpermalink":"/community/sig/istio/release/19/","summary":"2021 年 2 月 9 日，Istio 1.9 发布，重点提升 Day2 体验。","title":"Istio 1.9——提升 Day2 体验"},{"content":"对云原生社区有任何建议或意见，请与我们联系。\n读者 你可以通过以下方式云原生社区联系：\n在云原生社区动态公众号后台留言； 发送邮件给 jimmysong@jimmysong.io； 商务合作 如果您想与云原生社区合作，请联系 Jimmy，并说明来意。\n","relpermalink":"/community/contact/","summary":"与云原生社区联系。","title":"联系我们"},{"content":"北京时间 5 月 19 日，我们很高兴地宣布 Istio 1.10 的发布！我们要特别感谢我们的发布经理 Sam Naser 和 张之晗，以及整个测试和发布工作组在 1.10 中的工作。\n这是我们 2021 年的第二个版本，和过去几个版本一样，我们继续为 Istio 用户改善 Day 2 操作。\n该版本的亮点如下。\n发现选择器 在以前的 Istio 版本中，Istio 的控制平面一直在观察和处理集群中它所关心的所有 Kubernetes 资源的更新。这在大型集群或配置快速变化的集群中可能是一个可扩展性瓶颈。发现选择器（Discovery Selector）限制了 Istiod 监视的资源集，所以你可以很容易地忽略那些与网格无关的命名空间的变化（例如一组 Spark Job）。\n你可以认为它们有点像 Istio 的 Sidecar API 资源，但对于 Istiod 本身来说：Sidecar 资源限制了 Istiod 将发送至 Envoy 的配置集。发现选择器限制了 Istio 从 Kubernetes 接收和处理的配置集。\n请看 Lin、Christian 和 Harvey 的精彩文 …","relpermalink":"/community/sig/istio/release/20/","summary":"2021 年 5 月 19 日，Istio 1.10 发布，继续改善 Day 2 操作，并改版了官网。","title":"Istio 1.10——继续改善 Day2 操作并改版了官网"},{"content":"2021 年 8 月 12 日发布，本年度的第三个版本。\nCNI 插件（Beta） 默认情况下，Istio 会在部署在网格的 pod 中注入一个 init 容器。istio-init 容器使用 iptables 设置 pod 网络流量重定向到（来自）Istio sidecar 代理。这需要网格中部署 pod 的用户或服务账户有足够的权限来部署 具有 NET_ADMIN 和 NET_RAW 功能的容器。要求 Istio 用户拥有较高的 Kubernetes 权限，对于组织内的安全合规性来说是有问题的。Istio CNI 插件是 istio-init 容器的替代品，它执行相同的网络功能，但不要求 Istio 用户启用更高的 Kubernetes 权限。\nCNI 插件可以与其他插件同时使用，并支持大多数托管的 Kubernetes 实现。\n在这个版本中，我们通过改进文档和测试，将 CNI 插件功能提升为 Beta 版，以确保用户能够在生产中安全地启用这一功能。了解如何用 CNI 插件安装 Istio。\n外部控制平面（Beta） 去年，我们为 Istio 引入了一种 新的部署模式，即集群的控制 …","relpermalink":"/community/sig/istio/release/21/","summary":"2021 年 8 月 12 日，Istio 1.11 发布。","title":"Isito 1.11——使用 CNI 取代 Istio Init 容器"},{"content":"这是 Istio 在 2021 年发布的最后一个版本，也是本年度发布的第四个版本，Istio 依然在按照它既定的发布节奏发展。\nWebAssembly API WebAssembly 是一个重要的项目，开发了 3 年多，为 Istio 带来了先进的可扩展性，允许用户在运行时动态加载自定义构建的扩展。然而，直到现在，配置 WebAssembly 插件一直是实验性的，而且很难使用。\n在 Istio 1.12 中，我们通过增加一个 API 来配置 WebAssembly 插件 ——WasmPlugin 来改善这种体验。\n有了 WasmPlugin，你可以轻松地将自定义插件部署到单个代理，甚至是整个网格。\n该 API 目前处于 Alpha 阶段，正在不断发展。我们非常感谢 您的反馈意见!\n遥测 API 在 Istio 1.11 中，我们引入了全新的 Telemetry API，为 Istio 中配置追踪、日志和指标带来了标准化的 API。在 1.12 版本中，我们继续朝这个方向努力，扩大了对配置指标和访问日志 API 的支持。\n要想开始，请查看文档。\n遥测 API 概述\n追踪\nMetrics\n …","relpermalink":"/community/sig/istio/release/22/","summary":"2021 年 11 月 18 日，Istio 1.12 发布。","title":"Istio 1.12 —— 支持 WebAssembly 插件管理"},{"content":"每个 API 都需要一个前门，一个迎接请求与响应的门户。这个“门”不仅要坚固，能承受高流量的压力，最好还能过滤掉“蚊虫”——也就是潜在的威胁行为者和 DDoS 攻击。同时，一些额外的功能可以让整个体验更加愉快。\nAPI 网关便是你 API 的前门，它不仅仅负责流量的调度，还包括执行安全策略、优化性能等任务。然而，涉及大规模基础设施的决策总是难以把握，特别是当你已经开始构建新的 API，可能很难判断是否在正确的轨道上前行。\n受云原生计算基金会（CNCF）的 云原生成熟度模型 启发，我试图帮助你从全局视角出发，客观评估 API 前门的当前状态，并了解接下来的优化方向。\n基础阶段：打好地基 在这个阶段，你正处于 API 网关的 MVP 或预生产阶段，验证工具并分配各项责任，以便正式上线。\n决定 API 网关基础架构的基本形态（如云托管或本地部署），选择独立代理或通过 SDK 嵌入 API 网关功能，或者利用 Kubernetes 原生特性如 Gateway API。 实施安全基本策略，从基本认证开始，逐步升级到 JSON Web Tokens（JWT）。 设定速率限制和 IP 限制以防滥用。 …","relpermalink":"/blog/api-gateway-checklist-strength/","summary":"API 网关不仅是连接流量的入口，还肩负着安全、性能优化等多重任务。这篇清单可帮助你全面评估 API 网关的有效性，确保其在高负载下稳定可靠。","title":"API 网关的自查清单：你的 API 前门有多坚固？"},{"content":"为什么我们的 OpenEBS 项目被归档了？我们是如何修复它的？以及通过修复它，我们如何创建了一个可持续的商业模式。\n当云原生计算基金会（CNCF）在 2024 年 2 月归档了我们的 OpenEBS 项目时，我们面临两个选择：放弃项目，或者解决发现的问题并重新申请进入 CNCF 的 Sandbox 项目，重新开始。重新开始是最困难的选择，但对于每月有 25,000 名用户加入的 OpenEBS 来说，这是正确的做法。\n以下是 CNCF 归档我们项目的主要原因，我们是如何修复问题的，以及通过修复问题，我们是如何实现盈利的。\n所有权和控制问题 问题的核心是一个常见的治理问题。大约 60% 的 CNCF 项目都有一个企业赞助方——一个为项目提供资金的盈利公司。当公司将项目捐赠给 CNCF 时，项目就成为 CNCF 的财产，赞助公司放弃了对项目的所有权和控制权。\n但在项目尚未建立社区之前，赞助公司的员工通常仍在为该项目工作。许多 CEO 认为他们仍然拥有项目的所有权和控制权。“如果我的员工还在工作，那我就拥有决策权。”这种所有权和控制权的紧张关系导致了我们项目被归档，除非我们解决这个问题，否 …","relpermalink":"/blog/how-to-fix-cncf-governance-and-create-business/","summary":"通过解决 CNCF 项目治理中的所有权和控制问题，OpenEBS 项目实现了社区化与盈利。","title":"如何通过修复 CNCF 项目治理问题实现社区共赢与商业化"},{"content":"潜在的 Istio 用户经常会问：“Istio 与 Cilium 相比如何？”虽然 Cilium 最初仅提供 L3/L4 功能（如网络策略），但近来的版本增加了基于 Envoy 的服务网格功能以及 WireGuard 加密。与 Istio 一样，Cilium 也是 CNCF 认证的毕业项目，并在社区中存在多年。\n尽管表面上看这两个项目提供的功能相似，但它们的架构却有着显著不同，尤其是 Cilium 使用 eBPF 和 WireGuard 在内核中处理和加密 L4 流量，而 Istio 在用户空间通过其 ztunnel 组件处理 L4 流量。这些差异导致了关于 Istio 与 Cilium 在大规模下性能的广泛讨论。\n尽管已有关于租户模型、安全协议和基本性能的比较，但尚未有全面的企业级评估报告。与其强调理论性能，我们对 Istio 的 Ambient 模式和 Cilium 进行了测试，聚焦于延迟、吞吐量和资源消耗等关键指标。通过模拟一个繁忙的 Kubernetes 环境，我们施加了高负载场景，最后将 AKS 集群的规模扩展到 1000 个节点、11000 个核心，以了解这些项目在大规模下 …","relpermalink":"/blog/ambient-vs-cilium/","summary":"本文对比了 Istio Ambient 模式与 Cilium 在大规模场景下的性能表现，重点分析了各自的架构差异及扩展性。","title":"云原生对比：Istio Ambient 模式与 Cilium 的扩展性能分析"},{"content":"近日，AWS 官方博客发布公告，宣布将于2026 年 9 月 30 日正式停用 AWS App Mesh 服务。从2024 年 9 月 24 日起，新用户将无法再使用 App Mesh。AWS 建议现有的 App Mesh 用户开始规划迁移到 Amazon ECS Service Connect，以充分利用其改进的特性和功能。\nAmazon ECS Service Connect 的优势 在 2022 年的 re:Invent 大会上，AWS 推出了Amazon ECS Service Connect，这是一种连接 Amazon Elastic Container Service（Amazon ECS）中微服务的新方式。Service Connect 通过内置的健康检查、异常检测和重试机制，显著提高了容器化微服务的可靠性。此外，它还能将应用层网络指标发送到 Amazon CloudWatch，增强了系统的可观测性。\n与 App Mesh 不同，Service Connect 使用了 AWS 托管的网络数据平面，消除了管理 sidecar 代理的繁琐工作。这意味着开发者可以更专注于业务逻 …","relpermalink":"/blog/migrating-from-aws-app-mesh-to-amazon-ecs-service-connect/","summary":"近日，AWS 官方博客发布公告，宣布将于 2026 年 9 月 30 日正式停用 AWS App Mesh 服务。从 2024 年 9 月 24 日起，新用户将无法再使用 App Mesh。这一消息引起了云原生社区的广泛关注。AWS 建议现有的 App Mesh 用户开始规划迁移到 Amazon ECS Service Connect，以充分利用其改进的特性和功能。","title":"AWS 宣布将停用 App Mesh，鼓励用户迁移至 Amazon ECS Service Connect"},{"content":"当用户安装 Istio 时，默认会创建一个证书颁发机构（CA），并且 CA 证书是自签名的。然后，CA 证书用于管理运行在 Istio 服务网格上的应用程序的证书生命周期。这使得在 Istio 服务网格上运行的应用程序之间轻松设置开箱即用的 mTLS 通信成为可能。\n随着我们向生产环境的实施迈进，Istio 还提供了一个选项，可以使用你自己的 CA 证书，而不是使用默认的自签名 CA 证书。企业倾向于自动化其公钥/私钥基础设施（PKI），以确保、管理和创建证书。作为一般实践，企业会使用由其根证书或其他中间证书签名的私有 CA 证书来设置其服务网格的证书颁发机构。\n在众多可用选项中，AWS 私有 CA 是一个托管的 CA，帮助组织使用 AWS 中的私有证书来保护其应用程序和设备。此外，Cert Manager 是另一个流行的选择，用于简化获取、续订和使用这些证书的过程。Cert Manager 和 AWS Private CA issuer 插件通常一起使用，以设置 Istio 服务网格的自定义 CA。\n这种集成的一些主要优势包括：\n证书生命周期管理的自动化，确保在证书到期前续订，以避免 …","relpermalink":"/blog/istio-aws-private-ca/","summary":"了解如何将 Istio 与 AWS 私有CA集成，实现自动化证书管理，增强服务网格的安全性与可审计性。","title":"如何将 Istio 与 AWS 私有证书颁发机构（Private CA）无缝集成"},{"content":"我们的核心团队成员来自腾讯、JP Morgan、富途证券、E投睿、高盛等国际顶级金融机构和互联网巨头（BAT），团队成员拥有丰富的亿级规模用户项目经验。现在，我们正在招聘以下岗位：\n招聘岗位 市场类 品牌推广 渠道管理 商务BD 运营类 内容运营 客户成功经理 产品与研发类 产品经理 UI设计 前端开发 终端开发（Android、iOS） Java开发 Golang开发 云原生 DBA 安全运维 测试工程师 数据开发 数据分析师 公司福利 高薪资：薪资对标甚至高于BAT，年终奖在春节前发放。 弹性工作：不打卡，弹性工作制，工作氛围好，拒绝内卷，强调工作与生活平衡（WLB）。 远程办公：支持海内外分布式远程办公，春节享有加长假期。 完善保障：七险一金，含2000元商业保险及1500元健康体检。 丰富活动：每周篮球、羽毛球、游泳、棋牌桌游等活动俱乐部。 下午茶与零食：周三下午茶花样多，办公室零食不断，节假日福利丰厚。 团建与奖金：团建经费充足，提供丰厚的团队建设奖金（TB）。 公司：雄岸科技\n总部：新加坡（上市公司）\n长期招聘，外企远程岗位内推通道（直招） : …","relpermalink":"/blog/jd-grandshorestech/","summary":"远程云原生岗位，主要负责云基础设施运维与服务治理，要求 Kubernetes 与多云服务治理经验。","title":"外企远程岗位内推通道（直招）"},{"content":" 编者按：Envoy 作者 Matt Klein 的创业公司 Bitdrift 新推出了可观测性代理开源项目 Pulse。\n继宣布 Capture SDK 源代码可用之后，我们非常高兴地再次宣布Pulse的可用性，这是一个为大规模度量基础设施建造的观测代理。请阅读以下内容，了解 Pulse 的概述、其创建的简要历史，以及它如何适应更广泛的服务器端观测生态系统。\nPulse 是一个为大规模度量基础设施构建的观测代理，从包括statsite和statsrelay在内的先前项目中汲取思想，同时提供现代 API 驱动的配置和类似于Envoy所提供的无损配置重载。\n度量指标已经过时了吗？虽然行业趋势确实是向结构化日志转变，作为所有数据的首选来源，这一点在Capture的移动观测产品中也有体现，但传统的度量指标依然是许多大型组织观测实践的核心。\n尽管OTel Collector、Fluent Bit和Vector都是优秀的项目，提供一定程度的度量支持，但在处理大规模度量基础设施时尚存在不足，主要体现在：\n聚合：例如，去掉 pod 标签以衍生出服务级别的聚合度量。对 Prometheus 度量的聚合 …","relpermalink":"/blog/announcing-pulse-proxy/","summary":"Pulse 是为应对大规模度量基础设施挑战而设计的观测代理，提供现代化 API 驱动配置和无损配置重载能力。了解 Pulse 的详细介绍、发展历程及其在服务器端观测生态系统中的定位。","title":"Pulse 观测代理：为大规模度量基础设施打造的观测解决方案"},{"content":"随着 Istio 的环境数据平面模式的推出，平台团队可以高效地采用服务网格功能，并以最小的资源和开销影响为终端用户提供增强功能。\n什么是 Istio 环境模式？ Istio 的环境模式最初于 2022 年 9 月发布。它是一种新的数据平面模式 —— 无需 sidecar —— 旨在简化操作、扩大应用兼容性和降低基础设施成本。环境模式将 Istio 的功能分为两个独立的层：零信任安全覆盖层（ztunnel）和可选的第 7 层处理层（waypoint）。与 sidecar 相比，分层方法允许用户从无网格逐渐采用到基于 mTLS 的零信任覆盖，再到完整的第 7 层处理，根据需要进行。这为服务网格用户提供了来自同一专用社区的两个出色选择：传统的 sidecar 方法的 Istio 或无 sidecar 的环境模式。\nIstio 环境模式 在这篇博客中，我们将探讨与资源成本和操作挑战相关的一些示例场景，这些场景在采用服务网格时常常会引起紧张。我们还将讨论如何采用环境模式来应对这些挑战，并改善平台的总拥有成本（TCO）。\nIstio 的环境模式降低资源成本 默认情况下，Istio …","relpermalink":"/blog/istio-more-for-less/","summary":"随着 Istio 的环境数据平面模式的推出，平台团队可以高效地采用服务网格功能，并以最小的资源和开销影响为终端用户提供增强功能。\n什么是 Istio 环境模式？ Istio 的环境模式最初于 2022 年 9 月发布。它是一种新的数据平面模式 —— 无需 sidecar —— 旨在简化操作、扩大应用兼容性和降低基础设施成本。环境模式将 Istio 的功能分为两个独立的层：零信任安全覆盖层（ztunnel）和可选的第 7 层处理层（waypoint）。与 sidecar 相比，分层方法允许用户从无网格逐渐采用到基于 mTLS 的零信任覆盖，再到完整的第 7 层处理，根据需要进行。这为服务网格用户提供了来自同一专用社区的两个出色选择：传统的 sidecar 方法的 Istio 或无 sidecar 的环境模式。\n","title":"使用 Istio 的环境模式 —— 用更少的资源做更多的事！"},{"content":"在与 Kubernetes 用户的对话中，经常会听到这样一句话：“我只想让我的所有流量在 Kubernetes 中实现 mTLS 加密。”有时，这种要求还会加上一些附加条件，比如“……但不要涉及服务网格的复杂性。”\n这是一个合理的需求，市面上有很多解决方案，各自有不同的取舍。在本文中，我将介绍几种选择，并提供一些建议。\n为什么要求是“mTLS”，而不是更广泛的“加密”？原因有很多。有些人可能已经对各种加密机制进行了研究，并决定使用 mTLS，而有些人可能对其他选项不了解。在本文中，我将主要关注 mTLS。\n为什么选择 mTLS 在深入探讨 mTLS 的最佳方案之前，我们有必要先理解为什么要使用它。\nmTLS 代表双向 TLS，这与互联网上大多数使用的加密（如 https://）类似，但它是双向的。\n在标准的互联网场景中，浏览器会验证目标网站的 TLS 证书，以确认 bank.com 确实由 bank.com 操作，而不是遭遇中间人攻击（MITM）。网站也可能会验证用户，但通常是在应用层进行，而不是通过 TLS。\n双向 TLS 则是类似的机制，但客户端也会提供一个证书，该证书需要被服务器 …","relpermalink":"/blog/mtls-kubernetes/","summary":"本文探讨了在 Kubernetes 环境中实现 mTLS（双向 TLS）的方法，包括自行实现、基于 Sidecar 的服务网格和 Ambient 模式的比较与推荐。","title":"在 Kubernetes 中实现 mTLS：选项与推荐"},{"content":"2024 年 8 月 16 日，Istio 1.23 发布。该版本带来了环境模式的重大改进，包括性能提升、功能增强以及 DNS 自动分配和重试策略的优化，同时宣布集群内 Operator 将被弃用。\n环境模式 紧随最近将 环境模式升级到 Istio 1.22 的 Beta 版之后，Istio 1.23 带来了一系列重大改进。在与众多采用环境模式的用户紧密合作的基础上，我们一直在努力解决收到的所有反馈。这些改进包括更广泛的平台支持、新增功能、错误修复和性能改善。\n一小部分亮点：\n在 waypoint 代理中支持 DestinationRule。 在 waypoint 和 ztunnel 中支持 DNS ServiceEntries。 支持跨命名空间共享 waypoint。 支持新的 Service 字段 trafficDistribution，允许保持流量在本地区域/地区。 支持双栈和 IPv6 集群。 为 ztunnel 提供一个新的 Grafana 仪表板。 一个 Helm chart，用于一次性安装所有环境模式组件。 性能改进：我们的测试显示与 Istio 1.22 相比，吞吐量提 …","relpermalink":"/blog/istio-1-23-release/","summary":"Istio 1.23 版本带来了环境模式的重大改进，包括性能提升、功能增强以及 DNS 自动分配和重试策略的优化，同时宣布集群内 Operator 将被弃用。","title":"Istio 1.23 发布：环境模式升级与重要功能更新"},{"content":"由于在开发过程中我真的不喜欢等待，所以在构建 Ztunnel（一个为 Istio 的新Ambient 模式设计的底层网络代理）时，我的首要任务之一便是确保测试的快速进行（包括运行和编写测试），并且易于调试。\n这一任务颇为棘手，因为在大多数真实场景中，Ztunnel 高度依赖 Kubernetes。虽然它能够完全独立于 Kubernetes 运行，但许多关键代码路径的行为完全不同，使得仅通过这种方式进行测试变得不可行。\n下图为典型的 Ztunnel 部署架构：\nZtunnel 架构概览 在此架构中，用户将运行一个包含多个节点的 Kubernetes 集群。每个节点上都运行着一个 Ztunnel，配置了宿主机和每个 pod 的网络栈。\n此外，Ztunnel 实际上进入了每个 pod 的网络命名空间，并代表其发送/接收流量。这一点非常奇特且酷炫，但也大大增加了测试的难度！（详细信息）\n加速测试 启动完整的 Kubernetes 环境、重建镜像、部署到每个节点的过程非常缓慢且难以调试。\n黄金标准应该是将所有操作运行在一个简单的单一二进制文件中——仅需执行 cargo test。这种方式避开了复 …","relpermalink":"/blog/ztunnel-testing/","summary":"探讨如何在没有 Kubernetes 环境的情况下测试 Ztunnel 网络代理，该代理为 Istio 的新 Ambient 模式编写。","title":"无需 Kubernetes 测试 Kubernetes 网络实现"},{"content":"AI 是否存在隔离问题？ 在过去的几个月里，我们 Wiz 研究团队对多个 AI 服务提供商进行了广泛的租户隔离研究。我们认为这些服务更容易受到租户隔离漏洞的影响，因为它们允许用户运行 AI 模型和应用程序，这等同于执行任意代码。随着 AI 基础设施越来越成为许多商业环境的标配，这些攻击的影响正变得越来越重要。\n我们将在即将举行的 Black Hat 会议上展示这个研究项目的发现，在我们的会议“隔离还是幻觉？为乐趣和权重黑客攻击 AI 基础设施提供商”。\n在这个项目的最新一期中，我们研究了 SAP 的 AI 产品，恰当地命名为“SAP AI Core”。这是我们系列中的第三份报告，继我们对 Hugging Face 和 Replicate 平台的研究之后。本博客将探索漏洞链并详细介绍我们的发现，称为“SAPwned”，同时也将观察到确保管理 AI 平台安全的潜在影响和更广泛的启示。\n执行摘要 AI 训练过程需要访问大量敏感客户数据，这使 AI 训练服务成为攻击者的诱人目标。SAP AI Core 提供与 HANA 及其他云服务的集成，通过云访问密钥访问客户的内部数据。这些凭据非常敏感，我 …","relpermalink":"/blog/sapwned-sap-ai-vulnerabilities-ai-security/","summary":"本文通过研究 SAP AI Core，揭示了多个安全漏洞，这些漏洞可能允许攻击者访问客户数据和内部工件。","title":"SAPwned：SAP AI 漏洞暴露客户云环境和私有 AI 工件"},{"content":"在本指南中，我们将探讨如何利用 Istio 和 Keycloak 实现身份验证和授权。目标是简化开发流程，使开发者可以专注于核心任务，而不需要担心身份验证和授权问题。我们将通过实际示例和有效的示例代码，逐步讲解此过程。\n网格 Keycloak 介绍 Keycloak 是一个开源的身份及访问管理解决方案，提供单点登录（SSO）功能，允许用户一次认证后，使用单一凭证访问多个应用程序和服务。我特别印象深刻的一个功能是 Keycloak 的开发流程简化能力，它支持集成自定义主题，例如登录页面。在这个场景中，我们已将 Keycloak 部署在同一个 Kubernetes 集群内。\n以下是我们用于构建自定义 Keycloak 镜像的 Dockerfile。\nFROM quay.io/keycloak/keycloak:24.0.3 COPY ./ex-offenders-theme /opt/keycloak/themes/ex-offenders-theme COPY ./providers/create-account-custom-spi.jar …","relpermalink":"/blog/istio-keycloak-authentication-authorization/","summary":"本指南介绍了如何利用 Istio 和 Keycloak 来实现身份验证和授权，简化开发流程，让开发人员能够专注于核心任务。","title":"使用 Istio 和 Keycloak 实现身份验证和授权"},{"content":"撰写这篇博客非常有趣，虽然它可能不受某些人欢迎，但这是一个必须讨论的话题。\n亲爱的开发者朋友们，我们需要开诚布公地讨论一下微服务以及某些不适宜的使用场景。这个过程可能不会轻松，但我们必须进行这样的探讨，否则我们无法取得成功。\n如今，微服务极为流行，它是一种优秀的架构风格，有助于扩展系统和组织架构。许多成功的公司都在使用微服务（例如 Netflix、Spotify 等），因此，大多数公司正在使用或计划使用微服务并不令人意外。然而，一些公司忽视了它带来的额外成本。\n在深入讨论之前，让我分享一下我与微服务的经历。\n起始 - 是微服务吗？ 2012 年，在我当时的公司，我们面临一个挑战：如何使公司扩展到数千名工程师和增加 1000 倍的交易量。这篇文章不关注招聘、入职等方面，而是关注架构。\n当时我在阅读《Scalability Rules: 50 Principles for Scaling Web Sites》，这本书介绍了 AKF Scale Cube。\n来自《Scalability Rules: 50 Principles for Scaling Web Sites》的 AKF …","relpermalink":"/blog/you-probably-dont-need-microservices/","summary":"本文探讨了微服务架构的实际成本和挑战，并提出在特定情况下其他解决方案可能更为合适。","title":"你可能不需要微服务"},{"content":"7 月 6 日，由云原生社区主办的云原生技术开放日・大连站在大连星海假日酒店顺利举行。此次活动是云原生社区在大连举办的第四次技术盛会（连续四年）。活动为期一天，有 10 个 topic，讲师来自 Flomesh、腾讯、蚂蚁集团 \u0026amp; 开放原子基金会、乐天创研、MoonBit 社区、DaoCloud、中国移动、字节跳动、Kong 以及极狐 GitLab。分享话题涵盖了 Kubernetes、微服务、DevOps、Rust 等方面。\n虽然活动当天早晨是下雨天，但是依旧有超过 130 + 开发者到了活动现场，会场不得不临时增加座位。这是一场超预期的活动，成功的活动离不开所有人，包括参会者、赞助商、讲师、志愿者等。感谢所有人！\n回顾文章 PPT：见 GitHub ","relpermalink":"/event/cloud-native-meetup-dalian-14/","summary":"7 月 6 日，由云原生社区主办的云原生技术开放日・大连站在大连星海假日酒店顺利举行。","title":"云原生技术开放日・大连站"},{"content":"Meta 公司最近发布了 Llama 3，这是其最新一代尖端开源大型语言模型（LLM）。基于其前身的基础之上，Llama 3 旨在提升 Llama 2 作为与 ChatGPT 竞争的重要开源产品的能力，如文章 Llama 2: 深入探索开源挑战者 ChatGPT 中全面回顾的那样。\n在本文中，我们将讨论 Llama 3 背后的核心概念，探索其创新架构和训练过程，并提供关于如何负责任地访问、使用和部署这一开创性模型的实际指导。无论你是研究人员、开发者还是 AI 爱好者，这篇文章都将为你提供利用 Llama 3 为你的项目和应用赋能的知识和资源。\nLlama 的演变：从 Llama 2 到 Llama 3 Meta 的 CEO，Mark Zuckerberg，在 Threads.net 上宣布了 Llama 3 的首次亮相，这是 Meta AI 开发的最新 AI 模型。这个尖端模型现在已开源，旨在提升 Meta 的各种产品，包括 Messenger 和 Instagram。Zuckerberg 强调，Llama 3 使 Meta AI 成为最先进的免费可用的 AI 助手。 …","relpermalink":"/blog/everything-you-need-to-know-about-llama-3-most-powerful-open-source-model-yet-concepts-to-usage/","summary":"探索 Llama 3：Meta 推出的创新开源 LLM，介绍其架构、训练和实践应用，助力 AI 开发者。","title":"了解 Llama 3：迄今最强大的免费开源大模型从概念到使用"},{"content":"本文档描述了 Istio 控制平面——Istiod 的高层架构。Istiod 是一个模块化的单体应用，涵盖了从证书签名、代理配置（XDS）、传统的 Kubernetes 控制器等多种功能。\n代理配置 Istiod 的主要角色——以及大部分代码——是动态配置代理（Envoy sidecar、入口、gRPC、ztunnel 等）。这大致包括 3 个部分：\n配置摄取（系统的输入） 配置翻译 配置服务（XDS） 配置摄取 Istio 从超过 20 种不同的资源类型读取，并将它们聚合在一起构建代理配置。这些资源可以来自 Kubernetes（通过观察）、文件或通过 xDS；尽管如此，Kubernetes 是最常用的。\n主要出于历史原因，摄取分为几个组件。\nConfigStore ConfigStore 读取多种资源，并通过标准接口（Get、List 等）暴露它们。这些类型被包装在通用的 config.Config 结构中，与通常使用每种资源类型的 Kubernetes 客户端形成对比。最常见的是通过 crdclient 包从 Kubernetes 读取。 …","relpermalink":"/blog/istiod-architecture/","summary":"本文译自 Istio 官方代码仓库中对 Istiod 架构的解析。描述了 Istio 控制平面——Istiod 的高层架构。Istiod 是一个模块化的单体应用，涵盖了从证书签名、代理配置（XDS）、传统的 Kubernetes 控制器等多种功能。","title":"Istiod 架构详解"},{"content":"Apache SkyWalking 团队今天宣布发布 SkyWalking 10。SkyWalking 10 提供了一系列突破性的功能和增强功能。Layer 和 Service Hierarchy 的引入通过将服务和指标组织成不同的层次，并提供跨层无缝导航，从而简化了监控。利用 eBPF 技术，Kubernetes 网络监控提供了对网络流量、拓扑和 TCP/HTTP 指标的详细洞察。BanyanDB 作为高性能的原生存储解决方案出现，同时扩展的监控支持包括 Apache RocketMQ、ClickHouse 和 Apache ActiveMQ Classic。对多标签名称的支持增强了指标分析的灵活性，而增强的导出和查询功能简化了数据分发和处理。\n本文简要介绍了这些新功能和增强功能以及其他一些值得注意的变化。\nLayer 和 Service Hierarchy Layer 概念是在 SkyWalking 9.0.0 中引入的，它代表计算机科学中的一个抽象框架，例如操作系统（OS_LINUX layer）、Kubernetes（k8s layer）。它根据系统中服务和指标的角色和职责将其 …","relpermalink":"/blog/skywalking-10-release/","summary":"介绍 SkyWalking 10 的新特性，包括服务层次结构、基于 eBPF 的 Kubernetes 网络监控、BanyanDB 等。","title":"SkyWalking 10 发布：服务层次结构、基于 eBPF 的 Kubernetes 网络监控、BanyanDB 等"},{"content":"如今在 Kubernetes 中，服务网格已经变得司空见惯，有些平台甚至默认将其构建到集群中。服务网格无疑在多种方面提供了诸多好处，这些好处众所周知，但也众所周知，它们显著增加了集群的复杂性。除了增加了复杂性之外，服务网格在强制执行 Pod 安全性方面也带来了（臭名昭著的）问题，因为它们需要提升的权限可能对其他准入控制器造成难以处理的困扰，例如 Kubernetes 自身的 Pod 安全准入控制器。在本文中，我们将更详细地解释这个问题以及在使用服务网格时 Kyverno 如何成为真正的救星，同时为你预览一下即将到来的 Kyverno 1.12 版本中的一些东西，这将使安全服务网格变得轻而易举！\n介绍 服务网格为 Kubernetes 应用程序提供了许多好处，包括更好的负载均衡、双向 TLS、可观察性等。很可能你现在就在你的某个集群中使用了服务网格。最流行的开源服务网格包括 Istio 和 Linkerd。所有服务网格的工作方式基本相同，我们不会在这篇博文中深入探讨。一个显著的点是，为了将流量定向到其“旁路”代理并从其“旁路”代理，需要对底层 Linux 节点的 iptables 规则进 …","relpermalink":"/blog/securing-services-meshes-easier-with-kyverno/","summary":"利用 Kyverno 为服务网格提供更好的 Pod 安全性。","title":"使用 Kyverno 更轻松地保护服务网格"},{"content":"最近对于理解 Kubernetes 中的网络有很大的兴趣。本文是我对这个话题的贡献。我会尽力用直观的方式解释，并将技术部分翻译成易懂的语言，以便任何人都能理解。\n最好的学习网络的方式是通过“追踪数据包”或“数据包的生命周期”。基本上，你要跟随数据包从发送者到接收者的旅程，并在每一步停下来。我以前就用 Calico 实现的 Pod 到另一个 Pod 的通信 进行了这样的操作。这次我将使用另一个容器网络接口 (CNI) 叫做 Cilium，它基于 eBPF（了解快速和灵活的路由），并带有许多强大的功能和工具。让我们开始吧！\nKubernetes 中的传统网络 我们将从头开始。我会假设你对网络一无所知。也许你已经知道 IP 地址是什么？IP 地址是计算机网络接口的数字地址。这就是你的计算机可以连接到你的 Wi-Fi 网络并让你访问互联网的方式。如果你使用的是笔记本电脑，你的 Wi-Fi 网络接口有一个 IP 地址。这个网络接口还有另一个由硬件提供商烧录的唯一地址。这个地址称为介质访问控制 (MAC) 地址。\nIP 地址属于一个组（IP 子网）。为了知道它属于哪个组，它使用一种称为子网掩码的东 …","relpermalink":"/blog/kubernetes-networking-by-using-cilium-beginner-level/","summary":"本文介绍了传统网络和Kubernetes网络的基本概念。通过比喻和图示，解释了IP地址、子网、MAC地址等概念，并以“跟随数据包”的方式讲解了网络通信的过程。同时，也对Kubernetes中的网络通信进行了类比，解释了Pod、CNI和eBPF的概念。整体而言，文章从简单到复杂地讲解了网络通信的原理，便于读者理解。","title":"解密 Kubernetes 网络：跟随数据包的奇妙旅程"},{"content":"Istio 使用 Envoy 代理作为 Pod sidecar，应用程序将网络责任（例如入站和出站流量）委托给它，但有一个责任仍然属于应用程序容器：标头传播。\nEnvoy 代理无法将其发送到应用程序的请求与应用程序响应的请求关联起来，因此 Istio 无法自动传播标头。\n图 1：如果应用程序容器不转发回标头，Sidecar 无法将请求与响应关联起来。 在大多数情况下，基于标头的路由需要应用程序开发人员实现标头转发。例如，在 Istio 的 Bookinfo 应用程序中， productpage 微服务是这样实现的。这让我们想到一个问题：\n平台管理员如何在不修改应用程序内部的情况下使用基于标头的路由？\n泳道方法 使用 Bookinfo 应用程序，我们将根据 x-version 标头对请求路径进行分段，如下图 2 所示：\n图 2：根据 x-version 标头分段请求路径。 没有 x-version 标头的请求可能会被路由到任意后端。\n部署工作负载 我们将使用 Istio 的 Bookinfo 示例 ，并对版本控制应用程序进行一些细微的更改作为示例实现。\n首先， …","relpermalink":"/blog/header-based-routing-in-istio-without-header-propagation/","summary":"本文介绍了如何在 Istio 中使用头部信息进行路由，而无需修改应用程序内部。通过使用 Istio 的路由功能和头部匹配，可以实现基于头部信息的请求路由，同时展示了如何使用 delegate 功能和 sourceLabels 特性。","title":"Istio 中基于标头的路由——无需标头传播"},{"content":"本文是为那些刚开始使用 Istio 速率限制功能，希望了解基于请求路径的速率限制如何工作的人而写的。它源于我的实践，并澄清了关于rate_limit操作中 AND/OR 操作的困惑。我花了比预期更多的时间来弄清楚我将在这里为你总结的内容，以便你在几分钟内学习。\n基础知识 Istio 在 Envoy 之上运行，而我们将讨论的主要技术是 Envoy。Envoy 有在代理本身上实现的本地速率限制和在 L4 或 L7 上调用外部服务的全局速率限制的选项。\n外部速率限制服务 外部速率限制服务（RLS）与 Redis 数据库配合使用，通过 gRPC 与 envoy 实例连接。该 RLS 是由 filter 在 HTTP 路由过滤器之前的侦听器链中添加而被调用的。\n这个外部过滤器将描述符组织成域组。每个描述符都是一个键值对，由速率限制过滤器填充，并传递给 RLS 供其在规则执行逻辑中使用。请参阅 https://github.com/envoyproxy/ratelimit#overview 进行实现。\nRLS 需要由集群操作员（你）安装和管理，并且不会随 Istio 一起提供， …","relpermalink":"/blog/how-to-configure-global-rate-limits-by-path-in-istio/","summary":"这篇文章介绍了如何在 Istio 中根据请求路径配置全局限流。解释了 Envoy 限流过滤器和外部限流服务的工作原理，并通过例子展示了如何使用多个 rate limit action 来实现 OR 逻辑限流 certain paths。","title":"如何在 Istio 中按路径配置全局速率限制"},{"content":"Linkerd 是一个开源的服务网格项目，由 Buoyant 公司创建并维护。服务 网格是一种云原生技术，可以为微服务架构提供统一的网络层，实现服务间的安全、可观测和可控的通信。 Linkerd 以其轻量、快速和易用的特点，赢得了许多 开发者和企业的青睐。\n然而，Buoyant 公司最近宣布了一个重大的变化，即从 5 月开始，如果用户想要 下载和运行 Linkerd 的最新 稳定版本，就必须使用 Buoyant 的 商业分发版，即 Buoyant Enterprise for Linkerd（BEL）。BEL 是一个面向企业的 Linkerd 分发版，对于个人和 50 人以下的 企业免费使用，对于 50 人以上的企业，在生产环境中使用则需要付费。\n这一变化意味着，Linkerd 的 开源版本将只提供 Edge 版本，即每 10 天左右发布一次的预发布版本，用于测试新功能，但可能存在一些不兼容的变化。而 稳定版本，即经过充分测试和优化的版本，将只在 BEL 中提供。\nBuoyant 公司的 CEO William Morgan 在接受 The New Stack 的采访时解释了这一变化的 …","relpermalink":"/blog/linkerd-revise-release-model/","summary":"本文介绍了 Buoyant 公司对 Linkerd 服务网格的发布模式的调整，以及其对企业用户的影响。","title":"Linkerd 服务网格的发布模式变更： 开源版只提供 Edge 版本，稳定版需付费使用"},{"content":"Weaveworks 的首席执行官兼联合创始人 Alexis Richardson 在 LinkedIn 上分享了公司关闭的沉重消息。\nWeaveworks，曾经在云原生容器管理领域是创新的先驱，如今宣布停止运营，这一举动反映了科技初创公司行业不稳定的本质。\n在周一发布的令人惊讶的LinkedIn 帖子中，Weaveworks 首席执行官宣布公司即将停止运营。\nWeaveworks 的故事是一个典型的初创公司与市场动态和资金约束的潮起潮落的故事。尽管在 2023 年取得了两位数的增长，但公司面临着“波动”的销售和资金不足的局面，加剧了失败的收购谈判，这是许多初创公司都害怕但不可避免地会遇到的情况。\n成立于 2014 年，当时“云原生”这个词更多地是一个噱头而不是一个商业现实时，Weaveworks 立志于用他们的新概念GitOps来塑造未来的云基础设施管理。然而，尽管有着开拓精神和早期进入市场的优势，但该公司仍然与一个司空见惯的敌人搏斗：财务可持续性。\nWeave GitOps是一个开源软件包，旨在简化从 Git 存储库到 Kubernetes 集群的连续交付（CD）过程中部署应用程序 …","relpermalink":"/blog/end-of-an-era-weaveworks-closes-shop-amid-cloud-native-turbulence/","summary":"本文报道了 Weaveworks，一家推动 GitOps 和云原生技术的创业公司，宣布关闭的消息。文章分析了其在市场竞争和资金困境中的挣扎，以及其对整个行业的影响。","title":"Weaveworks 倒闭：云原生行业的变革与挑战"},{"content":"本文译自：Cloud-Computing in the Post-Serverless Era: Current Trends and beyond\n摘要：这篇文章主要讨论了未来云计算领域的三大趋势：从基本元素到云构件作为服务的转变、从超大规模到超专业化的转变、以及从基础设施到组合式编程作为服务的转变。作者指出，未来的云服务将更加集成编程构件，使得开发人员能够无缝地使用他们喜欢的编程语言来组合应用程序。文章强调了这些趋势对开发人员和运营团队的影响，并指出了这些变化将如何塑造未来以开发人员为中心的云服务。\n主要观点 无服务器计算正在超越其最初的范围，函数部分或完全被多才多艺的云构件取代，标志着云架构的新时代。 云市场正朝着高度专业化的垂直多云服务转变，提供独特的、精细粒度的功能，专门满足开发人员的需求。 即将推出的云服务将充满构件，改变开发人员处理路由、过滤和事件触发等任务的方式，使其更高效和用户友好。 从基础设施即代码转向构件即代码的趋势显著，开发人员使用熟悉的编程语言进行更直观的云服务配置。 微服务正在云景观中重新定义，从仅仅是架构边界演变为组织边界，在统一的开发者语言下整合各种云构 …","relpermalink":"/blog/cloud-computing-post-serverless-trends/","summary":"这篇文章主要讨论了未来云计算领域的三大趋势：从基本元素到云构件作为服务的转变、从超大规模到超专业化的转变、以及从基础设施到组合式编程作为服务的转变。作者指出，未来的云服务将更加集成编程构件，使得开发人员能够无缝地使用他们喜欢的编程语言来组合应用程序。文章强调了这些趋势对开发人员和运营团队的影响，并指出了这些变化将如何塑造未来以开发人员为中心的云服务。","title":"后 Serverless 时代的云计算趋势分析"},{"content":"本文译自 Exposing Load-Balanced Kubernetes Services with Cilium。\nCilium 是一个开源项目，旨在为云原生环境提供网络、安全和可观测性，例如 Kubernetes 集群和其他容器编排平台。本博客展示了如何使用 Cilium 和 BGP 将您的 Kubernetes 服务暴露给外部世界。\nBGP 边界网关协议（BGP）是一种标准化的外部网关协议，旨在在互联网上的自治系统（AS）之间交换路由和可达性信息。该协议被分类为路径矢量协议，因此它根据由网络管理员配置的路径、网络策略或规则集来做出路由决策。它参与制定核心路由决策，这使得它对互联网的正常运行至关重要。\nBGP 专为健壮性和可扩展性而开发，用于在大型网络之间路由数据，包括 ISP 和其他大型组织。它确保了无环的域间路由，并有助于维护稳定的网络结构。BGP 可以处理数千个路由，并以其随着网络增长而扩展的能力而脱颖而出。由于其灵活性和对路由策略的控制，它被广泛使用，使其能够快速响应网络变化。\nCilium 和 BGP 在版本 1.10 中，Cilium 集成了对 MetalLB …","relpermalink":"/blog/expose-loadbalanced-kubernetes-services-with-bgp-cilium/","summary":"本文介绍了如何使用 Cilium 和 BGP 技术，将 Kubernetes 中的 LoadBalanced 类型的服务暴露给外部网络。作者分享了他们的实验环境、BGP 路由器和 Cilium 的配置过程，以及测试和验证的结果。","title":"使用 Cilium 和 BGP 为 Kubernetes 服务进行负载均衡"},{"content":"在这篇博客中，我们将探讨当前的 Cilium 控制平面设计，大规模部署可能出现的限制的位置和原因，以及社区如何使用 CNCF 的 通用数据平面 (xDS) API 推进这个架构。\n了解 Cilium 的控制平面架构 Cilium 遵循基于“数据平面”和“控制平面”的常见网络架构。在 Cilium 中，数据平面部署在每个主机（或 Kubernetes 节点）上，包括用于处理 L3/L4 连接和策略的 eBPF 程序。为了简化起见，对于完整性，Cilium 还在其数据平面中使用 Envoy 代理处理 L7 策略，但我们将省略这部分。\nCilium 控制平面以 cilium-agent 守护程序的形式实现，部署在每个 Kubernetes 节点上。每个 cilium-agent 都是控制平面的单独、独立的实例。\ncilium-agent 连接到 Kubernetes API 服务器，监视配置更改，然后使用它来配置数据平面。cilium-agent 还将配置写入 Kubernetes API，表示正在其各自节点上创建的端点或标识。\n例如，当在 Kubernetes 节点上启动一个 Pod  …","relpermalink":"/blog/scaling-cilium-to-new-heights-with-xds/","summary":"本文探讨了 Cilium 的控制平面设计，分析了其在大规模部署中的局限性，以及如何使用 xDS API 来改进其架构和性能。","title":"Cilium 的控制平面升级之路：xDS API 的引入与应用"},{"content":"本文译自：Staying in the Zone: How DoorDash used a service mesh to manage data transfer, reducing hops and cloud spend\n摘要：本文介绍了 DoorDash 如何使用服务网格来优化其跨可用区的数据传输，降低成本和延迟。作者分享了他们的流量架构、问题分析和解决方案设计，以及使用 Envoy 和 Istio 实现区域感知路由的过程和效果。\nDoorDash 从单体应用架构演变为基于单元（cells）和微服务（microservices）架构后，获得了许多好处。新的架构降低了开发、测试和部署所需的时间，同时提高了可伸缩性和用户体验，包括商家、送餐员和消费者。然而，随着微服务和后端数量的增加，DoorDash 注意到了跨可用区（AZ）的数据传输成本上升。这些数据传输成本 — 在发送和接收时发生 — 允许 DoorDash 为其最终用户提供高可用性的服务，可以抵御一个或多个 AZ 的降级。\n成本上升促使我们的工程团队调查了以更高效的方式提供相同级别的服务的替代方法。在本博客文章中， …","relpermalink":"/blog/doordash-service-mesh/","summary":"本文介绍了 DoorDash 如何使用服务网格来优化其跨可用区的数据传输，降低成本和延迟。作者分享了他们的流量架构、问题分析和解决方案设计，以及使用 Envoy 和 Istio 实现区域感知路由的过程和效果。","title":"DoorDash 的服务网格之旅：如何实现高效的区域感知路由"},{"content":"注：原文发布于 2020 年 12 月，以下内容未在当下得到验证，可能已经过时。\n本文介绍了如何配置并在 AWS NLB 和 Istio Ingress 网关的堆栈中启用代理协议的最新经验。代理协议 旨在在不丢失客户端信息的情况下链接代理和反向代理。代理协议避免了对基础架构进行更改或 NAT 防火墙的需求，并提供了协议不可知性和良好可伸缩性的优势。此外，我们还在部署中启用了 X-Forwarded-For HTTP 标头，以便轻松读取客户端 IP 地址。在本文中，展示了 Istio Ingress 的流量管理，使用端口 80 和 443 上的 httpbin 服务来演示代理协议的使用。请注意，代理协议的 v1 和 v2 都适用于此示例，但由于 AWS NLB 目前仅支持 v2，因此默认情况下在本文的其余部分使用代理协议 v2。下图显示了在 AWS NLB 中使用代理协议 v2。\nAW NLB 中启用代理协议的页面 接收器可以配置为支持协议的版本 1 和版本 2。识别协议版本很容易：\n如果传入的字节计数为 16 或更多，并且前 13 …","relpermalink":"/blog/show-source-ip/","summary":"如何在 AWS NLB 和 Istio Ingress 网关上启用代理协议。","title":"在 AWS NLB 和 Istio Ingress 网关上启用代理协议"},{"content":"版本 1 和 2 摘要\nPROXY 协议提供了一种方便的方式，可以安全地传输连接信息，例如客户端的地址，跨越多层 NAT 或 TCP 代理。它旨在对现有组件进行少量更改，并限制由传输信息处理引起的性能影响。\n修订历史\n2010/10/29 - 第一个版本 2011/03/20 - 更新：实现和安全性考虑 2012/06/21 - 添加对二进制格式的支持 2012/11/19 - 最终审查和修复 2014/05/18 - 修改和扩展 PROXY 协议版本 2 2014/06/11 - 修复示例代码以考虑 ver+cmd 合并 2014/06/14 - 修复示例代码中的 v2 头检查，并更新 Forwarded 规范 2014/07/12 - 更新实现列表（添加 Squid） 2015/05/02 - 更新实现列表和 TLV 附加组件的格式 2017/03/10 - 添加校验和、noop 和更多与 SSL 相关的 TLV 类型、保留的 TLV 类型范围、添加 TLV 文档、澄清字符串编码。Andriy Palamarchuk（Amazon.com）的贡献。 2020/03/05 - 添加唯 …","relpermalink":"/blog/proxy-protocol/","summary":"本文译自 Proxy Protocol 定义文档。","title":"Proxy 协议"},{"content":"本文译自：Battle of the Pods: Kubernetes Autoscaling Showdown - KEDA vs. vanilla Kubernetes\n摘要：本文比较了 Kubernetes 的内置自动伸缩器（HPA 和 VPA）和 KEDA 项目的优缺点，分析了它们在不同场景下的适用性和效果，展示了 KEDA 如何解决 HPA 和 VPA 无法覆盖的复杂需求。\n1. 引言：自动伸缩的重要性 在今天的云原生生态系统中，波动的工作负载和动态的流量模式是常态。适应这种不可预测的行为需要能够实时调整的系统。自动伸缩是必需的，可以确保资源的最佳分配，遏制过度成本，并促进资源的高效使用。\n自动伸缩不仅关乎成本。它在维护应用性能和吞吐量方面发挥着关键作用。通过避免欠配置（导致用户体验不佳）和过度配置（导致不必要的成本），自动伸缩可以实现合理的平衡。\n2. 竞争者：了解基础知识 水平 Pod 自动伸缩器（HPA） HPA，作为 Kubernetes 的本地解决方案，根据观察到的指标（主要是 CPU 和内存）来扩展 Pod 的数量。虽然对于统一的工作负载来说非常直接和有益，但当考 …","relpermalink":"/blog/battle-of-the-pods-kubernetes-autoscaling-showdown-keda-vs-vanilla-kubernetes/","summary":"本文比较了 Kubernetes 的内置自动伸缩器（HPA 和 VPA）和 KEDA 项目的优缺点，分析了它们在不同场景下的适用性和效果，展示了 KEDA 如何解决 HPA 和 VPA 无法覆盖的复杂需求。","title":"KEDA vs. 原生 Kubernetes：谁是云原生应用的自动伸缩王者？"},{"content":"本文译自 Why the Latest Advances in OpenTelemetry Are Significant。\n摘要：OpenTelemetry 是一个标准化观测性和遥测数据格式的项目，支持多种工具的互操作。本文介绍了该项目的新特性，如新的转换语言、日志支持和自动化修复能力。\n今年，在云原生计算基金会（Cloud Native Computing Foundation）中，一个备受关注的项目是OpenTelemetry和OpenTelemetry Collector。这个项目是观测领域的一个非常令人兴奋的运动，旨在跨行业合作，达成观测和遥测的标准数据格式。\n这本身就非常重要，因为它允许多个观测和分析工具进行互操作，而以前的团队如果想要一个工具与另一个工具进行互操作，就必须多次转换数据。随着观测领域围绕人工智能/机器学习的炒作，公司更有可能从一个系统中存储和查看数据，然后在另一个系统中进行机器学习模型的训练。\n更棒的是，由于行业供应商和个人在OpenTelemetry Collector上合作，这个项目继续不断发展。它是一个标准化的代理和遥测收集器，提供高吞吐量的遥测数据收 …","relpermalink":"/blog/why-the-latest-advances-in-opentelemetry-are-significant/","summary":"OpenTelemetry 是一个标准化观测性和遥测数据格式的项目，支持多种工具的互操作。本文介绍了该项目的新特性，如新的转换语言、日志支持和自动化修复能力。","title":"OpenTelemetry 的最新进展及其对可观测性的影响"},{"content":"本文译自：Application traffic with eBPF\n摘要：本文介绍了如何使用 eBPF 程序捕获、分析和修改应用层的网络数据，包括 HTTP 头部和 URL 路径。作者还展示了如何使用 eBPF map 在内核和用户空间之间传递数据。\n在先前的帖子中，我稍微谈到了建立 eBPF 知识，以开始更多地了解网络适配器的输入和输出情况。基本上，将以太网帧并剥离标头（以太网标头+IP 标头+TCP/UDP 标头），最终你将得到来自应用程序或数据角度的数据包中剩余的内容。\n所有的代码都在“学习 eBPF”存储库中，具体的 eBPF 代码在这里。这篇文章的计划是逐步介绍我认为有用或可能重要的部分…\n注意：此代码确实对入口/出口数据包进行了一些修改，因此需要 6.1+ 的 Linux 内核才能使用一些 eBPF 助手函数。\n映射！ 你可能以前遇到过这些吧？如果没有，不用担心！简而言之，eBPF 映射是在用户空间和内核中的 eBPF 程序之间通信的机制。在我看来，非常酷的一点是这些映射使用键和值…所以我不必循环比较数据并寻找匹配的内容，我传递一个键，如果有匹配的内容，我就得到相应的数 …","relpermalink":"/blog/application-traffic-with-ebpf/","summary":"本文介绍了如何使用 eBPF 程序捕获、分析和修改应用层的网络数据，包括 HTTP 头部和 URL 路径。作者还展示了如何使用 eBPF map 在内核和用户空间之间传递数据。","title":"用 eBPF 洞察应用层网络流量"},{"content":"本文译自：eBPF adventures in networking\n摘要：这篇文章介绍了 eBPF 在网络领域的一些应用和实践，包括 XDP、TC 和 sysprobes 三种不同的 eBPF 程序挂载方式的优缺点，以及如何使用 eBPF 实现网络数据的捕获、分析和修改。作者还分享了一些有用的 eBPF 工具和资源，以及自己开发的一个 eBPF 网络代理的项目。\n我一直想写一些关于 eBPF 的帖子，希望它们能有所帮助，尽管通常在我想到可能有用的东西时，其他人已经先我一步了。鉴于我已经在网络方面集中精力一段时间，这基本上是我专注的领域，尽管我确实设法为最近的 eBPF 峰会 2023 准备了一些我认为很有趣的东西。正如我之前提到的，有很多人开始撰写关于 eBPF 的内容，因此我可能会参考他们的帖子，而不是重复内容。\n我将从一些在 Linux 内核中可能或可能不会遇到的首字母缩写或技术开始。但基本上从我的角度来看，这些是你修改正在运行的系统以与网络数据交互的主要选项。\nXDP 关于 eXpress Data Plane 已经存在大量信息，因此我不会深入探讨太多细节。tl;dr是 XDP …","relpermalink":"/blog/ebpf-adventures-in-networking/","summary":"这篇文章介绍了 eBPF 在网络领域的一些应用和实践，包括 XDP、TC 和 sysprobes 三种不同的 eBPF 程序挂载方式的优缺点，以及如何使用 eBPF 实现网络数据的捕获、分析和修改。作者还分享了一些有用的 eBPF 工具和资源，以及自己开发的一个 eBPF 网络代理的项目。","title":"如何用 eBPF 改变网络编程的游戏规则"},{"content":"本文译自 Securing cloud native’s most important use cases。\n摘要：云原生软件开发意味着为公有云和私有云的特性优化应用和环境。Chainguard 旨在提供不影响开发者体验的软件供应链安全工具，通过提供最小化、强化的容器镜像，让用户能够准确地扫描漏洞并消除 CVE 警报。本文介绍了 Chainguard Images 为 Istio 和 Cilium 这两个云原生基础技术提供的安全增强方案。\n从根本上说，构建云原生软件意味着构建针对公共和私有云特性进行优化的应用程序和环境。开发云原生软件意味着管理一定程度的混乱，这不是所有类型的软件都需要的。\n这在新的一年尤其重要，我们可以预期产品将趋向于优先考虑开发者体验，并且平台工程的崛起。良好的工程和工具使开发者可以专注于构建和创新。已经构建的所有内部开发者平台和即将推出的平台都需要尽量将基础设施管理从开发者那里抽象出来。\n这正是 Chainguard 想要解决的问题领域，特别是在安全性和漏洞管理方面。我们致力于提供不妨碍开发者体验的工具，以确保软件供应链的安全。我们通过提供最小化、加固的容器镜像来 …","relpermalink":"/blog/securing-cloud-natives-most-important-use-cases/","summary":"云原生软件开发意味着为公有云和私有云的特性优化应用和环境。Chainguard 旨在提供不影响开发者体验的软件供应链安全工具，通过提供最小化、强化的容器镜像，让用户能够准确地扫描漏洞并消除 CVE 警报。本文介绍了 Chainguard Images 为 Istio 和 Cilium 这两个云原生基础技术提供的安全增强方案。","title":"云原生软件的关键用例安全保障之道"},{"content":"这份报告回顾了 Cilium 项目在 2023 年的成就和进展，包括贡献者增长、版本亮点、用户调查结果、生产环境案例、社区活动和引用、以及 2024 年的发展方向。报告显示，Cilium 项目已经成为云原生网络、可观测性和安全性的领导者，得到了广泛的认可和采用。报告还展示了 Cilium 项目的健康状况和活跃度，通过数据和图表展示了项目的里程碑和提交情况。报告最后感谢了社区的支持和贡献，以及期待未来的更多创新和协作。\n详情见：https://www.cncf.io/blog/2023/12/21/ciliums-2023-annual-report/\n下载地址：GitHub\n以下内容选取自报告中的 release highlight 部分。\n版本更新 Cilium 在 2023 年进行了两次重大发布。Cilium 1.13 于 2 月发布，针对网络（特别是服务网格）、性能和软件供应链安全等方面进行了许多改进。Cilium 1.14 于 7 月发布，引入了一个备受期待的功能：与主要改进相结合的双向身份验证，同时扩展了 Kubernetes 之外的网络。Tetragon 1.0 于 10  …","relpermalink":"/blog/cilium-2023-annual-report/","summary":"这份报告回顾了 Cilium 项目在 2023 年的成就和进展，包括贡献者增长、版本亮点、用户调查结果、生产环境案例、社区活动和引用、以及 2024 年的发展方向。","title":"Cilium 2023 年度报告发布"},{"content":"Kubernetes 是构建灵活可扩展基础设施以运行动态工作负载的优秀解决方案。然而，随着我们的集群扩展，我们可能会面临同时扩展和管理多个集群的不可避免情况。这个概念可能会给我们的日常工作负载维护带来很多复杂性，并增加在所有环境中保持所有策略和服务的最新性的难度。在这种情况下，集群网格 可以在这些集群之间建立无缝的连接，并将工作负载集成到统一的网络环境中。\n集群网格是连接独立 Kubernetes 集群并在不同集群中的资源之间提供连接性的绝佳方式，以提供超出单个集群情况下可能的容错性和高可用性。\n在本博客文章中，我们将引导你完成构建多集群环境并建立集群网格所需的步骤，利用 Calico Open Source 的多功能能力。我们将探讨不同的方法，如顶级机架 (TOR) 和 overlay，以建立集群网格，解决不同环境提出的独特网络挑战。这是可能的，因为 Calico 提供了建立多集群环境的多种方法，灵活适应你的网络基础设施和特定要求。此外，我们还将介绍如何加入 DNS 连通性以增强集群间通信。\n随着你的集群网格环境扩展，我们将讨论涉及联邦和使用 Calico Enterprise 进行 …","relpermalink":"/blog/what-is-a-kubernetes-cluster-mesh-and-what-are-the-benefits/","summary":"这篇文章介绍了集群网格的概念和优势，以及如何使用 Calico Open Source 的多种方法，实现跨集群的服务间通信和负载均衡。","title":"如何使用 Calico 构建和管理 Kubernetes Cluster Mesh"},{"content":"在 Kubernetes 上部署应用程序后，通常的下一步是让用户可以访问它。我们通常使用Ingress 控制器，例如 Nginx、Haproxy、Traefik 或来自云提供商的控制器，来引导传入的流量到应用程序，管理负载平衡、TLS 终止等等。\n然后，我们必须从众多可用的选项 中进行选择。Cilium 是其中一个相对较新的选项，旨在处理所有这些网络方面的问题。\nCilium 是一个基于 eBPF 的开源网络和安全解决方案，其采用速度增长迅猛。它可能是提供最多功能的网络插件之一。我们不会涵盖所有功能，但其中一个功能涉及使用Gateway API (GAPI) 管理传入流量。\n我们的目标 准确了解 Gateway API 是什么，以及它如何代表从 Ingress API 进化而来。 演示以 GitOps 方式部署的真实场景。 当前的限制和即将推出的新功能。 提示\n本文中执行的所有步骤都来自这个git 存储库。\n我鼓励你探索它，因为它远远超出了本文的范围：\n使用启用了 kube-proxy 替代并具有专用 Daemonset 用于 Envoy 的 Cilium 配置的 EKS 集群的安装。 …","relpermalink":"/blog/cilium-gateway-api/","summary":"这篇文章介绍了如何使用 Cilium 部署和配置 Gateway API，一个新的服务网格 API，用于管理 Kubernetes 中的服务间通信。文章详细说明了 Gateway API 的概念和组件，以及如何使用 Cilium 的特性和工具，实现高效和灵活的路由策略。","title":"使用 Cilium 实现 Gateway API 指南"},{"content":"本文译自：Scaling the Sidecar。\n本文讨论我们如何在工作负载中扩展 Istio Sidecar，以及如何考虑 Sidecar 资源与应用程序紧密耦合的关系。\n目前有很多关于 Istio 新的 Ambient Mesh 的讨论。这种部署服务网格的新方法放弃了 Sidecar，而采用了两个新组件，ztunnel，一个用于处理核心 L4 网络问题的每节点组件，以及（如果需要）waypoint proxy 来处理 L7 问题。\n来源：https://istio.io/v1.15/blog/2022/introducing-ambient-mesh\n我听到的远离 Sidecar 的一个主要原因是，扩展 Sidecar 很复杂。如果只使用 L4 功能，我同意这一观点。然而，作为 L7 功能的重度用户，对我来说，似乎我们只是在管理 Waypoint 代理的规模，而不是 Sidecar。对我个人而言，也许有点自私，它感觉像是一个横向（充其量）的步骤，而不是前进。\n此外，我并不觉得管理 Sidecar 资源很痛苦，所以我很难产生共鸣。这部分是因为我从早期就开始使用 Istio，并建立了 …","relpermalink":"/blog/scaling-and-sizing-the-sidecar/","summary":"这篇博客介绍了作者在使用 Istio Sidecar 时，如何通过可视化和分析 Sidecar 的数据，以及使用 HPA 和 VPA 来自动调整 Sidecar 的大小，提高应用程序的效率和稳定性","title":"Istio Sidecar 的资源和性能管理：从监控到自动扩缩容的最佳实践"},{"content":"本文译自：OpenTelemetry and Observability: Looking Forward\n让我们探讨一些令人兴奋的趋势，考虑到我们期待 2024 年会有什么样的可观测性发展。\n随着年底的临近，现在是一个停下来思考的好时机。2023 年对于 OpenTelemetry 来说是一个里程碑，因为其三个基本信号，跟踪、度量和日志，都达到了稳定版本。这一成就标志着OpenTelemetry最初愿景的实现，即提供一个基于标准的框架，用于仪器化和收集可观测性数据。\n让我们抓住这个机会，探讨一下我们所见证的一些令人兴奋的趋势，深入研究创新的产品和用例，并在期待 2024 年的到来时深思熟虑地考虑可观测性的不断演变。\n度量标准的崭露头角 尽管 OpenTelemetry 关于度量的规范在 2022 年 5 月被宣布为稳定版本，但今年看到了其被广泛采用。以下是一些从业者的文章：\n由 VMware 的 Matthew Kocher 和 Carson Long 撰写的文章，标题为“体验报告：在 Cloud Foundry 中采用 OpenTelemetry 进行度量”。 …","relpermalink":"/blog/opentelemetry-and-observability-looking-forward/","summary":"本文展望 2024 年可观测性的发展。","title":"OpenTelemetry 与可观测性：展望未来"},{"content":"本文译自：What Will Be the API Management Trends for 2024?\n我们已经审视了 2023 年的发展，并确定了几个可能在明年主导 API 管理领域的关键趋势。\n根据一个想法：API 完全控制了数字世界，预测到本十年结束时，API 管理市场将增长六倍。\n随着越来越多的公司转向 API 为先的架构，API 管理的需求变得至关重要。一家组织可能会管理数百甚至数千个微服务，它们需要工具来有效地编排和监控这些 API。\n因此，随着这种增长的开始，API 管理在未来会带来什么？我们已经审视了 2023 年的发展，并确定了几个可能在 2024 年主导 API 管理领域的关键趋势。\n是时候实行零信任了（这并不是坏事！） 随着 API 的不断增加，安全漏洞、黑客和 API 问题的风险也在增加。将零信任安全概念与你的 API 战略结合起来，倡导一种安全模型，其中不管交互发生在网络边界内还是外部，都不会假定信任。\n这种方法要求对每个试图访问网络内资源的个人和设备进行严格的身份验证，有效地消除了传统的受信任的内部网络概念。在数据泄露和恶意行为者变得越来越复杂的时代，采 …","relpermalink":"/blog/what-will-be-the-api-management-trends-for-2024/","summary":"本文预测了 2024 年 API 管理的六大趋势，包括多源 API、多种 API 标准和格式、API 技术的解耦、API 的自动化和智能化、API 的无服务器化和边缘化、以及 API 的 GitOps 化。","title":"2024 年 API 管理趋势预测"},{"content":"编者按 本文译自：Grafana dashboards in 2023: Memorable use cases of the year。\n摘要：这篇文章回顾了 2023 年社区中一些令人印象深刻的 Grafana 仪表盘的用例，它们展示了 Grafana 的多样性和创造力，以及如何用可视化的方式监控和分析各种数据和场景。\n正文 随着每年使用 Grafana 的用户人数增加，人们使用 Grafana 仪表板 的原因也日益多样化。在 2023 年，我们社区内外的成员分享了一些令人难以置信的专业和个人项目，包括 Grafana 如何帮助他们成功发射火箭，减少碳排放，甚至帮助平衡国家电网。让我们回顾一下今年看到的一些最令人难忘的仪表板：\n获奖者 Grafana 在六月份迎来了 10 岁的生日，为了庆祝这一时刻，我们首次推出了 Golden Grot 奖项，这些奖项帮助突出显示了我们社区创建的令人惊叹的 Grafana 仪表板。但今年并不是唯一一个与仪表板相关的胜利：今年三月，加州大学洛杉矶分校的火箭工程团队使用 Grafana 作为测试和发射过程中的可视化工具，在一次业余火箭竞赛中赢得了冠 …","relpermalink":"/blog/grafana-dashboards-in-2023-memorable-use-cases-of-the-year/","summary":"这篇文章回顾了 2023 年社区中一些令人印象深刻的 Grafana 仪表盘的用例，它们展示了 Grafana 的多样性和创造力，以及如何用可视化的方式监控和分析各种数据和场景。","title":"令人惊叹的 Grafana 仪表盘用途：2023 年最有创意和有趣的用例分享"},{"content":"介绍 在过去的十年里，源代码交付过程发生了显著变化。在这个过程的部署方面，最近的适应是采用了一种声明式和版本控制的方法来定义应用程序所需的基础设施状态和配置，通常称为 “GitOps”。这种方法在云原生应用程序和容器编排平台（如 Kubernetes）的背景下变得流行起来，因为在这些环境中管理复杂的分布式系统可能会很具挑战性。\n由于这种所需的状态具有声明性质，它指向了特定/静态版本的应用程序。这带来了显著的好处，特别是可以在进行更改之前审计更改、回滚到先前状态并保持可重复的设置。然而，在不需要管道来更改应用程序的状态/配置的情况下，我们如何迁移到更新的应用程序版本而避免手动版本调整呢？\n这就是 Argo CD Image Updater 的作用所在；它验证容器镜像的更近版本是否可用，随后触发应用程序的 Kubernetes 资源的必要更新，或者可选择更新关联的版本控制。\n概述 在深入研究技术实现之前，让我们先了解 GitOps 过程的概述，并强调 Argo CD Image Updater 在此过程中的角色。\n默认 GitOps 该过程的第一部分始于开发人员修改应用程序的源代码并将更改 …","relpermalink":"/blog/extending-gitops-effortless-continuous-integration-and-deployment-on-kubernetes/","summary":"本文介绍了如何使用 ArgoCD 在 Kubernetes 中实现 GitOps。","title":"拓展 GitOps：在 Kubernetes 上轻松实现持续集成和部署"},{"content":"编者按 本文译自：OpenTelemetry best practices: A user’s guide to getting started with OpenTelemetry\n摘要：文章介绍了 OpenTelemetry 的概念和优势，以及如何使用 Grafana 的分发版进行自动和手动的仪表化、配置和导出数据。\n评论：这是一篇非常实用和有价值的文章，它为 OpenTelemetry 的新手和老手提供了一些最佳实践和技巧，帮助他们更好地利用这个强大的服务网格平台，实现应用程序的可观测性和安全性。文章不仅介绍了 OpenTelemetry 的基本概念和组件，还展示了如何使用 Grafana 的分发版，轻松地对 Java 和 .NET 应用程序进行仪表化，发送遥测数据到 Grafana Cloud，以及优化数据的质量和成本。文章还提供了一些有用的链接和资源，供读者进一步学习和探索。我认为这篇文章是 OpenTelemetry 的一个很好的入门指南，也是 Grafana 的一个很好的推广案例，值得云原生社区的关注和推荐。\n正文 如果你正在阅读这篇博客， …","relpermalink":"/blog/opentelemetry-best-practices/","summary":"文章介绍了 OpenTelemetry 的概念和优势，以及如何使用 Grafana 的分发版进行自动和手动的仪表化、配置和导出数据。","title":"OpenTelemetry 最佳实践：用户入门指南"},{"content":"编者按 本文译自：https://thenewstack.io/7-best-practices-for-developers-getting-started-with-genai/\n编辑评论：这是一篇非常有价值的文章，向开发者展示了生成式 AI 的潜力和应用。生成式 AI 是一种利用大型语言模型来生成和转换文本的技术，它可以帮助开发者解决一些复杂的问题，如代码生成，文档编写，内容创作等。生成式 AI 也是一种云原生的技术，它需要大量的计算资源和数据，以及高效的部署和管理方式。文章提供了一些实用的工具和平台，如 GitHub Copilot，Bard，ChatGPT 等，让开发者可以轻松地尝试和使用生成式 AI。文章还给出了一些注意事项和建议，如保护数据隐私，验证输出质量，避免滥用等，让开发者可以负责任地使用生成式 AI。我认为这篇文章是一个很好的入门指南，让开发者可以了解和利用生成式 AI 来打造创新的云原生应用。\n正文 通过一点经验，你可以使用 GenAI 解决一些相当困难的问题，就像学习任何新技术一样，最好的方法就是动手实践。\n随着可访问的生成式人工智能进入主流，以及由此产生的通 …","relpermalink":"/blog/7-best-practices-for-developers-getting-started-with-genai/","summary":"这篇文章分享了七个步骤，帮助开发者掌握生成式 AI 的基本概念和技能。","title":"给初学生成式 AI（GenAI）的开发人员的 7 条最佳实践"},{"content":"本文译自：https://thenewstack.io/does-kubernetes-really-perform-better-on-bare-metal-vs-vms/\n摘要：本文对比了虚拟机和裸机上 Kubernetes 集群的 CPU、RAM、存储和网络性能的详细比较。\n许多人认为部署在裸机上的 Kubernetes 集群比部署在虚拟机上的性能更好，但直到现在都没有关于这一假设的证据。在 Gcore，我们只提供基于充分证据的信息给客户，因此我们决定自行测试 Kubernetes 是否在裸机上比在虚拟机上表现更好，如果是的话，差距有多大。我将分享我们内部测试的结果。\n我故意不讨论虚拟节点与裸机节点竞争的其他方面，如成本效益或基础设施控制级别。这超出了本文的范围，本文只关注性能比较。\nVM 和裸机 Kubernetes 之间的区别 当您在虚拟机上部署 Kubernetes 集群时，与裸机（BM）相比，您会得到额外的基础设施层，即虚拟机监视器和客户操作系统。\n显示裸机和虚拟机架构差异的图表 图 1：裸机和虚拟机架构的差异。\n这些层占用物理 CPU 和 RAM 来运行，从工作负载中拿 …","relpermalink":"/blog/does-kubernetes-really-perform-better-on-bare-metal-vs-vms/","summary":"本文对比了虚拟机和裸机上 Kubernetes 集群的 CPU、RAM、存储和网络性能的详细比较。","title":"Kubernetes 在裸机上比虚拟机表现更好吗：Kubernetes 性能对比实验"},{"content":"云原生社区报道：Mitchell Hashimoto 的离职意味着 HashiCorp 这一领先的云原生工具和解决方案提供商将迎来新的篇章。他在离开之际分享了对过去的回顾和对未来的展望。HashiCorp 社区和生态系统将继续发展壮大，我们期待看到他们在云原生领域取得更多的成功。\n下文是 Mitchell Hashimoto 在 Hashicorp 官网上发布的离职感言。\n正文 在经过超过 11 年的时光后，HashiCorp 共同创始人 Mitchell Hashimoto 写下了一封深情的告别信，向他所帮助创立的公司告别。\n2023 年 12 月 14 日，作者：Mitchell Hashimoto\n本周早些时候，我向 HashiCorp 的员工发送了这封信，并在这里发布，以让整个 HashiCorp 社区了解我的计划：\n今天，我有一些双重情感要与大家分享：我决定离开 HashiCorp，不久后将不再是该公司的员工。我刚刚庆祝了自从开始 HashiCorp 以来的 11 年，回顾过去的十年，我认为自己无法找到更好的方式来度过我生命的这一部分。\n我离开 HashiCorp 是我长时间 …","relpermalink":"/blog/mitchell-reflects-as-he-departs-hashicorp/","summary":"Mitchell Hashimoto 的离职意味着 HashiCorp 这一领先的云原生工具和解决方案提供商将迎来新的篇章。他在离开之际分享了对过去的回顾和对未来的展望。HashiCorp 社区和生态系统将继续发展壮大，我们期待看到他们在云原生领域取得更多的成功。","title":"HashiCorp 创始人 Mitchell Hashimoto 宣布离职"},{"content":"本文译自：https://thenewstack.io/how-to-observe-your-ci-cd-pipelines-with-opentelemetry\n摘要：这篇文章介绍了 OpenTelemetry 这个开源框架，它可以帮助你生成、收集换和导出 CI/CD 管道的遥测数据，以实现性能、可靠性、安全性等方面的度量、监控、告警、分析等功能。\n如今的软件比 20 多年前的软件复杂得多，这带来了在故障排除代码时面临新挑战。幸运的是，通过将可观测性引入我们的系统，我们在理解应用程序的性能如何以及问题发生在何处方面取得了相当大的进展。\n然而，不仅软件发生了演变 - 创建和开发软件的过程也发生了变化。DevOps引入了CI/CD的概念。随着交付周期从每月、每季度，到现在每周甚至一天多次，我们正在全面采用自动化来进行软件交付。\n不幸的是，与应用程序软件相比，CI/CD流水线的可观测性进展不大。考虑到这些流水线是软件交付流程的基础，这令人惊讶：如果你没有可见性，那么当出现问题且无法将软件投入生产时，你该如何排除问题？\n这正是本文将重点讨论的内容：CI/CD 流水线的可观测性。首先，我们将 …","relpermalink":"/blog/how-to-observe-your-ci-cd-pipelines-with-opentelemetry/","summary":"这篇文章介绍了 OpenTelemetry 这个开源框架，它可以帮助你生成，收集，转换和导出 CI/CD 管道的遥测数据，以实现性能，可靠性，安全性 等方面的 度量，监控，告警，分析等功能。","title":"使用 OpenTelemetry 提升 CI/CD 管道的可观察性"},{"content":"本文译自 CNCF 官方博客。\nCNCF（技术监督委员会（TOC））已经投票批准归档服务网格接口（SMI）项目。\nSMI 被创建为在 Kubernetes 上为服务网格提供标准接口以及最常见的服务网格用例的基本功能集。它于 2020 年 3 月被接受为 CNCF 沙盒项目。\nSMI 是第五个被 CNCF 归档的项目。开源项目有一个生命周期，项目可能因各种原因而不活跃。还有一些情况下，项目可能不再希望得到 CNCF、维护者或 TOC 的支持。\nCNCF 的 CTO Chris Aniszczyk 表示：“在 CNCF 中，项目有一个生命周期，有时包括归档项目，特别是因为沙盒项目是用于实验的。这实际上是维护一个健康的开源生态系统的一部分。”他还说：“项目将自然地在生命周期中移动，并可能变得不太活跃，或者可能不再适合某个用例。就 SMI 而言，维护者已经决定将精力集中在 Kubernetes SIG Network 倡议下的 GAMMA 服务网格上。”\n在 2022 年 7 月，SMI 团队更新了项目博客站点：宣布 SMI 参与 Gateway API GAMMA 倡议。在 SMI 旗下没有 …","relpermalink":"/blog/cncf-archives-the-service-mesh-interface-smi-project/","summary":"CNCF（技术监督委员会（TOC））已经投票批准归档 Service Mesh Interface（SMI）项目。","title":"CNCF 将服务网格接口（SMI）项目归档"},{"content":"本文译自：https://www.infracloud.io/blogs/starting-platform-engineering-journey-backstage/\n摘要：这篇文章介绍了 Backstage 这个开源工具，它可以帮助你创建和管理一个内部开发平台，以提高开发团队的效率和协作。文章还展示了如何使用 Backstage 的模板和插件来构建和部署你的应用和服务。\n在不断增长的平台工程领域，它起源于 DevOps 实践，为软件开发团队提供自助服务功能，内部开发者门户或 IDP（Internal Developer Portals）正发挥着越来越重要的作用。通过提高协作、增加可见性和控制，内部开发者门户帮助组织快速高效地交付优质软件。\n在众多不同的内部开发者门户工具中，Backstage 是一个受欢迎的工具之一。Backstage 旨在通过为开发人员提供一个集中的地方来发现和使用服务，显著增强开发体验。本文探讨了其关键功能和优势，揭示了它如何在开发过程中发挥作用。但首先，让我们简要了解什么是内部开发者门户，以及它们为何在软件行业至关重要。\n什么是内部开发者门户（IDP）？ 内 …","relpermalink":"/blog/starting-platform-engineering-journey-backstage/","summary":"这篇文章介绍了 Backstage 这个开源工具，它可以帮助你创建和管理一个内部开发平台，以提高开发团队的效率和协作。文章还展示了如何使用 Backstage 的模板和插件来构建和部署你的应用和服务。","title":"使用 Backstage 开始平台工程之旅"},{"content":"本文译自：https://www.solo.io/blog/jwts-authenticate-services-api-gateways/\n摘要：这篇博客探讨了在云原生架构中使用 JSON Web Tokens（JWTs）进行服务间通信的复杂性。它详细讨论了通过 API 网关和服务网格实现安全认证的两种方法，强调了使用 JWTs 的挑战，包括安全性、密钥管理和性能问题。\n云原生架构中的 API 网关组件至关重要，因为它将关键的 API 安全性和策略功能卸载到一个公共位置，使后端 API 和服务能够专注于业务逻辑。API 身份验证、授权、审计、限流等任务可能会非常复杂且难以正确实现，因此许多组织选择使用 API 网关来处理它们。\n那么对于服务与服务（S2S）或内部东/西流量呢？强制 S2S 流量“回头”通过 API 网关会引入额外的跳跃、更多的延迟、增加的流量以及效率降低。\n通过 API 网关的 S2S 流量“回头”示意图 但是，如果您跳过 API 网关直接调用服务，如何确保流量的安全性？接收服务如何进行身份验证并知道是谁在调用它？\n显示 Service B 需要对 Service A …","relpermalink":"/blog/jwts-authenticate-services-api-gateways/","summary":"这篇博客探讨了在云原生架构中使用 JSON Web Tokens（JWTs）进行服务间通信的复杂性。它详细讨论了通过 API 网关和服务网格实现安全认证的两种方法，强调了使用 JWTs 的挑战，包括安全性、密钥管理和性能问题。","title":"JWT 在 API 网关中的角色：服务间认证的新视角"},{"content":"云原生社区最新报道：近日 IBM 发布了名为「IBM 混合云 Mesh」的多云网络解决方案，旨在为企业提供简单、可扩展、安全的应用程序中心化连接。该解决方案可帮助 CloudOps 团队实现可见性和优化，同时也有助于 DevOps 团队实现业务敏捷性。混合云 Mesh 通过连通各种环境，为应用程序和服务提供了无缝的入口。它还与 IBM NS1 Connect 的 DNS 流量引导功能相结合，提供可预测的延迟、带宽和成本。解决方案的核心组件包括 Mesh Manager 和 Gateways，用于集中管理、策略制定和数据传输。这一新范式将提高应用程序性能和安全性，促进团队协作，助力企业在多云环境中实现创新。\n在现代企业中，分布式软件应用程序需要始终可用、安全、响应迅速且全球优化的访问。为了为内部和外部用户提供这种应用体验，一个安全的混合云战略至关重要。我们对混合云的愿景非常清晰：帮助客户通过随时随地构建、部署和管理应用程序和服务，加速实现积极的业务成果。\n传统的 CloudOps 和 DevOps 模型涉及手动工作流程，可能无法提供所需的应用程序体验。IBM 坚信，现在是采取新方法的时 …","relpermalink":"/blog/app-centric-connectivity-a-new-paradigm-for-a-multicloud-world/","summary":"IBM 发布了名为「IBM 混合云 Mesh」的多云网络解决方案，旨在为企业提供简单、可扩展、安全的应用程序中心化连接。该解决方案可帮助 CloudOps 团队实现可见性和优化，同时也有助于 DevOps 团队实现业务敏捷性。混合云 Mesh 通过连通各种环境，为应用程序和服务提供了无缝的入口。它还与 IBM NS1 Connect 的 DNS 流量引导功能相结合，提供可预测的延迟、带宽和成本。解决方案的核心组件包括 Mesh Manager 和 Gateways，用于集中管理、策略制定和数据传输。这一新范式将提高应用程序性能和安全性，促进团队协作，助力企业在多云环境中实现创新。","title":"IBM 提出多云世界的新范式：App-centric Connectivity"},{"content":" Matt Klein 的推文宣布推出公司第一个产品及完成 A 轮融资 云原生社区报道：\n近期，Matt Klein——Envoy 代理的创造者——领导下的创业公司 Bitdrift 发布了他们的首款产品：Capture。这款专注于移动端可观测性的产品获得了 1500 万美元 A 轮融资，由 Amplify Partners 领投。这标志着 Bitdrift 在解决移动和服务器端可观测性问题方面迈出了重要的一步。\nBitdrift 初创团队 Bitdrift 的创始缘起于团队在规模化构建互联网基础设施时的挑战和挫折。公司团队来自 Twitter、AWS、Square、Google、Microsoft、Netflix 等知名企业，他们认为当前的可观测性生态系统存在供应商和消费者之间的不匹配问题。Bitdrift 旨在通过实时动态控制，仅发出可能用于解决客户问题的遥测数据，以改变这一现状。\n目前，移动端可观测性被认为是浪费、无序且远落后于服务器端。大约 95% 用于监控系统健康的数据从未被阅读。与此同时，移动工程师在生产中拥有的分析事件集合通常是静态的，而且调整这些事件以调试正在进行的问题 …","relpermalink":"/blog/matt-created-bitdrift/","summary":"Envoy 创始人 Matt Klein 领导的 Bitdrift 宣布推出首款产品 Capture，并完成 1500 万美元 A 轮融资。Capture 旨在革新移动端可观测性，允许动态实时控制遥测数据，大幅提高移动开发者的调试效率。这标志着 Bitdrift 在提升移动和服务器端可观测性方面迈出了重要一步，预示着可观测性生态系统的未来发展方向。","title":"Envoy 创始人 Matt Klein 领衔 Bitdrift 创业，推出创新移动可观测性产品并获得 1500 万美元 A 轮融资"},{"content":" 活动介绍：https://hdxu.cn/ysqsP\n视频回放：https://space.bilibili.com/515485124/channel/collectiondetail?sid=1927922\nPPT 下载：https://github.com/cloudnativeto/academy/tree/master/meetup/13-guangzhou\n现场图片直播：https://as.alltuu.com/album/1335461604/?from=appmessage\n详细回顾见：https://mp.weixin.qq.com/s/zbVr_C0lcDoJq7Qtl_RKfg\n注：应企业的要求，第一场分享不提供 PPT 下载和视频回放，敬请谅解。\n","relpermalink":"/event/cloud-native-meetup-guangzhou-13/","summary":"云原生金融科技开放日。","title":"云原生社区 meetup 第13期广州站"},{"content":"本文译自：https://istio.io/latest/blog/2023/egress-sni/\n摘要：一种通用方法，用于动态设置出口网关，可以将流量路由到一组受限制的目标远程主机，包括通配符域名。\n如果您正在使用 Istio 处理来自网格外部目标的应用程序发起的流量，那么您可能熟悉出口网关的概念。出口网关可用于监控并转发来自网格内应用程序的流量到网格外的位置。如果您的系统在受限环境中运行，并且希望控制从网格到公共互联网上可以访问什么，那么这是一个有用的功能。\n在官方 Istio 文档中，直到版本 1.13，包括配置出口网关以处理任意通配符域名的用例，但随后被移除，因为文档中的解决方案没有得到官方支持或推荐，而且可能在将来的 Istio 版本中失效。尽管如此，旧的解决方案仍然可以在 1.20 之前的 Istio 版本中使用。然而，Istio 1.20 放弃了一些对该方法工作所需的 Envoy 功能。\n本文试图描述我们如何解决了这个问题，并通过使用与 Istio 版本无关的组件和 Envoy 功能以及无需单独的 Nginx SNI 代理来填补这个空白。我们的方法允许旧解决方案的用户在 …","relpermalink":"/blog/istio-egress-sni/","summary":"一种通用方法，用于动态设置出口网关，可以将流量路由到一组受限制的目标远程主机，包括通配符域名。","title":"将出口流量路由到通配符目标"},{"content":"本文译自：https://thenewstack.io/how-ciliums-mutual-authentication-can-compromise-security/\n摘要：这篇文章是关于如何使用 Cilium 来实现 互相认证 (mTLS) 的，以及这种方法可能带来的安全问题。文章介绍了 Cilium 的特点和功能，以及如何使用 Cilium CLI 或 Hubble UI 来创建和管理证书和策略。文章还分析了 Cilium 的互相认证的局限和风险，例如证书过期，撤销，泄露和伪造等。文章的目的是帮助用户了解和使用 Cilium 来提高服务间的安全性。\n最近，Cilium 项目宣布支持一种新的双向认证机制，可以通过简单的配置标志透明地部署到应用程序中。从表面上看，这似乎是一种简单的方法，可以使用 Cilium 为 Kubernetes 工作负载实现服务之间的双向认证。然而，这种设计存在一个严重的缺陷，不容忽视：\nCilium 中的双向认证的整个基础是最终一致性。\n在安全实现的数据路径中，最终一致性可能导致意图中的安全属性失败，并且可能导致在不应该允许的情况下服务之间的流量继续传 …","relpermalink":"/blog/how-ciliums-mutual-authentication-can-compromise-security/","summary":"这篇文章是关于如何使用 Cilium 来实现 互相认证 (mTLS) 的，以及这种方法可能带来的安全问题。文章介绍了 Cilium 的特点和功能，以及如何使用 Cilium CLI 或 Hubble UI 来创建和管理证书和策略。文章还分析了 Cilium 的互相认证的局限和风险，例如证书过期，撤销，泄露和伪造等。文章的目的是帮助用户了解和使用 Cilium 来提高服务间的安全性。","title":"Ciilium 的相互认证如何危及安全"},{"content":"本文译自：https://istio.io/latest/blog/2023/istio-at-kubecon-na/\n摘要：本文介绍了 Istio 在 KubeCon North America 2023 的活动安排，包括 Istio Day、主题演讲、维护者跟踪和赞助商信息。\n快速回顾一下 2023 年 KubeCon 北美大会在芝加哥 McCormick Place 举行的情况。\n开源和云原生社区于 11 月 6 日至 9 日在芝加哥齐聚一堂，参加了 2023 年的最后一场 KubeCon。这四天的会议由云原生计算基金会组织，对于 Istio 来说可谓是“乐趣翻倍”，因为我们从 4 月的欧洲半天活动发展到了全天共同举办的活动。更令人兴奋的是，Istio Day 北美也标志着我们作为 CNCF 毕业项目的首次活动。\n随着 Istio Day 北美的结束，我们 2023 年主要社区活动也告一段落。如果你错过了它们，Istio Day 欧洲于 4 月举行，而与我们的虚拟 IstioCon 2023活动一同举行的2023 年 IstioCon 中国于 9 月 26 日在中国上海举行。 …","relpermalink":"/blog/istiocon-at-kubecon-na/","summary":"本文介绍了 Istio 在 KubeCon North America 2023 的活动安排，包括 Istio Day、主题演讲、维护者跟踪和赞助商信息。","title":"KubeCon 北美大会同场活动 IstioCon 2023 回顾"},{"content":"上个周末的 OpenAI“宫斗”大戏相信大家都知晓了，今天正巧看到 Ben Thompson 的这篇总结文章，感觉不错，分享给大家。\n关于作者：Ben Thompson（本·汤普森）是一位知名的科技和商业评论家，他是 Stratechery（《战略》）博客的创始人和作者。Stratechery 是一家专注于科技产业和商业策略分析的网站，汤普森在博客中深入剖析科技公司、产品、行业趋势和商业模式。他的文章通常涵盖了互联网、数字媒体、云计算、人工智能等领域的重要话题。\nBen Thompson 因其深刻的洞察力和独特的分析方法而闻名，他的文章常常引发行业内外的广泛讨论。他的分析不仅关注技术本身，还关注技术如何塑造和影响商业和社会。由于其博客的高质量内容，他已经建立了一支忠实的读者群，并成为了科技产业和商业领域的重要声音之一。\n下文译自：https://stratechery.com/2023/openais-misalignment-and-microsofts-gain/\n摘要： 这篇文章分析了 OpenAI 的使命与商业模式之间的不一致，以及 Microsoft 如何从中受益。文章认 …","relpermalink":"/blog/openais-misalignment-and-microsofts-gain/","summary":" 这篇文章分析了 OpenAI 的使命与商业模式之间的不一致，以及 Microsoft 如何从中受益。文章认为，OpenAI 的 GPT-3 模型是一种强大的通用人工智能，但是它的许可协议限制了它的应用范围。Microsoft 作为 OpenAI 的合作伙伴和投资者，拥有 GPT-3 的独家许可权，可以将其用于自己的产品和服务，从而获得竞争优势。","title":"微软零成本收购 OpenAI？——OpenAI 的错位与微软的收益"},{"content":"本文译自：https://www.infracloud.io/blogs/decoding-workload-specification-for-effective-platform-engineering/\n摘要：这篇文章介绍了工作负载规范的概念和作用，它是一种标准化的方法，可以简化和统一不同环境下的软件部署，减轻开发者的认知负担。\n在理想的情况下，开发人员专注于编写应用程序，而运维团队专注于将它们的工作负载无缝部署到不同的环境中。然而，现实远非如此。\n开发人员经常难以理解每个部署目标的细微差别，这增加了他们的认知负担。例如，他们可能在本地开发中使用 Docker Compose，但他们的工作负载可能在 Kubernetes 环境中部署。这种差距可能导致错误和不一致，影响工作负载的开发和部署。\n这就是为什么有迫切需要通过内部开发者平台（IDP）的标准化方法来配置工作负载。平台工程试图通过提供工具来管理工作负载来解决这个问题。\n在这篇博文中，我们将深入探讨工作负载规范的复杂性，这有助于简化代码从一个环境过渡到另一个环境，并减轻开发人员的认知负担。听起来激动人心吗？让我们深入了解。\n了解 …","relpermalink":"/blog/decoding-workload-specification/","summary":"这篇文章介绍了工作负载规范的概念和作用，它是一种标准化的方法，可以简化和统一不同环境下的软件部署，减轻开发者的认知负担。","title":"如何用工作负载规范打造高效的平台工程服务"},{"content":"本文译自：https://medium.com/@aditya.barik32/ordering-of-container-within-pod-a423d2e5ba52\n摘要：讨论了在 Kubernetes Pod 中排序容器的需求，介绍了开源工具 Kubexit 实现容器的有序启动和终止，提高工作流灵活性。\n为什么要在 Pod 中对容器进行排序？ 在某些情况下，Pod 的排序可能是一个使用案例，我们需要确保某些容器在启动应用程序代码之前已经正常运行。假设我们有一个 Java 应用程序，需要一个数据库（Mysql）、缓存（Aerospike/Redis）和 Kafka 来提供流量。与此同时，我们还需要这些依赖关系是特定于实例或与应用程序堆栈本地关联的。在这种情况下，在 v1.28 版本之前，Kubernetes 没有提供一个开箱即用的解决方案。对于版本小于 1.28 的集群，没有正式的解决方法。为了缓解这个问题，我们有另一种不太知名的开源解决方法，叫做 Kubexit。\n什么是 Kubexit？ Kubexit 是一个开源项目，旨在提供一种协调的方式来启动和终止 Pod 内的容器。\n …","relpermalink":"/blog/ordering-containers-within-pod/","summary":"本文讨论了在 Kubernetes Pod 中排序容器的需求，介绍了开源工具 Kubexit 实现容器的有序启动和终止，提高工作流灵活性。","title":"解密 Kubernetes Pod 中容器的有序部署：Kubexit 工具的妙用"},{"content":"摘要：本文回顾了 KubeCon NA 2023 五个引人入胜的主题演讲，涵盖微型容器、Kubernetes LTS、Kubernetes 未来愿景、优化 Kubernetes 资源使用、生成式 AI 在平台工程的应用。讨论了微型容器的尺寸对可持续性的影响，稳定性与创新的平衡，Kubernetes 未来发展方向，以及 AI 和资源优化在云原生环境中的重要性。整体看，Kubernetes 作为云原生平台在稳定性、安全性、简易性方面迎来了新的发展阶段。\nKubeCon + CloudNativeCon North America 2023，云原生的旗舰会议，已于几天前正式结束。本文包含了这三天中最有趣的演讲和公告。废话不多说，让我们进入回顾吧。✌️\n微型容器的微型讨论 — Eric Gregory，Mirantis 镜像大小的问题对可持续性、存储和网络效率等方面产生了重要影响。这就是为什么我们将首先讨论的话题是 Eric Gregory 的“微型容器的微型讨论”。这个话题对我个人也很有兴趣，我尝试过使用 Docker Slim 来减小镜像大小（包括集成到 CI/CD 流水线中），结果确实令 …","relpermalink":"/blog/kubecon-na-5-interesting-keynotes/","summary":"本文回顾了 KubeCon NA 2023 五个引人入胜的主题演讲，涵盖微型容器、Kubernetes LTS、Kubernetes 未来愿景、优化 Kubernetes 资源使用、生成式 AI 在平台工程的应用。讨论了微型容器的尺寸对可持续性的影响，稳定性与创新的平衡，Kubernetes 未来发展方向，以及 AI 和资源优化在云原生环境中的重要性。整体看，Kubernetes 作为云原生平台在稳定性、安全性、简易性方面迎来了新的发展阶段。","title":"KubeCon North America 2023:5 个有趣的主题演讲摘要"},{"content":"本文译自：https://danielbryantuk.medium.com/kubecon-chicago-key-takeaways-3de5ca13b375\n摘要：本文讨论了 KubeCon 的主要议题，包括平台工程、Kubernetes 的不断发展、开发者体验的重要性、对应用开发和集成的关注、云原生通信的捆绑问题、安全问题的重要性、对可持续性的关注，以及社区的力量。文章强调了在标准化和创新之间取得平衡的重要性，并预测云原生的未来将看到更多的 AI/LLMs。\n这次 KubeCon NA 对我来说是一次非常不同的体验，因为我不是代表公司或办展位。然而，我仍然度过了一段愉快的时光，与云原生社区的许多人见面真是太棒了。回到芝加哥也很不错，这座城市对我们很好 —— 我几乎忘记了我有多喜欢芝加哥式深盘披萨！\n以下是我从 KubeCon NA 2023 中得出的主要收获：\n云原生社区正在缓慢接受AI/LLM DevOps 已经过时：平台工程万物 山中有金！在平台激战中销售镐和铲子 Kubernetes 应该保持不完整（并不断发展） 别忘了开发者体验！ 增加对应用程序开发和集成的关注 云原生 …","relpermalink":"/blog/kubecon-chicago-key-takeaways/","summary":"本文讨论了 KubeCon 的主要议题，包括平台工程、Kubernetes 的不断发展、开发者体验的重要性、对应用开发和集成的关注、云原生通信的捆绑问题、安全问题的重要性、对可持续性的关注，以及社区的力量。文章强调了在标准化和创新之间取得平衡的重要性，并预测云原生的未来将看到更多的 AI/LLMs。","title":"KubeCon Chicago 主要收获：人工智能（AI）的缓慢崛起，平台工程的主导地位，以及 KubeCon NA 2023 对开发者体验的重新关注"},{"content":"译者注： 本文译自：https://www.cncf.io/blog/2023/10/11/kubernetes-secure-development-best-practices-in-action/\n本文作者基于 NGINX Gateway Fabric 项目（一个基于 Kubernetes Gateway API 的实现）的开发实例来展现 Kubernetes 下的最佳安全开发实践。\n本文作者来自：F5 NGINX 高级软件工程师 Saylor Berman 和 F5 NGINX 高级软件工程师 Ciara Stacke。\n使用最小 Docker 容器是容器化领域的一种流行策略，因为它具有安全性和资源效率的优势。这些容器是传统容器的精简版本，旨在仅包含运行应用程序所需的基本组件。在某些情况下，base 容器可能根本不包含任何内容（这将是“scratch”容器）。\n许多人尽可能简单地创建 Docker 映像来让他们的应用程序正常工作。这涉及选择一个基础映像，例如“ubuntu”或“python”，其中包含启动和运行所需的所有库和工具。虽然简单，但由于内部所有额外的“东西”，导致这些 …","relpermalink":"/blog/kubernetes-secure-development-best-practices-in-action/","summary":"作者基于 NGINX Gateway Fabric 项目（一个基于 Kubernetes Gateway API 的实现）的开发实例来展现 Kubernetes 下的最佳安全开发实践。","title":"Kubernetes 安全开发最佳实践的实际应用"},{"content":"译者注： 本文译自：https://www.nginx.com/blog/why-we-decided-to-start-fresh-with-our-nginx-gateway-fabric/\nGateway API 已经正式 GA，您可能好奇作为社区的一个重要实现，F5 NGINX 是如何决策和发展该项目的。F5 的产品管理总监 Brian Ehlert 以及首席软件工程师 Matthew Yacobucci 将在本文中为您阐述NGINX Gateway Fabric项目状态，以及未来的目标。\n在 Kubernetes Ingress 控制器的世界里，NGINX 已经非常成功地运行了。NGINX Ingress Controller 被广泛部署用于商业 Kubernetes 生产用例，同时也作为开源版本进行开发和维护。因此，你可能会认为，当 Kubernetes 网络（Gateway API）出现重大改进时，我们会继续做一件好事，并在我们现有的 Ingress 产品中实现它。\n相反，我们选择了一条不同的道路。看到新的 Gateway API 的惊人可能性， …","relpermalink":"/blog/why-we-decided-to-start-fresh-with-our-nginx-gateway-fabric/","summary":"Gateway API 已经正式 GA，您可能好奇作为社区的一个重要实现，F5 NGINX 是如何决策和发展该项目的。F5 的产品管理总监 Brian Ehlert 以及首席软件工程师 Matthew Yacobucci 将在本文中为您阐述 NGINX Gateway Fabric 项目及其未来的目标。","title":"为什么我们决定从新开始我们的 NGINX Gateway Fabric"},{"content":"本文译自：https://istio.io/latest/blog/2023/secure-apps-with-istio/\n摘要：本文讨论了使用相互 TLS (mTLS) 和 Istio 保护应用程序通信的重要性。mTLS 提供了端到端的安全性，只有源和目标可以解密数据，从而防止中间人攻击。然而，如果源或目标的身份没有加密，可能会出现问题。Istio 中的 mTLS 可以简单地启用，并为每个应用程序 pod 提供身份证书。为了强制执行严格的 mTLS，可以使用 Istio 的 PeerAuthentication 策略和 AuthorizationPolicy。最后，TLS 协议是最广泛审查、专家批准、经过战斗测试的数据安全协议之一，Istio 默认在内网应用程序通信中使用 TLS 1.3 版本。\n用户采用服务网格的最大原因之一是使用相互 TLS（mTLS）基于可通过加密验证的身份来启用应用程序之间的安全通信。在此博客中，我们将讨论应用程序之间安全通信的要求，以及 mTLS 如何实现并满足所有这些要求，以及使用 Istio 启用应用程序之间 mTLS 的简单步骤。\n您需要什么来保护应 …","relpermalink":"/blog/secure-apps-with-istio/","summary":"本文讨论了使用相互 TLS (mTLS) 和 Istio 保护应用程序通信的重要性。mTLS 提供了端到端的安全性，只有源和目标可以解密数据，从而防止中间人攻击。然而，如果源或目标的身份没有加密，可能会出现问题。Istio 中的 mTLS 可以简单地启用，并为每个应用程序 pod 提供身份证书。为了强制执行严格的 mTLS，可以使用 Istio 的 PeerAuthentication 策略和 AuthorizationPolicy。最后，TLS 协议是最广泛审查、专家批准、经过战斗测试的数据安全协议之一，Istio 默认在内网应用程序通信中使用 TLS 1.3 版本。","title":"使用相互 TLS 和 Istio 保护应用程序通信"},{"content":"本文译自：https://playbook.samaltman.com/\n摘要：创业指南强调了几个关键方面：首先，创业公司应快速解雇对文化有毒的员工，忽略竞争对手，特别是当他们筹集大量资金或在媒体上制造大量噪音时。其次，创业公司需要找到盈利的方法，尽快达到“拉面盈利”的状态，即赚足够的钱让创始人可以靠拉面度日。最后，筹资是大多数创业公司在某个时候都会面临的问题，成功筹资的秘诀是拥有一家好公司，而不是过度优化流程。创业公司应该在需要资金或者在条件好的情况下筹资，但要小心不要失去节俭精神，或者开始通过投钱来解决问题。\n作者 Sam Altman 是一位知名的企业家和投资人，他是 OpenAI 的创始人，Y Combinator（一家著名的创业孵化器）的前任主席。\n我们花了很多时间为创业公司提供咨询。虽然一对一的建议一直是至关重要的，但我们认为，如果我们能将这些建议中最能普遍化的部分提炼成一种可以给 YC 和 YC Fellowship 公司的指南，可能会帮助我们扩大 YC 的规模。\n然后我们想，我们应该把它给所有人。\n这本指南主要是为创业世界的新人准备的。对于已经阅读过很多 YC 合作伙伴 …","relpermalink":"/blog/startup-playbook/","summary":"创业指南强调了几个关键方面：首先，创业公司应快速解雇对文化有毒的员工，忽略竞争对手，特别是当他们筹集大量资金或在媒体上制造大量噪音时。其次，创业公司需要找到盈利的方法，尽快达到“拉面盈利”的状态，即赚足够的钱让创始人可以靠拉面度日。最后，筹资是大多数创业公司在某个时候都会面临的问题，成功筹资的秘诀是拥有一家好公司，而不是过度优化流程。创业公司应该在需要资金或者在条件好的情况下筹资，但要小心不要失去节俭精神，或者开始通过投钱来解决问题。","title":"创业指南"},{"content":"近日 Kubernetes Gateway API 宣布 GA，此版本包括将 Gateway、GatewayClass 和 HTTPRoute 升级到 v1，这意味着它们现在已全面可用 (GA)。此 API 版本表示对 API 表面的高度信任，并提供向后兼容性的保证。请注意，尽管标准通道中包含的这些 API 的版本现在被认为是稳定的，但这并不意味着它们是完整的。当这些 API 满足毕业标准时，将继续通过实验渠道接收新功能。有关所有这些工作原理的更多信息，请参阅网关 API 版本控制策略。\nKubernetes Gateway API logo 与此同时 Gateway API 项目组发布了 ingress2gateway 工具，它可以帮助你从 Ingress 迁移到 Gateway API。Gateway API 距离 GA（General Availability，正式版本）发布只有几周的时间，如果你还没有进行升级，现在是时候考虑一下了！\n背景 在不断发展的 Kubernetes 世界中，网络在其中起着至关重要的作用。随着越来越多的应用程序部署在 Kubernetes 集群中，将这些 …","relpermalink":"/blog/gateway-api-ingress2gateway/","summary":"Kubernetes Gateway API 正式发布，简化了 Gateway API 的升级。Gateway API 解决了 Ingress 在处理非 HTTP 工作负载方面的限制，并提供了更灵活、可扩展和强大的流量管理方式。它基于核心原则，使基础设施工程师、集群操作员和应用程序开发人员能够共同解决问题。ingress2gateway 工具简化了从 Ingress 迁移到 Gateway API 的过程。Gateway API 的设计具有可移植性、表达性和可扩展性的特点，提供了标准化支持。ingress2gateway 工具可以帮助简化从 Ingress 迁移到 Gateway API 的过程。Gateway API 是未来的 Kubernetes 网络标准，得到了 SIG Network 的支持和社区的积极参与。ingress2gateway 计划接入更多提供商，引入对更多类型的 Gateway API 路由的支持。Gateway API 即将发布 v1.0 版本，包含许多新功能。","title":"Kubernetes Gateway API 正式发布并引入 ingress2gateway 项目用于简化 Gateway API 升级"},{"content":"本文译自：https://www.uipath.com/inside-the-rocketship/tech-stories/optimizing-traffic-routing-uipath-automation-suite-envoy-wasm\n在这篇博文中，我们将深入探讨 UiPath Automation Suite 的路由基础设施，揭示关键见解和创新方法以提升性能。\nUiPath Automation Suite 内部的流量路由 UiPath Automation Suite使您能够在 Linux 上部署完整的UiPath Business Automation Platform，该平台由 40 多个微服务组成的 Kubernetes 集群。它有一个 API 网关位于所有微服务之前，具有自定义的路由业务逻辑，例如服务发现、请求拦截、请求操作和错误处理等。\n我们使用 Istio 和 Envoy 这个流行的组合作为路由基础设施，路由业务逻辑通过 Envoy 过滤器内的 Lua 脚本实现。除了以下几个痛点外，此解决方案运作良好：\n无法直接连接 Redis： …","relpermalink":"/blog/optimizing-traffic-routing-uipath-automation-suite-envoy-wasm/","summary":"在这篇博文中，我们将深入探讨 UiPath Automation Suite 的路由基础设施，揭示关键见解和创新方法以提升性能。","title":"在 UiPath Automation Suite 中使用 Envoy 和 WASM 优化流量路由"},{"content":"本文译自：https://www.infoq.com/presentations/dapr-cloud-services/，是 Ibryam 今年三月在 QCon London 的分享。\n摘要：软件堆栈的商品化是如何改变应用为先的云服务的游戏规则。通过使用开源项目和 API 将应用程序与集成逻辑绑定在一起，可以实现更高级别的抽象。Dapr 是一组作为 API 公开的分布式基元，可以作为 Sidecar 部署。应用程序云服务将计算和集成能力作为 SaaS 提供，开发人员可以将核心应用程序逻辑绑定到云服务上。这种应用程序优先云服务的出现使得应用程序可以更加专业化，并且可以在不同的云提供商之间灵活迁移。\nIbryam: 我叫 Bilgin Ibryam。我在这里要告诉大家我对云服务的演变以及这将如何影响我们正在构建的分布式应用的看法。这将是一个快节奏的演讲，我们没有时间深入研究每个技术和模式，而是快速概述架构的演变，并试图分析这对云原生应用的未来可能意味着什么。我是 Diagrid 的产品经理，我们正在为开发人员构建 API。在此之前，我是红帽公司的顾问、架构师和产品经理，在那里我使用了一些 …","relpermalink":"/blog/dapr-cloud-services/","summary":"软件堆栈的商品化是如何改变应用为先的云服务的游戏规则。通过使用开源项目和 API 将应用程序与集成逻辑绑定在一起，可以实现更高级别的抽象。Dapr 是一组作为 API 公开的分布式基元，可以作为 Sidecar 部署。应用程序云服务将计算和集成能力作为 SaaS 提供，开发人员可以将核心应用程序逻辑绑定到云服务上。这种应用程序优先云服务的出现使得应用程序可以更加专业化，并且可以在不同的云提供商之间灵活迁移。","title":"软件堆栈的商品化：应用为先的云服务如何改变游戏规则"},{"content":"本文译自：https://medium.com/@shrishs/understanding-grpc-load-balancing-in-kubernetes-with-istio-c6e71634724c\n摘要：本文介绍了在 Kubernetes 和 Istio 中使用 gRPC 负载均衡的行为。首先，通过创建命名空间、部署资源和配置文件来准备环境。然后，介绍了没有 Istio 的情况下，gRPC 服务的负载均衡行为。接下来，介绍了如何使用 Istio 创建虚拟服务和目标规则来实现负载均衡。还讨论了 ConnectionPoolSetting 对负载均衡行为的影响。最后，介绍了如何通过入口网关访问 gRPC 服务，并提供了验证步骤。\ngRPC（gRPC 远程过程调用）是一个跨平台的开源高性能远程过程调用（RPC）框架，使用 HTTP/2 进行传输。gRPC 相对于传统的 HTTP 机制具有诸多优势，例如在一个连接上多路复用多个请求（HTTP/2）。本文将解释在 Kubernetes（RedHat Openshift）和（Redhat Openshift Service Mesh）中 …","relpermalink":"/blog/understanding-grpc-load-balancing-in-kubernetes-with-istio/","summary":"本文介绍了在 Kubernetes 和 Istio 中使用 gRPC 负载均衡的行为。首先，通过创建命名空间、部署资源和配置文件来准备环境。然后，介绍了没有 Istio 的情况下，gRPC 服务的负载均衡行为。接下来，介绍了如何使用 Istio 创建虚拟服务和目标规则来实现负载均衡。还讨论了 ConnectionPoolSetting 对负载均衡行为的影响。最后，介绍了如何通过入口网关访问 gRPC 服务，并提供了验证步骤。","title":"理解使用 Istio 在 Kubernetes 中的 gRPC 负载均衡"},{"content":" 本文译自：https://sysdig.com/blog/top-owasp-kubernetes/\n摘要：OWASP Kubernetes Top 10 强调了 Kubernetes 生态系统中的关键风险和漏洞。它涵盖了诸如准入控制器中的配置错误，密钥管理故障，漏洞管理，身份验证机制失效以及过时和易受攻击的 Kubernetes 组件等主题。建议包括使用像 Falco 这样的工具来检测安全问题，对静态密钥进行加密，解决安全配置问题，确保日志记录和审计，扫描容器镜像以检测漏洞，管理依赖关系，保护对 Kubernetes 的访问以及及时了解 CVE 情况。\n使用 Kubernetes 时最大的关切之一是是否符合安全态势，并考虑到所有可能的威胁。因此，OWASP 创造了 OWASP Kubernetes Top 10，以帮助识别最可能的风险。\nOWASP Top 10 项目是对安全从业人员和工程师非常有用的认知和指导资源。它们也可以映射到其他安全框架，帮助事件响应工程师了解 Kubernetes 的威胁。MITRE ATT\u0026amp;CK 技术也常用于记录攻击者的技术，并帮助蓝队了解保护环境的最佳 …","relpermalink":"/blog/top-owasp-kubernetes/","summary":"OWASP Kubernetes Top 10 强调了 Kubernetes 生态系统中的关键风险和漏洞。它涵盖了诸如准入控制器中的配置错误，密钥管理故障，漏洞管理，身份验证机制失效以及过时和易受攻击的 Kubernetes 组件等主题。建议包括使用像 Falco 这样的工具来检测安全问题，对静态密钥进行加密，解决安全配置问题，确保日志记录和审计，扫描容器镜像以检测漏洞，管理依赖关系，保护对 Kubernetes 的访问以及及时了解 CVE 情况。","title":"构建安全的 Kubernetes 环境：OWASP Kubernetes Top 10"},{"content":"本文译自：https://fiberplane.com/blog/why-are-prometheus-queries-hard\nPrometheus 是一个强大的开源可观测性工具。但是许多人，包括我自己，都很难理解其查询语言。在这篇文章中，我将从头开始建立一个基本的查询，并使用每个步骤来解释 PromQL 中一些较难理解的方面。希望这能更直观地展示 Prometheus 的工作原理，帮助你编写查询并理解数据。\n关于Autometrics项目的一个快速介绍：它是一个开源微型框架，使你可以轻松地为代码添加最有用的指标，并为你编写 Prometheus 查询。无需手动编写查询，即可在生产环境中识别和调试问题！\n用“简单”的查询回答问题 假设我们正在运行一个 HTTP API，并且我们想了解用户遇到错误的频率。这似乎是一个简单的问题，对吧？\n为了从 Prometheus 中获取这个答案，我们需要进行类似以下的查询，其中已经涉及了很多内容：\nsum by (status) (rate(http_requests_total[5m])) 为了理解为什么这个查询有效，以及为什么我们需要这个查询，我 …","relpermalink":"/blog/why-are-prometheus-queries-hard/","summary":"Prometheus 是一个强大的开源可观测性工具。但是许多人，包括我自己，都很难理解其查询语言。在这篇文章中，我将从头开始建立一个基本的查询，并使用每个步骤来解释 PromQL 中一些较难理解的方面。希望这能更直观地展示 Prometheus 的工作原理，帮助你编写查询并理解数据。","title":"为什么 Prometheus 查询很难？"},{"content":"摘要：本文介绍了如何在 Docker 容器中运行 GUI 应用程序。通过使用 x11docker 应用程序，可以轻松启动带有桌面环境的 GUI 容器，并提供了许多功能，如 GPU 硬件加速、声音、剪贴板共享等。文章还提供了安装 Docker 运行时引擎和 x11docker 的详细步骤，并演示了使用 VLC 媒体播放器在容器中运行 GUI 应用程序的示例。\n本文译自：https://thenewstack.io/run-gui-applications-as-containers-with-x11docker/\n作为开发人员，您可能需要使用 GUI 容器进行工作。如果是这种情况，您会很快发现，传统的 Docker 运行时引擎并不支持运行 GUI 应用程序（除非它们是基于 Web 的类型）。当您想要开发容器化的 GUI 应用程序时，您该怎么办呢？\n幸运的是，有许多第三方应用程序可以在桌面上轻松启动 GUI 容器。正如您可能预期的那样，这需要一个桌面环境（否则，您将在更传统的基于服务器的设置上进行开发）。其中一个应用程序叫做 x11docker。顾名思义，此应用程序与 Linux X 显示 …","relpermalink":"/blog/run-gui-applications-as-containers-with-x11docker/","summary":"本文介绍了如何在 Docker 容器中运行 GUI 应用程序。通过使用 x11docker 应用程序，可以轻松启动带有桌面环境的 GUI 容器，并提供了许多功能，如 GPU 硬件加速、声音、剪贴板共享等。文章还提供了安装 Docker 运行时引擎和 x11docker 的详细步骤，并演示了使用 VLC 媒体播放器在容器中运行 GUI 应用程序的示例。","title":"如何在 Docker 容器中运行 GUI 应用程序"},{"content":" 2023 年 9 月 12 日，KCL 项目通过了全球顶级开源基金会云原生计算基金会（CNCF）技术监督委员会评定，正式成为 CNCF 沙箱项目。\n这意味着 KCL 得到了云原生开源社区的认可，保障了项目的中立性，有利于开发者、合作伙伴等共同参与项目建设，协作共赢，并为云原生应用交付带来动态配置管理和自动化能力迈出了重要一步！\n项目地址：https://github.com/kcl-lang/kcl 项目官网：https://kcl-lang.io 通过进入 CNCF 沙箱，KCL 社区将更多吸引更多开发者和用户参与共建，进一步推动项目在云原生业务场景的成熟应用，此外加入 CNCF 将为 KCL 提供一个增强的协作和创新平台。它提供了与处于云原生技术前沿的多元化开发者、组织和行业专家社区进行交流的机会。我们期待与其他 CNCF 项目进行更多合作，贡献我们的技术专业知识，并探索更多 CNCF 项目集成的可能性。\n什么是 CNCF？ CNCF，全称 Cloud Native Computing Foundation（云原生计算基金会），是 Linux 基金会旗下的子基金会。CNCF 致力 …","relpermalink":"/blog/kcl-joining-cncf-sandbox/","summary":"2023 年 9 月 12 日，KCL 项目通过了全球顶级开源基金会云原生计算基金会（CNCF）技术监督委员会评定，正式成为 CNCF 沙箱项目。","title":"Kubernetes 配置语言 KCL 正式成为 CNCF 沙盒项目"},{"content":"本文源自：https://thenewstack.io/webassembly/yes-webassembly-can-replace-kubernetes/\n摘要：WebAssembly 可以作为一种部署应用程序的方式，可以在服务器操作系统上运行，且在许多不同的硬件环境中表现出色。与 Kubernetes 相比，WebAssembly 的优点在于简易性和安全性。但是，Kubernetes 始终有其用途，它将始终用于编排微服务和容器。因此，对于某些用例来说，WebAssembly 可以替代 Docker 和容器，但是在高度分布式的云原生环境中，使用 WebAssembly 来编排容器和微服务程度上与 Kubernetes 相同的程度是不可能的。\n是的，WebAssembly 可以解决 Kubernetes 的一些问题。\nWebAssembly 或 Wasm 被证明是一种在 Web 浏览器上运行代码的非常实用的方式，它可以作为编译器。它已经作为一种语言运行得非常好，以至于世界万维网联盟（W3C）在 2019 年将其命名为 Web 标准，成为第四个 Web 标准，与 HTML、CSS …","relpermalink":"/blog/wasm-vs-kubernetes/","summary":"WebAssembly 可以作为一种部署应用程序的方式，可以在服务器操作系统上运行，且在许多不同的硬件环境中表现出色。与 Kubernetes 相比，WebAssembly 的优点在于简易性和安全性。但是，Kubernetes 始终有其用途，它将始终用于编排微服务和容器。因此，对于某些用例来说，WebAssembly 可以替代 Docker 和容器，但是在高度分布式的云原生环境中，使用 WebAssembly 来编排容器和微服务程度上与 Kubernetes 相同的程度是不可能的。","title":"WebAssembly 能够取代 Kubernetes 吗？探索其优势和限制"},{"content":"本文译自：https://thenewstack.io/7-steps-to-highly-effective-kubernetes-policies/\n摘要：本文介绍了 Kubernetes 策略的七个步骤，包括基线、修复标签和注释、迁移到受限制的 Pod Security 标准、压制误报、加入常见加固指南、插入并播放、添加自定义规则以应对未预料的特殊情况。通过实施这些步骤，可以逐步减少配置错误和漏洞的数量，实现认证、合规和长期安全目标。\n你刚刚开始了一份新工作，在这个工作中，你第一次有责任操作和管理 Kubernetes 基础设施。你对更深入地了解云原生充满了热情，但同时也非常担心。\n是的，你关注的是编写符合命名和资源使用控制最佳实践的安全应用程序的最佳方法，但是关于已经部署到生产环境中的所有其他内容呢？你打开一个新的工具来查看正在发生的情况，发现有 100 个高或严重的 CVE 和 YAML 配置问题。你关闭标签页告诉自己，你以后会处理所有这些问题的。\n你会吗？\n也许最有雄心壮志和无所畏惧的人会，但问题在于云原生社区喜欢谈论安全、标准化和“左移”，但这些对话都无法减轻因安全、资 …","relpermalink":"/blog/7-steps-to-highly-effective-kubernetes-policies/","summary":"本文介绍了 Kubernetes 策略的七个步骤，包括基线、修复标签和注释、迁移到受限制的 Pod Security 标准、压制误报、加入常见加固指南、插入并播放、添加自定义规则以应对未预料的特殊情况。通过实施这些步骤，可以逐步减少配置错误和漏洞的数量，实现认证、合规和长期安全目标。","title":"创建高效 Kubernetes 策略的 7 个步骤"},{"content":"摘要：本文讨论了在 Kubernetes 故障排除中的两种路径：一种是增强操作员的分析工作，通过自动化和简化对故障排除知识的访问来提供帮助；另一种是将操作员从故障排除中排除，通过使用 AI/ML 模型和可观察性数据来自动化故障修复。同时强调了数据的重要性，以及继续共享故障排除经验和建立对可观察性的一致认识的必要性。\n本文译自：https://thenewstack.io/can-chatgpt-save-collective-kubernetes-troubleshooting/\n数十年前，系统管理员们开始在互联网上分享他们每天面临的技术问题。他们进行了长时间、充满活力且富有价值的讨论，探讨如何调查和解决问题的根本原因，然后详细说明最终对他们有效的解决方案。\n这股洪流从未停歇，只是改变了流向。如今，这些讨论仍在 Stack Overflow、Reddit 以及企业工程博客上进行。每一次讨论都是对全球 IT 系统故障排除经验的宝贵贡献。\nKubernetes也从根本上改变了这种流向。与几十年来困扰系统管理员和 IT 人员的虚拟机（VM）和单体应用程序相比，微服务架构要复杂得多。 …","relpermalink":"/blog/can-chatgpt-save-collective-kubernetes-troubleshooting/","summary":"本文讨论了在 Kubernetes 故障排除中的两种路径：一种是增强操作员的分析工作，通过自动化和简化对故障排除知识的访问来提供帮助；另一种是将操作员从故障排除中排除，通过使用 AI/ML 模型和可观察性数据来自动化故障修复。同时强调了数据的重要性，以及继续共享故障排除经验和建立对可观察性的一致认识的必要性。","title":"Kubernetes 故障排除智慧的演变"},{"content":"本文译自：https://thenewstack.io/is-it-too-early-to-leverage-ai-for-webassembly/\n摘要：Fermyon Technologies 认为，将 AI 应用于 WebAssembly 并不为时过早。WebAssembly 为在服务器上运行推理提供了坚实的基础，而且在许多不同的环境中，如浏览器和物联网设备等，通过将这些工作负载移动到终端用户设备上，可以消除延迟并避免将数据发送到集中式服务器，同时能够在边缘发现的多种异构设备上运行。Fermyon Serverless AI 通过提供超过 100 倍于其他按需 AI 基础设施服务的亚秒冷启动时间来解决了企业级 AI 应用程序成本高的问题。这是一种共生关系。\n人工智能及其在 IT、软件开发和运营方面的应用刚开始发挥作用，预示着人类角色将如何在近期和长期内演变，特别是在较小的规模上，WebAssembly 代表着一种正在引起重大关注的技术，同时证明了其可行性，但成功的商业模型尚未实现，主要是由于最终端点的缺乏标准化。与此同时，至少有一家供应商 Fermyon 认为， …","relpermalink":"/blog/is-it-too-early-to-leverage-ai-for-webassembly/","summary":"Fermyon Technologies 认为，将 AI 应用于 WebAssembly 并不为时过早。WebAssembly 为在服务器上运行推理提供了坚实的基础，而且在许多不同的环境中，如浏览器和物联网设备等，通过将这些工作负载移动到终端用户设备上，可以消除延迟并避免将数据发送到集中式服务器，同时能够在边缘发现的多种异构设备上运行。Fermyon Serverless AI 通过提供超过 100 倍于其他按需 AI 基础设施服务的亚秒冷启动时间来解决了企业级 AI 应用程序成本高的问题。这是一种共生关系。","title":"将 AI 应用于 WebAssembly 还为时过早吗？"},{"content":"本文译自：https://istio.io/latest/news/releases/1.19.x/announcing-1.19/\nIstio 1.19 发布了，支持 Kubernetes Gateway API，并改进了 Ambient Mesh 部署模型。本次发布还包括安全配置增强和虚拟机和多集群体验的简化。欢迎提供升级过程中的反馈。\n我们很高兴地宣布 Istio 1.19 的发布。这是 2023 年的第三个 Istio 发布版本。我们要感谢整个 Istio 社区帮助发布 1.19.0 版本。我们要感谢这个版本的发布经理，Microsoft 的 Kalya Subramanian，DaoCloud 的 Xiaopeng Han，以及 Google 的 Aryan Gupta。发布经理们要特别感谢测试和发布工作组负责人 Eric Van Norman (IBM) 在整个发布周期中的帮助和指导。我们还要感谢 Istio 工作组的维护者和更广泛的 Istio 社区，在发布过程中及时提供反馈、审查、社区测试以及为确保及时发布的所有支持。\nIstio 官方支持 Kubernetes …","relpermalink":"/blog/istio-1-19-release/","summary":"Istio 1.19 发布了，支持 Kubernetes Gateway API，并改进了 Ambient Mesh 部署模型。本次发布还包括安全配置增强和虚拟机和多集群体验的简化。欢迎提供升级过程中的反馈。","title":"Istio 1.19 发布——支持 Gateway API 并改进了 Ambient Mesh 部署模型"},{"content":"本文译自：https://kubernetes.io/blog/2023/08/29/gateway-api-v0-8/\n作者： Flynn（Buoyant）、John Howard（Google）、Keith Mattix（Microsoft）、Michael Beaumont（Kong）、Mike Morris（独立）、Rob Scott（Google）\n我们非常高兴地宣布 Gateway API 的 v0.8.0 版本发布了！通过此版本，Gateway API 对服务网格的支持已达到实验性状态。我们期待您的反馈！\n我们特别高兴地宣布，Kuma 2.3+、Linkerd 2.14+ 和 Istio 1.16+ 都是 Gateway API 服务网格支持的完全符合实现。\nGateway API 中的服务网格支持 虽然 Gateway API 最初的重点一直是入口（南北）流量，但很快就清楚，相同的基本路由概念也应适用于服务网格（东西）流量。2022 年，Gateway API 子项目启动了GAMMA 计划，这是一个专门的供应商中立工作流， …","relpermalink":"/blog/gateway-api-release/","summary":"我们非常高兴地宣布 Gateway API 的 v0.8.0 版本发布了！通过此版本，Gateway API 对服务网格的支持已达到实验性状态。我们期待您的反馈！","title":"Gateway API v0.8.0: 引入服务网格支持"},{"content":"Istio 可以轻松创建具有丰富路由、负载均衡、服务间身份验证、监控等功能的已部署服务网络 - 所有这些都无需对应用程序代码进行任何更改。Istio 致力于以最小的资源开销提供这些优势，并旨在支持具有高请求率的大型网格，同时增加最小的延迟。\nIstio 数据平面组件（Envoy 代理）处理流经系统的数据。Istio 控制平面组件 Istiod 配置数据平面。数据平面和控制平面具有不同的性能问题。\nIstio 1.18 的性能摘要 Istio 负载测试网格由 1000 个服务和 2000 个 sidecar 组成，每秒有 70,000 个网格范围的请求。\n控制平面性能 Istiod 根据用户编写的配置文件和系统的当前状态来配置 sidecar 代理。在 Kubernetes 环境中，自定义资源定义 (CRD) 和部署构成了系统的配置和状态。Istio 配置对象（例如 Gateway 和 VirtualService）提供用户编写的配置。为了生成代理的配置，Istiod 处理来自 Kubernetes 环境的组合配置和系统状态以及用户编写的配置。\n控制平面支持数千个服务， …","relpermalink":"/blog/performance-and-scalability/","summary":"Istio 官方公布 Istio 1.18 性能测试结果。","title":"Istio 1.18 性能测试结果"},{"content":"嘉宾及讲师介绍\n张晓辉：\nCNCF ambassador，云原生社区管委会成员\n王青：\nJFrog 中国技术总监 十五年敏捷研发管理与软件工程实践经验，目前任 JFrog 中国技术团队负责人 阿里云 MVP\n叶天星：\n一个 Rust 初学者和 Rust 开源爱好者\n王璞：\n达坦科技（DatenLord）联合创始人。王璞博士拥有多年云计算领域的经验，擅长分布式计算、海量数据处理、大规模机器学习。\n王祖熙：\n铜锁项目核心成员之一，蚂蚁集团技术专家，专注于密码学、云原生、高性能和网络安全等领域的研发。\n彭柳：\nFlomesh 技术专家，资深网关研发。有多年的微服务和网关实践经验，主要工作涉及微服务、网关、容器、Kubernetes 等。\n详情见活动回顾。\n","relpermalink":"/event/cloud-native-meetup-chengdu-12/","summary":"本次活动关注云原生高性能 Rust \u0026 C++。","title":"云原生社区 meetup 第 12 期成都站"},{"content":"今天跟大家分享的 eBPF（extended Berkeley Packet Filter），相信很多技术人员已经很熟悉了。作为 Linux 社区的新宠，它备受 Goole、Facebook、Twitter 等大公司的青睐。\neBPF 究竟有什么魔力让大家这么关注 这是因为 eBPF 增加了内核的可扩展性，让内核变得更加灵活和强大。如果大家玩过乐高积木的话就会深有体会，乐高积木就是通过不断向主体添加积木来组合出更庞大的模型。而 eBPF 就像乐高积木一样，可以不断向内核添加 eBPF 模块来增强内核的功能。\n什么是 eBPF 在介绍 eBPF (Extended Berkeley Packet Filter) 之前，我们先来了解一下它的前身－BPF (Berkeley Packet Filter) 伯克利数据包过滤器。\nBPF 最早由 Van Jacobson 在 1992 年开发，用于在 Unix 操作系统中过滤和捕获网络数据包。它运行在内核中，通过提供一个简单而强大的虚拟机，可以在网络协议层上进行高效的数据包处理操作。BPF 通过把过程转换成指令序列来实现，这些指令直接在内核中执 …","relpermalink":"/blog/current-state-and-future-of-ebpf/","summary":"今天跟大家分享的 eBPF（extended Berkeley Packet Filter），相信很多技术人员已经很熟悉了。作为 Linux 社区的新宠，它备受 Goole、Facebook、Twitter 等大公司的青睐。","title":"深入浅出运维可观测工具（一）：聊聊 eBPF 的前世今生"},{"content":"摘要：O’Reilly 的雷达趋势报告列举了多个 AI、编程、安全、网络、加密货币、生物学和材料方面的趋势。其中包括 GPT-Prompt-Engineer、LlamaIndex、OpenAI 的代码解释器、WormGPT 等。此外，还有一些关于 Web 框架、浏览器、元宇宙、加密货币和室温常压超导体的趋势。\n本文译自：https://www.oreilly.com/radar/radar-trends-to-watch-august-2023/\n人工智能依然是新闻头条。在过去的一个月中，我们看到了许多语言模型的重大更新：Claude 2，其上下文限制为 10 万个令牌；LLaMA 2，限制相对较宽松；以及 Stable Diffusion XL，是 Stable Diffusion 的一个功能更强大的版本。Claude 2 的巨大上下文是否真的改变了模型的能力？开放访问和开源语言模型在商业应用发展中将扮演什么角色？\n人工智能 Stable Diffusion XL 是一个新的生成模型，扩展了 Stable Diffusion 的能力。它承诺更短、更容易的提示；正确地在图像内生成文本的 …","relpermalink":"/blog/radar-trends-to-watch-august-2023/","summary":"O'Reilly 的雷达趋势报告列举了多个 AI、编程、安全、网络、加密货币、生物学和材料方面的趋势。其中包括 GPT-Prompt-Engineer、LlamaIndex、OpenAI 的代码解释器、WormGPT 等。此外，还有一些关于 Web 框架、浏览器、元宇宙、加密货币和室温常压超导体的趋势。","title":"O'Reilly：值得关注的雷达趋势（2023 年 8 月）"},{"content":" 译者注：WebAssembly 的采用情况受到了组件模型的阻碍，这是一个需要解决的关键问题。尽管 WebAssembly 已经被广泛部署以提高应用程序在浏览器或后端运行时的性能，但其全部潜力尚未得到实现。为了实现一次编写、多处部署范例，需要一个通用的标准来将不同语言与其特定的功能集和设计范式集成起来。许多公司和大学的工程师正在开发组件模型、Wasi 提议和语言工具链，这些工程师的目标是将规范放入 W3C 中。\n原文地址：https://thenewstack.io/whats-holding-up-webassemblys-adoption/\nWebAssembly 的承诺是：将应用程序放在 WebAssembly（Wasm）模块中，可以提高运行时性能和降低延迟速度，同时提高跨平台的兼容性。\nWebAssembly 只需要 CPU 指令集。这意味着在 WebAssembly 模块中部署一个应用程序理论上应该能够在不同的不同的设备上运行和更新，无论是服务器、边缘设备、多云、无服务器环境等等。\n因此，WebAssembly 已经被广泛部署以提高应用程序在浏览器或后端运行时的性能。然 …","relpermalink":"/blog/whats-holding-up-webassemblys-adoption/","summary":"WebAssembly 的采用情况受到了组件模型的阻碍，这是一个需要解决的关键问题。尽管 WebAssembly 已经被广泛部署以提高应用程序在浏览器或后端运行时的性能，但其全部潜力尚未得到实现。为了实现一次编写、多处部署范例，需要一个通用的标准来将不同语言与其特定的功能集和设计范式集成起来。许多公司和大学的工程师正在开发组件模型、Wasi 提议和语言工具链，这些工程师的目标是将规范放入 W3C 中。","title":"WebAssembly 的采用受到了什么阻碍？"},{"content":"摘要：OpenTelemetry Protocol (OTLP) 1.0.0 已发布，它是 OpenTelemetry 项目中的通用遥测数据传递协议。OpenTelemetry 是一个开源的可观测性框架，提供了一组 API、库、代理和收集器服务，用于捕获分布式跟踪和指标。OTLP 在客户端和服务器之间进行数据交换，定义了一个序列化模式，紧密遵循跟踪、指标和日志的数据模型。\n原文地址：https://www.infoq.com/news/2023/08/otlp-version-one-released/\n最近，OpenTelemetry Protocol (OTLP) 1.0.0 发布了。OTLP 规范描述了遥测数据在遥测源、收集器等中间节点和遥测后端之间的编码、传输和传递机制。它是 OpenTelemetry 项目中设计的通用遥测数据传递协议。\nOpenTelemetry (OTEL) 是一个由 OpenCensus 和 OpenTracing 项目合并形成的开源 Cloud Native Computing Foundation (CNCF) 项目。它是一个供仪表化、生成、收集和导 …","relpermalink":"/blog/otlp-version-one-released/","summary":"OpenTelemetry Protocol (OTLP) 1.0.0 已发布，它是 OpenTelemetry 项目中的通用遥测数据传递协议。OpenTelemetry 是一个开源的可观测性框架，提供了一组 API、库、代理和收集器服务，用于捕获分布式跟踪和指标。OTLP 在客户端和服务器之间进行数据交换，定义了一个序列化模式，紧密遵循跟踪、指标和日志的数据模型。","title":"OpenTelemetry Protocol (OTLP) 1.0.0 发布"},{"content":"上周，Kubernetes 项目合并了一个新的 alpha 特性，使用户能够在规范中定义“sidecar containers”。这个新功能旨在帮助定义多容器 pod 中辅助容器的行为，这些容器可能有助于配置、网络、日志和度量收集等方面。\n什么是 sidecar container？ 理论上，Kubernetes 期望您在每个 pod 中运行一个容器。实际上，许多用例需要多容器 pod——例如，当您使用某些服务网格时，几乎所有的 pod 中都可能有 sidecar。\n有时，辅助容器仅用于初始化：例如为主容器配置和管理 secret。Kubernetes 已经为用户提供了定义 initContainer 的方式一段时间了。这个新功能最终为 initContainer 提供了更精细的粒度，以反映 sidecar 的特定要求，简化常见用法模式并为未来开辟了一些有趣的设计空间。\nsidecar container 特性如何工作？ 在这个新的功能门控中，sidecar containers 被定义为…\n在 pod 中比其他容器更早地启动，因为它们可能需要先初始化。这对于像服务网格这样的事情很重 …","relpermalink":"/blog/understanding-kubernetes-new-sidecar-container-feature/","summary":"Kubernetes 的新 sidecar container 特性允许用户在规范中定义辅助容器的行为，以帮助配置、网络、日志和度量收集等方面。这个新功能旨在为多容器 pod 中的 sidecar 容器提供更精细的粒度，使其能够比 initContainer 更好地反映 sidecar 的特定要求，简化常见用法模式并为未来开辟了一些有趣的设计空间。","title":"Kubernetes 将推出新 sidecar container 特性"},{"content":"前言 译者注：本文译自 Codefresh 公司发布的系列博客 Enterprise CI/CD Best Practices。\n如果你正在学习持续集成/交付/部署，你可能会发现主要有两类资源：\nCI/CD 是什么以及为什么需要它的概述。这些对于初学者很好，但不涵盖有关 Day2 操作或如何优化现有流程的任何内容。 仅涵盖 CI/CD 的特定方面（例如仅单元测试或仅部署）的详细教程，使用特定的编程语言和工具。 我们相信这两个极端之间存在差距。我们缺少一份恰当的指南，介于这两个类别之间，讨论最佳实践，但不是以抽象的方式。如果你一直想阅读有关 CI/CD 的指南，不仅解释“为什么”，还解释“如何”应用最佳实践，那么这份指南适合你。\n我们将描述所有有效的 CI/CD 工作流程的基本原理，但不仅以一般术语谈论，而且还将解释每个最佳实践背后的技术细节，更重要的是，如果你不采用它，它可能会对你产生什么影响。\n设置优先级\n一些公司试图在掌握基础知识之前跳上 DevOps 的列车。你很快会发现，CI/CD 流程中出现的一些问题通常是现有流程问题，只有当该公司试图遵循 CI/CD 流程的最佳实践时，才会 …","relpermalink":"/blog/enterprise-ci-cd-best-practices/","summary":"我们将描述所有有效的 CI/CD 工作流程的基本原理，但不仅以一般术语谈论，而且还将解释每个最佳实践背后的技术细节，更重要的是，如果你不采用它，它可能会对你产生什么影响。","title":"企业级 CI/CD 最佳实践"},{"content":"Istio 成为 CNCF 项目的毕业生。这一历史性的时刻代表着 Istio 在云原生领域的成长和成熟，标志着最广泛部署的服务网格迎来了一个令人兴奋的新篇章。Kubernetes 是 第一个获得毕业资格的项目，时间是 2018 年。今天，自它作为一个孵化项目进入 CNCF 不到一年的时间，Istio 就毕业了，成为 CNCF 历史上最快的一个。\nTetrate 是由 Istio 创始团队的成员创立的，旨在推广和扩大服务网格的应用，并自创立以来一直是 Istio 最重要的贡献者之一。我们为 Istio 及其社区的辛勤工作和奉献取得了这一里程碑式的认可而感到自豪和兴奋。\nIstio 毕业意味着什么？ CNCF 项目分为三个类别，作为项目成熟度的标志：\n沙盒。 CNCF“沙盒”是 CNCF 内新项目的入口。它为早期阶段的项目提供支持、指导和可见度，以便从 CNCF 社区中获得支持。沙盒旨在为这些项目提供一个安全和协作的环境，以便它们进行实验、创新和成熟。\n孵化。 孵化项目已经超过了开发的早期阶段，并展示了成为成熟云原生技术的潜力。Istio 凭借其强大的社区和早期采用者的不断生产使用而被接纳 …","relpermalink":"/blog/istio-service-mesh-graduates-cncf/","summary":"本文介绍了 Istio 作为 CNCF 项目的毕业生的成熟度、安全性、生产就绪、采用和生态系统、CNCF 支持和治理以及社区和企业支持。同时，介绍了 Tetrate 对 Istio 的影响，包括代码贡献、唯一的纯 OSS 企业产品、共同的专业知识、制定标准的安全领导力、社区参与、教育和培训、生态系统扩展等。Tetrate 和 Istio 的交织历史的简要时间线也被列出。最后，提供了使用 Istio 和 Tetrate Service Bridge 的方法和资源。","title":"Istio 成为最快的 CNCF 毕业项目"},{"content":"在 Kubernetes 中，同一命名空间中的任何 Pod 都可以使用其 IP 地址相互通信，无论它属于哪个部署或服务。虽然这种默认行为适用于小规模应用，但在规模扩大和复杂度增加的情况下，Pod 之间的无限通信可能会增加攻击面并导致安全漏洞。\n在集群中实施 Kubernetes 网络策略可以改善以下方面：\n安全性： 使用 Kubernetes 网络策略，你可以指定允许哪些 Pod 或服务相互通信，以及应该阻止哪些流量访问特定的资源。这样可以更容易地防止未经授权的访问敏感数据或服务。 合规性： 在医疗保健或金融服务等行业，合规性要求不可妥协。通过确保流量仅在特定的工作负载之间流动，以满足合规要求。 故障排除： 通过提供关于应该相互通信的 Pod 和服务的可见性，可以更轻松地解决网络问题，特别是在大型集群中。策略还可以帮助你确定网络问题的源，从而加快解决速度。 Kubernetes 网络策略组件 强大的网络策略包括：\n策略类型： Kubernetes 网络策略有两种类型：入口和出口。入口策略允许你控制流入 Pod 的流量，而出口策略允许你控制从 Pod 流出的流量。 …","relpermalink":"/blog/understanding-kubernetes-network-policies/","summary":"这篇文章介绍了 Kubernetes 网络策略的概念、作用和使用方法。Kubernetes 网络策略可以让你配置和执行一套规则，来控制集群内部的流量。它们可以提高安全性、符合合规性和简化故障排除。文章分析了网络策略的不同组成部分，包括选择器、入口规则和出口规则，并给出了不同的策略示例和最佳实践。文章的目标是让读者对使用 Kubernetes 网络策略来保护和管理流量有一个坚实的理解。","title":"Kubernetes 网络策略入门：概念、示例和最佳实践"},{"content":"译者注：本文译自 Sysdig 公司的网站，Sysdig 是一家提供容器安全、监控和故障排除解决方案的公司，其产品帮助用户在容器化环境中实现可观测性和安全性。这篇文章介绍了 CNAPP，CNAPP 是一个端到端的云安全解决方案，可提供实时威胁检测、简化符合性、改善 DevOps 协作、操作效率等多种好处。它通过整合安全控件、提供集中式管理和运行时洞察力等方式，增强组织的整体安全姿态。\n总览 CNAPP（容器化应用程序保护平台）是一种综合性的、全方位的安全策略，贯穿整个应用程序的生命周期（SDLC）。随着云计算的快速普及和现代应用程序的日益复杂，传统的安全措施往往无法有效地保护免受复杂的网络威胁。\nCNAPP 结合了“向左倾斜”和“向右防御”安全概念，提供了全面和强大的安全策略，确保了应用程序在整个生命周期中的保护。\n通过将安全向左移动，组织可以利用从应用程序开发过程的最开始阶段就开始的安全控制、漏洞扫描和合规性检查。\n“向右防御”概念侧重于在应用程序运行时阶段实时检测和响应安全事件。尽管在开发过程中尽最大努力保护应用程序，但漏洞可能仍然存在，或者新的威胁可能出现，因此 CNAPP 必须 …","relpermalink":"/blog/what-is-cnapp/","summary":"CNAPP 是一个端到端的云安全解决方案，可提供实时威胁检测、简化符合性、改善 DevOps 协作、操作效率等多种好处。它通过整合安全控件、提供集中式管理和运行时洞察力等方式，增强组织的整体安全姿态。","title":"什么是 CNAPP（容器化应用保护平台）?"},{"content":"前言 原生 Kubernetes 调度器仅基于资源的 Request 进行调度，在生产环境资源的真实使用率和申请率往往相差巨大，造成资源浪费的同时也会造成节点的负载不均衡。crane-sheduler 基于 prometheus 集群真实资源负载进行调度，将其应用于调度过程中的 Filter 和 Score 阶段，能够有效缓解集群资源负载不均的问题，真正实现企业的降本增效。\n背景 Kubernetes 集群是现代许多企业的首选方案之一，因为它可以帮助企业实现自动化部署、弹性伸缩和容错处理等功能，从而减少了人工操作和维护工作量，提高了服务的可靠性和稳定性，实现了降本增效。但是 Kubernetes 默认的调度器存在以下问题：\n节点的实际利用率和节点申请率往往相差巨大，造成资源的浪费； 节点间资源分布不均，会带来负载不均的问题。 crane-scheduler 由腾讯云团队开发，在一定程度上能够解决上述问题，直接基于资源的真实使用率进行调度，能够最大程度地利用资源，并排除了稳定性的后顾之忧，经过了长时间的实践和验证，可以很好地适应不同的场景和需求。开源后，crane-scheduler 受 …","relpermalink":"/blog/crane-scheduler/","summary":"crane-sheduler 基于 prometheus 集群真实资源负载进行调度，将其应用于调度过程中的 Filter 和 Score 阶段，能够有效缓解集群资源负载不均的问题，真正实现企业的降本增效。","title":"Crane 调度器介绍——一款在 Kubernetes 集群间迁移应用的调度插件"},{"content":"Argo workflow 是什么 老牌的 CICD 工具 Jenkins 应该是大部分都接触过的，而在云原生时代，诞生了两大 CI/CD 框架，也就是 Argo Workflow 和 Tekton，本文主要介绍一下 Argo Workflow。\nArgo Workflow 是一个云原生的工作流引擎，基于 kubernetes 来做编排任务，目前 Argo 项目是 CNCF 的毕业项目。\n只有当需要执行对应的 step 时才会创建出对应的 pod，因此和 Tekton 一样，对资源的申请和释放具有很好的利用性。\n基于 Argo Workflow 可以完成一些比较复杂的工作流，下面是一个来自某个 issue 的图：\nArgo Workflow 架构概览 架构图 在 Argo Workflow 中，每一个 step/dag task 就是一个 pod 中的容器，最基础的 pod 会有 1 个 init 容器和两个工作容器，其中 init 容器和主容器都是 argoproj/argoexec 容器，另一个则是 step 中需要使用的容器，也就是实际执行内容的容器，在 pod …","relpermalink":"/blog/cloudnative-ci-argo-workflow/","summary":"老牌的 CICD 工具 Jenkins 应该是大部分都接触过的，而在云原生时代，诞生了两大 CI/CD 框架，也就是 Argo Workflow 和 Tekton，本文主要介绍一下 Argo Workflow。","title":"Argo Workflow 介绍：一款强大的云原生持续集成工具"},{"content":" 摘要：本文译自 How OpenTelemetry Works with Kubernetes。本文介绍了如何将 OpenTelemetry 与 Kubernetes 配合使用。OpenTelemetry 可以作为 Prometheus 的替代品，也可以将数据导出到各种后端，包括 Prometheus。OpenTelemetry Operator 负责部署和管理 OpenTelemetry Collector，该组件是收集、处理和导出遥测数据的中央组件。OpenTelemetry 日志提供了一种标准化的方式来收集、处理和分析分布式系统中的日志。此外，本文还介绍了 OpenTelemetry 的下一步计划，包括 Web 服务器的自动化仪器化、OpenTelemetry Profile 和 Open Agent Management Protocol。\nOpenTelemetry 的主要目标是提供一种标准的方式，使开发人员和最终用户能够从他们的应用程序和系统中创建、收集和导出遥测数据，并促进不同可观察性工具和平台之间的互操作性。\nOTEL 支持多种编程语言， …","relpermalink":"/blog/how-opentelemetry-works-with-kubernetes/","summary":"本文介绍了如何将 OpenTelemetry 与 Kubernetes 配合使用。OpenTelemetry 可以作为 Prometheus 的替代品，也可以将数据导出到各种后端，包括 Prometheus。OpenTelemetry Operator 负责部署和管理 OpenTelemetry Collector，该组件是收集、处理和导出遥测数据的中央组件。OpenTelemetry 日志提供了一种标准化的方式来收集、处理和分析分布式系统中的日志。此外，本文还介绍了 OpenTelemetry 的下一步计划，包括 Web 服务器的自动化仪器化、OpenTelemetry Profile 和 Open Agent Management Protocol。","title":"如何利用 OpenTelemetry 监控和优化 Kubernetes 的性能"},{"content":"本文译自 A Comprehensive Guide to API Gateways, Kubernetes Gateways, and Service Meshes。\n摘要：本文介绍了 API 网关、Kubernetes 网关和服务网格的综合指南。API 网关和 Kubernetes 网关解决了边缘问题和 API 抽象化，而服务网格解决了服务之间的通信挑战。文章还介绍了如何在不同的网关中配置金丝雀部署，并讨论了 Kubernetes Gateway API 的发展和服务网格接口（SMI）规范。最后，文章提供了一些关于何时使用哪种网关的建议。\n简介 本文将介绍三种技术，它们分别是 API 网关、Kubernetes 网关和 Service Mesh，以及它们之间的区别，以及如何应用它们。\nAPI 网关 API 网关是一个连接客户端和 API 的中介，它接收所有客户端请求，将它们转发到所需的 API，并将响应返回给客户端。\n它基本上是一个具有许多功能的反向代理。\n除此之外，API 网关还可以具有诸如身份验证、安全性、细粒度流量控制和监控等功能，使 API 开发人员只需专注于业务需求。\n有 …","relpermalink":"/blog/gateway-and-mesh/","summary":"本文介绍了 API 网关、Kubernetes 网关和服务网格的综合指南。API 网关和 Kubernetes 网关解决了边缘问题和 API 抽象化，而服务网格解决了服务之间的通信挑战。文章还介绍了如何在不同的网关中配置金丝雀部署，并讨论了 Kubernetes Gateway API 的发展和服务网格接口（SMI）规范。最后，文章提供了一些关于何时使用哪种网关的建议。","title":"API 网关、Kubernetes 网关和 Service Mesh 综合指南"},{"content":"本文译自 Reframing Kubernetes Observability with a Graph。\n摘要：本文介绍了将 DevOps 和 Kubernetes 视为图形的方法，以提高效率和弹性。通过将 Kubernetes 部署中的不同组件建模为图中的节点，组织可以更好地了解不同组件的交互方式以及一个区域的更改如何影响整个系统。这可以帮助组织采取更为主动、战略性的 DevOps 方法，而不仅仅是在问题出现时做出反应。\nKubernetes 可以跨多个主机部署应用程序，同时让团队将它们作为单个逻辑单元进行管理。它抽象了底层基础架构，并提供了一个用于与集群交互的统一 API，以及用于简化工作流程的自动化。它是现代开发实践的完美系统。\n但在这些以云为先的生态系统中确保效率和弹性并不容易。微服务架构使得无法跟上正在不断发生的所有软件和基础架构变化。这个问题只会因分裂的监视和可观测工具以及团队和个人之间的隔离信息而变得更加严重。\n为了跟上，组织必须以一种新的方式考虑 DevOps 和 Kubernetes - 作为一个图形。\n将 DevOps 视为图形 DevOps 通常专注于自动化和集 …","relpermalink":"/blog/reframing-kubernetes-observability-with-a-graph/","summary":"本文介绍了将 DevOps 和 Kubernetes 视为图形的方法，以提高效率和弹性。通过将 Kubernetes 部署中的不同组件建模为图中的节点，组织可以更好地了解不同组件的交互方式以及一个区域的更改如何影响整个系统。这可以帮助组织采取更为主动、战略性的 DevOps 方法，而不仅仅是在问题出现时做出反应。","title":"以图形重构 Kubernetes 可观测性"},{"content":"本文介绍了 Kubernetes 网关 API，该 API 旨在提供一种在 Kubernetes 中管理网关和负载均衡器的标准方法。文章解释了 Kubernetes 网关 API 的核心组件和概念，并且详细介绍了如何使用网关 API 来配置和管理网关和负载均衡器。文章还介绍了一些常见的网关实现，例如 Istio 和 Contour，以及如何使用它们与 Kubernetes 网关 API 进行集成。最后，文章还讨论了 Kubernetes 网关 API 的未来发展方向。\n背景 Kubernetes Gateway API 是 Kubernetes 1.18 版本引入的一种新的 API 规范，是 Kubernetes 官方正在开发的新的 API，Ingress 是 Kubernetes 已有的 API。Gateway API 会成为 Ingress 的下一代替代方案。Gateway API 提供更丰富的功能，支持 TCP、UDP、TLS 等，不仅仅是 HTTP。Ingress 主要面向 HTTP 流量。Gateway API 具有更强的扩展性，通过 CRD …","relpermalink":"/blog/kubernetes-gateway-api-explained/","summary":"本文介绍了 Kubernetes 网关 API，该 API 旨在提供一种在 Kubernetes 中管理网关和负载均衡器的标准方法。文章解释了 Kubernetes 网关 API 的核心组件和概念，并且详细介绍了如何使用网关 API 来配置和管理网关和负载均衡器。文章还介绍了一些常见的网关实现，例如 Istio 和 Contour，以及如何使用它们与 Kubernetes 网关 API 进行集成。最后，文章还讨论了 Kubernetes 网关 API 的未来发展方向。","title":"Kubernetes Gateway API 深入解读和落地指南"},{"content":" 摘要：本文译自 OSM 官方博客。开放服务网格（OSM）宣布停止更新，将与 Istio 社区更加紧密地合作，以加速实现下一代服务网格技术的发展。服务网格社区的发展，如 Kubernetes Gateway API 和 GAMMA，进一步凸显了服务网格在当今云原生栈中的关键重要性和成熟度。OSM 团队将与 Istio 社区合作，包括利用 Kubernetes 的 ClusterTrustBundles 功能增强 Istio 的网格证书管理体验，提出“安全模式”功能方法，改进 Istio 的遥测体验，并与 Istio 新宣布的无 Sidecar 环境网格模式进行合作。\n开放服务网格（OSM）于 2020 年 8 月推出，并于此后不久加入了 CNCF。自那以后，OSM 一直在与社区紧密合作，提供一个使用可互操作的服务网格 API 集合的简化操作服务网格体验，这些 API 集合通过服务网格接口（SMI）实现。\n服务网格社区涌现了大量的兴奋、进步和共享的想法，这些想法与 OSM 的指导原则相一致。OSM 的宪章一直是提供一个聚焦于易于消费和操作的服务网格体验。同样， …","relpermalink":"/blog/osm-deprecated/","summary":"开放服务网格（OSM）宣布停止更新，将与 Istio 社区更加紧密地合作，以加速实现下一代服务网格技术的发展。服务网格社区的发展，如 Kubernetes Gateway API 和 GAMMA，进一步凸显了服务网格在当今云原生栈中的关键重要性和成熟度。OSM 团队将与 Istio 社区合作，包括利用 Kubernetes 的 ClusterTrustBundles 功能增强 Istio 的网格证书管理体验，提出“安全模式”功能方法，改进 Istio 的遥测体验，并与 Istio 新宣布的无 Sidecar 环境网格模式进行合作。","title":"OSM（Open Service Mesh）项目将停止更新，团队将协力 Istio 服务网格开发"},{"content":"最近，Docker 宣布与 WasmEdge 合作，在 Docker 生态系统中支持 WebAssembly。\n本文将介绍什么是 WebAssembly，以及为什么它与 Docker 生态系统相关，并提供一些实践示例。我们假设您熟悉 Docker 工具集。我们将使用我们的 WebAssembly PHP 的端口 来演示如何构建 PHP 解释器，将其打包为 OCI 镜像的一部分，并使用 Docker 运行它。\n请注意，本文的重点是获得实践经验，而不是讨论技术细节。您可以复制以下示例，也可以只读到最后，因为我们还将提供输出。\nWebAssembly - 什么？为什么？ 这是一个非常基本的介绍。如果您已经熟悉该技术，则可以跳到动手环节。\n什么是 WebAssembly？ WebAssembly（或 Wasm）是一个开放标准，定义了一种二进制指令格式，可以从不同的源语言创建可移植的二进制可执行文件。\n这些二进制文件可以在各种环境中运行。它起源于 web，并得到所有主要浏览器的支持。\nWasm 在浏览器中是如何工作的？ 浏览器引擎集成了一个 Wasm 虚拟机，通常称为 Wasm 运行时，它可以运 …","relpermalink":"/blog/docker-without-containers/","summary":"本文介绍了如何在 Docker 中使用 WebAssembly（Wasm）来运行 PHP 应用程序。Wasm 容器比传统容器更小，提供更高级别的沙盒性能，并且具有真正的可移植性。本文还提供了一些示例，演示了如何使用 Wasm 在不同的环境中运行 WordPress。","title":"WebAssembly：无需容器就能运行 Docker！"},{"content":"「可观测性峰会 2023」是云原生社区组织的技术会议，旨在分享并探讨云原生应用程序和基础架构中实现可观测性的最新技术和工具以及最佳实践。\n时间：2023 年 4 月 22 日（周六）\n地点：北京奥佳美术馆酒店\n活动详情：https://www.huodongxing.com/event/6695157778700\n本次大会的主持人来自云原生社区管委会，上半场主持人为罗广明。\n下半场主持人张丽颖。\n开场致辞 嘉宾：\n宋净超，云原生社区创始人\n陈屹力，中国信通院云大所副总工程师\n视频链接：https://www.bilibili.com/video/BV1zV4y1o79E/\n可观测性 OpsCenter 在移动云平台落地实践 沈巍，中国移动云能力中心架构师\n讲师介绍\n沈巍，中国移动云能力中心，软件开发工程师，曾就职于全球最大的移动通信设备商爱立信；在爱立信工作期间参与设计了爱立信全球第一套超大规模 NFV 电信云落地，全球第一套超大规模 5GC 电信云落地；荣获爱立信年度最具有价值员工称号。擅长 openstack，kubernetes 等云平台的解决方案设计与实现；云平台可观测性监控的 …","relpermalink":"/blog/observability-summit-2023-recap/","summary":"「可观测性峰会 2023」是云原生社区组织的技术会议，旨在分享并探讨云原生应用程序和基础架构中实现可观测性的最新技术和工具以及最佳实践。","title":"可观测性峰会 2023 回顾及 PPT 下载"},{"content":"活动日程请见活动行。\n","relpermalink":"/event/observability-summit-2023/","summary":"第一届可观测性峰会。","title":"可观测性峰会 2023"},{"content":"测试小姐姐正在对云原生的电商应用进行压测，但是如何对压测结果进行持续的观测呢？这一直是比较头痛的事情，本文将介绍如何利用 DeepFlow 的全景拓扑帮助小姐姐快速找到瓶颈点。DeepFlow 全景拓扑无需业务修改代码、配置或者重启服务，利用 BPF/eBPF 技术通过对业务零侵扰的方式构建而来，这是一种很便捷且低成本的方式来观测全链路压测的结果。\n背景介绍 DeepFlow 在线的 Sandbox 环境中部署了一个云原生的电商应用，此电商应用来源于 GitHub，此应用覆盖 Go/Java/.NET/PHP/Python 等多种语言，且涵盖 Redis/Kafka/PostgreSQL 等中间件，所有的这些服务都部署在 K8s 环境中。在做全链路压测时，当前通常的方式需要对应用进行代码级别的改造，这对于仅负责测试的小姐姐来说又很难推动，接下来将详细介绍 DeepFlow 的全景拓扑如何轻松解决小姐姐的苦恼。\n以下是电商应用微服务的调用关系图，提供了外网和内网访问的两种方式。\n调用关系 DeepFlow 的 Sandbox 考虑到安全性的问题，仅支持了内网的访问方式， …","relpermalink":"/blog/service-map-observation-performance-test/","summary":"测试小姐姐正在对云原生的电商应用进行压测，但是如何对压测结果进行持续的观测呢？这一直是比较头痛的事情，本文将介绍如何利用 DeepFlow 的全景拓扑帮助小姐姐快速找到瓶颈点。DeepFlow 全景拓扑无需业务修改代码、配置或者重启服务，利用 BPF/eBPF 技术通过对业务零侵扰的方式构建而来，这是一种很便捷且低成本的方式来观测全链路压测的结果。","title":"使用全景拓扑持续跟踪云原生应用的压测性能瓶颈"},{"content":" 译者注：本文译自 Docker + WebAssembly: a quick intro | by Fabrizio Guglielmino | Medium，本文介绍了使用 Docker 和 WebAssembly 创建容器的过程。通过比较标准 Docker 容器和 WebAssembly 容器，作者指出 WebAssembly 容器具有性能优势、架构中立等优点，但也存在不成熟的问题。WebAssembly 容器有望彻底改变容器化应用程序的方式。\n今天，我想展示一种实用且有趣的使用 Docker 的方式：在容器中使用 WebAssembly。\n我说“实用的方式”，这就是为什么我假设您有一些经验：\nDocker（当然） Rust（实际上，只是为了理解“Hello World”） WebAssembly；只需要对其有一个基本的了解（注意：我将在讨论中交替使用 WASM 和 WebAssembly 这两个术语） 关于我即将展示的内容，简单说一下：一个 Docker 容器是一个包含运行环境的映像的运行实例。运行环境通常是一个操作系统，大多数情况下是 Linux。操作系统是运行应用程序的必要 …","relpermalink":"/blog/docker-wasm-quick-intro/","summary":"本文介绍了使用 Docker 和 WebAssembly 创建容器的过程。通过比较标准 Docker 容器和 WebAssembly 容器，作者指出 WebAssembly 容器具有性能优势、架构中立等优点，但也存在不成熟的问题。WebAssembly 容器有望彻底改变容器化应用程序的方式。","title":"用 Docker 和 WebAssembly 打造容器的新时代！"},{"content":" 译者注：本文译自 CNCF 平台白皮书，介绍了如何构建云原生计算平台以及平台可能提供的能力。这些能力包括 Web 门户、API、黄金路径模板、自动化、开发环境、可观测性、基础设施服务、数据服务、消息和事件服务、身份和密码管理服务、安全服务和工件存储。此外，该文档还介绍了与平台相关的术语，如平台、平台能力提供者、平台工程师、平台产品经理、平台团队和平台用户。\n介绍 受 DevOps 所承诺的跨职能合作的启发，平台工程正在企业中作为一种明确的合作形式出现。平台策划和呈现基础功能、框架和体验，以促进和加速应用程序开发人员、数据科学家和信息工作者等内部客户的工作。特别是在云计算领域，平台已经帮助企业实现了云计算长期承诺的价值，例如快速的产品发布、跨基础架构的可移植性、更安全和更弹性的产品以及更高的开发者生产力。\n本文旨在支持企业领导、企业架构师和平台团队领导者提倡、调查和计划云计算内部平台。我们相信平台对企业的实际价值流有重大影响，但只是间接的，因此领导共识和支持对平台团队的长期可持续性和成功至关重要。在本文中，我们将通过讨论平台的价值、如何衡量该价值以及如何实施最大化该价值的平台团队来实现 …","relpermalink":"/blog/cncf-platforms-white-paper/","summary":"本文译自 CNCF 平台白皮书，介绍了如何构建云原生计算平台以及平台可能提供的能力。这些能力包括 Web 门户、API、黄金路径模板、自动化、开发环境、可观测性、基础设施服务、数据服务、消息和事件服务、身份和密码管理服务、安全服务和工件存储。此外，该文档还介绍了与平台相关的术语，如平台、平台能力提供者、平台工程师、平台产品经理、平台团队和平台用户。","title":" CNCF 平台白皮书"},{"content":"本文译自：Reducing the Cognitive Load Associated with Observability - The New Stack\n译者注：本文讨论了降低可观测性对认知负荷的影响。在处理大量数据时，我们需要过滤和转换数据点以生成适当的信号，并依赖警报系统来进行人类干预。游戏日是测试响应能力的好机会。在团队中培养协作文化对每个人的福祉至关重要。通过实施这些策略，软件工程团队可以确保他们具备使用和有效理解可观测性信号所需的知识和技能。\n你能想象在没有现代可观测工具的情况下开发或操作分布式系统吗？我们知道可观测性是一项关键的实践，可以让我们提高系统的可靠性，减少服务停机时间，可视化使用模式，提供性能见解并促进问题解决。\n随着过去十年微服务架构和全球“shift left”的意图的广泛采用，工程师的角色——从开发人员和运维人员到 DevOps、站点可靠性工程和平台工程——发生了巨大变化。许多人被赋予更多的责任，并增加了工作量。\n什么是 Shift left？\n“Shift left” 是一种软件开发术语，它指的是在开发生命周期的早期阶段引入测试和安全性措施，以便更早地 …","relpermalink":"/blog/reducing-the-cognitive-load-associated-with-observability/","summary":"本文讨论了降低可观测性对认知负荷的影响。在处理大量数据时，我们需要过滤和转换数据点以生成适当的信号，并依赖警报系统来进行人类干预。游戏日是测试响应能力的好机会。在团队中培养协作文化对每个人的福祉至关重要。通过实施这些策略，软件工程团队可以确保他们具备使用和有效理解可观测性信号所需的知识和技能。","title":"如何降低可观测性带来的认知负荷"},{"content":"本文译自：Startup Fermyon Releases Spin 1.0 for WebAssembly Serverless Applications。\nFermyon 最近宣布推出 Spin 1.0，这是一个用于使用 WebAssembly (Wasm) 开发无服务器应用的开源开发者工具和框架。\nSpin 1.0 是其去年推出 介绍 后的首个稳定版本。在 1.0 版本中，公司增加了对新编程语言（如 JavaScript、TypeScript、Python 或 C#，除了 Rust 和 Go 之外）、连接数据库（关系型 或 Redis）、使用流行的注册表服务分发应用程序（GitHub Container Registry、Docker Hub 或 AWS ECR）、内置的 键值存储 以保持状态、在 Kubernetes 上运行应用程序以及与 HashiCorp Vault 集成以管理运行时配置等方面的支持。\n通过 Spin，该公司为创建运行 Wasm 的应用程序提供了轻松的开发体验，包括部署和安全运行它们的框架。\nFermyon 的首席技术官 Radu Matei 在一篇 博客文 …","relpermalink":"/blog/spin-wasm-ga/","summary":"Fermyon 最近宣布推出 Spin 1.0，这是一个用于使用 WebAssembly (Wasm) 开发无服务器应用的开源开发者工具和框架。","title":"初创公司 Fermyon 发布 Spin 1.0 用于 WebAssembly 无服务器应用"},{"content":"Tetrate Service Express (TSE) 是一款基于开源软件的服务连接、安全和弹性自动化解决方案，专为 Amazon EKS 设计。\n本文译自：Tetrate Service Express 介绍\n快速实现 Amazon EKS 上安全和弹性的服务网格 今天我们很高兴地宣布 Tetrate Service Express (TSE)，这是一款针对 Amazon EKS 的服务连接、安全和弹性自动化解决方案。我们基于 Istio 和 Envoy 等开源服务网格组件构建了 TSE，并针对 AWS 对 TSE 进行了简化安装、配置和操作的优化。如果您的团队正在 AWS 上进行服务网格实验，并且需要快速证明投资回报率，而无需掌握复杂的 Istio 和 AWS 基元，那么 TSE 就是适合您的选择！如果您的团队已经在单个集群上拥有了服务网格，但希望将网格扩展到多个集群甚至区域，那么 TSE 也可以帮助您。事实上，TSE 是唯一一款基于开源软件并针对 AWS 进行优化的产品，预先集成了最受欢迎的 AWS 服务，可在几分钟内让您上手。\n如果您想快速了解 Tetrate …","relpermalink":"/blog/introducing-tetrate-service-express/","summary":"Tetrate Service Express (TSE) 是一款基于开源软件的服务连接、安全和弹性自动化解决方案，专为 Amazon EKS 设计。","title":"Tetrate 推出针对 Amazon EKS 设计的服务网格解决方案 TSE"},{"content":"您是否应该让多个团队使用同一个 Kubernetes 集群？\n您是否可以安全地运行来自不信任用户的不信任工作负载？\nKubernetes 是否具备多租户功能？\n本文将探讨在运行具有多个租户的集群时面临的挑战。\n多租户可分为：\n软多租户，适用于信任您的租户 - 比如与同一家公司的团队共享集群时。 硬多租户，适用于您不信任的租户。 您还可以混合使用！\n在租户之间共享集群的基本构建块是命名空间。\n命名空间在逻辑上对资源进行分组，它们不提供任何安全机制，也不能保证所有资源都部署在同一节点上。\n命名空间中的 Pod 仍然可以与集群中的所有其他 Pod 通信，向 API 发出请求并使用它们想要的任何资源。\n默认情况下，任何用户都可以访问任何命名空间。\n那应该怎么阻止它？\n通过 RBAC，您可以限制用户和应用程序对命名空间内和命名空间中的内容所能做的事情。\n常见的操作是授予有限用户权限。\n使用 Quotas 和 LimitRanges，您可以限制命名空间中部署的资源以及可以使用的内存、CPU 等。\n如果您想限制租户对其命名空间所能做的事情，这是一个绝妙的想法。\n默认情况下，所有 Pod …","relpermalink":"/blog/multi-tenancy-in-kubernetes/","summary":"本文将探讨在运行具有多个租户的集群时面临的挑战。","title":"如何在 Kubernetes 中实现多租户隔离：命名空间、RBAC 和网络策略的应用"},{"content":" 译者注\n这篇文章探讨了在人工智能时代，大数据公司如何适应和创新。作者采访了 Alation 的联合创始人 Aaron Kalb，了解了他们的“数据目录”平台，以及他对 ChatGPT 等生成型 AI 软件的看法。Kalb 认为，生成型 AI 是一种催化剂，推动了一波新的数据智能公司的出现。他还分析了生成型 AI 的优势和挑战，以及如何利用它来提高数据质量和可信度。 就像云计算引入了一系列“大数据”解决方案一样，生成式人工智能是新一波数据智能公司的催化剂。\n还记得“大数据”这个流行语吗？它在云计算时代孕育了许多成功的公司，如 Snowflake、Databricks、DataStax、Splunk 和 Cloudera。但现在我们处于人工智能时代，据说机器学习软件现在已经达到或接近“智能”了（即使它容易 产生幻觉 ——但是，我们所有人不都是吗？）。\n因此，鉴于当前的人工智能热潮，我们是否还需要“大数据”公司来对数据进行分类和组织呢？现在 AI 不是可以为我们做到这一点吗？\n为了了解数据公司如何适应人工智能时代，我采访了 Aaron Kalb，Alation 的联合创始人之 …","relpermalink":"/blog/the-next-wave-of-big-data-companies-in-the-age-of-chatgpt/","summary":"这篇文章探讨了在人工智能时代，大数据公司如何适应和创新。作者采访了 Alation 的联合创始人 Aaron Kalb，了解了他们的“数据目录”平台，以及他对 ChatGPT 等生成型 AI 软件的看法。Kalb 认为，生成型 AI 是一种催化剂，推动了一波新的数据智能公司的出现。他还分析了生成型 AI 的优势和挑战，以及如何利用它来提高数据质量和可信度。","title":"从 Siri 到 ChatGPT：大数据公司如何迎接 AI 新浪潮"},{"content":" 如果你正在阅读这篇博客文章，我假设你已经熟悉 Kubernetes 并且知道它是一个容器编排平台。在创建新的应用程序版本时，你的容器构建过程已经很好了。Kubernetes 提供了广泛的功能，使用户能够执行复杂的部署策略。挑战在于根据你的环境，有正确和错误的使用方式。\n你组织中的平台工程师很可能非常熟悉 Kubernetes，了解将应用程序部署到集群中的正确和错误方式。挑战在于向平台的所有用户传递这些信息。\n大多数运维人员的理解很可能来自于正式培训或花费很多时间构建平台并从错误中学习。要求所有打算与平台交互的应用程序开发人员具有相同的经验是不现实的。这对组织来说在时间、精力和对产品和客户的潜在影响方面都是昂贵的，因为这些经验是从错误中学到的。\n在每个组织内，用户使用内部开发平台的策略和标准是已知的或需要遵循的。挑战在于许多组织使用文档和广泛的沟通来确保用户遵循这些标准。这在人们偏离预期标准并学习正确方法之间提供了长时间的反馈循环。\nKyverno 这就是 Kyverno 的用武之地，它是一个基于 Kubernetes 的策略引擎，提供了一种将平台管理员学到的经验编码化的方 …","relpermalink":"/blog/argo-cd-kyverno-best-practice-policies/","summary":"本文介绍了如何使用 Kyverno 和 Argo CD 来强制执行 Kubernetes 的最佳实践。Kyverno 是一个 Kubernetes 原生的策略引擎，可以用来定义和执行安全和合规的规则。Argo CD 是一个 GitOps 的持续交付解决方案，可以用来管理 Kubernetes 集群的状态。文章通过一个具体的示例，展示了如何使用 Argo CD 来部署 Kyverno 和策略，以及如何处理策略违规的情况。","title":"使用 Kyverno 和 Argo CD 实施 Kubernetes 最佳实践"},{"content":" 译者注：本文介绍了 Istio 的新的目的地导向的 waypoint 代理，它可以简化和扩展 Istio 的功能。文章介绍了 waypoint 代理的架构，部署方式，以及如何将源代理的配置转移到目的地代理，从而提高可扩展性，可调试性，一致性和安全性。文章还展示了如何使用 Istio 的策略和遥测来管理和监控 waypoint 代理。文章的来源是 Istio 官方博客。\nAmbient 将 Istio 的功能分为两个不同的层，一个安全覆盖层和一个七层流量处理层。Waypoint 代理是一个可选组件，它基于 Envoy 并为其管理的工作负载进行七层流量处理。自 2022 年首次启动 Ambient 以来，我们进行了重大更改以简化路点配置、可调试性和可扩展性。\nWaypoint 代理的架构 与 sidecar 类似，waypoint 代理也是基于 Envoy 的，由 Istio 动态配置以服务于您的应用程序。Waypoint 代理的独特之处在于它运行每个命名空间（默认）或每个服务账户。通过在应用程序 pod 之外运行，waypoint 代理可以独立于应用程序安装、升级和扩展，并降低运营成 …","relpermalink":"/blog/waypoint-proxy-made-simple/","summary":"本文介绍了 Istio 的新的目的地导向的 waypoint 代理，它可以简化和扩展 Istio 的功能。文章介绍了 waypoint 代理的架构，部署方式，以及如何将源代理的配置转移到目的地代理，从而提高可扩展性，可调试性，一致性和安全性。文章还展示了如何使用 Istio 的策略和遥测来管理和监控 waypoint 代理。文章的来源是 Istio 官方博客。","title":"Istio Ambient 模式使用 Waypoint 代理简化 Istio 部署"},{"content":" 译者注：本文介绍了如何使用 OCI 容器来运行 WebAssembly 工作负载。WebAssembly（也称为 Wasm）是一种可移植的二进制指令格式，具有可嵌入和隔离的执行环境，适用于客户端和服务器应用。WebAssembly 可以看作是一种小巧、快速、高效、安全的基于栈的虚拟机，设计用于执行不关心 CPU 或操作系统的可移植字节码。WebAssembly 最初是为 web 浏览器设计的，用来作为函数的轻量级、快速、安全、多语言的容器，但它不再局限于 web。在 web 上，WebAssembly 使用浏览器提供的现有 API。WebAssembly System Interface（WASI）是为了填补 WebAssembly 和浏览器外系统之间的空白而创建的。这使得非浏览器系统可以利用 WebAssembly 的可移植性，使 WASI 成为分发和隔离工作负载时的一个很好的选择。文章中介绍了如何配置容器运行时来从轻量级容器镜像中运行 Wasm 工作负载，并给出了一些使用示例。\nWebAssembly（也称为 Wasm）以其可嵌入和隔离的执行环境而成为一种流行的便携式二进制指令格 …","relpermalink":"/blog/wasm-containers/","summary":"本文介绍了如何使用 OCI 容器来运行 WebAssembly 工作负载。WebAssembly（也称为 Wasm）是一种可移植的二进制指令格式，具有可嵌入和隔离的执行环境，适用于客户端和服务器应用。WebAssembly 可以看作是一种小巧、快速、高效、安全的基于栈的虚拟机，设计用于执行不关心 CPU 或操作系统的可移植字节码。WebAssembly 最初是为 web 浏览器设计的，用来作为函数的轻量级、快速、安全、多语言的容器，但它不再局限于 web。在 web 上，WebAssembly 使用浏览器提供的现有 API。WebAssembly System Interface（WASI）是为了填补 WebAssembly 和浏览器外系统之间的空白而创建的。这使得非浏览器系统可以利用 WebAssembly 的可移植性，使 WASI 成为分发和隔离工作负载时的一个很好的选择。文章中介绍了如何配置容器运行时来从轻量级容器镜像中运行 Wasm 工作负载，并给出了一些使用示例。","title":"使用 OCI 容器运行 WebAssembly 工作负载"},{"content":"客户向我们询问服务网格实践中关于开放策略代理 (OPA) 和服务网格如何结合使用的问题。我们探讨了关于服务网格和 OPA 策略的最佳实践，以及它们如何相互补充的想法。为了构建讨论框架，我们使用了 NIST 的零信任架构标准。在即将发布的 NIST 标准文档特别出版物 800-207A 中，基于身份的分段是一个主要概念。最低标准包括五项策略检查，应应用于进入的每个请求系统和每个后续跃点。您可以观看我们在今年的 CloudNativeSecurityCon 上与来自 NIST 的 Ramaswami Chandramouli 进行的深入讨论的演示。\n使用服务网格实现基于身份的分割的五个策略检查：\n传输中加密 服务身份和认证 服务到服务授权 最终用户身份和身份验证 最终用户对资源的授权 简而言之，服务网格是一个专用的基础设施层，专门用于为前四项检查实施策略，并在第五项中发挥一定作用。OPA 的亮点在于第五点：最终用户对资源的授权。\nIstio 的 sidecar 代理充当微服务应用程序的安全内核。Envoy 数据平面是一个通用的策略执行点 (PEP)，可以拦截所有流量并可以在应用层应用策略。 …","relpermalink":"/blog/understanding-istio-and-open-policy-agent-opa/","summary":"本文介绍了如何将服务网格和开放策略代理（OPA）结合使用，以实现基于身份的分割的五个策略检查。服务网格为前四项检查提供了执行点，而 OPA 则在第五项中发挥作用。本文还探讨了如何将特定于业务的策略应用于请求，以及如何使用 OIDC 或专用授权基础设施来实现最终用户对资源的授权。","title":"Istio 中的外部授权过滤器：使用 OPA 实现灵活的授权策略"},{"content":" 译者注：本文译自 Fusion Auth Developer。JSON Web Token（通常缩写为 JWT）是一种通常与 OAuth2 等标准协议一起使用的令牌。本文解释了 JWT 的组成部分和工作原理。\n在我们继续之前，重要的是要注意 JWT 通常被错误地称为 JWT Tokens。在末尾添加 Token 将会使其变成 JSON Web Token Token。因此，在本文中，我们省略末尾的 Token 并简单地称之为 JWT，因为这是更正确的名称。同样地，由于 JWT 通常用作身份验证和授权过程的一部分，一些人将其称为 Authentication Tokens 或 JWT Authentication Tokens。从技术上讲，JWT 只是一个包含 Base64 编码的 JSON 的令牌。它可以用于许多不同的用例，包括身份验证和授权。因此，在本文中，我们不使用这个术语，而是讨论如何在身份验证过程中使用 JWT。\n让我们开始吧！这是一个新生成的 JWT。为清楚起见添加了换行符，但它们通常不存在。 …","relpermalink":"/blog/jwt-components-explained/","summary":"JSON Web Token（通常缩写为 JWT）是一种通常与 OAuth2 等标准协议一起使用的令牌。本文解释了 JWT 的组成部分和工作原理。","title":"JWT 组件详解"},{"content":" 译者注：本文译自 Tetrate 博客。这篇文章介绍了 wazero，一个由 Tetrate 开发的用 Go 语言编写的 WebAssembly 运行时。wazero 可以让开发者用不同的编程语言编写代码，并在安全的沙箱环境中运行。wazero 有以下几个特点：\n纯 Go，无依赖，支持跨平台和跨架构 遵循 WebAssembly 核心规范 1.0 和 2.0 支持 Go 的特性，如并发安全和上下文传递 提供了丰富的编程接口和命令行工具 性能优异，超过了其他同类运行时 WebAssembly，也称为 Wasm，是一种编译用一种编程语言（例如 C 或 Rust）编写的代码并在不同的运行时（例如 Web 浏览器或微服务）上运行它的方法。这使得它成为编写插件、扩展以及在安全沙箱环境中运行任意用户定义代码的绝佳选择。\nWebAssembly 经常被误认为是一种仅限浏览器的技术，而实际上 Wasm 是一种跨平台的二进制文件，可以由任何 WebAssembly 运行时执行。从历史上看，Go 程序员没有太多好的选择，但这种情况已经改变。\n本文介绍了 wazero，它在用 Go 编程语言编写的基础设施 …","relpermalink":"/blog/introducing-wazero-from-tetrate/","summary":"这篇文章介绍了 wazero，一个由 Tetrate 开发的用 Go 语言编写的 WebAssembly 运行时。wazero 可以让开发者用不同的编程语言编写代码，并在安全的沙箱环境中运行。","title":"Tetrate 开源项目 Wazero 简介"},{"content":"本文作者 Bilgin Ibryam 是 Diagrid 的技术产品经理，致力于开发人员生产力工具。在此之前，他曾在 Red Hat 担任顾问和架构师，同时也是 Apache 软件基金会的提交者和成员。Bilgin 还与人合著了两本关于 Kubernetes 模式和 Camel 设计模式的书。在业余时间，Bilgin 喜欢通过博客和其他方式写作和分享他的知识。\n译者注：本文的原标题是《什么是云原生绑定应用》。本文介绍了云绑定应用程序的概念，并探讨了在使用云绑定应用程序时需要考虑的几个关键因素。首先，作者解释了云绑定应用程序是指在构建应用程序时使用云提供的服务和资源。作者强调了使用云绑定应用程序可以带来很多好处，例如降低成本和提高可靠性。然而，作者也指出了在使用云绑定应用程序时需要考虑的几个关键因素，包括云供应商锁定、数据隐私和网络连接可靠性等。最后，作者提供了一些建议，帮助企业在使用云绑定应用程序时避免潜在的风险。例如，选择具有高可用性的云服务提供商，并在使用云绑定应用程序时加强数据安全措施。\n关键要点 云提供商将重点从基础设施服务转移到开发人员直接使用的应用程序优先服务，从而产生了新 …","relpermalink":"/blog/cloud-bound-applications/","summary":"本文作者 Bilgin Ibryam 是 Diagrid 的技术产品经理，致力于开发人员生产力工具。在此之前，他曾在 Red Hat 担任顾问和架构师，同时也是 Apache 软件基金会的提交者和成员。Bilgin 还与人合著了两本关于 Kubernetes 模式和 Camel 设计模式的书。在业余时间，Bilgin 喜欢通过博客和其他方式写作和分享他的知识。\n","title":"云原生绑定应用：一种让开发者专注于业务逻辑的新架构"},{"content":"前言 近期由于产品需求需要打通多个 K8s 集群的容器网络，要求在一个集群的容器内，通过 Pod IP 直接访问另外一个集群的容器，因此笔者对相关网络技术进行了一番学习。本文将解释整体的组网思路，简单分析数据包的流转过程，最后给出详细的实验步骤。\n整体思路 Kubernetes 中常见的网络插件如 cni、fannel 等的实现中每个宿主机管理一个特定的容器网段，如主机 A 管理容器 223.17.8.0/24 网段，主机 B 管理 223.17.9.0/24 网段，将每个宿主机作为其上运行的容器的网关，并通过 vxlan，IPIP 等隧道技术，将包直接发往宿主机，再通过对应主机的路由到达容器中。因此我们也可以使用这种思路，将多个 K8s 集群的网络打通。\n整体架构图 上图以安装 calico 网络插件的集群为例子，展示了如何利用 vxlan 打通多集群网络，我们需要做的是：为所有节点创建 vxlan 虚拟网卡，将其它集群每个节点管理 Pod 网段的路由信息添加到当前集群节点中，并且指定下一跳地址为其它集群节点的 vxlan 虚拟网卡的 ip 地址。为每个节点的 vxlan …","relpermalink":"/blog/vxlan-calico-l2-network/","summary":"本文介绍了利用 vxlan 打通多个 K8s 集群网络的思路，并对包对流转做了简单分析。","title":"利用 VXLAN 打通多集群网络"},{"content":"前言 本文首先对 VictoriaMetrics 的功能和架构进行介绍。接着，使用一个场景例子演示单集群 VictoriaMetrics 的安装，并验证其对 Prometheus 的兼容性和可替换性。\nVictoriaMetrics 简介 我们知道，若要保证一个系统的稳定运行，那么对于这个系统的监控是不可或缺的环节。当今在云原生领域中，Prometheus 作为已经毕业的 CNCF 项目，已经成为了非常主流的监控和报警工具。但它也存在一些缺点，例如：默认情况下，其数据存储于本地文件的 TSDB 中，不利于容灾和做数据管理，若用于生产一般需要搭配第三方的如 InfulxDB 进行使用。大数据量的场景下，指标的收集和管理性能存在一定的瓶颈。\n而我们今天介绍的 VictoriaMetrics 可以认为是 Prometheus 在上述问题上的一个增强版。它不仅能作为时序数据库结合 Prometheus 使用进行指标的长期远程存储，也能单独作为一个监控解决方案对 Prometheus 进行平替。\n对比其他一些主流的监控方案、时序数据库，VictoriaMetrics 具有如下优势：\n指标数据的收 …","relpermalink":"/blog/victoriametrics/","summary":"本文首先对 VictoriaMetrics 的功能和架构进行介绍。接着，使用一个场景例子演示单集群 VictoriaMetrics 的安装，并验证其对 Prometheus 的兼容性和可替换性。","title":"优化云原生监控体验：VictoriaMetrics 入门指南"},{"content":"应用异常时，基本可以分为服务访问不通和服务响应慢两个大类。其中服务响应慢的问题定位非常棘手，很多无头案。应用团队有日志和追踪，对于自认为的不可能不合理的事情都会甩给基础设施团队，又由于基础设施团队现有的监控数据缺乏应用的观测视角，通常成为一切「不是我的问题」超自然现象的终极背锅侠，其中以网络团队尤为严重。\n响应时延 服务为什么响应慢？？？首先，我们需要一种方式来度量何为响应慢，参考 Google 在 SRE Handbook 中提到过4 个黄金信号及 Weave Cloud 提出来的 RED 方法，都存在度量的指标（Latency/Duration），后文统称为响应时延。\nLatency 表达的是服务处理某个请求所需要的时间，站在的是服务端视角 Duration 表达的是每个请求所花费的时间，站在的是客户端视角 总结下来，不论站在什么视角，响应时延表达的都是处理一个请求所花费的时间，可以用来表征服务响应慢的度量指标，但若要定位为什么响应慢还需要进一步剖解响应时延：\n系统时延：系统转发请求/响应的时延消耗 网络时延：包含查询 DNS 时延及网络处理的时延 应用时延：从不同视角来看，包含客 …","relpermalink":"/blog/analysis-of-delay-with-deepflow/","summary":"应用异常时，基本可以分为服务访问不通和服务响应慢两个大类。其中服务响应慢的问题定位非常棘手，很多无头案。应用团队有日志和追踪，对于自认为的不可能不合理的事情都会甩给基础设施团队，又由于基础设施团队现有的监控数据缺乏应用的观测视角，通常成为一切「不是我的问题」超自然现象的终极背锅侠，其中以网络团队尤为严重。","title":"应用响应时延背后深藏的网络时延"},{"content":" 译者注：这篇文章介绍了 Istio 的 Rust-Based Ztunnel，它是一种基于 Rust 语言的轻量级代理，用于 Istio 的 ambient mesh。在文章中，作者解释了为什么需要一种新的代理，以及 Rust 语言是如何成为最佳选择的。文章还讨论了如何使用 workload xDS 配置来管理工作负载，以及如何查看 ztunnel 日志和 L4 指标。作者表示，Rust-Based Ztunnel 显著简化了 Istio 的 ambient mesh，并提高了性能。此外，Istio ambient mesh 已经合并到了上游主干，可以通过遵循入门指南来尝试 Rust-Based Ztunnel。\nZtunnel（零信任隧道）组件是为 Istio Ambient Mesh 专门构建的每节点代理。它负责安全地连接和验证 Ambient Mesh 中的工作负载。Ztunnel 旨在专注于 Ambient Mesh 中工作负载的一小组功能，例如 mTLS、身份验证、L4 授权和遥测，而无需终止工作负载 HTTP 流量或解析工作负载 HTTP 标头。Ztunnel 确保流量高 …","relpermalink":"/blog/rust-based-ztunnel/","summary":"这篇文章介绍了 Istio 的 Rust-Based Ztunnel，它是一种基于 Rust 语言的轻量级代理，用于 Istio 的 ambient mesh。在文章中，作者解释了为什么需要一种新的代理，以及 Rust 语言是如何成为最佳选择的。文章还讨论了如何使用 workload xDS 配置来管理工作负载，以及如何查看 ztunnel 日志和 L4 指标。作者表示，Rust-Based Ztunnel 显著简化了 Istio 的 ambient mesh，并提高了性能。此外，Istio ambient mesh 已经合并到了上游主干，可以通过遵循入门指南来尝试 Rust-Based Ztunnel。","title":"Istio Ambient Mesh 中基于 Rust 的 Ztunnel 组件介绍"},{"content":" 译者注：这篇文章从多个角度探讨了 WebAssembly（Wasm）的现状和未来。首先，文章引用了 Cloud Native Computing Foundation（CNCF）的报告，指出 WebAssembly 在网页、无服务器、游戏和容器化应用中的应用越来越广泛，并预测 WebAssembly 将显著影响这些应用。其次，文章讨论了 WebAssembly 在容器、边缘计算、编程语言和无服务器应用等方面的应用。虽然 WebAssembly 已经成熟地应用于浏览器，但是在后端应用方面，如边缘设备的应用和部署，仍需要更多的工作。WASI 已经成为将 WebAssembly 扩展到浏览器之外的最佳选择，可以帮助解决在任何配置正确的 CPU 上运行 WebAssembly 运行时的复杂性。WebAssembly 和容器的应用预计将共同增长，尽管 WebAssembly 在某些用例中可以取代容器，但总体来说，两者是互补的产品。WebAssembly 的未来看起来非常光明，但是在可靠和高效地支持 WebAssembly 在浏览器之外的生产用例方面，仍有很多工作要做。 …","relpermalink":"/blog/is-webassembly-really-the-future/","summary":"这篇文章从多个角度探讨了 WebAssembly（Wasm）的现状和未来。首先，文章引用了 Cloud Native Computing Foundation（CNCF）的报告，指出 WebAssembly 在网页、无服务器、游戏和容器化应用中的应用越来越广泛，并预测 WebAssembly 将显著影响这些应用。其次，文章讨论了 WebAssembly 在容器、边缘计算、编程语言和无服务器应用等方面的应用。虽然 WebAssembly 已经成熟地应用于浏览器，但是在后端应用方面，如边缘设备的应用和部署，仍需要更多的工作。WASI 已经成为将 WebAssembly 扩展到浏览器之外的最佳选择，可以帮助解决在任何配置正确的 CPU 上运行 WebAssembly 运行时的复杂性。WebAssembly 和容器的应用预计将共同增长，尽管 WebAssembly 在某些用例中可以取代容器，但总体来说，两者是互补的产品。WebAssembly 的未来看起来非常光明，但是在可靠和高效地支持 WebAssembly 在浏览器之外的生产用例方面，仍有很多工作要做。","title":"WebAssembly 真的代表着未来吗？"},{"content":" 编者按：近日 Google 开源了一个名为 Service Weaver 的开源框架，它可以帮助开发者构建和部署分布式应用程序。Service Weaver 的特点是，它允许开发者以模块化单体的方式编写应用程序，然后使用自定义部署器将其部署为一组微服务。这样，开发者可以在不改变代码的情况下，灵活地调整应用程序的架构和性能。Google 开源博客介绍了该项目，并给出了开源地址：https://github.com/ServiceWeaver/weaver\nService Weaver 是一个用于构建和部署分布式应用程序的开源框架。Service Weaver 允许您将应用程序编写为模块化单体，并将其部署为一组微服务。\n更具体地说，Service Weaver 由两个核心部分组成：\n一组编程库，可让您将应用程序编写为单个模块化二进制文件，仅使用本机数据结构和方法调用，以及 一组部署器，可让您配置应用程序的运行时拓扑并将其部署为一组微服务，可以在本地或在您选择的云上部署。 Service Weaver 编程库从开发到执行的流程图，将标记为 A 到 D 的四个模块从跨微服务级别的应用程序移动 …","relpermalink":"/blog/introducing-service-weaver-framework-for-writing-distributed-applications/","summary":"编者按：近日 Google 开源了一个名为 Service Weaver 的开源框架，它可以帮助开发者构建和部署分布式应用程序。Service Weaver 的特点是，它允许开发者以模块化单体的方式编写应用程序，然后使用自定义部署器将其部署为一组微服务。这样，开发者可以在不改变代码的情况下，灵活地调整应用程序的架构和性能。","title":"Google 开源 Service Weaver——构建和部署分布式应用程序框架"},{"content":" 译者注：这篇文章介绍了如何编写云原生网络功能（CNF），即在电信领域的网络应用，它们与大多数云原生企业应用有不同的非功能性需求。CNF 需要满足高性能、高可靠性、高安全性和低延迟等指标。文章提出了一个基本的设计原则：每个容器只负责一个关注点，即一个单一的网络功能或子功能。\n本文主旨 Docker 和 Kubernetes 文档都提倡将一个应用程序或每个容器“一个问题”打包的概念。这也可以作为每个应用程序和容器运行“一种进程类型”的指南。 基于电信的云原生网络功能 (CNF) 具有低延迟、高吞吐量和弹性等特定要求，这激发了多关注点/多进程类型的容器化方法。 使用多种进程类型实现的高性能电信应用程序应该探索使用 unix 域套接字而不是 TCP 或 HTTP 进行通信，因为这可以加快容器之间的通信。 微服务的详细和简明定义 很有价值。厚微服务可以是任何利用康威定律并按产品团队边界部署代码的东西。精益微服务是那些遵循粗粒度代码部署的服务，通常在容器中，具有单一的关注点。\nCloud Native Network Functions（CNFs）是电信领域的网络应用，非功能性需求不同于大多数云 …","relpermalink":"/blog/cloud-native-network-functions-concern/","summary":"这篇文章介绍了如何编写云原生网络功能（CNF），即在电信领域的网络应用，它们与大多数云原生企业应用有不同的非功能性需求。CNF 需要满足高性能、高可靠性、高安全性和低延迟等指标。文章提出了一个基本的设计原则：每个容器只负责一个关注点，即一个单一的网络功能或子功能。","title":"云原生网络功能（CNF）应该让每个容器聚焦一个关注点"},{"content":"Envoy Gateway (EG)首次公开发布 四个月后，我们很高兴地宣布发布 版本 0.3 起。这个最新版本是几位 Tetrate 同事和整个社区其他人辛勤工作的结晶。Envoy Gateway 现在支持整个 Kubernetes Gateway API，包括实验部分——添加了一些强大的新功能，使这个免费的开源软件更接近于功能齐全的 API 网关。\nEG 的一大特点是它配置了新的网关 API，而不是旧的和非常有限的 Ingress API，或任何为了弥补 Ingress 缺陷的专有 API。虽然 EG 0.2 实现了 Gateway API 的核心部分（完全支持“基本”HTTP 路由），但 EG 0.3 在其 Gateway API 支持方面更进了一步，这可能是了解其新功能的最佳方式：\n支持更多 HTTP 功能，例如URL Rewrite、Response Header Operation 和流量镜像。这些来自 API 规范中的扩展字段。 支持路由 gRPC、UDP 和原始 TCP。这些来自 API 的实验性新部分。 请注意这些 API 扩展：我们正在努力为真实用户提供有用的功能。 …","relpermalink":"/blog/envoy-gateways-latest-v0-3-release-extends-the-kubernetes-gateway-api/","summary":"Envoy Gateway 0.3 发布，对 Kubernetes Gateway API 的支持更进一步。","title":"Envoy Gateway 0.3 发布——扩展 Kubernetes Gateway API"},{"content":"我们从最简单的基于 IDP 的 RBAC 开始，最终将基于组的 RBAC 与细粒度的权限和细粒度的资源相结合。\n授权很复杂，因为每个应用程序都必须发明自己的授权模型。但是，有一些陈旧的路径可以作为大多数应用程序的良好起点。这篇文章将描述这些模式以及 Topaz 开源项目或 Aserto 授权服务等授权平台如何帮助你实施他们。\n角色作为用户属性 最简单的授权模式将一组角色建模为用户的属性。这些角色可以在身份提供者 (IDP) 中配置，并且通常作为范围嵌入到 IDP 生成的访问令牌中。\n一些应用程序完全基于嵌入在访问令牌中的角色（或离散权限）进行授权。但这有一些缺点：\n角色/权限/范围爆炸：角色/权限越多，访问令牌中需要嵌入的范围就越多，从而导致大小问题。 IDP 和应用程序之间的耦合：每当向应用程序添加新权限时，也必须修改访问令牌中生成其他范围的代码。这通常由有权访问 IDP 的安全/身份和访问团队完成，并且它引入了工作流程的复杂性。 一旦发布，访问令牌就很难失效。只要访问令牌有效，经过身份验证的用户就拥有权限，即使他们的角色在令牌颁发后发生了变化。这反过来又会导致安全漏洞。 在这种情况 …","relpermalink":"/blog/role-based-access-control-five-common-authorization-patterns/","summary":"本文描述了五种访问控制模式以及 Topaz 开源项目或 Aserto 授权服务等授权平台如何帮助你实施他们。","title":"基于角色的访问控制：五种常见的授权模型"},{"content":"下面是我所知道的关于将 Rust 编译为 WebAssembly 的所有知识。\n前一段时间，我写了一篇如何在没有 Emscripten 的情况下将 C 编译为 WebAssembly 的博客文章，即不默认工具来简化这个过程。在 Rust 中，使 WebAssembly 变得简单的工具称为 wasm-bindgen，我们正在放弃它！同时，Rust 有点不同，因为 WebAssembly 长期以来一直是一流的目标，并且开箱即用地提供了标准库布局。\nRust 编译 WebAssembly 入门 让我们看看如何让 Rust 以尽可能少的偏离标准 Rust 工作流程的方式编译成 WebAssembly。如果你浏览互联网，许多文章和指南都会告诉你使用 cargo init --lib 创建一个 Rust 库项目，然后将 crate-type = [\u0026#34;cdylib\u0026#34;] 添加到你的 cargo.toml，如下所示：\n[package] name = \u0026#34;my_project\u0026#34; version = \u0026#34;0.1.0\u0026#34; edition = \u0026#34;2021\u0026#34; [lib] crate-type = [\u0026#34;cdylib\u0026#34;] …","relpermalink":"/blog/rust-to-wasm/","summary":"关于将 Rust 编译为 WebAssembly 的所有知识。","title":"Rust 编译 WebAssembly 指南"},{"content":" 译者评论\n本文作者观点是：不应该将自由和开源软件（FOSS）置于你的软件供应链中，而是寻找他们的供应商，因为只有能够为软件负责任的供应商存在才能作为供应链的一环。\n在过去的几年里，我们看到了很多围绕软件供应链概念的讨论。这些讨论始于 LeftPad 时代，并随着过去几年发生的各种事件而升级。这个领域所有工作的问题在于它忘记了一个基本点。\n在开始讨论这个基本点之前，我将定义供应链和一般供应商的含义，以及我们申请软件的原因。那么为什么将 FOSS（自由和开源软件）置于该定义之下的尝试被深深地误导了。\n概念 在过去的几十年里，我们看到了 FOSS 的兴起。特别是，这可以极大地增加打包为库的代码片段的重用。这要归功于围绕这个想法蓬勃发展的庞大的基础设施生态系统。今天，每一种编程语言环境中都有一个包管理器，中央存储库保存着查找库和处理它们的分发所需的元数据。\n这是可能的，因为 FOSS 许可证非常宽松，并且可以重复使用和重新混合这些库，否则会出现的大量法律和财务问题。一个现代软件项目可能有成百上千个这样的依赖项，从 OpenSSL 到测试框架或日期选择器，涵盖诸如 JSON 编码器/解码器库甚 …","relpermalink":"/blog/not-a-supplier/","summary":"在过去的几十年里，我们看到了自由和开源软件 (FOSS) 的兴起。这使得打包为库的代码段的重用大幅增长。包管理器适用于当今世界上的每一种编程语言，它们的中央存储库保存着查找库和处理它们的分发所需的元数据。","title":"我不是供应商"},{"content":"故障发生在 2023 春节前两天，DeepFlow 团队内部访问工单系统出现问题，影响了所有北京区的同事，这篇文章将详细记录如何利用 DeepFlow 定位到对这次问题根因（网关 MSS 误变更导致报文大于 MTU，大数据报文被丢弃）。\n背景介绍 工单系统是 DeepFlow 团队自主研发的一个跟踪工单的内部工具，部署在阿里公有云的容器服务（ACK）中，工单系统通过 Ingress 的方式对外提供服务，办公区与阿里云通过 VPN 连接，因此办公区可以直接使用域名访问工单系统。在《K8s 服务异常排障过程全解密》文中对 K8s 访问方式做过总结，工单系统是比较典型的方式三的访问形式\n集群外客户端通过 Ingress 访问集群内服务 下图是通过 DeepFlow 自动绘制的访问拓扑图，可以看出北京和广州办公区都是通过 Ingress 的形式来访问工单的入口服务 (ticket_web)。工单系统部署在基础服务的容器集群上，此容器集群所有的 Node 上都已经部署了 deepflow-agent，因此可以自动采集所有 POD 及 Node 的网络/系统/应用相关的数据， …","relpermalink":"/blog/troubleshooting-of-the-k8s-application-with-deepflow/","summary":"故障发生在 2023 春节前两天，DeepFlow 团队内部访问工单系统出现问题，影响了所有北京区的同事，这篇文章将详细记录如何利用 DeepFlow 定位到对这次问题根因（网关 MSS 误变更导致报文大于 MTU，大数据报文被丢弃）。","title":"可观测性实战：快速定位 K8s 应用故障"},{"content":"这是 服务网格最佳实践系列文章 中的第三篇，摘自 Tetrate 创始工程师 Zack Butcher 即将出版的新书 Istio in Production。\nIstio 就像一组乐高积木：它具有许多功能，可以按照您想要的任何方式进行组装。出现的结构取决于您如何组装零件。在 上一篇中，我们描述了一种运行时拓扑结构，用于构建健壮、有弹性且可靠的基础架构。在本文中，我们将描述一组网格配置，以帮助在运行时实现稳健性、弹性、可靠性和安全性。\nIstio 在其所谓的 根命名空间 中支持全局默认配置 —— 默认在 istio-system。在根命名空间中发布的配置默认适用于所有服务，但在本地命名空间中发布的任何配置都会覆盖它。因此，一些配置应该在根命名空间中发布，并且不允许在其他任何地方发布（例如用于在传输中强制加密的 PeerAuthentication 策略）。其他配置应该在每个服务自己的命名空间中编写（例如 VirtualService 控制它的弹性设置）。\n我们看到的最成功的网格采用将网格本身隐藏在另一个界面后面：例如 Helm 模板、Terraform 或更高级的解决方案， …","relpermalink":"/blog/optimize-traffic-management-and-security-with-these-service-mesh-best-practices/","summary":"本文推荐了服务网格安全性优化的一些最佳实践。","title":"服务网格安全性优化最佳实践"},{"content":"这是 服务网格最佳实践系列文章 中的第二篇，摘自 Tetrate 创始工程师 Zack Butcher 即将出版的书籍 Istio in Production。\n当涉及到在多集群的基础设施中部署服务网格时，有一些可移动的部分。这里主要想强调的是控制平面应该如何部署在应用程序附近，入口应该如何部署以促进安全性和敏捷性，如何使用 Envoy 促进跨集群负载均衡，以及网格内部如何使用证书。\n使服务网格控制平面与故障域保持一致 建议：围绕故障域部署松散耦合的控制平面以实现高可用性。\n构建高可用性系统可能具有挑战性，而且通常成本很高。我们知道的一种经过验证的技术是围绕故障域构建。故障域是当关键系统发生故障时受影响的基础架构部分。我们构建可靠系统的基本方法是将系统跨越的故障域分组为多个独立的孤岛。最终系统的整体可靠性取决于我们可以使孤岛的独立程度。实际上，总是存在一些相互依赖性，将其最小化总是成本与可用性的权衡。\n在没有耦合故障域的情况下创建隔离孤岛的最简单方法是在每个孤岛中运行关键服务的独立副本。我们可以说这些副本是筒仓的本地副本 —— 它们共享相同的故障域。在云原生架构中，Kubernetes …","relpermalink":"/blog/service-mesh-deployment-best-practices-for-security-and-high-availability/","summary":"本文强调的是控制平面应该如何部署在应用程序附近，入口应该如何部署以促进安全性和敏捷性，如何使用 Envoy 促进跨集群负载均衡，以及网格内部如何使用证书。","title":"服务网格安全性和高可用性部署最佳实践"},{"content":"注：原文发布于 2018 年 2 月 26 日。\n2018 年 Let’s Encrypt （免费、自动化、开放的证书颁发机构 EFF 在两年前帮助推出）达到了一个巨大的里程碑： 颁发了超过 5000 万个有效证书。而且这个数字只会继续增长，因为几周后 Let’s Encrypt 也将开始颁发“通配符”证书 —— 这是许多系统管理员一直要求的功能。\n什么是通配符证书？ 为了验证 HTTPS 证书，用户的浏览器会检查以确保证书中实际列出了网站的域名。例如，来自 www.eff.org 的证书实际上必须将 www.eff.org 列为该证书的有效域。如果所有者只想对他的所有域使用一个证书，则证书还可以列出多个域（例如，www.eff.org、ssd.eff.org、sec.eff.org 等）。通配符证书只是一个证书，上面写着“我对这个域中的所有子域都有效”，而不是明确地将它们全部列出。（在证书中，这是通过使用通配符来表示的，用星号表示。所以如果你今天检查 eff.org 的证书，它会说它对 *.eff.org 有效。）这样，\n为了颁发通配符证书，Let’s Encrypt 将要求用户通过 …","relpermalink":"/blog/technical-deep-dive-securing-automation-acme-dns-challenge-validation/","summary":"本文深入探讨了 DNS 质询的自动化。","title":"深入探讨：ACME DNS 质询验证的自动化"},{"content":"2022 年，WebAssembly（通常缩写为 Wasm）成为了焦点。新的 Wasm 初创企业出现。老牌公司宣布支持 Wasm。Bytecode Alliance 发布了许多 Wasm 标准。Cloud Native Computing Foundation 举办了两次 WasmDay 活动。而其中最大的 Wasm 用户之一 Figma 被 Adobe 以惊人的 200 亿美元的价格收购。\nWasm 是一种二进制格式。许多不同的语言都可以编译为相同的格式，并且该二进制格式可以在大量操作系统和体系结构上运行。Java 和 .NET 在这方面也很相似，但是 Wasm 有一个重要的区别：Wasm 运行时不信任执行的二进制文件。\nWasm 应用程序被隔离在沙盒中，只能访问用户明确允许的资源（如文件或环境变量）。Wasm 还有许多其他理想的特性（例如非常出色的性能），但正是它的安全模型使 Wasm 在广泛的环境中使用，从浏览器到边缘和 IoT，甚至到云端。\n如果要在 2022 年发现 Wasm 趋势，那就是 Wasm 现在在浏览器之外也同样成功。这一趋势是 2023 年的基础。随着 Wasm  …","relpermalink":"/blog/webassembly-5-predictions-for-2023/","summary":"2023 年将是 Wasm 年。","title":"2023 年 WebAssembly 技术五大趋势预测"},{"content":"本文是 Tetrate 即将出版的《Istio in Production》一书中摘录的服务网格最佳实践系列的第一篇，作者是 Tetrate 创始工程师 Zack Butcher。\n我们接到许多实施网格的企业的问题，其中之一是“我还需要哪些控制，而网格提供哪些控制？”换句话说，他们想知道网格如何适应现有的安全模型。我们发现，网格最适合作为一组安全控制的内圈，这些控制从物理网络到应用本身的每一层都被实施。\n服务网格作为通用策略执行点 我们看到网格的 Sidecar 作为通用策略执行点（NIST SP 800-204B：使用服务网格的基于属性的访问控制）。由于它拦截了所有进出应用程序的流量，Sidecar 为我们提供了一个强大的位置来实现各种策略。我们可以实现传统的安全策略，如基于应用程序标识而非网络位置的更高保证的应用程序之间的授权。但我们也可以实施之前不切实际或需要与应用程序深度参与的策略。例如，网格允许您编写以下策略：“后端可以从数据库读取（使用应用级身份进行身份验证和授权），但前提是请求具有有效的最终用户凭证并具有读取范围（使用最终用户身份进行身份验证和授权）。”\n虽然服务网格提供 …","relpermalink":"/blog/how-service-mesh-layers-microservices-security-with-traditional-security-to-move-fast-safely/","summary":"我们认为，服务网格最适合作为现有安全模型的一部分，通过在传统安全控制之上添加更细粒度的安全策略来实现。","title":"如何将服务网格作为安全模型的一部分，以分层形式将微服务安全与传统安全结合起来"},{"content":"本文为云杉网络原力释放 - 云原生可观测性分享会第十三期直播实录。回看链接，PPT 下载。\nGrafana 是目前最广泛使用的数据可视化软件之一，DeepFlow 中已有大量基于 Grafana Dashboard 解决的可观测性场景的实战分享。这些场景都是基于 DeepFlow Grafana 插件提供的查询能力来构建的。DeepFlow 社区致力于基于开源生态构建一个完整的可观测性平台，而终端呈现和数据的可视化呈现是其中的重要一环。本文对当前 DeepFlow 提供的 Grafana 插件做一个简单介绍，抛砖引玉，希望大家能了解并创造更多的 DeepFlow 可观测性生态应用，也希望能让大家掌握如何开发一套完整的 Grafana Plugin。\nDeepFlow 插件简介 在最早的 DeepFlow 企业版中，我们提供了一些比较简单的 Grafana 插件。这些插件是基于 DeepFlow 企业版 API 来提供服务的，目的是为了能让用户无缝将 DeepFlow 页面中的视图在自己的 Grafana 环境中搭建起来，避免改变用户的使用习惯。在 DeepFlow 宣布开源以后，我们基 …","relpermalink":"/blog/grafana-plugins-on-cloud-observability/","summary":"分享可观测性场景下 Grafana Plugin 的开发细节和原理。","title":"可观测性场景下 Grafana Plugin 开发实战"},{"content":"为何要进行 Egress 流量策略管控 2021 年 CNCF 调查显示，全球将 kubernetes 用在生产环境的用户占比已达 59.77%，欧洲用户更是达到了 68.98%。用户正越来越多的将生产业务迁移到 kubernetes 环境下。Gartner 2021 Hype Cycle for Cloud Security 也显示了容器与 Kubernetes 安全已处在”slope of Enlightenment”阶段。这说明保护 kubernetes 里的应用服务正变的越来越重要。\n当我们去审视运行在 kubernetes 中的大量微服务时，我们可以看到微服务安全具有典型的微边界以及需要进行持续性安全工程的特点。我们需要以每个微服务为边界进行保护，无论是其运行时，还是南北和东西流量。需要每个微服务单元在编码之初就开始着手安全考虑，进行安全左移，安全的防护设施、方法、策略应与开发者和 kubernetes 平台运维者适配。还需要有能力洞察所有的流量事件，采集所有运行时日志、事件等数据，通过持续性的安全工程系统对这些数据进行分析，聚合出规则并反馈到安全的策略设定中。 …","relpermalink":"/blog/egress-for-k8s/","summary":"关于 Kubernetes 环境下 Egress 流量的访问控制方法。","title":"是时候思考 Kubernetes 出向流量安全了"},{"content":"Kubernetes（K8s）是一个用于大规模运行分布式应用和服务的开源容器编排平台。K8s 让应用发布更加快速安全，让应用部署也更加灵活，但在带来这些便利性的同时，也给应用排障增加了 K8s 平台层面的复杂度，本篇文章将以常见的服务异常入手，来详细拆解 K8s 服务访问方式，以及如何利用现有的可观测体系来对 k8s 平台和应用服务进行快速排障。\n服务的访问方式 开启 K8s 服务异常排障过程前，须对 K8s 服务的访问路径有一个全面的了解，下面我们先介绍目前常用的 K8s 服务访问方式（不同云原生平台实现方式可能基于部署方案、性能优化等情况会存在一些差异，但是如要运维 K8s 服务，则需要在一开始就对访问方式有一个了解）。\n方式一：集群内客户端通过 ClusterIP 访问集群内服务\n集群内客户端通过 ClusterIP 访问集群内服务 从访问逻辑拓扑来分析，集群内客户端 POD 访问的是集群内服务的 svc_name，然后在 svc 层进行 DNAT，将请求转发到对应的后端 POD。这个过程对应的访问实现拓扑则要复杂不少：\nstep 1: client_pod 根据 DNS 配置， …","relpermalink":"/blog/k8s-service-exception-troubleshooting/","summary":"Kubernetes 服务异常排障过程的实践经验分享。","title":"Kubernetes 服务异常排障过程全解密"},{"content":"Istio 的核心功能之一是通过管理网格中服务的身份来促进零信任网络架构。为了在网格中检索用于 mTLS 通信的有效证书，各个工作负载向 istiod 发出证书签名请求 (CSR)。Istiod 反过来验证请求并使用证书颁发机构（CA）签署 CSR 以生成证书。默认情况下，Istio 为此目的使用自己的自签名 CA，但最佳实践是通过为每个 Istio 部署创建一个中间 CA，将 Istio 集成到您现有的 PKI 中。\n如果您正在管理多个集群，这意味着颁发多个中间 CA，每个中间 CA 都应设置为在几个月或更短的时间内到期。管理这些 CA 的生命周期至关重要，因为它们必须在过期或坏事发生之前进行轮换。本文将向您展示如何简化此 CA 管理以降低风险并提高系统的整体稳定性。\n轮换 CA 时的一个关键步骤是确保实际使用新的 CA。默认情况下，Istio 仅在启动时加载其 CA。但是，Istio 可以配置为监视更改并在更新时自动重新加载其 CA。本教程取自我们与管理大量 Istio 部署的企业客户合作开发的生产手册，将展示如何配置 Istio 以自动重新加载其 CA。 …","relpermalink":"/blog/automate-istio-ca-rotation-in-production-at-scale/","summary":"本文将向您展示如何简化 Istio 中的 CA 管理以降低风险并提高系统的整体稳定性。","title":"在生产中大规模自动化 Istio CA 轮换"},{"content":"当我们与想要使用 Istio 的客户或用户交流时，这一个问题时长会出现——Istio 中的证书信任如何工作的？Istio 有自己的证书颁发机构，而我们也有自己的证书颁发机构，如何确保它们相互信任？\n简而言之，通过中间签名证书将 Istio 纳入到您现有的信任链中。\n如果您使用 Istio 作为演示或开箱即用，它将拥有自己的自签名证书 —— 它是自己的根证书。对于在多个集群中运行 Istio 的用户来说，这是一个常见的痛点：他们无意中创建了两个互不不信任的孤岛，因此没有安全通信。\n以下是如何通过让 Istio 信任您现有的 PKI 的步骤。\n简述 这是简短的版本：您应该通过为每个 Istio 部署创建一个中间签名证书来让 Istio 信任您现有的 PKI（并且每个集群应该有一个 Istio 部署）。然后你会：\n启用跨 Istio 部署的通信 允许细粒度的证书撤销，而无需同时在整个基础架构中强制使用新证书（如果这听起来像是等待发生的重大中断，那么您是对的）。 启用签名证书的轻松轮换。您需要做的就是创建一个新的中间件并使用新证书重新启动 Istio。因为它在同一个信任根中，所以一切都继续工 …","relpermalink":"/blog/istio-trust/","summary":"本文讲解了如何让 Istio 信任现有 PKI 的步骤。","title":"将 Istio 纳入信任链：使用现有 PKI 作为信任根"},{"content":"在本文中，我们将探讨如何使用 Hashicorp Vault 作为一种比使用 Kubernetes Secret 更安全的方式来存储 Istio 证书。默认情况下，Secret 使用 base64 编码存储在 etcd 中。在安全策略严格的环境中，这可能是不可接受的，因此需要额外的措施来保护它们。一种此类解决方案涉及将机密存储在外部机密存储提供程序中，例如 HashiCorp Vault。\nVault 可以托管在 Kubernetes 集群内部和外部。在本案例中，我们将探索使用托管在 Kubernetes 外部的 Vault，以便它可以同时为多个集群提供秘密。该设置也非常适合探索 Istio 的多集群功能，它需要一个共享的信任域。\n利用 vault-agent-init 容器，我们可以将证书和私钥材料注入实际的 Istio 控制平面 Pod，以便它们使用外部 CA 证书进行引导。这避免了依赖 Secret 来引导 Istio 控制平面。该技术也完全适用于入口和出口证书。\n有关如何在 Istio 中使用和管理证书的更多信息，请参见官方文档：\n身份和证书管理 插入 CA …","relpermalink":"/blog/how-to-use-hashicorp-vault-as-a-more-secure-way-to-store-istio-certificates/","summary":"本文将指导你使用 Vault 存储 Istio 的证书。","title":"如何使用 Hashicorp Vault 作为一种更安全的方式来存储 Istio 证书"},{"content":"伴随着云计算的浪潮，云原生的概念也应运而生，从 2015 年 CNCF 云原生基金会的成立，已经持续高速发展了 7 年时间。而 Kubernetes 作为云原生的代表就像是一个全新的云操作系统，围绕着它诞生了丰富的上层应用和生态。\n迄今为止，CNCF 在其公布的云原生全景图中，显示了目前近 30 个领域、数百个项目的繁荣发展，云原生技术的广度和深度得到了前所未有的发展。\nCNCF Landscape 面对这庞杂的技术领域和技术工具，我们往往不知道要从哪儿下手开始学习。即便掌握了云原生核心技术 Docker 和 K8s，不过在工程实践中，这远远是不够的。\n那当我们有了云原生基础之后，想要进一步实现职业晋升，我建议你从下面的几个方面去学习：\n云原生架构师必须掌握的技能 总结来说，你需要聚焦在下面几个领域：\n容器和镜像：Docker 持续集成：GitHub Action、Jenkins、Tekton 镜像仓库：Harbor 应用定义：Helm、Kustomize 持续部署：FluxCD、ArgoCD 秘钥管理：Vault 容器编排：K8s 网关：Ingress-Nginx 日 …","relpermalink":"/blog/advanced-guide-for-cloudnative-architects/","summary":"本文介绍了进阶云原生架构师的学习路径以及怎么更高效地学习云原生的 12 大领域，同时也推荐了体系化云原生课程。","title":"云原生架构师进阶指南"},{"content":"传统的网络安全依赖于围绕可信内部网络的强大防御边界，以将不良行为者拒之门外，将敏感数据拒之门外。在日益复杂的网络环境中，维护强大的边界越来越困难。\n零信任安全正在成为企业保护其传统和现代云原生应用程序的首选方法。零信任网络架构颠覆了边界安全的假设。在零信任网络中，每个资源都在内部受到保护，就好像它暴露在开放的互联网中一样。\n为了为行业和美国联邦政府建立零信任安全指南，美国国家标准与技术研究院 (NIST) 在一系列出版物中建立了零信任安全指南，从 SP 800-207 开始，介绍一般的零信任架构及其配套SP 800-204 微服务安全标准系列。\n以下是 NIST 的核心零信任架构原则以及建议在实践中应用它们的 Kubernetes 和 Istio 参考架构。\n零信任网络的六项原则 无论网络位置如何，所有通信都应该是安全的。网络位置和可达性并不意味着信任。企业拥有或其他专用网络内部的访问请求必须满足与来自任何其他位置的通信相同的安全要求。零信任系统的一个标准是，您可以将它暴露在开放的互联网上，并且它仍然是安全的，没有未经授权的系统、数据或通信访问。 所有通信都应加密。线路上的加密可防止窃 …","relpermalink":"/blog/the-top-6-zero-trust-principles-for-kubernetes-security/","summary":"本文是 NIST 的核心零信任架构原则以及建议在实践中应用它们的 Kubernetes 和 Istio 参考架构。","title":"Kubernetes 安全的 6 大零信任原则"},{"content":"Kubernetes 是编排现代云原生工作负载的事实标准。但是，它不提供开箱即用的安全通信。这意味着每个需要实施传输中加密以对其 Kubernetes 部署采用零信任安全态势的人都需要自己解决这个问题。\n幸运的是，有很多易于理解的方法可以实现，在本文中，我们将介绍在 Kubernetes 中实现双向 TLS（mTLS）的三大最佳实践。\n什么是 mTLS，为什么对安全来说很重要？ 传输层安全性（SSL 的后继者）是部署最广泛的安全通信标准，在 HTTPS 中最为明显。TLS 非常适合在需要向客户端证明其身份的服务器之间建立既保密（防窃听）又真实（防篡改）的安全通信。但是，在双方都需要向对方证明身份的情况下（例如在 Kubernetes 应用程序中的微服务之间），TLS 是不够的。\n这就是双向 TLS (mTLS) 的用武之地。mTLS 是 TLS，但双方在建立安全通信通道之前向对方证明自己的身份。这是 Kubernetes 中安全通信所需的必要部分。mTLS 提供：\n在线加密以确保机密性和防篡改 相互的、加密的安全身份证明以确保真实性 要深入了解 mTLS 的工作原理， …","relpermalink":"/blog/top-3-mtls-best-practices-for-zero-trust-kubernetes-security/","summary":"我们将介绍在 Kubernetes 中实现双向 TLS（mTLS）的三大最佳实践。","title":"零信任 Kubernetes 安全的三大 mTLS 最佳实践"},{"content":"Apache SkyWalking 作为一个分布式系统的应用性能监控工具，它观察服务网格中的指标、日志、痕迹和事件。其中 SkyWalking OAP 高性能的数据流处理架构能够实时处理庞大的数据流量，但是这些海量数据的存储更新和后续查询对后端存储系统带来了挑战。\nSkyWalking 默认已经提供了多种存储支持包括 H2、OpenSearch、ElasticSearch、MySQL、TiDB、PostgreSQL、BanyanDB。其中 MySQL 存储提供的是针对单机和单表的存储方式（MySQL 的集群能力需要自己选型提供），在面对高流量的业务系统时，监控数据的存储存在较大压力，同时影响查询性能。\n在 MySQL 存储基础上 SkyWalking v9.3.0 提供了一种新的存储方式 MySQL-Sharding，它提供了基于 ShardingSphere-Proxy 的分库分表特性，而分库分表是关系型数据库面对大数据量处理的成熟解决方案。\n部署架构 SkyWalking 使用 ShardingSphere-Proxy 的部署方式如下图所示。\n部署架构 SkyWalking OAP …","relpermalink":"/blog/skywalking-shardingsphere-proxy/","summary":"在 MySQL 存储基础上 SkyWalking v9.3.0 提供了一种新的存储方式 MySQL-Sharding，它提供了基于 ShardingSphere-Proxy 的分库分表特性，而分库分表是关系型数据库面对大数据量处理的成熟解决方案。","title":"SkyWalking 基于 ShardingSphere-Proxy 的 MySQL-Sharding 分库分表的存储特性介绍"},{"content":"从 2017 年起我们就开始与 Kubernetes 社区合作，将 Kubernetes 作为后端容器编排平台，将无数应用程序迁移到云端。其中有些迁移进展顺利，而另一些则颇具挑战性。同样，我们利用云服务提供商（CSP）的本地容器编排解决方案来执行相同的操作，在易于迁移的情况下获得了类似的结果。本文无意讨论这些经验，也无意说明一种技术胜过另一种技术，而是讨论业务领导者和架构师选择利用 Kubernetes 的原因。\n根据我们的经验，根据你的组织结构和运营模式，大规模利用 Kubernetes 比利用其他 CSP 原生解决方案，如 AWS Elastic Container Service（ECS）、AWS Batch、Lambda、Azure App Service、Azure Functions 或 Google Cloud Run 的开销更大。\nKubernetes 是一种开源容器编排引擎，其本质旨在在任何地方运行。它的架构在如何通过本地使用插件和扩展来实现这种可移植性方面非常出色。但是，这是集群运维的责任，由他们来管理和操作这些插件。我们知道，某些服务（如 EKS、GKE …","relpermalink":"/blog/does-kubernetes-really-give-you-multicloud-portability/","summary":"本文讨论业务领导者和架构师选择使用 Kubernetes 的原因。","title":"Kubernetes 真的能提供多云可移植性吗？"},{"content":"2022 年 10 月底，作为在底特律举行的完整 KubeCon 和 CloudNativeCon 活动之前的场外活动，Open Observability Day 为期一天的活动首次举行。\n活动会场在亨廷顿广场会议中心，可以看到河对面加拿大的景色（很多人都不知道底特律离美国北部边境如此之近） 。\nOpen Observability Day 的完整时间表可在线获得，今天我想分享一下在那里的感受。\n这一天以所有与开放可观测性相关的 CNCF 项目为中心，充斥了供应商和以项目为中心的演讲。\n活动从 CNCF 项目创始人 Bartek Płotka 的概述开始，他叙述了 Thanos、Fluntd、OpenTelemetry、Jeager 等项目的更新。然后过渡到两个简短的主题演讲。\n分布式追踪：斗争是真实的 Chronosphere 的现场首席技术官 Ian Smith 分享了他在该领域从事分布式跟踪解决方案 9 年后的想法。他带我们进行了一次旋风之旅，了解了它的来源和可能的发展方向，以及围绕支持分布式跟踪的工具存在哪些技术问题。下面是他给出的 tips：\n追踪已成为高承诺、高努力、低价 …","relpermalink":"/blog/kubecon-summary-of-the-open-observability-day/","summary":"本文是作者参加 KubeCon 北美 2022 可观测性开放日的见闻分享。","title":"KubeCon 北美 2022 可观测性开放日见闻"},{"content":"本文为云杉网络原力释放 - 云原生可观测性分享会第十一期直播实录。回看链接，PPT 下载。\n大家好，我是陈晨，今天和分享的内容是《论元数据在可观测性中的重要性》，大纲为：\n从智能驾驶看可观测性未来发展。 用开源产品构建可观测性遇到的痛点。 构建内部元数据平台打通多信号关联。 那前期我们多位老师为大家分享了可观测性相关的领域知识，看到大家对多信号之间的关联有一些疑惑，今天来和大家聊下元数据在可观测性多信号关联的重要性。\n从智能驾驶看可观测性未来发展 在此之前为大家解释下多信号的概念，该概念来源于 CNCF 可观测性 SIG 推出的《可观测性白皮书》一文中的译词，当然云原生社区也有我们翻译的中文版白皮书内容，欢迎大家去看往期的文章推送。那从白皮书里总结起来，多信号就是可观测性系统中各种用途不同但具备结构化、标准化数据的总称，例如我们常常听到的 logs，traces，metrics 等数据。\n可观测性在获取到多个信号后，会将其以静态或动态的状态放置于存储内，通过多个不同状态的信号来构建属于自己的可观测性平台，以此来缩短解决错误的时间和透视化软件服务内部的黑盒状态。在这个动态过程中，让多信号 …","relpermalink":"/blog/the-importance-of-metadata-in-observability/","summary":"虚拟化和容器化让应用的部署环境和运行环境变得复杂起来，系统的复杂度呈指数级增长。在**垂直领域**下各个可观测性开源产品的**侧重点也是不同**，那打通这些产品之间的联系，来构建自己的可观测性平台是一件比较复杂的事情。","title":"论元数据在可观测性中的重要性"},{"content":"这项研究建立在 Datadog 以前版本的容器使用报告、容器编排报告和Docker 研究报告的基础上。最新更新于 2022 年 11 月。译自：https://www.datadoghq.com/container-report/。\n现代工程团队继续扩展他们对容器的使用，如今基于容器的微服务应用程序无处不在。不断增长的容器使用正在推动组织采用互补技术来简化他们操作集群的方式，而这种不断扩展的容器环境给组织带来了安全挑战。\n在本报告中，我们检查了数万 Datadog 客户运行的超过15 亿个容器，以了解容器生态系统的状态。继续阅读，了解从最新的实际使用数据中收集的更多见解和趋势。\n“这项调查表明，容器和 Kubernetes 革命正在不断发展壮大。结果揭示了使用容器和 Kubernetes 的云原生组织不仅发展得更快，而且获得了更大的信心——在比以往任何时候都更关键的生产环境中构建和部署更大型的应用程序和工作负载。\n得益于云原生生态系统中超过 175,000 名贡献者所推动的创新，云原生组织已为前进的道路做好了准备。他们正在创造可以让各种规模的工程团队都可以构建和运行应用程序的技术，以满 …","relpermalink":"/blog/container-insights-2022/","summary":"Datadog 发布最新的容器生态系统趋势洞察。","title":"2022 年容器生态系统的 9 大趋势洞察"},{"content":"在这篇文章中，我们将亲身体验 Envoy Gateway 和 Gateway API。以下是逐步指导你安装 Envoy Gateway 的说明，以及通过 Envoy 代理在集群外公开 HTTP 应用程序的简单用例。\n如果你不方便运行，我在本文中包含了每个命令的输出，即使你没有 Kubernetes 集群也可以看到它是如何工作的。\n如果你是 GUI 的粉丝，在文章的最后我会附上 Tetrate 基于 Backstage 的概念验证 Envoy Gateway GUI 的屏幕截图和详细信息，以展示针对 Gateway API 构建此类东西是多么容易。\n创建 Kubernetes 集群 首先运行 Envoy Gateway 和 Kubernetes 集群。最简单、最安全的方法是使用 minikube 在本地机器上启动集群。\n$ minikube start –driver=docker --cpus=2 --memory=2g 😄 minikube v1.27.0 on Arch 22.0.0 (x86_64) ▪ KUBECONFIG=... ❗ For more information, …","relpermalink":"/blog/hands-on-with-envoy-gateway/","summary":"最近 Envoy Gateway 0.2 发布了，API 网关的生态系统迎来了新的变化。这篇文章将想你介绍 Kubernetes API 网关领域的最新进展。","title":"使用 Envoy Gateway 0.2 体验新的 Kubernetes Gateway API"},{"content":"最近 Envoy Gateway 0.2 发布了，API 网关的生态系统迎来了新的变化。这篇文章将想你介绍 Kubernetes API 网关领域的最新进展。\n如何将外部的网络请求路由到 Kubernetes 集群？你可以使用入口控制器：一组 HTTP 反向代理，将流量转接到集群中，并由 operator 来管理。也可以使用 Ambassador、Contour、Traefik 或 HAproxy 这类软件。还可以使用云提供商的解决方案，或者只是用默认的的 Nginx Ingress。或者你可能使用一个功能更全面的 API 网关，如 Tyk 或 Kong，或者在 Kubernetes Ingress 前面的另一层有一个单独的网关，如 AWS 的 API 网关，或内部的 F5，可以选择的实在太多。\n为什么我们需要一个新的入口控制器 因为很多入口控制器都有不同程度的限制：有些是基于旧的技术，如 Nginx、HAproxy，甚至是基于 Apache 建立的。这些技术的特性不适用于云原生环境，比如在配置改变时放弃已建立的连接（如果你想深入了解，Ambassador 发表了一篇比较文章）。云供应 …","relpermalink":"/blog/envoy-gateway-to-the-future/","summary":"最近 Envoy Gateway 0.2 发布了，API 网关的生态系统迎来了新的变化。这篇文章将向你介绍 Kubernetes API 网关领域的最新进展。","title":"面向未来的网关：新的 Kubernetes Gateway API 和 Envoy Gateway 0.2 介绍"},{"content":"本文为云杉网络原力释放 - 云原生可观测性分享会第十期直播实录。回看链接，PPT 下载。\n大家好，我是云杉网络 DeepFlow 的云原生工程师宋建昌，今天给大家带来的主题是《DeepFlow 在 Kube-OVN 环境的可观测实践》\n今天讲解的主要内容是：\n第一：DeepFlow 高度自动化的可观测性能力； 第二：DeepFlow 一键开启 Kube-OVN 的可观测性； 第三：DeepFlow 在 Kube-OVN 环境下的实际应用。 0x0: DeepFlow 高度自动化的可观测性能力 为什么需要可观测性，以及可观测的概念前面几期已经讲解过了，我再简单聊一下 DeepFlow 的架构、能力，方便不太熟悉 DeepFlow 的同学快速了解 DeepFlow 的背景：\nDeepFlow 架构 Rust 实现的 deepflow-agent 作为 frontend 采集数据，并与 K8s apiserver 同步资源和 Label 信息；Golang 实现的 deepflow-server 作为 backend 负责管理控制、负载均摊、存储查询。我们使用 MySQL 存储元数据， …","relpermalink":"/blog/enable-the-observability-of-kube-ovn-cni-environment/","summary":"DeepFlow 在 Kube-OVN CNI 环境的全栈、全链路可观测性建设实践","title":"DeepFlow 开启 Kube-OVN CNI Kubernetes 集群的可观测性"},{"content":"在云原生快速发展的前提下，服务网格领域也开始逐渐火热。目前阶段，大家所熟知的服务网格解决方案很多，每种产品又各有其优势。因此在面对不同的行业或者业务背景时，每个人的选型想法都各不相同。\n服务网格现状和痛点 服务网格的出现其实跟目前业务架构的演进有很大关系。云原生趋势大涨后，大部分企业都开始转型做微服务。在这种背景之下，大家发现 App 开始变得越来越小，每个 App 里面都会一些通用的东西。所以就开始有一些想法“有没有一种技术可以把这些通用的东西沉淀下来”。于是，就出现了 Sidecar（边车）。\n有了 Sidecar 之后，就可以把一些诸如服务注册发现、流量管理、可观测性和安全防护等功能沉淀到其中，这样业务服务就可以专注于业务逻辑层面的开发。\n但是在出现 Sidecar 模式之后，在实践过程中人们也开始慢慢发现它的一些痛点，比如：\n方案众多，一旦选择就难以撤退。目前市面上的服务网格方案众多，各种方案中各有差异。一旦确定了其中一个方案，基本就会一直使用下去。但如果在后续使用过程中发现方案无法满足相关业务迭代，再次更换时就会产生巨大的成本。\n与基础设施整合成本高。服务网格在落地实践中，通 …","relpermalink":"/blog/2022-service-mesh-summit-apache-apisix-mesh/","summary":"本文描述了当下服务网格领域的一些痛点，同时介绍了基于 APISIX 的服务网格方案细节与表现。","title":"Apache APISIX 借助服务网格实现统一技术栈的全流量管理"},{"content":"本文为云杉网络原力释放 - 云原生可观测性分享会第九期直播实录。回看链接，PPT 下载。\nDeepFlow 是一款开源的高度自动化的可观测性平台，是为云原生应用开发者建设可观测性能力而量身打造的全栈、全链路、高性能数据引擎。DeepFlow 使用 eBPF、WASM、OpenTelemetry 等新技术，创新的实现了 AutoTracing、AutoMetrics、AutoTagging、SmartEncoding 等核心机制，帮助开发者提升埋点插码的自动化水平，降低可观测性平台的运维复杂度。利用 DeepFlow 的可编程能力和开放接口，开发者可以快速将其融入到自己的可观测性技术栈中。\nDeepFlow - 架构图 今天的内容是云杉网络“云原生可观测性分享会”的直播里面第八期DeepFlow 首个开源版本的分享的延续，上篇主要和大家详细聊了 AutoMetrics 和 AutoTracing 的能力，对于可观测领域三大支柱的的 Logging，在这次博客及直播中给大家带来详细讲解。\n今天从三个方面给大家进行分享：\n一：分享应用调用日志，从数据来源、数据抽象到数据使用三个角度和大家谈 …","relpermalink":"/blog/autologging-for-request-log-and-flow-log/","summary":"DeepFlow AutoLogging 可以自动采集网络流日志，并提供丰富的性能指标和精细至每包的 TCP 时序日志，与应用调用日志结合提供完整的全栈回溯能力。","title":"DeepFlow AutoLogging 介绍：自动采集应用调用日志和流日志"},{"content":"简介 Velero 前身是 Heptio Ark，是由 GO 语言编写的一款用于灾难恢复和迁移工具，可以安全的备份、恢复和迁移 Kubernetes 集群资源和持久卷。\nVelero 主要提供以下能力\n备份 Kubernetes 集群资源，并在资源丢失情况下进行还原 将集群资源迁移到其他集群 将生产集群复制到开发和测试集群 Velero 主要组件\nVelero 组件主要包括服务器端和客户端两部分 服务端：运行在你 Kubernetes 的集群中 客户端：运行在本地的命令行工具，本地环境需要配置好 Kubernetes 集群的 kubeconfig 及 kubectl 客户端工具 Velero 支持备份存储\nAzure BloB 存储 Google Cloud 存储 AWS S3 及兼容 S3 的存储（比如：MinIO） Aliyun OSS 存储 原理 Velero 的基本原理就是将 Kubernetes 集群资源对象数据备份到对象存储中，并能从对象存储中拉取备份数据来恢复集群资源对象数据。不同于 etcd 备份——将集群的全部资源备份起来——Velero 是对 Kubernetes  …","relpermalink":"/blog/introducing-velero/","summary":"本文从 Kubernetes 集群服务资源的备份还原角度，介绍 Velero 的原理和机制。","title":"使用 Velero 备份还原 Kubernetes 集群资源"},{"content":"2022 年 9 月 24 日，由云原生社区主办的第一届 Service Mesh Summit 在上海成功举办，这次峰会汇聚了国内几大服务网格落地企业和提供商，他们带来服务网格在实践以及商业化的经验以及对未来的展望，也吸引了大量线上线下服务网格技术的关注者。\n服务网格问世五年多来，业界对服务网格的应用进展以及发展趋势如何，这篇文章为大家来了本地大会内容的盘点，希望能帮助大家把握服务网格发展方向。\n一句话概括：市场趋于理性，设计更加务实，回归价值，产品百花齐放。\n这里总结了服务网格演进的几大方向：\n扩展性 连通性 性能与资源占用 易用性 从技术选型上来看，有基于流行的 Istio+Envoy 的定制，也有基于其他数据面代理和控制面的新产品出现。\n演进 扩展性 扩展性几乎是所有分享中都会提及的内容，相信也是已经采用的、或者观望中的用户的首要关注点。作为服务于业务的基础设施一部分的服务网格来说，不管是何种技术实现，其核心还是对业务的支撑。而业务和现有架构的多样性为服务网格的采用造成诸多掣肘，导致了服务网格需求的复杂性。作为服务网格明星的 Istio，其社区功能实际上就很难满足用户的实际需 …","relpermalink":"/blog/retrospect-service-mesh-summit/","summary":"一起回顾首届服务网格峰会的内容，了解服务网格的发展趋势。","title":"服务网格峰会回顾：服务网格的发展趋势"},{"content":"Istio最近宣布了“Ambient Mesh” —— 一种用于 Istio 的实验性“无 sidecar”部署模型。我们最近在从服务网格中获得最大性能和弹性的背景下写了关于 sidecar 与 sidecar-less 的文章。在本文中，我们将特别介绍我们对 Ambient Mesh 的看法。\n如果你想立即开始使用可用于生产的 Istio 发行版，请尝试Tetrate Istio Distro (TID)。TID 是经过审查的 Istio 上游发行版，它易于安装、管理和升级，基于适用于 FedRAMP 环境的 FIPS 认证构建。如果你需要一种统一且一致的方式来保护和管理一组应用程序中的服务，请查看Tetrate Service Bridge (TSB)，这是我们基于 Istio 和 Envoy 构建的全面的边缘到工作负载应用程序连接平台。\n什么是 Ambient Mesh？ Ambient Mesh 是最近引入 Istio 的一种实验性新部署模型。它将 Envoy sidecar 当前执行的职责分为两个独立的组件：一个用于加密的节点级组件（称为“ztunnel”）和一个为每个服务账 …","relpermalink":"/blog/what-is-ambient-mesh/","summary":"我们对任何能够使服务网格的采用更加容易的事情都充满热情，但我们还不确定 Ambient Mesh 的部署模型能否能兑现这一承诺。","title":"什么是 Ambient Mesh？"},{"content":"云原生应用安全应该从哪几个方向切入？ 讲师：马景贺\n个人介绍：\n极狐 (GitLab)DevOps 技术布道师，LFAPAC 开源布道师，CDF ambassador。关注在云原生和 DevSecOps 领域。\n议题大纲：\n云原生发展的过程中，安全不应该是成为被忽视的一环。云原生应用程序的安全防护体系建立应该是多方位的，要满足从静态到动态，从源码到上线，同时还要注意镜像以及部署文件的安全。需要将这些手段结合起来，与研发流程打通，构建安全研发闭环，从而保证云原生应用程序的安全。\n听众收益：\n镜像 \u0026amp; IaC 安全扫描 源代码安全审计（防止泄漏） 常规的安全检测手段（SAST、DAST、Fuzzing Testing 等） 漏洞管理 \u0026amp; 安全的研发闭环构建 基于硬件卸载的云原生网关连接平衡实现 讲师：戴翔\n个人介绍：\nIntel 云原生工程师，从事云原生行业多年，深耕开源，Dapr/Thanos/Golangci-lint Maintainer，目前专注于服务网格领域。GH: daixiang0\n议题大纲：\nEnvoy 是为单一服务和应用程序设计的高性能 C++ 分布式代理，也是为大型微服 …","relpermalink":"/event/cloud-native-meetup-guangzhou-09/","summary":"本次活动关注云原生实践。","title":"云原生社区 meetup 第九期广州站"},{"content":"活动日程请见活动行。\n","relpermalink":"/event/service-mesh-summit-2022/","summary":"第一届服务网格峰会。","title":"服务网格峰会 2022"},{"content":"前言 本文首先介绍了 K8s 的访问控制过程，并对 K8s 认证的用户模型进行讲解。最后对认证过程中的用户证书认证以及 Service Account Token 认证进行举例剖析。\nK8s API 请求访问控制的过程 我们知道，不论是通过 kubectl 客户端还是 REST 请求访问 K8s 集群，最终都需要经过 API Server 来进行资源的操作，生效结果会被持久化至 etcd 中，etcd 中的数据安全就变得十分重要。为了保证 etcd 的安全性，K8s 只允许 API Server 去访问操作 etcd，此时 API Server 就担负起了整个 etcd 的安全。那么 K8s 是如何管控和保障 API Server 访问过程的安全的呢？\n如下图 1 所示，整个过程可以分为 4 个阶段\n图 1 K8s API 请求访问过程 整体过程简述：请求发起方进行 K8s API 请求，经过 Authentication（认证）、Authorization（鉴权）、AdmissionControl（准入控制）三个阶段的校验，最后把请求转化为对 K8s 对象的变更操作持久化至 etcd …","relpermalink":"/blog/authentication-k8s/","summary":"本文从边缘设备管理和云边自定义消息传递两个方面，来介绍 KubeEdge 的云边协同机制。","title":"彻底搞懂 Kubernetes 中的认证"},{"content":"1. 问题背景 会话保持是七层负载均衡的核心功能之一。对于同一会话的请求或者连接，通过会话保持机制，负载均衡软件会将其路由到同一个后端，以利用局部性原理来提高服务整体的效率。\n在传统的 LB 产品之中，会话保持能力可以说是重中之重，比如 F5 软件就提供了丰富的会话保持机制供用户选择。而在云原生的场景当中，由于更多面向无状态的服务，服务实例动态启用和销毁，会话保持能力相对而言重要性有所降低。而作为云原生边缘网络代理，Envoy 在会话保持方面自然也相对薄弱。\n在开源 Envoy 当中，只提供了基于一致性哈希的会话保持机制。具体来说，Envoy 提供了一个一致性哈希负载均衡算法进行流量的负载均衡。对于一组后端服务实例，Envoy 会根据服务实例名称或者地址来计算出一个哈希环。之后，对于每一个 HTTP 请求，Envoy 都会根据请求的特征计算一个哈希值，然后根据哈希值在后端哈希环中选择一个最合适的后端实例（通过折半查找）。该会话保持机制不需要保存额外的状态，最终结果只和计算所得的哈希值以及哈希环有关。此外，天然的，该会话保持机制也可以做到跨实例会话保持，也即是当拥有多个 Envoy 实例 …","relpermalink":"/blog/envoy-stateful-session-hold-mechanism-design-and-implementation/","summary":"本文将详解 Envoy 中有状态会话保持机制的设计与实现。","title":"Envoy 有状态会话保持机制设计与实现"},{"content":"我们最近发布了 Istio Ambient Mesh（译者注：笔者更倾向于将其称为 Ambient Mode，即外围模式，但译文中仍然保留了 Ambient Mesh 的叫法），它是 Istio 的无 sidecar 数据平面。如公告博客中所述，我们使用 Ambient Mesh 解决的首要问题是简化操作、更广泛的应用程序兼容性、降低基础设施成本和提高性能。在设计 ambient 数据平面时，我们希望在不牺牲安全性或功能的情况下仔细平衡运维、成本和性能方面的问题。随着 ambient 组件在应用程序 pod 之外运行，安全边界发生了变化 —— 我们相信会变得更好。在这篇博客中，我们将详细介绍这些安全性变化以及它们与 sidecar 部署模式在安全性方面的对比。\nAmbient Mesh 的分层示意图 回顾一下，Istio Ambient Mesh 引入了一个分层网格数据平面，它具有负责传输安全和路由的安全覆盖层，可以选择为需要它们的命名空间添加 L7 功能。要了解更多信息，请参阅公告博客和入门博客。安全覆盖层包括一个节点共享组件 ztunnel，它负责 L4 …","relpermalink":"/blog/ambient-security/","summary":"深入研究最近发布的 Istio Ambient Mesh（Istio 的无 sidecar 数据平面）的安全隐患。","title":"Istio 服务网格 ambient 模式安全详解"},{"content":"今天，我们很高兴地介绍 Ambient Mesh（译者注：笔者更倾向于将其称为 Ambient Mode，即外围模式），这是一种新的 Istio 数据平面模式，旨在简化操作、扩大应用兼容性并降低基础设施成本。用户可以选择将 Ambient Mesh 集成到其基础设施的网格数据平面，放弃 sidecar 代理，同时保持 Istio 的零信任安全、遥测和流量管理等核心功能。我们正在与 Istio 社区分享 Ambient Mesh 的预览版，我们正努力在未来几个月内将其推向生产就绪。\nIstio 和 Sidecar 自项目成立以来，Istio 架构的一个决定性特征是使用 sidecar—— 与应用容器一起部署的可编程代理。利用 sidecar，不需要对应用程序进行重大调整即可以享受服务网格带来的好处，省去运维的负担。\nIstio 的传统模式是将 Envoy 代理作为 sidecar 部署在工作负载的 pod 中。 虽然 sidecar 比起重构应用程序有显著的优势，但它们并没有在应用程序和 Istio 数据平面之间提供一个完美的分离。这导致了一些限制：\n侵入性：sidecar 必须通过修改 …","relpermalink":"/blog/introducing-ambient-mesh/","summary":"Ambient Mesh（外围模式）是一种新的 Istio 数据平面模式，旨在简化操作、扩大应用兼容性并降低基础设施成本。","title":"Istio 无 sidecar 代理数据平面 ambient 模式简介"},{"content":"本文译自 Cloud Native Network Functions Are Here，译者 Jimmy Song。\n主要收获 云原生网络不是另一种方式的 SDN，它以一种完全不同的方式来看待网络。 虽然 SDN 似乎是把物理网络和机器做了虚拟化，但「云原生网络功能」（Cloud-native Network Functions，下文简称 CNF）不仅仅是容器化的网络和虚拟机，它还将网络功能分割成服务，这是 CNF 与 SDN 的一个主要区别。 CNF 是 OSI 网络模型中的网络功能（越底层实现起来就越困难），这些功能是根据云原生实践实现的。 虽然 SDN 数据平面（这里指的是转发数据包）位于硬件 ASIC 上，或在传统内核网络转发的虚拟化盒子里，但 CNF 探索用户平面转发或更新的 eBPF 数据路径转发。 在云原生数据中心中，偏向于三层的解决方案，但 CNF 的一大驱动力是电信服务提供商，他们经常下降到二层的功能。 在三类云资源（计算、存储和网络）中，网络似乎最难满足云原生的非功能性需求。例如，计算弹性可以通过虚拟机、容器和编排器合理分配，并通过 CI/CD 管道进行管理。网络 …","relpermalink":"/blog/cloud-native-network-functions/","summary":"这篇文章中，我们展示了云原生网络功能将网络应用引入云原生世界的一种尝试。究竟什么是 CNF，为什么它们很重要？","title":"云原生网络功能（CNF）介绍"},{"content":"前言 K8s 提供 Aggregated APIServer 的扩展方式，编写 Aggregated APIServer 本质上和 K8s 构建方式类似，理解 APiServer 资源的加载方式，能更好好的理解如何开发Aggregated APIServer。本文以内置资源的 handler 注册过程为线索介绍了 APiServer 的启动过程和 handler 注册过程。使用 k8s 代码 commit id 为 c6970e64528ba78b74bf77b86f9b78b7b61bd0cd\nAPIServer 启动过程介绍 图 1 APIServer 启动流程 图 1 给出了 ApiServer 的初始化流程，首先通过 CreateServerChain 构造出 3 个 APIServer：\nAggregatorServer：拦截 Aggregated APIServer 中定义的资源对象请求，并转发给相关的 Aggregated APIServer 处理。\nKubeAPIServer：用于处理 k8s 的内建资源，如：Deployment，ConfigMap 等。 …","relpermalink":"/blog/apiserver-handler-register/","summary":"APIServer handler 注册过程分析。","title":"Kubernetes API Server handler 注册过程分析"},{"content":"关键要点 零信任通过有选择地只允许访问用户应该被允许访问的特定资源，解决了开放网络访问的问题。 实现持续验证的关键策略是零信任网络访问 (ZTNA)。 实施零信任有助于解决 SOC（安全运营中心）或安全分析师角色中的组织技能短缺问题。 在零信任环境中，开发人员必须全面了解如何保护请求者与应用程序交互的每一步，同时考虑当前的安全上下文。 零信任框架并没有消除在每次部署后持续扫描漏洞的需要，漏洞扫描可以确保应用程序和后端系统保持保护和运作。 什么是零信任模型？ 零信任安全模型是一种设计和实施安全 IT 系统的方法。零信任背后的基本概念是“从不信任，始终验证”。这意味着用户、设备和连接在默认情况下永远不会被信任，即使它们连接到公司网络或之前已经过身份验证。\n现代 IT 环境由许多互连的组件组成，包括本地服务器、基于云的服务、移动设备、边缘位置和物联网 (IoT) 设备。依赖于保护所谓的“网络边界”的传统安全模型在这种复杂的环境中是无效的。\n攻击者可以破坏用户凭据并访问防火墙后面的本地系统。\n他们还可以访问在组织控制之外部署的基于云的或物联网资源。零信任方法在受保护资产周围建立微边 …","relpermalink":"/blog/zero-trust-developer-guide/","summary":"关于零信任，你需要了解这些知识。","title":"开发者需要了解的零信任知识"},{"content":"摘要 微服务引擎（Micro Service Engine 后面简称 MSE）是面向业界主流开源微服务生态的一站式微服务治理平台，兼容 Spring Cloud、Dubbo 微服务框架，提供高可用、免运维的服务注册中心（支持 Eureka/ Nacos/ZooKeeper）、配置中心（支持Apollo）和监控中心（支持Skywalking），实现对微服务的治理和监控。基于云原生环境下，微服务引擎又是如何一种架构？微服务引擎产品中Spring Cloud 及 Dubbo 相关服务治理是如何实现的？Spring Cloud 框架下如何实现参数的动态配置呢？\n前言 在云原生主流发展的环境下，基于需求而来，一种应云而生的微服务引擎架构，显然是脱颖而出，得到业界的普遍关注。服务治理，对于 Srping Cloud 类型的服务和 Dubbo 类型的服务，本文也给出了不同的设计方案。而针对常用的 Srping Cloud 类型的服务，做了详细的服务治理剖析，以及通过具体的案例解析相应的治理过程。\nMSE 部署组网架构实现 MSE 采用 nginx 网关作为流量入口，统一转发路由到各个服务； …","relpermalink":"/blog/microservice-engine-architecture-analysis/","summary":"本文基于一站式微服务治理平台 MSE，进行架构剖析，服务治理原理介绍。","title":"一种微服务引擎架构剖析及服务治理原理介绍"},{"content":"我们要祝贺 Kubernetes SIG Network 社区发布了 Gateway API 规范的 beta 版本。除了这个里程碑，我们很高兴地宣布，对在 Istio ingress 中使用 Gateway API 的支持正在升级为 Beta，并且我们打算让 Gateway API 成为未来所有 Istio 流量管理的默认 API。我们也很高兴地欢迎来自服务网格接口（SMI）社区的朋友，他们将加入我们的行列，使用 Gateway API 标准化服务网格用例。\nIstio 流量管理 API 的历史 API 设计更像是一门艺术而不是一门科学，Istio 经常被用作一个 API 来配置其他 API 的服务！仅在流量路由的情况下，我们必须考虑生产者与消费者、路由与后路由，以及如何使用正确数量的对象来表达复杂的特征集 —— 考虑到这些必须由不同的团队拥有。\n我们在 2017 年推出 Istio 时，我们将 Google 的生产 API 服务基础设施和 IBM 的 Amalgam8 项目的多年经验带到了 Kubernetes 上。我们很快就遇到了 Kubernetes 的 Ingress API …","relpermalink":"/blog/istio-gateway-api-beta/","summary":"Gateway API 将作为 Istio 的标准网关 API 支持。","title":"Istio 扩展对 Gateway API 的支持"},{"content":"背景 随着云原生技术的普及和落地，越来越多的云原生应用需要差异化的配置部署到不同的生产环境中，由于云原生应用通常都是基于云的分布式部署模式，且每个应用可能是由多个功能组件互相调用来一起提供完整的服务的，每个组件都有自己独立的迭代流程和计划，不同的生产环境会呈现差异化的配置。在这种情况下，功能组件越多，意味着应用的发布管理越复杂，如果没有一个好的方案来管理应用的持续交付的话，业务系统将面临巨大的风险。\n在这样的背景下，我们加入到应用持续交付的探索中。GitOps 为管理基础设施和应用程序提供了一种方法，以声明式描述整个系统并进行版本控制，提供了一个自动化的过程来确保部署的环境和存储库中期望的状态相匹配。Flux v2 是一组可支持实现 GitOps 的工具，负责监听配置源（如 Git Repository）的变化，对比当前应用的实际运行状态和期望运行状态的差异，自动拉取变更并同步到集群环境中，Flux v2 为实现云原生应用的持续部署提供了一种方法。本文是关于 Flux v2 在多集群场景下构建应用持续交付的实践。\nFlux v2 架构 Flux v2 是用 GitOps Toolkit …","relpermalink":"/blog/gitops-flux/","summary":"本文将从多集群场景下部署差异化配置的云原生应用出发，介绍基于 Flux v2 的应用持续交付实践。","title":"多集群场景下基于 Flux 的应用持续交付实践"},{"content":" 主要成员/站长 汪守法 合肥站徽章 合肥站徽章 ","relpermalink":"/community/city/hefei/","summary":"云原生社区合肥站。","title":"合肥站"},{"content":"济南站简介 济南站成立于 2020 年 9 月，社区成员已有百人。济南站致力于汇聚济南当地优秀云原生人才，连接云原生开源社区与开发者，促进云原生技术的交流和推广！\n主要成员/站长 伊冲 济南站徽章 济南站徽章 ","relpermalink":"/community/city/jinan/","summary":"云原生社区济南站。","title":"济南站"},{"content":" 主要成员/站长 褚红伟 青岛站徽章 青岛站徽章 ","relpermalink":"/community/city/qingdao/","summary":"云原生社区青岛站。","title":"青岛站"},{"content":" 主要成员/站长 梁桂钊 厦门站徽章 厦门站徽章 ","relpermalink":"/community/city/xiamen/","summary":"云原生社区厦门站。","title":"厦门站"},{"content":" 主要成员/站长 乔宇辰 苏州站徽章 苏州站徽章 ","relpermalink":"/community/city/suzhou/","summary":"云原生社区苏州站。","title":"苏州站"},{"content":" 主要成员/站长 徐炳尘 无锡站徽章 无锡站徽章 ","relpermalink":"/community/city/wuxi/","summary":"云原生社区无锡站。","title":"无锡站"},{"content":" 主要成员/站长 徐龙 王红阳 武汉站徽章 武汉站徽章 ","relpermalink":"/community/city/wuhan/","summary":"云原生社区武汉站。","title":"武汉站"},{"content":" 主要成员/站长 杨博源 西安站徽章 西安站徽章 ","relpermalink":"/community/city/xian/","summary":"云原生社区西安站。","title":"西安站"},{"content":" 主要成员/站长 赵波 长沙站徽章 长沙站徽章 ","relpermalink":"/community/city/changsha/","summary":"云原生社区长沙站。","title":"长沙站"},{"content":" 主要成员/站长 杨启周 郑州站徽章 郑州站徽章 ","relpermalink":"/community/city/zhengzhou/","summary":"云原生社区郑州站。","title":"郑州站"},{"content":" 主要成员/站长 唐毅 黄浩 重庆站徽章 重庆站徽章 ","relpermalink":"/community/city/chongqing/","summary":"云原生社区重庆站。","title":"重庆站"},{"content":" 主要成员/站长 柯栋 珠海站徽章 珠海站徽章 ","relpermalink":"/community/city/zhuhai/","summary":"云原生社区珠海站。","title":"珠海站"},{"content":"KubeEdge 介绍 KubeEdge 是一个致力于解决边缘场景问题的开源系统，在 Kubernetes 原生的容器编排和调度能力之上，实现了云边协同、计算下沉、海量边缘设备管理、边缘自治等能力。KubeEdge 架构如下图所示，包括云端和边缘端两部分。\nKubeEdge 架构图 ​\n其中：\nCloudHub：WebSocket 服务器，负责监控云端的变化、缓存并发送消息到 EdgeHub。\nEdgeController：扩展的 Kubernetes 控制器：负责管理边缘节点和 pods 的元数据，因此数据才能被发送到指定的边缘节点。\nDeviceController：扩展的 Kubernetes 控制器，负责管理边缘设备，实现边缘设备元数据/状态数据在云端与边缘端的同步。\nEdgeHub：WebSocket 客户端，负责与云边服务交互实现边缘计算。其中包括将云边资源同步更新到边缘端以及将边端主机、设备状态变化广播至云端。\nEdged：负责 pod 生命周期的管理，可以看成一个简易版的 kubelet。\nEventBus：EventBus 是一个 MQTT 客户端负责与 MQTT 服 …","relpermalink":"/blog/cloud-edge-collaboration-mechanism/","summary":"本文从边缘设备管理和云边自定义消息传递两个方面，来介绍 KubeEdge 的云边协同机制。","title":"边缘计算平台 KubeEdge 云边协同机制解析"},{"content":"前言 外部存储接入 Kubernetes 的方式主要有两种：In-Tree 和 Out-of-Tree。其中 In-Tree 是指存储驱动的源码都在 Kubernetes 代码库中，与 Kubernetes 一起发布、迭代、管理，这种方式灵活性较差，且门槛较高。Out-of-Tree 是指存储插件由第三方编写、发布、管理，作为一种扩展与 Kubernetes 配合使用。Out-of-Tree 主要有 FlexVolume 和 CSI 两种实现方式，其中，FlexVolume 因为其命令式的特点，不易维护和管理，从 Kubernetes v1.23 版本开始已被弃用。因此 CSI 已经成为 Kubernetes 存储扩展（Out-of-Tree）的唯一方式。\nCSI 组成 csi-architecture 参考上图（图片出处），通常情况下：CSI Driver = DaemonSet + Deployment(StatefuleSet)。\n其中：\n绿色部分：Identity、Node、Controller 是需要开发者自己实现的，被称为 Custom Components。 粉色部 …","relpermalink":"/blog/develop-a-csi-driver/","summary":"本文将介绍 Kubernetes 中的 CSI 驱动如何开发。","title":"CSI 驱动开发指南"},{"content":"背景介绍 Apache SkyWalking 观察部署在服务网格中的服务的度量、日志、追踪和事件。在进行故障排除时，SkyWalking 错误分析是一个宝贵的工具，可以帮助确定错误发生的位置。然而，确定性能问题更加困难：利用预先存在的观察数据往往不可能找到性能问题的根本原因。为此，动态调试和故障排除在进行服务性能剖析时就必不可少。在这篇文章中，我们将讨论如何使用 eBPF 技术来改进 SkyWalking 中的剖析功能，并用于分析服务网格中的性能影响。\nSkyWalking 中的追踪剖析 自 SkyWalking 7.0.0 以来，Trace Profiling 通过定期对线程堆栈进行采样，让开发者知道运行哪行代码花费更多时间，从而帮助开发者发现性能问题。然而，Trace Profiling 不适合以下情况：\n线程模型：Trace Profiling 对于剖析在单线程中执行的代码最有用。它对严重依赖异步执行模式的中间件不太有用。例如，Go 中的 Goroutines 或 Kotlin Coroutines。 语言：目前，Trace Profiling 只支持 Java …","relpermalink":"/blog/pinpoint-service-mesh-critical-performance-impact-by-using-ebpf/","summary":"在这篇文章中，我们将讨论如何使用 eBPF 技术来改进 SkyWalking 中的剖析功能，并用于分析服务网格中的性能影响。","title":"使用 eBPF 准确定位服务网格的关键性能问题"},{"content":"编者的话 本文是来自 Tetrate 工程师的分享，Tetrate 的拳头产品是 Tetrate Service Bridge（下文简称 TSB），它是在开源的 Istio 和 Envoy 基础上构建的，但为其增加了管理平面。\n简介 Tetrate 的应用连接平台 Tetrate Service Bridge（TSB）提供两种网关类型，分别为一级网关（Tier-1）和二级网关（Tier-2），它们都基于 Envoy 构建，但是目的有所不同。本文将探讨这两种类型网关的功能，以及何时选用哪种网关。\n关于两级网关的简要介绍：\n一级网关（下文简称 T1）位于应用边缘，用于多集群环境。同一应用会同时托管在不同的集群上，T1 网关将对该应用的请求流量在这些集群之间路由。 二级网关（下文简称 T2）位于一个的集群边缘，用于将流量路由到该集群内由服务网格管理的服务。 两级网关释义 托管在 TSB 管理的集群中的应用部署的设计与开源的 Istio 模型非常相似。它们的结构相同，使用入口网关来路由传入的流量。T2 网关相当于 Istio 的入口网关（Ingress Gateway），在逻辑上与 Istio …","relpermalink":"/blog/designing-traffic-flow-via-tier1-and-tier2-ingress-gateways/","summary":"在 Kubernetes 中我们不能仅依靠网络层加密，还需要 mTLS 来对客户端和服务端进行双向的传输层认证。本文将聚焦于 TLS 的真实性，以及证书管理的难题，说明服务网格对于在 Kubernetes 中开启 mTLS 带来的便利。","title":"通过两级网关设计来路由服务网格流量"},{"content":"背景 在生产环境使用 Istio 的时候，可能最需要考虑的问题一个是安全问题一个是性能问题，在这里和大家一起探讨下一个安全问题，如何在 Istio 网格中访问外部服务。Istio 提供了两种模式来配置对外部请求的访问策略，并通过配置项 outboundTrafficPolicy.mode 来指定。 默认的模式是 ALLOW_ANY，也就是允许在网格内请求所有外部的未知服务；另外一个模式是 REGISTRY_ONLY，表示只允许请求注册到服务网格注册表中的服务。默认的 ALLOW_ANY 模式虽然使用方便，但是存在一定的安全隐患，建议的做法是切换到 REGISTRY_ONLY 模式。那么在 REGISTRY_ONLY 模式下如何访问外部服务？实现机制是什么呢？在这里针对这两个问题和大家一起探讨下。\n方案调研 目前我们安装部署 Istio 使用的是 helm，可以在安装中添加相应的配置 --set meshConfig.outboundTrafficPolicy.mode=REGISTRY_ONLY 修改 outboundTrafficPolicy.mode 的值；如果 Istio 已经安 …","relpermalink":"/blog/istio-access-external-services/","summary":"作者在本文将和大家一起探讨下 Istio 访问外部服务的两种方法，介绍 Istio 访问外部服务的原理。","title":"Istio 网格中访问外部服务方法"},{"content":"前言 可观测性一词诞生于几十年前的控制理论，指系统可以由其外部输出推断其内部状态的程度。近年来，随着微服务、容器化、serverless 等多种技术架构的出现，应用的构建部署与实施运行都发生了巨大转变，服务链路错综复杂、微服务与分布式趋势增强、环境容器化等一系列变化促使可观测性在云原生体系中占据着重要的作用。通常，可观测性分为 Metrics (指标)、Tracing (追踪)、Logging (日志) 三部分。\nLogging 是在特定时间发生的事件的文本记录，包括说明事件发生时间的时间戳和提供上下⽂的有效负载。Metrics 是通过数据的聚合，对特定时间内的行为进行衡量，指标数据是可累加的，可以观察系统的状态和趋势。Tracing 面向请求，表示请求通过分布式系统的端到端的调用旅程，可以分析出请求中的异常点或故障的原因。\nIstio 为网格内所有的服务通信生成详细的遥测数据。这种遥测技术让 Isito 提供了服务行为的可观察性，使运维人员能够排查故障、维护和优化应用程序，而不会给服务的开发人员带来任何额外的负担。在 Istio1.7 版本之前，安装 Istio 时也会默认安装可观测 …","relpermalink":"/blog/istio-observability/","summary":"作者在本文将和大家一起探讨下 Istio 的路由管理，介绍使用 Istio 灰度发布的过程中，有哪些需要注意的地方。","title":"浅析 Istio——可观测性"},{"content":"编者的话 本文翻译节选自 A Kubernetes engineer’s guide to mTLS，为了便于读者理解，笔者对原文做了一点修改 1。因为笔者最近在研究 Istio 中的身份认证及 SPIFFE，对如何在 Kubernetes 中应用 mTLS 以及为什么要使用 mTLS 产生了浓厚的兴趣，再回想起五年前手动安装 Kubernetes 时，因为给集群开启 TLS 问题而导致安装停滞不前。\n本文的主要观点是：在 Kubernetes 中我们不能仅依靠网络层加密，还需要 mTLS 来对客户端和服务端进行双向的传输层认证。本文将聚焦于 TLS 的真实性，以及证书管理的难题，说明服务网格对于在 Kubernetes 中开启 mTLS 带来的便利。\n简介 Mutual TLS（双向 TLS），或称 mTLS，是 Kubernetes 中的一个热门话题，尤其是对于那些负责为应用程序提供传输层加密的人来说。但是，你有没有考虑过，什么是 mTLS，它提供什么样的安全，为什么需要 mTLS？\n本指南我将介绍什么是 mTLS，它与常规 TLS 的关系，以及为什么它与 Kubernetes 有 …","relpermalink":"/blog/mtls-guide/","summary":"在 Kubernetes 中我们不能仅依靠网络层加密，还需要 mTLS 来对客户端和服务端进行双向的传输层认证。本文将聚焦于 TLS 的真实性，以及证书管理的难题，说明服务网格对于在 Kubernetes 中开启 mTLS 带来的便利。","title":"写给 Kubernetes 工程师的 mTLS 指南"},{"content":"前言 在浅析 Istio 系列的上篇文章中，我们介绍了 Istio 的流量路由管理相关内容，并基于此实践了灰度发布相关技术。本篇文章，我们继续扩展探讨 Istio 服务治理的相关技术和原理。\n服务治理概念 应用从单体架构向微服务架构演进的过程中，由于细粒度的微服务应用数量大幅增长，微服务之间的服务发现、负载均衡、熔断限流等服务治理需求显著提高。\n在微服务场景下，每个服务有多个服务实例，需要一种机制将请求的服务名解析到服务实例地址上，这就需要服务发现和负载均衡机制。负载均衡一般和服务发现配合使用，服务发现负责从服务名中解析一组服务实例的列表，负载均衡负责从中选择一个实例发起请求。\n传统架构下负载均衡一般由服务端提供的，比如访问一个 Web 网站时，一般在网站入口处有一个负载均衡器来做请求的汇聚和转发（也称作反向代理）。服务的虚拟 IP 和后端实例映射通过配置文件维护，负载均衡器通过健康检查保证客户端的请求被路由到健康的服务实例。\nconcept-1 微服务架构下，服务发现和负载均衡相关功能包含以下工作流程： 服务注册：各服务将服务名和服务实例的对应信息注册到服务注册中心。 服务发现：发起 …","relpermalink":"/blog/istio-traffic-management-series-service-management-concept-theory/","summary":"作者在本文将和大家一起探讨下 Istio 的服务治理，介绍服务治理相关概念和实现原理。","title":"浅析 Istio——服务治理之概念和原理"},{"content":"编者的话 Istio 1.14 版本增加了对 SPIRE 集成的支持，这篇文章将指导你如何在 Istio 中集成 SPIRE。\nSPIRE 是 SPIFFE 规范的一个生产就绪的实现，它可以执行节点和工作负载证明，以便安全地将加密身份发给在异构环境中运行的工作负载。通过与 Envoy 的 SDS API 集成，SPIRE 可以被配置为 Istio 工作负载的加密身份来源。Istio 可以检测到一个 UNIX 域套接字的存在，该套接字在定义的套接字路径上实现了 Envoy SDS API，允许 Envoy 直接从它那里进行通信和获取身份。\n这种与 SPIRE 的集成提供了灵活的认证选项，这是默认的 Istio 身份管理所不具备的，同时利用了 Istio 强大的服务管理。例如，SPIRE 的插件架构能够提供多样化的工作负载认证选项，超越 Istio 提供的 Kubernetes 命名空间和服务账户认证。SPIRE 的节点认证将认证扩展到工作负载运行的物理或虚拟硬件上。\n关于这种 SPIRE 与 Istio 集成的快速演示，请参阅通过 Envoy 的 SDS API 将 SPIRE …","relpermalink":"/blog/istio-spire-integration/","summary":"Istio 1.14 版本增加了对 SPIRE 集成的支持，这篇文章将指导你如何在 Istio 中集成 SPIRE。","title":"如何在 Istio 中集成 SPIRE"},{"content":"端午节前夕，Istio 1.14 发布。\n这是 2022 年的第二个 Istio 版本。我们要感谢整个 Istio 社区对 Istio 1.14.0 发布的帮助。特别感谢发布经理 Lei Tang（谷歌）和 Greg Hanson（Solo.io），以及测试和发布工作组负责人 Eric Van Norman（IBM）的持续帮助和指导。\nIstio 1.14.0 正式支持 Kubernetes 1.21 至 1.24 版本。\n以下是该版本的一些亮点。\n对 SPIRE 运行时的支持 SPIRE 是 SPIFFE 规范的一个生产就绪的实现，它提供可插拔的多因子验证和 SPIFFE 联邦。我们使用 Envoy SDS API 对与外部证书颁发机构的集成方式进行了修改，以实现对 SPIRE 的支持。感谢惠普企业的团队对这项工作的贡献！SPIRE 通过使用不同的认证机制的组合，实现了强认证身份的引入。它为在 Kubernetes、AWS、GCP、Azure、Docker 中运行的工作负载提供了各种节点和工作负载证明，并通过面向插件的架构，它还可以使用自定义证明。该项目与定制的密钥管理系统有一个可插 …","relpermalink":"/blog/istio-1-14-release/","summary":"这是 Istio 在 2022 年发布的第二个版本。","title":"Istio 1.14 发布"},{"content":"前言 OpenTelemetry 追踪包含了理解分布式系统和排除故障的信息宝库 —— 但你的服务必须首先被指标化，以发射 OpenTelemetry 追踪来实现这一价值。然后，这些追踪信息需要被发送到一个可观察的后端，使你能够获得关于这些数据的任意问题的答案。可观测性是一个分析问题。\n本周早些时候，我们部分解决了这个问题，宣布在 Promscale 中普遍提供 OpenTelemetry 追踪支持，将由 SQL 驱动的可观测性带给所有开发者。随着对分析语言 ——SQL 的全面支持，我们解决了分析的问题。但我们仍然需要解决第一部分的问题：测量。\n为了让你的服务发出追踪数据，你必须手动添加 OpenTelemetry 测量工具到代码中。而且你必须针对所有服务和你使用的所有框架来做，否则你将无法看到每个请求的执行情况。你还需要部署 OpenTelemetry 收集器来接收所有新的追踪，处理它们，批处理它们，并最终将它们发送到你的可观测性后端。这需要花费大量的时间和精力。\n如果你不需要做所有这些手工工作，并且可以在几分钟内而不是几小时甚至几天内启动和运行呢？如果你还能建立一个完整的可观测性技术 …","relpermalink":"/blog/generate-and-store-opentelemetry-traces-automatically/","summary":"首先，我们将解释一下如何在 Kubernetes 自动生成和存储 OpenTelemetry 追踪，剖析 OpenTelemetry Operator 在内部的真正作用。接下来，我们将通过一个例子演示如何将其直接付诸实践。","title":"一键开启 Kubernetes 可观测性——如何自动生成和存储 OpenTelemetry 追踪"},{"content":"背景 我们团队对 Istio 进行相关研究与探索，并在生产环境进行了相应的应用，初期我们使用 Istio 主要做产品的灰度发布，同时我们团队也有相关研发人员基于 Istio，进行生产环境业务流量管理及可观测性追踪的研究。在做 Istio 灰度发布的实践中，遇到的第一个问题就是怎么在已经大规模部署产品的 Kubernetes 集群里，选择性的注入 Sidecar。下面详细的介绍下我们遇到的问题以及解决思路，供大家参考。\n遇到的问题 我们知道如果想把一个服务纳入 Istio 的网格中，需要在 pod 中注入 Sidecar 进行流量的劫持处理，通用的做法就是在 namespace 上打上 istio-injection=enabled 标签，这样只要在此 namespace 下创建或重启 pod 都会导致 pod 被注入 Sidecar，当然为了不让指定 pod 注入 Sidecar，可以在 pod 的 annotations 里加上 sidecar.istio.io/inject: \u0026#34;false\u0026#34;。线上产品是以 namespace 进行隔离的，并且产品 namespace …","relpermalink":"/blog/istio-sidecar-injection-method/","summary":"作者在本文将和大家一起探讨下 Istio 在满足什么条件的时候进行 Sidecar 的注入，介绍使用 Istio 进行 Sidecar 注入时的一些配置及生产应用","title":"一种灵活注入 Istio Sidecar 的方案探索"},{"content":"经常会有人问“当你们说可编程代理的时候，那么什么是可编程代理，为什么需要可编程代理”？本文从不同角度回答这个问题。首先会简单地介绍代理；然后讨论下代理在发展过程中的阶段划分；基于这些阶段的划分，讨论每一个阶段相比于上一个阶段的改进之处，以及为什么需要这些改进，同时我们讨论下“可编程”所包含的几个层面；最后我们总结下“为什么需要可编程代理”。\n什么是代理及代理的功能 代理是代理服务器的简称，代理服务器通常部署在两个互相隔离的网络的中间处，既能访问一侧网络也能访问另一侧网络，通过把一侧的数据搬运到另一侧，实现了网络的连通。代理是一种串路网络设备，自从计算机网络诞生，代理就存在了。由于代理是串路的，因此代理在实现网络连通功能的同时也衍生出新的功能和使用场景：\n路由：代理在转发数据的时候，根据数据的特征，转发到不同的目的地 负载均衡：在转发过程中，通过把数据分发到不同的目的地，提高吞吐量、避免目的地单点故障。负载均衡逐渐成为代理细分功能的一个领域 故障迁移：在转发过程中，当目的地出现故障时候，代理可以把数据转发到备用的目标，对请求方提供不间断的服务 访问控制：代理可以决定某些流量可以通过，哪些 …","relpermalink":"/blog/what-and-why-programmable-proxy/","summary":"经常会有人问“当你们说可编程代理的时候，那么什么是可编程代理，为什么需要可编程代理”？本文从不同角度回答这个问题。","title":"为什么需要可编程代理"},{"content":"主要收获 对于现代软件系统来说，可观测性不是关于数学方程。它是关于人类如何与复杂的系统互动并试图理解它们。\n混沌工程利用了可观测性，因为它可以检测到系统稳定状态的偏差。混沌工程借助可观测性可以发现和克服系统的弱点。\n可观测性依赖于系统所发出的信号，这些信号提供了关于系统行为的原始数据。然而，可观测性不仅受限于这些信号的质量，还受限于这些信号的可视化和解释的方式。\n考虑到混沌工程、可观测性和可视化涉及到人类自我的解释，仪表盘的设计者可能会对这些解释产生偏差，这是一个事实。在这个意义上，视觉隐喻并不能保证我们以正确的方式解释这些数据。\n基于视觉隐喻的仪表盘可以提供比经典的可视化更有用的数据。然而，这两种策略都很容易产生偏差；例如，在一项研究中，大多数参与者都注意到，由于显示了糟糕的柱状图和线状图，没有在图中显示出重要的分界点，因此整体结果是有偏差的。\n自从 Netflix、Slack 和 Linkedin 等领先的技术公司采用混沌工程来抵御生产中的意外中断后，这门学科在近来已经成为主流。在这条道路上，可观测性发挥了关键作用，为工程师们带来了数据和监控的力量，他们现在有了了解自己系统的策略， …","relpermalink":"/blog/chaos-engineering-observability-visual-metaphors/","summary":"本文为可观测性引入了一个新的角色：视觉隐喻，并进行了一项研究，对比了视觉隐喻与传统表示的结果。","title":"混沌工程和视觉隐喻的可观测性"},{"content":"前言 本文将和大家一起探讨下 Istio 的路由管理，介绍使用 Istio 灰度发布的过程中，有哪些需要注意的地方。\n流量治理用于控制服务之间的流量和接口调用。Istio 可以通过服务级别的配置，实现蓝绿发布、灰度发布以及百分比流量策略发布等，Istio 还可以实现诸如故障注入、熔断限流、超时重试等流量治理功能。那么 Istio 如何具有如此强大的功能，它的路由管理是如何实现的，生产中使用 Istio 需要注意的要点有哪些呢？\nIstio 为什么可以实现流量治理 Istio 中路由策略的转发处理都是通过 Envoy 实现，Envoy 作为 Sidecar 和每个服务容器部署在同一个 pod 中，Sidecar 在注入到 pod 之后，将原有服务调用从源容器 -\u0026gt; 目标容器的通信方式改变为源容器 -\u0026gt; Sidecar (源端) -\u0026gt; Sidecar (目的端) -\u0026gt; 目的容器，只要我们配置了正确的流量策略，通过 pilot 与 Envoy 之间建立的长连接，Envoy 可以实时获取最新的网络路由策略，这样 Envoy 接管了流入流出用户服务的流量，持有流量策略。并且 Istio 会自动探 …","relpermalink":"/blog/istio-traffic-management-series-route-management/","summary":"作者在本文将和大家一起探讨下 Istio 的路由管理，介绍使用 Istio 灰度发布的过程中，有哪些需要注意的地方。","title":"浅析 Istio——流量治理之路由管理"},{"content":"前言 今天，Envoy 社区宣布了一个令人兴奋的新项目：Envoy Gateway。该项目将行业领导者联合起来，精简由 Envoy 驱动的应用网关的好处。这种方法使 Envoy Gateway 能够立即为快速创新打下坚实的基础。该项目将提供一套服务来管理 Envoy 代理机群，通过易用性来推动采用，并通过定义明确的扩展机制来支持众多的用例。\n我们为什么要这样做？ Tetrate 是 Envoy Proxy 的第一贡献者（按提交量计算），也是 Envoy Gateway 指导小组的成员，其贡献者涵盖技术和管理领域。我们相信，我们强大的伙伴关系和在开源软件方面的深厚经验将有助于确保 Envoy Gateway 的成功。Tetrate 推动了 EG 计划，因为我们致力于上游项目，因为我们相信这将降低 Envoy Proxy 用户的进入门槛，也因为这与我们开发服务网格作为零信任架构基础的使命相一致。Tetrate 将大力投资建设 Envoy Gateway 的安全功能，包括支持 OAuth2 和 Let’s Encrypt 集成等 API 功能。\n对上游项目的承诺 Tetrate 从第一天起就 …","relpermalink":"/blog/the-gateway-to-a-new-frontier/","summary":"在我们看来，由于 Envoy 的设计、功能设置、安装基础和社区，它是业内最好的 API 网关。有了 Envoy Gateway，企业可以在将 Envoy 嵌入其 API 管理策略方面增加信心。","title":"Envoy API Gateway——推动网关的进一步发展"},{"content":"前言 今天，我们很高兴地宣布 Envoy Gateway 成为 Envoy 代理家族的新成员，该项目旨在大幅降低将 Envoy 作为 API 网关的使用门槛。\n历史 Envoy 在 2016 年秋天开源，令我们惊讶的是，它很快就引领了整个行业。用户被这个项目的许多不同方面所吸引，包括它的包容性社区、可扩展性、API 驱动的配置模型、强大的可观测性输出和越来越广泛的功能集。\n尽管在其早期历史中，Envoy 成为了服务网格的代名词，但它在 Lyft 的首次使用实际上是作为 API 网关 / 边缘代理，提供深入的可观测性输出，帮助 Lyft 从单体架构迁移到微服务架构。\n在过去的 5 年多时间里，我们看到 Envoy 被大量的终端用户采用，既可以作为 API 网关，也可以作为服务网格中的 sidecar 代理。同时，我们看到围绕 Envoy 出现了一个庞大的供应商生态系统，在开源和专有领域提供了大量的解决方案。Envoy 的供应商生态系统对项目的成功至关重要；如果没有对所有在 Envoy 上兼职或全职工作的员工的资助，这个项目肯定不会有今天的成就。\nEnvoy 作为许多不同的架构类型和供应商 …","relpermalink":"/blog/introducing-envoy-gateway/","summary":"今天，我们很高兴地宣布 Envoy Gateway 成为 Envoy 代理家族的新成员，该项目旨在大幅降低将 Envoy 作为 API 网关的使用门槛。","title":"开源项目 Envoy Gateway 简介"},{"content":"什么是 Wasm 插件？ 你可以使用 Wasm 插件在数据路径上添加自定义代码，轻松地扩展服务网格的功能。可以用你选择的语言编写插件。目前，有 AssemblyScript（TypeScript-ish）、C++、Rust、Zig 和 Go 语言的 Proxy-Wasm SDK。\n在这篇博文中，我们描述了如何使用 Wasm 插件来验证一个请求的有效载荷。这是 Wasm 与 Istio 的一个重要用例，也是你可以使用 Wasm 扩展 Istio 的许多方法的一个例子。您可能有兴趣阅读我们关于在 Istio 中使用 Wasm 的博文，并观看我们关于在 Istio 和 Envoy 中使用 Wasm 的免费研讨会的录音。\n何时使用 Wasm 插件？ 当你需要添加 Envoy 或 Istio 不支持的自定义功能时，你应该使用 Wasm 插件。使用 Wasm 插件来添加自定义验证、认证、日志或管理配额。\n在这个例子中，我们将构建和运行一个 Wasm 插件，验证请求 body 是 JSON，并包含两个必要的键 ——id 和 token。\n编写 Wasm 插件 这个示例使用 tinygo …","relpermalink":"/blog/validating-a-request-payload-with-wasm/","summary":"本文是一个开发 Wasm 插件验证请求负载的教程。","title":"使用 WebAssembly 验证请求负载"},{"content":"本文译自 Migrating Millions of Concurrent Websockets to Envoy，原文发布于 2021 年。作者是 Ariane van der Steldt Staff Software Engineer, Site Reliability，Radha Kumari Sr. Software Engineer, Site Reliability。\nSlack 有一个全球客户群，在高峰期有数百万同时连接的用户。用户之间的大部分通信涉及到向对方发送大量的微小信息。在 Slack 的大部分历史中，我们一直使用 HAProxy 作为所有传入流量的负载均衡器。今天，我们将讨论我们在使用 HAProxy 时所面临的问题，我们如何用 Envoy Proxy 来解决这些问题，迁移所涉及的步骤，以及结果是什么。让我们开始吧！\nSlack 的 Websockets 为了即时传递信息，我们使用 websocket 连接，这是一种双向的通信链接，负责让你看到 “有几个人在打字……\u0026#34;，然后是他们打的东西，速度几乎是光速的。websocket …","relpermalink":"/blog/migrating-millions-of-concurrent-websockets-to-envoy/","summary":"本文是 Slack 花半年时间从 HAProxy 迁移到 Envoy 上的经验分享。","title":"Slack 将数百万个并发的 Websockets 迁移到 Envoy 上经验分享"},{"content":"我是 Vrun Talwar，Tetrate 公司的联合创始人。我们是一家企业级服务网格公司。我要谈的是弹性，更准确地说，是运行时的弹性，是内置于你的网络中的东西。我喜欢从历史上的一个技术话题开始谈起。Cloud 1.0 是云的第一个时代。当时我们看到了虚拟化的浪潮，人们基本上从他们的硬件中获得更多。在我们进入当前的云时代之前，这已经持续了好几年，也就是 Cloud 2.0 时代，这基本上是从别人那里获得计算资源。你不需要在数据中心运行机器，别人为你更有效地运行它们。你刷一下信用卡，就可以得到他们管理的资源。这对配置灵活性和在我们想要的任何地方提供计算有很大的帮助。实际上，下一阶段就是 Cloud 3.0，这是一个更加动态和分布式的计算。从容器和自动伸缩的意义上讲，动态的，通过 Kubernetes 这样的协调器进行调度。分布式是指不同的区域：私有云、公有云、混合云等等。以及在应用组件分布的意义上的分布式。在一个计算如此动态的世界里，我们的网络和安全堆栈是滞后的。这些都是需要迎头赶上的。\nCloud 3.0 转型 —— 网络的创新 在创办 Tetrate 之前，我曾有机会在谷歌工作了大 …","relpermalink":"/blog/resiliency-app-aware-network/","summary":"本文是作者在 Qcon 上的分享，主要谈及服务网格及其引申出来的应用感知网络。","title":"利用服务网格和智能应用感知网络增强应用弹性"},{"content":"本文译自 7 Ways to Fail at Microservices，作者总结了她见过的导致微服务落地失败的一些情况，并提出了 7 个重要的关注点以引导大家来尽量避免。译者是在工作闲暇时间完成的翻译，其中难免有不当之处，请读者指正。\n本文主要观点：\n微服务是一种手段，而不是目标 分布式并不能保证解耦性 合约测试（Contract Testing）是任何微服务架构的重要组成部分 分解（Decomposition）需要发生在前端、后端和集成层，以及业务逻辑中 如果企业没有能力快速、独立地发布微服务，那么微服务的许多好处就会丧失 我（Holly Cummins）是 IBM 的一名 技术顾问，我的一部分工作是帮助企业实现云原生。在去年 11 月的 QCon Plus 上，我介绍了 一些不正确的微服务使用方式。这些问题是基于我的经验来整理的，它们是我在客户现场反复看到的一些问题。\n我看到的第一个问题是，我们有时甚至不知道问题出在哪里。人们觉得我们应该做 微服务，但我们并没有真正花足够的时间来定义我们为什么要做微服务。\n我们要解决的是什么问题？现在是什么问题在困扰我们？我们做了微服务之后，什么 …","relpermalink":"/blog/7-ways-to-fail-at-microservices/","summary":"作者总结了她经历的一些导致微服务落地失败的情况，并提出了 7 个重要的关注点以引导大家来尽量避免。","title":"避免在微服务上失败的 7 个关注点"},{"content":"WasmPlugin API 最近被添加到 Istio 项目中，作为一种新改进的可扩展性机制。在 Tetrate，我们最近成功举办了一个名为 Istio Wasm workshop 的研讨会。点击这里观看研讨会的录音，并加入 Slack 上的对话。\n我们谈论了 WebAssembly 及其在 Istio 和 Envoy 项目中的重要性，并通过使用 Proxy-Wasm Go SDK 和 func-e 进行了多个演示。\n我们在 Tetrate 关注 Istio 的可扩展性已经有很长一段时间了。Tetrate 的工程师 Takeshi Yoneda 和周礼赞在为此做出了巨大的贡献，我们非常高兴地看到 Istio 的可扩展性因此而得到了极大的改善。\n在这篇博文中，我描述了在引入 WasmPlugin API 之前 Istio 和 Envoy 可扩展性的状况；目前大为改善的情况；以及将或多或少完成这条可扩展性改进弧线的变化，我们预计这些变化将在即将到来的版本中出现。\nIstio 和 Wasm 的历史 Istio 1.4 之前 Istio 1.5 Istio 1.12 和未来 用 C++ 扩展维 …","relpermalink":"/blog/importance-of-wasm-in-istio/","summary":"本文回顾了 Istio 和 Envoy 中引入 Wasm 的历史并介绍了其重要性。","title":"在 Istio 中引入 Wasm 意味着什么？"},{"content":"作者简介：王凯，网易数帆高级工程师，主要负责轻舟微服务、轻舟 API 网关等相关产品数据面研发、扩展增强等工作。对于数据面 Envoy 扩展增强、实践落地具备丰富的经验。\n可扩展性是网络代理软件最为关键的特性之一，灵活强大的可扩展性可以大大拓展网络代理软件的能力边界。作为新兴的开源高性能网络代理软件，Envoy 本身提供了相对丰富的可扩展能力，如基于 C++ 的原生扩展，基于 WASM/Lua 的动态扩展。但是 Envoy 现有可扩展能力都各自存在其局限性。在大规模落地实践 Envoy 网关/网格过程中，网易数帆为 Envoy 实现了一套基于 Lua 的企业级自定义扩展框架-Rider，应用于轻舟微服务平台，满足业务方所需要的易开发、高性能、功能丰富等各项要求。 目前，Rider 扩展框架已经全面开源，并且被集成于开源 API 网关 Hango 当中，为 Hango 网关提供了灵活、强大、易用的自定义扩展能力。\n1. Envoy 的可扩展性现状 在互联网体系下，凡是需要对外暴露的系统几乎都需要网络代理：较早出现的 HAProxy、Nginx 至今仍在流行；进入微服务时代后，功能更丰富、 …","relpermalink":"/blog/hango-rider/","summary":"目前，Rider 扩展框架已经全面开源，并且被集成于开源 API 网关 Hango 当中，为 Hango 网关提供了灵活、强大、易用的自定义扩展能力。","title":"网易开源 Envoy 企业级自定义扩展框架 Hango Rider 简介"},{"content":"编者按 本文译自 How To Add eBPF Observability To Your Product，原文发布于 2021 年 7 月 3 日。本文作者 Brendan Gregg 是 eBPF 领域的专家，出版过多本相关书籍，本文是他给想要在产品中引入 eBPF 增加可观察性人员的忠告。\n正文 现在有一场军备竞赛，即增加 eBPF 的军备竞赛，在这篇文章中，我将介绍如何快速做到这一点。这也适用于人们将其添加到自己的内部监测系统中。\n人们喜欢在他们建立了原型或构建了产品之后向我展示他们的 BPF 可观察性产品，但我常常在他们开始之前给出建议。作为 BPF 可观察性的领导者，这是我在最近的谈话中一直包含的建议，现在我把它纳入这篇文章中。\n首先，我知道你很忙。你甚至可能不喜欢 BPF。为了务实起见，我将描述如何花最少的精力来获得最大的价值。把这看成是“第一版”。一个相当有用的出发点。无论你是否遵循这个建议，至少请你理解它，以避免以后的遗憾和痛苦。\n如果你正在使用开源监控平台，首先检查它是否已经有一个 BPF 代理。这篇文章假设它没有，而且你将首次添加一些东西。\n1. …","relpermalink":"/blog/how-to-add-bpf-observability/","summary":"本文是给想要在产品中引入 eBPF 增加可观察性人员的忠告。","title":"如何在产品中引入 eBPF 以增加可观察性"},{"content":"GitOps 是一种方法，通过声明式清单来管理 Kubernetes 集群，以强制执行自我修复和自我调整，达到你所期望的状态。\n与传统的 CI/CD 管道相比，GitOps 采用了拉与推的模式。这意味着开发人员和运维人员不需要调用管道来推送变更到集群中。开发人员只需在源控制中更新他们的 Kubernetes 清单，在集群上运行的 GitOps 控制器将拉取这些变更，并应用所需的状态。因此，Git 成为环境中的唯一的事实来源。\n为什么要实施 GitOps？ 在过去 11 年的行业观察中，我发现了从 TeamCity 到 Jenkins 到 Gitlab 等众多 CI/CD 系统的好处和陷阱。我在各组织中看到的一个共同模式是共享 CI/CD 基础设施。一台或几台构建服务器被几十个团队共享，这往往导致服务器方面的资源争夺，间歇性的网络问题，频繁的中断，这些都成为开发团队无法推送构建的瓶颈。当然，这些系统有许多好处，但肯定有更好的方法。\n很多时候，团队由于对共享服务的依赖而退步。\nGitOps 允许我们横向扩展集群的数量，因为每个集群都支持自我调节和自我修复。 …","relpermalink":"/blog/accelerating-developer-productivity-via-gitops/","summary":"本文介绍了什么是 GitOps 及其架构。","title":"GitOps 如何提高开发人员的工作效率"},{"content":" 编者按\n本博客将向您介绍零信任网络及其基本要素，这是 CISO（首席信息安全官）必须考虑的，以使网络强大，在当今的数字转型中没有安全漏洞，并减少潜在的财务损失。\n当今所有主要组织都在经历大规模的数字化转型，采用云、移动、微服务和容器技术来高效地提供服务，满足关键业务需求，赶上市场预期。企业的平台和 DevOps 团队必须对分布式和多云的应用程序和服务进行建模，以便随时随地进行访问，从而实现敏捷性。这在组织内部产生了两个重要的趋势：\n随着越来越多的组织采用多云，他们将其应用程序部署到公有云（谷歌、亚马逊、Azure 等），这意味着数据离开了他们所认为的安全的内部数据中心。 企业使用微服务和分布式架构来实现大规模和敏捷。 然而，应用程序开发人员现在需要解决一系列新的可靠性和安全性问题，因为越来越多的依赖性是通过网络调用消耗的。当集中式系统在使用时，网络和端点安全在十年前很容易实现和管理。安全团队可以利用防火墙充分保障周边的安全。随着多云中的分散数据和微服务导致的分布式工作负载的新趋势，IT 安全组织需要评估他们的安全态势，并重新思考他们的网络架构。当然，安全不是一个人或一个部门的工作，它 …","relpermalink":"/blog/zero-trust-network-for-microservices/","summary":"本博客将向您介绍零信任网络及其基本要素，这是 CISO（首席信息安全官）必须考虑的，以使网络强大，在当今的数字转型中没有安全漏洞，并减少潜在的财务损失。","title":"零信任网络的微服务基本要素概述"},{"content":"本文译自知名出版商 O’Reilly 创始人 Tim O’Reilly 的文章 Why it’s too early to get excited about Web3，原文发布于 2021 年 12 月 13 日。\n最近有很多关于 Web3 的讨论，作为 17 年前定义“Web2.0” 的人，我经常被要求发表评论。我通常避免这样做，因为大多数关于未来的预言都是错误的。不过，我们可以做的是问自己一些问题，帮助我们更深入地看到现在，也就是未来的土壤。正如 William Gibson 的名言：\u0026#34; [未来已来，只是还没有被平均分配](https://quoteinvestigator.com/2012/01/24/future-has-arrived/#:~:text=The Future Has Arrived — It’s,Evenly Distributed Yet – Quote Investigator) “。我们还可以审视经济和社会模式和周期，把马克・吐温的观点作为镜头，即“历史不会重复，但总会惊人的相似”。\n抛开这些噪音，我们可以对 Web3 说些什么？\n分权与集权 2006 …","relpermalink":"/blog/why-its-too-early-to-get-excited-about-web3/","summary":"现在谈论 Web 3.0 还为时尚早。","title":"为什么现在对 Web3 感到兴奋还为时过早？"},{"content":"本文译自 eBPF and Wasm: Exploring the Future of the Service Mesh Data Plane，作者 Vivian Hu，发布于 2022 年 1 月 10 日。\n编者按 前段时间，有人提出使用 eBPF 取代服务网格中的 sidecar 代理，该观点已经发出，就在服务网格和云原生社区中引起了“轩然大波”。后来也有不少人指出该方案实属武断，不切实际。本文就总结了 eBPF 在服务网格数据平面中的作用，以及使用 Wasm 这种新的方案。\n正文 2021 年 12 月 2 日，Cilium 项目宣布了 Cilium Service Mesh 的 beta 测试计划。在谷歌云基于 eBPF 的 Google Cloud Kubernetes Service（GKS）Dataplane V2（于 2020 年 8 月发布）所开创的概念基础上，Cilium Service Mesh 提倡“无 sidecar 服务网格 \u0026#34; 的理念。它扩展了 Cilium eBPF 产品，以处理服务网格中的大部分 sidecar 代理功能，包括 L7 路由和负载均 …","relpermalink":"/blog/ebpf-wasm-service-mesh/","summary":"eBPF 和 Wasm 是服务网格应用在数据平面上实现高性能的新生力量。它们仍然是新生的技术，但有可能成为今天微服务生态系统中 Linux 容器的替代品或补充。","title":"eBPF 和 Wasm：探索服务网格数据平面的未来"},{"content":"本文译自 Are Cloud-Based IDEs the Future of Software Engineering，原文发布于 2022 年 1 月 7 日。\n编者按\n本文主要对比了云端 IDE 的优缺点，就像云端 Office 一样，云端 IDE 迟早也会变得流行起来。\n传统上，软件开发是（而且在很大程度上仍然是）在个人机器上使用集成开发环境（IDE）工具，如 VSCode、JetBrains、Eclipse 等完成。虽然这种 “离线” 开发的模式在早期运作得非常好，但人们很快就注意到，这种方法并非完美。\n首先，合作起来很麻烦，因为写好的代码必须上传到网上供进一步审查。这样写出来的代码的可移植性也并不总是有保证，因为有各种各样的操作系统和其他限制条件，需要它来实现最佳的功能。\n正如开发者和技术记者 Owen Williams 去年 在他的博客 Charged 上写道：“在设备之间同步你的文档和照片是微不足道的…… 这样你就可以在任何地方把它们调出来，但开发者工具仍然停留在过去 —— 每台笔记本电脑或 PC 都要单独配置，使你的环境设置得恰到好处。”\n随着大流行期间越来越多的分布 …","relpermalink":"/blog/are-cloud-based-ides-the-future-of-software-engineering/","summary":"本文主要对比了云端 IDE 的优缺点，就像云端 Office 一样，云端 IDE 迟早也会变得流行起来。","title":"云端 IDE 是软件工程的未来吗？"},{"content":"译者注：本文作者是 Isovalent 联合创始人\u0026amp;CTO，原文标题 How eBPF will solve Service Mesh - Goodbye Sidecars，作者回顾了 Linux 内核的连接性，实现服务网格的几种模式，以及如何使用 eBPF 实现无 Sidecar 的服务网格。\n什么是服务网格？ 随着分布式应用的引入，额外的可见性、连接性和安全性要求也浮出水面。应用程序组件通过不受信任的网络跨越云和集群边界进行通信，负载均衡、弹性变得至关重要，安全必须发展到发送者和接收者都可以验证彼此的身份的模式。在分布式应用的早期，这些要求是通过直接将所需的逻辑嵌入到应用中来解决的。服务网格将这些功能从应用程序中提取出来，作为基础设施的一部分提供给所有应用程序使用，因此不再需要修改每个应用程序。\n服务网格示意图 纵观今天服务网格的功能设置，可以总结为以下几点：\n弹性连接：服务与服务之间的通信必须能够跨越边界，如云、集群和场所。通信必须是有弹性的和容错的。 L7 流量管理：负载均衡、速率限制和弹性必须是 L7 感知的（HTTP、REST、gRPC、WebSocket 等）。 基于身份 …","relpermalink":"/blog/ebpf-solve-service-mesh-sidecar/","summary":"本文回顾了 Linux 内核的连接性，实现服务网格的几种模式，以及如何使用 eBPF 实现无 Sidecar 的服务网格。","title":"告别 Sidecar——使用 eBPF 解锁内核级服务网格"},{"content":"最近我在研究 Istio 生态中的开源项目，Slime 这个项目开源与 2021 年初，是由网易数帆微服务团队开源的一款基于 Istio 的智能网格管理器。Slime 基于 Kubernetes Operator 实现，可作为 Istio 的 CRD 管理器，无须对 Istio 做任何定制化改造，就可以定义动态的服务治理策略，从而达到自动便捷使用 Istio 和 Envoy 高阶功能的目的。\nSlime 试图解决的问题 Slime 项目的诞生主要为了解决以下问题：\n网格内所有服务配置全量下到所有 Sidecar Proxy，导致其消耗大量资源使得应用性能变差的问题 如何在 Istio 中实现高阶扩展的问题：比如扩展 HTTP 插件；根据服务的资源使用率做到自适应限流 Slime 解决以上问题的答案是构建 Istio 的控制平面，具体做法是：\n构建可拔插控制器 数据平面监控 CRD 转换 通过以上方式 Slime 可以实现配置懒加载和插件管理器。\nSlime 架构 Slime 内部分为三大模块，其架构图如下所示。\nSlime 内部架构图 Slime 内部三大组件为： …","relpermalink":"/blog/smart-istio-management-plane-slime/","summary":"本文介绍的是由网易数帆微服务团队开源的一款基于 Istio 的智能网格管理器 Slime。","title":"网易开源 Istio 扩展项目 Slime 简介——基于 Istio 的智能服务网格管理器"},{"content":"Istio 1.12 中新的 WebAssembly 基础设施使其能够轻松地将额外的功能注入网格部署中。\n经过三年的努力，Istio 现在有了一个强大的扩展机制，可以将自定义和第三方 Wasm 模块添加到网格中的 sidecar。Tetrate 工程师米田武（Takeshi Yoneda）和周礼赞（Lizan Zhou）在实现这一目标方面发挥了重要作用。这篇文章将介绍 Istio 中 Wasm 的基础知识，以及为什么它很重要，然后是关于建立自己的 Wasm 插件并将其部署到网格的简短教程。\n为什么 Istio 中的 Wasm 很重要 使用 Wasm，开发人员可以更容易的扩展网格和网关。在 Tetrate，我们相信这项技术正在迅速成熟，因此我们一直在投资上游的 Istio，使配置 API、分发机制和从 Go 开始的可扩展性体验更加容易。我们认为这将使 Istio 有一个全新的方向。\n有何期待：新的插件配置 API，可靠的获取和安装机制 有一个新的顶级 API，叫做 WasmPlugin，可以让你配置要安装哪些插件，从哪里获取它们（OCI 镜像、容器本地文件或远程 HTTP 资源），在哪里 …","relpermalink":"/blog/istio-wasm-extensions-and-ecosystem/","summary":"Istio 1.12 中新的 WebAssembly 基础设施使其能够轻松地将额外的功能注入网格部署中。","title":"Istio 1.12 引入 Wasm 插件配置 API 用于扩展 Istio 生态"},{"content":"本文根据 2021 年 11 月 22 日晚我应极客邦邀请在「极客时间训练营」的直播分享《云原生漫谈：聊聊 Service Mesh 的现状》整理而成，赵化冰参与了本文的审校。\n本来极客时间是想邀请我分享云原生的，但我觉得那个范围太大，在一次分享中只能泛泛而谈，无法聚焦到一个具体的点，因此我想还是先聚焦在服务网格这一个专题上吧。云原生社区最近倒是在做一个云原生系列的分享，大家可以关注下。\n这是我今天分享的大纲：\n第一探讨下服务网格跟云原生的关系 第二是给大家陈述下我观察到的目前社区里关于服务网格有哪些争论 第三是给大家介绍几个服务网格的相关的开源项目 最后是畅想下服务网格未来的发展 服务网格与云原生的关系 首先我们将探讨下服务网格与云原生的关系。\n服务网格——容器编排大战后的产物 Docker Swarm vs Kubernetes vs Mesos 如果你关注云原生领域足够早的话，应该还会对 2015 到 2017 年间的容器编排大战记忆犹新。关于服务网格的起源已经无需多言。2017 年 Kubernetes 获得了容器大战的胜利，微服务的理念已经深入人心，容器化的趋势可谓势不可 …","relpermalink":"/blog/jimmy-service-mesh-talk/","summary":"本文探讨了服务网格和云原生的关系，社区发展现状，开源生态，及未来发展。","title":"都 2021 年了，对于服务网格，社区到底在讨论什么？"},{"content":"译者注：本文译自 Istio 官方博客，博客原标题 gRPC Proxyless Service Mesh，其实是 Istio 1.11 版本中支持的实验特性，可以直接将 gRPC 服务添加到 Istio 中，而不需要再向 Pod 中注入 Envoy 代理。本文中还给出了一个 Demo 性能测试数据，这种做法可以极大的提升应用性能，降低网络延迟。\nIstio 使用一组发现 API（统称为 xDS API 来动态配置其 Envoy sidecar 代理。这些 API 的目标是成为一个 通用的数据平面 API。gRPC 项目对 xDS API 有很好的支持，也就是说你可以管理 gRPC 工作负载，而不需要同时部署 Envoy sidecar。你可以在 Megan Yahya 的 KubeCon EU 2021 演讲中了解更多关于该集成的信息。关于 gRPC 支持的最新情况，可以在他们的提案中找到，还有实现状态。\nIstio 1.11 增加了实验性支持，可以直接将 gRPC 服务添加到网格中。我们支持基本的服务发现，一些基于 VirtualService 的流量策略，以及双向 TLS。\n支持 …","relpermalink":"/blog/grpc-proxyless-service-mesh/","summary":"本文介绍了 Istio 对 gRPC 的无代理服务网格功能的支持。","title":"基于 gRPC 和 Istio 的无 sidecar 代理的服务网格"},{"content":"本文译自 Istio 官方博客。这是 Istio 在 2021 年发布的最后一个版本，也是本年度发布的第四个版本，Istio 依然在按照它既定的发布节奏发展。\nWebAssembly API WebAssembly 是一个重要的项目，开发了 3 年多，为 Istio 带来了先进的可扩展性，允许用户在运行时动态加载自定义构建的扩展。然而，直到现在，配置 WebAssembly 插件一直是实验性的，而且很难使用。\n在 Istio 1.12 中，我们通过增加一个 API 来配置 WebAssembly 插件 ——WasmPlugin 来改善这种体验。\n有了 WasmPlugin，你可以轻松地将自定义插件部署到单个代理，甚至是整个网格。\n该 API 目前处于 Alpha 阶段，正在不断发展。我们非常感谢 您的反馈意见 !\n遥测 API 在 Istio 1.11 中，我们引入了全新的 Telemetry API，为 Istio 中配置追踪、日志和指标带来了标准化的 API。在 1.12 版本中，我们继续朝这个方向努力，扩大了对配置指标和访问日志 API 的支持。\n要想开始，请查看文档。 …","relpermalink":"/blog/istio-1-12-release/","summary":"这是 Istio 在 2021 年发布的最后一个版本，也是本年度发布的第四个版本，Istio 依然在按照它既定的发布节奏发展。","title":"Isto 1.12 发布——支持 WebAssembly 插件管理"},{"content":"作者：Carlos Santana (IBM)、Omer Bensaadon (VMware)、Maria Cruz (Google)，原文发布于 Knative 官方博客。\n今天我们发布了 Knative 1.0，达到了一个重要的里程碑，这要归功于 600 多名开发者的贡献和合作。Knative 项目是由谷歌在 2018 年 7 月发布的，并与 VMWare、IBM、Red Hat 和 SAP 紧密合作开发的。在过去 3 年中，Knative 已经成为 Kubernetes 上最广泛安装的无服务器层。\n最新动态 如果你没有密切关注 Knative 的发展，自从我们在 2018 年 7 月首次发布以来，已经有很多变化。\n除了无数的错误修复、稳定性和性能增强之外，我们的社区还按时间顺序进行了以下改进：\n支持多个 HTTP 路由层（包括 Istio、Contour、Kourier 和 Ambassador） 支持多个存储层的事件概念与常见的订阅方法（包括 Kafka、GCP PubSub 和 RabbitMQ） “鸭子类型 \u0026#34; 的抽象，允许处理具有共同字段（ …","relpermalink":"/blog/knative-1-0-ga/","summary":"今天我们发布了 Knative 1.0，达到了一个重要的里程碑，这要归功于 600 多名开发者的贡献和合作。","title":"Knative 1.0 发布了！"},{"content":"编者按 本文英文原文发布在 CNCF 官方博客 Dapr (Distributed Application Runtime) joins CNCF Incubator 上，译者敖小剑，宋净超参与了审校。另外云原生社区中也成立了 Dapr 小组，欢迎各位爱好者加入。\n正文 CNCF 技术监督委员会（TOC）已经投票决定接受 Dapr 作为 CNCF 的孵化项目。\nDapr 是一套使开发者能够轻松编写分布式应用的 API。无论是在 Kubernetes 还是其他环境中，Dapr 都是以 Sidecar 进程运行在应用程序旁边，为开发者提供了一套形式为 pub/sub、状态管理、秘密管理、事件触发器和服务间调用的安全而可靠的原语。在 Dapr 的帮助下，开发人员可以专注于构建业务逻辑而不是基础设施。\nDapr 维护者和指导委员会成员 Mark Fussell 说：“我听到开发者说 Dapr 如何缩短了他们在 Kubernetes 和其他托管平台上构建可扩展的分布式应用的时间，并解决了他们的业务需求，这对我产生了巨大的鼓舞。现在，随着 Dapr 成为 CNCF 的一部分，开发人员能够更容易地构 …","relpermalink":"/blog/dapr-distributed-application-runtime-joins-cncf-incubator/","summary":"CNCF 技术监督委员会（TOC）已经投票决定接受 Dapr 作为 CNCF 的孵化项目。","title":"Dapr（分布式应用运行时）加入 CNCF 孵化器"},{"content":"背景 随着云原生概念的普及，服务网格技术的流行以及 Istio 的成熟，使用 Istio 进行服务治理的实践也越来越多，正成为服务治理的趋势。\n在这样的背景下，我们也加入到 Istio 的研究中，希望初期通过 Istio 实现公司产品迭代版本的灰度发布，后续基于 Istio 为业务产品提供更多的流量管理及观测追踪能力。\n一开始设计 Istio 部署方案时，基于当时对公司产品部署方式的了解，每款产品独占一套 Kubernetes 集群，另外考虑到当时我们对 Istio 的熟悉程度，设计的是最基础的方案：一套 Kubernetes 集群中部署一套 Istio，将该 Kubernetes 集群内唯一的产品纳管到 Istio 服务网格中，即 Kubernetes 集群、产品、Istio 是 1:1:1 的关系。\n随着对公司产品部署方式调研的深入，我们了解到有几款产品部署在一套 Kubernetes 集群中，按照 namespace 进行分割，并且公司开始推行统一 Kubernetes 集群，已经在落地实施。\n如果我们继续使用初始的部署方案，在初期 Kubernetes 集群中产品数量不多，规模 …","relpermalink":"/blog/istio-multi-tenancy-exploration/","summary":"Istio 作为服务治理的主流技术，应用的越来越多。在将 Istio 落地部署的时候，需要考虑公司组织结构、产品、网络、人员等多种场景因素，确定合适的部署方案。我们需要在一个 Kubernetes 集群中通过 Istio 纳管多款产品，针对该需求，对 Istio 部署模型进行了一些调研探索，确定了适合的的部署模式，记录下来，为有相同需要的伙伴提供参考。","title":"多租户场景下 Istio 部署方案探索"},{"content":"本文译自 How eBPF Streamlines the Service Mesh。\n今天有几个服务网格的产品和项目，承诺简化应用微服务之间的连接，同时提供额外的功能，如安全连接、可观察性和流量管理。但正如我们在过去几年中反复看到的那样，对服务网格的兴奋已经被对额外的复杂性和开销的实际担忧所抑制。让我们来探讨一下 eBPF 是如何让我们精简服务网格，使服务网格的数据平面更有效率，更容易部署。\nSidecar 问题 今天的 Kubernetes 服务网格解决方案要求你在每一个应用 pod 上添加一个代理 sidecar 容器，如 Envoy 或 Linkerd-proxy。这是正确的：即使在一个非常小的环境中，比如说有 20 个服务，每个服务运行五个 pod，分布在三个节点上，你也有 100 个代理容器。无论代理的实现多么小和有效，这种纯粹的重复都会耗费资源。\n每个代理使用的内存与它需要能够通信的服务数量有关。Pranay Singhal 写了他配置 Istio 的经验，将每个代理的消耗从 1GB 左右减少到更合理的 60-70MB。但是，即使在我们的小环境中，在三个节点上有 100  …","relpermalink":"/blog/how-ebpf-streamlines-the-service-mesh/","summary":"本文探讨一下 eBPF 是如何让我们精简服务网格，使服务网格的数据平面更有效率，更容易部署。","title":"eBPF 如何简化服务网格"},{"content":"本文分析 Istio 安全认证体系与加密通信的源码，介绍 Istio 是如何构建集群内部 PKI 证书基础设施和实施安全通信的。\n分析过程的代码注释在我的 Github 仓库 mayocream/istio 的 citadel-review 分支。\n1. 身份模型 零信任架构下，需要严格区分工作负载的识别和信任，而签发 X.509 证书是推荐的一种认证方式1。在 Kubernetes 集群中，服务间是通过 DNS 名称互相访问的，而网络流量可能被 DNS 欺骗、BGP/路由劫持、ARP 欺骗等手段劫持，为了将服务名称（DNS 名称）与服务身份强关联起来，Istio 使用置于 X.509 证书中的安全命名（Secure naming）机制2。\nSPIFFE 是 Istio 所采用的安全命名的规范，它也是云原生定义的一种标准化的、可移植的工作负载身份规范。3\n1.1. 介绍 Secure Production Identity Framework For Everyone (SPIFFE) 是一套服务之间相互进行身份识别的标准，主要包含以下内容：\nSPIFFE ID 标准，SPIFFE …","relpermalink":"/blog/istio-zero-trust-source-code-reading/","summary":"本文分析 Istio 安全认证体系与加密通信的源码，让读者对零信任的实践有清晰的认识，这些知识能帮助构建零信任认证与通信体系。","title":"Istio 安全源码分析——认证体系与通信安全"},{"content":"本文基于 APISIX 2.6 版本进行源码分析，源码阅读注释仓库：review，分析主要流程以及核心机制。\n1. APISIX 概述 APISIX 与 Kong 类似，是一个基于 OpenResty 构建的 API 网关，如果你熟悉 OpenResty，你大概能猜到本文会讲述 APISIX 在 OpenResty 的几大生命周期中， 做了什么动作来进行路由匹配、服务发现、负载均衡以及加载插件。 如果你还想了解 Kong 网关是如何运作的，可以查看我的另一篇文章 Kong 源码分析。 当然，APISIX 不同于 Kong 的地方，例如 etcd 数据变化监听、强大的缓存机制、以及在性能优化上做的尝试，本文也会一一阐述。\n1.1. 项目概述 APISIX 是基于 OpenResty 开发的 API 网关，与 OpenResty 的请求生命周期一致，APISIX 利用 Lua Nginx Module 提供的 *_by_lua 添加 Hook。\nAPI Gateway traffic APISIX 抽象了 Route、Service、Upstream、Plugin、Consumer 等数据 …","relpermalink":"/blog/apisix-source-code-reading/","summary":"本文针对云原生网关 APISIX 的核心流程以源码分析的方式剖析其工作原理，并对于网关未来的发展方向进行了思考。","title":"云原生网关 APISIX 核心流程源码分析与进化方向思考"},{"content":"讲师分享 云原生社区 meetup 第八期上海站开场，郭旭东 云原生 2.0 华为云赋能“新云原生企业”，张凯豪 蚂蚁万级规模 K8s 集群 etcd 架构优化实践 —ETCD on OceanBase，宣超 新一代开源 HCI 底层原理剖析，胡凯 攀登规模化的高峰 —— 蚂蚁集团大规模 Sigma 集群 ApiServer 优化实践，唐博，谭崇康 云原生分布式存储 Rook 及其在企业中应用的未来，林文炜 ","relpermalink":"/event/cloud-native-meetup-shanghai-08/","summary":"本次活动聚焦于 OceanBase、Rook、Sigma 等。","title":"云原生社区 meetup 第八期上海站"},{"content":"Chaos Mesh 是由 TiDB 背后的 PingCAP 公司开发，运行在 Kubernetes 上的混沌工程（Chaos Engineering）系统。简而言之，Chaos Mesh 通过运行在 K8s 集群中的“特权”容器，依据 CRD 资源中的测试场景，在集群中制造浑沌（模拟故障）1。\n本文探索混沌工程在 Kubernetes 集群上的实践，基于源码分析了解 Chaos Mesh 的工作原理，以代码示例阐述如何开发 Chaos Mesh 的控制平面。 如果你缺乏基础知识，要想对 Chaos Mesh 的架构有宏观上的认识，请参阅文末尾注中的链接。\n本文试验代码位于 mayocream/chaos-mesh-controlpanel-demo 仓库。\n如何制造混沌 Chaos Mesh 是在 Kubernetes 上实施混沌工程的利器，那它是如何工作的呢？\n特权模式 上面提到 Chaos Mesh 运行 Kubernetes 特权容器来制造故障。Daemon Set 方式运行的 Pod 授权了容器运行时的权能字（Capabilities）。\napiVersion: …","relpermalink":"/blog/chaos-engineering-with-kubernetes/","summary":"本文探索混沌工程在 Kubernetes 集群上的实践，基于源码分析了解 Chaos Mesh 的工作原理，以代码示例阐述如何开发 Chaos Mesh 的控制平面。","title":"在 Kubernetes 实施混沌工程——Chaos Mesh 原理分析与控制面开发"},{"content":"本文针对 Kong 的启动流程、插件机制、缓存机制和请求的生命周期做了详细的阐述。\n1. 概述 本文针对的是 Kong 2.1 版本（Stable）。\n我阅读并作出中文注释的 Commits 可以在这里看到： https://github.com/mayocream/kong/commits?author=mayocream\nKong（OpenResty）的执行阶段：\nKong 的插件机制也是基于 OpenResty 的生命周期，只不过是其在上层做了些许封装。\nKong 的数据库关联关系：\nKong 虽然介绍中说是 Cloud Native 项目，也上榜了 CNCF 全景图，但是它还依赖于传统的数据库 PostgreSQL，并且还自定义了许多 Function，相比于 APISIX 的分布式储存 Etcd 显得较为弱势。比起 Etcd 客户端能建立 HTTP 长连接 Watch 数据变化，Kong 只能依赖定时的轮询从数据库更新状态，数据库高可用也相比搭建 Etcd 集群要复杂得多。\n2. 配置文件 Kong 在启动阶段会解析 kong/templates 目录下的 .lua 模板文 …","relpermalink":"/blog/kong-source-code-reading/","summary":"本文分析了 Kong 的启动流程、插件机制、缓存机制和请求的生命周期。","title":"云原生网关 Kong 源码分析"},{"content":"编者按 本文译自 Cloudflare 出品的白皮书 Can ZTNA replace your VPN? Compare 3 remote access approaches，本文对比了 VPN 和 ZTNA 远程访问解决方案，阐明了它们的好处和局限性，同时阐明了迁移项目的最重要考虑因素。同时给出了 Cloudflare 的解决方案及迁移到 ZTNA 的步骤建议。\n简介 安全、无缝的远程访问是一个业务促进因素——提高远程用户的生产力，减少 IT 团队花在入职和维护用户与应用连接的时间，并具有灵活性和弹性。然而，远程访问对许多企业来说仍然是一个挑战。\n很久以前，VPN 提供了一种简单的方法，将一些远程用户短暂地连接到企业网络。然而，随着劳动力的分布越来越广——企业需要在更长时间内保持远程用户的安全连接——这种方法的缺陷变得很明显，从性能低下、安全风险增加到扩展性问题。\n随着远程访问需求的增长，企业正越来越多地从传统的 VPN 实施方式转向更安全、性能更高的远程访问解决方案。零信任网络访问（Zero Trust Network Access），或称 ZTNA，围绕特定的应用程序、 …","relpermalink":"/blog/can-ztna-replace-vpn/","summary":"本文对比了 VPN 和 ZTNA 远程访问解决方案，阐明了它们的好处和局限性，同时阐明了迁移项目的最重要考虑因素。同时给出了 Cloudflare 的解决方案及迁移到 ZTNA 的步骤建议。","title":"ZTNA 能取代 VPN 吗？——三种远程访问方法对比"},{"content":"前言 前段时间我写了一篇文章《如何用研发效能搞垮一个团队》引起了业界同行大量的讨论与关注，今天想继续聊聊研发效能提升过程中另一个敏感话题：“度量”。讨论度量的目的不是争论对错，而是希望能够引发大家对这一话题的深入思考。\n度量失败的案例 首先来看一些由于度量体系设计不当而引发“内卷”等不良行为的案例。\n比如以“点击量”来度量自媒体运营的成果，那么就有可能出现点击量显著提升，但是公众号的关注人数却下降的现象。原因就是使用“标题党”等手段诱骗读者打开链接，但是实际内容名不副实，几次之后读者就不会继续关注该公众号了。\n再比如以“手术成功率”来考核医生，医生就会刻意回避疑难杂症和重症病人，医生的“手术成功率”是提高了，但重症病人却得不到救治。\n时代变了，很多事物底层逻辑都变了 今天的度量为什么容易失败呢？正如我在之前那篇文章中提到的，面对变革，最重要的并不是方法和技术的升级，而应该是思维模式的升级。我们身处数字化的变革之中，需要将工业化时代科学管理的思维彻底转为字节经济时代的全新思维。\n对于软件研发效能的度量，我们绝大多数时候还在用工业化时代形成的管理理念来试图改进字节经济下的研发模式。但时代变 …","relpermalink":"/blog/murder-case-triggered-by-rd-efficiency-measurement/","summary":"优秀的度量体系设计对目标会有很强的正向牵引作用，不恰当的度量体系往往会引发一场“腥风血雨”。","title":"研发效能度量引发的血案"},{"content":"本文译自：Service Mesh Ultimate Guide - Second Edition: Next Generation Microservices Development。\n主要收获 了解采用服务网格技术的新兴架构趋势，特别是多云、多集群和多租户模式，如何在异构基础设施（裸机、虚拟机和 Kubernetes）中部署服务网格解决方案，以及从边缘计算层到网格的应用 / 服务连接。 了解服务网格生态系统中的一些新模式，如多集群服务网格、媒体服务网格（Media Service Mesh）和混沌网格，以及经典的微服务反模式，如“死星（Death Star） “架构。 获取最新的关于在部署领域使用服务网格的创新总结，在 Pod（K8s 集群）和 VM（非 K8s 集群）之间进行快速实验、混乱工程和金丝雀部署。 探索服务网格扩展领域的创新，包括：增强身份管理，以确保微服务连接的安全性，包括自定义证书授权插件，自适应路由功能，以提高服务的可用性和可扩展性，以及增强 sidecar 代理。 了解操作方面即将出现的情况，如配置多集群功能和将 Kubernetes 工作负载连接到托管在虚拟机 …","relpermalink":"/blog/service-mesh-ultimate-guide-e2/","summary":"本文是 InfoQ 自 2020 年 2 月发表的服务网格终极指南后的第二版，发布于 2021 年 9 月。","title":"服务网格终极指南第二版——下一代微服务开发"},{"content":"1. 边缘计算专家长成计划 云原生社区边缘计算 SIG 从 2021 年 4 月成立以来，就定位为学习性边缘计算小组，为培养更多的边缘计算专家而奋斗着。到目前为止我们已经有 200 多位小伙伴，为 KubeEdge、SuperEdge、EdgeX Foundry、Karmada 等开源项目先后贡献了 40 多个 Commits。我们的开发者也快突破 30 人，来自不同公司，不同岗位，贡献着不同的开源项目。我们一块在此学习 -\u0026gt; 成长 -\u0026gt; 蜕变。\n以下是我们每周六下午 18:30 推出的边缘计算专家长成计划*入门篇的 20 篇合集，跟着我们学习的小伙伴有 150 多位。在此汇总一篇合集，作为边缘计算专家长成计划*入门篇的小结。\n2. 边缘计算专家入门 20 篇 第 01 课：边缘计算深度调研\n推荐语：深度调研边缘计算，让您从概念、市场、技术、玩家……对边缘计算有个全局的认识，带您走进边缘计算的大门。\n第 02 课：云走向边缘，云将无处不在\n推荐语：边缘计算需要合作共建，靠任意一家厂商拿不下来，必须靠硬件提供商、网络运营商、云厂商、内容提供商……一块干才能彻底打通云边端，实现万物互联！\n …","relpermalink":"/blog/edge-sig-learn-20/","summary":"云原生社区边缘计算 SIG 已经累计发布 20 篇边缘入门学习，欢迎跟着我们思路长成边缘计算专家！","title":"边缘计算专家长成计划入门 20 篇"},{"content":"前言 内部有非 K8S 环境上需要类似 SVC 的负载实现，一开始是用 NGINX 做的，所有 SVC 域名都解析成一个 dummy IP，然后 NGINX 根据 server_name 去 proxy 不同的 upstream。开始还是能用的，但是后面结果后面很多服务依赖 host 这个 header，报错签名错误，而且毕竟这样是在用户态，效率不如内核态高。于是打算搞下之前的打算：把 IPVS 的 ClusterIP 的 SVC 扣到非 K8S 环境上使用。\nkube-proxy 的 SVC 简单讲就是 node 上任何进程访问 SVC IP:SVC PORT 会被 dnat 成 endpoint ，是工作在内核态的四层负载，不会在机器上看到端口监听，而默认非集群的机器是无法访问 SVC IP。在 K8S 里，endpoint 的 ip 无非就是 POD IP，host IP。前者就是 SVC 选中 POD，后者例如 kubernetes 这个 SVC，会 DNAT 成每个 kube-apiserver 的 host IP:6443 端口，也可能是 ExternalName 或者手动 …","relpermalink":"/blog/create-a-ipvs-svc-without-container/","summary":"在没有容器的环境下，靠基础的软件实现一个 IPVS 的 SVC 负载。","title":"在非容器环境上实现散装的 IPVS SVC"},{"content":"编者注：本文译自 How Unnecessary Complexity Gave the Service Mesh a Bad Name。\n主要收获 采用服务网格有巨大的价值，但必须以轻便的方式进行，以避免不必要的复杂性。 在实施服务网格时，要采取务实的方法，与技术的核心功能保持一致，并注意分散注意力的问题。 服务网格的一些核心特征包括标准化监控、自动加密和身份识别、智能路由、可靠的重试和网络可扩展性。 服务网格可以提供强大的功能，但这些功能可能会分散对核心利益的注意力，并不被视为实施服务网格的主要原因。 一些值得注意的分心，可能对你的初始实施没有必要，包括复杂的控制平面、多集群支持、Envoy、WASM 和 A/B 测试。 服务网格是 Kubernetes 世界中的一个热门话题，但许多潜在的采用者已经失去了耐心。服务网格的采用受到了巨大的复杂性和似乎无穷无尽的供应商解决方案的限制。在我自己浏览了这个领域后，我发现采用服务网格有巨大的价值，但必须以轻量级的方式进行，以避免不必要的复杂性。尽管普遍存在幻灭感，但服务网格的前景依然光明。\n在工作中学习 我进入服务网格的世界，始于我在一家历史 …","relpermalink":"/blog/service-mesh-unnecessary-complexity/","summary":"服务网格是 Kubernetes 世界中的一个热门话题，但许多潜在的采用者已经失去了耐心。","title":"远离复杂性——服务网格需要更加务实"},{"content":"讲师分享 云原生社区 meetup 第七期深圳站开场致辞 - 宋净超 使用 IAST 构建高效的 DevSecOps 流程 - 董志勇 云原生场景下的开发和调试 - 汪晟杰，黄金浩 Envoy 在腾讯游戏云原生平台应用 - 田甜 使用 KubeVela 构建混合云应用管理平台 - 邓洪超 ","relpermalink":"/event/cloud-native-meetup-shenzhen-07/","summary":"本次活动关注于 DevSecOps、Envoy、KubeVela、Nocalhost 等。","title":"云原生社区 meetup 第七期深圳站"},{"content":"译者注：本文译自 Envoy 代理的创始人 Matt Klein 于昨晚在个人博客上发布的文章 5 year of Envoy OSS。他在 Twitter 因为自己的程序 bug 造成重大事故而离职，后加入 Lyft，在开源 Envoy 之前几乎没有贡献和管理开源项目的经验，这篇文章分享了他个人及 Envoy 开源的心路历程，在投身开源 Envoy 还是为雇主 Lyft 效命，该如何抉择？看完本文，相信对于开源项目的维护者、创业者及投资人都会大有收获。\n前言 今天是 Envoy Proxy 开源的 5 周年。毫不夸张地说，在专业方面，过去的 5 年是一个史诗般的过山车，我的情绪介于兴奋、自豪、焦虑、尴尬、无聊、倦怠之间。我想分享一下这个项目的前传和历史，以及我在发展大型开源软件项目的过程中所学到的一些经验教训。\n前传和历史 前传 除了一些小的弯路，我在技术行业二十年的职业生涯一直专注于底层系统：嵌入式系统，操作系统，虚拟化，文件系统，以及最近的分布式系统网络。我的分布式系统网络之旅始于 2010 年初在亚马逊，我有幸帮助开发了第一批高性能计算（HPC）EC2 实例类型。我学到了大量的 …","relpermalink":"/blog/envoy-oss-5-year/","summary":"开源网络代理 Envoy 的创始人 Matt Klein，在 Twitter 因为自己的程序 bug 造成重大事故而离职，后加入 Lyft，在开源 Envoy 之前几乎没有贡献和管理开源项目的经验，这篇文章分享了他个人及 Envoy 开源的心路历程，在投身开源 Envoy 还是为雇主 Lyft 效命，该如何抉择？","title":"网络代理 Envoy 开源五周年，创始人 Matt Klein 亲述开源心路历程及经验教训"},{"content":"8 月 22 日，在大连市腾飞园区 5 号楼一楼世达教育，云原生社区 meetup 大连站正式拉开了序幕。此次活动是大连第一次举办如此规模的云原生技术大会，现场到场人数 70+，线上观看人数 700+。来自大连多家头部公司的技术专家围绕云原生，给线上线下的观众奉献了一场精彩的技术盛会。\n让我们再次回顾一下此次 meetup！\n讲师话题 《Connecting,Contorlling and Observing Dubbo Microservices with Flomesh》 主讲人：林杨 Flomesh 首席架构师\n分享了如何使用 Flomesh 实现 Dubbo 项目的服务治理，包括可观测性、metrics、日志收集、灰度发布及限流限速等功能。\n《基于云原生技术的服务最大化可用性》 主讲人：白西原 乐天创研 架构师\n从乐天创研的实践入手，分享了如何基于云原生技术来实现服务最大化，提高服务可用性。\n《分布式系统的发展与趋势分析》 主讲人：张卫滨 金兰科技 软件设计师\n概述了分布式系统的发展过程以及相关的核心技术，展望微服务的发展趋势以及后 k8s 时代的分布式技术发展分析。 …","relpermalink":"/blog/cloud-native-meetup-dalian-recap/","summary":"2021 年 8 月 22 日，大连，四位讲师均围绕云原生为大家奉献了一场技术盛会。","title":"云原生社区 meetup 第六期大连站回顾"},{"content":"话题 欢迎来到云原生社区大连站 Connecting, Controlling and Observing Dubbo Microservices with Flomesh，林杨 基于云原生技术的服务最大化可用性，白西原（乐天创研） Jutopia 一站式云原生机器学习平台，何昌钦 分布式系统的发展与趋势分析，张卫滨 ","relpermalink":"/event/cloud-native-meetup-dalian-06/","summary":"本次活动关注服务网格、机器学习。","title":"云原生社区 meetup 第六期大连站"},{"content":"本文译自2021 European Tech Hiring Trends，作者The Chief I/O。\n译者评论 官方钦定：码农属于新生代农民工如今不再是程序员的调侃了 最近在社区里看到很多人在讨论国家开始不给大型互联网企业减税，互联网公司股价普跌，大部分距离年内最高点腰斩，个人所得税成为工薪税，程序员被划归为”新生代农名工“，”贫贱不能移“等话题。让我们一起来看看欧洲的 IT 招聘趋势还有薪资水平，是否国外的月亮就是圆呢？\n昨天在社区群里传的一张「北京市运维工程师薪资水平」 报告解读 尽管新冠疫情正在逐渐消退，但其影响仍将持续一段时间。本文衡量了疫情对欧洲科技企业招聘的影响，展露了欧洲科技招聘的新趋势。\n国家的经济规模不断扩大 欧洲国家的失业率保持稳定 招聘活动增加 软件开发人员、程序员的需求量更大 雇主寻求全面发展的技术人才 雇主要求软技能作为主要技能的一部分 39% 的招聘信息寻求具有 0-2 年经验的专业人士 薪资范围从 36000 到 90000 欧元 德国和法国在科技人员招聘方面领先 信息和通信业、制造业引领科技招聘 在所有行业中，2020 年是一个促进招聘的年份，迫使 …","relpermalink":"/blog/europoe-it-hiring-report-2021/","summary":"2021 年度欧洲 IT 求职报告解读。","title":"疫情期间欧洲 IT 民工招聘趋势报告解读，DevOps、AI 和平台工程师最高年薪 9 万欧"},{"content":"本文翻译自 Kubernetes Cloud Clusters Face Cyberattacks via Argo Workflows。\n译者点评 行业中一直不缺安全的声音，安全也是永远绕不过的槛。再优雅再先进的架构设计，无法保障安全也是一文不值，甚至干系到企业的存活。\n近期在云原生领域，安全也是被屡次被提起重视。从 Istio 首次安全评估结果公布、CNCF 云原生安全白皮书发布美国国家安全局出品《Kubernetes 加固指南》、《关键信息基础设施安全保护条例》的颁布看出，下到社区到基金会，上到国内外政府对安全的重视。\n近几年开源越来越热，各种的工具层出不穷。仪表盘可以说是离用户最近的一层，也是安全最容易被疏忽的一处，尤其是很多仪表盘并未提供用户校验或者容易配置错误。\n正文 Argo 的 web 仪表盘权限配置错误，会允许未经身份验证的攻击者在 Kubernetes 目标上运行代码，包括加密币挖掘容器。\n安全研究人员发出警告，Kubernetes 集群正受到配置错误的 Argo Workflow 实例的攻击。\nArgo Workflow 是一个开源的、容器原生的工作流引擎， …","relpermalink":"/blog/kubernetes-cyberattacks-argo-workflows/","summary":"近几年开源越来越热，各种的工具层出不穷。仪表盘可以说是离用户最近的一层，也是安全最容易被疏忽的一处，尤其是很多仪表盘并未提供用户校验或者容易配置错误。","title":"Kubernetes 云集群面临通过 Argo Workflows 实施的网络攻击"},{"content":"本文译自 Postman’s Series D Funding and the API-First World。\n译者评论 没错，这正是那个被人所熟知，在程序员中广为流传的 Postman，五年前我曾在被一个同事推荐 Chrome 中安装过一个插件，专门用来调试 API 的，这个插件就是 Postman。\nPostman Chrome App 正文 我很高兴地宣布，今天对 Postman 来说是一个巨大的里程碑。我们已经完成了 D 轮 2.25 亿美元的融资，目前公司的估值为 56 亿美元。本轮融资由 Insight Partners 领投，并有三个新的投资者加入 ——Coatue、Battery Ventures 和 BOND。我们也得到了现有 Postman 投资者 CRV 和 Nexus Venture Partners 的热情参与。此外，DoorDash 产品负责人 Gokul Rajaram 和 Freshworks 创始人 Girish Mathrubootham 作为个人投资者加入。\nAPI 已经迅速成为全球每个行业、每个国家的开发者使用的软件的基本构件，Postman  …","relpermalink":"/blog/postman-announces-series-d/","summary":"这就是我们熟悉的那个 API 调试和管理工具 Postman！","title":"印度 API 管理公司 Postman D 轮融资 2.25 亿美元，估值高达 56 亿美元"},{"content":"本文翻译自 gitpod 的 blog 文章 Dev environments as code。\n想象一下，仅在十年前，运维人员还在手动部署、配置和维护软件系统，这大大消耗了他们宝贵的生命和精力。\n而在今天，微服务架构时代，软件系统变得更加复杂，尝试手动维护操作和部署都变的不再可能。在我们进行“DevOps”或“基础设施即代码”的实践时，发现声明式的描述软件系统对于自动和持续地部署应用程序是必不可少的。\n那我们的开发环境呢？ 虽然我们已经自动部署了应用程序，但我们中的大多数人还没有将相同的技术应用于开发环境。相反，在项目中招募新团队成员往往需要几个小时来配置他们的开发环境。\n这种情况通常是这样的：\n新的开发人员接收到项目文档链接 阅读冗长且过时的 setup 说明 在开发终端上安装依赖、更新/降级版本等 尝试运行构建……等待 20 分钟 构建失败，尝试寻找哪里出了问题 询问同事。“哦是的，你还需要做 X 和 Y” 转回步骤 3 经过多次尝试，构建突然起作用了。您不知道为什么，但这现在不重要了。当然，您无法更新文档，因为您也不确定是如何完成设置的，甚至不确定现在的状态是否可以重现。因此如 …","relpermalink":"/blog/dev-env-as-code/","summary":"通过将开发环境的配置，以可执行的格式保存，并将其与项目源码一起存入源码存储库，从而实现开发环境配置的自动化、可复用和版本化。","title":"开发环境即代码：可以运行在云上的开发环境"},{"content":"本文译自 Takeaways from Gartner’s 2021 Hype Cycle for Cloud Security report。\nGartner 在该集团的最新预测中称，2021 年全球公有云服务将增长 26.2%，见 Forecast: Public Cloud Services, Worldwide, 2019-2025, 2Q21 Update。\n2020 年，云计算使 IT 路线图和计划不断向前推进，同时支持不断增长的虚拟劳动力和破纪录的数字转型步伐。麦肯锡对全球高管的调查发现，数字化转型的步伐在 2020 年加快了 7 年。\n此外，61% 的企业将云计算作为其数字化转型工作的一部分，其收入增长了 25% 或更多。云基础设施还使 IT 部门能够满足新的应用程序和系统的紧迫的上市时间表。然而，当云基础设施为应对不可预测的工作负载而扩大和缩小规模时，IT 怀疑论者变成了信徒，而之前的预测数据又无法依赖。\nGartner 引述了疫情之后企业对云计算的加速采用，预计这将推动五年的复合年增长率（CAGR）达到 21.5%。因此，全球公有云服务预计将从 2021 …","relpermalink":"/blog/takeaways-from-gartners-2021-hype-cycle-for-cloud-security-report/","summary":"云原生应用保护平台（CNAPP）和安全服务边缘（SSE）在今年迎来了的云安全领域的上升周期。","title":"从 Gartner 的 2021 年云安全炒作周期报告中得到的启示"},{"content":"本文译自 The Future of Microservices? More Abstractions，作者是 Container Solutions 的主编 Charles Humble。\n微服务是在 10 年前出现的，是软件融合进化的例子之一。虽然这个词可以归功于软件咨询公司 Thoughtworks 的 James Lewis 和 Martin Fowler，Adrian Cockcroft 也曾提出类似的想法。但当时在 Netflix 和许多硅谷的其他公司，如亚马逊、Google 和 eBay 等公司大致在相同的时间内独立搭建了或多或少相同的架构模式。\n在这个词诞生后的十年里，我们看到了 Kubernetes、服务网格和无服务器的兴起，我们也开始看到微服务被应用到了前端。除了可以横向扩展，微服务还可以让开发人员更快地部署代码，有利于组件的可替换性而不是可维护性。\n无论好坏，对许多人来说，微服务已经成为默认的架构选择。对于拥有自主团队和松散耦合系统的组织来说，微服务可以很好地工作，但它们带来了所有分布式系统都无法逃避的复杂性。\n“我坚决认为公共云比私有云和数据中心更好，这些好处是 …","relpermalink":"/blog/the-future-of-microservices/","summary":"在进入微服务时代的十年里，思考一下我们已经走到了哪一步，以及我们还需要解决哪些问题是很有意思的。","title":"微服务的未来——更多层抽象"},{"content":"本文译自 Istio 官方博客。\n这是 Istio 在 2021 年发布的第三个版本，我们要感谢整个 Istio 社区，特别是来自红帽的发布经理 John Wendell、来自 Solo.io 的 Ryan King 和来自英特尔的 Steve Zhang，感谢他们帮助 Istio 1.11.0 发布。该版本正式支持 Kubernetes 1.18.0 到 1.22.x。下面是该版本的一些亮点。\nCNI 插件（Beta） 默认情况下，Istio 会在部署在网格的 pod 中注入一个 init 容器。istio-init 容器使用 iptables 设置 pod 网络流量重定向到（来自）Istio sidecar 代理。这需要网格中部署 pod 的用户或服务账户有足够的权限来部署具有 NET_ADMIN 和 NET_RAW 功能的容器。要求 Istio 用户拥有较高的 Kubernetes 权限，对于组织内的安全合规性来说是有问题的。Istio CNI 插件是 istio-init 容器的替代品，它执行相同的网络功能，但不要求 Istio 用户启用更高的 Kubernetes 权限。 …","relpermalink":"/blog/istio-111-release/","summary":"这是 Istio 在 2021 年度发布的第三个版本。","title":"Istio 1.11 发布"},{"content":"本文翻译自 Bilgin Ibryam 的文章 A Framework for Open Source Evaluation。\n如今，真假开源无处不在。最近开源项目转为闭源的案例越来越多，同时也有不少闭源项目（按照 OSI 定义）像开源一样构建社区的例子。这怎么可能，开源项目不应该始终如此吗？\n开源不是非黑即白，它具有开放性、透明、协作性和信任性的多个维度。有些开源是 Github 上的任何项目，有些必须通过 OSI 定义，有些是必须遵守不成文但普遍接受的开源规范。这里通过看一些商业和技术方面，再讨论社区管理习惯，来同大家分享一下我对评估开源项目的看法。\n免责声明 这些是我的个人观点，与我的雇主或我所属的软件基金会和项目无关。 这不是法律或专业意见（我不是律师，也不是专门从事 OSS 评估的），而是外行的意见。 更新：我收到了多位开源律师的反馈并更新了文章！ 这篇博文由订阅和分享按钮赞助，点击这些按钮表示支持。 知识产权 关于“开源”项目的第一个问题是关于知识产权的所有权。好消息是，即使不了解这些法律含义，你可以应用一个简单的 Litmus 测试。该项目是否属于你信任的信誉良好的开源基 …","relpermalink":"/blog/a-framework-for-open-source-evaluation/","summary":"开源不是非黑即白，它具有开放性、透明、协作性和信任性的多个维度。本文从多个维度帮你评估一个项目是否符合开源标准。","title":"开源评估框架"},{"content":"还不知道 Pipy 是什么的同学可以看下 GitHub 。\nPipy 是一个轻量级、高性能、高稳定、可编程的网络代理。Pipy 核心框架使用 C++ 开发，网络 IO 采用 ASIO 库。Pipy 的可执行文件仅有 5M 左右，运行期的内存占用 10M 左右，因此 Pipy 非常适合做 Sidecar proxy。\nPipy 内置了自研的 pjs 作为脚本扩展，使得 Pipy 可以用 JS 脚本根据特定需求快速定制逻辑与功能。\nPipy 采用了模块化、链式的处理架构，用顺序执行的模块来对网络数据块进行处理。这种简单的架构使得 Pipy 底层简单可靠，同时具备了动态编排流量的能力，兼顾了简单和灵活。通过使用 REUSE_PORT 的机制（主流 Linux 和 BSD 版本都支持该功能），Pipy 可以以多进程模式运行，使得 Pipy 不仅适用于 Sidecar 模式，也适用于大规模的流量处理场景。在实践中，Pipy 独立部署的时候用作“软负载”，可以在低延迟的情况下，实现媲美硬件的负载均衡吞吐能力，同时具有灵活的扩展性。\n在玩过几次 Pipy 并探究其工作原理后，又有了更多的想法。\n初探 …","relpermalink":"/blog/pipy-implement-kubernetes-admission-control/","summary":"本文带你如何使用 Pipy 实现策略即代码做镜像检查。","title":"Rego 不好用？用 Pipy 实现 OPA"},{"content":"从互联网（或可信镜像仓库库以外的任何地方）拉取未知镜像会带来风险——例如恶意软件。但是还有其他很好的理由来维护单一的可信来源，例如在企业中实现可支持性。通过确保镜像仅来自受信任的镜像仓库，可以密切控制镜像库存，降低软件熵和蔓延的风险，并提高集群的整体安全性。除此以外，有时还会需要检查镜像的 tag，比如禁止使用 latest 镜像。\n这今天我们尝试用“策略即代码”的实现 OPA 来实现功能。\n还没开始之前可能有人会问：明明可以实现个 Admission Webhook 就行，为什么还要加上 OPA？\n确实可以，但是这样策略和逻辑都会耦合在一起，当策略需要调整的时候需要修改代码重新发布。而 OPA 就是用来做解耦的，其更像是一个策略的执行引擎。\n什么是 OPA Open Policy Agent（以下简称 OPA，发音“oh-pa”）一个开源的通用策略引擎，可以统一整个堆栈的策略执行。OPA 提供了一种高级声明性语言（Rego），可让你将策略指定为代码和简单的 API，以从你的软件中卸载策略决策。你可以使用 OPA 在微服务、Kubernetes、CI/CD 管道、API 网关等中实施策 …","relpermalink":"/blog/image-trusted-repository-with-open-policy-agent/","summary":"本文带你如何通过策略即代码实现镜像检查。","title":"使用 Open Policy Agent 实现可信镜像仓库检查"},{"content":"本文译自 Istio 官方博客 Security Best Practices。\nIstio 的安全功能提供了强大的身份、策略、透明的 TLS 加密以及认证、授权和审计（AAA）工具来保护你的服务和数据。然而，为了充分安全地利用这些功能，必须注意遵循最佳实践。建议在继续阅读之前，先回顾一下安全概述。\n双向 TLS Istio 将尽可能使用双向 TLS 对流量进行自动加密。然而，代理在默认情况下被配置为许可模式（Permissive Mode），这意味着他们将接受双向 TLS 和明文流量。\n虽然这是为了增量采用或允许来自没有 Istio sidecar 的客户端的流量的需要，但它也削弱了安全立场。建议在可能的情况下迁移到严格模式（Strict Mode），以强制使用双向 TLS。\n然而，仅靠双向 TLS 并不足以保证流量的安全，因为它只提供认证，而不是授权。这意味着，任何拥有有效证书的人仍然可以访问一个服务。\n为了完全锁定流量，建议配置授权策略。这允许创建细粒度的策略来允许或拒绝流量。例如，你可以只允许来自 app 命名空间的请求访问 hello-world 服务。\n授权策略 Istio …","relpermalink":"/blog/istio-security-best-practices/","summary":"本文列举了 Istio 安全的最佳实践。","title":"Istio 安全最佳实践"},{"content":"本文译自 DevSecOps: the Key to Securing Your Supply Chain in a Multi-Cloud Threatscape。\n主要收获 可以将最近的供应链攻击作为 DevSecOps 的一个试金石，我们可以看到在 DevOps 中确实需要一个改进的安全框架。\n随着网络安全的关注度的提升以及 IT 安全支持的激增，企业应该首先评估他们的 DevOps 做法。\nDevSecOps 是这样的：利用 CI/CD 平台和容器化，在 SDLC（软件开发生命周期）内增加测试和扫描，并且使用 AI/ML 来最大限度的减少手动安全措施。\n安全左移或许需要整个组织在多个业务部门之间进行组织架构改变，但整体安全态势将很快得到大幅改善。\n采用 DevSecOps 框架的企业不仅可以加强对漏洞的预防，还可以增加商业价值，因为他们可以提供更安全的产品和服务，更好地保护其业务和客户。\nDevSecOps 恰逢其时 随着近期的供应链和云攻击，企业现在正在寻求开发人员来增强企业安全。\n由于迅速转变为远程和混合工作模式，我们看到了所有部门在云计算应用和数字转型方面的爆炸式增长。这 …","relpermalink":"/blog/devsecops/","summary":"本文从多个角度说明了 DevSecOps 对于供应链安全的重要性。","title":"DevSecOps——在多云环境中确保供应链安全的关键"},{"content":"本文译自 Istio 社区官方博客 Announcing the results of Istio’s first security assessment。\nIstio 服务网格已在各行各业获得广泛的生产应用。该项目的成功，以及其在基础设施中执行关键安全策略的重要用途，都需要对与该项目相关的安全风险进行公开和中立的评估。\n为了实现这一目标，Istio 社区去年与 NCC 集团签约，对该项目进行第三方安全评估。审查的目标是“确定与 Istio 代码库有关的安全问题，突出管理员常用的高风险配置，并提供关于安全功能是否充分解决它们旨在提供的问题的观点”。\nNCC 集团在 Istio 社区的领域专家的协作下，进行了为期五周的审查。在这篇博客中，我们将研究报告的主要发现，为实施各种修复和建议而采取的行动，以及我们对 Istio 项目的持续安全评估和改进的行动计划。你可以下载并阅读安全评估报告的未删节版本。\n范围和主要发现 本次评估从整体上评估了 Istio 架构的安全相关问题，重点是 Istiod（Pilot）、Ingress/Egress 网关等关键组件，以及 Istio 作为数据平面代理的整 …","relpermalink":"/blog/istio-first-security-assessment/","summary":"由 NCC 集团进行的第三方安全审查的结果。","title":"Istio 首次安全评估结果公布"},{"content":"本文译自在 CNCF 官网上发布的博客 Networking with a service mesh: use cases, best practices, and comparison of top mesh options，有删节。作者是 Amir Kaushansky，ARMO 公司的产品 VP。\n服务网格技术是随着微服务结构的普及而出现的。由于服务网格促进了网络与业务逻辑的分离，它使你能够专注于你的应用程序的核心竞争力。\n微服务应用程序分布在多个服务器、数据中心或大陆上，使它们高度依赖网络。服务网格通过用路由规则和服务间包的动态方向控制流量来管理服务间的网络流量。\n在这篇文章中，我们将研究使用案例，比较顶级网格选项，并讨论最佳做法。\n让我们从使用服务网格的最常见场景开始。\n使用案例 服务网格是一种连接微服务和管理它们之间流量的架构方法。它们在一个组织的许多层面上被大量用于生产。因此，有一些标准化的、被广泛接受的用例。\n可观察性 假设你有一个后端服务的实例响应缓慢，在你的整个堆栈中造成了一个瓶颈。然后，来自前端服务的请求将超时，并重新尝试连接到缓慢的服务实例。在服务网格的帮助下， …","relpermalink":"/blog/top-service-mesh-pk/","summary":"服务网格大 PK。","title":"服务网格联网：使用案例、最佳实践和顶级服务网格选择比较"},{"content":"本文为翻译文章，点击查看原文。\n在这篇文章中，我会介绍在生产环境部署多副本应用时会碰到的一个经典问题：数据库 schema 更新。\n接下来将会讨论几种可能的解决方案，从简单到复杂。最后会总结一下我是如何在生产环境解决这个问题的：使用 Kubernetes Job 和 init container。了解了这些解决方案（最重要的是谨慎的设计数据库 schema）你可以比较从容的应对应用升级时的数据库数据更新的问题。\n经典问题：不断更新的数据库 这个问题其实非常普遍，新版本的应用需要使用到新的数据库 schema，所以当部署新版本应用时，就需要更新数据库的 schema，通常我们称之为 数据库 schema 变更 (database migrations),几乎所有涉及数据库的应用都会碰到类似的问题。\n有很多不同的方式来管理数据库的更新，比如说 EF Core，自动生成对应的更新数据来更新数据库。或者也有一些库可供使用，比如 DbUp 或者 FluentMigrator 可以让你以代码或者 SQL 脚本的方式定义数据库变更并自动的应用这些变更。\n这些方式都类似的会记录那些已经应用在数据库中的 …","relpermalink":"/blog/running-database-migration-when-deploying-to-kubernetes/","summary":"作者分析了如何在部署应用时更新数据库并给出了相应解决办法。","title":"在 Kubernetes 上部署应用时如何更新数据库"},{"content":"本文译自 Istio 官网。\n当用户将他们的服务转移到 Istio 服务网格中运行时，他们通常会惊讶地发现，控制平面默认会观察和处理集群中所有命名空间中的所有 Kubernetes 资源。这对于拥有大量命名空间和部署的大型集群，甚至对于拥有快速流动资源（例如 Spark 作业）的中等规模的集群来说，都可能是一个问题。\n我们需要一种方法来动态地限制作为网格一部分的命名空间集，以便 Istio 控制平面只处理这些命名空间的资源。限制命名空间的能力使 Istiod 能够观察和推送更少的资源和相关的变化到 sidecar，从而提高控制平面和数据平面的整体性能。\n背景 默认情况下，Istio 监视集群中的所有命名空间、服务、端点和 Pod。例如，在我的 Kubernetes 集群中，我把 sleep 服务部署在默认命名空间，把 httpbin 服务部署在 ns-x 命名空间。我已经把 sleep 服务添加到网格中，但我没有计划把 httpbin 服务添加到网格中，或者让网格中的任何服务与 httpbin 服务交互。\n使用 istioctl proxy-config endpoint …","relpermalink":"/blog/discovery-selectors/","summary":"了解如何使用发现选择器以及它们如何与 Sidecar 资源交互。","title":"使用发现选择器来为你的 Istio 服务网格配置命名空间"},{"content":"话题 开场演讲：欢迎来到云原生社区成都站，宋净超，云原生社区创始人、Tetrate 布道师 Amazon EKS Distro 开源项目解析 \u0026amp; 演示，粟伟，亚马逊云科技资深解决方案架构师 面向量化投资的 AI 平台 ——AI 赋能投资：打造以大数据 + AI 为核心的下一代投资平台，梁举，宽邦科技 CEO 基于 TiDB 的云原生数据库实践，王天宜，TiDB 社区部门架构师 Layotto: 开启服务网格 + 应用运行时新篇章，石建伟（卓与），蚂蚁集团高级技术专家 ","relpermalink":"/event/cloud-native-meetup-chengdu-05/","summary":"本次活动关注 EKS Distro、TiDB、AI 和服务网格。","title":"云原生社区 meetup 第五期成都站"},{"content":"前言 这篇内容篇幅比较长，如果不想深入探讨或时间有限，这是全文简述： 在默认设置下，扩展 Kubernetes 集群中的 pod 和节点可能需要几分钟时间。 了解如何调整集群节点的大小、配置水平和集群自动缩放器以及过度配置集群以加快扩展速度。\n目录 当自动伸缩的 Pod 报错 Kubernetes 的 Cluster Autoscaler 是如何工作的 探索 Pod 自动伸缩提前期 为 Kubernetes 节点选择最佳实例大小 在 Kubernetes 集群中过度配置节点 为 Pod 选择正确的内存和 CPU 资源 关于集群的缩容 为什么不基于内存或 CPU 进行自动伸缩 在 Kubernetes 中，自动伸缩功能包括：\nPod 水平自动伸缩（Horizontal Pod Autoscaler，HPA） Pod 垂直自动伸缩（Vertical Pod Autoscaler，VPA） 集群自动伸缩（Cluster Autoscaler，CA） 这些自动伸缩组件属于不同的类别，关注点也不同。\nHorizontal Pod Autoscaler 负责增加 Pod 的副本数量。随着你的应用接 …","relpermalink":"/blog/kubernetes-autoscaling-strategy/","summary":"本文讲述了 Kubernetes 集群自动伸缩策略的一些最佳实践。","title":"如何选择最佳的 Kubernetes 集群自动伸缩策略"},{"content":"什么是 OPA？ 这是一个始于 2016 年的项目，旨在统一不同技术和系统的策略执行。今天，OPA 被科技行业内的巨头们所使用。例如，Netflix 使用 OPA 来控制对其内部 API 资源的访问。Chef 用它来为他们的终端用户产品提供 IAM 功能。此外，许多其他公司，如 Cloudflare、Pinterest 等，都使用 OPA 在他们的平台上执行策略（如 Kubernetes 集群）。目前，OPA 已从 CNCF 中毕业。\nOPA 有什么用？ 你可能想知道 OPA 是怎样诞生的？它试图解决什么问题？事实上，API 和微服务的策略执行就如同微服务本身一样古老。没有一个生产级别的应用程序不执行访问控制、授权和策略。为了理解 OPA 的作用，考虑以下用例：你的公司通过一个在线门户销售笔记本电脑。像所有其他类似的应用程序一样，该门户由一个首页组成，客户在这里看到最新的产品，也许还有一些限时促销活动。如果客户想买东西，他们需要登录或创建一个账户。接下来，使用信用卡或其他方法付款。为了确保客户会反复访问，需要支持客户订阅，其中可能包含特别折扣信息。另外，他们可以选择在新产品公布后立即接 …","relpermalink":"/blog/introducing-policy-as-code-the-open-policy-agent-opa/","summary":"本文将带你初步了解开放策略代理 OPA，一个平台无关的策略执行工具。","title":"策略即代码——Open Policy Agent（开放策略代理 OPA）简介"},{"content":"现状 当前，云原生已经成为应用开发者在选择架构设计时的首选。云原生让应用开发者可以将所有精力都集中在开发业务逻辑本身，这极大降低了应用开发者的负担。\n而应用系统的敏捷性、扩展性、可靠性、高可用等，则由基础设施软件和运维团队共同承担。一方面，运维团队需要利用基础设施软件，快速响应业务系统提出的部署、扩容、迁移等需求，另一方面，也要时刻保持业务系统和基础设施软件的稳定运行。这为基础设施软件和运维团队都带来了更大的挑战。\n如何正确的为基础架构软件进行设计和选型，就成为了运维主管们最具挑战的任务之一。\n云原生场景下的存储系统 存储系统一直以来都是基础设施软件中的核心之一。无论业务采用什么样的运行环境和架构，都离不开存储系统的支撑。\n在过去的 30 年中，业务系统的运行环境经历了巨大的变化，从单独部署的物理机，小规模部署的虚拟化环境，大规模部署的云环境，以及目前的 Kubernetes 平台。在这个变革的过程中，业务系统对平台敏捷性的要求越来越高。在物理机时代，运维人员需要手动配置存储系统和部署业务系统，业务上线以周为单位。而在云原生时代，每分钟都可能发布新的应用版本，每天都可能有大量的业务要上 …","relpermalink":"/blog/storage-in-cloud-native-era/","summary":"本文介绍了目前云原生环境下，支持有状态应用的几种典型存储方案的特点，并对市场主流的几个云原生存储产品实际测试性能进行对比。","title":"云原生时代需要什么样的存储系统？"},{"content":"Service Mesh 在微服务领域已经非常流行，越来越多的公司开始在内部落地，蚂蚁从 Service Mesh 刚出现的时候开始，就一直在这个方向上大力投入，到目前为止，内部的 Mesh 方案已经覆盖数千个应用、数十万容器并且经过了多次大促考验，Service Mesh 带来的业务解耦，平滑升级等优势大大提高了中间件的迭代效率。\n在大规模落地以后，我们又遇到了新的问题，本文主要对 Service Mesh 在蚂蚁内部落地情况进行回顾总结，并分享对 Service Mesh 落地后遇到的新问题的解决方案。\n一、Service Mesh 回顾与总结 A、Service Mesh 的初衷\nImage 在微服务架构下，基础架构团队一般会为应用提供一个封装了各种服务治理能力的 SDK，这种做法虽然保障了应用的正常运行，但缺点也非常明显，每次基础架构团队迭代一个新功能都需要业务方参与升级才能使用，尤其是 bugfix 版本，往往需要强推业务方升级，这里面的痛苦程度每一个基础架构团队成员都深有体会。\n伴随着升级的困难，随之而来的就是应用使用的 SDK 版本差别非常大， …","relpermalink":"/blog/mosn-layotto-intro/","summary":"本文来自上周六的 SOFAMeetup#6 北京站分享。","title":"蚂蚁开源多运行时项目 Layotto 简介"},{"content":"译者注 本文作者 Patrick Woods 是 Orbit 公司的创始人和 CEO。Orbit 是一个 SaaS 服务，可以为你的社区提供任务控制，在任何平台上发展和衡量你的社区。\n前言 有人说社区是新的护城河，这是真的：拥有一个社区有助于防止竞争对手的公司或产品进入你的领域。无论这个社区是一群强大的用户、开源贡献者、创造者，甚至只是一个品牌（或特许经营）的超级粉丝，它都能带来更大的品牌知名度、更高的转换成本和规模经济。\n在今天的市场上，买家有无尽的选择，所以公司不能只依靠功能和价格来赢得商业。这就是为什么像 Figma、Lululemon、Salesforce、Sephora 和 Twilio 这样的公司 —— 从开发者平台和 CRM 到消费者品牌 —— 都把社区放在他们战略的首位。还有无数其他公司的例子，他们也有社区，即使他们还没有积极地参与其中。\n不过，社区的好处不仅仅是捍卫自己的行业地位。在当今软件不再被出售，而是被采用的世界里，比以往任何时候都有更多的公司正在拥抱他们以前所忽视的客户、贡献者和粉丝。但是，虽然他们中的一些人确实认识到了社区在他们的 Go To Market（ …","relpermalink":"/blog/community-marketing-why-we-need-go-to-community-not-just-go-to-market/","summary":"社区是新的护城河，市场化（GTM）和社区化（GTC）战略中激励机制的关键区别可以概括为价值获取与价值创造之间的区别。","title":"社区不等于营销——为什么我们要社区化，而不仅是市场化？"},{"content":"前言 自上次我们分享 Pinterest 的 Kubernetes 之旅已过去一年有多。从那时起，我们已交付了许多功能以促进客户采用，确保可用性和可伸缩性，并建立运维经验和最佳实践。\n总体来看，Kubernetes 平台用户都给予了积极的反馈。根据我们的用户调查，我们的用户分享的前三大好处有，减少了管理计算资源的负担，更好的资源和故障隔离，以及更灵活的容量管理。\n到 2020 年底，我们的 Kubernetes 集群上已编排了 35K+Pod，运行了 2500 + 个节点。这支撑了我们 Pinterest 的绝大部分业务，并且有机增长仍如火箭般迅速。\n简单概括 2020 年 随着用户采用率增长，工作负载的多样性和数量也不断增加。这要求 Kubernetes 平台需要更具可扩展性才能跟上工作负载管理，Pod 调度以及节点分配上持续增长的负载。随着越来越多的关键业务登上 Kubernetes，对平台可靠性的期望自然而然地提升到了一个新的水平。\n平台范围内的中断确实发生过。2020 年初，我们的一个集群由于 Pod 创建数猛增（比计划容量高出 3 倍），导致了集群的 autoscaler 一 …","relpermalink":"/blog/scaling-kubernetes-with-assurance-at-pinterest/","summary":"本文讲述了 Pinterest 在扩展大规模 Kubernetes 过程中的一些工程实践。","title":"Pinterest 如何有把握地扩展 Kubernetes"},{"content":"北京时间 6 月 1 日晚，据 TechCrunch 报道，KKR 和 CD\u0026amp;R 将以 53 亿美元收购 Cloudera，Cloudera 将被私有化。截止到本文发稿，11 点 49 分，Cloudera 股票报价 15.94 美元，涨幅 23.95%。\nCloudera 股价 Cloudera曾经是最热门的 Hadoop 初创公司之一，但是随着时间的推移，这个市场的光芒不再，今天它将被私有化，因为 KKR 和 Clayton Dubilier \u0026amp; Rice 这两家私募股权公司宣布他们打算以 53 亿美元收购 Cloudera。目前该公司的市值约为 37 亿美元。\nCloudera 和 Hortonworks 是 Hadoop 领域的两家重要初创公司，于2018 年以 52 亿美元的价格合并。Cloudera 可能受到激进投资者 Carl Icahn 的压力，他在 2019 年持有该公司18% 的股份，现在可以从这次出售中获益，该公司表示，每股 16 美元的价格对股东有 24% 的溢价。今早开市前，该公司的股价为 12.86 美元。\n早在十年前，当 Hadoop 成为处理大数据的方式 …","relpermalink":"/blog/cloudera-to-go-private-as-kkr-cdr-grab-it-for-5-3b/","summary":"北京时间 6 月 1 日晚，据 TechCrunch 报道，KKR 和 CD\u0026R 将以 53 亿美元收购 Cloudera，Cloudera 将被私有化。","title":"Hadoop 时代或将落幕，Cloudera 将被私有化"},{"content":"今天是六一儿童节，蚂蚁选择在今天开源 OceanBase，想必是给各位分布式数据库用户送上的儿童节礼物吧！昨日凌晨蚂蚁已将代码推送到 GitHub：https://github.com/oceanbase/oceanbase。\n本次开源的是 OceanBase 社区版，这是一款开源分布式 HTAP（Hybrid Transactional/Analytical Processing）数据库管理系统，具有原生分布式架构，支持金融级高可用、透明水平扩展、分布式事务、多租户和语法兼容等企业级特性。OceanBase 内核通过大规模商用场景的考验，已服务众多行业客户，现面向未来持续构建内核技术竞争力。\nOceanBase 社区版具有以下特点。\nOceanBase 社区版本特点 不同版本对比。\nOceanBase 版本对比 OceanBase 社区组织架构 OceanBase 社区治理架构借鉴 Apache 基金会的运作模式，角色分为：\n技术委员会（Technical Oversight Committee）：是 OceanBase 社区的技术管理机构，负责 OceanBase 社区相关的技术类 …","relpermalink":"/blog/ant-oceanbase-open-source/","summary":"今天是六一儿童节，蚂蚁选择在今天开源 OceanBase，想必是给各位分布式数据库用户送上的儿童节礼物吧！","title":"蚂蚁开源 OceanBase，开源分布式数据库领域又迎新玩家"},{"content":"有幸参加了 Flomesh 组织的 workshop，了解了他们的 Pipy 网络代理，以及围绕 Pipy 构建起来的生态。Pipy 在生态中，不止是代理的角色，还是 Flomesh 服务网格​中的数据平面。\n整理一下，做个记录，顺便瞄一下 Pipy 的部分源码。\n介绍 下面是摘自 Github 上关于 Pipy 的介绍：\nPipy 是一个轻量级、高性能、高稳定、可编程的网络代理。Pipy 核心框架使用 C++ 开发，网络 IO 采用 ASIO 库。Pipy 的可执行文件仅有 5M 左右，运行期的内存占用 10M 左右，因此 Pipy 非常适合做 Sidecar proxy。\nPipy 内置了自研的 pjs 作为脚本扩展，使得 Pipy 可以用 JS 脚本根据特定需求快速定制逻辑与功能。\nPipy 采用了模块化、链式的处理架构，用顺序执行的模块来对网络数据块进行处理。这种简单的架构使得 Pipy 底层简单可靠，同时具备了动态编排流量的能力，兼顾了简单和灵活。通过使用 REUSE_PORT 的机制（主流 Linux 和 BSD 版本都支持该功能），Pipy 可以以多进程模式运行， …","relpermalink":"/blog/glance-at-programmable-gateway-pipy/","summary":"初探 Flomesh 的数据平面 Pipy，一个可编程、高性能、轻量级的网关。","title":"初探可编程网关 Pipy"},{"content":"Istio 是由 Tetrate 创始人 Varun Talwar 和谷歌首席工程师 Louis Ryan 命名并在 2017 年 5 月 24 日开源。今天是 Istio 开源四周年，让我们一起来回顾一下 Istio 四年来的发展并展望一下它的未来。\nIstio 的开源历史 2017 年是 Kubernetes 结束容器编排之战的一年，Google 为了巩固在云原生领域的优势，并弥补 Kubernetes 在服务间流量管理方面的劣势，趁势开源了 Istio。下面是截止目前 Istio 历史上最重要的几次版本发布。\n日期 版本 说明 2017-05-24 0.1 正式开源，该版本发布时仅一个命令行工具。确立了功能范围和 sidecar 部署模式，确立的 Envoy 作为默认 sidecar proxy 的地位。 2017-10-10 0.2 支持多运行时环境，如虚拟机。 2018-06-01 0.8 API 重构。 2018-07-31 1.0 生产就绪，此后 Istio 团队被大规模重组。 2019-03-19 1.1 企业就绪，支持多 Kubernetes 集群，性能优化。 …","relpermalink":"/blog/istio-4-year-birthday/","summary":"今天是 Istio 开源四周年，让我们一起来回顾一下 Istio 四年来的发展并展望一下它的未来。","title":"Istio 开源四周年回顾与展望"},{"content":"开场致辞 讲师：宋净超（Tetrate 布道师、云原生社区创始人）\n讲师介绍：Tetrate 云原生布道师，云原生社区创始人，CNCF Ambassador。\n有了 Nginx 和 Kong，为什么还需要 Apache APISIX？ 讲师：王院生\n个人介绍：支流科技联合创始人 CTO\n演讲概要\n在云原生时代，k8s 和微服务已经成为主流，在带来巨大生产力提升的同时，也增加了系统的复杂度。如何发布、管理和可视化服务，成为了一个重要的问题。每次修改配置都要 reload 的 Nginx、依赖 postgres 才能工作的 Kong，都不是云原生时代的理想之选。这正是我们创造 Apache APISIX 的原因：没有 reload、毫秒内全集群生效、不依赖数据库、极致性能、支持 Java 和 Go 开发插件。\n听众收益\n更好的理解 API 网关、服务网格，以及各个开源项目的优劣势\n云原生时代的研发效能 讲师：黄国峰\n个人介绍：腾讯 PCG 工程效能专家。10 多年的软件和互联网从业经验；现任腾讯工程效能部，负责持续集成、研发流程和构建系统等平台；曾任职唯品会高级经理，负责架构团队。在云原生 …","relpermalink":"/event/cloud-native-meetup-guangzhou-04/","summary":"本次活动关注于 Dapr 和 APISIX 等。","title":"云原生社区 meetup 第四期广州站"},{"content":"本文译自 Istio 官方文档，有部分修改。\n北京时间 5 月 19 日，我们很高兴地宣布 Istio 1.10 的发布！我们要特别感谢我们的发布经理 Sam Naser 和 张之晗，以及整个测试和发布工作组在 1.10 中的工作。\n这是我们 2021 年的第二个版本，和过去几个版本一样，我们继续为 Istio 用户改善 Day 2 操作。\n该版本的亮点如下。\n发现选择器 在以前的 Istio 版本中，Istio 的控制平面一直在观察和处理集群中它所关心的所有 Kubernetes 资源的更新。这在大型集群或配置快速变化的集群中可能是一个可扩展性瓶颈。发现选择器（Discovery Selector）限制了 Istiod 监视的资源集，所以你可以很容易地忽略那些与网格无关的命名空间的变化（例如一组 Spark Job）。\n你可以认为它们有点像 Istio 的 Sidecar API 资源，但对于 Istiod 本身来说：Sidecar 资源限制了 Istiod 将发送至 Envoy 的配置集。发现选择器限制了 Istio 从 Kubernetes 接收和处理的配置集。 …","relpermalink":"/blog/istio-1-10-release/","summary":"我们很高兴地宣布 Istio 1.10 的发布！我们要特别感谢我们的发布经理 Sam Naser 和张之晗，以及整个测试和发布工作组在 1.10 中的工作。","title":"Istio 1.10 版本发布并改版官网"},{"content":"关于 Lura 项目 近日，Lura 项目，原名为 KrakenD 的开源框架，加入了 Linux 基金会，根据一份新闻声明，“它将是唯一一个在中立、开放论坛中托管的企业级 API 网关”。\nKrakenD API 网关的联合创始人兼首席执行官 Albert Lombarte 说，该项目现在每月活跃在 100 多万台服务器上。转到 Linux 基金会后，将技术放在了第一位，而不是企业公司的需求。\n“我们是真正的开源信徒，我们相信开源是这个项目的归宿，“Lombarte 说。“我们已经看到，技术与 API 网关玩得不好，所采取的做法不是技术的最佳做法，“而是为了营销或销售产品的需要，为了锁定客户。“而我们希望能解放这一点，“他指出。\nKrakenD API 网关建立在现在被称为 Lura 项目的基础上，Lombarte 解释说，KrakenD 是一个有主见的实现，即它注重速度而不是其他功能。Lura 是一个构建 API 网关的框架，可以根据企业的需求进行定制。它是为速度和可扩展性而设计的。Lombarte 说，Lura 用 Go 语言构建，是一个无状态、高性能的 API 网关框架，为云原 …","relpermalink":"/blog/krakend-api-gateway-joins-the-linux-foundation-as-the-lura-project/","summary":"这是一个 Go 语言编写的开源 API 网关，与其他 API 网关最主要的区别是它本身也是以微服务和无状态的方式工作。","title":"KrakenD API 网关更名为 Lura 项目并宣布加入了 Linux 基金会"},{"content":"好消息，好消息！源码架构图系列完整啦！\n大家好，我是杨鼎睿，Kubernetes 源码设计图已经整理完整啦，全部放在了云原生社区下，欢迎大家前来阅读！\n为了方便广大读者的阅读，我们将所有的源码图整理到了 GitBook 中，大家不必为阅读的顺序而困扰啦。\n阅读点我\n源码设计图共近 200 余张（100 余张是手绘的架构设计图），覆盖主要组件包括 API Server，Controller，Scheduler，Proxy，Client 等，同时还有 Docker，Golang 等相关部分。源码图理念以架构设计（数据结构的设计）为主，决不为了讲述流程而画流程图，阅读时需要配合源码同时阅读，同时会有一小部分的问题留白，可以引导读者带着问题进入源码中寻求答案，希望能籍此帮助大家在学习 K8S 的同时提高自己的设计能力。\n从去年 6 月开始到今年，很多图例都经过多次打磨，大小，含义保证一致，如虚线箭头代表动作等，对各种流程如循环迭代的画图表达也经过多次改版，除此之外，尤在图中不同实体的相互位置有下功夫，如同一水平线代表同一层次等，欢迎在画图表达上多多交流，共同推进如此理念的源码架构图。（ …","relpermalink":"/blog/kubernetes-apiserver-cacher/","summary":"本系列带领读者遍读了 Kuberentes 源码，通过源码设计图的方式帮助读者理解源码。","title":"Kubernetes1.18 架构设计源码阅读"},{"content":"本视频主要演示用 edgeadm 支持一键安装边缘 Kubernetes 集群和原生 Kubernetes 集群，让用户很简单、更灵活、无学习成本的一键化体验边缘自治、云边协同…… 能力，深刻体验 Kubernetes 扩展到边缘的强大。相应的功能是由云原生社区边缘计算 SIG 的同学和 SuperEdge 社区的同学一块开发的，详细操作文档见：用 edgeadm 一键化部署边缘 Kubernetes 和原生 Kubernete 集群。\n后续社区还有更多实战的活动推出，欢迎关注。\n使用 edgeadm 一键化部署边缘 Kubernetes 和原生 Kubernete 集群 - bilibili 扫描上面的二维码观看视频，或者访问链接，欢迎点赞、评论、转发。\n","relpermalink":"/blog/edgeadm-kubernetes/","summary":"EdgeAdm 边缘计算视频教程分享。","title":"使用 edgeadm 一键化部署边缘 Kubernetes 和原生 Kubernete 集群"},{"content":"本文翻译自 A Reference Architecture for Fine-Grained Access Management on the Cloud。\n什么是访问管理？ 访问管理是识别用户或一组用户是否应该能够访问给定资源（例如主机、服务或数据库）的过程。例如，对于开发人员来说是否可以使用 SSH 登录生产应用程序服务器，如果可以，那么可以登录多长时间？如果 SRE 在非支持时间尝试访问数据库，他们这样做？如果数据工程师已转移到其他团队，他们是否应该继续访问 ETL 管道的 S3 存储桶？\n现在如何进行访问管理？ 在云上各种基础设施和数据服务激增之前，访问管理是 DevOps 和 Security 团队要解决的相对简单的问题。VPN 和堡垒主机是（现在仍然是）在网络级别封锁所有关键资源的首选机制。用户必须先通过 VPN 服务器进行身份验证，或者登录到堡垒主机，然后才能访问专用网络上的所有资源。\n当资源是静态的并且它们的数量相对较小时，此方法效果很好。但是，随着越来越多的资源动态地涌入专用网络的各处，VPN / 堡垒主机解决方案变得站不住脚。\n具体来说，在三个方面，VPN 和堡垒 …","relpermalink":"/blog/access-management-reference-architecture/","summary":"本文翻译自 Manav Mital 的文章 A Reference Architecture for Fine-Grained Access Management on the Cloud。","title":"云上细粒度访问管理的参考架构"},{"content":"本文译自 ZDNet 的文章 New Relic open sources Pixie, its Kubernetes-native in-cluster observability platform，译者宋净超。\n好消息是，云计算、Kubernetes 和云原生计算结合在一起，使软件开发比以前更快、更强大。坏消息是，保持对所有这些的关注比以往任何时候都更难。这就是为什么 New Relic 将其 Kubernetes 原生集群内观察平台 Pixie 作为一个新的开源项目，在 Apache 2.0 许可下贡献给云原生计算基金会（CNCF）的原因，这是一个好消息。\nPixie 是一个新的云原生应用程序的可观察性平台。有了它，开发人员可以通过一个 shell 命令看到他们应用程序的所有指标、事件、日志和追踪。有了 Pixie，你不需要添加度量（instrumentation）代码，设置临时仪表板，或将数据移出集群，就能看到正在发生的事情。这将为你节省宝贵的时间，这样你就可以致力于建立更好的软件，而不是用更好的方法来监控它。\n该程序作为一组 Kubernetes 服务部署在被监控的集群内。简 …","relpermalink":"/blog/new-relic-open-sources-pixie-its-kubernetes-native-in-cluster-observability-platform/","summary":"想知道你的 Kubernetes 集群中到底发生了什么？刚刚成为云原生计算基金会项目的 Pixie 可以提供帮助。","title":"New Relic 开源 Pixie，其 Kubernetes 原生集群内观察平台"},{"content":"去年写过一篇博客：控制 Pod 内容器的启动顺序，分析了 TektonCD 的容器启动控制的原理。\n背景 为什么要做容器启动顺序控制？我们都知道 Pod 中除了 init-container 之外，是允许添加多个容器的。类似 TektonCD 中 task 和 step 的概念就分别与 pod 和 container 对应，而 step 是按照顺序执行的。此外还有服务网格的场景，sidecar 容器需要在服务容器启动之前完成配置的加载，也需要对容器的启动顺序加以控制。否则，服务容器先启动，而 sidecar 还无法提供网络上的支持。\n现实 sidecar-lifecycle-1 期望 sidecar-lifecycle-2 到了这里肯定有同学会问，spec.containers[] 是一个数组，数组是有顺序的。Kubernetes 也确实是按照顺序来创建和启动容器，但是 容器启动成功，并不表示容器可以对外提供服务。\n在 Kubernetes 1.18 非正式版中曾在 Lifecycle 层面提供了对 sidecar 类型容器的 支持，但是最终该功能并没有落地。\n那到底该怎么做？ …","relpermalink":"/blog/k8s-1.18-container-start-sequence-control/","summary":"Kubernetes 上如何保证容器按照期望的顺序启动？参考 Istio 的实现，模拟容器按指定顺序启动。","title":"Kubernetes 上如何控制容器的启动顺序？"},{"content":"译者注 这篇论文是我在翻译 Envoy 官方文档的 FAQ：Envoy 基准测试最佳实践时看到的，这篇论文学术气息非常浓厚，作者思维之缜密，态度之严谨，令人折服。这篇文章中对基准测试的一些常见误区，还有考虑问题的角度，在我们平时处理问题的时候，我觉得很有借鉴意义。所以翻译过来和大家共同学习。\n基准测试五宗罪 在审阅系统论文时（有时甚至在阅读已发表的论文时），我经常会遇到对基准测试极具误导性的使用。我并不是说作者有意误导读者，这大概率是作者能力有限。但这不是借口。\n我称这类案件为基准测试犯罪。不是因为你会为了他们入狱（但可能应该这样做），而是因为它们破坏了科学过程的完整性。请放心，如果我是论文的审稿人，并且你的论文中包含其中一项的话，那么你基本上是会被拒绝的。除非剩下的工作非常不错，以至于能让我宽恕你的基准测试犯罪（即使那样，你也将被要求在最终版本中进行修复）。\n以下列表正在处理中，当我遇到（或记起）更多基准测试犯罪的系统时，我会不断添加它。\n选择性基准测试 这是所有基准测试犯罪的源头：使用一组有偏见的基准测试（似乎）证明了这一点，这可能与更广泛的评估空间相矛盾。这清楚地表明，最好的情况 …","relpermalink":"/blog/benchmarking-crimes/","summary":"在审阅系统论文时（有时甚至在阅读已发表的论文时），我经常会遇到对基准测试极具误导性的使用。我并不是说作者有意误导读者，这大概率是作者能力有限。但这不是借口。","title":"基准测试五宗罪"},{"content":"本文译自 Tetrate 发布的《零信任架构白皮书》。\n背景介绍 传统的数据中心网络安全架构试图在一个优美的内部花园周围建立强大的围墙。这种堡垒模型长久以来存在一个固有的弱点，即当（而不是如果）入侵者渗透到周边时，他们就可以控制整个花园。虽然这个弱点早就存在，但随着进入数据中心的入口的增加及工作负载的扩展的趋势增加，这个弱点越发严重。\n零信任网络架构提供了一条前进的道路，它解决了基于周界安全的弱点，采取的立场是网络本身就是敌对的；周界背后的安全是一种幻觉，野蛮人已经撞开了大门。\n虽然零信任需要对现状进行重大反思，但它远不是一个崇高的、不可实现的目标。现在就有一些工具可以开始实施零信任网络架构。这些工具和实践可以逐步实施，以满足你的需要，而不是要求你全盘重新构建你的整个网络安全基础设施。\n传统安全模式的弱点 周边安全薄弱的原因与现代军队放弃大规模固定防御的原因类似：一旦被渗透，战斗就会失败；而周边安全最终也会被渗透。\n**单纯的周边安全提供了糟糕的控制粒度。**如果周界内的所有流量都是可信的，那么一个漏洞就会使周界内的一切都变得脆弱。当网络服务只有几十种时，这可能是可控的，而且可以通过物 …","relpermalink":"/blog/zero-trust-architecture/","summary":"本文译自 Tetrate 发布的《零信任架构白皮书》。","title":"零信任架构白皮书"},{"content":"译者注：本文译自 Evolving Kubernetes networking with the Gateway API，Gateway API 的出现解决了 Ingress 的可移植性问题，且有利于基于角色的访问设计。\nIngress 资源是 Kubernetes 众多成功案例中的一个。它创造了一个多样化的 Ingress 控制器的生态系统，这些控制器以标准化和一致的方式在数十万个集群中使用。这种标准化有助于用户采用 Kubernetes。然而，在 Ingress 创建五年后，有迹象表明它被分割成不同但惊人相似的 CRD 和 过载的注释。Ingress 普遍存在的可移植性问题也限制了它的未来。\n那是在 2019 年圣地亚哥的 Kubecon 上，一群充满激情的贡献者聚集在一起，讨论 Ingress 的发展。拥挤的人群溢出到了街对面的酒店大堂，而讨论出来的东西后来被称为 Gateway API。这次讨论是基于几个关键的假设：\n路由匹配、流量管理和服务暴露所依据的 API 标准已经商业化，对其实施者和用户提供的定制 API 的价值很小。 可以通过共同的核心 API 资源来表示 L4/L7 …","relpermalink":"/blog/evolving-kubernetes-networking-with-the-gateway-api/","summary":"Gateway API 的出现解决了 Ingress 的可移植性问题，且有利于基于角色的访问设计。","title":"利用 Gateway API 发展 Kubernetes 网络"},{"content":"说一说来龙去脉，Envoy 是一个非常注重规模化业务的底层网络组件，令人激动且功能强大。然而它在用户体验方面一直很欠缺。\n当用户开始使用一个新工具时，必然会从“如何在自己的环境中安装”这一问题开始。而 Envoy 之前并没有给出答案。\n为了填补这一空白，Tetrate 启动了 GetEnvoy 项目并且 推出了 getenvoy CLI，作为提供给用户的组件。\n新挑战 下一个关于 Envoy 的常见需求是“如何扩展”。\n截止目前，如果想扩展或定制 Envoy，你将不得不“越界”成为实质上的 Envoy 开发者。\n幸运的是，这种情况即将改变。一种名为 WebAssembly（Wasm） 的新技术即将纳入 Envoy。Wasm 让使用不同编程语言开发 Envoy 扩展成为可能。更重要的是，能以完全动态的方式部署这些扩展。\nGetEnvoy 扩展工具包 GetEnvoy 扩展工具包 的目的在于帮助有扩展 Envoy 需求的开发者，在短时间内完成扩展开发并启动运行。\n作为开发者，你很可能想：\n从工作中的典型示例入手 从开始就建立有效的开发工作流 利用最佳实践，自动避免常见陷阱 GetEnvoy …","relpermalink":"/blog/introducing-getenvoy-extension-toolkit-for-webassembly-based-envoy-extensions/","summary":"本文为大家介绍了如何使用开源项目 GetEnvoy 来扩展 Envoy。","title":"使用基于 WebAssembly 的 GetEnvoy 工具包扩展 Envoy"},{"content":"开场致辞 讲师：宋净超（Tetrate 布道师、云原生社区创始人）\n讲师介绍：Tetrate 云原生布道师，云原生社区创始人，CNCF Ambassador。\n使用 Chaos Mesh 来保障云原生系统的健壮性 讲师：周强\n公司：PingCAP\n讲师介绍：周强，PingCAP 工程效率负责人，Chaos Mesh 负责人，专注稳定性和性能测试平台。在混沌工程领域有 4 年的从业经验，领导开发云原生混沌测试平台 Chaos Mesh。\n演讲概要：\n在云原生的世界中，错误无处不在，混沌工程在提高系统稳定性方面起着至关重要的作用。通过执行混沌工程实验，我们可以了解系统的弱点并主动解决。我们开发了云原生混沌工程平台 Chaos Mesh，并在内部使用 Chaos Mesh 来提升云原生分布式数据库 TiDB 的健壮性。目前 Chaos Mesh 已加入 CNCF Sandbox 项目，该平台依托于 k8s 基础设施，通过对 pod/container 进行诸如杀节点、IO 错误和延时注入、时间回退、内核分配内存失败等等来进行混沌测试。主题大纲：\n在分布式领域会遇到的质量和稳定性问题 混沌工程 …","relpermalink":"/event/cloud-native-meetup-hangzhou-03/","summary":"本次活动关注于 ChaosMesh、Envoy 和 KubeVela。","title":"云原生社区 meetup 第三期杭州站"},{"content":"网络应用性能会影响用户的留存率。如果页面加载时间过长，用户就会放弃。所以我们需要监控 Web 应用来了解性能，确保服务稳定、可用、健康。Apache SkyWalking 是一款专门为云原生和基于容器架构设计的应用性能监控（APM）工具。其 skywalking-client-js 是一个轻量级的客户端 JavaScript 异常、性能和追踪库。\n本文介绍了 skywalking-client-js 如何将其监控扩展到浏览器，为 SkyWalking 后端提供性能指标和错误收集。\n性能指标 skywalking-client-js 使用 window.performance 来收集性能数据。从 MDN 文档来看，性能接口提供了对当前页面的性能相关信息的访问。它是 High Resolution Time API 的一部分，但对 Performance Timeline API、Navigation Timing API、User Timing API 和 Resource Timing API 有所增强。\n在 skywalking-client-js 中，所有的性能指标都是根据 W3C …","relpermalink":"/blog/end-user-tracing-in-a-skywalking-observed-browser/","summary":"本文介绍了 skywalking-client-js 如何将其监控扩展到浏览器，为 SkyWalking 后端提供性能指标和错误收集。","title":"SkyWalking 前端监控的应用"},{"content":"本文将向大家介绍同程旅行大数据集群在 Kubernetes 上服务化建设的一些实践和经验。\n前言 同程旅行大数据集群从 2017 年开始容器化改造，经历了自研调度 docker 容器，到现在的云舱平台，采用 Kubernetes 调度编排工具管理大数据集群服务。\n在这个过程中遇到很多问题和难点，本文会向大家介绍上云过程中总结的经验和教训。\n今天的议题主要分下面几点来阐述：\n为什么要将大数据集群服务搬到 Kubernetes 上 在上云的过程遇到哪些痛点 大数据服务上云攻略 现状和未来发展 集群即服务的理念 部门内部很早就提出集群即服务的理念，作为基础组件研发，希望从产品的角度来看待组件或者集群，让业务研发能直接触达底层集群，可以包含节点、日志、监控等功能，让集群使用更简单。\n推行小集群化 以前组件研发部署一个组件集群，这个集群会陆续承接一些业务，时常会遇到 A 业务影响 B 业务，集群负责人会开始考虑拆分，搭建出一个新集群将消耗资源的业务拆分出去。这种是以人工介入的方式去评估业务体量并分配资源。\n现在部门开始推行小集群模式，每个业务研发组都可以申请一个或者多个集群，在物理层面做到资源隔 …","relpermalink":"/blog/2021-tongchenglvxing-shared/","summary":"本文介绍同程旅行大数据集群在 Kubernetes 上的服务化实践。","title":"同程旅行大数据集群在 Kubernetes 上的服务化实践"},{"content":"本文译自 Using Traefik Ingress Controller with Istio Service Mesh。\nIstio 服务网格自带 ingress，但我们经常看到有要求使用非 Istio ingress 的客户。此前，我们已经介绍过将 NGINX 与 Istio 集成的情况。最近，我们一直在与使用 Traefik ingress 的客户合作。通过对我们之前建议的方法进行一些轻微调整，我将向你介绍如何实现 Traefik 作为 Istio 服务网格的入口网关。\n流量的流向如下图所示。一旦请求从 Traefik Ingress 到达服务网格，Istio 就能够对请求应用安全性、可观察性和流量引导规则。\n传入的流量绕过 Istio sidecar，直接到达 Traefik，所以请求终止在 Traefik ingress。\nTraefik 使用 IngressRoute 配置重写 Host 头以匹配目的地，并将请求转发到目标服务，这是一个多步骤的过程。\n从 Traefik Ingress 出来的请求被重定向到 Istio sidecar（由 iptables）。 …","relpermalink":"/blog/using-traefik-ingress-controller-with-istio-service-mesh/","summary":"本文演示了如何将 Traefik Ingress 作为 Istio 服务网格的入口点。","title":"在 Istio 服务网格中使用 Traefik Ingress Controller"},{"content":"本文翻译自 To Multicluster, or Not to Multicluster: Inter-Cluster Communication Using a Service Mesh。Istio 服务网格是解决 Kubernetes 集群间通信的一个关键，虽然翻译这篇文章距离原文发表也有快 2 年时间了，但是其中的很多观点仍不过时。\n主要观点 Kubernetes 已经成为容器编排的事实标准，许多组织都运行着多个集群。集群内的通信是一个解决了的问题，但是跨集群的通信需要更多的设计和操作开销。 在决定是否实施多集群支持之前，你应该了解你的通信用例。 你还应该确定你想要从解决方案中获得什么（单一界面的观察性、统一信任域等），然后制定一个关于如何实现这些的计划。 有几种多集群服务网格方法，如共同管理、集群感知服务通过网关路由、扁平网络和 split-horizon 端点发现服务（EDS）。 Istio 有现有的多集群支持，在 1.1 中还有额外的新功能，甚至未来还会有更多的功能出现。 Kubernetes 已经成为企业中容器编排的事实标准。这是有充分理由的 —— 它提供了一系列功能， …","relpermalink":"/blog/multi-cluster-service-mesh/","summary":"是否该使用服务网格构建多集群？本文会给你答案。","title":"是否选择多集群——使用服务网格的集群间通信"},{"content":"本文译自 The Evolution of Distributed Systems on Kubernetes。\n在 3 月份的 QCon 上，我做了一个关于 Kubernetes 的分布式系统进化的演讲。首先，我想先问一个问题，微服务之后是什么？我相信大家都有各自的答案，我也有我的答案。你会在最后发现我的想法是什么。为了达到这个目的，我建议大家看看分布式系统的需求是什么？以及这些需求在过去是如何发展的，从单体应用开始到 Kubernetes，再到最近的 Dapr、Istio、Knative 等项目，它们是如何改变我们做分布式系统的方式。我们将尝试对未来做一些预测。\n现代分布式应用 为了给这个话题提供更多的背景信息，我认为的分布式系统是由数百个组件组成的系统。这些组件可以是有状态的、无状态的或者无服务器的。此外，这些组件可以用不同的语言创建，运行在混合环境上，并开发开源技术、开放标准和互操作性。我相信你可以使用闭源软件来构建这样的系统，也可以在 AWS 和其他地方构建。具体到这次演讲，我将关注 Kubernetes 生态系统，以及你如何在 Kubernetes 平台上构建这样一个系统。 …","relpermalink":"/blog/distributed-systems-kubernetes/","summary":"本文翻译自 Bilgin Ibryam 的文章 The Evolution of Distributed Systems on Kubernetes。","title":"分布式系统在 Kubernetes 上的进化"},{"content":"近期，腾讯云 CODING DevOps 开源了云原生开发环境 - Nocalhost。\n根据官方文档介绍，Nocalhost 来源于 No Localhost，其含义是开发者不再依赖本地计算机的编码、调试和测试过程。他是一个云原生开发环境，旨在解决云原生下开发难的问题。\n例如，在 Kubernetes 环境下进行微服务开发，通常会面临以下问题：\n每次修改代码，都需要经过构建映像-\u0026gt;推送映像-\u0026gt;拉取映像-\u0026gt;重新启动应用程序（Pod）的过程，开发的反馈循环非常长（10 分钟以上）； 为了开发某个微服务，必须要在本地启动整个环境和所有微服务，这带来了过度依赖本地资源的问题； 开发人员只专注于他们自己的服务，随着迭代的进行，本地启动或更新完整的开发环境越来越难； 微服务之间的依赖关系和启动顺序难以控制； 新入职的员工一般需要 2-3 周的时间来熟悉开发环境的搭建及学习背景知识 那么，Nocalhost 到底是怎么解决以上问题的？Nocalhost 的开源，又会给 K8s 生态带来哪些影响呢？带着这些问题，我们与 Nocalhsot 的设计者之一、新晋 CNCF 大使、云原生社区成员，来自腾讯 …","relpermalink":"/blog/interview-with-cncf-ambassador-wangwei/","summary":"Nocalhost 的开源，又会给 K8s 生态带来哪些影响呢？带着这些问题，我们与 Nocalhsot 的设计者之一、新晋 CNCF 大使、云原生社区成员，来自腾讯云 CODING DevOps 的王炜，详细聊聊关于 Nocalhost 的产品、技术和生态。","title":"专访 CNCF 大使王炜：让云原生开发回归原始而又简单"},{"content":"本文译自 Cloud-Native Is about Culture, Not Containers，文章洋洋洒洒上万字，作者总结了她见过的云原生失败的各种经验教训，还用生动的示例说明了什么不是云原生。译者是在周末闲暇时间仓促间翻译的，其中难免有不当之处，请读者指正。\n本文主要观点：\n不需要一味的微服务，就可以做到非常的云原生。 在开始云原生转型之前，必须明确云原生对你的团队意味着什么，以及要解决的真正问题是什么。 如果发布涉及繁琐的仪式，不经常发布，而且所有的微服务都必须同时发布，那么微服务架构的好处将无法得到落实。 持续集成和部署是你要做的事情，而不是你买的工具。 过度的治理扼杀了云的效率，但如果你对消耗的东西不够重视，就会造成严重的浪费。 在去年的伦敦 QCon 大会上，我提供了一个关于文化而非容器的云原生会议。让我开始思考文化在云原生中的作用的是 Bilgin Ibryam 一篇很棒的 InfoQ 文章。Bilgin 做的其中一件事是将云原生架构定义为很多微服务，通过智能管道连接。我看了之后，觉得它看起来完全不像我写的应用，尽管我认为我在写云原生应用。我是 IBM Garage …","relpermalink":"/blog/cloud-native-culture-not-container/","summary":"作者总结了她见过的云原生失败的各种经验教训，还用生动的示例说明了什么不是云原生。","title":"云原生关乎文化，而不是容器"},{"content":"本文根据腾讯云赵化冰和知乎唐阳在 IstioCon 2021 中的演讲 “How to Manage Any Layer-7 Traffic in an Istio Service Mesh?” 整理而成。\n大家好，今天我们想和大家分享的主题是如何扩展 Istio 以支持任何七层协议？作为云原生领域中一个人气非常高的开源项目，Istio 目前已经基本成为了 Service Mesh 的事实标准。腾讯云上也提供了基于 Istio 进行增强，和 Istio API 完全兼容的 Service Mesh 管理服务 TCM（Tencent Cloud Mesh），以帮助我们的用户以较小的迁移成本和维护代价快速利用到 Service Mesh 提供的流量管理和服务治理能力。今天非常高兴能够有这个机会来和大家一起分享一下我们在此过程中的一些经验。\nService Mesh 提供了一个对应用透明的基础设施层，可以解决我们在分布式应用/微服务中遇到的常见挑战，例如：如何找到服务提供者？如何保证服务之间的通信安全？如何得知服务之间的调用关系？如何进行流量管理如灰度发布？等等。Service Mesh 的 …","relpermalink":"/blog/istiocon-layer7-traffic/","summary":"本文根据腾讯云赵化冰和知乎唐阳在 IstioCon 2021 中的演讲 How to Manage Any Layer-7 Traffic in an Istio Service Mesh? 整理而成。","title":"使用 Aeraki 在 Isito 中支持 Dubbo、Thrift、Redis，以及任何七层协议"},{"content":"背景 要想深入学习 istio，还得学习下数据面的实现，istio 的数据面使用了 envoy，在 istio group 下有个叫 proxy 的仓库，包含了一些 istio 用到的一些 envoy 扩展，编译时将 envoy 代码作为库来引用，最终使用 bazel 编译出 istio 版本的 Envoy。\n代码量非常庞大，如果没有智能的代码跳转、查找引用与实现，阅读和开发起来简直低效的要命。如何更加高效呢？关键在于 IDE/编辑器 的代码索引能力要好，需要能够准确跳转和查询，vscode 用的同学比较多，但它的 c/c++ 插件不够智能，很多情况无法跳转，而且效率较低；它还有个 clangd 的插件，基于 LSP，但不够成熟。这方面做的最好的目前还是来自 JetBrains 的 CLion，不过它需要依赖 CMakeLists.txt 文件来解析项目结构，由于 c/c++ 没有统一的结构标准，不同项目结构千差万别，不太好自动生成 CMakeLists.txt，需要我们先理解项目结构，然后编写 CMakeLists.txt 来让 CLion 进行解析。\n虽然社区有人针对 bazel  …","relpermalink":"/blog/use-clion-read-envoy-source/","summary":"本文介绍如何使用 CLion 来阅读和开发 istio-proxy (envoy) 的代码。","title":"使用 CLion 搭建 istio-proxy (envoy) 开发环境"},{"content":"前言 2021 年伊始，如果你想要在生产环境中落地 Service Mesh，那 Istio 一定已经在你的考虑范围之内。\nIstio 作为目前最流行的 Service Mesh 技术之一，拥有活跃的社区和众多的落地案例。但如果你真的想在你的生产环境大规模落地 Isito，这看似壮观美好的冰山下，却是暗流涌动，潜藏着无数凶险。\n本文是笔者深度参与百亿量级流量生产环境研发和落地 Istio 两年来的经验总结和一些思考，以期读者在自己生产环境引入 Isito 前，能有所参考和启发，做好更充足的准备，能更轻松的“入坑”Istio。\n如果你对 Service Mesh 的概念还不甚了解，可先行阅读《云原生时代，你应该了解的 Service Mesh》。\n使用 Isito 前的考虑要素 使用 Istio 无法做到完全对应用透明 服务通信和治理相关的功能迁移到 Sidecar 进程中后，应用中的 SDK 通常需要作出一些对应的改变。\n比如 SDK 需要关闭一些功能，例如重试。一个典型的场景是，SDK 重试 m 次，Sidecar 重试 n 次，这会导致 m * n 的重试风暴，从而引发风险。\n此 …","relpermalink":"/blog/the-facts-of-using-istio/","summary":"深度落地 Istio 两年的若干思考。","title":"在生产环境使用 Istio 前的若干考虑要素"},{"content":"Istio 是云原生世界中最受欢迎、发展最迅速的开源项目之一；虽然这种增长充分说明了用户从 Istio 中获得的价值，但其快速的发布节奏对于用户来说也是一种挑战，因为他们可能要同时管理多个不同版本的 Istio 集群，并为云平台手动配置 CA 证书。\n概述 我们今天推出了一个名为 GetIstio 的新开源项目，为用户提供了安装和升级 Istio 的最简单方法。GetIstio 提供了一个经过审核的 Istio 上游发行版–Istio 的强化镜像，并提供持续的支持，安装、管理和升级更加简单。它将与云原生和流行的 on-prem 证书管理器（如 AWS ACM、Venafi 等）进行整合。此次发布的内容包括：\nGetIstio CLI，最简单的方式来安装，操作和升级 Istio。GetIstio 提供了一个安全的、经过审核的、上游的 Istio 发行版，经过 AKS、EKS 和 GKE 的测试。 免费的 Istio 基础在线课程，现在可以在 Tetrate 学院获得。 一个新的社区，汇集了 Istio 和 Envoy 用户和技术合作伙伴。 GetIstio CLI GetIstio 是一 …","relpermalink":"/blog/getistio-launching/","summary":"GetIstio 为用户提供了安装和升级 Istio 的最简单方法。","title":"Tetrate 开源 GetIstio：简单、安全、企业级的 Istio 发行版"},{"content":"本文来自酷家乐先进技术工程团队，作者罗宁，酷家乐资深开发工程师。\n公司背景 酷家乐公司以分布式并行计算和多媒体数据挖掘为技术核心，推出的家居云设计平台，致力于云渲染、云设计、BIM、VR、AR、AI 等技术的研发，实现“所见即所得”体验，5 分钟生成装修方案，10 秒生成效果图，一键生成 VR 方案的 SAAS 云端软件服务平台。\n核心问题 公司快速增长的业务需求，使得支持各开发语言的 Serverless 设施在国内外六个 Kubernetes 集群上线落地，但公司现状已有一套成熟的自研 Java 服务服务治理系统，承载了部署在 Kubernetes / KVM 平台的上千服务。这两者的服务治理体系完全不同，如何打通之间的调用顺利落地 Serverless 平台为产品功能研发增加效能呢？\n策略制定 酷家乐使用的成熟开源 Serverless 设施是依赖于 Istio 服务网格的 Knative，在 Kubernetes 集群中 Istio 提供的灵活又强大的动态路由/流量管理功能，配上一些相关的网关设施，不仅可以巧妙的解决不同体系服务相互调用的问题，且依旧保持了在酷家乐目前治理体系下 …","relpermalink":"/blog/coohom-istio-practice/","summary":"酷家乐的 Istio 使用实践分享。","title":"酷家乐如何使用 Istio 解决新服务治理系统（Serverless）接入已有成熟自研 Java 服务治理体系"},{"content":"本文为我跟 Ignasi Barrera 共同创作，本文英文版首发于 TheNewStack。\n不同的公司或软件供应商已经设计了无数种方法来控制用户对功能或资源的访问，如酌情访问控制（DAC）、强制访问控制（MAC）、基于角色的访问控制（RBAC）和基于属性的访问控制（ABAC）。从本质上讲，无论何种类型的访问控制模型，都可以抽象出三个基本要素：用户、系统 / 应用和策略。\n在本文中，我们将介绍 ABAC、RBAC 以及一种新的访问控制模型 —— 下一代访问控制（NGAC），并比较三者之间的异同，以及为什么你应该考虑 NGAC。\n什么是 RBAC？ RBAC，即基于角色的访问控制，采用的方法是根据用户在组织中的角色授予（或拒绝）对资源的访问。每个角色都被分配了一系列的权限和限制，这很好，因为你不需要跟踪每个系统用户和他们的属性。你只需要更新相应的角色，将角色分配给用户，或者删除分配。但这可能很难管理和扩展。使用 RBAC 静态角色模型的企业经历了角色爆炸：大公司可能有数万个相似但不同的角色或用户，他们的角色会随着时间的推移而改变，因此很难跟踪角色或审计不需要的权限。RBAC 具有固定的 …","relpermalink":"/blog/why-you-should-choose-ngac-as-your-access-control-model/","summary":"本文将向你介绍下一代权限控制模型——NGAC，并对比 ABAC、RABC，说明为什么要选择 NGAC。","title":"为什么应该选择使用 NGAC 作为权限控制模型"},{"content":"前言 随着业务的快速发展，技术部门的组织架构在横向及纵向不断扩大和调整，与此同时，企业的生产资料：应用系统，也变得越来越庞大。为了让应用系统适配企业组织架构的调整，梳理组织架构对于应用权责的边界，大部分组织会选择使用“微服务”架构来对应用系统进行横向拆分，使得应用系统的维护边界适配组织架构的权责边界。\n一般来说，越庞大的组织架构，应用系统会被拆分地越来越细，“微服务”的数量也变得越来越多。而在“微服务”的拆分的实践中，很容易出现将组织架构的权责边界一股脑地对标到“微服务”的拆分粒度中，这可能导致“微服务”拆分粒度过细，数量进一步剧增的问题。最终，“微服务”之间的调用关系就像跨部门协作，也变得越来越复杂，问题在想要新增需求时尤为突出。\n“微服务”带来便利的同时，对开发人员而言，还带来了额外的挑战：如何快速启动完整的开发环境？开发的需求依赖于其他同事怎么联调？如何快速调试这些微服务？\n而对于管理人员来说，也同样带来了一系列的挑战：如何管理开发人员的开发环境？如何让新入职的同事快速进行开发？\n试想一下，要开发由 200 个“微服务”组成的云原生应用，会遇到哪些困难呢？\nLocalhost 时 …","relpermalink":"/blog/nocalhost-redefine-cloud-native-dev-environment/","summary":"“微服务”带来便利的同时，对开发人员而言，还带来了额外的挑战：如何快速启动完整的开发环境？开发的需求依赖于其他同事怎么联调？如何快速调试这些微服务？","title":"Nocalhost - 重新定义云原生开发环境"},{"content":"背景 Istio 作为当前最活跃的 service mesh 项目，提供着众多的能力，流量管理，安全性，可观察性，每一项能力都是服务治理，运维所必需的。Istio 丰富的能力同时也带来一定性的复杂系统运维的挑战，但是相对于能力以及未来的扩展性，Istio 能力给服务治理带来了无限的想象，机遇同时充满着挑战。\n当前涂鸦智能前端业务 Istio 控制面版本为 1.5.0，接入 Istio 控制面 700 + 服务，1100+pod 实例，承担涂鸦智能前端最大的业务集群的流量管控和能力支撑。\n涂鸦智能在开发流程上存在的问题 前端基础团队 2018 年开始接触 Kubernetes，并基于 kubernetes 自建了发布平台服务于前端业务团队，但随着业务团队越来越大，开发发布流程上开始出现一些问题：\n多分支并行开发的验证问题 多地域环境带来的配置复杂性导致的线上问题 最开始考虑让业务团队自己内部调整处理，但由于出现问题的团队越来越多，我们开始考虑通过灰度发布能力来解决这些开发发布流程上的问题，在日常预发环境，多个分支发布多个灰度版本，根据不同的 header 分发流量到不同版本， …","relpermalink":"/blog/tuya-istio-case/","summary":"涂鸦智能使用 Istio 的实践分享。","title":"涂鸦智能的 Istio 企业级生产环境的实践"},{"content":"本文为翻译文章，点击查看原文。\nIstio 1.9 版本的重点是改善用户在生产中运行 Istio 的 Day2 操作。在用户体验工作组收集到的反馈意见的基础上，我们希望改善用户的稳定性和整体升级体验。稳定性的一个关键是明确 Istio 核心 API 和功能发布的功能状态，并增强它们的稳定性，使用户能够放心使用 Istio 的这些功能，这是 1.9 版本的另一个重点。\n请关注我们的博客，了解我们的 2021 年路线图，我们将在那里展示我们对持续改善 Day 2 体验的关注。\n感谢我们的用户参与了用户体验调查和共鸣会，帮助我们确保 Istio 1.9 是迄今为止最稳定的版本。\n这是 2021 年的第一个 Istio 版本。我们要感谢整个 Istio 社区，特别是发布经理 Shamsher Ansari（Red Hat）、Steven Landlow（Google）和 Jacob Delgado（Aspen Mesh），感谢他们帮助我们发布 Istio 1.9.0。\nIstio 1.9.0 正式支持 Kubernetes 1.17.0 至 1.20.x 版本。\n以下是本次发布的一些亮点。\n虚 …","relpermalink":"/blog/istio-19-release/","summary":"北京时间 2021 年 2 月 10 日晨，Istio 1.9 发布，这是 2021 年的第一个版本。","title":"Istio 1.9 发布"},{"content":"2020 年是云原生社区的起步之年，感谢所有云原生社区的参与者和合作伙伴们！在此新春佳节之际，祝大家新春快乐，万事如意！\n下面我们一起回顾下云原生社区在过去一年来的进展，同时感谢社区讲师、贡献者、志愿者、SIG 负责人和城市站站长。\n城市站 云原生社区相继成立了北京站、上海站、成都站、深圳站、南京站、杭州站等 20 个城市站。\n北京站 社区由核心成员罗广明、王殿进、王福印来组织与筹划社区发展与线下活动等事宜。我们热爱开源事业，热爱云原生技术。希望有更多人加入社区，一起组织线下活动，在北京推广云原生技术。\n2020 年 8 月 30 日，云原生社区北京站成立活动。\n2020 年 12 月 20 日，云原生社区 meetup，第二期，北京站合影。\n在中场环节《云原生操作系统 Kubernetes》作者之一张城在签字售书。\n本次活动由云原生社区及 Tetrate 联合举办，感谢中国信通院 CCSA、电子工业出版社博文视点赞助，Dubbo Go 社区、ServiceMesher 社区及 CNCF 的大力支持。\n上海站 云原生社区上海站成立于 2020 年 8 月，由核心成员郭旭东、沈旭、任增 …","relpermalink":"/blog/community-summary-2020/","summary":"感谢过去一年来所有云原生社区的参与者及合作伙伴们！","title":"云原生社区 2020 年度总结及证书颁发"},{"content":"Problem 网易作为一家拥有众多互联网业务的公司，不同业务结合自身的业务特性、团队组成均有一些微服务技术栈选择、体系建设，这在业务发展初期并没有问题。当业务持续发展，不管业务规模、复杂度、团队的组成都发生了变化，这时候微服务架构就会遇到诸多问题：\n各业务分别投入研发，研发成本高 网易集团技术资产无法沉淀 微服务框架对业务侵入性大，需要业务人员明显感知、学习、掌控和维护 升级周期长，即使是很小版本的框架升级，都需要动辄 1 个月以上的升级周期 语言局限，绝大多数核心业务的微服务体系基于 Java 语言构建，对其他语言支持薄弱 Strategy Service Mesh 是云原生体系下重要的微服务技术，可以有效的解决网易诸多互联网业务在微服务架构下存在的问题。网易选择 Istio 这一有代表性的 Service Mesh 开源框架有着深刻的考虑：\n有深厚的云原生背景及大厂背书 Istio 的核心数据面组件 Envoy 是云原生数据面的事实标准组件 在 Service Mesh 领域，Istio 是最为流行的框架选择，有着活跃的技术社区和优秀的技术架构 Istio 在帮助企业落地、框架易 …","relpermalink":"/blog/netease-qingzhou-istio/","summary":"网易轻舟使用 Istio 的实践分享。","title":"网易轻舟如何基于 Istio 实现微服务架构演进"},{"content":"Kubernetes 作为 eBay 的统一云平台，统管了在线业务、大数据、搜索后台等多种异构应用。集群数量高达上百，其中的大型集群中，单个集群运行数千个微服务，数十万 Pod。不同类型的应用，针对流量管控的需求也各有不同，如何用一套统一的模型将各种流量管控需求统一起来是 eBay 多年来一直面临的挑战。\n以云应用为例，为实现跨数据中心高可用的需求，生产应用的网络拓扑可以简要描述如下：\neBay 采用多活数据中心的网络拓扑，因此任何生产应用都需要完成跨三个数据中心的部署。 为满足单集群的高可用，针对每个数据中心，任何应用都需进行多副本部署，并配置负载均衡。 以实现全站微服务化，但为保证高可用，服务之间的调用仍以南北流量为主。 针对核心应用，除集群本地负载均衡配置以外，还需配置跨数据中心负载均衡，并通过权重控制将 99% 的请求转入本地数据中心，将 1% 的流量转向跨地域的数据中心。该配置的主要目的是当某应用的所有本地服务实例失效时，运维可快速将跨数据中心负载均衡器上指向本地的 99% 流量的成员禁止掉，流量可在秒级转向其他数据中心从而保护业务不受影响。业务版本发布、硬件故障、防火墙、路 …","relpermalink":"/blog/ebay-istio/","summary":"eBay 的 Istio 使用实践分享。","title":"eBay 基于 Istio 的统一流量管理实践"},{"content":"很荣幸收到 CSDN 的邀请，接受”云原生人物志“专栏采访，其实我从 2017 年起就已经在撰写 Kubernetes 和云原生年度总结和新年展望，今天在此聊抒己见，欢迎大家讨论和指正。\n云原生在演进 云原生是一种行为方式和设计理念，究其本质，凡是能够提高云上资源利用率和应用交付效率的行为或方式都是云原生的。云计算的发展史就是一部云原生化的历史。Kubernetes 开启了云原生 1.0 的序幕，服务网格 Istio 的出现，引领了后 Kubernetes 时代的微服务，serverless 的再次兴起，使得云原生从基础设施层不断向应用架构层挺进，我们正处于一个云原生 2.0 的新时代。\n业界动向 最近国内的一些云厂商，如阿里云、腾讯云、华为云陆续发布了各自的云原生相关的架构和实践白皮书。\n2020 年 7，中国信通院发布了《云原生产业白皮书（2020）》。 2020 年 12 月 20 日，在腾讯 2020 Techo Park 开发者大会上，腾讯云正式发布了《云原生最佳实践路线图》，同时发布的还有一份 3 万多字的《腾讯云原生路线图手册》。 2020 年 12 月 23 日，阿里云 …","relpermalink":"/blog/cloud-native-2021/","summary":"本文为应 CSDN《云原生人物志》栏目专访，知微见著，窥见云原生价值与趋势。","title":"“寒武纪大爆发”之后的云原生，2021 年走向何处？"},{"content":"注：本文是本人在云原生社区直播分享的内容整理，视频见 B 站，PPT 可以在 GitHub 下载。\nSlime 是网易数帆微服务团队开源的服务网格组件，它可以作为 Istio 的 CRD 管理器，旨在通过更为简单的配置实现 Istio/Envoy 的高阶功能。目前 slime 包含三个非常实用的子模块：\n配置懒加载：无须手动配置 SidecarScope，按需加载配置和服务发现信息 Http 插件管理：使用新的的 CRD pluginmanager/envoyplugin包装了可读性，摒弃了可维护性较差的envoyfilter，使得插件扩展更为便捷 自适应限流：结合监控信息自动调整限流策略 后续我们团队会开放更多实用功能在 slime 中，希望 slime 能帮助使用者更好的驾驭 Istio 这艘小帆船 1. 背景 服务网格作为新一代微服务架构，采用 sidecar 模式，实现了业务逻辑和微服务治理逻辑的物理解耦，降低微服务框架的开发与运维成本。权责清晰，易维护，可观测，多语言支持等一些列优势使其逐渐成为微服务话题中的焦点。而 Istio+Envoy …","relpermalink":"/blog/netease-slime/","summary":"Slime 是网易数帆微服务团队开源的服务网格组件，它可以作为 Istio 的 CRD 管理器，旨在通过更为简单的配置实现 Istio/Envoy 的高阶功能。","title":"Slime：让 Istio 服务网格变得更加高效与智能"},{"content":"本文译自 Service Mesh Comparison: Istio vs Linkerd。\n根据 CNCF 的最新年度调查，很明显，很多人对在他们的项目中使用服务网格表现出了极大的兴趣，并且许多人已经在他们的生产中使用它们。将近 69％ 的人正在评估 Istio，64％ 的人正在研究 Linkerd。Linkerd 是市场上第一个服务网格，但是 Istio 的服务网格更受欢迎。这两个项目都是最前沿的，而且竞争非常激烈，因此选择哪一个是一个艰难的选择。在此博客文章中，我们将了解有关 Istio 和 Linkerd 的架构，其及组件的更多信息，并比较其特性以帮你做出明智的决定。\n服务网格简介 在过去的几年中，微服务架构已经成为设计软件应用程序的流行风格。在这种架构中，我们将应用程序分解为可独立部署的服务。这些服务通常是轻量级的、多语言的，并且通常由各种职能团队进行管理。直到这些服务的数量变得庞大且难以管理之前，这种架构风格效果很好。突然之间，它们不再简单了。这在管理各个方面（例如安全性、网络流量控制和可观察性）带来了挑战。服务网格可以帮助应对这些挑战。\n术语服务网格用于描述组成此类应用 …","relpermalink":"/blog/service-mesh-comparison-istio-vs-linkerd/","summary":"本文翻译自 Anjul Sahu 的文章 Service Mesh Comparison: Istio vs Linkerd。","title":"服务网格比较：Istio 与 Linkerd"},{"content":"非常有幸参加了云原生社区 Meetup 北京站，有机会和众多业内的大牛一起讨论云原生相关的技术和应用，本次 Meetup 上我和大家分享了关于云原生下的可观测性相关的议题，相关的视频可以移步《B 站视频回放：云原生下的可观测性》回看，本篇文章主要是视频的文字性总结，欢迎大家留言讨论。\n可观测性的由来 可观测性最早来自于电气工程领域，主要原因是随着系统发展的逐步复杂，必须要有一套机制用来了解系统内部的运行状态以便更好的监控和问题修复，为此工程师们设计了很多传感器、仪表盘用于表现系统内部的状态。\nA system is said to be observable if, for any possible evolution of state and control vectors, the current state can be estimated using only the information from outputs.\n电气工程发展了上百年，其中各个子领域的可观测性都在进行完善和升级，例如交通工具（汽车 / 飞机等）也算的是可观测性上的集大成者。抛开飞机这种超级工程不谈，一辆可 …","relpermalink":"/blog/cloud-native-observability/","summary":"本文来自云原生社区 meetup 北京站的分享。","title":"解读：云原生下的可观测性发展方向"},{"content":"本文译自 Envoy 官方文档 HTTP connection management\nHTTP 连接管理 HTTP 是现代面向服务体系架构的重要组成部分，Envoy 实现了大量的 HTTP 特定功能。Envoy 内置了一个叫 HTTP 连接管理器 的网络层过滤器。此过滤器将原始字节转换为 HTTP 协议的消息和事件，例如，请求头接收、请求体数据接收、请求标尾 (trailers) 接收等。过滤器同时处理所有 HTTP 连接和请求的通用功能，例如 访问日志、 请求 ID 生成与追踪、 请求头/响应头的操作、 路由表 管理和 统计。\nHTTP 连接管理器 配置。\nHTTP 协议 Envoy 的 HTTP 连接管理器原生支持 HTTP/1.1、WebSockets 和 HTTP/2。现在还不支持 SPDY。Envoy HTTP 设计的首要目标是成为一个 HTTP/2 多路复用代理。在内部，HTTP/2 术语用于描述系统组件。例如，一个 HTTP 请求和响应发生在流上。一个编解码 API 被用来将不同的电报协议转换为流、请求、响应等协议无关的格式。对于 HTTP/1.1 来说，编解码器将协议的 …","relpermalink":"/blog/envoy-http-connection-management/","summary":"本文翻译自 Envoy 官方文档，介绍内置网路层过滤器 HTTP 连接管理器。","title":"Envoy HTTP 连接管理"},{"content":"在任何公司，网络用户必须经过认证和授权，才能访问系统中可能导致安全漏洞的部分。获得授权的过程称为访问控制。在本指南中，我将讨论管理系统访问控制的两种主要方法 —— 基于角色的访问控制（RBAC）和基于属性的存取控制（ABAC）它们的差异，以及使用访问权限管理工具的重要性。\n认证和授权 安全的两个基本方面是认证和授权。在您输入凭证登录电脑或登录应用程序或软件后，设备或应用程序会进行身份验证，以确定您的授权级别。授权可能包括您可以使用哪些账户，您可以访问哪些资源，以及允许您执行哪些功能。\n基于角色的访问控制（RBAC）与基于属性的访问控制（ABAC） 基于角色的访问控制（RBAC）和基于属性的访问控制（ABAC）是控制认证过程和授权用户的两种方法。RBAC 和 ABAC 之间的主要区别是 RBAC 基于用户角色提供对资源或信息的访问，而 ABAC 基于用户、环境或资源属性提供访问权限。从本质上讲，当考虑 RBAC 与 ABAC 时，RBAC 控制整个组织的广泛访问，而 ABAC 则采取细粒度的方法。\n什么是 RBAC？ RBAC 是基于角色的，所以根据你在组织中的角色而拥有不同的访问权限。 …","relpermalink":"/blog/rbac-vs-abac/","summary":"本文主要研究了 RBAC 和 ABAC 这两种访问能控制之间的异同。","title":"RBAC vs ABAC，两者有何异同？"},{"content":"直到最近，最流行的授权方法是基于角色的访问控制（RBAC）。这种解决方案涉及到创建一套角色，定义组织内所有的工作描述和功能，然后给用户分配角色，决定他们可以访问的内容（例如，文件、网络、应用程序、网页上的一个字段），以及他们可以执行的操作。\n当使用 RBAC 时，系统管理员可以控制用户可以对特定的 IT 资源做什么，以及他们可以访问哪些区域。它的实现很简单，因为只有三个基本原则需要牢记，角色是基于“角色分配”、“角色授权“和“权限授权“的。然而，RBAC 并非没有问题和局限性。其中一个主要问题是，它不是一个自动的过程，这意味着它需要进行艰苦的管理，并且经常涉及大量的人工干预。\n例如，假设你的组织结构图已经和你的员工名单以及他们的头衔一起最终确定，你已经准备好推出你的 RBAC 计划。你已经把所有的角色摆在你面前，你很自信，他们都有明确的定义，并且有正确的汇报线和控制范围。突然间，市场部副总裁提到，他们部门里有一些人需要访问某些资源、共享文件夹和专门的应用程序，而这些资源和应用程序只有其他部门的角色才能使用。你不能对副总裁说“不”，所以你检查已有的映射，并试图找到一组额外的符合要求的角 …","relpermalink":"/blog/problem-with-rbac/","summary":"本文主要讲述了 RBAC 面临的主要挑战。","title":"基于角色的访问控制（RBAC）存在的问题"},{"content":"在 Envoy 网关和 Service Mesh 服务网格落地过程中，大部分组织和公司几乎不可避免的需要对 Envoy 做一些二次开发和功能增强，以应对自身的个性化需求，只是或多或少的问题。虽然 Envoy 本身基于 L4/L7 Filter 提供了非常灵活可扩展性，可以让开发者在各个层级对 Envoy 进行扩展。然而以现有的 Filter 开发流程太过繁琐沉重。一个简单的功能扩展都需要重新构建整个 Envoy，升级和部署也涉及到服务重启等问题。\n为此，Envoy 社区在 Envoy 中嵌入了 WASM 虚拟机以获得一个安全的沙箱环境，用于动态加载和运行可拔插的扩展代码（被编译为 WASM 字节码），简化 Envoy 二次开发和功能增强的复杂度。实际上，在 Envoy 社区将该特性合入主干之前，Istio 社区就已经在力推该特性，并基于该特性重写了部分的功能扩展。\n网易数帆旗下轻舟云原生团队也一直在关注社区的进展和动态。轻舟微服务在各个业务方落地的过程中，业务方的定制化需求往往难以避免，而随着业务方的不断增多，如何管理这些不断横向膨胀的定制化需求，避免它们成为轻舟微服务产品本身演进的负 …","relpermalink":"/blog/envoy-wasm-source-deep-dive/","summary":"本文旨在从源码角度解析 Envoy 和 WASM 沙箱是如何桥接的。希望读者通过阅读本文，能够对 Envoy WASM 的接入有一定的了解。在实践的过程之中，能够帮助读者在繁杂的类型关系和调用链路中理清思路。本文默认读者具备一定的 Envoy 知识基础并且对 Envoy Filter 机制具备一定的了解。如果仅仅是希望使用 WASM 而不需要深入了解或者二次开发 Envoy WASM，那么可以阅读 SDK 文档即可。","title":"Envoy WASM 源码抽丝剥茧"},{"content":"Istio 1.8——还是从前那个少年 讲师：宋净超（Tetrate 布道师、云原生社区创始人）\n个人介绍：Tetrate 布道师、CNCF Ambassador、云原生社区 创始人、电子工业出版社优秀译者、出品人。Kubernetes、Istio 等技术的早期使用及推广者。曾就职于科大讯飞、TalkingData 和蚂蚁集团。\n议题简介：带你回顾 Istio 的发展历程，看他是否还是从前那个少年，“没有一丝丝改变”，能够经历时间的考验。带你一起来了解 Istio 1.8 的新特性，看它是如何作为传统和现代应用的桥接器，成为云原生应用中的中流砥柱。同时也会为你分享云原生社区的规划，为了推行云原生，我们在行动。\n百度服务网格在金融行业的大规模落地实践 讲师：孙召昌（百度高级研发工程师）\n个人介绍：百度高级研发工程师，现就职于百度基础架构部云原生团队，参与了服务网格产品的研发工作和大规模落地实践，对云原生、微服务、Service Mesh 等方向有深入的研究和实践经验。\n议题简介：百度服务网格技术在金融行业大规模落地过程的实践经验和思考，主要包括：\n支持传统微服务应用的平滑迁移， …","relpermalink":"/event/cloud-native-meetup-beijing-02/","summary":"本次活动关注 Istio、云原生存储、可观测性、DubboGo 等。","title":"云原生社区 meetup 第二期北京站"},{"content":"本文译自 Creating a Cloud Security Policy\n任何想要保护他们自己云资产的公司都需要云安全策略。安全策略有助于保持云数据的安全，且能赋予快速应对威胁和挑战的能力。\n文章将解释云安全策略的价值。请继续阅读来了解这些策略都包含什么、它们能够带来什么收益以及如何为你的业务作出正确的选择。\n什么是云安全策略？ 云安全策略是公司在云运营过程中的一些正式准则。这些指导定义了安全策略，对于所有对云资产安全的决策进行指导。云安全策略指：\n能够或不能够迁移至云上的数据类型 团队如何应对每种数据类型的风险 将负载迁移至云上的决定由谁来做 谁应该被授权来对数据进行访问或者迁移 法规条款和当前合规状态 正确应对威胁，黑客攻击和数据泄漏 围绕风险优先级的规则 云安全策略是一个公司安全项目中的重要组成部分。安全策略能够保证信息的完整性和私密性，而且能够帮助团队快速作出正确的决定。\nimg 云安全策略的必要性 尽管云计算能够带来很多收益，但是云计算服务也具有一些安全隐患：\n第三方设置中缺乏安全控制 多云环境中可见性差 有足够的空间来窃取和滥用数据 云是 DDos 攻击 的常见目标 攻击 …","relpermalink":"/blog/cloud-security-policy/","summary":"本文翻译自 Andreja Velimirovic 的文章 Creating a Cloud Security Policy","title":"云安全策略的创建"},{"content":"本文译自 Contributing to the Development Guide\n我猜大多数人提到为开源项目做贡献，他们想到的是贡献代码变更、新的功能以及修复缺陷。作为一个长期使用开源应用并贡献了很多代码的软件开发工程师来说，我也确实是这么想的。尽管我已经在同的工作流中贡献了大量的文档，但这么大的 Kubernetes 社区对我来说仍然是个新工作对象。当 Google 要求我的同胞和我在 Lion’s Way 上对《Kubernetes 开发指南》进行急需的更新时，我还是不知道会发生什么。\n和社区合作的乐趣 作为一个专业作家，我们习惯于被雇来写一些具体的作品。我们专门从事技术服务和产品的营销、培训和文档，范围从相对宽松的营销电子邮件到针对 IT 和开发人员的深入技术白皮书。凭借这种专业服务，每一项交付成果往往都有可衡量的投资回报。我也知道，做开源文档会和之前做的项目标准不一样，但我还是预测不了它是如何改变我和项目之间的关系的。\n我们贡献开源项目文档和之前给传统客户做工作，一个主要的特点就是，我们和公司内部总会有一两个主要的负责人。有这些负责人来审阅我们的文章，并保证文章是按公司想要 …","relpermalink":"/blog/contributing-to-the-development-guide/","summary":"一个新的贡献者讲述为《Kubernetes 开发指南》做贡献的经验。","title":"为《Kubernetes 开发指南》提交贡献"},{"content":"Kubernetes 不再是（只是）好玩的游戏了。它正在被用于生产；它是关键任务；所有旧有的安全和合规规则和法规都需要以某种方式加装到 Kubernetes 上。不幸的是，像 RBAC 这样的旧的访问控制工具根本无法应对挑战。\n概述 Kubernetes API 的设计与大多数现代 API 不同。 它是基于意图的，这意味着使用 API 的人考虑的是他们想要 Kubernetes 做什么，而不是如何实现。其结果是一个令人难以置信的可扩展性、弹性，和一个强大而流行的系统。 同时，其基于意图的 API 给安全带来了挑战。 标准的访问控制解决方案（基于角色的访问控制、基于属性的访问控制、访问控制列表或 IAM 策略）都不够强大，无法强制执行基本的策略，比如谁可以更改 pod 上的标签，或者哪些镜像存储库是安全的。 Kubernetes Admission Control 就是为了解决这个问题而设计的。 Kubernetes Admission Controller 并不能解决开箱即用的访问控制问题，但它们允许你使用 Webhook 来解决授权挑战与解耦策略。 Kubernetes …","relpermalink":"/blog/why-rbac-is-not-enough-for-kubernetes-api-security/","summary":"所有旧有的安全和合规规则和法规都需要以某种方式加装到 Kubernetes 上。不幸的是，像 RBAC 这样的旧的访问控制工具根本无法应对挑战。","title":"为什么 RBAC 不足以保障 Kubernetes 的安全？"},{"content":"本文译自 Envoy 官方文档 What is Envoy\nEnvoy 是为面向大型现代服务架构而设计的 L7 代理和通信总线。该项目源于以下理念：\n对于应用来说网络应该是透明的。当网络和应用出现故障时，应该非常容易定位问题发生的根源。\n事实上，实现上述的目标非常困难。Envoy 试图通过提供以下高级功能来实现这一目标：\n进程外架构：Envoy 是一个独立进程，伴随每个应用服务运行。所有的 Envoy 形成一个透明的通信网格，每个应用与 localhost 收发信息，对网络的拓扑结构无感知。在服务间通信的场景下，进程外架构对比传统软件库的方式有两大优势：\nEnvoy 适用于任何应用编程语言。Envoy 部署可以在 Java、C++、Go、PHP、Python 等不同语言编写的应用之间形成一个网格。在面向服务架构中，使用多种应用框架和编程语言变得越来越普遍。Envoy 弥合了它们之间的差异。 任何与面向大型服务架构打过交道的人都知道部署和升级软件库非常的痛苦。Envoy 可以透明地在整个基础架构上快速部署和升级。 L3/L4 filter 架构：Envoy 的核心是一个 L3/L4 网络 …","relpermalink":"/blog/what-is-envoy/","summary":"本文翻译自 Envoy 官方文档，从高层介绍 Envoy。","title":"Envoy 是什么？"},{"content":"今天，我们发布了 Amazon EKS Distro（EKS-D），这是一个基于 Amazon Elastic Kubernetes Service（Amazon EKS）的 Kubernetes 发行版，并由 Amazon EKS 用于创建可靠和安全的 Kubernetes 集群。通过 EKS-D，你可以依赖 EKS 部署的相同版本的 Kubernetes 及其依赖项。这包括最新的上游更新以及扩展的安全补丁支持。EKS-D 遵循与亚马逊 EKS 相同的 Kubernetes 版本发布周期，我们以 GitHub 上的开源项目的方式 提供。\n在这篇文章中，我们将介绍 EKS Distro，并使用合作伙伴生态系统中的例子来解释开始使用 EKS Distro 的不同方法。\n什么是 EKS-D？ 通过 EKS Distro，你现在可以在通过 EKS 提供的相同 Kubernetes 发行版上实现标准化。这意味着你现在可以手动部署可靠和安全的集群，而无需持续测试和跟踪 Kubernetes 更新、依赖性和安全补丁。每个 EKS Distro 版本都遵循 EKS 验证新 Kubernetes 版本 …","relpermalink":"/blog/introducing-amazon-eks-distro/","summary":"本文介绍 EKS Distro，并使用合作伙伴生态系统中的例子来解释开始使用 EKS Distro 的不同方法。","title":"亚马逊 EKS 发行版（EKS-D）介绍"},{"content":" 演讲幻灯片及视频回放请点击页面上方的按钮。 开场演讲 讲师：宋净超\n公司：Tetrate\n讲师介绍：Tetrate 布道师，云原生社区创始人，CNCF Ambassador。\nKubernetes 在 UCloud 内部的应用 讲师：高鹏\n公司：UCloud\n讲师介绍：高鹏 UCloud 后台研发工程师，负责内部云原生平台的建设。\n演讲概要：在 Kubernetes 的实际应用中，我们会碰到各种各样的问题，比如复杂的网络结构、持久化存储的实现、多租户的权限模型、集群的升级、Istio 的使用、镜像仓库的高可用、CI/CD、监控告警、日志、Operator 等等等等。这次分享将介绍 UCloud 内部对 Kubernetes 以及云原生生态的应用实践，和大家分析每个选择背后的原因，碰到的问题以及解决方案。\n使用 Apache SkyWalking Adapter 实现 K8s HPA 讲师：高洪涛\n公司：Tetrate\n讲师介绍：高洪涛 美国 servicemesh 服务商 Tetrate 创始工程师。原华为软件开发云技术专家，对云 APM 有深入的理解，并有丰富的 APM 产品设计， …","relpermalink":"/event/cloud-native-meetup-shanghai-01/","summary":"云原生社区举办的第一届城市站 meetup。","title":"云原生社区 meetup 第一期上海站"},{"content":"开源越来越受欢迎 2019 年的 IDC 北美开源软件使用调查显示，71% 的企业正在使用开源软件，54% 的企业计划扩大使用范围。2020 年的 RedHat 企业开源现状调查显示，有 95% 的 IT 领导者认为企业开源对于企业基础架构软件战略至关重要。\n一方面企业越来越接受开源软件，另一方面企业也开始参与开源。现在思考的主要问题，不再是用不用，而是怎样用好开源软件。\nimg 可以说开源迎来了一个大时代，对协作模式、研发流程、产品发布等方方面面产生了深远的影响。\n开源的核心是管理和运营社区 开源不是公开源代码，而是管理和运营社区。\n很多关于开源的讨论在强调，license、管理风险、安全风险等防守策略。对于大企业，这些无法避免，为了获得上层的支持，却给开源带来了极大的负担，最终没有精力管理和运营社区。\n社区的特征是共识与协作。开源项目是开源社区的共识，也是开源协作的对象。社区成员质量越高、数量越多，就越能代表该领域的先进性。\nimg 在有限的人群上，可以构建无限的社区。但在无限的社区上，个人又只能投入有限的精力和时间。这就是开源项目之间争夺的焦点。\n更多高质量的人、更长时间地参与是 …","relpermalink":"/blog/the-core-of-open-source-is-community/","summary":"这是云原生的机会，更是开源社区的机会。","title":"开源的核心是管理和运营社区"},{"content":"本文译自：Guidance for Building a Control Plane to Manage Envoy Proxy at the edge, as a gateway, or in a mesh。\n这篇文章我看了之后非常想翻译，为什么呢？一方面我也在学习 Envoy，并且在公司的实际项目中使用 Envoy，另一方面，我确实也在设计一个控制管理端来统一管控多个集群的所有流量，没错我说的是所有的流量管控。目前这个管理系统在内部已经在逐步使用起来了。所以翻译这篇文章，即学习 Envoy 技术，也是想做一个参考，印证我的想法是不是 OK 的，取长补短。\n指导在服务边缘构建控制面来管理 Envoy Proxy，让它作为服务网关或者在服务网格中使用 Envoy 已经成为了一个非常流行的网络组件了。Matt Klein 几年前写过一篇博文，就在讨论 Envoy 的动态配置 API 和它如何成为 Envoy 被采用越来越多的原因之一。他在博文中说这是“统一数据面板 API”（UDPA）。随着很多其它项目都采用 Envoy 作为其核心组件，可以毫不夸张的说 Envoy …","relpermalink":"/blog/guidance-for-building-a-control-plane-to-manage-envoy-proxy-based-infrastructure/","summary":"这篇文章我看了之后非常想翻译，为什么呢？一方面我也在学习 Envoy，并且在公司的实际项目中使用 Envoy，另一方面，我确实也在设计一个控制管理端来统一管控多个集群的所有流量，没错我说的是所有的流量管控。","title":"如何为 Envoy 构建一个控制面来管理集群网络流量"},{"content":"1.8 是 Istio 在 2020 年发布的最后一个版本，按照 Istio 社区在今年初设定的目标继续推进，该版本主要有以下更新：\n支持使用 Helm 3 进行安装和升级 正式移除了 Mixer 新增了 Istio DNS proxy，透明地拦截应用程序的 DNS 查询，实现智能应答 新增了 WorkloadGroup 以简化对虚拟机的引入 WorkloadGroup 是一个新的 API 对象，旨在与虚拟机等非 Kubernetes 工作负载一起使用，模仿现有的用于 Kubernetes 工作负载的 sidecar 注入和部署规范模型来引导 Istio 代理。\n安装与升级 Istio 从 1.5 版本开始弃用了 Helm，使用 istioctl manifest 方式安装，后来又改成了 istioctl install，现在又重新回归了 Helm，Helm 作为 Kubernetes 环境下最常用的应用安装管理组件，此次回归也是倾听用户声音，优化安装体验的的反应吧，不过 Istio Operator 依然将是 Istio 安装的最终形式，从 1.8 版本开始 Istio …","relpermalink":"/blog/istio-18-release/","summary":"引入了 WorkloadGroup 和 DNS proxy，对如虚拟机的非 Kubernetes 负载的支持更进了一步。","title":"Istio 1.8 发布——用户至上的选择"},{"content":"本文译自 Istio 官方博客 Expanding into New Frontiers - Smart DNS Proxying in Istio。\nDNS 解析是 Kubernetes 上任何应用基础架构的重要组成部分。当你的应用代码试图访问 Kubernetes 集群中的另一个服务，甚至是互联网上的服务时，在发起与服务的连接之前，它必须首先查找服务主机名对应的 IP 地址。这个名称查找过程通常被称为服务发现。在 Kubernetes 中，集群 DNS 服务器，无论是 kube-dns 还是 CoreDNS，如果是 ClusterIP 类型的服务，都会将服务的主机名解析成一个唯一的不可路由的虚拟 IP（VIP）。每个节点上的 kube-proxy 将这个 VIP 映射到一组服务的 pod 上，并将流量转发到随机选择的其中一个。当使用服务网格时，sidecar 的工作原理与 kube-proxy 类似，都是为了转发流量。\n下图描述了当前的 DNS 的作用。\nIstio 中 DNS 的作用 DNS 带来的问题 虽然 DNS 在服务网格中的作用看似微不足道，但它一直阻碍着将网格扩展到虚拟 …","relpermalink":"/blog/istio-dns-proxy/","summary":"本文将向你介绍 Istio 1.8 中新增的智能 DNS 代理功能。","title":"Istio 中的智能 DNS 代理功能"},{"content":"本文译自 Helm Chart Repository Deprecation Update\n在 2019 年，当 Helm v2 的支持时间表和 终止计划 被宣布的时候，helm/charts GitHub 仓库 的弃用也同时被宣布。对于弃用的最主要原因是 仓库维护人员 的维护成本显著增加。在过去的几年里，受维护的 charts 数量从约 100 增加到 300 个以上，这也导致了对于仓库的拉取请求和更新需求相应增加。很不幸的是，尽管采取了很多的措施来实现自动 review 和维护任务，但是维护人员能抽出的可用时间却没有增加。\n当我们开始宣布弃用的时候，我们已经开始着手分享我们曾经用来维护 helm/charts 仓库的工具和指导文档。对于那些想要自己保持和维护自己仓库的小伙伴们，你们现在已经有工具能完成以下流程：\nChart 测试 为你的 charts PR 提供 lint 和测试 Chart 发布 提供工具来帮助你使用 GitHub Releases 和 pages 功能来管理你自己的 chart 仓库 测试和发布 GitHub Action 自动化调用上述工具。 在上述工具的帮助 …","relpermalink":"/blog/helm-chart-repository-deprecation-update/","summary":"Helm Chart 仓库更换地址，旧仓库地址将被弃用。","title":"Helm Chart 仓库弃用更新"},{"content":"由来 和我博客前一篇文章 银河麒麟 arm64 系统上 k8s 集群跨节点不通的一次排查 不一样，从来没遇到过这样的问题，这里记录下。实施在客户那边部署业务后，业务在浏览器上无法访问，我远程上去查看日志发现 pod 内部无法 DNS 无法解析，nginx 连不上 upsteam 报错而启动失败，实际上也是跨节点不通。实际排查过程也有往错误的方向浪费了一些时间和尝试，就不写进来了，以正确的角度写下排查过程。\n环境信息 OS 是 arm64 的银河麒麟系统：\n$ cat /etc/os-release NAME=\u0026#34;Kylin Linux Advanced Server\u0026#34; VERSION=\u0026#34;V10 (Tercel)\u0026#34; ID=\u0026#34;kylin\u0026#34; VERSION_ID=\u0026#34;V10\u0026#34; PRETTY_NAME=\u0026#34;Kylin Linux Advanced Server V10 (Tercel)\u0026#34; ANSI_COLOR=\u0026#34;0;31\u0026#34; $ uname -a Linux localhost.localdomain 4.19.90-17.ky10.aarch64 #1 SMP Sun Jun 28 14:27:40 …","relpermalink":"/blog/arm-kylin-clone-vxlan-error/","summary":"Arm64 的麒麟系统，克隆后网卡的 mac 不同，vxlan 的 vmac 却一样，如何解决？","title":"Arm64 银河麒麟系统克隆机器上 k8s vxlan 跨节点不通的一次排查"},{"content":"本文译自 Zero Trust Cybersecurity:‘Never Trust, Always Verify’。\n啊？什么？这是我第一次听到零信任网络安全这个词时候的反应，我是从 2018 年秋天开始在国家标准技术研究所 (NIST) 的国家网络安全中心部门 (NCCoE) 开始工作的。值得注意的是，我有了一个新的开始，同时也是一个巨大的转变，即从通常意义上讲的软件开发工程师转变为网络安全工程师。当然，在我的职业生涯中我曾经设计和开发了一些安全软件方案，甚至会做一些安全系统的平台的工作，但是零信任网络对我来讲，完全是另一回事。一方面，它没有围栏（意指防火墙之类的网络安全，后文有介绍）。\n我为什么这么说呢？传统的网络安全方式依赖的是网络屏障——防火墙——它控制着进出网络的流量。从另一个角度来讲，零信任网络是指没有这些网络屏障的情况。它通常和“消除边界”，“缩小边界”，“减小边界”，“无边界”这些词语一起提及。这些都是“去边界化”思想的常见提法，这种提法最早是在 2005 年由一个叫做 Jericho Forum 的团队首次提出的。2010 年，在 Forrester …","relpermalink":"/blog/zero-trust-cybersecurity/","summary":"本文翻译自 Alper Kerman 的文章 Zero Trust Cybersecurity: 'Never Trust, Always Verify'","title":"零信任网络安全：“从不信任，永远验证”"},{"content":"本文译自 NGINX Steps into the Service Mesh Fray Promising a Simpler Alternative。\n本月初，NGINX 推出 了 一款服务网格 NGINX Service Mesh（NSM）。它使用了开源 NGINX 代理的商业版本 NGINX Plus 驱动其数据平面。尽管许多服务网格都是基于完全开源的组件构建的，但 NGINX 营销副总裁 Rob Whiteley 认为，与其在市场上投放另一种开源解决方案，不如精力集中将 NSM 聚焦于当前市场缺失的部分。他认为客户正在为 Istio 的规模和复杂性而苦苦挣扎。\n“Istio 诞生于 Google，其设计精巧复杂，以支持运行数以亿计的容器和数千种服务。但从结果上看，Istio 带来了一定数量的额外开销，也佐证了设计的复杂性。Istio 采取了一种非常偏执的开发设计方式，其所用到的开源组件关联紧密无法自由组合简化。从技术上讲，可以将其中用不到的部分精简出去，但其设计时没有做到模块化。”Whiteley 表示，“NGINX Service Mesh 更轻量，易于安装，是为那些需求逐渐 …","relpermalink":"/blog/nginx-servicemesh/","summary":"本文介绍了 NGINX 官方新推出的服务网格方案 NGINX Service Mesh (NSM) 和 NSM 方案后续规划的两个目标。相较于现有服务网格，NSM 突出了轻量、简单、易上手入门的特点。","title":"NGINX 携新方案进军服务网格"},{"content":"本期是 Envoy 系列分享的第一期，在本次分享开始前云原生社区中进行了关于 Envoy 的问卷调查，从问卷结果来看大多数同学都希望了解调试流量这个主题，所以就选了这个主题作为第一次分享。而且大多数同学都是刚开始看 Envoy，所以本次分享也会涉及到很多 Envoy 入门的内容，未来我也会在社区中给大家分享更多 Envoy 的内容。视频回放见 B 站。\nEnvoy 直播回放地址 此次分享由三部分组成：\n历史和设计理念：这部分主要是 Envoy 入门，介绍为什么 Envoy 被开发出来，有哪些设计理念，扩展点。 Envoy 如何处理一个请求：这部分讲解了一下 Envoy 如何处理一个请求，在其中 Listener、Transport Socket、Filter、Cluster 这些概念分别起到什么作用。 如何用调试流量：分享了以下几种调试流量的方法：日志、stats、TAP。演示了如何用日志和 TAP 来调试流量。 Envoy AMA（Ask Me Anything）环节的问答主要围绕着：Wasm、Istio 支持、性能方面，还有一些社区相关的问题。以下是对问答内容的整理。\nWASM 相 …","relpermalink":"/blog/envoy-ama/","summary":"云原生学院第七期分享《Envoy 调试流量的常用技巧》的视频回放及问答整理。","title":"Envoy 调试流量的常用技巧直播分享及问答整理"},{"content":"Redis 是一个高性能的 key-value 存储系统，被广泛用于微服务架构中。如果我们想要使用 Redis 集群模式提供的高级特性，则需要对客户端代码进行改动，这带来了应用升级和维护的一些困难。利用 Istio 和 Envoy，我们可以在不修改客户端代码的前提下实现客户端无感知的 Redis Cluster 数据分片，并提供读写分离、流量镜像等高级流量管理功能。\nRedis Cluster Redis 的一个常见用途是用作数据高速缓存。通过在应用服务器和数据库服务器之间加入一个 Redis 缓存层，可以减少应用服务器对数据库的大量读操作，避免数据库服务器在大压力下响应缓慢甚至宕机的风险，显著加强整个系统的健壮性。Redis 作为数据缓存的原理如图所示：\n在一个小规模的系统中，上图所示的单个 Redis 就可以很好地实现缓存层的功能。当系统中需要缓存的数据量较大时，一个 Redis 服务器无法承担所有应用服务器的缓存需求；同时单个 Redis 实例失效时也会导致大量读请求被直接发送到后端的数据库服务器上，导致数据库服务器瞬时压力超标，影响系统的稳定性。我们可以采用 Redis …","relpermalink":"/blog/redis-cluster-with-istio/","summary":"本文将介绍如何通过 Istio 和 Envoy 实现客户端无感知的 Redis Cluster 数据分片，并实现读写分离、流量镜像等高级流量管理功能。","title":"在 Istio 中实现 Redis 集群的数据分片、读写分离和流量镜像"},{"content":"为什么写这篇文章 看到这个标题后，大家可能会问“都已经 2020 年了，Kubernetes 开源有 6 年时间了，为什么还要写一篇 Kubernetes 入门的文章？”我想说的是，Kubernetes 还远远没有达到我们想象的那么普及。众多的开发者，平时忙于各自的业务开发，学习新技术的时间有限；还有大量的学生群体，可能还仅仅停留在“知道有这门技术”的阶段，远远没有入门。这篇文章将助于各位有志于从事云原生领域工作或需要了解该领域背景的人群快速入门 Kubernetes 和云原生。\n因为云原生的知识体系过于庞杂，本文主要讲解容器、Kubernetes 及服务网格的入门概念，关于云原生的更多细节将在后续文章中推出。另外大家也可以关注云原生社区推出的 云原生知识图谱 项目，进一步了解云原生。\n引言 Kubernetes 一词来自希腊语，意思是“飞行员”或“舵手”。这个名字很贴切，Kubernetes 可以帮助你在波涛汹涌的容器海洋中航行。\nKubernetes 是做什么的？什么是 Docker？什么是容器编排？Kubernetes 是如何工作和扩展的？你可能还有很多其他的问题，本文将一一为你 …","relpermalink":"/blog/must-read-for-cloud-native-beginner/","summary":"这篇文章将助于各位有志于从事云原生领域工作或需要了解该领域背景的人群快速入门 Kubernetes 和云原生。","title":"云原生初学者入门必读"},{"content":"云原生社区邀请 RHCA Level 5，红帽资深解决方案架构师魏新宇，为大家带来分享「基于 Red Hat OpenShift 4 构建 Paas、DevOps 平台」。\nDevOps、微服务、PaaS 将成为 IT 技术发展的新趋势。越来越多的日常开发和生命周期任务正在实现自动化，通过现有数据流提供 AI 支持，通过灵活的 DevOps 管道驱动和孵化。生命周期和应用开发也会更加的智能化，越来越多的企业应用部署在 PaaS 平台上，使用微服务架构。\nOpenShift 是红帽推出的企业就绪型 Kubernetes 容器平台，可以实现全堆栈自动化运维，以管理混合云和多云部署。OpenShift 已进行过优化，可以提高开发人员的生产力并推动创新。\n如何通过 OpenShift 构建 DevOps 平台？为企业构建敏捷生态需要哪些路径？OpenShift 在 K8S 容器平台之上做了哪些增强？在微服务治理、容器安全、CI/CD 方面提供哪些创新和解决方案？\n本主题将会从容器云生态、容器安全、DevOps、微服务等领域介绍企业需求和 OpenShift 提供的企业级解决方案。\n讲师： …","relpermalink":"/blog/academy-6/","summary":"云原生社区邀请 RHCA Level 5，红帽资深解决方案架构师魏新宇，为大家带来分享《基于 Red Hat OpenShift 4 构建 Paas、DevOps 平台》。","title":"基于 Red Hat OpenShift 4 构建 Paas、DevOps 平台"},{"content":"本文译自 Cracking kubernetes node proxy (aka kube-proxy)。\nKubernetes 中有几种类型的代理。其中有 node proxier 或 kube-proxy，它在每个节点上反映 Kubernetes API 中定义的服务，可以跨一组后端执行简单的 TCP/UDP/SCTP 流转发 [1]。\n为了更好地理解节点代理模型，在这篇文章中，我们将用不同的方法设计和实现我们自己版本的 kube-proxy; 尽管这些只是 toy-proxy，但从透明流量拦截、转发、负载均衡等方面来说，它们的工作方式与 K8S 集群中运行的普通 kube-proxy 基本相同。\n通过我们的 toy-proxy 程序，非 K8S 节点（不在 K8S 集群中）上的应用程序（无论是宿主本地应用程序，还是在 VM/容器中运行的应用程序）也可以通过 ClusterIP 访问 K8S 服务 – 注意，在 kubernetes 的设计中，ClusterIP 只能在 K8S 集群节点中访问（在某种意义上，我们的 toy-proxy 程序将非 K8S 节点变成了 K8S 节点）。 …","relpermalink":"/blog/k8s-node-proxy/","summary":"带你一步步理解 kube-proxy。","title":"深入理解 Kubernetes 网络模型：自己实现 kube-proxy 的功能"},{"content":"本文译自 Zero-Trust Security with Service Mesh\n去年，是数据安全方面充满挑战的一年。仅在前 9 个月，就报告了 5183 起违规事件，并泄露了 79 亿条记录。与 2018 年年中相比，违规总数上升了 33.3％，泄露的记录总数翻了一番多，上升了 112％。到目前为止，2020 年的数据 与这些趋势相吻合，最大的安全隐患包括保护方面的差距，降低的检测率，更长的违规影响以及增加的客户数据曝光率。\n这告诉我们，尽管进行了重大的技术投资，但是软件安全性仍然存在很大的差距。不及时打补丁或配置错误可让不法分子肆意破坏或窃取数据。对于迁移到云以及基于微服务和容器化的云原生架构公司而言，困难则会得多。除了外围设备和网络本身之外，还有一个新的网络基础设施需要保护：微服务间的无数连接。\n使用微服务，意味着可攻击面呈指数增长，使数据面临更大的风险。此外，与网络相关的问题如访问控制，负载均衡和监控对于巨大的传统单体应用只需解决一次，而现在必须针对集群中的每个服务分别进行处理。简而言之，存在更多的违规空间。\n我们如何获得零信任？ 传统上，网络安全是基于强大的边界来帮助阻止 …","relpermalink":"/blog/zero-trust-service-mesh/","summary":"本文翻译自 Rose Sawvel 的文章 Zero-Trust Security with Service Mesh。","title":"服务网格的零信任安全"},{"content":"本文译自 Building a Kubernetes Mutating Admission Webhook。\n当你在 Kubernetes 中创建 Pod 的时候，是否注意到在容器的 /var/run/secrets/kubernetes.io/serviceaccount/token 路径上存放了一个用于认证的 token 文件？你可以通过如下命令，在 Kubernetes 集群中验证下：\n$ kubectl run busybox --image=busybox --restart=Never -it --rm -- ls -l /var/run/secrets/kubernetes.io/serviceaccount/token # output /var/run/secrets/kubernetes.io/serviceaccount/token 注：在 Kubernetes 1.6 以上的版本，你可以 取消 这一个自动注入的功能。\n现在假设有这样一个场景，需要添加一个“hello.txt”文件到所有（或某组）pod 的容器文件系统内，不能通过在 pod spec …","relpermalink":"/blog/mutating-admission-webhook/","summary":"本文介绍了从零开始构建 Kubernetes Mutating Admission Webhook 的详细步骤。通过使用 Mutating Admission Webhook，实现将文件注入容器的功能。","title":"如何构建 Kubernetes Mutating Admission Webhook"},{"content":"本文译自 Introducing NGINX Service Mesh。\n此版本 NGINX Service Mesh (NSM) 是一个高度集成的轻量级的服务网格的开发版本，它利用 NGINX Plus 支持的数据平面来管理 Kubernetes 环境中的容器流量。NSM 可以免费 下载。非常希望广大开发者们能在开发和测试环境中尝试一下，期待你们在 GitHub 仓库留下对 NSM 的反馈。\n随着部署规模的扩大并且变得越来越复杂，微服务的落地也变得很有挑战。服务之间的通信错综复杂，在系统中调试问题可能会更加困难，并且服务增多意味着需要管理更多的资源。\nNSM 通过使用户集中配置来解决以上挑战：\n安全——如今安全比以往任何时候都更加重要，数据泄露每年可能使组织损失数百万美元的收入和声誉。NSM 确保所有通信均经过 mTLS 加密，因此网络上没有敏感数据可被黑客窃取。通过访问控制可以定义策略来控制哪些服务可以相互通信。 流量管理——在部署应用程序的一个新版本时，用户可能希望先限制新版本应用程序接收的流量，以防可能存在 bug。使用 NSM 智能容器流量管理，用户可以指定限制流量到新服务的 …","relpermalink":"/blog/nginx-service-mesh/","summary":"本文翻译自 Nginx 官方博客初识 NGINX 服务网格。","title":"初识 NGINX 服务网格"},{"content":"本文译自 Request affinity with istio。\n背景介绍 很多 Cash App 的应用都会有一系列运行在 AWS 的 Kubernetes 集群上的分布式服务。们的工程团队也在几年前开始把应用迁移到 Kubernetes 上面，最近我们才开始使用 Istio 作为一种服务网格的解决方案来解决我们服务之间的通信。在这篇文章里，我会专注在 Istio 接管流量负载均衡这一功能是如何大幅度的提高我们的服务的性能和稳定性。\n服务网格以解决服务发现以及服务通信的问题见长，而其中一个吸引我们的功能就是如何将流量负载均衡分配到服务的 Pod 上面。在使用 Istio 之前，我们给每一个服务安放了一个它专用的 ELB 来负载分发流量。使用了 Istio 后，负载分发流量的任务就被下发至每个 Pod，不仅从网络流量中移除了负载均衡器，还提供了更加丰富的负载均衡配置功能。\n问题所在 我们在 AWS 环境中部署了一套 Kafka 集群，用于异步的消息订阅和发布。另外还使用了一套 Kotlin 服务用于连接传统服务，evently-cloud，座落在传统服务跟 Kafka 之间，它暴露出 …","relpermalink":"/blog/request-affinity-with-istio/","summary":"本文翻译自 Alex Holmes 的文章 Request affinity with istio。","title":"如何使用 Istio 处理亲和性网络请求"},{"content":"背景 Istio 一直是服务网格产品中的佼佼者，其数据面的组件—— Envoy 也受到很多互联网厂家及 IT 行业人员的追捧和青睐。云原生社区秉承普及和推广云原生相关技术的宗旨，已经在早些时候成立了Envoy SIG。为了方便国内 IT 行业人员学习与研究 Envoy，云原生社区决定将Envoy 官网最新版本进行翻译（Envoy 有 1.7 中文版本，但是版本过老）。\n翻译志愿者的条件和收获 如果你满足以下几点要求：\n热爱云原生技术，广交天下云原生同好 关注服务网格 追踪 Envoy 最新进展 喜欢翻译工作，并能够持续贡献 那就考虑加入云原生社区 Envoy 官网翻译团队吧。你能够收获：\n云原生社区中众多志同道合的小伙伴 对 Envoy 更深刻，更全面的认知 普及云原生技术所带来的成就感 如何加入翻译志愿者团队 加入云原生社区，加入我们 加入 Envoy SIG（添加微信 jimmysongio 或者 majinghe11，备注姓名 - 公司，并说明加入 Envoy SIG）。 翻译的相关事项都会在 Envoy SIG 群里公布，包括成员招募，启动翻译，进度跟踪等。\nEnvoy 翻译仓 …","relpermalink":"/blog/envoy-trans-recruit/","summary":"Envoy 官网最新版本翻译，招募翻译小组成员。","title":"云原生社区 Envoy 官网翻译小组成员招募中"},{"content":"本文根据我在云原生学院的分享整理而成，视频见 Bilibli。\n云原生学院\n本文将从云原生时代的机遇和挑战说起，介绍一个全新的开源高性能云原生 API 网关——Apache APISIX，探讨如何解决云原生时代 API 网关所面临的一些痛点，最后介绍该开源项目未来的规划。\n背景 云原生的机遇和挑战 很多应用和服务都在向微服务、容器化迁移，形成新的云原生时代。云原生是下一个 5-10 年的技术颠覆，重写了传统企业的技术架构，例如云原生中的 Kubernetes 颠覆了传统操作系统，所有的“主机”（node 上的容器）由 Kubernetes 来控制和编排，非常适用于公有云、私有云、混合云等各种环境。云原生体系的特点之一就是由各种开源项目组成，不同于以往的商业闭源项目，缓解了收费贵等问题，加速了技术落地。现代公司的技术是非常重要的组成部分，在一个商业竞争激烈的时代，公司愈早的占据技术顶峰愈是能够占据商业顶峰。网关作为云原生入口，是掌握云原生的一个必经之地，是开启“财富”的关键钥匙。\n微服务的演进 从 2014-2015 年，谷歌搜索引擎上“微服务”关键字的搜索趋势呈直线上升。\nimg 在单 …","relpermalink":"/blog/full-traffic-api-gateway-based-on-apache-apisix/","summary":"基于 Apache APISIX 的全流量 API 网关统筹集群流量。","title":"Apache APISIX 的全流量 API 网关统筹集群流量"},{"content":"本文译自Migrating to Service Mesh。\n今年 Allegro.pl 已满 21 岁。该公司在为数以百万计的波兰人提供在线购物服务的同时，还参与了许多技术进步。您可以使用公共云产品，机器学习来打破僵局。即使我们使用的许多技术似乎只是在大肆宣传，但他们的采用依然有可靠的理由的支持。让我告诉你一个我有幸从事的项目的故事。\n为什么要迁移到服务网格 我不准备对 Service Mesh 的背景知识做过多的讨论，因为已经有大量关于此主题的文章。我曾写过一篇文章（波兰语），专门介绍我们为什么决定从这种方法中收益。\n这里只列出我们想要的内容：\n将通用平台代码从 SDK（服务发现、负载均衡、分布式跟踪）中分离 将 mTLS 的逻辑从 SDK 和应用程序分离 统一服务间通信的访问控制 统一服务间流量的 HTTP 层面可观察性 系统的复杂性 类似 Allegro.pl 这样的在线市场是一个复杂的野兽。业务的许多部分都按照自己的节奏来演进并使用不同的技术。我们的服务（主要基于 JVM）主要运行在作为本地私有云解决方案的 Mesos/Marathon 上。 …","relpermalink":"/blog/migrating-to-service-mesh/","summary":"本文翻译自 Dariusz Jędrzejczyk 的文章 Migrating to Service Mesh。","title":"迁移到服务网格"},{"content":"本篇主要探讨上一篇源码分析中留下的问题，如 EnvoyXdsServer 是如何工作的，以及 xDS 的下发流程。对推送事件的防抖、SidecarScope 的运用做一些细致的分析。\nEnvoyXdsServer EnvoyXdsServer 主要负责 Pilot 中 xDS 协议的生成和下发，接收并处理 configController 和 serviceController 推送的 PushRequest，与集群中所有的数据面代理进行 gRPC 通信，并处理它们的请求。在 Pilot Server 中的定义如下：\n// Server contains the runtime configuration for the Pilot discovery service. type Server struct { EnvoyXdsServer *xds.DiscoveryServer } EnvoyXdsServer 只是 Pilot Server 中的别名，真正的 xds.DiscoveryServer 结构在 istio/pilot/pkg/xds/discovery.go:71  …","relpermalink":"/blog/istio-pilot-3/","summary":"本篇主要介绍 Pilot 源码中 EnvoyXdsServer 的工作流程，重点探讨了防抖、SidecarScope 等逻辑。","title":"Istio Pilot 源码分析（三）"},{"content":"了解了 Pilot 源码的基本结构和启动流程之后，我们可以深入探索 Pilot 究竟是怎么下发 xDS 协议的，以及协议的生成逻辑。相信大家都会有这些疑问：控制面与数据面详细的交互过程是什么？到底什么时候才会增量推送？增量推送判断的逻辑是什么？非 Kubernetes 原生的服务（如存在于虚拟机的服务、 Dubbo 服务等）到底是怎么注册并且经过一系列转化下发至数据面的？\n带着这些问题，开始我们今天对 Pilot 的探索。\n注：本文基于 istio release-1.7 分支分析，其他版本的代码结构会有所不同。\nServiceEntryStore 在多点落地 ServiceMesh 的过程中，大量的用到了 ServiceEntry ，每一个 Dubbo 服务都会映射一个 ServiceEntry 创建在 Kubernetes 里。 ServiceEntry 的作用就是将集群外部的服务注册到 Pilot 中，再统一由 ServiceController 进行管理。相应的，管理外部服务实例的对象为 WorkloadEntry ， ServiceEntry …","relpermalink":"/blog/istio-pilot-2/","summary":"本篇主要介绍 Pilot 源码中的 ServiceEntryStore 及其推送 xDS 的流程。","title":"Istio Pilot 源码分析（二）"},{"content":"DevOps 简述 顾名思义，DevOps 就是开发（Development）与运维（Operations）的结合体，其目的就是打通开发与运维之间的壁垒，促进开发、运营和质量保障（QA）等部门之间的沟通协作，以便对产品进行小规模、快速迭代式地开发和部署，快速响应客户的需求变化。它强调的是开发运维一体化，加强团队间的沟通和快速反馈，达到快速交付产品和提高交付质量的目的。\nDevOps 并不是一种新的工具集，而是一种思想，一种文化，用以改变传统开发运维模式的一组最佳实践。一般做法是通过一些 CI/CD（持续集成、持续部署）自动化的工具和流程来实现 DevOps 的思想，以流水线（pipeline）的形式改变传统开发人员和测试人员发布软件的方式。随着 Docker 和 Kubernetes（以下简称 k8s）等技术的普及，容器云平台基础设施越来越完善，加速了开发和运维角色的融合，使云原生的 DevOps 实践成为以后的趋势。下面我们基于混合容器云平台详细讲解下云平台下 DevOps 的落地方案。\n云原生 DevOps 特点 DevOps 是 PaaS 平台里很关键的功能模块，包含以下重要能 …","relpermalink":"/blog/cloudnative-devops/","summary":"这篇文章通过对容器平台 DevOps 组件设计，从源码级别做了详尽介绍。","title":"云原生 DevOps 落地方案"},{"content":"随着云原生发展的深入，服务网格的发展也如火如荼，其中的翘楚之才——Istio 也是备受大家的关注与喜爱，部分企业已经将 Istio 在生产上进行了使用。虽然 Istio 经历了架构变化、捐赠风波，但是不影响广大 IT 从业者对其的热爱。\n云原生社区为了能够给国内服务网格热爱者提供一个交流学习的机会，并秉承云原生社区的宗旨——普及和推广云原生相关技术，云原生决定成立 Envoy SIG（目前已经有 Operator SIG、OAM SIG），并在时机成熟时（会在云原生社区 Envoy SIG 微信群及社区公众号进行公布）招募志愿者翻译 Envoy 的最新版本（Envoy 有 1.7 中文版本，但是版本过老），并举办更多的 Envoy 技术交流活动。\n为什么加入 Envoy SIG 如果你：\n热爱云原生技术，广交天下云原生同好 关注服务网格 追踪 Envoy 最新进展 讨论负载均衡和网络代理技术 那就加入 Envoy SIG 吧。我们一起搞事情。\nEnvoy SIG 仓库：cloudnativeto/sig-envoy\n如何加入 Envoy SIG 加入云原生社区组织，详情请看云原生社区的 …","relpermalink":"/blog/sig-envoy-announcement/","summary":"Envoy SIG 成立公告及成员招募。","title":"云原生社区 Envoy SIG 成立啦！"},{"content":"Istio 作为目前 Service Mesh 方案中的翘楚，吸引着越来越多的企业及开发者。越来越多的团队想将其应用于微服务的治理，但在实际落地时却因为不了解 Istio 黑盒中的运行机制而左右为难，本文将基于 1.7 的源码讲解 Istio 的核心组件 Pilot 的结构及运行流程，希望对读者应用 Istio 有所助益。\n注：本文基于 istio release-1.7 分支分析，其他版本的代码结构会有所不同。\n背景 随着 Istio 1.7 的发布，内部组件精简后的 istiod 日趋稳定，越来越多的公司将其应用到自身微服务的流量治理、安全通信及监测中。多点也不例外，应用 Istio 来落地业务系统所有 Dubbo 服务的网格化，下沉 SDK 逻辑，解决基础中间件与业务系统过于耦合等痛点。目前，我们是通过自己开发的 Controller 组件对接 Zookeeper 等注册中心，将注册到 Zookeeper 的节点实时转化为 ServiceEntry 及 WorkloadEntry 等 Istio 配置类型写入 kube-apiserver，再由 Pilot 转化为 xDS 协议下 …","relpermalink":"/blog/istio-pilot/","summary":"基于 Istio 1.7 源码深入分析 Istio 流量管理、安全通信等方面的流程及原理，带你揭开 Istio 的神秘面纱。","title":"Istio Pilot 源码分析（一）"},{"content":"彭磊，陈凌鹏，腾讯云高级软件工程师，目前负责 TCM 服务网格产品，致力于打造云原生服务网格。本文首发于腾讯云 + 社区。\n在腾讯，已经有很多产品已使用或者正在尝试使用 istio 来作为其微服务治理的基础平台。不过在使用 istio 时，也有一些对通信性能要求较高的业务会对 istio 的性能有一些担忧。由于 envoy sidecar 的引入，使两个微服务之间的通信路径变长，导致服务延时受到了一些影响，istio 社区一直以来也有这方面的声音。基于这类抱怨，我们希望能够对这一通信过程进行优化，以更好的满足更多客户的需求。\n首先，我们看一下 istio 数据面的通信模型，来分析一下为什么会对延时有这么大的影响。可以看到，相比于服务之间直接通信，在引入 istio 之后，通信路径会有明显增加，主要包括多出了两次本地进程之间的 tcp 连接通信和用户态网络代理 envoy 对数据的处理。所以我们的优化也分为了两部分进行。\n内核态转发优化 那么对于本地进程之间的通信优化，我们能做些什么呢？其实在开源社区已经有了这方面的探索了。istio 官方社区在 2019 年 1 月的时候已经有了这方面 …","relpermalink":"/blog/istio-data-plane-performance-optimization/","summary":"由于 Envoy sidecar 的引入，使两个微服务之间的通信路径变长，导致服务延时受到了一些影响，Istio 社区一直以来也有这方面的声音。基于这类抱怨，我们希望能够对这一通信过程进行优化，以更好的满足更多客户的需求。","title":"深入了解 Istio 服务网格数据平面性能和调优"},{"content":"一、简介 在 kubernetes 系统中，组件之间通过 http 协议进行通信，通过 informer 来做到了消息的实时性、可靠性、顺序性，通过 informer 机制与 api-server 进行通信。\n二、架构设计 infomer 1.Reflector (1) 简介 informer 可以对 kubernetes api server 的资源执行监控（watch）操作，类型可以是 kubernetes 内置资源也可以是 crd 自定义资源，其中最核心的功能是 Reflector，Reflector 用于监控指定资源的 kubernetes 资源，当资源发生变化的时候，例如发生了 Added 资源添加等事件 会将其资源对象存放在本地缓存 DeltaFIFO 中。\n(2) 核心介绍（listandwatch） 第一部分首先获取资源列表数据。 第二部分通过 watchhandler 来监控资源对象。\n// path: staging/src/k8s.io/client-go/tools/cache/reflector.go // ListAndWatch 首先列出所有项目，并在调用 …","relpermalink":"/blog/client-go-informer-arch/","summary":"这篇文章通过对 informer 架构中所用到的组件，分别做了不同的介绍。","title":"Kubernetes client-go informer 架构介绍"},{"content":"本文是 2020 年 8 月 15 号在深圳 GIAC（GLOBAL INTERNET ARCHITECTURE CONFERENCE）全球互联网架构大会，由宋净超（Jimmy Song）出品的云原生专场中的现场实录。\n王发康（毅松）蚂蚁集团可信原生技术部 技术专家，专注于高性能网络服务器研发，是 MOSN、Tengine 开源项目核心成员，目前关注云原生 Service Mesh、Nginx、Istio 等相关领域，喜欢开源，乐于分享，GItHub：https://github.com/wangfakang 。\n以下是分享全文。\n前言 MOSN 在蚂蚁集团的 Service Mesh 大规模落地后，通过对接 UDPA 打造为 Istio 的数据面之一，本文就其在演进过程中遇到的问题及思考进行展开。对接 UDPA，实现 Istio 融合，并增强 MOSN 服务治理及流量控制能力对接云原生周边组件，实现 MOSN 开箱即用。\n大家下午好，我叫王发康，来自蚂蚁集团可信云原生应用网络团队，之前几年一直从事南北向网关（接入层）的开发和维护，说来也是和流量有着别样的渊缘，现在主要做东西向的流量网 …","relpermalink":"/blog/cloud-native-mosn/","summary":"本文是王发康在 2020 年 8 月 15 号在深圳 GIAC（全球互联网架构大会）云原生专场上的分享现场实录。","title":"云原生网络代理 MOSN 的进化之路"},{"content":"Overview 这篇文章主要是学习 Informer 机制并且理解 Informer 各个组件的设计。\n背景 为什么 Kubernetes 需要 Informer 机制？我们知道 Kubernetes 各个组件都是通过 REST API 跟 API Server 交互通信的，而如果每次每一个组件都直接跟 API Server交互去读取/写入到后端的etcd的话，会对API Server 以及 etcd 造成非常大的负担。而 Informer 机制是为了保证各个组件之间通信的实时性、可靠性，并且减缓对 API Server 和 etcd 的负担。\nInformer 流程 这个流程，建议先看看《From Controller Study Informer》\n这里我们以 CoreV1. Pod 资源为例子：\n第一次启动 Informer 的时候，Reflector 会使用List从 API Server 主动获取 CoreV1. Pod 的所有资源对象信息，通过resync将资源存放在Store中 持续使用Reflector建立长连接，去Watch API Server …","relpermalink":"/blog/informer-study/","summary":"Kubernetes Informer 源码理解","title":"Kubernetes Informer 机制源码解析"},{"content":"不管你关注不关注，云原生它走来了，它乘着万丈光芒的 Kubernetes 走来了；不管你承认不承认，Kubernetes 已经成为了云计算时代的操作系统。对于 Kubernetes，最为大家所熟知的就是它强大的容器编排能力（同为容器编排的还有 Mesos、Docker Swarm，但是 Kubernetes 已成一枝独秀），其实 Kubernetes 还有一个更强大的能力——扩展能力。如果只是利用 Kubernetes 内置的资源及 controller 类型，也就只能做到将应用“挪”到 Kubernetes 上，而不是真正的 Kubernetes 原生。如果利用 Kubernetes 的扩展能力，就可以将应用变成 Kubernetes 原生的了。\nKubernetes 扩展之 Operator Kubernetes 的扩展可以通过 Operator（Kubernetes API + CRD）来实现。在早期，为了实现一个 Operator，用户需要自己完成很多 Kubernetes 功能的实现，比如 Kubernetes Client 的创建，Kubernetes API Server …","relpermalink":"/blog/kubebuilder-summary/","summary":"Kubebuilder 中文翻译总结以及 Envoy 中文翻译志愿者招募。","title":"Kubebuilder 中文翻译总结"},{"content":"本文主要根据书籍《Kubernetes 源码剖析》的基础上，对 Client-go 部分的 Informer 机制进行了解与学习。\nInformer 机制 Kubernetes 中使用 http 进行通信，如何不依赖中间件的情况下保证消息的实时性，可靠性和顺序性等呢？答案就是利用了 Informer 机制。Informer 的机制，降低了了 Kubernetes 各个组件跟 Etcd 与 Kubernetes API Server 的通信压力。\nInformer 机制架构设计 图片源自 Client-go under the hood\n⚠️ 这张图分为两部分，黄色图标是开发者需要自行开发的部分，而其它的部分是 client-go 已经提供的，直接使用即可。\nReflector：用于 Watch 指定的 Kubernetes 资源，当 watch 的资源发生变化时，触发变更的事件，比如 Added，Updated 和 Deleted 事件，并将资源对象存放到本地缓存 DeltaFIFO； DeltaFIFO：拆开理解，FIFO 就是一个队列，拥有队列基本方 …","relpermalink":"/blog/client-go-informer-source-code/","summary":"Kubernetes Client-go Informer 机制及源码理解","title":"深入了解 Kubernetes Informer"},{"content":"Informer 原理图 为了便于理解，先上两张图。\n源码的调用流程图 可以对照着图中的代码文件及代码行数跟下代码。\n注：图中的代码行数基于1.15版。\ninformer 数据结构图 informer-data-structure Informer 工厂 先来看下cmd/kube-controller-manager/app/controllermanager.go:162的Run方法。\nfunc Run(c *config.CompletedConfig, stopCh \u0026lt;-chan struct{}) error { ... run := func(ctx context.Context) { rootClientBuilder := controller.SimpleControllerClientBuilder{ ClientConfig: c.Kubeconfig, } var clientBuilder controller.ControllerClientBuilder if …","relpermalink":"/blog/client-go-informer/","summary":"这篇文章从 Informer 的初始化调用链和事件如何流向的角度分析了 Informer 各个组件。","title":"Kubernetes client-go informer 原理"},{"content":"作为开源 Service Mesh 明星项目 Istio 背后的主要厂商，Google 也在其公有云上推出了 Service Mesh 管理服务。让人迷惑的是 Google Cloud 上有两个 Service Mesh 产品：Traffic Director 与 Anthos Service Mesh。Google Cloud 首先在 2019 年 3 月发布了其第一个 Service Mesh 产品 Traffic Director，随后不久在 2019 年 9 月紧接着发布了另一个 Service Mesh 产品 Anthos Service Mesh，随后两个产品独立并行发展，直到如今。\nGoogle Cloud 同时推出两个 Service Mesh 产品的原因是什么？这两个产品的定位有何不同？本文将分别分析这两个产品的架构和功能，以试图解答该疑问。\nTraffic Director Traffic Director 是 Google Cloud 专为服务网格打造的全托管式流量控制平面，用户不需要对 Traffic Director 进行部署，维护和管理。 …","relpermalink":"/blog/google-cloud-mesh/","summary":"作为开源 Service Mesh 明星项目 Istio 背后的主要厂商，Google 也在其公有云上推出了 Service Mesh 管理服务。让人迷惑的是 Google Cloud 上有两个 Service Mesh 产品：Traffic Director 与 Anthos Service Mesh。Google 同时推出两个 Servcie Mesh 产品的原因是什么？这两个产品的定位有何不同？","title":"Google Cloud 服务网格：Traffic Director 与 Anthos Service Mesh 的左右互搏"},{"content":"引言 2020 年 8 月 21 日，Istio 发布了 1.7 版本。除了介绍新版本的主要更新内容外，本文会重点分析 Istio 团队在产品更新策略上的激进态度和举措。是稳扎稳打做好向后兼容，带给用户所承诺的易用性；还是快刀斩乱麻，做进击的追风少年，且听笔者慢慢道来。\n如约而至——Istio 1.7.0 发布 就在几天前，Istio 发布了 1.7 版本，和 1.6 版本的发布时间正好间隔三个月，完美的实现了季度发布的诺言。本次发布的口号是“伟大的 Istio 社区（Istio’s great community）”，因为有来自 40 多个公司的 200 多个开发者做出了贡献。Istio 官方是这样描述的：\n正是因为有如此令人惊羡（amazing）的社区，才让 Istio 能够在每个季度有如此多的改进。\nIstio 团队已经从上个月倒卖商标的麻烦中走了出来，看上去是想通过强调 Istio\u0026#39;s great community 这个理念来抚平社区开发者受伤的心灵？笔者认为，作为开发者和用户不必太在意 Google 的商业行为，至少现阶段 Istio 还在以开源的身份持续演进，还能为我所 …","relpermalink":"/blog/istio-1-7-explanation/","summary":"从用户角度出发，深度解读 Istio 1.7 版本。","title":"Istio 1.7 发布——进击的追风少年"},{"content":" Linux 年内和观测技术 BPF 由范老师和我一起翻译的图书《Linux 内核观测技术 BPF》已经在 JD 上有现货，欢迎感兴趣 BPF 技术的同学选购。链接地址 https://item.jd.com/72110825905.html\n“eBPF 是我见过的 Linux 中最神奇的技术，没有之一，已成为 Linux 内核中顶级子模块，从 tcpdump 中用作网络包过滤的经典 cbpf，到成为通用 Linux 内核技术的 eBPF，已经完成华丽蜕变，为应用与神奇的内核打造了一座桥梁，在系统跟踪、观测、性能调优、安全和网络等领域发挥重要的角色。为 Service Mesh 打造了具备 API 感知和安全高效的容器网络方案 Cilium，其底层正是基于 eBPF 技术”\n1. BPF BPF（Berkeley Packet Filter），中文翻译为伯克利包过滤器，是类 Unix 系统上数据链路层的一种原始接口，提供原始链路层封包的收发。1992 年，Steven McCanne 和 Van Jacobson 写了一篇名为《BSD 数据包过滤：一种新的用户级包捕获架构》的论文。在文 …","relpermalink":"/blog/bpf-intro/","summary":"eBPF 是我见过的 Linux 中最神奇的技术，没有之一，已成为 Linux 内核中顶级子模块，从 tcpdump 中用作网络包过滤的经典 cbpf，到成为通用 Linux 内核技术的 eBPF，已经完成华丽蜕变，为应用与神奇的内核打造了一座桥梁，在系统跟踪、观测、性能调优、安全和网络等领域发挥重要的角色。为 Service Mesh 打造了具备 API 感知和安全高效的容器网络方案 Cilium，其底层正是基于 eBPF 技术","title":"eBPF 技术简介"},{"content":"目前在云原生社区的 Kubernetes 源码研习社中和广大学友们共同学习郑东旭大佬的 Kubernetes 源码剖析这本书。当前正在开展第一期学习活动，第五章节 client-go 的学习。之所以从这一章节开始学习，主要是考虑到 client-go 在源码中相对比较独立，可以单独阅读。更主要的是它是 Kubernetes 的核心处理框架，基本上运用在 Kubernetes 各个组件中，因此，如果你学好了这一章节，对于后面 Kubernetes 源码的阅读，将会有很大的帮助。此外随着 Operator 的盛行，一些开源的生成框架也受到广大 Operator 开发者们的青睐。例如 kubebuilder 和 operator-SDK 等。而精通了 client-go，将对你理解这些生成框架及编写 Operator 也是有很好的帮助。\n下面内容是在学习过程中总结的相关笔记及个人见解。\n概括 client-go 是用 Golang 语言编写的官方编程式交互客户端库，提供对 Kubernetes API server 服务的交互访问。\n其源码目录结构如下：\ndiscovery: …","relpermalink":"/blog/client-go-study/","summary":"该篇博客是本人在学习 client-go 源码时的一些总结和个人感受，希望可以能够给后面的学者一些帮助。","title":"client-go 源码学习总结"},{"content":"TL;DR 声明：下文提到的bpf/BPF字样是泛指，包括cBPF和eBPF。\n通过文章，你能了解 Linux 内核代码中关于 bpf 程序的编译运行机制，并能学会如何基于 Linux 内核 bpf 示例环境编写你自己的 bpf 程序。文章涉及的实验环境和代码可以到这个 git repo 获取： https://github.com/nevermosby/linux-bpf-learning\n最近 Kubecon 2020 China 上已经有了 3 个关于 bpf 的中文分享（来自腾讯和 PingCAP），也看到国内第一梯队公司越来越关心 bpf 这项新技术，欢迎大家都能加入 bpf 学习队伍。\n内核源码里的 BPF 示例代码概述 示例代码里基本是kern和user成对出现，也就是对于一个示例来说，分别提供了在内核空间运行的和用户空间运行的程序，绝对是良心之作了。\n下载 Linux 内核源代码 First thing first，第一步是下载内核代码。\n选择内核版本 目前社区维护的内核版本繁多，你需要确定下载哪个版本的代码。个人建议是下载与你的操作系统运行一致的内核版本，避免后续编译 …","relpermalink":"/blog/compile-bpf-examples/","summary":"Linux 社区的大佬们为学习 eBPF 的同学们准备了福利，Linux 内核源码里包含了大量的 eBPF 示例代码，几乎覆盖了所有种类的 eBPF 程序，非常适合学习者阅读和测试。今天为大家介绍如何编译运行这些 eBPF 示例代码。","title":"编译运行 Linux 内核源码中的 eBPF 示例代码"},{"content":"Kubernetes 诞生至今已经 5 年了，火爆整个社区，大家对 Kubernetes 越来越熟悉，越来越了解。但现阶段很多人都是熟练使用 Kubernetes，甚至我们会自嘲为“YAML 工程师”。\n可是随着各类云原生应用的出现、Operator 理念的推广、深入维护 Kubernetes 的需求下，仅仅做一个 “YAML 工程师” 已经不能满足老板的要求了。需要我们进一步了解 Kubernetes 是如何实现的，该怎么扩展 Kubernetes。\n我在这样的场景下，开始学习 Kubernetes 编程，在这里总结了我学习到的 Kubernetes 编程的基础知识，让大家对 Kubernetes 编程有个大致的了解。\n基于 Kubernetes 编程 什么叫做基于 Kubernetes 编程呢？回想一下，我们以前听过基于 Linux 编程，基于 Windows 编程，可以放在‘基于’后面的都是通用标准的平台。基于 Kubernetes 编程有着相同的概念，Kubernetes 经过 5 年的高速发展，已经成为了容器编排调度框架的标准，直接将之定义为“云原生操作系统”也不为过。 …","relpermalink":"/blog/kubernetes-programming-base/","summary":"如何从 YAML 工程师迈入云原生研发工程师。","title":"Kubernetes 编程基础知识"},{"content":"IT 技术日新月异，想必每个 IT 人都会有类似的焦虑：我该学习什么？哪些知识学到就是赚到？怎样学习才能最有效提升编程能力？\n阅读优秀的代码是提高编程能力万无一失的办法。诚然，提高编程能力的显著方法是写更多代码，但也需要静下心来品味优秀的代码，大侠行走江湖也需要武功秘籍，而当今优秀的开源项目代码便是程序员的武林秘籍。\n优秀的开源项目浩如烟海，应该如何选择适合自己的项目呢？\n选择方式有很多，比如项目使用到什么开源项目就学习该项目的源码，比如基于 Apache Dubbo 构建微服务，则可以学习 Dubbo 框架源码，理解其底层机制以及原理（比如服务治理），学以致用；阅读那些让你印象深刻或者自己可以掌握的源码，比如从一个小项目或者一个插件开始，也是不错的选择；最重要的是，大多数人时间有限但选择又太多，一定要选择适合自己的，能够融入自己的知识体系。如果你是云原生爱好者，那么阅读 Kubernetes 核心源码就是一个非常好的选择。\n找到一个合适的开源项目后，但在具体实践的时候常常因为一些不正确的看法而误入歧途，中途折戟：\n缺乏自信，我并未参与该项目开发，因此我很难深入理解其源码 数据结构和算 …","relpermalink":"/blog/study-groups/","summary":"读源码如读书，积累的越多，越熟练，读得越快。","title":"如何学习开源项目源码"},{"content":"本文作者：林静，F5 软件方向解决方案架构师，历任 F5 Global Service ENE，APAC Professional Service 顾问，技术专家。拥有超过 10 多年的应用交付领域工作经验，秉承持续学习和反馈的理念，致力于现代应用体系下的应用服务研究。CNCF Kubernetes CKA 664 号认证获得者，中国首位 F5 Security Solution Expert 认证获得者。\n感谢邱世达对本文的审校。\n前言 Envoy，使者，使节，代表！就像其单词含义本身一样，带着一种权威感，一种全代理的神圣感。结合其本身用途与角色，真是“人如其名”，不禁为 Lyft 点赞，不知是得到了哪位大师的指点来起这个名字。在当前火热的微服务时代下，Envoy 是个绝对的明星，用众人皆知来形容可以说一点也不为过。曾有人问我如何看 Envoy 以及在云原生时代下是否 Envoy 将取代 F5 取代 NGINX，作为一个经历了两次应用交付技术领域更迭浪潮的老兵，在本文中我将来浅谈一下 Envoy，以及试图从个人角度来理解与回答一下这个问题。为什么说浅谈一下，这真的不是谦虚，而是客观上 …","relpermalink":"/blog/thoughts-to-envoy-from-adn-perspective/","summary":"Envoy 是云原生时代的明星，其本质是反向代理负载均衡类软件，领域上归于应用交付，那么作为应用交付领域的老兵如何看待 Envoy，Envoy 又引发了哪些关于传统应用交付领域的思考？","title":"应用交付老兵眼中的 Envoy, 云原生时代下的思考"},{"content":" 本文主要分享火焰图使用技巧，介绍 systemtap 的原理机制，如何使用火焰图快速定位性能问题原因，同时加深对 systemtap 的理解。\n让我们回想一下，曾经作为编程新手的我们是如何调优程序的？通常是在没有数据的情况下依靠主观臆断来瞎蒙，稍微有些经验的同学则会对差异代码进行二分或者逐段调试。这种定位问题的方式不仅耗时耗力，而且还不具有通用性，当遇到其他类似的性能问题时，需要重复踩坑、填坑，那么如何避免这种情况呢？\n俗语有云：“工欲善其事，必先利其器。”个人认为，程序员定位性能问题也需要一件“利器”。如同医生给病人看病，需要依靠专业的医学工具（比如 X 光片、听诊器等）进行诊断，最后依据医学工具的检验结果快速精准地定位出病因所在。性能调优工具（比如 perf / gprof 等）之于性能调优就像 X 光之于病人一样，它可以一针见血地指出程序的性能瓶颈。\n但是常用的性能调优工具 perf 等，在呈现内容上只能单一地列出调用栈或者非层次化的时间分布，不够直观。这里我推荐大家配合使用火焰图，它将 perf 等工具采集的数据呈现得更为直观。\n初识火焰图 火焰图（Flame Graph）是 …","relpermalink":"/blog/flame-graph/","summary":"本文主要分享火焰图使用技巧，介绍 systemtap 的原理机制，如何使用火焰图快速定位性能问题原因，同时加深对 systemtap 的理解。","title":"性能调优利器--火焰图"},{"content":"背景 Istio 从发布开始就使用 Envoy 作为自己的数据平面，充分利用了 Envoy 提供的服务发现、路由、熔断、负载均衡等功能。与此同时，Istio 项目也一直致力于提供一个便于灵活扩展的平台，以满足用户多样化的需求。在过去的一年半中，Google 的团队一直在努力用 WebAssembly 技术为 Envoy 代理添加动态扩展，并推出了针对 Envoy 代理的 WebAssembly (以下简称为 WASM) 扩展机制，包括标准化的 ABI，SDK，以及该扩展机制的第一个重点实现：全新的、低延迟的 Istio 遥测系统。\n本文主要对 Envoy 和 WebAssembly 技术进行介绍，并使用 solo.io 团队推出的 wasme 工具完成 WASM filter 的构建、发布和部署，方便读者了解 Envoy WASM Filter 的扩展方式及其实现原理。\nEnvoy 的过滤器机制 Envoy 是 Istio 中的 Sidecar 官方标配，是一个面向服务架构的高性能网络代理，由 C++ 语言实现，拥有强大的定制化能力。Envoy 提供了进程外架构、支持 L3/L4 …","relpermalink":"/blog/envoy-wasm/","summary":"本文对 WebAssembly 和 Envoy 技术进行了介绍，通过 WASM Filter 的构建、发布和部署过程，方便读者了解 Envoy WASM Filter 的扩展方式及其实现原理。","title":"Istio 进阶学习系列 - 基于 WebAssembly 实现 Envoy 与 Istio 的功能扩展"},{"content":" 作者介绍：aoho，一线码农，对云原生、微服务、Go 语言、容器化感兴趣，并做了深入研究。闲暇时间会分享一些技术思考和实践，与大家讨论交流，共同进步。\n0 专辑概述 etcd 是云原生架构中重要的基础组件，由 CNCF 孵化托管。etcd 在微服务和 Kubernates 集群中不仅可以作为服务注册于发现，还可以作为 key-value 存储的中间件。\n《彻底搞懂 etcd 系列文章》将会从 etcd 的基本功能实践、API 接口、实现原理、源码分析，以及实现中的踩坑经验等几方面具体展开介绍 etcd。预计会有 20 篇左右的文章，笔者将会每周持续更新，欢迎关注。\n1 etcd 介绍 etcd 是 CoreOS 团队于 2013 年 6 月发起的开源项目，它的目标是构建一个高可用的分布式键值 (key-value) 数据库。具有以下特点：\n简单：安装配置简单，而且提供了 HTTP API 进行交互，使用也很简单 键值对存储：将数据存储在分层组织的目录中，如同在标准文件系统中 监测变更：监测特定的键或目录以进行更改，并对值的更改做出反应 安全：支持 SSL 证书验证 快速：根据官方提供 …","relpermalink":"/blog/etcd-1/","summary":"etcd 了解一下！","title":"彻底搞懂 etcd 系列文章（一）：初识 etcd"},{"content":"导言 2018 年 kubecon 大会上，阿里的陈俊大佬分享 Node-operator 的主题让我印象深刻，回来之后开始着手研究 Operator。正好当时老板希望能够将公司正在使用的 Nosql 组件容器化，顺势给老板安利一波 Operator 的思想。随后以 opentsdb 的容器为开端，后续完成一系列组件容器化，一路走来不断学习和借鉴其他 operator 的先进经验。Zookeeper 作为最新完成 operator 化的组件，除了可以快速部署以外，还实现了 Operator 对 scale up/down 的进度干预，控制 rolling 的重启顺序，感知组件实际运行状态等，具体实现请阅读对于相关章节。\n功能需求 目前 operator 主要实现如下功能：\n快速部署 安全伸缩容 自动化监控 故障自愈 可视化操作 CRD Operator 设计第一步是定义声明式接口的 Item，spec 主要包含节点资源、监控组件、副本数、持久化存储。\napiVersion: database.ymm-inc.com/v1beta1 kind: ZooKeeper metadata: …","relpermalink":"/blog/zookeeper-operator/","summary":"Zookeeper 作为最新完成 operator 化的组件，除了可以快速部署以外，还实现了 Operator 对 scale up/down 的进度干预，控制 rolling 的重启顺序，感知组件实际运行状态等，具体实现请阅读对于相关章节。","title":"Zookeeper operator 实战"},{"content":"前言 开源已经无处不在，当下已经很难找到一款软件是完全和开源没有任何关系的了。开源软件，正在成为现代社会的基础设施。\n“Open up your phone. Your social media, your news, your medical records, your bank: they are all using free and public code.” - Nadia Eghbal 《Roads and Bridges: The Unseen Labor Behind Our Digital Infrastructure》\n开源，并非与你不相关，并非离你很遥远，开源就在你身边！\n而谈到开源软件的开发模式，不得不提及 Eric S.Raymond 在其著名的论文《大教堂与集市》中论证了开源的软件工程理论。如他所定义的 Linus 定律：众目睽睽之下，Bug 将无处藏身，模块化、去中心化、快速发布快速反馈等等是可行的，Kernel 就是成功的案例。\n随着 Linux、Apache、Perl/Python/PHP、MySQL/PostgreSQL 等开源技术的崛起，以及技术的更 …","relpermalink":"/blog/opensource-and-community/","summary":"本文分享作者近期关于对开源社区的一些思考的沉淀，以飨读者！","title":"解秘开源与社区"},{"content":"今天我们不讲行业和商业，讲讲 2019 年最热的概念——云原生（Cloud Native）。\n我认为云原生是未来 10 年 IT 发展最重要的趋势，但是它涵盖的概念非常多，需要花很多时间研究，同时浩如烟海的资料分散在网络上各个地方，缺乏系统性的梳理。今年 2 月我在基金内部做过一个分享，今日成文，希望让更多的人有所了解。\n本文试图解答：\n为什么云原生概念具有革命性？ 什么是微服务？ 微服务和中台的关系 容器和微服务为什么是最佳搭档？ 容器化与虚拟化的区别 API 管理与 API 集成的区别 Kubernetes 是做什么用的？ 开源软件商业化遇到的典型问题是什么？ 涉及到的概念包括云原生、DevOps、持续集成、持续交付、持续部署、微服务、API 管理、iPaaS、Service Mesh、Serverless、容器、Docker、Kubernetes 等等，我争取用比较形象和通俗的方式把这些技术概念讲清楚。\n本文内容较多，共分为六个章节。\n第一部分：云原生及 CNCF 基金会 第二部分：DevOps 与 CI/CD 第三部分：微服务、API 管理与集成 第四部分：容器与 Docker …","relpermalink":"/blog/cloud-native-era/","summary":"我认为云原生是未来 10 年 IT 发展最重要的趋势，但是它涵盖的概念非常多，需要花很多时间研究，同时浩如烟海的资料分散在网络上各个地方，缺乏系统性的梳理。今年 2 月我在基金内部做过一个分享，今日成文，希望让更多的人有所了解。","title":"云原生时代——投资人视角下的云原生趋势思考"},{"content":"作为云原生服务网格领域的热门开源项目，Istio 可以为微服务提供无侵入的流量管理、安全通信、服务可见性等服务治理能力。目前越来越多的微服务项目开始考虑将自己的微服务基础设施向 Istio 进行迁移。\nIstio 对 Kubernetes 具有较强的依赖性，其服务发现就是基于 Kubernetes 实现的。如果要使用 Istio，首先需要迁移到 Kubernetes 上，并使用 Kubernetes 的服务注册发现机制。但是对于大量现存的微服务项目来说，这个前提条件并不成立。很多微服务项目要么还没有迁移到 Kubernetes 上；要么虽然采用了 Kubernetes 来进行部署和管理，但还是使用了 Consul，Eureka 等其他服务注册解决方案或者自建的服务注册中心。\n在这种情况下，我们如何能够以最小的代价快速地将现有微服务项目和 Istio 进行集成，以享受 Istio 提供的各种服务治理能力呢？本文将分析 Istio 服务注册机制的原理，并提出几种 Istio 与第三方服务注册中心集成的可行方案，以供读者参考。\nIstio 服务模型 我们先来看一下 Istio 内部的服务模 …","relpermalink":"/blog/istio-service-registy-integration/","summary":"对于大量使用了 Consul，Eureka 或者自建服务注册中心的项目来说，如何能够以最小的代价快速地将现有微服务项目和 Istio 进行集成，以享受 Istio 提供的各种服务治理能力呢？本文将分析 Istio 服务注册机制的原理，并提出几种 Istio 与第三方服务注册中心集成的可行方案，以供读者参考。","title":"如何将第三方服务中心注册集成到 Istio？"},{"content":"内容摘要：从 1.2 版本开始，Istio 进入季度发布的节奏。5 月 21 日发布的 1.6 版本可以说是最准时的一次。我们是否可以理解 Istio 架构简化后的开发工作已经步入了正轨？这次的更新是否会带给我们惊喜？亦或是还有遗憾？让我们一一道来。 （感谢罗广明同学的审校和修改建议）\n加法和减法 Istio 1.6 的 Release note 开篇的标题用三个巨大的 Simplify 来表明态度：我们要把极简主义进行到底！其中最大的简化就是将原有组件的功能完全整合入 Istiod ，完成了悟天克斯们的合体过程，让 Istiod 更加完整，也彻底移除了 Citadel、Sidecar Injector 和 Galley。当然，你也可以理解为，这其实是对 1.5 版本未完成工作的收尾。\n龙珠 Z 第二项简化工作是添加 istioctl install 命令来替代 manifest apply 的安装过程，用更直观、更精简的命令改善安装过程的体验。当然，manifest 子命令依然保留，你还是可以通过清单方式进行部署。在 Change Notes 的三十多项更新中，有七个 …","relpermalink":"/blog/istio-16-explain/","summary":"Istio 1.6 如期发布。让我们从不同的视角来解读一下这一版本的特性。","title":"迈向极简主义 - Istio 1.6 发布"},{"content":"前言 这个问题 flannel 和 calico 的 VXLAN 模式下都会发生，部分人的集群的 A 记录 UDP 下查询可能有问题。原因是 v1.17+ 的 kubernetes 某部分会引起内核的某个 UDP 相关的 BUG 而不是 CNI 的软件层面，WEAVE 没有这个问题，原因后面会说到。写这篇文章的日期是 05/28，最开始发现是上周五也就是 05/23 号，文章从时间线写起，因为很多时候想发文章但是没空。\n2020-07-19 官方版本 v1.18.6, v1.16.13, v1.17.9+ 已经修复这个问题，可以同版本内升级，或者只切 kube-proxy 版本。\n由来 上周五我经过同事的工位看到同事的桌面是 kubectl get po 的输出，问他咋开始学 Kubernetes 了，他说跟着视频学下。看了下用的 kubeadm 部署了一套 1.18.2 的集群。1.18 的 kube-proxy 的 ipvs 包的 parseIP 有 bug，我推荐他换 v1.17.5。他当时在部署一个入门的 SVC 实验，无法解析域名。使用 dig 命令排查了下，下面是对照： …","relpermalink":"/blog/kubernetes-1-17-vxlan-63s-delay/","summary":"本文为使用工具排查出 v1.17+的 kubernetes 集群下为何 CNI 的 VXLAN 模式下有超时，并且给出了三种解决方案和定位到问题起源。","title":"Kubernetes v1.17+ 集群下 CNI 使用 VXLAN 模式 SVC 有 63 秒延迟的触发原因定位"},{"content":" OAM 和 Crossplane 社区共同致力于建设一个聚焦在标准化的应用和基础设施上的开放社区。\n前言 在 2020 年三月份，在来自 Crossplane 社区的协作和巨大贡献下，开放应用模型（即 OAM）项目发布了其v1alpha2 规范，旨在为 OAM 本身和任何采用 OAM 的 Kubernetes 应用平台带来绝佳的可扩展性。在 2020 年 5 月份，随着 Crossplane 最新的 v0.11 版本发布，Crossplane 现在具备了 OAM 规范的标准实现。我们十分激动看到两个社区间的合作，合作将标准的应用和基础设施定义与实施一起带入了云原生社区。\n旅程的开始 从 Kubernetes 工程师的角度来说，我们很接受现在的 Kubernetes 抽象层级：容器和基础设施 API 资源。但是对于平台的终端用户而言还是太过底层。\n为了在一定程度上提高终端用户的体验，一些团队试图通过引入 PaaS 或者 GUI 来向终端用户隐藏 Kubernetes API。初看上去，这似乎是一个好主意。但事实上，这极大的限制了平台的能力。Kubernetes 资源模型强调系统的所有能 …","relpermalink":"/blog/oam-crossplane/","summary":"本文翻译自阿里云高级技术专家张磊的文章 OAM and Crossplane: The Next Stage for Building Modern Application","title":"OAM 和 Crossplane: 构建现代应用的下一个阶段"},{"content":"在上一篇文章一文带你彻底厘清 Kubernetes 中的证书工作机制中，我们介绍了 Kubernetes 中证书的工作机制。在这篇文章中，我们继续探讨 Istio 是如何使用证书来实现网格中服务的身份认证和安全通信的。\n本文是对 Istio 认证工作机制的深度分析，假设读者已经了解 Service Mesh 以及 Istio 的相关基础概念，因此在本文对此类基础概念不再解释。对于 Istio 不熟悉的读者，建议先阅读 Istio 官方网站上的的这篇基础介绍 What is Istio?。\nIstio 安全架构 Istio 为微服务提供了无侵入，可插拔的安全框架。应用不需要修改代码，就可以利用 Istio 提供的双向 TLS 认证实现服务身份认证，并基于服务身份信息提供细粒度的访问控制。Istio 安全的高层架构如下图所示：\n图 1. Istio Security Architecture，图片来源istio.io\n图中展示了 Istio 中的服务认证和授权两部分内容。让我们暂时忽略掉授权部分，先关注认证部分。服务认证是通过控制面和数据面一起实现的：\n控制面：Istiod …","relpermalink":"/blog/istio-certificate/","summary":"Istio 为微服务提供了无侵入，可插拔的安全框架。应用不需要修改代码，就可以利用 Istio 提供的双向 TLS 认证实现服务身份认证，并基于服务身份信息提供细粒度的访问控制。本文将为你揭秘 Istio 双向 TLS 认证的实现机制。","title":"一文带你彻底厘清 Istio 中的证书工作机制"},{"content":"这篇文章是基于 Tekton Pipeline 的最新版本v0.12.1版本。\n快速入门请参考：云原生 CICD: Tekton Pipeline 实战 ，实战是基于版本 v0.10.x。\nPipeline CRD 与核心资源的关系 $ k api-resources --api-group=tekton.dev NAME SHORTNAMES APIGROUP NAMESPACED KIND clustertasks tekton.dev false ClusterTask conditions tekton.dev true Condition pipelineresources tekton.dev true PipelineResource pipelineruns pr,prs tekton.dev true PipelineRun pipelines tekton.dev true Pipeline taskruns tr,trs tekton.dev true TaskRun tasks tekton.dev true Task Tekton Pipelines 提供了上 …","relpermalink":"/blog/how-tekton-works/","summary":"结合源码和场景分析 Tekton 的工作原理。","title":"Tekton 的工作原理"},{"content":"接触 Kubernetes 以来，我经常看到 Kubernetes 在不同的地方使用了证书（Certificate），在 Kubernetes 安装和组件启动参数中也需要配置大量证书相关的参数。但是 Kubernetes 的文档在解释这些证书的工作机制方面做得并不是太好。经过大量的相关阅读和分析工作后，我基本弄清楚了 Kubernetes 中证书的使用方式。在本文中，我将试图以一种比官方文档更容易理解的方式来说明 Kubernetes 证书相关的工作机制，如果你也存在这方面的疑惑，希望这篇文章对你有所帮助。\nKubernetes 组件的认证方式 首先让我们来看一下 Kubernetes 中的组件：在 Kubernetes 中包含多个以独立进程形式运行的组件，这些组件之间通过 HTTP/gRPC 相互通信，以协同完成集群中应用的部署和管理工作。\nkubernetes 组件，图片来源kubernetes.io\n从图中可以看到，Kubernetes 控制平面中包含了 etcd，kube-api-server，kube-scheduler，kube-controller-manager 等组 …","relpermalink":"/blog/k8s-certificate/","summary":"在本文中，我将试图以一种比官方文档更容易理解的方式来说明 Kubernetes 和证书（Certificate）相关的工作机制，如果你也存在这方面的疑惑，希望这篇文章对你有所帮助。","title":"一文带你彻底厘清 Kubernetes 中的证书工作机制"},{"content":"前言 Service Mesh 在企业落地中有诸多挑战，当与传统微服务应用共同部署治理时可用性挑战更为严峻。本文将以 Service Mesh 与 Spring Cloud 应用互联互通共同治理为前提，着重介绍基于 Consul 的注册中心高可用方案，通过各种限流、熔断策略保证后端服务的高可用，以及通过智能路由策略（负载均衡、实例容错等）实现服务间调用的高可用。\nService Mesh 与 Spring Cloud 应用的互通、互联 微服务是时下技术热点，大量互联网公司都在做微服务架构的推广和落地。同时，也有很多传统企业基于微服务和容器，在做互联网技术转型。而在这个技术转型中，国内有一个现象，以 Spring Cloud 与 Dubbo 为代表的微服务开发框架非常普及和受欢迎。近年来，新兴的 Service Mesh 技术也越来越火热，受到越来越多开发者的关注，大有后来居上的趋势。\n在听到社区里很多人谈到微服务技术选型时，注意到他们讨论一个非此即彼的问题：采用 Spring Cloud 还是以 Istio 为代表的 Service Mesh 技术？然而这个答案并非非黑即白、非你即我， …","relpermalink":"/blog/microservices-ha-practice/","summary":"本文为 Service Mesh Virtual Meetup - 'Service Mesh 高可用在企业级生产中的实践'分享专题重新整理的文字稿。","title":"混合微服务高可用在企业级生产中的实践"},{"content":"Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖来自陌陌和百度的 Service Mesh 生产实践，Service Mesh 的可观察性和生产实践以及与传统微服务中可观察性的区别，还有如何使用 SkyWalking 来观测 Service Mesh。\n本文根据 5 月 13 日晚，百度高级工程师罗广明的主题分享《Service Mesh 高可用在企业级生产中的实践》整理。文末包含本次分享的视频回顾链接以及 PPT 下载地址。\n前言 Service Mesh 在企业落地中有诸多挑战，当与传统微服务应用共同部署治理时可用性挑战更为严峻。本次分享将以 Service Mesh 与 Spring Cloud 应用互联互通共同治理为前提，着重介绍基于 Consul 的注册中心高可用方案，通过各种限流、熔断策略保证后端服务的高可用，以及通过智能路由策 …","relpermalink":"/blog/baidu-service-mesh-ha-practice/","summary":"本文为百度高级研发工程师罗广明在 Service Mesh Virtual Meetup 上分享的文字整理。","title":"Service Mesh 高可用在企业级生产中的实践"},{"content":"Service Mesh Webinar 是由 ServiceMesher 社区和 CNCF 联合发起的线上直播活动，活动将不定期举行，邀请社区成员为大家带来 Service Mesh 领域的知识和实践分享。\nService Mesh Webinar#1，邀请多点生活平台架构组研发工程师陈鹏，带来分享《多点生活在 Service Mesh 上的实践——Istio + MOSN 在 Dubbo 场景下的探索之路》。\n随着多点生活的业务发展，传统微服务架构的面临升级困难的问题。在云原生的环境下，Service Mesh 能给我们带来什么好处。如何使用社区解决方案兼容现有业务场景，落地成符合自己的 Service Mesh 成为一个难点。服务之间主要通过 Dubbo 交互，本次分享将探索 Istio + MOSN 在 Dubbo 场景下的改造方案。\n直播时间：2020 年 5 月 28 日（周四）20:00-21:00 直播地址：https://live.bilibili.com/21954520（欢迎关注直播间） 分享主题 《多点生活在 Service Mesh 上的实践——Istio + …","relpermalink":"/blog/service-mesh-webinar-1/","summary":"B 站直播：多点生活在 Service Mesh 上的实践——Istio + MOSN 在 Dubbo 场景下的探索之路。","title":"Service Mesh Webinar #1"},{"content":"2020 年伊始，受新冠疫情影响，全球各地的员工开启了在家办公的模式，因此人与人之间的距离感觉被拉远了。但是云原生圈子里有我们这样一群人，因为一个共同的愿景聚集到了一起，组建了社区管理委员会，并在过去的三个月里利用业余时间，齐心协力完成了社区的筹备工作。今天我们要正式宣布云原生社区正式成立了。\n成立背景 Software is eating the world. —— Marc Andreessen\n“软件正在吞噬这个世界”已被大家多次引用，随着云原生（Cloud Native）的崛起，我们想说的是“Cloud Native is eating the software”。随着越来越多的企业将服务迁移上云，企业原有的开发模式以及技术架构已无法适应云的应用场景，其正在被重塑，向着云原生的方向演进。\n那么什么是云原生？云原生是一系列架构、研发流程、团队文化的最佳实践组合，以此支撑更快的创新速度、极致的用户体验、稳定可靠的用户服务、高效的研发效率。开源社区与云原生的关系密不可分，正是开源社区尤其是终端用户社区的存在，极大地促进了以容器、服务网格、微服务等为代表的云原生技术的持续演进！\n随着云 …","relpermalink":"/blog/cnc-announcement/","summary":"我们很高兴地宣布，云原生社区今天正式成立了。","title":"云原生社区成立"},{"content":"内容摘要：Service Mesh 落地实践三年，效果一直并不理想，到了该反思的时候了。Mecha 作为面向服务的分布式能力抽象层，是 Service Mesh 模式的自然进化版本，预计也将是云原生化和 Mesh 化的必然趋势，让我们将 Mesh 进行到底。\nMecha 介绍 什么是 Macha？ Mecha 一词，相信爱好动漫的同学应该都不陌生。是的，就是大家熟悉的那个 Mecha（机甲）：\nMecha 这个词之所以出现在这里，主要是因为 Bilgin Ibryam 的这个博客文章“Multi-Runtime Microservices Architecture”，提出了微服务架构的一个新的设想：Multiple Runtime。\n备注：这篇博客文章强烈推荐阅读，我甚至建议在阅读本文之前先阅读这篇文章，因为我今天的内容，可以视为对这个文章的深度解读和思考。为了方便，这里提供一份中文翻译版本 多运行时微服务架构。\n在这篇博客中，Bilgin Ibryam 首先分析并总结了分布式应用的四大需求：\n生命周期（Lifecycle） 网络（Networking） 状态（State） 捆 …","relpermalink":"/blog/mecha/","summary":"Service Mesh 落地实践三年，效果一直并不理想，到了该反思的时候了。Mecha 作为面向服务的分布式能力抽象层，是 Service Mesh 模式的自然进化版本，预计也将是云原生化和 Mesh 化的必然趋势，让我们将 Mesh 进行到底。","title":"Mecha：将 Mesh 进行到底"},{"content":" 官网 list786_444#.jpg Service Mesh Virtual Meetup 是 ServiceMesher 社区和 CNCF 联合主办的线上系列直播。本期为 Service Mesh Virtual Meetup#1，邀请了四位来自不同公司的嘉宾，从不同角度展开了 Service Mesh 的应用实践分享，分享涵盖来自陌陌和百度的 Service Mesh 生产实践，Service Mesh 的可观察性和生产实践以及与传统微服务中可观察性的区别，还有如何使用 SkyWalking 来观测 Service Mesh。\n本文根据 5 月 6 日晚，陌陌中间件架构师高飞航的主题分享《陌陌的 Service Mesh 探索与实践》整理。文末包含本次分享的视频回顾链接以及 PPT 下载地址。\n前言 本次演讲为大家分享的是陌陌目前正在进行的 Service Mesh 实践的相关内容。共分为三个部分：\n第一部分是原有微服务架构的相关背景； 第二部分是原有架构遇到的问题以及决定采用 Service Mesh 方案的思考过程； 最后的部分对 Service Mesh 落地实践的方案 …","relpermalink":"/blog/momo-service-mesh-practice/","summary":"本文为陌陌中间件架构师高飞航在 Service Mesh Virtual Meetup 上分享的文字整理。","title":"陌陌的 Service Mesh 探索与实践"},{"content":"因为疫情的原因，ServiceMesher 社区暂时无法举办线下 meetup，因此我们将活动改为线上，将采用 B 站直播的形式。本期为第一届 Service Mesh Virtual Meetup 线上系列直播，邀请了四位来自不同公司的嘉宾，从四个角度对 Service Mesh 的应用实践展开分享。\n本次线上 meetup 分享涵盖 Service Mesh 的可观察性和生产实践。为大家介绍 Service Mesh 中的可观察性与传统微服务中可观察性的区别，如何使用 SkyWalking 来观测 Service Mesh，还有来自百度和陌陌的 Service Mesh 生产实践。\n本系列采用线上直播的形式，从 2020 年 5 月 6 日开始到 5 月 14 日，每周三、周四晚上 19:00-20:00 我们相约进行一个主题分享。\n直播信息 直播地址：https://live.bilibili.com/21954520 直播回放地址：https://space.bilibili.com/228717294/channel/detail?cid=126804 PPT 下载地 …","relpermalink":"/blog/service-mesh-virtual-meetup-1/","summary":"因为疫情的原因，ServiceMesher 社区暂时无法举办线下 meetup，因此我们将活动改为线上，将采用 B 站直播的形式。","title":"Service Mesh Virtual Meetup #1"},{"content":"本文基于 Istio 1.5.1 版本，将为大家介绍以下内容：\n什么是 sidecar 模式和它的优势在哪里。 Istio 中是如何做 sidecar 注入的？ Sidecar proxy 是如何做透明流量劫持的？ 流量是如何路由到 upstream 的？ 在此之前我曾写过基于 Istio 1.1 版本的理解 Istio Service Mesh 中 Envoy 代理 Sidecar 注入及流量劫持，Istio 1.5 与 Istio 1.1 中的 sidecar 注入和流量劫持环节最大的变化是：\niptables 改用命令行工具，不再使用 shell 脚本。 sidecar inbound 和 outbound 分别指定了端口，而之前是使用同一个端口（15001）。 注：本文中部分内容收录于 ServiceMesher 社区出品的 Istio Handbook。\nSidecar 模式 将应用程序的功能划分为单独的进程运行在同一个最小调度单元中（例如 Kubernetes 中的 Pod）可以被视为 sidecar 模式。如下图所示，sidecar 模式允许您在应用程序旁边添加更多功能， …","relpermalink":"/blog/sidecar-injection-iptables-and-traffic-routing/","summary":"本文基于 Istio 1.5.1 版本，介绍了 sidecar 模式及其优势 sidecar 注入到数据平面，如何做流量劫持和转发的，以及流量是怎样路由到 upstream 的。","title":"Istio 中的 Sidecar 注入及透明流量劫持过程详解"},{"content":"前言 关于 Service Mesh 和 API Gateway 之间的关系，这个问题过去两年间经常被问起，社区也有不少文章和资料给出解答。其中不乏 Christian Posta 这样的网红给出过深度介绍。我在这里做一个资料的整理和汇总，结合个人的理解给出一些看法。另外在本文最后，介绍蚂蚁金服在 Service Mesh 和 API Gateway 融合的这个最新领域的一些开创性的实践和探索，希望给大家一个更有体感的认知。\n备注 1：为了节约篇幅，我们将直奔主题，假定读者对 Service Mesh 和 API Gateway 已有基本的了解。\n备注 2: 这边文章更关注于梳理整个脉络，内容不会展开的特别细，尤其是其他文章已经详细阐述的部分。如果您在浏览本文之后，还想更深入的了解细节，请继续阅读文章最后的参考资料和推荐阅读。\n原本清晰的界限：定位和职责 首先，Service Mesh 和 API Gateway 在功能定位和承担的职责上有非常清晰的界限：\nService Mesh：微服务的网络通信基础设施，负责（系统内部的）服务间的通讯 API Gateway：负责将服务以 API  …","relpermalink":"/blog/service-mesh-and-api-gateway/","summary":"本文就 Service Mesh 和 API Gateway 关系进行了深度探讨。","title":"Service Mesh 和 API Gateway 关系深度探讨"},{"content":"简介 Istio 1.5 回归单体架构，并抛却原有的 out-of-process 的数据面（Envoy）扩展方式，转而拥抱基于 WASM 的 in-proxy 扩展，以期获得更好的性能。本文基于网易杭州研究院轻舟云原生团队的调研与探索，介绍 WASM 的社区发展与实践。\n超简单版解释：\n–\u0026gt; Envoy 内置 Google V8 引擎，支持 WASM 字节码运行，并开放相关接口用于和 WASM 虚拟机交互数据； –\u0026gt; 使用各种语言开发相关扩展并编译为 .WASM 文件； –\u0026gt; 将扩展文件挂载或者打包进入 Envoy 容器镜像，通过 xDS 动态下发文件路径及相关配置由虚拟机执行。\nWebAssembly 简述 Istio 最新发布的 1.5 版本，架构发生了巨大调整，从原有的分布式结构回归为单体，同时抛却了原有的 out-of-process 的 Envoy 扩展方式，转而拥抱基于 WASM 的 in-proxy 扩展，以期获得更好的性能，同时减小部署和使用的复杂性。所有的 WASM 插件都在 Envoy 的沙箱中运行，相比于原生 C++ Envoy 插件，WASM 插件具有以下的优 …","relpermalink":"/blog/istio-envoy-wasm/","summary":"Istio 1.5 回归单体架构，并抛却原有的 out-of-process 的数据面（Envoy）扩展方式，转而拥抱基于 WASM 的 in-proxy 扩展，以期获得更好的性能。本文基于网易杭州研究院轻舟云原生团队的调研与探索，介绍 WASM 的社区发展与实践。","title":"Istio1.5 \u0026 Envoy 数据面 WASM 实践"},{"content":"简介 本文是基于阿里云托管服务网格 ASM 完成应用在多集群环境中全自动化渐进式发布的 GitOps 实践。\nASM 阿里云服务网格（Alibaba Cloud Service Mesh，简称 ASM）提供了一个全托管式的服务网格平台，兼容于社区 Istio 开源服务网格，用于简化服务的治理，包括服务调用之间的流量路由与拆分管理、服务间通信的认证安全以及网格可观测性能力，从而极大地减轻开发与运维的工作负担。ASM 的架构示意图如下：\nasm_arch.png ASM 定位于混合云、多云、多集群、非容器应用迁移等核心场景中，构建托管式统一的服务网格能力，能够为阿里云用户提供以下功能：\n一致的管理方式 以一致的方式来管理运行于 ACK 托管 Kubernetes 集群、专有 Kubernetes 集群、ServerlessKubernetes 集群、混合云或多云场景下的接入集群上的应用服务，从而提供一致的可观测性和流量控制 统一的流量管理 支持容器或者虚拟机混合环境下统一的流量管理 控制平面核心组件托管化 托管控制平面的核心组件，最大限度地降低用户资源开销和运维成本 ArgoCD …","relpermalink":"/blog/202003-gitops-progressive-delivery-with-asm/","summary":"本文是基于阿里云托管服务网格 ASM 完成应用在多集群环境中全自动化渐进式发布的 GitOps 实践。","title":"使用托管服务网格实现应用在多集群中的 GitOps 全自动化渐进式发布"},{"content":"最近几个月一直在研究 kubernetes 的 scheduling-framework 调度框架，发现还是十分有意思的，我自己也实现了一个基于 scheduling-framework 调度框架的自定义调度器，希望感兴趣的同学一起学习：https://github.com/NJUPT-ISL/Yoda-Scheduler\nScheduling-framework 调度框架 Kubernetes 的 scheduling-framework 调度框架（以下简称调度框架）是针对当前 kubernetes 调度器的增强，它不同于之前的 scheduler-extender，用户可以编写多个插件，这些插件可以在调度的不同阶段作为原有调度器的扩展，并且这些插件会和 kubernetes 原有的调度器源代码会一起编译到调度程序中。\n调度框架设计目标 增强 kubernetes 原有调度器的可扩展性。 通过将调度程序的某些功能移至插件，可以简化调度程序核心。 调度框架中可设置多个扩展点。 调度框架通过插件机制来接收插件结果，并根据接收到的结果继续或中止。 提出一种处理错误并将其与插件进行通信的机 …","relpermalink":"/blog/202003-k8s-scheduling-framework/","summary":"Kubernetes 的 scheduling-framework 调度框架是针对当前 kubernetes 调度器的增强。","title":"浅谈 Kubernetes Scheduling-Framework 插件的实现"},{"content":"本文为翻译文章，点击查看原文。\n译者注：Istio 的架构在 1.5 版本中发生了翻天覆地的变化，控制平面从微服务回归单体，pilot、citadel、galley 等控制平面组件整合成了单一的 istiod 二进制文件，同时饱受诟病的 mixer 同志终于在 1.5 中 deprecated 了，社区呼声很高的 Wasm 以 Proxy-Wasm plugins 的方式登上历史舞台，官方承诺在 1.6 版本中提供标准的 wasm 插件配置 API，甚至还推出了 webassemblyhub 这样的类似应用商店的服务，构建 wasm plugin 生态的野心不可谓不大。结合代理无关的 ABI 标准，只能说谷歌又在下一盘大棋。mixer 的两大核心功能，check 和 report，分别使用 Proxy-Wasm plugins 和 telemetry V2 替代，曾经所谓的 Mixer V2 计划也渐渐烟消云散，湮没在历史尘埃中。本文翻译官方的技术博客，来一探本次的划时代变更 proxy-wasm plugin 的究竟。\n自 2016 年采用Envoy以来，Istio 项目一直希望提供 …","relpermalink":"/blog/redefining-extensibility-in-proxies/","summary":"编者按 istio1.5 架构发生了重大升级，用于扩展代理服务器的新接口允许将 Istio 可扩展性从控制平面移至 Sidecar 代理本身，本文探讨采用 Istio 采用 Wasm 技术的背景和未来生态发展的考虑","title":"重新定义代理的扩展性：WebAssembly 在 Envoy 与 Istio 中的应用"},{"content":"引子 Istio 1.5 是一个具有重大变革的版本。长久以来，面对社区对 Istio 的性能和易用性的诟病，Istio 团队终于正视自身的问题，在当前版本中彻底推翻了原有控制平面的架构，完成了重建。正如 Simplified Istio 文中所说：\n复杂是万恶之源，让我们停止焦虑，爱上单体。\nIstio 1.5 回归单体，无论架构和使用方式都发生了巨大变化。因此笔者决定对 1.5 的变化内容做深入解读，以便开发者可以更好的理解和学习新版本，为使用和升级提供参考。\n架构调整 这部分主要分析 Istio 1.5 在架构上的调整，这也是该版本最核心的变化。主要包括重建了控制平面，将原有的多个组件整合为一个单体结构 istiod；同时废弃了被诟病已久的 Mixer 组件。还对是否向后兼容的部分也做了说明，如果你要从 1.4.x 版本升级到 1.5 必须知道这些变化。\n重建控制平面 官方使用的是重建（Restructuring）而不是重构（Refactoring）一词，可见其变化之大。在 Istio 1.5 中，控制平面将使用新的部署模式，将原有的各个组件整合在一起。\nIstiod Istio …","relpermalink":"/blog/istio-1-5-explanation/","summary":"本文基于 istio 最新的架构调整设计文档，分析了 istio 未来的设计目标。","title":"拥抱变化 —— Istio 1.5 新特性解读"},{"content":"背景 这是使用 istio 最常见的困境：在微服务中引入 envoy 作为代理后，当流量访问和预期行为不符时，用户很难快速确定问题是出在哪个环节。客户端收到的异常响应，诸如 403、404、503 或者连接中断等，可能是链路中任一 sidecar 执行流量管控的结果，但也有可能是来自某个服务的合理逻辑响应。\n特别的，当 service mesh 系统的维护者和应用程序的开发者来自不同的团队时，问题尤为凸显。\n在 mesh 中引入全链路跟踪系统，可以解决部分问题，我们可以知道请求到达了哪些工作负载，但是对于中断的异常请求，我们仍然很难确定原因。因为本着最大透明化（Maximize Transparency）的设计目标，istio 的遥测系统会尽量屏蔽掉 sidecar 的存在。另一方面，用户自行维护一套全链路跟踪系统成本也很高，受限于遥测采样率和有限的协议支持，我们通常无法采集所有链路数据。\n幸运的是，envoy 本身可以记录流量的信息，本文主要介绍如何利用 envoy 日志，对类似问题进行定位。\ndemo 环境为腾讯云 TKE，istio 版本 1.4.3，代码归档 …","relpermalink":"/blog/istio-debug-with-envoy-log/","summary":"istio 遵循最大透明化的设计目标，在遥测系统中屏蔽了 sidecar 的信息，本文分享如何通过 envoy 日志对数据面流量问题进行定位","title":"istio 数据面日志调试"},{"content":"前言 当第一次看到 Network Service Mesh 这一名词时，你很可能和我一样好奇它到底是什么？是否和 Service Mesh 有什么关系？Network Service Mesh 是云原生领域中一个新的热点，是 CNCF（云原生基金会）中的一个沙箱项目。本文将介绍 Network Service Mesh 的起源和架构，并探讨其与 Service Mesh、SDN、NFV 等相关技术的区别与联系。\n正文云原生应用面临的网络问题 Kubernetes 网络模型 Kubernetes 已经成为云原生应用编排（即应用程序资源分配、部署和运行管理）的事实标准，几乎所有的公有和私有云解决方案都提供了 Kuberetes 的管理服务。由于采用了微服务架构，因此云原生应用系统中存在大量服务间的东西向网络流量。为了满足集群内部应用之间的这些东西向流量需求，Kubernetes 采用了一个扁平的三层网络模型。该模型可以有多种实现方式，但所有这些实现都必须满足下面的基本要求：\n每个 Pod 有一个独立的 IP 地址。 每个 Pod 可以和集群中任一个 Pod 直接进行通信（ …","relpermalink":"/blog/202002-network-service-mesh/","summary":"当第一次看到 Network Service Mesh 这一名词时，你很可能和我一样好奇它到底是什么？是否和 Service Mesh 有什么关系？Network Service Mesh 是云原生领域中一个新的热点，是 CNCF（云原生基金会）中的一个沙箱项目。本文将介绍 Network Service Mesh 的起源和架构，并探讨其与 Service Mesh、SDN、NFV 等相关技术的区别与联系。","title":"NFV 走向云原生时代：Network Service Mesh 项目介绍"},{"content":"2020 年 2 月 4 日到 2 月 11 日，ServiceMesher 社区发起了 Service Mesh 终端用户调查，以下为问卷调查结果。\n参与问卷调查的人员情况 共收集到 516 份问卷结果，问卷填写者 94.2% 来自 ServiceMesher 社区，21.7% 的人参与过社区线上活动，27.5% 的人参与过社区 meetup，86.6% 看好 Service Mesh 的未来发展前景。\n下面是参与问卷调查人员的基本情况。\n公司所属行业\n公司所属行业 所在公司的 Service Mesh 使用情况\n所在公司的 Service Mesh 使用情况 工作年限\n工作年限 在公司中担任的职务\n在公司中担任的职务 关注 Service Mesh 技术的时长\n关注 Service Mesh 技术的时长 周围关注或了解 Service Mesh 技术的人员情况\n周围关注或了解 Service Mesh 技术的人员情况 学习 Service Mesh 技术的方式\n学习 Service Mesh 技术的方式 关注的 Service Mesh 相关开源项目\n关注的 Service …","relpermalink":"/blog/service-mesh-end-user-survey-report/","summary":"本文是 ServiceMesher 社区对 Service Mesh 终端用户的调查报告。","title":"Service Mesh 终端用户调查报告"},{"content":"本文为翻译文章，点击查看原文。\n编者按 如文章标题所示，本文通过对 Service Mesh 技术和 API 网关的对比，着重分析了两者的功能重合点和分歧点，解答了开发者的困惑，为如果进行技术选型和落地提供了指导思路。\n前言 这篇文章也许无法打破缠绕在 API 网关和服务网格周围的喧嚣。即便已经是 2020 年了，围绕这些话题仍然会存在大量的疑虑。我撰写此文是为了给出真实而具体的解释，以帮助大家理清它们之间的差异、重叠以及适用场景。如果你不同意我觉得我在添乱，或者想请我喝杯啤酒，欢迎随时在 Twitter 上@我（@christianposta）。\n第一个曝光： 我在 Solo.io 这家公司工作，公司的业务聚焦于今天我们要讨论的主题。我提前说明一下以免你会有“你的观点是有偏见的”的反应。每个人的观点都有偏见。但可以肯定的是，我在 Solo.io 工作是因为我想看到这些想法被付诸实施并推向市场，而不是与之相反。\n第二个曝光： 我正在写一本有关服务网格的书，名为《Istio in Action》，这花了我很多时间。在本文中，不可否认我是站在 Istio 的角度来讨论“服务网格”的，但如果 …","relpermalink":"/blog/do-i-need-an-api-gateway-if-i-have-a-service-mesh/","summary":"本文对 API 网关和 Service Mesh 进行了对比，指出了它们之间的异同。","title":"使用了 Service Mesh 后我还需要 API 网关吗"},{"content":"背景 有外文指出，2020 年 Service Mesh 技术将有以下三大发展：\n快速增长的服务网格需求； Istio 很难被打败，很可能成为服务网格技术的事实标准； 出现更多的服务网格用例，WebAssembly 将带来新的可能。 针对 Service Mesh 技术，ServiceMesher 社区治理委员会成员在 2020 新年伊始发表了他们各自的看法，并邀请云原生与服务网格领域业界大牛抒发各自的见解，汇总成文，希望能给读者们带来一些思考和启发。\n正文 宋净超（蚂蚁金服） 用一句话概括 Service Mesh 近几年的发展——道阻且长，行则将至。这几年来我一直在探寻云原生之道，从容器、Kubernetes 再到 Service Mesh，从底层的基础设施到越来越趋向于业务层面，Service Mesh 肯定不是云原生的终极形式，其复杂性依然很高，且业界标准也尚未形成，它的发展也远没有同期的 Kubernetes 那么顺利，但是很多人都已意识到了服务网格价值，现在它正在远离最初市场宣传时的喧嚣，走向真正的落地。\n罗广明（百度） 据了解，2020 年的 Kubecon EU 的提案 …","relpermalink":"/blog/service-mesh-technology-outlook-2020/","summary":"本文由 ServiceMesher 社区治理委员与业界知名大牛针对 Service Mesh 技术发表的看法汇总而成。","title":"2020 年 Service Mesh 技术展望"},{"content":"本文译自 The Future of Cloud Native Applications With OAM and Dapr。\n在 2019 年 11 月 4 日至 8 日于佛罗里达州奥兰多举办的2019 年微软 Ignite 大会上，Azure 首席技术官 Mark Russinovich 介绍了微软开发的两个创新和革命性的项目，旨在解决当今 IT 专业人士和开发人员在试图构建基于微服务的应用程序时的一系列现有问题。这场会议被命名为《基于开放应用模型（OAM）和分布式应用运行时（Dapr）的云原生应用的未来》。\n开放式应用模型（OAM） 因此，其中一个项目与开放应用模型（OAM）有关。它代表了一个开放的标准，允许我们建立云原生应用程序，与平台无关，并遵循关注点分离的原则，通过将应用程序的定义与应用程序的部署和托管基础设施的细节分离，为我们提供一些好处。\n将应用程序的定义与操作细节分开，使应用程序开发人员能够专注于其应用程序的关键要素，并将其从部署地点和方式的操作细节中抽象出来。另外，关注点的分离允许平台架构师开发可重复使用的组件，而应用开发者则专注于将这些组件与他们的代码集成，以快 …","relpermalink":"/blog/the-future-of-cloud-native-applications-with-oam-and-dapr/","summary":"本文介绍了基于 OAM 和 Dapr 的云原生应用的未来。","title":"利用 OAM 和 Dapr 的云原生应用的未来"},{"content":"引子 早在 2019 年底的 KubeConNA 中，Google API 基础设施的架构师 Louis Ryan 就透露了 Istio 控制平面架构将要进行调整的消息。从即将发布的 1.5 版本开始，原本多个独立的组件将会整合在一起，成为一个单体结构。相信每个开发者都能意识到架构调整会带来什么样的后果。这一重磅消息也促使笔者决定著成此文，以告天下拥趸：变化有风险，落地需谨慎！\n原罪 解耦是罪？ 这并不是 Istio 第一次调整架构了。号称 Production ready 的 1.0 版本在后续的 1.1 版本就进行了比较大的调整，分离了 Pilot 的配置下发功能到新的 Galley 组件中，将 Mixer 组件中原本进程内运行的 Plugin 改为了进程外运行的 adapter，进一步加剧了 Mixer 组件的性能问题。\narch1 坦白讲，如果抛开性能问题，笔者个人非常喜欢 Istio 1.1 的架构设计。它是贯彻解耦原则的典范，各个组件职责清晰，界限分明，所谓真正的设计优雅。1.1 版本的控制平面包括了下面几个组件：\nPilot：数据平面配置中心； Mixer: …","relpermalink":"/blog/istio-self-salvation/","summary":"本文基于 istio 最新的架构调整设计文档，分析了 istio 未来的设计目标","title":"回归单体 —— Istio 的自我救赎？"},{"content":"本文根据网易高级技术专家王国云于第九届 Service Mesh Meetup 杭州站上分享的整理而成。\n王国云 - 网易-Service Mesh Meetup 背景 Service Mesh 在严选的探索与实践大致分了以下几个阶段。\n第一个阶段是探索期（2015 年底~2016 年 4 月） 网易严选从 2015 年底开始内部孵化到 2016 年 4 月正式面世，这个阶段严选的技术团队规模非常小，差不多 10 人左右，核心业务采用的是单体架构，同时会依赖少量业务基础服务，如推送服务、文件存储服务、消息中心等等。\n在这个时期，如果我们将视野扩大到孵化严选的网易邮件事业部，当时采用的主流架构是面向服务的架构 (SOA)，但实现上并不统一，有使用中心化的 ESB 技术提供的服务、也有使用去中心化的 Spring Cloud 框架提供的服务。\n不管是 ESB 还是以 Spring Cloud 为代表的分布式服务框架，都有一些典型的问题需要解决，而严选作为一个现象级的电商产品，其可以预见的业务复杂度使得我们不得不重视这次关键的选型，稍有不慎，就有可能会带来非常大的技术负债。\n这次基础架构选型 …","relpermalink":"/blog/netease-yeation-service-mesh/","summary":"本文根据网易高级技术专家王国云于第九届 Service Mesh Meetup 杭州站上分享的整理而成。","title":"网易严选 ServiceMesh 实践"},{"content":"第九届 Service Mesh Meetup 杭州站，12 月 28 日在杭州滴滴举行，现场 150+ 参与，下面是现场合影（人太多，镜头没装下）。\n活动现场照片 视频回放与资料下载 地址：https://tech.antfin.com/community/activities/1056\n致谢 感谢以下单位的大力支持\n联合主办方蚂蚁金服金融科技 电子工业出版社赠书 滴滴提供场地支持 ","relpermalink":"/blog/service-mesh-meetup-hangzhou-20191228/","summary":"本期 Meetup 与滴滴联合举办，将深入 Service Mesh 的落地实践，并带领大家探索 Service Mesh 在更广阔领域的应用。","title":"第九届 Service Mesh Meetup 杭州站回顾"},{"content":"讲师与演讲话题 蚂蚁集团 API Gateway Mesh 的思考与实践 主讲人：贾岛\n在 Service Mesh 微服务架构中，我们常常会听到东西流量和南北流量两个术语。蚂蚁集团开源的 Service Mesh Sidecar MOSN 已经多次与大家见面交流了，以往的议题重点在东西流量的服务发现与路由，那么蚂蚁集团在南北流量上的思考是怎样的？本次分享，将从蚂蚁集团 API 网关发展历程来看，Mesh 化的网关架构是怎样的，解决了什么问题，双十一的实践表现，以及我们对未来的思考。\n酷家乐的 Istio 与 Knative 踩坑实录 主讲人：付铖\n酷家乐在部分业务模块，自 2018 年使用了 Istio 进行服务治理，自 2019 年使用了 Knative 作为 FaaS 基础设施，在实践过程中解决了大量问题，也积累了不少第一手经验。本次分享，将重点讨论服务网格的性能损耗，存量业务迁移难题，函数计算的冷启动时间问题以及解决方案等。\n云原生开放智能网络代理 MOSN 金融级云原生架构助推器 - 蚂蚁集团 主讲人：肖涵（涵畅）\n圆桌环节：Service Mesh 落地的务实与创新 主讲 …","relpermalink":"/event/service-mesh-meetup-09/","summary":"这是第七届 Service Mesh Meetup。","title":"Service Mesh Meetup #9 杭州站"},{"content":"本期为 Service Mesh Meetup#8 特别场，联合 CNCF、阿里巴巴及蚂蚁集团共同举办。\n不是任何一朵云都撑得住双 11。\n成交 2684 亿，阿里巴巴核心系统 100% 上云。\n蚂蚁集团的核心交易链路大规模上线 Service Mesh。\n这次，让双 11 狂欢继续，让云原生经得起双 11 大考，也让云原生走到开发者身边。\n你将收获 3 大经验加持：\n双 11 洗礼下的阿里巴巴 K8s 超大规模实践经验 蚂蚁集团首次 Service Mesh 大规模落地经验 阿里巴巴超大规模神龙裸金属 K8s 集群运维实践经验 讲师与演讲话题 释放云原生价值，双 11 洗礼下的阿里巴巴 K8s 超大规模实践 主讲人：曾凡松（逐灵） 、汪萌海（木苏）\n2019 双 11 点燃了全球人民的购物热情，而阿里经济体核心系统全面上云则刷爆了国内的技术圈子，引起了众多热爱云计算、云原生技术专家的热议。阿里巴巴是首个在超大规模体量公司内大规模使用 K8s 的公司，借此机会将为大家带来阿里巴巴在生产场景中大规模应用 K8s 的实践经验，包括在大规模应用管理上的经验教训；当前如何通过云原生方式高效管理 …","relpermalink":"/event/service-mesh-meetup-08/","summary":"这是第八届 Service Mesh Meetup。","title":"Service Mesh Meetup #8 北京站"},{"content":"Envoy 的内存占用 在 Istio 服务网格中，每个 Envoy 占用的内存也许并不算多，但所有 sidecar 增加的内存累积起来则是一个不小的数字。在进行商用部署时，我们需要考虑如何优化并减少服务网格带来的额外内存消耗。\n下面是在我环境中的一个实测数据：\nEnvoy 配置中的 Listener 和 Cluster 数量\nListener 数量 175 Cluster 数量 325 endpoint 数量 466 内存占用情况\n$ sudo docker stats 2e8fb CONTAINER CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS 2e8fb 0.75% 105.9 MiB / 256 MiB 41.39% 0 B / 0 B 0 B / 0 B 165 从上面的数据可以看到，在一个有 325 个 cluster 和 175 个 Listener 的服务网格中，一个 Envoy 的实际内存占用量达到了 100M 左右；网格中一共有 466 个实例，则所有 Envoy …","relpermalink":"/blog/envoy-memory-optimize/","summary":"在 Istio 服务网格中，每个 Envoy 占用的内存也许并不算多，但所有 sidecar 增加的内存累积起来则是一个不小的数字。在进行商用部署时，我们需要考虑如何优化并减少服务网格带来的额外内存消耗。","title":"如何降低 Istio 服务网格中 Envoy 的内存开销？"},{"content":" Banner 活动主题：Kubernetes \u0026amp; Cloud Native X Service Mesh Meetup 活动时间：2019 年 11 月 24 日（星期日）9:30-16:30 活动地点：北京朝阳大望京科技商务园区宏泰东街浦项中心 B 座 2 层多功能厅 活动形式：线下活动 活动报名：请戳这里 活动介绍 Service Mesh Meetup#8 特别场 本期为 Service Mesh Meetup#8 特别场，联合 CNCF、阿里巴巴及蚂蚁金服共同举办。\n不是任何一朵云都撑得住双 11。\n成交 2684 亿，阿里巴巴核心系统 100% 上云。\n蚂蚁金服的核心交易链路大规模上线 Service Mesh。\n这次，让双 11 狂欢继续，让云原生经得起双 11 大考，也让云原生走到开发者身边。\n你将收获 3 大经验加持：\n双 11 洗礼下的阿里巴巴 K8s 超大规模实践经验； 蚂蚁金服首次 Service Mesh 大规模落地经验； 阿里巴巴超大规模神龙裸金属 K8s 集群运维实践经验； 错过一次，再等一年哦。\nKubernetes \u0026amp; Cloud Native x …","relpermalink":"/blog/k8s-cloud-native-service-mesh-meetup/","summary":"11 月 24 日（周日），北京，Service Mesh Meetup#8 双十一特别场邀您参加，本期联合 CNCF、阿里巴巴及蚂蚁金服共同举办。","title":"第八届 Service Mesh Meetup 特别场：Kubernetes \u0026 Cloud Native X Service Mesh Meetup"},{"content":"本文为翻译文章，点击查看原文。\n编者按 目前 Kubernetes 的 Pod 水平自动伸缩（HPA，Horizontal Pod Autoscaler）已在业界广泛应用。但对一些特殊的 Pod（如一些有状态的 Pod），HPA 并不能很好地解决资源不足的问题。这就引出 Pod 垂直自动伸缩（VPA，Vertical Pod Autoscaler），本文主要介绍 Kubernetes 社区对 Pod 垂直自动伸缩组件的开发规划。\nVPA 定义 垂直自动伸缩（VPA，Vertical Pod Autoscaler） 是一个基于历史数据、集群可使用资源数量和实时的事件（如 OMM，即 out of memory）来自动设置 Pod 所需资源并且能够在运行时自动调整资源基础服务。\n介绍 背景 计算资源 资源服务质量 准入控制器 外部准入 webhooks 目标 VPA 有两个目标：\n通过自动配置资源请求来减少运维成本。 在提高集群资源利用率的同时最小化容器出现内存溢出或 CPU 饥饿的风险。 相关特性 水平自动伸缩（Horizontal Pod Autoscaler，HPA） HPA 是基于 …","relpermalink":"/blog/kubernetes-vertical-pod-autoscaler/","summary":"介绍 Kubernetes 社区对 Pod 垂直自动伸缩组件的开发规划。","title":"Kubernetes 垂直自动伸缩走向何方？"},{"content":" 作者：哗啦啦 mesh 团队，热衷于 kubernetes、devops、apollo、istio、linkerd、openstack、calico 等领域技术。\n概述 Linkerd2 由控制平面和数据平面组成：\n控制平面是在一个专门的 Kubernetes 命名空间（默认是 linkerd）中运行的一组服务，这些服务共同实现了聚合遥测数据、提供一组面向用户的 API、向数据平面提供控制指令等功能。\n数据平面由一组用 Rust 编写的轻量级代理组成，它们安装在服务的每个 pod 中。它通过initContainer配置iptables来接管 Pod 的所有出入流量。它对服务毫无侵入，服务本身不需要修改任何代码，甚至可以将它添加到正在运行的服务中。\n以下是官方的架构示意图：\nproxy-destination tap 是 Linkerd2 的一个非常有特色的功能，它可以随时抓取某资源的实时流量。有效的利用该功能可以非常方便的监控服务的请求流量情况，协助调试服务。\ntap 相关的功能组件如下：\nweb/CLI: 发起 tap 请求，展示 tap 监控结果 tap: 将来自web/CLI …","relpermalink":"/blog/linkerd2-proxy-tap-analysis/","summary":"在本文章中，能粗略了解到 linker2 的代理服务 proxy 组件中关于 tap 的交互原理。","title":"Linkerd2 proxy tap 学习笔记"},{"content":"前言 如果具有通信或者网络行业的知识背景，那么你对 SDN(Software Defined Network) 一定不会陌生。你也许已经注意到，近来在微服务领域兴起的 Service Mesh 和 SDN(Software Defined Network) 非常相似，这两者都采用了软件对网络进行管理和控制，也都采用了包含控制面和数据面的类似架构。\n那么 Service Mesh 和 SDN 有什么关系？Service Mesh 是下一代的 SDN 吗？Service Mesh 是否可以从 SDN 的发展历史中借鉴一些经验？本文将就这些问题进行一一探讨。\n传统网络面临的挑战 首先我们来回顾一下 SDN 的起源。传统的 IP 网络是一个分布式的无中心架构，各个网络设备包含完整的控制面和数据面，单个设备通过网络协议探测网络中其他设备的状态，自主决定如何对流量进行路由。该架构的好处是容错性强，即使网络局部出现故障，整个网络也可以自主恢复，不会影响整个网络的运行。\n在传统的网络架构下，控制面和数据面位于同一设备中 这种去中心的架构在基于文本和图片的 web 浏览器应用时代运作良好，但随着互联网业 …","relpermalink":"/blog/what-can-service-mesh-learn-from-sdn/","summary":"Service Mesh 和 SDN(Software Defined Network) 的架构非常相似，这两者都采用了软件对网络进行管理和控制，也都包含控制面和数据面的概念。那么 Service Mesh 和 SDN 有什么关系？Service Mesh 是下一代的 SDN 吗？Service Mesh 可以从 SDN 的发展历史中借鉴哪些经验？本文将就这些问题进行一一探讨。","title":"Service Mesh 是下一代 SDN 吗？"},{"content":" 作者：哗啦啦 mesh 团队，热衷于 kubernetes、devops、apollo、istio、linkerd、openstack、calico 等领域技术。\nlinkerd2 介绍 Linkerd 由控制平面和数据平面组成：\n控制平面是在所属的Kubernetes命名空间（linkerd 默认情况下）中运行的一组服务，这些服务可以完成汇聚遥测数据，提供面向用户的 API，并向数据平面代理提供控制数据等，它们共同驱动数据平面。\n数据平面用 Rust 编写的轻量级代理，该代理安装在服务的每个pod中，并成为数据平面的一部分，它接收 Pod 的所有接入流量，并通过initContainer配置iptables正确转发流量的拦截所有传出流量，因为它是附加工具，并且拦截服务的所有传入和传出流量，所以不需要更改代码，甚至可以将其添加到正在运行的服务中。\n借用官方的图：\nproxy-destination proxy 由 rust 开发完成，其内部的异步运行时采用了Tokio框架，服务组件用到了tower。\n本文主要关注 proxy 与 destination 组件交互相关的整体逻辑， …","relpermalink":"/blog/linkerd2-proxy-destination-analysis/","summary":"在本文章中，能粗略了解到 linker2 的代理服务 proxy 组件中关于 destination 的交互原理。","title":"linkerd2 proxy destination 学习笔记"},{"content":" 第七届 Service Mesh Meetup 成都站 《基于 5G 管理网络的服务网格实践》》 主讲人：赵化冰 中兴通讯 网管软件资深专家\n在通信网络向 5G 演进的过程中，电信行业借鉴了 IT 行业的微服务架构和云原生相关技术对 5G 网络功能进行重构，以提供敏捷、灵活、易于扩展的业务能力。本演讲主题将介绍在 5G 网络管理平台的微服务架构中落地微服务网格的产品实践，包括多网络平面支持、API 网关和网格 Ingress 的定位、Consul Registry 的性能增强等等。\n赵化冰 Service Mesh Meetup 成都站 《蚂蚁金服网络代理的演进之路》 主讲人：肖涵（涵畅）蚂蚁金服高级技术专家\n从网络硬件设备到自研平台，从传统服务治理到 Service Mesh，本次分享将介绍蚂蚁金服网络代理在接入层以及 Service Mesh 化道路上是如何一步步支撑秒级百万支付，千万红包请求的。\n肖涵（涵畅）Service Mesh Meetup 成都站 《进击的 Traefik——云原生边缘路由探秘》 主讲人：杨川胡（阳明）知群后台负责人\nTraefik 是一个云原生的边缘路 …","relpermalink":"/blog/service-mesh-meetup-chengdu-20191028/","summary":"本期 Meetup 邀请社区大咖，从服务网格下微服务架构设计、在 5G 时代的应用、如何使用开源的 Traefik 构建云原生边缘路由及蚂蚁金服的服务网格代理演进角度给大家带来精彩分享。","title":"第七届 Service Mesh Meetup 成都站回顾"},{"content":"本期 Meetup 邀请社区大咖，从服务网格下微服务架构设计、在 5G 时代的应用、如何使用开源的 Traefik 构建云原生边缘路由及蚂蚁集团的服务网格代理演进角度给大家带来精彩分享。\n讲师与演讲话题 服务网格技术在 5G 网络管理平台中的落地实践 赵化冰（中兴通讯网管软件资深专家）\n在通信网络向 5G 演进的过程中，电信行业借鉴了 IT 行业的微服务架构和云原生相关技术对 5G 网络功能进行重构，以提供敏捷、灵活、易于扩展的业务能力。本演讲主题将介绍在 5G 网络管理平台的微服务架构中落地微服务网格的产品实践，包括多网络平面支持、API 网关和网格 Ingress 的定位、Consul Registry 的性能增强等等。\n蚂蚁集团网络代理的演进之路 肖涵（蚂蚁集团高级技术专家）\n从网络硬件设备到自研平台，从传统服务治理到 Service Mesh，本次分享将介绍蚂蚁集团网络代理在接入层以及 Service Mesh 化道路上是如何一步步支撑秒级百万支付，千万红包请求的。\n进击的 Traefik——云原生边缘路由探秘 杨川胡（知群后台负责人）\nTraefik 是一个云原生的边缘路由 …","relpermalink":"/event/service-mesh-meetup-07/","summary":"这是第七届 Service Mesh Meetup。","title":"Service Mesh Meetup #7 成都站"},{"content":"Istio Pilot 组件介绍 在 Istio 架构中，Pilot 组件属于最核心的组件，负责了服务网格中的流量管理以及控制面和数据面之间的配置下发。Pilot 内部的代码结构比较复杂，本文中我们将通过对 Pilot 的代码的深入分析来了解 Pilot 实现原理。\n首先我们来看一下 Pilot 在 Istio 中的功能定位，Pilot 将服务信息和配置数据转换为 xDS 接口的标准数据结构，通过 gRPC 下发到数据面的 Envoy。如果把 Pilot 看成一个处理数据的黑盒，则其有两个输入，一个输出：\nPilot 的输入与输出 目前 Pilot 的输入包括两部分数据来源：\n服务数据：来源于各个服务注册表 (Service Registry)，例如 Kubernetes 中注册的 Service，Consul Catalog 中的服务等。 配置规则：各种配置规则，包括路由规则及流量管理规则等，通过 Kubernetes CRD(Custom Resources Definition) 形式定义并存储在 Kubernetes 中。 Pilot 的输出为符合 xDS 接口的数据面配置数 …","relpermalink":"/blog/pilot-code-deep-dive/","summary":"Istio Pilot 组件介绍 在 Istio 架构中，Pilot 组件属于最核心的组件，负责了服务网格中的流量管理以及控制面和数据面之间的配置下发。Pilot 内部的代码结构比较复杂，本文中我们将通过对 Pilot 的代码的深入分析来了解 Pilot 实现原理。\n","title":"Istio Pilot 代码深度解析"},{"content":"本文为翻译文章，点击查看原文。\n编者按 本文作者介绍了企业组织采用服务网格面临的哪些挑战，建议企业应该从数据平面开始逐步推进，从了解它、熟悉它、再到扩大规模使用它，并且以介绍其演讲的幻灯片为切入点介绍了架构演进的步骤。\n正文 最近，我写了一篇关于在企业组织中采用服务网格的具有哪些挑战的文章，这篇文章是为 DZone 及其迁移到微服务的报告撰写的。在这篇文章中，我们首先要解决的问题之一是“你是否应该沿着采用服务网格的道路走下去”，我是这么说的：\n首先回答“不”。如果您刚刚开始使用微服务架构和少量的服务，请确保您首先准备好了基础部分。微服务及其相关的基础设施是一种优化方式，可以让您更快的变更应用程序。在没有服务网格的情况下，您可以朝着更快的方向前进。你甚至可能想要一些服务网格带来的好处，而不是去关注它所有的复杂性。那么，请看看类似 Gloo 的产品，一个建立在 Envoy 代理上的 API 网关。\n我认为在当前时刻，这是一个非常重要的考虑，有以下两大原因：\n总的来看，服务网格的实现还没有准备好投入生产。 全部投入 (all-in) 到一个服务网络的复杂性仍然很高。 这并不意味着没有团队成功 …","relpermalink":"/blog/challenges-of-adopting-service-mesh-in-enterprise-organizations/","summary":"本文作者介绍了企业组织采用服务网格具有哪些挑战，并且结合自身经验给企业组织提出了推进服务网格的建议。","title":"企业组织中采用服务网格的挑战"},{"content":"作者：马若飞，lead software engineer in FreeWheel，《Istio 实战指南》作者，ServiceMesher 社区管委会成员。\n前言 近两年随着微服务架构的流行，服务网格（Service Mesh）技术受到了越来越多的人关注，并拥有了大批的拥趸。目前市面上比较成熟的开源服务网格主要有下面几个：Linkerd，这是第一个出现在公众视野的服务网格产品，由 Twitter 的 finagle 库衍生而来，目前由 Buoyant 公司负责开发和维护；Envoy，Lyft 开发并且是第一个从 CNCF 孵化的服务网格产品，定位于通用的数据平面或者单独作为 Sidecar 代理使用；Istio，由 Google、IBM、Lyft 联合开发的所谓第二代服务网格产品，控制平面的加入使得服务网格产品的形态更加完整。\n服务网格技术作为构建云原生应用的重要一环，逐渐的被越来越多的人和厂商认可，并看好它的发展前景。在 Istio 大红大紫的今天，作为和 Google 在云服务市场竞争的 Amazon 来说，自然不愿错失这块巨大的蛋糕。他们在今年 4 月份发布了自己的服务网格产 …","relpermalink":"/blog/compare-appmesh-with-istio/","summary":"本文从架构和功能等方面较为全面的对比了 AWS App Mesh 和 Istio 两个服务网格产品。","title":"AWS App Mesh vs Istio"},{"content":" 本文通过 spotguides——一个示例 spring-boot 应用，讲了 Banzai Cloud 是如何通过 Istio operator 来实现 pod 水平扩展。\n基于自定义 Istio 指标的 Pod 水平自动缩放 Pipeline的核心功能之一，Banzai Cloud 的应用程序和 devops 容器管理平台，是多维的并可以基于默认和自定义指标进行自动调节。在我们引入自定义指标后，我们选择了通过Prometheus 适配器从Prometheus收集指标。从那时起，我们的许多客户开始使用 Hoizontal Pod Autoscaling，他们中的大多数人只对基本的 CPU 和内存指标感到满意。\n我们一直都知道这不是一个理想的解决方案，我们一直在努力寻求更灵活的解决方案，以便：\n基于自定义Prometheus 指标的扩展 为更复杂的Prometheus 查询提供扩展支持 随着我们的开源Istio operator的发布以及在Pipeline 平台上广泛引入基于 Istio 的服务网格，我们也提供了根据自定义的 Istio 指标的自动缩放功能。Prometheus 现在 …","relpermalink":"/blog/horizontal-pod-autoscaling-based-on-custom-istio-metrics/","summary":"本文通过 spotguides，一个示例 spring-boot 应用，讲了 Banzai Cloud 是如何通过 Istio operator 来实现 pod 水平扩展。","title":"基于自定义 Istio 指标的 Pod 水平自动缩放"},{"content":"本文为翻译文章，点击查看原文。\n编者按 许多 Kubernetes 用户，特别是那些企业级用户，很快就遇到了对环境自动缩放的需求。幸运的是，Kubernetes Horizontal Pod Autoscaler（HPA）允许您将部署配置为以多种方式水平扩展。使用 Kubernetes Autoscaling 的最大优势之一是您的集群可以跟踪现有 Pod 的负载能力，并计算是否需要更多的 Pod。\nKubernetes Autoscaling 通过协调内置的两层可扩展性，可以充分利用高效的 Kubernetes Autoscaling：\nPod 级别的自动缩放：包括 Horizontal Pod Autoscaler（HPA）和 Vertical Pod Autoscaler（VPA）; 两者都可以扩展容器的可用资源。 集群级别的自动缩放：集群自动调节器（CA）通过在必要时向上或向下扩展集群内的节点数来管理这种可扩展性平面。 Kubernetes Autoscaling 详情 Horizontal Pod Autoscaler (HPA) HPA 会在集群中缩放 Pod 副本的数量。该 …","relpermalink":"/blog/k8s-autoscaling-all-you-need-to-know/","summary":"本文介绍了 kubernetes 的几种缩放方式：HPA、VPA、cluster scaler，并提供了两个测试用例以供测试和学习。","title":"你必知的 Kubernetes 自动缩放"},{"content":"本文为翻译文章，点击查看原文。\n编者按 作者简要介绍了熔断的概念，然后以实战演练的方式分别演示了如何通过 Backyards UI、CLI 等方式创建并设置熔断功能。注：Backyards 是 Banzai Cloud 开发的一款基于 Istio 的服务网格产品，本文是该产品功能介绍系列中的一篇。\n前言 Istio 因灵活的可观察性和安全的服务间通信受到了赞许。然而，其他更重要的功能才真正使得 Istio 成为了服务网格里的瑞士军刀，当遇到运行时长、延迟和错误率等 SLO 问题时，服务间的流量管理能力是至关重要的。\n在今年早些时候发布 Istio operator 时，我们的目标（除了管理 Istio 的安装和升级）是为这些出色的流量路由特性提供支持，同时使所有的功能都更加易用。最后，我们创建了一个简单且自动化的服务网格Backyards，它在 Istio operator 之上提供了管理 UI、CLI 和 GraphQL API 的能力。Backyards 集成到了 Banzai Cloud 的容器管理平台 Pipeline中，也可以作为一个单一的产品独立工作。当然， …","relpermalink":"/blog/istio-circuit-breaking/","summary":"本文展示了如果通过 Backyards 创建熔断。","title":"Istio 熔断器解析"},{"content":"本文为翻译文章，点击查看原文。\n编者按 本文强调了应用程序定制指标的重要性，用代码实例演示了如何设计指标并整合 Prometheus 到 Django 项目中，为使用 Django 构建应用的开发者提供了参考。\n为什么自定义指标很重要？ 尽管有大量关于这一主题的讨论，但应用程序的自定义指标的重要性怎么强调都不为过。和为 Django 应用收集的核心服务指标（应用和 web 服务器统计数据、关键数据库和缓存操作指标）不同，自定义指标是业务特有的数据点，其边界和阈值只有你自己知道，这其实是很有趣的事情。\n什么样的指标才是有用的？考虑下面几点：\n运行一个电子商务网站并追踪平均订单数量。突然间订单的数量不那么平均了。有了可靠的应用指标和监控，你就可以在损失殆尽之前捕获到 Bug。 你正在写一个爬虫，它每小时从一个新闻网站抓取最新的文章。突然最近的文章并不新了。可靠的指标和监控可以更早地揭示问题所在。 我认为你已经理解了重点。 设置 Django 应用程序 除了明显的依赖（pip install Django）之外，我们还需要为宠物项目（译者注：demo）添加一些额外的包。继续并安装pip …","relpermalink":"/blog/custom-application-metrics-with-django-prometheus-and-kubernetes/","summary":"本文演示如果为一个 Django 应用添加 Prometheus 自定义指标。","title":"使用 Django，Prometheus，和 Kubernetes 定制应用指标"},{"content":"本文为翻译文章，点击查看原文。\n编者按 2019 年 9 月 10 日，Kong 正式宣布开源一款 Service Mesh：Kuma。此消息一出，立即在云原生社区引起反响，各大媒体争相报道。让我们跟随 SDxCentral 的总编辑，一起来看看 Kong 的 CTO 如何介绍 Kuma 这款 Service Mesh 产品以及对于 SMI 的看法。关于 Kuma 的具体功能介绍可以阅读官网博客以及Github。\n翻译一下其 Github 关于 Kuma 功能特性的简介如下，方便读者了解：\n通用的控制平面: 易于使用，分布式，可以在任何平台运行。 轻量的数据平面: 基于 Envoy，可处理任意类型流量。 自动化: 在 K8s 平台上部署无需任何代码改动，也可在虚拟机上灵活部署。 多租户: 可在一个集群与同一个控制平面上部署多套服务网格。 网络安全: 自动 mTLS 加密。 流量分割: 灵活的 ACL 规则。 流量追踪: 与 Zipkin 和 Jaeger 自动集成。 流量指标: 与Prometheus/Splunk/ELK自动集成。 代理配置模版: 方便进阶 (收费) …","relpermalink":"/blog/kong-open-sources-kuma-the-universal-service-mesh/","summary":"本文引述了 Kong 的 CTO 对 Kuma 这款 Service Mesh 产品的介绍以及对于 SMI 的看法。","title":"服务网格 Kuma 爬过了 K8S 这座大山"},{"content":" 编者按 本文从多个维度阐述了使用更少的大节点与更多的小节点来组建 Kubernetes 集群各自的优势与劣势，并结合实践经验给出了选择工作节点数量和大小的一般方法。\n引言 欢迎来到 Kubernetes 学习园地，这是一个常规专栏，收集整理了我们在线上以及线下研讨会上由 Kubernetes 专家回答的最有意思的问题。\n今天问题的答案由 Daniel Weibel 给出。Daniel 是一名软件工程师，同时也是 Learnk8s 的讲师。\n如果您希望在下一期中展示您的问题，请通过邮件联系我们或者在 tweet 上 @learnk8s。\n错过了前几期？点击这里查看往期内容。\n在创建 Kubernetes 集群时，您首先会想到的问题之一就是：“我应该创建何种类型的工作节点，以及应该创建多少个？”。\n如果您正在搭建内部集群，是应该购买最新一代的超级服务器，还是使用数据中心里的十几台旧机器呢？\n或者您使用的是托管 Kubernetes 服务，例如 Google Kubernetes Engine (GKE)，是应该使用 8 个 n1-standard-1 实例，还是应该使用 2 …","relpermalink":"/blog/architecting-kubernetes-clusters-choosing-a-worker-node-size/","summary":"本文从多个维度阐述了使用更少的大节点与更多的小节点来组建 Kubernetes 集群各自的优势与劣势，并结合实践经验给出了选择工作节点数量和大小的一般方法。","title":"构建 Kubernetes 集群 —— 选择工作节点数量和大小"},{"content":"编者按 本文简要介绍了 AWS App Mesh 的基本概念，并通过一个示例演示了如何在 AWS 的控制台创建一个 App Mesh 的服务网格。\n前言 AWS App Mesh 可以帮助你运行和监控大规模的 HTTP 和 TCP 服务。你可以用一致的方式来路由和监控流量，获得发现问题的能力，并在失败或代码更改后重新路由流量。App Mesh 使用开源的Envoy代理，让你可以使用来自 AWS 合作伙伴和开源社区的各种工具。\n服务可以运行在AWS Fargate， Amazon EC2，Amazon ECS， Amazon Elastic Container Service for Kubernetes 或 Kubernetes上。每个服务的所有进出流量都经过 Envoy 代理，以便对其进行路由、可视化、测量和记录。这种额外的间接层让你可以用任何想要的语言构建服务，而不必使用一组公共的通信库。\nApp Mesh 基本概念 在深入了解之前，让我们先来回顾一下 App Mesh 里的重要概念和组件：\n服务网格 – 网络流量在其服务之间的逻辑边界。网格可以包含虚拟服务、虚拟节点、虚拟路由器和 …","relpermalink":"/blog/aws-app-mesh-application-level-networking-for-cloud-applications/","summary":"本文演示了如何在 AWS 控制台创建一个 App Mesh","title":"AWS App Mesh - 云应用的服务网格"},{"content":"KUN（中文名鲲）是 UCloud 面向内部的基于 Kubernetes 的资源交付平台，提供监控告警、CI/CD、网络双栈、Service Mesh 等能力。在践行 Service Mesh 理念的过程中，面对 Istio 的不足，团队针对其源码做了大量改进，包括给网络子系统 Pilot 下的资源做隔离，对 EnvoyFilter 做深度优化等，使其能在生产环境稳定运行，并提供强大的扩展能力。截止目前，KUN 平台上已有 175 个应用通过 Istio 提供服务。下面将分享我们在这方面的实践经验。\nIstio 流量管理策略 Istio 中的流量管理策略是通过 Pilot 统一管理下发给 Envoy 的，Envoy 作为数据面，对外提供 XDS 接口。为了保证最终一致性，Pilot 实现了 Envoy 提供的 ADS(Aggregated Discovery Service) 接口，执行顺序为：CDS, EDS, LDS, RDS。Pilot 本身是无状态的，所有的资源配置全部以 CRD 实例的形式保存在 Kubernetes 集群上，Envoy 和 Pilot 连接建立完成以 …","relpermalink":"/blog/using-envoyfilter-extend-istio/","summary":"EnvoyFilter 是 Istio 中自定义的一种网络资源对象，用来更新配置 Envoy 中的 filter，为服务网格控制面提供了强大的扩展能力。","title":"Kubernetes 上的 Service Mesh 实践：用 EnvoyFilter 扩展 Istio"},{"content":" 微服务架构被认为是构建大型复杂系统的最佳理论指导，其采用了分而治之、单一职责、关注点分离等方法论来设计系统架构。微服务的实现方式和思路有很多种，本文简述基于 kubernetes 的微服务平台建设思路及技术选型。\n应用架构发展历史 要了解微服务架构提出的背景，首先我们来看一下应用架构的发展历程，如下图所示： application.png 单体应用：传统应用的开发技术为.NET、J2EE 等技术，开发完成后部署在 websphere、weblogic 这样的商业容器中（或者开源的 tomcat）。应用间的交互一般通过 CORBA、DCOM 这样 RPC 风格的组件进行，此时并没有服务化的概念。部署的环境一般为小型机、服务器。 SOA 架构：业界在意识到了系统集成标准化的重要性后，提出了 SOA 的理念。SOA 强调的是服务化、标准化，通过制定统一的应用接口标准，所有的应用都可以方便的提供服务，并且也可以快速调用其他应用提供的服务，通过一个集中化的服务中间件，系统集成的效率大大提高。经典的落地场景就是 ESB 企业服务总线。交互协议多用基于 SOAP 的 web service。在这个 …","relpermalink":"/blog/201909-build-full-micro-service-platform-by-spring-boot-with-kubernetes/","summary":"本文简述基于 kubernetes 的微服务平台建设思路及技术选型。","title":"使用 spring boot+kubernetes 构建完整微服务平台"},{"content":" 在 Kubernetes 中运行大规模以 Web 为中心的工作负载，最关键的需求之一就是在 L7 层实现高效流畅的入口流量管理。自从第一批 Kubernetes Ingress Controller 开发完成以来，Envoy（由 Matt Klein 和 Lyft 团队开发）已经成为云原生生态系统中的新生力量。Envoy 之所以受到支持，因为它是一个 CNCF 托管的项目，与整个容器圈和云原生架构有着天然的支持。\n容器公司 Heptio 开源的项目 Contour 使用 Envoy 作为 Kubernetes 的 Ingress Controller 实现，为大家提供了一条新的 Kubernetes 外部负载均衡实现思路。\n据官方博客介绍，Heptio Contour 可以为用户提供以下好处：\n一种简单的安装机制来快速部署和集成 Envoy。 与 Kubernetes 对象模型的集成。 Ingress 配置的动态更新，而无需重启底层负载均衡器。 项目成熟后，将允许使用 Envoy 一些强大的功能，如熔断器、插件式的处理器链，以及可观测性和可调试性，可以非常方便地对接监控系统。 …","relpermalink":"/blog/use-envoy-as-a-kubernetes-ingress/","summary":"Contour 使用 Envoy 作为 Kubernetes 的 Ingress Controller 实现，为大家提供了一条新的 Kubernetes 外部负载均衡实现思路。本文介绍了 Contour 分布式架构的工作原理，Envoy 初始配置以及后续动态配置的下发流程，最后通过 Prometheus-Operator 抓取 Contour 的监控指标。","title":"Contour 学习笔记（一）：使用 Contour 接管 Kubernetes 的南北流量"},{"content":" 作者：Min Kim(yue9944882)，Kubernetes 社区 CRD 维护者，蚂蚁金服高级研发工程师。Kubernetes 1.16 扩展性 GA Sprint 迭代组成员，主要负责 CRD OpenAPI 聚合发布相关特性。\n随着近段时间以 CRD（CustomResourceDefinition）的形式扩展 Kubernetes 火爆起来，在开源社区涌现了许许多多用 CRD 作为平台构建应用的成功开源项目。整个社区对 CRD 的积极拥抱其实是远在维护者们的期望之外的。然而经过 5 个 release 的洗礼，CRD 从最开始的实验性项目渐渐变得清晰了起来，社区对 CRD 模型提出的许许多多建议或者挑战，将在本次 1.16 的版本得到完整的解决和回应。CRD 的 GA 计划从 1.14 版本开始斩露萌芽到 Kubenretes 1.16 全力冲刺的研发周期中，主要过程是来自谷歌和红帽的工程师在执行，还有少数的社区志愿者。\n通过本篇文章，作者将通过梳理 CRD 的 GA 进化中的主要革新点，同时结合 CRD 面临的问题/缺陷进而推导出其中的联系/因果，在最后还会对 CRD …","relpermalink":"/blog/kubernetes-1.16-crd-ga-preview/","summary":"本文以社区 CRD 维护者的角度前瞻 1.16CRD 的 GA 进化主要的革新与应对。","title":"全面进化：Kubernetes CRD 1.16 GA 前瞻"},{"content":"本文为翻译文章，点击查看原文。\n编者按 本文是一篇介绍容器运行时和管理工具的文章。文中对主要的容器管理项目和技术做了较为详细的介绍和横向对比，并给出了项目的代码库供读者参考。\n前言 容器带来了更高级的服务端架构和更复杂的部署技术。目前已经有一堆类似标准的规范（1, 2, 3, 4, ……）描述了容器领域的方方面面。当然，它的底层是 Linux 的基本单元，如 namespace 和 cgroups。容器化软件已经变得非常的庞大，如果没有它自己关注的分离层，几乎是不可能实现的。在这个持续努力的过程中，我尝试引导自己从最底层到最高层尽可能多的实践（代码、安装、配置、集成等等），当然还有尽可能多的获得乐趣。本篇内容会随着时间的推移而改变，并反映出我对这一主题的理解。\n容器运行时 我想从最底层的非内核原语说起——容器运行时。在容器服务里，运行时这个词是有歧义的。每个项目、公司或社区对术语容器运行时都有自己的、通常是基于上下文的特定理解。大多数情况下，运行时的特征是由一组职责定义的，从最基本的职责（创建 namespace、启动init进程）到复杂的容器管理，包括（但不限于）镜像操作。这篇文章对 …","relpermalink":"/blog/journey-from-containerization-to-orchestration-and-beyond/","summary":"本文是一篇介绍容器运行时和管理工具的文章，对主要的容器管理工具做了介绍","title":"容器化到容器编排之旅"},{"content":" 前言 在 2019 年的今天，微服务这个词相信对于绝大多数的开发者都已经不再陌生。时至今日，非常多的项目都逐渐开始实践起微服务这一设计思想，将原本的磐石应用逐渐按照领域模型切分成一个个小的服务，对于微服务的实践也日渐趋向于成熟。在笔者目前工作的业务实践中，同样也使用着微服务作为后端服务的架构设立思想，微服务为我们的代码管理与项目管理带来了非常大的简便性。然而随着需求的迭代与代码的日益积累，曾经泾渭分明、代码精简的各个微服务也逐渐开始变得逻辑复杂、代码冗余，同时每个微服务之间有似乎存在着剪不断理还乱的关系。2019 年是 Serverless 蓬勃发展的一年，作为 Serverless 领域的中的明星产品，Knative 在今年 8 月份发布了 0.8 版本，其中 Serving 组件的 0.8 版本在笔者看来才真正达到了可用的程度。本篇文章将介绍笔者是如何使用 Knative 来作为 API 聚合层，来解决我们在实践微服务中所遇到的问题的。\n微服务迭代之痛 在笔者目前的工作实践中，我们在架构设计中严格遵循着微服务的设计理念。每块业务上独立的领域作为一个微服务，每个微服务有自己单独的数 …","relpermalink":"/blog/using-knative-as-api-aggregator-layer/","summary":"本文是介绍通过 Knative 在实际业务中起到 API 聚合层，从而解决在微服务架构中复杂接口痛点的实践。","title":"使用 Knative 作为 API 聚合层的实践"},{"content":"什么是 GitOps? GitOps, 这已经并不是一个新鲜的概念了。2018 年 5 月初在丹麦举行的哥本哈根 KubeCon 大会上，Weaveworks 公司的演讲将 GitOps 与 Istio Service Mesh 进行了集成，如果说以前 Docker Swarm 与 Kubernetes 竞争之时 Docker 公司提出了 Docker Native，CNCF 基于 Kubernetes 提出了自己的 Cloud Native，毫不夸张的说，Weaveworks 公司开源的 Weave Flux 也可以说是 GitOps 的‘Native’了。而在 2019 年 8 月 20 日，Flux 项目也最终成功加入了 CNCF Sandbox，成为了 CNCF Sandbox 中的一员。\nflux-cd-diagram.png 当然，GitOps 的概念是从 DevOps 慢慢延伸出来的。把时间轴向前调调整，如 2014 年左右如火如荼的 DevOps 一样，当时从大到小的互联网企业都在招聘 DevOps 工程师。然而慢慢脱离了以前 DevOps 理念的不成熟， …","relpermalink":"/blog/flux-get-start-easy/","summary":"本文对 GitOps 理念进行了深入的理解和详细的介绍，并使用 Weaveworks 开源的 GitOps 工具 Flux 通过 Git 管理 Kubernetes 集群。","title":"基于 Flux 项目的云原生 GitOps 实践"},{"content":"本文为翻译文章，点击查看原文。\n编者按 云原生领域，Go 几乎成了垄断编程语言。本文作者团队另辟蹊径，向读者们展示了如何使用最流行的编程语言之一 Python 创建一个可靠的 Kubernetes operator。\n前言 目前，人们创建 Kubernetes operator 时，Go 编程语言几乎成了唯一选择。他们的偏好来自如下客观原因：\n有一个强大的框架支持基于 Go 开发 operator - Operator SDK。 许多基于 Go 的应用程序，如 Docker 和 Kubernetes，已经成为游戏的主导者。用 Go 编写 operator 可以让你用同一种语言与生态系统对话。 基于 Go 的应用程序的高性能以及开箱即用的并发机制。 但是，如果缺乏时间或者仅仅是没有动力去学习 Go 语言呢？在本文中，我们将向您展示如何使用几乎所有 DevOps 工程师都熟悉的最流行的编程语言之一 Python 创建一个可靠的 operator。\n欢迎 Copyrator — the copy operator 为了使事情变得简单实用，让我们创建一个简单的 operator： …","relpermalink":"/blog/kubernetes-operator-in-python/","summary":"本文向读者们展示了如何使用流行编程语言 Python 创建一个可靠实用的 operator，并且不依赖于任何框架与 SDK。","title":"实现 Kubernetes Operator 的新方式：Python"},{"content":"本文为翻译文章，点击查看原文。\n一篇杂烩文，虽然结构比较混乱，但是对微服务相关概念的介绍还是较为全面的。\n微服务能在企业中发挥积极作用。因此了解微服务架构（MSA）设计的一般目标或原则，以及一些微服务的设计模式，都是是很有意义的。\n降低成本：MSA 降低了 IT 服务的设计、实现和管理的总体成本。 提高交付速度：MSA 能够提高服务的实现速度。 增强健壮性：MSA 能够增强我们服务网络的健壮性。 提供可视化支持：MSA 能够为服务和网络提供更好的可视化支持。 你需要理解微服务架构的构建原则：\n伸缩能力 可用性 健壮性 弹性 独立的匿名服务 去中心化的治理 故障隔离 自动供给 通过 DevOps 实现持续交付 在系统建设中，坚持上述原则会遭遇很多挑战和问题。这些问题在很多解决方案中都会出现。如果能够正确的使用合适的设计模式，就能够克服这些问题。微服务的设计模式可以分为五大类，每个大类中都包含一些设计模式。\ntree 拆分模式 根据业务能力进行分解的方式，能降低服务耦合度，实现单一职责的服务目标。这里说的业务能力是来自业务架构模型的一个概念，是企业用来创造价值的行为。业务能力通常对应到业务 …","relpermalink":"/blog/design-patterns-for-microservices/","summary":"本文详细的介绍了微服务的多种设计模式。","title":"微服务的设计模式"},{"content":" 第六届 Service Mesh Meetup 《虎牙直播在微服务改造方面的实践》 张波 虎牙基础保障部中间件团队负责人\n本次主要分享虎牙注册中心、名字服务、DNS 的改造实践，以及如何通过 Nacos 实现与 istio 打通实现，使微服务平滑过渡到 service mesh。\n张波 虎牙基础保障部中间件团队负责人 《Service Mesh 在蚂蚁金服的生产级安全实践》 彭泽文 蚂蚁金服高级开发工程师\n介绍通过 Envoy SDS（Secret Discovery Service）实现 Sidecar 证书管理的落地方案；分享如何为可信身份服务构建敏感信息数据下发通道，以及 Service Mesh Sidecar 的 TLS 生产级落地实践。\n彭泽文 蚂蚁金服高级开发工程师 《基于 Kubernetes 的微服务实践》 涂小刚 慧择网运维经理\n介绍如何跟据现有业务环境情况制定容器化整体解决方案，导入业务进入 K8S 平台，容器和原有业务环境互通。制订接入规范、配置中心对接 K8S 服务、网络互通方案、DNS 互通方案、jenkins-pipeline 流水线构建方案、日志采集方 …","relpermalink":"/blog/service-mesh-meetup-guangzhou-20190811/","summary":"ServiceMesher 社区和蚂蚁金服联合主办的第六届 Service Mesh Meetup 广州站收官，来自虎牙的张波、慧择网的涂小刚、蚂蚁金服的彭泽文、敖小剑为社区带来精彩分享。","title":"第六届 Service Mesh Meetup 广州站回顾"},{"content":"讲师与演讲话题 虎牙直播在微服务改造方面的实践 张波 虎牙基础保障部中间件团队负责人\n本次主要分享虎牙注册中心、名字服务、DNS 的改造实践，以及如何通过 Nacos 实现与 istio 打通实现，使微服务平滑过渡到 service mesh。\nService Mesh 在蚂蚁集团的生产级安全实践 彭泽文 蚂蚁集团高级开发工程师\n介绍通过 Envoy SDS（Secret Discovery Service）实现 Sidecar 证书管理的落地方案；分享如何为可信身份服务构建敏感信息数据下发通道，以及 Service Mesh Sidecar 的 TLS 生产级落地实践。\n基于 Kubernetes 的微服务实践 涂小刚 慧择网运维经理\n介绍如何跟据现有业务环境情况制定容器化整体解决方案，导入业务进入 K8S 平台，容器和原有业务环境互通。制订接入规范、配置中心对接 K8S 服务、网络互通方案、DNS 互通方案、jenkins-pipeline 流水线构建方案、日志采集方案、监控方案等。\nService Mesh 发展趋势（续）： …","relpermalink":"/event/service-mesh-meetup-06/","summary":"这是第六届 Service Mesh Meetup。","title":"Service Mesh Meetup #6 广州站"},{"content":"本文为翻译文章，点击查看原文。\n编者按 本文是一篇 Kafka 的基准测试分析报告，作者详细介绍了测试的环境和配置选择，并在单集群、多集群、多云、混合云等各种场景下进行了 A/B 测试和性能分析，评估了 Istio 的引入对性能的影响情况。最后对作者所在公司 Banzai Cloud 的云产品进行了介绍。\n我们的容器管理平台Pipeline以及 CNCF 认证的 Kubernetes 发行版PKE的一个关键特性是，它们能够在多云和混合云环境中无缝地构建并运行。虽然Pipeline用户的需求因他们采用的是单云方法还是多云方法而有所不同，但通常基于这些关键特性中的一个或多个：\n多云应用管理 一个基于 Istio 的自动化服务网格，用于多云和混合云部署 基于 Kubernetes federation v2（集群联邦）的联合资源和应用部署 随着采用基于Istio operator的多集群和多混合云的增加，对运行接入到服务网格中的分布式或去中心化的应用的能力的需求也增加了。我们的客户在 Kubernetes 上大规模运行的托管应用之一是Apache Kafka。我们认为， …","relpermalink":"/blog/running-apache-kafka-over-istio-benchmark/","summary":"作者对在 Istio 环境下运行的 Kafka 进行了基准测试，并对测试结果进行了分析。","title":"运行在 Istio 之上的 Apache Kafka——基准测试"},{"content":" 在微服务架构中，API 网关是一个十分重要的存在。一方面它为外部的流量访问提供了统一的入口，使得可以方便的进行防火墙的策略实施；另一方面，可以在网关处进行流量控制、认证、授权、灰度发布、日志收集、性能分析等各种高级功能，使得业务功能与非业务功能有效解耦，给予了系统架构更大的灵活性。本系列文章尝试分析目前主流的云原生微服务网关，并比较它们各自的优劣。\n网关选型标准 其实 kubernetes 本身有一个 ingress controller，基于 Nginx 或 HAProxy 等 7 层代理进行流量的转发。不过 ingress 只能进行简单的反向代理，不支持流控、灰度、认证、授权等网关必备的功能。所以一般意义认为，ingress 是一个 7 层 http 代理，而非 api 网关。本系列主要分析 Ambassador、Traefik、Kong 等具备微服务所需能力的网关产品。\n什么是 Ambassador？ 这里引用官网的一段描述\nAmbassador 是一个基于 Envoy proxy 构建的，kubernetes 原生的开源微服务网关。Ambassador 在构建之初就致力于支持 …","relpermalink":"/blog/cloud-native-api-gateway-part-1/","summary":"在微服务架构中，API 网关是一个十分重要的存在。在云原生时代，API 网关有了新的定义和发展。本系列文章尝试分析目前主流的云原生微服务网关，并比较各自的优劣。","title":"构建云原生微服务网关 - 篇一：Ambassador"},{"content":"随着容器技术的流行，大量互联网公司和传统 IT 企业都在尝试应用容器化和服务上云。容器化是一个持续的过程，伴随着多地域部署、安全等级隔离、多云和混合云等复杂的场景需求。\n上篇文章中我们成功将广州和新加坡 2 地的 kubernetes 集群连通为一个服务网格，实现了多集群服务透明共享：recommend v1 和 recommend v2 分别部署在广州和新加坡地域，但是两地用户都可以无差别的访问到任一版本。\nimage-20190730145706365 接下来我们上述环境中，尝试几个多集群服务网格的应用场景，包括：\n异地容灾\n地域感知负载均衡\n多地域负载策略分析\n相关代码汇总于：zhongfox/multicluster-demo\n异地容灾 要保证系统高可用和良好的用户体验，服务多副本部署、特别是异地多副本部署是必不可少的架构，即使对于吞吐量低压力小的应用，考虑「墨菲定律」单点部署仍是应该尽量避免的。对于 SLA 要求较高的关键系统，两地部署甚至多地部署应对容灾也是非常必要的。\n在已部署的环境中，我们尝试将广州集群中的 recommend v1 服务副本数删除至 0 个，模拟广州集 …","relpermalink":"/blog/istio-analysis-6/","summary":"利用 istio 多集群能力实现「异地容灾」和「地域感知负载均衡」","title":"Istio 庖丁解牛六：多集群网格应用场景"},{"content":"本文为翻译文章，点击查看原文。\n编者按 本文作者洞察全局，高屋建瓴，结合当前服务网格的形势，分析了服务网格普遍的局限性，以及从开发者角度讲述服务网格带来的三个有价值的好处：可观测性、流量控制和安全。本文的观点阐述详细而深刻，涵盖了服务网格的关键性技术与架构，以及许多备受瞩目与广泛探讨的话题。\n正文 欢迎来到关于服务网格的优势和运维局限的系列文章的第 2 部分。在第 1 部分中，我们了解了开发人员如何从服务网格为微服务架构提供附加的可观察性、流量控制和安全功能的能力中获益。在这篇文章中，我们将关注同样的三个维度，但不同于开发人员关心的问题，我们会从运维团队的角度深入研究服务网格的局限性。\n可观测性的限制 可观察性始终是分布式系统工程师的首选。因此，服务网格尽其所能来满足这种需求就不足为奇了。然而，工程师期望的以及服务网格提供的可观察性并没有针对传统的运维行为，比如容量规划：它关注的是运行时调试的开发活动。\n当然，运行时调试要求指标在请求的执行线程上下文中是“可解释的”。这与当今联合的，有组织发展的服务架构（Organic Architecture）是不一致的，它的度量标准是不可预测和不确 …","relpermalink":"/blog/service-mesh-istio-limits-and-benefits-part-2/","summary":"本文结合当前服务网格的形势，分析了服务网格的局限性，以及其带来的三个有价值的好处：可观测性、流量控制和安全。","title":"服务网格的三个技术优势及其运维局限 - 第 2 部分"},{"content":"本文为翻译文章，点击查看原文。\n编者按 本文作者洞察全局，高屋建瓴，结合当前服务网格的形势，分析了服务网格普遍的局限性，以及从开发者角度讲述服务网格带来的三个有价值的好处：可观测性、流量控制和安全。本文的观点阐述详细而深刻，涵盖了服务网格的关键性技术与架构，以及许多备受瞩目与广泛探讨的话题。\n前言 今天的应用程序架构师实际上已经放弃了单一的设计，转而改用云原生微服务架构，这样他们就可以充分利用云的灵活性更快地响应不断变化的业务需求，加快开发人员的敏捷迭代。当然，采用微服务架构也有成本。由于应用程序的个数比单个应用程序多得多，所以微服务架构需要更多的管理、监控和安全。像Istio 和 Linkerd这样的服务网格技术近年来已经相继出现，它们承诺将使微服务的管理、监控和安全的实现更容易。除了管理服务间连接最基本的好处，即将来源服务的请求路由到最佳目的地服务实例，服务网格还为开发人员提供三个有价值的关键领域的好处：可观测性、流量控制和安全。\n在本系列的第 1 部分中，我们将探讨开发人员获得的这些好处。在第 2 部分中，我们将从运维的角度来研究它们的局限性。\n什么是服务网格？ 服务网格是一个专 …","relpermalink":"/blog/service-mesh-istio-limits-and-benefits-part-1/","summary":"本文结合当前服务网格的形势，分析了服务网格的局限性，以及其带来的三个有价值的好处：可观测性、流量控制和安全。","title":"服务网格的三个技术优势及其运维局限 - 第 1 部分"},{"content":"1.多集群网格背景介绍 Istio 并不是单一领域的技术，它综合了诸多服务治理领域的解决方案和最佳实践。在模型上，istio 提供了多个层次的抽象，以适配不同的平台场景; 在实际应用上，istio 提供了若干可选的开源系统和技术，并合理的将这些系统组合在一起，以实现服务网格中的「连接」、「安全」、「控制」和「可观测性」。\nimage-20190729153848023 在 istio 的应用场景中，异地多集群网格是其中最复杂的场景之一。istio 在 1.1 后提供了三种多集群的连通拓扑：\n多控制面 单网络单控制面 多网络单控制面 第一种「多控制面连通拓扑」，严格的讲每个 kubernetes 集群仍然是独立的服务网格，各网格之间服务实例无法共享，互相访问不透明。应用场景有限，实现简单。\n第二种「单网络单控制面拓扑」，实现了多 kubernetes 集群融合为一个服务网格，但是该种拓扑对网络有严格的要求：需要所有集群处于同一个扁平网络，pod ip 互通且不重叠，使用 VPN 连通多集群网络是常见的一个选项。不过这些网络需求在实际环境可能难以满足，也限制了该拓扑的应用场景。\n第三种「多 …","relpermalink":"/blog/istio-analysis-5/","summary":"在 istio 的应用场景中，异地多集群网格是其中最复杂的场景之一，本文将对「多网络单控制面」的搭建和连通过程进行分析。","title":"Istio 庖丁解牛五：多集群网格实现分析"},{"content":"在上一篇文章中，我们通过一个网上商店的示例程序学习了如何使用 Opentracing 在 Istio 服务网格中传递分布式调用跟踪的上下文，以及如何将方法级的调用信息加入到 Istio/Envoy 生成的调用链中。采用 Opentracing 可以减少应用代码中传递 HTTP header 的重复代码；也可以根据需要在调用链中加入更细粒度的 Span，以用于对系统性能瓶颈进行在线分析。\n在实际项目中，除了同步调用之外，异步消息也是微服务架构中常见的一种通信方式。在本篇文章中，我将继续利用 eshop demo 程序来探讨如何通过 Opentracing 将 Kafka 异步消息也纳入到 Istio 的分布式调用跟踪中。\neshop 示例程序结构 如下图所示，demo 程序中增加了发送和接收 Kafka 消息的代码。eshop 微服务在调用 inventory，billing，delivery 服务后，发送了一个 kafka 消息通知，consumer 接收到通知后调用 notification 服务的 REST 接口向用户发送购买成功的邮件通知。\n将 Kafka …","relpermalink":"/blog/using-opentracing-with-istio-part-2/","summary":"在实际项目中，除了同步调用之外，异步消息也是微服务架构中常见的一种通信方式。在本篇文章中，我将继续利用 eshop demo 程序来探讨如何通过 Opentracing 将 Kafka 异步消息也纳入到 Istio 的分布式调用跟踪中。","title":"洞若观火：使用 OpenTracing 增强 Istio 的调用链跟踪 - 篇二"},{"content":"编者按：Consul 团队写了一篇易懂、又有实操的如何在 Service Mesh 中，实现服务的可观察性的文章。即使没有太多基础，也能比较容易的看懂并了解 service mesh 中，如何实现服务的度量。\n这是系列博客的第二篇文章，重点介绍 Consul 服务网格中的新功能。\n简介 您之前可能已经听过“可观察性”一词，但它实际上意味着什么？它只是监控重新品牌，还是更多的可观察性？我们正在发布一系列博客文章，讨论服务网格的核心用例。在本博客中，我们将详细介绍可观察性以及如何启用最近Consul 1.5 发布中包含的 Consul Connect 的新 L7 可观察性功能。\n首先，让我们重新审视一个熟悉的概念：监控。\n监控 监控意味着使用内部或外部工具检测应用程序和系统，以确定其状态。\n例如，您可能有一个外部运行状况检查，用于探测应用程序的状态或确定其当前的资源消耗。您可能还有内部统计信息，用于报告特定代码块的性能，或执行某个数据库事务所需的时间。\n可观察性 可观察性来自工程和控制理论的世界。控制理论指出可观察性本身就是一种描述“从外部产出的知识中推断出系统内部状态的程度”的措施。与监 …","relpermalink":"/blog/layer-7-observability-with-consul-service-mesh/","summary":"Consul 团队写了一篇易懂、又有实操的如何在 Service Mesh 中，实现服务的可观察性的文章。即使没有太多基础，也能比较容易的看懂并了解 service mesh 中，如何实现服务的度量。","title":"Consul Service Mesh 的 7 层网络可观察性"},{"content":"说到 GitOps 和 ChatOps，那就不得不谈到 DevOps。DevOps 作为一种文化，旨在促进开发、测试和运维人员之间的沟通与协作。而促进合作的方式，往往是使用一系列工具，完成这三个角色的相互协作。这带来的好处也是显而易见的：更快的交付速度和更低的人力成本。获益于 DevOps 和公有云，一个近百人的研发团队，可以只配备一到两个专职运维人员，降低的成本不言而喻。既然 DevOps 是一种文化，那么在不同的团队则会有不同的实践，而无论实践如何，其最终目的都是一样的：最大化的实现自动化，释放更多的人力资源，创建更大价值。\n而 GitOps 和 ChatOps，则是 DevOps 的两种实践。这两种实践分别通过使用 版本控制软件 Git 和实时聊天软件来达到提升交付速度和研发效率的目的。\nGitOps GitOps 是一种实现持续交付的模型，它的核心思想是将应用系统的声明性基础架构和应用程序存放在 Git 的版本控制库中。\n将 Git 作为交付流水线的核心，每个开发人员都可以提交拉取请求（Pull Request）并使用 Gi​​t 来加速和简化 Kubernetes 的应用程序 …","relpermalink":"/blog/gitops-and-chatops/","summary":"本文介绍 GitOps 和 ChatOps 这两种 DevOps 实践，通过版本控制软件 Git 和实时聊天软件来达到提升交付速度和研发效率的目的。","title":"GitOps 与 ChatOps 的落地实践"},{"content":"什么是分布式调用跟踪？ 相比传统的“巨石”应用，微服务的一个主要变化是将应用中的不同模块拆分为了独立的进程。在微服务架构下，原来进程内的方法调用成为了跨进程的 RPC 调用。相对于单一进程的方法调用，跨进程调用的调试和故障分析是非常困难的，很难用传统的调试器或者日志打印来对分布式调用进行查看和分析。\n如上图所示，一个来自客户端的请求经过了多个微服务进程。如果要对该请求进行分析，则必须将该请求经过的所有服务的相关信息都收集起来并关联在一起，这就是“分布式调用跟踪”。\n什么是 Opentracing？ CNCF Opentracing 项目 Opentracing是CNCF（云原生计算基金会）下的一个项目，其中包含了一套分布式调用跟踪的标准规范，各种语言的 API，编程框架和函数库。Opentracing 的目的是定义一套分布式调用跟踪的标准，以统一各种分布式调用跟踪的实现。目前已有大量支持Opentracing 规范的 Tracer 实现，包括 Jager,Skywalking,LightStep 等。在微服务应用中采用 Opentracing API 实现分布式调用跟踪， …","relpermalink":"/blog/using-opentracing-with-istio-part-1/","summary":"本文将介绍如何利用OpenTracing来增强Istio/Envoy缺省的调用链跟踪实现：如何利用Opentracing来实现跨进程边界的分布式调用上下文传递；以及在Istio/Envoy生成的分布式调用跟踪基础上实现方法级的细粒度调用跟踪。","title":"洞若观火：使用 OpenTracing 增强 Istio 的调用链跟踪 - 篇一"},{"content":"本文是对 ClusterMesh（Cilium 的多集群实现）的深入研究。简而言之，ClusterMesh 提供：\n通过隧道或直接路由，以本地性能对多个 Kubernetes 集群进行 Pod IP 路由，而无需任何网关或代理。 使用标准Kubernetes服务和coredns/kube-dns的透明服务发现。 跨多个集群的网络策略实施。策略可以指定为 Kubernetes NetworkPolicy 资源或扩展的 CiliumNetworkPolicy CRD。 透明加密，用于本地集群中的节点之间以及跨集群边界的所有通信。 image.png 多集群功能以层为单位构建，您可以选择使用所有层，也可以仅选择和使用所需的层。\n用例 在深入研究实现细节之前，让我们回顾一下连接多个 Kubernetes 集群的一些用例。\n用例：高可用性 image.png 对于大多数人来说，高可用性是最明显的用例。此用例包括在多个区域（regions）或可用区（availability zones）中运行 Kubernetes 集群，并在每个集群中运行相同服务的副本。一旦失败，请求可以故障转移到其他集群。此用 …","relpermalink":"/blog/deep-dive-into-cilium-multi-cluster/","summary":"ClusterMesh 是 Cilium 的多集群实现，可以帮助 cilium 实现跨数据中心、跨 VPC 的多 K8S 集群管理，本文对于 ClusterMesh 的实现原理进行了深入探讨，并与 istio 的多集群管理进行了比较。","title":"深入了解 Cilium 多集群"},{"content":"编者按 Prow 是 Google 发起的适应云原生开源项目的 ChatOps 系统。Kubernetes、Istio 等项目都使用 Prow 实现开源协同。\nK8s 的 Prow 系统：https://prow.k8s.io/ Prow 开源仓库：https://github.com/kubernetes/test-infra/ Prow 官方文档：https://github.com/kubernetes/test-infra/blob/master/prow/README.md 我们将以我的 Github 测试仓库 zhangsean/prow-test 为例，来演示在一个本地 k8s 集群上使用 Prow 来实现CI/CD的诸多效果。\n准备一个 k8s 集群 Prow 运行在 k8s 集群中，最好运行在有公网 IP 地址的 k8s 集群，可以免去 Webhook 转发的麻烦。临时测试可以使用本地集群。我使用 kind 创建一个本地 k8s 集群，使用 minikube 等其他工具都可以。\n# 创建一个本地集群 kind create cluster export …","relpermalink":"/blog/prow-quick-start-guide/","summary":"Prow 是 Google 发起的适应云原生开源项目的 ChatOps 系统。Kubernetes、Istio 等项目都使用 Prow 实现开源协同。我们将以一个测试代码仓库为例，来演示在一个本地 k8s 集群上使用 Prow 来实现CI/CD的诸多效果。","title":"Prow 快速入门向导"},{"content":"大会背景介绍 2019 年 6 月 24-26 日，KubeCon + CloudNativeCon + Open Source Summit 大会在上海世博中心举行。本次大会是由 CNCF 的 LC3 和 Linux 基金会的 OSS 两个大会合并而成的，因此规模空前甚大，估计有超过 40 多个国家，3000 多名开发者参与会议。\n由于最近两年在从事 Service Mesh 方面的一些工作，而本次大会中有多个关于 Service Mesh和Istio/Envoy相关的议程，我向公司申请报名参加了这次大会。\n会议期间上海天气很好，虽然已经是夏天，但这几天的天气并不热，大部分时间天高云淡，中间下了一场小雨。参会地点所在的世博中心在江边，旁边就是世博中国馆，景色很好。 SOFAStack Workshop 会议第一天参加了蚂蚁金服的 SOFAStack Workshop。蚂蚁的同学在国内 Service Mesh 非常活跃，是中文 Istio 文档翻译和国内 Service Mesh 社区 http://servicemesher.com 的主要组织者。像小剑、Jimmy、花肉等，我之前 …","relpermalink":"/blog/kubecon-cncf-oss-2019/","summary":"奇妙的 2019 KubeCon + ClondNativeCon + Open Source Summit 大会！在这里，我近距离接触了大神 Linus；见到了来自 ServiceMesher 社区的很多朋友；还遇到了搞 Kubernetes 的恩格斯后人！","title":"开源，社区与朋友们 -2019 KubeCon + ClondNativeCon + Open Source Summit 有感"},{"content":"本文为翻译文章，点击查看原文。\n编者按\n本文介绍如何为 Envoy 构建控制面指南的第 2 部分：识别控制平面的各个组件。对实施 Envoy 控制平面需要了解的基础知识很有帮助。也算是 Envoy 的概念介绍。\n在这个系列文章的前一篇中，我们浏览了 Envoy 动态配置对于在云原生环境中运行 Envoy 是多么的重要。在这篇文章中，我们来一起看看为了支持控制平面，我们需要如何协调各个组件。\n由于操作环境的变化很大，因此为 Envoy 实施控制平面所需的组件也是如此。例如，在一个极端情况下，如果你需要构建时静态生成 Envoy 文件并发送给 Envoy 的需求，你需要以下组件来满足：\n模板引擎 数据存储/ VCS，用于输入模板的值 任何特定于服务的配置，可能/可能不与服务/应用程序一起存储 一个将各个部分组合在一起的编排器 一种将这些传递给 Envoy 的方法 一种触发配置文件重新加载/热重启的方法 另一方面，如果您选择使用 gRPC 流式 xDS 实现，则需要：\n核心 xDS 服务接口和实现 用于处理向服务注册表注册/取消注册服务的组件 服务注册表 描述您的 Envoy 配置的抽象对象 …","relpermalink":"/blog/guidance-for-building-a-control-plane-for-envoy-part-2-identify-components/","summary":"本文介绍如何为 Envoy 构建控制面指南的第 2 部分：识别组件。","title":"为 Envoy 构建控制面指南第 2 部分：识别组件"},{"content":"前言 很多人学习和使用 envoy 时，很容易混淆一些概念，比如把异常点驱逐和微服务熔断混为一谈，分不清最大驱逐比与恐慌阈值的区别等。本文将基于 envoy 官方文档 (v1.10.0)，详细介绍异常点检测的类型、驱逐算法以及相关概念的解析，并且最后对易混淆的几个概念进行辨析。\n简介 异常点检测 (Outlier detection) 和驱逐 (Ejection) 是用来动态确定上游集群中是否有表现不同于其他主机的实例，并将它们从健康负载均衡集中移除的过程。性能可能会沿着不同的轴变化，如连续失败，一时的成功率，短时间内的延迟等。异常值检测是一种被动的健康检查形式。Envoy 还支持主动健康检查。被动和主动健康检查功能可以一起或独立使用，它们共同构成整个上游健康检查解决方案的基础。\n驱逐算法 根据异常值检测的类型，驱逐要么以直线方式运行（例如在连续返回 5xx 的情况下），要么以指定的间隔运行（例如在周期性成功率的情况下）。驱逐算法的工作原理如下：\n主机被确定为异常点。 如果没有主机被驱逐，Envoy 会立即驱逐主机。否则，它会检查以确保驱逐主机的数量低于允许的阈值（ …","relpermalink":"/blog/envoy-feature-explain-outlier-detection/","summary":"很多人把异常点驱逐和微服务熔断混为一谈，分不清最大驱逐比与恐慌阈值的区别等。本文将基于 envoy 官方文档 (v1.10.0)，详细介绍异常点检测的类型、驱逐算法以及相关概念的解析。","title":"Envoy 功能点详解之异常点检测"},{"content":"本文为翻译文章，点击查看原文。\n编者按 作为探索为 Envoy 构建控制平面系列文章的第 5 部分，本文介绍了部署控制平面的选项与权衡，着重阐述了保持控制平面与数据平面解耦的几大好处，并且在文章结尾建议构建一个可拔插的控制平面以支持各种新特性、拓展和适配。\n前言 这是探索为 Envoy 构建控制平面系列文章的第 5 部分。\n采用一种机制来动态更新 Enovy 的路由、服务发现和其他配置 识别构成控制平面的组件，包括支持存储、服务发现 api、安全组件等 构建最适合你的使用场景和组织架构的特定域的配置对象和 api 考虑如何最好地使你的控制平面可插在你需要它的地方 部署各种控制平面组件的选项 (本文) 基于控制平面的测试工具的思考 在上一篇文章中，我们探讨了为什么可拔插控制平面对于跟上快速迭代的 Envoy API 以及与组织可能采用的不同工作流集成至关重要。在本文中，我们将讨论部署各种控制平面组件时的权衡。\n部署控制平面组件 一旦您构建并设计了控制平面及其各种支持组件，您就需要准确地决定如何部署它的组件。在确定最适合您的实现时，您需要权衡各种安全性、可伸缩性和可用性问题。这些选项里包括 …","relpermalink":"/blog/guidance-for-building-a-control-plane-for-envoy-deployment-tradeoffs/","summary":"本文介绍了部署控制平面的选项与权衡，并且着重阐述了保持控制平面与数据平面解耦的几大好处。","title":"构建 Envoy 的控制平面手册第 5 部分 - 部署的权衡"},{"content":"本文为翻译文章，点击查看原文。\n编者按 本文介绍了使用 Jenkins X 实现 ChatOps。很好的阐述了如何使用 Jenkins X 来实践 ChatOps，文中手把手带我们从零开始完成了一次 Kubernetes Native的CI/CD之旅。\nJenkins X 主逻辑是基于 GitOps 理念。每个更改都必须用 Git 记录，并且只允许 Git 触发集群中发生更改的事件。这种逻辑是 Jenkins X 的基石，到目前为止，它为我们提供了很好的服务。但是，我们可能还需要执行一些不会导致源代码或配置更改的操作，由此 ChatOps 就问世了。\n我们可以将 ChatOps 定义为对话驱动开发。除了单人团队外，沟通对其他所有团队都是必不可少的。当我们开发的特性准备好时，我们需要与他人沟通。我们需要请其他人来 review 我们的变化。我们可能需要请求合并到主分支的权限。我们可能需要沟通的事情是无限多的。这并不意味着所有的交流都变成了聊天，而是我们交流的一部分变成了聊天。由系统来决定沟通的哪些部分应该导致操作，以及什么是没有实际结果的纯人与人之间的消息传递。\n我不会用 ChatOps …","relpermalink":"/blog/implementing-chatops-with-jenkins-x/","summary":"本文很好的阐述了如何使用 Jenkins X 来实践 ChatOps，文中手把手带我们从零开始完成了一次 Kubernetes Native的CI/CD之旅。","title":"使用 Jenkins X 实现 ChatOps"},{"content":"SMI 介绍 SMI 是什么？ 5 月 21 号，在 kubeconf 上，微软联合一众小伙伴，宣布了 Service Mesh Interface，简称 SMI。SMI 是一个服务网格规范，定义了通用标准，包含基本特性以满足大多数场景下的通用需求。\n援引来自 SMI 官方网站 smi-spec.io 的介绍资料，对 Service Mesh Interface 的定位是：\nA standard interface for service meshes on Kubernetes.\nKubernetes 上的 service mesh 的标准接口\n微软的 官方博客文章 这样介绍 SMI：\nSMI 定义了一组通用可移植的 API，为开发人员提供跨不同服务网格技术的互通性，包括 Istio，Linkerd 和 Consul Connect。\nSMI 是希望在各家 Service Mesh 的实现之上建立一个抽象的 API 层，然后通过这个抽象来解耦和屏蔽底层 Service Mesh 实现，让上层的应用、工具、生态系统可以建立在一个业界标准之上，从而实现跨不同实现的可移植性和互通性。 …","relpermalink":"/blog/service-mesh-interface-detail/","summary":"微软最近宣布了 Service Mesh Interface 服务网格规范，定义了通用标准，包含基本特性以满足大多数场景下的通用需求。本文将带您深入了解 Service Mesh Interface。","title":"Service Mesh Interface 详细介绍"},{"content":"本文为翻译文章，点击查看原文。\n编者按 本文通过介绍一个构建和运行微服务的平台 dotCloud 的历史、容器间路由，进而阐述了它与现代服务网格的相同与不同之处；接着介绍了如何实现一个类似的服务网格以及其与 Istio 的区别；最后引入了 SuperGloo 的介绍，一个管理和编排大规模服务网格的开源项目。\n前言 有许多的材料是关于服务网格的，这是另一个。为什么呢？因为我想分享给你们一个观点：有一些人认为服务网格在 10 年前就已经存在，远早于 Docker 和 Kubernetes 这样的容器平台的兴起。我并不是说这个观点比其他观点更好或更差，但是由于服务网格是相当复杂的架构，所以我相信多种观点有助于更好地理解它们。\n我将讨论 dotCloud 平台，这是一个建立在 100 多个微服务之上的平台，支持数千个运行在容器中的应用程序；我将解释在构建和运行它时所面临的挑战；以及服务网格将如何 (或不会) 提供帮助。\ndotCloud 的历史 我已经写过关于 dotCloud 平台的历史和它的一些设计选择，但是我没有过多讨论它的网络层。如果你不想跳进我以前的关于 dotCloud 的博客，所 …","relpermalink":"/blog/containers-microservices-service-meshes/","summary":"本文介绍了 dotCloud 的历史、容器间路由，进而阐述了它与现代服务网格的相同与不同之处，如何实现一个类似的服务网格以及其与 Istio 的区别。","title":"容器、微服务和服务网格简史"},{"content":"本文为翻译文章，点击查看原文。\n编者按\n作者是 Banzai Cloud 的工程师，文章介绍了 istio 环境下，如何结合 Prometheus 进行网络度量指标监测，给出了一些示例配置。最后，还推广了一下 Banzai Cloud 自家的 Pipeline，天然支持跨云、混合云情况下的网络度量监测，欢迎体验。\nIstio 的一个核心功能就是网络流量的可观察性。因为所有服务间的通信都通过 Envoy 代理，而且 Istio 的控制平面可以从这些代理收集日志和指标，服务网格能够让你深入了解你的网络状况。虽然 Istio 的基本安装就装好了收集遥测数据所需的全部组件，但是理解这些组件如何配合，并且使他们能够工作在生产环境中却不是一个容易的事情。如果服务网格扩展到跨越多个云服务提供商的多个群集时，或者在混合云情况下，甚至在边缘计算环境下，这个工作就更加困难。我们在这篇文章中，尽可能解释清楚 Istio 的遥测是怎么工作的，并且会完整浏览一些监控例子，包括如何配置 Prometheus 的目标和尝试不同可用的指标。看完这篇文章，你将会对 Banzai 云中新的Pipeline组件有一个提前了 …","relpermalink":"/blog/exploring-istio-telemetry-and-observability/","summary":"文章介绍了 istio 环境下，如何结合 Prometheus 进行网络度量指标监测，给出了一些示例配置。最后，还推广了一下 Banzai Cloud 自家的 Pipeline，天然支持跨云、混合云情况下的网络度量监测，欢迎体验。","title":"Istio 遥测和可观察性探索"},{"content":" 前言 本文内容整理自 5 月 25 日在 Kubernetes \u0026amp; Cloud Native Meetup 上海站发表的主题演讲，主要介绍了 Service Mesh 最新的产品动态，分析其发展趋势和未来走向；结合蚂蚁的上云实践，阐述在云原生背景下 Service Mesh 的核心价值，以及对云原生落地的关键作用。\n内容主要有三个部分：\nService Mesh 产品动态：介绍最近半年 Service Mesh 的产品动态，包括开源项目和云厂商推出的云上服务 Service Mesh 发展趋势：根据最近的产品动态，总结 Service Mesh 的发展趋势，推断未来的走向 Service Mesh 与云原生：结合云原生，更好的理解 Service Mesh 的价值和作用 Service Mesh 产品动态 Istio1.1 发布 Istio 是目前 Service Mesh 社区最引人注目的开源项目，在今年的 3 月份发布了期待已久的 Istio 1.1 版本，我们来看看 Istio 最近几个版本的发布情况：\n2018 年 6 月 1 日，Istio 发布了 0.8 版本， …","relpermalink":"/blog/201905-servicemesh-development-trend/","summary":"介绍 Service Mesh 最新的产品动态，分析其发展趋势和未来走向；结合蚂蚁的上云实践，阐述在云原生背景下 Service Mesh 的核心价值，和对云原生落地的关键作用。","title":"Service Mesh 发展趋势：云原生中流砥柱"},{"content":"本文为翻译文章，点击查看原文。\n编者按\n本文演示了如何基于 Go 语言、gRPC 和 Protobuf 技术构建一个微服务，并着重介绍了实现 Istio 可观测功能的三大支柱：日志、度量和追踪，以及与之对应的工具 Logrus、Prometheus、Grafana、Jaeger 等。通过文章内容和示例代码，读者会对如何构建 gRPC 技术栈的微服务和使用 Istio 可视化工具观测服务的实现方案有一个全面的认识。\n在过去的两篇文章中（具有 Istio 服务网格的基于 Kubernetes 的微服务可视化 和 具有 Istio 服务网格的 AKS 可视化），我们探索了包含在 Istio 服务网格中的可视化工具，包括用于指标收集、监控和报警的Prometheus 和 Grafana，用做分布式追踪的Jaeger，以及基于 Istio 服务网格的微服务可视化和监控工具Kiali和云平台原生的监控、日志服务相比（例如 GCP 的 Stackdriver，AWS 上的 CloudWatch，Azure 上的 Azure Monitor），我们有针对现代化的、分布式的云应用的全面的可视化解决方案。 …","relpermalink":"/blog/istio-observability-with-go-gprc-and-protocol-buffers-based-microservices/","summary":"文章介绍了为什么要用服务网格，以及简单的介绍了两个重要实现：Istio 和 Linkerd，鼓励大家上手实验。","title":"基于 Go、gRPC 和 Protobuf 的微服务的 Istio 可观察性"},{"content":"编者按 本文介绍了使用 Envoy 来加速 Monzo，对比了使用 Linkerd 和 Envoy，通过试验证明 Envoy 拥有更小的延迟。\n我们基础设施的一个核心组件是远程过程调用 (RPC) 系统。它允许微服务通过网络以可伸缩和可容错的方式彼此通信。\n每当评估 RPC 系统时，通常会查看以下几个关键指标：\n高可用，服务之间的通信应该尽可能快。RPC 子系统应该做到延迟开销最小化，并在路由请求时避免路由到失败的服务副本。\n可伸缩性，平台每秒会收到数以万计的请求，随着用户基数的增长，这些请求的数量还在不断增加。所拥有的任何子系统都需要继续支持这种增长。\n可恢复性，当服务副本宕机、发生 bug 或者网络不可靠时。子系统应该能检测到不可用的下游和异常值，让系统收到反馈并绕过失败进行路由。\n可观察性，RPC 子系统生成大量关于平台性能的数据。与现有的度量标准和追踪基础设施集成，以在现有的服务度量标准和追踪的同时公开服务网格信息。\n2016 年，我们写了一篇关于构建现代银行后台的博客，其中一个关键部分是服务网格，它由Linkerd 1.0提供支持。当我们在 2016 年选择 Linkerd …","relpermalink":"/blog/deploying-envoy-proxy/","summary":"本文介绍了使用 Envoy 来加速 Monzo，对比了使用 Linkerd 和 Envoy，通过试验证明 Envoy 拥有更小的延迟。","title":"部署 Envoy 代理来为 Monzo 提速"},{"content":"本文为翻译文章，点击查看原文。\n编者按 本文阐述了如何使用 Helm 和 Istio 实现手动金丝雀发布。\n我近期工作的项目目标是为微服务应用的金丝雀/分阶段发布制定一套流水线。而这些微服务被部署在Azure Kubernetes 集群上（AKS）。\n本文假设您熟悉Kubernetes，Helm和Istio 流量管理。\n这篇文章描述了发布的基本要求，为这些要求选择的发布策略，以及每个阶段实现细节。\n在后面的文章中，我将详细介绍本文中描述的发布阶段如何对应到Azure DevOps 发布流水线。\n关键要求 高级要求是将应用程序服务通过金丝雀版本发布到生产环境中。\n基本要求/限制： 每个 Micro 服务都应打包为单独的Helm图表。\n不同的团队管理不同的微服务，每个团队应该能够独立于其他微服务发布。\n服务网格Istio安装在 Kubernetes 集群上\n在项目的初始阶段，只有Helm和Istio可用于集群。在此阶段，不使用类似flagger这样的工具。\n团队可以使用 Helm chart 分阶段的发布新版本应用程序：\n- 10％ 的流量路由到新版本\n- 90％ 的流量路由到新版本\n- …","relpermalink":"/blog/canary-release-strategy-using-kubernetes-istio-and-helm/","summary":"本文阐述了如何使用 Helm 和 Istio 实现手动金丝雀发布。","title":"使用 Kubernetes，Istio 和 Helm 实现金丝雀发布"},{"content":"本文为翻译文章，点击查看原文。\n编者按\n本文是一篇来自 Glasnostic 官网的博客。作为介绍熔断系列文章的第二篇，本文通过介绍开发人员和运维人员两种不同视角下的微服务典型应用场景，引入进阶的熔断功能。进而分别介绍和对比了熔断功能的三种不同实现：Hystrix, Service Mesh (Istio、Linkerd) 和 Glasnostic。\n前言 这是关于熔断的两部分系列文章的第二部分。在第一部分中，我们介绍了该模式以及开发人员和运维人员如何以不同的方式处理它。而在本文中，我们将探讨它的典型应用场景以及如何在现代服务中间件中实现它。\n典型的微服务应用场景 开发人员和运维人员通常为不同的目的使用熔断。开发人员主要关心的是保护他们的代码，他们把熔断作为补偿上游故障的一种方法。另一方面，运维人员负责整个服务环境的稳定性和可用性，因此主要使用熔断来监控和补救。\n开发人员：对上游故障的补偿 除了“熔断”和继续前进，开发人员主要关心断路器的三个好处。首先，由于断路器允许开发人员处理服务故障，客户端可以以一种优雅的方式随时间动态地适应服务可用性的变化。其次，在微服务架构中共享状态的断路器提 …","relpermalink":"/blog/preventing-systemic-failure-circuit-breaking-part-2/","summary":"本文介绍了开发人员和运维人员两种不同视角下的微服务典型应用场景，对比了熔断功能的三种不同实现：Hystrix, Service Mesh (Istio、Linkerd) 和 Glasnostic。","title":"微服务中的熔断简介及工作原理详解（第 2 部分）"},{"content":"本文为翻译文章，点击查看原文。\n编者按\n文章介绍了基于 Kubernetes 的服务网格，简要的说明了服务网格的作用，sidecar 的作用以及服务网格两个重要实现：Istio 与 Linkerd 的起源和结构，鼓励大家上手尝试。\nALEN KOMLJEN 2018 年 1 月 28 日，阅读时间 4 分钟\n几个月前我同事问起我对于如何集成Linkerd到我们新的运行在Kubernetes应用里面有什么想法。我的第一反应是，嘿，难道 Kubernetes 服务和ingress还不够么？你能够基于它们做很多事情了。再考虑服务网格的话似乎有点过度设计。通常你有一些 API 只对内部网络开放，然而对于现在流行的应用来说，这并不够。API 通常暴露在互联网上并且也有非常大的流量。你需要在流量上有更多的控制。甚至你还需要做 API 版本化，做金丝雀部署，观察并记录每一个请求。这就引入了服务网格。无论你用Linkerd或是Istio，原理上都是一样的。\n为什么要用服务网格？ 服务网格并不是和 Kubernetes 一起出现。然而，因为有 Kubernetes，服务网格更容易被引入到你的环境中。有两 …","relpermalink":"/blog/kubernetes-service-mesh/","summary":"文章介绍了为什么要用服务网格，以及简单的介绍了两个重要实现：Istio 和 Linkerd，鼓励大家上手实验。","title":"基于 Kubernetes 的 Service Mesh 简介"},{"content":"本文为翻译文章，点击查看原文。\n[编者按]\n之前有社区成员询问是不是想尝试 Knative 时，必须要安装 Istio 才行，今天就告诉大家一种 Istio 的替代方案，使用 Solo.io 公司研发的 Gloo 来替代 Istio 来使用 Knative。\n在 Knative 中，Istio 的主要作用是作为一个 Ingress 技术。Gloo 现在加入 Istio 作为 Knative 的集成和支持 Ingress。有关快速演示 demo，请参阅文章末尾。\n简而言之，Knative 的存在是为了定义在Kubernetes上构建和服务化工作负载的一套标准方法。Knative 的一个显著特性是它的 serverless 特性：它将工作负载的执行与事件关联起来，而只在此类事件发生时消耗计算能力（事件驱动）。\nKnative 是最初在谷歌创建，现在已与 Pivotal、Red Hat、SAP、IBM 等许多公司联合开发的开源协作技术。\n使用 Knative 服务处理请求 让我们简要了解一下 Knative 如何处理请求，以及它与“纯”Kubernetes 的比较。\nKubernetes 上 …","relpermalink":"/blog/gloo-by-solo-io-is-the-first-alternative-to-istio-on-knative/","summary":"本文介绍如何 Solo.io 公司研发的 Gloo 产品，可以作为使用 Knative 时部署 Istio 的替代方案。","title":"Solo.io 打造的 Gloo——Knative 中 Istio 的替代方案"},{"content":"在启用了 Istio 服务网格的 Kubernetes 集群中，缺省情况下只能在集群内部访问网格中的服务，要如何才能从外部网络访问这些服务呢？Kubernetes 和 Istio 提供了 NodePort，LoadBalancer，Kubernetes Ingress，Istio Gateway 等多种外部流量入口的方式，面对这么多种方式，我们在产品部署中应该如何选择？\n本文将对 Kubernetes 和 Istio 对外提供服务的各种方式进行详细介绍和对比分析，并根据分析结果提出一个可用于产品部署的解决方案。\n说明：阅读本文要求读者了解 Kubernetes 和 Istio 的基本概念，包括 Pod、Service、NodePort、LoadBalancer、Ingress、Gateway、VirtualService 等。如对这些概念不熟悉，可以在阅读过程中参考文后的相关链接。\n内部服务间的通信 首先，我们来回顾一下 Kubernetes 集群内部各个服务之间相互访问的方法。\nCluster IP Kubernetes 以 Pod 作为应用部署的最小单位。Kubernetes 会根 …","relpermalink":"/blog/how-to-pick-gateway-for-service-mesh/","summary":"本文将对 Service Mesh 对外暴露服务的各种方式进行详细介绍和对比分析，并根据分析结果提出一个可用于产品部署的入口网关解决方案。","title":"如何为服务网格选择入口网关？"},{"content":"如今，API 网关经历了一系列身份认同危机：\n它们是集中式共享资源，有助于将 API 暴露和维护到外部实体吗？ 它们是否为集群的 ingress 哨兵，严格控制用户流量在集群的进出？ 或它们是否为某类 API 的集成，以便更简洁地表达 API，具体取决于它所具有的客户端类型？ 当然还有不愿多谈但我经常听到的一个问题：“服务网格是否会使 API 网关过时？” 有关背景 随着技术的快速发展，以及行业在技术和架构模式中的快速发展，你会想到\u0026#34;这一切都让我头晕目眩\u0026#34;。在这篇文章中，我希望简化\u0026#34;API 网关\u0026#34;的不同身份，澄清组织中哪些组可能使用 API 网关（他们试图解决的问题），并重新关注第一原则。理想情况下，在本文结束时，您将更好地了解不同团队在不同层面的 API 架构的作用，以及如何从每个层面中获取最大价值。\n在我们深入研究之前，让我们对 API 这个术语非常清楚。\n我对 API 的定义： 一种明确且有目的地定义的接口，旨在通过网络调用，使软件开发人员能够以受控且舒适的方式对组织内的数据和功能进行编程访问。\n这些接口抽象了实现它们的技术基础结构的细节。对于这些设计好的端点，我们期望能有些一定 …","relpermalink":"/blog/api-gateways-are-going-through-an-identity-crisis/","summary":"本文主要向读者介绍在 FAAS 和微服务架构之间的区别以及如何根据自身情况选择正确的架构方案。","title":"API Gateway 的身份认同危机"},{"content":" 作者：钟华，腾讯云容器产品中心高级工程师，热衷于容器、微服务、service mesh、istio、devops 等领域技术\n今天我们来解析 istio 控制面组件 Pilot, Pilot 为整个 mesh 提供了标准的服务模型，该标准服务模型独立于各种底层平台，Pilot 以插件方式对接不同的服务发现平台，解析用户输入的流控配置，转换为统一的服务发现和流量控制模型，并以 xDS 方式下发到数据面。\nPilot 译为领航员, 在 mesh 中负责路由领航，是 istio 控制面的核心组件。\n在组件拓扑中，Pod istio-pilot包括istio-proxy(sidecar) 和discovery2 个容器，pilot 核心能力由容器 discovery中执行的命令pilot-discovery discovery提供。\n1.jpg 查看高清原图\n在源代码中，package github.com/istio/istio/tree/master/pilot/cmd 有三个命令的入口：\nsidecar-injector: 在前面文章中有过介绍。 pilot-discovery: 控制 …","relpermalink":"/blog/istio-analysis-4/","summary":"Pilot 译为领航员，在 mesh 中负责路由领航，是 istio 控制面的核心组件。","title":"Istio 庖丁解牛四：pilot discovery"},{"content":"在 Cloud Next 2019 大会上，Google 宣布了 Cloud Run，这是一个新的基于容器运行 Serverless 应用的解决方案。Cloud Run 基于开源的 knative 项目，宣称要将 serverless 带入容器世界。\nCloud Run 介绍 在旧金山举办的 Google Cloud Next 2019 大会上，Google 宣布了 Cloud Run，这是一个新的基于容器运行 Serverless 应用的解决方案。Cloud Run 基于开源的 knative 项目，是 knative 的 Google Cloud 托管版本，也是业界第一个基于 Knative + Kubernetes 的 Serverless 托管服务。\n援引来自 Google Cloud 官方网站的介绍资料，对 Cloud Run 的定位是：\nRun stateless HTTP containers on a fully managed environment or in your own GKE cluster.\n在完全托管的环境或者自己的 GKE …","relpermalink":"/blog/google-cloud-run-intro/","summary":"在 Cloud Next 2019 大会上，Google 宣布了 Cloud Run，这是一个新的基于容器运行 Serverless 应用的解决方案。Cloud Run 基于开源的 knative 项目，宣称要将 serverless 带入容器世界。","title":"Google Cloud Run 详细介绍"},{"content":"Traffic Director 介绍 img Traffic Director 是 Google Cloud 推出的完全托管的服务网格流量控制平面。\n援引来自 Traffic Director 官方网站的介绍资料，Traffic Director 的定位是：\nEnterprise-ready traffic management for open service mesh.\n适用于开放式服务网格的企业级流量管理工具。\n目前 Traffic Director 还处于测试阶段，尚未 GA：\n在 2018 年 7 月的 Cloud Next‘18 大会上，Google Cloud 推出了 Traffic Director 的 alpha 版本 在 2019 年 4 月的 Cloud Next‘19 大会上，Google Cloud 推出了 Traffic Director 的 beta 版本 Traffic Director 推出的背景 在详细介绍 Traffic Director 的功能之前，我们先看一下 Traffic Director 推出的背景。由于 Traffic …","relpermalink":"/blog/google-traffic-director-detail/","summary":"Traffic Director 是 Google Cloud 推出的完全托管的服务网格流量控制平面。","title":"Google Traffic Director 详细介绍"},{"content":" 本文通过对 Google 近期发布的 Anthos 混合云产品的核心组件 Anthos Config Management 进行分析，探究其背后设计的核心理念——Infrastructure as Code 是如何推动业内一直以来非标准的混合云慢慢走向标准化、供应商无锁定化。\n0. Anthos Config Management 是什么？ Hello World Demo 大家可以看 Arctiq 公司搞的修改 node 数量 Demo：https://www.arctiq.ca/our-blog/2019/4/9/gke-on-prem-and-anthos-config-management/\n简单说，当你修改某个 git 管理下的 yaml 配置文件，里面描述了某个 GKE 私有集群某个 cluster 的 node 数量，然后 Anthos Config Management 会帮你自动的发命令并让节点数量变成你想要的那个。\nAnthos 是啥？ 是 Google 发布的混合云多云平台\nGKE：Anthos 的命令和控制核心。用户通过 GKE …","relpermalink":"/blog/anthos-config-management-intro/","summary":"简单说，当你修改某个 git 管理下的 yaml 配置文件，里面描述了某个 GKE 私有集群某个 cluster 的 node 数量，然后 Anthos Config Management 会帮你自动的发命令并让节点数量变成你想要的那个。","title":"Google 混合云多云平台 Anthos Config Management 产品设计分析"},{"content":"背景 昨日得到的消息，CNCF 正在筹建通用数据平面 API 工作组（Universal Data Plane API Working Group / UDPA-WG)，以制定数据平面的标准 API，为 L4/L7 数据平面配置提供事实上的标准，初始成员将包括 Envoy 和 gRPC 项目的代表。\n目前还处于非常早期的筹备阶段，具体内容可以见下面的文档：\nhttps://docs.google.com/document/d/1y-H-pQ2mmhBPX_U9pP3mMMUbEpZskxBdEbwd5KlivY4/edit#heading=h.fdi15bvpmxen\n方便起见，我将目前文档的内容搬运出来并简单翻译如下：\n文档内容 目标 通用数据平面 API 工作组（Universal Data Plane API Working Group/UDPA-WG）的目标是将对数据平面代理和负载均衡器的通用控制和配置API感兴趣的行业各方聚集在一起。\n愿景 通用数据平面 API（UDPA） …","relpermalink":"/blog/cncf-udpa-wg/","summary":"CNCF 正在筹建通用数据平面 API 工作组（Universal Data Plane API Working Group / UDPA-WG)，以制定数据平面的标准 API，为 L4/L7 数据平面配置提供事实上的标准，初始成员将包括 Envoy 和 gRPC 项目的代表。","title":"CNCF 正在筹建通用数据平面 API 工作组，以制定数据平面的标准 API"},{"content":" 摘要： Docker Hub 遭入侵，19 万账号被泄露；Java 8 终于开始提供良好的容器支持；Snyk 年度安全报告出炉，容器安全问题形势空前严峻。\n业界要闻 Docker Hub 遭入侵，19 万账号被泄露 : 4 月 25 日 Docker 官方邮件曝露，因为 Hub 的一个数据库收到非授权访问，影响了约 19 万用户的用户名和哈希后的密码，以及用户自动构建的 Github 和 Bitbucket Token。Docker 公司建议用户修改其登录密码。如果您在公有云上的应用依赖于来自 Docker Hub 的镜像，我们强烈建议您登录容器服务控制台更新相应的 docker login 信息或 kubernetes secret。此外，阿里云容器镜像服务企业版提供网络访问控制、独享 OSS Bucket 加密存储等安全加固功能，最大程度保障您的镜像仓库的安全。 Java 8 终于开始提供良好的容器支持**：**长久以来，容器 和 Java 就像一对“欢喜冤家”。一方面，容器技术的“不可变基础设施”特性为开发者带来了无比宝贵的依赖与环境一致性保证；但另一方面，Linux …","relpermalink":"/blog/cloud-native-weekly-03/","summary":"这是 Cloud Native 周报第 3 期。","title":"云原生生态周报（Cloud Native Weekly）第 3 期"},{"content":"本文为翻译文章，点击查看原文。\n编者按\nEnvoy 创始人 Matt Klein 分享了他对企业开始使用 Envoy 部署微服务所遇到的挑战以及可观察性的看法和选择，他认为 Service Mesh 还处于早期阶段，企业应该逐步推进，同时最好选择商业解决方案。\nService Mesh 的受欢迎程度正在飙升，尽管它还处于初期阶段。在为部署 Envoy 的企业寻求有关服务网格和可观察性最佳实践的建议时，我与 Envoy 的创建者和云原生计算基金会（CNCF）技术监督委员会（TOC）的代表 Matt Klein 聊了聊。在下面的讨论中，Matt 分享了他对企业开始使用 Envoy 部署微服务所遇到挑战的看法，同时也谈到了可观察性，以及在与 Envoy 一起选择可观察性平台时可以做出的选择。\nStela Udovicic：您认为在采用微服务时遇到什么样的痛点表明应该去考虑 Envoy？\nMatt Klein：我认为当人们采用微服务时，他们会看到普遍存在的问题，其中很多问题都与网络和可观察性有关。有关网络稳定性的问题，有关重试和断路等相似的问题都是常见的例子。所以，这将通过用他们最终使用的任何 …","relpermalink":"/blog/envoy-service-mesh-and-observability-best-practices-for-enterprises/","summary":"通过对 Envoy 创始人 Matt Klein 的采访，Matt 分享了他对企业开始使用微服务部署 Envoy 所遇到的挑战以及可观察性的看法和选择。","title":""},{"content":"本文为翻译文章，点击查看原文。\n编者按 作者是 Shopify 的工程师，公司在引入 Istio 作为服务网格的过程中发现消耗的计算成本过高。基于此问题，作者使用了公司内部开发的基准测试工具 IRS 对 Istio 和 Linkerd 的 CPU 使用情况做了测试和对比。测试结果发现 Istio 在 CPU 的使用上要比 Linkerd 耗费更多的资源。这为 Istio 的拥趸们敲响了警钟，提醒大家 Istio 在生产化的道路上还有很多需要优化的地方。\n背景 在Shopify，我们正在部署 Istio 作为服务网格。我们做的很不错但遇到了瓶颈：成本。\nIstio 官方发布的基准测试情况如下：\n在 Istio 1.1 中一个代理每秒处理 1000 个请求大约会消耗 0.6 个 vCPU。\n对于服务网格中的第一个边界（连接的两端各有两个代理），1200 个内核的代理每秒处理 100 万个请求。Google 的价格计算器估计对于n1-standard-64机型每月每个核需要 40 美元，这使得这条单边界的花费超过了 5 万美元/每月/每 100 万请求。\nIvan Sim 去年写了一个关于服 …","relpermalink":"/blog/benchmarking-istio-and-linkerd-cpu/","summary":"本文对 Istio 和 Linkerd 的 CPU 使用情况做了基准测试和比较。","title":"Istio 和 Linkerd 的 CPU 基准测试"},{"content":" 本周报由阿里巴巴容器平台联合蚂蚁金服共同发布\n本周作者：傅伟，敖小剑，张磊，临石，南异，心贵，王夕宁，长虑\n责任编辑：木环\n业界要闻 Kubernetes External Secrets 近日，世界上最大的域名托管公司 Godaddy 公司，正式宣布并详细解读了其开源的 K8s 外部 Secrets 管理项目： Kubernetes External Secrets，简称 KES。这个项目定义了 ExternalSecrets API，让开发者可以在 K8s 内部以和使用内部 Secret 相似的方式使用外部系统提供的 Secrets，大大简化了开发者为了让应用获取外部 Secrets 所需要的工作量。从安全的角度，这个方案降低了使用外部 Secret 时候的攻击面（外部 Secret 是通过一个 K8s API 暴露的，而不是之前的每个应用自己实现），也降低了应用在适配外部 Secret 时候的难度。另外，Kubernetes KMS plugin 开源插件 ，采用信封加密的方式与密钥管理能力结合，对进行 K8s secret 的存储加密。建议安全相关技术人员重点关注。 CNCF …","relpermalink":"/blog/cloud-native-weekly-02/","summary":"这是 Cloud Native 周报第 2 期。","title":"云原生生态周报（Cloud Native Weekly）第 2 期"},{"content":"原文地址：http://wei-meilin.blogspot.com/2019/03/my2cents-eight-things-leads-to.html。\n编者按\n作者以较为嘲讽的口吻列举了在开发云原生微服务系统时可能出现的 8 个错误，告诫开发人员要注意避免这些问题。其观点集中在业务划分、解耦合、重复代码和过度的 API 交互等方面。作者以自嘲的方式把这些想法用\u0026#34;我的两分钱\u0026#34;比喻，译者意译为\u0026#34;随笔\u0026#34;以方便理解。\n大部分标注“我的两分钱”的文章只是一些想法。你只需要快速愉快的阅读，不用太深入，但值得做笔记：）\n1. 设置错误的领域边界 这是一种工作保障策略，它让参与项目的每个人在开发和测试中无休止地循环，而无法将服务投入生产环境！首先，一切都从简单开始，逐渐发现有越来越多的功能、业务逻辑被添加到微服务中，最后甚至不得不重新命名整个该死的东西。\n1 临床症状和副作用\n不断增长的微服务变得过于臃肿，或者域中的每个微服务都调用你的服务。（有时核心微服务具有相同的行为，但你不应该在单个域中看到如此多的这类服务）。这违反了简单、可维护和敏捷的微服务原则。 到处都是重复的微服务/代码。你可以 …","relpermalink":"/blog/eight-things-leads-to-developing-catastrophic-cloud-native-microservices-system/","summary":"本文介绍了作者认为在开发云原生微服务系统时会出现的 8 个问题，并告诫大家避免犯错。","title":"导致云原生微服务系统开发灾难性的 8 件事"},{"content":"本文为翻译文章，点击查看原文。\n编者按\n本文介绍如何为 Envoy 构建控制面指南的第 4 部分：构建的可扩展性。Gloo 团队建议将重点放在控制平面的简单核心上，然后通过插件和微服务控制器的可组合性扩展它。Gloo 的体系结构是这样构建的，它使 Gloo 团队能够快速添加任何新特性，以支持任何平台、配置、过滤器，以及更多的新特性。这就是为什么，尽管 Gloo 是非常 kubernets 原生的，但它是为在任何云上的任何平台上运行而构建的。核心控制平面的设计允许这样做。\n这是探究为 Envoy 代理构建控制平面系列文章的第 4 部分。请关注@christianposta和@soloio_inc将在一周内推出下一部分内容。\n在本系列博客中，我们将关注以下领域：\n采用一种机制来动态更新 Envoy 的路由、服务发现和其他配置 确定控制平面由哪些组件组成，包括支持存储、服务发现 API、安全组件等 建立最适合您的使用场景和组织架构的特定于域的配置对象和 API 考虑如何让控制平面支持可拔插 (本博客) 部署各种控制平面组件的选项 为你的控制平面考虑测试套件 在上一篇文章中，我们探讨了为您的控 …","relpermalink":"/blog/guidance-for-building-a-control-plane-for-envoy-part-4-build-for-extensibility/","summary":"本文介绍如何为 Envoy 构建控制面指南的第 4 部分：构建的可扩展性。","title":"为 Envoy 构建控制面指南第 4 部分：构建的可扩展性"},{"content":"本文为翻译文章，点击查看原文。\n编者按 本文先后阐述服务网格中监控的重要性和 Istio 相关名词概念，再由一个实例切入，详解在 Istio 中部署和实现监控的全过程。（注：阅读本文需要有一定的 Kubernetes 实践基础，并了解集群中常用的监控工具 Prometheus。）\n前言 istio-monitoring-explained 如果我说“服务网格”是当今技术社区的热门话题，没有人会感到惊讶。这个领域最活跃的项目之一是Istio。它由 IBM、谷歌和 Lyft 联合创建，作为对微服务体系结构已知问题的解决方案。容器和 Kubernetes 极大地帮助了 Istio 适配微服务体系结构。然而，与此同时，他们也带来了一系列我们以前没有遇到过的新问题。\n现如今，我们所有的服务都使用 HTTP/gRPC APIs 来进行它们之间的通信。在过去的单体应用时代，这些只是流经单个应用程序的函数调用。这意味着，在微服务系统中，存在着大量服务间交互，这使得可观察性、安全性和监控更加困难。\n已经有很多资源可以解释Istio 是什么以及它是如何工作的。我不想在这里重复这些，所以我将聚焦于一个领 …","relpermalink":"/blog/istio-monitoring-explained/","summary":"本文先后阐述服务网格中监控的重要性和 Istio 相关名词概念，再由一个实例切入，详解在 Istio 中部署和实现监控的全过程。","title":"Istio 监控详解"},{"content":" 本文转载自zhangguanzhang 的博客。\n旨在面向新手讲解手动部署过程，本文 dashboard 的暴露不会用 nodePort（不喜欢使用它）和 apiserver 的 web proxy 代理也就是/api/v1/namespaces/kube-system/services/https:kubernetes-dashboard:/proxy/这种。\n主要讲下四种场景方式：\n纯 dashboard http 和 https 不惨合外部证书 openssl 证书给 dashboard 当 https 个人向域名使用 https 小绿锁 ingress tls 代理 http[s]的 dashboard 以及最后讲解的如何定义带权限的 token 去利用 token 登陆 dashboard。 先要理解的一点就是 JWT（JSON Web Tokens）思想，k8s 的很多 addon 都是 pod 形式跑的，addon 的 pod 都是要连接 kube-apiserver 来操作集群来减少运维的工作量和提供方便。addon 都是 pod，pod 操作和查看集群信息需要鉴权。 …","relpermalink":"/blog/general-kubernetes-dashboard/","summary":"本文是对 Kubernetes 的 dashboard 有关 ssl 下各个场景的相关说明。","title":"kubernetes dashboard 在 ssl 的各种场景下的手动部署"},{"content":" 本文转载自zhangguanzhang 的博客。\n从之前对 ingress controller 到现在了解架构和一些经验总结下，顺带给人科普少走弯路 需要看懂本文要具备一下知识点：\nService 实现原理和会应用 知道反向代理原理，了解 nginx 和 apache 的 vhost 概念 了解 service 的几种类型（Nodeport、clusterip、LB） 四层和七层区别（不明白就这样去理解，七层最常见就是应用层的 http，也就是 url，四层是传输层，为 tcp/udp 端口） 域名解析，/etc/hosts 等基础知识 Ingress Controller 介绍 Ingress Controller是一个统称，并不是只有一个，有如下这些：\nIngress NGINX: Kubernetes 官方维护的方案，也是本次安装使用的 Controller。 F5 BIG-IP Controller: F5 所开发的 Controller，它能够让管理员通过 CLI 或 API 让 Kubernetes 与 OpenShift 管理 F5 BIG-IP 设备。 …","relpermalink":"/blog/kubernetes-ingress-controller-deployment-and-ha/","summary":"本文是对 Kubernetes 的 Ingress controller 的介绍、部署及高可用说明。","title":"Kubernetes Ingress Controller 的使用介绍及高可用落地"},{"content":" 本周作者：张磊 临石 禅鸣 至简 宋净超\n编辑：木环\n这是 Cloud Native 周报第一期。\n业界要闻 在上周于旧金山举办的 Google Cloud Next 2019 大会上，Google Cloud 正式发布了：\nCloud Run。这是一个跟 Microsoft Azure ACI，AWS Fargate 类似的容器实例服务。但与 ACI 和 Fargate 基于虚拟机技术栈的实现不同，Google 的 Cloud Run 服务则是基于 Knative 这个 Kubernetes 原生的 Serverless 基础设施项目完成的。这也是业界第一个基于 Knative + Kubernetes + gVisor 体系的 Serverless 服务。此外，Cloud Run 的计费模型也颇具创新性：它不像 Fargate 那样完全按请求数目计费，而是将所有并发的请求算在一个计费单位内，这有望大大减低用户需要支付的成本。 Traffic Director。一个与 AWS App Mesh 对标的 Service Mesh 产品。Traffic Director 通过 xDS  …","relpermalink":"/blog/cloud-native-weekly-01/","summary":"这是 Cloud Native 周报第一期。","title":"云原生生态周报（Cloud Native Weekly）第 1 期"},{"content":"所谓边车模式（Sidecar pattern），也译作挎斗模式，是分布式架构中云设计模式的一种。因为其非常类似于生活中的边三轮摩托车而得名。该设计模式通过给应用程序加上一个“边车”的方式来拓展应用程序现有的功能。该设计模式出现的很早，实现的方式也多种多样。现在这个模式更是随着微服务的火热与 Service Mesh 的逐渐成熟而进入人们的视野。\n什么是边车模式 在 Azure Architecture Center 的云设计模式中是这么介绍边车模式的：\nDeploy components of an application into a separate process or container to provide isolation and encapsulation.\n— Sidecar pattern\n这里要注意的是：这里的 Sidecar 是分布式架构中云设计模式的一种，与我们目前在使用的 Istio 或 Linkerd 中的 Sidecar 是设计与实现的区别，后文中提到的边车模式均是指这种设计模式，请勿与 Istio 或 其他 Service Mesh …","relpermalink":"/blog/from-sidecar-to-servicemesh/","summary":"本文谈谈从边车模式这一分布式架构的设计模式到 Service Mesh 的演变。","title":"从边车模式到 Service Mesh"},{"content":"本文为翻译文章，点击查看原文。\n欢迎回到我们关于 Service Mesh 和 Istio 的博客文章系列。\n在之前的帖子中，我们讨论了 Istio 服务网格是什么，以及它为什么如此重要。然后，我们介绍了如何将 Istio 投入生产环境中，包括了如何进行高级应用程序部署和安全功能，到 SRE 监控最佳实践。\n今天，在 Google Cloud NEXT ‘19 之前，我们正在谈论在各种环境中使用 Istio，以及 Istio 如何帮助您释放混合云的强大功能。\n为什么采用混合云？ 混合云可以采用多种形式。通常，混合云指的是跨公共云和私有（内部部署）云运行，而多云意味着跨多个公共云平台运行。\n采用混合云或多云架构可以为您的组织带来诸多好处。例如，使用多个云提供商可以帮助您避免供应商锁定，并使得您为实现目标可选择最佳的云服务。使用云和本地环境，您可以同时享受云的优势（灵活性、可扩展性、成本降低）和本地的好处（安全性、低延迟、硬件复用）。如果您是首次迁移到云端，采用混合云步骤可以让您按照自己的节奏，以最适合您业务的方式进行。\n根据我们在 Google 的经验以及我们从客户那里得到的信息，我们认 …","relpermalink":"/blog/the-service-mesh-era-istios-role-in-the-future-of-hybrid-cloud/","summary":"谈谈如何使用 Istio 将混合服务网格变为现实，以及 Istio 在混合云未来扮演的角色。","title":"服务网格时代：Istio 在混合云未来扮演的角色"},{"content":"设计目标 当前实现将用户 pod 流量转发到 proxy 的默认方式是使用 privileged 权限的 istio-init 这个 init container 来做的（运行脚本写入 iptables），Istio CNI 插件的主要设计目标是消除这个 privileged 权限的 init container，换成利用 k8s CNI 机制来实现相同功能的替代方案\n原理 Istio CNI Plugin 不是 istio 提出类似 k8s CNI 的插件扩展机制，而是 k8s CNI 的一个具体实现 k8s CNI 插件是一条链，在创建和销毁 pod 的时候会调用链上所有插件来安装和卸载容器的网络，istio CNI Plugin 即为 CNI 插件的一个实现，相当于在创建销毁 pod 这些 hook 点来针对 istio 的 pod 做网络配置：写入 iptables，让该 pod 所在的 network namespace 的网络流量转发到 proxy 进程 当然也就要求集群启用 CNI，kubelet 启动参数：--network-plugin=cni （该参数只有两个可选 …","relpermalink":"/blog/istio-cni-note/","summary":"这是一篇关于 Istio CNI 的学习笔记。","title":"Istio 学习笔记：Istio CNI 插件"},{"content":"本文为翻译文章，点击查看原文。\n在做项目的云原生改造时我们可以采用微服务架构。DevOps 和自动化构建两方面的成功经验对微服务的实践很有帮助。经过一段时间的实践，你可能会有将微服务架构推广到其他部门的想法。而你担心微服务本身的复杂性和分布式系统的高维护成本会让其他部门难以接受它。可能在我们想方设法解决微服务带来的问题时，总会有些人觉得这样做毫无意义。因为现在技术发展如此之快，总会出现更好的技术方案，你能保证自己在微服务领域所做的工作最后没有白费吗？\n我认为不会白费！\n现在“serverless”和“functions-as-a-service”（FAAS）还处于早期的炒作阶段。有些人觉得 serverless 就是下一代的微服务，所以我们应该跳过当前的微服务模式而直接采用 serverless。其实这种说法是有点夸大其词。作为架构师或开发者，我们通过学习新技术来提升自身能力让自己变得更\u0026#34;值钱\u0026#34;并没有错。但我们也要以务实态度来判断是否应该采用新技术。虽然持续跟进最新技术是我们作为架构师的职责所在，但掌握在之前的产品和 IT 部门引用新技术的时机也很重要。我们可以通过下面的模块来理解微服 …","relpermalink":"/blog/faas-vs-microservices/","summary":"本文主要向读者介绍 FaaS 和微服务架构之间的区别以及如何根据自身情况选择正确的架构方案。","title":"选择 FaaS 还是微服务？"},{"content":"本文为翻译文章，点击查看原文。\n持续部署（Continuous delivery）符合企业软件实践，它是完善持续集成（continuous integration）原则的自然演化。 但持续部署案例却非常罕见，其中原因可能是需要复杂的管理以及担心部署失败而影响系统的可用性。\nFlagger是一个开源的 Kubernetes operator，旨在解决上述复杂性。它使用 Istio 切换流量并通过 Prometheus 指标分析业务应用在更新发布期间的状态表现。\n以下是在 Google Kubernetes Engine（GKE）环境安装和使用 Flagger 的步骤指导。\n搭建 Kubernetes cluster 首先创建 GKE 集群和 Istio 组件（如果你没有 GCP 帐号，点击注册帐号）。 登录 Google Cloud，创建项目并为其启用结算。安装gcloud命令行工具，然后使用gcloud init配置项目。 设置默认项目，计算资源区域和地区（用实际项目 ID 替换PROJECT_ID）：\ngcloud config set project PROJECT_ID …","relpermalink":"/blog/automated-canary-deployments-with-flagger-and-istio/","summary":"本文介绍如何使用 Flagger 和 Istio 实现自动化金丝雀部署。","title":"基于 Flagger 和 Istio 实现自动化金丝雀部署"},{"content":"Istio 服务网格架构的概述，通常都是从对数据面和控制面的叙述开始的。\n来自 Istio 的官方文档。\nIstio 服务网格逻辑上分为数据平面和控制平面。\n数据平面由一组以 sidecar 方式部署的智能代理（Envoy）组成。这些代理和 Mixer（一个通用的策略和遥测中心）合作，对所有微服务之间的之间所有的网络通信进行控制。\n控制平面负责管理和配置代理来路由流量。此外控制平面配置 Mixer 以实施策略和收集遥测数据。\nSidecar 注入到应用的过程，可以是自动的，也可以是手动的，了解这一过程是很重要的。应用的流量会被重定向进入或流出 Sidecar，开发人员无需关心。应用接入 Istio 服务网格之后，开发者可以开始使用网格功能并从中受益。然而数据平面是如何工作的，以及需要怎样的条件才能完成这种无缝工作？本文中我们会深入到 Sidecar 注入模型中，来更清晰的了解 Sidecar 的注入过程。\nSidecar 注入 简单来说，注入 Sidecar 就是把附加的容器配置插入 Pod 模板的过程。Istio 服务网格所需的附加容器是：\nistio-init 这个初始化容器用于设 …","relpermalink":"/blog/data-plane-setup/","summary":"本文中我们会深入到 Sidecar 注入模型中，来更清晰的了解 Sidecar 的注入过程。","title":"Istio Sidecar 注入过程解密"},{"content":"本文为翻译文章，点击查看原文。\n这是探索为 Envoy 代理构建控制平面系列文章的第 3 部分。\n在本系列博客中，我们将关注以下领域：\n采用一种机制来动态更新 Envoy 的路由、服务发现和其他配置 确定控制平面由哪些组件组成，包括支持存储、服务发现 api、安全组件等 建立最适合您的使用场景和组织架构的特定于域的配置对象和 api（本博客） 考虑如何最好地使您的控制平面可插在您需要它的地方 部署各种控制平面组件的选项 通过控制平面的测试工具来思考 在前面的博客部分中，我们评估了控制平面可能需要的组件。在本节中，我们将探索特定于域的 API 在您的控制平面上可能是什么样子的。\n建立您的控制平面交互点和 API 面 一旦您考虑了哪些组件可能构成您的控制平面体系结构 (请参阅前面的部分)，您就需要考虑您的用户将如何与控制平面交互，甚至更重要的是，您的用户将是谁？要回答这个问题，您必须决定基于 Envoy 的基础设施将扮演什么角色，以及流量将如何通过体系结构。它可以是：\nAPI 管理网关（南北向流量） 简单 Kubernetes 边缘负载均衡器/反向代理/入口控制（南北向流量） 共享服务代 …","relpermalink":"/blog/guidance-for-building-a-control-plane-for-envoy-part-3-domain-specific-configuration/","summary":"本文介绍如何为 Envoy 构建控制平面指南的第 3 部分：领域特定配置。","title":"为 Envoy 构建控制平面指南第 3 部分：领域特定配置"},{"content":"本文为翻译文章，点击查看原文。\n原文发表于 2019 年 3 月 27 日。\n在 re:Invent 2018，AWS 宣布了 AWS App Mesh 的公开预览版，App Mesh 是一个服务网格，可以轻松监视和控制跨应用的通信。今天，我很高兴地宣布 App Mesh 已经可以为用户提供使用了（GA）。\n新的架构模式 许多客户正在对现有应用进行现代化改造，以求更快更灵活地进行创新。微服务等架构模式使团队能够独立测试服务并不断持续发布应用变更。这种方式可以让开发团队更快地进行实验和迭代，从而提高团队生产力。它还可以让团队快速扩展他们构建和运行应用的方式。\n当构建所有需要以一个应用的形式一起工作的新服务时，他们需要一种方式来在整个应用间连接，监控，控制和调试通信。此类功能的示例包括服务发现，应用级度量和日志，帮助调试流量模式的跟踪，流量整形以及保护服务之间通信的能力。\n通常需要在 SDK 中构建通信管理逻辑，并要求每个开发团队使用它。但是，随着应用的增长和团队数量的增加，跨服务一致地提供这些功能会变得复杂而耗时。\n我们的目标是自动化和抽象通信基础设施，以支撑每个现代应用程序，使团队能够 …","relpermalink":"/blog/redefining-application-communications-with-aws-app-mesh/","summary":"在 re:Invent 2018，AWS 宣布了 AWS App Mesh 的公开预览版，App Mesh 是一个服务网格，可以轻松监视和控制跨应用的通信。今天，我很高兴地宣布 App Mesh 已经可以为用户提供使用了（GA）。","title":"用 AWS App Mesh 重新定义应用通讯"},{"content":" 作者：钟华，腾讯云容器产品中心高级工程师，热衷于容器、微服务、service mesh、istio、devops 等领域技术。\n今天我们来解析 istio 控制面组件 Galley。Galley Pod 是一个单容器单进程组件，没有 sidecar, 结构独立，职责明确。\n查看高清原图\n前不久 istio 1.1 版本正式发布，其中 istio 的配置管理机制有较大的改进，以下是1.1 release note 中部分说明：\nAdded Galley as the primary configuration ingestion and distribution mechanism within Istio. It provides a robust model to validate, transform, and distribute configuration states to Istio components insulating the Istio components from Kubernetes details. Galley uses the Mesh …","relpermalink":"/blog/istio-analysis-3/","summary":"今天我们来解析 istio 控制面组件 Galley。Galley Pod 是一个单容器单进程组件，没有 sidecar，结构独立，职责明确。","title":"Istio 庖丁解牛三：galley"},{"content":"本文为翻译文章，点击查看原文。\n“服务网格”是一个热点话题。似乎去年每一个与容器相关的大会都包含了一个“服务网格”议题，世界各地有影响力的业内人士都在谈论这项革命性的技术带来的好处。\n然而，截至 2019 年初，服务网格技术仍不成熟。主要的实现产品 Istio 还没有准备好进行广泛的企业级部署，只有少数成功的案例运行在生产环境中。也存在其他的服务网格产品，但并没有得到业界专家所说的广泛关注。\n我们如何协调这种不匹配呢？一方面，我们听到“你需要一个服务网格”的声音，而另一方面，企业和公司多年来一直在没有服务网格的容器平台上成功地运行着它们的应用。\n开始使用 Kubernetes 服务网格是你旅途中的一个里程碑，但它不是起点。\n在容器应用的生产环境部署中，Kubernetes 已经被证明是一个可以胜任的平台。它提供了一个丰富的网络层，提供了服务发现， 负载均衡， 健康检查 和访问控制 的能力，以支持复杂的分布式系统。\n这些功能对于简单和易于理解的应用程序来说已经足够了， 遗留的应用已经被容器化。它们允许你满怀信心地部署应用，根据需要扩容，避免意外故障，并实现简单的访问控制。\n1 ① …","relpermalink":"/blog/do-i-need-a-service-mesh/","summary":"本文对当前的服务网格发展状况进行了分析和预测，建议在适当的时机开始使用服务网格来替代现有解决方案。","title":"你真的需要服务网格吗？"},{"content":"本文为翻译文章，点击查看原文。\n编者按 如果说 Spring Cloud 是以 SpingBoot 为核心和基础的微服务架构，那么 MicroProfile 则是将传统 JavaEE 轻量化以适应微服务时代的一个体系。作者 Emily Jiang，开源项目eclipse/microprofile的 contributor 之一，在本文中探讨了如何结合 MicroProfile 与流行的服务网格 Istio 安全地部署微服务，比较了二者的不同之处，并且阐述了二者共存的生态系统的现状及未来。\nshutterstock.jpg MicroProfile in a nutshell MicroProfile 是一个快速发展的开源社区。它是一个热情友好的平台，可以让开发人员聚在一起为云原生微服务开发编程模型。自 2016 年 6 月成立以来，不到两年的时间里，它已经发布了 6 个总体版本和 16 个单独的规范版本。 [此页](https://wiki.eclipse.org/MicroProfile/Implementation# eclipse_microprofile_versions)显示 …","relpermalink":"/blog/microprofile-the-microservice-programming-model-made-for-istio/","summary":"本文探讨了如何结合eclipse/microprofile与流行的服务网格Istio安全地部署微服务。","title":"MicroProfile——为 Istio 创建的微服务编程模型"},{"content":"本文为翻译文章，点击查看原文。\n在微服务领域，各个服务需要在网络上执行大量的调用。而网络是很脆弱的，如果某个服务繁忙或者无法响应请求，将有可能引发集群的大规模级联故障，从而造成整个系统不可用，通常把这种现象称为 服务雪崩效应。为了使服务有一定的冗余，以便在系统故障期间能够保持服务能力，我们可以使用熔断机制。\n什么是熔断？ 熔断（Circuit Breaking）这一概念来源于电子工程中的断路器（Circuit Breaker）。在互联网系统中，当下游服务因访问压力过大而响应变慢或失败，上游服务为了保护系统整体的可用性，可以暂时切断对下游服务的调用。这种牺牲局部，保全整体的措施就叫做熔断。\n如果不采取熔断措施，我们的系统会怎样呢？我们来看一个栗子。\n当前系统中有 A、B、C 三个服务，服务 A 是上游，服务 B 是中游，服务 C 是下游。它们的调用链如下：\n一旦下游服务 C 因某些原因变得不可用，积压了大量请求，服务 B 的请求线程也随之阻塞。线程资源逐渐耗尽，使得服务 B 也变得不可用。紧接着，服务 A 也变为不可用，整个调用链路被拖垮。\n像这种调用链路的连锁故障，就是上文所说的服务雪 …","relpermalink":"/blog/circuit-breaking-and-outlier-detection-in-istio/","summary":"通过 Istio 来窥探 Envoy 的熔断与异常检测机制。","title":"熔断与异常检测在 Istio 中的应用"},{"content":"背景 由于容器化和微服务的大力发展，Kubernetes 基本已经统一了容器管理方案，当我们使用 Kubernetes 来进行容器化管理的时候，全面监控 Kubernetes 也就成了我们第一个需要探索的问题。我们需要监控 kubernetes 的 ingress、service、deployment、pod……等等服务，以达到随时掌握 Kubernetes 集群的内部状况。\n此文章是 Prometheus 监控系列的第一篇，目的也很明确，旨在于寻找一套能够胜任 kubernetes 集群监控的架构。\nk8s 监控方案调研 1、cAdvisor + InfluxDB + Grafana 2、Heapster + InfluxDB + Grafana 3、Promethus + kube-state-metrics + Grafana Grafana: 开源 DashBoard，后端支持多种数据库，如：Influxdb、Prometheus…，插件也比较多，功能强大。非常适合用于做展示。 InfluxDB: 开源时间序列数据库，性能高效 cAdvisor: 来自 Google 的容器监控 …","relpermalink":"/blog/prometheus-monitor-k8s-1/","summary":"本文旨在于寻找一套能够胜任 kubernetes 集群监控的架构。","title":"Prometheus 监控 Kubernetes 系列 1——监控框架"},{"content":"背景 由于容器化和微服务的大力发展，Kubernetes 基本已经统一了容器管理方案，当我们使用 Kubernetes 来进行容器化管理的时候，全面监控 Kubernetes 也就成了我们第一个需要探索的问题。我们需要监控 kubernetes 的 ingress、service、deployment、pod……等等服务，以达到随时掌握 Kubernetes 集群的内部状况。\n此文章是 Prometheus 监控系列的第二篇，基于上一篇讲解了怎么对 Kubernetes 集群实施 Prometheus 监控。\nK8s 编排文件可参考 https://github.com/xianyuLuo/prometheus-monitor-kubernetes\nPrometheus 部署 在 k8s 上部署 Prometheus 十分简单，下面给的例子中将 Prometheus 部署到 prometheus 命名空间。\n部署——数据采集 将 kube-state-metrics 和 prometheus 分开部署，先部署 prometheus。\nPrometheus …","relpermalink":"/blog/prometheus-monitor-k8s-2/","summary":"本文介绍 Prometheus 监控的部署。","title":"Prometheus 监控 Kubernetes 系列 2——监控部署"},{"content":"背景 由于容器化和微服务的大力发展，Kubernetes 基本已经统一了容器管理方案，当我们使用 Kubernetes 来进行容器化管理的时候，全面监控 Kubernetes 也就成了我们第一个需要探索的问题。我们需要监控 kubernetes 的 ingress、service、deployment、pod……等等服务，以达到随时掌握 Kubernetes 集群的内部状况。\n此文章也是 Prometheus 监控系列的第三篇，具体描述了在 Kubernetes 中使用 Prometheus 来采集业务指标。多数为思想指导，会列出两个例子。第一个例子是针对部署在 Kubernetes 中的服务，另外一个例子是非 Kubernetes 部署的服务。前者为使用“动态采集”，后者使用“静态采集”。\n概念 要使用 Prometheus 实现自动采集业务指标数据真的非常简单，只需要 2 步\n1、业务侧实现一个接口，返回 Prometheus 规范化数据，如下： …","relpermalink":"/blog/prometheus-monitor-k8s-3/","summary":"本文介绍 Prometheus 如何采集业务指标。","title":"Prometheus 监控 Kubernetes 系列 3——业务指标采集"},{"content":"本文为翻译文章，点击查看原文。\n编者案 Idit Levine 作为 solo.io 创始人兼首席执行官，在本系列博客中介绍了她们的产品 Gloo。这篇博客是系列中的其中一篇，这一篇的主要内容是，如果要基于 Envoy 构建一个控制平面的话，我们需要考虑哪些问题；要用什么样的解决方案来应对这些问题。作者在本文章阐述了 Envoy 的工作原理、为什么要选择 Envoy 以及在构建一个控制平面过程中要做出的技术体系结构的抉择。\n在本系列博客中，我们将分享如何为 Envoy Proxy 构建一个多用途控制平面 Gloo 的经验。本系列的第一个博客关注于 Envoy 的设计，以及在构建控制平面的第一层时需要做出的技术体系结构抉择。\nEnvoy Proxy 是由 Lyft 研发团队设计的通用数据平面。Envoy 的优势源于性能、可扩展性和动态配置的结合。然而，这种能力是以增加配置复杂性为代价的。事实上，Envoy 配置是由管理层 (通常称为“控制平面”) 通过机器生成的。\n为 Envoy 编写一个控制平面并不是一件容易的事情，就像 Ambassador 创建者最近在一篇文章中描述的那样，该文章详 …","relpermalink":"/blog/building-a-control-plane-for-envoy/","summary":"本文介绍如何利用 Gloo 提供的功能，减少自己需要编写的代码。","title":"为 Envoy 赋能——如何基于 Envoy 构建一个多用途控制平面"},{"content":"本文为翻译文章，点击查看原文。\nIstio 提供了非常易用的安全解决方案，包括服务间身份验证mTLS，服务间访问控制RBAC，以及终端用户身份验证JWT等，本文主要介绍如何使用服务间访问控制，同时涉及双向TLS。\nIstio 版本 1.1.0 在的github.com/hb-go/micro-mesh中有结合示例的RBAC 配置实践可以参考 要实现RBAC主要理解以下几个类型的yaml配置，以及之间的关系：\n双向 TLS Policy或MeshPolicy，上游server开启 TLS DestinationRule，下游client开启 TLS RBAC ClusterRbacConfig/RbacConfig，启用授权及范围 ServiceRole，角色权限规则 ServiceRoleBinding，角色绑定规则 Optional ServiceAccount，ServiceRoleBinding.subjects的user条件 假设场景 网格内service-1、service-2开启 RBAC 访问控制 仅service-1授权给ingressgateway访 …","relpermalink":"/blog/istio-rbac-quick-start/","summary":"Istio 提供了非常易用的安全解决方案，包括服务间身份验证 mTLS，服务间访问控制 RBAC，以及终端用户身份验证 JWT 等，本文主要介绍如何使用服务间访问控制，同时涉及双向 TLS。","title":"Istio 安全之服务间访问控制 RBAC"},{"content":" 本文为翻译文章，点击查看原文。\n这篇文章是使用 Istio 打造微服务的第二部分，如果没有看第一篇的话，请先看第一部分内容，因为这篇博客是以第一篇博客为基础进行进一步深入的。\n在第一篇文章中，我们建立了一个 Kubernetes 集群，并且在上面部署了 Istio 和示例微服务应用程序“Sentiment Analysis”，用来展示 Istio 的功能。\n使用 Istio 后，我们可以把应用层中的重试、超时、断路器、跟踪、监控内容抛弃，以保持我们的服务应用保持在一个简单专注的微型状态，（如图 1 所示）。此外，我们还启用了高级测试和部署技术，如 A/B 测试，镜像和金丝雀部署。\n图 1.微服务的形式构成 在本文中，我们将带领读者使用 Istio 来处理身份验证和授权！\nIstio 中的认证和授权 我永远不会相信认证和授权会让我感到兴奋！但是 Istio 可以让这个话题变得有趣，这种情况下难道你不感到兴奋么？\n答案很简单：Istio 将这些职责从我们的服务下沉到 Envoy 代理，当请求到达我们的服务时，它们已经经过身份验证和授权，我们只需编写提供业务价值的代码。\n听起来不错？让我们 …","relpermalink":"/blog/back-to-microservices-with-istio-part-2-authentication-authorization/","summary":"系列文章使用 Istio 打造微服务的第 2 部分。","title":"使用 Istio 打造微服务（第 2 部分）——认证和授权"},{"content":"下面这段是发布说明，来自 Istio 官方博客 https://istio.io/zh/blog/2019/announcing-1.1/，译者宋净超。\nIstio 于北京时间今日凌晨 4 点，太平洋时间下午 1 点 Istio 1.1 发布。\n自从去年 7 月份 1.0 发布以来，为了帮助人们将 Istio 投入生产我们做了很多工作。我们不出所料得发布了很多补丁（到目前为止已经发布了 6 个补丁！），但我们也在努力为产品添加新功能。\n1.1 版本的主题是”Enterprise Ready“（企业级就绪）。我们很高兴看到越来越多的公司在生产中使用 Istio，但是随着一些大公司加入进来，Istio 也遇到了一些瓶颈。\n我们关注的主要领域包括性能和可扩展性。随着人们将 Istio 逐步投入生产，使用更大的集群以更高的容量运行更多服务，可能会遇到了一些扩展和性能问题。Sidecar 占用了太多资源增加了太多的延迟。控制平面（尤其是 Pilot）过度耗费资源。\n我们投入了很多精力在使数据平面和控制平面更有效率上。在 1.1 的性能测试中，我们观察到 sidecar 处理 1000 rps 通 …","relpermalink":"/blog/istio-11/","summary":"Istio 1.1 发布了，该版本历时 8 个月，ServiceMesher 社区同时推出了 Istio 中文文档。","title":"Istio 1.1 发布，中文文档同时释出"},{"content":"背景 对于服务的可见性，在 Istio 设计之初，是没有特别考虑的，或者说，Istio 一开始的假定，就是建立在如下这个前提下的：\nIstio 中的每个服务都可以访问 Mesh 中的任意服务\n即在服务发现/请求转发这个层面，对服务访问的可见性不做任何限制，而通过安全机制来解决服务间调用权限的问题，如RBAC的使用。在这个思想的指导下，Pilot组件是需要将全量的服务信息（服务注册信息和服务治理信息）下发到 Sidecar，这样 Sidecar 才能在做到不管服务要请求的目标是哪个服务，都可以做到正确的路由。\n这个机制在 demo 和小规模使用时不是问题，但是，在实际项目落地时，如果服务数量比较多，数以百计/数以千计，则立即显露出来：\n下发的信息量太大：因此 Pilot 和 Sidecar 的 CPU 使用会很高，因为每次都要将全量的数据下发到每一个 sidecar，需要编解码。Sidecar 的内存使用也会增加。 下发的频度非常密集：系统中任何一个服务的变动，都需要通知到每一个 Sidecar，即使这个 Sidecar 所在的服务完全不访问它 试想：假定 A 服务只需要访问 B/C 两 …","relpermalink":"/blog/istio-service-visibility/","summary":"对于服务的可见性，在 Istio 设计之初，是没有特别考虑的，或者说，Istio 一开始的设计就是建立在如下前提下的：Istio 中的任何服务都可以访问其他任意服务。直到 Istio1.1 版本才开始正视这个问题。","title":"Istio1.1 新特性之限制服务可见性"},{"content":" 作者：钟华，腾讯云容器团队高级工程师，热衷于容器、微服务、service mesh、istio、devops 等领域技术\n今天我们分析下 istio-sidecar-injector 组件：\nimage-20190319105935249 查看高清原图\n用户空间的 Pod 要想加入 mesh, 首先需要注入 sidecar 容器，istio 提供了 2 种方式实现注入：\n自动注入：利用 Kubernetes Dynamic Admission Webhooks 对 新建的 pod 进行注入：initContainer + sidecar 手动注入：使用命令istioctl kube-inject 「注入」本质上就是修改 Pod 的资源定义，添加相应的 sidecar 容器定义，内容包括 2 个新容器：\n名为istio-init的 initContainer: 通过配置 iptables 来劫持 Pod 中的流量 名为istio-proxy的 sidecar 容器：两个进程 pilot-agent 和 envoy, pilot-agent 进行初始化并启动 envoy img 1. …","relpermalink":"/blog/istio-analysis-2/","summary":"今天我们来分析下 istio-sidecar-injector 组件。","title":"Istio 庖丁解牛二：sidecar injector"},{"content":"引子 这几天拜读了灵雀云出品的一篇文章：《从“鸿沟理论”看云原生》，其中有两段关于 Istio 的陈述，我深感赞同：\n在 Control Plane，Istio 是最具光环的明星级项目。它正在引领 Service Mesh 创造出一个全新的市场，不过从传播周期看现在还没有跨过技术鸿沟，处于 Early adopters 阶段。 在开源领域，并不存在对 Istio 有实质性威胁的竞品。可能在经历了 Kubernetes 之后，以及 Istio 早期迅猛的发展和在社区中巨大的影响力之下，很少有开源项目愿意在 Control Plane 和 Istio 正面交锋。 按照我对 Istio 的理解，正如该文所说，正处于鸿沟一侧，正是从早期采用者到早期大众之间关键阶段。然而这一系统的情况又比较特殊，Service Mesh 的饼，虽说是 Linkerd 画出来的，然而真正把饼变大的，正是 Istio。Istio 画了硕大无朋的饼之后，就步步泥潭，功能薄弱、进度拖沓，让包括我在内的众多用户大摇其头。然而，画饼的另一面，就是挖坑——Istio 放出的漫天卫星，极大的吊起了各种用户的胃口，可以说是用先声 …","relpermalink":"/blog/service-mesh-and-chasm/","summary":"Istio 1.1 新特性概览。","title":"鸿沟前的服务网格—Istio 1.1 新特性预览"},{"content":" 本文转载自赵化冰的博客。\n在 Istio 架构中，Pilot 组件负责维护网格中的标准服务模型，该标准服务模型独立于各种底层平台，Pilot 通过适配器和各底层平台对接，以使用底层平台中的服务数据填充此标准模型。\n例如 Pilot 中的 Kubernetes 适配器通过 Kubernetes API Server 到 Kubernetes 中的 Service 以及对应的 Pod 实例，将该数据被翻译为标准模型提供给 Pilot 使用。通过适配器模式，Pilot 还可以从 Cloud Foundry、Consul 中获取服务信息，也可以开发适配器将其他提供服务发现的组件集成到 Pilot 中。\n本文将从代码出发，对 Pilot 的服务注册机制进行分析。\n备注：本文分析的代码对应 Istio commit 58186e1dc3392de842bc2b2c788f993878e0f123\n服务注册相关的对象 首先我们来了解一下 Pilot 中关于服务注册的一些基本概念和相关数据结构。\nIstio 源码中，和服务注册相关的对象如下面的 UML 类图所示。\nService 源码文 …","relpermalink":"/blog/istio-pilot-service-registry-code-analysis/","summary":"本文将从代码出发，对 Istio Pilot 的服务注册插件机制进行分析。","title":"Istio 服务注册插件机制代码解析"},{"content":"本文为翻译文章，点击查看原文。\nSidecar 代理模式是一个重要的概念，它允许Istio为服务网格中运行的服务提供路由、度量、安全和其他功能。在这篇文章中，我将解释为 Istio 提供支持的关键技术，同时还将向您展示一种构建简单的 HTTP 流量嗅探 sidecar 代理的方法。\n引言 服务网格的实现通常依赖于 sidecar 代理，这些代理使得服务网格能够控制、观察和加密保护应用程序。sidecar 代理是反向代理，所有流量在到达目标服务之前流过它。代理将分析流经自己的流量并生成有用的统计信息，而且还能提供灵活的路由功能。此外，代理还可以使用mTLS来加密保护应用程序流量。\n在这篇文章中，我们将构建一个简单的 sidecar 代理，它可以嗅探 HTTP 流量并生成统计信息，例如请求大小，响应状态等。然后，我们将在Kubernetes Pod 中部署 HTTP 服务，配置 sidecar 代理，并检查生成的统计信息。\n构建 HTTP 流量嗅探代理 Istio 依靠Envoy来代理网络流量。Envoy 代理被打包为一个容器，并部署在一个 Pod 中的服务容器旁边。在这篇文章中，我们将使 …","relpermalink":"/blog/hand-crafting-a-sidecar-proxy-like-istio/","summary":"本文介绍了一种实现简单 HTTP 流量嗅探代理的基本步骤，并进行了相关实验验证，生动展现了 Istio 实现流量管理的核心原理与概念。","title":"手工打造像 Istio 中一样的 Sidecar 代理"},{"content":"作者：钟华，腾讯云容器团队高级工程师，热衷于容器、微服务、service mesh、istio、devops 等领域技术。\nIstio 作为 Service Mesh 领域的集大成者，提供了流控，安全，遥测等模型，其功能复杂，模块众多，有较高的学习和使用门槛，本文会对 istio 1.1 的各组件进行分析，希望能帮助读者了解 istio 各组件的职责、以及相互的协作关系。\n1. istio 组件构成 以下是 istio 1.1 官方架构图：\n虽然 Istio 支持多个平台，但将其与 Kubernetes 结合使用，其优势会更大，Istio 对 Kubernetes 平台支持也是最完善的，本文将基于 Istio + Kubernetes 进行展开。\n如果安装了 grafana, prometheus, kiali, jaeger 等组件的情况下，一个完整的控制面组件包括以下 pod:\n% kubectl -n istio-system get pod NAME READY STATUS grafana-5f54556df5-s4xr4 1/1 Running …","relpermalink":"/blog/istio-analysis-1/","summary":"Istio 作为 Service Mesh 领域的集大成者，提供了流控，安全，遥测等模型，其功能复杂，模块众多，有较高的学习和使用门槛，本文会对 istio 1.1 的各组件进行分析，希望能帮助读者了解 istio 各组件的职责、以及相互的协作关系。","title":"Istio 庖丁解牛一：组件概览"},{"content":" 译者：杨铁党、孙海洲、邱世达、宋净超、徐鹏\nKnative 是一个基于 Kubernetes 的，用于构建、部署和管理现代 serverless 应用的平台。Getting Started with Knative 是一本由 Pivotal 公司赞助 O’Reilly 出品的电子书，本书中文版由 ServiceMesher 社区自发翻译，这是该系列的第二篇文章。\n即便使用无服务器架构，处理和响应 HTTP 请求的能力依然重要。在开始写代码使用事件触发一个函数之前，您需要有地方来运行代码。\n本章探讨 Knative Serving 组件，您将了解 Knative Serving 如何管理部署以及为应用和函数提供服务。通过 Serving，您可以轻松地将一个预先构建好的镜像部署到底层 Kubernetes 集群中。（在第三章：Build，您将看到 Knative Build 可以帮助构建镜像以在 Serving 组件中运行）Knative Serving 维护某一时刻的快照，提供自动化伸缩功能 (既支持扩容，也支持缩容直至为零)，以及处理必要的路由和网络编排。\nServing 模块定义一 …","relpermalink":"/blog/knative-serving/","summary":"本章介绍 Knative Serving 组件，描述 Knative Serving 如何部署并为应用和函数 (funtions) 提供服务。","title":"Knative 入门系列 2：serving 介绍"},{"content":"译者：陈佳栋、宋净超、孙海洲、徐鹏、邱世达\nKnative 是一个基于 Kubernetes 的，用于构建、部署和管理现代 serverless 应用的平台。Getting Started with Knative 是一本由 Pivotal 公司赞助 O’Reilly 出品的电子书，本书中文版由 ServiceMesher 社区自发翻译，从今天起 ServiceMesher 社区将陆续为大家推出本书的中文译文。\n前言 Kubernetes 赢了。这不是夸大其词，事实就是如此。越来越多的人开始基于容器部署，而 Kubernetes 已经成为容器编排的事实标准。但是，Kubernetes 自己也承认，它是一个容器而不是代码平台。它可以作为一个运行和管理容器的很好的平台，但是这些容器是如何构建、运行、扩展和路由很大程度上是由用户自己决定的。这些是 Knative 想要补充的缺失部分。\n也许你已经在生产上使用 Kubernetes，或者你是一个前沿技术爱好者，梦想着将你基于 OS/2 运行的组织现代化。不管怎样，本报告都没有假定太多东西，只是要求您知道容器是什么，具有 Kubernetes 的 …","relpermalink":"/blog/knative-overview/","summary":"本文是 Knative 入门系列的第一篇，knative 概述。","title":"Knative 入门系列 1：knative 概述"},{"content":"本文为翻译文章，点击查看原文。\n编者按 本文作者由浅及深，从核心问题的引入到具体模式的代码实现，阐述了微服务两种断路器模式的实现原理、优缺点以及二者的比较。\n前言 不可否认的是，在过去的几年里，Docker 和 Kubernetes 等技术已经彻底改变了我们对软件开发和部署的理解。\n但是，尽管软件开发行业的快速发展促使开发人员采用最新的技术，但是后退一步，更好地查看支持这些技术的已建立的模式是很重要的。\n断路器模式是微服务体系结构中广泛采用的模式之一。我们将比较使用两种不同方法实现它的优缺点：Hystrix 和 Istio。\nistio-vs-hystrix.jpg 微服务同步通信的核心问题 设想一个非常简单的微服务体系结构，包括：\n一个后端服务 一个前端服务 我们假设后端和前端通过同步 HTTP 调用进行通信。\n客户端C1 和 C2 调用 前端 获取一些信息。由于前端没有客户端所需的所有数据，因此它调用后端以获得缺失的部分数据。\n但是因为网络通信，很多事情会发生：\n前端和后端之间的网络故障 后端可能会因为错误而宕机 一个被后端依赖的服务 (*e.g.*数据库) …","relpermalink":"/blog/istio-vs-hystrix-circuit-breaker/","summary":"由微服务同步通信的核心问题引入，讨论断路器模式，再深入阐述 Istio 与 Hystrix 两种断路器的实现原理，最后比较二者的优缺点和选型建议。","title":"微服务断路器模式实现：Istio vs Hystrix"},{"content":"快速开始：https://micro-mesh/examples/adapter/auth源码传送门。\n研究 Istio 下构建简洁的微服务架构，对 Istio 的研究也更深入，自定义 Mixer Adapter 必不可少，以下结合使用场景做一个自定义适配器的实践分享。\n背景 结合https://github.com/hb-go/micro-mesh的实践场景，需要在ingressgateway与API service间加入认证\u0026amp;鉴权 (JWT\u0026amp;RBAC)，自然考虑 Istio 提供的安全方案，但使用 JWT 做认证鉴权在后端是无状态的，这样在使用场景上有一定限制，如：\n密码修改、终端连接限制等场景下无法踢除 访问控制策略无法实时生效 默认方案只是在一些场景下不合适，根据具体需求考虑。\n基于这样的场景可以自定义 Adapter 来实现，目标：\nToken-JWT 服务端验证 token 有效性 应对密码修改、终端数量限制等场景 ACL-Casbin 服务端获取用户角色，做 API 访问控制 用户角色及接口授权策略实时生效 以下示例对 token 验证、访问控制不做具体设计，重点介绍如何 …","relpermalink":"/blog/custom-istio-mixer-adapter/","summary":"研究 Istio 下构建简洁的微服务架构，对 Istio 的研究也更深入，自定义 Mixer Adapter 必不可少，以下结合使用场景做一个自定义适配器的实践分享。","title":"自定义 Istio Mixer Adapter 示例教程（附源码）"},{"content":"本文为翻译文章，点击查看原文。\n背景 Istio 发送的默认指标有助于了解流量如何在集群中流动。但是，要了解应用程序的行为，还需要应用程序指标。\nPrometheus提供了客户端库，您可以使用它来检测应用程序并发送监测指标。 这很好，但也提出了一些问题：\n您从哪里抓取这些指标？ 您是使用 Istio 附带的 Prometheus，还是自建新的 Prometheus？ 如果使用 Istio 附带的 Prometheus，那您需要使用什么样的配置来获取这些指标？ 让我们尝试回答这些问题。\nIstio 的 Prometheus vs. 独立的 Prometheus 在 Prometheus 中，有一个联邦功能，它允许一个 Prometheus 服务端从另一个 Prometheus 服务端获取指标数据。如果您想将 Istio 指标和应用程序指标分开，可以为应用程序指标设置一个单独的 Prometheus 服务端。然后，您可以使用联邦功能来获取应用程序指标以及 Istio 默认的观测指标。\n一种更简单的方法是直接使用 Istio 的 Prometheus 来提取应用程序的指标，这正是我在这里要重 …","relpermalink":"/blog/application-metrics-in-istio/","summary":"本文介绍了在 Istio 环境下进行应用程序指标度量的背景知识、一般方法以及可能出现的问题。","title":"Istio 中的应用程序指标度量"},{"content":"本文为翻译文章，点击查看原文。\n编者案 Envoy 作为最受欢迎的早期网络组件，现在已经可以说是云原生架构中的通用数据平面。本文作者指引我们更方便的使用 Envoy，及其定制控制平面，作者通过收集到的数据给出定制控制平面不同的意见，非常中肯，后续系列会更深入，欢迎关注该系列文章。\nEnvoy 最近成为一个受欢迎的网络组件。几年前 Matt Klein 写了一篇博客 ，讨论了 Envoy 的动态配置 API，以及 Envoy 发展的历史和动机。他称该博客为“通用数据平面 API”。由于许多其他项目采用Envoy 作为其产品的核心组件，因此对于应用程序/L7 网络解决方案而言，毫不夸张地说，“Envoy 已成为云原生架构中的通用数据平面”，而不仅仅是简单建立了 API 标准。\n此外，由于 Envoy 的通用数据平面 API ，我们已经看到了许多 管理层 的实现，用于配置和驱动基于 Envoy 的基础架构。我们将深入探讨为 Envoy 构建控制平面所需的内容，以便您可以使用此信息来评估哪种类型的基础架构最适合您的组织和使用情况。因为这是一个广泛的主题，我们将在未来几天发布的多部系列博客中解决 …","relpermalink":"/blog/guidance-for-building-a-control-plane-to-manage-envoy-proxy-at-the-edge-as-a-gateway-or-in-a-mesh/","summary":"Envoy Proxy 构建控制平面指南。","title":"Envoy Proxy 构建控制平面指南"},{"content":"本文为翻译文章，点击查看原文。\n[编者案]\nKnative 作为 Google 发起开源的 serverless 项目，给我们提供了一套简单易用的 serverless 开源解决方案。本文作者直观地向我们展示了如何使用 Knative 来一步一步逐渐精简我们的代码，来更加简单容易的开发云原生应用。作者使用实例来逐步向我们讲述如何使用 Knative 提供的 Build、Serving 和 Eventing 三大组件来发挥威力，逐渐精简代码。如果您对 Knative 有兴趣，本文对于你通过 Knative 实践 serverless 一定会有所启发，希望您能喜欢。\n对我来说，2018 年最好的开源项目是Knative，这是一个建立在 Kubernetes 之上的 serverless 平台。不仅是为了 serverless 平台本身，也是为了它所倡导的整个开发范式。事件驱动开发并不新鲜，但 Knative 为围绕事件构建生态系统奠定了基础。\n如果您不熟悉 Knative，那么您读到的任何文档都将它分为三大组件：\n构建 (Build) —— 我如何构建代码和打包代码？ …","relpermalink":"/blog/knative-whittling-down-the-code/","summary":"本文介绍如何利用 Knative 提供的功能，减少自己需要编写的代码。","title":"Knative：精简代码之道"},{"content":" Istio 是一个由 Google，IBM 和 Lyft 团队合作开发的开源项目，它提供了基于微服务的应用程序复杂性的解决方案，仅举几例：\n流量管理 ：超时，重试，负载均衡， 安全性： 最终用户身份验证和授权， 可观察性： 跟踪，监控和记录。 所有这些都可以在应用程序层中解决，但是您的服务不再是“微型”，相对于提供业务价值的资源，实现这些的所有额外工作都是公司资源的压力。我们来举个例子：\nPM：添加反馈功能需要多长时间？\n开发：两个冲刺（敏捷开发中的术语，一般一个冲刺周期 30 天）。\nPM：什么……？那只是一个 CRUD！\n开发：创建 CRUD 很容易，但我们需要对用户和服务进行身份验证和授权。而且由于网络不可靠，我们需要在客户端实施重试和熔断器，并确保我们不会占用整个系统，我们需要 Timeout 和 Bulkheads，另外还要检测我们需要监控的问题，跟踪[… ]\nPM：那么我们就把它放在产品服务中吧。哎呀！\n你明白了，必须满足所有形式才可以为我们添加一项巨大的服务（有很多不是业务功能的代码）。在本文中，我们将展示 Istio 如何从我们的服务中删除所有上述交叉问题。\n图 1. …","relpermalink":"/blog/back-to-microservices-with-istio-p1/","summary":"使用 Istio 打造微服务的教程（第 1 部分）。","title":"使用 Istio 打造微服务（第 1 部分）"},{"content":"2019 年 2 月 15 日晚，我在朋友圈里发起了 Istio 知识图谱项目。\nIstio 知识图谱发起 而后获得 ServiceMesher 社区成员的热烈响应，在此后的一周内陆续有 151 参与进来。\nistio 知识图谱参与人员 经过 10 天的孵化，Istio 知识图谱 v0.1 发布了，该版本作为 Istio 知识图谱的启动版本，未来将会进一步细化甚至推出一本开源书籍。\nIstio 知识图谱阅览 Istio knowledge map Istio 知识图谱提供以下格式，点击下面的链接可以查看：\nMarkdown MindNode PDF PNG 参与贡献 Istio 知识图谱 v0.1 在 Google docs 上协作编辑，参与编辑请参考贡献指南。\n致谢 感谢 Istio 知识图谱工作组的全体人员，特别鸣谢以下参与贡献者（GitHub ID，按字母顺序排序）：\ndreadbird haiker2011 icyxp junxy kongbo1987 mgxian nicklv sataqiu rootsongjc wujunze xianyuluo 关于 Istio 知识图 …","relpermalink":"/blog/istio-knowledge-map-v0-1-release/","summary":"Istio 知识图谱 v0.1 版本发布及 Istio handbook 联署签名征集。","title":"Istio 知识图谱 v0.1 发布及社区图书孵化"},{"content":"关于 Knative eventing 的基本概念可以参考：\nhttps://github.com/knative/docs/blob/master/eventing/README.md https://thenewstack.io/knative-enables-portable-serverless-platforms-on-kubernetes-for-any-cloud/ 本文不对基本概念做介绍，本文主要是基于 Kubernetes Event Source example 为例分析 in-memory-channel 的实现原理。\n在运行 Kubernetes Event Source example 之前要保证已经安装了 in-memory-channel , 下面先从 in-memory-channel controller 开始介绍 channel 的工作机制。\nin-memory-channel controller in-memory-channel 安装好以后就会自动创建一个 controller …","relpermalink":"/blog/knative-eventing-in-memory-channel-deep-dive/","summary":"本文不对基本概念做介绍，本文主要是基于 Kubernetes Event Source example 为例分析 in-memory-channel 的实现原理。","title":"Knative Eventing in-memory-channel 实现原理解析"},{"content":"本文为翻译文章，点击查看原文。\n编者注：原文于 2017 年 7 月 30 日发布于 Envoy 博客上。\n关于 Envoy 代码库的底层技术文档目前相当稀少。为了纠正这个问题，我打算做一系列关于各种子系统的博客文章。由于这是第一篇文章，请让我知道您的想法以及您希望了解的其他主题。\n我经常看到的关于 Envoy 的最常见技术问题之一就是要求从底层描述 Envoy 使用的线程模型。这篇文章将介绍 Envoy 如何将连接映射到线程，以及内部使用的线程本地存储（TLS）系统的描述，以使代码极其并行且性能更高。\n线程模型概览 Envoy 使用三种不同类型的线程，如上图所示。\nMain：此线程负责服务器启动和关闭，所有 xDS API 处理（包括 DNS，运行状况检查 和常规 集群管理），运行时，统计刷新，管理和一般进程管理（信号，热启动 等）。在此线程上发生的所有事情都是异步的并且是“非阻塞的”。通常，主线程协调所有不需要大量 CPU 来完成的关键过程功能。这允许将大多数管理代码编写为单线程编写。 Worker：默认情况下，Envoy 为系统中的每个硬件线程生成一个工作线程。（ …","relpermalink":"/blog/envoy-threading-model/","summary":"Envoy 的架构师 Matt Klein 对 Envoy 中多线程模型的简单介绍。","title":"Envoy 架构师 Matt Klein 对 Envoy 线程模型的简介"},{"content":" 此文章适合没有任何 Kubernetes/容器/Docker 经验的同学 — 在不久的将来，你不懂如何操作 Kubernetes 接口，就等于现在的你不懂最普通的 Linux 命令。此文章阅读耗时大概 15 分钟。\n蚂蚁金服资源调度组致力于将 Kubernetes 落地到世界上最有价值的金融科技独角兽公司，欢迎联系作者微信 answer1991chen 咨询招聘事宜。\n文章 Markdown 源码位于 https://github.com/answer1991/articles/blob/master/Kubernetes-is-the-next-generation-os.md，遵从 Apache License 2.0 开源协议。\n导言 此文章着重介绍如何在入门阶段使用 Kubernetes，以及要面向 Kubernetes 编程带来的优势，不会介绍复杂的 Kubernetes 架构、实现。因此此文章适合没有任何 Kubernetes/容器/Docker 经验的同学，对 Kubernetes 有了解的同学也可以从此文章里面获取一些灵感，可以更加酷炫的玩转 Kubernetes。\n …","relpermalink":"/blog/the-data-center-os-kubernetes/","summary":"此文章着重介绍如何在入门阶段使用 Kubernetes，以及要面向 Kubernetes 编程带来的优势。","title":"面向 Kubernetes 编程：Kubernetes 是下一代操作系统"},{"content":"本文为翻译文章，点击查看原文。\n2017 年 5 月，谷歌面向大规模容器化应用管理的开源项目 Istio 正式发布了。此后经过快速的发展，于 2018 年 7 月发布了里程碑式的 1.0 版本。本文的主要内容包括：Istio 是什么、Istio 的工作原理以及落地方式。在本系列的后续文章中我们还会深入了解 Istio 的安全和流量管理功能。\nIstio 是什么？ 从过去几年发布的大量开源项目中我们可以总结出谷歌内部构建、部署与管理大型分布式容器化应用的方案。而 Istio 就是这个方案的最后一步——管理应用程序。了解 Istio 在谷歌内部的起源可以帮你更好的理解它的设计思想和历史背景。\nNetflix 详细的介绍过混沌工程实践以及故障注入、熔断、限流和链路跟踪等概念。为了避免在每个新项目中都需要重新实现这些功能，开发者一般选择在底层网络实现它们。当前的两种嵌入方式：\n把这些功能和公司用到的所有语言的网络库打包到一起，并为所有的服务和团队维护它们。 通过服务网格透明的提供这些功能。Istio 使用的就是这种方式。Istio 把Envoy 代理作为每个 pod 的 sidecar 运行并 …","relpermalink":"/blog/istio-kubernetes-service-mesh/","summary":"本文介绍了什么是 Istio，并详细分析了 Istio 的优势，最后分享了关于 Istio 的一些落地经验。","title":"Istio——企业级微服务解决方案"},{"content":"《深入浅出 Istio》这本书这两天开始卖了，我也第一时间入手了以后到现在已经基本上全部翻完了。在这里记录一下看完这本书的读后感。 总体来说，这本书是一本既适合 Istio 本身有一定了解程度的使用者，也适合对 ServiceMesh 初学者的去学习 Istio 的书籍。这本书比较全面的介绍并总结了 Istio 的各个组件及其使用方法，并给出了许多具体的场景。\n作为一名接触 ServiceMesh 领域和 Istio 快小半年的我来说，对于书中一些比较基础的章节和内容快速翻了一翻，同时也对部分对我帮助非常大的章节做了一些总结和心得。在这里用一篇读后感记录我读完以后的感受。\n深入浅出 Istio 关于书籍作者 作者在 ServiceMesher 社区里面是一个非常活跃的人，对 istio.io 的中文化工作做了非常大的贡献。作为一个大部分时间在社区内处于一个围观群众，在这里对作者对国内 ServiceMesh 领域做出的贡献表示由衷的感谢。\n全书结构 整本书分为十章，整本书我重点看了第 1,2,3,5,8,10。第七章重点看了后半部分。\n服务网格历史 服务网格的特性 介绍 istio 安 …","relpermalink":"/blog/reading-istio-service-mesh-book/","summary":"本文是《深入浅出 Istio》（崔秀龙著，电子工业出版社出版）一书的读后感。","title":"《深入浅出 Istio》读后感"},{"content":"前言 在 2017 年年底，在 Service Mesh 刚刚兴起之时，应 InfoQ 的邀请撰写过一篇名为 “Service Mesh 年度总结：群雄逐鹿烽烟起” 的文章，对 2017 年 Service Mesh 的发展做了一次年度回顾。当时正是 Service Mesh 技术方兴未艾，各家产品你争我夺之时，一片欣欣向荣的气象。\n时隔一年，江湖风云变幻。再次有幸收到 InfoQ 的邀请，继续进行 Service Mesh 2018 年的年度总结。本次年度总结将由来自聚集国内 ServiceMesh 爱好者的 ServiceMesher 社区 的多位嘉宾共襄盛举，希望能为 Service Mesh 2018 年的发展做一个系统而全面的总结。\n备注：为了不重复去年年度总结的内容，我们将直接从 2018 年初开始本次年度总结，如果您想了解 service mesh 在 2018 年前的发展历程，请先参阅 2017 年年度总结。\n为了更有成效的完成总结，我们将以问答的方式来让下文中陆续出场的各个 Service Mesh 产品和解决方案提供自己的答案，问题很简单：在 2018 年，做了什 …","relpermalink":"/blog/service-mesh-summary-2018/","summary":"Service Mesh 2018 年度总结。","title":"Service Mesh 的 2018 年度总结"},{"content":" 发布概述 本文为翻译文章，点击查看原文。\n我们很高兴地宣布 Cilium 1.4 版本。该版本引入了几项新功能以及优化和可扩展性工作。重点包括增加全局服务，提供跨多个集群的 Kubernetes 服务路由、DNS 请求/响应感知授权和可见性、透明加密（beta）、IPVLAN 支持以获得更好的性能和延迟（beta）、与 Flannel 集成、GKE 在 COS 上支持、基于 AWS 元数据的策略实施（alpha）以及优化内存和 CPU 使用的重要工作。\n像往常一样，感谢过去 4 个月中在版本 1.3 和 1.4 之间贡献了 1048 次提交的 Cilium 开发人员及整个社区。\nCilium 是什么？ Cilium 是一个开源软件，用于透明地提供和保护使用 Kubernetes、Docker 和 Mesos 等 Linux 容器管理平台部署的应用程序服务之间的网络和 API 连接。\nCilium 的基础是一种名为 BPF 的新 Linux 内核技术，它可以在 Linux 本身内动态插入强大的安全性、可见性和网络控制逻辑。BPF 用于提供诸如多集群路由， …","relpermalink":"/blog/cilium-1-4/","summary":"Cilium 1.4：多集群服务路由，DNS 授权，IPVLAN 支持，透明加密，Flannel 集成，与其他 CNI 的基准测试。","title":"Cilium 1.4 发布了，新功能一览"},{"content":"互联网服务离不开用户认证。JSON Web Token(后简称 JWT) 是一个轻巧，分布式的用户授权鉴权规范。和过去的 session 数据持久化的方案相比，JWT 有着分布式鉴权的特点，避免了 session 用户认证时单点失败引起所有服务都无法正常使用的窘境，从而在微服务架构设计下越来越受欢迎。然而 JWT 单点授权，分布鉴权的特点也给我们带来了一个问题，即服务端无法主动回收或者 BAN 出相应的 Token，使得即使某个服务主动封禁了一个用户时，这个用户同样可以使用之前的 JWT 来从其他服务获取资源。本文我们将阐述利用 Istio Mixer Adapter 的能力，来将所有请求在服务网格的入口边缘层进行 JWT 检查的例子，从而实现用户封禁与主动逐出 JWT 等功能。\n背景 在我之前的投稿中，描绘了一个非常简单的基于 K8S 平台的业务场景，在这里我们将会基于这个场景来进行讨论。 对于一个简单的微服务场景，我们有着三个服务在 Istio 服务网格中管理。同时集群外的请求将会通过 nginx-ingress 转发给 istio-ingressgateway 以后， …","relpermalink":"/blog/using-istio-mixer-adapter-to-check-jwt/","summary":"本文介绍了作者如何通过自定义 Istio Mixer Adapter 在 JWT 场景下实现用户封禁的原理与步骤。","title":"通过自定义 Istio Mixer Adapter 在 JWT 场景下实现用户封禁"},{"content":"2019 年 2 月初，CNCF 发布了 2018 年的年度报告，这是 CNCF 继 2017 年度报告之后，第二次发布年度报告，2017 年度的报告只有区区 14 页，今年的报告长度增长了一倍达 31 页。下面我将带大家一起来深度解读下这份 2018 年的年度报告，一窥 CNCF 过去一年里在推广云原生的道路上取得的进展。\n注：本文最后附上了 2017 年和 2018 年度的报告下载地址。\nCNCF 年度报告涵盖的范围 在解读 CNCF 的 2018 年度报告之前，我们先简单回顾下2017 年度的报告，因为 2017 年度报告是 CNCF 的首份年度报告，这样我们也能更好的了解 CNCF 的来龙去脉。\n2017 年度报告已经基本确定了 CNCF 每个年度报告所包含的主题：\n自我定位 会员参与情况 终端用户社区 项目更新 会议和活动 社区 培训和认证 以上为 CNCF 主要的市场活动，2017 年时其成立的第二年，经过一年时间的筹备，这一年里各种市场活动都已经开始确立并有声有色的开展了起来，包括 KubeCon、成员单位、终端用户都已经发展起来了，以后历年里只是对其不断的发展和完善。 …","relpermalink":"/blog/cncf-annual-report-2018-review/","summary":"本文是对 CNCF（云原生计算基金会）2018 年年度报告的解读。","title":"CNCF 年度报告解读（2018 年）"},{"content":"Kong 是一个基于 OpenResty (Nginx) 封装的微服务中间件产品，在微服务架构体系中，作为 API 网关以及 API 中间件（kubernetes ingress）提供服务。由于其天生具备 Nginx 的高性能、nginx-lua 插件的可定制性，再加上完善的社区以及齐全的文档，在中小企业用户群非常受欢迎，拥有较好的群众基础。\n2018 年 8 月，kong 发布了 1.0 GA 版本，正式宣布其支持 service mesh，并提供社区版以及企业版 2 个版本。下面我们从 Demo、配置、功能这 3 方面，对 kong mesh 进行体验及分析。\nDemo 体验 Kong 社区提供了 kong mesh 的 demo (https://github.com/Kong/kong-mesh-dist-kubernetes），该 demo 是实现的是 tcp 四层透明代理转发业务。\n该 demo 主要做的事情是：提供两个服务 servicea 以及 serviceb，serviceb 作为服务端，通过 ncat 监听 8080 端口，接受外部的 TCP 消 …","relpermalink":"/blog/kong-mesh-analyse-report/","summary":"本文试用了 kong mesh 并与 istio + envoy 做了功能对比。","title":"Kong mesh 深度分析报告"},{"content":"作者：钟华，腾讯云容器团队高级工程师，热衷于容器、微服务、service mesh、istio 等领域。\n今天分享的内容主要包括以下 4 个话题：\n1 Service Mesh: 下一代微服务 2 Istio: 第二代 Service Mesh 3 Istio 数据面 4 Istio 控制面 首先我会和大家一起过一下 Service Mesh 的发展历程，并看看 Istio 为 Service Mesh 带来了什么，这部分相对比较轻松。接下来我将和大家分析一下 Istio 的主要架构，重点是数据面和控制面的实现，包括 sidecar 的注入，流量拦截，xDS 介绍，Istio 流量模型，分布式跟踪，Mixer 的适配器模型等等，中间也会穿插着 istio 的现场使用 demo.\n1. Service Mesh: 下一代微服务 应用通信模式演进 Service Mesh(服务网格) 的出现 第二代 Service Mesh Service Mesh 的定义 Service Mesh 产品简史 国内 Service Mesh 发展情况 1.1 应用通信模式演进：网络流控进入操作系统 在计算 …","relpermalink":"/blog/istio-the-king-of-service-mesh/","summary":"本文根据钟华在腾讯云容器团队进行的 istio 主题分享和现场演示整理输出。","title":"腾讯云容器团队内部 Istio 专题分享"},{"content":"本文为翻译文章，点击查看原文。\ngRPC-Web作为 gRPC 的 JavaScript 客户端库，使 Web 应用可以不用自定义 HTTP 服务器为中介，直接通过 Envoy 与 gRPC 服务交互。经过了约两年的活跃开发，上周（2018 年 10 月底，译者注）gRPC 团队在 CNCF 博客宣布 gRPC-Web 的 GA 版本正式发布。\n自从在Improbable engineering blog读到了这篇博文，我个人就对 gRPC-Web 很感兴趣。之前一直很看好 gRPC 的性能、可拓展性和 IDL（接口描述语言）驱动的服务交互方式，而且特别想在服务调用链中去掉 REST 部分。我很高兴 gRPC-Web 发布正式版本，它在 Web 开发领域开辟了新的方式。\n我觉得 gRPC-Web 的优势就是自 Web 端向下构建了完整的端到端 gRPC 服务架构。在以前，如果你想让 web 端与 gRPC 服务交互，就必须自己开发 REST 接口处理 HTTP 和 gRPC 之间的转换。而使用 gRPC-Web，我们不再需要自己写额外的 HTTP 接口，可以直接用Protocol …","relpermalink":"/blog/envoy-and-grpc-web-a-fresh-new-alternative-to-rest/","summary":"本文为大家推荐的是一种 REST 的替代方案 Envoy + gRPC-Web。","title":"REST 的替代者：Envoy+gRPC-Web"},{"content":"这不是一篇教程，本文试图带您梳理清楚 Kubernetes、Envoy（xDS 协议）以及 Istio Service Mesh 之间的关系及内在联系。本文介绍了 Kubernetes 中的负载均衡方式，Envoy 的 xDS 协议对于 Service Mesh 的意义以及为什么说有了 Kubernetes 还需要 Istio。\nEnvoy 对于 Service Mesh 或者说 Cloud Native 最大的贡献就是定义了 xDS，Envoy 虽然本质上是一个 proxy，但是它的配置协议被众多开源软件所支持，如 Istio、Linkerd、AWS App Mesh、SOFAMesh 等。\n关于本文标题\n2018 年 9 月 1 日，Bilgin Ibryam 在 InfoQ 发表了一篇文章 Microservices in a Post-Kubernetes Era，中文版见后 Kubernetes 时代的微服务（译文有些错误，仅供参考）。本文标题中虽然没有明确指明”后 Kubernetes 时代的微服务“是什么，但是从文中可以看出作者的观点是：在后 Kubernetes 时代， …","relpermalink":"/blog/service-mesh-the-microservices-in-post-kubernetes-era/","summary":"本文假定您已经对 Kubernetes 有比较全面的了解，同时还使用过 Istio service mesh，但是对于 Kubernetes、Envoy 及 Istio 之间的关系不甚了解，及 Istio 如何使用 xDS 协议控制所有的 Sidecar 有浓厚的兴趣，那么推荐您继续阅读。","title":"Service Mesh——后 Kubernetes 时代的微服务"},{"content":" 崔秀龙，HPE 软件分析师，Kubernetes 权威指南作者之一，Kubernetes、Istio 项目成员。\n本文根据崔秀龙在 2019 广州 Service Mesh Meetup#5 分享整理，完整的分享 PPT 获取方式见文章底部。\n本文内容收录在崔秀龙的新书：《深入浅出 Istio - Service Mesh 快速入门与实践》的第十章，该书将于近期由博文视点出版发行，敬请关注。\nimg Service Mesh 概念在 Linkerd 落地之后，让一直漂浮在空中的微服务治理方案有了一个明确的落地点，给微服务架构的具体实现指出了一个清晰的方向，围绕这一概念逐步开始形成新的技术生态，在业界造成不少震动。这种震动对于企业 IT 转型工作带来的影响，甚至比容器化的影响更加深远。对于承担企业 IT 转型工作的企业服务行业来说，也自然首当其冲感觉到新概念带来的压力。\n企业服务行业和互联网行业相比，业务形态、技术积累和人员结构等方面都大相径庭，举几个常见的差异：\n开发、运维、基础设施所属 人员结构、水平和年龄 资源使用率差别 架构和平台一致性 负载能力 … 目前进行 Service …","relpermalink":"/blog/explore-at-the-edge-of-istio-service-mesh/","summary":"本文根据崔秀龙在 2019 广州 Service Mesh Meetup#5 分享整理。","title":"在网格的边缘试探——企业服务行业如何试水 Istio"},{"content":"写这篇文章原因 所有监控的agent底层最终都是查询的/proc和/sys里的信息推送(如果错了轻喷)，因为在Kubernetes中收集宿主机信息方面也想用pod跑，会面临到问题。\n常见的zabbix_agent默认读取fs的/proc和/sys，容器跑agent会导致读取的不是宿主机的/proc和/sys。\n而 prometheus 的node-exporter有选项--path.procfs和--path.sysfs来指定从这俩选项的值的 proc 和 sys 读取，容器跑node-exporter只需要挂载宿主机的/proc和/sys到容器fs的某个路径挂载属性设置为readonly后用这两个选项指定即可，zabbix4.0看了文档和容器都找不到类似选项应该不支持。\n虽说上 prometheus 但是 Kubernetes 监控这方面，经常看到如下问题：\n如何部署 用 prometheus 的话 pod ip 会变咋整之类的 我的target怎么是0/0 官方 yaml 怎么用 operator 和传统的 prometheus 有啥差异 operator …","relpermalink":"/blog/prometheus-operator-manual/","summary":"Prometheus所有的监控的agent底层最终都是查询的/proc和/sys里的信息推送，本文分享了当收集宿主机信息的agent跑在pod中时会遇到的问题。","title":"全手动部署 prometheus-operator 监控 Kubernetes 集群遇到的坑"},{"content":" 2019 年广州 service mesh meetup 唯品会 Service Mesh 的实践分享 郑德惠 唯品会 Java 资深开发工程师，内部 Service Mesh 框架负责人，唯品会开源项目 vjtools 重要开发者，10 年电信与互联网后台开发经验。\n郑德惠，唯品会 SOFAMosn 持续演进路径及实践案例 陈逸凡 花名无钩，蚂蚁金服资深开发工程师。专注于网络接入层，高性能服务器研发，SOFAMosn 团队核心成员\n陈逸凡，蚂蚁金服 在网格的边缘试探——企业 Istio 试水指南 崔秀龙 HPE 软件分析师，Kubernetes 权威指南作者之一，Kubernetes、Istio 项目成员\n崔秀龙 service mesh Roundtable：回顾 2018，Service Mesh 蓄势待发 陈逸凡、崔秀龙、敖小剑、郑德惠共同参加的圆周讨论环节，共话 service mesh，解答观众现场提问。\n视频回放与资料下载 地址：https://tech.antfin.com/activities/72/review\n致谢 感谢以下单位的大力支持：\n联合主办方蚂蚁金服金 …","relpermalink":"/blog/service-mesh-meetup-guangzhou-20190106/","summary":"ServiceMesher 社区和蚂蚁金服联合主办、SOFAStack 社区协办的第五届 Service Mesh Meetup 广州站收官，唯品会郑德惠、蚂蚁金服陈逸凡、HPE 的崔秀龙给大家带来分享并增加 Roundtable 环节。","title":"第五届 Service Mesh Meetup 广州站回顾"},{"content":"Envoy 是 Istio Service Mesh 中默认的 Sidecar，Istio 在 Enovy 的基础上按照 Envoy 的 xDS 协议扩展了其控制平面，在讲到 Envoy xDS 协议之前还需要我们先熟悉下 Envoy 的基本术语。下面列举了 Envoy 里的基本术语及其数据结构解析，关于 Envoy 的详细介绍请参考 Envoy 官方文档，至于 Envoy 在 Service Mesh（不仅限于 Istio）中是如何作为转发代理工作的请参考网易云刘超的这篇深入解读 Service Mesh 背后的技术细节 以及理解 Istio Service Mesh 中 Envoy 代理 Sidecar 注入及流量劫持，本文引用其中的一些观点，详细内容不再赘述。\nEnvoy proxy 架构图 基本术语 下面是您应该了解的 Enovy 里的基本术语：\nDownstream（下游）：下游主机连接到 Envoy，发送请求并接收响应，即发送请求的主机。 Upstream（上游）：上游主机接收来自 Envoy 的连接和请求，并返回响应，即接受请求的主机。 Listener（监听器）：监听器 …","relpermalink":"/blog/envoy-proxy-config-deep-dive/","summary":"本文介绍了 Envoy proxy 的概念，对应的 xDS 的版本以及配置的详细解析。","title":"Istio 的数据平面 Envoy Proxy 配置详解"},{"content":"讲师与演讲话题 唯品会 Service Mesh 的实践分享 郑德惠 唯品会 Java 资深开发工程师，内部 Service Mesh 框架负责人，唯品会开源项目 vjtools 重要开发者，10 年电信与互联网后台开发经验。\nSOFAMosn 持续演进路径及实践案例 陈逸凡 花名无钩，蚂蚁集团资深开发工程师。专注于网络接入层，高性能服务器研发，SOFAMosn 团队核心成员\n在网格的边缘试探——企业 Istio 试水指南 崔秀龙 HPE 软件分析师，Kubernetes 权威指南作者之一，Kubernetes、Istio 项目成员\nRoundtable：回顾 2018，Service Mesh 蓄势待发 主持人：宋净超，ServiceMesher 社区联合创始人\n","relpermalink":"/event/service-mesh-meetup-05/","summary":"这是第五届 Service Mesh Meetup。","title":"Service Mesh Meetup #5 广州站"},{"content":"笔者 2017 年就曾注意到 solo.io 这家公司，它的创始人 Idit 曾在 KubeCon 上分享过 Squash，去年 11 月推出了 SuperGloo 服务网格编排器再起吸引了我的注意，但最重要的一件事是，Christian Posta 于 2018 年 1 月 3 号宣布加盟 solo.io，这让我很惊讶，我原以为他会加入 T 公司。\nIdit Levine Idit Levine 现为 solo.io 的创始人，这是一个很小的 base 在马塞诸塞州剑桥市的创业公司，这家公司致力于云原生的混合云解决方案。曾是 EMC 云管理部门的 CTO，也是其全球 CTO 办公室的成员，她专注于整个堆栈，微服务，云原生应用和 PaaS 的管理和协调（M＆O）。当她加入 DynamicOps（vCAC，现在是 VMware 的一部分）作为其首批员工之一时，Idit 对云产生了浓厚的兴趣。随后，她参与了 Verizon Terremark 的下一代公有云的开发，并担任 Intigua 的代理 CTO，Intigua 是一家专注于容器和管理技术的创业公司。\nChristian Posta …","relpermalink":"/blog/supergloo-a-service-mesh-orchestrator/","summary":"作为服务网格的编排器，它为用户自由组合任何服务网格开启了方便之门，SuperGloo 也承载着 Solo 这家公司的愿景，混合云环境的云原生应用管理平台。","title":"SuperGloo—服务网格编排平台"},{"content":" 大家好，今天给大家来的演讲专题是“Knative：重新定义 Serverless”, 我是来自蚂蚁金服中间件的敖小剑。\n这是我的个人资料，有兴趣的同学可以关注的我的个人技术博客网站 https://skyao.io。\n这次演讲的内容将会有这些，首先给大家介绍一下 knative 是什么，然后是 knative 的主要组件，让大家对 knative 有一个基本的了解。之后我会简单的对 knative 做一些分析和探讨，以及介绍一下 knative 后续的发展。希望本次的内容让大家能够对 knative 有一个基本的认知。\n什么是 knative？ Knative 是 Google 牵头发起的 serverless 项目。\n这是 Knative 的项目定义，注意这句话里面几个关键字：kubernetes，serverless，workload。\n这是最近几年 Google 做大型项目的常态：产品刚出来，阵营就已经很强大了，所谓先声夺人。\n这是目前 Knative 项目的进展，可以看到这是一个非常新的项目，刚刚起步。\n备注：这是截至 2018-11-24 演讲当天的情况，到 2018 …","relpermalink":"/blog/knative-redefine-serverless/","summary":"本文整理自敖小剑在 2018 年 GIAC 上海站的分享。","title":"Knative：重新定义 serverless"},{"content":"本文以 Istio 官方的 bookinfo 示例来讲解在进入 Pod 的流量被 iptables 转交给 Envoy sidecar 后，Envoy 是如何做路由转发的，详述了 Inbound 和 Outbound 处理过程。关于流量拦截的详细分析请参考理解 Istio Service Mesh 中 Envoy 代理 Sidecar 注入及流量劫持。\n下面是 Istio 官方提供的 bookinfo 的请求流程图，假设 bookinfo 应用的所有服务中没有配置 DestinationRule。\n下面是 Istio 自身组件与 Bookinfo 示例的连接关系图，我们可以看到所有的 HTTP 连接都在 9080 端口监听。\n可以在 Google Drive 上下载原图。\nSidecar 注入及流量劫持步骤概述 下面是从 Sidecar 注入、Pod 启动到 Sidecar proxy 拦截流量及 Envoy 处理路由的步骤概览。\n1. Kubernetes 通过 Admission Controller 自动注入，或者用户使用 istioctl 命令手动注入 sidecar 容器。 …","relpermalink":"/blog/envoy-sidecar-routing-of-istio-service-mesh-deep-dive/","summary":"本文以 Istio 官方的 bookinfo 示例来讲解在进入 Pod 的流量被 iptables 转交给 Envoy sidecar 后，Envoy 是如何做路由转发的，详述了 Inbound 和 Outbound 处理过程。","title":"理解 Istio Service Mesh 中 Envoy Sidecar 代理的路由转发"},{"content":" 本篇主要通过对中国开发者在开源社区中的活动的观察，总结了一些有待提升或者存在弊病的现象。这些现象的背后原因可能是开发者的利益诉求，也可能是公司之间的恶性竞争，不管如何，这些行为或多或少给开源社区技术圈子已经带来了一些影响或冲击，甚至可能影响到了外国开发者对中国开源社区的公共印象。希望随着成熟，这样的现象在未来可以有所改善。\n前几天某开源前端框架的事件闹得沸沸扬扬，尽管负责团队已经给出了诚恳的道歉并承认了过失，但是这次事件对中国开源社区敲响了警钟。在开源社区合作互赢的前提是相互信任相互负责，随着开源的概念深入中国开发者圈子，我们应该反省并从中吸取教训。大如阿里尚且会犯下错误，如果把同样的责任和权力转移给其他中国技术公司的头上，处理的未可能未必会更合理。与此同时，这次事件也让我们看到开源项目在中国的火爆程度，通过Github 全球开发者的账号统计又让我们看到了中国开发者对全球开源社区的力量。甚至在世界已经有了一定的地位，其中尤其以前端项目领先，那么非前端项目呢？\nGithub 全球用户分布 Github 全球用户分布，中国为仅此于美国的第二大用户来源，数据来 …","relpermalink":"/blog/strange-stories-from-chinese-github-participants/","summary":"本文谈论了一些 GitHub 上中式开源的怪象，希望从事开源的读者引以为戒。","title":"Github 中式开源志异"},{"content":" 本文转载自吴伟的博客。\nkubernetes 资源简介 什么是资源？ 在 kubernetes 中，有两个基础但是非常重要的概念：node 和 pod。node 翻译成节点，是对集群资源的抽象；pod 是对容器的封装，是应用运行的实体。node 提供资源，而 pod 使用资源，这里的资源分为计算（cpu、memory、gpu）、存储（disk、ssd）、网络（network bandwidth、ip、ports）。这些资源提供了应用运行的基础，正确理解这些资源以及集群调度如何使用这些资源，对于大规模的 kubernetes 集群来说至关重要，不仅能保证应用的稳定性，也可以提高资源的利用率。\n在这篇文章，我们主要介绍 CPU 和内存这两个重要的资源，它们虽然都属于计算资源，但也有所差距。CPU 可分配的是使用时间，也就是操作系统管理的时间片，每个进程在一定的时间片里运行自己的任务（另外一种方式是绑核，也就是把 CPU 完全分配给某个 pod 使用，但这种方式不够灵活会造成严重的资源浪费，kubernetes 中并没有提供）；而对于内存，系统提供的是内存大小。\nCPU 的使用时间是可压缩 …","relpermalink":"/blog/kubernetes-resource-management/","summary":"本文是关于 Kubernetes 中资源管理的概述。","title":"Kubernetes 资源管理概述"},{"content":" 本文转载自赵化冰的博客。\nIstio 1.0 版本只支持在单个网络，即 Mesh 中的服务只能连接在一个网络上。虽然在架构设计上是开放的，但从目前的代码来看，Istio 的内部实现还是和 Kubernetes 高度集成的。由于 Kubernetes 集群中 Pod 缺省只支持一个网络接口，因此 Istio 也存在该限制并不让人意外。\n随着 Kubernetes 在 NFV（网络功能虚拟化）领域中的逐渐应用，已经出现多个 Kubernetes 的多网络平面解决方案，Istio 也需要考虑支持多网络平面，以为 5G 的微服务化架构提供服务通讯和管控的基础设施。\n什么是多网络平面？ 多网络平面是一个电信行业的常用术语，即将一个电信设备或者系统同时连接到多个网络上。简而言之，就是一个主机上有多个物理或者虚拟的网络接口，这些接口分别连接到不同的网络，这些网络之间一般是相互独立的。由于电信系统对可靠性的要求非常高，因此系统会通过配置多网络平面来避免不同网络流量的相互影响，提高系统的健壮性。\n为什么需要多网络平面？ 但在一些应用场景下，多网络平面是一个必须支持的重要特性。例如在电信系统中，一般都是 …","relpermalink":"/blog/multi-network-interfaces-for-istio/","summary":"随着 Kubernetes 在 NFV（网络功能虚拟化）领域中的逐渐应用，已经出现多个 Kubernetes 的多网络平面解决方案，Istio 也需要考虑支持多网络平面，以为 5G 的微服务化架构提供服务通讯和管控的基础设施。","title":"拥抱 NFV，Istio 1.1 将支持多网络平面"},{"content":"本文介绍了 Istio 和 Kubernetes 中的一些服务和流量的抽象模型。虽然 Istio 一开始确定的抽象模型与对接的底层平台无关，但目前来看基本绑定 Kubernetes，本文仅以 Kubernetes 说明。另外在 ServiceMesher 社区中最近有很多关于 Istio、Envoy、Kubernetes 之中的服务模型关系的讨论，本文作为一个开篇说明，Kubernetes 和 Istio 之间有哪些共有的服务模型，Istio 在 Kubernetes 的服务模型之上又增加了什么。\n**服务具有多个版本。**在 CI/CD 过程中，同一个服务可能同时部署在多个环境中，如开发、生产和测试环境等，这些服务版本不一定具有不同的 API，可能只是一些小的更改导致的迭代版本。在 A/B 测试和灰度发布中经常遇到这种情况。\nKubernetes 与 Istio 中共有的模型 因为 Istio 基本就是绑定在 Kubernetes 上，下面是我们熟知的 Kubernetes 及 Istio 中共有的服务模型。\n上图是 Kubernetes 中 iptables 代理模式（ …","relpermalink":"/blog/istio-service-and-traffic-model/","summary":"本文介绍了 Kubernetes、Envoy 和 Istio 中流量管理的一些服务模型以及为什么说 Kubernetes service 存在的意义仅剩下做服务发现。","title":"Istio 中的服务和流量的抽象模型"},{"content":" 本文作者：吴伟，蚂蚁金服系统部技术专家，本文转载自其博客。\nknative 是谷歌开源的 serverless 架构方案，旨在提供一套简单易用的 serverless 方案，把 serverless 标准化。目前参与的公司主要是 Google、Pivotal、IBM、Red Hat，2018 年 7 月 24 日才刚刚对外发布，当前还处于快速发展的阶段。\n这是 Google Cloud Platform 宣布 knative 时给出的介绍：\nDeveloped in close partnership with Pivotal, IBM, Red Hat, and SAP, Knative pushes Kubernetes-based computing forward by providing the building blocks you need to build and deploy modern, container-based serverless applications.\n可以看出，knative 是为了解决容器为核心的 serverless 应用的构建、部署和运行 …","relpermalink":"/blog/knative-serverless-platform/","summary":"本文是对 Google 开源的 serverless 计算平台 knative 的介绍。","title":"Serverless 平台 knative 简介"},{"content":"SOFAMosn 几个月前由蚂蚁金服开源，使用 Go 语言实现，遵循 Envoy xDS 协议，既可以单独作为网络代理使用，也可以作为 Istio/SOFAMesh 中的数据平面 Sidecar 代理。开源地址：https://github.com/alipay/sofa-mosn\nHTTP 协议优化 性能优化：HTTP/1.x 性能提升 30%，HTTP/2.0 性能提升 100% IO、流处理接入 MOSN 自研框架，统一架构，并支持 metrics 收集等基础能力 支持HTTP/1.x、HTTP/2.0协议自动识别 支持 GRPC 流量路由 \u0026amp; 管理 完善故障注入机制，支持基于路由匹配、后端匹配的延迟、错误响应异常注入 支持 HTTP 请求 direct response 路由机制 支持对 HTTP 请求添加自定义 Headers，支持删除指定 Headers 支持重写 HTTP 请求中 Host、URI 支持基于计数的失败重试机制 支持基于 QPS、基于速率限流 完善 TCP 转发功能，支持灵活的转发特性配置 遥感 支持对接Mixer上报请求/响应的基本信息 扩展性 重构、优化 …","relpermalink":"/blog/sofa-mosn-0-4-0-changelog/","summary":"本文是蚂蚁金服开源的 SOFAMosn 的 0.4.0 版本的发布日志。","title":"蚂蚁金服开源的 Service Mesh Sidecar 代理 SOFAMosn 发布 0.4.0 版本"},{"content":"本文为翻译文章，点击查看原文。\n在过去几年中，我们注意到应用程序架构正在迅速转变为分布式微服务架构——单体和庞大的应用程序被分解为更小的单个服务，其可被独立修改、构建、部署和管理。这种模式的主要优点就是简洁和快速，同时由于其对其他服务的依赖性很小或者完全没有依赖，更易于升级和独立扩展。这与敏捷和 DevOps 理念非常吻合，这种模式也已经被许多规模化的 Web 公司成功采用。过去的许多年中，这些公司中的大多数都能够很好地采用这种模式，但是近几年中成功将这种模式发扬光大的两大推手非 Docker 和 Kubernetes 莫属。Docker 简化了将微服务构建为 Linux 容器的过程，Kubernetes 则能够以资源优化的方式来部署、管理和扩展服务。\n应用架构演进 在这篇博客中，我们不会花太多时间讨论微服务架构的优缺点。相反，我们将专注于在向基于微服务构建的云原生架构的重大转变上。\n虽然微服务架构提供了灵活性，但其也带有复杂性。Kubernetes 在部署和管理微服务方面发挥了非常重要的作用，但我们需要的不仅仅是单一的运行在生产环境中的云原生应用程序——还需要在服务发现、安全性、流量 …","relpermalink":"/blog/from-fragmented-microservices-ecosystem-to-service-mesh/","summary":"本文中概述了应用架构的演进及微服务生态是如何演化到服务网格的。","title":"微服务生态从百家争鸣阶段演化到服务网格"},{"content":"本文首先向你简单介绍了 Kubernetes，然后教你从零开始构建一个 Kubernetes CRD。如果你已经对 Kubernetes 十分了解的话可以跳过本文前半部分的 Kubernetes 介绍，直接从 Controller 部分开始阅读。\n快速入门 Kubernetes Kubernetes 是一个容器管理系统。\n具体功能：\n基于容器的应用部署、维护和滚动升级 负载均衡和服务发现 跨机器和跨地区的集群调度 自动伸缩 无状态服务和有状态服务 广泛的 Volume 支持 插件机制保证扩展性 通过阅读Kubernetes 指南和Kubernetes HandBook以及官方文档 或者 阅读 Kubernetes 权威指南可以获得更好的学习体验。\n在开始安装 Kubernetes 之前，我们需要知道：\n1、Docker 与 Kubernetes Docker 是一个容器运行时的实现，Kubernetes 依赖于某种容器运行时的实现。\n2、Pod Kubernetes 中最基本的调度单位是 Pod，Pod 从属于 Node（物理机或虚拟机），Pod 中可以运行多个 Docker 容器，会 …","relpermalink":"/blog/kubernetes-crd-quick-start/","summary":"本文首先向你简单介绍了 Kubernetes，然后教你从零开始构建一个 Kubernetes CRD。","title":"如何从零开始编写一个 Kubernetes CRD"},{"content":"如果你是初次接触服务网格和 Envoy，我这里有一篇文章可以帮助你入门。\n在微服务架构中，可观测性变得越加重要。我认为这是选择微服务这条路的必要条件之一。我的一位前同事列出了一份非常棒的需求清单，如果你想做微服务，那么你需要满足提到的这些要求。\n可观测性有许多事要做：\n监控 报警 日志集中化 分布式追踪 本文只讨论 Envoy 下的分布式追踪，我尽量给出一个全貌来描述分布式追踪、OpenTracing、Envoy 和 Jaeger 是如何整合在一起工作的。在下一篇文章中，我们将讨论使用 Envoy、prometheus 和 grafana 做监控。\n分布式追踪 随着大量的服务和请求的流转，你需要能够快速发现哪里出了问题。分布式追踪最早由谷歌的 Dapper普及开来，它本质上具有在微服务的整个生命周期中追踪请求的能力。\n最简单的实现方法是在前端代理生成一个唯一的请求 id（x-request-id），并将该请求 id 传递给与其交互的所有服务。基本上可以向所有的日志追加这一请求 id。因此，如果你在 kibana 这样的系统中搜索唯一 id，你会看到针对该特定请求的所有相关的日志。\n这非 …","relpermalink":"/blog/distributed-tracing-with-envoy-service-mesh-jaeger/","summary":"本文用实例讲解了如何利用 Envoy 和 Jaeger 实现分布式追踪。","title":"使用 Envoy 和 Jaeger 实现分布式追踪"},{"content":"gRPC-Web使 Web 应用能够通过类似于 Envoy 的代理访问 gRPC 后端。Envoy 是 Istio 的默认代理，因此，我们可以利用 Istio 的EnvoyFilter构件来创建无缝连接的云原生应用。\ngrpc istio 介绍 在这篇文章中，我将引导你构建一个简单的 Web 应用，使用 emoji 替换用户输入文本中的关键字，并使用 gRPC-Web 和 Istio 与 gRPC 后端进行通信。\n以下是我们创建 emoji 应用的步骤大纲：\n使用Protobuf定义协议格式； 编译 Protobuf 定义文件，来生成 Go 和 JavaScript 文件； 构建并测试基于 Go 的 gRPC 服务，该服务使用 emoji 替换输入文本中的关键字； 使用 gRPC-Web 为 emoji 服务创建 Web 界面； 配置 EnvoyFilter 并通过 Istio 部署后端； 部署 Web 应用程序并测试我们的 emoji 服务。 架构 让我们进一步理解 emoji 服务的最终架构是什么样子。\narchitecture 简而言之，只要用户提供一些文本，Web …","relpermalink":"/blog/seamless-cloud-native-apps-with-grpc-web-and-istio/","summary":"本文构建了一个简单的 Web 应用，该应用使用 emoji 替换用户输入文本中的关键字，并使用 gRPC-Web 和 Istio 与 gRPC 后端进行通信。","title":"构建无缝集成的 gRPC-Web 和 Istio 的云原生应用教程"},{"content":"这是我在Envoy架构系列中的第 3 篇文章。这篇文章基于以前关于 Envoy 的线程模型和热重启功能的帖子。如果您还没有阅读这些帖子，请先阅读。需要指出的是，随着预演的结束，我们现在可以进入更有趣的话题！\n统计概述 到目前为止，Envoy 所做的最重要的事情是为分布式系统的可观测性提供了一个健壮的平台。这包括统计数据、日志记录和分布式跟踪。这篇文章将集中在统计数据和 Envoy 是如何实现允许高容量的同时保持卓越性能的。Envoy 目前支持三种不同的统计数据：\nCounter（计数器）：只能增加不会减少的无符号整数。例如，总请求。 Gauge（计量）：可以同时增加和减少的无符号整数。例如，目前有效的请求。 Timer/hitogram（计时器/直方图）：无符号整数，最终将产生汇总百分位值。Envoy 不区分计时器（通常以毫秒为单位）和原始直方图（可以是任何单位）。例如，上游请求时间（以毫秒为单位）。 Envoy 目前不支持任何浮点统计数据。\nEnvoy 生成很多对调试分布式系统有用的数据！ ## 统计子系统目标 Envoy 统计子系统的总体目标如下：\n粗略的线性吞吐量：可以与任意数量 …","relpermalink":"/blog/envoy-stats/","summary":"本文讲述了 Envoy 数据统计系统的设计及实现原理。","title":"Envoy 中的数据统计"},{"content":" 朵晓东，花名奕杉，蚂蚁金服高级技术专家。专注企业云计算技术及产品，蚂蚁金融云 PaaS 创始团队核心成员，Antstack 网络产品负责人。开源爱好者，Apache Kylin 创始团队核心成员；SOFAMesh 创始团队核心成员，SOFAMosn 项目负责人。\n本文根据晓东在 GIAC 上海站的演讲内容整理，完整的分享 PPT 获取方式见文章底部。\nimage.png | left | 720x481.1881188118812 大家好，我是蚂蚁金服系统部的高级技术专家奕杉，今天分享的内容是：《蚂蚁金服在 ServiceMesh 推进落地过程中对新型网络代理的思考和实践》\n内容结构： 主要的分享顺序：\n背景概述 架构设计及功能特性 技术案例 总结展望 1、背景、概览： image | left ServiceMesh 作为云原生之上的服务网格技术在今年引起了业界的广泛关注，首先我们来看一下目前 ServiceMesh 数据平面的一些方案。\n最为大家熟知的是老牌七层代理 Nginx 和 ISTIO 原生的数据平面 Envoy。Nginx 早已在国内外广泛使用， …","relpermalink":"/blog/microservice-with-service-mesh-at-ant-financial/","summary":"本文根据晓东在 GIAC 上海站的演讲内容整理，完整的分享 PPT 获取方式见文章底部。","title":"蚂蚁金服 Service Mesh 新型网络代理的思考与实践"},{"content":" Jenkins x 本文为翻译文章，点击查看原文。\nJenkins 服务来源于创建自 2004 年的 Hudson。在软件行业中，Jenkins 已经是家喻户晓的明星产品，并且已经是 CI 和 CD 的领头羊。到目前为止有超过 2050 万的 Jenkins 任务，以及将近 20 万的 Jenkins 服务在运行中。这真的是非常惊人的增长速度。\njenkins 的增长变化图 上面的增长图说明在技术领域已经有很大的进步，列如云计算和容器，这些变化说明 Jenkins 在很多方面已经起到了很好的作用，我们应该很好的利用这些影响力。如今，很多公司都开始进行容器化改造，我们希望 jenkins 能跟上时代的步伐，开始自己的云原生之路。Jenkins 应当继续成长，提供更多大家需要的自动化，可靠性，以及更好的开发体验。\nJenkins 在取得巨大成功的同时，也产生了一些问题。\n下面让我们来简要描述一些我们了解到的比较重要的问题。\nJenkins 服务的单点问题。特别是在服务维护期间，git webhook 的操作都会被丢失。 Jenkins 服务经常将磁盘跑满，需要脚本或者人工清理之后，才能继 …","relpermalink":"/blog/serverless-jenkins-with-jenkins-x/","summary":"本文主要介绍了 serverless Jenkins 起源和基本使用，Jenkins X 是可供团队使用的一站式服务，可用来进行 Prow ChatOps 编排静态、无服务器或 Knative 构建作业，其中包括用于 Kubernetes 工作负载的自动化 CI/CD 以及更多自动化。","title":"Serverless Jenkins 和 Jenkins X"},{"content":" 大家好，今天给大家带来的演讲主题是“蚂蚁金服 Service Mesh 渐进式迁移方案”，给大家介绍一下我们蚂蚁金服主站的 Service Mesh 迁移方案，在稍后的内容中我会给大家解释什么是“渐进式”。今天的演讲方式有些特殊，将会是两位讲师合作。我是敖小剑，来自蚂蚁金服中间件团队，另外一位讲师 龙轼，来自 UC 基础研发部。\n今天的内容将会有四块主要内容：\nService Mesh 演进路线：介绍蚂蚁金服计划在主站落地 Service Mesh 的方案，由于涉及到大量的存量应用和超大规模，又要保证迁移过程的平滑，因此我们的落地方案相比社区方案要复杂的多。 实现平滑迁移的关键：介绍在整个迁移方案中，为了实现平滑迁移的几个关键做法，然后今天我们将详细展开其他的一个关键点：DNS 寻址方案。 DNS 寻址方案的演进：详细介绍 Kubernetes/Istio/SOFAMesh 一路演进过来的 DNS 寻址方式 DNS 寻址方案的后续规划：介绍我们在 DNS 寻址方案上的后续规划 前两块内容将由我来为大家介绍，后两块内容将由我的同事 龙轼 为大家介绍。\n在展开内容之前，先看一下背 …","relpermalink":"/blog/ant-financial-service-mesh-adoption-plan/","summary":"本文是上周末 Service Mesh Meetup 上海站的演讲内容，前面一半内容来自蚂蚁金服的敖小剑，后一半来自阿里 UC 的龙轼。","title":"蚂蚁金服 Service Mesh 渐进式迁移方案"},{"content":" 一直想给我所从事的企业服务行业写点啥，又千头万绪不知从何说起。此次 KubeCon 上海一行，眼见 CNCF 高起朱楼大宴宾客，深受触动。企业服务这个巨大的“角落”，似乎已被遗忘。本文尝试给云原生时代的同学们讲讲这个似乎有点蒙昧的角落。也希望能给奋斗在企业服务项目中的朋友们一点启发。\n谁是隐形人 身为一个企业服务部门的 IT 工人，在为甲方殚精竭虑的同时，经常有一种跟世界脱节的感觉：流量经济持续不断的冲刷之下，微服务、云原生等新的架构和概念如火如荼；大咖说、InfoQ 等各色机构的活动也是越来越多；新技术产品和新技术偶像层出不穷。云原生时代以来，更大的困扰出现了：漫山遍野的“免费”、“开源”技术，似乎难于学习、无力推进、更不要说做出贡献了。\n各种困境各种难，让这一人群成为了一种隐身的状态：大会的讲台上下、热门的书籍和公众号、开源社区的贡献和参与统统都和他们毫无瓜葛，似乎只剩下了偶尔出现的产业新闻和咨询案例，才能提供一个“可能还在做技术”的证明。隐形人的一些生存特点：\n产品一般称为“XXXX 管理系统”。 在甲方自有数据中心或托管服务器上运行。 硬件利用率不高，相对硬件规模来说，业务规 …","relpermalink":"/blog/invisible-men-in-the-world-of-cloudnative/","summary":"一直想给我所从事的企业服务行业写点啥，又千头万绪不知从何说起。此次 KubeCon 上海一行，眼见 CNCF 高起朱楼大宴宾客，深受触动。企业服务这个巨大的“角落”，似乎已被遗忘。本文尝试给云原生时代的同学们讲讲这个似乎有点蒙昧的角落。也希望能给奋斗在企业服务项目中的朋友们一点启发。","title":"云原生世界中的隐形人如何拥抱 Istio"},{"content":"本文为翻译文章，点击查看原文。\n在我的上一篇博客中，我谈到了微服务的设计模式。现在我想更深入地探讨微服务架构中最重要的模式：微服务之间的相互通信。我仍然记得我们过去开发单一应用时通讯是一项艰巨的任务。在那时我们必须小心的设计数据库表和对象模型映射之间的关系。而现在在微服务中，我们已经将它们分解为独立的服务，并创建网格来彼此通信。让我们来谈谈迄今为止为解决这个问题而发展起来的所有通信方式和模式。\n许多架构师已经将微服务之间的通信划分为同步和异步两种模式。让我们一个一个来介绍。\n同步模式 当我们说到同步时，意思是客户端向服务端发出请求并等待其响应。线程将被阻塞，直到它接收到返回。实现同步通信最主要的协议是 HTTP。HTTP 可以通过 REST 或 SOAP 实现。现在 REST 在微服务方面发展迅速并超越了 SOAP。对我而言两者都很好用。\n现在让我们讨论同步模式中的不同的工作流、用例，我们面临的问题以及如何去解决。\n先从一个简单的例子开始。你需要一个服务 A 来调用服务 B 并等待实时数据的响应。这是实现同步的一个很好的选择，因为不会涉及到下游服务。如果使用多个实例，除了负载均衡之外， …","relpermalink":"/blog/design-patterns-for-microservice-communication/","summary":"本文详细的介绍了同步和异步模式下微服务间的通信模式。","title":"微服务通信的设计模式"},{"content":"Service Mesh被用作微服务的基础设施层，使通信变得更加灵活，可靠和快速。它得到了谷歌、微软、IBM、红帽和 Pivotal 等行业巨头的推动，并且正在推出 Kubernetes、OpenShift 和 Pivotal Container Service（PKS）等平台和服务。\n虽然 Service Mesh（服务网格）可以很好地支持同步 RESTful 和一般的\u0026lt;请求 - 回复\u0026gt;交互，但它不支持异步、事件驱动的交互，不适合将云原生微服务与遗留应用程序连接，也不适用于 IoT。\n现代企业正在将事件驱动架构作为其数字化转型的一部分，每个事件驱动型的企业都需要一个中枢神经系统来快速、可靠和安全地将事件从它们发生的地方发送到它们需要去的地方。\n这个中枢神经系统可以被视为 Event Mesh（事件网格） - 您架构中的一个新层。\n事件网格作为服务网格的补充，可以做为应用程序的连接层，以提供企业实现其数字化转型目标所需的全套应用程序间通信模式。\n什么是 Event Mesh？ 事件网格对于事件驱动的应用程序，就好比是服务网格对于 RESTful 应用程序：一个架构层，无论在哪里部署这些 …","relpermalink":"/blog/service-mesh-meet-event-mesh/","summary":"本文主要介绍了 Event Mesh 是什么，Event-Driven 型企业为什么需要 Event Mesh 层。","title":"当 Service Mesh 遇见 Event Mesh: Event-Driven 型企业新的架构层"},{"content":"本文为翻译文章，点击查看原文。\n在这个令人惊奇的时代，我们可以不需要编写一行代码，便可以很智能的集成应用程序，收集应用程序指标。\n在这篇文章中，我将演示使用 helm 安装 Istio mtls 环境、必要的 yamls 配置以及安装 Istio 带来的其他收获。另外，在文章最后，我还会展示路由配置的一些例子。\n假设你已经安装好 Kubernetes 和 helm，并且对他们都有一定的了解。本教程将以 AWS 作为我们的运行环境。请参考官方安装文档：\nhttps://istio.io/docs/setup/kubernetes/helm-install/\n以下是 Istio 的官方拓扑图：\n通过我们的设置，所有的容器会连同一个 istio-proxy 一起创建并部署到 istio-injected 的命名空间中。应用程序将与 istio-proxy (envoy) 进行通信，然后后者将处理所有的链接、mtls 以及其他应用程序的负载均衡。\n安装以及配置 开始步骤，下载并解压 istio-1.0.0 安装包\nwget …","relpermalink":"/blog/istio-envoy-grpc-metrics-winning-with-service-mesh-in-practice/","summary":"本文展示的是如何使用 Istio 和 Envoy 来对 gRPC 做度量。","title":"使用 Istio 和 Envoy 实践服务网格 gRPC 度量"},{"content":"本文为翻译文章，点击查看原文。\n当学习像Istio这样的新技术时，我推荐看一看项目自带的示例。Istio 包含了一些示例程序，但都有各种各样的不足。比如说BookInfo就是很好的一个应用。但是对我来说，它太冗长，服务太多，而且文档似乎专注于管理 BookInfo 应用程序，而不是从头构建。另外还有一个小一点的示例-helloworld，但是它仅关注于自动伸缩。\n在这篇文章中，我想从基础讲起，并向您展示如何从头开始构建支持 Istio 的“HelloWorld”应用程序。要记住的一点是，Istio 只管理您应用的流量，应用程序生命周期由底层平台 Kubernetes 管理。因此，您需要了解容器和 Kubernetes 基础知识，并且需要了解 Istio 路由原语，例如 Gateway，VirtualService，DestinationRule。我假设大多数人都知道容器和 Kubernetes 基础知识。我将在本文中专注于介绍 Istio 路由。\n基本步骤 这些大致是创建 Istio“HelloWorld”应用程序的步骤：\n创建一个 Kubernetes …","relpermalink":"/blog/istio-routing-basics/","summary":"本文展示了如何从头开始构建 Istio 应用程序和 Istio 路由的基础知识。","title":"Istio 路由基础"},{"content":" Observability and Istio telemetry 吴晟 Apache SkyWalking 创始人、Apache Sharding-Sphere 原型作者、比特大陆资深技术专家、CNCF OpenTracing 标准化委员会成员\n蚂蚁金服 Service Mesh 渐进式迁移方案 敖小剑 蚂蚁金服高级技术专家，十六年软件开发经验，微服务专家，Service Mesh 布道师，Servicemesher 社区联合创始人\n张瑜标 阿里巴巴技术专家、前京东 Hadoop 负责人、Hadoop 代码贡献者、现负责 UC 基于 Kubernetes 自研的 PaaS 平台整体的稳定性\n探讨和实践基于 Istio 的微服务治理事件监控 徐运元 谐云科技云平台架构师，致力于容器 PaaS 平台、企业级容器云平台的方案设计和技术落地\nEnvoy、Contour 与 Kubernetes 实践 冯玮 七牛容器云平台产品架构师，曾在百度和华为从事公有云领域高性能分布式计算和存储平台的架构设计和产品研发\n视频回放与资料下载 地 …","relpermalink":"/blog/service-mesh-meetup-shanghai-20181125/","summary":"ServiceMesher 社区和蚂蚁金服联合主办、SOFAStack 社区协办的第四届 Service Mesh Meetup 上海站收官，Apache Skywalking 创始人吴晟、蚂蚁金服敖小剑、阿里巴巴 UC 张瑜标 (龙轼)、谐云科技徐运元、七牛云的冯玮给大家带来分享。","title":"第四届 Service Mesh Meetup 上海站回顾"},{"content":"讲师与演讲话题 Observability and Istio telemetry 吴晟 Apache SkyWalking 创始人、Apache Sharding-Sphere 原型作者、比特大陆资深技术专家、CNCF OpenTracing 标准化委员会成员\n蚂蚁集团 Service Mesh 渐进式迁移方案 敖小剑 蚂蚁集团高级技术专家，十六年软件开发经验，微服务专家，Service Mesh 布道师，Servicemesher 社区联合创始人\n张瑜标 阿里巴巴技术专家、前京东 Hadoop 负责人、Hadoop 代码贡献者、现负责 UC 基于 Kubernetes 自研的 PaaS 平台整体的稳定性\n探讨和实践基于 Isito 的微服务治理事件监控 徐运元 谐云科技云平台架构师，致力于容器 PaaS 平台、企业级容器云平台的方案设计和技术落地\nEnvoy、Contour 与 Kubernetes 实践 冯玮 七牛容器云平台产品架构师，曾在百度和华为从事公有云领域高性能分布式计算和存储平台的架构设计和产品研发\n","relpermalink":"/event/service-mesh-meetup-04/","summary":"这是第四届 Service Mesh Meetup。","title":"Service Mesh Meetup #4 上海站"},{"content":"本文为翻译文章，点击查看原文。\n本文将简单的讨论下我们经常听到的“Service Mesh”是什么，以及如何使用“Envoy”构建服务网格 (Service Mesh)。\n什么是 Service Mesh? Service Mesh 可以比作是微服务结构中的通信层。每个服务之间来往\b的所有请求都将通过网格。每个服务都有自己的代理服务，所有这些代理服务共同组成了“服务网格”(Service Mesh)。所以假如一个服务想要和另一个服务通信，他不是直接和这个目标服务通信的，他会先把请求路由给自己本地的代理，再由代理把请求路由到目标服务。从本质上讲，每个服务实例都只知道自己本地的代理，并不知道外面世界是什么样的。\n当你在谈论“Service Mesh”的时候，你肯定也会听到“Sidecar”这个词，“SideCar”就是用于每个服务实例中的代理，每个“SideCar”负责一个服务中的一个实例。\nService Mesh 能带来什么？ 服务发现 可观测性（Metrics） 限速 熔断 流量迁移 负载均衡 认证与授权 分布式追踪 Envoy Envoy 是一个用 C++ 编写的高性能代理。绝不是 …","relpermalink":"/blog/service-mesh-with-envoy-101/","summary":"本文将简单的讨论下我们经常听到的 Service Mesh 是什么，以及如何使用 Envoy 构建服务网格 (Service Mesh),使用速率限制服务来减轻客户端对 API 资源的消耗。","title":"使用 Envoy 搭建 Service Mesh"},{"content":"本文为翻译文章，点击查看原文。\n大家好！我在 Istio 上做了一些实验，禁用控制平面的组件，并观察应用和服务网格会发生什么。下面是我的笔记。\nPilot Pilot 负责 Istio 的流量控制特性，同时将 Sidecar 更新至最新的网格配置。\nPilot 启动以后，监听端口 15010 （gRPC）和 8080 （HTTP）。\n当应用的 Sidecar（Envoy，Istio-Proxy）启动以后，它将会连接 pilot.istio-system:15010 ，获取初始配置，并保持长连接。\nPilot 会监听 Kubernetes 资源，只要检测到网格发生变化，就会将最新的配置通过 gRPC 连接推送到 Sidecar 上。\n当 Pilot 停止以后，Pilot 和 Sidecar 之间的 gRPC 连接被关闭，同时 Sidecar 会一直尝试重连。 网络流量不会受到 Pilot 停止的影响，因为所有的配置被推送过来以后，就会存储在 Sidecar 的内存中。 网格中新的变更信息（例如新的 Pod、规则、服务等等）不会继续到达 Sidecar，因为 Pilot 不再监听这些变化并 …","relpermalink":"/blog/istio-what-happens-when-control-plane-is-down/","summary":"本文展示了当 Istio 控制平面的组件出现故障以后会发生什么现象。","title":"Istio 控制平面故障后会发生什么？"},{"content":" “它是一只鸟，它是一架飞机，它是超级……”。不，等等，它是 Istio！即使你眯着眼睛，也能够看出来！什么是 Istio？超级英雄有各种形状和大小！今天，在微服务架构中，Kubernetes 是超人。它很容易被认出来，它是当今最强大的云（和本地）超级英雄：刀枪不入，飞来飞去，总是随叫随到，安全，值得信赖…\n正如电影《蚁人 2：黄蜂女现身》，我想谈谈微服务架构中最小的超级英雄，被称为 Istio！Istio 拥有超级英雄的一些最佳品质，混乱必定被遏制，并保卫银河系的正常秩序。\n在漫画的世界中，最小的超级英雄可以说是 Ant-Man。在微服务的世界中，它绝对是 Istio，就像 Ant-Man 一样，Istio 小巧，快速，灵活，强大。超人和 Kubernetes 非常适合解决大问题，但在狭小的空间里它们反而显得很笨拙并且很慢。Ant-Man 和 Istio 则在这些环境中表现出色，事实上，它们正是出于这个原因而设计的（关注点分离 SOC）。\nIstio - 微服务部署的小英雄 - 就像 Ant-Man（图像链接）\nIstio 提供统一方法来管理，保护和监控微服务。我们之前听过这个，对 …","relpermalink":"/blog/istio-is-it-a-bird-microgateway-blog-series-part-4/","summary":"本文讲述 Istio 强大的功能以及 Istio 组件介绍。","title":"Istio 像鸟一样轻盈？微网关博客系列（4）"},{"content":"本文为翻译文章，点击查看原文。\n试用 gRPC 构建服务时要在.proto 文件中定义消息（message）和服务（service）。gRPC 支持多种语言自动生成客户端、服务端和 DTO 实现。在读完这篇文章后，你将了解到使用 Envoy 作为转码代理，使 gRPC API也可以通过HTTP/JSON的方式访问。你可以通过github代码库中的Java代码来测试它。有关gRPC的介绍请参阅blog.jdriven.com/2018/10/grpc-as-an-alternative-to-rest/。\n为什么要对 gRPC 服务进行转码？ 一旦有了一个可用的 gRPC 服务，可以通过向服务添加一些额外的注解（annotation）将其作为 HTTP/JSON API 发布。你需要一个代理来转换 HTTP/JSON 调用并将其传递给 gRPC 服务。我们称这个过程为转码。然后你的服务就可以通过 gRPC 和 HTTP/JSON 访问。大多数时候我更倾向使用 gRPC，因为使用遵循“契约”生成的类型安全的代码更方便、更安全，但有时转码也很有用：\nweb应用程序可以通过HTTP/JSON调 …","relpermalink":"/blog/transcoding-grpc-to-http-json-using-envoy/","summary":"本文用实例讲解了如何利用Envoy将gRPC转码为HTTP/JSON。","title":"使用Envoy将gRPC转码为HTTP/JSON"},{"content":"本文为翻译文章，点击查看原文。\n如果你刚接触“Service Mesh“和“Envoy”，我这里有一篇文章可以帮你入门。\n这是Envoy service mesh 下的可观测性系列的第二篇文章，你可以在这里阅读第一篇关于分布式追踪的文章。\n在微服务中谈及监控时，你可不能被蒙在鼓里，至少要知道问题出在哪儿了。\n让我们看看 Envoy 是怎样帮助我们了解我们的服务运行状况的。在 service mesh 下，所有的通信都会通过 mesh，这意味着没有任何服务会与其它服务直接通信，服务向 Envoy 发起调用请求，然后 Envoy 将调用请求路由到目标服务，所以 Envoy 将持有传入和传出流量的上下文。Envoy 通常提供关于传入请求、传出请求和Envoy 实例状态的指标。\n准备 这是我们将要构建的系统概览。\noverall setup Statsd Envoy 支持通过两到三种格式来暴露指标，但本文中我们将使用statsd格式。\n所以流程将是这样，首先 Envoy 推送指标到 statsd，然后我们用prometheus（一个时序数据库）从 statsd 拉取指标，最后通过grafana …","relpermalink":"/blog/microservices-monitoring-with-envoy-service-mesh-prometheus-grafana/","summary":"本文介绍了 Envoy service mesh 下结合 Prometheus 和 Grafana 实现的微服务监控方案。","title":"Envoy service mesh、Prometheus 和 Grafana 下的微服务监控"},{"content":"本文为翻译文章，点击查看原文。\nEnvoy是专为 Cloud Native 应用设计的轻量级服务代理，也是为数不多的支持gRPC的代理之一。gRPC 是一个基于HTTP/2的高性能 RPC（远程过程调用）框架，支持多种语言。\nEnvoy 在这篇文章中，我们将使用 gRPC 和Protocol Buffers构建 C++语言版本的Greeter 应用，使用Go语言构建另一个 gRPC 应用，实现 Envoy 的RateLimitService接口。最后，将 Envoy 部署为 Greeter 应用的代理，使用我们的速率限制服务实现反压机制（backpressure）。\ngRPC Greeter 应用 我们首先安装gRPC和Protobuf，然后构建 C++语言版本的 Greeter 应用。您还可以通过选择文档中列出的其他语言来构建此应用程序; 但是，我将在本文中使用 C++。\n以下是 Greeter 应用的示意图。\nGreeter 运行 Greeter 应用时，终端中会有以下输出：\n$ ./greeter_server Server listening on 0.0.0.0:50051 …","relpermalink":"/blog/envoy-grpc-and-rate-limiting/","summary":"本文使用 C++构建了客户端/服务端应用，通过 Envoy 代理和 gPRC 协议进行通信，然后使用 Go 语言实现了 Envoy 速率限制服务。","title":"Envoy，gRPC 和速率限制"},{"content":"本文为翻译文章，点击查看原文。\n除非你长期与世隔绝，否则你应该听说过 Kubernetes，他已经称为高速发展的互联网公司的一条准则。最近又有一个热门话题–Service Mesh（服务网格），它已经被这些高速发展公司用来解决一些特定的问题。所以如果你想了解什么是 Service Mesh，接下来我可以给你一个更好的解释。\n互联网应用的演进 为了理解 Sevice Mesh 的重要性，我们通过四个阶段来简短的回顾下互联网应用的发展历程。\n阶段 0：单体应用 还记得那些年吗？所有的代码库都打包成一个可执行和部署的软件包。当然，至今在某些使用场景下这个方式依然是很管用的。但是对于一些业务快速增长的互联网公司，在应用的可扩展性、快速部署和所有权等方面遇到了阻力。\n阶段 1：微服务 微服务的思思想很简单，依照 SLA（服务等级协议）将单体应用拆分成多个模块。这种方式运行效果显著，所以广泛为企业所接受。现在，每个团队都用他们喜爱的语言、框架等自由地设计他们的微服务。然后它开始看起来就像下面这样。\n我们曾经在我的一个项目中开玩笑说，那里有各种语言的微服务:)\n尽管微服务解决了单体应用的一些问题，但 …","relpermalink":"/blog/why-is-service-mesh/","summary":"本文讲述互联网应用演进过程，Service Mesh 能带来什么好处","title":"为什么要选择 Service Mesh？"},{"content":" 本文为翻译文章，点击查看原文。\nRancher 1.6 和 Rancher 2.0 底层容器编排引擎的术语和概念略微有所不同。想要了解这些差异就需要先了解 Cattle 和 Kubernetes 之间的根本区别。对于使用过 Cattle 或者 Kubernetes 的新手来说，这篇文章比较适合您。同时你也可以从这里获取到容器编排引擎 Cattle 到 Kubernetes 的对应关系词汇表 cheatsheet。\n无服务器 kubernetes\n在 Pokemon Go 的早期，我们都惊讶于 Niantic 如何在全球范围内扩展其用户群，现在看来他们应该是以无缝地向其容器集群添加额外的节点以容纳更多的玩家和环境，所有这一切都可以通过使用 Kubernetes 作为容器编排工具来实现。Kubernetes 在扩展和管理容器基础架构中，能够从开发者角度抽象出部分过程和低级依赖关系。这使它成为一个非常有效的平台，用于开发和维护跨多个容器的应用程序服务。本文将探讨如何利用 K8S 的设计参数和服务编排功能，并将它们与无服务器框架和函数即服务（FaaS）结合起来。特别是，我们将深入研究其特性和 …","relpermalink":"/blog/evaluation-of-serverless-frameworks-for-kbe/","summary":"本文讲解了如何利用 K8S 的设计参数和服务编排功能，并将它们与无服务器框架和函数即服务（FaaS）结合起来。","title":"Kubernetes 的无服务器框架的评估"},{"content":"Cilium 是一个纯开源软件，没有哪家公司提供商业化支持，也不是由某一公司开源，该软件用于透明地保护使用 Linux 容器管理平台（如 Docker 和 Kubernetes）部署的应用程序服务之间的网络连接。\nCilium 的基础是一种名为 BPF 的新 Linux 内核技术，它可以在 Linux 本身动态插入强大的安全可见性和控制逻辑。由于 BPF 在 Linux 内核中运行，因此可以应用和更新 Cilium 安全策略，而无需对应用程序代码或容器配置进行任何更改。\nCilium 基于微服务的应用程序分为小型独立服务，这些服务使用HTTP、gRPC、Kafka等轻量级协议通过 API 相互通信。但是，现有的 Linux 网络安全机制（例如 iptables）仅在网络和传输层（即 IP 地址和端口）上运行，并且缺乏对微服务层的可见性。\nCilium 为 Linux 容器框架（如Docker和Kubernetes）带来了 API 感知网络安全过滤。使用名为BPF的新 Linux 内核技术，Cilium 提供了一种基于容器/容器标识定义和实施网络层和应用层安全策略的简单而有效的方法。\n …","relpermalink":"/blog/cilium-intro/","summary":"Cilium 是一个纯开源软件，没有哪家公司提供商业化支持，也不是由某一公司开源，该软件用于透明地保护使用 Linux 容器管理平台（如 Docker 和 Kubernetes）部署的应用程序服务之间的网络连接。","title":"Cilium——具备 API 感知的网络和安全性管理的开源软件"},{"content":" Cilium Kubernetes 本文为翻译文章，点击查看原文。\n我们很高兴地宣布 Cilium 1.3 发布了。这个版本加入了几个新特性。主要的亮点是实现了 Cassandra 和带有策略执行能力的 Memcached 协议解析器，作为Envoy的 Go 语言扩展包。\n和往常一样，整个 Cilium 社区的开发者贡献巨大，他们在 1.2 到 1.3 版本的这段时间贡献了 785 个提交。\n什么是 Envoy 的 Go 语言扩展？ 从 1.0 版本开始，我们一直依赖Envoy处理所有的 HTTP、gRPC 以及 HTTP 的派生如 Elasticsearch 的请求。社区讨论如何扩大支持 7 层协议的范围，Envoy 作为推动未来协议补充的首选平台是显而易见的。焦点迅速转移到寻找简化 Envoy 可扩展性的方法，并且允许重用现有的开源项目，如 CNCF 项目Vitess。于是实现 Envoy 的 Go 扩展的想法就诞生了。\n在 Cilium 1.3 中，我们引入了 Envoy 的 Go 扩展作为其 Beta 特性。\nEnvoy Golang Extension …","relpermalink":"/blog/cilium-13-go-extensions-for-envoy-cassandra-memcached-support/","summary":"本文讲解了具备 API 感知的网络和安全性管理的开源软件 Cilium1.3 的新特性，并用示例演示新的 Go 扩展如何使用。","title":"Cilium 1.3：支持 Envoy、Cassandra 和 Memcached 的 Go 语言扩展"},{"content":" gateway 定义用于配置在 mesh 边缘，到 mesh 的 tcp 和 http 的负载均衡。 非 TLS 单主机环境 相关拓扑 使用 azure aks 环境。 ingress gateway 的 service 类型为 loadbalancer。 ingress gateway 的 service enternal ip 为 104.211.54.62。 通过该 external ip 对应的域名，访问 ingress gateway svc。 增加 gateway 定义。 gateway 定义中的 selector 会将该设置与相应的 gateway pod 绑定。 gateway 定义中的 servers 会在相应的 pod 中生成 listener 实例，该拓扑中的监听端口为 80。 需要将 80 端口注册到该 gateway pod 对应的服务中（默认已注册）。 gateway 定义中的 hosts 表示 listener 会向哪些特定的虚拟主机转发流量，在该示例中为 httpbin.7cb9a9b7b318440399a0.eastus.aksapp.io。 …","relpermalink":"/blog/summary-control-traffic-using-gateway-in-istio/","summary":"本文重点为分析 Istio Gateway 以及 VirtualService 定义如何生成 Istio Ingress Gateway 的 Envoy 相关配置。","title":"Istio Ingress Gateway 中的 Envoy 配置解析"},{"content":"本文为翻译文章，点击查看原文。\n速率限制是缓解级联故障和防止耗尽共享资源的一种简单有效的方法。Envoy 是一个功能丰富的代理，可以为任何服务轻松添加速率限制的功能。本文将介绍在不更改应用程序本身配置的前提下如何配置 Envoy 来强制对应用进行速率限制。\n问题 你是否遇到过资源被大量的请求淹没或耗尽的情况？你的客户端是否具有回退重试或速率限制的逻辑？在微服务架构中，不对其使用量进行限制的资源很容易被客户端发出的大量请求所淹没。当然可能存在一定数量的客户端，这些客户端本身就已经实现了各种重试/回退和速率限制的策略。不对访问量进行限制的客户端会耗尽服务端的资源，从而使其他客户端无法访问服务，甚至有些客户端会一直发起请求，直到使服务完全不可用。\n对 API 的使用进行约束的常用方法是启用速率限制。与基于 IP 的速率限制或者 web 框架提供的应用级别速率限制不同，Envoy 允许在 HTTP 层实现快速，高性能和可靠的全局速率限制。\n上图中左侧的 Service Client 代表使用率特别高的客户端。在运行期间，它可以使负载均衡后端的所有服务实例流量饱和，并使其他更高优先级的客户端丢弃 …","relpermalink":"/blog/sre-resiliency-bolt-on-sidecar-rate-limiting-with-envoy-sidecar/","summary":"本文详述了如何做速率限制服务来减轻客户端对 API 资源的消耗。","title":"SRE 弹性能力：使用 Envoy 对应用进行速率限制"},{"content":"本文为翻译文章，点击查看原文。\n在服务网格系列的第一部分中，我们认为服务网格是微服务体系架构发展的必然和有益的结果。随着 Istio 1.0 的发布，我们在服务网格领域已经经过了一个重要的里程碑，在这个重要的的时间节点上，我们需要思考服务网格的未来将如何发展。\n在 VMware 我们非常愿意花时间和精力支持开源的服务网格架构。我们已经成为 Istio 和 Envoy（Istio 用来动态控制微服务的特定的开源服务代理）的贡献成员。我们在改善网络方面投入了大量的精力，同时在其他领域贡献力量。\n我们考虑到几乎每个 Istio 的演示目前都是基于一个单一的示例。保加利亚的一位 VMware 同事目前正在构建一个全新的 Istio 演示示例，用于演示如何在封闭字幕等服务之间管理视频质量，并演示 Istio 在微服务环境中的动态路由的能力。\n因为我们认为服务网格是有价值的，而且可以一直存在，所以我们一只在寻求将 VMware 自己的世界级系统管理工具集与服务网格框架进行集成。这里有一个很好的例子，我们最近创建了一个适配器，将 Istio metrics 导出到 VMware …","relpermalink":"/blog/the-future-of-service-mesh/","summary":"本文通过分析服务网格的优势，阐述了其未来的发展情况。","title":"服务网格的未来 Part 2：Istio 1.0 之后何去何从？"},{"content":"本文为翻译文章，点击查看原文。\nKubernetes 不仅仅是一个容器管理工具。它是一个平台，旨在处理包装在任意数量的容器和组合中的各种工作负载。Kubernetes 内置了多个控制器，可映射到云原生架构的各个层。\nDevOps 工程师可以将 Kubernetes 控制器视为指示团队运行的各种工作负载的基础架构需求的手段。他们可以通过声明方法定义所需的配置状态。例如，容器/pod 作为 ReplicationController 的一部分部署保证始终可用。打包为 DaemonSet 的容器​保证在集群的每个节点上运行。声明式的方法使 DevOps 团队能够利用代码控制基础架构。下面讨论的一些部署模式遵循不可变基础结构的原则，其中每个新的部署都会导致原子部署。\nDevOps 工程师可以通过声明方法定义所需的配置状态——每个工作负载映射到控制器。\n了解云原生用例 Kubernetes 的控制平面不断跟踪部署，以确保它们符合 DevOps 定义的所需配置状态。\nKubernetes 的基本部署单位是一个 pod。它是 Kubernetes 的基本构建块，是 Kubernetes 对象模型中最 …","relpermalink":"/blog/how-to-map-cloud-native-workloads-to-kubernetes-controllers/","summary":"本文介绍了如何将云原生工作负载映射到 Kubernetes 中的控制器。","title":"如何将云原生工作负载映射到 Kubernetes 中的控制器"},{"content":"本文为翻译文章，点击查看原文。\n本文最初发表于 2017 年 5 月 24 日。\n随着大量新平台和支持工具的出现，云原生势头正在增长。这些新平台为开发人员提供了越来越多的功能，可以以自动化的方式快速开发，部署和管理大量微服务。\n但这种云原生的势头的增长同样会伴随着成本的增加，最好做好为此付出代价的准备。\n最近我写了一篇由 Kubernetes 等云原生平台提供的“为开发者准备的新的分布式原语”，以及这些原语如何与开发应用程序的编程原语相结合。例如，下面看看开发人员必须了解和使用多少 Kubernetes 概念才能有效地运行单个容器化应用程序：\n基于 Kubernetes 的微服务 请记住，此图表不包含 DevOps 团队的 Ops 部门必须管理的支持 Kubernetes 的对象。在操作之前也不需要额外的应用程序支持工具（用于日志管理、监控、跟踪、服务网格等）。\n更有可能的是，开发人员必须编写与容器中的应用程序代码相同数量的 YAML 代码。更重要的是，应用程序本身将依赖于比以往更多的平台。云原生应用程序期望平台执行运行状况检查、部署、放置、服务发现、运行定时任务（ cron 作业）或 …","relpermalink":"/blog/myth-cloud-native-portability/","summary":"本文介绍了云原生的可移植性，告诫读者应该看重生态系统而不是某个具体平台。","title":"云原生可移植性的神话"},{"content":"当Istio 1.0在几个月前发布时，TechCrunch称它为“可能是目前最重要的开源项目之一”。它并不是完美的 (在本系列的第 2 部分会有详细介绍)，但是这个版本标志着服务网格架构开发的一个重要里程碑。\n尽管对 Istio 的发布给予了关注，但是，在开源社区服务网格还是不为人知。在这两篇文章中，我们首先提供一个窗口让读者了解服务网格的功能，然后在第二部分，展望在不久的会有何收获。\n关于服务网格，有一件重要的事情需要知道：那就是一旦微服务开始流行起来，服务网格基本上就变得不可避免了。这是因为本质上，它们运行并作为平台来解决服务之间通信的日益复杂的挑战。\n它们是这样工作的：假设你有一个微服务用来在客户数据库中查找支付方式，另一个来处理支付流程。如果你想确保信息不会泄露，或者你要将客户信息关联到正确的支付处理程序，那么你需要对它们之间的通信进行加密。服务网格可以处理加密而不需要任何一个服务知道如何加密。\n服务网格的作用远不止于此。总的来说，它们负责广泛的核心通信，包括：\n可观测性——在服务之间提供日志和度量数据 发现——使服务连接在一起能够彼此发现 通信——建立通信策略、方法和安全 认 …","relpermalink":"/blog/service-mesh-architectures-inevitable/","summary":"本文来自 VMware 开源小组，通过分析服务网格的优势，阐述了其未来的发展情况。","title":"服务网格的未来 Part 1：服务网格架构是必然趋势并愈加重要"},{"content":"介绍 自从istio-1.0.0 在今年发布了正式版以后，Coohom项目在生产环境中也开启了使用 istio 来作为服务网格。\n本文将会介绍与分享在 Coohom 项目在使用 istio 中的一些实践与经验。\nCoohom 项目 杭州群核信息技术有限公司成立于 2011 年，公司总部位于浙江杭州，占地面积超过 5000 平方米。酷家乐是公司以分布式并行计算和多媒体数据挖掘为技术核心，推出的家居云设计平台，致力于云渲染、云设计、BIM、VR、AR、AI 等技术的研发，实现“所见即所得”体验，5 分钟生成装修方案，10 秒生成效果图，一键生成 VR 方案，于 2013 年正式上线。作为“设计入口”，酷家乐致力于打造一个连接设计师、家居品牌商、装修公司以及业主的强生态平台。\n依托于酷家乐快速的云端渲染能力与先进的 3D 设计工具经验，Coohom致力于打造一个让用户拥有自由编辑体验、极致可视化设计的云端设计平台。Coohom 项目作为一个新兴的产品，在架构技术上没有历史包袱，同时 Coohom 自从项目开启时就一直部署运行在 Kubernetes 平台。作为 Coohom 项目的技术积累， …","relpermalink":"/blog/practice-for-coohom-using-istio-in-production/","summary":"本文是酷家乐的 Coohom 项目使用 Istio 服务网格的实践经验分享。","title":"云端设计平台 Coohom 在生产环境中使用 istio 的经验与实践"},{"content":" 用Istio治理服务时须通过 istioctl 或 kubectl，这种方式可能存在一些问题。因此小米武汉研发中心推出 Naftis，帮助用户更轻松地管理 Istio。\n近年来服务网格（Service Mesh）已成为各大公司关注重点，各大公司纷纷开始调研 Service Mesh 相关架构。作为 Service Mesh 中的佼佼者，Istio 诞生之初就已吸引众多目光。\n作为基础设施层，Istio 有优秀的服务治理能力。但使用 Istio 进行服务治理时，开发者需通过 istioctl 或 kubectl 工具在终端中进行操作，这种方式目前存在一些问题，举例如下：\nIstio 要求用户熟练掌握 istioctl 工具的数百种指令，有较高的学习成本。 Istio 进行服务治理时需要的 yaml 配置文件的数量非常庞大，如何配置和管理这些配置文件，也是个难题。 Istio 的 istioctl 工具没有用户权限的约束，存在一定安全隐患，无法适应大公司严格的权限管理需求。 Istio 的 istioctl 工具不支持任务回滚等需求，在执行任务出错的情况下，无法快速回滚到上一个正确版本。 …","relpermalink":"/blog/naftis-istio-dashboard-xiaomi/","summary":"用 Istio 治理服务时须通过 istioctl 或 kubectl，这种方式可能存在一些问题。因此小米武研推出 Naftis，帮助用户更轻松地管理 Istio。","title":"小米正式开源 Istio 管理面板 Naftis"},{"content":"本文为翻译文章，点击查看原文。\nIstio通过虚拟服务, 目标规则, Gateway等概念提供了复杂的路由机制。Istio 1.0 通过加权路由定义启用了 HTTP 流量转移。我提交的Envoy 和Istio的 pull request为TCP/TLS服务提供了类似的特性。这一特性已经在Envoy 1.8.0中发布了。Istio 中的这一特性也会在即将发布的1.1.0版本中提供使用。\nIstio 在本文中，我们将用Go编写的一个简单的 TCP Echo 服务，用Docker将其容器化并部署到Kubernetes上，并通过练习 Istio 的加权 TCP 路由特性来理解其在生产服务中的行为。\nTCP Echo 服务 在本文中，我们将创建一个简单的监听连接的 TCP 服务，并在客户端的请求数据加上一个简单的前缀，将其作为响应返回。图示如下：\nTCP Client - Server Architecture 让我们看一下 TCP Echo 服务端的 Go 代码：\npackage main import ( \u0026#34;bufio\u0026#34; \u0026#34;fmt\u0026#34; \u0026#34;io\u0026#34; \u0026#34;net\u0026#34; \u0026#34;os\u0026#34; ) // main 作为程 …","relpermalink":"/blog/raw-tcp-traffic-shaping-with-istio/","summary":"本文通过构建一个简单的 echo 服务演示了如何在 Istio1.1.0 下进行 TCP 流量控制。","title":"Istio1.1.0 下的 TCP 流量控制"},{"content":"本文为翻译文章，点击查看原文。\n在 Istio 和相关技术持续获得增势之时，中间件在 Service Mesh 中的地位正在逐渐减弱。尽管它们都可以用来监管不同应用和服务之间的通信，但是在运维和范式方面却大不相同。在今天以容器为中心的世界里，面向服务的架构体系盛行，中间件会变得无关紧要吗？\n中间件 中间件将应用和它底层的数据库连接起来，因此常被称作“软件胶水”。它将客户端的网络请求连接到后端数据，通过将所有消息聚合到一个管道中来实现通信。中间件在这个管道中整合一些关键功能，包括安全验证、日志记录、路由、性能监控和消息转换。中间件以传统的方式整合面向服务架构（SOA）应用的通信，后者由可复用的组件组成或者是一个单体应用。\n如下图所示，中间件的工作方式，是将不同应用的消息汇总到中心化的通信节点。然后将这些消息传递到一系列功能管道，直到“用户注册”服务。消息通过企业服务总线（ESB）进行传输。这种通信方式便于隐藏分布式系统的多样性、硬件和操作系统的差异性。\n中间件 随着企业组织持续拥抱容器化，传统中间件的一些问题开始变得愈加明显。DevOps 实践鼓励基于分布式系统的现代环境，以及快速、自动 …","relpermalink":"/blog/does-the-service-mesh-spell-the-end-for-middleware/","summary":"本文分别介绍了中间件和服务网格，以及两者之间的权衡。使用诸如 Istio 之类的工具，将中间件的计算能力带入到 Kubernetes 和基于容器的系统。如果组织架构希望使用服务网格替代某些中间件，则必须重新评估其组织流程和方法论。","title":"服务网格是中间件的终结者吗？"},{"content":" 由来 ​ 开发istio-ui是由于运维：到时候线上几百个istio配置文件管理会很麻烦。其实在开始接触 istio 的时候，我们其他同学就有这样的想法，当时大家都认为不久官方或社区就会有相应的产品出来。但等了几个月还是没音讯，所以我们就按照我们自己的需求开发了istio-ui，并且开源。当然现在还是一块滑板。离奔驰还需要慢慢雕琢。在这个基础上，结合我们当前服务环境，增加了：校验，注入，模板等功能。\n校验 校验是必须的，没人能保证自己不犯错，即使是Ctrl+C，Ctrl+V\n注入 有三种方式\n一键注入\n基于运行中的服务Deployment:apps/v1进行注入，使用这种方式服务会被重新部署\n文件上传注入\n将需要注入的文件发送到远程 api 接口\nkubectl apply -f \u0026lt;(curl -F \u0026#34;config=@samples/bookinfo/platform/kube/bookinfo.yaml\u0026#34; http://localhost:9100/inject/file) 内容注入\n将需要注入的内容发送到远程 api 接口\nkubectl apply -f \u0026lt;(curl -X …","relpermalink":"/blog/istio-ui-tutorial/","summary":"本文介绍的是联邦车网的工程师朱经惠开源的 istio-ui 项目，该项目主要是为了减轻配置工作和减少犯错几率。","title":"istio-ui——一款开源的简易 Istio UI 的介绍和使用教程"},{"content":"Istio 中有个 issue #9066 要求将 Istio 中默认使用的 Service Graph 替换成 Kiali。Kiali 最初是由 Red Hat 开源的，用于解决 Service Mesh 中可观察性即微服务的可视性问题。目前已获得 Istio 社区的官方支持。\n关于 Kiali 单体应用使用微服务架构拆分成了许多微服务的组合。服务的数量显著增加，就对需要了解服务之间的通信模式，例如容错（通过超时、重试、断路等）以及分布式跟踪，以便能够看到服务调用的去向。服务网格可以在平台级别上提供这些服务，并使应用程序编写者从以上繁重的通信模式中解放出来。路由决策在网格级别完成。Kiali 与 Istio 合作，可视化服务网格拓扑、断路器和请求率等功能。Kiali 还包括 Jaeger Tracing，可以提供开箱即用的分布式跟踪功能。\nKiali 提供的功能 Kiali 提供以下功能：\n服务拓扑图 分布式跟踪 指标度量收集和图标 配置校验 健康检查和显示 服务发现 下图展示了 kiali 中显示的 Bookinfo 示例的服务拓扑图。 …","relpermalink":"/blog/kiali-the-istio-service-mesh-observability-tool/","summary":"本文介绍了 Istio Service Mesh 中的可观察性工具 Kiali 的功能、架构和部分代码。","title":"Kiali——Istio Service Mesh 的可观察性工具"},{"content":"Istio 发布 1.0 版本后，其服务发现和路由规则功能已基本具备 production 能力，我们也开始了 Istio 和公司内部微服务平台的集成工作，打算以 Istio 为基础打造一个微服务管控中心，在这里把目前的进展和遇到的坑和大家分享一下。\n现有系统架构 目前公司的微服务架构如图所示，系统中主要包含三类服务：\n业务服务，大部分的业务服务都已经实现了微服务化和无状态，采用 docker 容器部署在 K8s 集群中，利用 K8s 的容器管理能力进行服务部署，弹缩。但也有部分服务只做了容器化，但并未进行微服务改造，此类服务属于 SOA 架构，一个服务可能对外暴露多个业务 API，这和敖小剑老师在《SOFAMesh 中的多协议通用解决方案》系列文章中提到的情况是类似的。 一些有状态的公共服务，例如数据库，FTP 服务器，共享缓存等，目前未放入到 K8s 集群中，但业务服务对这些公共服务存在大量的依赖。 其他未纳入 K8S 集群的服务，如遗留系统和第三方系统提供的服务。某些业务服务和这些服务之间存在互相访问的需求。 服务注册 电信领域与 IT 领域相比有一些特殊性，其中一点就是多网络平 …","relpermalink":"/blog/istio-paas-integration/","summary":"Istio 发布 1.0 版本后，其服务发现和路由规则功能已基本具备 production 能力，我们也开始了 Istio 和公司内部微服务平台的集成工作，打算以 Istio 为基础打造一个微服务管控中心，在这里把目前的进展和遇到的坑和大家分享一下。","title":"Istio 微服务平台集成实践"},{"content":"本文为翻译文章，点击查看原文。\n你已经浏览了 Istio Mixer Adapter 的指南 ，现在想要发布自己的 Adapter？这篇文章将教你创建自己的 Adapter，在生产环境的海洋中扬帆起航。\nIstio 介绍 根据你对Go、Protobufs、gRPC、Istio、Docker和Kubernetes知识有所了解，你可能会发现发布 Istio Mixer Adapter 的过程很容易。本文假设你对这些技术有一些经验，并且根据 Istio 的 Wiki 已经能够完成至少一个演练。\n就本文的目的而言，我将讨论如何构建一个消费Metrics的 Istio Mixer Adapter。下面是简要步骤：\nIstio Mixer - Adapter 接口架构 创建一个简单的 Mixer Adapter 将 Adapter 发布到 Docker Hub 为 Adapter 编写 Kubernetes Config 在 Istio 上部署和测试 Adapter 再次强调，我将尽最大努力在这篇文章里呈现所有重要的细节，让你的 Adapter 运行起来。\nIstio Mixer - …","relpermalink":"/blog/set-sail-a-production-ready-istio-adapter/","summary":"本文通过示例讲解了如何创建并部署一个生产环境就绪的 Istio Adapter。","title":"教程 | 构建生产就绪的 Istio Adapter"},{"content":"本文为翻译文章，点击查看原文。\n在本文中，我将演示如何使用 Golang 来操作 Kubernetes Custom Resources，以 Istio 为例。不需要您了解 Istio，我只是用它来展示概念！\nIstio是一个非常受欢迎的服务网格平台，它允许工程师快速地为基于服务的应用程序添加遥测技术、先进的流量管理等功能。\nIstio 工作原理的一个有趣的地方是，当部署到 Kubernetes 集群中时，许多关键配置对象被作为自定义资源处理。自定义资源是一个非常强大的 Kubernetes 特性，它允许您创建自己的”一等“资源（就像 pod、副本、部署等），然后使用kubectl或 Kubernetes API 与它们进行交互。\n在本文中，我将展示如何使用 Golang Kubernetes client 与这些自定义资源交互。\nCRD：快速概述 在为集群设置 Istio 时，您可能要做的一件常见的事情是指定如何路由通信。这可能相当复杂，如下所示：\n图 1：来自 istio.io 的 Istio 流量管理示例\n对于这样的系统，有一种配置方法就是使用一个 ConfigMap，其中包含如 …","relpermalink":"/blog/manipulating-istio-and-other-custom-kubernetes-resources-in-golang/","summary":"主要介绍了在 Golang 中操作 Istio 和其他 Kubernetes 自定义资源（CRD），主要讲解了除 go-client 之外的另一种方法。","title":"使用 Go 语言操作 Istio 和其他 Kubernetes CRD"},{"content":" 本文是 SOFAMesh 中的多协议通用解决方案 x-protocol 介绍系列文章之一。\nSOFAMesh 中的多协议通用解决方案 x-protocol 介绍系列（1）——DNS 通用寻址方案\nSOFAMesh 中的多协议通用解决方案 x-protocol 介绍系列（2）——快速解码转发\nSOFAMesh 中的多协议通用解决方案 x-protocol 介绍系列（3）——TCP 协议扩展\n背景 在 Istio 和 Envoy 中，对通讯协议的支持，主要体现在 HTTP/1.1 和 HTTP/2 上，这两个是 Istio/Envoy 中的一等公民。而基于 HTTP/1.1 的 REST 和基于 HTTP/2 的 gRPC，一个是目前社区最主流的通讯协议，一个是未来的主流，google 的宠儿，CNCF 御用的 RPC 方案，这两个组成了目前 Istio 和 Envoy（乃至 CNCF 所有项目）的黄金组合。\n而我们 SOFAMesh，在第一时间就遇到和 Istio/Envoy 不同的情况，我们需要支持 REST 和 gRPC 之外的众多协议：\nSOFARPC： …","relpermalink":"/blog/x-protocol-tcp-protocol-extension/","summary":"在本系列文章中，我们将详解 Service Mesh 中的多协议解决方案 x-protocol，本文介绍的是 TCP 协议扩展。","title":"SOFAMesh 中的多协议通用解决方案 x-protocol 介绍系列（3）——TCP 协议扩展"},{"content":"本文为翻译文章，点击查看原文。\n最近的几次关于容器使用情况的调研都得到了相似的结果，开发团队不仅采用而且开始拥抱容器技术。大多数人并没有像超大型组织那样大规模的使用容器。在一项思科赞助的调研中发现有超过 8000 家企业在生产环境中使用容器。这听起来令人印象深刻，但他们使用容器的规模有限。在戴尔 EMC，英特尔和红帽委托的 Forrester 报告中，63％使用容器的企业运行的实例超过 100 个，82％预计到 2019 年会达到这一规模。这与超大型技术公司使用的数十万的规模相距甚远。\n虽然采用率很高，这并不是说组织使用容器的道路就是一帆风顺的。采纳任何一样新技术都是存在挑战的。人们使用容器时最关心的是：网络和管理。其次才去关注安全性和不一致性。\n网络挑战是由于 Kubernetes 等流行的容器编排软件所带来的。Kubernetes 构建的就是要支持微服务架构。这允许开发和运维人员将功能抽象成一组 pod，并将其作为“service”暴露出来，并通过定义好的 API 进行访问。Kubernetes 支持 DNS 和基于 TCP 的 L4 负载均衡。\n基于 TCP L4 负载均衡的问题 …","relpermalink":"/blog/going-beyond-container-orchestration/","summary":"容器编排是一个很好的基础设施，但企业组织需要的不仅仅是一个良好的基础设施。他们需要能够与堆栈上层的服务进行交互的能力，这需要使用 Service Mesh 指标和现代架构去实现。","title":"容器编排无法解决微服务的所有问题，你还需要服务网格"},{"content":" 本文是 SOFAMesh 中的多协议通用解决方案 x-protocol 介绍系列文章之一。\nSOFAMesh 中的多协议通用解决方案 x-protocol 介绍系列（1）——DNS 通用寻址方案\nSOFAMesh 中的多协议通用解决方案 x-protocol 介绍系列（2）——快速解码转发\nSOFAMesh 中的多协议通用解决方案 x-protocol 介绍系列（3）——TCP 协议扩展\n前言 在 Istio 和 Envoy 中，对通讯协议的支持，主要体现在 HTTP/1.1 和 HTTP/2 上，而我们 SOFAMesh，则需要支持以下几个 RPC 协议：\nSOFARPC：这是蚂蚁金服大量使用的 RPC 协议（已开源） HSF RPC：这是阿里集团内部大量使用的 RPC 协议（未开源） Dubbo RPC: 这是社区广泛使用的 RPC 协议（已开源） 更适合的平衡点：性能和功能 对于服务间通讯解决方案，性能永远是一个值得关注的点。而 SOFAMesh 在项目启动时就明确要求在性能上要有更高的追求，为此，我们不得不在 Istio 标准实现之外寻求可以获取更高性能的方式， …","relpermalink":"/blog/x-protocol-rapid-decode-forward/","summary":"在本系列文章中，我们将详解 Service Mesh 中的多协议解决方案 x-protocol，本文介绍的是快速解码转发方案。","title":"SOFAMesh 中的多协议通用解决方案 x-protocol 介绍系列（2）——快速解码转发"},{"content":"首先声明，我在 RedHat 工作，确切得说，是在 3scale 团队开发 3scale API 管理解决方案。最近，在跟我们的客户讨论时有个问题被越来越多的提及：使用了Istio之后，为什么还需要API管理？\n为了回答这个问题，我们首先要搞明白服务网格和 API 管理究竟是什么，剧透一下：3scale API Management 和 Istio 可以共存。\n让我们聚焦于 3scale API Management 和 Istio Service Mesh（这两者是我比较了解的），我会尽量描述清楚这两个方案的目标是解决哪些问题。\nAPI Management 解决方案是什么？ 我们先看一下 Wikipedia 的定义：API管理的过程包括创建和发布Web API、执行调用策略、访问控制、订阅管理、收集和分析调用统计以及报告性能。\n这是一个清晰的定义。作为一家已经创建了一系列内部 Service 的公司，我现在希望通过向外部订阅者提供 API 的方式构建业务。当然，我会通过提供一些订阅计划来量化它，包括使用限制、范围，并且可以自动的给客户提供账单。\n此外，外部开发者可以很容易地发现我提 …","relpermalink":"/blog/api-management-and-service-mesh/","summary":"本文分别介绍了 API Management 和 Service Mesh，并简单分析了它们的共同点。","title":"API 管理和服务网格——为什么说服务网格无法替代 API 管理"},{"content":" 本文由作者授权，转载自赵化冰的博客。\nIstio 作为一个 service mesh 开源项目，其中最重要的功能就是对网格中微服务之间的流量进行管理，包括服务发现，请求路由和服务间的可靠通信。Istio 实现了 service mesh 的控制面，并整合 Envoy 开源项目作为数据面的 sidecar，一起对流量进行控制。\nIstio 体系中流量管理配置下发以及流量规则如何在数据面生效的机制相对比较复杂，通过官方文档容易管中窥豹，难以了解其实现原理。本文尝试结合系统架构、配置文件和代码对 Istio 流量管理的架构和实现机制进行分析，以达到从整体上理解 Pilot 和 Envoy 的流量管理机制的目的。\nPilot 高层架构 Istio 控制面中负责流量管理的组件为 Pilot，Pilot 的高层架构如下图所示：\nimg Pilot Architecture（来自Isio 官网文档[1])\n根据上图，Pilot 主要实现了下述功能：\n统一的服务模型 Pilot 定义了网格中服务的标准模型，这个标准模型独立于各种底层平台。由于有了该标准模型，各个不同的平台可以通过适配器和 Pilot …","relpermalink":"/blog/istio-traffic-management-impl-intro/","summary":"本文尝试结合系统架构、配置文件和代码对 Istio 流量管理的架构和实现机制进行分析，以达到从整体上理解 Pilot 和 Envoy 的流量管理机制的目的。","title":"Istio 流量管理实现机制深度解析"},{"content":" 本文是 SOFAMesh 中的多协议通用解决方案 x-protocol 介绍系列文章之一。\nSOFAMesh 中的多协议通用解决方案 x-protocol 介绍系列（1）——DNS 通用寻址方案\nSOFAMesh 中的多协议通用解决方案 x-protocol 介绍系列（2）——快速解码转发\nSOFAMesh 中的多协议通用解决方案 x-protocol 介绍系列（3）——TCP 协议扩展\n前言 在 2018 年上半年，蚂蚁金服决定基于 Istio 订制自己的 ServiceMesh 解决方案，在 6 月底对外公布了 SOFAMesh，详情请见之前的文章：大规模微服务架构下的 Service Mesh 探索之路 。\n在 SOFAMesh 的开发过程中，针对遇到的实际问题，我们给出了一套名为 x-protocol 的解决方案，定位是云原生、高性能、低侵入性的通用 Service Mesh 落地方案，依托 Kubernetes 基座，利用其原生的服务注册和服务发现机制，支持各种私有 RPC 协议低成本、易扩展的接入，快速享受 Service Mesh 所带来的红利。\n具体解决的问题包括：\n …","relpermalink":"/blog/x-protocol-common-address-solution/","summary":"在本系列文章中，我们将详解 Service Mesh 中的多协议解决方案 x-protocol，首先介绍的是 DNS 通用寻址方案。","title":"SOFAMesh 中的多协议通用解决方案 x-protocol 介绍系列（1）——DNS 通用寻址方案"},{"content":"本文为翻译文章，点击查看原文。\nEnvoy 通过查询文件或管理服务器来动态发现资源。概括地讲，对应的发现服务及其相应的 API 被称作 xDS。Envoy 通过订阅（subscription）方式来获取资源，如监控指定路径下的文件、启动 gRPC 流或轮询 REST-JSON URL。后两种方式会发送 DiscoveryRequest 请求消息，发现的对应资源则包含在响应消息 DiscoveryResponse 中。下面，我们将具体讨论每种订阅类型。\n文件订阅 发现动态资源的最简单方式就是将其保存于文件，并将路径配置在 ConfigSource 中的 path 参数中。Envoy 使用 inotify（Mac OS X 上为 kqueue）来监控文件的变化，在文件被更新时，Envoy 读取保存的 DiscoveryResponse 数据进行解析，数据格式可以为二进制 protobuf、JSON、YAML 和协议文本等。\n译者注：core.ConfigSource 配置格式如下：\n{ \u0026#34;path\u0026#34;: \u0026#34;...\u0026#34;, \u0026#34;api_config_source\u0026#34;: \u0026#34;{...}\u0026#34;, \u0026#34;ads\u0026#34;: …","relpermalink":"/blog/envoy-xds-protocol/","summary":"本文翻译自 Envoy 代码库中的文档，本文通过示例详解了 Envoy 的 xDS REST 和 gPRC 协议。","title":"Envoy 中的 xDS REST 和 gRPC 协议详解"},{"content":" 本文为翻译文章，点击查看原文。\nTrulia是一个多功能的房地产网站，为您提供有关待售房屋、出租公寓、邻里洞察、市场和趋势的本地独家新闻，以帮助您确切了解房屋购买、出售或出租的内容、地点和时间。您还可以找到房地产经纪人，查看最近售出的房屋的价格，并查看您所在社区的房屋价值。\nKubernetes 和 Istio 如何帮助 Trulia 消除 PHP 单体架构，并用可持续的微服务架构取代。这篇博文是我们关于偿还欠下的技术债和重新构建我们平台的系列文章的延续。您可以阅读这篇介绍性文章：聚焦未来的技术债。\n引言 Trulia 致力于将 https://www.trulia.com 单体应用分解成面向服务（SOA）的架构。所有支持的 APIs 和服务都将替换成工程部门 AWS 账号下拥有的各种功能单元。许多遗留 AWS 服务都是通过 AMI 映像 promotion 进行部署的，并使用各种不同的方法实现可观测性。将测量工具添加到代码库和基础架构所需的手动操作一直是个传统痛点。此外，这种用于构建可观测性的手动、个性化方法意味着没有单一的代码库可以在增强和工具上进行协作。\n在 2017 年。我们 …","relpermalink":"/blog/microservice-observability-with-istio/","summary":"在 kubernetes 和 istio 的帮助下，Trulia 能够分解 PHP 单体架构替换成可持续交付的微服务架构。团队不再被迫手动将工具添加到单个代码库或基础架构自动化中。","title":"Istio 和 Kubernetes 帮助 Trulia 房产网站消除单体架构增强微服务的可观测性"},{"content":"本文为翻译文章，点击查看原文。\n随着 Istio 1.0 版本的发布，Istio 正在为开发云原生应用并希望采用服务网格解决方案的公司准备黄金时间。但是，有一个潜在的问题可能会降低这些公司的采用率：服务网格内的 Pod 需要提升权限才能正常运行。\n为了从一定程度上缓解这个问题，本文将介绍一个新的工具：istio-pod-network-controller。\n问题 作为服务网格正常操作的一部分，Istio 需要操作 Pod 的 iptables 规则，以拦截所有的进出 Pod 的流量，并注入使 Istio 能够发挥作用的 Sidecar。由于 iptables 规则是针对网络命名空间操作的，所以在某个 Pod 中修改 iptables 规则不会影响到其他 Pod 或运行该 Pod 的节点。\ninit 容器是 Istio Pod 的一部分，负责在应用程序容器启动之前添加这些 iptables 规则。如果想在容器中操作 iptables 规则，必须通过开启 NET_ADMIN capability 来提升操作权限。NET_ADMIN 是一种允许你重新配置网络的 Linux …","relpermalink":"/blog/increasing-security-of-istio-deployments-by-removing-the-need-for-privileged-containers/","summary":"Red Hat OpenShift 通过一个名叫 istio-pod-network-controller 的 DaemonSet 控制器将配置 Pod 的 iptables 规则的逻辑移出 Pod 本身，从而消除了特权容器的需求来提高 Istio Deployment 的安全性。","title":"通过消除对特权容器的需求来提高 Istio Deployment 的安全性"},{"content":" 本文为翻译文章，点击查看原文。\nRed Hat 的 OpenShift 服务网格技术预览版上线，基于 Istio。\n软件开发实践的进步与软件交付中的技术改进相结合导致了组织中的应用程序实例数量激增。无论它们是基于“macro”的还是单体的，“迷你”服务还是微服务，随着服务数量的增加交互的数量和复杂性都会显著增加。\n到目前为止，管理这些复杂服务交互的大部分负担都放在了应用程序开发人员身上。像Netflix Common Runtime Services \u0026amp; Libraries这样的库集的发展为应用程序弹性、流量控制等带来了许多特性和优势。但是这些库与运行时相关，比如 Netflix 的库是基于 Java 的，开发人员必须将它们集成到应用程序中。\n网格\n服务网格概念将这些责任推给了基础架构，从而消除了开发人员的负担。当底层基础架构负责流量管理、可观察性、策略实施和服务身份/安全性时，开发人员就可以专注于业务价值本身。开发人员不用再花费时间将库集成到应用程序中。然后，基础设施运营团队负责维护网格基础设施，作为日常维护和管理实践的一部分。\n几年来，Red Hat 一直通过 Red Hat …","relpermalink":"/blog/istio-on-openshift-technology-preview/","summary":"技术预览计划将为现有的 OpenShift Container Platform 客户提供在其 OpenShift 集群上部署和使用 Istio 平台的能力。红帽正在提供此计划，旨在收集反馈和经验，同时 Red Hat 期望在 2019 自然年提供 OpenShift 上 Istio 的全面支持和全面可用性。","title":"Red Hat OpenShift 发布 Istio 预览版"},{"content":"本文为翻译文章，点击查看原文。\n据我所知，这是 kubernetes 可用网关的最完整的列表。从技术上来讲，Ambassador 不是 ingress，但是它表现地已经非常好了。你可能已经看到了我制作的大表。\n下面有个连接可以打开并清晰的看到一个 excel 表格，包含了图表的详细内容，如果发现不正确的地方，请在文章末尾留言，我将及时修改。\n查看全表请点击这里。\n基于这些特点和我自己的经验、从别人的描述和其他相关文章中得知，我尝试着给每一个网关提供了一些选择的参考条件。下面描述先后顺序没有特别含义。\n1. ingress-nginx 这可能是最常用的 ingress。安全、简单可靠。支持 http、https 和 ssl termination。你可能还想通过它支 TCP、UDP，但是从 GitHub 上提的 issue 来看，目前你最好别这样做。您可以获得一些良好负载均衡选项以及强大的路由，websocket 支持，基础身份认证和追踪。\n但是没有动态服务发现有点遗憾。有个配置生成器可以自动生成但还是不太完美。\n注意：我们在这里谈论的内容有官方的 Kubernetes ingress。 …","relpermalink":"/blog/nginx-ingress-vs-kong-vs-traefik-vs-haproxy-vs-voyager-vs-contour-vs-ambassador/","summary":"本文是对可作为 Kubernetes 中的 API 网关的开源软件的推荐列表。","title":"8 款开源的 Kubernetes Ingress Controller/API Gateway 推荐"},{"content":" 第一届 Kong Summit 本文为翻译文章，点击查看原文。\n图片：Kong 公司员工们在庆祝第一届 Kong Summit 举办（来自 Kong 官方 Twitter）\nKong公司的前身是 Mashape，发布了其核心开源 API 网关的 1.0 版本，名字也为Kong 。这是包括诺基亚、纽约​时报和哈佛大学等客户近四年生产经验的结晶。\nKong 1.0 是该公司构建服务控制平台愿景的基础，该平台结合了人工智能、机器学习和其他先进技术，可以促进信息流在服务之间的流动。\n“我们相信未来所有数据都将处于运动状态，并且将从数据池转移到系统间代理信息的地方。Kong 最初是一个网关，在 1.0 发布之后将转型为服务控制平台，“[Geoff Townsend](https://www.linkedin.com/in / geoff-townsend-25058347 /)，Kong 工程副总裁。据该公司称，截至目前，该软件已被下载 4500 万次。\n本周在Kong Summit 2018上，在该公司的总部旧金山探讨了 1.0 里程碑以及企业级组件包括开发人员门户、Open API 规范、 …","relpermalink":"/blog/kong-at-1-0-a-service-control-platform/","summary":"Kong 1.0 是该公司构建服务控制平台愿景的基础，该平台结合了人工智能、机器学习和其他先进技术，可以促进信息流在服务之间的流动。","title":"Kong 1.0 发布，从网关转型为服务控制平台"},{"content":" Linkerd 本文为翻译文章，点击查看原文。\n今天，云原生计算基金会（CNCF）和Linkerd 的维护者很高兴地宣布 Linkerd 2.0 GA 发布。\n2.0 版本为 Linkerd 带来了性能、资源消耗和易用性方面的显着改进。它还将项目从集群范围的 service mesh 转换为可组合的 service sidecar ，旨在为开发人员和服务所有者提供在云原生环境中成功所需的关键工具。\n2016 年，Linkerd 由 Buoyant创始人 William Morgan 和 Oliver Gould 发布，于 2017 年初捐献给 CNCF。从那时起，该项目经历了快速增长，现在为全球各种应用程序生态系统提供支持，从卫星成像到支付处理再到人类基因组计划。\nLinkerd 2.0 的 service sidecar 设计使开发人员和服务所有者能够在他们的服务上运行 Linkerd，提供自动可观察性、可靠性和运行时诊断，而无需更改配置或代码。通过提供轻量级的增量路径来获得平台范围的遥测、安全性和可靠性的传统 service mesh 功能，service sidecar 方法还 …","relpermalink":"/blog/linkerd-2-0-in-general-availability/","summary":"Linkerd 2.0 版本为 Linkerd 带来了性能、资源消耗和易用性方面的显着改进。它还将项目从集群范围的 service mesh 转换为可组合的 service sidecar，旨在为开发人员和服务所有者提供在云原生环境中成功所需的关键工具。","title":"Linkerd 2.0 GA 版本发布"},{"content":"本文为翻译文章，点击查看原文。\nIstio 正在引发大量的关注，特别是 1.0 版本发布后。但它是否成为 Kubernetes 之上的事实的服务网络标准呢？我们采访了 Red Hat 的 Istio 产品经理“红胡子”Brian Harrington，他的答案是肯定的。“有了 Istio，部署很简单，与 Kubernetes 的集成也是浑然一体的。感觉就应该是这样。“\n红胡子 Brian Harrington 图片：红胡子 Brian Harrington\nBrian Harrington，也被称为 Redbeard（红胡子），是 CoreOS 的首席架构师，现在是 Red Hat 的 Istio 的产品经理。他是开源开发和系统管理领域的开发人员，黑客和技术撰稿人。\nIstio 1.0 在今年 8 月初发布，所有核心功能现在都可以用于生产。\n如果您已经熟悉 0.8 中提供的功能，那么您应该知道 1.0 中提供的新功能列表并不长；该团队选择专注于修复错误并提高性能。如果您想看看 Istio 1.0 中引入的所有更改，可以阅读发行说明。\n我们与 Red Hat 的 Istio 产品经理“红 …","relpermalink":"/blog/istio-service-mesh-interview-redbear-brian-harrington/","summary":"Istio 能否成为 Kubernetes 之上的事实的服务网络标准呢？","title":"Service Mesh 的未来将与 Knative 和 Apahce Whisk 等技术和谐共存——采访 RedHat 的 Istio 产品经理"},{"content":"本文为翻译文章，点击查看原文。\n让我们来看看 Serverless 与容器的采用率、工具支持以及围绕 Serverless 和容器化的其他争论。\n在 Serverless 和容器中，我们有两种令人惊叹的技术，可以为工程师提供高效的，与机器无关的抽象。然而，两个阵营之间似乎存在着不可逾越的鸿沟。\n如果你读过我在过去两年写的任何内容，你就会知道我坚定地站在 Serverless 阵营。但我也是容器的早期采用者。在 Docker 达到 1.0 里程碑后不久，2015 年初我的第一个容器化项目问世。\n这篇文章不是为了再次引发阵营战争或宣布某个阵营的胜利。相反，我将尝试客观地看待 Serverless 和容器的状态，根据它们提供的利弊权衡，并对未来的情况给出诚实的看法。\n鉴于 Serverless 和 FaaS 函数即服务（FAAS）通常已经可以互换使用，为了本文的目的，我将限制 Serverless 的定义为 FAAS 产品，例如 AWS Lambda。\n容器状态 自从 Docker 早期可用以来已经走过了漫长的道路。随着我们在容器上运行的系统越来越复杂，我们的需求已经催生了丰富的工具生态系 …","relpermalink":"/blog/serverless-vs-containers/","summary":"本文介绍 Serverless 与容器的采用率、工具支持以及围绕 Serverless 和容器化的其他争论。","title":"Serverless vs Container——开发人员向左，DevOps 向右"},{"content":" 作为 Istio 教程第二篇文章本教程将一步步带领你熟悉指令并解释指令的作用。我们的前一篇文章解析了 istio 原理、示例，以及使用它给开发和运维带来的好处。我们也已经演示在如何在 kubernetes 集群安装 Service Mesh。\n在看这篇文章之前，如果你还没有 istio 的开发或测试集群，你可以使用我们自主开发的“Kublr in a box”工具，在 aws、azure 云环境或 VirtualBox 上运行的物理机上创建自己的 kubernetes 集群。\n启动至少两个节点的集群。可以按照“快速入门”指南在你的集群上安装 service mesh。\n安装完成后，你能在你的 kubernetes dashboard 的左侧边栏 pods 中查看已部署的 istio 组件。如下图所示：\n我们将会启动一个自动化 sidecar 注入器，避免手动将 Istio sidecar 配置添加到每个部署的本地 YAML 文件中。“istio kube-inject”命令我们在前面的教程中已经介绍过。如果你的 kubernetes 的版本小于 1.9，应该使用手动的方式执 …","relpermalink":"/blog/hands-on-canary-deployments-with-istio-and-kubernetes2/","summary":"作为 Kublr 推出的 Istio 教程第二篇文章本教程将一步步带领你熟悉 Istio 指令并解释指令的作用，并在 Kubernetes 集群中实现金丝雀部署。","title":"教程 | 使用 Istio 在 Kubernetes 集群中实现金丝雀部署"},{"content":"本文为翻译文章，点击查看原文。\n本文将带您了解为什么服务网格和边缘代理如此重要以及它们与持续交付的关系。\n了解现代云架构如何使用微服务具有的许多优势，使开发人员能够以 CI/CD 方式交付业务软件。\n去年，Matt Klein 写了一篇精彩的博客“服务网格中的数据平面与控制平面”。尽管我已经很熟悉“控制面板”这个术语，Matt 再次加深了我对这个概念的理解以及与软件持续交付有关的重要性，特别是在入口/边缘网关和服务网格周围的部署控制（和细微差别）方面。\n我之前写过关于边缘代理和 API 网关在软件交付中可以发挥的作用，持续交付：API 网关有什么作用？像 Envoy 这样的现代代理在“云原生”应用程序操作中所产生的影响，我们进行了几次讨论。我得出的结论是，尽管微服务为具有动态编排的容器和云技术的使用提供了新的机会，但是剩下的核心挑战就是控制平面必须进行调整才能跟上变化。\n控制平面和角色 在 Matt 的文章中，他指出服务网格控制平面“为网格中所有正在运行的数据平面提供策略和配置”，并且“控制平面将所有数据平面转变为分布式系统。”最终，控制平面的目标是设置将由数据平面制定的策略。控制平面 …","relpermalink":"/blog/the-importance-of-control-planes-with-service-mesh/","summary":"本文将带您了解为什么服务网格和边缘代理如此重要以及它们与持续交付的关系。","title":"服务网格的控制平面和边缘代理的重要性"},{"content":" 本文作者：彭泽文，阿里巴巴 UC 事业部高级开发工程师。\nsofamesh x-protocol dubbo X-protocol 的定位是云原生、高性能、低侵入性的通用 Service Mesh 落地方案，依托 Kubernetes 基座，利用其原生的服务注册和服务发现机制，支持各种私有 RPC 协议低成本、易扩展的接入，快速享受 Service Mesh 所带来的红利。\n本文将以 Dubbo 为例，演示 Dubbo on x-protocol 场景下 Service Mesh 路由功能，涵盖 Version route、Weighted route 功能。\n关于 x-protocol 的介绍请参考 蚂蚁金服开源的 SOFAMesh 的通用协议扩展解析。\n前期准备 安装 Minikube，推荐使用 Minikube v0.28 以上来体验，请参考 https://github.com/kubernetes/minikube 安装 kubectl 命令行工具， …","relpermalink":"/blog/dubbo-on-x-protocol-in-sofa-mesh/","summary":"本文将以 Dubbo 为例，演示 SOFAMesh 中 Dubbo on x-protocol 场景下 Service Mesh 路由功能，涵盖 Version route、Weighted route 功能。","title":"Dubbo on x-protocol——SOFAMesh 中的 x-protocol 示例演示"},{"content":" 以往有很多文章讲解 Istio 是如何做 Sidecar 注入的，但是没有讲解注入之后 Sidecar 工作的细节。本文将带大家详细了解 Istio 是如何将 Envoy 作为 Sidecar 的方式注入到应用程序 Pod 中，及 Sidecar 是如何做劫持流量的。\n在讲解 Istio 如何将 Envoy 代理注入到应用程序 Pod 中之前，我们需要先了解以下几个概念：\nSidecar 模式：容器应用模式之一，Service Mesh 架构的一种实现方式。 Init 容器：Pod 中的一种专用的容器，在应用程序容器启动之前运行，用来包含一些应用镜像中不存在的实用工具或安装脚本。 iptables：流量劫持是通过 iptables 转发实现的。 查看目前 productpage-v1-745ffc55b7-2l2lw Pod 中运行的容器：\n$ kubectl -n default get pod productpage-v1-745ffc55b7-2l2lw -o=jsonpath=\u0026#39;{..spec.containers[*].name}\u0026#39; productpage …","relpermalink":"/blog/envoy-sidecar-injection-in-istio-service-mesh-deep-dive/","summary":"以往有很多文章讲解 Istio 是如何做 Sidecar 注入的，但是没有讲解注入之后 Sidecar 工作的细节。本文将带大家详细了解 Istio 是如何将 Envoy 作为 Sidecar 的方式注入到应用程序 Pod 中，及 Sidecar 是如何做劫持流量的。","title":"理解 Istio Service Mesh 中 Envoy 代理 Sidecar 注入及流量劫持"},{"content":" Aspen Mesh 这家公司隶属于 F5，Aspen Mesh 基于 Istio 1.0 开发，这个周末刚发布了 1.0 版本，可以申请免费试用。\nAspen Mesh 对比 Istio 1.0 有如下优势：\n作为托管的 SaaS 平台 丰富的 UI dashboard 更多实验特性 可获得 Aspen Mesh 工程师团队的支持 Aspen Mesh 对比 Istio 1.0 有如下改进，主要集中在性能和可靠性上：\n现在可以递增地推出双向 TLS，而无需更新服务的所有客户端 在 Kubernetes 中创建 Istio 配置时就已经过验证。这是由 Galley 强制执行的 Kubernetes 准入控制器 webhook 针对服务和工作负载的更精确和全面的遥测 Mixer 现在支持进程外适配器，可以更轻松地与更多的后端集成 想要试用的话可以去Aspen Mesh 官网上申请。\n","relpermalink":"/blog/aspen-mesh-released/","summary":"Aspen Mesh 这家公司隶属于 F5，Aspen Mesh 基于 Istio 1.0 开发，上个周末刚发布了 1.0 版本，可以申请免费试用。","title":"F5 公司 Aspen Mesh 1.0 发布，基于 Istio 1.0"},{"content":" Kubernetes and Istio 本文为翻译文章，点击查看原文。\n作为一名全栈开发，假如最近花了不少时间开发应用，肯定已经理解了微服务架构下要面临的一系列全新挑战。尽管应用已经从庞大的单体应用转变成了开发更快、弹性更好、更小也更聚焦的微服务，但现实是，开发者需要开始操心将这些服务集成到分布式系统中的问题了，包括服务发现、负载均衡、注册、容错、监控、路由、兼容和安全等。\n让我们更详细的拆解微服务架构下开发和运维面临的挑战吧。先来看看第一代简单的 Service Mesh 场景，如下图所示，服务 A 要和 服务 B 通信，没有采用直接通信的方式，请求是通过 NGINX 路由的。NGINX 从 Consul（服务发现工具）查找路由，并在收到 HTTP 502 响应时，自动重试。\n图 1.0 - 一代 Service Mesh 图 1.1 - 服务增多时，级联失败演示 但随着微服务架构的到来，服务数量的增长一发不可收拾，下面列出的是开发和运维团队遇到的问题：\n如何让日益增长的微服务们互联？ 如何为微服务提供负载均衡？ 为微服务提供基于角色的路由； 如何控制微服务的出口流量，如何实现灰 …","relpermalink":"/blog/test-drive-your-first-istio-deployment-using-play-with-kubernetes-platform-cloud-computing/","summary":"在 Docker 提供的免费的 Kubernetes 试玩平台上，使用好奇心驱动的方式部署一个 Istio Service Mesh。本方式适合没有测试资源又不想自己整环境的，只是想上去爽一把的人士。","title":"在 Play with Kubernetes 平台上以测试驱动的方式部署 Istio"},{"content":" 关键要点 微服务架构仍然是分布式系统最流行的架构风格。但 Kubernetes 和云原生运动已经在很大程度上重新定义了应用程序的设计和开发。 在云原生平台上，服务的可观察性是不够的。更基本的先决条件是通过实施健康检查，对信号做出反应，声明资源消耗等，使微服务自动化。 在后 Kubernetes 时代，服务网格技术将完全取代使用库来实现操作网络问题（例如 Hystrix 断路器）。 微服务现在必须通过从多个维度实现幂等性来设计用于“恢复”。 现代开发人员必须精通编程语言以实现业务功能，并且同样精通云原生技术以满足非功能性基础架构级别要求。 微服务炒作开始于一堆关于组织结构、团队规模、服务规模、重写和抛出服务而不是修复、避免单元测试等的极端想法。根据我的经验，大多数这些想法被证明是错误的，不实用的或者至少不通用。如今，大多数剩余的原则和实践都是如此通用和松散地定义，以至于它们可能在未来许多年内都会成立，而在实践中却没有多大意义。\n在 Kubernetes 诞生的前几年微服务还是分布式系统最流行的架构风格。但 Kubernetes 和云原生运动已经改变了应用程序设计和开发的方方面面。在本文 …","relpermalink":"/blog/microservices-post-kubernetes/","summary":"在 Kubernetes 诞生的前几年微服务还是分布式系统最流行的架构风格。但 Kubernetes 和云原生运动已经改变了应用程序设计和开发的方方面面。在本文中，我要质疑微服务的一些理念，指明它们在后 Kubernetes 时代不会再像以前那样强大。","title":"后 Kubernetes 时代的微服务"},{"content":" Envoy Lyft 本文为翻译文章，点击查看原文。\n关键要点 在过去的四年中，Lyft 已从单体架构转变为数百个微服务。随着微服务数量的增加，由于级联故障或意外内部拒绝服务导致的中断次数也在增加。 今天，这些故障情况在 Lyft 基础设施中已经基本解决。Lyft 部署的每项服务都通过使用 Envoy 代理自动获得吞吐量和并发保护。 Envoy 可以作为中间件部署或仅在请求入口处部署，但最大的好处来自于在应用程序本地的入口和出口部署它。在请求的两端部署 Envoy 允许它充当服务器的智能客户端和反向代理。 在接下来的几个月里，Lyft 将与 Netflix 的并发限制库背后的团队合作，将基于其库的系统带入 Envoy L7 过滤器。 级联故障是高吞吐量分布式系统中不可用的主要原因之一。在过去的四年中，Lyft 已从单体架构转变为数百种微服务。随着微服务数量的增加，由于级联故障或意外内部拒绝服务导致的中断次数也在增加。今天，这些故障情况在 Lyft 基础设施中基本上已经解决。Lyft 部署的每项服务都会自动获得吞吐量和并发保护。通过对我们最关键的服务进行一些有针对性的配置更改，基于负载 …","relpermalink":"/blog/envoy-service-mesh-cascading-failure/","summary":"本文分享了 Lyft 对于 Envoy 的在服务网格领域的实践，主要为了解决级联故障的问题，以及 Lyft 对于 Envoy 的未来规划。","title":"Envoy 服务网格在 Lyft 的实践及未来路线图"},{"content":" 本文作者：邵俊雄（熊啸），蚂蚁金服中间件团队高级技术专家，目前主要负责 SOFAMesh 的开发工作。\n本文是基于作者在 Service Mesh Meetup #3 深圳的主题分享《SOFAMesh 的通用协议扩展》部分内容所整理，完整内容见文末的直播回放\n邵俊雄 蚂蚁金服 Service Mesh SOFA MOSN 本次分享主要介绍蚂蚁金服在 SOFAMesh 上开发对 SOFARPC 与 HSF 这两个 RPC 框架的支持过程中总结出来的通用协议扩展方案\n1. SOFAMesh 介绍 SOFAMesh 是蚂蚁从 ISTIO 上游克隆的开源项目，目的是在 ISTIO 的基础上进行控制平面的发展和创新，同时保持和上游 ISTIO 的同步更新，跟随 ISTIO 的发布节奏，当然也会把一些有价值能力贡献给 ISTIO 社区。\nSOFAMesh 的一个重要目标是用蚂蚁自研的 Golang 版 L4/L7 层代理服务器 SOFAMosn 作为数据平面，取代 C++ 开发的 ENVOY。之前的 Meetup 中我们已经探讨过了一个 Golang 版本的数据平面的重要性，我们相信统一控制平面 …","relpermalink":"/blog/ant-financial-sofamesh-common-protocol-extension/","summary":"本文作者是蚂蚁金服中间件团队的高级技术专家邵俊雄（熊啸），主要负责 SOFAMesh 的开发工作。本文是基于作者在 Service Mesh Meetup #3 深圳的主题分享《SOFAMesh 的通用协议扩展》部分内容所整理，完整内容见文末的直播回放。","title":"蚂蚁金服开源的 SOFAMesh 的通用协议扩展解析"},{"content":"本文为翻译文章，点击查看原文。\n本文为该教程的第 1 部分。\n如果你之前没有听说过 Service Mesh，不用担心。虽然从可用文档、公开讨论和 Github 活跃度来看，它是一个相对较新的技术，与基于容器和微服务架构相似还没有被广泛采用，但是它将会对软件架构带来深远影响。本文将帮助您了解 Service Mesh 的基础知识和教程，以及如何实现它并从基础架构获益。\nService Mesh 的两个主要目标是允许洞察先前不可见的服务通信层，并获取对所有微服务间像动态服务发现、负载均衡、超时、回退、重试、断路器、分布式调用链路追踪和安全策略的执行等通信逻辑的完全控制。更多细节请查看 Istio 流量审计和分布式链路追踪相关资料。\nKubernetes 已经拥有开箱即用的“Service Mesh”。它的“service”资源，提供了针对指定需要的 pod 的服务发现功能和请求的负载均衡。通过在集群的每个主机上配置管理 iptables 规则使一个“service”生效，只允许轮询式负载均衡途径，没有重试或回退逻辑，除此之外没有其他我们可能想要的用一个现代的 Service Mesh 解 …","relpermalink":"/blog/hands-on-canary-deployments-with-istio-and-kubernetes/","summary":"本文 kublr 出品的 Istio Service Mesh 教程的第 1 部分，主要讲解了 Istio 的部署和流量路由部分。","title":"教程 | 使用 Istio 实现一个 Service Mesh 以简化微服务间的通信模式"},{"content":" 本文为翻译文章，点击查看原文。\n本文原标题为：Istio 目标是成为容器化微服务的网状管道\n在精彩的软件容器世界中，原本早已解决的问题又有新的解决方案出现，给人有种恍惚的感觉。在许多情况下这些问题很久以前就得到了解决，但现代云原生架构的出现，推动部署更大规模的应用程序，这就需要新的工具和方法来管理这些服务。\n微服务就是一个很好的例子。在此模型下，典型的应用程序或服务将被分解为可独立部署的功能模块，这些模块可以彼此分开扩展和维护，并且链接在一起以提供整个应用程序或服务的全部功能。\n在使用容器开发微服务时，后者可能是比较棘手的部分。当所有组件可能分布在服务器节点集群中，并且它们的实例不断上线并被更新的版本替换时，如何将它们连接起来？在面向服务的体系结构（SOA）中，微服务可以被看作是进化的继承者，这种任务类似于企业服务总线（ESB）所处理的任务。因此，我们需要的是 ESB 的云原生版本。\n这是一个相对较新的开源项目Istio旨在填补的工作。它被正式描述为服务网格，因为它的一部分与基础设施一起分布在它管理的容器旁边，并且它开始着手满足服务发现、负载均衡、消息路由、遥测和监控的要求，当然还有 …","relpermalink":"/blog/istio-aims-to-be-the-mesh-plumbing-for-containerized-microservices/","summary":"本文主要是 IBM 研究员兼云计算 CTO Jason McGee 对 Istio 项目的起源、分工与目标的解说。","title":"IBM 云计算 CTO 讲述 Istio 项目的起源、分工及目标"},{"content":" Cilium 本文为翻译文章，点击查看原文。\n我们很高兴地宣布推出 Cilium 1.2。该版本引入了几个新功能实现了 Cilium 用户和社区成员最迫切想要的功能。其中最吸引人的功能之一是引入基于 DNS 名称的安全策略，目的是保护对集群外服务的访问。另一个最受关注的问题是加入了连接和保护多个 Kubernetes 集群的能力。我们将 ClusterMesh 功能进入 Alpha 版本。它可以连接和保护在多个 Kubernetes 集群中运行的 pod。Kube-router 与 Cilium 的集成同等重要。DigitalOcean 团队的努力使 kube-router 提供 BGP 网络与 Cilium 提供的基于 BPF 的安全性和负载均衡相结合。整个 Cilium 开发者社区贡献者总数已增加到 85 个，在 1.1 到 1.2 版本内贡献了 579 个 PR。\nCilium 是什么？ Cilium 是一个开源软件，用于在 Kubernetes、Docker 和 Mesos 等 Linux 容器管理平台部署的应用程序服务之间提供透明连接、保护网络和 API。\nCilium 是 …","relpermalink":"/blog/cilium1-2-dns-security-policies-eks-support-clustermesh-kube-router-integration/","summary":"Cilum 使用 Kube-router 在 Kubernetes Pod 与集群外部运行的服务之间建立连接，再引入基于 DNS 名称的安全策略保护对集群外服务的访问，再增加 Cluster Mesh 增加对多 Kubernetes 集群的支持。","title":"Cilium 1.2 发布—DNS 安全性策略、EKS 支持、ClusterMesh、kube-router 集成等"},{"content":" Service Mesh Meetup 深圳站 ServiceMesher 社区和蚂蚁金服联合主办、SOFAStack 社区协办的第三届 Service Mesh Meetup 深圳站收官，感谢各位现场参加和通过 IT 大咖说观看直播的同学参与 ServiceMesher 社区，华为张超盟、蚂蚁金服熊啸、JEX 杨文、联邦车网朱经惠的分享，深圳名堂共创空间提供场地支持，vivo 的两位美女志愿者，电子工业出版社提供图书。更多活动信息和 Service Mesh 资讯请关注我们的微信公众号 ServiceMesher。\n相关资料 本次活动的视频回放，请访问IT 大咖说。\nPPT 下载地址：https://github.com/servicemesher/meetup-slides\n现场照片 场地提供方，名堂共享空间。\n来自 Vivo 的两位美女志愿者\n到现场参加的有 100 多人。\n通过IT 大咖说在线观看的有几千人。\n张超盟（华为）——Kubernetes 容器应用基于 Istio 的灰度发布实践 Service Mesh 张超盟 华为 现场提问的观众。\n朱经惠（联邦车 …","relpermalink":"/blog/service-mesh-meetup-shenzhen-20180825/","summary":"ServiceMesher 社区和蚂蚁金服联合主办、SOFAStack 社区协办的第三届 Service Mesh Meetup 深圳站收官，华为张超盟、蚂蚁金服熊啸、JEX 杨文、联邦车网朱经惠给大家带来分享。","title":"第三届 Service Mesh Meetup 深圳站回顾"},{"content":"讲师与演讲话题 张超盟（华为）——Kubernetes 容器应用基于 Istio 的灰度发布实践\nTopic 摘要：随着 1.0 版本在上月底的发布，标志着 Istio 作为最火热的 ServcieMesh 框架已经逐渐成熟。本次议题中将以典型的灰度发布为例，分享华为云容器服务在 Istio 的实践，以及 Istio 和 Kubernetes 的完美结合释放云原生应用的核心优势，加速企业微服务技术转型。\n讲师简介：华为云微服务平台架构师，现负责华为云容器服务 Istio 产品化工作。参与华为 PaaS 平台产品设计研发，在 Kubernetes 容器服务、微服务架构、云服务目录、大数据、APM、DevOpS 工具等多个领域有深入研究与实践。曾供职于趋势科技。\n朱经惠（联邦车网）——Istio 控制平面组件原理解析\nTopic 摘要：网上有很多关于 Istio 的介绍，但主要的关注是数据平面。所以这次独辟蹊径，给大家解密 Istio 里强大的控制平面：管理生命周期的 Pilot-Agent，配置中心 Pilot-Discovery，生成遥测报告的 Mixer …","relpermalink":"/event/service-mesh-meetup-03/","summary":"这是第三届 Service Mesh Meetup。","title":"Service Mesh Meetup #3 深圳站"},{"content":"我最近在讨论集成服务的演进以及服务网格的使用，特别是关于 Istio。自从 2017 年 1 月我听说了 Istio 以来，我一直很兴奋，事实上我是为这种新技术感到兴奋，它可以帮助组织构建微服务以及原生云架构成为可能。也许你可以说，因为我已经写了很多关于它的文章（请关注 @christianposta 的动态)：\nThe Hardest Part of Microservices: Calling Your Services Microservices Patterns With Envoy Sidecar Proxy: The series Application Network Functions With ESBs, API Management, and Now.. Service Mesh? Comparing Envoy and Istio Circuit Breaking With Netflix OSS Hystrix Traffic Shadowing With Istio: Reducing the Risk of Code Release Advanced …","relpermalink":"/blog/application-safety-and-correctness-cannot-be-offloaded-to-istio-or-any-service-mesh/","summary":"Istio 和服务网格的总体目标是解决应用程序网络类问题。将这些问题的解决方案迁移到服务网格中是可操作性的优化。但这并不意味着它不再是应用程序的责任，而是意味着这些功能的实现存在于进程之外了，并且必须是可配置的。","title":"应用程序安全性和正确性的责任不能推卸给 Istio 和任何服务网格"},{"content":" 这是我在 kubernetes 之上部署 Istio 系列文章中的第三篇，内容是关于我们试图通过 Vamp Lamia 实现的更多细节以及我们为什么选择 Istio 的原因，可以查看我的第一篇和第二篇文章。\n在 Vamp.io，我们正在开发 Vamp Lamia，以帮助您轻松地将您的服务连接到需要 SSL/TLS 连接的现实世界。最近，许多浏览器和其他技术开始强制实施 SSL 连接。用户使用谷歌浏览器访问 HTTP 链接将给予警告，Android 现在默认也需要安全连接。\n在过去，从权威机构获取证书是一项艰难而费事的过程。所以需要一种简便常规的解决方案。Let’s Encrypt免费提供了SSL/TLS认证获取的最佳实践。以下是Let’s Encrypt 的官方使命。\nLet’s Encrypt 是一个免费、自动化和开放的证书颁发机构（CA），为公众的利益而运行。它是由 Internet Security Research Group（ISRG）提供的服务。我们为用户提供所需的数字证书，以便以更友好的方式免费为网站启用 HTTPS（SSL/TLS）。我们这样做是因为我们想要创建一个更 …","relpermalink":"/blog/securing-ingress-services-in-istio-with-lets-encrypt-on-kubernetes/","summary":"这是 Vamp 在 kubernetes 之上部署 Istio 系列文章中的第三篇，内容是关于 Vamp 试图通过 Vamp Lamia 实现的更多细节以及我们为什么选择 Istio 的原因。","title":"使用 Let’s Encrypt 在 Kubernetes 上保护 Istio 的 Ingress 服务"},{"content":" 本文为翻译文章，点击查看原文。\nGoogle Cloud 采用了 Istio 服务网格技术来管理微服务，这可能比 Kubernetes 和无服务器产生更大的影响。\n随着现代数字计算基础设施的不断发展，新的自动化层加速了创新和提升了适应性。一旦实现容器化微服务几秒之内部署一个新功能成为可能。那么 Kubernetes 和类似工具的出现增加了一层业务流程，以便大规模协调容器部署。在基础设施中一个功能很容易抽象成为一个满足需求的 serverless 模型。现在，正在形成一个称为“service mesh”的新层，以便在所有这些功能中添加服务间治理、管理和通信功能。8 月 1 号一个名为 Istio 的 service mesh 的新开源框架 1.0 版本发布生产版本，像之前的 Kubernetes 一样，由谷歌以及 IBM 支持。\n比 Kubernetes 更有价值 您可能没有听说过 Istio，但如果您进行任何形式的敏捷数字开发或运维工作，您很快就会知道 Istio。Google 云计算 CTO（UrsHölzle）上周告诉我，他预计 service mesh 将会被普遍采用：“我希望 …","relpermalink":"/blog/google-istio-bigger-kubernetes-serverless/","summary":"Google Cloud 采用了 Istio 服务网格技术来管理微服务，这可能比 Kubernetes 和无服务器产生更大的影响。你可以在任何你喜欢的云提供商之间自由迁移，且使你上云之路更加平稳。一旦人们熟悉了 Kubernetes 和 Istio 的管理和编排方式，上云就不会变得可怕了。","title":"Google 加持 Istio：这可能比 Kubernetes 和 Serverless 产生更大影响力"},{"content":" 追本溯源，Service Mesh 实际上是一种 SDN，等同于 OSI 模型中的会话层。每一次技术变革，必然要导致生产力和生产关系的变革，我们看到这种趋势正在加速。本书中给出了企业上 Service Mesh 的路径，可供广大技术和管理人员参考。\n这是一本由 Nginx 赞助，O’Reilly 出版社出品的关于服务网格的书籍，本书标题是 The Enterprise Path to Service Mesh，还有个副标题 Decoupling at Layer 5，第一版发行于 2018 年 8 月 8 日。这本书一共 61 页，本文是我对该书的一些解读，读者可以在Nginx 的网站上免费下载阅读完整内容。\n关于作者 本书作者是Lee Calcote，先后在 Cisco、Seagate、Solarwind 任职负责技术战略决策，参与 DMTF（Distributed Management Task Foundation）、CIS（Center for Internet Security），还是 CNCF Ambassador、Docker Captain。\nThe …","relpermalink":"/blog/the-enterprise-path-to-service-mesh-architectures/","summary":"本文是对 Lee Calcote 的 The Enterprise path to Service Mesh Architectures 一书的解读。追本溯源，Service Mesh 实际上是一种 SDN，等同于 OSI 模型中的会话层。","title":"企业级服务网格架构之路解读之 Service Mesh 在会话层解耦"},{"content":"以下的的性能报告为 SOFAMosn 0.1.0 在做 Bolt 与 HTTP1.x 协议的纯 TCP 转发上与 envoy 的一些性能对比数据，主要表现在 QPS、RTT、失败率/成功率等。\n本文原文来自 GitHub。\n这里需要强调的是，为了提高 SOFAMosn 的转发性能，在 0.1.0 版本中，我们做了如下的一些优化手段：\n在线程模型优化上，使用 worker 协程池处理 stream 事件，使用两个独立的协程分别处理读写 IO 在单核转发优化上，在指定 P=1 的情况下，我们通过使用 CPU 绑核的形式来提高系统调用的执行效率以及 cache 的 locality affinity 在内存优化上，同样是在单核绑核的情况下，我们通过使用 SLAB-style 的回收机制来提高复用，减少内存 copy 在 IO 优化上，主要是通过读写 buffer 大小以及读写时机和频率等参数的控制上进行调优 以下为具体的性能测试数据。\nTCP 代理性能数据 这里，针对相同的部署模式，我们分别针对上层协议为 \u0026#34;Bolt(SofaRpc相关协议)\u0026#34; 与 \u0026#34;HTTP1.1\u0026#34; 来进行对比\n部署模式  …","relpermalink":"/blog/sofa-mosn-performance-report-0-1-0/","summary":"以下的蚂蚁金服开源的 SOFAMosn 0.1.0 版本的性能报告，在做 Bolt 与 HTTP1.x 协议的纯 TCP，转发上与 Envoy 的一些性能对比数据、主要表现在 QPS、RTT、失败率/成功率等。","title":"蚂蚁金服开源 Go 语言版 Service Mesh 数据平面 SOFAMosn 性能报告"},{"content":"如果您要拆分单体架构，使用 Istio 管理您的微服务的一个巨大优势是，它利用与传统负载均衡器和应用分发控制器类似的入口模型的配置。\n在负载均衡器领域，虚拟 IP 和虚拟服务器一直被认为是使运营商能够以灵活和可扩展的方式配置入口流量的概念（Lori Macvittie 对此有一些相关的想法)。\n在 Istio 中，Gateway控制网格边缘的服务暴露。Gateway 允许用户指定 L4-L6 设置，如端口和 TLS 设置。对于 Ingress 流量的 L7 设置，Istio 允许您将网关绑定到VirtualServices。\n这种分离使得管理流入到网格的流量变得容易，就像在传统负载均衡器中将虚拟 IP 绑定到虚拟服务器一样。这使得传统技术栈用户能够以无缝方式迁移到微服务。对于习惯于整体和边缘负载均衡器的团队来说，这是一种自然的进步，而不需要考虑全新的网络配置方式。\n需要注意的一点是，在服务网格中路由流量和将外部流量引入网格不同。在网格中，您在正常流量中分辨异常的部分，因为只要在服务网格内，默认情况下 Istio 可以与（与 Kubernetes 兼容）所有应用通信。如果您不希望与某些服 …","relpermalink":"/blog/why-you-should-care-about-istio-gateways/","summary":"在 Istio 中，Gateway 控制网格边缘的服务暴露。Gateway 允许用户指定 L4-L6 设置，如端口和 TLS 设置。对于 Ingress 流量的 L7 设置，Istio 允许您将网关绑定到 VirtualServices。","title":"为什么你应该关心 Istio gateway"},{"content":" 本文为翻译文章，点击查看原文。\n8 月 1 日 Istio 1.0 发布，Cilium 社区感谢所有 Istio 贡献者为此付出的巨大努力。我们很幸运能够参与社区活动，为 Istio 做出贡献，并帮助一些用户通过 Istio 和 Cilium 进行生产部署。如果您有兴趣在深入了解技术细节之前了解 Istio + Cilium 的用户故事，请考虑阅读 HP FitStation 团队（最大的 Cilium + Istio 用户之一）发布的以下 Istio 博客：Istio 是惠普 FitStation 平台的游戏规则的改变者。\n本博客将介绍 BPF 和 Cilium 如何增强 Istio 的一些细节：\n增强安全 使用 socket 感知 BPF 程序为多容器 pod 提供最小权限 防止受损的 sidecar 代理和绕过 sidecar 协议 使用 BPF 强制所有应用程序流量经过 sidecar 代理 开启 Istio 对外部服务的支持 使用 socket 感知 BPF 程序和 kTLS 提供 TLS 链接加密的可视化和控制管理 性能 高效网络和 socket 重定向加速 istio  …","relpermalink":"/blog/how-cilium-enhances-istio-with-socket-aware-bpf-programs/","summary":"本博客将介绍 BPF 和 Cilium 如何增强 Istio 的一些细节，主要关注 Istio 的安全性，开启 Istio 对外部服务的支持和性能部分。","title":"使用 Cilium 增强 Istio—通过 Socket 感知 BPF 程序"},{"content":" 本文为翻译文章，点击查看原文。\n金融服务公司通常都拥有沉重的历史包袱，当然对于想要进入这个行业的新秀来说也算是商业壁垒，因为他们很难突破低利润和严苛的监管规则。曾占主导地位的大型金融企业的市场份额正面临着比起小巧、灵活的小金融科技公司的蚕食。这些小科技公司技术嗅觉灵敏、专业、注重客户用户体验。为了保持良好的竞争优势，金融服务公司都计划将自己原有的繁杂的技术架构向更具适应性的方向转变。最近对金融机构的一项调查发现大约 85％的人认为他们的核心技术过于僵化和缓慢。因此，预计在未来五年内约有 80％的金融机构打算替换其核心银行系统架构。\n金融新法则旨在解决新的数字支付问题。例如在欧洲的 PSD2（支付服务指令法则），要求银行采用新的运营方式和交付方式。像 PSD2 这样的变化旨在将银行业带入开放的 API 共享经济，通过开放标准推动互操作性和集成。要成为数据开放、无缝集成、API 共享的世界一流金融科技需要借助微服务的力量。\n微服务为金融服务提供了三个关键优势 增加安全性\n现代金融科技发展过程中给此前已建立的安全基础设施带来挑战。如数字钱包、智能机器人咨询服务和区块链等要求建立新的安全机 …","relpermalink":"/blog/enabling-the-financial-services-shift-to-microservices/","summary":"随着初创金融科技公司的竞争，以及客户期望的不断增长，成熟的金融服务公司必须改变他们提供产品和与客户开展业务的方式。在交付层面老系统很难满足这些要求，金融服务公司需要一套灵活、适应性强、可扩展性高、可靠且强大的软件架构。微服务使其成为可能，而服务网络正好满足了微服务大规模管理的需求。 ","title":"服务网格加速金融科技向微服务转型"},{"content":" 我们都是知道 Kubernetes 中个资源对象叫 autoscaler，该对象在 serverless 架构中更是不可或缺，有了它可以负责应用的自动水平伸缩，用户再也不用关心示例的个数和资源消耗，本文是来自阿里巴巴 UC 事业群基础研发部的陈有坤同学对 Knative 的解析之 autoscaler 部分，还有大量的解析等待放出，起关注本站的后续内容。\nKnative是一款基于 Kubernetes 的平台，用来构建、部署和管理现代 serverless 应用的框架。该框架试图将云原生应用开发的以下三个领域的最佳实践结合起来：\n构建容器（和函数） 为工作负载提供服务（和动态扩展） 事件 Knative 是由谷歌与Pivotal、IBM、Red Hat 和SAP紧密协作开发的。 Knative 构建在 Kubernetes 和Istio之上，它的设计考虑到了多种角色通过该框架进行交互，包括开发人员、运维人员和平台提供者。\nKnative 所涉及的角色（图片来源于Knative GitHub 仓库）\nKnative 致力于提供可重用的“通用模式和最佳实践组合”实现，目前可用的组件包括： …","relpermalink":"/blog/knative-serving-autoscaler-single-tenancy-deep-dive/","summary":"我们都是知道 Kubernetes 中个资源对象叫 autoscaler，该对象在 serverless 架构中更是不可或缺，有了它可以负责应用的自动水平伸缩，用户再也不用关心示例的个数和资源消耗，本文是来自阿里巴巴 UC 事业群基础研发部的陈有坤同学对 Knative 的解析之 autoscaler 部分。","title":"基于 Kubernetes 和 Istio 的 Serverless 框架 Knative 解析之 Autoscaler"},{"content":"8 月 1 日 0 点，Istio 1.0 发布，已生产就绪！大家都已经跃跃欲试了，几天前我发布了一键在本地搭建运行 Istio 1.0 的分布式 Kubernetes 集群教程，在本地搭建起来还是有些门槛，稍显复杂，现在我推荐几个可以在线上学习的地方。这是目前搜集的比较完整的 Istio 学习环境和包含代码的示例教程有如下几个：\n目前搜集的比较完整的 Istio 学习环境和包含代码的示例教程有如下几个：\nKatacoda 的学习环境 Istio 官方的 bookinfo 教程 IBM 的 Istio 示例教程 我 Fork 的 RedHat 的 Demo，Christian Posta 在 OSCON 上的 Istio workshop Katacode 上的 Istio 学习环境 推荐指数：⭑⭑⭑⭑⭑\n推荐原因：使用简单，使用官方示例，免费，快速，无需注册，可直接通过互联网访问示例应用页面，支持最新版的 Istio。\nKatacoda 已支持 Istio 1.0 的学习环境。\n地 …","relpermalink":"/blog/istio-tutorials-collection/","summary":"给大家推荐下，目前本人搜集到的可以说是最完整的 Istio 学习环境和包含代码的示例教程。","title":"Istio service mesh 示例教程汇总"},{"content":"本文为翻译文章，点击查看原文。\nIT 团队能否只使用一种工具，使开发人员能够专注于编写应用程序代码，使管理员只专注于 IT 资源的管理？使用 Istio 可以实现，尽管如此，采纳 Istio 前确实需要研究下它的利弊。\nKubernetes 是一个开源容器编排系统，它提供了管理和扩展容器化应用程序的强大功能，但有些事情它不能很好地完成。而 Istio 增加了额外的支持，它可以管理微服务之间的流量。\nIstio 服务网格项目是平台无关的，协作和开源的，由 IBM、Google 和 Lyft（基于应用程序的传输服务）开发。它使用代理 sidercar 模型在云平台上连接、保护、管理和监控微服务网络。Istio 明确定义了基础架构的作用，与运行在其上的软件分离。\n集成 Istio 的利弊 编排工具 Kubernetes 与 Istio 的整合，可以让开发人员和 IT 管理员在应用程序容器化这一共同目标上一起努力，IT 管理软件提供商 SolarWinds 的首席软件架构师 Karlo Zatylny 表示：“软件开发人员将注意力集中在编写能够创造最大商业价值的代码上”。他们不需要考虑部署因 …","relpermalink":"/blog/istio-service-mesh-tech-boosts-kubernetes-work-with-trade-offs/","summary":"本文中各位分析师给出了采纳在 Kubernets 上运行的 Istio service mesh 的利弊分析。","title":"采纳运行在 Kubernetes 上的 Istio 服务网格的利弊分析"},{"content":"本文为翻译文章，点击查看原文。\nSidecar 设计模式已经越来越受欢迎，并在社区内得到更广泛的采用。构建具有高度可扩展性、弹性、安全性和可观察性的微服务架构具有挑战性。Service Mesh 架构的发展已经改变了游戏规则。它降低了与微服务架构相关的复杂性，并提供了许多功能，如负载平衡、服务发现、流量管理、熔断、遥测、故障注入等。\n阅读我之前的博客能够了解 Service Mesh 的概念，为什么云原生应用需要它以及它受欢迎的原因——服务网格架构的兴起。\n什么是 Sidecar 模式 将应用程序的功能划分为单独的进程可以被视为 Sidecar 模式。Sidecar 设计模式允许你为应用程序添加许多功能，而无需额外第三方组件的配置和代码。\n就如 Sidecar 连接着摩托车一样，类似地在软件架构中，Sidecar 应用是连接到父应用并且为其扩展或者增强功能。Sidecar 应用与主应用程序松散耦合。\n让我用一个例子解释一下。想象一下假如你有 6 个微服务相互通信以确定一个包裹的成本。\n每个微服务都需要具有可观察性、监控、日志记录、配置、断路器等功能。所有这些功能都是根据一些行业标准的第 …","relpermalink":"/blog/sidecar-design-pattern-in-microservices-ecosystem/","summary":"Sidecar 设计模式已经越来越受欢迎，并在社区内得到更广泛的采用。构建具有高度可扩展性、弹性、安全性和可观察性的微服务架构具有挑战性。Service Mesh 架构的发展已经改变了游戏规则。它降低了与微服务架构相关的复杂性，并提供了许多功能，如负载平衡、服务发现、流量管理、熔断、遥测、故障注入等。","title":"微服务中的 Sidecar 设计模式解析"},{"content":"MOSN GitHub 地址：https://github.com/sofastack/mosn\n本文作者：朵晓东，花名奕杉，蚂蚁金服高级技术专家，专注云计算技术及产品。Apache Kylin 创始团队核心成员，蚂蚁金融云 PaaS 创始团队核心成员，Antstack 网络产品负责人，SOFAMesh 创始团队核心成员。\n朵晓东 service mesh meetup 本文是基于作者在第二届 Service Mesh Meetup 的主题分享《蚂蚁金服 Service Mesh 数据平面 SOFAMosn 深层解密》部分内容所整理，以下是具体内容。关于本次 meetup 的情况请访问第二届 Service Mesh Meetup 北京站回顾。\n前言 今天给大家带来的分享内容是蚂蚁金服 Service Mesh 数据平面 SOFAMosn 深层揭秘。\n承接小剑老师月初《大规模微服务架构下的 ServiceMesh 探索之路》对 SOFAMosn 的分享，本次聚焦在数据平面在蚂蚁落地的思考和探索。\n背景 上一次分享小剑老师已经介绍了 SOFAMesh 的技术选型，以及我们在开源和自研方面 …","relpermalink":"/blog/sofa-mosn-deep-dive/","summary":"本文基于蚂蚁金服高级技术专家朵晓东在第二届 Service Mesh Meetup 北京站分享的部分内容所整理。","title":"Service Mesh 数据平面 SOFAMosn 深层揭秘"},{"content":" 本文转载自：Istio 官方网站，点击阅读原文。\n今天，我们很高兴地宣布 Istio 1.0。这距离最初的 0.1 版本发布以来已经过了一年多时间了。从 0.1 起，Istio 就在蓬勃发展的社区、贡献者和用户的帮助下迅速发展。现在已经有许多公司成功将 Istio 应用于生产，并通过 Istio 提供的洞察力和控制力获得了真正的价值。我们帮助大型企业和快速发展的创业公司，如 eBay、Auto Trader UK、Descartes Labs、HP FitStation、Namely、PubNub 和 Trulia 使用 Istio 从头开始连接、管理和保护他们的服务。将此版本作为 1.0 发布是对我们构建了一组核心功能的认可，用户们可以依赖这些功能进行生产。\n生态系统 去年，我们看到了 Istio 生态系统的大幅增长。Envoy 继续其令人印象深刻的增长，并增加了许多对生产级别服务网格至关重要的功能。像 Datadog、 SolarWinds、 Sysdig、Google Stackdriver 和 Amazon CloudWatch …","relpermalink":"/blog/announcing-istio-1-0/","summary":"今天，我们很高兴地宣布 Istio 1.0。这距离最初的 0.1 版本发布以来已经过了一年多时间了。从 0.1 起，Istio 就在蓬勃发展的社区、贡献者和用户的帮助下迅速发展。现在已经有许多公司成功将 Istio 应用于生产，并通过 Istio 提供的洞察力和控制力获得了真正的价值。","title":"Istio 1.0 发布，已生产就绪！"},{"content":"2018 年 7 月 29 日，周日，天气闷热，北京中关村 e 世界。\n由 ServiceMesher 社区和蚂蚁金服联合举办的，Sharding-Sphere 社区、Apache SkyWalking 社区、SOFA 社区、新浪微博协办的第二届 Service Mesh Meetup 北京站圆满落幕。\nService Mesh Meetup 张亮（京东金融数据研发负责人）Service Mesh 的延伸 —— 论道 Database Mesh\n张亮 京东金融 Service Mesh Meetup 张亮 京东金融 Service Mesh Meetup 吴晟（Apache SkyWalking 创始人），Observability on Service Mesh —— Apache SkyWalking 6.0\n吴晟 Apache SkyWalking 朵晓东（蚂蚁金服，高级技术专家），蚂蚁金服开源的 Service Mesh 数据平面 SOFA MOSN 深层揭秘\n朵晓东 蚂蚁金服 Service Mesh 朵晓东 Service Mesh 蚂蚁金服 丁振凯（新浪微博，微博搜索架构 …","relpermalink":"/blog/beijing-meetup-20180729/","summary":"2018 年 7 月 29 日，北京，中关村 e 世界，由 ServiceMesher 社区和蚂蚁金服联合举办的，Sharding-Sphere 社区、Apache SkyWalking 社区、SOFA 社区、新浪微博协办的第二届 Service Mesh Meetup 北京站圆满落幕。","title":"第二届 Service Mesh Meetup 北京站回顾"},{"content":"讲师与演讲话题 张亮（京东金融数据研发负责人）：Service Mesh 的延伸 —— 论道 Database Mesh\n个人简介：张亮，京东金融数据研发负责人。热爱开源，目前主导两个开源项目 Elastic-Job 和 Sharding-Sphere(Sharding-JDBC)。擅长以 java 为主分布式架构以及以 Kubernetes 和 Mesos 为主的云平台方向，推崇优雅代码，对如何写出具有展现力的代码有较多研究。2018 年初加入京东金融，现担任数据研发负责人。目前主要精力投入在将 Sharding-Sphere 打造为业界一流的金融级数据解决方案之上。\n随着 Service Mesh 概念的推广与普及，云原生、低接入成本以及分布式组件下移等理念，已逐渐被认可。在 Service Mesh 依旧处于高速迭代的发展期的同时，以它的理念为参考，其他的 Mesh 思想也在崭露萌芽。Database Mesh 即是 Service Mesh 的其中一种延伸，虽然理念与 Service Mesh 相近，但数据库与无状态的服务却有着巨大的差别。Database Mesh 与分布式数 …","relpermalink":"/event/service-mesh-meetup-02/","summary":"这是第二届 Service Mesh Meetup。","title":"Service Mesh Meetup #2 北京站"},{"content":"本文为Service Mesh深度学习系列之一：\nService Mesh 深度学习系列 part1—istio 源码分析之 pilot-agent 模块分析 Service Mesh 深度学习系列 part2—istio 源码分析之 pilot-discovery 模块分析 Service Mesh 深度学习系列 part3—istio 源码分析之 pilot-discovery 模块分析（续） 本文分析的 istio 代码版本为 0.8.0，commit 为 0cd8d67，commit 时间为 2018 年 6 月 18 日。\npilot 总体架构 首先我们回顾一下 pilot 总体架构，上面是官方关于 pilot 的架构图，因为是 old_pilot_repo 目录下，可能与最新架构有出入，仅供参考。所谓的 pilot 包含两个组件：pilot-agent 和 pilot-discovery。图里的 agent 对应 pilot-agent 二进制，proxy 对应 Envoy 二进制，它们两个在同一个容器中，discovery service …","relpermalink":"/blog/istio-service-mesh-source-code-pilot-discovery-module-deepin-part2/","summary":"本文是谐云科技 CTO 丁轶群博士对 Istio 0.8 版本代码中的 pilot-discovery 的深度源码解析续篇。","title":"Service Mesh 深度学习系列 part3—istio 源码分析之 pilot-discovery 模块分析（续）"},{"content":"本文为翻译文章，点击查看原文。\n我们都知道微服务会增加复杂性。了解服务网络如何解决这一问题和其他挑战。\n我最近正在阅读 Dimensional Research 撰写的全球微服务趋势报告，在阅读的同时，我个人也认为“服务网络可以帮助解决这个问题。”所以我将阐述这 3 个挑战以及服务网格是如何解决它们。报告中引用的受访者表明微服务正在得到广泛采用。同样清楚的是，除了微服务带来的无数好处之外，同样也带来了一些严峻的挑战。报告显示：\n91％的企业正在使用微服务或有计划使用 99％的用户认为在使用微服务时遇到了挑战 微服务主要的挑战 该报告指出了公司面临的一系列挑战。\n大量公司既面临着技术上的挑战，同时也面临着组织结构上的挑战。而我将专注于能够用服务网格解决的技术挑战，但值得注意的是，服务网格所做的一件事就是带来一致性，因此可以在团队之间实现相同的愿景，从而减少对某些技能的需求。\n每个额外的微服务都会增加运维的难度 如果没有服务网格，这句话将成为现实！服务网格可以通过 API 提供监控，可伸缩性和高可用性，而不是通过分离设备。这种灵活的框架消除了与现代应用相关的操作复杂性。基础设施服务传统上是 …","relpermalink":"/blog/how-service-mesh-addresses-3-major-microservices/","summary":"本文讲述的是企业在实施微服务时遇到的挑战，以及如何使用 Service Mesh 应对这些挑战。","title":"Service Mesh 如何解决微服务中的 3 个主要挑战"},{"content":"本文为翻译文章，点击查看原文。\n容器是 IT 行业的超级英雄，它与服务网格是最佳组合。它们联手对抗混乱的网络管理。\n容器和微服务出现催生了一种称为服务网格的新型网络架构范例，但 IT 观察家们对它是否能够广泛应用到生产上持有不同意见。\n服务网格使用一个称为 sidecar 的代理，它是附加在应用程序旁、虚拟机或运行在 Kubernetes 的 pod 中的容器，具体运行在哪里取决于所使用的服务网格的类型。然后，该代理可以连接到集中式的控制平面软件，这些软件收集细粒度的网络遥测数据，应用网络管理策略或更改代理配置，建立并执行网络安全策略。\nIT 系统中的服务网格架构还处于初期阶段，但与容器一样它上升的很快。在 2017 年 12 月云原生计算基金会（CNCF）举办的 KubeCon 和 CloudNativeCon 上，服务网格已经取代容器成为 DevOps 前沿最热门的话题。\n“我们经常发现自己在构建应用软件时，我们实际上在做的是一遍又一遍地编写相同的代码来解决某些实际上非常困难的计算机科学问题，这些问题应该被考虑到某种通用接口中”，微服务监控创业公司 LightStep …","relpermalink":"/blog/service-mesh-architecture-radicalizes-container-networking/","summary":"本文将是您了解和评估何时以及如何采纳服务网格的最佳参考资料。本文回顾了服务网格的历史，并采访了创造 Service Mesh 一词的 Buoyant 创始人，Istio 的产品经理，Enovy 的架构师 Matt Klein，分别就谁应该何时以何种方式采纳服务网格给出了意见并展望了服务网格的未来。","title":"服务网格架构激活了容器网络管理—来自于服务网格创建者们的见解与展望"},{"content":"本文为翻译文章，点击查看原文。\n注：这是介绍服务网格的软件架构方面系列的第二篇文章。要了解更多，请查看服务网格之路。\n如果你正在围绕微服务构建软件和团队，并且在寻找更快、更灵活的迭代方法。Service Mesh 可以在保持（或增强）系统可观察性和控制方面带来帮助。这篇博文中，我将讨论 Service Mesh 是什么，以及在选择和部署 Service Mesh 时需要考虑的因素。\n那么，什么是 Service Mesh？它与现有的架构有什么不同？Service Mesh是运行在请求/响应上层的通信层，对于构建微服务有以下几点帮助：\n不对安全边界做出假设的零信任安全原则。 跟踪微服务间的通讯。 故障注入和容错，可以让您通过实验验证应用的弹性。 高级的服务路由可以做到如A/B测试、快速版本控制和部署以及流量复制。 为什么又发明一个新术语？ 看了上面那个列表，你可能会想“如果没有 Service Mesh，我照样可以做到这一切”，你是对的。滑动窗口协议或请求框架也是这个逻辑。但是，一旦有符合需求的新兴标准出现，那么使用该标准比自己实现会更有效。Service Mesh 是微服务模式的新的层 …","relpermalink":"/blog/service-mesh-architectures/","summary":"这是介绍服务网格的架构系列的第二篇文章，本文讲解了 Service Mesh 术语的含义，为什么说节点代理和 Sidecar 模型是微服务的新模式和未来。","title":"Service Mesh 架构解析"},{"content":" 本文英文原文最初发表时间：2017 年 12 月 6 日\nCirconus 参与开源软件有着悠久的传统。因此，当看到 Istio 提供了一个精心设计的接口，通过适配器连接 syndicate 服务遥测，我们就知道 Circonus 适配器可以与 Istio 很好的衔接。Istio 已经被设计成提供高性能、高可扩展的应用控制平面，并且 Circonus 也是按照高性能和可扩展性的核心原则设计的。\n今天我们很高兴的宣布 Istio 服务网格 的 Circonus 适配器的可用性。这篇博客文章将介绍这个适配器的开发，并向您展示如何快速启动并运行它。我们知道你会对此非常感兴趣，因为 Kubernetes 和 Istio 可以提供扩展 Circonus 的能力使其远强于其他遥测解决方案。\n如果你不知道什么是服务网格那也没关系，其实你已经用了很多年了。互联网的路由基础设施就是一个服务网格；它有利于 TCP 重传、访问控制、动态路由、流量规划等。以往占主导地位的单体 web 应用正在为微服务让路。Istio 通过一个 sidecar proxy 提供基于容器的分布式应用程序的控制平面功能。它为服务 …","relpermalink":"/blog/the-circonus-istio-mixer-adapter/","summary":"本文是 Circonus 公司的人员分享的为 Istio mixer 开发适配器的过程。","title":"Circonus Istio Mixer 适配器"},{"content":"本文分析的 istio 代码版本为 0.8.0，commit 为 0cd8d67，commit 时间为 2018 年 6 月 18 日。\n本文为Service Mesh深度学习系列之一：\nService Mesh 深度学习系列 part1—istio 源码分析之 pilot-agent 模块分析 Service Mesh 深度学习系列 part2—istio 源码分析之 pilot-discovery 模块分析 Service Mesh 深度学习系列 part3—istio 源码分析之 pilot-discovery 模块分析（续） pilot 总体架构 Istio pilot 总体架构图 首先我们回顾一下 pilot 总体架构，上面是官方关于 pilot 的架构图，因为是 old_pilot_repo 目录下，可能与最新架构有出入，仅供参考。所谓的 pilot 包含两个组件：pilot-agent 和 pilot-discovery。图里的 agent 对应 pilot-agent 二进制，proxy 对应 Envoy 二进制，它们两个在同一个容器中，discovery …","relpermalink":"/blog/istio-service-mesh-source-code-pilot-discovery-module-deepin/","summary":"本文是谐云科技 CTO 丁轶群博士对 Istio 0.8 版本代码中的 pilot-discovery 的深度源码解析。","title":"Service Mesh 深度学习系列 part2—istio 源码分析之 pilot-discovery 模块分析"},{"content":"本文为翻译文章，点击查看原文。\n在微服务领域，分布式跟踪正逐渐成为调试和跟踪应用程序最重要的依赖工具。\n最近的聚会和会议上，我发现很多人对分布式跟踪的工作原理很感兴趣，但同时对于分布式跟踪如何与 Istio 和Aspen Mesh等服务网格进行配合使用存在较大的困惑。特别地，我经常被问及以下问题：\nTracing 如何与 Istio 一起使用？在 Span 中收集和报告哪些信息？ 是否必须更改应用程序才能从 Istio 的分布式跟踪中受益？ 如果目前在应用程序中报告 Span，它将如何与 Istio 中的 Span 进行交互？ 在这篇博客中，我将尝试回答这些问题。\n在我们深入研究这些问题之前，建议先快速了解为什么我要写与分布式跟踪相关博客。如果您关注Aspen Mesh的博客，您会注意到我写了两篇与 tracing 相关的博客，一篇关于 ”使用 Istio 跟踪 AWS 中的服务请求“，另一篇关于”使用 Istio 跟踪 gRPC 应用程序\u0026#34;。\n我们在 Aspen Mesh 有一个非常小的工程团队，如果经常在子系统或组件上工作，您很快就会成为（或标记或分配）常驻专家。我在微服务中添加了 …","relpermalink":"/blog/distributed-tracing-istio-and-your-applications/","summary":"本文是由 Aspen Mesh（隶属于 F5）公司的 Neeraj Poddar 介绍如何在 Istio 中使用分布式跟踪，需要修改程序才能利用 Istio 做分布式追踪，Istio 报告的 Span 如何与应用程序创建的 Span 交互。","title":"使用 Istio 分布式跟踪应用程序"},{"content":"4 月，蚂蚁金服自主研发的分布式中间件（Scalable Open Financial Architecture，以下简称 SOFA）启动开源计划，并开放多个组件，（相关背景请点击链接阅读《开源 |蚂蚁金服启动分布式中间件开源计划，用于快速构建金融级云原生架构》、《开源 | 蚂蚁金服分布式中间件开源第二弹：丰富微服务架构体系》），这一系列的动作受到大家的关注和支持，SOFA 社区也日益壮大。\n在两轮开源之后，蚂蚁金服自主研发的分布式中间件（Scalable Open Financial Architecture，以下简称 SOFA）在今天推出了第三轮的开源产品：SOFAMesh。和前两轮开源的历经多年沉淀和打磨的成熟产品不同，本轮的开源主角 SOFAMesh，将探索一条和以往产品有所不同的开源道路。下面我们就来看看到底有哪些不同吧！\nSOFAMesh 的开源探索之路 SOFAMesh 尝试在以下几个方面进行自我突破和勇敢探索：\n全新的技术领域\nService Mesh 是目前技术社区最为炙手可热的新技术方向，有下一代微服务的明显趋势。但是目前 Service Mesh 技术还处于发展早 …","relpermalink":"/blog/introducing-sofamesh-a-solution-for-large-scale-service-mesh-by-ant-financial/","summary":"蚂蚁金服开源 SOFAMesh—一款基于 Istio 改进和扩展而来的 Service Mesh 大规模落地实践方案，同时开源了 Go 语言版的 Sidecar—SOFA MOSN（可单独使用），期待通过社区贡献。","title":"蚂蚁金服开源 SOFAMesh—一款基于 Istio 改进和扩展而来的 Service Mesh 大规模落地实践方案"},{"content":" 这是我们正在发布的系列文章中的第二篇，描述了我们在 Kubernetes 上采用 Istio 进行流量路由的经验。有关我们试图通过 Vamp 实现的更多详情以及我们选择 Istio 的原因，请参阅我们的第一篇文章。\n最近几个月对 Istio 社区来说相当令人兴奋。随着 0.8 版本的发布，该平台变得更加稳定，现在受益于更加一致（尽管仍然粗糙）的设计。然而，这些改进的代价是路线配置更加复杂。\nVamp Lamia 这个新版本的目标是将 Istio 从 0.7.1 迁移到 0.8 并让它使用起来更加简单。与此同时，我们希望提供一种有助于某种现实场景应用的新功能。 如今，许多产品经理希望通过 A/B 测试来测试页面上新功能的价值。不幸的是，这通常来说都很难做到。 通常人们最终会以离线的方式处理复杂系统，功能切换或日志系统。往往所有这些情况都依赖于人工干预，从而成为一个缓慢，容易出错的过程，也不能很好地与 CI/CD管道集成。\n当我们开始工作时，我们问自己：有多少工作可以在不用写编码的情况下自动完成？\n进入 Vamp Lamia 0.2.0。\n我们解决这个问题的方法的核心是实 …","relpermalink":"/blog/ab-testing-on-kubernetes-with-istio-0-8/","summary":"本文讲述 Vamp（一款商业版的云原生应用平台）如何在 Kubernetes 上采用 Istio 进行流量路由的经验","title":"使用 Istio 0.8 对 Kubernetes 进行 A/B 测试"},{"content":"本文为翻译文章，点击查看原文。\n先前关于速率限制文章主要描述如何构建并部署基于 Java 的速率限制服务，该服务可以和开源的 Ambassador API 网关以及 Kubernetes 集成（文章的第 1 部分和第 2 部分请见这里）。大家或许会疑惑怎么样才能更好地设计速率限制服务，尤其是如何保证 Ambassador 以及其底层的 Envoy 代理的灵活性？这篇文章将给大家启发。\n设置场景 如果你还没有阅读这个系列的第 3 部分“基于 Ambassador API 网关实现 Java 速率限制服务”，我建议你先阅读（文章的第 1 部分和第 2 部分请见这里）。其中最关键的是Ambassador API 网关，其就像其底层使用的Envoy 代理一样，通过请求另一个服务来决定一个请求的速率是否需要被限制。这是关注点分离（和单一原则）设计的良好实现。同时由于 Ambassador 可作为 Kubernetes 原生 API 网关，因此你可以很方便将 rate limiter 部署为 Kubernetes 基础服务，用来管理平台的容错特性，同时其也很容易进行扩展。 …","relpermalink":"/blog/designing-a-rate-limiting-service-for-ambassador-part-4/","summary":"先前关于速率限制文章主要描述如何构建并部署基于 Java 的速率限制服务，该服务可以和开源的 Ambassador API 网关以及 Kubernetes 集成。大家或许会疑惑怎么样才能更好地设计速率限制服务，尤其是如何保证 Ambassador 以及其底层的 Envoy 代理的灵活性？这篇文章将给大家启发。","title":"速率限制系列 part4—为 Ambassador API 网关设计速率限制服务"},{"content":"本文分析的 istio 代码版本为 0.8.0，commit 为 0cd8d67，commit 时间为 2018 年 6 月 18 日。\n本文为Service Mesh深度学习系列之一：\nService Mesh 深度学习系列 part1—istio 源码分析之 pilot-agent 模块分析 Service Mesh 深度学习系列 part2—istio 源码分析之 pilot-discovery 模块分析 Service Mesh 深度学习系列 part3—istio 源码分析之 pilot-discovery 模块分析（续） pilot 总体架构 上面是官方关于 pilot 的架构图，因为是 old_pilot_repo 目录下，可能与最新架构有出入，仅供参考。所谓的 pilot 包含两个组件：pilot-agent 和 pilot-discovery。图里的 agent 对应 pilot-agent 二进制，proxy 对应 envoy 二进制，它们两个在同一个容器中，discovery service 对应 pilot-discovery 二进制，在另外一个跟应用分开部署的 …","relpermalink":"/blog/istio-service-mesh-source-code-pilot-agent-deepin/","summary":"本文是谐云科技 CTO 丁轶群博士对 Istio 0.8 版本代码中的 pilot-agent 的深度源码解析。","title":"Service Mesh 深度学习系列 part1—istio 源码分析之 pilot-agent 模块分析"},{"content":"本文转载自InfoQ。\n重要结论 微服务风格的架构能够简化单个服务的开发。然而，对于成百上千个微服务的通信、监控以及安全性的管理并不是一件简单的事。 Service Mesh 提供了一种透明的、与编程语言无关的方式，使网络配置、安全配置以及服务观察等操作能够灵活而简便地实现自动化。从本质上说，它解耦了服务的开发与运维工作。 Istio Service Mesh 由两部分组成。1. 由 Envoy 代理组成的数据面板，它能够拦截网络请求，并控制服务之间的通信。2. 支持服务的运行时管理的控制面板，它提供策略实施、遥测数据收集以及证书轮换等功能。 近期的项目目标是在关键的功能进入 beta 阶段后发布 Istio 1.0 版本（其中包括对于混合环境的支持）。 长期的项目目标则是使 Istio 能够融入各种不同的环境中。 不夸张的说，正是 Istio 的出现使“Service Mesh”这一概念开始流行起来。在深入介绍 Istio 的细节之前，让我们首先简单地了解一下 Service Mesh 是什么，以及它的重要性体现在哪里。我们都已经了解单体应用所面对的挑战，一种显而易见的方案是将其分解 …","relpermalink":"/blog/istio-future-service-mesh/","summary":"本文讲述了 Istio 的基本原理以及后续发展计划，得出结论说 istio 是服务网格的未来","title":"Istio 以及 Service Mesh 的未来"},{"content":"7 月 6 日，Linkerd 博客再次更新，宣布 Conduit 0.5 发布：在翻炒了无数次 Prometheus 支持的冷饭之后，终于发布了新的功能 —— TLS 支持。\n紧接着一个更加重磅的消息：0.5 将是 Conduit 最后一个版本，未来将作为 Linkerd 2.0 的基础继续存在 - Conduit 的 Github 项目将会转移为 Linkerd2。\n回想一下，2017 年 12 月 5 日发布到现在的两百多天里，一共发布了 13 个版本、9 篇文档以及 12 篇博客。大致完成了 Conduit 问世之初的承诺：轻量、快速以及 Service Mesh 该有的种种功能；然而很可惜，第一篇 Conduit 博客中还提到了一点：“Conduit is not Linkerd 2.0. ”。这一次“战略性转移”，也印证了之前大家的担心——如果自身投入不足，又不能有效持续制造焦点、获取社区的持续关注和支持，先驱就变成先烈了。\nService Mesh 的鏖战尚未开始，已经有人出局了，R.I.P. Conduit。\n详见官方博客 Conduit 0.5.0 and the …","relpermalink":"/blog/rip-conduit/","summary":"2018 年 7 月 6 日，Linkerd 博客再次更新，宣布 Conduit 0.5 发布：在翻炒了无数次 Prometheus 支持的冷饭之后，终于发布了新的功能——TLS 支持。紧接着一个更加重磅的消息：0.5 将是 Conduit 最后一个版本，未来将作为 Linkerd 2.0 的基础继续存在——Conduit 的 Github 项目将会转移为 Linkerd2。","title":"Conduit 0.5 发布—以及 R.I.P. Conduit"},{"content":" 本文是根据蚂蚁金服 Service Mesh 布道师敖小剑在 Service Mesher 社区进行的第一次 Meetup 上分享的《大规模微服务架构下的 Service Mesh 探索之路》现场演讲内容实录整理编辑而成，希望能给关注 Service Mesh 产品的朋友们带来帮助和了解。\n讲师 PPT 下载地址：\nhttps://github.com/servicemesher/meetup-slides\n敖小剑 蚂蚁金服 service mesh 杭州 meetup 前言 今天给大家带来的内容叫做 Service Mesh 探索之路，但是在前面加了一个定语：大规模微服务架构下。之所以加上这个词，是因为我们这个体系是在蚂蚁金服这样一个大的架构下进行的，蚂蚁金服的体量大家可以想象，所以这个探索会带有一个非常隆重的色彩：对性能/规模/高可用等方面的思考。\n今年 6 月初，在深圳的 GIAC 大会，我们同事披露了这个正在开发中的 Service Mesh 产品，我们现在暂时命名为 SOFA Mesh。我们目前的产品都在 SOFA 品牌下，比如 SOFA RPC，SOFA Boot 等。今 …","relpermalink":"/blog/the-way-to-service-mesh-in-ant-financial/","summary":"本文是根据蚂蚁金服 Service Mesh 布道师敖小剑在 Service Mesher 社区进行的第一次 Meetup 上分享的《大规模微服务架构下的 Service Mesh 探索之路》现场演讲内容实录整理编辑而成，希望能给关注 Service Mesh 产品的朋友们带来帮助和了解。","title":"蚂蚁金服大规模微服务架构下的 Service Mesh 探索之路"},{"content":" 本文系转载，作者：郑伟，小米信息部技术架构组\n本系列文章主要从源码（35e2b904）出发，对 istio 做深入剖析，让大家对 istio 有更深的认知，从而方便平时排查问题。不了解 Service Mesh 和 Istio 的同学请先阅读敖小剑老师如下文章进行概念上的理解：\nService Mesh：下一代微服务 服务网格新生代-Istio 本文主要对 istio 在 ubuntu16.04 下环境搭建做简单介绍，Mac 用户和其他 linux 发行版用户请根据 bash 脚本做相应调整。\n概念介绍 Mixer 提供三个核心功能：\n前置条件检查（Precondition Checking）：某一服务响应外部请求前，通过 Envoy 向 Mixer 发送 Check 请求，检查该请求是否满足一定的前提条件，包括白名单检查、ACL 检查等。 配额管理（Quota Management）：当多个请求发生资源竞争时，通过配额管理机制可以实现对资源的有效管理。 遥测报告上报（Telemetry Reporting）：该服务处理完请求后，通过 Envoy 向 Mixer 上报日志、监控等数 …","relpermalink":"/blog/istio-deepin-part3-mixer-workflow/","summary":"本系列文章主要从 Istio 源码出发深入剖析，让大家对 istio 有更深的认知，从而方便平时排查问题。本文是对 Istio 中 Mixer 的工作流程浅析。","title":"Istio 源码解析系列 part3—Mixer 工作流程浅析"},{"content":" 本文系转载，原文作者：郑伟，小米信息部技术架构组\n本系列文章主要从源码（35e2b904）出发，对 istio 做深入剖析，让大家对 istio 有更深的认知，从而方便平时排查问题。不了解 Service Mesh 和 Istio 的同学请先阅读敖小剑老师如下文章进行概念上的理解：\nService Mesh：下一代微服务 服务网格新生代-Istio 服务治理配置生效流程解析 如果大家安装bookinfo并执行过文档中的 task，可以了解到，所有服务治理流程都是通过 istioctl 工具，执行指定 yaml 配置文件来实现。那么从执行 istioctl 指令到配置文件生效，整个流程到底是什么样的呢？下面给大家做一个简单的介绍。\n整个配置生效的流程图如下所示：\n配置文件解析\n以 task request-routing为例，我们的需求是把名为 jason 的用户访问 reviews 服务的版本切换为 v2。route-rule-reviews-test-v2.yaml内容如下所示：\napiVersion: config.istio.io/v1alpha2 kind: …","relpermalink":"/blog/istio-deepin-part2-serivce-management-workflow/","summary":"本系列文章主要从 Istio 源码出发深入剖析，让大家对 istio 有更深的认知，从而方便平时排查问题。本文讲解 Istio 中的 bookinfo 示例并执行过文档中的 task，介绍从执行 istioctl 指令到配置文件生效的整个流程。","title":"Istio 源码解析系列 part2—服务治理配置生效流程解析"},{"content":" 本文系转载，作者：郑伟，小米信息部技术架构组\n本系列文章主要从源码（35e2b904）出发，对 istio 做深入剖析，让大家对 istio 有更深的认知，从而方便平时排查问题。不了解 Service Mesh 和 Istio 的同学请先阅读敖小剑老师如下文章进行概念上的理解：\nService Mesh：下一代微服务 服务网格新生代-Istio 本文主要对 istio 在 ubuntu16.04 下环境搭建做简单介绍，Mac 用户和其他 linux 发行版用户请根据 bash 脚本做相应调整。\n概述 Istio 为希腊文，意思是“启航”，和“kubernetes（舵手）”遥相呼应，是一个开源的微服务管理、保护、监控的基础设施。Istio 发音**“意丝帝欧”**，重音在“意”上。\n前两篇文章主要对 istio 开发环境以及通过服务治理配置生效流程做了介绍。考虑到有些用户可能没有接触过 Istio，本文会对 Istio 整体架构、内部各组件做介绍。\nIstio 是逻辑上分为数据平面（Data Plane）和控制平面（Control Plane）。\n数据平面的含义是什么？官网是这么描述 …","relpermalink":"/blog/istio-deepin-part1-framework-and-environment/","summary":"本系列文章主要从 Istio 源码出发深入剖析，让大家对 istio 有更深的认知，从而方便平时排查问题。本文讲解 Istio 源码架构及开发环境搭建。","title":"Istio 源码解析系列 part1—Istio 源码架构介绍及开发环境搭建"},{"content":"本文为翻译文章，点击查看原文。\n运营容器化基础设施给我们带来了一系列新的挑战。您需要对容器进行测试，评估您的 API 端点性能，并确定您的基础架构中的不良的组件。Istio 服务网格可在不更改代码的情况下实现 API 的检测，并且可以自由的设置服务延迟。但是，我们该如何理解所有这些数据？用数学的方式，对，就是这样。\nCirconus 是 Istio 的第一个第三方适配器。在 之前的文章中，我们讨论了第一个用于监视基于 Istio 的服务的 Istio 社区适配器。这篇文章将对此进行扩展。我们将解释如何全面了解您的 Kubernetes 基础设施。我们还将解释如何为基于容器的基础架构增加 Istio 服务网格实现。\nIstio 概述 Istio 是 Kubernetes 的服务网格，这意味着它负责所有服务之间的通信和协调，就像网络路由软件为 TCP/IP 流量所做的一样。除了 Kubernetes 之外，Istio 还可以与基于 Docker 和 Consul 的服务进行交互。与 LinkerD 相似，Istio 已经的出现已经有很长时间了。\nIstio 是由 Google、IBM、思科 …","relpermalink":"/blog/comprehensive-container-based-service-monitoring-with-kubernetes-and-istio/","summary":"本文讲述了容器化基础设运维的挑战，Istio 给我们带来了哪些便利，怎样通过设置服务级别目标（SLO）、服务级别目标（SLO）、服务级别协议（SLA）、RED 仪表板，根据监控数据的分布，进行数据分析来判断性能指标，而不是简单的百分位统计。","title":"使用 Kubernetes 和 Istio 对基于容器基础设施的全面服务监控"},{"content":"本文为翻译文章，点击查看原文。\n在本文中，我将解释如何在 Fn 函数之间使用 Istio 服务网格实现基于版本的流量路由。\n我将首先解释 Istio 路由的基础知识以及将 Fn 部署和运行在 Kubernetes 上的方式。最后，我将解释我是如何利用 Istio 服务网格及其路由规则在两个不同的 Fn 函数之间路由流量的。\n请注意，接下来的解释非常基本和简单——我的目的不是解释 Istio 或 Fn 的深入细节，而是解释得足够清楚，让您可以了解如何使自己的路由工作。\nIstio 路由入门 让我花了一点时间来解释 Istio 路由如何工作。Istio 使用 sidecar 容器（ istio-proxy ）注入到您部署的应用中。注入的代理会劫持所有进出该 pod 的网络流量。部署中所有这些代理的集合与 Istio 系统的其他部分进行通信，以确定如何以及在何处路由流量（以及其他一些很酷的事情，如流量镜像、故障注入和断路由）。\n为了解释这是如何工作的，我们将开始运行一个 Kubernetes 服务（myapp）和两个特定版本的应用程序部署（v1和v2）。\n在上图中，我们有 myapp 一个选 …","relpermalink":"/blog/traffic-routing-between-fn-functions-using-fn-project-and-istio-fd/","summary":"本文首先解释 Istio 路由的基础知识以及将服务器架构（Serverless framework）Fn 部署和运行在 Kubernetes 上的方式。然后将说明如何利用 Istio 服务网格及其路由规则在两个不同的 Fn 函数之间路由流量的。","title":"使用 Istio 控制 Serverless 架构 Fn Project 中的函数间流量路由"},{"content":"本文为翻译文章，点击查看原文。\n本文译自 HashiCorp 官网关于 Consul 1.2 支持 Service Mesh 发布的博客文章。\n本文是 HashiCorp 创始人 Mitchell Hashimoto 在 2018 年 6 月 26 日发布的关于 Consul 1.2 新功能 Service Mesh 的官方介绍。译者接触过的 Hashicorp 的产品有过不少，每款都给人感觉功能强大，设计简洁，可以说是都是非常优秀的开源产品（当然这与背后的 Hashicorp 公司商业级支撑有关）。译者有幸见过作者 Mitchell 一面，是个日裔混血，佩服他们取得的成就，期待他们推出的新功能能够取得市场上的成功。\nService Mesh 是最近很火的微服务新范式，以 Istio 为首的开源项目引领着潮流，其他各大公司也在迅速跟上，包括 Hashicorp 也在 Consul 中加入类似的功能。我们后续也将提供 Service Mesh 这方面更多的技术文章，敬请期待。\nHarshiCorp Consul 我们很激动宣布 HashiCorp Consul 1.2 正式发布了。这个版 …","relpermalink":"/blog/consul-1-2-service-mesh/","summary":"本文是 HashiCorp 创始人 Mitchell Hashimoto 在 2018 年 6 月 26 日发布的关于 Consul 1.2 新功能 Service Mesh 的官方介绍。","title":"Service Mesh 新成员：Consul 1.2"},{"content":"本文为翻译文章，点击查看原文。\n基于 Kubernetes 云原生的Ambassador API网关所提供的速率限制功能是完全可定制的，其允许任何实现 gRPC 服务端点的服务自行决定是否需要对请求进行限制。本文在先前第 1 部分和第 2 部分的基础上，阐述如何为 Ambassador API 网关创建和部署简单的基于 Java 的速率限制服务。\n部署 Docker Java Shop 在我之前的教程“使用 Kubernetes 和 Ambassador API 网关部署 Java 应用”中，我将开源的 Ambassador API 网关添加到现有的一个部署于 Kubernetes 的 Java（Spring Boot 和 Dropwizard）服务中。如果你之前不了解这个，建议你先阅读下此教程及其他相关内容来熟悉基础知识。 本文假定你熟悉如何构建基于 Java 的微服务并将其部署到 Kubernetes，同时已经完成安装所有的必备组件（我在本文中使用Docker for Mac Edge，并启用其内置的 Kubernetes 支持。若使用 minikube 或远程群集应该也类似）。\n …","relpermalink":"/blog/implementing-a-java-rate-limiting-service-for-the-ambassador-api-gateway-part3/","summary":"在本速率限制系列的第三篇文章中，根据实际 Java 语言编写的案例带领我们使用 Ambassador API 网关速率限制入门，并将实例部署到 Kubernetes 中，同时使用 Java 语言演示基于令牌通算法的速率限制方式。","title":"速率限制 part3—基于 Ambassador API 网关实现 Java 速率限制服务"},{"content":"6 月 30 日，杭州，蚂蚁 Z 空间，一大早就下起了雨，我还心想，这雨要是下大了会不会很多人不来了？而且我们还一早就放出了 IT 大咖说的直播链接。没想到最后现场签到了有 120 多个小伙伴！👍视频直播最高峰值 800 多人同时在线，截止 7 月 1 号显示有 5340 人观看。\n讲师 PPT：https://github.com/servicemesher/meetup-slides 视频直播回放：http://www.itdks.com/eventlist/detail/2311 Meetup 结束时现场观众和讲师的合影。\nService Mesh meetup 顺利落幕，感谢到场的小伙伴，线上观众，IT 大咖说的直播支持，来自蚂蚁金服、网易、才云科技、谐云科技老师的精彩分享，蚂蚁金服提供场地支持，电子工业出版社提供赠书支持。下一站北京见！更多 SM 内容请关注我们社区的官方网站 www.servicemesher.com，忙活了一天都没饭，真的是很饿，晚上在回北京的高铁上叫了个外卖应付了下。\n现场回顾（多图预警） 当天中午杭州的天气。\n前几天从 LC3 大会上拿来的贴 …","relpermalink":"/blog/hangzhou-meetup-20180630/","summary":"2018 年 6 月 30 日，杭州，蚂蚁 Z 空间，一大早就下起了雨，我还心想，这雨要是下大了会不会很多人不来了？而且我们还一早就放出了 IT 大咖说的直播链接。没想到最后现场签到了有 120 多个小伙伴！视频直播最高峰值 800 多人同时在线，截止 7 月 1 号显示有 5340 人观看。","title":"第一届 Service Mesh Meetup 杭州站回顾"},{"content":"本文为翻译文章，点击查看原文。\n在本速率限制系列的第一篇文章中，介绍了实施速率限制的动机，并讨论了几种实施方案（取决于你是否同时作为通信的发送端和接收端）以及相关的权衡。本文会更加深入地探讨 API 网关速率限制的需求。\n为什么 API 网关需要速率限制 在第一篇文章中，我讨论了在何处实施速率限制的几个选项：发送端、接收端或中间层（字面意思可以理解为发送端和接收端中间的服务）。 当通过公共 API 暴露你的应用程序时，通常你必须在接收端或中间层中实施速率限制。即使你控制了源代码（客户端）应用程序，你也希望防止会导致过多 API 请求的错误产生，同时应付可能会试图破坏客户端应用程序的不良行为者。 Stripe 博客有一篇精彩的关于“用限速器扩展你的 API”的文章，我将在本文中引用这篇文章，那篇文章的开头部分讨论了速率限制会如何帮助你在以下情况中让你的 API 更加可靠：\n某位用户制造了流量洪峰，导致你的应用过载，而你的应用此时还需要为其他用户提供服务。 某位用户因为使用了行为不当的脚本，无意中向你发送了很多请求（相信我，这比你想象的要更频繁 - 我曾经亲自创建的压测脚本就意外触发了拒绝 …","relpermalink":"/blog/rate-limiting-for-api-gateway-daniel-bryant-part2/","summary":"在本速率限制系列的第一篇文章中，介绍了实施速率限制的动机，并讨论了几种实施方案（取决于你是否同时作为通信的发送端和接收端）以及相关的权衡。本文会更加深入地探讨 API 网关速率限制的需求。","title":"速率限制 part2—作用于 API 网关的速率限制"},{"content":"背景和想法 Service Mesh 提供了微服务化开发的新思路，核心思想是构建一个代理转发网络并结合控制和转发分离的做法来对成千上万个微服务间做流量、策略、安全等管理，而另一方面 Linux Kernel 提供一种运行时高效扩可编程的网络注入机制 eBPF，借此能实现 L47 层代理转发。假设借助 eBPF，作为 Service Mesh 的数据转发层，对接 Pilot、Mixer 等控制面，实现策略、流量和安全管理，是不是一种更高效的方式？这会比 Envoy 拥有更好的性能，虽然性能未必是 Mesh 首要考虑的问题，后搜索发现 Cilium 果然做了类似的尝试，详情见 http://docs.cilium.io/en/latest/gettingstarted/istio/，但对接的方式很特别，并不像 Envoy 一样，为每一个 Pod 部署一个 Envoy 容器，而是在多个 Pod 外部署一个 Cilium，以 Kubernetes Daemon Set 模式部署，为多个 Pod 进行代理，对控制器层面的 Pilot 做了定制，部署配置如下：\n$ sed -e …","relpermalink":"/blog/a-new-more-efficient-proxy-model/","summary":"借助 eBPF，作为 Service Mesh 的数据转发层，对接 Pilot、Mixer 等控制面，实现策略、流量和安全管理，是不是一种更高效的方式？这会比 Envoy 拥有更好的性能，虽然性能未必是 Mesh 首要考虑的问题，本文中讲述使用 Cilium 的尝试。","title":"探讨 Service Mesh 中一种更高效的代理模式"},{"content":"讲师分享 云原生社区 meetup 第七期深圳站开场致辞 - 宋净超 使用 IAST 构建高效的 DevSecOps 流程 - 董志勇 云原生场景下的开发和调试 - 汪晟杰，黄金浩 Envoy 在腾讯游戏云原生平台应用 - 田甜 使用 KubeVela 构建混合云应用管理平台 - 邓洪超 ","relpermalink":"/event/service-mesh-meetup-01/","summary":"这是第一届 Service Mesh Meetup。","title":"Service Mesh Meetup #1 杭州站"},{"content":"在计算领域，速率限制通常用于控制服务发起或消耗的操作速率，或者是请求发送或接收的流量。如果你有一年以上的软件开发经验，那么你应该会遇到这个概念。但是，和很多软件架构所面临的挑战一样，比起实际出现的问题，需要思考的问题会更多。本文概述了现代分布式应用程序中的一些关于速率限制的实现方案、优势和挑战。\n为什么需要速率限制？ 实现速率限制主要是由于以下三个原因：通过资源节制防止（有意无意的）拒绝服务，限制（潜在的）级联故障的影响，以及限制或计量资源的使用情况。\nTwitter 或 Ebay 这样的企业组织使用了一种类似的拒绝服务防治模式：在 SaaS API 之前放置一个速率限制器，以此来避免针对 API 后端的拒绝服务恶意攻击，同时也可以为所有消费者提供一致的服务。在那些支付 API（如 Stripe ）的减负策略中可以使用速率限制来防止级联故障（通过系统中的一些组件部分降级）。同样，当为外部信息源轮询健康检查这些新数据时，也会使用限制（或计量）模式。这样我们只需要定期获取数据，并可以为启动的每个请求付费。\n如何选择？ 基于简化的原则，我们假设正在处理点对点通信模型中的速率限制。在这种场景 …","relpermalink":"/blog/rate-limiting-a-useful-tool-with-distributed-systems-part1/","summary":"在计算领域，速率限制通常用于控制服务发起或消耗的操作速率，或者是请求发送或接收的流量。如果你有一年以上的软件开发经验，那么你应该会遇到这个概念。但是，和很多软件架构所面临的挑战一样，比起实际出现的问题，需要思考的问题会更多。本文概述了现代分布式应用程序中的一些关于速率限制的实现方案、优势和挑战。","title":"速率限制 part1—分布式系统的一个实用工具"},{"content":"本文为翻译文章，点击查看原文。\n通过使用 Istio Service Mesh 来保障 Kubernetes 平台服务。通常可以运行示例代码有助于用户更清晰的理解并将概念应用到实际的案例中。该项目围绕一个简单的 Node.js 应用程序演示了以 Istio Service Mesh 为 ETCD 的持久化数据服务的能力。\nIstio 背景 Istio 是一个 连接、管理以及保障微服务的开放平台。如需要了解更多 Istio 的信息，请访问介绍页面 。\n安装 假设已对 Kubernetes 有了初步了解。在这个项目中，有一组脚本，假设已预先安装了 Docker、Kubernetes CLI 以及 JQ，用于操作 Kubernetes commands 返回的各种 JSON 对象。且有一定层度的 Node.js 知识。\n各种工具的连接如下：\nDocker 安装：https://docs.docker.com/install/\nKubernetes 安装：https://kubernetes.io/docs/tasks/tools/install-kubectl/\njq 下载地 …","relpermalink":"/blog/istio-is-not-just-for-microservices/","summary":"通过使用 Istio Service Mesh 来保障 Kubernetes 平台服务。通常可以运行示例代码有助于用户更清晰的理解并将概念应用到实际的案例中。该项目围绕一个简单的 Node.js 应用程序演示了以 Istio Service Mesh 为 ETCD 的持久化数据服务的能力。","title":"Istio 不仅为微服务而生—使用 Istio Service Mesh 保护 Kubernetes 中的服务"},{"content":"本文为翻译文章，点击查看原文。\n更新\n感谢 Laurent Demailly 的评论，这里有一些更新。这篇文章已经得到了更新：\n现在有一个 Cert-Manager 官方 Helm chart Istio Ingress 也支持基于 HTTP/2 的 GRPC Istio Istio 是管理微服务世界中数据流的一种新方式。事实上，这对我来说更是如此。人们不停的谈论微服务与单体应用，说微服务更好开发，易于维护，部署更快。。。呃，他们是对的，但微服务不应该仅仅是小应用程序之间互相通信。微服务应该考虑沉淀为你的基础设施的这种方式。考虑如何决定您的“简单”应用程序公开指标和日志的方式，考虑您如何跟踪状态，考虑如何控制服务之间的流程以及如何管理错误，这些问题应该是做微服务应该考虑的。\n那么 Istio 能够在这个微服务世界中增加什么？\nIstio 是一个服务网格的实现！\n什么？服务网格？我们已经有了 Kubernetes API，我们需要“网格”吗？\n那么，是的，你需要服务网格。我不会解释使用它的所有好处，你会在网上找到足够的文档。但是用一句话来说，服务网格就是将您所有的服务提供给其他服务的技 …","relpermalink":"/blog/istio-envoy-cert-manager-lets-encrypt-for-tls/","summary":"本文是使用 Let's Encrypt 为 Istio（Envoy）Service Mesh 添加 TLS 安全支持的教程。","title":"利用 Let's Encrypt 为 Istio（Envoy）添加 TLS 支持"},{"content":"本文为翻译文章，点击查看原文。\n关键点 服务网格框架用于处理服务间的通信，并提供连接、管理和保护微服务的平台。 服务网格通过处理需要复杂编码的功能来帮助应用程序开发人员，例如路由决策，这些决策在网格层级完成，而不是在应用程序中完成。 它还提供了可以编入网格的安全策略。例如，您可以设置一个策略，以限制网格中某些服务的入站网络流量。 像 Istio 这样的服务网格可以在 Kubernetes 平台上无缝工作，但在其他平台上使用还比较麻烦。 Sidecar 代理使得应用程序与管理服务通信的操作方面有效和可靠。 服务网格是一个专用的基础设施层，用于处理服务间通信，并提供连接、管理和保护微服务的平台。\n服务网格使得微服务之间的通信变得灵活可靠。它提供了分布式服务所需的关键功能环境，如弹性、服务发现、负载均衡、加密、授权、容错（通过服务重试和断路器）。\nInfoQ 与服务网格领域的主题专家进行了交谈，以更多地了解为什么服务网格框架已成为云本机体系结构的关键组件。\n本文下面的部分提供了与我们交谈的小组成员的详细信息，虚拟小组中包含的问题以及小组成员的答复。\n讨论嘉宾：\nMatt Klein，Lyft …","relpermalink":"/blog/vp-microservices-communication-governance-using-service-mesh/","summary":"本文是 InfoQ 对 Serivce Mesh 业界领袖 Matt Klein、Dan Berg、Priyanka Sharma、Lachlan Evenson、Varun Talwar、Oliver Gould 的采访，几位大咖分别就 Service Mesh 的定义及其在微服务交互和治理方面带来的优势、服务网格与 ESB 的区别，谁应该关心服务网格，服务网格的运行方式、sidecar 以及学习曲线展开了讨论。","title":"InfoQ 访谈：使用服务网格的微服务通信与治理"},{"content":"多租户是一个在各种环境和各种应用中都得到了广泛应用的概念，但是不同环境中，为每租户提供的具体实现和功能性都是有差异的。Kubernetes 多租户工作组致力于在 Kubernetes 中定义多租户用例和功能。然而根据他们的工作进展来看，恶意容器和负载对于其他租户的 Pod 和内核资源的访问无法做到完全控制，因此只有“软性多租户”支持是可行的。\n软性多租户 文中提到的“软性多租户”的定义指的是单一 Kubernetes 控制平面和多个 Istio 控制平面以及多个服务网格相结合；每个租户都有自己的一个控制平面和一个服务网格。集群管理员对所有 Istio 控制面都有控制和监控的能力，而租户管理员仅能得到指定 Istio 的控制权。使用 Kubernetes 的命名空间和 RBAC 来完成不同租户的隔离。\n这种模式的一个用例就是企业内部共享的基础设施中，虽然预计不会发生恶意行为，但租户之间的清晰隔离仍然是很有必要的。\n在文章最尾部会对 Istio 未来的多租户模型进行一些描述。\n注意：这里仅就在有限多租户环境中部署 Istio 做一些概要描述。当官方多租户支持实现之后，会在文档中具体呈现。\n …","relpermalink":"/blog/soft-multitenancy-in-istio-service-mesh/","summary":"多租户是一个在各种环境和各种应用中都得到了广泛应用的概念，但是不同环境中，为每租户提供的具体实现和功能性都是有差异的。Kubernetes 多租户工作组致力于在 Kubernetes 中定义多租户用例和功能。然而根据他们的工作进展来看，恶意容器和负载对于其他租户的 Pod 和内核资源的访问无法做到完全控制，因此只有“软性多租户”支持是可行的。","title":"Istio 的软性多租户支持"},{"content":"本文为翻译文章，点击查看原文。\nDocker 和 Kubernetes 为代表的容器技术炙手可热，熟知这一技术领域的用户，一定都知道下一个热点：Service Mesh，它承诺将微服务之间的内部网络通信均一化，并解决一系列监控、故障隔离等通用非功能性需求。底层的代理服务器技术是 Service Mesh 的立身之本，这种技术在 Service Mesh 之外，还能以 API 网关的形式在边缘为业务系统提供一系列的增强。\n虽说 Service Mesh 的爆发之势让人误以为罗马是一日建成的，事实上，在这一热点浮出水面之前，包括 Verizon、eBday 以及 Facebook 在内的很多组织已经在应用后来被我们称之为 Service Mesh 的技术了。这些早期应用 Service Mesh 的组织之一就是 Lyft，这是一家年收入超过十亿美元的美国网约车巨头。Lyft 还是开源软件 Envoy Proxy 的诞生地，Envoy 在 Service Mesh 世界中举足轻重，Kubernetes 原生的 Istio 控制面 和 Ambassador API 网关 也都建筑在 Lyft  …","relpermalink":"/blog/containers-service-mesh-and-api-gateways-it-starts-at-the-edge/","summary":"本文中提到的典型是 Envoy（数据平面）、Istio（控制平面）和 Ambassador（API Gateway），Matt Klein 指出人们在践行微服务的道路踩到的坑大多是与 debugging 有关，我们应该从服务网格的边缘开始实现反向代理、负载均衡和动态路由。实现或迁移基于容器技术的云原生平台如 Kubernetes 才刚刚开始，Service Mesh 填补了该平台中的许多空白。","title":"容器、服务网格和 API 网关：从边缘开始"},{"content":" 本文转载自nino’s blog。\n本篇总结 pilot 的 xDS 常用接口，顺便浏览了部分 pilot 实现，下篇总结下 istio 的流量管理和服务发现的实现。简单来说 istio 做为管理面，集合了配置中心和服务中心两个功能，并把配置发现和服务发现以一组统一的 xDS 接口提供出来，数据面的 envoy 通过 xDS 获取需要的信息来做服务间通信和服务治理。\napi v1 reference Istio 中部署 pilot 的启动方式是pilot-discovery discovery。初始化阶段依次 init 了各种模块，其中 discovery service 就是 xDS 相关实现。envoy API reference 可以查到 v1 和 v2 两个版本的 API 文档。envoy control plane 给了 v2 grpc 接口相关的数据结构和接口。\npilot-xDS是几个月前 0.6.0 版本的环境上实验的接口，今天在 0.8.0 上跑发现 RDS 和 CDS 都查不到配置了，心好累。追到对应版本的代码发现因为 routerule …","relpermalink":"/blog/istio-service-mesh-pilot-xds-note/","summary":"本篇总结 pilot 的 xDS 常用接口，顺便浏览了部分 pilot 实现，下篇总结下 istio 的流量管理和服务发现的实现。简单来说 istio 做为管理面，集合了配置中心和服务中心两个功能，并把配置发现和服务发现以一组统一的 xDS 接口提供出来，数据面的 envoy 通过 xDS 获取需要的信息来做服务间通信和服务治理。","title":"服务网格 Istio 之 pilot-xDS 接口笔记"},{"content":"正如我之前所说的，在如此短的时间内，Envoy 带来的兴奋既神奇又震撼人心。我经常问自己：envoy 的哪些方面导致了我们所看到的异常的社区增长？虽然 Envoy 具有很多引人注目的特征，但最终我认为有三个主要特征在共同推动：\n性能：在具备大量特性的同时，Envoy 提供极高的吞吐量和低尾部延迟差异，而 CPU 和 RAM 消耗却相对较少。 可扩展性：Envoy 在 L4 和 L7 都提供了丰富的可插拔过滤器能力，使用户可以轻松添加 开源版本中没有的功能。 API 可配置性：或许最重要的是，Envoy 提供了一组可以通过控制平面服务实现的管理 API 。如果控制平面实现所有的 API，则可以使用通用引导配置在整个基础架构上运行 Envoy。所有进一步的配置更改通过管理服务器以无缝方式动态传送，因此 Envoy 从不需要重新启动。这使得 Envoy 成为通用数据平面，当它与一个足够复杂的控制平面相结合时，会极大的降低整体运维的复杂性。 有代理具备超高性能。也有代理具备高度的可扩展性和动态可配置性。在我看来，性能、可扩展性和动态可配置性的结合 才使得 Envoy 如此的引人注目。\n在这篇文 …","relpermalink":"/blog/the-universal-data-plane-api/","summary":"本文是 Matt Klein 于 2017 年 9 月在 Meduim 上发表的通用数据平面 API 文章，文中指出了 Envoy 在 API 设计上的要点，以及数据平面与控制平面的关系。","title":"Service Mesh 中的通用数据平面 API 设计"},{"content":" vistio 全局级别可视化视图 本文为翻译文章，点击查看原文。\nVistio GitHub 地址：https://github.com/nmnellis/vistio\nVizceral是 Netflix 发布的一个开源项目，用于近乎实时地监控应用程序和集群之间的网络流量。Vistio 是使用 Vizceral 对 Istio 和网格监控的改进。它利用 Istio Mixer 生成的指标，然后将其输入 Prometheus。Vistio 查询 Prometheus 并将数据存储在本地以允许重播流量。\nVizceral 有两个可视化级别，全局可视化和集群级别可视化。在全局范围内（如上所示），您可以通过 Istio Ingress Gateway 等入口点将从 Internet 到 Istio 服务网格网络的网络流量可视化，或者您可以在 Istio 服务网格网络中显示总网络流量。\n在集群级别（如下所示），您可以可视化内部网格的流量。通过设置警告和错误级别警报，当应用程序出现问题时可以被快速检测出来。\nVistio 的集群级别可视化 在 Istio 服务网格中安装 Vistio …","relpermalink":"/blog/vistio-visualize-your-istio-mesh-using-netflixs-vizceral/","summary":"Vizceral 是 Netflix 发布的一个开源项目，用于近乎实时地监控应用程序和集群之间的网络流量。Vistio 是使用 Vizceral 对 Istio 和网格监控的改进。本文是使用 Vistio 对 Istio mesh 做流量可视化的教程。","title":"Vistio—使用 Netflix 的 Vizceral 可视化 Istio service mesh"},{"content":"本文为翻译文章，点击查看原文。\nAspen Mesh 的 Andrew Jenkins 说，转向微服务本身并不能消除复杂性。\n在本文中，我们与 Aspen Mesh 的首席架构师 Andrew Jenkins 谈论了如何从单一应用程序转向微服务，并通过一些关于服务网格的宣传来管理微服务架构。有关服务网格的更多信息，请考虑参加于 2018 年 5 月 2 日至 4 日在丹麦哥本哈根举行的KubeCon + CloudNativeCon EU。\n1.微服务解决了许多公司面临的单体架构问题。你认为其最大的价值在哪里？\nAndrew Jenkins ：对我来说，这是关于最小化时间对用户的影响。向虚拟化和云转型的关键是降低与支持应用程序的所有基础架构相关的复杂性，以便您可以灵活地分配服务器和存储等。但是这种转变并不一定会改变我们构建的应用程序。现在我们有了灵活的基础架构，我们应该构建灵活的应用程序以充分利用它。\n微服务是灵活的应用程序——构建小型，单一用途的模块并快速构建它们，以便您可以快速将它们交付给最终用户。组织可以使用它来根据实际用户需求进行测试并迭代构建。\n2.随着企业从单体应用程序向微 …","relpermalink":"/blog/making-most-out-microservices-service-mesh/","summary":"本文是在哥本哈根 KubeCon 上对 Aspen Mesh（隶属于 F5 公司）的首席架构师 Andrew Jenkins 关于微服务和 Service Mesh 的采访。","title":"使用 Service Mesh 来充分利用微服务"},{"content":"这个原文是 5 月初发表的日文原文的翻译。补充一下这篇文章的背景，Cookpad 是一家拥有 200 多种产品开发的中型科技公司，拥有 10 多支团队，每月平均用户数量达到 9000 万。https://www.cookpadteam.com/\n你好，我是来自生产团队的开发人员Taiki。目前，我想介绍一下在 Cookpad 上构建和使用服务网格所获得的知识。\n对于服务网格本身，我认为您将对以下文章，公告和教程有完整的了解：\nhttps://speakerdeck.com/taiki45/observability-service-mesh-and-microservices https://buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/ https://blog.envoyproxy.io/service-mesh-data-plane-vs-control-plane-2774e720f7fc …","relpermalink":"/blog/service-mesh-in-cookpad/","summary":"Cookpad 是日本的一家分享菜谱和烹调经验的网站，本文是该网站使用 Service Mesh 的实践，当前 Cookpad 没有直接使用 Istio 而是以 Envoy 为数据平面，自研的控制平面。","title":"服务网格在 Cookpad 网站中的实践"},{"content":"本文为翻译文章，点击查看原文。\n在接下来的几个月中，我们将撰写一系列文章来记录从传统负载均衡器到谷歌 Kubernetes 引擎（GKE）之上服务网格的WePay 工程化之路。\n在本系列的第一部分中，我们将看看曾使用过的一些路由和负载均衡选项并将它们与服务网格代理进行比较，以及它们是如何改变我们基础设施的运行方式的。\n数据面板使用 sidecar 代理模式 图 1.数据面板使用 sidecar 代理模式\n图 1 显示了一个数据面板的简化版本。用服务网格术语来描述就是：服务 X 通过其 sidecar 代理向服务 Y 发送请求。由于服务 X 通过其代理发送请求，所以请求首先被传递给服务 X 的代理（PX），然后在到达目的服务 Y 之前被发送到服务 Y 的代理（PY）。在大多数情况下，PX 通过服务发现服务发现 PY，例如 Namerd。\n我们有期主题为 gRPC 的 meetup讨论了一些关于使用该模式进行代理负载平衡的内容。\n本文由于简便起见将专注于数据面板，并为进一步简化，将只讨论使用 sidecar 模式的代理。\n注意：本文所提到的全部技术都是非常复杂的软件，由许多天才工程师所著， …","relpermalink":"/blog/using-linkerd-as-a-service-mesh-proxy-at-wepay/","summary":"本文是 WePay（一家做支付平台和风控产品的公司）使用 Linkerd 作为服务网格的代理的分享文章。","title":"WePay 如何使用 Linkerd 作为服务网格代理"},{"content":" UCloud 作为一家 To B 的公有云服务商，我们的 CTO 莫显峰经常说：“研发团队最首要的任务是提供稳定的服务，然后才是提供符合客户需求的、易用和低成本的产品”。但事实是，在提供稳定云服务的同时，面对快速发展的客户业务场景，我们还需要不断“拥抱变化”。\nMax Kanat-Alexander 在《简约之美：软件设计之道》（Code Simplicity）中提出的软件设计的 6 条法则恰到好处的描述了这一矛盾的事实，具体内容如下：\n软件的目的是帮助他人； 相比降低开发成本，更重要的是降低维护成本； 变化定律：软件存在的时间越久，它的某部分需要变化的可能性越大； 缺陷定律：软件出现缺陷的可能性，正比于你对它所做修改的程度； 简洁定律：软件任一部分的维护难度，正比于该部分的复杂程度； 测试定律：你对软件行为的了解程度，等于你真正测试它的程度。 正像法则 1、3、4 和 6 所说的软件的目的就是满足客户的需求，而随着时间的推移，用户需求总会改变；伴随着用户需求的改变，软件也需要适应新的需求而做修改，修改必然会引入缺陷；如果要排除缺陷就必须进行测试。\n但目前软件行业的现状大部分面临这样 …","relpermalink":"/blog/lightweight-service-mesh-practice-in-ucloud/","summary":"本文讲述的是 UCloud 对 Istio 做的部分改造，并在内部使用轻量 Service Mesh 的实践。","title":"轻量 Service Mesh 在 Ucloud 的实践"},{"content":" 黄挺在 GIAC 演讲 蚂蚁金服在服务化上面已经经过多年的沉淀，支撑了每年双十一的高峰峰值。Service Mesh 作为微服务的一个新方向，在最近两年成为领域的一个大热点，但是如何从经典服务化架构往 Service Mesh 的方向上演进，中间可能会遇到什么样的问题，几乎没有可以借鉴的经验。\n本文会给大家分享 Service Mesh 在蚂蚁金服的演进历程和在 2018 年 6 月举办的 GIAC 全球互联网架构大会中蚂蚁金服高级技术专家与现场人员关于 Service Mesh 的热门 QA 互动。\n前言 在过去的一段时间中蚂蚁金服已经开始采用 Service Mesh 来帮助解决一些架构上的问题，并且在 Service Mesh 如何更好地与经典的服务化架构结合上有一定的经验，希望借此分享和大家交流我们这部分的实践。使大家对蚂蚁金服当前的服务化架构有更多了解，并对 Service Mesh 如何解决经典服务化架构中的问题以及蚂蚁金服实际在落地 Service Mesh 中的时候的一些设计考虑和未来展望有更进一步的了解，也希望能与行业分享蚂蚁金服服务化架构现状。\n蚂蚁金服从单体应用 …","relpermalink":"/blog/migrating-from-classical-soa-to-service-mesh-in-ant-financial/","summary":"本文会给大家分享 Service Mesh 在蚂蚁金服的演进历程和在 2018 年 6 月举办的 GIAC 全球互联网架构大会中蚂蚁金服高级技术专家与现场人员关于 Service Mesh 的热门 QA 互动。","title":"蚂蚁金服是如何实现经典服务化架构向 Service Mesh 方向演进的？"},{"content":"本文为翻译文章，点击查看原文。\n如何确保微服务之间网络通信的可靠性、安全性和可管理性？使用服务网格吧！\n在过去一年中，Istio服务网格技术引发关注度和吸引力的持续提升，这是一件非常有趣的事情。事实上，在我写这篇文章时，Istio 仅为 0.8 版本，但对于最近两届KubeCon/CloudNativeCon活动而言，它一直是热门话题，仅在丹麦的活动中就有超过十几个不同的活动议题。那么它为什么会这样受欢迎？\n在深入研究 Istio 受欢迎的原因之前，让我们先来介绍一下服务网格。这是一个通用术语，其早已被投入在多个不同场景中。例如定义不同无线设备之间的通信方法；或者定义一个系统，各个应用程序可以直接通过它与其他应用程序通信。最近，这个术语被用来表示应用或微服务的网络，以及它们之间的互相作用关系。后者是本文的重点。\n事实上红帽公司一直参与云原生和微服务领域建设，包括四年前决定将 OpenShift 向 Kubernetes 和 Docker 转变，这帮助我们理解了服务网格技术，尤其是 Istio 的重要性。本文将探讨为什么我会坚信 Istio 会很受欢迎的四个原因。\n微服务和转型 纵观你整 …","relpermalink":"/blog/the-rise-of-the-istio-service-mesh/","summary":"本文将探讨为什么我会坚信 Istio 会很受欢迎并给出了四个原因，分别从微服务与转型、微服务先驱 Netflix OSS 的案例、分布式架构的方面来阐述微服务使用服务网格的必然性。","title":"Istio 服务网格的崛起"},{"content":"本文为翻译文章，点击查看原文。\nIstio 已经成为一种流行且可靠的服务网格管理平台，使用它可以更轻松地部署、操作和扩展跨云部署的微服务。作为保证这些服务网格的一种方式，Twistlock 已经与 Istio 集成，以丰富平台的连接机器学习功能。Twistlock 通过使用 Twistlock 数据来隔离受损服务并提供合规策略来执行安全配置，以及 Istio 运行的其他堆栈。\n随着云原生成为构建和运行现代的基于 Web 的大规模应用程序的默认方式，组织需要越来越复杂的工具来将基本复杂性从日常操作中抽象出来。Kubernetes 显然是编排调度军备竞赛的赢家，并且已经提炼出了管理大型计算节点的复杂性。但是，由于 Kubernetes 可以实现更大规模的部署，因此我们可以利用其平台级别原语的配套技术使管理大型服务组合变得更简单。\n例如，使用 Kubernetes 您可以轻松部署应用程序并将其扩展到 1000 个节点的集群，并处理部署和节点故障。但是，为该服务路由流量、监控服务的整体运行状况（而不仅仅是单个节点和 pod）以及确保该服务与集群内其他服务之间的公平资源分配可能很复杂。 …","relpermalink":"/blog/twistlock-makes-istios-security-layer-more-robust-easier-to-monitor/","summary":"本文介绍网络安全公司 Twistlock 如何实现 Istio service mesh 的可视化并增强微服务的安全性","title":"Twistlock 使 Istio 的安全层更强大，更易于监控"},{"content":" 本文转载自敖小剑的博客\n接前文，继续分析 Mixer Check Cache 的源码，这次的重点是签名算法，也就是 Referenced::Signature() 方法。\n前情回顾：\nReferenced 保存的是 mixer adapter 使用的引用属性的一个组合，也就是前面例子中的 “a,b,c”或者“a,b,c不存在” Referenced 中有两个数据结构： std::vector\u0026lt;AttributeRef\u0026gt; absence_keys_ 和 std::vector\u0026lt;AttributeRef\u0026gt; exact_keys_，exact_keys_保存的是一定要出现的属性，absence_keys_中保存的是没有出现的属性 基本流程 我们来看详细源代码，具体在文件src/istio/mixerclient/referenced.cc中，代码的基本流程非常清晰：\nbool Referenced::Signature(const Attributes \u0026amp;attributes, const std::string \u0026amp;extra_key, std::string *signature) …","relpermalink":"/blog/istio-mixer-cache-part4-signature/","summary":"接前文，继续分析 Mixer Check Cache 的源码，这次的重点是签名算法，也就是 Referenced::Signature() 方法。","title":"Istio Mixer Cache 工作原理与源码分析 part4－签名"},{"content":" 本文转载自敖小剑的博客\n经过前面基本概念和实现原理的介绍，大家对 mixer check cache 应该有了基本的了解，下面我们开始展开源代码来细细研读。\nCheck Cache 的主要流程 Check Cache 的调用入口 对 mixer cache 的调用在代码 proxy/src/istio/mixerclient/client_impl.cc中的方法 Check() 中，此处跳过 quota cache 的内容：\nCancelFunc MixerClientImpl::Check( const Attributes \u0026amp;attributes, const std::vector\u0026lt;::istio::quota_config::Requirement\u0026gt; \u0026amp;quotas, TransportCheckFunc transport, CheckDoneFunc on_done) { ++total_check_calls_; std::unique_ptr\u0026lt;CheckCache::CheckResult\u0026gt; check_result( new …","relpermalink":"/blog/istio-mixer-cache-part3-main/","summary":"经过前面基本概念和实现原理的介绍，大家对 mixer check cache 应该有了基本的了解，下面我们开始展开源代码来细细研读。","title":"Istio Mixer Cache 工作原理与源码分析 part3—主流程"},{"content":"Istio 为网格中的微服务提供了较为完善的安全加固功能，在不影响代码的前提下，可以从多个角度提供安全支撑，官方文档做了较为详细的介绍，但是也比较破碎，这里尝试做个简介兼索引，实现过程还是要根据官方文档进行。\nIstio 的安全功能主要分为三个部分的实现：\n双向 TLS 支持。 基于黑白名单的访问控制。 基于角色的访问控制。 JWT 认证支持。 首先回顾一下 Istio 网格中的服务通信过程：\n利用自动或者手工注入，把 Envoy Proxy 注入到每个服务 Pod 中，用 Sidecar 的方式运行。 Pod 初始化过程里，使用 iptables 劫持所在 Pod 的出入流量。 服务间的通信，从原来的直接通信，转换为现在的 Envoy 之间通信，Envoy 在这里同时作为客户端和服务端负载均衡组件。 Envoy 的工作过程中，可能会和 Mixer、Pilot 以及 Citadel 等组件发生互动。 双向 TLS 支持 双向 TLS 支持主要针对的是通信方面，把明文传输的服务通信，通过转换为 Envoy 之间的加密通信。这一安全设置较为基础，可以在全局、Namespace 或者单个服务 …","relpermalink":"/blog/istio-security-notes-by-fleeto/","summary":"Istio 为网格中的微服务提供了较为完善的安全加固功能，在不影响代码的前提下，可以从多个角度提供安全支撑，官方文档做了较为详细的介绍，但是也比较破碎，这里尝试做个简介兼索引，实现过程还是要根据官方文档进行。","title":"Istio 安全设置笔记"},{"content":"本文为翻译文章，点击查看原文。\n现代服务网格架构提供了很多的新功能，基础设施相关的依赖部分被逐步从代码中移除，极大的降低了编码工作量。除此之外，这一架构的智能路由功能还把金丝雀发布以及类似功能大大的简化了。\n接下来的内容会探讨一下，Istio 路由规则是如何使用 OpenTracing Baggage 的。\nIsto 路由规则 想像一个场景，这个场景中我们需要通过 User-Agent Header 来鉴别 Safari 用户，并把它们重定向到服务的一个特定版本去。这是一个典型的金丝雀场景：新版本发布时，首先开放给一部分用户。然而很明显只有第一个服务能够接收到 User-Agent 头，如果路由规则中涉及到调用关系图中位置较低（靠后）的服务，就不得不把这个 Header 信息传播给所有途中经过的服务。这是一个分布式上下文传播的典型用例，很多跟踪系统都有这个功能。我们接下来会看看 Jaeger 的 OpenTracing 实现。\nBaggage 条目是字符串组成的键值对，和 Span/SpanContext 互相关联，在一个 Trace 的范围内，会在所有的下游 Span 中进行传播。\n …","relpermalink":"/blog/istio-routing-using-opentracing-baggage-distributed-context-propagation/","summary":"这是一篇关于在 Istio 路由规则中使用 Opentracing Baggage 对流量进行分布式追踪的教程。","title":"在 Istio 中使用 OpenTracing Baggage 进行传播和路由"},{"content":"Aspen Mesh 很喜欢用gRPC。Apen Mesh 面向公众的 API 和许多内部 API 大多都是使用 gRPC 构建的。如果您还没有听说过 gRPC（熟练掌握 gRPC 真的很难），那么我先为您简单的介绍下，它是一种新型、高效和优化的远程过程调用（RPC）框架。gRPC 基于protocol buffer序列化格式和HTTP/2网络协议。\n使用HTTP/2协议，gRPC应用程序可以利用多路复用请求显著提高连接利用率，而且比起如HTTP/1.1等其他协议具有更多增强功能。此外，protocal buffer 是以二进制方式对结构化数据进行序列化，这比起基于文本的序列化方式更简单且可扩展，还可以显着提高性能。将这两个结果组合在一个低延迟和高度可扩展的 RPC 框架中，这实质上就是 gRPC。此外，不断增长的 gRPC 生态支持使用多种语言编写应用程序，例如（C ++、Java、Go 等），还包括大量第三方库。\n除了上面列出的好处之外，gRPC 让我最喜欢的一点是可以让我以简单直观的方式指定 RPC（使用 protobuf IDL）以及客户端调用服务器端的方法，就好像是调用本地函 …","relpermalink":"/blog/tracing-grpc-with-istio/","summary":"本文介绍的是如何在 Istio 中使用 grpc 并设置跟踪（tracing）与 header 传播，包括 gRPC 到 grpc 请求传播 header、gRPC 到 HTTP 请求传播 header、使用 grpc-gateway 时传播 header 等","title":"在 Istio 中跟踪 gRPC"},{"content":"本文为翻译文章，点击查看原文。\n把单体应用拆分为微服务之后，会得到不少好处，例如稳定性的提高、持续运行时间的增长以及更好的故障隔离等。然而把大应用拆分为小服务的过程中，也会引入一个风险就是——可能的受攻击面积变大了。从前单体应用中通过函数调用完成的通信，现在都要通过网络完成。提高安全性从而避免这个问题带来的安全影响，是微服务之路上必须要着重考虑的问题。\nAspen Mesh 的基础是一个开源软件：Istio，他的关键能力之一就是为微服务提供安全性和策略控制方面的支持。Istio 为 Service Mesh 增加了很多安全特性，但是这并不是说微服务的安全工作就结束了。网络安全策略也是需要着重考虑的问题（推荐阅读：In the land of microservices, the network is the king(maker)），结合网络策略，可以检测和应对针对服务网格基础设施的攻击，从而解决各种安全威胁。\n后面的内容将会看看 Istio 所能够解决的问题，其中包含边缘通信的流量控制、网格内通信加密以及 7 层策略控制等。\n边缘通信安全 针对不当进入网格的流量，Istio 加入了一 …","relpermalink":"/blog/service-mesh-security-addressing-attack-vectors-with-istio/","summary":"把单体应用拆分为微服务的过程中，会引入一个风险就是——可能的受攻击面积变大了。从前单体应用中通过函数调用完成的通信，现在都要通过网络完成。提高安全性从而避免这个问题带来的安全影响，是微服务之路上必须要着重考虑的问题。","title":"Service Mesh 安全：用 Istio 应对攻击"},{"content":" 转载自敖小剑的博客\n前言 经过前面的基础概念的介绍，我们现在已经可以勾勒出一个 mixer cache 的实现轮廓，当然实际代码实现时会有很多细节。但是为了方便理解，我们在深入细节之前，先给出一个简化版本，让大家快速了解 mixer cache 的实现原理。后面的章节我们再逐渐深入。\nMixer Cache 分为两个部分：\ncheck cache quota cache 简单起见，我们先关注 check cache，在 check cache 讲述清楚之后，我们再继续看 quota cache。\n备注：istio 一直在持续更新，以下代码来源于 istio 0.8 版本。\nMixer Check Cache 的构造 Mixer Cache 在实现时，在 envoy 的内存中，保存有两个数据结构：\nclass CheckCache { std::unordered_map\u0026lt;std::string, Referenced\u0026gt; referenced_map_; using CheckLRUCache = utils::SimpleLRUCache\u0026lt;std::string, …","relpermalink":"/blog/istio-mixer-cache-part2-principle/","summary":"经过前面的基础概念的介绍，我们现在已经可以勾勒出一个 mixer cache 的实现轮廓，当然实际代码实现时会有很多细节。但是为了方便理解，我们在深入细节之前，先给出一个简化版本，让大家快速了解 mixer cache 的实现原理。后面的章节我们再逐渐深入。","title":"Istio Mixer Cache 工作原理与源码分析 part2－工作原理"},{"content":"前言 本系列文章将详细介绍 Istio 中 Mixer Cache 的工作原理，为了避免空谈，将引入广大程序员同学喜闻乐见的源码分析环节，并结合 Mixer 的接口 API，详细展现 Mixer Cache 的各种细节。\n预警：Mixer Cache 系列文章除了本文讲述概念比较简单外，其它文章会包含大量复杂和繁琐的细节，包括设计／实现／API 等，适合追求深度的同学。\n阅读本系列文章前，请确保对 Service Mesh 和 Istio 有基本的认知，临时上车的同学请自觉补课：\nService Mesh：下一代微服务: Service Mesh 介绍 服务网格新生代-Istio：Istio 介绍 此外如果对 Mixer 职责和设计不熟悉的同学，请先阅读下文（本文可以理解为是此文的番外篇）：\nService Mesh 架构反思：数据平面和控制平面的界线该如何划定？ 在这篇文章中，出于对 Istio 性能的担忧和疑虑，我们探讨了 Mixer 的架构设计，工作原理，并猜测了 Mixer 的设计初衷。期间，我们介绍到，为了保证运行时性能，避免每次请求都远程访问 Mixer，Istio …","relpermalink":"/blog/istio-mixer-cache-part1-concepts/","summary":"本系列文章将详细介绍 Istio 中 Mixer Cache 的工作原理，为了避免空谈，将引入广大程序员同学喜闻乐见的源码分析环节，并结合 Mixer 的接口 API，详细展现 Mixer Cache 的各种细节。","title":"Istio Mixer Cache 工作原理与源码分析 part1－基本概念"},{"content":"本文为翻译文章，点击查看原文。\n到目前为止，Istio 提供了一个简单的 API 来进行流量管理，该 API 包括了四种资源：RouteRule、DestinationPolicy、EgressRule 和 Ingress（直接使用了 Kubernets 的 Ingress 资源）。借助此 API，用户可以轻松管理 Istio 服务网格中的流量。该 API 允许用户将请求路由到特定版本的服务，为弹性测试注入延迟和失败，添加超时和断路器等等，所有这些功能都不必更改应用程序本身的代码。\n虽然目前 API 的功能已被证明是 Istio 非常引人注目的一部分，但也有一些用户反馈该 API 确实有一些缺点，尤其是在使用它来管理包含数千个服务的大型应用，以及使用 HTTP 以外的协议时。此外，使用 Kubernetes Ingress 资源来配置外部流量的方式已被证明不能满足需求。\n为了解决上述缺陷和其他的一些问题，Istio 引入了新的流量管理 API v1alpha3，新版本的 API 将完全取代之前的 API。尽管 v1alpha3 和之前的模型在本质上是基本相同的，但旧版 API 并不向后 …","relpermalink":"/blog/introducing-the-istio-v1alpha3-routing-api/","summary":"本文讲解的是 Istio 0.8 中的一项重大变化——引入 v1alpha3 routing API，旧版本的 API 将不再兼容，未来会提供模型转换工具来转换旧版 API。","title":"Istio v1aplha3 routing API 介绍"},{"content":"本文为翻译文章，点击查看原文。\n说明 开发人员正在摆脱大型单体应用的束缚，转而采用小巧而专一的微服务，以加速软件开发并加强系统弹性。为了满足这个新生态的需求，开发人员需要为部署的微服务创建一个具有负载均衡、高级流量管理、请求跟踪和连接功能的服务网络。\n概述 如果您花时间开发过应用程序，那么有件事情您肯定明白：单体应用正成为过去。当今的应用程序都是关于服务发现、注册、路由和连接。这给微服务的开发和运维人员提出了新的挑战。\n如果您的服务网格在规模和复杂性上不断增长，您可能想知道如何理解和管理服务网格。我们也遇到了同样的问题：如何使这些越来越多的微服务能够彼此连接、负载均衡并提供基于角色的路由？如何在这些微服务上启用传出流量并测试金丝雀部署？仅仅创建一个独立的应用程序还不够，所以我们该如何管理微服务的复杂性呢？\nIstio 是 IBM、Google 和 Lyft 合作创建的项目，旨在帮助您应对这些挑战。Istio 是一种开放技术，它为开发人员提供了一种这样的方式：无论是什么平台、来源或供应商，微服务之间都可以无缝连接，服务网格会替您管理和保护微服务。在下面的开发之旅中， …","relpermalink":"/blog/manage-microservices-traffic-using-istio/","summary":"开发人员正在摆脱大型单体应用的束缚，转而采用小巧而专一的微服务，以加速软件开发并加强系统弹性。为了满足这个新生态的需求，开发人员需要为部署的微服务创建一个具有负载均衡、高级流量管理、请求跟踪和连接功能的服务网络。","title":"使用 Istio 为微服务提供高级流量管理和请求跟踪功能"},{"content":"本文译者 Grace。\n基于微服务的架构是未来的趋势，但是实现这种架构会面临许多困难。现代应用架构远比过去的架构复杂，因此实现微服务架构将会带来了一系列特殊的挑战，而服务网格可以帮我们解决很多问题。\n最近一段时间，管理者不再专注于调试单个应用程序服务器，相反，现代系统就像是一群牛，研究整体的行为远比单个的服务器更有意义，分布式系统就是一个典型。\n微服务是一种分布式架构，目的在于通过不断调整自身以适应当前流量状况的变化，例如，有一组处理客户端请求路由的容器，改变这组容器，反过来也意味着路由表在不断变化，由此反映了应用程序端点的变化位置。与此同时，在任何架构体系中都会有过去的遗留物，从必须使用单个大型数据库服务器的应用程序到捆绑 API 以使其看起来是以服务为重点的遗留系统。\n而服务网格是当前最先进的微服务模式。它建立在容器以及容器编排之上，配有处理内部服务通信的专用控制面。它负责协调分布式网格的微服务所需的安全性，路由，身份验证，授权和类似功能，服务网格将这些功能从应用程序（或应用程序的服务组件）中剥离出来作为可编程的基础组件。虽然不是所有的公司都需要如此复杂的服务网格（尽管这些公司大部 …","relpermalink":"/blog/8-ways-a-service-mesh-eases-microservices-deployment/","summary":"基于微服务的架构是未来的趋势，但是实现这种架构会面临许多困难。现代应用架构远比过去的架构复杂，因此实现微服务架构将会带来了一系列特殊的挑战，而服务网格可以帮我们解决很多问题。","title":"服务网格：8 种方式简化微服务部署"},{"content":"儿童节期间，拖拉了一个多月的 Istio 0.8 正式发布了，这可能是 Istio 1.0 之前的最后一个 LTS 版本，意义重大。\n新版本中，原来的 Kubernetes 安装文件 install/kubernetes/istio.yaml，变成了 install/kubernetes/istio-demo.yaml，是的，你没看错，这个 LTS 的安装文件名字叫 demo。查看了一下文档，大概察觉到不靠谱的 Istio 发布组的意图了：这个项目的组件相对比较复杂，原有的一些选项是靠 ConfigMap 以及 istioctl 分别调整的，现在通过重新设计的 Helm Chart，安装选项用 values.yml 或者 helm 命令行的方式来进行集中管理了。下面就由看看 Istio 的 Helm Chart 的安装部署及其结构。\n使用 Helm 安装 Istio 安装包内的 Helm 目录中包含了 Istio 的 Chart，官方提供了两种方法：\n用 Helm 生成 istio.yaml，然后自行安装。 用 Tiller 直接安装。 很明显，两种方法并没有什么本质区别。例如第一个命 …","relpermalink":"/blog/helm-chart-for-istio-0-8/","summary":"本文将带您探究 Istio 0.8 LTS 版本中的 Helm Chart 的安装部署及其结构。","title":"Istio 0.8 的 Helm Chart 解析"},{"content":" 本文为翻译文章，点击查看原文。\n当我们谈论服务网格的时候，有几个问题经常被提及。这些问题的范围覆盖从简单的了解服务网格的历史，到产品和架构相关的比较深入的技术问题。\n为了回答这些问题，通过 Aspen Mesh 之旅，我们带来三个主题的系列博文来讨论我们为什么选择了 Istio。\n作为开始，我将重点讨论我最经常被问到的问题之一：\n为什么你选择服务网格，是什么原因促使你这样做？\nLineRate：高性能负载均衡软件 这个旅程起源于来自 Boulder 的初创公司 LineRate，该公司在 2013 年被 F5 Networks 公司收购。LineRate 除了是我曾经有幸参与的最聪明、最有才华的工程团队，还是一款轻量级高性能 L7 软件代理。当我说高性能时，我正在谈论的是如何将 5 年前在数据中心已经存在的服务器，变成一个高性能 20+ Gbps 200,000+ HTTP 请求每秒的全功能负载。\n虽然性能本身是引入注目的并为我们的客户打开了大门，但是我们的出发点在于客户期望付费的是容量，而不是硬件。这种见解是 LineRate 的核心价值主张。这个简单的概念将使我们的客户能够改变他 …","relpermalink":"/blog/the-path-to-service-mesh/","summary":"通过 Aspen Mesh 之旅，我们带来三个主题的系列博文来讨论我们为什么选择了 Istio。","title":"服务网格之路"},{"content":"本文为翻译文章，点击查看原文。\nAspenMesh 提供一种 Istio 的分布式架构支持，这意味着即使与上游 Istio 项目无关，我们也需要能够测试和修复 Bug。为此我们已开发构建了我们自己的打包和测试基础架构方案。如果你对 Istio 的 CI（持续集成）也感兴趣，请参考我们已经投入使用，可能有用但还没有提交给 Circle CI 或 GKE 的组件。\n这篇文章描述的是我们如何制作一个新的Minikube-in-a-Container容器和使用Jenkins Pipeline来构建和测试 Istio 的流程脚本。如果你觉得有必要，你可以通过docker run上运行 minikube 容器，然后在容器中部署功能性的 kubernetes 集群，不需要使用时可随时删除。Jenkins bits 现在可帮助你构建 Istio，也可以作为初始环境，以便在容器内构建容器。\nMinikube-in-a-container 这部分描述了我们如何构建一个可以在构建过程中用来运行 Istio 冒烟测试的 Minikube-in-a-container 镜像。我们最初不是这么想的，我们最初使用本 …","relpermalink":"/blog/building-istio-with-minikube-in-a-container-and-jenkins/","summary":"本文讲述如何制作一个新的 Minikube-in-a-Container 容器和使用 Jenkins Pipeline 来构建和测试 Istio 的流程脚本。","title":"使用 Minikube-in-a-Container 和 Jenkins 构建 Istio"},{"content":"北京时间 2018 年 6 月 1 日（儿童节）上午 9: 30 Istio 0.8.0 LTS（长期支持版本）发布。该版本除了常见的一堆错误修复和性能改进之外，还包含以下更新和新功能。\nIstio 0.8 发布 网络 改进了流量管理模型。我们终于准备好了推出新的流量管理配置模型。该模型增加了许多新功能并解决了先前模型的可用性问题。istioctl 中内置了一个转换工具来帮助您迁移旧模型。试用新的流量管理模型。 Ingress/Egress 网关。我们不再支持将 Kubernetes Ingress 配置与 Istio 路由规则相结合，因为这会导致一些错误和可靠性问题。Istio 现在支持独立于 Kubernetes 和 Cloud Foundry 平台的 ingress/egress 网关，并与路由规则无缝集成。 **新的网关支持基于服务器名称指示（Server Name Indication）**的路由，以及根据 SNI 值提供证书。HTTPS 访问外部服务将基于 SNI 自动配置。 Envoy v2。用户可以选择使用 Envoy 的 v2 API 注入 sidecar。在这种模式 …","relpermalink":"/blog/istio-0-8-release-note/","summary":"北京时间 2018 年 6 月 1 日（儿童节）上午 9: 30 Istio 0.8.0 LTS（长期支持版本）发布。该版本除了常见的一堆错误修复和性能改进之外，还包含以下更新和新功能。","title":"Istio 0.8 发布了！"},{"content":"本文为翻译文章，点击查看原文。\n在今年的哥本哈根 Kubecon 大会上，Weaveworks 的 CEO Alexis Richardson 与 Varun Talwar（来自一家隐形创业公司）谈到了 GitOps 工作流程和 Istio。会后 Weaveworks 的 Stefan Prodan 进行了的演示，介绍如何使用 GitOps 上线和管理 Istio 的金丝雀部署。\n会谈和演示中解释了：\n什么是 GitOps？为什么需要它？ Istio 和 GitOps 的最佳实践是如何管理在其上运行的应用程序的。 如何使用 GitOps 工作流程和 Istio 进行金丝雀部署。 什么是 GitOps？ GitOps 是实现持续交付的一种方式。“GitOps 使用 Git 作为声明式基础架构和应用程序的真实来源”Alexis Richardson 说。\n当对 Git 进行更改时，自动化交付管道会上线对基础架构的更改。但是这个想法还可以更进一步——使用工具来比较实际的生产状态和源代码控制中描述的状态，然后告诉你什么时候集群的状态跟描述的不符。\nGit 启用声明式工具 通过使用 Git 这样 …","relpermalink":"/blog/gitops-for-istio-manage-istio-config-like-code/","summary":"本文是 Weaveworks 的 CEO 对 GitOps 工作流程和 Istio 的看法。本文还介绍了如何使用 GitOps 上线和管理 Istio 的金丝雀部署。以上观点来自哥本哈根 Kubecon 上的 Weaveworks 的分享。","title":"Istio 的 GitOps—像代码一样管理 Istio 配置"},{"content":"作者介绍：田晓亮，8 年软件行业经验，曾就职于三星，2012 年进入云计算领域，对 PaaS，DevOps，APM 有深入的研究和实践经验，方案支撑近千台 VM 中的应用部署监控。2016 年加入华为担任架构师，负责微服务的 Go 语言开发框架及 Service Mesh 设计和落地。\n图 1 微服务架构需要解决的问题\n微服务将原本内存中函数的调用转换为网络中的调用后，就牵扯到这些问题，而任何一个分支展开，都会涉及一系列的问题。业务开发者也许真的有精力去学习架构相关的复杂问题，然而对于公司来说，真正有价值的是业务本身，让业务开发者解决这些问题需要花费浪费大量的时间精力，导致业务上线受到影响。那我们来看看是否有便捷的方式来解决业务开发者的痛点。\nChassis 模式 一句话来概括：一种语言开发框架来作为微服务开发的底座，封装掉复杂性，帮助你解决跨网络带来的问题，让用户聚焦在上层业务逻辑的开发。通常情况下会实现以下功能：\n日志、Metrics、分布式追踪数据上报 健康检查 对接统一的配置中心实现动态配置 对接注册中心 实现负载均衡、熔断降级、容错、限流等保证高可靠运行的功能 现在我们来看看 …","relpermalink":"/blog/the-desigin-patterns-for-a-commercial-service-mesh/","summary":"本文分享了微服务中存在的问题，以及如何通过商用级的 Service Mesh 设计来解决问题，作者分享了华为的 Service Mesh 设计之道。","title":"一个商用级 Service Mesh 服务的设计之道"},{"content":"在 Kubernetes 称为容器编排的标准之后，Service Mesh 开始火了起来，但是很多文章讲概念的多，讲技术细节的少，所以专门写一篇文章，来解析 Service Mesh 背后的技术细节。\n一、Service Mesh 是 Kubernetes 支撑微服务能力拼图的最后一块\n在上一篇文章为什么 kubernetes 天然适合微服务中我们提到，Kubernetes 是一个奇葩所在，他的组件复杂，概念复杂，在没有实施微服务之前，你可能会觉得为什么 Kubernetes 要设计的这么复杂，但是一旦你要实施微服务，你会发现 Kubernetes 中的所有概念，都是有用的。\n微服务设计 在我们微服务设计的十个要点中，我们会发现 Kubernetes 都能够有相应的组件和概念，提供相应的支持。\n其中最后的一块拼图就是服务发现，与熔断限流降级。\n众所周知，Kubernetes 的服务发现是通过 Service 来实现的，服务之间的转发是通过 kube-proxy 下发 iptables 规则来实现的，这个只能实现最基本的服务发现和转发能力，不能满足高并发应用下的高级的服务特性， …","relpermalink":"/blog/deepin-service-mesh-tech-details/","summary":"在 Kubernetes 称为容器编排的标准之后，Service Mesh 开始火了起来，但是很多文章讲概念的多，讲技术细节的少，所以专门写一篇文章，来解析 Service Mesh 背后的技术细节。","title":"深入解读 Service Mesh 背后的技术细节"},{"content":"本文是 Istio 管理 Java 微服务的案例教程，使用的所有工具和软件全部基于开源方案，替换了 redhat-developer-demos/istio-tutorial 中的 minishift 环境，使用 kubernetes-vagrant-centos-cluster 替代，沿用了原有的微服务示例，使用 Zipkin 做分布式追踪而不是 Jaeger。\n本文中的代码和 YAML 文件见 GitHub。\n准备环境 在进行本教程前需要先准备以下工具和环境。\n8G 以上内存 Vagrant 2.0+ Virtualbox 5.0 + 提前下载 kubernetes1.9.1 的 release 压缩包 docker 1.12+ kubectl 1.9.1+ maven 3.5.2+ istioctl 0.7.1 git curl、gzip、tar kubetail siege 安装 Kubernetes 请参考 kubernetes-vagrant-centos-cluster 在本地启动拥有三个节点的 kubernetes 集群。\ngit clone …","relpermalink":"/blog/istio-service-mesh-tutorial/","summary":"本文是 Istio 管理 Java 微服务的案例教程，使用的所有工具和软件全部基于开源方案，替换了 redhat-developer-demos/istio-tutorial 中的 minishift 环境，使用 kubernetes-vagrant-centos-cluster 替代，沿用了原有的微服务示例，使用 Zipkin 做分布式追踪而不是 Jaeger。","title":"Istio Service Mesh 教程"},{"content":"今天我们不谈技术，不谈架构，也不谈具体的产品，我们来聊一聊在未来一两年之内，Service Mesh 技术会在微服务相关的市场带来什么样的变化？\n大家好，我是敖小剑，今天给大家带来的这个主题叫做“Service Mesh：重塑微服务市场”。\n刚才主持人张亮提到说，过去一年 Service Mesh 成为一个热词。基本上，在国内的话，我差不多是 Service Mesh 最早的布道师。可能如果大家之前有看相关的资料的话，应该会看到一些我的资料。我先后做过几场的演讲，做过一些技术的分享，也写过很多文章。但在此之前，这些内容可能更多的都是集中在技术领域。那今天我们会特殊一点，我们今天不谈详细的技术，不谈具体的架构，我们也不谈具体的产品。后面的这些名词，Istio/Conduit/Envoy/Linkerd/Nginmesh，这些词可能听过，可能没听过，但没问题，今天这些我们统统都不讲。我们今天要讲另外一个东西：我们会聊一聊在未来一两年之内，Service Mesh 技术会在微服务相关的市场带来什么样的变化？\n主要内容会是三大块：首先我们会看一下目前微服务的市场的一些现状，然后接下来我们会探讨 …","relpermalink":"/blog/service-mesh-rebuild-microservice-market/","summary":"今天我们不谈技术，不谈架构，也不谈具体的产品，我们来聊一聊在未来一两年之内，Service Mesh 技术会在微服务相关的市场带来什么样的变化？","title":"Service Mesh：重塑微服务市场"}]