Lately I have been hitting situations where containers overload the system disk on my EKS nodes. Once the root disk maxes out its throughput, the operating system freezes, CPU usage spikes, and the node drops into NotReady. Even worse, the node stops accepting SSH, so I cannot inspect what actually went wrong. Kubernetes will eventually reschedule the Pods, but only after the node has stayed in NotReady for five minutes.

To keep this from happening again, I split the system disk and the container data disk into two separate EBS volumes so that container workloads always land on the second volume.

最近碰到在 EKS cluster 中，容器對系統磁碟的壓力過大狀況，這種情況會因為系統磁碟效能達到上限，作業系統無法正常運作，CPU 使用率飆高，最後節點進入 NotReady 狀態。尤其，在這種情況發生時，我們只能看到節點處於 NotReady 狀態，無法觀測到是哪一個部分出了問題，同時，因我們也沒辦法連入節點了。儘管 Kubernetes 具備自動恢復的能力，但在節點 NotReady 過了五分鐘後，才會將 Pod 刪除並重新部署到 EKS cluster 當中。

為了避免這個反覆發生，我把節點的系統磁碟和容器資料磁碟拆開為兩個 EBS 磁區，以確保容器只會使用第二顆 EBS volume。

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 的版本控制庫後，能夠自動更新到我的網站上的話就太方便了。

不僅如此 …