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 用于设置 iptables 规则，以便将入站/出站流量通过 sidecar 代理。初始化容器与应用程序容器在以下方面有所不同：

• 它在启动应用容器之前运行，并一直运行直至完成。
• 如果有多个初始化容器，则每个容器都应在启动下一个容器之前成功完成。

因此，您可以看到，对于不需要成为实际应用容器一部分的设置或初始化作业来说，这种容器是多么的完美。在这种情况下，istio-init 就是这样做并设置了 iptables 规则。

istio-proxy 这个容器是真正的 sidecar 代理（基于 envoy）。
下面的内容描述了向 pod 中注入 istio sidecar 的两种方法：使用 手动注入或启用 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