Blue Matador在比較了各種特性之後，將他們的Kubernetes基礎設施從AWS實例上的kops託管集羣遷移到了AWS的託管Kubernetes服務EKS。他們選擇EKS是因爲它有更好的安全模型、託管控制平面，而且可以降低他們特定用例的成本。在創建一個新的Kubernetes集羣方面，kops是贏家，而EKS在集羣管理和安全性方面得分更高。InfoQ聯繫了Blue Matador的軟件工程師Keilan Jackson，進一步瞭解他們的經驗。
EKS的共享責任模型及其託管控制平面是遷移的主要原因。在EKS之前，Blue Matador團隊在3個c4.large AWS實例上運行他們自己的Kubernetes主節點。Kubernetes的升級——包括Bug修復和安全補丁——都由團隊負責。因爲基礎設施在AWS內部，所以AWS仍然提供了一個安全層，但是他們必須自己管理Kubernetes的特定安全問題。在私有網絡、加密根卷和安全組控制等資源方面，Jackson寫道：“使用kops創建的Kubernetes集羣的默認設置和EKS非常類似。”使用EKS設置一個新的集羣需要做一些準備工作，但是，初始設置完成後，EKS使集羣管理更容易。
Blue Matador主要使用Terraform來管理他們的AWS資源。Terraform實現了跨雲提供商的多種資源類型，但現實世界的使用情況揭示了其中的挑戰。Jackson談到了他們面臨的EKS特有的挑戰：
我儘量利用社區構建的EKS模塊。我遇到的主要問題是使用了AWS提供程序和Terraform的過期版本，然後將這個模塊中的託管資源連接到我的外部託管資源，比如我們的主ALB、RDS實例等等。我建議從配置EKS的模塊中輸出一些Terraform變量，這樣就可以在其他模塊中引用它們，如下所示：
output “worker_role_arn” {
value = “${module.eks_cluster.worker_iam_role_arn}”
}
雖然Terraform可以很好地創建和管理EKS集羣，但是後者依賴於相互關聯的外圍資源。Jackson提供了詳細的闡述：
除了運行EKS集羣本身之外，EKS還需要大量的資源。您必須配置工作節點、安全組、VPC網絡，並計劃好在EKS提供新版本Kubernetes支持時進行更新。如果可能的話，一定要使用社區模塊，因爲它有助於正確連接這其中的許多基本資源，但是請記住，務必要按照您的安全需求仔細檢查設置。例如，確保安全組只對需要它們的東西開放，確保工作節點不會獲得公共IP地址，確保使用加密的AMI作爲根設備。
在談到集羣規模時，Jackson說，“集羣的總大小還沒有達到我們不得不在kops集羣中使用超過3個主節點的程度，但重要的是，我們能夠快速、輕鬆地擴展節點，並在Kubernetes新版本發佈時更新到新版本。”
託管Kubernetes服務通常與他們平臺的監控解決方案集成在一起。Jackson解釋了他們如何監控他們的集羣：
我們主要依靠自己的產品Blue Matador實現Kubernetes集羣報警。它會發現一些不健康的部署、關鍵節點事件、pod內存耗盡等問題，並幫助我們監視集羣的利用率。我們還使用Datadog，但僅用於繪製幾個自定義指標。我們關注Amazon EKS的CloudWatch容器洞察，但通常，CloudWatch對Kubernetes而言不夠活躍，因此，我不會依賴它來進行生產環境報警。
遷移還降低了團隊的基礎設施和監控成本。
查看英文原文：Migrating From Self-Managed Kubernetes to AWS EKS Using Terraform at Blue Matador