MOPCON 2020 - 從遺留架構動身前往 Kubernetes 的世界

342dde780fe56d44bdeada4bb429145a?s=47 Luka Huang
October 25, 2020

MOPCON 2020 - 從遺留架構動身前往 Kubernetes 的世界

https://mopcon.org/2020/schedule/2020027
本次演講近一年的實戰心得與矽谷 10X 工程師並肩作戰的過程,完整解析將舊架構遷移至 Kubernetes 的過程。

- 遺留程式碼大家很常聽到,那麼什麼是遺留架構呢?
- 遺留架構如何讓我們的生產力低落?
- K8S 如何解決這些痛點?
- 重構架構該考慮些什麼?
- 我們進入 K8S 的世界了,是不是真的這麼好?

如果你對時下最夯的 Kubernetes 有興趣,一定要來聽一下!筆者會以淺顯易懂的方式,開發者的角度,帶你走過 K8S 的技術體系。

342dde780fe56d44bdeada4bb429145a?s=128

Luka Huang

October 25, 2020
Tweet

Transcript

  1. Moving From Legacy Infrastructure to Kubernetes Luka.Huang@mopcon 2020

  2. Self Intro • Luka Huang • Senior Backend Developer works

    for Splashtop
  3. Self Intro • Luka Huang • Senior Backend Developer works

    for Splashtop • Medium - Luka Huang
  4. Self Intro • Luka Huang • Senior Backend Developer works

    for Splashtop • Medium - Luka Huang • A Curator of StarBugs Weekly
  5. Self Intro • Luka Huang • Senior Backend Developer works

    for Splashtop • Medium - Luka Huang • A Curator of StarBugs Weekly • Creator of CodeShiba https://www.facebook.com/CodeShiba
  6. Career 1. Web Developer 
 ( Ruby on Rails +

    Vue.js) 2. Backend Developer 3. Interested in DevOps 
 ( Terraform / Docker / Kubernetes … etc)
  7. Involve in Large-scale System 1. It’s exciting 2. Knowledge is

    important 3. Can earn more money
  8. 想要分享的原因

  9. 難得的機會 將近 10 年的系統,要遷移至 Kubernetes 需要承載很⼤的流量 對停機時間非常要求 ⾶到矽⾕與架構師、顧問開會,討論、學習如何架構系統 實際參與「開始」到「上線」的完整的過程

  10. 延伸 如何將「遺留程式碼」的觀念,⽤在處理「遺留架構」上 ⼗倍⼯程師是怎麼樣的存在︖ 離國際型的⼈才,距離有多遠︖

  11. Outline • Why we move to Kubernetes ? • Introduction

    to Kubernetes & IAC • Move legacy infrastructure to K8s • Legacy infrastructure vs Legacy Code • Talking about 10x Engineer • Conclustion
  12. Why we move to Kubernetes ? 為什麼要使⽤ Kubernetes ?

  13. 過得好好的,為什什麼要⽤用 K8S ?

  14. 契機

  15. 啟動歐洲區

  16. 如果要擴展歐洲業務, 要建立⼀一個獨立的系統

  17. GDPR

  18. GDPR

  19. 好嚴格阿!

  20. ⽤用原來來的架構再搭⼀一套不好嘛?

  21. Single system Infrastructure Layer (EC2、VPC、RDS … etc) Application Layer(API, Web,

    Worker, … etc ) Testing by QA
  22. Clone the entire system 2 * Infrastructure Layer (EC2、VPC、RDS …

    etc) 2 * Application Layer(API, Web, Worker, … etc ) 2 * Testing by QA The new system is 90% the same as original system.
  23. 
 in the code and 
 in the infrastructure Don’t

    Repeat Yourself
  24. 插曲,轉折點

  25. 顧問降臨臨 直到,從矽⾕的顧問⾶來台北辦公室

  26. 介紹了了⼀一下 K8S 技術

  27. 了了解 infrastructure

  28. 有⽤用 CI 跑測試很棒

  29. 兩兩週後,宣布要使⽤用 K8S

  30. None
  31. 眾⼈人:(驚)真的假的?要⽤用 K8S?沒有⼈人會耶

  32. 兩兩週後,集結最⾼高戰⼒力力,開始作戰。

  33. 我扮演的⾓角⾊色 在遷移至 K8S 這個專案中,主要的後端開發者 負責容器化後端的服務 負責將以前的架構解析,遷移至 K8S 跨團隊協作,與 QA、Auto-testing、DevOps Team

    合作 與矽⾕的架構師與顧問合⼒實作後端架構
  34. 順利利啟動歐洲區

  35. Introduction to Kubernetes & IAC

  36. Kubernetes 就是

  37. None
  38. 傳統架構 vs K8S 架構

  39. https://thenewstack.io/7-features-that-make-kubernetes-ideal-for-ci-cd/ Traditional Framework

  40. https://thenewstack.io/7-features-that-make-kubernetes-ideal-for-ci-cd/ Using Docker without K8S

  41. https://thenewstack.io/7-features-that-make-kubernetes-ideal-for-ci-cd/ K8S

  42. 簡單介紹 K8S Kubernetes 重要元件介紹: Node Pod Service Deployment Ingress

  43. https://thenewstack.io/7-features-that-make-kubernetes-ideal-for-ci-cd/ Node

  44. https://thenewstack.io/7-features-that-make-kubernetes-ideal-for-ci-cd/ Pod

  45. https://thenewstack.io/7-features-that-make-kubernetes-ideal-for-ci-cd/ Service & Deployment

  46. https://thenewstack.io/7-features-that-make-kubernetes-ideal-for-ci-cd/ Ingress

  47. Helm ⽤法有點像是你想要在 ubuntu 系統下安裝 vim 輸入 apt install vim 即可安裝完成

    那在 K8S 的世界,你想要安裝⼀個 wordpress 只要輸入 helm install my-wordpress wordpress
 (指令為簡略⽰意版)
  48. Terraform https://geekflare.com/terraform-for-beginners/

  49. Moving from legacy infrastructure
 to Kubernetes

  50. but how?

  51. 第⼀一個難題

  52. 如何了了解⽬目前的系統?

  53. Part 1 - 從 Application Level 了了解

  54. Application level Application level - 應⽤程式層 API Server Web Server

    Worker Other Service
  55. 伺服器上藏著許多⼤大密寶

  56. 幾種⼤大密寶 init.d - 伺服器上藏了多少初始化⼤密寶 (shell script) ? system.d - 伺服器上藏了多少服務型⼤密寶

    (shell script) ? monit.d - 伺服器上藏了多少監控型⼤密寶 (shell script) ?
  57. init.d init.d - 伺服器上藏了多少初始化⼤密寶 (shell script) ? 服務啟動腳本通通放置於 /etc/init.d/ 底下

    init 是開機後核⼼主動呼叫 根據使⽤者⾃訂的執⾏等級 (runlevel) 來喚醒不同的服務
  58. system.d 伺服器上藏了多少服務型⼤密寶 (shell script) ? 系統初始化需要做的事情非常多 每⼀步驟被 system.d 抽象成⼀個單元 service

    - 代表⼀個後台 process,例如: mysqld, httpd, … etc IUUQGFMJYMJODPNMJOVYJOJU&#$&$&"%#&"#&#%&##$&##"&&MJOVY&%&"#&$JOJU&###&##&'#$$&"$"$&"&TZTUFNE
  59. system.d https://linuxhint.com/list_service_systemd/

  60. monit.d 可以⾃動修復已經停⽌的程序 不需要⼈⼯⼲預 所以這些需要 monit 的 process,是重要的

  61. Nginx / Apache Config init.d - 伺服器上藏了多少初始化⼤密寶 (shell script) ?

    system.d - 伺服器上藏了多少服務型⼤密寶 (shell script) ? monit.d - 伺服器上藏了多少監控型⼤密寶 (shell script) ? Nginx / Apache 的 config 做了哪些設定︖
  62. Nginx Config IUUQTTUBDLPWFSGMPXDPNRVFTUJPOTIPXEPJNBLFNZMBSBWFMBQQXPSLPOBOHJOYTFSWFS

  63. 發現了了⼤大密寶之後

  64. 還是要出來來⾯面對

  65. 把這些搬到 K8S 上⾯面

  66. 好東⻄西,不搬嘛?

  67. 搬!哪次不搬?

  68. 所以要怎麼搬呢?

  69. K8S 對應的元件 init.d - 初始化⼤密寶 => entrypoint

  70. K8S 對應的元件 init.d - 初始化⼤密寶 => entrypoint system.d - 服務型⼤密寶

    => K8S 讓 pod 中的 process 變得單純
  71. K8S 對應的元件 init.d - 初始化⼤密寶 => entrypoint system.d - 服務型⼤密寶

    => docker / entrypoint monit.d - 監控型⼤密寶 => 運⽤ K8S 對 pod 的監控機制
  72. K8S 對應的元件 init.d - 初始化⼤密寶 => entrypoint system.d - 服務型⼤密寶

    => docker / entrypoint monit.d - 監控型⼤密寶 => 運⽤ K8S 對 pod 的監控機制 Nginx / Apache 的 config => ingress 的設定
  73. Part 2 - 從 Deployment 了了解

  74. 如何更更新 code ,達到持續部屬(CD)的⽬目標

  75. 以前的⽅方法是把 code 拉到伺服器上⾯面

  76. 傳統的⽅方法是把 code 拉到伺服器上⾯面, 再去重啟

  77. 可能透過⼀一些⼯工具去協助你,但原理理⼤大概 就是這樣。

  78. 進入 kubernetes 的世界之後

  79. 使⽤用 Docker 是比較有效益的作法

  80. Docker 跟 Ansible 相比 Docker 不太會跟環境相依,Ansible 會

  81. 同樣的腳本,有時候 Ansible 會莫名其妙的失敗, 可能是作業系統不同或是某種套件版本不⼀一導致

  82. 現代化,使⽤用 docker + kubernetes 的機制 進⾏行行部屬

  83. kubernetes 有很完整的機制達到更更新 pod 的 版本,卻不會讓使⽤用者感到存在停機時間

  84. K8S - pod 的⽣生命週期 readiness probe - 確保 pod 就緒才把流量導進來

    liveness probe - 確保 pod 還是在正常⼯作,否則 kubernetes 會終⽌這個 pod 並重啟。
  85. Part 3 - Infrastructure layer

  86. IAC - Infrastructure as Code Terraform - 把所有的基礎設施寫成程式碼,例如:EC2、S3、 VPC ...

    etc,使⽤ Terraform 來撰寫。 Docker - 把安裝在機器中的東西也寫成程式碼,例如:⽤ apt install nginx 之類的套件,可以⽤ Ansible / Docker 來寫。 Kubernetes - 能夠將所有機器變成⼀個⼤平台。透過修改 K8S 的設定檔即可完成所需架構。
  87. 如果可以把 infrastruce 寫成 code,其 實就可以⽤用程式碼的概念念來來套⽤用

  88. 實現 IAC 的步驟 實現 IAC 的第⼀步 - ⽤ Docker 建⽴

    test image 實現 IAC 的第⼆步 - ⽤ Ansible 寫出 Staging 伺服器配置 實現 IAC 的第三步 - 設計新的架構來對應舊架構 實現 IAC 的最終⽬標 - 所有的改動,都使⽤ Terrafrom + Helm
  89. 進入到今天的重點

  90. Legacy infrastructure vs Legacy Code

  91. Legacy Code 怎麼樣的程式碼是 Legacy Code ?

  92. Legacy Code 1. 別⼈寫的

  93. Legacy Code 1. 別⼈寫的 2. 也可能是⾃⼰寫的

  94. Legacy Code 1. 別⼈寫的 2. 也可能是⾃⼰寫的 3. 沒有測試覆蓋

  95. Legacy Code 1. 別⼈寫的 2. 也可能是⾃⼰寫的 3. 沒有測試覆蓋 4. 測試無法表達意圖

  96. Keywords 1. Legacy Code 2. Unit Test 3. Refactor 4.

    TDD (Test Driven Development)
  97. 如果⾃自⼰己讀不懂的話

  98. 可以找他

  99. None
  100. 91 敏捷開發之路路 1. Legacy Code 2. Unit Test 3. Refactor

    4. TDD (Test Driven Development)
  101. Legacy Infrastructure 怎麼樣的架構是遺留架構︖

  102. Legacy Infrastructure 1. 別⼈架設的伺服器

  103. Legacy Infrastructure 1. 別⼈架設的伺服器 2. 也可以能是⾃⼰架設的

  104. Legacy Infrastructure 1. 別⼈架設的伺服器 2. 也可以能是⾃⼰架設的 3. 沒有測試覆蓋

  105. Legacy Infrastructure 1. 別⼈架設的伺服器 2. 也可以能是⾃⼰架設的 3. 沒有測試覆蓋 4. 測試無法表達意圖

  106. Can we write down tests on infrastructure?

  107. Yes, we can.

  108. Testing on Infrastructure 1. End-to-End testing

  109. Testing on Infrastructure 1. End-to-End testing 2. Nightly build

  110. Testing on Infrastructure 1. End-to-End testing 2. Nightly build 3.

    Load Testing
  111. Testing on Infrastructure 1. End-to-End testing => 功能正確 2. Nightly

    build => 修改後的架構可以提供正常服務 3. Load Testing => 修改後的架構可以承載⼤流量 4. 這些都整合在 CI / CD 裡⾯
  112. Refactor 程式碼的 Refactor

  113. Refactor 的⽤用意 • 降低未來修改的成本 • 降低未來理解程式碼的成本

  114. Refactor Infrastructure 架構⾯的 Refactor

  115. Refactor Infrastructure • 架構也是⼀樣的道理 • 降低未來修改的成本 • 降低未來理解程式碼的成本

  116. Refactor Infrastructure • 相同的事情,有沒有更簡單,更容易懂的作法︖例如: • 公司內網才能使⽤管理員後台 • 資料庫只能被 Application Server

    存取 • S3 只能由被 Application Server 存取
  117. Refactor Infrastructure • 我們可以藉由不斷的重構,讓 IAC 的 Code 變得越來 越直覺。 •

    以後需要變動架構的時候,才不會覺得很痛苦,不知 道怎麼改起
  118. 10x Engineer

  119. ⼗倍⼯程師是否真的存在︖

  120. 有⼈說,我以前不相信⼗倍⼯程師的 存在,直到我遇到了 1/10 ⼯程師

  121. 真的有⼗倍⼯程師存在嘛︖

  122. 是的,真的有⼗倍⼯程師的存在

  123. ⼗倍⼯程師是怎麼樣的⼈︖

  124. ⼗十倍⼯工程師 技術又深又廣,每⼀個點的技術都比你強 Web Infrastructure Endpoint K8S

  125. ⼗十倍⼯工程師 強⼤的跨⽂化溝通能⼒與跨團隊溝通能⼒ Backend DevOps Ops QA Auto Testing

  126. ⼗十倍⼯工程師 語⾔能⼒ 英⽂ (native) ⽇⽂ 中⽂ (最近學的)

  127. ⼗十倍⼯工程師 能夠說服公司採⽤⽅案 有很強的技術不是⼀切 技術強,也要想辦法轉換成價值,讓公司買單 並且真的做出來,產⽣效益

  128. ⼗十倍⼯工程師 ⾜夠⼤的市場 市場規模,決定你的想像⼒ 技術強,思維也要跟上,才能解決更⼤市場的問題 如何讓⾃⼰可以接觸這樣的市場就是⼀個重要的課題

  129. ⼗十倍⼯工程師 ⼤家多多嘗試進軍世界舞台,可以看到不⼀樣的世界

  130. Conclusion 了解 K8S、Helm、Terraform … 等等技術名詞的意義。 了解傳統作法與新的 Terraform + K8S 技術體系的差異

    了解頗析⼀個舊架構,遷移至 K8S 為中⼼的雲原⽣架構的過程。 了解如何重構舊架構 聽到了⼀個⼗倍⼯程師的故事
  131. Thanks for listening