第七章 九析带你轻松完爆 service mesh - istio 注入

网友投稿 293 2022-10-29

第七章 九析带你轻松完爆 service mesh - istio 注入

系列文章:总目录索引:九析带你轻松完爆 istio 服务网格系列教程

目录

1 前言

2 istio 注入与平台生态影响

2.1 环境准备

2.2 istio 注入操作

2.3 istio 注入本质

2.4 istio 注入 pod 后各容器作用以及关系

2.5 istio-proxy 和 envoy 关系

2.6 istio-proxy 和 kube-proxy 关系

2.7 envoy 进程服务端口

3 小节

1 前言

如果你对博客有任何疑问,请告诉我。

2 istio 注入与平台生态影响

虽然 istio 是平台间独立的,不仅支持 K8s、Consul,也同样支持虚拟机,但是本文部署平台环境还是聚焦在 k8s。

2.1 环境准备

在本系列文章的第二篇中提到过资源的 istio 注入,这里再做一个回顾。

新建 jiuxi 命名空间:

kubectl create ns jiuxi

编写 nginx deployment 资源文件 nginx-deploy.yaml:

apiVersion: apps/v1kind: Deploymentmetadata:    name: nginx    namespace: jiuxi    labels:    app: nginxspec:    replicas: 1    selector:        matchLabels:            app: nginx    template:        metadata:            labels:                app: nginx        spec:            containers:            -   name: nginx                image: nginx:1.14-alpine                ports:                - containerPort: 80

新建 nginx deployment 资源:

kubectl apply -f nginx-deploy.yaml

2.2 istio 注入操作

执行 istio 注入操作之前,须确保 istio 和 istioctl 都正确安装,安装操作请参阅《第一章》。

手动执行 istio 注入操作:

istioctl kube-inject -f nginx-deploy.yaml | kubectl apply -f -

执行成功之后截图如下:

此时 nginx pod 内部容器从原来的 1 个变成了 2 个(严格意义上应该是 3 个,因为有个启动容器执行完就结束了,因此这里看不到,后面会细说)。

2.3 istio 注入本质

我们再审视一下 istio 注入过程:

istioctl kube-inject -f nginx-deploy.yaml | kubectl apply -f -

该命令通过管道符 “|” 将两步操作合为一步,"|" 前在 nginx-deploy.yaml 资源文件注入 istio 内容,"|" 后部署经过 istio 注入的新的 nginx-deploy.yaml 文件。

那么 istio 到底注入了哪些内容呢?执行如下命令查看:

kubectl edit deployment -n jiuxi nginx

由此可知,istio 注入本质就是在宿主资源中添加 istio 特性,从而起到提高整个平台的能力。类似克拉克加了披风变成超人,布洛克吸附外星物质变成毒液一样的道理。

2.4 istio 注入 pod 后各容器作用以及关系

上图演示了 pod 在 istio 注入后产生了 2 个新的容器,这样原来单容器的 pod 现在变成了 3 个容器共存同一个 pod 中,而且宿主容器(nginx)跟 istio-proxy 容器还处于同一网络空间。

istio-init: 初始化容器。作用是初始化 pod 网络空间,创建 iptables 规则。istio-proxy: sidecar 容器。作用是启动 pilot-agent 和 envoy 进程。

可以通过 kubectl exec -it 命令进入 nginx pod 的 nginx 和 istio-proxy 容器,发现两个容器共享同一网络空间。如下图所示:

2.5 istio-proxy 和 envoy 关系

envoy 其实本质与 nginx 和 haproxy 一样,都属于网络代理服务器,运行时则是一个进程。envoy 在架构设计上也采用了类似 nginx 的设计模式(多线程、非阻塞、异步IO),后面的课程我会详细讲解。

2.6 istio-proxy 和 kube-proxy 关系

从表现形式上说,istio-proxy 是容器(运行在 pod 内),kube-proxy 是 pod (资源类型是 daemonset)。

从处理网络流量角度来说,istio-proxy 和 kube-proxy 本质上都是通过 iptables/netfilter 来处理网络流量。只不过 istio-proxy 和 kube-proxy 活动在不同的网络空间。istio-proxy 位于 pod 网络空间,处理的是 pod 内的网络流量,而 kube-proxy 位于宿主机网络空间,处理的是宿主机内网络流量(因为 kube-proxy 是 daemonset,因此它位于 k8s 集群的每个 node 节点上)。

2.7 envoy 进程服务端口

上面我们介绍了 envoy 是运行在 istio-proxy 容器内的一个进程,改进程的作用是管理网络流量(类比 nginx),下图展示 envoy 进程开启的网络端口,网络流量可以通过端口进入到 envoy 进程内部。网络流量、网络端口和 envoy 进程的关系就像风、窗户和房屋的关系一样,风(网络流量)通过窗口(网络端口)进入到房屋(envoy),一个房屋(envoy)可以不止一个窗户(网络端口)。

自此,九析带你轻松完爆了 istio 的注入以及对平台生态的影响。下章节将继续介绍 istio 注入后对网络流量的流向的改变。

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:以FPGA机载为核心的实时视频图形处理系统设计
下一篇:Java线程池必知必会知识点总结
相关文章

 发表评论

暂时没有评论,来抢沙发吧~