DEV Community: RicoToothless

ECS migrate to EKS part 3

RicoToothless — Sun, 15 Aug 2021 09:03:50 +0000

本文撰寫自 2020-10-20，技術的細節可能不是最新的

How to start your AWS CDK journey?

在台灣 AWS CDK meetup#1 裡有分享過新手 operator 寫 CDK 之旅（建議把整個 PDF 下載下來，裡面有很多連結），初學者怎麼入門後快速熟悉整個 CDK 生態圈，最近 AWS 在全球非常積極推動 CDK，各個關於 CDK 的分享或資源真的全世界各個國家都有，裡面的資源可以陪伴新手從初級到進階都沒問題。

AWS CDK EKS Overview

AWS CDK 把每一個 AWS 服務包成一個 package，每一個 package 成熟度不一，像是 AWS CDK EKS 就還在 experiment 階段，也曾經因為 CDK EKS 有非常大的 breaking change，不得不重新創一個新的 EKS cluster，並且把所有的 application migrate 過去。最近 EKS 的功能越來越齊全了，像是可以創建 IRSA（IAM Roles for Service Accounts）的 Service Account 之外，還會把 OIDC ID provider 自動創建起來，非常地方便。實際建置時 EKS 除了 application CICD 是用 Jenkins 做之外，像是 backing services、monitoring 的建置，還有 backing services 本身、monitoring 與 application 本身的 IRSA 都是靠 CDK 建置的。例如：Hashicorp Vault KMS Auto-Unseal 會需要 AWS KMS 的權限來調用 KMS 做為 Vault Master Key 來加解密敏感資料。

2021-08-15 更新，AWS CDK EKS 已經正式脫離 experiment 進入 stable 的狀態了。

AWS CDK EKS Helm Chart management

Kubernetes 使用者對於 Helm 的使用率還是非常地高，建置服務的時候可以大幅縮短自己造輪子的時間，想當初建置一個 rabbitmq cluster、redis sentinel 或者 vault 等等都要在不彈性的 ECS 上建置，就會覺得有類似於 package manager 功能的工具是非常需要的。也因此，CDK EKS 有支援 Helm 的確不太意外，但在實際上使用的時候會發現有客製 chart repository server 的需求，就要小心不要遇到雞生蛋蛋生雞的問題，例如把 chart repository 放在 Nexus 裡，然後 Nexus 是透過 ingress controller 代理的，又剛好這個 ingress controller 是客製化的 chart，就有可能會變成在 CDK deploy 的時候因為 ingress 沒有啟動而抓不到 Nexus server 裡面的 chart。所以這裡的建議是放在 ECR or S3 會比較好一點，做法就是一樣用 CDK 建置 chart repository 專用的 repository or Bucket 之後，chart 再從 source control 出發開始跑 CICD 最後到 chart repository 裡，最後 CDK EKS helm chart 再從 chart repository 裡 pull 我們客製化過的 chart。

AWS CDK Kubernetes resources management

AWS CDK EKS 在 Kubernet resource management 歷史比較久而且變化一直都蠻大的，最一開始只有用 kubectl apply 來實踐 Kubernetes resource 的創建或修改，對我而言其實算夠用了，畢竟大部分的 services 都是靠 Helm 管理，只有少部分的 resources 像是 PV、PVC 或 storageClass 需要額外管理。在最近的 CDK 版本中，多了一個新的 CDK8s 的選擇之外，CDK EKS 本身也多了 query 的概念，像是在官方文件中的案例為抓取已經建立好的 LoadBalancer DNS name，我自己本身也是使用 LoadBalancer 想說希望有 query 的功能，但山不轉路轉，我後來是選擇使用 external-dns 做為 service discovery 的工具。

EKS ingress solution: Traefik (v1.7) + ALB

對於 ingress 的實踐相對複雜一點，原本是使用 Traefik (v1.7) + Network Load Balancer，但面對複雜的 routing 需求再加上想要與 AWS resources 有更好地整合，像是可以直接套用 WAF、ACM 或 Security Group 等等。後來有想導入 AWS ALB controller 來替 ingress 加上 ALB，但現實上遇到的問題就是走 microservices 要替每一個 ingress 建立一個 ALB 的話不太符合經濟效益。所以最後的做法是 Traefik (v1.7) + ALB，關於怎麼運作的流程圖：

在公開的 Helm charts stable 裡，最多只有到 service，並沒有 ingress object，所以要能夠使用這個架構必須自己客製 chart。

流程大致如下：

使用 Helm charts incubator aws-alb-ingress-controller 建置 ALB controller，並且額外建立 service account for IRSA
使用客製的 Traefik chart，透過 ingress object 讓 ALB controller 知道要建立 Traefik 專屬的 ALB
建立想要讓外面流量可以訪問的 application，透過 ingress object 讓 Traefik 知道要建立 routing rule
當一般的 user 做訪問的時候會先從 ALB 進來到 Traefik service，再來是 Traefik pods，之後 Traefik 會把 application 的行為傳回 user

Conclusion

CDK package 每個成熟度不一，依照公司可以承擔的風險做選擇
CDK EKS package 在 experiment 中，但依舊有很多好用的功能像是 IRSA、Helm 或進階的 Kubernetes resources management
自建的 chart repository 要避免落入雞生蛋蛋生雞的情境
CDK EKS 對 Kubernetes resources 除了 create or modify 之外，新增了 query 的功能
設計系統的過程中要適時的山不轉路轉
Traefik + ALB 可以讓 routing 做更多的變化，與 AWS resources 有更好地整合

Reference

ECS migrate to EKS part 2

RicoToothless — Sun, 15 Aug 2021 08:52:07 +0000

本文撰寫自 2020-02-09，技術的細節可能不是最新的

Software Development Life Cycle (SDLC)

這一次的 Migration 基本上可以套用 SDLC 的概念，但是迭代更快，為了增加效率決定把 task 細分，每個 task 都跑一次 SDLC 。其實 SDLC 每個階段的劃分大家都不太一樣，而我的 SDLC 的流程大致如下：

Project Initiation
Requirements Gathering
Analysis
Design
Development
Testing
Deployment
Maintenance

Project Initiation

在這裡我們需要站在高處上考慮到整體，什麼問題需要解決、手中資源有多少、時程、里程碑、商業價值等等。

上一篇文章，因為公司內部日趨複雜的專案越來越多，原本簡單的維運方式已經無法負荷，所以從 ECS migrate to EKS。

Requirements Gathering

原本在 SDLC 裡 Requirements Gathering 是幫助定義是否有這需求，不過呢，基本上原本在 ECS 的優點都是必須的，幸運的是這些優點都可以在 EKS 上實現，我們能做的就是排定優先順序完成。

Analysis

分析是否可以把整個 Project 切成小的 task 。
分析每個 task 若要達成的話需要哪些要求，例如資料要先備份，有依賴性的服務要先把依賴關係搞清楚。
分析失敗的風險是要可以控制且可以預測的，基本上只要資料有備份好，使用 container 切換很快所以還可以。
分析這個 Project 是否可以對不同職位的人都容易上手，我個人的想法是呈現給他們的都是最簡單的一面，實際使用的時候不用知道太多背後的原理。

Design

因為每一個 task 實際怎麼達成目標的方法都不太一樣，以下幾點是 Design 的核心原則：

要做出好的 Design 必須深入了解所有技術的細節，你的 application 能力、工具的能力、團隊能力等等。（雖然整個 migrate 過程只有我一個人就是了）
所有的 Design 計畫必須要給有相關的人員檢視過。
若相關人員給出建議之後再整合到 Design 計畫裡。

在真正開始 migrate 之前，必須要先了解工具現有的 migrate solution ，像是資料庫 migrate 和 credential migrate ，這些工具都會有 migrate 的功能，不只了解還得實際演練一次，畢竟任何資料都要小心謹慎處理。

Development

接下來就是真正要實作的部分，一樣有幾個核心原則：

先測試環境之後正式環境。
先無狀態 application 之後有狀態 application 。
先簡單之後困難

第一點應該沒什麼需要補充的，而第二點其實跟第三點的概念十分相似，自己本身雖然有學過 Kubernetes 但畢竟實際實踐是兩回事，所以本質上是從頭開始學起，所以先站穩腳步再提及跑步是妥當的做法，再加上有些工具都要跟著換會更好，例如 CICD 的工具 Kubernetes plugin for Jenkins。

Testing

Testing 是非常重要的一環，必須要把功能各方面都保護好，除了要測是否有 bug 也要測是不是完全符合需求。基本上測試的人也是我，所以沒有特別跑 Bug lifecycle，因為是我自己跑那個 lifecycle 。 Testing 核心原則如下：

不要有任何推測、假想、幻想某些看似基本或微小的功能是正常的。
測試發現跟預期不一樣也不能對功能有妥協，功能當初設計要 80 分，驗收的時候就該是 80 分以上。
如果真的需要妥協，像是當初 Design 就有問題，就 feedback 並回到 Design 的階段。

Deployment

Deployment 的原則和 Development 差不多，每個 task 重要程度不一，所以 Deployment 也要看花多少資源準備。當我測完之後，就會開始 migrate ，不論是哪種 task ，在這之前都要準備好備份。當然還有一點就是要稍微選擇一下停機時間，盡量不影響他人是美德。

Maintenance

接下來就是準備好接受真實 user 的 feedback 了，不論 user 是客戶或是坐在隔壁的開發人員都必須好好面對，畢竟他們給的 feedback 才是最有價值處理的事情。

Conclusion

下一篇會講更多實踐的技術細節，這邊先做一些總結：

Project Initiation 要確認 migrate 價值
Requirements Gathering 要確認是否有開啟 migrate 的需求
Analysis 要分析我們能做到什麼程度，風險是什麼
Design 要深入了解技術後再 Design，且必須持續整合其他人的 feedback
Development 要扎扎實實且一步一步的完成
Testing 要務實、堅守立場最後真的有疑慮再做 feedback
Deployment 要隨時有 B 計畫，並且盡量讓服務不停機
Maintenance 要廣納接受所有 feedback

ECS migrate to EKS part 1

RicoToothless — Sun, 15 Aug 2021 08:44:22 +0000

本文撰寫自 2020-01-13，技術的細節可能不是最新的

What is ECS?

這裡簡單的介紹一下 ECS ，他是一個簡單好上手的 container orchestration，個人覺得比 Docker Swarm 還要容易上手。

ECS 我們都只使用 EC2 的底層，他的架構如下：

我特別標示了 Auto Scaling Group 的部分可以看出，實際上 ECS host 也就是所謂的 EC2 Instance ，如果要一個 cluster 裡面要多台 EC2 就是靠 Auto Scaling Group 自動 create EC2 給你，之後再靠 task definition file 和 service 來定義 container 要怎麼啟動。

What is EKS?

EKS 本質上就是受到 AWS 託管的 Kubernetes，跟自架的 Kubernetes cluster 相比， EKS 幫使用者做好了 control plane master node HA 之外， network 的部分也整合到 AWS VPC 裡面，這樣就不用太過煩惱要用什麼 Kubernetes 那種網路方案，也不用煩惱網路效能的問題。還有整合 AWS IAM 到 EKS 裡，權限的控管就不用特別在 EKS 裡再做一次了。

EKS 的架構如下：

其實 EC2 的增長跟 ECS 用的都是同一套 Auto Scaling Group ，而使用者的 application 怎麼跑就是使用 Kubernetes API 定義的範圍裡寫 YAML file 來定義。

Why ECS migrate to EKS?

一開始我們的架構很單純，ECS 裡面架設自己的 app 加上 RDS ，但後來漸漸地需要各式各樣的工具，像是儲存 secret、message queue 和 cache 等等。而且這些工具都是 stateful 的服務，光是本身要做 HA 就不太容易，而在 ECS 上做 HA 更是讓 ECS 的優勢不再凸顯，在 ECS 上架設 HA 跟直接在一般的 EC2 上架設差不多。

一大主因是對於 ECS storage 雖然也有類似 Kubernetes PV （Persistent Volume）的概念，而且 ECS 用 EBS 也可以用 user-data 做到類似的效果，但基本上 ECS 對於 mount volume 只有 Docker 的實作，而 Kubernetes 的實作包含了兩個，一個是 controller + CRI（通常都是用 Docker）的實作。所以最大問題就來了， ECS 最一開始 volume 要 assign 到哪一個 node 上要怎麼決定？在 ECS 對於 worker node 都是以 Auto Scaling Group 的做法， user-data 的方法很在多台 node 下的 cluster 明顯是有問題的。

	如何 assign volume 到 worker node	如何 mount 到 container 裡
ECS	user-data or 自己手動	Docker 實作
EKS	master node 上的 AttachDetachController	worker node 裡 kubelet 的 VolumeManagerReconciler

（不過最近 ECS 正在推出 EFS storage ，教學文傳送門在此，雖然沒有實際實驗過，看起來是為了 application 不一定非要綁死特定的 node 上而設計的，目前正在 beta 版中。）

或許會問，不論是 secret、message queue 或 cache 也好，這些其實都有 AWS 現成的服務，為何不選用呢？原因不外乎別的，就是成本考量。而 Kubernetes 有個蓬勃發展的生態圈，像是 Helm 也是讓很多管理人員省下不少事，而雖然 Helm 很方便，但需要 debug 的時候還是得了解其原理才行。幸好我在 ECS 架設 Vault、Redis 以及 Rabbitmq 時已經了解不少，畢竟要是不了解根本無法在 ECS 上「完美的」架起來，因為有點追求完美的個性，會希望即使關機也能夠快速恢復，但又因為 ECS 的特性，最後真的用得很不俐落。

還有一點推力是 ECS & EKS 本是同根生，同樣都是使用 container 技術， migrate 非常容易，code 不需要做任何變更，所以完全不會影響開發進度。

原本我們只有兩個環境，當增長到三個環境時候發現，手動建置整個環境非常勞累，綜合上述的總總，是時候該還技術債了。

而為什麼我們選擇 EKS 而非搬到 GCP 上？除了我們已經有很多像是 IAM 的權限、網路 VPN 以及 ECR 的服務之外，最殺手級的主因是 AWS CDK。

What & Why AWS CDK?

AWS CDK 是專門定義 AWS resources 的 IaC 工具，他支援多種語言像是 TypeScript、Python、JAVA 等等，也陸陸續續有新的語言支援，而 AWS CDK 最大的罩門就是目前只限於 AWS resources。其實 AWS 原本就有 IaC 工具為 CloudFormation ，而 AWS CDK 再往上做一層抽象層，所以 AWS CDK 實際要執行的時候，最後 generate 出來的其實就是 CloudFormation 的格式。另外 AWS CDK 可以使用原本熟悉語言的特性，和這個工具本身就是 AWS 自己的產品，理應會得到 AWS resource 自身最好的整合，這也是我最後不選擇 Terraform 的原因。

我本身對於 IaC 就一直非常想要導入， IaC 好處非常得多，像是快速部屬多個環境、減少不一致性、增加 Infra 透明度、版本控管、減少人工手動建設的時間（節省人力成本）等等好處。另外還有一些個人的原因就是我想一些寫程式的實戰經驗，其他人寫程式不外乎就是寫爬蟲、網站或聊天機器人，可是這些我真的沒興趣，寫 IaC 就是比較可以給我成就感，或許只有我這麼怪異吧？

另外 AWS CDK 是 open source project，有覺得不符合預期行為的地方，都可以去翻 code 是不是 bug ，或提出自己新 feature 的想法。 AWS CDK 由 AWS 自己主導外，也歡迎所有有志之士一起貢獻，例如目前只會開 issue 的我。

Manager support

當我把這個計劃提出後，主管算蠻支持的，除了把遇到的難題跟未來的瓶頸講清楚，以及這樣 refactor architecture 的好處是什麼，不過只要服務不中斷以及 billing 成本不要上升（其實很難，尤其 EKS control plane 又有另外收管理費的錢，只能從 spot instance & EKS Fargate 著手了），基本上主管都放手讓我去做。

Conclusion

ECS 不太適合使用 stateful services 所以遷移到 EKS 上
Kubernetes 生態圈可以快速對整個系統做客製化
IaC 好處很多，且工具有許多選擇
AWS CDK 確切的符合我們的需求，再加上是 open source project
主管的目標導向要先了解，符合他們的需求後再做導入