穿越到 GKE 異世界也到了第 30 天了，在 GKE 異世界 30 天的旅程中，我與 Terraform 和 IAM Workload Identity 這兩位可靠的夥伴形影不離。我們探索了 Cloud DNS，體驗了 GCP 原生的 NEG Ingress、Nginx Ingress，並預覽了未來的 Gateway API，也順道拜訪了 APISIX。為了確保網路安全，我們使用了 Google Trust Services 證書和 Cert-manager；為了強化 GKE 安全性，我們倚賴 Teleport 和 External Secrets Operator。
旅程中，由於儲存空間不足，我們添購了 Filestore 和 Cloud Storage。在造訪 Grafana 時，我們通過了 GCP OAuth API 的驗證。隨後，我們踏入了 GPU 的領域，先透過 Kueue 排隊，學習如何有效分配 GPU 資源。最後，在旅程的尾聲，我們得以一窺 GKE Fleet 的宏偉架構。
一年多前，我將 Kubernetes 叢集從 Amazon EKS 遷移到 Google Kubernetes Engine (GKE)。雖然 EKS 和 GKE 都基於開源的 Kubernetes，但在功能、整合性以及操作體驗上，兩者存在顯著差異。為了幫助其他面臨類似遷移挑戰的使用者，我決定撰寫一篇教學文章，提供完整的遷移指南，並分享一些學習方向和注意事項，讓讀者能順利完成遷移，並充分發揮 GKE 的優勢。
在過去一年使用 Google Cloud Platform (GCP) 的過程中，我發現 GCP 相較於其他雲平台，在某些方面更為強大，例如豐富的網路設定選項。GKE 提供了更多可調整的參數，甚至支援跨雲的 Kubernetes 叢集整合。然而，更多的設定彈性也意味著更高的複雜度，更容易遇到一些意想不到的狀況。這篇文章旨在引導讀者避開這些潛在的陷阱，並順利完成 EKS 到 GKE 的遷移。
當初決定報名這個活動時，內心真是百感交集。一方面，我渴望挑戰自我，希望能藉此機會提升寫作能力，建立持續創作的習慣；另一方面，我又深怕自己缺乏恆心與毅力，無法堅持每日更新，尤其系列文章的壓力更是讓我卻步。
如今，一個月的光陰轉瞬即逝，我竟然真的完成了！回首這段旅程，我心中充滿了難以言喻的感動和成就感。我克服了內心的恐懼和惰性，實現了當初許下的諾言，完成了看似不可能的任務。
首先，感謝 Palup SRE 的夥伴們，Yoga, Alson 及 Will，這一系列文章介紹的內容，很多都是他們幫忙引進的項目，更重要的是，他們將這些技術融入到 Palup 的日常運維中，並根據實際情況不斷調整和優化，確保系統的穩定性和可擴展性。
可惜的是，我們的鐵人賽只有 30 天，礙於篇幅，這 30 天的內容僅僅觸及 GKE 的冰山一角，許多實用的功能尚未來得及介紹，例如：CI/CD, GKE Monitoring, Service Mesh 等，但是對於 GKE 有興趣的讀者也別失望，之後我會持續撰寫 GKE 系列文章，敬請期待！
iThome鐵人賽
看影片追技術