unikernels
conmon
unikernels | conmon | |
---|---|---|
2 | 4 | |
536 | 396 | |
0.0% | 1.8% | |
0.0 | 7.7 | |
about 2 years ago | 4 days ago | |
C++ | C | |
- | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
unikernels
-
Nanos – A Unikernel
About unikernels https://github.com/cetic/unikernels?tab=readme-ov-file#unike...
-
Docker is dead?!? Podman - an alternative tool?
Another possibility to switch from Docker containers are the so-called Unikernels. These are briefly mentioned here for the sake of completeness, even though they currently have no significance in the Kubernetes context. An interesting blog post on the topic can be found on Hackernoon. It is an interesting construct that may one day find its way into the world of Kubernetes if containers can be replaced by unikernels. Currently, the use of unikernels would not be feasible in my opinion.
conmon
-
Creating Kubernetes Cluster With CRI-O
It is an open-source, community-driven project which supports OCI-based container registries. It is being maintained by contributors working in Red Hat, Intel, etc. It also comes with a monitoring program known as conmon. Conmon is an OCI container runtime monitor, which makes the communication between CRI-O and runc for a single container.
-
Which alternative for slirp4netns in rootless containers is better?
When considering using socket activation it's good to know that socket-activation has the advantage that you can create on-demand services. And in the future you might be able to do container image upgrades without loosing an active TCP connection https://github.com/containers/conmon/issues/393 (Right now it's just a feature request that I wrote).
-
Docker is dead?!? Podman - an alternative tool?
This was a wrong assumption. Podman directly uses runC or crun instead of containerd using a technology named conmon. Some more useful information can be found in this article.
-
Podman: A Daemonless Container Engine
Well, "daemonless" is kind of marketing - there is still this daemon-per-container 'conmon' thing https://github.com/containers/conmon and I don't get why it is needed because 1) who actually needs to re-attach anyway? 2) container's streams are already properly handled by whatever supervisor (e.g. systemd). You can't disable conmon and I'm not sure if its usage is not hardcoded throughout the codebase.
I would very much like to use Podman as a finally proper container launcher in production (non-FAANG scale - at which you maybe start to need k8s), but having an unnecessary daemon moving part in thousands lines of C makes me frown so far.
What are some alternatives?
podman - Podman: A tool for managing OCI containers and pods.
nanos - A kernel designed to run one and only one application in a virtualized environment
runc - CLI tool for spawning and running containers according to the OCI specification
k3d - Little helper to run CNCF's k3s in Docker
crun - A fast and lightweight fully featured OCI runtime and C library for running containers
nerdctl - contaiNERD CTL - Docker-compatible CLI for containerd, with support for Compose, Rootless, eStargz, OCIcrypt, IPFS, ...
docker - Docker - the open-source application container engine
distribution-spec - OCI Distribution Specification
go - The Go programming language
hub-feedback - Feedback and bug reports for the Docker Hub
pq - a command-line Protobuf parser with Kafka support and JSON output