首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

为什么GKE上的Istio不创建网关?

GKE上的Istio不创建网关的原因是因为GKE集群已经集成了Google Cloud Load Balancer(GCLB),它可以作为Istio的入口流量管理器和负载均衡器。GCLB提供了高可用性、自动扩展和全球负载均衡等功能,因此不需要额外创建Istio网关。

Istio是一个开源的服务网格解决方案,用于管理和连接微服务架构中的服务。它提供了流量管理、安全性、可观察性和策略执行等功能。在GKE上使用Istio,可以通过Istio控制平面来管理和配置服务之间的通信。

在GKE上使用Istio时,可以通过以下步骤配置和部署:

  1. 创建GKE集群:使用GKE创建一个Kubernetes集群,并确保启用Istio功能。
  2. 安装Istio:使用Istio的安装文件或Helm Chart在GKE集群上安装Istio。安装过程中会自动部署Istio的控制平面组件。
  3. 配置Istio:通过定义Istio的配置文件,可以配置流量管理、安全策略、故障注入等功能。可以使用Istio的VirtualService、DestinationRule和Gateway等资源对象来定义路由规则和流量控制策略。
  4. 部署应用:将应用程序部署到GKE集群中,并将其配置为使用Istio的代理进行通信。可以通过Istio的Sidecar注入功能自动将代理注入到应用容器中,或者手动配置代理。
  5. 监控和故障排除:使用Istio的可观察性功能,如Prometheus和Grafana,来监控和分析服务的性能和健康状况。可以使用Istio的故障注入功能模拟故障,并使用Jaeger等工具进行故障排除。

推荐的腾讯云相关产品是腾讯云容器服务(TKE),它是腾讯云提供的托管Kubernetes集群的解决方案。TKE提供了与GKE类似的功能,包括自动扩展、负载均衡和容器编排等。您可以通过腾讯云容器服务快速搭建和管理Kubernetes集群,并使用Istio进行流量管理和安全控制。

更多关于腾讯云容器服务的信息,请访问:腾讯云容器服务

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

Ingress 的继任者 —— Gateway API?

在 Kubernetes 集群边缘对外提供网络服务的时候,通常需要借助 Ingress 对象,这个对象提供了暴露 Service 所必须的核心要素,例如基于主机名的路由、对 URL 路径的适配以及 TLS 配置等。但是在实际开放服务的时候,往往会有更多的具体需求,这时 Ingress 对象所提供的核心功能就有些力不从心了,各种 Ingress 控制器往往会使用 metadata.annotations 中的特定注解,来完成对 Ingress 特定行为的控制,完成各自的个性化功能,例如认证、路径变更、黑白名单等,这就让 Ingress 对象变成了一个奇怪的东西:结构化的核心结构,和非结构化的标注结合起来形成各种 Ingress 方言,并且后期还出现了 Traefik Middleware 这样的 CRD 配置,这给 Ingress 功能的集中管理造成了一个较大的困扰;另外 Ingress 中可以随意定制主机名、路径以及后端服务,也给共享集群的用户造成了一定的安全隐患。包括 Cotour、Traefik 在内的 Ingress 控制器后期都提供了各自的基于 CRD 的功能表达,客观上也让 Ingress 世界更为分裂。 例如要移除路径前缀,Nginx Ingress 控制器需要使用 nginx.ingress.kubernetes.io/rewrite-target 注解,而 Traefik 1.7 中则需要使用 traefik.ingress.kubernetes.io/rule-type: PathPrefixStrip 注解。

06

JFrog助力Google Anthos混合云Devops实践,实现安全高质量的容器镜像管理

自Google Anthos推出以来在混合云领域受到极大关注,作为Google进入ToB混合云市场的战略级产品,Anthos集成了如GKE (Google Kubernetes Engine)、GKE On-Prem、Istio on GKE等……引起业界的关注。可以说这又是Google又一大利器。那么混合云作为企业数字化转型的重要基础设施建设,既留了核心数据,降低了迁移风险,又能在原来资源的基础上增加公共云的弹性,一举多得,成为当前云计算发展的热门话题。而作为数字化转型的另外一个风向标DevOps如何与当前的混合云发展进行协作,带向企业进入云原生时代,将会成日今后数字化建设的一个重要主题。

04

Kubernetes Gateway API

初始的 Kubernetes 内部服务向外暴露,使用的是自身的 LoadBlancer 和 NodePort 类型的Service,在集群规模逐渐扩大的时候,这种 Service 管理的方式满足不了我们的需求,比如 NodePort 需要大量的端口难以维护,多了一层NAT,请求量大会对性能有影响;LoadBlancer 需要每个 Service 都有一个外部负载均衡器。接着 Kubernetes 提供了一个内置的资源对象 Ingress API 来暴露 HTTP 服务给外部用户,它的创建是为了标准化的将 Kubernetes 中的服务流量暴露给外部,Ingress API 通过引入路由功能,克服了默认服务类型 NodePort 和 LoadBalancer 的限制。在创建 Ingress 资源的时候通过 IngressClass 指定该网关使用的控制器,主要是靠 Ingress 控制器不断监听 Kubernetes API Server 中 IngressClass 以及 Ingress 资源的的变动,配置或更新入口网关和路由规则。IngressClass实现了网关与后台的解耦,但也有着很多的局限性。Ingress 配置过于简单,只支持 http 和 https 协议的服务路由和负载均衡,缺乏对其他协议和定制化需求的支持,而且 http 路由只支持 host 和 path 的匹配,对于高级路由只能通过注解来实现,当然这取决于 Ingress 控制器的实现方式,不同的 Ingress 控制器使用不同的注解,来扩展功能,使用注解对于 Ingress 的可用性大打折扣;路由无法共享一个命名空间的网关,不够灵活;网关的创建和管理的权限没有划分界限,开发需要配置路由以及网关。当然也有很多第三方的网关组件,例如 istio 和 apisix 等,提供了丰富的流量管理功能,如负载均衡、动态路由、动态 upstream、A/B测试、金丝雀发布、限速、熔断、防御恶意攻击、认证、监控指标、服务可观测性、服务治理等,还可以处理南北流量以及服务之间的东西向流量。对外提供路由功能,对内提供流量筛选,已经很好的满足了当下网络环境的所有需求。但对于小集群来说,这两个网关的部署成本有点高;而且太多类型的网关,不同的配置项、独立的开发接口、接口的兼容性、学习成本、使用成本、维护成本以及迁移成本都很高。急需一种兼容所有厂商 API 的接口网关。所以应运而生,Kubernetes 推出了 Gateway API。Gateway API 是 Kubernetes 1.19 版本引入的一种新的 API 规范,会成为 Ingress 的下一代替代方案。它有着 Ingress 的所有功能,且提供更丰富的功能,它支持更多的路由类型选择,除了 http路由外,还支持 tcp 以及 grpc 路由类型;它通过角色划分将各层规则配置关注点分离,实现规则配置上的解耦;并提供跨 namespace 的路由与网关支持使其更适应多云环境等。与 Ingress Api 工作类似的,Gateway Controller 会持续监视 Kubernetes API Server 中的 GatewayClass 和 Gateway 对象的变动,根据集群运维的配置来创建或更新其对应的网关和路由。API 网关、入口控制器和服务网格的核心都是一种代理,目的在于内外部服务通信。更多的功能并不等于更好的工具,尤其是在 Kubernetes 中,工具的复杂性可能是一个杀手。

03

Knative 全链路流量机制探索与揭秘

服务接收到流量请求后,从0自动扩容为N,以及没有流量时自动缩容为0,是一个Serverless平台最本的特征。 可以说,自动扩缩容机制是那颗皇冠,戴上之后你才能被称之为Serverless。 当然了解Kubernetes的人会有疑问,HPA不就是用来干自动扩缩容的事儿的吗?难道我用了HPA就可以摇身一变成为Serverless了。 这里最关键的区别在于,Serverless语义下的自动扩缩容是可以让服务从0到N的,但是HPA不能。HPA的机制是检测服务Pod的metrics数据(例如CPU等)然后把Deployment扩容,但当你把Deployment副本数置为0时,流量进不来,metrics数据永远为0,此时HPA也无能为力。 所以HPA只能让服务从1到N,而从0到1的这个过程,需要额外的机制帮助hold住请求流量,扩容服务,再转发流量到服务,这就是我们常说的冷启动。 可以说,冷启动是Serverless皇冠中的那颗明珠,如何实现更好、更快的冷启动,是所有Serverless平台极致追求的目标。 Knative作为目前被社区和各大厂商如此重视和受关注的Serverless平台,当然也在不遗余力的优化自动扩缩容和冷启动功能。 不过,本文并不打算直接介绍Knative自动扩缩容机制,而是先探究一下Knative中的流量实现机制,流量机制和自动扩容密切相关,只有了解其中的奥秘,才能更好的理解Knative autoscale功能。 由于Knative其实包括Building(Tekton)、Serving和Eventing,这里只专注于Serving部分。另外需要提前说明的是,Knative并不强依赖Istio,Serverless网关的实际选择除了集成Istio,还支持Gloo、Ambassador。同时,即使使用了Istio,也可以选择是否使用envoy sidecar注入。本文介绍的时候,我们默认使用的是Istio和注入sidecar的部署方式。

01

为什么 Envoy Gateway 是云原生时代的七层网关?

大家好,我叫赵化冰,是 CNCF 云原生基金会大使,也是一个软件行业老兵和云原生从业者。我还记得,当我 2017 年在 Linux 基金会下的一个开源项目中从事微服务相关工作时,第一次从该项目的一个朋友那里了解到了 Istio/Envoy。从此以后,我就被 Istio/Envoy 的先进设计理念所吸引。我是国内最早一批从事 Istio/Enovy 产品研发的技术人员之一,在 2018 年就主导了 Istio/Envoy 的第一个产品化项目。在后续的工作中,我还研发了大规模 Kubernetes 集群上基于 Envoy 的多租户七层云原生网关,创建了基于 Envoy 的多协议七层网关开源项目 MetaProtocolProxy,以及基于 Envoy/Istio 的多协议服务网格开源项目 Aeraki Mesh(CNCF Sandbox 项目),该项目被腾讯、百度、华为等多个公司采用,在基于 Envoy 的网关和服务网格上支持了超过数十种应用协议。今天,我想和大家聊一聊 Envoy 生态中的新成员 Envoy Gateway,以及为什么我认为 Envoy Gateway 是云原生时代的七层网关。

02

istio多集群链路追踪,附实操视频

这里的可观察性主要指服务网格的可观察性,也就是需要观测服务网格中运行的微服务。为什么可观察性很重要,因为随着微服务架构的流行,一个系统可能运行成百上千微服务,如果系统出现故障,定位问题带来很大的问题。有了观测系统,就能更好的分析问题发生的原因,已经更好的监控告警。服务网格可观察性主要分为三个大类,分别是log,metrics,tracing。log是指将分布式系统的日志收集起来集中存储,用于日志分析,常用的工具如efk。metrics是指收集服务网格的监控指标,进行监控告警,常用工具比如prometheus。tracing是指分布式链路追踪,用于可视化显示服务调用的依赖关系,及获取延迟数据,常用工具如zipkin,jaeger等。本文关注的是tracing,这里我们用到了zipkin作为tracing工具。

01
领券