Examples

    A minimal fully static bootstrap config is provided below:

    A bootstrap config that continues from the above example with dynamic endpoint discovery via an gRPC management server listening on 127.0.0.1:5678 is provided below:

    2.   address:
    3.     socket_address: { address: 127.0.0.1, port_value: 9901 }
    5. static_resources:
    6.   listeners:
    7.   - name: listener_0
    8.     address:
    9.       socket_address: { address: 127.0.0.1, port_value: 10000 }
    10.     filter_chains:
    11.     - filters:
    12.       - name: envoy.filters.network.http_connection_manager
    13.         typed_config:
    14.           "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
    15.           stat_prefix: ingress_http
    16.           codec_type: AUTO
    17.           route_config:
    18.             name: local_route
    19.             virtual_hosts:
    20.             - name: local_service
    21.               domains: ["*"]
    22.               routes:
    23.               - match: { prefix: "/" }
    24.                 route: { cluster: some_service }
    25.           http_filters:
    26.           - name: envoy.filters.http.router
    27.   clusters:
    28.   - name: some_service
    29.     connect_timeout: 0.25s
    30.     lb_policy: ROUND_ROBIN
    31.     type: EDS
    32.     eds_cluster_config:
    33.       eds_config:
    34.         resource_api_version: V3
    35.         api_config_source:
    36.           api_type: GRPC
    37.           transport_api_version: V3
    38.           grpc_services:
    39.             - envoy_grpc:
    40.                 cluster_name: xds_cluster
    41.   - name: xds_cluster
    42.     connect_timeout: 0.25s
    43.     type: STATIC
    44.     lb_policy: ROUND_ROBIN
    45.     typed_extension_protocol_options:
    46.       envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
    47.         "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
    48.         explicit_http_config:
    49.           http2_protocol_options:
    50.             connection_keepalive:
    51.               interval: 30s
    52.               timeout: 5s
    53.       # configure a TCP keep-alive to detect and reconnect to the admin
    54.       # server in the event of a TCP socket half open connection
    55.       tcp_keepalive: {}
    57.       cluster_name: xds_cluster
    58.       endpoints:
    59.       - lb_endpoints:
    60.         - endpoint:
    61.             address:
    62.               socket_address:
    63.                 address: 127.0.0.1
    64.                 port_value: 5678

    Notice above that xds_cluster is defined to point Envoy at the management server. Even in an otherwise completely dynamic configurations, some static resources need to be defined to point Envoy at its xDS management server(s).

    It’s important to set appropriate TCP Keep-Alive options in the tcp_keepalive block. This will help detect TCP half open connections to the xDS management server and re-establish a full connection.

    In the above example, the EDS management server could then return a proto encoding of a :

    1. version_info: "0"
    2. resources:
    3. - "@type": type.googleapis.com/envoy.config.endpoint.v3.ClusterLoadAssignment
    4.   cluster_name: some_service
    5.   endpoints:
    6.   - lb_endpoints:
    7.     - endpoint:
    8.         address:
    9.           socket_address:
    10.             address: 127.0.0.1
    11.             port_value: 1234

    A fully dynamic bootstrap configuration, in which all resources other than those belonging to the management server are discovered via xDS is provided below:

    The management server could respond to LDS requests with:

    1. version_info: "0"
    2. resources:
    3. - "@type": type.googleapis.com/envoy.config.listener.v3.Listener
    4.   name: listener_0
    5.   address:
    6.     socket_address:
    7.       address: 127.0.0.1
    8.       port_value: 10000
    9.   filter_chains:
    10.   - filters:
    11.     - name: envoy.filters.network.http_connection_manager
    12.       typed_config:
    13.         "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
    14.         stat_prefix: ingress_http
    15.         codec_type: AUTO
    16.         rds:
    17.           route_config_name: local_route
    18.           config_source:
    19.             resource_api_version: V3
    20.             api_config_source:
    21.               api_type: GRPC
    22.               transport_api_version: V3
    23.               grpc_services:
    24.                 - envoy_grpc:
    25.                     cluster_name: xds_cluster
    26.         http_filters:
    27.         - name: envoy.filters.http.router

    The management server could respond to RDS requests with:

    1. version_info: "0"
    2. resources:
    3. - "@type": type.googleapis.com/envoy.config.route.v3.RouteConfiguration
    4.   name: local_route
    5.   virtual_hosts:
    6.   - name: local_service
    7.     routes:
    9.       route: { cluster: some_service }

    The management server could respond to CDS requests with:

    The management server could respond to EDS requests with:

    1. version_info: "0"
    2. resources:
    3. - "@type": type.googleapis.com/envoy.config.endpoint.v3.ClusterLoadAssignment
    4.   cluster_name: some_service
    5.   endpoints:
    6.   - lb_endpoints:
    7.     - endpoint:
    8.         address:
    9.           socket_address:
    10.             address: 127.0.0.1
    11.             port_value: 1234

    This lets you split your file into two parts: one in which we have YAML content not subject to parsing according to the schema and another part that is parsed. YAML anchors in the first part may be referenced by aliases in the second part. This mechanism can simplify setups that need to re-use or dynamically generate configuration fragments.

    See the following example:

    1. !ignore dynamic_sockets:
    2. - &admin_address {address: 127.0.0.1, port_value: 9901}
    3. - &listener_address {address: 127.0.0.1, port_value: 10000}
    4. - &lb_address {address: 127.0.0.1, port_value: 1234}
    6. admin:
    7.   address:
    8.     socket_address: *admin_address
    10. static_resources:
    11.   listeners:
    12.   - name: listener_0
    13.     address:
    14.       socket_address: *listener_address
    15.     filter_chains:
    16.     - filters:
    17.       - name: envoy.filters.network.http_connection_manager
    18.         typed_config:
    19.           "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
    20.           stat_prefix: ingress_http
    21.           codec_type: AUTO
    22.           route_config:
    23.             name: local_route
    24.             virtual_hosts:
    25.             - name: local_service
    26.               domains: ["*"]
    27.               routes:
    28.               - match: {prefix: "/"}
    29.                 route: {cluster: some_service}
    30.           http_filters:
    31.           - name: envoy.filters.http.router
    32.   clusters:
    33.   - name: some_service
    34.     connect_timeout: 0.25s
    35.     type: STATIC
    36.     lb_policy: ROUND_ROBIN
    37.     load_assignment:
    38.       cluster_name: some_service
    39.       endpoints:
    40.       - lb_endpoints:
    41.         - endpoint:
    42.             address:

    Warning

    If you parse Envoy YAML configuration using external loaders, you may need to inform these loaders about the !ignore tag. Compliant YAML loaders will typically expose an interface to allow you to choose how to handle a custom tag.

    For example, this will instruct PyYAML to treat an ignored node as a simple scalar when loading: