Show HN: Own your Kubernetes: installation, addons, best practices – as code
github.com
github.com
Along the years we actively looked for best tools and practices and incorporated them in this project. We try to bring it closer to a common/initial generic k8s based platform. (it does not plan to compete with RH's OKD, but only it's basic features: out of the box network, ingress controller, monitoring, HighAvailability, etc). Authentication, better security hardening, logging are in future plans.
Do you find it useful now, when one can simply pay jump to gke/eks/aks/pks ?
If so, what should be the next steps to make it a successful project (measured by users and community around it)
When Sugarkube installs your apps, it'll create all the necessary cloud infrastructure you define. It also respects dependencies, so e.g. your Wordpress sites will only be installed once there is a database to back them. You can also choose to only install a subset of your applications (i.e. so you don't need to bother installing the monitoring stack if you just want to work on Jenkins).
Sugarkube can also tear everything down again leaving you with the same clean slate that you started with, so you can use it to spin up and tear down clusters either locally or remotely to your heart's content.
Check out the sample project [2] and accompanying tutorials [3] which demonstrate running a web cluster for a couple of Wordpress sites, and an Ops cluster containing Jenkins, monitoring and Keycloak. Sugarkube supports several advanced use cases, including creating a Kops cluster, installing Keycloak into it, then reconfiguring the Kops cluster to authenticate against the Keycloak instance running inside the cluster. That's all with one command (after you've created a workspace).
I'm happy to answer any questions since I wrote it :-)
[2] https://github.com/sugarkube/sample-project/
[3] https://docs.sugarkube.io/getting-started/tutorials/local-we...
Sugarkube orchestrates other tools. In this case where you have to actually SSH into machines to install kubeadm then Ansible may be a better choice for actually creating the clusters (since there's probabaly no single binary that does that).
However, Sugarkube can also be used as a ready-made release pipeline for applications. In general, using Sugarkube to release applications gives you a standardised way of being able to install apps onto different clusters (local/on-prem/cloud), keeping your options open for the future. So you could use it to promote applications through various dev/testing/staging clusters to production, some of which may be on-prem, some on AWS.
If you're looking to create a common set of applications in your project (monitoring, CI/CD, ingresses, etc.), using Sugarkube would allow users to install them into clusters regardless of how they were created (either by your project via kubeadm, or by Kops/EKS with or without Sugarkube, etc), so your applications may be more generally useful to more people.
However, it is simply in terms of getting this running. No best practices, no plugins, nothing extra. I think one great thing my little project achieved is that it uses each tool for its appropriate task correctly, without creating hard coupling between tools. I made that repository so others could learn (I pushed to github today under a private repo).
I'm glad a more mature project is out there for this.
It's pretty sad that in 2019, to setup a web app that can properly scale you need to understand and use so many technologies. Developing a scalable website in 2013 was a lot easier than in 2019. Back then PaaS was all the rage (Heroku, Google App Engine, Amazon Elastic Beanstalk). Since then, things have gotten much harder.
I suspect that this development has less to do with technical challenges and more to do with revenue. Cloud providers now provide all of these services, and they make little money getting small folks up and running with something that "just works". The real money is going after enterprise clients that need to tweak every detail and have the resources to devote to all of these technologies.
There have been so many platforms and libraries that have come out over the past 10 years, the industry is more than ready for a period of consolidation.
Lambdas are great, and they do borrow much from the ideals of PaaS, including the lack of load balancing or HTTP servers. However, there are so many other extremely common services that Lambdas don't cover, for example: email, background tasks, memcache, databases, search engines, security, and so much more. Nearly every web app needs all of these services, but no one is building a single platform that does all of these things decently well out of the box. Instead, you're pushed towards using a different tool for each one. These custom tools certainly offer more power and control, but having to go chase and evaluate each one is a huge road-block for smaller projects that just want to get off the ground.
Is there anything stopping you from using these? Because they're well maintained and even better than before. In fact, many companies and individuals are still using them. And if you have different needs, it's good that there are more flexible alternatives, no?
If by lock-in that means higher margins for these major cloud providers then the only remedy is to have a free market, and the only way to achieve that is for us to have the ability (or at least the threat) to take our stuff and run.
In short, the word is out now that there is no "free cloud lunch" they're making $billions off of us for what we once called hosting (clever trick!). Yes, we want the promise of "Cloud" but not all of us are SnapChat and/or willing to pay the high premium for it.
Lock-in is fine when you're small, it only becomes problematic when you're big. PaaS platforms are not well suited for big organizations for precisely this reason. However, they're great for trying out something new quickly and having it scale without thinking about it. But Google (and others), realized the real money is not in startups wanting a PaaS platform, but in large enterprises, which are far more sensitive to lock-in.
In the ideal world, they'd provide systems like GAE and make it easy to later convert each service (e.g., database, memcache, tasks, email) to a finely tuned system.
1. Server 2. nginx 3. A certificate 4. DNS
The vast majority of people don’t actually need to scale at all. I got HN hugged once and my little Digital Ocean droplet with nginx performed just fine. Granted, it was a static site. But scalability is one of those things that everyone says they want, but probably don’t actually need (or haven’t really profiled to see if scaling horizontally would help).
I’ve been burned too much by devs using Docker and Kubernetes and all of this other nonsense just to host basic web backends, because I’m always the one who has to clean up the mess when it shits the bed. Web hosting needn’t be difficult, but we keep making it difficult.
I wasn't talking about building a static website, I was talking about building a scalable web app. You can start a project as a hobby, but if you every hope to dream of doing something larger, you should at very least consider a path to expansion. This shouldn't mean jumping into Docker and Kubernetes, which are pretty complex. There should be platforms that handle database and instance scaling automatically. When you start off, you only need one or two instances, and as you grow, new instances get automatically added.
Back in the old days of 2013, this was super easy, no Dockerfile or Kubernetes yaml files were needed. Now, you need to configure every single tiny variable for every operation. This is great for large enterprises, but miserable for small companies that want to get started.
Considering it is built with Go, why is such a aggregation playbook needed? Shouldn't this be the default documentation of Kubernetes?
Do the following to use Kubernetes for what it is meant for! If you want to simply run containers in 1-5 machines - may be look at Docker/Podman + Ansible instead?
HA for controller,
Software defined networking,
Autoscaling pods,
Deployment policies,
Auto discovering DNS
Disaster recovery etc.
If these are not what you _need_, then looking at Kubernetes is probably not smart right?
You want well tested software?
kubectl create namespace pr-12-fix-banner-clipping
helm upgrade --install --wait --set url=pr-12-fix-banner-clipping.example.com pr-12-fix-banner-clipping . --namespace pr-12-fix-banner-clipping
./end2end --url https://pr-12-fix-banner-clipping.example.com
helm delete --purge pr-12-fix-banner-clipping
kubectl delete namespace pr-12-fix-banner-clipping
This assumes infrastructure as code, production like environments, ephemeral compute, etc. It's one of the easiest ways to achieve this and it's available anywhere.
You also don't want something like software defined networking. You want the ability for services to talk to each other, and firewalling at the service level, and when you throw multiple services on shared infrastructure together, the SDN helps you do this.
When you add it altogether, pretty much everyone wants all this stuff if they're going to deliver services at a professional level, but its obviously not the only way to do it, and most people don't want to be working at the kubernetes abstraction level.
(I have a set of setup scripts for Azure at https://github.com/rcarmo/azure-k3s-cluster that can easily be re-used for other environments)
(there is always a difference between curiosity and borderline insanity :))
I think you would generally have the same issues as running a general data center on-prem. I have not seen any resources yet for running one specifically for k8s. I managed a beowulf cluster for a while for running one. It was a complete pain.
Would also be cool to see other CNCF tools included like a service mesh, some DB operators, etc.
I feel bad every time I have to deploy that old rotten piece of code because a lot of our dashboards still use those metrics.