mirror of https://github.com/linkerd/linkerd2.git
1071ec2e77
### What This change adds the `config.linkerd.io/proxy-await` annotation which when set will delay application container start until the proxy is ready. This allows users to force application containers to wait for the proxy container to be ready without modifying the application's Docker image. This is different from the current use-case of [linkerd-await](https://github.com/olix0r/linkerd-await) which does require modifying the image. --- To support this, Linkerd is using the fact that containers are started in the order that they appear in `spec.containers`. If `linkerd-proxy` is the first container, then it will be started first. Kubernetes will start each container without waiting on the result of the previous container. However, if a container has a hook that is executed immediately after container creation, then Kubernetes will wait on the result of that hook before creating the next container. Using a `PostStart` hook in the `linkerd-proxy` container, the `linkerd-await` binary can be run and force Kubernetes to pause container creation until the proxy is ready. Once `linkerd-await` completes, the container hook completes and the application container is created. Adding the `config.linkerd.io/await-proxy` annotation to a pod's metadata results in the `linkerd-proxy` container being the first container, as well as having the container hook: ```yaml postStart: exec: command: - /usr/lib/linkerd/linkerd-await ``` --- ### Update after draft There has been some additional discussion both off GitHub as well as on this PR (specifically with @electrical). First, we decided that this feature should be enabled by default. The reason for this is more often than not, this feature will prevent start-up ordering issues from occurring without having any negative effects on the application. Additionally, this will be a part of edges up until the 2.11 (the next stable release) and having it enabled by default will allow us to check that it does not conflict often with applications. Once we are closer to 2.11, we'll be able to determine if this should be disabled by default because it causes more issues than it prevents. Second, this feature will remain configurable; if disabled, then upon injection the proxy container will not be made the first container in the pod manifest. This is important for the reasons discussed with @electrical about tools that make assumptions about app containers being the first container. For example, Rancher defaults to showing overview pages for the `0` index container, and if the proxy container was always `0` then this would defeat the purpose of the overview page. ### Testing To test this I used the `sleep.sh` script and changed `Dockerfile-proxy` to use it as it's `ENTRYPOINT`. This forces the container to sleep for 20 seconds before starting the proxy. --- `sleep.sh`: ```bash #!/bin/bash echo "sleeping..." sleep 20 /usr/bin/linkerd2-proxy-run ``` `Dockerfile-proxy`: ```textile ... COPY sleep.sh /sleep.sh RUN ["chmod", "+x", "/sleep.sh"] ENTRYPOINT ["/sleep.sh"] ``` --- ```bash # Build and install with the above changes $ bin/docker-build ... $ bin/image-load --k3d ... $ bin/linkerd install |kubectl apply -f - ``` Annotate the `emoji` deployment so that it's the only workload that should wait for it's proxy to be ready and inject it: ```bash cat emojivoto.yaml |bin/linkerd inject - |kubectl apply -f - ``` You can then see that the `emoji` deployment is not starting its application container until the proxy is ready: ```bash $ kubectl get -n emojivoto pods NAME READY STATUS RESTARTS AGE voting-ff4c54b8d-sjlnz 1/2 Running 0 9s emoji-f985459b4-7mkzt 0/2 PodInitializing 0 9s web-5f86686c4d-djzrz 1/2 Running 0 9s vote-bot-6d7677bb68-mv452 1/2 Running 0 9s ``` Signed-off-by: Kevin Leimkuhler <kevin@kleimkuhler.com> |
||
|---|---|---|
| .. | ||
| templates | ||
| Chart.yaml | ||
| requirements.lock | ||
| requirements.yaml | ||