Guides
Guides
Guides

Develop on Kubernetes

Suggest Edits

In this page, we describes how to use Crafting platform to develop on Kubernetes apps, including following topics:

Here we assume your team has already setup Crafting for Kubernetes properly, and talk about the day-to-day usage from a developer point of view. To learn how to set up, please see Setup for Kubernetes for details. Basically the team should setup in advance of following things:

  • Connect Crafting platform to a shared Kubernetes cluster for hosting the namespaces
  • [optional] Setup direct Kubernetes API server access to run kubectl in sandbox
  • [optional] Setup the template that include a Kubernetes resource for per-dev namespace

Use on-demand per-dev Kubernetes namespace

Crafting enables each developer to launch a dedicated namespace with services running end-to-end in it to support their development and testing work. In this model, each sandbox is launched with a dedicated namespaces along side. The workspaces in the sandbox can directly access services running in the namespace. Developers using different sandboxes will have their own namespaces in Kubernetes.

More importantly, the life-cycle of the Kubernetes namespaces are managed by the sandbox so that:

  • When the sandbox is created, the namespace is created,
  • When the sandbox is deleted, the namespace is deleted as well, freeing up resources.
  • When the sandbox is suspended/resumed, the number of replicas for the services in the namespace can be scaled down to 0/scaled back, respectively, further improving resource utilization.

The mechanism is to leverage Crafting's resource model, define a specially configured Kubernetes resource to implement the namespace management, and include that in the sandbox template. Read here for more details about setup. The following guide assumes that setup is already done by the team.

Shown in the figure above, this sandbox has a workspace and a Kubernetes resource already setup. After launch, the sandbox is created and the corresponding hook to launch the Kubernetes namespace is executed in the workspace (e.g. dev).

We can monitor the creation of the namespace from the Kubernetes Clusters menu, by selecting the connected cluster and namespace (Note that it may take a few refreshes to have the newly created namespace listed). We can see the new namespace is created and the services are getting started in it. When the sandbox launching is done, we can see all services are ready and we can also see them from the workspace with kubectl command

At this point, we have a dedicated Kubernetes environment for testing and debugging. We can run the product flow end-to-end by hitting the Kubernetes Ingress (or Load Balancer Service), or through the endpoint in sandbox, which can be setup to hit any service in the Kubernetes namespace, as shown below.

When the sandbox is suspended (or auto-suspended), the corresponding namespace will be scaled to zero, as shown below, and upon resuming, it will be scaled back quickly.

Intercept traffic from Kubernetes

With Crafting, a developer can replace a service running in a Kubernetes cluster with the dev version running in the Crafting sandbox to develop business logic end-to-end. This is great for quickly iterating the code without rebuilding container every time. You can see your change live instantly.

Crafting does that via traffic interception on a Kubernetes workload. As shown in the figure above, Developer A intercepts the API service, so that the traffic hitting the API service inside the cluster will be rerouted to the API service running in Crafting Sandbox 1's workspace. That way Developer A directly modify the code in the sandbox and rebuild/restart service in the workspace, and then the new version will directly receive traffic from the cluster.

When interception is active, the modified service can also call to other services in the cluster directly using the in-cluster DNS names or Pod/Service IP addresses (such as backend). If there is any callback from other services to the API service, the dev version will receive it. In summary, it's virtually plugged in and replaced the API service in the cluster, effective in an end-to-end flow.

Crafting allows multiple interceptions to be done to the same or different sandbox for an integration testing. In the above figure, Developer B intercepts the Cart service at the same time, so the Cart service in Crafting Sandbox 2 is the effective Cart service used in the cluster. That way, Developer A and Developer B can let their dev version of the service working in the same product flow together for integration testing. Crafting also supports conditional interception for only intercepting specific traffic stream into the services to avoid developers interfering each other. Please see conditional interception for more information.

📘

Did you know?

Traffic interception can be done in any Kubernetes namespaces in the connected cluster, not limited to the per-dev namespace described in Use on-demand per-dev Kubernetes namespace. It can also be used for debugging any Kubernetes deployment in the cluster (e.g. shared staging environment).

To start an interception, we can go to the namespace under Kubernetes Cluster menu item, and click the Start interception for the target service (highlighted below).

In the dialog, select the sandbox and workspace we want to intercept the traffic to and select the source and destination port. After clicking Confirm, the traffic interception is established.

At this time, if we go to the sandbox page, we can see an active interception. Here we can see the detailed information regarding the interception and can stop the interception. Note that we can also start an interception from the sandbox page by clicking the Start interception in the Actions

We can also start or stop Kubernetes interception using CLI

$ cs kubernetes intercept [start|stop]

Conditional interception

Crafting supports Conditional traffic interception, i.e., only intercepting the requests that match specific headers from Kubernetes to sandbox. With conditional interception, Many developers can use a shared Kubernetes deployment as the base environment, and conditionally intercept their own testing traffic to hit the dev version of the service running in their sandbox, without letting their dev version of the service interfere with the rest.

As shown above, only the traffic from Developer A (Green arrow) is subject to the interception to replace API-Service, while traffic from Developer B (Yellow arrow) is not. Similarly, only the traffic from Developer B (Yellow arrow) is intercepted for service Cart. That way, each developer can test their dev version of the service using a shared environment without affecting each other.

This is especially useful when building a per-dev namespace to include all the services is not economical. Specifically, we recommend using conditional routing in either of the following cases:

  • For a large Kubernetes environment with hundreds or thousands of services
  • For a large engineering team with hundreds or thousands of developers.

Conditional interception depends on headers in the request to identify which traffic stream it belongs to, and decide whether to reroute it. Therefore, the services themselves need to support header propagation so that the traffic headers can be passed along. Please see the setup guide regarding how to set it up.

To start a conditional interception, after opening the interception dialog and selecting workloads, ports, etc., uncheck the Intercept all traffic to the sandbox as shown below.

After clicking NEXT, you can get to the conditional routing dialog, where you can add endpoints in your sandbox which will inject headers that can be propagated by common tracing libraries for proper conditional interception.

For example here, we can add an endpoint named test and select the frontend service in our target namespace as entry point (as shown below).

After setting the endpoint, we click START to start the interception.

As shown in the above interception status, now the endpoint test is added to send traffic with special headers to the frontend service. And only traffic with these headers will be routed to the dev version of the checkout service running in the sandbox.

You can start testing your dev version of the checkout service with context of the target Kubernetes namespace without worrying about interfering other developers using the same Kubernetes namespace for their testing.

Demo Video

A demo video for how to develop Kubernetes on Crafting can be found here

Updated about 1 year ago