If you need to inspect kubectl network traffic, you can add verbose logging options (-v=8 or higher) to any kubectl command and you can see the URLs, request and response body/headers (except authorization). These headers usually are not complete, because more headers are added after the request is logged. To have a complete view, you need to intercept traffic using a local proxy like mitmproxy. Read More →

Google Cloud Run now has support for unary gRPC requests (i.e. non-streaming methods). This guide explains how to authenticate to a private gRPC service running on Cloud Run. Read More →

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 →