说说咱们为何须要lstio

本文来自lstio的中文社区：
https://istio.cn/t/topic/18

我最近没有多少时间去玩k8s，并认可Istio到底给k8s带来了什么方面有点迷失了。这是否会增长更多的运营开销？它是否简化了咱们一般须要作的事情？这些问题都浮如今个人脑海里。

（我怀疑在发布了这些内容以后，个人团队中比我更懂k8s的人可能会想找我谈谈……虽然我讲会跟团队中的成员辩论，但那将是我最喜欢的对话）

那么Istio到底是什么？

Istio网站 4上说：

Istio带给你：

HTTP、gRPC、WebSocket和TCP流量的自动负载均衡。
经过丰富的路由规则、重试、故障转移和故障注入对流量行为进行细粒度控制。
支持访问控制、速率限制和配额的可拔插策略层和配置API。
自动指标、日志和集群内全部流量的跟踪，包括集群入口和出口。
经过集群中的服务之间的强身份断言来实现服务间的身份验证。
经过在整个环境中部署一个特殊的sidecar代理（辅助容器），您能够将Istio支持添加到服务中（这给我留下了深入的印象，若是您想作到这一点，请参阅后面的内容）。安装了sidecar代理以后，（微）服务之间的全部网络通讯都经过这个代理。此外，全部的网络通讯都是使用Istio的控制平面功能进行配置和管理的。

Istio是 Service Mesh（服务网格） 。我认为的service mesh定义就是“它是一个专用的基础设施层，使得服务间的通讯安全、高效和可靠”

然而，若是像我同样，你从概念文档 11开始看的话，上面有这样的内容：“术语 service mesh 一般用于描述组成这些应用程序的微服务网络以及它们之间的交互。随着服务网格的大小和复杂程度不断增长，可能会变得难以理解和管理。可能出现包括服务发现、负载平衡、故障恢复、度量和监控，以及更复杂的需求，如A/B测试、金丝雀发布、速率限制、访问控制和端到端身份验证。Istio提供了一个完整的解决方案，经过对整个服务网格提供行为分析和操做控制来知足微服务应用程序的各类需求。“

读完以后你可能会像我同样困惑！最后在网上查了一圈关于什么是服务网格以后，我终于搞明白了。我最后使用的多是一个在全部搜索到的样本里一个非表明性的共识，但这是一个合理的选择。不过有个细节确实了，就是如何将它与k8s等编排工具分开。Istio须要跟k8s一块儿使用，没有k8s或其余容器编排工具的它就不存在了吗？它没有作编排，实际上它的是为解决管理基于微服务的解决方案中网络和操做复杂性而设计的。它涵盖的范围就像k8s同样！如今我真的须要继续这个帖子了。。。

因此我知道Istio是什么，给咱们带来了什么，但它实际上解决了什么挑战呢？

从为何使用Istio页面 11中能够看出，它在服务网络中统一提供了许多关键功能：

流量管理
可观察性
强制策略
服务身份标识和安全
对于我来讲，要真正理解Istio的价值，因此我使用了codelab 43。编写code lab的人真是太棒了！

Code lab向我介绍了Istio控制平面的四个主要组件：

Pilot ：处理代理sidecar的配置和编程。
Mixer ：为您的流量处理决策并收集遥测数据。
Ingress ：处理来自群集外部的传入请求。
CA ：证书颁发机构。
查看Istio架构概念 11页面了解这些组件如何协同工做的。

Code lab提供了路由规则 4——流量管理部分

我还尝试了Istio.io中的一些task，由于我须要了解它如何处理那些领域的工做。

提示：若是您在完成codelab时也决定在四处看看，那么请将您的群集与应用程序一块儿启动并运行。不管如何，你会再次使用它。

因此我对它如何解决这些问题有了一个基本的了解，可是若是我使用像GKE这样的托管K8s（好吧，你知道我会选那个不是吗？）使用Istio是否合适？

注意 ：是的，这里有更多的细节，但我主要想弄明白为何须要使用Istio。

集群最终用户/开发人员访问

GKE结合使用IAM和RBAC 1，是的，这里面有不少东西须要你了解。

要为您的集群用户授予比Cloud IAM更细粒度的权限，您可使用namespace和RBAC来限制对特定pod的访问或排除对secret的访问。

Istio RBAC介绍了两个侧重于服务的角色

ServiceRole 定义用于访问网格中的服务的角色。
ServiceRoleBinding 将角色授予主题（例如用户、组、服务）。
它们是k8s中的CustomResourceDefinition（CRD）对象。但您仍然须要了解IAM。

服务身份标识

GKE可使用service account来管理GKE上运行的应用程序可使用哪些GCP服务。这些service accout的密钥使用secret存储。Pod中运行的进程的身份标识是由k8s service account 2与RBAC一块儿决定的。Istio使用istio-auth，它使用双向TLS提供强大的服务间和最终用户身份验证，内置身份和凭证管理。Istio-auth使用Kubernetes service account。

Itsio不提供任何使用GCP service account帮助。这还很早，可是它正在制定将来发展计划的路线图。

Istio-auth很好，计划中的加强功能将值得等待。我对安全的复杂性感到厌烦，由于这不可避免地致使配置错误，因此我但愿它与service account类型之间进行更加无缝的对齐！

网络控制

GKE（用于k8s版本1.7.6 +）使用k8s网络策略 1来管理哪些Pod能够和服务通讯。这是相对简单的配置。 Istio也有网络策略，但他们不是你知道和喜欢的K8s策略，为何会有这样的区别呢？ 这篇文章 1很好地解释了这一点，因此我不会在这里重述，可是这个表格总结了不一样之处以及为何会有这样的不一样。

项目 Istio策略 网络策略
层 Service（7层） Network（三、4层）
实现 Userspace Kernel
控制点 Pod Node
Istio使用envoy做为sidecar代理。Envoy在OSI模型的应用层运行，因此在第7层。个人这篇博客将为你详细解释。

您须要两种策略类型，这是纵深防护的方法。

多个集群

Istio有个很是酷的功能是mixer适配器。简而言之，它能够从底层后端进行抽象以提供核心功能，例如日志记录、监控、配额、ACL检查等。它公开了一个一致的API，与使用的后端无关。就像GCS公开了一个API，不管您使用什么存储类别！

我认为mixer适配器模型 1博客文章中的这张图片解释了mixer适配器中的所有要点。
mixer适配器模型

有一个早期demo 4，我认为它是istio最有用的特性之一，它实际上使用虚拟机来承载codelab中使用的评分dbase MySQL数据库，并将其做为GKE集群所属网格的一部分。使用一个网格来管理它们！

流量管理

若是你使用了codelab，你会看到使用istio来引导使用路由规则的流量是多么容易。使用K8s，您还可使用金丝雀部署进行流量管理，并以相似于istio的方式将必定比例的流量引导至您的应用的一个版本，但Istio在这种状况下更灵活，方法是容许您设置细粒度流量百分比并控制流量使用code lab中的其余标准。

服务发现

服务注册在k8s中完成。Istio抽象出底层的服务发现机制，并将其转换为envoy sidecar可消费的标准格式。

审计记录和监控

若是是超出GKE提供的标准日志记录的话，能够将GKE与StackDriver日志记录集成来收集，在持久化存储中存储 容器日志 、 系统日志 和关于群集中的活动的 事件 ，例如Pod的调度。还能够与StackDriver Monitoring集成以收集系统度量指标（度量群集的基础设施，例如CPU或内存使用状况）和自定义指标（特定于应用程序的指标）。

Istio利用prometheus与grafana一块儿做为仪表板进行记录和监控。我喜欢service graph配置 1，它能够为您提供service mesh的图形表示。你也能够用kibana和fluentd来配合Elasticsearch使用。

那么我须要Istio吗？

Istio的流量管理很是棒，mixer适配器模型能够轻松管理覆盖多个群集和虚拟机的网格。我喜欢Istio是由于它可让你进中精力思考服务，而不是那么多的pod和节点，并非说你没必要担忧这些，而是只关注服务就行了！

若是你须要管理一个分布式集群，那么Istio应该在你的选择列表里。若是您须要在流量管理方面有比k8s提供的更多的灵活性的化那么Istio也很值得关注。

若是你有足够的资源来处理处于发展早期的事物，那么尽早理解Istio是值得的。若是你已经在使用k8s的话那么istio的学习曲线将很低。

记住它是一个创建在上层的东西，因此你仍然须要在k8s层作些事情，好比配置k8s网络策略来补充istio网络策略。

Istio还处于发展的早期阶段，因此它不会作你指望的全部事情，但咱们但愿它会。你将没法避免的在提供商API和Istio之间来回调用才能完成一个完整的工做，因此它不是你但愿的那种一站式解决方案。

Dashboard是可视化网格配置的一种很好的方式，由于编写YAML会让人很快疲惫！是的，您能够设置仪表板上的控制面板来可视化度量指标，但我但愿看到它与StackDriver集成。

所以，在整体了解Istio以后，我实际上很喜欢它所承诺的内容。