Introducing APK, the API Platform for Kubernetes, a cutting-edge API management solution designed to leverage the power of Kubernetes for seamless and scalable deployments. APK harnesses Kubernetes' native features, enabling automatic scaling based on load and configurable parameters, utilizing rich Kubernetes metrics.

At the core of APK's robust gateway solution is the meticulously selected Envoy technology, known for exceptional performance, lightweight nature, and perfect compatibility within the APK ecosystem. APK extends beyond traditional gateways with purpose-built extensions addressing specific API management use cases. Some of these extensions have been contributed back to the Envoy community, reflecting our commitment to collaborative innovation.

WSO2 APK adheres to the Kubernetes Gateway API specification, an open-source project managed by the SIG-NETWORK community. This specification introduces vital resources such as GatewayClass, Gateway, HTTPRoute, TCPRoute, and Service, augmenting service networking capabilities in Kubernetes. By adhering to this specification, WSO2 APK seamlessly integrates with Kubernetes service networking, leveraging expressive and extensible interfaces to enhance API management functionality within Kubernetes deployments.

Some characteristics of APK

• APK's microservices architecture offers advantages such as easy scalability and seamless upgrades, harnessing the benefits of the architecture for agility and flexibility.
• The separation of the control plane and data plane in APK allows users to integrate any control plane of their choice, providing maximum flexibility and customization.
• APK is an evolving open-source solution that delivers advanced API management capabilities and is designed for cloud-native architectures, seamlessly integrating with Kubernetes.
• With seamless CI/CD integration, APK supports a streamlined GitOps approach for efficient deployment and management of APIs.
• APK aims to provide API marketplace capabilities, enabling sharing, discovery, and reusability of APIs while focusing on efficient governance and administration.
• With its Kubernetes-native approach, exceptional characteristics, microservices architecture, and commitment to collaboration and innovation, APK sets a new standard for API management.

For more information about APK release planning and project management information, visit APK Project Dashboard

For in-depth information about WSO2 API Management Platform, visit WSO2 API Management

To ask questions and get assistance from our community, visit WSO2 Discord

To learn how to participate in our overall community, visit our community page

In this README:

• Introduction
• Getting Started
• Issue management

You'll find many other useful documents on our Documentation.

APK is an open-source platform for providing complete API Management capabilities on top of the Kubernetes cluster management platform.

APK is composed of these components:

The APK architecture consists of both control plane and data plane components. In the data plane, we have the Config Service, an open API for generating APK configurations and Kubernetes API artifacts based on inputs like OpenAPI schema files. The Deployer Service enables the creation of API artifacts within the gateway runtime, requiring a valid access token for secure deployment.

These components efficiently generate configurations and deploy API artifacts within the data plane. The gateway partition comprises the Router, Enforcer, and Management Client. The Router intercepts API traffic, applying QoS policies for optimal performance. The Enforcer handles authentication and authorization, ensuring authorized access. The Management Client configures and synchronizes the Router and Enforcer, ensuring the gateway partition's smooth operation.

The architecture also includes the Rate Limiting Service, which manages rate limits for API calls. The Router communicates with the Rate Limiter to enforce quota compliance. To facilitate distributed counters across gateways, Redis serves as a shared information store for rate limiting.

WSO2 APK comes with Postman collections to test product APIs and developers can use collection of API requests and configure them to test different scenarios. For example, they can reuse available requests to verify that the API returns the correct responses for different requests. These tests will allow users to identify potential issues or bugs that may need to be addressed before using it. Please refer Postman Tests section of the repo for more information about tests and test artifacts.

To tryout APK please refer to this document.

• Install Helm (3.11.x) and Kubernetes client.

• Setup a Kubernetes cluster. If you want to run it on the local you can use Minikube or Kind or a similar software.

• Setup deployment namespace.

  kubectl create namespace <namespace>

HELM-HOME = apk/helm-charts

1. Execute helm repo add bitnami https://charts.bitnami.com/bitnami and helm repo add jetstack https://charts.jetstack.io.

2. Clone the repo and cd into the HELM-HOME folder.

3. Execute helm dependency build command to download the dependent charts.

4. Now execute helm install apk-test . to install the APK components.

   Optional

   To deploy control plane components only use --set wso2.apk.dp.enabled=false

   To deploy data plane components only use --set wso2.apk.cp.enabled=false

5. Verify the deployment by executing kubectl get pods

• You can either, identify the router-service external IP address to invoke the API through the APK gateway

  kubectl get svc | grep router-service

• or, port forward to router-service to use localhost.

  kubectl port-forward svc/apk-test-wso2-apk-router-service 9095:9095

Follow the instruction below to deploy an API using the kubectl.

1. Create API CR and create production and/or sandbox HTTPRoute CRs, and service for the API backend. You can find a sample CR set in developer/tryout/samples/ folder in this repository.

2. Apply CRs to kubernetes API server using the kubectl.

   kubectl apply -f developer/tryout/samples/

   Note

   Services should be created in a different namespace than APK or Kubernetes System namespaces.

   APIs should be created in the APK deployment namespace.

   Provide the router service external ip to {router_service} in below commands.

3. Get a token to invoke the System API.

   ACCESS_TOKEN=$(curl --location --request POST "https://{router_service}:9095/oauth2/token" \
   --header "Host: idp.am.wso2.com" \
   --header "Authorization: Basic NDVmMWM1YzgtYTkyZS0xMWVkLWFmYTEtMDI0MmFjMTIwMDAyOjRmYmQ2MmVjLWE5MmUtMTFlZC1hZmExLTAyNDJhYzEyMDAwMg==" \
   --header "Content-Type: application/x-www-form-urlencoded" \
   --data-urlencode "grant_type=client_credentials" | jq -r ".access_token")

4. List the created API and retrieve API's id.

   curl --location --request GET "https://{router_service}:9095/api/runtime/apis" \
   --header "Host: api.am.wso2.com" \
   --header "Authorization: Bearer $ACCESS_TOKEN"

5. Get a token to invoke the created API. Provide the API's id to {api_id} in below command.

   INTERNAL_KEY=$(curl --location --request POST "https://{router_service}:9095/api/runtime/apis/{api_id}/generate-key" \
   --header "Content-Type: application/json" \
   --header "Accept: application/json" \
   --header "Host: api.am.wso2.com" \
   --header "Authorization: Bearer $ACCESS_TOKEN" | jq -r ".apikey")

6. Invoke the API.

   curl --location --request GET "https://{router_service}:9095/http-bin-api/1.0.8/get" \
   --header "HOST: gw.wso2.com" \
   --header "Internal-Key: $INTERNAL_KEY"

Test Postman collection

1. Install Java JDK 11.
2. Install Gradle(7.5.1).
3. Install Ballerina Ballerina version: 2201.3.1 (Swan Lake Update 3).
4. Install Go.
5. Install Lua.
6. Docker Runtime Up and Running.

Run apk/build-apk.sh file.

sh build-apk.sh

For example: building Runtime Domain Service

cd runtime/runtime-domain-service
gradle build

We use GitHub to track all of our bugs and feature requests. Each issue we track has a variety of metadata:

• Epic. An epic represents a feature area for APK as a whole. Epics are fairly broad in scope and are basically product-level things.Each issue is ultimately part of an epic.
• Milestone. Each issue is assigned a milestone. This is 0.1, 0.2, ..., or 'Nebulous Future'. The milestone indicates when we think the issue should get addressed.
• Priority. Each issue has a priority which is represented by the column in the Prioritization project. Priority can be one of P1, P2, or >P2. The priority indicates how important it is to address the issue within the milestone. P1 says that themilestone cannot be considered achieved if the issue isn't resolved.