在開發了微服務之後,我們進行了容器化,以容器形式運行微服務應用
其中微服務應用會有很多個,甚至有複製(replica)的實體容器
這些可以簡單部署到裝有docker的EC2的機台上面:
但是困難的問題來了
該怎麼管理!?
- 機台上還有多少可用的資源?
- 哪一台適合拿來部署下一個容器應用?
- 是否有容器應用掛了?(可能資源不夠等問題),然後還要手動重啟嗎?
- 假設有個容器應用replica成5個,如何設置load balanceing?如果有replica 50的容器應用要移除時,該怎麼做比較好!?一個個移除!?或是客製化一個shell腳本!?
- 假設有10個replica,我該上哪知道它其實應該要50還是10!?決定該多少定義在哪?
不管10個容器還是100個容器,都需要有管理
所以我們需要Automation Tool — Container Orchestration Tool
Container Orchestration Tool
=Managing,scaling and deploying containers
其中最知名的就是Kubernetes:
其他還有很多類似的工具:
接著會簡單介紹甚麼是ECS
Elastic Container Service(ECS)
- 容器編排(Orchestration)服務
- 管理整個容器的生命週期(start,re-schedule,load balance)
ECS如何運作?
- 運行容器化應用程式叢集在AWS上
- 需要先建立由AWS管理的ECS Cluster
- 其中ECS叢集包含所有管理容器的服務,並透過Control Plane管理
- 其中Control Plane在叢集建立時就會有,並提供re-scheduling,Orchestration等服務
- 但是其中被管理的應用程式容器需要運行在某處,也就是EC2機台上
- 而這些EC2機台上的容器都將統一被ECS的Control Plane控管
- 這些EC2機台還是需要另外管理
- 並且這些EC2機台需要安裝Container Runtime(如docker)及ECS Agent
ECS與EC2機台:
- ECS的host即是那些EC2機台,並且管理其上的容器
- 但是還是需要人力去管理這些EC2機台(例如要人力去建立EC2機台)
- 然後人為進去設定使其加入ECS叢集
- 人為檢查是否有足夠資源
- 人為管理裡面的OS
- 人為安裝維護剛剛提到的Container Runtime與ECS Agent
- 但是就代表有完全的基礎設施掌控
ECS with Fargate
如果想將那些基礎設施的管理也交給AWS來搞?
也就是
- 容器編排(Orchestration)交給AWS
- Hosting Infrastructure Management也交給AWS
- 原本是自建EC2後納入ECS叢集
- 改由Fargate的實例納入ECS叢集
AWS的Fargate如何運作?
- 他是無伺服器(Serverless,)建立容器
- 不再需要自行建立或提供伺服器
- 只要請求Fargate運行容器就好
- 並且Fargate就會自行查看這個容器要多少資源(CPU/MEM/Storage…)來運行
- i.e.不用供應與管理伺服器了
- 只要給要求給Fargate就夠了
- 這帶來的好處即是只會需要足夠的基礎設施資源來提供給容器運行
- 只要為這些需要的資源付錢就好!
- 很容器擴展而不需要調整資源配置
接著可能會問Fargate怎麼收費:
- 依據使用的時間收費
- 被佈署上的容器吃掉多少CPU與Memory而定
以自建EC2來說要付整台Server的錢
EC2即便上面沒有運行各種應用程式也要花錢
也就是使用了Fargate就代表你的基礎設施(Infrastructure)也交由AWS管理
所以當ECS+Fargate即代表:
- Infrastructure是由AWS管理(Fargate)
- 容器也是由AWS管理(ECS)
- 最終只要專心於應用程式怎麼建立,然後打包成image
- 並且可以串接各種AWS服務
可串接的各種AWS服務有:
- CloudWatch for Monitoring
- Elastic Load Balancing for LoadBalancing
- IAM for Users and Permissions
- VPC for Networking
- …etc
而現在越來越多傾向直接使用Kubernetes的解決方案
市佔也是最高的
若在AWS上面是否可以使用Kubernetes呢?
答案就會是EKS這個AWS上的解決方案
由其建議的是已經有在使用Kubernetes相關解決方案
不論是地端Kubernetes或是GCP,Azure等Kubernetes要轉移到AWS
都更是建議使用EKS,而非ECS
但是都要注意這類升級到不同平台都一定是困難的
ECS稍微比EKS適合的場景大概是針對較沒那麼複雜的使用場景
以及ECS的control plane不用收費
EKS如何運作?
當建立了EKS叢集後,AWS就會在背後自動建立master node
並且這些master node上會安裝好Kubernetes必要元件
符合High Availability-Master Nodes replicated across Availability Zones
而針對Kubernetes的Worker Node部分
1.EKS與EC2機台(完全自己管理):
首先要先建立EC2的機台,這邊稱之為Compute Fleet
建立許多台,讓EKS連線到這類機台
相比於ECS要在EC2上面自行加裝Docker Agent與ECS Agent
EKS的Worker Node也就是Compute Fleet則要加裝
除了Docker Agent外再加上K8s Processes
也就是要自行管理EC2來當作Worker node
2.EKS與Nodegroup(半管理):
另外EKS有一層叫Nodegroup,提供半管理式的worker node管理
Nodegroup設置下可以統一建立,移除EC2 instance
以及統一安裝Container Runtime(但是這要自己做設定)
但是要記得的是,這仍未包含worker機台的自動擴展
3.EKS與Fargate(完全託管):
透過Fargate實現完全託管的worker node機台
4.甚至於可以EKS搭配EC2+Fargate等組合
實際概念可以達到如下圖
實際建立EKS Cluster的步驟
- 建立EKS Cluster:此時AWS會依據設定協助建立出Master Node
- 建立EC2機台群的Nodegroup:以此方式建Worker Node不論幾百幾千台
- 連線上述Nodegroup至EKS Cluster(或是第二步改Fargate,也是要設連線)
- 使用kubectl工具連線到EKS的Cluster開始部署容器應用
Elastic Container Registry(ECR)
前面描述了兩個關於容器應用的AWS服務
- ECS
- EKS
還有另一個服務即是ECR,就是存放Docker image的地方
並且也比較方便與ECS及EKS整合(較容易設置)
