I wanted it simple. I made it simple. Then I discovered that making it actually useful meant adding feature after feature. What started as building blocks became an entire castle.

The Beginning: A Simple Idea

On November 30, 2025, I made my first commit: amcp agent init. In the README, I described it like this:

A Lego-style coding agent CLI with built-in tools (grep, read files, bash execution) and MCP server integration for extended capabilities. Lego-style—that was my north star. I envisioned a coding agent that worked like Lego bricks:

• Minimal core: Just grep, read_file, and bash—the essentials

• Composable: Extend capabilities through the MCP protocol

• Lightweight: Only 2,482 lines of Python

• Few dependencies: Just typer, rich, pydantic, mcp, and openai And I succeeded. The initial AMCP was a clean, focused CLI tool:

src/amcp/
├── agent.py       # 620 lines - Main agent loop
├── tools.py       # 511 lines - Tool definitions
├── chat.py        # 579 lines - Conversation handling
├── cli.py         # 265 lines - CLI entry point
├── config.py      # 169 lines - Configuration loading
├── mcp_client.py  # 102 lines - MCP integration
└── readfile.py    #  47 lines - File reading

Simple. Beautiful. Complete. Or so I thought.

Turning Point #1: The Context Window Explodes

Two weeks after launch (December 14, 2025), I hit my first real problem: context window overflow. When an agent works on complex tasks, conversation history grows indefinitely. My initial solution was brutal—just keep the last 20 messages. But that meant the agent would "forget" critical context from earlier in the session. I had no choice but to add compaction.py (+155 lines):

# 467d72b: feat: add context compaction
class Compactor:
    """Intelligently compress conversation history while preserving key information."""

This was the first "mandatory brick." Without it, the agent couldn't complete complex, multi-step tasks.

Turning Point #2: Not Everyone Uses OpenAI

Two days later (December 16, 2025), reality knocked again: not everyone uses OpenAI.

a9455d5: feat: add support for ACP
fb6b08c: add anthropic and open_response LLM format support

This added 2,709 lines of code:

• acp_agent.py: 752 lines (Agent Client Protocol support)

• Anthropic Claude integration

• OpenAI Responses API format support What started as a simple openai.chat.completions.create() call was now a multi-headed abstraction layer. Different APIs, different formats, different quirks—all needing adaptation.

Turning Point #3: One Agent Isn't Enough

On Christmas Day 2025, I realized that complex tasks need multiple agents working together:

e61bba1: add multiple agents
5e58fc3: add TaskTool and EventBus

This added 2,246 lines of code:

• multi_agent.py: 375 lines

• message_queue.py: 531 lines

• event_bus.py (eventually grew to 635 lines)

• task.py (now 859 lines) The jump from single-agent to multi-agent was a qualitative shift. My Lego bricks were becoming a castle.

Turning Point #4: Users Need Extensibility

Between December 28, 2025 and January 2, 2026, I added two extensibility systems:

d746a8c: feat: add Hooks system for extensible agent behavior (v0.5.0)
17eeeb3: feat: add skills and commands system for agent extensibility

The Hooks system (+886 lines) lets users inject custom logic before and after tool execution. The Skills and Commands system (+836 lines) enables dynamic capability loading. I initially thought these were "nice to have." But when I started actually using AMCP for real work:

• Dangerous operations needed validation → PreToolUse hooks

• Everyone on the team had their own workflows → Commands

• Different projects needed different expertise → Skills Features I thought were optional turned out to be essential.

Turning Point #5: Production Needs a Server

January 7-9, 2026 brought the biggest refactor:

7f0ac35: feat: init C/S architecture
52c93c2: feat(server): complete Phase 2 - streaming & events
af7ce69: feat: complete Phase 3 - CLI Client SDK
f923591: feat: protocol and sessions

This added 3,266+ lines of code:

• HTTP/WebSocket server

• Session management

• Event broadcasting system

• Multi-client support

• Protocol adaptation layer Why? Because:

• IDE integration requires persistent connections

• Multiple clients need shared sessions

• Real-time streaming requires WebSocket

• Enterprise deployment requires a service architecture

The Numbers Tell the Story

Here's a before-and-after comparison:

Growth Timeline

2025-11-30  ████                           Initial version (2.5K lines)
2025-12-14  █████                          + Context Compaction
2025-12-16  ████████                       + ACP + Multi-LLM Support
2025-12-25  ████████████                   + Multi-Agent + EventBus
2025-12-28  ██████████████                 + Hooks System
2026-01-02  ████████████████               + Skills & Commands
2026-01-07  ████████████████████           + C/S Architecture
2026-01-09  █████████████████████████      Current version (20K+ lines)

Why "Simple" Doesn't Last

Looking back at 40 days of development, I've identified four reasons why simplicity was impossible to maintain:

1. Reality Is More Complex Than Your Imagination

I initially thought read_file + grep + bash would be enough. Reality disagreed:

• Large files need chunked reading → smart readfile modes

• Large-scale edits are error-prone → apply_patch tool

• Complex refactoring needs planning → todo tool

• Dangerous operations need confirmation → permission system

2. User Needs Are Incremental

At first, I was the only user. Then others started using it:

• "Can you support Claude?" → Multi-LLM support

• "Can I use this in Zed?" → ACP protocol

• "Can multiple agents collaborate?" → Multi-Agent architecture

• "Can I customize workflows?" → Skills & Commands

• "Can I deploy this as a service?" → C/S architecture Every request was reasonable. Every feature became necessary.

3. Production Requires Robustness

Toys can be simple. Production systems must:

• Handle edge cases

• Manage resource lifecycles

• Support concurrent access

• Provide monitoring and debugging

• Guarantee type safety These "non-functional requirements" often require more code than the features themselves.

4. Composability Requires Infrastructure

Here's the irony: to achieve true "Lego-style" composability, you need:

• A unified tool interface → BaseTool abstraction

• A message passing mechanism → EventBus

• Lifecycle hooks → Hooks system

• Dynamic loading → Skills system

• Configuration management → Complex config layer The infrastructure for composability is itself a source of complexity.

What I Learned

1. "Lego-Style" Is a Philosophy, Not a Destination

Lego bricks look simple. But Lego the company has thousands of different parts, strict quality standards, and a sophisticated design system behind those "simple" blocks. AMCP is still "Lego-style"—its design still prioritizes composability. But achieving composability requires significant complexity.

2. Complexity Is Necessary, But Must Be Managed

The codebase grew 8x, but if you look closely, complexity is distributed:

• Core agent logic remains relatively simple

• Complexity is encapsulated in individual modules

• Modules communicate through clean interfaces Complexity is inevitable, but it can be isolated.

3. Incremental Evolution Is the Right Path

If I had tried to design a 20,000-line system from day one, I would have:

• Built features nobody actually needed

• Optimized the wrong things too early

• Lost the ability to iterate quickly By starting simple and solving only "the most painful problem right now," AMCP evolved into something actually useful.

Conclusion: Did I Really "Fail"?

So, did I actually fail? If the goal was to stay at 2,500 lines of code—yes, I failed spectacularly. But if the goal was to build a coding agent that actually works in production—then I succeeded. The price of success was accepting that complexity is unavoidable. "Lego-style" isn't about simplicity. It's about the right abstractions, clear boundaries, and composable design. AMCP still has those.

Written on January 10, 2026AMCP v0.8.0 | 58 commits | 20,176 lines of code

In January 2026, I encountered a series of cryptic authentication errors while publishing an npm package. This post documents the complete journey from problem discovery to final resolution—hopefully saving others from the same headaches.

Background

I maintain an npm package called amp-acp, an adapter that bridges Amp Code to the Agent Client Protocol (ACP). The project uses GitHub Actions for automated releases: pushing a v* tag triggers automatic publishing to npm and creates a GitHub Release.

The Problem

Starting with v0.3.1, every publish attempt failed. The GitHub Actions logs showed:

npm error code ENEEDAUTH
npm error need auth This command requires you to be logged in to https://registry.npmjs.org/
npm error need auth You need to authorize this machine using `npm adduser`

Even more confusing was this warning:

npm notice Security Notice: Classic tokens have been revoked. 
Granular tokens are now limited to 90 days and require 2FA by default. 
Update your CI/CD workflows to avoid disruption. 
Learn more https://gh.io/all-npm-classic-tokens-revoked

Root Cause Analysis

The End of npm Classic Tokens

After investigation, I discovered that npm permanently deprecated all Classic Tokens on December 9, 2025. According to the GitHub official announcement:

• All existing npm classic tokens have been permanently revoked

• Classic tokens can no longer be created or restored

• New Granular tokens have a maximum validity of 90 days and require 2FA by default

This means the traditional approach of storing NPM_TOKEN in GitHub Secrets is no longer viable (at least not as convenient as before).

The New Authentication Method: OIDC Trusted Publishing

npm's recommended solution is OIDC Trusted Publishing. This OpenID Connect-based authentication mechanism offers several advantages:

1. No token management – No need to create, store, or rotate tokens

2. Enhanced security – Uses short-lived, cryptographically signed, workflow-specific credentials

3. Automatic provenance – Automatically generates provenance statements, providing build-origin transparency

4. Industry standard – Aligns with PyPI, RubyGems, crates.io, and other major package registries

Troubleshooting Log

Attempt 1: Upgrading npm Version

Initially, I assumed the issue was an outdated npm version, so I added this to the workflow:

- name: Update npm to latest
  run: npm install -g npm@latest

Result: Failed ❌

Attempt 2: Removing registry-url

Someone suggested removing the registry-url parameter from actions/setup-node:

- uses: actions/setup-node@v4
  with:
    node-version: '22'
    # Removed registry-url

Result: Failed ❌

Attempt 3: Setting NODE_AUTH_TOKEN to Empty String

Based on some outdated resources, I tried setting NODE_AUTH_TOKEN to an empty string:

- name: Publish to npm
  run: npm publish --access public
  env:
    NODE_AUTH_TOKEN: ''

Result: Failed ❌

Here's the critical misconception: setting an empty NODE_AUTH_TOKEN actually prevents OIDC from working, because npm attempts to use the empty token instead of OIDC.

Attempt 4: Completely Removing NODE_AUTH_TOKEN

I finally realized that for OIDC Trusted Publishing, NODE_AUTH_TOKEN should not be set at all:

- name: Publish to npm
  run: npm publish --access public
  # Note: no env section

Result: Partial success ⚠️

This time OIDC authentication started working (logs showed Signed provenance statement), but a new error appeared:

npm error 422 Unprocessable Entity - PUT https://registry.npmjs.org/amp-acp - 
Error verifying sigstore provenance bundle: Failed to validate repository information: 
package.json: "repository.url" is "", expected to match 
"https://github.com/tao12345666333/amp-acp" from provenance

Attempt 5 (Final Success): Adding the repository Field

It turns out npm's Provenance validation requires package.json to include a repository field matching the GitHub repository:

{
  "name": "amp-acp",
  "version": "0.3.7",
  "repository": {
    "type": "git",
    "url": "https://github.com/tao12345666333/amp-acp"
  }
}

Result: Success! ✅

The Correct Configuration

1. Configure Trusted Publisher on npmjs.com

First, configure Trusted Publisher on the npm website:

1. Navigate to https://www.npmjs.com/package/YOUR_PACKAGE/settings

2. Find the "Trusted Publisher" section

3. Select "GitHub Actions"

4. Fill in the following:

   • Organization/User: Your GitHub username or organization name

   • Repository: Your repository name

   • Workflow filename: The workflow file name (e.g., release.yml)

   • Environment: (Optional) If using GitHub Environments

2. GitHub Actions Workflow Configuration

name: Release

on:
  push:
    tags:
      - 'v*'

permissions:
  id-token: write   # Required for OIDC authentication
  contents: write   # Required for creating GitHub Release

jobs:
  release:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '22'
          registry-url: 'https://registry.npmjs.org'

      - name: Update npm to latest
        run: npm install -g npm@latest

      - name: Install dependencies
        run: npm ci

      - name: Publish to npm
        run: npm publish --access public
        # Note: Do NOT set NODE_AUTH_TOKEN!

      - name: Create GitHub Release
        uses: softprops/action-gh-release@v2
        with:
          generate_release_notes: true

3. Required package.json Fields

{
  "name": "your-package-name",
  "version": "x.y.z",
  "repository": {
    "type": "git",
    "url": "https://github.com/YOUR_USERNAME/YOUR_REPO"
  }
}

Key Takeaways

1. npm Classic Tokens are dead – As of December 9, 2025, all classic tokens are permanently invalidated

2. OIDC Trusted Publishing is the new standard – No token management, enhanced security, built-in provenance

3. Do not set NODE_AUTH_TOKEN – For OIDC, this environment variable should not be set at all

4. Configure Trusted Publisher on npmjs.com – This step is often overlooked

5. package.json must include the repository field – Required for provenance validation

6. Ensure id-token: write permission – Otherwise, OIDC token generation will fail

7. npm CLI version requirement – Requires npm 11.5.1 or later

FAQ

Q: Can I use OIDC to publish the first version of a new package?

A: No. The first version must be published manually or using a traditional token. Trusted Publisher can only be configured afterward.

Q: Can I use OIDC with self-hosted runners?

A: Currently, only GitHub/GitLab-hosted runners are supported. Self-hosted runners are not yet supported.

Q: Why doesn't setting NODE_AUTH_TOKEN to an empty string work?

A: An empty string is still a value—npm will attempt to use it rather than falling back to OIDC. Only when this variable is completely unset will npm automatically use OIDC.

Q: What should I do if provenance validation fails?

A: Verify that repository.url in package.json exactly matches the GitHub repository URL (including case sensitivity).

References

• npm Trusted Publishing Documentation

• GitHub Changelog: npm classic tokens revoked

• npm Provenance Introduction

Written on January 4, 2026, based on the publishing experience of amp-acp project from v0.3.1 to v0.3.7.

Kubernetes, as we know, is a powerful platform for automating the deployment, scaling, and operations of application containers across clusters of hosts. However, for these containers, or rather 'Pods' as they are known within the Kubernetes realm, to effectively communicate and serve their purpose, a robust networking model is essential. Let's delve into the components that constitute networking in Kubernetes.

Firstly, we have "Communication between Pods on the same Node." This is the most basic level of networking within Kubernetes. Pods running on the same physical or virtual machine need to communicate with each other. Kubernetes uses the networking namespace and other isolation mechanisms provided by the underlying operating system to ensure that these Pods can connect efficiently and securely.

Moving a step further, we encounter the scenario of "Communication between Pods on different Nodes." As our applications scale, they span across multiple Nodes, creating a need for cross-node communication. Kubernetes abstracts the complexity involved in this process, ensuring Pods can communicate seamlessly, irrespective of their physical location within the cluster.

Next, let's talk about "Service." A Service in Kubernetes is an abstraction that defines a logical set of Pods and a policy by which to access them. This abstraction enables the decoupling of backend Pod implementations from the frontend services that access them. Services allow for stable, reliable communication pathways between different components of an application.

"Ingress and Egress" mechanisms in Kubernetes facilitate the management of incoming and outgoing traffic to your cluster. Ingress controls how external traffic reaches your services within the cluster, allowing you to define accessible URLs, load balance traffic, terminate SSL, and offer name-based virtual hosting. Egress, on the other hand, controls the outbound traffic from your Pods to the external world, ensuring that only authorized connections are made, thus enhancing the security of your cluster. Although Kubernetes does not have native Egress resources, some other components provide this implementation, such as Calico.

Lastly, we have "NetworkPolicy." This is a specification of how groups of Pods are allowed to communicate with each other and other network endpoints. NetworkPolicies are crucial for enforcing security rules and ensuring that only the intended traffic can flow between Pods, Services, and the external world.

These are the basic concepts that will be encountered when discussing Kubernetes networking. However, these concepts require some specific components to implement their functions.

Kubernetes Networking Components

The following are some of the main components.

CNI Implementations:

Let's start with the foundation of Kubernetes networking - the Container Network Interface, or CNI. The CNI is a specification and a set of tools that facilitate the configuration of network interfaces for containers. Kubernetes relies on CNI implementations to provide in-pod networking capabilities. These implementations, such as Calico, Flannel, and Cilium, to name a few, allow for a pluggable framework that supports a wide range of networking features including network segmentation, policy enforcement, and overlay networks. Choosing the right CNI implementation is critical as it influences the network performance, security, and scalability of your Kubernetes cluster.

For example, A few years ago, Flannel, which was widely used, did not provide network policy support. Therefore, if this CNI plugin is used, network policies cannot take effect.

However, in addition to the native NetworkPolicy of Kubernetes, Calico and Cilium have also implemented their own enhanced versions of network policy.

kube-proxy:

Moving on, we encounter kube-proxy, a vital component that runs on each node in the Kubernetes cluster. kube-proxy is responsible for maintaining network rules on nodes. These rules allow network communication to your Pods from network sessions inside or outside of your cluster. Essentially, kube-proxy enables the forwarding of TCP and UDP packets to pods based on the IP and port number of the incoming request. Through services, kube-proxy abstracts the IP addresses of individual pods, ensuring that the internal network structure is hidden from the external clients.

DNS:

In the realm of Kubernetes, DNS plays a pivotal role in service discovery. It allows Pods to locate each other and external services through human-readable names. When a Kubernetes cluster is created, a DNS service is automatically deployed, assigning DNS names to other Kubernetes services. This simplifies communication within the cluster, as Pods can reach each other and external resources using these DNS names, enhancing the overall application architecture's flexibility and robustness.

Controller:

Lastly, let's delve into the controller, particularly focusing on IPAM, and the Endpoint/EndpointSlice/Service mechanisms.

• IPAM (IP Address Management): This functionality is crucial for managing the assignment of IP addresses to Pods and Services. Efficient IPAM practices ensure that there is no conflict between the IPs assigned within the cluster, maintaining a smooth network operation.

• Endpoint/EndpointSlice/Service: These components work together to manage how external and internal communications reach the Pods. A Service defines a logical set of Pods and a policy by which to access them. The Endpoints and EndpointSlices keep track of the IP addresses of the Pods that are associated with each Service. This system ensures that network traffic is efficiently routed to the appropriate Pods, allowing for scalable and reliable application deployments.

Although they may appear complex, they all follow the most basic models.

Kubernetes Networking Model

The kubernetes networking model is ingeniously designed to ensure seamless communication within the cluster, which is pivotal for deploying scalable and resilient applications. Let's explore the core principles that define this networking model.

Each Pod has its own IP address:

The first principle to understand is that in Kubernetes, each Pod is assigned its own unique IP address. This is a significant departure from traditional deployments where containers or applications within a host might share the host's IP address. This unique IP per Pod simplifies application configuration and inter-service communication. It means that each Pod can be treated as if it's a physical host on the network, making network policies and communications more straightforward to manage.

All Pods can communicate across Nodes without the need for NAT

Components on the Node (e.g., kubelet) can communicate with all Pods on the Node:

These two rules have been introduced earlier, and they define how Pods are accessed.

How to Access Applications Deployed in Kubernetes

Let’s discuss How to Access Applications Deployed in Kubernetes

Deploying applications is only part of the journey. An equally crucial aspect is how these applications, once deployed, are made accessible to the outside world.

NodePort:

Let's start with NodePort, a simple yet powerful way to access your applications. When you configure a service as NodePort, Kubernetes exposes that service on each Node’s IP at a static port (the NodePort). A NodePort service is accessible by the IP of the Node it's running on combined with a high port number assigned specifically for that service. This means that anyone who can reach the Node, either within the internal network or from the outside world, can access the service by hitting the Node's IP at the designated port.

This method is particularly useful for development environments or smaller setups where direct access to each node is manageable. However, it's worth noting that managing access through NodePort can become challenging in environments with a large number of Nodes, as it requires keeping track of multiple IP addresses and ports.

LoadBalancer:

Moving on to a more sophisticated and widely used approach – LoadBalancer. This method integrates Kubernetes services with existing cloud providers' load balancers. When you create a service of type LoadBalancer, Kubernetes provisions a cloud load balancer for your service, and directs external traffic to it. This external load balancer then automatically routes the traffic to your Kubernetes Pods, regardless of which Node they're running on.

The beauty of using LoadBalancer is its simplicity and scalability. It abstracts away the complexity of dealing with individual Node IPs and ports, providing a single entry point – the load balancer's IP – to access your service. This makes it an ideal choice for production environments where reliability and scalability are paramount.

Whether you opt for NodePort for its simplicity and direct access, or LoadBalancer for its robustness and scalability, Kubernetes offers flexible solutions to suit different application access needs.

But you may be curious, in most cases we talk about accessing applications inside the cluster through Ingress from outside the cluster. What exactly is Ingress?

What is Ingress

Ingress: A Specification

At its core, Ingress is not merely a tool or a component; it is a powerful API object that provides a sophisticated method for handling external access to the services in a Kubernetes cluster. It allows you to define flexible, HTTP-based routing rules that direct traffic to different services based on the request's details. Let's delve into the key elements that make up an Ingress specification:

Host:

The 'host' field in an Ingress specification is what allows us to define domain names that will be routed to specific services within our cluster. This means that you can have different domain names or subdomains pointing to different parts of your application, all managed through a single Ingress resource. This is particularly useful for applications that require multiple entry points or for hosting multiple services under the same cluster.

Paths:

Next, we have 'paths.' This element works in conjunction with 'host' to provide even finer control over the routing of incoming requests. By specifying paths, you can direct traffic not just based on the domain name, but also based on the URL path. For instance, requests to example.com/api could be routed to one service, while requests to example.com/blog could be directed to another. This allows for a highly customizable and efficient distribution of traffic to the various components of your applications.

Certificates:

Lastly, an essential aspect of modern web applications is security, particularly the use of SSL/TLS certificates to encrypt traffic. Ingress facilitates this by allowing you to specify certificates for each host, ensuring that all communication is securely encrypted. This integration of SSL/TLS certificates with Ingress means that you can manage the security of your services at the same point where you're managing their accessibility, simplifying the overall configuration and maintenance of your applications.

However, simply creating an Ingress resource is not enough for it to work.

How does Ingress work?

The Ingress Controller: Translating Rules into Action

At the heart of the Ingress mechanism lies the Ingress controller. This isn't just any controller; it's the maestro of network traffic, orchestrating how requests from outside the Kubernetes cluster are handled and directed. But how does it achieve this?

The Ingress controller continuously monitors the Kubernetes API for Ingress resources - the rules and paths that you define for routing external traffic. Upon detecting an Ingress resource, the controller springs into action, translating these high-level Ingress rules into specific, actionable dataplane rules. This translation process is where the abstract becomes concrete, turning our defined paths and domains into precise instructions on how traffic should flow.

The Dataplane: Carrying Traffic to its Destination

With the rules translated, we now turn to the dataplane - the physical and logical network paths that actual traffic flows through. The dataplane is where the rubber meets the road, or more aptly, where the packet meets the pod.

In the context of Ingress, the dataplane is responsible for carrying the external traffic, now governed by the rules set forth by the Ingress controller. This can involve a variety of operations, such as SSL termination, load balancing, and content-based routing, all performed with the goal of ensuring that incoming requests are delivered to the correct service within the cluster.

Usually, we create a service for the dataplane and then expose it to external access by using NodePort or LoadBalancer as mentioned earlier.

Limitations of Ingress

Limited Expressiveness

One of the core limitations of Ingress lies in its limited expressiveness. Ingress rules are designed to be straightforward, focusing primarily on HTTP and HTTPS routing. This simplicity, while beneficial for ease of use and understanding, means that Ingress cannot natively handle more complex routing scenarios. For example, Ingress does not inherently support advanced load balancing algorithms, TCP or UDP traffic routing, or canary deployments out of the box.

This limitation can pose challenges for applications requiring more sophisticated traffic management and routing capabilities.

Reliance on Annotations for Controller Implementation Extensions

Another significant limitation is the way Ingress extends its functionality - through annotations. Each Ingress controller, such as Ingress-NGINX, Kong Ingress controller, or HAProxy, may implement additional features that are not part of the standard Ingress specification. These features are often enabled or configured via annotations in the Ingress resource.

While annotations provide a flexible way to extend Ingress capabilities, they also introduce variability and complexity. Different Ingress controllers might support different sets of annotations, leading to a lack of standardization across implementations. This can result in portability issues when moving applications between clusters using different Ingress controllers. Furthermore, relying heavily on annotations can make Ingress resources cluttered and harder to manage, especially as the number of annotations grows to accommodate more complex configurations.

Advantages of Gateway API

Considering these limitations of Ingress, the Kubernetes community decided to make some changes and thus began the design of the Gateway API.

Gateway API offers several key advantages that make it an attractive choice for managing network traffic in Kubernetes:

Role-oriented:

Gateway API is designed with distinct roles for different types of users. This allows for a more fine-grained and role-specific way of controlling access to resources, improving security, and making the management of permissions more straightforward. For example, cluster operators can control infrastructure-related aspects of gateways and routes, while developers can manage application-level configurations.

More Universal:

Unlike Ingress, which primarily focuses on HTTP/HTTPS traffic, Gateway API is protocol-agnostic and can handle a broader range of traffic types, including TCP and UDP. This makes it a more universal solution for managing all types of network traffic within a Kubernetes cluster.

Vendor-neutral:

Gateway API is designed to be vendor-neutral, meaning it doesn't favor any specific networking solution. This ensures that it can be used consistently across different environments and networking solutions, enhancing portability and reducing vendor lock-in. This neutrality also fosters a more collaborative ecosystem, as improvements and extensions can benefit all users, regardless of their specific networking implementation.

Role-oriented

In the context of the Kubernetes Gateway API, being "role-oriented" means that the API is designed with distinct roles for different types of users. This approach allows for a more fine-grained control over resources, improving security, and making the management of permissions more straightforward.

For example, the roles could be divided between cluster operators and application developers. Cluster operators control infrastructure-related aspects of gateways and routes, such as selecting the type of load balancer used, setting up SSL/TLS certificates, and managing access logs. On the other hand, application developers manage application-level configurations, such as specifying the routes for their applications, setting up path-based routing, and defining request and response headers.

This role-oriented design allows each user to focus on their area of expertise, without needing to worry about the details that are outside of their purview. It also ensures that only authorized users can make changes to specific aspects of the configuration, enhancing the overall security of the system.

Why the Managed Gateway is Needed

Let's move on to the next section and discuss why a Managed Gateway is needed. As you can guess from its name, it simplifies our work.

why multi-tenant Gateways are needed

The Managed Gateway is essential for several reasons:

• Simplified Management: Managed Gateways handle the underlying infrastructure, freeing up development teams to focus on application logic. This simplifies the management of the gateway, as the complexities of configuration, maintenance, and upgrades are handled by the provider.

• Scalability: Managed Gateways offer automatic scaling capabilities. They can scale up to handle high traffic loads and scale back down during quieter periods, ensuring optimal resource usage.

• Reliability: Managed Gateways provide high availability and fault tolerance. They are designed to maintain service continuity, even in the face of network disruptions or hardware failures.

• Security: Managed Gateways often come with built-in security features such as SSL encryption, and identity-based access control. This ensures that your applications are secure and compliant with industry standards.

• Isolate and protect tenant traffic, reducing the blast radius.

General solution

To handle this scenario, they will deploy multiple ingress controllers. Here are two common solutions:

• Differentiation through IngressClass: IngressClass is a Kubernetes resource that allows users to specify the type of Ingress controller they want to use in their applications. By defining different IngressClasses, users can associate their Ingress resources with specific Ingress controllers. This is beneficial as it allows for a clear separation and management of different application traffic within the cluster, each handled by its own Ingress controller.

• Differentiation through namespaces: Another method to differentiate between multiple Ingress controllers is by using namespaces. Kubernetes namespaces provide a scope for names and allow users to divide cluster resources between multiple users or teams. By deploying different Ingress controllers in different namespaces, users can ensure that each controller only manages the traffic for the applications within its own namespace. This approach enhances the security and organization of the cluster, as it provides a clear separation of concerns between different applications and their respective Ingress controllers.

Pain point

While deploying multiple Ingress controllers in the same cluster may seem like a viable solution, it introduces several pain points:

• Increased Complexity: Managing multiple Ingress controllers increases the complexity of your Kubernetes cluster. Each controller has its own configuration and behavior, leading to potential inconsistencies and conflicts. This can make it hard to predict how the controllers will interact and complicate debugging efforts when issues arise.

• Resource Wastage: Each Ingress controller requires its own resources to run. Deploying multiple controllers may lead to resource wastage, especially if some controllers are not fully utilized. This inefficiency can lead to increased costs and reduced performance for your cluster.

• Increased Maintenance: With multiple Ingress controllers, you need to maintain each one separately. This includes monitoring, updating, troubleshooting, and securing each controller. This increased maintenance can take significant time and effort.

• Lack of Centralized Control: Having multiple Ingress controllers can make it difficult to achieve centralized control and visibility over your network traffic. Without a single point of control, it can be challenging to manage traffic routing consistently and apply uniform security policies across all controllers.

• Potential Security Risks: Each Ingress controller has its own security features and configurations. If not properly managed, having multiple controllers can introduce security risks, as each controller could potentially be a separate point of vulnerability in your cluster.

Kong Gateway Operator

Today, let me share an innovative open-source project created by Kong Inc., known as the Kong Gateway Operator. This project is not just another tool in the tech space; it's a game-changer designed to address some of the most pressing challenges we face in managing API gateways.

In our journey towards digital transformation, we often encounter bottlenecks that hinder our progress. The Kong Gateway Operator is here to eliminate those bottlenecks by offering:

1. Full Lifecycle Management: Managing the lifecycle of Kong Gateway has never been easier. From deployment to retirement, the Kong Gateway Operator ensures a smooth journey. Moreover, it supports a blue/green strategy for upgrading Kong Gateway, making transitions seamless and minimizing downtime.

2. Elastic Scaling: Cost-efficiency is paramount in today's tech landscape. The Kong Gateway Operator leverages Horizontal Pod Autoscaling (HPA) and latency measurements to dynamically scale your resources. This not only ensures optimal performance but also significantly reduces operational costs.

3. Automatic Certificate Rotation: Security is a top priority, and managing certificates can be a cumbersome task. Thanks to the integration with cert-manager, the Kong Gateway Operator automates certificate rotation, ensuring your applications are always secure without the manual hassle.

4. AI Gateway Support: In an era where AI and LLM (Large Language Models) applications are becoming increasingly prevalent, the Kong Gateway Operator sets the stage by prioritizing AI gateway support. This feature is designed to streamline the development and deployment of AI-driven applications, making it easier for developers to integrate cutting-edge technologies into their solutions.

How to Deploy a Managed Gateway using KGO in Civo

Create Kubernetes cluster

The cluster running on Civo is k3s, but it is also a distribution that has passed Kubernetes conformance certification.

To create a cluster through Civo, you can operate it in the dashboard of Civo or install Civo's CLI. It is very convenient to create through CLI. Here I have installed and configured Civo's CLI.

➜  ~ civo k8s create --merge  --save  --wait
Merged with main kubernetes config: /home/tao/.kube/config

Access your cluster with:
kubectl config use-context red-nightingale-6cf01085
kubectl get node                     
The cluster red-nightingale-6cf01085 (9752f456-f316-4bdf-95fe-82c9b08db61b) has been created in 1 min 9 sec

Deploying clusters on Civo is very fast, which is one of the reasons why I like Civo the most.

Install KGO

KGO can be installed through Helm, and the CRDs of Kubernetes Gateway API are already included in KGO's Helm chart, so there is no need to perform a separate installation step.

• Add kong Helm repo.

(⎈|red-nightingale-6cf01085:default)➜  ~ helm repo add kong <https://charts.konghq.com>
"kong" has been added to your repositories
(⎈|red-nightingale-6cf01085:default)➜  ~ helm repo update
Hang tight while we grab the latest from your chart repositories...
...Successfully got an update from the "kong" chart repository
Update Complete. ⎈Happy Helming!⎈

• Install KGO using Helm.

(⎈|red-nightingale-6cf01085:default)➜  ~ helm upgrade --install kgo kong/gateway-operator -n kong-system --create-namespace --set image.tag=1.3

Release "kgo" does not exist. Installing it now.
NAME: kgo
LAST DEPLOYED: Sat Jul 20 01:40:28 2024
NAMESPACE: kong-system
STATUS: deployed
REVISION: 1
TEST SUITE: None
NOTES:
kgo-gateway-operator has been installed. Check its status by running:

  kubectl --namespace kong-system  get pods

For more details, please refer to the following documents:

* <https://docs.konghq.com/gateway-operator/latest/get-started/kic/create-gateway/>
* <https://docs.konghq.com/gateway-operator/latest/get-started/konnect/deploy-data-plane/>

Create Gateway

To use the Gateway API resources to configure your routes, you need to create a GatewayClass instance and create a Gateway resource that listens on the ports that you need.

(⎈|red-nightingale-6cf01085:default)➜  ~ echo '
kind: GatewayConfiguration
apiVersion: gateway-operator.konghq.com/v1beta1
metadata:
 name: kong
 namespace: default
spec:
 dataPlaneOptions:
   deployment:
     podTemplateSpec:
       spec:
         containers:
         - name: proxy
           image: kong:3.7.1
           readinessProbe:
             initialDelaySeconds: 1
             periodSeconds: 1
 controlPlaneOptions:
   deployment:
     podTemplateSpec:
       spec:
         containers:
         - name: controller
           image: kong/kubernetes-ingress-controller:3.2.0
           env:
           - name: CONTROLLER_LOG_LEVEL
             value: debug
---
kind: GatewayClass
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
 name: kong
spec:
 controllerName: konghq.com/gateway-operator
 parametersRef:
   group: gateway-operator.konghq.com
   kind: GatewayConfiguration
   name: kong
   namespace: default
---
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
 name: kong
 namespace: default
spec:
 gatewayClassName: kong
 listeners:
 - name: http
   protocol: HTTP
   port: 80

' | kubectl apply -f -

gatewayconfiguration.gateway-operator.konghq.com/kong created
gatewayclass.gateway.networking.k8s.io/kong created
gateway.gateway.networking.k8s.io/kong created

You can verify whether the Gateway has been successfully created by using the following command.

(⎈|red-nightingale-6cf01085:default)➜  ~ kubectl get Gateway -A
NAMESPACE   NAME   CLASS   ADDRESS         PROGRAMMED   AGE
default     kong   kong    74.220.29.143   True         3m35s

(⎈|red-nightingale-6cf01085:default)➜  ~ export PROXY_IP=$(kubectl get gateway kong -n default -o jsonpath='{.status.addresses[0].value}')
(⎈|red-nightingale-6cf01085:default)➜  ~ curl $PROXY_IP                                                                                   
{
  "message":"no Route matched with those values",
  "request_id":"382d5a15ac243b3183b5b239a5e3ae77"
}

At the same time, you can also see that KGO has created deployments for CP and DP in the default namespace.

(⎈|red-nightingale-6cf01085:default)➜  ~ kubectl get deploy          
NAME                            READY   UP-TO-DATE   AVAILABLE   AGE
dataplane-kong-tkbct-snkrk      1/1     1            1           9m5s
controlplane-kong-lv62b-tf6xl   1/1     1            1           9m5s

Create another Gateway

To verify the ability of KGO, we have created a new namespace and created Gateway resources.

(⎈|red-nightingale-6cf01085:default)➜  ~ kubectl create ns moe        
namespace/moe created

(⎈|red-nightingale-6cf01085:default)➜  ~ echo '
kind: Gateway
apiVersion: gateway.networking.k8s.io/v1beta1
metadata:
 name: moe
 namespace: moe
spec:
 gatewayClassName: kong
 listeners:
 - name: http
   protocol: HTTP
   port: 80

' | kubectl apply -f -

We can check whether Gateway has been deployed correctly by viewing the status of Gateway resources, or we can verify it by requesting the IP of Gateway using the method in the previous section.

(⎈|red-nightingale-6cf01085:default)➜  ~ kubectl get Gateway -A
NAMESPACE   NAME   CLASS   ADDRESS         PROGRAMMED   AGE
default     kong   kong    74.220.29.143   True         14m
moe         moe    kong    74.220.28.102   True         8m6s

Of course, a more intuitive way would be to check the status of kocp and kodp.

(⎈|red-nightingale-6cf01085:default)➜  ~ kubectl get kodp,kocp -A
NAMESPACE   NAME                                               READY
default     dataplane.gateway-operator.konghq.com/kong-tkbct   True
moe         dataplane.gateway-operator.konghq.com/moe-bfwnl    True

NAMESPACE   NAME                                                  READY   PROVISIONED
default     controlplane.gateway-operator.konghq.com/kong-lv62b   True    True
moe         controlplane.gateway-operator.konghq.com/moe-9dgjc    True    True

After the Gateway is ready, you can refer to the KGO official documentation to use Kubernetes Gateway API to create routes.

Summary

In this article, I introduced why we need to use a multi-tenant Gateway in Kubernetes clusters, and also demonstrated how to deploy the Gateway through KGO in Civo's Kubernetes cluster.

KGO provides a wide range of capabilities, please feel free to explore them! https://konghq.com/products/kong-gateway-operator

I'll cover how to reduce the code of GitHub Actions, and give some advice.

According to G2's statistical report, GitHub Actions is the easiest-to-use CI/CD tool, and more and more people like it.

Since GitHub Actions is GitHub's native CI/CD tool, tens of thousands of Actions can be used directly in the marketplace, and it is free for public repositories. More and more projects are switching their CI tools to GitHub Actions.

I also really like GitHub Actions and use it for almost all my GitHub-hosted repositories.

But recently I was working on a project that hit the GitHub Actions quota limit. It took me some time to focus on its cost.

Why is the quota exhausted?

Recently I found an interesting project: upptime/upptime: ⬆️ Free uptime monitor and status page powered by GitHub

I want to try to use it to monitor some of the services I have developed and make a status page, this will involve some API configurations, and I don't want to make it public, so I forked the project into a private repository. After a simple configuration, it works fine.

Since I wanted more data, I tweaked the CI scheduler configuration. Make these tasks run more frequently.

workflowSchedule:
  graphs: "0 * * * *"
  responseTime: "0 * * * *"
  staticSite: "0 * * * *"
  summary: "0 * * * *"
  updateTemplate: "0 * * * *"
  updates: "0 * * * *"
  uptime: "*/5 * * * *"

According to the billing documentation for GitHub Actions, GitHub Actions for public repositories is Free, but there is a quota limit for private repositories.

GitHub Actions usage is free for standard GitHub-hosted runners in public repositories, and for Self-hosted runners. For private repositories, each GitHub account receives a certain amount of free minutes and storage for use with GitHub-hosted runners, depending on the product used with the account. Any usage beyond the included amounts is controlled by spending limits.

Soon I received a quota reminder email from GitHub, reminding me that the quota was about to be used up.

This got me thinking about how to solve it.

Cost of using GitHub Actions

Making the repository public is the most straightforward way, but I explained above why it cannot be made public. I can only find other solutions.

Paying for GitHub Actions is also a very straightforward solution.

Before deciding to pay for it, I want to estimate the cost. GitHub provides a Pricing Calculator, which can easily estimate costs.

Since I modified the CI's scheduling configuration, the most frequently run tasks will run every 5 minutes.

I used Meercode to collect the running data of GitHub Actions in this repository. It provides some dashboards by default:

It also allows users to customize it themselves. I created my dashboard. If you are interested in Meercode, please let me know in the comments.

As can be seen from the figure above, each task takes no more than 0.5 minutes, and there are no more than 12 tasks per hour. Using the price calculator, the approximate cost is $35 per month.

Ways to save costs

Since my repository is mainly run uptime CI, it consumes few resources but has frequent tasks, so I wonder if I can save costs if I use a self-hosted runner.

I compared the prices of 3 lower-priced cloud service providers:

• Civo

• DigitalOcean

• Vultr

Among them, both Civo and Vultr provide 1C1G instances at $5/month, and DigitalOcean instances with the same specifications are priced at $6/month.

I finally chose Civo, which is a cloud-native service provider, and there is an introduction on its homepage:

Transparent pricing from just $5 a month

Civo provides a variety of services, such as Kubernetes (based on k3s), or compute instances.

Among them, the instance specification of the Extra Small type is 1C1G, and it has 1TB traffic, and if you choose the Kubernetes service, you do not need to pay for the control plane(same as Azure AKS). Even the larger specs look cheap.

I have tried using its Kubernetes service, and compute instance respectively, and they both work fine.

Using compute instances

Deploying the GitHub Actions runner in a Linux compute instance is simple, just add it to the project https://github.com/<Your name>/<Project name>/settings/actions/runners/new.

There are complete deployment steps on this page, just follow the steps.

My installation process is as follows:

civo@polished-bush-99d8-1926a1:~$ mkdir actions-runner && cd actions-runner
civo@polished-bush-99d8-1926a1:~/actions-runner$ curl -o actions-runner-linux-x64-2.301.1.tar.gz -L https://github.com/actions/runner/releases/download/v2.301.1/actions-runner-linux-x64-2.301.1.tar.gz
civo@polished-bush-99d8-1926a1:~/actions-runner$ echo "3ee9c3b83de642f919912e0594ee2601835518827da785d034c1163f8efdf907  actions-runner-linux-x64-2.301.1.tar.gz" | shasum -a 256 -c
actions-runner-linux-x64-2.301.1.tar.gz: OK                                                                     
civo@polished-bush-99d8-1926a1:~/actions-runner$ tar xzf ./actions-runner-linux-x64-2.301.1.tar.gz              
civo@polished-bush-99d8-1926a1:~/actions-runner$ ./config.sh --url https://github.com/MoeLove/monitoring --token $TOKEN

After the execution is complete, some files will be added to the current directory. Execute ./env.sh to start the GitHub Actions runner.

civo@polished-bush-99d8-1926a1:~/actions-runner$ ls
_diag  _work  actions-runner-linux-x64-2.301.1.tar.gz  bin  config.sh  env.sh  externals  run-helper.cmd.template  run-helper.sh  run-helper.sh.template  run.sh  safe_sleep.sh  svc.sh

If you want to run stably in the background, you can execute ./svc.sh install to install the runner as a systemd service and manage its life cycle through systemd.

Using Kubernetes

Civo does not charge for the Kubernetes control plane, but only for Worker Nodes. The advantage of using Kubernetes is that I can automatically scale up and down in the cluster, and I can easily run and create multiple runners for different projects.

Since GitHub official has not provided to deploy a Self-hosted runner on Kubernetes, I used the Actions Runner Controller (ARC) project, This project allows rapid deployment of Self-hosted runners through Runner custom resources.

The deployment process is clearly described in the documentation. The following is my deployment process.

# deploy cert-manager
(MoeLove) ➜ kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.11.0/cert-manager.yaml

# deploy ARC
(MoeLove) ➜ helm repo add actions-runner-controller https://actions-runner-controller.github.io/actions-runner-controller
(MoeLove) ➜ helm upgrade --install --namespace actions-runner-system --create-namespace\
  --set=authSecret.create=true\
  --set=authSecret.github_token="REPLACE_YOUR_TOKEN_HERE"\
  --wait actions-runner-controller actions-runner-controller/actions-runner-controller

# create runner
(MoeLove) ➜ cat <<EOF | kubectl apply -f -
apiVersion: actions.summerwind.dev/v1alpha1
kind: RunnerDeployment
metadata:
  name: moelove-runner
spec:
  replicas: 1
  template:
    spec:
      repository: MoeLove/monitoring
EOF

After installation, the following results are achieved:

Self-hosted vs GitHub-managed

In the content above, I introduced how I used Meercode to measure the key indicators of CI metrics and estimate the cost of GitHub Actions. According to my actual low resource consumption and high time-consuming scenario, I chose the Self-hosted runner.

So when is it more appropriate to choose a GitHub-managed runner? What are the benefits of GitHub-managed?

The GitHub-managed runner has the following advantages:

• Support for multiple operating systems: In addition to providing Linux systems, GitHub-managed runner also supports macOS and Windows, but most cloud providers do not provide macOS environments. (I used to put some Mac minis as servers in the data center for specific scenarios)

• VM-level isolation: According to the GitHub Actions documentation, when the GitHub Actions runner runs a job, it creates a VM to run all tasks, which brings certain security and isolation guarantees. If it is a Self-hosted runner when running through the binary, the task will share the host environment, and if it is running through ARC, it will bring isolation through the Pod. This will cause certain security issues.

• Low Maintenance Costs: In fact in any large system, maintenance costs are very expensive. If it is only for personal use, or only a few projects use the Self-hosted runner, the maintenance cost is relatively controllable. Once it gets big, it introduces a lot of complexity. The GitHub-managed runner is maintained by GitHub.

There are also two products that offer self-hosted runner services:

• Actuated

• cirun

They reduce the cost of runner maintenance and management and provide more secure isolation and support for Arm-based environments. cirun also provides GPU runner support.

If you have the above requirements, you may also wish to consider these services.

Summarize

In general, the following steps are required to reduce the cost of GitHub actions.

• Visualization/Observability: Estimate costs using actual data.

• Compare multiple vendors/solutions: Different vendors offer different pricing for different scenarios or products, and you can choose according to your actual situation.

• Security and maintenance costs also need to be considered.

If you are interested in my articles, please subscribe to my Newsletter!

I'll share my Rust journey, how I learned Rust and some free Rust learning resources.

Rust has become more and more popular. Through the StackOverflow 2022 Developer Survey, we can see that many people are interested in Rust.

Rust is on its seventh year as the most loved language with 87% of developers saying they want to continue using it.

Rust also ties with Python as the most wanted technology with TypeScript running a close second

• Most Wanted

  

• Most Loved vs. Dreaded

  

But Rust has a particular learning curve.

This made me want to share my Rust journey, why I chose Rust, and how to learn Rust.

Getting connected with Rust

I had heard about Rust when it was first released, and my impression was that it was a system programming language that could replace C/C++ and was safe enough. But I didn't learn and use it. (I've only used it to write Hello World!)

Back in time to 5 years ago, I was leading the transformation of the company's infrastructure into a cloud-native stack.

I need to construct a monitoring stack based entirely on Prometheus to replace a set of monitoring software in the company with more than 10 years of history. And some other monitoring software, such as Nagios, Zabbix, and Graphite.

Yes, you read that right, we are using a lot of surveillance software. There are a few reasons for this:

• A single software cannot meet all needs

• The team is scattered, and most of the time, new software is introduced just to meet specific needs, rather than to solve the problem

Anyway, here are some historical reasons.

And, from what I mentioned above, we have a set of self-developed monitoring software with a history of more than 10 years, as you can see, our infrastructure is slow to iterate.

And because we have our physical data center, this also leads to many old machines in our servers that have not been updated. (This is one of the reasons why I used Rust later)

I first replaced the monitoring stack in a newly launched small data center, with about 400 machines, and the effect was good. Using Prometheus to complete the monitoring of all the servers in this small data center and the various services running on them. There are also Dashboards created for them in Grafana, and alarm notifications created through Alertmanager.

Later, I promoted these transformations in two data centers, and overall it was relatively smooth, including the monitoring of Kubernetes was also completed during this process.

But when it was implemented in the last data center, I faced the biggest challenge.

node_exporter failed to start on some machines, and some machines crashed automatically after running for some time.

I started to investigate this issue. For the automatic crash issue, I temporarily fixed it by adding a restart script.

I'm mainly concerned with why node_exporter won't start. I found that the operating system of this part of the machine is CentOS 5, and the kernel is 2.6.18.

I found that there are already similar issues in the community: https://github.com/prometheus/node_exporter/issues/691

At the same time, I also noticed that the Go documentation clearly stated that CentOS 5 is not supported, and a kernel of at least version 2.6.32 or above is required.

(I forgot the minimum dependencies when I checked, but through the web archive, I see that the minimum kernel version required in 2017 is 2.6.23)

After some searching, I also saw something like How to install Go 1.1 on CentOS 5.9, but at the same time, some known issues are mentioned in the article.

So I'm not going to keep fighting it.

I want to re-implement one by myself, which can also solve the above automatic crash problem.

In the end, I used Rust to implement a tool similar to node_exporter and completed the upgrade and transformation of the monitoring system.

This is where my journey started with Rust in production.

Next, let me introduce why I chose Rust.

Why choose Rust

I have introduced some background above. At that time, the easiest choice should be Python, which is simple enough and rich in ecology. At the same time, I also have many years of experience in Python development, I can quickly build the tools I need.

The reasons for not choosing Python are:

• Not all of these machines have a Python environment, and the versions of Python are also different. I was asked not to modify the environment on these machines as much as possible;

• Since I may make some modifications later, I think the subsequent distribution may not be convenient;

Then I rethought my goal:

• Can be compiled into binary executable files for easy distribution and deployment. I used Ansible for unified deployment.

So a more suitable option is C/C++/Rust.

I have more experience in C development and a little experience in C++. For my first requirement, the above three languages can be easily met.

When most people compare Rust and C/C++, they are comparing their performance and safety.

And in my use case at the time, I don't think the results in the other two languages would be worse than in Rust, although these are also considerations. And since I was just starting to learn Rust at the time, it might be worse than my C implementation.

But I want more challenges, try something new, and in terms of Prometheus monitoring, the C/C++-related ecology is not very active. Another point I think Rust will have great development in the future.

So in the end I chose Rust.

How I learned Rust

Rust is not simple, and it's not quite the same as other languages, so some practices that work in other languages may not work in Rust.

Since I have a specific problem that needs to be solved, I need to implement a node_exporter to complete the transformation of the monitoring stack. So I learned Rust through the learning-by-doing mode.

I first took a quick look at the following:

• The Rust Programming Language: This book is very complete, I didn't read it completely at first. Instead, use it to understand the main concepts and some usages in Rust.

• Rust By Example: There are many examples here, and you can also increase your familiarity with Rust by practicing these examples;

• Rust std lib docs: Documentation of the standard library, a quick overview, understanding some keywords, modules, etc. But it is not necessary to read it in its entirety initially.

This way I quickly implemented a basic node_exporter version. Then continue to iterate and apply it to the production environment, and completed the construction of the Prometheus monitoring stack.

Later, I continued to implement some small tools in Rust, learned its best practices, and learned some open-source projects implemented in Rust to increase my Rust experience.

Recommend some Rust learning resources

There are many learning resources for Rust now. In addition to the ones I listed above, I recommend the following free content:

• Take your first steps with Rust - Training | Microsoft Learn

• rust-lang/rustlings: Small exercises to get you used to reading and writing Rust code!

videos:

• Rust Crash Course | Rustlang - YouTube

• Rust Tutorial - YouTube

• Rust for Beginners - YouTube

Summarize

This is how my Rust journey started, and it continues.

Although I focus on Cloud Native and Kubernetes-related technologies, and now I write more Go language, I also still write some tools in Rust and use Rust in WebAssembly.

In the future, I will also share relevant content. If you are interested in my articles, welcome to subscribe to my Newsletter!