I spent some time researching how to deploy the Nginx Ingress Controller to an EKS cluster. Firstly, we can decide how to use the Nginx Ingress Controller, and you have several different choices:

1. CLB or NLB: Deploy the controller as either a Classic Load Balancer or a Network Load Balancer category.
2. Public or Private: The load balancer is either publicly accessible or private access only (only accessible within your VPC network).
3. HTTP or HTTPS: Whether to configure SSL, allowing encrypted connections between the client and the Load Balancer.

花了一點時間研究了如何將 Nginx Ingress Controller 部署到 EKS 叢集當中。首先，我們可以決定要怎麼使用 Nginx Ingress Controller，你有幾種不同的選擇：

1. CLB or NLB：將控制器部署為 Classic Load Balancer 或 Network Load Balancer 類別
2. Public or Private：負載均衡器是可公開存取的或是僅能私有存取（只有位於你的 VPC 網路內才能夠存取）
3. HTTP or HTTPS：是否要配置 SSL，讓客戶端到 Load Balancer 之間有加密連線

This article primarily introduces the core operational process of Karpenter, including how Karpenter filters Pods that need to be scheduled and the actual process of scheduling Pods onto worker nodes.

這一篇文章中，主要介紹了 Karpenter 的核心運作流程，包含 Karpenter 如何過濾需要被規劃的 Pod，以及實際 Pod 被規劃到工作節點上的過程。

設定好了 CodePipeline 與 CodeBuild 之後，我們在 push 新的 commit 到 GitHub 時，應該可以看到 CodePipeline 被觸發，接著啟動了一連串的建置流程，並且把成品部署到 S3 bucket 當中。不過，現在的網站還不算完成，雖然可以透過 AWS S3 的 endpoint 存取到內容了，但是不僅不方便使用者存取，SEO 的排名也不會上去。因此，我們會透過 Route53、CloudFront 與 lambda 來加強網站的使用者體驗。

到了現在，我們已經部署好我們的 AWS CodePipeline，如果你到放置建置檔案的 Bucket，應該可以看到 CodePipeline 從 GitHub 拉過來的程式碼，程式碼用 zip 的方式保存。在 pipeline 建立好之後，我們接下來要撰寫 Build spec，因為 CodeBuild 會根據 spec 的內容來依序執行由我們定義的建置步驟。

故事是這樣子的，有了 CI/CD 的經驗之後，無意之間逛到 AWS CodePipeline 時，腦海中靈光一現，假設我在寫好新文章時，把文章的原始碼 commit 到 GitHub 的版本控制庫後，能夠自動更新到我的網站上的話就太方便了。

不僅如此 …