使用 Sidecar CRD 優化 Istio 性能
我們知道在服務網格集群中的每個工作負載實例上都會透明地注入一個 Istio sidecar 代理，這個代理攔截負載的出入流量，并根據配置完成相應的流量管理，包括流量、安全、可觀測性等等。為了更加細粒度的控制代理的行為，從 1.1 版本開始 Istio 便引入了和服務網格數據面 Sidecar 同名的 Sidecar CRD 資源對象，控制負載上的出入流量以及課訪問的目標服務等。
Sidecar 對象描述了 sidecar 代理的配置，sidecar 代理管理與其連接的工作負載的 inbound 和 outbound 流量。默認情況下，Istio 將為網格中的所有 sidecar 代理服務，使其具有到達網格中每個工作負載所需的必要配置，并在與工作負載關聯的所有端口上接收流量。Sidecar 資源提供了一種的方法，在向工作負載轉發流量或從工作負載轉發流量時，微調端口集合和代理將接收的協議，此外，可以限制代理在從工作負載轉發 outbound 流量時可以達到的服務集合。
比如我們可以創建一個如下所示的 Sidecar 對象：
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
name: test-sc
spec:
egress:
- hosts:
- "istio-system/*"
- "default/*"在上面的 Sidecar 對象中我們指定了 egress 字段，這個字段用于指定 sidecar 代理的出口流量，其中 hosts 字段用于指定 sidecar 代理可以訪問的目標服務，這里我們指定了 istio-system/* 和 default/*，意思是我們可以控制 default 命名空間下的 sidecar 代理只可以訪問 istio-system 和 default 命名空間下的服務，其他命名空間下的服務則無法訪問。
整體上 Sidecar 對象的核心包括四個字段：workloadSelector、ingress 與 egress、outboundTrafficPolicy。
- workloadSelector：這個字段用來指定 sidecar 代理所屬的工作負載，可以通過標簽來指定，如果沒有指定則會應用到當前命名空間下所有的工作負載上（每個命名空間下只能定義一個全局的 Sidecar 對象），如果定義在根命名空間 istio-system 下則會應用到所有命名空間下的工作負載上。需要注意的是如果一個命名空間下存在多個 workloadSelector 的 Sidecar 選中同樣的負載，則也會出現問題，所有要注意避免這種情況。
- egress：這個字段用來配置 sidecar 代理對服務網格內部其他服務的訪問，如果沒有配置則默認命名空間下的所有服務都可以訪問，如果配置了則只能訪問配置的服務。該字段下面可以配置如下幾個參數：
- hosts：這是一個必選的字段，表示監聽器對應的服務地址，格式為 <namespace>/<FQDN>，可以對 namespace、FQDN 進行通配符匹配，比如 default/* 表示 default 命名空間下的所有服務，*/foo 表示所有命名空間下的 foo 服務，*/* 表示允許目標是任意命名空間下的任意服務，~/* 表示禁止目標是任意命名空間下的任意服務。
- port：監聽器關聯的端口。
- bind：監聽器綁定的地址。
- captureMode：配置流量捕獲模式，可以是 DEFAULT、IPTABLES、NONE 三種模式，默認是 DEFAULT，DEFAULT 模式表示使用環境默認的流量捕獲規則；IPTABLES 模式表示基于 iptables 規則轉發的流量，NONE 模式表示沒有流量攔截。
- ingress：這個字段用來配置 sidecar 代理對應工作負載的入流量控制。該字段下面可以配置如下幾個參數：
port：這是一個必選的字段，表示監聽器對應的端口。
bind：監聽器綁定的地址。
captureMode：配置流量捕獲模式，與 egress 中的 captureMode 字段一樣。
defaultEndpoint：也是必選字段，表示流量的轉發目標地址，比如 127.0.0.1:port 或者 0.0.0.0:port。
outboundTrafficPolicy：這個字段用來配置 sidecar 代理對應工作負載的出流量控制，該字段有兩種訪問配置：
ALLOW_ANY：表示允許訪問任意服務，sidecar 代理在攔截到這個出流量后，會直接透傳。
REGISTRY_ONLY：sidecar 代理會攔截所有的出口流量，只允許服務網格內部服務可以被訪問，對于外部服務需要使用 ServiceEntry 注冊才可以被訪問。
Sidecar 對象可以定義在根命名空間 istio-system 下，這樣就會應用到所有命名空間下的工作負載上，比如我們可以創建一個如下所示的 Sidecar 對象：
# global-sidecar.yaml
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
name: default
namespace: istio-system
spec:
egress:
- hosts:
- "./*"上面的這個 Sidecar 對象定義在 istio-system 命名空間下，這樣就會應用到所有命名空間下的工作負載上，其中 egress 字段中的 hosts 字段指定了可以訪問的服務，這里我們指定了 "./*"，表示限制整個服務網格中的服務只能訪問本命名空間的服務。在實踐中我們推薦使用這種方式在全局范圍定義一個統一的 Sidecar 規則，然后在特定的命名空間下再定義一個 Sidecar 對象來覆蓋全局的 Sidecar 規則。
比如我們可以在 default 命名空間下創建一個如下所示的 Sidecar 對象來覆蓋上面全局的這個對象：
# default-sidecar.yaml
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
name: default
namespace: default
spec:
egress:
- hosts:
- "foo/*"這個對象就允許 default 命名空間的服務可以訪問 foo 命名空間的服務。
同樣我們還可以使用 workloadSelector 字段來指定 sidecar 代理所屬的工作負載，比如我們可以創建一個如下所示的 Sidecar 對象：
# default-sidecar.yaml
apiVersion: networking.istio.io/v1beta1
kind: Sidecar
metadata:
name: default
namespace: default
spec:
workloadSelector:
labels:
app: bar
egress:
- hosts:
- "bar/foo-api"上面的這個對象只會應用到 app: bar 標簽的工作負載上，并覆蓋以上命名空間級別的規則，使得 default 命名空間下面的 app: bar 標簽的工作負載只能訪問 bar 命名空間下面的 foo-api 服務。
接下來我們使用 sleep 和 httpbin 應用來進行測試說明，將這兩個應用部署到 default 和 other 兩個命名空間下面：
kubectl create ns other
kubectl label ns other istio-injectinotallow=enabled
kubectl apply -f samples/sleep/sleep.yaml -n default
kubectl apply -f samples/sleep/sleep.yaml -n other
kubectl apply -f samples/httpbin/httpbin.yaml -n default
kubectl apply -f samples/httpbin/httpbin.yaml -n other默認情況下，注入了 Istio 的工作負載會進行全網格的傳播，假設 default 和 other 兩個不相干的命名空間，other 中有大量的服務，而 default 中只有幾個，因為路由傳播的關系，default 命名空間中的工作負載，其 sidecar 代理中也會帶上 other 命名空間中的路由信息。例如：
$ istioctl proxy-config clusters sleep-9454cc476-jfw97 |grep other
httpbin.other.svc.cluster.local 8000 - outbound EDS
sleep.other.svc.cluster.local 80 - outbound EDS可以看到，在 default 命名空間中的 Pod，保存了其它命名空間中的路由信息。這不管是對內存消耗還是路由控制來說，都會造成一定浪費，這個時候我們就可以定義一個 Sidecar 資源，限制 sleep 服務只訪問同一命名空間的其他服務，如下所示：
# sleep-sidecar.yaml
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
name: sleep
spec:
workloadSelector:
labels:
app: sleep
egress:
- hosts:
- "default/*"直接應用上面的資源對象即可：
$ kubectl apply -f sleep-sidecar.yaml
$ kubectl get sidecar
NAME AGE
sleep 16s這個時候可以看到在 sleep 應用中只剩下了本命名空間之內的服務了：
$ istioctl proxy-config clusters sleep-9454cc476-jfw97
SERVICE FQDN PORT SUBSET DIRECTION TYPE DESTINATION RULE
80 - inbound ORIGINAL_DST
BlackHoleCluster - - - STATIC
InboundPassthroughClusterIpv4 - - - ORIGINAL_DST
PassthroughCluster - - - ORIGINAL_DST
agent - - - STATIC
httpbin.default.svc.cluster.local 8000 - outbound EDS
kubernetes.default.svc.cluster.local 443 - outbound EDS
prometheus_stats - - - STATIC
sds-grpc - - - STATIC
sleep.default.svc.cluster.local 80 - outbound EDS
xds-grpc - - - STATIC
zipkin - - - STRICT_DNS現在我們可以在 sleep 應用中去訪問下 httpbin 的應用：
$ kubectl exec -it sleep-9454cc476-jfw97 -- curl http://httpbin.default:8000/ip
{
"origin": "127.0.0.6"
}可以看到 default 命名空間下面的應用可以正常訪問，那么對于 other 命名空間下面的服務正常就不能訪問了。
$ kubectl exec -it sleep-9454cc476-jfw97 -- curl http://httpbin.other.svc.cluster.local:8000/ip可以看到 default 命名空間下面的應用無法訪問 other 命名空間下面的服務了。
Istio 默認情況下，服務網格內部的所有數據面代理都通過 xDS 從控制面獲取全量的配置，這種方式在數據面代理數量較少的情況下是沒有問題的，但是當數據面代理數量較多的大規模服務網格的場景下，這種方式顯然會造成性能問題，全量的配置會引起數據面代理的內存暴漲，所以 Sidecar 對象是非常有必要的，通過 Sidecar 對象只維護少量依賴服務的配置，可以大大減少無用的內存消耗，所以在生產環境中我們推薦大家使用 Sidecar 對象來控制數據面代理的配置。
