Steven Cheng

All right folks, I intend to keep this one short and that’s what I will do. I mean, it’s supposed to be easy but the official documentation(1 , 2 ) makes it unnecessarily confusing. So I think maybe I can help to fill in the gap. I will be using one of our business requirements at Buffer in this [https://itnext.io/how-to-set

A mystery So, it all started on September 1st, right after our cluster upgrade from 1.11 to 1.12. Almost on the next day, we began to see alerts on kubelet reported by Datadog. On some days we would get a few (3 – 5) of them, other days we would get more than 10 in a single day. The alert monitor is based on a Datadog check – kubernetes.kubelet.check, and it’s triggered whenever the kubelet process is down in a node. We know kubelet [https://kubernetes.io/docs/concepts/overview/components/#kube

At Buffer we invest heavily on Kubernetes. Since we use AWS as our cloud provider, getting services the right permission usually means having AWS keys/secrets in Kubernetes manifest files. In this SnackChat Steven walks through the steps of using kube2iam to eliminate the exposure of AWS keys/secrets. kube2iam: https://github.com/jtblin/kube2iam

History and Background Ever since Buffer started its journey with Kubernetes (k8s) almost 1 year ago we have embarked on a mission to streamline the deployment experience. The inherent nature of microservices differs significantly from a monolith application in many ways. For each deploy, a monolith application requires merging the changes and deploying to an environment that’s well defined, tested and proven p