github.com/projectcontour/contour@v1.28.2/site/content/docs/v1.8.2/redeploy-envoy.md (about)

     1  # Redeploying Envoy
     2  
     3  The Envoy process, the data path component of Contour, at times needs to be re-deployed.
     4  This could be due to an upgrade, a change in configuration, or a node-failure forcing a redeployment.
     5  
     6  When implementing this roll out, the following steps should be taken: 
     7  
     8  1. Stop Envoy from accepting new connections 
     9  2. Start draining existing connections in Envoy by sending a `POST` request to `/healthcheck/fail` endpoint
    10  3. Wait for connections to drain before allowing Kubernetes to `SIGTERM` the pod
    11  
    12  ## Overview
    13  
    14  Contour implements a new `envoy` sub-command which has a `shutdown-manager` whose job is to manage a single Envoy instances lifecycle for Kubernetes.
    15  The `shutdown-manager` runs as a new container alongside the Envoy container in the same pod.
    16  It exposes two HTTP endpoints which are used for `livenessProbe` as well as to handle the Kubernetes `preStop` event hook.
    17  
    18  - **livenessProbe**: This is used to validate the shutdown manager is still running properly. If requests to `/healthz` fail, the container will be restarted.
    19  - **preStop**: This is used to keep the container running while waiting for Envoy to drain connections. The `/shutdown` endpoint blocks until the connections are drained.
    20  
    21  ```yaml
    22   - name: shutdown-manager
    23     command:
    24     - /bin/contour
    25     args:
    26       - envoy
    27       - shutdown-manager
    28     image: docker.io/projectcontour/contour:main
    29     imagePullPolicy: Always
    30     lifecycle:
    31       preStop:
    32         exec:
    33           command:
    34             - /bin/contour
    35             - envoy
    36             - shutdown
    37     livenessProbe:
    38       httpGet:
    39         path: /healthz
    40         port: 8090
    41       initialDelaySeconds: 3
    42       periodSeconds: 10  
    43  ```
    44  
    45  The Envoy container also has some configuration to implement the shutdown manager.
    46  First the `preStop` hook is configured to use the `/shutdown` endpoint which blocks the Envoy container from exiting.
    47  Finally, the pod's `terminationGracePeriodSeconds` is customized to extend the time in which Kubernetes will allow the pod to be in the `Terminating` state.
    48  The termination grace period defines an upper bound for long-lived sessions.
    49  If during shutdown, the connections aren't drained to the configured amount, the `terminationGracePeriodSeconds` will send a `SIGTERM` to the pod killing it.
    50  
    51  ![shutdown-manager overview][1]{: .center-image }
    52  
    53  ### Shutdown Manager Config Options
    54  
    55  The shutdown manager has a set of arguments that can be passed to change how it behaves:
    56  
    57  - **check-interval:** Time to poll Envoy for open connections.
    58    - Type: duration (Default 5s)
    59  - **check-delay:** Time wait before polling Envoy for open connections.
    60    - Type: duration (Default 60s)
    61  - **min-open-connections:** Min number of open connections when polling Envoy.
    62    - Type: integer (Default 0)
    63  - **serve-port:** Port to serve the http server on.
    64    - Type: integer (Default 8090)
    65  
    66    [1]: ../img/shutdownmanager.png