Kubernetes上基于Istio体验云原生应用实践

主播:osswangxining 视频数:1
2375
直播介绍 相关视频
#kubernetes# #Istio#

Service Mesh被认为是继Kubernetes之后当前最为热门技术方向,在过去一年中已成为容器行业的排名第一的流行词。Service Mesh可以极大地简化用户体验,并将大中型企业的Kubernetes落地引领进下一个全新阶段,被业界普遍认为是新一代的微服务架构的最佳技术设计。

从容器技术发展来看,Istio与K8S是一种互补的关系,弥补了K8S在微服务的连接、管理和监控方面的短板,它与K8S的结合最终帮助企业用户在容器和微服务领域达到双剑合璧的效果。

本次Topic中将分享在阿里云容器服务Kubernetes上如何使用Istio进行云原生应用的实践。

该直播其他视频
您可能感兴趣
  • Kubernetes全方位日志采集与管理的最佳实践
    Kubernetes全方位日志采集与管理的最佳实践
    来源:元乙 3260
  • Kubernetes and Cloud Native Meetup 广州场来啦!
    Kubernetes and Cloud Native Meetup 广州场来啦!
    来源:amber涂南 3060
  • Kubernetes and Cloud Native Meetup 【北京场】直播报名中
    Kubernetes and Cloud Native Meetup 【北京场】直播报名中
    来源:amber涂南 4960
  • 基于Kubernetes的持续交付实践 | 阿里巴巴研发效能实践日
    基于Kubernetes的持续交付实践 | 阿里巴巴研发效能实践日
    来源:云效鼓励师 5210
问答
ae86 | 8月前 istio的内部应用调用还是走service么?
回答
  • - 在启用了Istio之后,服务网格中应用实例之间的通信是由Istio来负责负载均衡的。Istio中的Pilot模块负责与服务注册交互,使用来自服务注册的信息,并提供与平台无关的服务发现接口。服务网格中的 Envoy 实例执行服务发现,并相应地动态更新其负载均衡池。 ![_](https://yqfile.alicdn.com/cffb3fdd80dfa6142726f935a77440ef727ddc41.png) - 如上图所示,服务网格中的服务使用其 DNS 名称访问彼此,这个DNS解析仍然是借用Kubernetes中提供的DNS解析能力。服务的所有请求流量都会通过 Envoy 自动重新路由。Envoy 在负载均衡池中的实例之间分发流量。
阳洋love1 | 8月前 你刚能有刚演示的Istio流量切换的具体实践如何做的,能有一个具体的开发文档么?
回答
navy_jia | 8月前 目前阿里云hadoop、spark在向kubernetes迁移吗?
回答
  • 随着云原生技术的不断发展,传统应用逐渐向Kubernetes迁移将成为一种趋势。作为大数据平台的Hadoop和Spark,社区也都提供了相应的解决方案。阿里云也正在相关层面开展了相应的工作。如果您有相关业务需要,请提交工单支持。
troytroy | 8月前 问题:QPS应该还与具体选择的通信协议有关吧,比如grpc>>》http2>http1
回答
  • 是的,当前对Istio的性能评估,主要是基于Istio官方社区的端到端综合基准测试,具体可以参见: https://istio.io/docs/concepts/performance-and-scalability/
pu2chyh | 8月前 能讲讲destinationrule和virtualservice的关系吗?流量控制是靠谁实现的
回答
  • - DestinationRule 用于配置将流量转发到实际工作负载时应用的策略集。 这些策略集由服务提供者来提供编写,用于描述熔断器、负载均衡设置以及TLS 设置等。 - VirtualService 描述了一个或多个用户可寻址目标到网格内实际工作负载之间的映射关系。其中,用户可寻址目标可以是任何用于定位服务的,具有可选通配符前缀或 CIDR 前缀的 DNS 名称。这对于应用从单体架构到微服务架构的迁移过程特别有用,单体应用被拆分为多个独立的微服务后,采用 VirtualService 可以继续把多个微服务对外暴露为同一个目标地址,而不需要服务消费者进行修改以适应该变化。 - DestinationRule 定义了目标 host 的子集 subsets (或者称之为命名版本)。 这些 subset 用于 VirtualService 的路由规则设置中,可以将流量导向服务的某些特定版本。 通过这种方式为版本命名后,可以在不同的 virtual service 中明确地引用这些命名版本的 subset,简化 Istio 代理发出的统计数据。 - 服务的所有请求流量都会通过 Envoy 自动重新路由。Envoy 在负载均衡池中的实例之间分发流量。
  • 问题7
展开全部答案
ae86 | 8月前 istio的性能怎么样,有没有高并发大数据量的实践
回答
  • 当前对Istio的性能评估,主要是基于Istio官方社区的端到端综合基准测试,具体可以参见: https://istio.io/docs/concepts/performance-and-scalability/ 在基于Istio1.0.4版本的测试中,在不启用Mixer的情况下,集群内的服务之间的调用QPS可达~8500,贴近Envoy的性能测试指标。基本满足大部分的生产用QPS要求。 启用Mixer之后,集群内的服务之间的调用QPS在3500左右。因为Mixer启用之后,可以提供对服务之间调用的监控、built-in Grafana Dashboard等,在传统的分布式系统的运维中,这些功能也往往是需要自行创建维护的,也会有一定的性能损耗。
  • 问题6
展开全部答案
204232336046181891 | 8月前 服务发现不是用k8s的吗
回答
  • - 在启用了Istio之后,服务网格中应用实例之间的通信是由Istio来负责负载均衡的。Istio中的Pilot模块负责与服务注册交互,使用来自服务注册的信息,并提供与平台无关的服务发现接口。服务网格中的 Envoy 实例执行服务发现,并相应地动态更新其负载均衡池。 ![_](https://yqfile.alicdn.com/c4e1f132a92edfc9c181edbfcc157640264d2e0d.png) - 如上图所示,服务网格中的服务使用其 DNS 名称访问彼此,这个DNS解析仍然是借用Kubernetes中提供的DNS解析能力。服务的所有请求流量都会通过 Envoy 自动重新路由。Envoy 在负载均衡池中的实例之间分发流量。
  • 补充问题 +4
展开全部答案
navy_jia | 8月前 可以讲一下istio集成阿里云的云监控的adapter的实现细节吗?
回答
  • mark
  • - 要实现一个新的 Mixer 适配器,请参考适配器开发者指南: https://github.com/istio/istio/wiki/Mixer-Out-Of-Process-Adapter-Dev-Guide
  • 问题5
展开全部答案
pu2chyh | 8月前 istio怎么做服务发现?
回答
  • - 在启用了Istio之后,服务网格中应用实例之间的通信是由Istio来负责负载均衡的。Istio中的Pilot模块负责与服务注册交互,使用来自服务注册的信息,并提供与平台无关的服务发现接口。服务网格中的 Envoy 实例执行服务发现,并相应地动态更新其负载均衡池。 ![_](https://yqfile.alicdn.com/c4e1f132a92edfc9c181edbfcc157640264d2e0d.png) - 如上图所示,服务网格中的服务使用其 DNS 名称访问彼此,这个DNS解析仍然是借用Kubernetes中提供的DNS解析能力。服务的所有请求流量都会通过 Envoy 自动重新路由。Envoy 在负载均衡池中的实例之间分发流量。
  • 问题4
展开全部答案
troytroy | 8月前 问题:对于传统模式的或者使用类dubbo的微服务框架,如何一步一步地过渡到istio上呢
回答
  • - 一般来说,如果之前的应用是一个单体应用,自然首先要做的就是微服务化改造。这里面涉及到的不仅仅是技术问题,更多的是对业务进行梳理,探究如何把一个业务进行微服务分解。 过去的几年里,业界一直在不断地讨论如何从单体应用程序向分布式的微服务架构进行转型。 - 当然,如果应用已经使用Spring Cloud或者Dubbo完成了微服务化的改造,回答要不要迁移到Kubernetes和Istio上来这个问题,首先需要梳理清以下几个问题: - 当前的微服务架构的实现往往是以代码库的方式构建在应用程序本身中,这些代码库中包括了服务发现、熔断、限流等这样的一些功能,版本不同往往会带来冲突问题,而且版本一旦变更,整个应用也要随之全部变更,即使你的应用逻辑并没有任何变化。这是否也是你面临的问题? - 此外,复杂系统中的微服务实现往往会使用到不同的编程语言、不同的框架,这些实现方案往往存在差异大、缺少共性的问题。这是否同样是你面临的问题? - 如果这些问题和挑战你同样需要去解决,那么毫无疑问解决这些问题的一个方法就是Service Mesh服务网格技术。Istio作为服务网格技术的代表作, 提供了一个完整的解决方案,可以解决这些问题。 - 首先,需要将你的应用逐渐迁移到Kubernetes上。这是因为Istio是基于Kubernetes基础之上的,尽管它也可以支持Consul等非Kubernetes平台,但目前Kubernetes才是最佳且稳定的平台唯一选择。 - 其次,需要根据应用的代码逻辑,逐渐把非业务功能模块进行解耦,交由Istio的智能代理Envoy来负责完成诸如服务发现、负载均衡、故障容忍、端到端监测、动态路由等功能。这个过程可以是渐进式的,先从流量管理出发,把服务发现、动态路由、负载均衡交由Istio来实现;然后再逐渐过渡到故障容忍、端到端监测等。
  • 问题3
展开全部答案
troytroy | 8月前 南北向和东西向怎么定义的呢?
回答
  • - Ingress 将Kubernetes中的应用暴露成对外提供的服务,以及如何针对这个对外暴露的服务实现灰度发布、流量管理等。通常,我们把这种从入口请求到集群服务的流量管理称之为北向流量管理。与之相对应的,从集群内访问外部服务的出口的流量管理通常称之为南向流量管理。 - 而东西向流量则是指集群内服务之间的流量管理、或者称之为服务网格之间的流量管理;
  • 东西向是系统内部,服务之间互相调用的请求
  • 南北向是进入系统或者系统发出的请求。
  • 问题1
展开全部答案
发送
提问 0/100