Uses MutatingAdmissionWebhook in Kubernetes to inject sidecars into new deployments at resource creation time.
Forked from tumblr/k8s-sidecar-injector.
It is a small service that runs in each Kubernetes cluster, and listens to the Kubernetes API via webhooks. For each pod creation, the injector gets a (mutating admission) webhook, asking whether or not to allow the pod launch, and if allowed, what changes we would like to make to it. For pods that have special annotations on them (i.e. injector.tumblr.com/request=logger:v1
), we rewrite the pod configuration to include the containers, volumes, volume mounts, host aliases, init-containers and environment variables defined in the sidecar logger:v1
's configuration.
There is a kustomize base provided in /manifests/base.
Refer to the example to see what a sample deployment may look like for you.
See /docs/sidecar-configuration-format.md to get started with setting up your sidecar injector's configurations.
- A pod is created. It has annotation
injector.tumblr.com/request=logger:v1
- K8s webhooks out to this service, asking whether to allow this pod creation, and how to mutate it
- If the pod is annotated with
injector.tumblr.com/status=injected
: Do nothing! Return "allowed" to pod creation - Pull the "logger:v1" sidecar config, patch the resource, and return it to k8s
- Pod will launch in k8s with the modified configuration
A crappy ASCII diagram will help :)
+-----------------+
+------------------------------+ | |
| | | Sidecar |
| MutatingAdmissionWebhook | | configuration |
| | | files on disk |
+------------+-----------------+ | |
| +------+----------+
discover injector | |
endpoints | | load from disk
| |
+-------v--------+ pod launch +--------------------v-----+
| +------------------------> |
| Kubernetes | | k8s-sidecar-injector |
| API Server <------------------------+ |
| | mutated pod spec +--------------------------+
+----------------+
The image is built and published on Quay. See the example for how to run this in Kubernetes.
$ ./bin/k8s-sidecar-injector --tls-port=9000 --config-directory=conf/ --tls-cert-file="${TLS_CERT_FILE}" --tls-key-file="${TLS_KEY_FILE}"
NOTE: this is not a supported method of running in production. You are highly encouraged to deploy this to Kubernetes in The Supported Way.
See hacking.md
Run make release VERSION=<version>
to create a new release.
This will create a commit which updates the image in the deployment manifests
and another which reverts the image tag to 'latest'. Tag the former commit
with the release version.
This ensures that the release tag points to manifests that include the
corresponding image version but the master
branch gives you the latest
tag.
Copyright 2019, Tumblr, Inc.
Copyright (c) 2020-2023 Utility Warehouse Ltd.