248 karma · joined July 27, 2015
Also, I've found renumbering passives to keep the same values in contiguous groups to simplify hand prototyping. You end up having dozens of 0.1uF for example and it's nice to knock them all out instead of switching between different components
I'm probably missing the point - but that first 3 months of training is where you make the fastest growth and can double the weight you lift (from untrained to novice). Sure - you aren't going to compete at a world level after 3 months, but it doesn't seem right to describe it as 'nothing'.
This technology is probably more applicable to situations where you have a source of low quality heat and you want to extract a tiny bit of power.
Seems like a debugger for reactive systems should be let you attach to a running graph and extract/visualise traces.
Each node you are going to include in your cluster needs to have docker and kubelet running. You will need to start kubelet with your init system (systemd, etc).
Then all you need is to bootstrap a control plane. The control plane has 3 components. The API server needs to communicate to etcd, everything else just talks to the API server. The API server is stateless and can (should) have multiple instances running. The other two parts are the Controller and Scheduler. Also stateless. The tool Bootkube[1] can generate all the configuration and perform the bootstrapping for you.
To answer your dot points, all but 4 are easy enough with using the kubernetes docs and some systems/networking knowledge. Point 4, assuming you mean starting new machines based on load, will require you to look at which systems are supported by the autoscaling system and potentially add an integration for your environment. There is the horizontal pod autoscaler that will run more of your service when needed and the cluster autoscaler[2] which will start more machines when it can't run as more instances of your service on the current number of machines.
Edit: There are also tools like Patroni, Stolon, and postgres operators that will assist with your DB (postgres in this case) management. Scaling, HA, backups, etc.
1 - https://github.com/kubernetes-incubator/bootkube
2 - https://github.com/kubernetes/autoscaler/blob/master/cluster...
I wonder if releasing the posts in the period leading up to the release would be better, or if that would just lead to artificial delays on the actual release.