github.com/projectcontour/contour@v1.28.2/site/content/docs/v1.4.0/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         httpGet:
    33           path: /shutdown
    34           port: 8090
    35           scheme: HTTP
    36     livenessProbe:
    37       httpGet:
    38         path: /healthz
    39         port: 8090
    40       initialDelaySeconds: 3
    41       periodSeconds: 10  
    42  ```
    43  
    44  The Envoy container also has some configuration to implement the shutdown manager.
    45  First the `preStop` hook is configured to use the `/shutdown` endpoint which blocks the container from exiting.
    46  Finally, the pod's `terminationGracePeriodSeconds` is customized to extend the time in which Kubernetes will allow the pod to be in the `Terminating` state.
    47  The termination grace period defines an upper bound for long-lived sessions.
    48  If during shutdown, the connections aren't drained to the configured amount, the `terminationGracePeriodSeconds` will send a `SIGTERM` to the pod killing it.
    49  
    50  ![shutdown-manager overview][1]{: .center-image }
    51  
    52  ### Shutdown Manager Config Options
    53  
    54  The shutdown manager has a set of arguments that can be passed to change how it behaves:
    55  
    56  - **check-interval:** Time to poll Envoy for open connections.
    57    - Type: duration (Default 5s)
    58  - **check-delay:** Time wait before polling Envoy for open connections.
    59    - Type: duration (Default 60s)
    60  - **min-open-connections:** Min number of open connections when polling Envoy.
    61    - Type: integer (Default 0)
    62  - **serve-port:** Port to serve the http server on.
    63    - Type: integer (Default 8090)
    64  
    65    [1]: ../img/shutdownmanager.png