Recent submissions

Comment · 1 year ago
This is the approach we took while building our Internal Developer Platform: watches (via client-go informers with client-side caching) to sync data into a Postgres database as JSONB. Changes are tracked using JSON patches and Kubernetes events. To avoid a watch on every resource kind, we handle this by performing incremental object fetches for the objects involved in watched events.

Getting this to perform well required several optimizations at both the Go and Postgres levels. On the Go side, we use prioritized work queues, event de-duplication, and even switched to Rust for efficient JSON diffs. For Postgres, we leverage materialized views and trigger-based optimistic locking

Comment · 3 years ago
Comment · 4 years ago
Comment · 4 years ago
Comment · 4 years ago
High Availability, Scalability, Deployments, etc are NOT the goal of Kubernetes, they are features that are not exclusive to Kubernetes, nor is Kubernetes necessarily better at them then others.

The goal of Kubernetes is to improve the portability of people by introducing abstraction layers at the infrastructure layer - These abstractions can seem overly complex, but they are essential to meet the needs of all users (developers, operators, cloud providers, etc)

Before kubernetes in order for a developer to deploy an application they would need to (send email, create terraform/cloudformation, run some commands, create ticket for loadbalancer team, etc) - these steps would rarely be same between companies or even between different teams in the same company.

After kubernetes you write a Deployment spec, and knowing how to write a deployment spec is portable to the next job. Sure there are many tools that introduce opinionated workflows over the essentially verbose configuration of base Kubernetes objects, and yes your next job may not use them, but understanding the building blocks, still make it faster than if every new company / team did everything completely differently.

If you only have a single team/application with limited employee churn - then the benefits may not outweigh the increased complexity.

Comment · 4 years ago
Comment · 5 years ago
SEEKING FREELANCER(s) | Global Remote | AWS / Go / Kubernetes Engineers

We are looking for full-time, part-time and weekend warriors to help us with R&D and some project based work.

Email me @ moshe at flanksource.com

Comment · 5 years ago
Flanksource | AWS and Kubernetes SRE's | Fully Remote

Flanksource is hiring for AWS and Kubernetes Site Reliability Engineers we are remote first since inception with a strong focus on open-source - both from a technology perspective and a way of working.

Email me @ moshe at flanksource.com

Comment · 5 years ago
Comment · 6 years ago
Flanksource (https://www.flanksource.com) | Kubernetes SRE | Part-Time or Full-Time, Remote

We are looking for strong engineers to join our remote, fully distributed team to help us build a management plane to cater for Kubernetes as the OS for the Datacenter/Enterprise.

Apply here: https://www.flanksource.com/careers/site-reliability-enginee...

Comment · 6 years ago
Comment · 6 years ago
I meant OpenStack.

Kubernetes works with fully-fledged VM's as well - See Kubevirt

Comment · 6 years ago
OpenStack and Kubernetes don't serve different purposes - they just solve them differently.

Both fundamentally are about abstracting the way in which infrastructure is managed.

Comment · 6 years ago
The size of the slack channel alludes to the size of the eco-system, and the scale at which Kubernetes is solving not just technical coding problems, but non-technical communication problems

Live from the official Hacker News API

A modern reader for Hacker News · SvelteKit + Skeleton