The KubeFox Platform is driven by three core components; API Server, Operator, and Runtime Server.

The API Server implements the KubeFox API, a resource-based (RESTful) programmatic interface provided via HTTP. Several types of primary resources are defined by the API. Additional subresources are defined for each primary resource type.

Most KubeFox API resource types are objects: they represent a concrete instance of a concept, like a config or a system. A smaller number of API resource types are virtual in that they represent operations on objects, rather than objects themselves, such as a deployment or release.

Every primary resource includes a metadata subresource. The metadata subresource contains attributes that apply to all instances (objects) of that resource.

Resources of type config, environment, and system include a special set of subresources known as refs which allow retrieval of a specific resource instance (object). Three types of ref subresources exist: id, tag, and branch. The branch subresource is only included in the system resource. Performing a get on a ref subresource will return the specific resource instance (object) it references.

An id subresource is automatically created when a resource of type config, environment, or system is created. The URI of the subresource is generated by the server and is guaranteed to be unique to that instance of the resource.

A tag subresource can be created by sending the id of the resource instance it should reference. Tag subresources can be created or deleted, but not updated. If a tag subresource is being utilized by a deployment or release it cannot be deleted.

For system resources a branch subresource can be created by sending the id of the resource instance it should reference. Branch subresources can be updated to reference a different id at any time.

API verbs are supported by most primary resources and subresources.

A config contains secrets and component configuration required for a component to process an event.

Supported refs:

• id
• tag

All endpoints are prefixed with the path api/kubefox/v0/.

An environment is a named set of variables. These variables can be accessed by components during runtime or used in route templates. An environment must reference a config so that component configuration can be looked up when processing events assigned to that environment.

Supported refs:

• id
• tag

A system is a collection of applications, components, and routes. They are generated from a KubeFox Git repository tree. The id of a system is the hash of the Git commit for that tree.

Supported refs:

• Id
• Branch
• Tag

Subresources:

• Deployment
• Release

It is possible to start a Kubefox Platform component locally for development. The follow examples apply to starting the runtime-server but can be used to start any component with modifications to the commands. To start port forward to vault and nats:

kubectl port-forward -n kubefox-system service/kfp-vault 8200
kubectl port-forward -n kubefox-system service/kfp-nats 4222

Then start the broker and component on your workstation. This can be done using the launch.json in VS Code. First launch the broker using the launch configuration named runtime-broker. Then launch the runtime server using the runtime launch configuration.

Now copy the following file to ./workstation/runtime-srv-service-local.yaml. Replace <YOUR IP ADDRESS> with the workstation's IP address. This will redirect requests from components running in Kubernetes to the instance running locally on the workstation:

---
apiVersion: v1
kind: Service
metadata:
  name: kfp-runtime-server
  labels:
    app.kubernetes.io/component: runtime-server
    app.kubernetes.io/instance: kubefox
    app.kubernetes.io/name: kubefox
spec:
  clusterIP: None
  ports:
    - name: grpc
      port: 6060
      protocol: TCP
      targetPort: 6060
---
apiVersion: v1
kind: Endpoints
metadata:
  name: kfp-runtime-server
  labels:
    app.kubernetes.io/component: runtime-server
    app.kubernetes.io/instance: kubefox
    app.kubernetes.io/name: kubefox
subsets:
  - addresses:
      - ip: <YOUR IP ADDRESS>
    ports:
      - name: grpc
        port: 6060
        protocol: TCP

Finally, scale down the component running on Kubernetes and redirect the service to the component running locally on the workstation:

kubectl scale -n kubefox-system deployment/kubefox-runtime-server --replicas 0
kubectl delete -n kubefox-system service/kfp-runtime-server
kubectl apply -n kubefox-system -f ./workstation/runtime-srv-service-local.yaml