crossoverJie

在上一期 k8s-服务网格实战-配置 Mesh 中讲解了如何配置集群内的 Mesh 请求，Istio 同样也可以处理集群外部流量，也就是我们常见的网关。 其实和之前讲到的k8s入门到实战-使用Ingr

在上一篇 k8s-服务网格实战-入门Istio中分享了如何安装部署 Istio，同时可以利用 Istio 实现 gRPC 的负载均衡。 今天我们更进一步，深入了解使用 Istio 的功能。

终于进入大家都比较感兴趣的服务网格系列了，在前面已经讲解了： 如何部署应用到 kubernetes 服务之间如何调用 如何通过域名访问我们的服务 如何使用 kubernetes

最近在升级服务网格 Istio，升级后有个必要的流程就是需要重启数据面的所有的 Pod，也就是业务的 Pod，这样才能将这些 Pod 的 sidecar 更新为新版本。 方案 1 因为我们不同环境的

前段时间写过一篇 gRPC 的入门文章，在最后还留了一个坑没有填： 也就是 gRPC 的负载均衡问题，因为当时的业务请求量不算大，再加上公司没有对 Istio 这类服务网格比较熟悉的大牛，所以我

Helm 是一个 Kubernetes 的包管理工具，有点类似于 Mac 上的 brew，Python 中的 PIP；可以很方便的帮我们直接在 kubernetes 中安装某个应用。 比如我们可

在前面三节中已经讲到如何将我们的应用部署到 k8s 集群并提供对外访问的能力，x现在可以满足基本的应用开发需求了。 现在我们需要更进一步，使用 k8s 提供的一些其他对象来标准化我的应用开发。

前段时间给 VictoriaLogs 提交了一个 PR： https://github.com/VictoriaMetrics/VictoriaMetrics/pull/4934 本来一切都很顺

前两章中我们将应用部署到了 k8s 中，同时不同的服务之间也可以通过 service 进行调用，现在还有一个步骤就是将我们的应用暴露到公网，并提供域名的访问。 这一步类似于我们以前配置 Ngin