Wei-Yu Chen’s Blog

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.

Within Amazon EKS, we use IAM Role for Service Account (IRSA) or EKS Pod Identity to grant applications permission to call AWS APIs. While Pod Identity Agent won't be covered in this article, we'll explore how IRSA works in your EKS cluster. Understanding this feature better will help you troubleshoot issues when they arise.

Applications running in your cluster may need to call AWS APIs to manage AWS resources. For example, when you install an EKS Add-on like the EBS CSI Controller, it needs to interact with AWS APIs to perform tasks such as mounting EBS volumes to EKS worker nodes. The kubelet can then mount these volumes into Pods via the Container Storage Interface.

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:

Firstly, determine whether to use a Classic Load Balancer or a Network Load Balancer. In terms of installation, when an AWS Load Balancer Controller exists within the cluster, your Nginx Ingress Controller will be created as a Network Load Balancer (NLB). If the AWS Load Balancer Controller does not exist, then the controller will be deployed as a Classic Load Balancer Controller (CLB). As CLB is referred to as a previous generation load balancer by the AWS official guide [1], it is no longer recommended for use.

Regarding my experience and impression of using NeMo-Guardrails, what struck me most was its user-friendly nature. The development team provided several examples that guide users step-by-step to quickly understand the core functionalities of this framework. Moreover, NeMo-Guardrails allows users to customize dialogue flows (referred to as "flow" within NeMo-Guardrails), enabling the design of conversation processes for different scenarios. It also includes functionalities for input and output checks (self input/output check), allowing GPT to self-examine whether the input or output is valid and help detect some prompt-injection attempts. Lastly, NeMo-Guardrails introduces the concept of Retrieval-Augmented Generation (RAG) to generate conversations. By establishing a knowledge base (kb, knowledge base), it allows the language model to produce accurate results based on relevant documents…

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 is a tool designed by AWS for Kubernetes clusters. It scales the cluster based on the workload of worker nodes (instances). Karpenter has several features and functions:

Migration Assistant made moving an Intel Mac's environment to an Apple Silicon MacBook look almost effortless. The problem appeared later: familiar development tools no longer behaved as expected, and even an attempt to run AutoGPT led to environment problems.

These notes record the two migration issues I investigated: Intel applications carried over unchanged, and the difference between Intel and Apple Silicon Homebrew installations.

This walkthrough builds a complete experimental 5G mobile network using the open-source free5GC core and UERANSIM, a simulator for user equipment and radio access. After starting both sides, the final check is an established PDU session and successful connectivity.

The commands document the December 2020 lab, including free5GC v3.0.4, Go 1.14.4, and the UERANSIM interface available then. They are retained as a historical procedure, not silently replaced with commands for a different generation of the software.

While integrating services, I used gRPC for application-to-application communication. An HTTP API would also make development and testing easier: a quick cURL request is more convenient than writing a gRPC client for every check.

grpc-gateway provides that bridge. It generates an HTTP reverse proxy that translates REST-style requests into calls to a gRPC service.

The pipeline now builds and deploys the blog, but a successful deployment is not the same as a working website. Hexo and its theme support many hosting environments, and some defaults did not match the S3 and CloudFront arrangement in this series.

Before publishing, I checked the site's buttons and links individually. This follow-up records the remaining problems: confusing error responses, directory links without trailing slashes, and configuration that should not live in a public repository.

Once CodePipeline and CodeBuild are connected, a new commit can trigger a build and place the generated files in S3. There are still several pieces needed for a comfortable browsing experience: a domain name, HTTPS, delivery through CloudFront, and working directory-style links.

This part explains the original S3 and CloudFront setup, including the small Lambda@Edge function used to rewrite requests for nested index pages.

With CodePipeline configured, the source retrieved from GitHub appears in the artifact bucket as a ZIP archive. The next step is to tell CodeBuild how to turn that source into the website. Those instructions belong in buildspec.yml.

A buildspec describes the commands used to build and test a project, much like a Jenkins Pipeline script. CodeBuild normally looks for buildspec.yml in the source root:

After working with CI/CD, I came across AWS CodePipeline and had a simple idea: when I commit a new article to GitHub, why not let the site rebuild and publish itself? Hosting the generated files on S3 would also remove the need to maintain a VPS.

That small idea eventually grew into a pipeline involving CodePipeline, CodeBuild, S3, Route 53, CloudFront, Lambda, and IAM. This first part explains how the pipeline fits together, how to create it, and why its service roles need access to the artifact bucket.