The Future of Kubernetes

• istio

  87 34,943 10.0 Go

  Connect, secure, control, and observe services.

  

I've been running Istio for years and have never heard of Tetrate. It might be started by people who originally worked on Istio, but the project is primarily driven by Google.

Istio development is primarily driven by its steering committee [0][1], which is led by Google. If you look at the contributors [2], 6 of the top 10 are Google employees (perhaps more - not everyone lists their employer on GitHub). They have an open design process, posting design documents and similar to their Google Drive [3]. The team is likewise active at community events, where they solicit input that drives what they work on.

[0]: https://docs.google.com/spreadsheets/d/1Dt-h9s8G7Wyt4r16ZVqc...

[1]: https://docs.google.com/spreadsheets/d/1Dt-h9s8G7Wyt4r16ZVqc...

[2]: https://github.com/istio/istio/graphs/contributors

[3]: https://istio.io/latest/get-involved/

• buf

  39 8,232 9.5 Go

  The best way of working with Protocol Buffers.

  

Everyone I've worked with save a few that experienced protobufs with extentions immediately finds the benefit once they use them.

However I have yet to convince anyone at an org that isn't already using them that they will change things for the better.

Schema once, code everywhere. It is really nice.

Have you seen Buf? https://buf.build/

• WorkOS

  workos.com sponsored

  The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.

  

• dxvk-native

  23 383 3.0 C++

  Discontinued D3D9/11 but it runs natively on Linux!

It also helps that now you can natively use Direct3D 9 through 11 on Linux.

https://github.com/Joshua-Ashton/dxvk-native

• k3s

  291 26,405 9.6 Go

  Lightweight Kubernetes

  

I've actually written about why i'd personally look towards Docker Swarm for smaller projects and setups in my blog post "Docker Swarm over Kubernetes": https://blog.kronis.dev/articles/docker-swarm-over-kubernete...

(though it is a pretty brief stream of consciousness)

Either that or Hashicorp Nomad, because it is also a pretty nice solution and seems to overall have a brighter future than Swarm does, even if the HCL which it uses is a little bit weird and needs porting over from Docker Compose files.

Admittedly, in the last year, i've also seen Kubernetes be tolerable for on-prem deployments in the form of K3s, which is a lovely project and wastes way less memory and CPU for smaller clusters: https://k3s.io/

I know that many out there won't necessarily have to or won't want to run it on-prem and instead will just run whatever Kubernetes solution will be offered to them by their cloud vendor, which is also a valid point, but not one that i have to deal with.

Instead, i often find myself with a VM that has about 8 GB of RAM and needs to run everything from the actual cluster, to PostgreSQL, RabbitMQ, Redis, a few Java apps and who knows what else inside of a development environment, because clearly that was possible without containers so also should be possible with them. There, running something like Rancher or even a K8s cluster that's made from scratch (or initialized with kubeadm or whatever) would be insanity. And having a shared cluster for the whole company might also necessitate people to just manage it, which isn't in the cards.

Also, in my personal hybrid cloud (homelab + cloud VPSes), running Kubernetes would be comparatively expensive and wasteful, since Docker Swarm still has a lower overhead and Swarm provides me with most of the functionality that i might want, oftentimes in the form of regular containers, e.g. Caddy/Nginx/httpd web server as an ingress with some configuration files.

Actually, anyone who has ever tried to get the K3s Traefik ingress working with a custom wildcard certificate will probably understand why i might actually prefer to do that, since in K3s you'll need the following for such a setup to work:

  - a ConfigMap for Traefik, knowledge about the structure of the ConfigMap (tls.stores.default.defaultCertificate)

Suggest a related project