istio
文章平均质量分 85
深山猿
不断进化的深山猿
展开
-
预发布相关技术方案与梳理
后端:前端根据用户访问的域名知道当前的环境,预发布环境中添加header后访问后端接口,后端通过header将对应环境的请求路由到对应的环境。需要梳理预发布和线上哪些资源是需要隔离的,确认mysql、nas、oss等存储不隔离,但分支、redis(可以通过)、mq、naocs需要隔离。2)面对线上环境的问题,研发有更多的时间进行解决,相关方案也会更加完备,避免解决一个问题同时带来另一个问题。1)让测试老师有更多时间在线上环境验证问题,能提前暴露部分线上问题,进而提升用户的体验,原创 2023-03-27 17:38:42 · 532 阅读 · 0 评论 -
ingress与gateway https秘钥配置
该类型的Service被提交后,Kubernetes 就会调用 CloudProvider 在公有云上为你创建一个负载均衡服务,并且把被代理的 Pod 的 IP 地址配置给负载均衡服务做后端。所以:isito的ingress和gateway对应的pod是一样的,所以ingress对应的pod的功能主要就是从公网接收请求转到isito内部的gateway。然后vs再引用gateway,gateway将请求分发到不同的vs,vs层再将请求分发到k8s的service,最后到具体的pod。原创 2022-10-26 09:03:28 · 1556 阅读 · 0 评论 -
sentinel、isitio、hystrix 限流熔断降级
限流:统计和限制访问次数熔断:服务出错或响应过慢时,直接返回错误信息,或者返回历史数据、默认数据等。降级:干掉次要功能,保留主要功能sentinel详细文档https://sentinelguard.io/zh-cn/docs/circuit-breaking.htmlistio文档https://istio.io/latest/docs/tasks/traffic-management/circuit-breaking/sentinel vs hystrix发展前景Netflix已原创 2021-11-17 14:56:16 · 4548 阅读 · 0 评论 -
容器化问题:优雅停机、spring探针配置、websocket关闭变慢
问题1: 服务发版等导致的服务间接性不可用问题原因1:请求需要10s完成,但是服务所在pod在第8秒被干掉解决:设置preStop和延迟销毁pod, sleep时间要小于terminationGracePeriodSeconds.且sleep之后不会再有请求进入该pod imagePullPolicy: Always lifecycle: preStop: exec: comm...原创 2021-09-16 16:38:44 · 564 阅读 · 0 评论 -
服务容器化踩坑
upstream connect error or disconnect/reset before headers. reset reason: connection failure通过istio访问容器内服务:https://test-practice.xiaohoucode.com/api/practice/platform/project/X1503upstream connect error or disconnect/reset before headers. reset reason:原创 2021-07-15 19:47:16 · 5022 阅读 · 0 评论 -
Sidecar机制和istio多集群服务治理
第6章 透明的Sidecar机制Sidecar Injector只在创建Pod时进行Sidecar容器注入,在Pod的创建请求到达Kube-apiserver 后,首先进行认证鉴权,然后在准入控制阶段,Kube-apiserver以REST的方式同步调用Sidecar Injector Webhook服务进行init与istio-proxy容器的注入,最后将Pod对象持久化存储到etcd中。如图:第7章 多集群服务治理云原生应用会越来越多地面向跨云、跨区域、跨集群的部署场景,因此支持多集群是I原创 2021-05-01 14:14:00 · 741 阅读 · 0 评论 -
第5章 istio可插拔的服务安全
第5章 可插拔的服务安全istio提供的安全功能可以解决类似如下的问题:◎ 项目要发布了,做安全稽查时却发现不满足某项安全标准, 导致项目延期、苦不堪言;◎ 因为要处理某项安全要求,所以不得不在干干净净的业务代码里引入各种安全库,并添加各种安全处理,导致部分代码面目全非;◎ 好不容易给服务提供了双向TLS认证,在运行一段时间后服务访问却出问题了,调查很久后才发现原来是证书过期了。5.1 Istio服务安全的原理Istio的安全功能以一种安全基础设施方式提供的,不用修改业务代码就能提供服务访问安原创 2021-04-30 15:41:55 · 488 阅读 · 3 评论 -
4 istio的策略和遥测 与适配器
Istio中策略和遥测要解决的问题、实现原理和使用方式;并讲解Istio基于Adapter机制提供的Prometheus、Fluentd、Quota 等策略和遥测功能,包括这些Adapter的工作机制和使用方法等;并基于这种扩展机制在不修改代码的情况下收集服务的运行数据和 执行策略。4.1 istio策略和遥测的原理4.1.1 应用场景除了需要具备服务治理功能,还需要知道服务运行的怎么样、有没有问题、以及哪里有问题等。这一班是APM的职能,设计数据采集、存储、检索。1、传统的遥测数据收集方式原创 2021-04-29 17:50:54 · 505 阅读 · 2 评论 -
destinationRule\Gateway\ServiceEntry\SideCar配置详解
3.3 destinationRuledestinationRule 和 VirtualService的联系和区别1)两者之间的关系在讲解virtualService中,路由目标对象destination中会包含Service子集的subset字段,这个服务子集就是通过DestinationRule定义的。2) 两者都是用于流量治理,那应用场景有什么区别?virtualService是一个虚拟的service,描述的是满足什么条件的流量被那个后端处理。类似于根据路径去匹配方法,是更开放的martc原创 2021-04-28 16:30:44 · 1851 阅读 · 0 评论 -
istio的流量治理(负载均衡 熔断 故障注入 灰度)与各种配置实例 与VIrtualService(路由规则配置)
服务治理要解决的问题:1) 服务的负载均衡2)同一个服务有两个版本在线,将一部分流量切到某个版本上3)服务保护,如限制并发连接数、请求数、隔离有故障的服务实例等4)动态修改服务中的内容istio流量治理目标:提供非侵入的流量治理,用户仅仅关注自己的业务逻辑,无须关注服务访问管理。流量治理的流程:控制面:1)管理面创建流量规则2)pilot将流量规则转换为envoy的标准格式3)pilot将规则下发给envoy数据面:1)envoy拦截Pod上本地容器的Inbound和outbo原创 2021-04-22 16:27:47 · 2621 阅读 · 0 评论 -
isito的相关组件和工作机制概述
2.1 istio的工作机制istio架构分为控制面和数据面两部分。控制面:包括pilot、mixer、citadel等组件数据面:由伴随每个应用程序部署的代理程序envoy组成,执行针对应用程序的治理逻辑从fronted服务访问forecast服务来看istio内部的组件都做了什么如图:1)sidecar自动创建与注入:创建应用程序时自动注入sidecar代理。在k8s场景下创建Pod时,在创建业务容器的同时会创建sideCar容器,然后kube-apiserver调用管理面组件的sid原创 2021-04-21 20:52:11 · 1260 阅读 · 0 评论 -
istio概述,与微服务、云原生、k8s的关系
1.1简单介绍istio与k8s紧密结合,适用于云原生场景,service mesh形态,服务治理的开放平台服务治理,包括:连接、安全、策略执行和可观察性。连接:通过配置的流量规则控制服务间的流量和调用,实现负载均衡,熔断,故障注入,重试,重定向等服务治理安全:提供认证机制、通道加密、服务访问授权等,增强服务访问的安全性策略执行:通过可动态插拔,可扩展的策略,实现访问控制,速率限制,配额管理,服务计费等能力可观察性:动态获取服务运行数据和输出,提供强大的调用链,监控,和调用日志收集与输出的能力。原创 2021-04-19 17:29:40 · 12845 阅读 · 3 评论