概念及示例
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