In this page, we describes how to use Crafting platform to develop on Kubernetes apps, including following topics:
- Use on-demand per-dev Kubernetes namespace with sandbox
- Intercept traffic from Kubernetes to instantly iterate on your code
- Demo video
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
- [optional] Setup the template that include a Kubernetes resource for per-dev 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.
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
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.
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
We can also start or stop Kubernetes interception using CLI
$ cs kubernetes intercept [start|stop]
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.
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.
A demo video for how to develop Kubernetes on Crafting can be found here
Updated 8 months ago