shifu VS k3s

To create the Shifu Plugin for ChatGPT, I utilized an open-source infrastructure called Shifu: https://github.com/Edgenesis/shifu. Shifu is a Kubernetes-native industrial edge that allows complete IoT interoperability by virtualizing devices into Kubernetes pods. This adaptability and flexibility made it possible for seamless integration with ChatGPT, providing AI access to and control over the physical world. This approach can be applied to a wide range of IoT devices, further expanding AI-human interaction possibilities.

It's heart breaking to see talents especially former colleagues losing their jobs. But it is also a big warning sign telling people to select open-source software for their infrastructure. With that being said, our startup Edgenesis is building an open-source IoT framework, shifu

I don't know if you have any specific problem you wish to address to, but I've been paying attention to this project: https://github.com/Edgenesis/shifu, it is a Kubernetes-native IoT development framework. If you wish to use k8s to "easily scale and manage large numbers of IoT devices, automate deployments, and ensure high availability", maybe you can take a look at this.

I've been working on a k8s native IoT development framework as well: https://github.com/edgenesis/shifu

Should metaverse be completely virtual? Should it be simply a utopia created according to our needs? But what about the real world? Are we all just gonna discard it and escape to the virtual metaverse? That sounds both impractical and disastrous. I would much prefer a physical metaverse instead.

Wait... What the hell is a physical metaverse? In my opinion, it is a place where we can easily alter things around us to serve our needs. But how can we get there? Here's my answer -- IoT. If we can orchestrate various IoT devices with ease, then we are off to a good start. Smart home is a tangible example, it can be viewed as the prototype of a physical metaverse. Here comes the PROBLEM: how can we orchestrate all these heterogeneous IoT devices with ease? Here I proudly introduce you Shifu, a framework to build your own physical metaverse.

The idea of Shifu is quite simple: Shifu creates digtal twins for IoT devices in the form of Kubernetes pods. This way, we can quickly integrate heterogeneous IoT devices into the cluster, and expose their capabilities as APIs. It means Shifu will make building IoT APPs as simple as building web APPs.

Through a "device integration-- data acquisition-- app development-- decision distribution" feedback loop, Shifu enables developers to build their own physical metaverse. What's even better, Shifu is more than just a crazy idea. Shifu has been successfully deployed in various fully automated labs/factories and received exciting results.

Talk is cheap, it's time to show you the code. Please pay us a visit at https://github.com/Edgenesis/shifu, and join the revolution of building your own physical metaverse!!!

BTW, don't forget to give us a star! It means A LOT to us: ) Thx!

Check out our Github page at https://github.com/Edgenesis/shifu for more information and to see how Shifu can help your business with IoT development.

If you're a developer working with MQTT, I highly recommend giving Shifu a try. To get started, head over to it's Github page at https://github.com/Edgenesis/shifu and take a look at the documentation and code examples. It's a game changer and will save you a lot of time and effort.

Shifu is a Kubernetes native, production-grade, protocol & vendor agnostic IoT development framework. You can develope your application while managing your devices, spare the need for maintaining an additional O&M infrastructure. Check https://github.com/Edgenesis/shifu for more details!

Before you dig deep into https://shifu.run for our great product, buzzword-wise it for sure has the following features that can replace what you enjoy in Google IoT Core as easily and fast as turning a switch:

Opinionated meaning it picks, install, patches your CNI/Ingress/Load Balancer/DNS Server/Metrics Server/Monitoring Setup.

k3s is probably most well known as it ships with bunch of preinstall software: https://github.com/k3s-io/k3s so you can just start throwing yaml files at cluster and handling workloads. It's what I use for my homelab.

Paid things I've heard of include OpenStack and SideroLabs. Haven't used personally by SRE coworkers say good things about them.

For self-hosting I've found https://k3s.io to be really good from the SUSE people. Works on basically any Linux distro and makes self-hosting k8s not miserable.

Yes it’s going to depend on which k8s distribution you’re using. We have work in-progress for k3s to natively support nix-snapshotter: https://github.com/k3s-io/k3s/pull/9319

For other distributions, nix-snapshotter works with official containerd releases so it’s just a matter of toml configuration and a systemd unit for nix-snapshotter.

We run Kubernetes outside of NixOS, but yes the NixOS modules provided by the nix-snapshotter certainly make it simple.

K3S: is a lightweight distribution of Kubernetes that is designed for resource-constrained environments. It is an excellent option for running Kubernetes on a virtual machine or cloud server.

I recently purchased a used Lenovo M900 Think Centre (i7 with 32GB RAM) from eBay to expand my mini-homelab, which was just a single Synology DS218+ plugged into my ISP's router (yuck!). Since I've been spending a big chunk of time at work playing around with Kubernetes, I figured that I'd put my skills to the test and run a k3s node on the new server. While I was familiar with k3s before starting this project, I'd never actually run it before, opting for tools like kind (and minikube before that) to run small test clusters for my local development work.

Kubernetes - k3s distribution

I’ve created a local cluster with K3S and installing Windmill could not be simpler with just one chart to configure, which already has sane defaults to get started. For this demo we will also configure workers to passthrough environment variables to our scripts so that they have access to the Kubernetes API server for later.

You should be familiar with Kubernetes and have set up a Kubernetes cluster. I recommend k3s.