拥有大型单体应用程序的公司越来越多地开始将这些笨拙的应用分解为更小的容器化微服务。微服务之所以受欢迎是因为它们提供敏捷性、高速度和灵活性,但是它们可能很复杂,这成为了其采用之路上的一大障碍。此外,拥有多个微服务而不是单个单体,也会增大应用的攻击面。

Istio 将控制权交还给应用开发者和网格运营人员。具体来说,Istio 是一个开源服务网格(service mesh)平台,可确保微服务在处理故障时以规定的方式相互连接。借助 Istio,可以更轻松地观察整个微服务网络中正在发生的状况,保护服务之间的通信,并确保策略得以执行。

Istio 的新版本 1.3 可以让用户更轻松地使用服务网格平台。

Istio 1.3 提高了易用性

Istio 拥有众多功能,因此它比我尝试过的其他开源服务网格项目更为复杂。如果要实现让 Istio 成为首选服务网格实现的目标,就必须让其他开发者更轻松地使用 Istio。

具体来说,我们必须简化开发者将微服务移至 Istio 服务网格的过程,无论开发者是想先利用安全性、流量管理还是遥测技术。我们创建了一个用户体验工作组,这个工作组与社区互动,着力改善 Istio 的用户体验。通过众多工作组Envoy 社区之间的密切协作,我很高兴地看到 Istio 1.3 中发生了以下变化:

  • 默认情况下将捕获所有入站流量。无需在 Kubernetes deployment YAML 中为 Istio 声明 containerPort 来指出您希望 Envoy sidecar 捕获的入站端口。
  • CLI 中的单个 add-to-mesh 命令会将现有服务添加到 Istio 网格,无论该服务是在 Kubernetes 还是虚拟机中运行。
  • describe 命令允许开发者描述满足 Istio 要求和任何 Istio 相关配置所需的 Pod 和服务。
  • 实现了自动协议检测,并且默认情况下会为出站流量启用,但对于入站流量则会禁用此功能,这样便实现了这一功能的稳定性。您仍然需要修改 Kubernetes service YAML,使用 v1.3 的协议来命名服务端口或作为名称的前缀,我希望在将来的版本中可以取消此要求。

参阅 Istio 1.3 发布博客发布说明,了解更多发行相关详细信息。

Istio 1.3 实战

一年多以前,我试图将流行的 Kubernetes guestbook 示例迁移到 Istio 网格中运行。由于没有密切关注文档,并且直到完成后方才发现正确的文档,我为此花费了好几天的时间。注入 sidecar 时并没有遇到任何问题;但 Pod 和服务的需求列表却难倒了我。

让我们以此为例,看看使用 Istio 1.3 时如何简化此过程。

通过使用 guestbook-all-in-one.yaml 文件,我已经在 IBM Cloud(1.14.6) 上的 Kubernetes 集群中部署了上游 guestbook 样本。我取消注释了第 108 行,以对前端服务使用 type: LoadBalancer

$ kubectl get pods
NAME                           READY   STATUS    RESTARTS   AGE
frontend-69859f6796-4nj7p      1/1     Running   0          49s
frontend-69859f6796-772sw      1/1     Running   0          49s
frontend-69859f6796-n67w7      1/1     Running   0          49s
redis-master-596696dd4-ckcj4   1/1     Running   0          49s
redis-slave-96685cfdb-8cfm2    1/1     Running   0          49s
redis-slave-96685cfdb-hwpxq    1/1     Running   0          49s

我使用了快速入门指南来安装 Istio 1.3。社区在减少自定义资源定义(CRD)的数量方面取得了进展,现已降至 23 个。我们将根据用户安装的 Istio 功能,继续减少 CRD 的数量。

安装完成后,我使用了 add-to-mesh 命令将前端服务添加到 Istio 网格中:

$ istioctl x add-to-mesh service frontend
deployment frontend.default updated successfully with Istio sidecar injected.
Next Step: Add related labels to the deployment to align with Istio's requirement: https://istio.io/docs/setup/kubernetes/additional-setup/requirements/

结果,我的前端 Pod 注入并运行了 sidecar。

$ kubectl get pods
NAME                           READY   STATUS    RESTARTS   AGE
frontend-69577cb555-9th62      2/2     Running   0          25m
frontend-69577cb555-pctrg      2/2     Running   0          25m
frontend-69577cb555-rvjk4      2/2     Running   0          25m
redis-master-596696dd4-dzf29   1/1     Running   0          26m
redis-slave-96685cfdb-2h789    1/1     Running   0          26m
redis-slave-96685cfdb-7sp6p    1/1     Running   0          26m

我描述了一个前端 Pod,看看 Pod 和关联的前端服务是否满足 Istio 的要求。

$ istioctl x describe pod frontend-69577cb555-9th62
Pod: frontend-69577cb555-9th62
   Pod Ports: 80 (php-redis), 15090 (istio-proxy)
Suggestion: add 'version' label to pod for Istio telemetry.
--------------------
Service: frontend
   Port:  80/UnsupportedProtocol
   80 is named "" which does not follow Istio conventions
Pilot reports that pod is PERMISSIVE (enforces HTTP/mTLS) and clients speak HTTP

代码清楚地告诉了我缺少哪些内容!我需要为协议命名端口,在本例中为 HTTP。对我来说,遥测的版本标签是可选的,因为前端服务只有一个版本。

我使用 kubectl 编辑了前端服务。

$ kubectl edit service frontend

我使用 name: http 添加了命名服务的代码行,并保存了更改。

…
  ports:
  - nodePort: 30167
    port: 80
    protocol: TCP
    targetPort: 80
    name: http
…
service/frontend edited

我重复了相同的 istioctl x add-to-mesh service redis-masteristioctl x add-to-mesh redis-slave 命令,以将 redis-master 和 redis-slave 添加到网格中。对于 redis,我只使用了默认的 tcp 协议,因此无需命名端口。

$ kubectl get pods
NAME                           READY   STATUS    RESTARTS   AGE
frontend-b8595c9f-gp7vx        2/2     Running   0          51m
frontend-b8595c9f-pr5nb        2/2     Running   0          51m
frontend-b8595c9f-q7fx9        2/2     Running   0          50m
redis-master-5589dc575-bqmtb   2/2     Running   0          51m
redis-slave-546f8d974c-gq4sn   2/2     Running   0          50m
redis-slave-546f8d974c-qjjwl   2/2     Running   0          50m

我在网格中添加了 frontendredis-masterredis-slave 服务!我使用负载均衡器 IP 访问了 guestbook 应用:

$ export GUESTBOOK_IP=$(kubectl get service frontend -o jsonpath='{.status.loadBalancer.ingress[0].ip}')
$ curl $GUESTBOOK_IP

我使用 istioctl dashboard grafana 命令启动了 Grafana,用于提供 guestbook 服务指标。

Grafana 指标

在这里,我使用了 istioctl dashboard jaeger 启动 Jaeger,为我提供每个 guestbook 请求的 guestbook 跟踪。须注意,它们是单独的跟踪范围,并不相关。我期望使用单独的跟踪范围,是因为我需要传播跟踪头(trace header),以便可以将多个跟踪范围绑定到每个单独的请求。

Grafana 指标

之后,我使用了 istioctl dashboard kiali 启动 Kiali,用于直观呈现 guestbook 应用。

Grafana 指标

我能够通过 Grafana、Jaeger 或 Kiali 在应用层观察微服务,而无需修改服务代码或重建 guestbook 容器镜像!根据业务需求,您可以在开发更高版本微服务的过程中,通过转变来保护微服务或在微服务中建立弹性,或者控制流量

我相信,随着开发者将其微服务移入网格或移出服务,社区正在致力于提高 Istio 的易用性。默认情况下为入站流量启用了智能协议检测功能后,就无需实时编辑服务。应该很快就会添加此功能。

Istio 的开源优势

Istio 的开源架构及其生态系统使这项技术更有效。没有供应商锁定,也不会限制您可以使用的服务类型。另外,Istio 可以在任何云模型中运行:公共、私有、本地或混合云模型。

Istio 由 IBM、Google 和 Lyft 于 2017 年携手打造,与之相关的社区蓬勃发展,现已包含 Cisco、Red Hat、Pivotal、Tigera、Tetrate 等其他合作伙伴。在本文撰写之时,Istio 项目拥有来自 300 多家公司的 400 多个贡献者,活跃的多元化社区和技能使之受益无穷。

Istio 和 IBM

在 Istio 公开发布之前,IBM 就一直参与 Istio 的活动,IBM 为 Istio 捐赠了我们的 Amalgam8 项目。作为这一开源项目的第二大贡献者,IBM 员工现在就职于 Istio 指导委员会技术监督委员会,共同领导环境工作组、构建/测试发布工作组、性能和可伸缩性工作组、用户体验工作组以及文档工作组。

为什么大家都对 Istio 感兴趣?随着开发团队不断寻求快速扩展,他们需要一些工具来摆脱束缚,从而革新和简化跨环境的应用构建和部署 – 这就是 IBM 继续投资 Istio 的原因所在。

多家云提供商提供了托管 Istio 体验,简化了 Istio 控制平面的安装和维护过程。例如,IBM Cloud 提供了 Istio 托管产服务,让您可以一步安装 Istio。

我们都知道,客户需要对其应用和应用基础架构进行现代化改造,我们深信,Istio 是一项关键技术,借助 1.3 版本中的这些新变化,客户便可以安全可靠地轻松完成这项任务。

参与 Istio 项目

因为 Istio 是开源的,所以我们依靠活跃的开发者社区来帮助改进、保护和扩展这一技术。您可以通过以下几种方式来参与:

Sun Lin 是 IBM 的高级技术研究员兼发明大师 (Master Inventor)。她是 Istio 项目的维护者,也是 Istio 指导委员会和技术监督委员会的成员。

参考资源

本文翻译自:Istio 1.3 is out: Here’s what it means for you(2019-09-12)

加入讨论