2021/06/20 九析带你轻松完爆 istio (一)

大纲介绍

**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
在这里插入图片描述
验证是否正确
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
测试是否有错误
vv
应用一下,然后查看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
在这里插入图片描述
验证是否正确
在这里插入图片描述
在这里插入图片描述
在这里插入图片描述
测试是否有错误
vv
应用一下,然后查看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是一个比较稀有的资源,那么我们就可以在端口上做文章
在这里插入图片描述

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值