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/