Learn Tailscale - Kubernetes, Docker & Containers

#Introduction

In episode 15 you learned to expose services. But what if your apps run as containers — on Docker or Kubernetes? Running Tailscale in a container has its own challenges: no systemd, state must persist, and containers are ephemeral.

Episode 16 covers three patterns: the official tailscale/tailscale image as a sidecar in Docker, running tailscale up in immutable containers, and the Tailscale Kubernetes Operator for Ingress, Egress, Service load balancers, and workload identity.

#Tailscale in Containers

#Official Image and Sidecar Mode

The tailscale/tailscale image is purpose-built for containers. The most common pattern is a sidecar: one Tailscale container sitting next to an application container, sharing network and volumes.

docker run -d --name ts-sidecar \
  --network host \
  -e TS_AUTHKEY=tskey-auth-xxxx \
  -e TS_HOSTNAME=container-web \
  -e TS_EXTRA_ARGS=--advertise-tags=tag:server \
  -v ts-state:/var/lib/tailscale \
  tailscale/tailscale

The docker run command above runs Tailscale as a daemon in a container, uses an auth key for provisioning, and stores state in the ts-state volume so identity survives container restarts.

#tailscale up in Immutable Containers

Containers are immutable — no systemd and an ephemeral filesystem. The correct pattern:

• Use the TS_AUTHKEY env var for browser-free authentication.
• Store state in a persistent volume so node keys don't change on every restart.
• Run a single process in the container: tailscaled.
• If needed, use an image with an init that manages both tailscaled and tailscale.

docker volume create ts-state
docker run -d --name ts -v ts-state:/var/lib/tailscale tailscale/tailscale

With the ts-state volume, every container restart keeps the same node identity — without it, a new node appears on every restart.

#Practical Rules

• Always mount a volume for /var/lib/tailscale.
• Use ephemeral auth keys for test environments.
• Set TS_HOSTNAME and tags for clear identity.
• Don't use --network host unless necessary; use port mapping instead.

#Kubernetes Operator

#What Is the Tailscale Kubernetes Operator

The Tailscale Kubernetes Operator is a component that integrates Kubernetes with a tailnet natively. With the operator, you don't write manual sidecars — just define resources and the operator handles provisioning, auth, and networking.

Installation via Helm:

helm repo add tailscale https://tailscale.github.io/k8s-operator
helm install operator tailscale/tailscale-operator \
  --namespace tailscale --create-namespace

#Ingress and Egress Proxies

The operator provides two main modes:

• Ingress proxy: a Kubernetes Service is exposed to the tailnet via a MagicDNS hostname.
• Egress proxy: traffic from the tailnet is forwarded to a Service in the cluster.

apiVersion: tailscale.com/v1alpha1
kind: ProxyGroup
metadata:
  name: ingresses
spec:
  type: ingress
  proxyPort: 80

The ProxyGroup resource with type: ingress above makes a cluster Service reachable from the tailnet. This declarative approach is what makes the operator so convenient for large teams.

#Service Load Balancers and Workload Identity

With the operator, you can also create LoadBalancer Services backed by Tailscale — traffic to the Service is automatically available on the tailnet. For workloads that need identity, the operator supports workload identity: pods are recognized as Tailscale nodes with specific tags, so ACLs can govern access between workloads granularly.

#Container Best Practices

#Checklist

• Auth keys or OAuth for interaction-free provisioning.
• Persistent volume for node state.
• Consistent hostnames and tags.
• Auto-update for images and the operator.
• ACLs restricting what workloads can access.

Docker     -> tailscale/tailscale sidecar + state volume
Kubernetes -> Operator (Ingress/Egress, LoadBalancer, identity)

#Summary

Containers change how you deploy, and Tailscale follows: the official image for simple sidecar patterns, and the Kubernetes Operator for native, declarative integration.

#Closing

Episode 16 brought Tailscale into the container world: you understand the Docker sidecar pattern with persistent state, how to run tailscale up in immutable containers, and the power of the Kubernetes Operator for Ingress, Egress, and load balancers.

Key takeaways:

• The tailscale/tailscale image for the sidecar pattern.
• An auth key is required for provisioning in containers.
• A persistent volume keeps node identity across restarts.
• The Kubernetes Operator handles provisioning declaratively.
• Ingress proxy for out to the tailnet, Egress for into the cluster.
• Workload identity gives pods an identity for ACLs.

In the next episode, episode 17, we'll cover API, OAuth, and automation — managing devices, keys, and ACLs via the REST API, OAuth apps for device provisioning, plus the Terraform Provider and automated provisioning workflows with scripts and Ansible.