Istio 是一项开放技术,为开发人员提供一种无缝连接、管理和保护不同微服务网络的方法,且无需考虑平台、来源或供应商。Istio 是目前基于 Github 贡献者增长最快的开源项目之一,优势在于它的社区。IBM 很荣幸成为 Istio 项目的创始人和贡献者以及 Istio 工作组的领导者。
要了解有关服务网格世界的更多信息,请阅读由 Istio 控制委员会成员、IBM 发明大师 Lin Sun 以及 IBM 杰出工程师 Dan Berg 撰写的 O'Reilly 电子书 Istio Explained。
Istio 与 IBM Cloud Log Analysis 和 IBM Cloud Monitoring 完美搭配运行。
设置和部署应用程序;使用 IBM Watson® 服务扩展和更新应用程序。
了解 12 因素方法、微服务和 Istio 如何在 IBM Cloud Kubernetes Service 中工作。
在微服务旁边安装 Istio 作为 Guestbook 模拟应用程序;将其部署到集群。
解放 Kubernetes 开发人员
参见文档。如需其他内容,只需加入 Slack 频道提问即可。
Istio 作为一种可配置的开源服务网格层,能连接、监视和保护 Kubernetes 集群中的容器。Istio 最初仅搭配 Kubernetes,但其开源特性使任何人都可以编写扩展程序,因此能在任何集群软件上运行。
Kubernetes 是一种容器编排工具,Kubernetes 的一个核心单元是节点。节点由一个或多个容器以及其他组件组成。Kubernetes 管理节点的可用性和资源消耗,并根据需求增加使用 pod 自动扩缩控制器添加 pod。Istio 将其他容器注入 pod 中以增加安全性、管理和监控。
由于这种开源性,Istio 可以在支持它的公共云以及经管理员同意的私有云上运行。
组织转向微服务时,需要支持数十或数百个具体应用程序。单独管理这些端点需要支持大量虚拟机,包括需求。Kubernetes 这样的集群软件可以创建并扩展 Pod,但 Kubernetes 不提供路由表、流量规则、强大的监视或调试工具。
输入服务网格。
随着服务数量的增加,潜在的通信方式数量呈指数级增长。2 个服务只有 2 条通信路径。3 个服务有 6 条,10 个服务有 90 条。服务网格通过创建通信策略提供一种配置这些通信路径的单一方法。
服务网格检测服务并根据预定义配置定向通信流量。管理员无需配置正在运行的容器或编写代码来执行此操作,而是可以向服务网格提供配置并让它完成该工作。以前,此操作必须在 Web 服务器和服务到服务通信中进行。
在集群中执行此操作的最常见方法是使用 sidecar 模式。sidecar 是 pod 内部的一个新容器,用于路由和观察服务和容器之间的通信流量。
Istio 层位于 Kubernetes 之上,添加了程序员和管理员基本不可见的“侧柜容器”,这些容器充当“中间人”,引导流量并监视组件之间的交互。两者通过如下三种方式协同运行。
配置:使用 Kubernetes 设置配置的主要方法是 kubectl 命令,通常为 kubectl -f <filename>,其中文件是 YAML 文件。Istio 用户可以使用 kubectl 运行新的不同类型的 YAML 文件,也可以使用新的可选 ioctl 命令。
监控:借助 Istio,您可以监控使用 Kubernetes 运行的应用程序的运行状况。Istio 检测可以管理和可视化应用程序的运行状况,与 Kubernetes 对集群和节点进行一般监控提供的洞察力相比,Istio 检测提供的洞察力更多。
管理:由于 Istio 的界面本质上与 Kubernetes 相同,因此管理它几乎不需要额外工作。Istio 允许用户创建影响和管理整个 Kubernetes 集群的策略,从而减少管理每个集群的时间,同时消除对自定义管理代码的需求。
Istio 使用 Envoy 的深度扩展版本来执行监控、管理和日志记录。每个 pod 都需要跟踪,Istio 需要汇集并提供所有 pod 相关信息。使用 Istio 的一种可能替代方案是将 Envoy 直接部署到 Kubernetes 集群中并编写管理代码。这本质上是重新创建 Istio,包含自定义开发项目的相关成本和错误。