Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality. Learn more →
Top 23 Shell Kubernete Projects
-
-
90DaysOfDevOps
This repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
docker-mailserver
Production-ready fullstack but simple mail server (SMTP, IMAP, LDAP, Antispam, Antivirus, etc.) running inside a container.
-
docker-selenium
Provides a simple way to run Selenium Grid with Chrome, Firefox, and Edge using Docker, making it easier to perform browser automation
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
-
containers-roadmap
This is the public roadmap for AWS container services (ECS, ECR, Fargate, and EKS).
-
Kubernetes-Certified-Administrator
Online resources that will help you prepare for taking the CNCF CKA 2020 "Kubernetes Certified Administrator" Certification exam. with time, This is not likely the comprehensive up to date list - please make a pull request if there something that should be added here.
-
container.training
Slides and code samples for training, tutorials, and workshops about Docker, containers, and Kubernetes.
-
sysbox
An open-source, next-generation "runc" that empowers rootless containers to run workloads such as Systemd, Docker, Kubernetes, just like VMs.
-
-
-
eks-distro
Amazon EKS Distro (EKS-D) is a Kubernetes distribution based on and used by Amazon Elastic Kubernetes Service (EKS) to create reliable and secure Kubernetes clusters.
-
-
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
Project mention: Open-source alternative to Heroku, Vercel, and Netlify | news.ycombinator.com | 2024-04-29Would be great to see a comparison to some better known alternatives like
- Dokku [0]
- CapRover [1]
[0] https://dokku.com/
[1] https://caprover.com/
90DaysOfDevOps 2022
I can recommend Docker mailserver (it also works with Podman). It is already pretty lightweight but you can even make it lighter and it has an active community as well as regular updates.
Project mention: Has anyone managed to install changedetection.io with the visual selector? | /r/selfhosted | 2023-11-29Edit: I got some parts of it running. This video is very helpful. I gave up on the official docker repository for change detection io and switched to the LSIO version. I had to first install and run the docker Selenium container (available here). I installed the standalone version of Chrome from that page. Now I added one line to the docker-compose.yml in the environment section (as mentioned in the video. I did not add BASE_URL) and that was "WEBDRIVER_URL=http://192.168.1.15:4444" (this has to be an actual IP address, can't use "localhost" or anything else. I redeployed the container and the webdriver worked.
I overcome this issue with Longhorn which is a native distributed block storage for Kubernetes and supports by default RWM and not only RWO (ReadWriteOnce).
Thanks for showing up and answering questions. Congratulations on the release.
What kind of plans for support of Rust's evolving async ecosystem?
Any particular reason why the public roadmap does not show the columns similar to "Researching", "We're Working On It" like the other similar public AWS Roadmaps? See example for Containers: https://github.com/aws/containers-roadmap/projects/1
Would be nice to have fully working examples on Github, for most common scenarios across most AWS services. This is something that historically
# autocomplete kubectl & helm source <(kubectl completion zsh) source <(helm completion zsh) alias k=kubectl # when using below aliases, print kubectl command and then execute it function kctl() { echo "+ kubectl $@" && command kubectl $@ } # add aliases collection like 'kgpo' for 'kubectl get pods` from https://github.com/ahmetb/kubectl-aliases [ ! -f ~/.kube/aliases.sh ] && curl -fsSL "https://raw.githubusercontent.com/ahmetb/kubectl-aliases/master/.kubectl_aliases" > ~/.kube/aliases.sh && sed -i -e 's/kubectl/kctl/g' ~/.kube/aliases.sh source ~/.kube/aliases.sh # set default namespace alias kn='kctl config set-context --current --namespace' # get events sorted by last timestamp alias kgel='kctl get events --sort-by=.lastTimestamp' # get events sorted by creation timestamp alias kgec='kctl get events --sort-by=.metadata.creationTimestamp' # get pod's descending events function kger() { kctl get events --sort-by=.lastTimestamp --field-selector involvedObject.name="$@" } # get 'real' all alias kgworld='kctl get $(kubectl api-resources --verbs=list --namespaced -o name | paste -sd ",")' # display all nodes resources request and limits alias kgnr="k get nodes --no-headers | awk '{print \$1}' | xargs -I {} sh -c 'echo {} ; kubectl describe node {} | grep Allocated -A 5 | grep -ve Event -ve Allocated -ve percent -ve -- ; echo '" # start a debug pod (including lots of troubleshooting tools) alias kdebug="kctl -n default run debug-$USER --rm -it --tty --image leodotcloud/swiss-army-knife:v0.12 --image-pull-policy=IfNotPresent -- bash" # get pod's containers list function kgpc() { kctl get pod -o jsonpath="{.spec.containers[*].name}" "$@" && echo "" } # ping a service, ex: 'kping whoami:8080' alias kping='kctl run httping -it --image bretfisher/httping --image-pull-policy=IfNotPresent --rm=true --' # get existing pod's yaml without forbidden fields, ex: 'kyaml pod whoami' function kyaml() { kubectl get "$@" -o yaml | kubectl-neat } # display and delete failed pods in current namespace alias krmfailed='kctl delete pods --field-selector=status.phase=Failed'
Project mention: Show HN: Kubetail – A private, real-time log viewer for Kubernetes clusters | news.ycombinator.com | 2024-02-13There is an existing project named kubetail, which is quite popular 3.2K starts https://github.com/johanhaleby/kubetail
Project mention: ☸️ Kubernetes: Awesome Maintained Links You Will Keep Using Next Year | dev.to | 2023-09-03Speaking of cheat sheets, dennyzhang upholds the heatsheet-kubernetes-A4 repository on GitHub. This repository offers a printable single-page A4 cheat sheet.
This is incredibly popular a take, and this anti-k8s is rapidly upvoted almost every time.
The systemd hate has cooled a bit, but it too functions as a sizable attractor for disdain & accusation hurling. Let's look at one of my favorite excerpts from the article, on systemd:
> Fleet was glorious. It was what made me decide to actually learn how to use systemd in earnest. Before I had just been a "bloat bad so systemd bad" pleb, but once I really dug into the inner workings I ended up really liking it. Everything being composable units that let you build up to what you want instead of having to be an expert in all the ways shell script messes with you is just such a better place to operate from. Not to mention being able to restart multiple units with the same command, define ulimits, and easily create "oneshot" jobs. If you're a "systemd hater", please actually give it a chance before you decry it as "complicated bad lol". Shit's complicated because life is complicated.
Shits complicated because life is complicated. In both cases, having encompassing ways to compose connectivity has created a stable base - starting point to expert/advanced capable - that allowed huge communities to bloom. Rather than every person being out there by ourselves, the same tools work well for all users, the same tools are practiced with the same conventions.
Overarching is key to commanlity being possible. You could walk up to my computer and run 'systemd cat' on any service on it, and quickly see how stuff was setup (especially on my computers which make heavy use of environment variables where possible); before every distro and to a sizable degree every single program was launched & configured differently, requires plucking through init scripts to see how or if the init script was modified. But everything has a well defined shape and form in systemd, a huge variety of capabilities for controlling launch characteristics, process isolation, ulimits, user/group privileges, special tmp directories is all provided out of the box in a way that means there's one man page to go to, and that's instantly visible, so we don't have to go spelunking.
The Cloud Native paradigm that Kubernetes practices is a similar work of revelation, offering similar batteries included capabilities. Is it confusing having pods, replicasets, and services? Yes perhaps at first. But it's unparalleled that one just POSTs resources one wants to an API-server and let's the system start & keep that running; this autonomic behavior is incredibly freeing, leaving control loops doing what humans have had to shepherd & maintain themselves for decades; a paradigm break turning human intent directly into consistent running managed systems.
The many abstractions/resource types are warranted, they are separate composable pieces that allow so much. Need to serve on a second port? Easy. Why are there so many different types? Because computers are complex, because this is a model of what really is. Maybe we can reshuffle to get different views, but most of that complexity will need to stay around, but perhaps in refactores shapes.
And like systemd, Kubernetes with it's Desired State Management and operators, it creates a highly visible highly explorable system; any practitioner can walk up to any cluster and start gleening tons of information from it, can easily see it run.
It's a wrong hearted view to think that simpler is better. We should start with essential complexity & figure out simultaneously a) how to leverage and b) how to cut direct paths through our complex capable systems. We gain more by permitting and enabling than by pruning. We gain my by being capable of working at both big and small scales than we gain by winnowing down/down scoping our use cases. The proof is in the pudding. Today there's hundreds of guides one can go through in an hour to setup & get started running some services on k3s. Today there's a colossal communities of homelab operators sharing helm charts & resources (ex: https://github.com/onedr0p/home-ops), the likes of which has vastly outclassed where we have stood before. Being afraid of & shying away from complexity is a natural response, but i want people to show that they see so many of the underlying simplicities & conceptions that we have gotten from kube that do make things vastly simpler than the wild West untamed world we came from, where there weren't unified patterns of API servers & operators, handling different resources but all alike & consistent. To conquer complexity you must understand it, and I think very few of those with a true view of Kubernetes complexity have the sense that there are massive opportunities for better, for simpler. To me, the mission, the goal, the plan should be to better manage & better package Kubernetes to better onboard & help humans through it, to try to walk people into what these abstractions are for & shine lights on how they all mirror real things computers need to be doing.
(Technical note, Kubernetes typically runs 0 vm's, it runs containers. With notable exceptions being snap-in OCI runtimes like Firecracker and Kata which indeed host pods as vms. Kine relies on containers are far more optimizable; works like Puzzlefs and Composefs CSIs can snap-in to allow vastly more memory-and-storage-efficient filesystems to boot. So many wonderful pluggable/snappable layers; CNI for networking too.)
Big fan of Talos, have used it in some homelab + cloud clusters over the years, currently powers all my self-hosting. The `talosctl` command is great, and any time you need to do node-level debugging, there's always something like node-shell [1].
[1] https://github.com/kvaps/kubectl-node-shell
Project mention: Simplified Deployment: A Deep Dive into Containerization and Helm | dev.to | 2023-10-09helm plugin install https://github.com/databus23/helm-diff helm plugin install https://github.com/aslafy-z/helm-git helm plugin install https://github.com/jkroepke/helm-secrets
NOTE:
The open source projects on this list are ordered by number of github stars.
The number of mentions indicates repo mentiontions in the last 12 Months or
since we started tracking (Dec 2020).
Shell Kubernetes related posts
-
Why Kubernetes Was a Mistake for My SaaS Business (🤯)
-
Rebuilding my homelab: Suffering as a service
-
Kubernetes the Hard Way – Vagrant, Ansible, No Cloud
-
Ditching PaaS: Why I Went Back to Self-Hosting
-
What is DevOps?
-
An open-source alternative for Redis, MongoDB on K8s
-
Homelab setup for Kubernetes training
-
A note from our sponsor - InfluxDB
www.influxdata.com | 20 May 2024
Index
What are some of the best open-source Kubernete projects in Shell? This list will help you:
| Project | Stars | |
|---|---|---|
| 1 | Dokku | 26,122 |
| 2 | 90DaysOfDevOps | 25,919 |
| 3 | awesome-kubernetes | 14,773 |
| 4 | docker-mailserver | 13,473 |
| 5 | netshoot | 7,788 |
| 6 | docker-selenium | 7,583 |
| 7 | longhorn | 5,655 |
| 8 | containers-roadmap | 5,152 |
| 9 | Kubernetes-Certified-Administrator | 4,207 |
| 10 | container.training | 3,553 |
| 11 | kube-ps1 | 3,421 |
| 12 | kubectl-aliases | 3,276 |
| 13 | kubetail | 3,262 |
| 14 | sysbox | 2,546 |
| 15 | docker-spark | 2,011 |
| 16 | cheatsheet-kubernetes-A4 | 1,922 |
| 17 | examples | 1,853 |
| 18 | home-ops | 1,764 |
| 19 | eks-distro | 1,346 |
| 20 | kubectl-node-shell | 1,333 |
| 21 | helm-secrets | 1,333 |
| 22 | crunchy-containers | 1,003 |
| 23 | geodesic | 920 |
Sponsored
SaaSHub - Software Alternatives and Reviews
SaaSHub helps you find the best software and product alternatives
www.saashub.com