deserialized's comments

deserialized | 2 years ago | on: Twitter is refusing to pay its Google Cloud bill

My experience with LG&E and Time Warner in Kentucky circa 2008 was getting a shutoff notice dated the day after the payment due date with 14 days to comply. They did in-fact shut the power off at the state date.

This was a common occurrence that people referred to as 'brown billing' because the shutoff notice had a brown header instead of the green header on your regular utility bill.

deserialized | 2 years ago | on: Ask HN: Cloud to on-premise (reverse migration). Is it a thing?

Have the on prem team start deploying some assets that can utilized by the cloud team via a familiar interface like terraform. (metal as a service, kubevirt, Vsphere, nebula, whatever)

Start small, pick one service at a time (compute this quarter, postgres next quarter, secrets management the next) and use the emerging platform to strangle out paid services

Cloud team gets to stay cloudy, on prem team still gets to farm servers

deserialized | 2 years ago | on: A unified API for all the GPU clouds?

'Might' is doing a lot of work here.

I've put together multiple hybrid and multi-cloud setups between gcp, aws, azure, equinix, and others using terraform.

Iam tends to be very different between providers but there is absolutely a lowest common denominator between them especially when you focus on compute, storage, and networking as primitives with which to host your own services.

You'll get quite far by consolodating requirements into a json file containing a list of ports to open, ip addresses to allow, required number of cores, disk space, operating system version, max spot bid price, default region, maximum desired replicas etc...

Another factor is how you provision your machines. Cloud-init radically simplifies the process of creating homogenous instances across providers versus custom packer images, ansible playbooks, puppet etc... and is supported by almost every cloud and exposed via their terraform provider

deserialized | 2 years ago | on: K0smotron: Running Kubernetes-in-Kubernetes

It's real, kubevirt is a kubenetes wrapper for QEMU which allows you to use kubernetes the manage the lifcycle of virtual machines the same way you manage a pod.

Metal3 is just a wrapper for Ironic from open-stack.

The two work together to re-image bare metal machines and attach them to clusters as nodes which can then be sliced up into smaller virtaul machine nodes to sell to your end user which they can then use to run docker, kubernets or whatever else they want.

Doing this allows you to have full kernel level isolation on a per-tenant basis which is not possible just using normal containers.

It also allows you to pin workloads to specific CPU cores for latency sensitive tasks as well as pass pci express devices through to individual VMs on the host and other fun things

It's really only useful if your problem is 'i have one really big computer but I want to have lots of small computers instead' but that's pretty much every data center so shrug

ClusterAPI (CAPI) enters the equation in that CAPI requires Virtual Machines or Bare Metal machines as inputs which it then uses to create a kubenrtes cluster. Thus, kubernetes in kubernetes with kernel level isolation on a per-tenant basis

deserialized | 2 years ago | on: K0smotron: Running Kubernetes-in-Kubernetes

Definitely neat and a huge flex but I think if you want to actually do multi-tenant kubernetes in kubernetes you should be using kubevirt or metal3 to bootstrap a VM and get a real kernel in there to isolate the cluster from its neighbors.
page 1