48N6E

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

验证是否正确

测试是否有错误

应用一下，然后查看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的就是路由器，路由器是链接不同网络的设备