## 數據落盤問題的由來 這本質上是數據持久化問題，對于有些應用依賴持久化數據，比如應用自身產生的日志需要持久化存儲的情況，需要保證容器里的數據不丟失，在Pod掛掉后，其他應用依然可以訪問到這些數據，因此我們需要將數據持久化存儲起來。 ## 數據落盤問題解決方案 下面以一個應用的日志收集為例，該日志需要持久化收集到ElasticSearch集群中，如果不考慮數據丟失的情形，可以直接使用前面提到的[應用日志收集](app-log-collection.md)一節中的方法，但考慮到Pod掛掉時logstash（或filebeat）并沒有收集完該pod內日志的情形，我們想到了如下這種解決方案，示意圖如下：  1. 首先需要給數據落盤的應用劃分node，即這些應用只調用到若干臺主機上 2. 給這若干臺主機增加label 3. 使用`deamonset`方式在這若干臺主機上啟動logstash的Pod（使用nodeSelector來限定在這幾臺主機上，我們在邊緣節點啟動的`treafik`也是這種模式） 4. 將應用的數據通過volume掛載到宿主機上 5. Logstash（或者filebeat）收集宿主機上的數據，數據持久化不會丟失 ## Side-effect 1. 首先kubernetes本身就提供了數據持久化的解決方案statefulset，不過需要用到公有云的存儲貨其他分布式存儲，這一點在我們的私有云環境里被否定了。 2. 需要管理主機的label，增加運維復雜度，但是具體問題具體對待 3. 必須保證應用啟動順序，需要先啟動logstash 4. 為主機打label使用nodeSelector的方式限制了資源調度的范圍