大纲介绍
**istio是一种服务网格的实现,大概从12个方面
0 istio的简单介绍
1 istio的架构和核心
2 **
1 istio的架构和核心,有两个平面,数据平面envoy(负责服务间通讯)和控制平面(mixer策略的制订,pilot观察者,服务发现用的galtey配置中心,citadel服务之间调用证书)
流量管理,路由
security其实是google的alts,有范围,只针对点对点,服务对服务,pod对pod
策略和调测
可观察性,针对所有网络里的流量都要进行跟踪
上面就是4个future,下面就是安装升级,操作
9诊断工具,10分析配置
istio的一些命令
安装和卸载
istio的安装包
可以跟kubectl放在一起
放到环境变量里
第一步添加环境变量完成
但是istioctl的自动补全功能 没有,还需要安装
现在已经完成好自动补全了
istioctl这个工具其实式和K8S里 跑的istio通信的一个客户端工具
报错,现在其实并没有安装完成,istioctl其实会和iK8S里的stio进行通信,集群里的还没装好,就只能看到 对当前客户端的版本
可以先把istio链接远程的关闭
安装方式可分位istioctl和helm
这里其实就是apply manifest清单里的,istio里有多种,比如demo,
打个比方,奔驰G系可以有多个车型,从商家角度就是可以做 差别化管理,profile可以作为同一款车型的不同的车类别
可以看一下profile的类别,当前1.4.5有这么多的 profile
安装说白了,就是apply到K8S集群里,tracing就是一个链路追踪的,pilot服务发现,服务配置,kiali就是一个istio的dashboard,prometheus监控,telemetry是一个遥测(一个请求可以report资源情况给telemetry),galley整个istio的配置中心,ingressgateway入口网关,egressgateway出口网关,cidadel流量加密身份认值,policy定义黑白名单。
![](https://img-blog.csdnimg.cn/20210621173134699.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyMjI3ODE4,size_16,color_FFFFFF,t_70)
做一下检查,默认会有这么多服务,自动创建一个istio-system
istio部署的service,K8S的svc类别有loadbalance(用到了外部的负载均衡),clusterip,nodeport,ExternalName。
这个loadbalance的外部ip永远不会给,所以我们等待需要修改
deployment也有3个有问题
HPA,苗测
查看是不是镜像拉取 不到
正在拉镜像
现在 架构是3台master,10台worker
有几台是已经安装过有镜像的,可以直接喊出pod,让它调度到有镜像的地方去
现在要把这个svc改成node port
现在已经改为nodeport了
卸载掉istio,通过istioctl manifest 这个资源清单的子命令,先把profile=demo的配置信息产生,再用kubectl 删除
命名空间已经删除了
我们没有lb类型的是,所以安装的时候需要把istio的ingressgateway类型改成nodeport
istioctl profile
前面大概说明了istioctl的安装
配置istioctl
利用istioctl在k8s里安装istio
利用istioctl在k8s里卸载istio
本章目标是
介绍istioctl version子命令,analyze子命令
kiali组件,介绍profile。
单纯安装istioctl,没有安装istio在k8s里这个工具后会报错,所以只打印了istictl的版本号,没有输出istio的版本号
安装好再去指向,除了打印istioctl的版本号,还会打印istio 数据面和控制面的版本号
analyze实际上是分析配置信息,并将配置信息配置分析的经结果打印到控制台。
会分析默认的命名空间下有关istio的注入的信息,现在还没有对istio的命名空间做任何的配置和注入,管理,所以会报错。
另外一个名称空间做了一个注入,会去分析在jiuxi这个名称空间下被istio注入的配置检查工作。检查的结果就是,没有任何的校验问题。
kiali是一个服务网格的可视化工具
以demo的profile安装。默认就会安装kiali
jiuxi的名称空间下安装了4个istio官方的微服务
一定要加上traffic animation
现在 尝试打入一点流量
注入一些流量进去
已经看到效果了
三角形是K8S的service
圆形代表pod
百分百的流量会进入productpage
进入productpage之后会分50%到reviews,49.7%到details
reviews有三个版本,基本上是round Robin
重点说明istio的profile
生面的车系对比不是特别贴切,下面的每个手机套餐可以算作不同的profile,定了某个profile,就会有不同的升值服务。安装不同的profile,就等于不同的istio的控制行为
首先看demo的profile
其实每个profile都是不同的,配置值不一样,demoprofile主要定义了两大部分。core components 和addons。
addons可以理解未插件,component可以理解为组件。
组件会通过出口网关,入口网关,pilot,,跟官网提供的说明一样。
之前安装都是demo.yaml,没有修改,组件一个都不少。
另外一个profile是minimal,只是开启了非常 少的功能,istio-pilot
可以看到组件都是 关闭的
default profile其实是官方推荐的,主要开启了 prometheus,入口网关,pilot,istio官方推荐在生产和环境安装的profile
空模板,其实是就是根据自己爱好添加
官方作废了,不推荐使用
最难的profile
官方说是只开启了一个prometheus插件,但是实际上入口网关和pilot也是开启的
inject 注入
**上一章主要将,istioctl的version和analyze的子命令。
kiali组件可视化网格。
istioctl的6个profile
**
1.注入的本质和后果。
2.哪些资源可以被注入
3.手动注入
4.从进程角度分析一下注入之后。
5.自动化注入
注入在以后pod内会生成两个兄弟,,mr.net负责网络初始化,mr.window就是当前资源跟K8S其他资源交互的一个窗口
查看哪些资源可以被istio注入。
黑体字部分,被istio注入就是有了孩子了,会有孪生兄弟。红色的资源被istio注入后,实际上是不会产生什么结果的。
实际的例子,istio手工 注入。
第4条开始才是注入,把注入的 效果展示出来,但是实际上并没有注入,下面一条才是执行istio的真实注入
创建命名空间
当前pod后缀是lc打头,其实注入会把原来的pod杀掉,pod相当于重启了。
管道前面只是用了istioctl工具,对原有的deployment资源注入,并将注入的结果,用kubectl发布出去
现在pod里有两个容器,生成一个新的pod,把原来的pod杀死掉
把注入后有哪些资源都dump出来
注入的资源比原来丰富了不少。现在是2个容器
其实容器有两种,一种是containers,一种是initcontiners
第二个容器叫istio-proxy
还有一种让其是iinitcontainer
初始化的容器里有istio-init
注入前和注入后
rancher的可视化界面其实就看到了,三个容器,初始化容器其实就terminate了
istio-init这个让其是做什么,其实就是mr.net(初始化网络名称空间用的),istio-proxy其实就是mr.window
所有的容器都处在一个网络名称空间里
-it以交互的方式,在当前pod里的nginx容器,–只是kubectll要命令pod里的容器进行操作的一个必要语法执行ifconfig命令
查看 isitio-proxy的
它们的网络名称空间都是一样的
经过istio注入,网络名称空间究竟发生了什么
网络端口发生了变化
重新发布一个资源 ,把原来的deployeent资源发布到另外一个命名空间里去,形成一个没有注入的效果。
在default命名空间下发布一个deployment
查看当前的端口号,这是没有被istio注入前的
那么之前在jiuxi命名空间下进行了一个istio的注入,网络端口号多了5个,实际上这5个进程是envoy
多开的这几个端口号,背后的进程是envoy进程,还会有个pilot-agent进程。
注入后会多5个端口
不仅端口发生改变,网络的协议栈也会发生改变,tcp/ip协议之一般是操作系统内核来实现的,因为写代码的时候并不会去关心tcp/ip如何去实现的。
什么是网络协议策略,可以去做一些限制某一个ip来访问主机,具体实现是在内核里。比如iptables工具是从内核里的net和filter进行交互去调整。
是istio-init这个容器做了网络名称空间打通的事情
从init这个容器的命令里,在启动的时候会调用istio-iptables,可以去猜一下istio-iptables这个脚步做了什么
也可以通过这个命令直接看到
可以看到istio-init这个容器消耗的时候的日志,做了哪些操作
下面修改了iptables,修改nat表
在nat表里加了4条链,ISTIO_REDIREC,ISTIO_IN_REDIRECT,ISTIO_INBOUND,ISTIO_OUTPUT
针对每一条链添加了相应的规则
无论是从哪里来的流量,如果这个流量是tcp协议的会转到15001的端口上,这就是istio_redirect这样一个链
可以进入到pod里的容器里看看iptables
进入到容器里查看iptables网络情况,可以去看看nat表
istio_redirect
可以用rancher这个web页面来可视化查看,当前pod里有三个容器
istio的iptables里执行了这些命令
无论从哪里来,到哪里去,只要是tcp协议的都转到15001端口
在pod容器里就是这么体现的,无论从哪里来,到哪里去,只要是tcp协议的都转到15001端口
iptables原生的链,只有4条,prerouting,output,input,postrouting,
注入之后,进程的分析
istio-init这个容器的执行命令
nginx进程master是负责接受的,worker是负责干活的
nginx容器里工作了两个进程
其实istio-proxy就是一般讲的边车
是一个进程启动了另一个进程,还是两个进程都启动
其实上面 两个进程是有主从关系的。pilot-agent这样一个进程实际上是生成envoy的启动配置,然后再启动envoy,当envoy这样一个进程起来后,pilot-agent进程会实时的watch这个envoy进程,如果envoy进程出错了,会负责把envoy进程重启。
此外,当外部的一些流控的规则,发生了变化以后,pilot-agent会监听这种变化,同时再把envoy以新的配置再重新加载。
envoy其实和nginx或haproxy做对比,它相当于反向代理服务器。envoy做边车,其实是因为它比较轻量。
圆形代表pod,方形代表container,圆角矩形代表进程,每一个pod里有istio-proxy容器,每个容器跑了客户端监视进程pilot-agent会和pilot服务端进行通信。
poilot 作为一个服务端会不断watch api server,api-server又把状态都存到etcd里。
如果现在apply istio的资源 流控文件。api-server解析后,形成一堆规则,pilot-discover其实就是pilot-server监听到api-server的配置,然后解析成envoy的配置,发到每一个istio代理的itio-pilot-agent,agent请求envoy进程。envoy拿到配置的时候就会去做一些流控等操作。
每一个注入的istio-proxy,都会有一个pilot-agent进程去监视envoy
istio-system名称空间下会有一个isiod组件,pilot-discovery(istio1.15.0后的叫法),pilot-discovery就是pilot-server,这个服务端就会watch api-server
**envoy的进程作用,它的作用类似nginx,haproxy。
服务端口和作用的对应关系。
**
envoy管理端口,并不对外开放,只是127.0.0.1
被注入后的资源变化情况
同样的镜像,产生了不一样的行为
1.5.0版本
注意两个点。
这个是当一个docker镜像被运行成容器的时候,entrypoint是首先执行的命令。可以查看一下为什么是pilot-agent启动的envoy
K8S里的yaml文件如果有commd和args的时候可以覆盖dockerfiile里 的 entrypoint,如果有冲突的话都是以K8S为主。
被注入后的资源有args
可以进容器里看到pilot-agent后面的指令加了一堆的参数
/usr/ocal/bin/pilot-agent其实就是镜像转成容器的时候就会去运行的entrypoint
后面的参数都是K8S资源带进来的
上面就是针对istio/proxyv2这个容器的行为
也是一样的
同样的操作,iinit-container就没有执行
而是只生成了一堆iptables结果
容器分两种类型,一种是init容器,一种是container容器
这个args是针对container级别的容器
init里并没有args,只有command
也就是只会执行这一段
自动注入
这是原来命名空间没有注入的时候,lables的情况
改造一下,让这个命名空间实现自动注入
没有进行手动注入,只是再当前命名空间下打了标签,这样发布原始的deployment就会实现自动注入
1istio注入的本质
2.哪些资源可以被注入。
3.
生成一个service,使用expose命令在原来的deployment上形成一个service
这个service做为一个pod负载,挡在pod前面,可以通过service去直接访问这个pod
使用istioctl手动注入一下
把yaml文件dump出来
现在进行注入
尽管注入了,也没有发生任何改变
upgrade 升级
1.sitio的升级计划
2.升级的前置条件
3.升级步骤
升级istio有两种方式,一种是istioctl,另一种是helm(K8S包管理器)
如果要升级到1.5.0.你的istio版本可能要高于1.4.4,不能拿1.1.0的版本直接升级到1.5.0,之前是使用istioctl工具升级,前期也必须是istioctl安装的旧版本才可以通过istioctl升级到新版本,前后安装方式要保持一致性。
设置环境变量
现在客户端版本是1.4.5,安装K8S里的资源也是1.4.5
istio1.4.5升级到1.5.0,在资源上有很大区别了,很多组件要么在1.5.0里被删除了,就是以另外一种方式展示出来
istio的升级有两个方面,istio本身的升级,曾经被isti注入过的资源升级到istio新版本的时候也需要升级到新版本
在现有版本先注入istio的资源
先删除,重新再注入一次
现在已经注入成功了
在升级istio
新版本istio下载到本地
已将三个istio版本放到百度网盘了1.3.2,1.4.5,1.5.0
重新设置环境变量
老版本的环境变量还存在,需要换掉
istioctl这个客户端工具切换掉了
还需要升级K8S上的istio
有这样一个脚本,打子命令就可以用tab键了
在进行istio升级的时候,确保新的profile和老的profile是一致的,原先如果是装的是demo profile,那么新升级装的也需要是demo profile
新的profile先dump出来
升级的时候如果处问题,那么可能是jwt策略没有做修改
如果这里不进行修改,那么就会报证书无法挂载的一些情况
使用istioctl upgrade进行升级
正在升级
出口网关。,入口网关
istiod是控制面的主要管理者
新版本istio的架构图,数据面还是istio-proxy,数据面的东西
控制面已经发生改变,老版本的mixer已经被废弃掉了,现在变成了pilot,citadel,galley
现在的版本变化情况,控制面升级成了1.5.0,数据面因为老版本注入了一个1.4.5,所以还有一个1.4.5
上面升级的提示代表,手工注入还是用手工,自动注入就需要用rollout
现在就都升级到1.5.0了
virtual service 介绍
istio流量管理的一小部分,virtual service
istio1.5以前的特性都有哪些
网络流量的管理
经典网络管理模型
istio流量管理和istio流量管理模型
实现istio流量管理有哪些方法
虚拟服务的样例,和介绍
vitual service只是istio流量管理的一种实现方式
ittio1.5版本之前的特性主要是流量管理,服务之间通信的流量加密,observability可观察性,policy策略
但是1.5.14的,重点都在流量管理
流量的本质就是采用合适的策略控制流量的方向和多少
经典流量管理模型
以前是只有流量,没有流量管理
后面就有了一层的转换,有了反向代理服务器就可以选择了,这既是经典的网络流量管理模型
istio的流量
istio的架构,1.5版本相比较之前的版本做了很大的简化了,可以大致看到两部分,数据面(proxy就是指的是envoy)+控制面(piloy。citadel,gally)
经过注入后的微服务就会形成一个网格,只要是K8S资源被istio注入就会形成一个网格出来。实际上在istio之内,有很多很多服务网格。
有了网格之后serviceA访问serviceB不是直接访问,而是通过proxy,到另外的网格里的proxy再到服务。
如果注入资源很多的话,就会形成一个个网格,绿色是微服务,蓝色相当于代理,各个微服务之间的通信,就相当于是代理之间的通信,因为这些代理会拦截微服务之间的流量。
把蓝色的方格抽取到右边,就形成了服务网格的控制面,会发消息给所有的代理
istio的架构由数据面和控制面组成,istio的流量也可以分为数据面流量和控制面流量。数据面流量是指微服务之间业务调用的流量,控制面流量是指istio各组件之间配置和控制网络行为的流量。
istio流量的管理
istio流量管理模型
网格发送的接收的所有流量都要通过envoy代理
比如有个java服务,要去调用女神服务的深层次接口,如果调用失败,语言层面会有retryable这个annotation,调用失败会重试3次。
三次都调用失败会去调用修复recover的接口,这些代码是跟业务 关系无关的。
假如有envoy就会 代替你做 这些操作
istio的流量管理到底为什么实现
istio的5个资源 类型
是如何生效的,假如服务网格有老司机服务和女神goddess服务,两个服务完成注入,经过istio注入后会有两个进程pilot-agent和envoy。piloy-agent是管理envoy的,pilot-agent会和istiod pilot server端进行通讯。
istiod的pilot会去监听apiserver,假如有资源通过 kubectl命令发布以后,kubectl会和apiserver进行交互,apiserver会执行部署文件,生成相关的K8S资源,数据存储到etcd里。
如果产生istio流量管理资源,istio就能够被监听到,会把相关配置信息发送给pilot-agent,pilot-agent会去变更envoy
本章主要讲istio资源的virtual service sample
可以看看三个例子场景
第一个场景是,不是istio,是纯K8S的,部署了两个deployment,deployment是httpd,tomcat,前面都有一个配套的service关联它们,客户端可以通过指定的服务类型访问到具体的服务器。
下面 的场景是,现在客户端根本不想指定,后面的两个服务器其实都属于web服务器,完全没有必要一个个指定。可以让一个web服务关联两种web服务器。
这种也是可以用K8S直接去实现
现在不想均分流量了,这种情况,K8S目前是做不到的。
现在就轮到istio登场了,没有太多变化,只是加了以恶virtual service set route rule,这个虚拟服务其实就是设定流量大小,方向。
要达到这种效果,这些资源必须在istio的服务网格中。
写这几个例子需要4个文件,上面三个都是K8S相关的,跟istio无关
把自动补全功能加上
因为有matchlabels,低版本的K8s可能要做一个调整
测试有没有问题。再把它删掉。
客户端写好了,就可以写deployment
测试是否成功
上面的deployment写好了,下面是service
验证是否正确
测试是否有错误
应用一下,然后查看svc是否有绑定,显示none代表并没有绑定
现在就关联上 了
现在已经完成了第一个场景
-q是静态,-O是输出的地址
第二个场景需要多起一个web service
这样就基本实现了轮询
第三个场景
首先需要新增istio的资源文件
这个资源文件代表一个virtualservice的资源,host都才用 K8S的service
如果是因为在一个命名空间下,贪图省力可以写上面的短域名方式
这样就代表生效了
这个virtual service是isttio自己的资源,在K8S的svc里是查不出来的
要想生效,所有的资源都需要被istio注入,三个服务都需要在istio的网格之间。
现在开始注入
注入完成
现在就是8比 2 的流量
访问ip也是 可以的,因为这个IP本来 就指定了host
访问istio网格外的服务是否有 8比2的效果,直接 用K8S层面 的去调用,这样就还是 轮询的,istio的 规则并没有生效
这次不注入,也就是不放在istio网格中
使用服务网格 外 的服务 访问网格内,查看是否还按照规则
还是 轮询的方式,istio没有生效
virtual service 原理
istio虚拟服务理论
1.回顾上次虚拟服务的例子
2.虚拟服务作用
3.虚拟服务本质
4.虚拟服务执行
5.虚拟服务语法
6.虚拟服务另外的样例
上次的样例是三个服务网格,两个service,1个客户端
虚拟服务的作用。官方是说虚拟服务是一种流量路由的基石,虚拟服务 可以让你在服务网格内配置请求如何路由到服务上去的。
总结:虚拟服务就是在istio网格内实现流量路由的,这就是istio的 virtual service的作用。
虚拟服务的本质
以前没有istio做路由,大部分是用nginx,第一部分是服务名,第二部分是路由规则,
虚拟服务就是一个istio的api资源,istio采用k8s的crd,定义成自己的服务,也是跟nginx类似,分成2个部分,对外提供寻址服务,第二部分也是路由规则
总结:虚拟服务的本质就是配置的片段
配置最终是要执行,虚拟服务这个资源到底是怎么被执行的
**比如nginx,ginx配置加载到nginx进程上才可以进行流量路由
虚拟服务必须要加载到envoy这个反向代理服务器上 可以进行流量路由 **
虚拟服务的文件写法
利用kubectl工具把刚才写的虚拟服务文件发布到apiserver上,istiod的pilot server监听到资源创建后,下发给服务网格内的pilot-agent,pilot-agent取得了服务资源后再发给网格内的envoy进程,envoy进程把配置 加载生效,立刻生成了定义的virtual service路由的规则。
以后在一个网格内调用其他服务的时候,调用前就会被envoy进程捕获到这种行为,就会把新的规则应用到流量控制。
虚拟服务的语法
hosts代表一个K8S集群内可以寻址到的一个访问目标。如果要访问目标,就需要遵守下面的访问规则。
其实就是这两部分,除了支持http还可以支持tcp。
K8S的web service都会有一个虚拟ip(kubectl get svc)的,这个ip就说明这个web服务是可以寻址的,就一定会用到路由规则
虚拟服务的语法之一,host field
如果在K8S集群内,k8s的svc就是一个可寻址的访问目标,那么host就是这个svc的名称或者ip,web-svc其实是个短域名,如果在web-svc同一个命名空间下,那么就可以使用短域名访问,否则就不行。
如果client和web-svc不在同一个命名空间下,那么就不能用短域名访问了,为了能被寻址到,就只能写长域名。
K8S集群内,除了可寻址的访问目标,K8S还有一张资源,ingress
如果K8S集群外访问到K8S里面的话,前提是要在K8S集群打一个孔出来,这个孔就是ingress-controller,这个是一个可选的组件,实现有很多种,比如traefik-ingress-controller,也有nginx-ingress-controller
ingress配置了一个域名也可以对外寻址到的,这个域名指向最终的后端服务是tea-svc,如果是另外的域名即使coffee-svc
总结,虚拟服务的hosts语法指的是k8s集群内是一个可寻址可访问目标
hosts的值通常是下面的4种
1.服务的短域名。
2.全域名,如果客户端访问这个service不在一个名称空间下,必须要把全域名写上,否则是访问不到的,流量的规则也不会生效。
3.网关,所有流量的一个入口
4.如果是*星号,经常会和网关结合起来用,标识这个virtualservice对整个K8S所标识的所有资源(可寻址的访问目标),都市同样的路由规则。
虚拟服务的路由规则,百分之20流量和百分之80流量
路由规则有两个元素,1个匹配条件,一个路由的目的地
virtual service规则,网格内的服务要去访问web-svc服务,并且是http协议,http头里有end-user的key,值是jiuxi,就会把流量转发到httpd-svc上去。
反之,转发到tomcat-svc上去。
转发规则是两个部分,match部分和destination部分。
规则的优先级。
越上面的优先级越高,匹配到了就不往下走了。
路由规则可以是组合的
下面的路由规则有2个维度,一个http的header,一个uri,如果流量是基于http协议的,头部有end-user这个key,值等于json,并且请求的前缀是/rating/v2/,并且忽略大小写敏感。
这样规则就形成了一个组合
匹配的条件,比如header里是一个map级,exact代表你的key的值完全要等于,prefix前缀部分,针对这些组合,可以对路由规则进行一个非常复杂的组合。
一个虚拟服务的例子,增加一个http header做一个条件。
之前是在webservice之上增加了一个虚拟 服务
现在把80,20流量去掉,改成根据http header来
添加变量,增加istio自动补全。
把上次的服务清理掉
现在开始做istio注入
现在都注入网格了
现在启动一个K8S的service
之前的虚拟服务是在web-svc上
使虚拟服务生效
现在测试访问应该是4比1的流量
把现有的虚拟服务删除,新增一个有匹配条件的虚拟服务
在http协议头部加上end-user的key,让这个key的值完全等于jiuxi
部署有条件的虚拟服务
没有加头,就是直接访问httpd-svc去了
加了头就访问tomcat去了,说明虚拟服务生效了。
虚拟服务的作用就是流量路由的。虚拟服务的本质其实就是nginx的一段配置而已。写的yaml文件应用到apiserver,被istio的pilot -server监听到,就把istio层面的配置转换成envoy去发送给网格内的pilot-agent。这样就实现了在K8S进行操作,就能够被网格内的istio识别
istio-前世一
一般java架构师向上接触不到运维层,操作系统,存储,网络,协议。所以有些java架构师面对公司的一些要求的时候,是比较迷茫的
要不停地实践和操作,现在新知识的获取比以前容易太多了,会让你产生一个错觉,花2天时间学完了,就会觉得自己很优秀。
大概需要去学去实践1万个小时才能成为自己的,就是《一万小时天才理论讲的》
但是要明白,5年干一件事情,也就相当于干一年,并不会成为专家
要持续的精进,学的不在多,在精,那么多语言,其实归根到底还是数据结构,加控制语句
如果像成为某个领域的佼佼者,必须踏踏实实投入时间,还需要进行大量的训练
有一些架构师在云端控制,并不再去研究技术,就是指挥别人干活,那么技术的更新会把整个团队的人淘汰掉。
当你的认知水平提高了,你学习新的东西就更快了
悟只能是自己的事情,别人是教不了的
释迦摩尼传宗,普适化好,留下地涌金莲,顽石点头,天花乱坠,讲的好。
佛讲究空
前世二
苏轼三兄弟本来水平都差不多,但是苏轼后来接触了佛教的一些事务,就思想水平层次上有了更进一步,拉开了其他兄弟。
做人的时候,要学学道家
技术人员往往需要在一片废墟中进行创造
user——shadow表相当于user表的复制
前世三
维米尔的戴耳环的少女
前世四、五、六
network namespace
目标:
1.linux的网络名称空间介绍
2.linux的网络名称空间的操作。
3.两个网络名称空间的通信
4.多个网络名称空间的通信。
**网络名称是linux的发行版都共享了网络接口,iptables还有路由表的条目,这些组成了linux的网络名称空间。
网络接口像是操作系统的网关,就是网卡,流量是在这个点上出入的,一旦流量进入系统中,就要靠iptables转发流量
**
设计网卡的目的就是想多个计算机互相通信使用的,为什么可以通信,要被对方能够找到,前提是要能标识自己,mac地址。
网卡属于osi7层中的第二层,网卡之间的链接可以通过有线或者无线波的方式。mac地址是记录在网卡的ram里的
流量的具体走向还需要靠iptables,4表5链,现在展示的是filter表,
路由表代表流量最终可以从哪个网络设备出去,比如可以通过eno,calico,flannel网络设备转发
耶和华可以做为一个linux发行版本,亚当可以当一个命令工具,夏娃可以认为是一个网络接口,伊甸园可以做为linux的网络名称空间。
回环口,只要是127网段的都行
很多命令都可以操作NIC网络接口也就是夏娃,并不只是ping,亚当
netns add 添加了一个网络名称空间,但是发现进入网络名称空间的提示符是一样的,可以优化
**把greenland提示符修改,通过exec进入到greenland采用bash shell 采用-rcfile 设定后面的内容 **
新的网络名称空间里面其实跟其他网络名称空间完全不一样,说明起到一个隔离的作用
不进入网络名称空间也可以进行操作
对网络名称空间的操作就像是进入到docker容器里操作,因为网络名称空间就是linux内核的一个功能,docker只是在原来的基础之上做了一次扩展。
在网络名称空间里可以执行的操作
换命名空间里的命名提示符
但是网络不可达,因为当前网络设备是down
启动网络接口
network namespace 二
两个不同命名空间是如何通讯的
等于现在有两个网络名称空间
先把之前的删掉
创建两个各自的网络名称空间,但是现在无法进行沟通
可以搭建一个梯子
**ip link梯子,梯子是一对的veth peer **
这个设备是一对的peer
这梯子是双向的,从a到b,b到a
这个梯子是要一半放在a里,一半放在b里
目前a里只有一个回环口
把一半梯子放在a里
把属于b的一半放在b的里面
现在两个梯子就搭建好了
创建了一个梯子,把梯子的每一半搭建到对方里面
现在要把梯子固定好,实际上就是设置好自己的ip地址
针对ximengqing的网络名称空间,把刚才安装 好的梯子固定在一个ip上
另外一个也需要固定ip
两个拆开的梯子需要搭在一起 ,两个都需要up掉。
需要启用设备,LOWERLAYERDOWN,单方面启用是不够的 ,需要双方启用。
只有当两者的梯子都启用了才有用
现在就可以进行访问了
梯子其实就是一个网络设备,ip link命令创建的一个 网络设备,有了这个设备,两个不同网络名称空间下的设备就可以进行通信了.
network namespace 三
王婆可以作为 一个桥
在外面搭一个桥
现在需要两把梯子,每一把梯子都分为2半,一半在王婆一半在xmq院子里,
创建好后,就发现xmq和wp
创建了梯子,就需要固定住
原先的名字错了了,重新简历一个名称空间
xmq到王婆的已经好了
在外部操作
现在xmq和王婆的梯子建立好了
设置xmq的地址
把梯子设备激活
现在把王婆家的梯子激活
同样的,pjl也需要梯子
现在梯子就创建好了
少一个王婆到pjl的
固定梯子
下面启动pjl家的梯子
现在王婆起到一个桥接的作用
network namespace 四
需要把王婆这样一个桥接设备启用
现在把王婆的设备宕机
现在就ping不通了
network device 一
**1.hub集线器
2.网桥
3.交换机
4.dhcp
5.nat
**
集线器工作在L1层,工作在物理层的一种设备
机制就是,负责数据的传输和转发,这个转发并非是ip层面的转发,hub接到数据包会往各个头发出去,是一种广播的机制。
一个头打入消息。,其他的头都能接收到
**导致的不好的地方在于,会话劫持和网络风暴。
如果在http1.0的时候,所有信息都是明文,看到你的消息包的时候,也是明文,所以叫session劫持。
只想把流量发送给一个台机子,但是其他机子也受到了,如果主机很多的话,整个网络会非常慢。
**
这是一个网桥设备
网桥设备工作在l2层,属于数据链接层的设备,2层设备根据mac地址来的,跟3层设备的ip是不一样的
网桥依靠mac地址,可以进行寻址,就不需要再广播了,这就是比HUB设备优越的地方
知道mac地址就可以寻址,但是还是一个局域网的范畴
network device 二
现在讲二层交换机,三层的交换机可以根据ip有一种路由的功能了
2层,数据连接层最直接的就是mac地址
还是基于mac地址来寻址,在局域网内,一台主机要访问另外一台主机,不用通过广播形式,通过mac地址就可以把机器定位到
(无论三层还是二层,都是不可能跨网络的,如果有一个局域网A和局域网B,通过网桥和二层交换机是无法通讯的,通过路由器菜可以,因为路由器是三层的设备,划的lana和lanb,相当于一个大网段内的分两个小网,分了两个能够互相通讯的网。)
如果用网桥接到两个hub口,网桥的mac表记住不同的mac地址,首先还是用hub网络广播进行通讯,但是网桥学习到了mac地址后,就不需要进行网络风暴了
端口和mac地址是一对多的
交换机其实也有mac表,一个插口对应一个mac地址
这就是二层交换机和网桥的区别,网桥是有限控制了流量风暴,没有完全杜绝,二层交换机就完全杜绝了
DHCP,是动态主机配置协议
dhcp客户端启动后发广播整个网络,dhcp server捕获请求,会分配ip地址,网关,dns
dhcp客户端和服务端通讯,客户端是会向全网发送广播的,dhcp会收到请求后,在自己的持久层里,查看客户端以前是否有绑定ip的记录。有的话,如果没人使用会把原来的发给客户端,客户端进行配置,发送确认给服务端,服务端会确认进行更新到自己的记录里。
network service 三
最常用nat的就是路由器,路由器是链接不同网络的设备
大纲介绍
**istio是一种服务网格的实现,大概从12个方面
0 istio的简单介绍
1 istio的架构和核心
2 **
1 istio的架构和核心,有两个平面,数据平面envoy(负责服务间通讯)和控制平面(mixer策略的制订,pilot观察者,服务发现用的galtey配置中心,citadel服务之间调用证书)
流量管理,路由
security其实是google的alts,有范围,只针对点对点,服务对服务,pod对pod
策略和调测
可观察性,针对所有网络里的流量都要进行跟踪
上面就是4个future,下面就是安装升级,操作
9诊断工具,10分析配置
istio的一些命令
安装和卸载
istio的安装包
可以跟kubectl放在一起
放到环境变量里
第一步添加环境变量完成
但是istioctl的自动补全功能 没有,还需要安装
现在已经完成好自动补全了
istioctl这个工具其实式和K8S里 跑的istio通信的一个客户端工具
报错,现在其实并没有安装完成,istioctl其实会和iK8S里的stio进行通信,集群里的还没装好,就只能看到 对当前客户端的版本
可以先把istio链接远程的关闭
安装方式可分位istioctl和helm
这里其实就是apply manifest清单里的,istio里有多种,比如demo,
打个比方,奔驰G系可以有多个车型,从商家角度就是可以做 差别化管理,profile可以作为同一款车型的不同的车类别
可以看一下profile的类别,当前1.4.5有这么多的 profile
安装说白了,就是apply到K8S集群里,tracing就是一个链路追踪的,pilot服务发现,服务配置,kiali就是一个istio的dashboard,prometheus监控,telemetry是一个遥测(一个请求可以report资源情况给telemetry),galley整个istio的配置中心,ingressgateway入口网关,egressgateway出口网关,cidadel流量加密身份认值,policy定义黑白名单。
![](https://img-blog.csdnimg.cn/20210621173134699.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQyMjI3ODE4,size_16,color_FFFFFF,t_70)
做一下检查,默认会有这么多服务,自动创建一个istio-system
istio部署的service,K8S的svc类别有loadbalance(用到了外部的负载均衡),clusterip,nodeport,ExternalName。
这个loadbalance的外部ip永远不会给,所以我们等待需要修改
deployment也有3个有问题
HPA,苗测
查看是不是镜像拉取 不到
正在拉镜像
现在 架构是3台master,10台worker
有几台是已经安装过有镜像的,可以直接喊出pod,让它调度到有镜像的地方去
现在要把这个svc改成node port
现在已经改为nodeport了
卸载掉istio,通过istioctl manifest 这个资源清单的子命令,先把profile=demo的配置信息产生,再用kubectl 删除
命名空间已经删除了
我们没有lb类型的是,所以安装的时候需要把istio的ingressgateway类型改成nodeport
istioctl profile
前面大概说明了istioctl的安装
配置istioctl
利用istioctl在k8s里安装istio
利用istioctl在k8s里卸载istio
本章目标是
介绍istioctl version子命令,analyze子命令
kiali组件,介绍profile。
单纯安装istioctl,没有安装istio在k8s里这个工具后会报错,所以只打印了istictl的版本号,没有输出istio的版本号
安装好再去指向,除了打印istioctl的版本号,还会打印istio 数据面和控制面的版本号
analyze实际上是分析配置信息,并将配置信息配置分析的经结果打印到控制台。
会分析默认的命名空间下有关istio的注入的信息,现在还没有对istio的命名空间做任何的配置和注入,管理,所以会报错。
另外一个名称空间做了一个注入,会去分析在jiuxi这个名称空间下被istio注入的配置检查工作。检查的结果就是,没有任何的校验问题。
kiali是一个服务网格的可视化工具
以demo的profile安装。默认就会安装kiali
jiuxi的名称空间下安装了4个istio官方的微服务
一定要加上traffic animation
现在 尝试打入一点流量
注入一些流量进去
已经看到效果了
三角形是K8S的service
圆形代表pod
百分百的流量会进入productpage
进入productpage之后会分50%到reviews,49.7%到details
reviews有三个版本,基本上是round Robin
重点说明istio的profile
生面的车系对比不是特别贴切,下面的每个手机套餐可以算作不同的profile,定了某个profile,就会有不同的升值服务。安装不同的profile,就等于不同的istio的控制行为
首先看demo的profile
其实每个profile都是不同的,配置值不一样,demoprofile主要定义了两大部分。core components 和addons。
addons可以理解未插件,component可以理解为组件。
组件会通过出口网关,入口网关,pilot,,跟官网提供的说明一样。
之前安装都是demo.yaml,没有修改,组件一个都不少。
另外一个profile是minimal,只是开启了非常 少的功能,istio-pilot
可以看到组件都是 关闭的
default profile其实是官方推荐的,主要开启了 prometheus,入口网关,pilot,istio官方推荐在生产和环境安装的profile
空模板,其实是就是根据自己爱好添加
官方作废了,不推荐使用
最难的profile
官方说是只开启了一个prometheus插件,但是实际上入口网关和pilot也是开启的
inject 注入
**上一章主要将,istioctl的version和analyze的子命令。
kiali组件可视化网格。
istioctl的6个profile
**
1.注入的本质和后果。
2.哪些资源可以被注入
3.手动注入
4.从进程角度分析一下注入之后。
5.自动化注入
注入在以后pod内会生成两个兄弟,,mr.net负责网络初始化,mr.window就是当前资源跟K8S其他资源交互的一个窗口
查看哪些资源可以被istio注入。
黑体字部分,被istio注入就是有了孩子了,会有孪生兄弟。红色的资源被istio注入后,实际上是不会产生什么结果的。
实际的例子,istio手工 注入。
第4条开始才是注入,把注入的 效果展示出来,但是实际上并没有注入,下面一条才是执行istio的真实注入
创建命名空间
当前pod后缀是lc打头,其实注入会把原来的pod杀掉,pod相当于重启了。
管道前面只是用了istioctl工具,对原有的deployment资源注入,并将注入的结果,用kubectl发布出去
现在pod里有两个容器,生成一个新的pod,把原来的pod杀死掉
把注入后有哪些资源都dump出来
注入的资源比原来丰富了不少。现在是2个容器
其实容器有两种,一种是containers,一种是initcontiners
第二个容器叫istio-proxy
还有一种让其是iinitcontainer
初始化的容器里有istio-init
注入前和注入后
rancher的可视化界面其实就看到了,三个容器,初始化容器其实就terminate了
istio-init这个让其是做什么,其实就是mr.net(初始化网络名称空间用的),istio-proxy其实就是mr.window
所有的容器都处在一个网络名称空间里
-it以交互的方式,在当前pod里的nginx容器,–只是kubectll要命令pod里的容器进行操作的一个必要语法执行ifconfig命令
查看 isitio-proxy的
它们的网络名称空间都是一样的
经过istio注入,网络名称空间究竟发生了什么
网络端口发生了变化
重新发布一个资源 ,把原来的deployeent资源发布到另外一个命名空间里去,形成一个没有注入的效果。
在default命名空间下发布一个deployment
查看当前的端口号,这是没有被istio注入前的
那么之前在jiuxi命名空间下进行了一个istio的注入,网络端口号多了5个,实际上这5个进程是envoy
多开的这几个端口号,背后的进程是envoy进程,还会有个pilot-agent进程。
注入后会多5个端口
不仅端口发生改变,网络的协议栈也会发生改变,tcp/ip协议之一般是操作系统内核来实现的,因为写代码的时候并不会去关心tcp/ip如何去实现的。
什么是网络协议策略,可以去做一些限制某一个ip来访问主机,具体实现是在内核里。比如iptables工具是从内核里的net和filter进行交互去调整。
是istio-init这个容器做了网络名称空间打通的事情
从init这个容器的命令里,在启动的时候会调用istio-iptables,可以去猜一下istio-iptables这个脚步做了什么
也可以通过这个命令直接看到
可以看到istio-init这个容器消耗的时候的日志,做了哪些操作
下面修改了iptables,修改nat表
在nat表里加了4条链,ISTIO_REDIREC,ISTIO_IN_REDIRECT,ISTIO_INBOUND,ISTIO_OUTPUT
针对每一条链添加了相应的规则
无论是从哪里来的流量,如果这个流量是tcp协议的会转到15001的端口上,这就是istio_redirect这样一个链
可以进入到pod里的容器里看看iptables
进入到容器里查看iptables网络情况,可以去看看nat表
istio_redirect
可以用rancher这个web页面来可视化查看,当前pod里有三个容器
istio的iptables里执行了这些命令
无论从哪里来,到哪里去,只要是tcp协议的都转到15001端口
在pod容器里就是这么体现的,无论从哪里来,到哪里去,只要是tcp协议的都转到15001端口
iptables原生的链,只有4条,prerouting,output,input,postrouting,
注入之后,进程的分析
istio-init这个容器的执行命令
nginx进程master是负责接受的,worker是负责干活的
nginx容器里工作了两个进程
其实istio-proxy就是一般讲的边车
是一个进程启动了另一个进程,还是两个进程都启动
其实上面 两个进程是有主从关系的。pilot-agent这样一个进程实际上是生成envoy的启动配置,然后再启动envoy,当envoy这样一个进程起来后,pilot-agent进程会实时的watch这个envoy进程,如果envoy进程出错了,会负责把envoy进程重启。
此外,当外部的一些流控的规则,发生了变化以后,pilot-agent会监听这种变化,同时再把envoy以新的配置再重新加载。
envoy其实和nginx或haproxy做对比,它相当于反向代理服务器。envoy做边车,其实是因为它比较轻量。
圆形代表pod,方形代表container,圆角矩形代表进程,每一个pod里有istio-proxy容器,每个容器跑了客户端监视进程pilot-agent会和pilot服务端进行通信。
poilot 作为一个服务端会不断watch api server,api-server又把状态都存到etcd里。
如果现在apply istio的资源 流控文件。api-server解析后,形成一堆规则,pilot-discover其实就是pilot-server监听到api-server的配置,然后解析成envoy的配置,发到每一个istio代理的itio-pilot-agent,agent请求envoy进程。envoy拿到配置的时候就会去做一些流控等操作。
每一个注入的istio-proxy,都会有一个pilot-agent进程去监视envoy
istio-system名称空间下会有一个isiod组件,pilot-discovery(istio1.15.0后的叫法),pilot-discovery就是pilot-server,这个服务端就会watch api-server
**envoy的进程作用,它的作用类似nginx,haproxy。
服务端口和作用的对应关系。
**
envoy管理端口,并不对外开放,只是127.0.0.1
被注入后的资源变化情况
同样的镜像,产生了不一样的行为
1.5.0版本
注意两个点。
这个是当一个docker镜像被运行成容器的时候,entrypoint是首先执行的命令。可以查看一下为什么是pilot-agent启动的envoy
K8S里的yaml文件如果有commd和args的时候可以覆盖dockerfiile里 的 entrypoint,如果有冲突的话都是以K8S为主。
被注入后的资源有args
可以进容器里看到pilot-agent后面的指令加了一堆的参数
/usr/ocal/bin/pilot-agent其实就是镜像转成容器的时候就会去运行的entrypoint
后面的参数都是K8S资源带进来的
上面就是针对istio/proxyv2这个容器的行为
也是一样的
同样的操作,iinit-container就没有执行
而是只生成了一堆iptables结果
容器分两种类型,一种是init容器,一种是container容器
这个args是针对container级别的容器
init里并没有args,只有command
也就是只会执行这一段
自动注入
这是原来命名空间没有注入的时候,lables的情况
改造一下,让这个命名空间实现自动注入
没有进行手动注入,只是再当前命名空间下打了标签,这样发布原始的deployment就会实现自动注入
1istio注入的本质
2.哪些资源可以被注入。
3.
生成一个service,使用expose命令在原来的deployment上形成一个service
这个service做为一个pod负载,挡在pod前面,可以通过service去直接访问这个pod
使用istioctl手动注入一下
把yaml文件dump出来
现在进行注入
尽管注入了,也没有发生任何改变
upgrade 升级
1.sitio的升级计划
2.升级的前置条件
3.升级步骤
升级istio有两种方式,一种是istioctl,另一种是helm(K8S包管理器)
如果要升级到1.5.0.你的istio版本可能要高于1.4.4,不能拿1.1.0的版本直接升级到1.5.0,之前是使用istioctl工具升级,前期也必须是istioctl安装的旧版本才可以通过istioctl升级到新版本,前后安装方式要保持一致性。
设置环境变量
现在客户端版本是1.4.5,安装K8S里的资源也是1.4.5
istio1.4.5升级到1.5.0,在资源上有很大区别了,很多组件要么在1.5.0里被删除了,就是以另外一种方式展示出来
istio的升级有两个方面,istio本身的升级,曾经被isti注入过的资源升级到istio新版本的时候也需要升级到新版本
在现有版本先注入istio的资源
先删除,重新再注入一次
现在已经注入成功了
在升级istio
新版本istio下载到本地
已将三个istio版本放到百度网盘了1.3.2,1.4.5,1.5.0
重新设置环境变量
老版本的环境变量还存在,需要换掉
istioctl这个客户端工具切换掉了
还需要升级K8S上的istio
有这样一个脚本,打子命令就可以用tab键了
在进行istio升级的时候,确保新的profile和老的profile是一致的,原先如果是装的是demo profile,那么新升级装的也需要是demo profile
新的profile先dump出来
升级的时候如果处问题,那么可能是jwt策略没有做修改
如果这里不进行修改,那么就会报证书无法挂载的一些情况
使用istioctl upgrade进行升级
正在升级
出口网关。,入口网关
istiod是控制面的主要管理者
新版本istio的架构图,数据面还是istio-proxy,数据面的东西
控制面已经发生改变,老版本的mixer已经被废弃掉了,现在变成了pilot,citadel,galley
现在的版本变化情况,控制面升级成了1.5.0,数据面因为老版本注入了一个1.4.5,所以还有一个1.4.5
上面升级的提示代表,手工注入还是用手工,自动注入就需要用rollout
现在就都升级到1.5.0了
virtual service 介绍
istio流量管理的一小部分,virtual service
istio1.5以前的特性都有哪些
网络流量的管理
经典网络管理模型
istio流量管理和istio流量管理模型
实现istio流量管理有哪些方法
虚拟服务的样例,和介绍
vitual service只是istio流量管理的一种实现方式
ittio1.5版本之前的特性主要是流量管理,服务之间通信的流量加密,observability可观察性,policy策略
但是1.5.14的,重点都在流量管理
流量的本质就是采用合适的策略控制流量的方向和多少
经典流量管理模型
以前是只有流量,没有流量管理
后面就有了一层的转换,有了反向代理服务器就可以选择了,这既是经典的网络流量管理模型
istio的流量
istio的架构,1.5版本相比较之前的版本做了很大的简化了,可以大致看到两部分,数据面(proxy就是指的是envoy)+控制面(piloy。citadel,gally)
经过注入后的微服务就会形成一个网格,只要是K8S资源被istio注入就会形成一个网格出来。实际上在istio之内,有很多很多服务网格。
有了网格之后serviceA访问serviceB不是直接访问,而是通过proxy,到另外的网格里的proxy再到服务。
如果注入资源很多的话,就会形成一个个网格,绿色是微服务,蓝色相当于代理,各个微服务之间的通信,就相当于是代理之间的通信,因为这些代理会拦截微服务之间的流量。
把蓝色的方格抽取到右边,就形成了服务网格的控制面,会发消息给所有的代理
istio的架构由数据面和控制面组成,istio的流量也可以分为数据面流量和控制面流量。数据面流量是指微服务之间业务调用的流量,控制面流量是指istio各组件之间配置和控制网络行为的流量。
istio流量的管理
istio流量管理模型
网格发送的接收的所有流量都要通过envoy代理
比如有个java服务,要去调用女神服务的深层次接口,如果调用失败,语言层面会有retryable这个annotation,调用失败会重试3次。
三次都调用失败会去调用修复recover的接口,这些代码是跟业务 关系无关的。
假如有envoy就会 代替你做 这些操作
istio的流量管理到底为什么实现
istio的5个资源 类型
是如何生效的,假如服务网格有老司机服务和女神goddess服务,两个服务完成注入,经过istio注入后会有两个进程pilot-agent和envoy。piloy-agent是管理envoy的,pilot-agent会和istiod pilot server端进行通讯。
istiod的pilot会去监听apiserver,假如有资源通过 kubectl命令发布以后,kubectl会和apiserver进行交互,apiserver会执行部署文件,生成相关的K8S资源,数据存储到etcd里。
如果产生istio流量管理资源,istio就能够被监听到,会把相关配置信息发送给pilot-agent,pilot-agent会去变更envoy
本章主要讲istio资源的virtual service sample
可以看看三个例子场景
第一个场景是,不是istio,是纯K8S的,部署了两个deployment,deployment是httpd,tomcat,前面都有一个配套的service关联它们,客户端可以通过指定的服务类型访问到具体的服务器。
下面 的场景是,现在客户端根本不想指定,后面的两个服务器其实都属于web服务器,完全没有必要一个个指定。可以让一个web服务关联两种web服务器。
这种也是可以用K8S直接去实现
现在不想均分流量了,这种情况,K8S目前是做不到的。
现在就轮到istio登场了,没有太多变化,只是加了以恶virtual service set route rule,这个虚拟服务其实就是设定流量大小,方向。
要达到这种效果,这些资源必须在istio的服务网格中。
写这几个例子需要4个文件,上面三个都是K8S相关的,跟istio无关
把自动补全功能加上
因为有matchlabels,低版本的K8s可能要做一个调整
测试有没有问题。再把它删掉。
客户端写好了,就可以写deployment
测试是否成功
上面的deployment写好了,下面是service
验证是否正确
测试是否有错误
应用一下,然后查看svc是否有绑定,显示none代表并没有绑定
现在就关联上 了
现在已经完成了第一个场景
-q是静态,-O是输出的地址
第二个场景需要多起一个web service
这样就基本实现了轮询
第三个场景
首先需要新增istio的资源文件
这个资源文件代表一个virtualservice的资源,host都才用 K8S的service
如果是因为在一个命名空间下,贪图省力可以写上面的短域名方式
这样就代表生效了
这个virtual service是isttio自己的资源,在K8S的svc里是查不出来的
要想生效,所有的资源都需要被istio注入,三个服务都需要在istio的网格之间。
现在开始注入
注入完成
现在就是8比 2 的流量
访问ip也是 可以的,因为这个IP本来 就指定了host
访问istio网格外的服务是否有 8比2的效果,直接 用K8S层面 的去调用,这样就还是 轮询的,istio的 规则并没有生效
这次不注入,也就是不放在istio网格中
使用服务网格 外 的服务 访问网格内,查看是否还按照规则
还是 轮询的方式,istio没有生效
virtual service 原理
istio虚拟服务理论
1.回顾上次虚拟服务的例子
2.虚拟服务作用
3.虚拟服务本质
4.虚拟服务执行
5.虚拟服务语法
6.虚拟服务另外的样例
上次的样例是三个服务网格,两个service,1个客户端
虚拟服务的作用。官方是说虚拟服务是一种流量路由的基石,虚拟服务 可以让你在服务网格内配置请求如何路由到服务上去的。
总结:虚拟服务就是在istio网格内实现流量路由的,这就是istio的 virtual service的作用。
虚拟服务的本质
以前没有istio做路由,大部分是用nginx,第一部分是服务名,第二部分是路由规则,
虚拟服务就是一个istio的api资源,istio采用k8s的crd,定义成自己的服务,也是跟nginx类似,分成2个部分,对外提供寻址服务,第二部分也是路由规则
总结:虚拟服务的本质就是配置的片段
配置最终是要执行,虚拟服务这个资源到底是怎么被执行的
**比如nginx,ginx配置加载到nginx进程上才可以进行流量路由
虚拟服务必须要加载到envoy这个反向代理服务器上 可以进行流量路由 **
虚拟服务的文件写法
利用kubectl工具把刚才写的虚拟服务文件发布到apiserver上,istiod的pilot server监听到资源创建后,下发给服务网格内的pilot-agent,pilot-agent取得了服务资源后再发给网格内的envoy进程,envoy进程把配置 加载生效,立刻生成了定义的virtual service路由的规则。
以后在一个网格内调用其他服务的时候,调用前就会被envoy进程捕获到这种行为,就会把新的规则应用到流量控制。
虚拟服务的语法
hosts代表一个K8S集群内可以寻址到的一个访问目标。如果要访问目标,就需要遵守下面的访问规则。
其实就是这两部分,除了支持http还可以支持tcp。
K8S的web service都会有一个虚拟ip(kubectl get svc)的,这个ip就说明这个web服务是可以寻址的,就一定会用到路由规则
虚拟服务的语法之一,host field
如果在K8S集群内,k8s的svc就是一个可寻址的访问目标,那么host就是这个svc的名称或者ip,web-svc其实是个短域名,如果在web-svc同一个命名空间下,那么就可以使用短域名访问,否则就不行。
如果client和web-svc不在同一个命名空间下,那么就不能用短域名访问了,为了能被寻址到,就只能写长域名。
K8S集群内,除了可寻址的访问目标,K8S还有一张资源,ingress
如果K8S集群外访问到K8S里面的话,前提是要在K8S集群打一个孔出来,这个孔就是ingress-controller,这个是一个可选的组件,实现有很多种,比如traefik-ingress-controller,也有nginx-ingress-controller
ingress配置了一个域名也可以对外寻址到的,这个域名指向最终的后端服务是tea-svc,如果是另外的域名即使coffee-svc
总结,虚拟服务的hosts语法指的是k8s集群内是一个可寻址可访问目标
hosts的值通常是下面的4种
1.服务的短域名。
2.全域名,如果客户端访问这个service不在一个名称空间下,必须要把全域名写上,否则是访问不到的,流量的规则也不会生效。
3.网关,所有流量的一个入口
4.如果是*星号,经常会和网关结合起来用,标识这个virtualservice对整个K8S所标识的所有资源(可寻址的访问目标),都市同样的路由规则。
虚拟服务的路由规则,百分之20流量和百分之80流量
路由规则有两个元素,1个匹配条件,一个路由的目的地
virtual service规则,网格内的服务要去访问web-svc服务,并且是http协议,http头里有end-user的key,值是jiuxi,就会把流量转发到httpd-svc上去。
反之,转发到tomcat-svc上去。
转发规则是两个部分,match部分和destination部分。
规则的优先级。
越上面的优先级越高,匹配到了就不往下走了。
路由规则可以是组合的
下面的路由规则有2个维度,一个http的header,一个uri,如果流量是基于http协议的,头部有end-user这个key,值等于json,并且请求的前缀是/rating/v2/,并且忽略大小写敏感。
这样规则就形成了一个组合
匹配的条件,比如header里是一个map级,exact代表你的key的值完全要等于,prefix前缀部分,针对这些组合,可以对路由规则进行一个非常复杂的组合。
一个虚拟服务的例子,增加一个http header做一个条件。
之前是在webservice之上增加了一个虚拟 服务
现在把80,20流量去掉,改成根据http header来
添加变量,增加istio自动补全。
把上次的服务清理掉
现在开始做istio注入
现在都注入网格了
现在启动一个K8S的service
之前的虚拟服务是在web-svc上
使虚拟服务生效
现在测试访问应该是4比1的流量
把现有的虚拟服务删除,新增一个有匹配条件的虚拟服务
在http协议头部加上end-user的key,让这个key的值完全等于jiuxi
部署有条件的虚拟服务
没有加头,就是直接访问httpd-svc去了
加了头就访问tomcat去了,说明虚拟服务生效了。
虚拟服务的作用就是流量路由的。虚拟服务的本质其实就是nginx的一段配置而已。写的yaml文件应用到apiserver,被istio的pilot -server监听到,就把istio层面的配置转换成envoy去发送给网格内的pilot-agent。这样就实现了在K8S进行操作,就能够被网格内的istio识别
istio-前世一
一般java架构师向上接触不到运维层,操作系统,存储,网络,协议。所以有些java架构师面对公司的一些要求的时候,是比较迷茫的
要不停地实践和操作,现在新知识的获取比以前容易太多了,会让你产生一个错觉,花2天时间学完了,就会觉得自己很优秀。
大概需要去学去实践1万个小时才能成为自己的,就是《一万小时天才理论讲的》
但是要明白,5年干一件事情,也就相当于干一年,并不会成为专家
要持续的精进,学的不在多,在精,那么多语言,其实归根到底还是数据结构,加控制语句
如果像成为某个领域的佼佼者,必须踏踏实实投入时间,还需要进行大量的训练
有一些架构师在云端控制,并不再去研究技术,就是指挥别人干活,那么技术的更新会把整个团队的人淘汰掉。
当你的认知水平提高了,你学习新的东西就更快了
悟只能是自己的事情,别人是教不了的
释迦摩尼传宗,普适化好,留下地涌金莲,顽石点头,天花乱坠,讲的好。
佛讲究空
前世二
苏轼三兄弟本来水平都差不多,但是苏轼后来接触了佛教的一些事务,就思想水平层次上有了更进一步,拉开了其他兄弟。
做人的时候,要学学道家
技术人员往往需要在一片废墟中进行创造
user——shadow表相当于user表的复制
前世三
维米尔的戴耳环的少女
前世四、五、六
network namespace
目标:
1.linux的网络名称空间介绍
2.linux的网络名称空间的操作。
3.两个网络名称空间的通信
4.多个网络名称空间的通信。
**网络名称是linux的发行版都共享了网络接口,iptables还有路由表的条目,这些组成了linux的网络名称空间。
网络接口像是操作系统的网关,就是网卡,流量是在这个点上出入的,一旦流量进入系统中,就要靠iptables转发流量
**
设计网卡的目的就是想多个计算机互相通信使用的,为什么可以通信,要被对方能够找到,前提是要能标识自己,mac地址。
网卡属于osi7层中的第二层,网卡之间的链接可以通过有线或者无线波的方式。mac地址是记录在网卡的ram里的
流量的具体走向还需要靠iptables,4表5链,现在展示的是filter表,
路由表代表流量最终可以从哪个网络设备出去,比如可以通过eno,calico,flannel网络设备转发
耶和华可以做为一个linux发行版本,亚当可以当一个命令工具,夏娃可以认为是一个网络接口,伊甸园可以做为linux的网络名称空间。
回环口,只要是127网段的都行
很多命令都可以操作NIC网络接口也就是夏娃,并不只是ping,亚当
netns add 添加了一个网络名称空间,但是发现进入网络名称空间的提示符是一样的,可以优化
**把greenland提示符修改,通过exec进入到greenland采用bash shell 采用-rcfile 设定后面的内容 **
新的网络名称空间里面其实跟其他网络名称空间完全不一样,说明起到一个隔离的作用
不进入网络名称空间也可以进行操作
对网络名称空间的操作就像是进入到docker容器里操作,因为网络名称空间就是linux内核的一个功能,docker只是在原来的基础之上做了一次扩展。
在网络名称空间里可以执行的操作
换命名空间里的命名提示符
但是网络不可达,因为当前网络设备是down
启动网络接口
network namespace 二
两个不同命名空间是如何通讯的
等于现在有两个网络名称空间
先把之前的删掉
创建两个各自的网络名称空间,但是现在无法进行沟通
可以搭建一个梯子
**ip link梯子,梯子是一对的veth peer **
这个设备是一对的peer
这梯子是双向的,从a到b,b到a
这个梯子是要一半放在a里,一半放在b里
目前a里只有一个回环口
把一半梯子放在a里
把属于b的一半放在b的里面
现在两个梯子就搭建好了
创建了一个梯子,把梯子的每一半搭建到对方里面
现在要把梯子固定好,实际上就是设置好自己的ip地址
针对ximengqing的网络名称空间,把刚才安装 好的梯子固定在一个ip上
另外一个也需要固定ip
两个拆开的梯子需要搭在一起 ,两个都需要up掉。
需要启用设备,LOWERLAYERDOWN,单方面启用是不够的 ,需要双方启用。
只有当两者的梯子都启用了才有用
现在就可以进行访问了
梯子其实就是一个网络设备,ip link命令创建的一个 网络设备,有了这个设备,两个不同网络名称空间下的设备就可以进行通信了.
network namespace 三
王婆可以作为 一个桥
在外面搭一个桥
现在需要两把梯子,每一把梯子都分为2半,一半在王婆一半在xmq院子里,
创建好后,就发现xmq和wp
创建了梯子,就需要固定住
原先的名字错了了,重新简历一个名称空间
xmq到王婆的已经好了
在外部操作
现在xmq和王婆的梯子建立好了
设置xmq的地址
把梯子设备激活
现在把王婆家的梯子激活
同样的,pjl也需要梯子
现在梯子就创建好了
少一个王婆到pjl的
固定梯子
下面启动pjl家的梯子
现在王婆起到一个桥接的作用
network namespace 四
需要把王婆这样一个桥接设备启用
现在把王婆的设备宕机
现在就ping不通了
network device 一
**1.hub集线器
2.网桥
3.交换机
4.dhcp
5.nat
**
集线器工作在L1层,工作在物理层的一种设备
机制就是,负责数据的传输和转发,这个转发并非是ip层面的转发,hub接到数据包会往各个头发出去,是一种广播的机制。
一个头打入消息。,其他的头都能接收到
**导致的不好的地方在于,会话劫持和网络风暴。
如果在http1.0的时候,所有信息都是明文,看到你的消息包的时候,也是明文,所以叫session劫持。
只想把流量发送给一个台机子,但是其他机子也受到了,如果主机很多的话,整个网络会非常慢。
**
这是一个网桥设备
网桥设备工作在l2层,属于数据链接层的设备,2层设备根据mac地址来的,跟3层设备的ip是不一样的
网桥依靠mac地址,可以进行寻址,就不需要再广播了,这就是比HUB设备优越的地方
知道mac地址就可以寻址,但是还是一个局域网的范畴
network device 二
现在讲二层交换机,三层的交换机可以根据ip有一种路由的功能了
2层,数据连接层最直接的就是mac地址
还是基于mac地址来寻址,在局域网内,一台主机要访问另外一台主机,不用通过广播形式,通过mac地址就可以把机器定位到
(无论三层还是二层,都是不可能跨网络的,如果有一个局域网A和局域网B,通过网桥和二层交换机是无法通讯的,通过路由器菜可以,因为路由器是三层的设备,划的lana和lanb,相当于一个大网段内的分两个小网,分了两个能够互相通讯的网。)
如果用网桥接到两个hub口,网桥的mac表记住不同的mac地址,首先还是用hub网络广播进行通讯,但是网桥学习到了mac地址后,就不需要进行网络风暴了
端口和mac地址是一对多的
交换机其实也有mac表,一个插口对应一个mac地址
这就是二层交换机和网桥的区别,网桥是有限控制了流量风暴,没有完全杜绝,二层交换机就完全杜绝了
DHCP,是动态主机配置协议
dhcp客户端启动后发广播整个网络,dhcp server捕获请求,会分配ip地址,网关,dns
dhcp客户端和服务端通讯,客户端是会向全网发送广播的,dhcp会收到请求后,在自己的持久层里,查看客户端以前是否有绑定ip的记录。有的话,如果没人使用会把原来的发给客户端,客户端进行配置,发送确认给服务端,服务端会确认进行更新到自己的记录里。
network service 三
最常用nat的就是路由器,路由器是链接不同网络的设备
路由器工作在三层,属于ip层
1物理层
2数据链路层
3.网络层
4.传输层,更多的是关注到机器上的具体port
5.会话层
6.表示层
7.应用层
nat是一种网络技术,可以把内部的ip地址转换成外部的网路ip
houstA想要访问外部网络,需要经过路由器的两个网口,会把内部的IP地址转换成外网的8.8.8.69出去访问互联网,外部的ip会进行一个逆转换,返回到HOSTa
nat有三种类型,静态nat,池nat,网络地址端口转换
静态nat关系是1对1,69ipp对应转换成公网的189,13转换成对应的188,1对1
池nat是多对多的,ipo并不是手动绑定的,而是外部有一个地址池
实际场景用NAPT多一点,ip是一个比较稀有的资源,那么我们就可以在端口上做文章