k8s以及雲原生相關概念近年來一直比較火熱，阿丸最近搞了個相關項目，小結一下。
本文將重點分享阿里開源項目otter適配k8s部署的改造過程，其中的改造過程和技巧應該適用於將大多數開源項目改造到k8s進行部署。
1.背景
otter是阿里開源的分布式資料庫同步系統，基於資料庫增量日誌解析，並準實時同步到本機房或異地機房的mysql/oracle資料庫(相關內容可以參考https://github.com/alibaba/otter，本文不做過多贅述)。
為了充分利用物理資源、快速擴容同步節點、擁抱雲原生，決定使用k8s部署otter。
otter的項目整體上自成一體，出於改造成本考慮，儘量在項目已有基礎上，做一些適配，不改動原始碼。
本文將重點分享對於otter適配k8s部署的改造過程，有不當之處，還請多多指教。
涉及到幾個核心內容：
otter基本架構 dockerfile編寫 deployment編寫 啟動腳本改造 K8s中固定ip/port訪問2.otter的基本架構
典型管理系統架構，manager(web管理)+node(工作節點)
manager運行時推送同步配置到node節點 node節點將同步狀態反饋到manager上 基於zookeeper，解決分布式狀態調度的，允許多node節點之間協同工作 基於Canal開源產品，獲取資料庫增量日誌數據。當然，otter採用了canal的嵌入式模式，不是獨立的canal節點。基於以上部署架構，我們只需要將otter-manager和otter-node部署到k8s上。
尤其是otter-node，需要利用k8s實現節點快速水平擴展、計算性能彈性擴縮容。
2.Dockerfile編寫
2.1 otter-manager的Dockerfile
otter-manager比較簡單，包括幾個步驟：
使用一個centos的基礎鏡像 設置時區 創建目錄 拷貝下載好的manager.deployer-4.2.18到指定目錄 使用啟動startup-new.sh腳本啟動(這裡對原本的啟動腳本做了一些改造，後文進行詳述)具體如下所示：
2.2 otter-node的Dockerfile
otter-node稍微有所不同，根據官方文檔說明，需要安裝aria2來做文件傳輸。
注意注意，由於aria2安裝非常慢，因此，我們需要先安裝aria2作為一個新的基礎鏡像，然後在新的基礎鏡像上構建otter-node鏡像，能大大提高後續鏡像構建速度。
新的基礎鏡像如下，命名為 registry.xxx.com/xxx/otter-node-base:1.0。
然後在此基礎上構建新的otter-node鏡像。
注意，otter-node的配置方式比較特殊，需要先在otter-admin上獲取一個nid，然後才能運行一個otter-node。
所以，我們在dockerfile中以ARG 聲明一個nid，然後在後續構建鏡像的時候，通過 --docker-arg 傳入nid具體的值。
當然，如果把nid看作一個配置文件的話，也可以用下文提到的ConfigMap的形式在Deployment中掛載進去
3.Deployment編寫
什麼是Deployment?
k8s的一個Deployment控制器為 Pods 和 ReplicaSets 提供聲明式的更新能力。我們通過編寫Deployment描述期望的目標狀態，然後 Deployment 控制器更改Pods或者ReplicaSets的實際狀態， 使其變為期望狀態。具體關於Deployment的知識不展開說明，可以參考k8s官方文檔。
我們需要部署測試環境與生產環境兩套集群，而無論是otter-manager還是otter-node，都依賴於讀取 conf/otter.properties 作為配置。
因此，我們需要根據環境，修改不同的otter.properties。
那麼，對於k8s部署來說，可以採用同一份鏡像，然後在不同環境(k8s的不同namespace)中將otter.properties作為ConfigMap寫入，最後通過volume的形式掛載到pod的指定路徑上。
這裡對幾個名詞做簡單介紹，詳細內容可以參考k8s官方文檔。
ConfigMap：一種 API 對象，用來將非機密性的數據保存到鍵值對中。使用時，Pods可以將其用作環境變量、命令行參數或者存儲卷中的配置文件。(如果想存儲的數據是機密的，可以使用 Secret，而不是ConfigMap) Volume：卷的核心是包含一些數據的一個目錄，Pod 中的容器可以訪問該目錄。所採用的特定的卷類型將決定該目錄如何形成的、使用何種介質保存數據以及目錄中存放 的內容。使用卷時, 在 .spec.volumes 欄位中設置為 Pod 提供的卷，並在 .spec.containers[*].volumeMounts 欄位中聲明卷在容器中的掛載位置。所以，首先在指定環境(namespace中)創建configmap，以otter.properties作為key，以文件內容作為value。
具體命令如下
kubectl create configmap otter-manager-dev-config --from-file=otter.properties=conf/otter-dev.properties -n otter-system
在namespace為otter-system中創建一個名字為otter-manager-dev-config的ConfigMap，其中，以otter.properties作為key，以文件內容作為value。產生的ConfigMap如下圖所示
最後，將這個ConfigMap在Deployment中用volume進行引用，然後通過volumeMounts掛載到指定目錄，Deployment具體如下所示。
這裡需要特別注意volumeMounts的路徑覆蓋問題，需要在volumeMounts中配置subPath為具體文件名。
4.啟動腳本改造
Otter包括兩個部分，管理控制臺manager和工作運行節點node，正常情況下都是用各自的啟動腳本startup.sh啟動的。
為了適配k8s，我們需要對啟動腳本做改造，本文以otter-manager的啟動腳本為例，otter-node也是類似。
將啟動腳本startup.sh改造為 startup-moon.sh，重點解決兩個問題
4.1 前臺進程保持運行
由於容器中用entrypoint啟動的進程為1號進程，一旦1號進程執行結束，容器就會退出了。
而原本的startup.sh中，用java啟動後，使用 「&」 將java進程轉換為後臺進程，所以startup.sh作為1號進程會很快執行結束，容器就會自動退出了。
所以我們需要將1號進程保持住，不要退出。
這裡考慮了兩個方案：
Startup.sh腳本中增加一個前臺進程進行保持，比如 tail -f /dev/null 命令 將「&」去掉，讓java啟動後就作為前臺進程一直保持後來考慮了一下，還是選擇了方案二。主要原因是為了利用pod自動重啟的特性。
如果Java進程意外退出了，那麼方案二就能使得1號進程也結束，然後pod就能自動重啟了。而方案一的話，由於startup.sh腳本仍然在執行tail，所以即使java進程退出，1號進程也不會結束。
具體修改如下：
最終pod中的進程如圖所示
4.2 虛擬機大小自定義配置
由於otter項目中，將jvm的啟動參數配置在了start.sh中，不方便進行手動配置。
因此，將start.sh的配置jvm參數的邏輯注釋掉，採用自己配置的環境變量JAVA_OPTIONS進行注入。
這個環境變量的注入方式也比較簡單，就是在Deployment中的env配置的(藍色框部分)，方便以後手動修改jvm參數大小而不用修改鏡像。
5.k8s上固定IP/Port訪問
otter-node的部署中，有個比較特殊的地方。
不同於普通的微服務的無狀態擴展，otter-node的部署必須指定nid、ip、port，這種設計據說是為解決單機部署多實例而設計的，允許單機多node指定不同的埠(具體可以參考官方wiki，https://github.com/alibaba/otter/wiki/Node_Quickstart，這裡不展開說明)。
還是直接看看如何在k8s上進行適配吧。
這裡採用了k8s的NodePort進行處理。
NodePort 服務是引導外部流量到你的服務的最原始方式。NodePort，正如這個名字所示，在所有節點(虛擬機)上開放一個特定埠，任何發送到該埠的流量都被轉發到對應服務。如下圖所示。
在上面的配置中，可以使用IP1:3000 或者 IP2:3000 或者 IP3:3000 訪問service。
當然，為了保證不綁定特定KVM的IP，我們在前面掛一個SLB服務，通過訪問SLB的 虛擬IP:PORT 的形式訪問。
對於otter部署來說，otter-manager需要兩組 IP:PORT、每個node需要三組 IP:PORT。
注意，由於otter部署中，每個node需要暴露的port都是不同的，所以每次新增一個otter-node，都需要新增三組 IP:PORT。
我們以otter-node為例，來看下NodePort類型的Service的yml文件吧。
6.總結
經過這樣的改造，我們就能用k8s的部署otter-manager和otter-node了，並且能夠快速擴容節點、彈性使用機器資源。
我們回顧一下其中的關鍵問題和技巧：
Dockerfile編寫中，可以把環境相關依賴打成一個新的基礎鏡像，提高後續應用鏡像的構建速度。 Dockerfile中，可以通過ARG定義一些構建過程中的變量，進行替換。 對於不同環境的配置文件，可以在不同環境(k8s的namespace)下配置不同的ConfigMap，然後在Deployment文件中通過volumeMounts的方式掛載進去。 對於後臺進程，需要改造為前臺進程使得pod能夠保持 對於一些特定的環境變量，可以在Deployment中通過env進行傳入。其他開源項目如果有需要上k8s的，這些技巧應該都能用上。
【編輯推薦】
【責任編輯：
姜華TEL：（010）68476606】