{%hackmd @coscup/S1EDiCRcn %}

> 請從這裡開始

controller manager 在 Reconcile 時，不會得知先前的狀態名稱，因此沒辦法直接修改就完成 新增 + 刪除舊的流程

- 直接禁止修改 Bridge Name 欄位，要修改就是建新的

重新設計內容：

1. BridgeConfig：
1. 負責選擇節點，處理 Bridge CR 的狀態，紀錄 Bridge 的樣版
2. 類似於 Daemonset
2. Bridge
1. 實際上動到 Linux 上面的 bridge
2. 類似於 Pods

也就是說，使用者是新增 BridgeConfig, 然後 controller 會去產生 Bridge 到對應的節點 (不同的 selector)

在 BridgeConfig 上，若是修改 BridgeName，可以透過 label 的方式找到舊的 BridgeName 然後處理刪除舊的 + 新增新的 (只要與新增上去的 BridgeName 不同就是舊的）

- Bridge Contoller 也會同步在 Linux node 上面移除 網路 binding 設定

利用以上的方式就可以把 Uplink 與 Bridge 的設定拆開來
- BridgeConfig 只負責與 Linux Bridge 相關的設定
- Uplink 也可能因為節點不同有不一樣的設定

一樣設計另外一個 `UplinkConfig`，機制與上述類似

Uplink 與 Bridge 就沒有相異性問題，除非 Uplink 設定 Bridge 為 master

- 但其實也沒關係，先建好 Uplink 之後會持續監看，就算沒有對應的 bridge，只要後續建立之後還是會同步狀態上去

使用者設定可以透過 WebUI 設定精靈一次處理掉 (e.g Vmware)

Kubernetes Controller 的 Reconcile 的機制：

- 不能 sleep，會把整個的機制停掉
- 只能叫他幾秒後再重做一次