DEMO: Deploying the wasmCloud Kubernetes Operator
Brooks runs us through what it's like to deploy the wasmcloud-operator. Many engineering teams are asking us for simpler, more agnostic ways to connect K8s to Wasm. The wasmcloud-operator was built to satisfy this ask.
wasmcloud-operator readme is a great starting point if you're new to the operator. The Kubernetes operator was a Cosmonic tool which we recently donated to the wasmCloud ecosystem.
The wasmCloud-operator brings the extensibility of WebAssembly to Kubernetes. It simplifies the deployment and distribution of wasmCloud applications to even the most remote locations; something Kubernetes struggles to do well. Longer blog for more info.
Opinionated methodology for running wasmCloud apps in Kubernetes. Kubernetes is used all over the place as we know. We wanted to allow a K8s-native experience for wasmCloud and an opinionated way to deploy wasmCloud on cloud native infrastructure.
Watch the recording for a step-by-step guide to running the wasmcloud-operator with kind (Kubernetes and Docker tooling).
The beauty of the deploy methodology is that it is intentionally simple, like everything in wasmCloud. One thing to note, a native K8s secret is required to run the wasmCloud cluster as the wasmCloud cluster seed is used to do cluster ID between wasmCloud nodes. Essentially a mini version of the wash-up process.
4 Simple Steps:
Use all of the standard tools that you would deploy on to K8s.
Deploy NATS which is the most important piece if infrastructure for wasmCloud: networking, RPC, etc.
Deploy Wadm to manage many hosts: spreads our apps across them.
Select your custom resources: so the operator knows how to translate the instruction to the host.
Watch the recording to see Dan demo a concrete example of the operator in a prod-like environment.
Using the operator on different K8s clusters. 3 deploys of the host connected by NATS, running on the same lattice. It's possible to connect external sources (geoIP for instance) and direct traffic to a particular K8s cluster based on where the traffic is coming from. Connected back to a 3rd K8s cluster to query remote capability. Clusters can be serving the same application. Scales automatically, infinitely and horizontally and the developer doesn't need to think about it.
We noticed a couple of issues with trace propagation - we updated to a newer version of the downstream OTLP crate we use for wasmCloud and that did change the behaviour of URL provision for exports.
If you are overriding your endpoint this shoudn't affect you but this is something we fixed in the host so that based on the URL you provide will append the v1 or cut it off (GRPC endpoint).
Lands in the next patch of the host or wasmCloud 1.1.
Ritesh - tracing enpoint propogation issue. Thank you so much for the flag.
Bug fix for NATS also included.
New versions of all capability providers will absorb these changes.
Packaging providers in an efficient way. Nice if we could build in debug mode as it's faster to build components and providers in this mode.
Issue has been filed and is a perfect one to dip your feed into. Repeat contributors, this is a great way to understand where we are with Rust support in wash build.
New page in the developer guide in the workflows section.
wash 0.29 finalizing as we speak - we have a couple of additional utilities - validating and deploying apps more quickly.
wash-replace - Jochen: super useful, could this be a default?
Taylor did some work in Wadm to remove the need for versions. Two diff ways at solving the same problem but there should be a way to remove the version, as long as you replace before deploy.
Take a look at this fresh documentation and if you have any requests or feedback jump over to wasmcloud.slack.com - we'd love to understand how you run your workflows.
UPDATE: SigScale in Copenhagen for TM Forum Event
A group of telcos have been working with wasmCloud to explore whether it can replace Kubernetes to handle ODA components (open APIs).
If you're interested in learning more about the TM Forum WebAssembly Canvas Catalyst project, take a look at this recent CNCF blog.
This is the 2nd phase in the project - and the new mission is looking at a unified orchestration methodology for highly distributed applications. Which is why wasmCloud is perfect for the use case.
Standardizes OSS/BSS components (open APIS) that are a little like lego blocks. Wasm components are the same, which makes them perfect. They're also completely open and standardized where K8s remains opinionated.
Cloud Native Live: all things Wasm and Kubernetes. Dan Norris and Taylor Thomas's stream: "Advanced Kubernetes Integrations with wasmCloud" looked at some advanced extension points work, using the wasmCloud operator as the backdrop. Watch to find out how we integrated Wasm into Kubernetes using Rust and extension points like Endpoint Slices, API aggregation and more!
On Cloud Native Live, Taylor joined Synadia's Jeremy Saenz to discuss the benefits of building a distributed Wasm-native reconciliation loop with NATS JetStream. Watch to learn about key-value buckets, streams and work queues, how they work and why they matter. 12 midday ET.
Bailey recently joined Dan Lorenc at Chainguard to discuss all things Wasm, Kubernetes, distroless compute models and more. Tune in for this step-by-step exploration of Wasm.
The CNCF and Bytecode Alliance came together on CNCF Cloud Native Live for an interesting discussion on WASI 0.2 the Component Model..and the role of the BA in driving forward Wasm standards and tooling.
Cloud Native Wasm Day recordings are available! Particular highlights are presentations from our community users MachineMetrics and Orange.
Check out the Arm Developer Podcast where Bailey and Liam discussed the intersection of Wasm and GPU technologies..
Bailey was a guest on a recent Rancher Live podcast with Divya Mohan. Tune in for a deep dive into WASI 0.2!