LEARN ENVOY - Routing Configuration — RDS - ツナワタリマイライフ

ROUTING WITH A CONTROL PLANE

とあるのでやはり Control Plane のことを考えねばならんのか。

Large Scale に Envoy を Production で展開するには Control Plane が便利
Single Source of Truth として Configuration を管理できるので便利
Serving Routes via RDS
- RDS は何かというと Route discovery service
- Control Plane が API として RDS を実装して、それを Envoy から呼んで Routing Configuration を Dynamic に設定するんだろう
Best Practices for Routing Definitions
- In order to scale out a single system for routing definitions, there are three key principles to follow:
  - Treat routes as data, not config
  - Distribute control to teams with ACLs
  - Design for changes with audit logs and rollbacks
1: Treat routes as data
- 言いたいことがイマイチわからないなー
- バージョンコントロールとかにのせて Routing を 1つの yaml でみんなで管理しようとするのがよくないと言っている？
- 何かしらの api 経由で更新するようにして、正しく動くことを保証して整合性を保つようにしろと言っている？
2: Distribute control to teams
- トラフィックのルーティングをサービスチームができるようにする
- その場合、権限も一緒に渡す
- それはそう
3: Design for change
- route の変更履歴は残そう
- 誰がいつやったのか
- ロールバックもできるようにしよう
- それはそう

やっぱり Control Plane を扱ったことがないとイマイチつかみきれない展開が続いてつらい。

1: Treat routes as data