Steven stevenc81

Tainting and Labeling Kubernetes Nodes to Run Special Workload - A quick guide that is finally NOT confusing

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 documentations(1, 2) make it unnecessary confusing. So I think maybe I can help filling in the gap.

I will be using one of our business requirements at Buffer in this project, as the example for this blog post.

Quick recap

So, we need a few nodes that are dedicated to running cronjobs, and nothing else. At the same time we want to make sure the cornjobs are scheduled to these nodes, and nowhere else. This means we need 2 things

How to Set Kubernetes Resource Requests and Limits - A Saga to Improve Cluster Stability and Efficiency

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 plays an important role in Kubernetes scheduling. Not having it running properly in a node would directly remove that node from a functional cluster. Having more nodes with problematic kubelet then we get a cluster degradation. Now, Imagine waking up to

Quick Kubernetes Helm Learnings on Chart Backward Compatibility

At Buffer we utilize kube2iam for AWS permissions. It's deployed, upgraded and managed with the stable Helm Chart repository.

It has been working great, until last week due to my oversight. The situation was resolved in a matter of 30 minutes and no users were affected. Nonetheless, I'd love to share my learnings with the community.

To upgrader kube2iam I have been using this command

helm upgrade kube2iam --install stable/kube2iam --namespace default -f ./values.yaml

Kubernetes Master Nodes Backup for Kops on AWS - A step-by-step Guide

For those who have been using kops for a while should know the upgrade from 1.11 to 1.12 poses a greater risk, as it will upgrade etcd2 to etcd3.

Since this upgrade is disruptive to the control plane (master nodes), although brief, it's still something we take very seriously because nearly all the Buffer production services are running on this single cluster. We felt a more thorough backup process than the currently implemented Heptio Velero was needed.

To my surprises, my Google searches didn't yield any useful result on how to carry out the backup steps. To be fair, there are a few articles that are specifically for backing up master nodes created by kubeedm but nothing too concrete for `kop

Application Observability in Kubernetes with Datadog APM and Logging - A simple and actionable example

Last year I shared an example on how to realize application tracing in Kuberntes with Istio and Jaeger. After that, the industry has made some substantial headway on this front and we are seeing more vendor support as a result. At Buffer, since we primarily use Datadog for Kubernetes and application monitoring, it's only fitting to complete the circle with Datadog APM and Logging. I had a chance to create a small example for the team and would very much love to share with the community.

Okay, without further ado, let's dive in!

Installing Datadog agent

First thing first, in order to collect metrics and logs from Kubernetes an Datadog agent has to be installed in the cluster. The Datadog team ma

	apiVersion: batch/v1beta1
	kind: CronJob
	metadata:
	namespace: dev
	name: steven-cron
	labels:
	app: steven-cron
	spec:
	schedule: "* * * * *"
	jobTemplate:

	apiVersion: kops.k8s.io/v1alpha2
	kind: InstanceGroup
	metadata:
	labels:
	kops.k8s.io/cluster: steven.k8s.com
	name: frequent-cronjob-nodes
	spec:
	image: kope.io/k8s-1.13-debian-stretch
	machineType: m4.xlarge
	maxSize: 2

	resources:
	limits:
	cpu: 1000m
	memory: 512Mi
	requests:
	cpu: 100m
	memory: 50Mi

	extraArgs:
	base-role-arn: "arn:aws:iam::<YOUR AWS ACCOUNT ID>:role/"
	host:
	interface: cni0
	iptables: true
	rbac:
	create: true
	resources:
	limits:
	cpu: 100m

	extraArgs:
	base-role-arn: "arn:aws:iam::<YOUR AWS ACCOUNT ID>:role/"
	host:
	interface: cni0
	iptables: true
	rbac:
	create: true
	resources:
	limits:
	cpu: 100m