Top 2 Golang Resources for Kubernetes CRD Development

Introduction: The Uncharted Territories of Kubernetes and the Power of Custom Resources

Kubernetes has undeniably become the de facto operating system for the cloud-native world, orchestrating containers, automating deployments, and managing complex microservices architectures at an unprecedented scale. However, its true power lies not just in its out-of-the-box capabilities but in its profound extensibility. While Kubernetes provides a rich set of built-in resources like Pods, Deployments, and Services, real-world applications often demand more nuanced, domain-specific abstractions. This is where Custom Resource Definitions (CRDs) come into play, transforming Kubernetes from a generic orchestrator into a highly specialized platform tailored to an application's unique needs.

CRDs empower developers to extend the Kubernetes API, introducing new object types that behave just like native Kubernetes resources. This capability allows for the creation of "operators" – specialized controllers that understand these custom resources and automate the lifecycle management of complex applications and services within the Kubernetes ecosystem. Imagine defining an "EtcdCluster" or a "KafkaTopic" as a first-class Kubernetes object; operators then watch these custom resources and take actions to ensure the real-world state (e.g., actual Etcd clusters running) matches the desired state declared in the CRD. This paradigm shift, from imperative commands to declarative API specifications, is a cornerstone of modern cloud-native development.

For those venturing into this fascinating realm of extending Kubernetes, Golang stands out as the language of choice. Its concurrency primitives, strong typing, robust standard library, and a development philosophy that aligns closely with Kubernetes' own design principles make it the preferred language for writing controllers and operators. The very foundation of Kubernetes itself is built with Golang, providing an unparalleled ecosystem of libraries, tools, and community expertise. Navigating this ecosystem to build robust, scalable, and maintainable CRD-backed solutions, however, requires understanding the right tools. This comprehensive guide will delve deep into the two most pivotal Golang resources for Kubernetes CRD development: controller-runtime and kubebuilder. We will explore their philosophies, capabilities, and best practices, equipping you with the knowledge to craft powerful Kubernetes operators that push the boundaries of cloud-native automation.

Section 1: The Foundation - Kubernetes CRDs and Golang's Indispensable Role

To fully appreciate the utility of controller-runtime and kubebuilder, it's essential to first establish a solid understanding of what Kubernetes CRDs are and why Golang is the language of preference for their associated controllers. This foundational knowledge will illuminate the problem space these tools aim to solve and the elegance with which they do so.

What are Custom Resource Definitions (CRDs)? Extending the Kubernetes API

At its core, Kubernetes operates on a declarative API model. Users declare their desired state using YAML or JSON manifest files, which describe resources like Pods, Deployments, Services, and Ingresses. The Kubernetes control plane then continuously works to reconcile the cluster's actual state with this declared desired state. CRDs extend this powerful model by allowing administrators and developers to define their own custom resource types.

A CRD itself is a Kubernetes resource that defines a new kind of object. It specifies the name of the new custom resource, its scope (namespace-scoped or cluster-scoped), its versioning strategy, and most importantly, its schema. This schema, often defined using OpenAPI v3 validation, ensures that instances of your custom resource adhere to a predefined structure, much like how a Pod manifest must conform to the Pod schema. For example, you might define a Database CRD with fields for engine, version, storageSize, and replicaCount. Once the Database CRD is applied to a cluster, users can then create Database objects (e.g., kind: Database, apiVersion: stable.example.com/v1alpha1) and interact with them using standard Kubernetes tools like kubectl.

The true power of CRDs emerges when they are paired with custom controllers, often referred to as "operators." An operator is an application that runs inside the Kubernetes cluster, constantly watching for changes to these custom resources. When a new Database object is created, modified, or deleted, the operator detects this event and takes appropriate actions to provision, update, or deprovision the actual database instance in the underlying infrastructure (e.g., a cloud provider's managed database service, or a database running within the cluster). This combination of CRD and operator creates an "extension" to Kubernetes, effectively teaching it how to manage new types of applications and infrastructure. This approach allows for infrastructure-as-code principles to extend beyond generic compute to highly specialized domain-specific services, providing unparalleled automation and consistency.

Why Golang for Kubernetes Operators? A Symbiotic Relationship

The choice of Golang as the primary language for building Kubernetes operators and controllers is not arbitrary; it's a deeply symbiotic relationship driven by several key factors:

1. Native Kubernetes Ecosystem: Kubernetes itself is written in Golang. This means that all the core client libraries, API definitions, and internal components are natively accessible and optimized for Golang. Developers building operators benefit from direct access to the same robust, battle-tested libraries that Kubernetes itself uses, ensuring compatibility and leveraging the collective experience of the Kubernetes development community. This includes the k8s.io/api, k8s.io/apimachinery, and k8s.io/client-go packages, which are fundamental for interacting with the Kubernetes API server.
2. Concurrency and Performance: Kubernetes operators are inherently event-driven and concurrent. They need to watch multiple resource types, process events asynchronously, and potentially manage a large number of custom resources simultaneously. Golang's built-in concurrency primitives—goroutines and channels—are exceptionally well-suited for this model. They allow for lightweight, efficient parallelism without the complexity of traditional threading models, enabling operators to handle high throughput of events and reconcile state effectively without excessive resource consumption. Its compiled nature also ensures excellent runtime performance, critical for systems that need to react quickly to changes in a dynamic environment.
3. Static Typing and Robustness: Golang is a statically typed language, which aids significantly in catching type-related errors at compile time rather than runtime. This leads to more robust and reliable operators, reducing the likelihood of unexpected behavior in production. Given that operators often control critical infrastructure, stability and predictability are paramount. The strong type system also enhances code readability and maintainability, especially in large, complex projects.
4. Simplicity and Readability: Golang is known for its simplicity and opinionated design, which encourages consistent coding styles. This makes it easier for teams to collaborate on operator development, as the code tends to be more readable and maintainable across different contributors. The clear syntax and minimal language features reduce cognitive load, allowing developers to focus on the logic of their operator rather than wrestling with complex language constructs.
5. Strong Community and Tooling: The vibrant Golang community, particularly within the cloud-native space, continuously contributes to a rich ecosystem of tools, libraries, and best practices. For Kubernetes CRD development, this includes specialized frameworks and utilities that abstract away much of the boilerplate, further accelerating development. The existence of controller-runtime and kubebuilder themselves is a testament to this strong tooling support.
6. Cross-Platform Compilation: Golang's ability to compile into single, statically linked binaries for various operating systems and architectures simplifies deployment significantly. An operator written in Golang can be easily containerized and run within any Kubernetes environment without worrying about runtime dependencies, which aligns perfectly with the container-centric nature of Kubernetes.

In essence, Golang provides the performance, concurrency, safety, and ecosystem that are perfectly aligned with the demanding requirements of building Kubernetes controllers and operators. It allows developers to create sophisticated extensions to Kubernetes that are both powerful and manageable, laying the groundwork for the advanced tools we are about to explore.

Section 2: Resource 1 - controller-runtime: The Heartbeat of Kubernetes Operators

The journey into Golang-based Kubernetes CRD development invariably leads to controller-runtime. It is not just a library; it is the foundational toolkit that abstracts away much of the complexity of writing Kubernetes controllers, providing a robust and opinionated framework upon which more advanced tools like kubebuilder are built. Understanding controller-runtime is crucial for anyone serious about extending Kubernetes with custom resources, as it exposes the core concepts and patterns that underpin all modern Kubernetes operators.

What is controller-runtime? Unpacking its Purpose and Origins

controller-runtime is a set of libraries that provides a high-level API for building Kubernetes controllers. Developed by the Kubernetes SIGs (Special Interest Groups), particularly SIG API Machinery and SIG Multicluster, it emerged from the need to standardize and simplify the development of Kubernetes controllers. Before controller-runtime, writing a controller involved directly interacting with client-go libraries, manually setting up informers, caches, work queues, and event handlers – a process that was boilerplate-heavy, error-prone, and required deep knowledge of Kubernetes' internal workings.

controller-runtime aims to solve these problems by offering abstractions that encapsulate these common patterns. It focuses on the "reconcile loop" pattern, where a controller continuously observes the desired state (defined by a CRD instance) and compares it with the actual state of the cluster, taking corrective actions to bring them into alignment. It provides utilities for:

• Watching Resources: Efficiently monitoring changes to Kubernetes resources (both native and custom).
• Event Handling: Processing these changes as events and queuing them for reconciliation.
• Caching: Maintaining local caches of Kubernetes objects to reduce API server load and improve performance.
• Leader Election: Ensuring that in a highly available setup, only one instance of a controller is active at any given time.
• Webhooks: Simplifying the creation of admission webhooks (Mutating and Validating) and conversion webhooks for CRD versioning.
• Metrics: Integrating with Prometheus for exporting operational metrics.

Essentially, controller-runtime provides the essential scaffolding and operational primitives that every Kubernetes controller needs, allowing developers to concentrate on the business logic of their operator rather than the intricate details of Kubernetes API interaction.

Key Abstractions: The Building Blocks of a Controller

To grasp controller-runtime, it's vital to understand its core abstractions:

1. Manager: The orchestrator of your controller. A Manager sets up and starts all the controllers, webhooks, and other components in your application. It holds references to the client.Client (for interacting with the Kubernetes API), a scheme.Scheme (for registering all the Go types representing Kubernetes resources), a cache.Cache (for efficient read operations), and a EventRecorder (for emitting Kubernetes events). You typically create one Manager per operator application.
2. Controller: This abstraction represents an individual controller responsible for a specific resource type. A Controller is configured with a Reconciler and instructs the Manager which resources to watch. It handles the mechanics of picking up events, queuing them, and dispatching them to its Reconciler.
3. Reconciler (controller.Reconciler interface): This is where your operator's core logic resides. The Reconciler interface defines a single method: Reconcile(context.Context, reconcile.Request) (reconcile.Result, error). Whenever a watched resource changes (created, updated, deleted) or a dependent resource changes, the Controller invokes the Reconcile method with a reconcile.Request containing the namespace and name of the object that triggered the reconciliation. The Reconcile function is expected to fetch the latest state of the object, compare it with the desired state, and make necessary changes to the cluster. It should be idempotent, meaning it can be called multiple times with the same input without causing unintended side effects.
4. Source (source.Source interface): Defines what the controller watches. This can be a primary resource (the CRD your operator manages), or secondary resources (native Kubernetes resources like Deployments, Services, or even other CRDs that your primary resource creates or depends on). When a Source resource changes, controller-runtime determines which primary resource it belongs to and queues that primary resource for reconciliation.
5. EventHandler (handler.EventHandler interface): Defines how events from a Source are processed. When an event occurs for a watched resource, the EventHandler translates that event into a reconcile.Request for a primary resource. Common handlers include EnqueueRequestForObject (for the object itself) or EnqueueRequestForOwner (for the owner of the object, often used for secondary resources).
6. Predicate (predicate.Predicate interface): Allows for filtering events. Sometimes, you only want your reconciler to be triggered by specific types of changes (e.g., ignore updates that only change metadata). Predicates provide a way to define custom logic to filter out unwanted events before they reach the reconciler, reducing unnecessary reconciliation cycles and improving performance.

The Reconcile Loop: Simplicity in Action

The core operational pattern promoted by controller-runtime is the "reconcile loop." Every time an event related to a watched resource occurs, the Reconciler function for the primary CRD is triggered. Inside this function, the typical flow is as follows:

1. Fetch the Custom Resource: Retrieve the latest version of the custom resource instance (e.g., Database object) from the API server using the client.Client provided by the Manager.
2. Handle Deletion (Optional but Recommended): Check if the object is being deleted (indicated by a non-empty metav1.DeletionTimestamp). If so, perform any necessary cleanup (e.g., deprovision the actual database) and remove any finalizers.
3. Validate and Mutate (Optional): Perform any custom validation logic or default values if not handled by CRD schema validation or webhooks.
4. Reconcile Desired State: Compare the state defined in the custom resource with the current actual state of the infrastructure it manages. This involves fetching related Kubernetes resources (e.g., Deployments, Services, ConfigMaps) that your operator is responsible for creating or managing.
5. Create/Update/Delete Secondary Resources: Based on the comparison, create, update, or delete the necessary secondary Kubernetes resources (e.g., a Deployment for the database pods, a Service to expose it). Use the client.Client for these operations.
6. Update Status: Update the Status subresource of your custom resource to reflect the current actual state of the managed infrastructure (e.g., status.Phase: Ready, status.ObservedGenerations: N). This provides valuable feedback to users about the operational state of their custom resource.
7. Handle Errors and Requeue: If an error occurs, return an error from Reconcile to signal controller-runtime to retry the reconciliation later. If everything is successful, return reconcile.Result{}. You can also explicitly requeue after a duration (reconcile.Result{RequeueAfter: ...}) for eventual consistency checks or to handle external dependencies.

This pattern, while simple conceptually, covers a vast range of operational complexities and ensures that your operator continuously strives to achieve the desired state.

Advanced Features: Beyond Basic Reconciliation

controller-runtime offers more than just the basic reconcile loop:

• Webhooks (Admission & Conversion):
  • Admission Webhooks: Allows you to intercept API requests to your CRDs (or any other resource) before they are persisted. MutatingAdmissionWebhook can change the object (e.g., inject sidecars, set default values), while ValidatingAdmissionWebhook can reject invalid objects. controller-runtime simplifies the registration and implementation of these webhooks.
  • Conversion Webhooks: Essential for CRD versioning. When you introduce new versions of your CRD (e.g., v1alpha1 to v1beta1), a conversion webhook translates objects between these versions, allowing users to upgrade and downgrade their CRD definitions smoothly without data loss.
• Metrics: Out-of-the-box integration with Prometheus client libraries allows operators to expose useful metrics, such as reconciliation durations, success rates, and the number of processed events. This is critical for observability and troubleshooting in production environments.
• Leader Election: For high availability, you typically run multiple replicas of your operator. controller-runtime includes built-in leader election using Kubernetes Leases, ensuring that only one instance actively performs reconciliation at any given time, preventing conflicts and ensuring consistency.

Pros and Cons of Using controller-runtime Directly

Pros:

• Flexibility and Control: Provides a powerful, unopinionated framework, giving developers maximum control over the operator's design and implementation.
• Performance and Efficiency: Built on top of client-go with efficient caching and event processing mechanisms.
• Kubernetes Native: Leverages the same libraries and patterns used by Kubernetes itself, ensuring deep compatibility.
• Extensive Features: Supports advanced features like webhooks, metrics, and leader election out of the box.
• Foundation for kubebuilder: Understanding controller-runtime is key to mastering kubebuilder as it is the underlying engine.

Cons:

• Boilerplate: While less than raw client-go, it still requires a fair amount of boilerplate code for project setup, CRD definition, and basic controller structure.
• Steeper Learning Curve: Requires a good understanding of Kubernetes concepts, client-go, and controller-runtime abstractions.
• Less Opinionated: The flexibility can sometimes be a double-edged sword, as it leaves more design decisions to the developer.

controller-runtime serves as the bedrock for modern Kubernetes operator development in Golang. It provides the essential tools to build robust, scalable, and highly available controllers that extend the Kubernetes API. While it demands a certain level of familiarity with Kubernetes internals, its well-designed abstractions make the complex task of operator development significantly more manageable. For those looking to manage custom APIs within Kubernetes, understanding controller-runtime is paramount, as it forms the very mechanism through which these custom APIs are brought to life and their associated resources are governed. If these custom resources were to provision external-facing services, an API gateway would be the natural next step to manage their exposure, a concept we will touch upon later.

Section 3: Resource 2 - kubebuilder: Accelerating Operator Development

While controller-runtime provides the essential building blocks for Kubernetes operators, it still requires developers to set up a project structure, define CRD Go types, generate YAML manifests, and configure many aspects manually. This is where kubebuilder steps in. kubebuilder is a framework that supercharges the development process by automating much of the boilerplate, providing an opinionated project structure, and integrating seamlessly with controller-runtime. It's the go-to tool for rapidly scaffolding, developing, and deploying production-ready Kubernetes operators.

What is kubebuilder? A Scaffolding Tool on Top of controller-runtime

kubebuilder is a command-line tool and a set of libraries designed to make building Kubernetes APIs and operators in Go as simple as possible. It builds directly upon controller-runtime, leveraging its capabilities while adding an intelligent layer of code generation and project management. Think of kubebuilder as a complete development workflow solution that guides you from project initialization through to CRD definition, controller logic, webhook implementation, and testing.

Its primary goals are:

• Reduce Boilerplate: Automatically generates project structure, Dockerfiles, Makefiles, CRD YAMLs, controller stubs, and webhook implementations.
• Enforce Best Practices: Provides an opinionated project layout and development workflow that aligns with Kubernetes operator best practices.
• Streamline Development: Simplifies tasks like CRD definition, Go type generation from CRD schemas, and integration with controller-runtime.
• Facilitate Testing: Sets up a robust testing framework for unit, integration, and end-to-end tests.

kubebuilder isn't a replacement for controller-runtime; rather, it's a powerful accelerator that lets you harness the full potential of controller-runtime with significantly less manual effort. It abstracts away the initial setup complexities, allowing developers to immediately focus on the unique business logic of their operator.

Key Features: The kubebuilder Workflow

The kubebuilder workflow is highly structured and typically follows these steps:

1. kubebuilder init: Initializes a new operator project. This command sets up the basic directory structure, go.mod file, Makefile, Dockerfile, and other essential files. It configures the project with your chosen domain, group name, and Go module path. This step establishes the foundation upon which your custom APIs will be built.
2. kubebuilder create api: This is the heart of CRD generation. You specify the Group, Version, and Kind for your custom resource (e.g., group: stable.example.com, version: v1alpha1, kind: Database). kubebuilder then performs several critical actions:
   • Generates CRD Go Types: Creates the api/<version>/<kind>_types.go file, defining the Go struct for your custom resource (e.g., DatabaseSpec, DatabaseStatus). You will then add fields to these structs to define your custom resource's schema.
   • Generates CRD Manifest: Creates the config/crd/bases/<group>_<kind>.yaml file, which is the YAML definition of your CRD that you apply to Kubernetes. This manifest is automatically generated from the Go types, ensuring consistency.
   • Generates Controller Stub: Creates the controllers/<kind>_controller.go file with a basic Reconciler struct and an SetupWithManager method, ready for you to implement your reconciliation logic.
   • Updates main.go: Adds boilerplate code to main.go to register your new CRD types with the Manager and set up the controller.
3. Define CRD Schema in Go Types: After create api, you define the Spec and Status fields of your custom resource in the generated api/<version>/<kind>_types.go file using standard Go structs and json tags. Importantly, kubebuilder leverages Go comments to define OpenAPI v3 schema validations. For example, // +kubebuilder:validation:Minimum=1 can be used to specify schema constraints, which are then automatically reflected in the generated CRD YAML. This allows you to enforce robust validation rules for your custom API.
4. Implement Reconciler Logic: In the controllers/<kind>_controller.go file, you implement the Reconcile method, leveraging the controller-runtime client.Client to interact with the Kubernetes API. This is where you write the core business logic of your operator, similar to how you would with raw controller-runtime.
5. kubebuilder create webhook (Optional): If your operator requires admission or conversion webhooks, this command generates the necessary code for them. You specify the webhook type (validating, mutating, conversion) and kubebuilder creates the Go code and updates the Makefile to generate the required certificates and deploy the webhook server. This ensures that your custom API interactions can be further controlled and validated.
6. make generate, make manifests: These Makefile targets, generated by kubebuilder, are crucial. make generate runs controller-gen to generate code based on markers in your Go types (e.g., DeepCopy methods, client-go interfaces, validation schema). make manifests updates the CRD YAML definitions based on your Go types and markers. These commands maintain the critical synchronization between your Go code and the Kubernetes manifests.
7. make docker-build, make docker-push: kubebuilder also generates a Dockerfile and includes Makefile targets to build and push your operator's container image.
8. make deploy: Deploys your CRD and operator to a Kubernetes cluster.

Project Structure Generated by kubebuilder

A typical kubebuilder project adheres to a well-defined structure:

├── apis/                     # Contains Go types for CRDs (e.g., stable.example.com/v1alpha1/database_types.go)
├── config/                   # Kubernetes YAML manifests for deploying the operator
│   ├── crd/                  # CRD definitions (generated from apis/)
│   ├── default/              # Kustomize base for deployment, RBAC, etc.
│   ├── manager/              # Deployment for the operator controller
│   ├── rbac/                 # Role-based Access Control definitions
│   └── samples/              # Example custom resource instances
├── controllers/              # Reconciler implementations (e.g., database_controller.go)
├── Dockerfile                # Dockerfile for building the operator image
├── go.mod, go.sum            # Go module files
├── main.go                   # Entry point for the operator, sets up manager, controllers, webhooks
├── Makefile                  # Automation for code generation, build, deploy, test
└── PROJECT                   # kubebuilder project metadata

This structure is designed to be intuitive and scalable, making it easy to manage multiple CRDs and controllers within a single operator project.

Testing Strategies with kubebuilder

kubebuilder provides robust support for different testing methodologies, critical for ensuring the reliability of your operators:

• Unit Tests: Standard Go unit tests for individual functions and logic within your reconciler. These mock out Kubernetes API interactions.
• Integration Tests: kubebuilder ships with a envtest package (from controller-runtime/pkg/envtest), which allows you to run a lightweight, in-memory Kubernetes API server and etcd instance locally. This enables you to test your reconciler against a real Kubernetes-like environment without needing a full cluster, providing realistic scenarios for CRD creation, updates, and interactions with native resources.
• End-to-End (E2E) Tests: For testing the deployed operator in a real Kubernetes cluster, kubebuilder can integrate with testing frameworks like Ginkgo and Gomega.

Pros and Cons of Using kubebuilder

Pros:

• Rapid Development: Significantly speeds up operator development by automating boilerplate and code generation.
• Opinionated Structure: Enforces best practices and provides a consistent project layout, improving maintainability and collaboration.
• Integrated Workflow: Provides a complete workflow from project initialization to deployment and testing.
• Reduced Learning Curve: Abstracts away many controller-runtime complexities, especially for initial setup.
• Code Generation: Automates generation of CRD types, manifests, controller stubs, and webhooks, ensuring consistency between Go code and YAML.

Cons:

• Less Flexibility for Advanced Scenarios: While powerful, its opinionated nature can sometimes feel restrictive for highly customized or unconventional operator architectures.
• Dependency on kubebuilder CLI: Relies on the kubebuilder CLI and its generated Makefile for much of the workflow, which can be a dependency to manage.
• Abstraction Layer: While beneficial, the additional abstraction layer means you are one step further removed from the underlying controller-runtime and client-go, which can make debugging complex issues slightly more challenging if you don't understand the underlying components.

kubebuilder is the recommended starting point for most new Kubernetes operator projects in Golang. It significantly lowers the barrier to entry for building powerful custom APIs and controllers, enabling developers to quickly bring their domain-specific orchestrations to life within Kubernetes. For any service provisioned by these operators that needs to interact with the outside world, or for managing the overall lifecycle of these custom APIs from a consumption perspective, a robust API gateway solution becomes invaluable, a topic we will delve into further as we discuss best practices.

APIPark is a high-performance AI gateway that allows you to securely access the most comprehensive LLM APIs globally on the APIPark platform, including OpenAI, Anthropic, Mistral, Llama2, Google Gemini, and more.Try APIPark now! 👇👇👇

Section 4: Comparing controller-runtime and kubebuilder: Choosing the Right Tool

Having explored controller-runtime and kubebuilder in detail, it's clear they are complementary tools in the Golang CRD development ecosystem. While kubebuilder builds upon controller-runtime, they serve slightly different purposes and cater to different levels of developer experience and project needs. Understanding their distinctions is key to choosing the right approach for your specific operator project.

When to Choose controller-runtime Directly

Using controller-runtime directly provides the maximum flexibility and control over your operator's internal workings. It is particularly suitable for:

• Deep Dive and Learning: Developers who want to truly understand the mechanics of Kubernetes controllers, including informers, caches, and event handling, will benefit from starting directly with controller-runtime. It provides a more transparent view of the underlying components.
• Highly Specialized Operators: For operators with unique architectural requirements, unconventional resource watching patterns, or a desire to minimize external dependencies and generated code, controller-runtime offers the freedom to build exactly what's needed without the constraints of an opinionated framework.
• Integrating into Existing Projects: If you're adding controller logic to an existing Golang project that already has a established structure or needs fine-grained control over dependencies, controller-runtime can be integrated more modularly.
• Framework Contribution: For those contributing to controller-runtime itself or developing other frameworks on top of it, direct usage is essential.

When to Choose kubebuilder

kubebuilder is the recommended starting point for the vast majority of new operator projects. Its benefits are most pronounced when:

• Rapid Prototyping and Development: When speed and efficiency are paramount, kubebuilder significantly reduces the time to market for a new operator by automating boilerplate.
• Standardized Projects: For teams aiming for consistency across multiple operator projects, kubebuilder's opinionated structure and code generation enforce best practices and a uniform approach.
• Beginner-Friendly: Developers new to Kubernetes operator development will find kubebuilder's scaffolding and guided workflow much easier to get started with, reducing the initial learning curve.
• Comprehensive Features: If you need features like CRD definition, code generation, controller stubs, webhook support, and integrated testing, kubebuilder provides an all-in-one solution.
• Maintaining Consistency: It helps keep your Go types, CRD manifests, and controller configurations in sync through its make generate and make manifests commands.

Comparative Analysis Table

To further clarify their roles, here's a comparative table highlighting key aspects of controller-runtime and kubebuilder:

Feature/Aspect	controller-runtime	kubebuilder
Primary Role	Core libraries for building Kubernetes controllers	Framework and CLI for scaffolding & managing operator projects
Opinionation	Low (provides building blocks, few prescriptive patterns)	High (provides opinionated project structure, workflow, and code generation)
Learning Curve	Moderate to High (requires understanding core concepts)	Low to Moderate (guided workflow, but benefits from controller-runtime knowledge)
Boilerplate	Significant (manual setup of project, CRD types, Makefiles)	Minimal (automates setup, generates most boilerplate)
Code Generation	Relies on controller-gen separately for types	Integrates controller-gen into its workflow; generates controllers, webhooks, CRDs
CRD Definition	Manual Go struct definition; manual YAML generation	Go struct definition with markers; automated YAML generation
Webhook Support	Provides libraries for building webhooks	Generates webhook server and handler stubs
Testing Support	Provides envtest for integration tests	Integrates envtest, sets up testing framework with Makefile targets
Project Structure	None prescribed, flexible	Opinionated, standardized directory structure
Initial Setup Time	Longer (more manual configuration)	Shorter (quick init and create api commands)
Target Audience	Experienced operator developers, framework contributors	Most operator developers, especially beginners and those valuing rapid development

Synergies Between Them

It's crucial to reiterate that kubebuilder and controller-runtime are not mutually exclusive; they are synergistic. kubebuilder uses controller-runtime internally. When you use kubebuilder, you are implicitly leveraging the power of controller-runtime. The Reconciler interface, the client.Client, the Manager, and the envtest package are all components provided by controller-runtime that kubebuilder orchestrates and simplifies.

A developer starting with kubebuilder will quickly find themselves writing code that directly interacts with controller-runtime's client.Client and implementing the Reconcile method. Therefore, while kubebuilder eases the initial burden, a solid understanding of controller-runtime's principles will greatly enhance a developer's ability to debug, customize, and optimize operators built with kubebuilder. The ideal path for many is to start with kubebuilder for its efficiency and then dive deeper into controller-runtime concepts as the operator grows in complexity or requires more advanced features. This combined approach ensures both rapid development and a deep understanding of the underlying Kubernetes extension mechanisms.

Section 5: Best Practices for Golang CRD Development: Crafting Robust Operators

Developing Kubernetes operators with Golang, whether using controller-runtime directly or kubebuilder, involves more than just writing code that reconciles state. It requires adherence to a set of best practices that ensure the operator is robust, scalable, secure, and maintainable. These practices span CRD design, controller logic, testing, and observability, laying the groundwork for a successful cloud-native extension.

CRD Design Principles: The Foundation of Your Custom API

The Custom Resource Definition is your custom API, and its design heavily influences the usability and maintainability of your operator.

1. Version with Intent (API Versioning):
   • Always start with v1alpha1 for initial, experimental versions. This signals that the API is unstable and may change.
   • Progress to v1beta1 when the API is somewhat stable but still has room for non-breaking changes.
   • Aim for v1 when the API is considered stable and production-ready, guaranteeing backward compatibility.
   • Use conversion webhooks to handle conversions between different versions of your CRD. This ensures that users can upgrade or downgrade their CRD definitions without data loss, and your controller can operate on a single preferred storage version.
2. Schema Validation (OpenAPI v3):
   • Leverage OpenAPI v3 schema validation in your CRD definition to define strict rules for the fields in your custom resources. This includes data types, required fields, minimum/maximum values, string patterns, and immutability constraints.
   • Use // +kubebuilder:validation: markers in your Go structs to automatically generate these validation rules into your CRD YAML. This provides immediate feedback to users when they submit invalid resources, preventing your operator from having to deal with malformed input.
3. Status Subresource:
   • Separate the spec (desired state) from the status (actual observed state). Users write to spec, while your operator updates status.
   • The status should provide clear, actionable information about the resource's current state, including phases (e.g., Pending, Ready, Error), conditions (e.g., Available, Progressing), and any error messages or important metrics. This allows users to easily query the operational status of their custom resource.
   • Always update the status subresource using a separate client update (e.g., client.Status().Update(...)) to avoid conflicts with spec updates.
4. Immutability:
   • Carefully consider which fields, if any, should be immutable after creation. Mark immutable fields using // +kubebuilder:validation:Immutable and enforce this either via schema validation or a validating admission webhook. This prevents unexpected behavior or resource re-creation.
5. Naming Conventions:
   • Follow Kubernetes naming conventions for resource names, groups, and versions (e.g., lowercase, hyphenated).
   • Ensure your Kind name is clear and descriptive of the custom resource's purpose.

Controller Best Practices: Building Resilient Reconciliation Logic

The Reconcile function is the heart of your operator, and its implementation demands careful consideration to ensure resilience and correctness.

1. Idempotency:
   • Your Reconcile function must be idempotent. This means calling it multiple times with the same desired state should produce the same actual state without side effects. Assume your reconciler can be triggered at any time, even without changes, or multiple times for the same change.
   • Avoid direct imperative commands; instead, declare the desired state of secondary resources and let Kubernetes' built-in controllers reconcile them.
2. Error Handling and Requeuing:
   • Always handle errors gracefully. If an unrecoverable error occurs, return an error from Reconcile to signal controller-runtime to requeue the request for a retry.
   • Use backoff strategies for retries to avoid overwhelming external systems or the API server during transient issues. controller-runtime handles exponential backoff by default for returned errors.
   • For external dependencies, consider using reconcile.Result{RequeueAfter: someDuration} to periodically check for changes or availability.
3. Owner References:
   • For all secondary resources created by your operator (e.g., Deployments, Services), set an owner reference back to the primary custom resource. This enables Kubernetes' garbage collection to automatically clean up dependent resources when the primary CRD instance is deleted.
   • Ensure that the owner reference points to the correct API version and kind of your CRD.
4. Event-Driven Architecture:
   • Operators are inherently event-driven. Leverage controller-runtime's Watches() and EnqueueRequestForOwner() to ensure your reconciler is triggered not only by changes to the primary custom resource but also by changes to its owned secondary resources or other relevant resources. This is crucial for reactive behavior.
5. Finalizers for Cleanup:
   • For resources that require external cleanup (e.g., deprovisioning a cloud database), implement finalizers. When a custom resource is marked for deletion, Kubernetes adds a deletion timestamp but doesn't immediately remove the object if finalizers are present. Your operator can then perform the necessary cleanup logic (e.g., call a cloud API to delete the database), and once done, remove the finalizer. Only then will Kubernetes delete the object.
6. Avoid Blocking Operations:
   • Your Reconcile function should return quickly. Avoid long-running, blocking operations. If an operation takes a long time, consider externalizing it to a separate goroutine or using asynchronous patterns, and update the CRD's status to reflect the ongoing work.
7. Resource Ownership and Shared Resources:
   • Be clear about which resources your operator owns exclusively. If multiple operators might manage the same resource, establish clear ownership rules or use mechanisms like labels and annotations to differentiate. Avoid "stomping" on resources owned by other components.

Testing: Ensuring Operator Reliability

Thorough testing is non-negotiable for operators, which often manage critical infrastructure.

1. Unit Tests:
   • Test individual functions and components of your reconciler in isolation. Mock Kubernetes API interactions and external dependencies. Use standard Go testing tools.
2. Integration Tests (envtest):
   • Leverage controller-runtime/pkg/envtest (which kubebuilder integrates) to run your reconciler against a local, in-memory Kubernetes API server and etcd. This provides a realistic environment without the overhead of a full cluster.
   • Test scenarios like CRD creation, updates, deletion, and how your operator interacts with native resources.
   • Ensure your Makefile includes targets for running these tests (make test).
3. End-to-End (E2E) Tests:
   • Deploy your operator and CRDs to a real Kubernetes cluster (e.g., kind, minikube, or a staging cluster).
   • Write tests that simulate user interactions (e.g., kubectl apply, kubectl delete) and verify the desired state is achieved and maintained.
   • E2E tests are crucial for catching issues related to cluster environment, RBAC, and complex interactions that envtest might not fully replicate.

Observability: Seeing Inside Your Operator

Operators are long-running processes that silently manage complex systems. Robust observability is vital for debugging and operational insights.

1. Logging:
   • Use a structured logger (e.g., logr used by controller-runtime) to emit informative logs. Include correlation IDs, resource names, and relevant details.
   • Configure log levels appropriately to control verbosity.
   • Ensure logs are forwarded to a centralized logging system (e.g., Fluentd + Elasticsearch/Loki) for analysis.
2. Metrics:
   • Expose Prometheus metrics from your operator. controller-runtime provides helpers for common metrics like reconciliation duration and queue depth.
   • Add custom metrics relevant to your operator's domain (e.g., number of databases provisioned, external API call latency).
   • Use Grafana or similar tools to visualize these metrics and set up alerts for anomalies.
3. Tracing (Optional but Recommended):
   • For complex operators interacting with multiple external services, consider integrating distributed tracing (e.g., OpenTelemetry) to track requests across different components.

Security Considerations: Building Defensible Operators

Operators run with elevated privileges in a Kubernetes cluster, making security paramount.

1. Least Privilege RBAC:
   • Grant your operator's ServiceAccount only the minimum necessary permissions (Role-Based Access Control) to perform its duties. Avoid cluster-admin unless absolutely essential.
   • Explicitly list the APIGroups, resources, and verbs required. kubebuilder helps generate appropriate RBAC.
2. Image Security:
   • Build operator images on minimal base images (e.g., scratch or distroless) to reduce the attack surface.
   • Scan container images for vulnerabilities using tools like Trivy or Clair.
3. Secrets Management:
   • Never hardcode sensitive information (API keys, passwords) in your operator code or configurations.
   • Use Kubernetes Secrets, Sealed Secrets, or external secret management systems (e.g., HashiCorp Vault) to securely store and inject secrets into your operator.
4. Input Validation:
   • Strictly validate all input from custom resources using CRD schema validation and admission webhooks. Never trust user input implicitly.

Managing Your Custom APIs with APIPark

As you develop sophisticated custom APIs with Golang and manage complex services within Kubernetes using operators, the need for robust API management often extends beyond the cluster's internal boundaries. While your CRDs define internal Kubernetes APIs, the services they provision might need to be exposed externally, consumed by other applications, or managed across teams. This is where an advanced API gateway and management platform becomes essential.

Consider a scenario where your Golang operator provisions several microservices, each exposed via a Kubernetes Service. For external applications, or even internal teams, to consume these services reliably, they require a unified, secure, and observable API gateway. This is precisely the problem that APIPark addresses.

APIPark - Open Source AI Gateway & API Management Platform

Overview: APIPark is an all-in-one AI gateway and API developer portal that is open-sourced under the Apache 2.0 license. It is designed to help developers and enterprises manage, integrate, and deploy AI and REST services with ease.

Official Website: ApiPark

Key Features:

1. Quick Integration of 100+ AI Models: APIPark offers the capability to integrate a variety of AI models with a unified management system for authentication and cost tracking.
2. Unified API Format for AI Invocation: It standardizes the request data format across all AI models, ensuring that changes in AI models or prompts do not affect the application or microservices, thereby simplifying AI usage and maintenance costs.
3. Prompt Encapsulation into REST API: Users can quickly combine AI models with custom prompts to create new APIs, such as sentiment analysis, translation, or data analysis APIs.
4. End-to-End API Lifecycle Management: APIPark assists with managing the entire lifecycle of APIs, including design, publication, invocation, and decommission. It helps regulate API management processes, manage traffic forwarding, load balancing, and versioning of published APIs.
5. API Service Sharing within Teams: The platform allows for the centralized display of all API services, making it easy for different departments and teams to find and use the required API services.
6. Independent API and Access Permissions for Each Tenant: APIPark enables the creation of multiple teams (tenants), each with independent applications, data, user configurations, and security policies, while sharing underlying applications and infrastructure to improve resource utilization and reduce operational costs.
7. API Resource Access Requires Approval: APIPark allows for the activation of subscription approval features, ensuring that callers must subscribe to an API and await administrator approval before they can invoke it, preventing unauthorized API calls and potential data breaches.
8. Performance Rivaling Nginx: With just an 8-core CPU and 8GB of memory, APIPark can achieve over 20,000 TPS, supporting cluster deployment to handle large-scale traffic.
9. Detailed API Call Logging: APIPark provides comprehensive logging capabilities, recording every detail of each API call. This feature allows businesses to quickly trace and troubleshoot issues in API calls, ensuring system stability and data security.
10. Powerful Data Analysis: APIPark analyzes historical call data to display long-term trends and performance changes, helping businesses with preventive maintenance before issues occur.

Deployment: APIPark can be quickly deployed in just 5 minutes with a single command line:

curl -sSO https://download.apipark.com/install/quick-start.sh; bash quick-start.sh

Commercial Support: While the open-source product meets the basic API resource needs of startups, APIPark also offers a commercial version with advanced features and professional technical support for leading enterprises.

About APIPark: APIPark is an open-source AI gateway and API management platform launched by Eolink, one of China's leading API lifecycle governance solution companies. Eolink provides professional API development management, automated testing, monitoring, and gateway operation products to over 100,000 companies worldwide and is actively involved in the open-source ecosystem, serving tens of millions of professional developers globally.

For developers building sophisticated custom APIs with Golang operators that manage complex service meshes or expose various RESTful endpoints, APIPark serves as an ideal external management layer. It can sit in front of the services provisioned by your CRDs, providing centralized authentication, authorization, rate limiting, traffic management, and observability. This ensures that the robust internal automation you've built with controller-runtime or kubebuilder is complemented by equally robust external API gateway capabilities, offering a complete end-to-end solution for your cloud-native APIs, from their internal Kubernetes definition to their external consumption.

Section 6: Advanced Topics and Future Trends in Golang CRD Development

The landscape of Kubernetes and its extension mechanisms is constantly evolving. As operators become more sophisticated, new challenges and opportunities arise. Golang CRD development is at the forefront of these innovations, with ongoing work in areas that push the boundaries of what operators can achieve. Understanding these advanced topics and future trends is crucial for building next-generation cloud-native applications.

Cross-Namespace Reconciliation and Multi-Tenancy

While most CRDs are namespace-scoped, many real-world applications require resources or configurations that span multiple namespaces or even entire clusters.

• Cluster-Scoped CRDs: For global configurations (e.g., IngressClass, StorageClass), cluster-scoped CRDs are used. Operators managing these resources need to understand their cluster-wide impact and reconcile across all namespaces.
• Cross-Namespace References: Operators might need to reference resources in other namespaces. For example, a DatabaseClaim CRD in namespace A might need to provision a Database in namespace B and create a Secret in namespace A containing connection details. Careful design of RBAC and resource ownership is essential here.
• Multi-Tenancy: In multi-tenant Kubernetes clusters, operators must be designed to respect tenant boundaries. This often involves ensuring that a tenant's operator only has permissions to manage resources within its designated namespaces and that its CRDs don't inadvertently affect other tenants. Strategies like per-tenant operators or a single operator with robust authorization checks are common.

Multi-Cluster Operators and Federation

As organizations adopt multi-cluster strategies for high availability, disaster recovery, or geographical distribution, the need for operators that can manage resources across multiple Kubernetes clusters becomes paramount.

• Cluster API: This project is a prime example of a multi-cluster operator, designed to manage the lifecycle of Kubernetes clusters themselves as first-class Kubernetes objects. Operators built with controller-runtime can leverage Cluster API to provision and manage clusters across different cloud providers.
• Federation v2 (KubeFed): KubeFed allows for the synchronization of resources and configuration across multiple clusters. An operator could manage a federated CRD, ensuring that its custom resources are consistently applied and reconciled across a fleet of clusters.
• External Control Planes: Some advanced patterns involve an operator running in a "management cluster" that controls resources in multiple "workload clusters." This requires the operator to have kubeconfig access to all managed clusters and perform remote reconciliation, significantly increasing the complexity of client-go interactions and error handling. This could also mean that the API gateway itself might need to manage services across multiple clusters.

Integrating with External Services and Cloud Providers

Operators often serve as the bridge between Kubernetes and external systems, including cloud provider APIs, external databases, or third-party SaaS platforms.

• Cloud Provider Integration: Operators can provision and manage cloud resources (e.g., AWS EC2 instances, Azure SQL Databases, Google Cloud Storage buckets) in response to CRD declarations. This requires secure authentication with the cloud provider APIs (e.g., using IAM roles, service accounts, or credential injection) and robust error handling for external API calls.
• External Service State Synchronization: An operator might need to synchronize state between a Kubernetes CRD and an external system. For example, a User CRD might create and manage user accounts in an external identity provider. This bidirectional synchronization requires careful design to handle conflicts and ensure eventual consistency.
• Event-Driven External Interactions: Leveraging event queues (e.g., Kafka, RabbitMQ) or webhooks, operators can react to events from external systems or push events to them, creating powerful automation loops. When integrating with such external systems, particularly if they expose their own APIs, an API gateway can be a critical component for managing security, rate limiting, and resilience of those external API interactions from within the operator.

The Evolving Landscape of Kubernetes Operators

The operator pattern continues to mature, with ongoing developments that enhance its capabilities and simplify its adoption:

• Operator SDK and OLM: Beyond kubebuilder, the Operator SDK (which incorporates kubebuilder internally) provides additional tools for building, testing, and deploying operators. The Operator Lifecycle Manager (OLM) provides a way to install, upgrade, and manage operators and their associated CRDs on a cluster, creating an app store-like experience for Kubernetes extensions.
• Runtime Extensions and WebAssembly: Emerging technologies like WebAssembly (Wasm) are being explored to potentially extend Kubernetes in new ways, offering alternative runtimes for lightweight controllers or powerful admission logic. While Golang remains dominant, the ecosystem is always open to innovation.
• AI/ML Operators: With the rise of AI/ML in cloud-native applications, operators are increasingly being used to manage the lifecycle of AI/ML workloads, including model training, deployment, inference services, and data pipelines. This often involves defining custom resources for Model, TrainingJob, or InferenceService. These AI-specific custom APIs, once deployed, are ideal candidates for management through a specialized AI API gateway like APIPark. APIPark, with its ability to quickly integrate 100+ AI models and standardize AI invocation, offers a perfect complement to Golang operators that orchestrate AI workloads within Kubernetes. By creating custom resources that provision AI services, and then exposing and managing those services through APIPark, organizations can achieve a seamless and highly automated AI infrastructure.

The journey into Golang CRD development is an exploration of Kubernetes' deepest capabilities. By mastering controller-runtime and kubebuilder, and staying abreast of these advanced topics and future trends, developers can build truly transformative cloud-native solutions that extend Kubernetes far beyond its initial scope, solving complex orchestration challenges with elegance and efficiency.

Conclusion: Mastering the Art of Kubernetes Extension with Golang

The ability to extend Kubernetes with Custom Resource Definitions and custom controllers is a game-changer for cloud-native development. It transforms Kubernetes from a generic container orchestrator into a highly specialized platform capable of managing virtually any application or infrastructure component with native-like fluidity. For developers looking to wield this immense power, Golang is not merely a suitable language; it is the definitive choice, offering a symbiotic relationship with Kubernetes that delivers performance, robustness, and an unparalleled development experience.

Throughout this extensive guide, we have delved into the two most critical Golang resources that empower this extension: controller-runtime and kubebuilder. controller-runtime stands as the robust foundation, providing the core libraries and patterns for building resilient, event-driven reconciliation logic. It offers granular control over resource watching, event processing, and state management, catering to those who seek a deep understanding and maximum flexibility. On the other hand, kubebuilder acts as the powerful accelerator, abstracting away much of the boilerplate and enforcing best practices through an opinionated framework and extensive code generation. It streamlines the entire development workflow, from CRD definition and controller stub generation to webhook implementation and testing, making it the ideal starting point for most operator projects.

While distinct in their approach, these two resources are intrinsically linked and complementary. kubebuilder leverages controller-runtime under the hood, meaning that a solid grasp of controller-runtime's principles will greatly enhance your proficiency with kubebuilder. By strategically combining their strengths, developers can achieve both rapid iteration and profound control over their Kubernetes extensions.

Beyond the tools themselves, we emphasized the crucial role of best practices. Crafting robust operators demands careful attention to CRD design principles like versioning and schema validation, resilient controller logic built on idempotency and proper error handling, comprehensive testing strategies (unit, integration, E2E), and robust observability through logging and metrics. Furthermore, security considerations, including least-privilege RBAC and secure secrets management, are paramount for operators that often run with elevated permissions.

Finally, we explored how operators often interact with broader cloud-native ecosystems, particularly when the services they manage need to be exposed and governed externally. This highlighted the increasing relevance of advanced API gateway and management platforms like APIPark. Whether your Golang operator provisions RESTful services, manages AI/ML workloads, or integrates with external cloud APIs, APIPark can provide the crucial layer for unified management, security, and observability of these APIs, bridging the gap between internal Kubernetes automation and external consumption.

In essence, mastering Golang CRD development is about more than just writing code; it's about understanding the Kubernetes control plane, embracing the declarative paradigm, and leveraging powerful tools and best practices to build intelligent, self-managing systems. The journey into extending Kubernetes is challenging but profoundly rewarding, enabling you to tailor the world's leading container orchestrator to the precise demands of your applications and unlock a new era of cloud-native automation.

Frequently Asked Questions (FAQs)

1. What is the fundamental difference between controller-runtime and kubebuilder?

controller-runtime is a set of core libraries providing the fundamental building blocks for writing Kubernetes controllers (e.g., client, cache, reconciler interface, manager). It's low-level and flexible. kubebuilder is a higher-level framework and CLI tool that uses controller-runtime internally. It provides scaffolding, code generation, and an opinionated project structure to accelerate operator development, handling much of the boilerplate that controller-runtime users would set up manually. Think of controller-runtime as the engine and kubebuilder as the car with an assembled chassis, making it easier to drive.

2. When should I choose to use controller-runtime directly instead of kubebuilder?

You might choose controller-runtime directly if you need maximum control and flexibility over your project's architecture, want to integrate controller logic into an existing Go project with a unique structure, or if you are specifically trying to learn the deeper mechanics of Kubernetes controllers without the abstraction layers. Experienced developers building highly specialized or unconventional operators, or those contributing to the controller-runtime library itself, often prefer direct usage. For most new operator projects, kubebuilder is the recommended starting point due to its efficiency.

3. How do Custom Resource Definitions (CRDs) relate to APIs, and how does an API Gateway fit in?

CRDs effectively allow you to extend the Kubernetes API by defining new, custom resource types that behave like native Kubernetes objects. Your Golang operator then interacts with these custom APIs to manage domain-specific applications. When services managed by your operator need to be exposed to external consumers or other internal teams outside the immediate Kubernetes cluster, an API gateway becomes essential. An API gateway like APIPark sits in front of these exposed services, providing centralized entry points, managing authentication, authorization, rate limiting, traffic routing, and observability for the entire lifecycle of these external-facing APIs, complementing the internal APIs managed by your CRD controller.

4. What are admission webhooks, and why are they important for CRD development?

Admission webhooks are HTTP callbacks that intercept API requests to the Kubernetes API server before they are persisted. There are two types: MutatingAdmissionWebhook can modify an object (e.g., inject default values or sidecars), and ValidatingAdmissionWebhook can reject invalid objects. They are important for CRD development because they allow you to enforce complex validation rules that go beyond what OpenAPI v3 schema validation can provide, perform dynamic defaulting, or inject additional configuration, ensuring the integrity and correctness of custom resources before your operator even sees them. kubebuilder makes it easy to generate and deploy these webhooks.

5. What are finalizers, and why are they a best practice in Golang CRD development?

Finalizers are special keys added to a Kubernetes object's metadata. When an object with finalizers is deleted, Kubernetes adds a deletion timestamp but does not immediately remove the object. Instead, it waits for the controller (your operator) to remove all finalizers. This mechanism is a crucial best practice for ensuring proper cleanup of external resources. For example, if your operator provisions a database in a cloud provider, you'd add a finalizer to the Database CRD instance. When the CRD is deleted, your operator intercepts this, deprovisions the cloud database, and then removes the finalizer, allowing Kubernetes to finally delete the CRD object. This prevents resource leaks and ensures data integrity during deletion.

🚀You can securely and efficiently call the OpenAI API on APIPark in just two steps:

Step 1: Deploy the APIPark AI gateway in 5 minutes.

APIPark is developed based on Golang, offering strong product performance and low development and maintenance costs. You can deploy APIPark with a single command line.

curl -sSO https://download.apipark.com/install/quick-start.sh; bash quick-start.sh

In my experience, you can see the successful deployment interface within 5 to 10 minutes. Then, you can log in to APIPark using your account.

Step 2: Call the OpenAI API.