Hi all, This thread is to initiate the discussion on providing native API Management support for K8s. The intention of this is to make convenient managing APIs in Kubernetes cluster in a cloud-native manner. This email contains the basic design and flow of the process. Following diagram depicts the overview design of the intended implementation.
[image: apimoperatos.jpg] *Design overview* WSO2 API Microgateway[1] will be used and backed for managing APIs ( proxying, throttling, security etc). To cater to the above, four custom resource definitions(CRDs) for K8s cluster will be introduced as mentioned below. 1. API Kind - This will be deploying the API with the user given swagger definition. It will pass the swagger definition to the micro-gateway toolkit with the API name so that the given API will be exposed in the Kubernetes cluster via micro-gateway. 2. Endpoint Kind - The endpoint can be given either as an endpoint URL or docker image. If it is defined as a docker image, the controller will create k8s artefacts (deployments/services) for the endpoint using the details mentioned in the endpoint kind. This will be referred from the API swagger definition using vendor extensions. 3. Rate-limiting Kind - Contains the throttle policy details which would ultimately create a policy.yaml file. This will generate the necessary policies source files once mounted to the micro-gateway project(toolkit). 4. Security Kind - It defines the API security. Accept user credentials and certificates followed by adding credentials to the micro-gateway config file and add the certificates to the micro-gateway trust store. After applying all the above resources including the API operator in k8s cluster, an API can be exposed in a k8s cluster with a simple command as "*kubectl add api <api_name> --from-file=<path to swagger.json>".* The ultimate result would be k8s deployments using the micro-gateway docker image exposing the service for the given API definitions. Once the final micro-gateway docker image is built, it will be pushed to a docker registry so that it can be used across different environments (QA, Dev, Pre-prod, Production etc) and spin up necessary APIs in the k8s cluster efficiently. Since docker images are built inside k8s cluster, we are using a Google container tool "Kaniko" [1]. Kaniko builds container images from a Dockerfile, inside a container of a Kubernetes cluster. *Implementation details of APIM Controller/operator:* 1. The operator reads the swagger definition from the config map and resolves if it refers to other kinds( such as endpoints/security etc). 2. The resolved swagger definition will be mounted to the kaniko[2] pod along with the other necessary artefacts (micro-gw.cong, policies.yaml, certificates) to generate the micro-gateway image(micro-gateway executable with micro-gateway runtime). 3. Kaniko container uses Dockerfile, build context etc to build the final docker image and pushes to a destination registry. - Dockerfile which is used in Kaniko will be a multi-staged docker file. - Stage 1: - Run the micro-gateway toolkit and generate the micro-gateway executable file - Stage 2: - Pass the generated executable file to the micro-gateway runtime and start the service - The created docker image's name would be in the format of *<docker_registry>/<api_name>:<api_version>* 4. If the relevant docker image is already available in the registry, the operator would avoid running the Kaniko Pod. Instead, it will create the k8s deployments and services using the relevant available docker images. [1] https://wso2.com/api-management/api-microgateway/ [2] https://github.com/GoogleContainerTools/kaniko/blob/master/README.md Thanks, DinushaD -- *Dinusha Dissanayake* | Senior Software Engineer | WSO2 Inc (m) +94 71 293 9439 | (e) dinus...@wso2.com <https://wso2.com/signature>
_______________________________________________ Dev mailing list Dev@wso2.org http://wso2.org/cgi-bin/mailman/listinfo/dev