在启用了Istio服务网格的Kubernetes集群中，缺省情况下只能在集群内部访问网格中的服务，要如何才能从外部网络访问这些服务呢？ Kubernetes和Istio提供了NodePort，LoadBalancer，Kubernetes Ingress，Istio Gateway等多种外部流量入口的方式，面对这么多种方式，我们在产品部署中应该如何选择？ 本文将对Kubernetes和Istio对

本文为翻译文章，点击查看原文。 [编者按] 之前有社区成员询问是不是想尝试Knative时，必须要安装Istio才行，今天就告诉大家一种Istio的替代方案，使用Solo.io公司研发的Gloo来替代Istio来使用Knative。 在Knative中，Istio的主要作用是作为一个Ingress技术。Gloo现在加入Istio作为Knative的集成和支持Ingress。有关快速演示demo，请

本文为翻译文章，点击查看原文。 编者按 文章介绍了基于Kubernetes的服务网格，简要的说明了服务网格的作用，sidecar的作用以及服务网格两个重要实现：Istio与Linkerd的起源和结构，鼓励大家上手尝试。 ALEN KOMLJEN 2018年1月28日，阅读时间4分钟 几个月前我同事问起我对于如何集成Linkerd到我们新的运行在Kubernetes应用里面有什么想法。我的第一反应是

本文为翻译文章，点击查看原文。 编者按 本文是一篇来自Glasnostic官网的博客。作为介绍熔断系列文章的第二篇，本文通过介绍开发人员和运维人员两种不同视角下的微服务典型应用场景，引入进阶的熔断功能。进而分别介绍和对比了熔断功能的三种不同实现：Hystrix, Service Mesh (Istio、Linkerd) 和 Glasnostic。 前言 这是关于熔断的两部分系列文章的第二部分。在第

本文为翻译文章，点击查看原文。 编者按 本文阐述了如何使用Helm和Istio实现手动金丝雀发布。 我近期工作的项目目标是为微服务应用的金丝雀/分阶段发布制定一套流水线。而这些微服务被部署在Azure Kubernetes集群上（AKS）。 本文假设您熟悉Kubernetes，Helm和Istio流量管理。 这篇文章描述了发布的基本要求，为这些要求选择的发布策略，以及每个阶段实现细节。 在后面的文

编者按 本文介绍了使用Envoy来加速Monzo，对比了使用Linkerd和Envoy，通过试验证明Envoy拥有更小的延迟。 我们基础设施的一个核心组件是远程过程调用(RPC)系统。它允许微服务通过网络以可伸缩和可容错的方式彼此通信。 每当评估RPC系统时，通常会查看以下几个关键指标： 高可用，服务之间的通信应该尽可能快。RPC子系统应该做到延迟开销最小化，并在路由请求时避免路由到失败的服务副本

本文为翻译文章，点击查看原文。 编者按 本文演示了如何基于Go语言、gRPC和Protobuf技术构建一个微服务，并着重介绍了实现Istio可观测功能的三大支柱：日志、度量和追踪，以及与之对应的工具Logrus、Prometheus、Grafana、Jaeger等。通过文章内容和示例代码，读者会对如何构建gRPC技术栈的微服务和使用Istio可视化工具观测服务的实现方案有一个全面的认识。 在过去的

前言 本文内容整理自5月25日在 Kubernetes & Cloud Native Meetup 上海站发表的主题演讲，主要介绍了Service Mesh最新的产品动态，分析其发展趋势和未来走向；结合蚂蚁的上云实践，阐述在云原生背景下Service Mesh的核心价值，以及对云原生落地的关键作用。 内容主要有三个部分： Service Mesh产品动态：介绍最近半年 Service Me

本文为翻译文章，点击查看原文。 编者按 作者是Banzai Cloud的工程师，文章介绍了istio环境下，如何结合Prometheus进行网络度量指标监测，给出了一些示例配置。最后，还推广了一下Banzai Cloud自家的Pipeline，天然支持跨云、混合云情况下的网络度量监测，欢迎体验。 Istio的一个核心功能就是网络流量的可观察性。因为所有服务间的通信都通过Envoy代理，而且Isti

本文为翻译文章，点击查看原文。 编者按 本文通过介绍一个构建和运行微服务的平台dotCloud的历史、容器间路由，进而阐述了它与现代服务网格的相同与不同之处；接着介绍了如何实现一个类似的服务网格以及其与Istio的区别；最后引入了SuperGloo的介绍，一个管理和编排大规模服务网格的开源项目。 前言 有许多的材料是关于服务网格的，这是另一个。为什么呢？因为我想分享给你们一个观点：有一些人认为服务

SMI介绍 SMI是什么？ 5月21号，在 kubeconf上，微软联合一众小伙伴，宣布了 Service Mesh Interface，简称SMI。SMI是一个服务网格规范，定义了通用标准，包含基本特性以满足大多数场景下的通用需求。 援引来自SMI官方网站 smi-spec.io 的介绍资料，对 Service Mesh Interface 的定位是 ： A standard interface

本文为翻译文章，点击查看原文。 编者按 本文介绍了使用Jenkins X实现ChatOps。很好的阐述了如何使用Jenkins X来实践ChatOps，文中手把手带我们从零开始完成了一次Kubernetes Native的CI/CD之旅。 Jenkins X 主逻辑是基于GitOps理念。每个更改都必须用Git记录，并且只允许Git触发集群中发生更改的事件。这种逻辑是Jenkins X的基石，到目

本文为翻译文章，点击查看原文。 编者按 作为探索为Envoy构建控制平面系列文章的第5部分，本文介绍了部署控制平面的选项与权衡，着重阐述了保持控制平面与数据平面解耦的几大好处，并且在文章结尾建议构建一个可拔插的控制平面以支持各种新特性、拓展和适配。 前言 这是探索为Envoy构建控制平面系列文章的第5部分。 采用一种机制来动态更新Enovy的路由、服务发现和其他配置 识别构成控制平面的组件，包括支

前言 很多人学习和使用envoy时，很容易混淆一些概念，比如把异常点驱逐和微服务熔断混为一谈，分不清最大驱逐比与恐慌阈值的区别等。本文将基于envoy官方文档(v1.10.0)，详细介绍异常点检测的类型、驱逐算法以及相关概念的解析，并且最后对易混淆的几个概念进行辨析。 简介 异常点检测(Outlier detection)和驱逐(Ejection)是用来动态确定上游集群中是否有表现不同于其他主机的

本文为翻译文章，点击查看原文。 编者按 本文介绍如何为 Envoy 构建控制面指南的第2部分：识别控制平面的各个组件。对实施Envoy控制平面需要了解的基础知识很有帮助。也算是Envoy的概念介绍。 在这个系列文章的前一篇中，我们浏览了Envoy动态配置对于在云原生环境中运行Envoy是多么的重要。在这篇文章中，我们来一起看看为了支持控制平面，我们需要如何协调各个组件。 由于操作环境的变化很大，因

大会背景介绍 2019年6月24-26日，KubeCon + CloudNativeCon + Open Source Summit大会在上海世博中心举行。本次大会是由CNCF的LC3和Linux基金会的OSS两个大会合并而成的，因此规模空前甚大，估计有超过40多个国家，3000多名开发者参与会议。 由于最近两年在从事Service Mesh方面的一些工作，而本次大会中有多个关于Service M

编者按 Prow 是 Google 发起的适应云原生开源项目的 ChatOps 系统。Kubernetes、Istio 等项目都使用 Prow 实现开源协同。 K8s 的 Prow 系统：https://prow.k8s.io/ Prow 开源仓库：https://github.com/kubernetes/test-infra/ Prow 官方文档：https://github.com/kube

本文是对ClusterMesh（Cilium的多集群实现）的深入研究。简而言之，ClusterMesh 提供： 通过隧道或直接路由，以本地性能对多个Kubernetes集群进行Pod IP路由，而无需任何网关或代理。 使用标准Kubernetes服务和coredns/kube-dns的透明服务发现。 跨多个集群的网络策略实施。 策略可以指定为Kubernetes NetworkPolicy资源或扩

什么是分布式调用跟踪？ 相比传统的“巨石”应用，微服务的一个主要变化是将应用中的不同模块拆分为了独立的进程。在微服务架构下，原来进程内的方法调用成为了跨进程的RPC调用。相对于单一进程的方法调用，跨进程调用的调试和故障分析是非常困难的，很难用传统的调试器或者日志打印来对分布式调用进行查看和分析。 如上图所示，一个来自客户端的请求经过了多个微服务进程。如果要对该请求进行分析，则必须将该请求经过的所有

说到 GitOps 和 ChatOps ，那就不得不谈到 DevOps 。 DevOps 作为一种文化，旨在促进开发、测试和运维人员之间的沟通与协作。而促进合作的方式，往往是使用一系列工具，完成这三个角色的相互协作。这带来的好处也是显而易见的：更快的交付速度和更低的人力成本。获益于 DevOps 和公有云，一个近百人的研发团队，可以只配备一到两个专职运维人员，降低的成本不言而喻。既然 DevOps