边车 — 不改代码就改变网络的办法
一句话总结
服务消息不是新的网络，而是在每个平板电脑上安装一台代理，并在中央设置该代理的结构。
为什么需要这个？
创建了大约十个麦克服务后，无论哪个团队都会重复出现相同的代码。重试、超时、电路断路器、TLS证书加载、对方验证、请求日志、跟踪头传播。如果服务分散在Java、Go、Python、Node上，就需要实现这四个列表，四个实现的行为有微妙的差异。要更改一个超时默认值，需要在四个存储库上发布PR，并部署四次。
消息的想法很简单。**把共同的兴趣点从应用程序流程中拿出来，让同一进程中的代理来代替处理。**应用程序仍然http://reviews:9080虽然发送了平文请求，但实际上将该请求传递给对方是代理。因此，打开mTLS不是应用程序部署，而是应用一个设置资源。
怎么行动
Istio分为两层。控制平面（istiod）和数据平面（每个端点的Envoy）。istiod是将Pilot、Citadel、Galley合并为1.5的单二进制，1.8中完全移除了拦截请求路径的Mixer。也就是说，**在处理一个请求时，不会向控制平面询问。**即使istiod死亡，已经接受设置的Envoy也会继续以最后设置发送流量。
设置通过名为xDS的gRPC流进行。
| API | 运送什么 | Istio 侧输入 |
|---|---|---|
| LDS | 监听器（端口，协议） | 端口名称，Gateway |
| RDS | HTTP 路由规则 | VirtualService |
| CDS | 上游群集 | DestinationRule |
| EDS | 集群的实际端点 | Kubernetes Endpoints |
| SDS | TLS证书和密钥 | istiod CA |
Istio将这一切都合并成一个名为ADS的流发送出去。这是为了防止端点比群集定义先到达，从而瞬间破坏设置。
注入由容器管理的MutatingAdmissionWebhook进行。在命名空间中istio-injection=enabled如果贴有标签，在那个命名空间中帕德生成的瞬间istiod会修改帕德规格，然后将两个容器放在一起。
istio-init（初始化容器）：istio-iptables执行并播种REDIRECT规则。入站流量为15006，出站流量为15001。只有以UID 1337出去的流量例外，因为那是代理本身。如果没有这个例外，就会陷入无限循环。istio-proxy（侧卡）：Envoy和istio-agent一起运行的容器。在15090上暴露Prometheus指标，在15021上暴露健康检查。
这里有一个经常发生事故的分店。**标签只有在创建护盾时才有效。**已经漂浮着的护盾不会发生任何事情，所以贴上标签后，必须拉动展开，再重新创建护盾才能进入侧翼卡。“贴上标签了，为什么不进入梅西”的答案有九个。
在现场相遇的样子
**第一，从账单上看侧卡的价格。**每台板大约增加100MB左右的内存和启动时间几秒钟。如果板有100个，就10GB了。所以没有侧卡的情况下，节点单位ztunnel负责L4，命名空间单位waypoint负责L7的Ambient模式出现了，甚至选择完全不同的方向eBPF数据通道（Cilium之类）甚至取消kube-proxy的配置也变得常见。引入消息意味着应该可以回答“支付这个费用买什么”。
**第二，升级是重新启动。**要上传侧卡版本，必须重新创建所有板块。在数千个板块群集中，这需要几个小时的工作，所以消息升级计划中必须包括部署顺序和窗口时间。
第三，istioctl kube-inject是WebHook的线下版。在WebHook生成Pad时，提前在Manifest文件中应用所做的事情，显示结果。在想用GitOps固定注入结果时，以及像现在这样想用眼睛确认注入结果的解剖时使用。
下次实习要做的事情
istioctl manifest generate制作安装文件，检查包含的内容，然后将消息API类型（CRD）注册到群集中。mesh-lab在注入标签，legacy不粘在上面，做对比群。然后在图像工作负载上istioctl kube-inject将容器数量和初始化容器的作用用JSON整理出来。
有两件事需要提前说明。在这个实践环境中，真正的Envoy不会处理流量。Pad会变成Running，但数据包不会流畅，kubectl exec我也没有转发。所以这个课程的评分全部是撰写宣言书。istioctl analyze/validate看静态验证。实际握手和指标通过阅读和测验来处理。判断设置是否正确的眼光也可以通过这种方式充分培养，在实际工作中，一半的思维不是来自数据包，而是来自设置。