Google Kubernetes引擎上使用Istio简化微服务 — 第I部分(译)

本文涉及的产品
注册配置 MSE Nacos/ZooKeeper,118元/月
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
云原生网关 MSE Higress,422元/月
简介: Google Kubernetes引擎上使用Istio简化微服务 — 第I部分(译)

使用Istio简化微服务系列一:如何用Isito解决Spring Cloud Netflix部署微服务的挑战?


Original 2018-03-12 姚炳雄 译 ServiceMesh中文网

作者:Nithin Mallya

翻译:姚炳雄

原文:Simplifying Microservices with Istio in Google Kubernetes Engine — Part I

原文链接:https://medium.com/google-cloud/simplifying-microservices-with-istio-in-google-kubernetes-engine-part-i-849555f922b8


本系列翻译链接:


我所写的关于 Istio 的文章是 Istio 非常棒的官方文档 中的一部分。如果想了解更多,请阅读官方文档。


概述


Istio 简化了服务间的通信,流量涨落,容错,性能监控,跟踪等太多太多。如何利用它来帮我们从各微服务中抽象萃取出基础架构和功能切面?


我写的这些关于 Istio 的文章是 Istio官网文档的子集。读官网文档可了解更多。

注意::如果你很熟悉微服务,请跳过背景介绍这段。


在本系列的第一部分,将涵盖如下内容:


  • 背景: 单体应用及微服务介绍
  • Spring Cloud Netflix Stack及其优势
  • Istio 介绍
  • Istio的服务-服务通信举例


背景


过去,我们运维着“能做一切”的大型单体应用程序。 这是一种将产品推向市场的很好的方式,因为刚开始我们也只需要让我们的第一个应用上线。而且我们总是可以回头再来改进它的。部署一个大应用总是比构建和部署多个小块要容易。

然而,这样的应用开发将导致“爆炸式的”工作量(我们经过数月的工作后将再次部署整个应用),并且增量变更将因为构建/测试/部署/发布周期等的复杂特性而来来回回折腾很长时间。但是,如果你是产品负责人,尤其是在部署一个新版本后发现一个严重的 Bug,那么这就不仅仅是多少钱的问题。 这甚至可能导致整个应用回滚。相对于比较小的组件来说,将这样的一个大型应用部署到云上并弹性扩展它们也并不容易。

进入微服务

微服务是运行在自己的进程中的可独立部署的服务套件。 他们通常使用 HTTP 资源进行通信,每个服务通常负责整个应用中的某一个单一的领域。 在流行的电子商务目录例子中,你可以有一个商品条目服务,一个审核服务和一个评价服务,每个都只专注一个领域。

用这种方法来帮助分布式团队各自贡献各种服务,而不需要在每个服务变更时去构建/测试/部署整个应用,而且调试也无需进入彼此的代码。 将服务部署到云上也更容易,因为独立的服务就能按需进行自动弹性扩展。

用这种方法让多语言服务(使用不同语言编写的服务)也成为可能,这样我们就可以让 Java/C++ 服务执行更多的计算密集型工作,让 Rails / Node.js 服务更多来支持前端应用等等。


Spring Cloud Netflix:


随着微服务的流行,简化服务的创建和管理的框架如雨后春笋。 我个人在2015年最喜欢的是 Netflix OSS 栈(Spring Cloud Netflix),它让我用一个非常简单的方式,通过 Spring Tool Suite IDE 来创建 Java 微服务。

我可以通过 Netflix 套件获得以下功能(图1):


  • 通过 Eureka 进行服务注册- 用于注册和发现服务
  • Ribbon 做客户端的负载均衡- 客户端可以选择将其请求发送到哪个服务器。
  • 声明 REST 客户端 Feign 与其他服务交谈。在内部,使用 Ribbon。
  • API 网关用 Zuul —单一入口点来管理所有 API 调用,并按路由规则路由到微服务。
  • Hystrix 做熔断器 — 处理容错能力以及在短时间内关闭通信信道(断开回路)并在目标服务宕机时返回用户友好的响应。
  • 用 Hystrix 和 Turbine 做仪表板 —— 可视化流量和熔断


图1: Spring Cloud Netflix 实现微服务


当然,这种构建和部署应用的方法也带来了它的挑战。


挑战


部署:怎样才能通过一种统一一致的方式将我们的服务部署到云中,并确保它们始终可用,并让它们按需进行自动弹性扩展?

横切关注点:如何对每个微服务代码改动很少甚至不改代码的情况下能获得更多我们所看到的 Spring Cloud Netflix 中所实现的功能? 另外,如何处理用不同语言编写的服务


解决方案


部署:Kubernetes 已经为在 Google Kubernetes Engine(GKE)中高效部署和编排 Docker 容器铺平了道路。 Kubernetes 抽象出基础架构,并让我们通过 API 与之进行交互。 请参阅本文末尾的链接以获取更多详细信息。

横切关注点:我们可以用 Istio。 Istio 官网上的解释称:“ Istio 提供了一种简单的方法,来创建一个提供负载均衡、服务间认证、监控等的服务网络,且不需要对服务代码进行任何更改。 通过在整个环境中部署专门的 sidecar 代理服务,来拦截微服务间的所有网络通信,整个配置和管理通过 Istio的控制面板来做。”


Istio介绍:


换句话说,通过Istio,我们可以创建我们的微服务,并将它们与“轻量级 Sidecar 代理”一起部署(下图2),以处理我们的许多横切需求,例如:


  • 服务到服务的通信
  • 追踪
  • 熔断(类 Hystrix 功能)和重试
  • 性能监控和仪表板(类似于 Hystrix 和 Turbine 仪表板)
  • 流量路由(例如:发送 x% 流量到 V2 版本的应用实例),金丝雀部署
  • 一个额外的红利(特别是如果您正在处理医疗保健中的 PHI 等*敏感数据时)出站(Istio 服务网格之外的外部可调用服务)需要明确配置,并且可以阻止在服务网格之外的做特殊调用的服务。


image.gif图2: 用 Envoy 代理来做多语言服务间的通信


在上图2中,我们已经去掉了图1中的许多组件,并添加了一个新组件(Envoy Proxy)。 任何服务(A)如需与另一个服务(B)交谈,则提前对它的代理做路由规则预配置,以路由到对方的代理进行通信。 代理与代理交谈。 由于所有通信都是通过代理进行的,所以很容易监控流量,收集指标,根据需要使用熔断规则等。


对横切面的声明式的配置规则和策略,无需更改任何服务代码,让我们可以更专注于最重要的事情:构建高业务价值的高质量的服务。


从高的层面看,Istio 有如下组件:


  • Envoy:一个高性能,低空间占用的代理,支持服务之间的通信,并有助于负载平衡,服务发现等;
  • Mixer:负责整个生态(服务网格)中所有服务的访问控制策略,并收集通过 Envoy 或其他服务发送的遥测信息;
  • Pilot:帮助发现服务,流量缓慢调整和容错(熔断,重试等);
  • Istio-Auth用于服务间认证以及都使用 TLS 的终端用户认证。本文中的示例不使用 Istio-Auth。

用Istio进行服务—服务通信


让我们在练习中了解它!


我们将举一个简单的例子,展示3个通过 Envoy 代理进行通信的微服务。它们已经用 Node.js 写好,但如前所述,你可以用任何语言。


图3: 用于提取宠物细节的3个微服务的逻辑视图


  1. 宠物服务:通过调用 PetDetailsService 和 PetMedicalHistoryService 来返回宠物的信息和病史。 它将在9080端口上运行。
  2. 宠物详细信息服务:返回宠物信息,如姓名,年龄,品种,拥有者等,它将在端口9081上运行。
  3. 宠物医疗历史信息服务:返回宠物的病史(疫苗接种)。 它将在9082端口运行。


步骤:


在 GKE中创建一个 Kubernetes 集群(我叫 nithinistiocluster)。 确保缺省服务帐户具有以下权限:roles / container.admin(Kubernetes Engine Admin)。

按照 https://istio.io/docs/setup/kubernetes/quick-start.html 中的说明安装 istio。


1. 现在,我们准备将我们的应用程序(上述3个服务)部署到 GKE,并将边车代理注入到部署中。

2. 在 github 仓库中,您将看到4个目录(安装各种组件时创建的istio目录和我的微服务的3个目录)。

3. 对于每个微服务,我在 petinfo.yaml 文件的 kube 目录中创建了相应的 Kubernete s部署和服务。 服务名为宠物服务宠物详细信息服务宠物医疗历史信息服务。 由于PetServic e可以公开访问,因此它有一个指向 petservice 的 Kubernetes Ingress。

4. 你可以转到每个服务目录,在 deploy.sh 文件中更新项目和群集名称并运行它。 它构建服务,创建 Docker 镜像,将其上传到Google Container Registry,然后运行 istioct l 以注入 Envoy 代理。 例如,对于 PetService,它看起来像:

#!/usr/bin/env bash
export PROJECT=nithinistioproject 
export CONTAINER_VERSION=feb4v2
export IMAGE=gcr.io/$PROJECT/petservice:$CONTAINER_VERSION
export BUILD_HOME=.
gcloud config set project $PROJECT
gcloud container clusters get-credentials nithinistiocluster --zone us-central1-a --project $PROJECT
echo $IMAGE
docker build -t petservice -f "${PWD}/Dockerfile" $BUILD_HOME
echo 'Successfully built ' $IMAGE
docker tag petservice $IMAGE
echo 'Successfully tagged ' $IMAGE
#push to google container registry
gcloud docker -- push $IMAGE
echo 'Successfully pushed to Google Container Registry ' $IMAGE
# inject envoy proxy
kubectl apply -f <(istioctl kube-inject -f "${PWD}/kube/petinfo.yaml")

在上面的代码中,高亮显示的行显示了我们如何使用 Istio 命令行工具(istioctl)来将代理注入到我们的各种 Kubernetes 部署中。

Petservice 目录下的 petinfo.yaml 文件包含服务、部署和 Ingress的配置。 看起来像:

apiVersion: v1
kind: Service
metadata:
  name: petservice
  labels:
    app: petservice
spec:
  ports:
  - port: 9080
    name: http
  selector:
    app: petservice
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: petservice-v1
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: petservice
        version: v1
    spec:
      containers:
      - name: petservice
        image: gcr.io/nithinistioproject/petservice:feb4v2
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 9080
---
###########################################################################
# Ingress resource (gateway)
##########################################################################
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: gateway
  annotations:
    kubernetes.io/ingress.class: "istio"
spec:
  rules:
  - http:
      paths:
      - path: /pet/.*
        backend:
          serviceName: petservice
          servicePort: 9080
---


一旦运行了 deploy.sh,就可以通过执行以下命令来检查确认部署、服务和 Ingress 是否已经创建:

mallyn01$ kubectl get deployment
NAME                          DESIRED   CURRENT   UP-TO-DATE   AVAILABLE   AGE
petdetailsservice-v1          1         1         1            1           1h
petmedicalhistoryservice-v1   1         1         1            1           58m
petservice-v1                 1         1         1            1           54m


mallyn01$ kubectl get service
NAME                       TYPE        CLUSTER-IP     EXTERNAL-IP   PORT(S)    AGE
kubernetes                 ClusterIP   10.51.240.1    <none>        443/TCP    2d
petdetailsservice          ClusterIP   10.51.255.10   <none>        9081/TCP   1h
petmedicalhistoryservice   ClusterIP   10.51.244.19   <none>        9082/TCP   59m
petservice                 ClusterIP   10.51.242.18   <none>        9080/TCP   1h


petservice mallyn01$ kubectl get ing
NAME      HOSTS     ADDRESS        PORTS     AGE
gateway   *         108.59.82.93   80        1h
mallyn01$ kubectl get pods
NAME                                           READY     STATUS    RESTARTS   AGE
petdetailsservice-v1-5bb8c65577-jmn6r          2/2       Running   0          12h
petmedicalhistoryservice-v1-5757f98898-tq5j8   2/2       Running   0          12h
petservice-v1-587696b469-qttqk                 2/2       Running   0          12h


当查看控制台中 pod 的信息,即使你只为每个容器部署了一项服务,但仍会注意到有2/2个容器正在运行。 另一个容器是 istioctl 命令注入的边车代理。


5. 一旦上述所有内容都运行完毕,您可以使用 Ingress 的 IP 地址去调用示例端点来获取 Pet 的详细信息。

mallyn01$ curl http://108.59.82.93/pet/123
{
  "petDetails": {
    "petName": "Maximus",
    "petAge": 5,
    "petOwner": "Nithin Mallya",
    "petBreed": "Dog"
  },
  "petMedicalHistory": {
    "vaccinationList": [
      "Bordetella, Leptospirosis, Rabies, Lyme Disease"
    ]
  }
}

注意: 由于 PetService 调用 PetDetailsService 和 PetMedicalHistoryService,实际的调用将如下所示:

fetch('http://petdetailsservice:9081/pet/123/details')
          .then(res => res.text())
          .then(body => console.log(body));
        ;
fetch('http://petmedicalhistoryservice:9082/pet/123/medicalhistory')
          .then(res => res.text())
          .then(body => console.log(body));
        ;

结论: 我们覆盖了大量内容 (但这只是第一部分!!)


在随后的部分中,将详细介绍如何使用其他 Istio 特性,例如将流量逐步迁移到一个新升级的版本上,使用性能监控仪表板等等。

特别感谢 Ray Tsang 的关于 Istio 的 演讲材料


资源


  1. The Istio home page https://istio.io/
  2. DevOxx 的Ray Tsang的 Istio 演讲材料: https://www.youtube.com/watch?v=AGztKw580yQ&t=231s
  3. 案例的Github link: https://github.com/nmallya/istiodemo
  4. Kubernetes: https://kubernetes.io/
  5. 微服务: https://martinfowler.com/articles/microservices.html
  6. Spring Cloud Netflix: https://github.com/spring-cloud/spring-cloud-netflix
相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
2月前
|
SQL Kubernetes 监控
微服务从代码到k8s部署应有尽有系列(九、事务精讲)
微服务从代码到k8s部署应有尽有系列(九、事务精讲)
微服务从代码到k8s部署应有尽有系列(九、事务精讲)
|
2月前
|
Kubernetes 负载均衡 微服务
Kubernetes 生态系统中的微服务治理
【8月更文第29天】随着微服务架构的普及,管理分布式系统的复杂性也随之增加。Kubernetes 作为容器编排的事实标准,为微服务架构提供了强大的支持。结合像 Istio 这样的服务网格工具,Kubernetes 能够有效地解决微服务治理中的诸多挑战,如服务发现、负载均衡、流量管理和安全策略等。
33 1
|
2月前
|
Kubernetes jenkins 持续交付
微服务从代码到k8s部署应有尽有系列(十四、部署环境搭建)
微服务从代码到k8s部署应有尽有系列(十四、部署环境搭建)
|
2月前
|
Kubernetes 监控 中间件
微服务从代码到k8s部署应有尽有系列全集
微服务从代码到k8s部署应有尽有系列全集
|
2月前
|
消息中间件 Kubernetes Kafka
微服务从代码到k8s部署应有尽有系列(八、各种队列)
微服务从代码到k8s部署应有尽有系列(八、各种队列)
|
2月前
|
Kubernetes NoSQL API
微服务从代码到k8s部署应有尽有系列(五、民宿服务)
微服务从代码到k8s部署应有尽有系列(五、民宿服务)
|
1天前
|
Kubernetes Docker 微服务
微服务实践k8s&dapr开发部署实验(1)服务调用(一)
微服务实践k8s&dapr开发部署实验(1)服务调用(一)
18 2
|
1天前
|
Kubernetes Cloud Native 微服务
微服务实践之使用 kube-vip 搭建高可用 Kubernetes 集群
微服务实践之使用 kube-vip 搭建高可用 Kubernetes 集群
13 1
|
2天前
|
Kubernetes Cloud Native 云计算
云原生时代的技术演进:Kubernetes与微服务架构的完美融合
随着云计算技术的飞速发展,云原生概念逐渐深入人心。本文将深入探讨云原生技术的核心——Kubernetes,以及它如何与微服务架构相结合,共同推动现代软件架构的创新与发展。文章不仅剖析了Kubernetes的基本工作原理,还通过实际案例展示了其在微服务部署和管理中的应用,为读者提供了一条清晰的云原生技术应用路径。
10 2
|
1天前
|
Kubernetes Docker 微服务
微服务实践k8s&dapr开发部署实验(1)服务调用(二)
微服务实践k8s&dapr开发部署实验(1)服务调用(二)
18 0