How to Use gcloud container operations list api

In the rapidly evolving landscape of cloud computing, managing containerized applications at scale has become a cornerstone for many enterprises. Google Kubernetes Engine (GKE), Google Cloud's managed service for deploying, managing, and scaling containerized applications using Kubernetes, stands out as a robust and powerful platform. However, the sheer complexity and dynamic nature of Kubernetes operations demand vigilant oversight. From creating new clusters to upgrading node pools, every significant change within GKE is an "operation" – a discrete, trackable event that has a lifecycle of its own. Understanding and effectively monitoring these operations is not just a best practice; it's a critical component of maintaining system stability, ensuring successful deployments, and diagnosing issues swiftly.

This comprehensive guide delves deep into one of the most fundamental yet powerful commands within the gcloud CLI for GKE: gcloud container operations list. We will explore its capabilities, demonstrate practical usage scenarios, dissect its output, and provide insights into how you can leverage this command to gain unparalleled visibility into your GKE environment. Our journey will cover everything from basic invocation to advanced filtering and formatting techniques, ensuring you can harness the full potential of this indispensable tool.

The Foundation: Google Kubernetes Engine and gcloud CLI

Before we dive into the specifics of listing operations, it's crucial to establish a foundational understanding of the ecosystem we're working within. Google Kubernetes Engine (GKE) abstracts away much of the underlying infrastructure complexity, allowing developers and operators to focus on deploying and managing their applications rather than the intricacies of infrastructure provisioning. However, behind this abstraction lies a sophisticated orchestration system, and every interaction with GKE, whether initiated through the Google Cloud Console, Terraform, or the gcloud CLI, triggers a series of actions often encapsulated within a GKE operation.

The gcloud command-line interface is the primary tool for interacting with Google Cloud services. It provides a unified and powerful interface, allowing you to manage resources, deploy applications, and retrieve information directly from your terminal. It's built upon a structured command hierarchy, with gcloud container specifically targeting GKE-related functionalities. Within this hierarchy, gcloud container operations is the subgroup dedicated to managing and monitoring these critical GKE operations.

Every action you take that modifies your GKE clusters – be it scaling a node pool, upgrading the Kubernetes version, creating a new cluster, or deleting an existing one – is registered as an operation. These operations are not instantaneous; they often involve provisioning resources, performing health checks, and waiting for various components to stabilize. Monitoring their progress, status, and associated details is paramount for understanding the current state of your GKE environment and proactively addressing any potential issues. Without a clear view into these ongoing and recently completed operations, you'd be flying blind, unable to verify the successful execution of your commands or troubleshoot failures effectively. The gcloud container operations list command serves as your indispensable cockpit instrument, providing that critical visibility.

Setting the Stage: Prerequisites for Using gcloud container operations list

To effectively follow along and utilize the gcloud container operations list api command, you'll need to ensure your environment is properly configured. This involves a few key steps:

1. Google Cloud Project: You must have an active Google Cloud project. All GKE clusters and operations are scoped to a specific project. If you don't have one, you can create one through the Google Cloud Console.
2. gcloud CLI Installation: The Google Cloud SDK, which includes the gcloud command-line tool, must be installed on your local machine. You can find detailed installation instructions for various operating systems in the official Google Cloud documentation. It's crucial to keep your SDK updated to ensure you have access to the latest commands and features.
3. Authentication and Configuration:
   • Authenticate gcloud: After installation, you need to authenticate your gcloud CLI with your Google Cloud account. This is typically done using gcloud auth login. This command will open a browser window, prompting you to log in with your Google account and grant necessary permissions.
   • Set Default Project: It's highly recommended to set a default Google Cloud project for your gcloud commands to avoid specifying --project with every command. You can do this with gcloud config set project [YOUR_PROJECT_ID].
   • Set Default Zone/Region (Optional but Recommended for GKE): GKE clusters are zonal or regional resources. Setting a default zone or region can simplify commands. Use gcloud config set compute/zone [YOUR_ZONE] or gcloud config set compute/region [YOUR_REGION].
   • Enable GKE API: Ensure the Kubernetes Engine API is enabled for your project. You can check and enable it via the Google Cloud Console or using the gcloud command: gcloud services enable container.googleapis.com.

Once these prerequisites are met, you're ready to start exploring the power of gcloud container operations list.

Understanding GKE Operations: What Are They and Why Do They Matter?

In the context of GKE, an "operation" represents a single, asynchronous unit of work initiated by a user or an automated process that modifies the state of a GKE cluster or its components. These operations are often long-running, spanning minutes or even tens of minutes, making real-time monitoring essential. Each operation has a unique identifier, a specific type, a current status, and a target resource it affects.

Consider the lifecycle of a GKE cluster. When you execute gcloud container clusters create my-new-cluster, this command doesn't instantly provision all the resources. Instead, it initiates a "create cluster" operation. This operation then goes through various stages: provisioning control plane, setting up networking, deploying nodes, and finally reaching a "DONE" state. If any of these sub-steps fail, the operation's status will reflect that failure, providing crucial diagnostic information.

Common Types of GKE Operations:

• CREATE_CLUSTER: Initiated when a new GKE cluster is provisioned.
• DELETE_CLUSTER: Triggered when a GKE cluster is decommissioned.
• UPDATE_CLUSTER: Encompasses various cluster modifications like changing master version, enabling/disabling features, or modifying network policies.
• CREATE_NODE_POOL: For adding new node pools to an existing cluster.
• DELETE_NODE_POOL: For removing existing node pools.
• UPDATE_NODE_POOL: For modifying aspects of a node pool, such as machine type, disk size, or image type.
• UPGRADE_MASTER: When the Kubernetes version of the control plane is upgraded.
• UPGRADE_NODES: When the Kubernetes version of the worker nodes is upgraded.
• SET_LABELS: Applying or modifying labels on a cluster.
• SET_LEGACY_ABAC: Enabling or disabling Legacy ABAC authorization.

Why is tracking these operations so important?

1. Verification of Success: After initiating a critical change, you need to confirm it completed successfully. An operation reaching a "DONE" status provides that confirmation.
2. Troubleshooting Failures: If a command fails or hangs, examining the associated operation's status and error details is often the first step in diagnosing the root cause.
3. Understanding System State: Long-running operations can impact cluster performance or availability. Knowing which operations are pending or in progress helps in understanding the current state and planning subsequent actions.
4. Auditing and Compliance: Operations logs provide a historical record of changes made to your GKE clusters, which is vital for security auditing and compliance requirements.
5. Automation and Scripting: In automated workflows, you might need to wait for one operation to complete before initiating another. Polling operation status programmatically is a common pattern in CI/CD pipelines.

In essence, GKE operations are the breadcrumbs that detail the journey of your clusters through various states and transformations. The gcloud container operations list command is your tool for following these breadcrumbs.

The gcloud container operations list Command: Your Eye on GKE

The core of our discussion revolves around the gcloud container operations list command. At its simplest, executing this command without any additional flags will list all GKE operations that have occurred in your currently configured project and default zone/region within a certain timeframe (typically recent operations).

gcloud container operations list

Upon execution, you'll see a table-formatted output, with each row representing a distinct GKE operation. Let's break down the typical columns you'd encounter:

• NAME: A unique identifier for the operation. This is crucial for retrieving more detailed information about a specific operation later using gcloud container operations describe [OPERATION_NAME].
• TYPE: The kind of operation performed (e.g., CREATE_CLUSTER, UPDATE_NODE_POOL, DELETE_CLUSTER).
• STATUS: The current state of the operation (e.g., RUNNING, DONE, PENDING, ABORTING, ABORTED, FAILED).
• TARGET: The name of the GKE cluster or node pool that the operation is acting upon.
• LOCATION: The compute zone or region where the GKE cluster is located.
• START_TIME: The timestamp when the operation began.
• END_TIME: The timestamp when the operation completed or failed. For RUNNING or PENDING operations, this will be empty.
• USER: The email address of the user or service account that initiated the operation. This is incredibly valuable for auditing.

Diving Deeper: Filtering Operations for Precision

While listing all operations can be useful, in a busy GKE environment, the output can quickly become overwhelming. This is where filtering comes into play. gcloud container operations list offers powerful filtering capabilities, allowing you to narrow down the results to precisely what you need.

1. Filtering by Project

If you haven't set a default project or need to view operations across different projects, you can use the --project flag:

gcloud container operations list --project=my-other-gcp-project

2. Filtering by Location (Zone/Region)

GKE clusters are zonal or regional resources. You can filter operations by their location using the --zone or --region flags. Remember that a zone is a specific geographical location within a region (e.g., us-central1-a), while a region is a larger geographical area (e.g., us-central1).

• For zonal clusters: bash gcloud container operations list --zone=us-central1-c
• For regional clusters (or to see operations across all zones in a region): bash gcloud container operations list --region=us-central1 Alternatively, you can omit --zone or --region entirely if you've set a default compute zone/region, or use --global to see all operations across all locations (though this might return a large dataset).

3. Filtering by Status

One of the most common filtering needs is to see operations in a particular state. For instance, you might want to see only currently running operations or only failed ones.

• Show only running operations: bash gcloud container operations list --filter="status=RUNNING"
• Show only failed operations: bash gcloud container operations list --filter="status=FAILED"
• Show operations that are either running or pending: bash gcloud container operations list --filter="status=(RUNNING OR PENDING)"

4. Filtering by Operation Type

If you're interested in specific types of changes, such as cluster creations or node pool updates, you can filter by operationType.

• List all cluster creation operations: bash gcloud container operations list --filter="operationType=CREATE_CLUSTER"
• List all node pool related operations (creation, deletion, update): bash gcloud container operations list --filter="operationType=(CREATE_NODE_POOL OR DELETE_NODE_POOL OR UPDATE_NODE_POOL)"

5. Filtering by Target

To see operations related to a specific GKE cluster or node pool, use the targetLink or target field in the filter. The targetLink is a full resource path, while target is often just the cluster name.

• Operations for a specific cluster: bash gcloud container operations list --filter="target=my-cluster-name"
• Operations for a specific node pool within a cluster (requires knowing the full targetLink which can be found in a describe output): This often requires a more advanced filter based on the full resource name. For simplicity, filtering by target (cluster name) is usually sufficient to narrow it down, then examine the operationType.

6. Filtering by User

For auditing or understanding who initiated a particular change, filtering by the user field is invaluable.

gcloud container operations list --filter="user=user@example.com"

7. Combining Filters

The power of filtering truly shines when you combine multiple criteria. You can use AND, OR, and parentheses for complex expressions.

• List all running UPDATE_CLUSTER operations in us-central1-f: bash gcloud container operations list --filter="status=RUNNING AND operationType=UPDATE_CLUSTER" --zone=us-central1-f
• List all failed operations for my-prod-cluster: bash gcloud container operations list --filter="status=FAILED AND target=my-prod-cluster"

Mastering Output: Formatting Options

The default table output is great for quick glances, but for scripting, automation, or more detailed analysis, you'll often need different output formats. The --format flag is your key here.

1. JSON Format

For programmatic consumption, JSON is often preferred. This provides a structured, machine-readable output.

gcloud container operations list --format=json

This will output an array of JSON objects, each representing an operation. You can then pipe this output to tools like jq for further parsing.

2. YAML Format

YAML is another human-readable, yet machine-parsable, format, often favored for configuration files.

gcloud container operations list --format=yaml

3. CSV Format

For spreadsheet analysis, CSV can be very useful.

gcloud container operations list --format=csv

4. Text Format

The text format provides a simple, space-separated output, which can be easier to parse with basic shell scripting tools like awk or cut.

gcloud container operations list --format=text

5. Custom Formats (Projection)

One of the most powerful features of gcloud formatting is the ability to project specific fields. This allows you to select only the columns you care about and even rename them.

• Example: Get only the operation name, type, and status: bash gcloud container operations list --format="value(name,operationType,status)"
• Example: Rename columns and select specific fields: bash gcloud container operations list --format="table(name:NAME,operationType:TYPE,status:STATUS,user:INITIATED_BY)"

By combining --filter with --format, you can create highly targeted and precisely formatted outputs for any use case, from simple monitoring scripts to complex data ingestion pipelines.

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! 👇👇👇

Advanced Usage Scenarios and Best Practices

With a firm grasp of filtering and formatting, let's explore more advanced scenarios where gcloud container operations list proves indispensable.

Monitoring Long-Running Operations

Many GKE operations, especially cluster creation or version upgrades, can take significant time. It's often necessary to monitor their progress without constantly refreshing the Google Cloud Console.

# Monitor a specific operation by its name, refresh every 10 seconds
watch -n 10 'gcloud container operations describe OPERATION_NAME'

While describe is for a single operation, list can be used to poll for the status of a set of operations:

# Continuously list running operations for a specific cluster
watch -n 5 'gcloud container operations list --filter="target=my-cluster AND status=RUNNING"'

This allows you to keep an eye on operations directly from your terminal, which is especially useful in automation scripts.

Troubleshooting Failed Operations

When a GKE operation fails, understanding why it failed is paramount. The gcloud container operations list --filter="status=FAILED" command is your first line of defense. Once you identify a failed operation, you can use its NAME to get more detailed error messages:

gcloud container operations describe [OPERATION_NAME]

The error field in the describe output will provide specific details about the failure, often including error codes and human-readable messages that can guide your troubleshooting efforts. This detailed api response is crucial for diagnosis.

Scripting and Automation

gcloud container operations list is a workhorse in automation scripts. Imagine a scenario where you want to upgrade your GKE cluster, but only after ensuring that no other critical operations are currently running.

#!/bin/bash

CLUSTER_NAME="my-prod-cluster"
ZONE="us-central1-f"

echo "Checking for pending GKE operations on $CLUSTER_NAME..."

# List running or pending operations for the target cluster
RUNNING_OPS=$(gcloud container operations list --zone=$ZONE --filter="target=$CLUSTER_NAME AND status=(RUNNING OR PENDING)" --format="value(name)")

if [ -n "$RUNNING_OPS" ]; then
    echo "ERROR: Found active operations on $CLUSTER_NAME. Cannot proceed with upgrade."
    echo "Active operations: $RUNNING_OPS"
    exit 1
else
    echo "No active operations found. Proceeding with cluster upgrade..."
    # Your gcloud container clusters upgrade command here
    # Example: gcloud container clusters upgrade $CLUSTER_NAME --master --cluster-version 1.28.3-gke.1068000
fi

This script snippet demonstrates how to leverage the filtered output to make informed decisions within an automated pipeline. The api of gcloud commands makes this kind of scripting very powerful.

Integrating with Other Google Cloud Services

The gcloud CLI commands, including gcloud container operations list, interact with the underlying Google Cloud APIs. This means that the information they expose is also accessible through other means:

• Cloud Logging (Operations Logs): GKE operations generate detailed logs that are automatically sent to Google Cloud Logging. You can view these logs in the Cloud Console, stream them to external systems, or query them using the Cloud Logging api. The operation name and type are usually present in these logs, allowing for rich correlation.
• Cloud Monitoring: While GKE operations themselves aren't directly pushed as metrics, the state changes they represent can trigger alerts. For instance, an UPDATE_CLUSTER operation failing might be correlated with a drop in node health metrics, which Cloud Monitoring can track.

By understanding how gcloud commands translate to underlying api calls and logging events, you gain a holistic view of your GKE environment and can build more resilient monitoring and alerting systems.

Security Considerations: IAM Roles and Auditing

Access to gcloud container operations list and the underlying GKE operations API is governed by Identity and Access Management (IAM) roles. Users or service accounts need appropriate permissions to view operations. The container.operations.list permission is typically part of roles like roles/container.viewer, roles/container.admin, or roles/owner.

• Least Privilege: Always adhere to the principle of least privilege. Grant only the necessary permissions. A developer who only needs to monitor operations might only require a viewer role, not an admin role.
• Audit Logs: All gcloud commands, including gcloud container operations list, generate audit logs in Cloud Audit Logs. These logs record who performed what action, when, and from where. This is crucial for security compliance, post-incident analysis, and ensuring accountability. Regular review of these audit logs, particularly for GKE-related activities, is a recommended security practice.

The Broader Landscape: API Management in the Cloud Era

While gcloud container operations list empowers you to manage the infrastructure and operations of your GKE clusters, the applications running on these clusters often interact with each other and with external services through various Application Programming Interfaces (APIs). These application-level APIs are distinct from the underlying Google Cloud APIs that gcloud commands interact with, but their effective management is equally critical for modern software ecosystems.

In a world increasingly driven by microservices, serverless functions, and AI-powered applications, the sheer volume and complexity of APIs can become daunting. Developers build and consume APIs, businesses expose APIs to partners, and internal teams rely on a web of interconnected APIs to deliver functionality. Managing the entire lifecycle of these APIs – from design and publication to security, traffic management, and analytics – requires dedicated tools.

This is where a robust API management platform becomes indispensable. Just as gcloud streamlines your interaction with cloud infrastructure, an API management platform streamlines your interaction with and governance of your application APIs. It provides a centralized control plane for all your API traffic, offering features like authentication, authorization, rate limiting, caching, transformation, and comprehensive analytics.

One such platform making significant strides in this space, especially for those working with AI and REST services, is ApiPark. APIPark, an open-source AI gateway and API developer portal, helps developers and enterprises manage, integrate, and deploy AI and REST services with remarkable ease. It provides a unified system for authentication and cost tracking across over 100 AI models, standardizes API invocation formats, and even allows users to encapsulate prompts into new REST APIs. This approach drastically simplifies AI usage and reduces maintenance costs by decoupling application logic from specific AI model implementations.

APIPark offers end-to-end API lifecycle management, assisting with design, publication, invocation, and decommissioning. It helps regulate API management processes, manage traffic forwarding, load balancing, and versioning of published APIs. For teams, it facilitates API service sharing within an organization, presenting all services in a centralized display. Furthermore, it supports multi-tenancy, ensuring independent APIs and access permissions for each team, while its subscription approval features prevent unauthorized API calls. With performance rivaling Nginx (over 20,000 TPS on modest hardware) and detailed API call logging and powerful data analysis, APIPark provides the necessary tools to ensure API stability, security, and optimization. While gcloud focuses on the "how" of cloud infrastructure, platforms like APIPark focus on the "how" of API delivery and consumption, ensuring your applications thrive on that infrastructure.

Best Practices for Overall GKE Operations Management

Beyond just using gcloud container operations list, adopting a holistic approach to GKE operations management will significantly enhance your reliability and efficiency.

1. Automate Everything Possible: Manual operations are prone to human error. Use Infrastructure as Code (IaC) tools like Terraform to define and manage your GKE clusters and node pools. This ensures consistency and reproducibility. Your automation scripts can then incorporate gcloud container operations list to monitor the progress of these automated changes.
2. Implement Robust Monitoring and Alerting: Don't just rely on manual checks. Set up alerts in Cloud Monitoring or other observability platforms to notify you of failed operations, prolonged pending operations, or other anomalies. Integrate GKE operation logs into your central logging system for easier analysis.
3. Regularly Review Operation History: Periodically review your GKE operation history (e.g., weekly or monthly) using gcloud container operations list and Cloud Logging. This can help identify recurring issues, unauthorized changes, or patterns that indicate underlying problems.
4. Use Labels and Annotations: Apply meaningful labels to your GKE clusters and node pools. While gcloud container operations list doesn't filter directly by labels on the target, using descriptive names and consistent labeling helps correlate operations with specific environments, teams, or applications.
5. Understand GKE Versioning and Upgrade Strategies: GKE frequently releases new Kubernetes versions. Have a clear strategy for upgrading your clusters and node pools. Monitor UPGRADE_MASTER and UPGRADE_NODES operations closely during these critical periods. Use gcloud container operations list to ensure all nodes are successfully upgraded.
6. Document Processes: Maintain clear documentation for GKE operational procedures, including how to check operation status, troubleshoot common failures, and escalate issues. This ensures consistency, especially in larger teams.
7. Practice Disaster Recovery: Simulate failures and test your recovery procedures. This includes understanding how to quickly identify the root cause of an issue using tools like gcloud container operations list and how to revert or correct a failed operation.

By integrating gcloud container operations list into your daily workflow, automation scripts, and monitoring routines, you'll transform reactive troubleshooting into proactive management, ensuring your GKE environment remains stable, performant, and secure.

Field Name	Description	Example Value	Filtering Example (--filter)
name	Unique identifier for the operation.	operation-1678888888888-abcdefgh	name:operation-123*
operationType	The type of GKE operation performed.	CREATE_CLUSTER	operationType=UPDATE_NODE_POOL
status	Current state of the operation.	RUNNING, DONE, FAILED	status=FAILED
targetLink	Full resource path of the GKE cluster/node pool affected.	/v1/projects/.../clusters/my-cluster	targetLink:*my-cluster*
target	Name of the GKE cluster or node pool.	my-cluster	target=my-prod-cluster
location	Google Cloud zone or region where the cluster resides.	us-central1-c	location=asia-east1
startTime	Timestamp when the operation began (RFC3339 format).	2023-10-27T10:00:00Z	startTime > "2023-10-26"
endTime	Timestamp when the operation completed/failed (RFC3339 format).	2023-10-27T10:15:00Z	endTime < "2023-10-27T12:00:00Z"
user	Email of the user or service account initiating the operation.	user@example.com	user:my-service-account@*
statusMessage	A human-readable message about the operation status.	Resource "..." is being created.	statusMessage:*error*
selfLink	URL for the operation resource itself.	/v1/projects/.../operations/...	(Rarely filtered directly)
zone	Alias for location when the cluster is zonal.	us-central1-c	zone=us-central1-a

Table 1: Key Fields and Filtering Options for gcloud container operations list

Conclusion

The gcloud container operations list command is more than just a simple listing tool; it's a window into the very heartbeat of your Google Kubernetes Engine environment. By providing granular visibility into every significant action performed on your clusters, it empowers you to verify changes, diagnose issues, ensure compliance, and build robust automation workflows. From understanding the basic command structure to mastering advanced filtering and formatting, the insights gained from this api are invaluable for any GKE administrator or developer.

In the complex tapestry of cloud infrastructure, where infrastructure as code meets dynamic application workloads, having reliable tools to monitor the state of your systems is paramount. Whether you're a seasoned SRE managing mission-critical production clusters or a developer iterating on new microservices, integrating gcloud container operations list into your toolkit will undoubtedly enhance your efficiency and bolster the resilience of your GKE deployments. Embrace this powerful command, and take a significant step towards truly mastering your Google Cloud operations.

Frequently Asked Questions (FAQ)

1. How can I get more detailed information about a specific GKE operation after listing it?

Once you have identified an operation's NAME using gcloud container operations list, you can use the gcloud container operations describe command followed by the operation name to retrieve comprehensive details, including any error messages if the operation failed. Example: gcloud container operations describe operation-1234567890abcdef

2. What are the common statuses for GKE operations, and what do they mean?

The most common statuses are: * PENDING: The operation has been submitted but has not started execution yet. * RUNNING: The operation is currently in progress. * DONE: The operation completed successfully. * FAILED: The operation encountered an error and did not complete successfully. * ABORTING: The operation is in the process of being canceled. * ABORTED: The operation was canceled before completion.

3. Can I monitor GKE operations across multiple Google Cloud projects simultaneously?

No, gcloud container operations list operates on a single project at a time. To monitor operations across multiple projects, you would need to either: 1. Iterate through your projects using a shell script, changing the default project (gcloud config set project) or specifying the --project flag for each command. 2. Use Google Cloud's Operations (formerly Stackdriver) for centralized logging and monitoring, where you can aggregate logs from multiple projects and query for GKE operations across them.

4. How can I automate actions based on the completion or failure of a GKE operation?

You can write shell scripts or use gcloud's capabilities within CI/CD pipelines. A common pattern is to initiate an operation, then periodically poll its status using gcloud container operations list --filter="name=OPERATION_NAME" (or describe) until the status is DONE or FAILED. Based on the final status, you can trigger subsequent actions or send notifications. For more advanced event-driven automation, consider using Cloud Logging exports to Cloud Pub/Sub and then Cloud Functions to react to specific operation log entries.

5. What is the difference between a GKE operation and a Cloud Logging entry?

A GKE operation is a high-level, discrete unit of work that modifies your GKE cluster or its components, tracked by the GKE API. Each operation has a lifecycle (pending, running, done, failed). A Cloud Logging entry, on the other hand, is a much more granular record of an event or message generated by a Google Cloud service, including GKE. While GKE operations generate multiple related log entries throughout their lifecycle, the operation itself is a consolidated view of that entire workflow. You can find log entries associated with a specific operation in Cloud Logging, often by filtering by the operation's name or id.

🚀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.