If you are migrating to serverless with Google Cloud Run from your on-premises datacenters, or Google Kubernetes Engine (GKE) clusters, you might notice that Cloud Run has a slightly different networking stack than GCE/GKE.

When accessing endpoints that require “IP whitelisting” (such as Cloud Memorystore, or something on your corporate network) from Cloud Run, you can’t easily have static IPs for your Cloud Run applications. This is because currently you can’t configure Cloud NAT or Serverless VPC Access yet.

Until we support these on Cloud Run, I want to share a workaround (with example code) that involves routing the egress traffic of a Cloud Run application through a GCE instance with a static IP address. Read More →

Many Google Cloud Run users are starting to develop containers for the first time, but often they are migrating their existing applications. Sometimes, these apps aren’t designed as microservices that fit one-process-per-container model, and require multiple server processes running together in a container.

Often you will hear “running multiple processes in a container is bad”, although nothing is wrong with doing so, as I explained in my previous article comparing init systems optimized for containers.

In this article, I’ll show a not super production-ready (hence “the lazy way”) but working solution for running multi-process containers on Cloud Run, and will provide example code. Read More →

If you are developing containers you must have heard the “single process per container” mantra. Inherently, there’s nothing wrong¹ with running multiple processes in a container, as long as your ENTRYPOINT is a proper init process. Some use cases are having processes are aiding each other (such as a sidecar proxy process) or porting legacy applications.

Recently, I had to spawn a sidecar process inside a container. Docker’s own tutorial for running multiple processes in a container is a good place to start, but not production-ready. So I outsourced my quest on Twitter to find an init replacement that can:

1. run multiple child processes, but do not restart them
2. exit as soon as a child process terminates (no point of restarting child processes, let the container crash to be restarted by docker or Kubernetes)
3. fulfill PID 1 (init process) responsibilities like zombie child reaping and signal forwarding.

In this article I explored pros and cons of some of the options like supervisord, runit, monit, tini/dumb-init, s6 (audience favorite), and tini+bash4.x combo (personal favorite). Read More →

If you’re using Google Kubernetes Engine and deploying to it from headless environments like CI/CD, you’re probably installing the gcloud command-line tool (perhaps every time) you run a build. There’s a way to authenticate to GKE clusters without gcloud CLI! Read More →

There is a kubeconfig file behind every working kubectl command. This file typically lives at $HOME/.kube/config. Having written kubectx, I’ve interacted with kubeconfigs long enough to write some tips about how to deal with them. Read More →

In my previous article on kubectl plugins, I explained how kubectl plugins work and how you can develop your own plugins. If “kubectl plugins” are new to you, read that article first.

In this article, I will explain why we have developed a kubectl plugin manager at Google, and how it addresses some of the usability, discoverability and packaging problems around kubectl plugins. Read More →

Did you know you can create and distribute your own kubectl commands? As of Kubernetes 1.12, kubectl now allows adding external executables as subcommands.

In this blog post, I’ll explain how kubectl plugin mechanism works, why plugins are useful, how you can write your own plugins, and current challenges in the plugin ecosystem. Read More →

Kubernetes keeps applications running while you’re asleep: This is mostly thanks to the “Readiness and Liveness Probes”. If you don’t know about them, read this cool article.

This article is about some health check patterns I have seen in the wild for applications that are not natively supporting Kubernetes-native probes. Read More →