我们知道在服务网格集群中的每个工作负载实例上都会透明地注入一个Istiosidecar代理，这个代理拦截负载的出入流量，并根据配置完成相应的流量管理，包括流量、安全、可观测性等等。为了更加细粒度的控制代理的行为，从1.1版本开始Istio便引入了和服务网格数据面Sidecar同名的SidecarCRD资源对象，控制负载上的出入流量以及课访问的目标服务等。

Sidecar对象描述了sidecar代理的配置，sidecar代理管理与其连接的工作负载的inbound和outbound流量。默认情况下，Istio将为网格中的所有sidecar代理服务，使其具有到达网格中每个工作负载所需的必要配置，并在与工作负载关联的所有端口上接收流量。Sidecar资源提供了一种的方法，在向工作负载转发流量或从工作负载转发流量时，微调端口集合和代理将接收的协议，此外，可以限制代理在从工作负载转发outbound流量时可以达到的服务集合。

比如我们可以创建一个如下所示的Sidecar对象：

apiVersion:working.istio.io/v1beta1kind:Sidecarmetadata:name:test-scspec:egress:-hosts:-"istio-system/*"-"default/*"

在上面的Sidecar对象中我们指定了egress字段，这个字段用于指定sidecar代理的出口流量，其中hosts字段用于指定sidecar代理可以访问的目标服务，这里我们指定了istio-system/*和default/*，意思是我们可以控制default命名空间下的sidecar代理只可以访问istio-system和default命名空间下的服务，其他命名空间下的服务则无法访问。

整体上Sidecar对象的核心包括四个字段：workloadSelector、ingress与egress、outboundTrafficPolicy。

Sidecar对象可以定义在根命名空间istio-system下，这样就会应用到所有命名空间下的工作负载上，比如我们可以创建一个如下所示的Sidecar对象：

#global-sidecar.yamlapiVersion:networking.istio.io/v1beta1kind:Sidecarmetadata:name:defaultnamespace:istio-systemspec:egress:-hosts:-"./*"

上面的这个Sidecar对象定义在istio-system命名空间下，这样就会应用到所有命名空间下的工作负载上，其中egress字段中的hosts字段指定了可以访问的服务，这里我们指定了"./*"，表示限制整个服务网格中的服务只能访问本命名空间的服务。在实践中我们推荐使用这种方式在全局范围定义一个统一的Sidecar规则，然后在特定的命名空间下再定义一个Sidecar对象来覆盖全局的Sidecar规则。

比如我们可以在default命名空间下创建一个如下所示的Sidecar对象来覆盖上面全局的这个对象：

#default-sidecar.yamlapiVersion:networking.istio.io/v1beta1kind:Sidecarmetadata:name:defaultnamespace:defaultspec:egress:-hosts:-"foo/*"

这个对象就允许default命名空间的服务可以访问foo命名空间的服务。

同样我们还可以使用workloadSelector字段来指定sidecar代理所属的工作负载，比如我们可以创建一个如下所示的Sidecar对象：

#default-sidecar.yamlapiVersion:networking.istio.io/v1beta1kind:Sidecarmetadata:name:defaultnamespace:defaultspec:workloadSelector:labels::baregress:-hosts:-"bar/foo-api"

上面的这个对象只会应用到app:bar标签的工作负载上，并覆盖以上命名空间级别的规则，使得default命名空间下面的app:bar标签的工作负载只能访问bar命名空间下面的foo-api服务。

接下来我们使用sleep和httpbin应用来进行测试说明，将这两个应用部署到default和other两个命名空间下面：

kubectlcreatensotherkubectllabelnsotheristio-injectinotallow=enabledkubectlapply-fsamples/sleep/sleep.yaml-ndefaultkubectlapply-fsamples/sleep/sleep.yaml-notherkubectlapply-fsamples/httpbin/httpbin.yaml-ndefaultkubectlapply-fsamples/httpbin/httpbin.yaml-nother

默认情况下，注入了Istio的工作负载会进行全网格的传播，假设default和other两个不相干的命名空间，other中有大量的服务，而default中只有几个，因为路由传播的关系，default命名空间中的工作负载，其sidecar代理中也会带上other命名空间中的路由信息。例如：

$istioctlproxy-configclusterssleep-9454cc476-jfw97|grepotherhttpbin.other.svc.cluster.local8000-outboundEDSsleep.other.svc.cluster.local80-outboundEDS

可以看到，在default命名空间中的Pod，保存了其它命名空间中的路由信息。这不管是对内存消耗还是路由控制来说，都会造成一定浪费，这个时候我们就可以定义一个Sidecar资源，限制sleep服务只访问同一命名空间的其他服务，如下所示：

#sleep-sidecar.yamlapiVersion:networking.istio.io/v1alpha3kind:Sidecarmetadata:name:sleepspec:workloadSelector:labels:app:sleepegress:-hosts:-"default/*"

直接应用上面的资源对象即可：

$kubectlapply-fsleep-sidecar.yaml$kubectlgetsidecarNAMEAGEsleep16s

这个时候可以看到在sleep应用中只剩下了本命名空间之内的服务了：

$istioctlproxy-configclusterssleep-9454cc476-jfw97SERVICEFQDNPORTSUBSETDIRECTIONTYPEDESTINATIONRULE80-inboundORIGINAL_DSTBlackHoleCluster---STATICInboundPassthroughClusterIpv4---ORIGINAL_DSTPassthroughCluster---ORIGINAL_DSTagent---STATIChttpbin.default.svc.cluster.local8000-outboundEDSkubernetes.default.svc.cluster.local443-outboundEDSprometheus_stats---STATICsds-grpc---STATICsleep.default.svc.cluster.local80-outboundEDSxds-grpc---STATICzipkin---STRICT_

现在我们可以在sleep应用中去访问下httpbin的应用：

$kubectlexec-itsleep-9454cc476-jfw97--curl{"origin":"127.0.0.6"}

可以看到default命名空间下面的应用可以正常访问，那么对于other命名空间下面的服务正常就不能访问了。

$kubectlexec-itsleep-9454cc476-jfw97--curl

 可以看到default命名空间下面的应用无法访问other命名空间下面的服务了。


 Istio默认情况下，服务网格内部的所有数据面代理都通过xDS从控制面获取全量的配置，这种方式在数据面代理数量较少的情况下是没有问题的，但是当数据面代理数量较多的大规模服务网格的场景下，这种方式显然会造成性能问题，全量的配置会引起数据面代理的内存暴涨，所以Sidecar对象是非常有必要的，通过Sidecar对象只维护少量依赖服务的配置，可以大大减少无用的内存消耗，所以在生产环境中我们推荐大家使用Sidecar对象来控制数据面代理的配置。



 人生若如初见全集资源有吗


 资源链接发出来了，时间不长易被取消！网页链接你再点应该就没用了。
  
  一定要尽快保存，如果有用的，帮我点赞，采纳一下，谢谢～


 求我有一个剑修前夫百度云，谢谢


 网页链接网格中的每个pod必须运行与istio兼容的sidecar。
  
  以下部分介绍了将istio sidecar注入到一个pod的两种方法：手动使用istioctl cli工具或自动使用istio初始化程序。
  
  请注意，sidecar不涉及同一pod内的容器之间的通信。