This is the documentation for the latest development version of Contour. Both code and docs may be unstable, and these docs are not guaranteed to be up to date or correct. See the latest version.
The Envoy process, the data path component of Contour, at times needs to be re-deployed. This could be due to an upgrade, a change in configuration, or a node-failure forcing a redeployment.
When implementing this roll out, the following steps should be taken:
Contour implements a new
envoy sub-command which has a
shutdown-manager whose job is to manage a single Envoy instances lifecycle for Kubernetes.
shutdown-maanger runs as a new container alongside the Envoy container in the same pod.
It exposes two HTTP endpoints which are used for
livenessProbe as well as to handle the Kubernetes
preStop event hook.
/healthzfail, the container will be restarted.
/shutdownendpoint blocks until the connections are drained.
- name: shutdown-manager command: - /bin/contour args: - envoy - shutdown-manager image: docker.io/projectcontour/contour:master imagePullPolicy: Always lifecycle: preStop: httpGet: path: /shutdown port: 8090 scheme: HTTP livenessProbe: httpGet: path: /healthz port: 8090 initialDelaySeconds: 3 periodSeconds: 10
The Envoy container also has some configuration to implement the shutdown manager.
preStop hook is configured to use the
/shutdown endpoint which blocks the container from exiting.
Finally, the pod’s
terminationGracePeriodSeconds is customized to extend the time in which Kubernetes will allow the pod to be in the
The termination grace period defines an upper bound for long-lived sessions.
If during shutdown, the connections aren’t drained to the configured amount, the
terminationGracePeriodSeconds will send a
SIGTERM to the pod killing it.
The shutdown manager has a set of arguments that can be passed to change how it behaves: