We wrap up this series by exploring one of Traffic Director’s advanced traffic management features.

This article is part of the series that starts with Traffic Director by Example: Part 1.

So far we have used Traffic Director simply for service discovery; here we examine one of the advanced traffic management features documented in Configuring advanced traffic management.

Traffic Splitting

To illustrate Traffic Director’s traffic splitting feature, we will use it to deploy a canary release.

Canary release is a technique to reduce the risk of introducing a new software version in production by slowly rolling out the change to a small…

Using Traffic Director with Google Kubernetes Engine (GKE).

This article is part of the series that starts with Traffic Director by Example: Part 1.

Sidebar into Automatic Envoy Deployments

In the last article, we manually installed the Envoy service proxy for the client on a GCE VM instance. Below, we will manually install it on a GKE pod. At the same time, Traffic Director supports installing the Envoy service proxy automatically for both GCE VM instances and GKE pods.

At the same time, there are clear advantages to the automated installs.

When you use automated Envoy deployment with Compute Engine VMs, the Envoy version installed…

An introduction to Google’s managed service mesh offering.

Assuming that we have a theoretical understanding of service meshes, we then can ask and understand; What is Traffic Director?

Traffic Director is Google Cloud’s fully managed traffic control plane for service mesh. Traffic Director works out of the box for both VMs and containers. It uses the open source xDS APIs to communicate with the service proxies in the data plane, ensuring that you’re never locked into a proprietary interface.

— Google Cloud — Google Cloud networking in-depth: How Traffic Director provides global load balancing for open service mesh

In reading…

It is easy to think about a pod’s container as a black box that consumes the CPU that it provided, but sometimes we need to know a bit more about what is going on under the hood.

Through two example workloads, we will explore their container’s processes and their threads; and why sometimes we need to think about such things.

The Examples

The first example workload, written in Java, provides a gRPC service method of helloworld.Greeter.SayHello. We deploy it into it a Kubernetes cluster using a service and pod. …

Setting up Kubernetes probes for workloads providing gRPC services.

The working example described in this article is available for download.

You have a workload running on Kubernetes that provides gRPC services and are looking to add both a liveness and readiness probe to it. First, we need to remind ourselves what they are and more importantly what they are used for.

Many applications running for long periods of time eventually transition to broken states, and cannot recover except by being restarted. Kubernetes provides liveness probes to detect and remedy such situations.

— Kubernetes — Configure Liveness, Readiness and Startup Probes

…

A basic introduction to service meshes with Istio.

Introduction

What is a service mesh?

For all the hype, the service mesh is architecturally pretty straightforward. It’s nothing more than a bunch of userspace proxies, stuck “next” to your services (we’ll talk about what “next” means in a bit), plus a set of management processes. The proxies are referred to as the service mesh’s data plane, and the management processes as its control plane. …

Advanced deployment capabilities built using Kubernetes custom resources.

What is Argo Rollouts?

Argo Rollouts is a Kubernetes controller and set of CRDs which provide advanced deployment capabilities such as blue-green, canary, canary analysis, experimentation, and progressive delivery features to Kubernetes.

— Argo Rollouts — Argo Rollouts

As we will explore, Argo Rollouts introduces a Kubernetes API rollout resource that is a drop-in replacement for the built-in deployment resource; it is this rollout resource that enables much of the advanced deployment capabilities. By operating as a Kubernetes API resource, we get a number of things for free:

• Familiar User Experience: Deploy…

A dive into the importance of properly constructing domain names in workloads running on Kubernetes.

TL;DR: It is most efficient to use absolute domain names (ends in a dot) when accessing resources from a container of a Kubernetes pod; this is particularly important for off-cluster resources. If this is not possible, we can use the pod specification field dnsConfig to modify the behavior of the container’s resolver to make using relative domain names (does not end in a dot) to off-cluster resources equally efficient.

If this is new to you, it was for me, then let us walk through why…