code serving text serving code

Health probes are essential to running a highly available service, yet they are surprisingly tricky to implement without inadvertently making your uptime worse . Even popular frameworks like Spring Boot (until recently 1 ) used unfortunate defaults that may accidentally encourage a hurried developer to fall into some surprising traps that reduce their services' uptime. Over time, my team has come up with a set of rules to avoid these traps . I'll lay them out first succinctly, and then explain them in detail along with the model we use that embodies them. Don't overload health endpoints – favor more over reuse Keep logic out of monitors – put in endpoints Be very conservative when determining if un healthy Run health checks in background – not on demand If your in a hurry , you can skip straight to the summary . This post may use Kubernetes terms like "container" and "probe", but these ideas can be applied to services running on any ...

Kubernetes documentation is thorough, and you should read it when you have the time. Until then, this is a condensed overview aimed at developers using a Kubernetes platform that should get you comfortable enough, quickly enough, to have enough of a foothold to experiment and understand the official documentation where more detail is needed. I'm not an expert, so YMMV. I assume you are familiar with Docker, linux containers, and with the basic premise of Kubernetes: you've got images and want to run them reliably, with minimal manual intervention. As a tradeoff, you must learn and invest in Kubernetes' abstractions. Overview Kubernetes (or "k8s"–which is to Kubernetes as a11y is to accessibility) runs on top of a cluster of nodes , where a node is machine as in physical or virtual machines, and a cluster is a datacenter or part of one. Nodes are the resources k8s uses to run its Control Plane and the workloads it schedules . You'll interact with ...