なぜ書いているのか？

Istioをドキュメントを読んだり、動かしてみたりしていました。

しかし、タイトルに記載したSidecarリソースについてはいまいち理解できていませんでした。

個人的に抱えているこのモヤモヤをなくすためにIstioのSidecarリソースについて理解したことを書いていこうと思います。

IstioのSidecarリソースはいったい何者なのか

Istioの1.1にリリースされたカスタムリソースです。

ドキュメントには下記のように記載されています。

Sidecar describes the configuration of the sidecar proxy that mediates inbound and outbound communication to the workload instance it is attached to.

The Sidecar configuration provides a way to fine tune the set of ports, protocols that the proxy will accept when forwarding traffic to and from the workload. In addition, it is possible to restrict the set of services that the proxy can reach when forwarding outbound traffic from workload instances.

https://istio.io/latest/docs/reference/config/networking/sidecar/より抜粋

Fine-tune the set of ports and protocols that an Envoy proxy accepts.

Limit the set of services that the Envoy proxy can reach.

You can specify that you want a sidecar configuration to apply to all workloads in a particular namespace, or choose specific workloads using a workloadSelector.

https://istio.io/latest/docs/concepts/traffic-management/#sidecarsより抜粋

デフォルトの状態でアプリケーションをデプロイするとistio proxyはメッシュ内のすべてのワークロードと通信できるように設定を持ちます。

このSidecarリソースは、istio proxyが持つ通信の設定を調整したりすることができるリソースです。

例えば、ある特定のNamespaceにデプロイされているPodはそのNamespace内の他のPodとしか通信を行わないのに

デフォルトのままだと他のNamespaceと通信できるようにistio proxyに設定が注入されてしまいます。

セキュリティ面や後述するistio proxyのリソースの面でもSidecarリソースを使うことによって通信できる範囲を絞ることができます。

このあたりは実際にデプロイされているistio proxyの設定を確認したほうが見たほうがよさそうです。

しかし、設定をどう見るかについはEnvoyを少し知る必要があったので、少し整理してみたいと思います。

Envoyをざっくり理解する

ここではEnvoyが何者なのかは割愛しますが、istio proxyの設定を見るためにEnvoyで出てくる用語などについて書きます。

主な用語

downstream：Envoyに接続する。 Envoyをプロキシとしたサイドカーアプリケーションがデプロイされている場合

リクエストを送るクライアントがダウンストリームにあたる。レスポンスを返すサイドカーアプリケーションがダウンストリームにあたる。

upstream : Envoyが受け取ったリクエストを転送する先を指す。 Envoyをプロキシとしたサイドカーアプリケーションがデプロイされている場合

Envoyがクラアントから受け取ったリクエストを転送する先であるサイドカーアプリケーションがアップストリームにあたる。 Envoyがサイドカーアプリケーションから受け取ったレスポンスを転送する先であるクライアントがアップストリームにあたる。

listener : Envoyがダウンストリームからの接続を受け入れるためのIPやポートなどの情報。

cluster : Envoyがアップストリームへ接続するため（転送するため）のエンドポイントのグループ

endpoint : クラスタが持つエンドポイントグループの1つ。クラスタとは親子関係になる。

router: Envoyが受け取ったリクエストをどのクラスタを選択してアップストリームに転送するかを決める経路情報。 HTTPヘッダで転送先を切り替えたり、リクエストのリトライの回数を制御したり、パーセンテージをベースにしたトラフィックの分割、優先順位ベースのルーティング、、、などルートで設定できることは多岐にわたります。

Envoyがリクエストを受け取る情報はリスナーで管理され、そのリクエストを転送するための情報がクラスタで管理されている形になります。 routerによってリスナーとクラスタが紐づき、ダウンストリームからアップストリームへと転送できるようになります。

参考 :

https://www.envoyproxy.io/docs/envoy/latest/intro/life_of_a_request

EnvoyのxDSについて

Envoyは静的にも、動的にも設定を適用することができますが、ここではIstioが採用している形式に合わせて動的な設定にフォーカスします。

Envoyはファイルシステムによる設定変更やREST APIや、gRPCなど様々な手段で設定を変更することができますが、

特にREST APIやgRPCによる設定変更では、Envoyが管理サーバーに問い合わせて動的に設定を受け取り更新します。

この設定を提供するサービスとAPIをまとめてxDSと呼ばれています。

xには用語で説明したclusterやlistenerがあてはまります。

LDS(Listener Discovery Service) : Listenerの設定を受け取るためのサービス

CDS(Cluster Discovery Servide) : Clusterの設定を受け取るためのサービス

EDS(Endpoint Discovery Service) : Endpointの設定を受け取るためのサービス

RDS(Route Discovery Service) : Routeの設定を受け取るためのサービス

（ADSやSDSは省略しています。）

設定を提供するAPIのサーバーをコントロールプレーンと呼び、問い合せるEnvoyプロキシをデータプレーンと呼びます。

Istioのコントロールプレーン内のPilotというコンポーネントがまさにIstio Proxyの設定を提供していますね。

Istio Proxyの設定を見てみる

Envoyについてざっくりと確認したため実際にIstio Proxyにはどんな設定されているか見てみたいと思います。

例として Namespace foo と bar にそれぞれdeployment（Pod1台）をapplyしてみます。

(それぞれのNamespaceにデプロイされたPod間での内部通信する要件はないとします。)

Namespace.yaml

apiVersion: v1
kind: Namespace
metadata:
  name: foo
  labels:
    istio-injection: enabled
---
apiVersion: v1
kind: Namespace
metadata:
  name: bar
  labels:
    istio-injection: enabled

Deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-app
  namespace: foo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test-app
  template:
    metadata:
      labels:
        app: test-app
    spec:
      containers:
        - name: test-app
          image: test-app
          ports:
            - containerPort: 80
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: test-app
  namespace: bar
spec:
  replicas: 1
  selector:
    matchLabels:
      app: test-app
  template:
    metadata:
      labels:
        app: test-app
    spec:
      containers:
        - name: test-app
          image: test-app
          ports:
            - containerPort: 80

Service.yaml

apiVersion: v1
kind: Service
metadata:
  name: foo
  namespace: foo
spec:
  selector:
    app: test-app
  ports:
    - port: 80
      targetPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: bar
  namespace: bar
spec:
  selector:
    app: test-app
  ports:
    - port: 80
      targetPort: 80

これでIngressの設定次第などでは、Port 80で通信できるような構成になりました。

NamespaceとDeploymentをapplyしたので、istio-proxyの設定を確認してみたいと思います。

Istioにはデバッグ目的も含めproxyのステータスを確認するコマンドが用意されています。

% istioctl proxy-status

NAME                                                   CDS        LDS        EDS        RDS          ISTIOD                     VERSION
istio-ingressgateway-7576658c9b-gqrgh.istio-system     SYNCED     SYNCED     SYNCED     NOT SENT     istiod-c85d85ddd-6nfmg     1.8.1
test-app-9dfd8f5-58t4d.foo                             SYNCED     SYNCED     SYNCED     SYNCED       istiod-c85d85ddd-6nfmg     1.8.1
test-app-9dfd8f5-x9m2q.bar                             SYNCED     SYNCED     SYNCED     SYNCED       istiod-c85d85ddd-6nfmg     1.8.1

前述のEnvoyのxDSに沿ってそれぞれのステータスが記載されています。

test-appのistio-proxyはどのサービスディスカバリでも SYNCED になっているためistio-proxyは正常にinjectされているようです。

ちなみにステータスの状態は3種類存在します。

SYNCED : Istiodが最後に送った情報をistio-proxyが受け取り、確認応答を返した状態

NOT SENT : 送信するべき設定がなく、Istiodが何も送ってないことを示す状態

STALE : Istiodが送った設定の確認応答が返ってきていない状態

istio-proxyが正常に動いていることを確認することができたため、各設定も確認していこうと思います。

Listener

 % istioctl proxy-config listener test-app-9dfd8f5-58t4d.foo
ADDRESS      PORT  MATCH                                                               DESTINATION
10.68.0.10   53    ALL                                                                 Cluster: outbound|53||kube-dns.kube-system.svc.cluster.local
0.0.0.0      80    Trans: raw_buffer; App: HTTP                                        Route: 80
0.0.0.0      80    ALL                                                                 PassthroughCluster
10.68.13.187 80    Trans: raw_buffer; App: HTTP                                        Route: bar.bar.svc.cluster.local:80
10.68.13.187 80    ALL                                                                 Cluster: outbound|80||bar.bar.svc.cluster.local
10.68.4.198  80    Trans: raw_buffer; App: HTTP                                        Route: foo.foo.svc.cluster.local:80
10.68.4.198  80    ALL                                                                 Cluster: outbound|80||foo.foo.svc.cluster.local
10.68.0.1    443   ALL                                                                 Cluster: outbound|443||kubernetes.default.svc.cluster.local
10.68.0.60   443   ALL                                                                 Cluster: outbound|443||istio-ingressgateway.istio-system.svc.cluster.local
10.68.10.133 443   ALL                                                                 Cluster: outbound|443||istiod.istio-system.svc.cluster.local
10.68.11.98  443   Trans: raw_buffer; App: HTTP                                        Route: metrics-server.kube-system.svc.cluster.local:443
10.68.11.98  443   ALL                                                                 Cluster: outbound|443||metrics-server.kube-system.svc.cluster.local
0.0.0.0      15001 ALL                                                                 PassthroughCluster
0.0.0.0      15001 Addr: *:15001                                                       Non-HTTP/Non-TCP
0.0.0.0      15006 Addr: *:15006                                                       Non-HTTP/Non-TCP
0.0.0.0      15006 Trans: tls; App: TCP TLS; Addr: 0.0.0.0/0                           InboundPassthroughClusterIpv4
0.0.0.0      15006 Trans: raw_buffer; Addr: 0.0.0.0/0                                  InboundPassthroughClusterIpv4
0.0.0.0      15006 Trans: tls; App: HTTP TLS; Addr: 0.0.0.0/0                          InboundPassthroughClusterIpv4
0.0.0.0      15006 Trans: raw_buffer; App: HTTP; Addr: 0.0.0.0/0                       InboundPassthroughClusterIpv4
0.0.0.0      15006 Trans: tls; App: istio-http/1.0,istio-http/1.1,istio-h2; Addr: *:80 Cluster: inbound|80||
0.0.0.0      15006 Trans: raw_buffer; App: HTTP; Addr: *:80                            Cluster: inbound|80||
0.0.0.0      15006 Trans: tls; App: TCP TLS; Addr: *:80                                Cluster: inbound|80||
0.0.0.0      15006 Trans: raw_buffer; Addr: *:80                                       Cluster: inbound|80||
0.0.0.0      15006 Trans: tls; Addr: *:80                                              Cluster: inbound|80||
0.0.0.0      15010 Trans: raw_buffer; App: HTTP                                        Route: 15010
0.0.0.0      15010 ALL                                                                 PassthroughCluster
10.68.0.60   15012 ALL                                                                 Cluster: outbound|15012||istio-ingressgateway.istio-system.svc.cluster.local
10.68.10.133 15012 ALL                                                                 Cluster: outbound|15012||istiod.istio-system.svc.cluster.local
0.0.0.0      15014 Trans: raw_buffer; App: HTTP                                        Route: 15014
0.0.0.0      15014 ALL                                                                 PassthroughCluster
0.0.0.0      15021 ALL                                                                 Inline Route: /healthz/ready*
10.68.0.60   15021 Trans: raw_buffer; App: HTTP                                        Route: istio-ingressgateway.istio-system.svc.cluster.local:15021
10.68.0.60   15021 ALL                                                                 Cluster: outbound|15021||istio-ingressgateway.istio-system.svc.cluster.local
0.0.0.0      15090 ALL                                                                 Inline Route: /stats/prometheus*
10.68.0.60   15443 ALL                                                                 Cluster: outbound|15443||istio-ingressgateway.istio-system.svc.cluster.local

routes

% istioctl proxy-config routes test-app-9dfd8f5-58t4d.foo
NOTE: This output only contains routes loaded via RDS.
NAME                                                          DOMAINS                               MATCH                  VIRTUAL SERVICE
80                                                            bar.bar                               /*
80                                                            default-http-backend.kube-system      /*
80                                                            foo                                   /*
80                                                            istio-ingressgateway.istio-system     /*
15010                                                         istiod.istio-system                   /*
15014                                                         istiod.istio-system                   /*
istio-ingressgateway.istio-system.svc.cluster.local:15021     istio-ingressgateway.istio-system     /*
metrics-server.kube-system.svc.cluster.local:443              metrics-server.kube-system            /*
foo.foo.svc.cluster.local:80                                  foo                                   /*
bar.bar.svc.cluster.local:80                                  bar.bar                               /*
                                                              *                                     /stats/prometheus*
InboundPassthroughClusterIpv4                                 *                                     /*
InboundPassthroughClusterIpv4                                 *                                     /*
inbound|80||                                                  *                                     /*
                                                              *                                     /healthz/ready*
inbound|80||                                                  *                                     /*

cluster

% istioctl proxy-config cluster test-app-9dfd8f5-58t4d.foo
SERVICE FQDN                                            PORT      SUBSET     DIRECTION     TYPE             DESTINATION RULE
                                                        80        -          inbound       STATIC
BlackHoleCluster                                        -         -          -             STATIC
InboundPassthroughClusterIpv4                           -         -          -             ORIGINAL_DST
PassthroughCluster                                      -         -          -             ORIGINAL_DST
agent                                                   -         -          -             STATIC
bar.bar.svc.cluster.local                               80        -          outbound      EDS
default-http-backend.kube-system.svc.cluster.local      80        -          outbound      EDS
foo.foo.svc.cluster.local                               80        -          outbound      EDS
istio-ingressgateway.istio-system.svc.cluster.local     80        -          outbound      EDS
istio-ingressgateway.istio-system.svc.cluster.local     443       -          outbound      EDS
istio-ingressgateway.istio-system.svc.cluster.local     15012     -          outbound      EDS
istio-ingressgateway.istio-system.svc.cluster.local     15021     -          outbound      EDS
istio-ingressgateway.istio-system.svc.cluster.local     15443     -          outbound      EDS
istiod.istio-system.svc.cluster.local                   443       -          outbound      EDS
istiod.istio-system.svc.cluster.local                   15010     -          outbound      EDS
istiod.istio-system.svc.cluster.local                   15012     -          outbound      EDS
istiod.istio-system.svc.cluster.local                   15014     -          outbound      EDS
kube-dns.kube-system.svc.cluster.local                  53        -          outbound      EDS
kubernetes.default.svc.cluster.local                    443       -          outbound      EDS
metrics-server.kube-system.svc.cluster.local            443       -          outbound      EDS
prometheus_stats                                        -         -          -             STATIC
sds-grpc                                                -         -          -             STATIC
xds-grpc                                                -         -          -             STATIC
zipkin                                                  -         -          -             STRICT_DNS

endpoints

% istioctl proxy-config endpoints test-app-9dfd8f5-58t4d.foo
ENDPOINT                         STATUS      OUTLIER CHECK     CLUSTER
10.64.0.10:80                    HEALTHY     OK                outbound|80||foo.foo.svc.cluster.local
10.64.0.4:53                     HEALTHY     OK                outbound|53||kube-dns.kube-system.svc.cluster.local
10.64.0.8:443                    HEALTHY     OK                outbound|443||metrics-server.kube-system.svc.cluster.local
10.64.0.9:8080                   HEALTHY     OK                outbound|80||default-http-backend.kube-system.svc.cluster.local
10.64.1.3:53                     HEALTHY     OK                outbound|53||kube-dns.kube-system.svc.cluster.local
10.64.1.4:8080                   HEALTHY     OK                outbound|80||istio-ingressgateway.istio-system.svc.cluster.local
10.64.1.4:8443                   HEALTHY     OK                outbound|443||istio-ingressgateway.istio-system.svc.cluster.local
10.64.1.4:15012                  HEALTHY     OK                outbound|15012||istio-ingressgateway.istio-system.svc.cluster.local
10.64.1.4:15021                  HEALTHY     OK                outbound|15021||istio-ingressgateway.istio-system.svc.cluster.local
10.64.1.4:15443                  HEALTHY     OK                outbound|15443||istio-ingressgateway.istio-system.svc.cluster.local
10.64.2.2:15010                  HEALTHY     OK                outbound|15010||istiod.istio-system.svc.cluster.local
10.64.2.2:15012                  HEALTHY     OK                outbound|15012||istiod.istio-system.svc.cluster.local
10.64.2.2:15014                  HEALTHY     OK                outbound|15014||istiod.istio-system.svc.cluster.local
10.64.2.2:15017                  HEALTHY     OK                outbound|443||istiod.istio-system.svc.cluster.local
10.64.2.3:80                     HEALTHY     OK                outbound|80||bar.bar.svc.cluster.local
127.0.0.1:80                     HEALTHY     OK                inbound|80||
127.0.0.1:15000                  HEALTHY     OK                prometheus_stats
127.0.0.1:15020                  HEALTHY     OK                agent
35.189.153.189:443               HEALTHY     OK                outbound|443||kubernetes.default.svc.cluster.local
unix://./etc/istio/proxy/SDS     HEALTHY     OK                sds-grpc
unix://./etc/istio/proxy/XDS     HEALTHY     OK                xds-grpc

どの設定もたくさんあります。

ちょっと気になるのがfooのPodはbarのPodとは通信する予定はないのに、通信できるような設定があります。

冒頭に記載しているようにデフォルトではサービスメッシュ内のすべてのワークロードを通信できるような設定が適用されてしまいます。

本来であればbarのPodとは疎通できなくても問題ないため上記のbarに関する設定は消したいところです。

消すためにはSidecarリソースを使用します。

やっと本題であるSidecarリソースを使っていきたいと思います。

Sidecarリソースを使ってみる

ドキュメントを参考にSidecarリソースをapplyしてみようと思います。

今回はメッシュ内の、istio-systemと疎通できるような設定にしてみます。

Sidecar.yaml

apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: foo
  namespace: foo
spec:
  workloadSelector:
    labels:
      app: test-app
  ingress:
  - port:
      number: 80
      protocol: HTTP
    defaultEndpoint: 127.0.0.1:80
  egress:
  - hosts:
    - "istio-system/*"
---
apiVersion: networking.istio.io/v1alpha3
kind: Sidecar
metadata:
  name: bar
  namespace: bar
spec:
  workloadSelector:
    labels:
      app: test-app
  ingress:
  - port:
      number: 80
      protocol: HTTP
    defaultEndpoint: 127.0.0.1:80
  egress:
  - hosts:
    - "istio-system/*"

適用後のendpointsの設定を確認してみます。

% istioctl proxy-config endpoints test-app-9dfd8f5-58t4d.foo
ENDPOINT                         STATUS      OUTLIER CHECK     CLUSTER
10.64.1.4:8080                   HEALTHY     OK                outbound|80||istio-ingressgateway.istio-system.svc.cluster.local
10.64.1.4:8443                   HEALTHY     OK                outbound|443||istio-ingressgateway.istio-system.svc.cluster.local
10.64.1.4:15012                  HEALTHY     OK                outbound|15012||istio-ingressgateway.istio-system.svc.cluster.local
10.64.1.4:15021                  HEALTHY     OK                outbound|15021||istio-ingressgateway.istio-system.svc.cluster.local
10.64.1.4:15443                  HEALTHY     OK                outbound|15443||istio-ingressgateway.istio-system.svc.cluster.local
10.64.2.2:15010                  HEALTHY     OK                outbound|15010||istiod.istio-system.svc.cluster.local
10.64.2.2:15012                  HEALTHY     OK                outbound|15012||istiod.istio-system.svc.cluster.local
10.64.2.2:15014                  HEALTHY     OK                outbound|15014||istiod.istio-system.svc.cluster.local
10.64.2.2:15017                  HEALTHY     OK                outbound|443||istiod.istio-system.svc.cluster.local
127.0.0.1:80                     HEALTHY     OK                inbound|80||
127.0.0.1:15000                  HEALTHY     OK                prometheus_stats
127.0.0.1:15020                  HEALTHY     OK                agent
unix://./etc/istio/proxy/SDS     HEALTHY     OK                sds-grpc
unix://./etc/istio/proxy/XDS     HEALTHY     OK                xds-grpc

先ほどまで存在していたbarへの通信の設定がなくなりました。

Sidecarリソースを使うことで設定を必要以上に持たなくて済みました。

Sidecarリソースをもう少し理解したい

先ほどのSidecarリソースを使ってみた例ではいまいち恩恵を受けることができているのか、いないのかという印象は薄かったかもしれません。

しかし、istio-proxyのリソース使用量などパフォーマンスの側面で見るとSidecarリソースを使用することはとても大切になるようです。

大規模なシステムでistio-proxyが必要以上に設定を持ってしまうとCPUやメモリの消費も増えてしまいます。

issueなどにもVitualServiceリソースが増加するごとにメモリの使用量が増加した事例などがありました。

自身もどれくらいの負荷の増減が発生するのか検証してみました。

今回はVirtualServiceやリクエストによる負荷ではなく、単純にSidecarリソースを使用せずにNamespaceとPodを増やしてみてリソースの使用量に差異が見られるのか検証してみました。

Pod数を初回6台くらいから徐々に増やしていき最終的に120台まで増やしてみました。120台まで増やした後にSidecarリソースを適用してみました。

以下がその際のメモリの使用量の推移です。

f:id:jksdaba:20210329010836p:plain

全体として見ると増減は見られますが、5MB~10MBほどの増減でした。

時刻で見ると19:00頃から少しずつ使用量が増加しています。

19:00頃の Podの台数は50~60台ほどでした。そこから120台まで徐々に増加していったことが確認できました。

2:00前くらいから使用量が減少していますが、このときにSidecarリソースを適用しました。

一応メモリ使用量の変化を確認することができましたが、増減の値が小さかったり、、と少し検証内容は不十分だったのでは？と考えています。

絶えずリクエストを送ったり、VirtualServiceを使用して、サーキットブレーカーや割合によるリクエスト制御など様々な機能を利用した複雑なProxy設定を行った上でメトリクスを確認したら、より違った効果が見られたかもしれません。

Podを増やしていく上で、追加されたPodのistio-proxy、既に存在しているPodのistio-proxyどちらにも設定の更新が発生するためControl PlaneのIstiodにも負荷がかかってしまうということもわかりました。このあたりはPodの立ち上がりに影響が出てしまうかもしれないため別途検証してみたほうがよさそうです。