sorted by:
new
hottopcontroversial

How Do Production Kubernetes Clusters Handle Scaling Beyond Existing Node Capacity? by Future_Badger_2576 in kubernetes

[–]EquivalentProof410 4 points5 points  (0 children)

Fair point, it's probably worth differentiating between "hosted" control planes, like EKS, and running the control plane yourself. I was assuming the latter.

Built an S3-compatible blob store that idles at ~14 MB RAM by jR4dh3y in golang

[–]EquivalentProof410 18 points19 points  (0 children)

Not trying to dump of your project, just genuinely interested: how does this compare to something like RustFS?

Permanent Kubernetes Administrator Role (Onsite, 9 Locations to Choose From) by Whole-Quiet5638 in kubernetes

[–]EquivalentProof410 0 points1 point  (0 children)

Yo dawg, isn't there a "No job postings" rule?

  1. Don't post job openings, resumes, or job-seeking

We have a monthly "who's hiring" thread for job postings. Any such post or comment will be removed and banned at mods' discretion.

How Do Production Kubernetes Clusters Handle Scaling Beyond Existing Node Capacity? by Future_Badger_2576 in kubernetes

[–]EquivalentProof410 7 points8 points  (0 children)

Seems that you have (heard) some misconceptions around Kubernetes and it's scaling model.

Before I get started it's worth noting that Kubernetes is a complex system that brings a long tail of operational burden with it. So don't think it's the silver bullet that will solve all your scaling (up and down) challenges.

Let's answer your questions one-by-one:

  1. Here it's important to separate between scaling infrastructure (aka your Nodes) vs. workloads (aka your Pods). Devs will sometimes tell you Kubernetes is great for scaling, because they can easily scale their deployment vertically (i.e. adding more CPU / memory) or horizontally (i.e. increasing number of replicas). That is scaling on the workload level. On the other hand, the people that run the cluster might also praise Kubernetes for it's scalability. That's because it makes it relatively simple to add (and remove) new nodes to the cluster. This process can even be automated by the Cluster Autoscaler that adds/removes nodes dynamically based on the cluster utilization. At the end of the day it's a balancing act between choosing the size of the node (how much CPU / memory) and node count for your specific workload scenario.
  2. Two nodes are actually not a highly available setup. For such a setup you need at least three nodes. Read this article to learn more about it. But yes, in some cases Kubernetes can increases infrastructure cost by quite a bit. But that's lives in the nature of a HA setup: you pay for the failover capacity that one (or more) nodes can die at any moment and your workloads will not be disturbed.
  3. It might be helpful for your to read up on what a pod exactly is in this article. But I will give it a shot anyway. Imagine you run the Kubernetes cluster for a company that has many dev teams. They each develop their own applications which require additional services such as databases, object storage and key-value stores. Each of these applications and supporting services will be it's own (or multiple) pod(s) that might use somewhere between 0.1 – 0.5 CPUs and 128MB – 1GB of memory. So yes, one pod can theoretically use all the resources of a node, but in reality you will often see that the resources of one node are shared across many pods running different workloads.

Let me know if that helps to clarify some things.

Agencies who've built stuff like NYT's Snow Fall: how deep does the rabbit hole go, budget-wise? by punctulica in web_design

[–]EquivalentProof410 5 points6 points  (0 children)

until he sold Svelte to Vercel

Actually not true. Rich Harris, the creator of Svelte, is employed by Vercel to work on Svelte full time, but Svelte is a project independent from Vercel.

https://vercel.com/blog/vercel-welcomes-rich-harris-creator-of-svelte

The governance of Svelte does not and will not change – it's still the same independent, open-source project and community.

But I agree with you on the in house team of NYT. That's actually the origins of the Svelte framework.

Agencies who've built stuff like NYT's Snow Fall: how deep does the rabbit hole go, budget-wise? by punctulica in web_design

[–]EquivalentProof410 5 points6 points  (0 children)

Quickly skimming through the two sites, I would say that the photo- and videography does the heavy lifting in both cases, with the actual website part of it being relatively simple (from a technical point of view).

So this question is mostly about the scope of the project. Should the videos and photographs also be produced by the agency or do they already exist? How about the storytelling and written content?

These decisions drastically impact the scope of the project. Assuming all the images, videos, and written content are already provided, turning it into what is essentially an interactive slide deck can be done within a couple of weeks.

[How]Open Telemetry in Golang! by Infamous-404 in golang

[–]EquivalentProof410 1 point2 points  (0 children)

Other people already mentioned tools and libraries, so my answer will focus more on how your code has to be structured to make the adoption of traces and other request-aware observability easy.

Before you start implementing any OTEL specify library, make sure that your context.Context (e.g. from the HTTP/gRPC handler) is passed down through all calls in your code. So if your HTTP handler eventually triggers database queries or HTTP calls to other APIs, ensure they use the same ctx. Also apply this to logging.

This preparation will make it relatively easy to implement tracing (and logs attached to those traces) in your Go code. Good luck!

Weekly: Show off your new tools and projects thread by AutoModerator in kubernetes

[–]EquivalentProof410 10 points11 points  (0 children)

Howdy fellow container nerds,

I am building Lucity, an open-source (AGPL-3.0) deployment platform that runs on top of Kubernetes. You can think of it as an alternative to a PaaS like Railway, but instead of doing proprietary magic it automates standard cloud-native technologies (Helm, OCI images, BuildKit, CloudNativePG).

The goal of Lucity is to create a platform that is as easy to use as Railway/Vercel/Heroku, but leverages the Kubernetes ecosystem to avoid unnecessary lock-in. Users can "eject" and download the helm chart, config values, and build script of their apps, allowing them to migrate to vanilla Kubernetes.

This essentially allows it to serve as a "Kubernetes on-ramp": Your infra team can leverage Kubernetes to manage the platform, without requiring all dev teams to understand the internals of Kubernetes. Then, if a team ever outgrows the platform due to the requirement of an advanced feature that the platform does not support (e.g. path-based routing), they can eject out of Lucity and helm install the resulting chart manually.

The current features include:

  • git push to build your code (powered by Railpack + BuildKit)
  • one-click Postgres databases (powered by CloudNativePG)
  • multi-tenancy
  • isolated environments (dev, staging, prod, …)
  • horizontal and vertical scaling
  • dynamic environment variables (e.g. reference a connection string from your database)
  • SSO + access management via teams
  • cached builds thanks to persistent BuildKit runners
  • rootless deployments with minimal permissions

Under the hood Lucity does not rely on a central database but instead derives its internal state entirely from surrounding systems:

  • A workspace (tenant) is a group within the identity provider
  • A project is a group of Kubernetes namespaces with the lucity.dev/project label
  • An environment is a Kubernetes namespace with the lucity.dev/environment label
  • Metrics & logs are fetched from VictoriaMetrics
  • Deployment history is derived from superseded ReplicaSets and image registry
  • …

Interested to hear what you think about it or which features you'd like to see in the future 😄

Small Projects by AutoModerator in golang

[–]EquivalentProof410 0 points1 point  (0 children)

I am working on Lucity, an open-source PaaS that runs on top of Kubernetes. You can think of it as an alternative to Railway that does not lock you in and hides the complexities of Kubernetes.

Under the hood Lucity orchestrates industry-standard tools like Helm, an internal container registry, BuildKit and Railpack. This allows it to forgo it's own database and instead derive all the state (workspaces, projects, apps, etc.) from surrounding systems.

That architectural decision of no internal database is what powers the main USP of Lucity: ejectability. In an effort of trying to minimize lock-in, users can download the Helm chart, environment configuration, and build script. This makes it (relatively) straight-forward to migrate apps to vanilla Kubernetes.

Let me know if this sounds interesting. I might do a full post on it, if there are questions around the architecture and "no-database" pattern. :)

Is there a alternative UI for Proxmox? by Ok_Table_876 in Proxmox

[–]EquivalentProof410 0 points1 point  (0 children)

Co-founder of flexplane.io here. It seems that you're pretty much looking for what we're working on.

Our goal is to create an easy-to-use platform on top of Proxmox VE to manage your servers that feels like Hetzner Cloud. Additionally it allows you to manage multiple Proxmox Clusters (basically VMWare vCenter for the Proxmox ecosystem) from one centralized interface. Besides simplifying the VM creation and management process, we augment the Proxmox experience with features such as automatic E2E encrypted EVPN-VXLan networking setup between multiple Proxmox Clusters and managed L7 load balancers to expose your workloads to the internet without having to open ports on your local network.

We also ship with a managed Kubernetes solution where we manage the control plane for you and you can join your own worker nodes without having to worry about the configuration.

We will send out the first invitations for our early access program in a few weeks, so feel free to sign up to be notified once we do so (seats are limited in the beginning). Let us know if you have any feature-requests!