This article explains a new approach to running your applications in Kubernetes using WebAssembly instead of containers. The article will explain what a Krustlet is and why you should care about this new approach. Before going into the details of Krustlet, a quick recap on a high-level view of the Kubernetes architecture is provided.
Kubernetes System Architecture
Kubernetes is essentially a tool that allows scaling applications by mapping containers, executable software units, onto a number of hosts, so-called worker nodes. Usually, a Kubernetes cluster is controlled by one or more master nodes, which is the brain of the cluster.
The master node is the interface for the software engineer to provide a desired state to the cluster via the API server. At the same time, the master node requires the possibility to run containers on the worker nodes in order to fulfill the config provided by the software engineer. It does this by passing a pod specification to the worker node.
The worker node needs to interpret the configuration and implement it in its container runtime, which means pulling the container image, running it, and checking the health of the container. The worker node does this by running a component called Kubelet. The Kubelet is a component that acts like a translator, it translates the pod specification into the actions that need to be executed on the container runtime.
From Kubelet to Krustlet
WebAssembly is a binary format that allows low-level access to the browser. You can take a programming language and compile it into a powerful portable binary format that runs almost at native speed. WebAssembly was built to run alongside JavaScript in the browser. Every developer who has worked on the Web knows a key feature of developing browser applications is to sandbox your application, meaning your application does only interact and access data within your application.
You would not want your banking website to share the data with your Chat provider for instance. This idea of sandboxing was built into WebAssembly and has been battle-tested extensively. The potential of creating portable software packages that can be created from many different programming languages is not only helpful in the browser. However, to build applications outside of the browser, you need the capabilities to interact with the underlying system. Those capabilities were specified in the WebAssembly System interface, short WASI. One WASI implementation is wasmtime, a standalone runtime for WebAssembly. Instead of the browser, you use wasmtime to run your code and interact with the underlying system, e.g. accessing files, and networking (even though this is still tricky).
WebAssembly vs Containers
Based on the information above, we can see that WebAssembly is a way of building portable software units and running them isolated in their sandbox, which is essentially something that containers already offer. Containers allow packing software and sandboxing on an operating system level. While this gives developers a lot of flexibility, it comes with an overhead.
The packaging of WebAssembly is much more lightweight, as containers unfortunately often include unnecessary system dependencies, which increase the image size and create a bigger attack surface for hackers. In addition to the smaller memory and storage footprint, it promises faster startup and shutdown times. It should be noted that Krustlet is still under heavy development, but it has the potential to be particularly interesting in IoT because the lightweight, portable character fits fantastically into a resource-constrained problem domain.
Want to build the products of the future?
This article explains a new approach to running your applications in Kubernetes using WebAssembly instead of containers. The article will explain what a Krustlet is and why you should care about this new approach. Before going into the details of Krustlet, a quick recap on a high-level view of the Kubernetes architecture is provided.
Kubernetes System Architecture
Kubernetes is essentially a tool that allows scaling applications by mapping containers, executable software units, onto a number of hosts, so-called worker nodes. Usually, a Kubernetes cluster is controlled by one or more master nodes, which is the brain of the cluster.
The master node is the interface for the software engineer to provide a desired state to the cluster via the API server. At the same time, the master node requires the possibility to run containers on the worker nodes in order to fulfill the config provided by the software engineer. It does this by passing a pod specification to the worker node.
The worker node needs to interpret the configuration and implement it in its container runtime, which means pulling the container image, running it, and checking the health of the container. The worker node does this by running a component called Kubelet. The Kubelet is a component that acts like a translator, it translates the pod specification into the actions that need to be executed on the container runtime.
From Kubelet to Krustlet
WebAssembly is a binary format that allows low-level access to the browser. You can take a programming language and compile it into a powerful portable binary format that runs almost at native speed. WebAssembly was built to run alongside JavaScript in the browser. Every developer who has worked on the Web knows a key feature of developing browser applications is to sandbox your application, meaning your application does only interact and access data within your application.
You would not want your banking website to share the data with your Chat provider for instance. This idea of sandboxing was built into WebAssembly and has been battle-tested extensively. The potential of creating portable software packages that can be created from many different programming languages is not only helpful in the browser. However, to build applications outside of the browser, you need the capabilities to interact with the underlying system. Those capabilities were specified in the WebAssembly System interface, short WASI. One WASI implementation is wasmtime, a standalone runtime for WebAssembly. Instead of the browser, you use wasmtime to run your code and interact with the underlying system, e.g. accessing files, and networking (even though this is still tricky).
WebAssembly vs Containers
Based on the information above, we can see that WebAssembly is a way of building portable software units and running them isolated in their sandbox, which is essentially something that containers already offer. Containers allow packing software and sandboxing on an operating system level. While this gives developers a lot of flexibility, it comes with an overhead.
The packaging of WebAssembly is much more lightweight, as containers unfortunately often include unnecessary system dependencies, which increase the image size and create a bigger attack surface for hackers. In addition to the smaller memory and storage footprint, it promises faster startup and shutdown times. It should be noted that Krustlet is still under heavy development, but it has the potential to be particularly interesting in IoT because the lightweight, portable character fits fantastically into a resource-constrained problem domain.
Want to build the products of the future?
This article explains a new approach to running your applications in Kubernetes using WebAssembly instead of containers. The article will explain what a Krustlet is and why you should care about this new approach. Before going into the details of Krustlet, a quick recap on a high-level view of the Kubernetes architecture is provided.
Kubernetes System Architecture
Kubernetes is essentially a tool that allows scaling applications by mapping containers, executable software units, onto a number of hosts, so-called worker nodes. Usually, a Kubernetes cluster is controlled by one or more master nodes, which is the brain of the cluster.
The master node is the interface for the software engineer to provide a desired state to the cluster via the API server. At the same time, the master node requires the possibility to run containers on the worker nodes in order to fulfill the config provided by the software engineer. It does this by passing a pod specification to the worker node.
The worker node needs to interpret the configuration and implement it in its container runtime, which means pulling the container image, running it, and checking the health of the container. The worker node does this by running a component called Kubelet. The Kubelet is a component that acts like a translator, it translates the pod specification into the actions that need to be executed on the container runtime.
From Kubelet to Krustlet
WebAssembly is a binary format that allows low-level access to the browser. You can take a programming language and compile it into a powerful portable binary format that runs almost at native speed. WebAssembly was built to run alongside JavaScript in the browser. Every developer who has worked on the Web knows a key feature of developing browser applications is to sandbox your application, meaning your application does only interact and access data within your application.
You would not want your banking website to share the data with your Chat provider for instance. This idea of sandboxing was built into WebAssembly and has been battle-tested extensively. The potential of creating portable software packages that can be created from many different programming languages is not only helpful in the browser. However, to build applications outside of the browser, you need the capabilities to interact with the underlying system. Those capabilities were specified in the WebAssembly System interface, short WASI. One WASI implementation is wasmtime, a standalone runtime for WebAssembly. Instead of the browser, you use wasmtime to run your code and interact with the underlying system, e.g. accessing files, and networking (even though this is still tricky).
WebAssembly vs Containers
Based on the information above, we can see that WebAssembly is a way of building portable software units and running them isolated in their sandbox, which is essentially something that containers already offer. Containers allow packing software and sandboxing on an operating system level. While this gives developers a lot of flexibility, it comes with an overhead.
The packaging of WebAssembly is much more lightweight, as containers unfortunately often include unnecessary system dependencies, which increase the image size and create a bigger attack surface for hackers. In addition to the smaller memory and storage footprint, it promises faster startup and shutdown times. It should be noted that Krustlet is still under heavy development, but it has the potential to be particularly interesting in IoT because the lightweight, portable character fits fantastically into a resource-constrained problem domain.
Want to build the products of the future?
This article explains a new approach to running your applications in Kubernetes using WebAssembly instead of containers. The article will explain what a Krustlet is and why you should care about this new approach. Before going into the details of Krustlet, a quick recap on a high-level view of the Kubernetes architecture is provided.
Kubernetes System Architecture
Kubernetes is essentially a tool that allows scaling applications by mapping containers, executable software units, onto a number of hosts, so-called worker nodes. Usually, a Kubernetes cluster is controlled by one or more master nodes, which is the brain of the cluster.
The master node is the interface for the software engineer to provide a desired state to the cluster via the API server. At the same time, the master node requires the possibility to run containers on the worker nodes in order to fulfill the config provided by the software engineer. It does this by passing a pod specification to the worker node.
The worker node needs to interpret the configuration and implement it in its container runtime, which means pulling the container image, running it, and checking the health of the container. The worker node does this by running a component called Kubelet. The Kubelet is a component that acts like a translator, it translates the pod specification into the actions that need to be executed on the container runtime.
From Kubelet to Krustlet
WebAssembly is a binary format that allows low-level access to the browser. You can take a programming language and compile it into a powerful portable binary format that runs almost at native speed. WebAssembly was built to run alongside JavaScript in the browser. Every developer who has worked on the Web knows a key feature of developing browser applications is to sandbox your application, meaning your application does only interact and access data within your application.
You would not want your banking website to share the data with your Chat provider for instance. This idea of sandboxing was built into WebAssembly and has been battle-tested extensively. The potential of creating portable software packages that can be created from many different programming languages is not only helpful in the browser. However, to build applications outside of the browser, you need the capabilities to interact with the underlying system. Those capabilities were specified in the WebAssembly System interface, short WASI. One WASI implementation is wasmtime, a standalone runtime for WebAssembly. Instead of the browser, you use wasmtime to run your code and interact with the underlying system, e.g. accessing files, and networking (even though this is still tricky).
WebAssembly vs Containers
Based on the information above, we can see that WebAssembly is a way of building portable software units and running them isolated in their sandbox, which is essentially something that containers already offer. Containers allow packing software and sandboxing on an operating system level. While this gives developers a lot of flexibility, it comes with an overhead.
The packaging of WebAssembly is much more lightweight, as containers unfortunately often include unnecessary system dependencies, which increase the image size and create a bigger attack surface for hackers. In addition to the smaller memory and storage footprint, it promises faster startup and shutdown times. It should be noted that Krustlet is still under heavy development, but it has the potential to be particularly interesting in IoT because the lightweight, portable character fits fantastically into a resource-constrained problem domain.