Kubernetes Exposed: One YAML Away from Disaster

This page summarizes the projects mentioned and recommended in the original post on news.ycombinator.com

Our great sponsors
  • WorkOS - The modern identity platform for B2B SaaS
  • InfluxDB - Power Real-Time Data Analytics at Scale
  • SaaSHub - Software Alternatives and Reviews
  • typhoon

    Minimal and free Kubernetes distribution with Terraform

  • This is also why managed Kubernetes is a useful thing (EKS, GKE, et al)... but if you still want to do it yourself, maybe look into some Kubernetes distros (like Typhoon (https://typhoon.psdn.io) which I run on my clusters)

  • Portainer

    Making Docker and Kubernetes management easy.

  • > I moved to docker swarm and love it. It's so much easier, straight forward, automatic ingress network and failover were all working out of the box. I'll stay with swarm for now.

    I've had decent luck in the past with the K3s distribution, which is a bit cut down Kubernetes: https://k3s.io/

    It also integrates nicely with Portainer (aside from occasional Traefik ingress weirdness sometimes), which I already use for Swarm and would suggest to anyone that wants a nice web based UI: https://www.portainer.io/

    Others might also mention K0s, MicroK8s or others - there's lots of options there. But even so, I still run Docker Swarm for most of my private stuff as well and it's a breeze.

    For my needs, it has just the right amount of abstractions: stacks with services that use networks and can have some storage in the form of volumes or bind mounts. Configuration in the form of environment variables and/or mounted files (or secrets), some deployment constraints and dependencies sometimes, some health checks and restart policies, as well as resource limits.

    If I need a mail server, then I just have a container that binds to the ports (even low port numbers) that I need and configure it. If I need a web server, then I can just run Apache/Nginx/Caddy and use more or less 1:1 configuration files that I'd use when setting up either outside of containers, but with the added benefit of being able to refer to other apps by their service names (or aliases, if they have underscores in the names, which sometimes isn't liked).

    At a certain scale, it's dead simple to use - no need for PVs and PVCs, no need for Ingress and Service abstractions, or lots and lots of templating that Helm charts would have (although those are nice in other ways).

  • WorkOS

    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.

    WorkOS logo
  • k3s

    Lightweight Kubernetes

  • > I moved to docker swarm and love it. It's so much easier, straight forward, automatic ingress network and failover were all working out of the box. I'll stay with swarm for now.

    I've had decent luck in the past with the K3s distribution, which is a bit cut down Kubernetes: https://k3s.io/

    It also integrates nicely with Portainer (aside from occasional Traefik ingress weirdness sometimes), which I already use for Swarm and would suggest to anyone that wants a nice web based UI: https://www.portainer.io/

    Others might also mention K0s, MicroK8s or others - there's lots of options there. But even so, I still run Docker Swarm for most of my private stuff as well and it's a breeze.

    For my needs, it has just the right amount of abstractions: stacks with services that use networks and can have some storage in the form of volumes or bind mounts. Configuration in the form of environment variables and/or mounted files (or secrets), some deployment constraints and dependencies sometimes, some health checks and restart policies, as well as resource limits.

    If I need a mail server, then I just have a container that binds to the ports (even low port numbers) that I need and configure it. If I need a web server, then I can just run Apache/Nginx/Caddy and use more or less 1:1 configuration files that I'd use when setting up either outside of containers, but with the added benefit of being able to refer to other apps by their service names (or aliases, if they have underscores in the names, which sometimes isn't liked).

    At a certain scale, it's dead simple to use - no need for PVs and PVCs, no need for Ingress and Service abstractions, or lots and lots of templating that Helm charts would have (although those are nice in other ways).

  • kubeztl

    A zitified kubernetes client

  • https://github.com/openziti-test-kitchen/kubeztl/tree/main

    disclosure: i am a maintainer and the software overlay in the middle (helps enforce outbound-only, pre-authorized connects only) needs to be managed (self-hosted foss or hosted saas), so there are still trade-offs.

NOTE: The number of mentions on this list indicates mentions on common posts plus user suggested alternatives. Hence, a higher number means a more popular project.

Suggest a related project

Related posts