概念及示例
Sidecar描述了sidecar代理的配置。默认情况下，Istio 让每个 Envoy 代理都可以访问来自和它关联的工作负载的所有端口的请求，然后转发到对应的工作负载。您可以使用 sidecar 配置去做下面的事情：
- 微调 Envoy 代理接受的端口和协议集。
- 限制 Envoy 代理可以访问的服务集合。
您可能希望在较庞大的应用程序中限制这样的 sidecar 可达性，配置每个代理能访问网格中的任意服务可能会因为高内存使用量而影响网格的性能。
您可以指定将 sidecar 配置应用于特定命名空间中的所有工作负载，或者使用 workloadSelector 选择特定的工作负载。例如，下面的 sidecar 配置将 bookinfo 命名空间中的所有服务配置为仅能访问运行在相同命名空间和 Istio 控制平面中的服务。
每个名称空间只能有一个没有任何配置
workloadSelector的Sidecar配置 ， 如果Sidecar给定名称空间中存在多个不使用选择器的配置，则系统的行为是不确定的。
下面声明的Sidecar在根名称空间中声明了全局默认配置istio-config，该配置在所有名称空间中配置了sidecar，以仅允许将流量发送到同一名称空间中的其他工作负载以及该名称空间中的服务istio-system。
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
name: default
namespace: `istio-config`
spec:
egress:
- hosts:
- "./*"
- "istio-system/*"
下面声明的Sidecar在配置prod-us1 命名空间覆盖全局默认以上定义，使出口流量到公共服务中prod-us1，prod-apis和istio-system 命名空间。
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
name: default
namespace: prod-us1
spec:
egress:
- hosts:
- "prod-us1/*"
- "prod-apis/*"
- "istio-system/*"
下面的示例Sidecar在prod-us1名称空间中声明一个配置，该配置接受端口9080上的入站HTTP通信并将其转发到侦听Unix域套接字的附加工作负载实例。在出口方向上，除了istio-system名称空间外，Sidecar仅代理绑定到端口9080的HTTP流量，以用于prod-us1名称空间中的服务
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
name: default
namespace: prod-us1
spec:
ingress:
- port:
number: 9080
protocol: HTTP
name: somename
defaultEndpoint: unix:///var/run/someuds.sock
egress:
- port:
number: 9080
protocol: HTTP
name: egresshttp
hosts:
- "prod-us1/*"
- hosts:
- "istio-system/*"
Sidecar配置
| Field | Type | Description | Required |
|---|---|---|---|
| workloadSelector | WorkloadSelector | 表示工作负载的选择器，Sidecar 的配置可以使用 workloadSelector 应用到命名空间下的一个或多个负载，如果未配置 workloadSelector，则应用到整个命名空间。每个命名空间都只能定义一个没有 workloadSelector 的 Sidecar，表示对命名空间的全局配置 | No |
| ingress | IstioIngressListener[] | IstioIngressListener 类型，配置 Sidecar 对于的工作负载的 Inbound 流量。 | No |
| egress | IstioEgressListener[] | 是一种 istioEgressListener 类型，可用来配置 Sidecar 对网络内其他服务的访问，如果没有配置，则只要命名空间可见，命名空间里的服务就都可以被访问。 | Yes |
| outboundTrafficPolicy | OutboundTrafficPolicy | 允许配置出站流量策略 | No |
WorkloadSelector配置
WorkloadSelector指定的标准来确定是否Gateway， Sidecar或EnvoyFilter配置可被应用到一个代理。匹配条件包括与代理关联的元数据，工作负载实例信息或代理在初始握手期间提供给Istio的任何其他信息。如果指定了多个条件，则必须匹配所有条件才能选择工作负载实例。当前，仅支持基于标签的选择机制。
| Field | Type | Description | Required |
|---|---|---|---|
labels |
map |
一个或多个标签，指示Sidecar应在其上应用此配置的一组特定的Pod / VM 。标签搜索的范围仅限于存在资源的配置名称空间。 |
Yes |
Sidecar Injection
简单来说，Sidecar 注入会将额外容器的配置添加到 Pod 模板中。Istio 服务网格目前所需的容器有：
istio-init init 容器用于设置 iptables 规则，以便将入站/出站流量通过 sidecar 代理。初始化容器与应用程序容器在以下方面有所不同：
- 它在启动应用容器之前运行，并一直运行直至完成。
- 如果有多个初始化容器，则每个容器都应在启动下一个容器之前成功完成。
因此，您可以看到，对于不需要成为实际应用容器一部分的设置或初始化作业来说，这种容器是多么的完美。在这种情况下，istio-init 就是这样做并设置了 iptables 规则。
istio-proxy 这个容器是真正的 sidecar 代理（基于 Envoy）。
下面的内容描述了向 pod 中注入 Istio sidecar 的两种方法：使用 istioctl 手动注入或启用 pod 所属命名空间的 Istio sidecar 注入器自动注入。
手动注入直接修改配置，如 deployment，并将代理配置注入其中。
当 pod 所属namespace启用自动注入后，自动注入器会使用准入控制器在创建 Pod 时自动注入代理配置。
通过应用 istio-sidecar-injector ConfigMap 中定义的模版进行注入。
自动注入 sidecar
当你在一个namespace中设置了 istio-injection=enabled 标签，且 injection webhook 被启用后，任何新的 pod 都有将在创建时自动添加 sidecar. 请注意，区别于手动注入，自动注入发生在 pod 层面。你将看不到 deployment 本身有任何更改 。
kubectl label namespace xxx istio-inhection=enabled
手动注入 sidecar
手动注入 deployment ，需要使用 使用 istioctl kube-inject
istioctl kube-inject -f samples/sleep/sleep.yaml | kubectl apply -f -
默认情况下将使用集群内的配置，或者使用该配置的本地副本来完成注入。
kubectl -n istio-system get configmap istio-sidecar-injector -o=jsonpath='{.data.config}' > inject-config.yaml
kubectl -n istio-system get configmap istio-sidecar-injector -o=jsonpath='{.data.values}' > inject-values.yaml
kubectl -n istio-system get configmap istio -o=jsonpath='{.data.mesh}' > mesh-config.yaml
指定输入文件，运行 kube-inject 并部署
istioctl kube-inject
--injectConfigFile inject-config.yaml
--meshConfigFile mesh-config.yaml
--valuesFile inject-values.yaml
--filename samples/sleep/sleep.yaml
| kubectl apply -f -
验证 sidecar 已经被注入到 READY 列下 2/2 的 sleep pod 中
kubectl get pod -l app=sleep
NAME READY STATUS RESTARTS AGE
sleep-64c6f57bc8-f5n4x 2/2 Running 0 24s
卸载 sidecar 自动注入器
kubectl delete mutatingwebhookconfiguration istio-sidecar-injector
kubectl -n istio-system delete service istio-sidecar-injector
kubectl -n istio-system delete deployment istio-sidecar-injector
kubectl -n istio-system delete serviceaccount istio-sidecar-injector-service-account
kubectl delete clusterrole istio-sidecar-injector-istio-system
kubectl delete clusterrolebinding istio-sidecar-injector-admin-role-binding-istio-system
上面的命令不会从 pod 中移除注入的 sidecar。需要进行滚动更新或者直接删除对应的pod，并强制 deployment 重新创建新pod。
参考文献
https://preliminary.istio.io/zh/docs/reference/config/networking/sidecar/#Sidecar