Istio Sidecar

概念及示例

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	Criteria used to select the specific set of pods/VMs on which this Sidecar configuration should be applied. If omitted, the Sidecar configuration will be applied to all workload instances in the same namespace.	No
ingress	IstioIngressListener[]	Ingress specifies the configuration of the sidecar for processing inbound traffic to the attached workload instance. If omitted, Istio will automatically configure the sidecar based on the information about the workload obtained from the orchestration platform (e.g., exposed ports, services, etc.). If specified, inbound ports are configured if and only if the workload instance is associated with a service.	No
egress	IstioEgressListener[]	Egress specifies the configuration of the sidecar for processing outbound traffic from the attached workload instance to other services in the mesh.	Yes
outboundTrafficPolicy	OutboundTrafficPolicy	This allows to configure the outbound traffic policy. If your application uses one or more external services that are not known apriori, setting the policy to ALLOW_ANY will cause the sidecars to route any unknown traffic originating from the application to its requested destination.	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

https://preliminary.istio.io/zh/docs/setup/additional-setup/sidecar-injection/#automatic-sidecar-injection

https://preliminary.istio.io/zh/blog/2019/data-plane-setup/