Interface ClusterConfigOrBuilder

All Superinterfaces:
com.google.protobuf.MessageLiteOrBuilder, com.google.protobuf.MessageOrBuilder
All Known Implementing Classes:
ClusterConfig, ClusterConfig.Builder

public interface ClusterConfigOrBuilder extends com.google.protobuf.MessageOrBuilder
  • Method Summary

    Modifier and Type
    Method
    Description
    boolean
    If true allow HTTP/2 and HTTP/3 connections to be reused for requests to different origins than the connection was initially created for.
    boolean
    If true allow the cluster configuration to disable the auto_sni and auto_san_validation options in the :ref:`cluster's upstream_http_protocol_options <envoy_v3_api_field_config.cluster.v3.Cluster.upstream_http_protocol_options>`
     
    The DNS cache configuration that the cluster will attach to.
    The DNS cache configuration that the cluster will attach to.
    Configuration for sub clusters, when this configuration is enabled, Envoy will create an independent sub cluster dynamically for each host:port.
    Configuration for sub clusters, when this configuration is enabled, Envoy will create an independent sub cluster dynamically for each host:port.
    boolean
    The DNS cache configuration that the cluster will attach to.
    boolean
    Configuration for sub clusters, when this configuration is enabled, Envoy will create an independent sub cluster dynamically for each host:port.

    Methods inherited from interface com.google.protobuf.MessageLiteOrBuilder

    isInitialized

    Methods inherited from interface com.google.protobuf.MessageOrBuilder

    findInitializationErrors, getAllFields, getDefaultInstanceForType, getDescriptorForType, getField, getInitializationErrorString, getOneofFieldDescriptor, getRepeatedField, getRepeatedFieldCount, getUnknownFields, hasField, hasOneof
  • Method Details

    • hasDnsCacheConfig

      boolean hasDnsCacheConfig()
       The DNS cache configuration that the cluster will attach to. Note this configuration must
       match that of associated :ref:`dynamic forward proxy HTTP filter configuration
       <envoy_v3_api_field_extensions.filters.http.dynamic_forward_proxy.v3.FilterConfig.dns_cache_config>`.
       
      .envoy.extensions.common.dynamic_forward_proxy.v3.DnsCacheConfig dns_cache_config = 1;
      Returns:
      Whether the dnsCacheConfig field is set.
    • getDnsCacheConfig

      DnsCacheConfig getDnsCacheConfig()
       The DNS cache configuration that the cluster will attach to. Note this configuration must
       match that of associated :ref:`dynamic forward proxy HTTP filter configuration
       <envoy_v3_api_field_extensions.filters.http.dynamic_forward_proxy.v3.FilterConfig.dns_cache_config>`.
       
      .envoy.extensions.common.dynamic_forward_proxy.v3.DnsCacheConfig dns_cache_config = 1;
      Returns:
      The dnsCacheConfig.
    • getDnsCacheConfigOrBuilder

      DnsCacheConfigOrBuilder getDnsCacheConfigOrBuilder()
       The DNS cache configuration that the cluster will attach to. Note this configuration must
       match that of associated :ref:`dynamic forward proxy HTTP filter configuration
       <envoy_v3_api_field_extensions.filters.http.dynamic_forward_proxy.v3.FilterConfig.dns_cache_config>`.
       
      .envoy.extensions.common.dynamic_forward_proxy.v3.DnsCacheConfig dns_cache_config = 1;
    • hasSubClustersConfig

      boolean hasSubClustersConfig()
       Configuration for sub clusters, when this configuration is enabled,
       Envoy will create an independent sub cluster dynamically for each host:port.
       Most of the configuration of a sub cluster is inherited from the current cluster,
       i.e. health_checks, dns_resolvers and etc.
       And the load_assignment will be set to the only one endpoint, host:port.
      
       Compared to the dns_cache_config, it has the following advantages:
      
       1. sub clusters will be created with the STRICT_DNS DiscoveryType,
          so that Envoy will use all of the IPs resolved from the host.
      
       2. each sub cluster is full featured cluster, with lb_policy and health check and etc enabled.
       
      .envoy.extensions.clusters.dynamic_forward_proxy.v3.SubClustersConfig sub_clusters_config = 4;
      Returns:
      Whether the subClustersConfig field is set.
    • getSubClustersConfig

      SubClustersConfig getSubClustersConfig()
       Configuration for sub clusters, when this configuration is enabled,
       Envoy will create an independent sub cluster dynamically for each host:port.
       Most of the configuration of a sub cluster is inherited from the current cluster,
       i.e. health_checks, dns_resolvers and etc.
       And the load_assignment will be set to the only one endpoint, host:port.
      
       Compared to the dns_cache_config, it has the following advantages:
      
       1. sub clusters will be created with the STRICT_DNS DiscoveryType,
          so that Envoy will use all of the IPs resolved from the host.
      
       2. each sub cluster is full featured cluster, with lb_policy and health check and etc enabled.
       
      .envoy.extensions.clusters.dynamic_forward_proxy.v3.SubClustersConfig sub_clusters_config = 4;
      Returns:
      The subClustersConfig.
    • getSubClustersConfigOrBuilder

      SubClustersConfigOrBuilder getSubClustersConfigOrBuilder()
       Configuration for sub clusters, when this configuration is enabled,
       Envoy will create an independent sub cluster dynamically for each host:port.
       Most of the configuration of a sub cluster is inherited from the current cluster,
       i.e. health_checks, dns_resolvers and etc.
       And the load_assignment will be set to the only one endpoint, host:port.
      
       Compared to the dns_cache_config, it has the following advantages:
      
       1. sub clusters will be created with the STRICT_DNS DiscoveryType,
          so that Envoy will use all of the IPs resolved from the host.
      
       2. each sub cluster is full featured cluster, with lb_policy and health check and etc enabled.
       
      .envoy.extensions.clusters.dynamic_forward_proxy.v3.SubClustersConfig sub_clusters_config = 4;
    • getAllowInsecureClusterOptions

      boolean getAllowInsecureClusterOptions()
       If true allow the cluster configuration to disable the auto_sni and auto_san_validation options
       in the :ref:`cluster's upstream_http_protocol_options
       <envoy_v3_api_field_config.cluster.v3.Cluster.upstream_http_protocol_options>`
       
      bool allow_insecure_cluster_options = 2;
      Returns:
      The allowInsecureClusterOptions.
    • getAllowCoalescedConnections

      boolean getAllowCoalescedConnections()
       If true allow HTTP/2 and HTTP/3 connections to be reused for requests to different
       origins than the connection was initially created for. This will only happen when the
       resolved address for the new connection matches the peer address of the connection and
       the TLS certificate is also valid for the new hostname. For example, if a connection
       has previously been established to foo.example.com at IP 1.2.3.4 with a certificate
       that is valid for ``*.example.com``, then this connection could be used for requests to
       bar.example.com if that also resolved to 1.2.3.4.
      
       .. note::
         By design, this feature will maximize reuse of connections. This means that instead
         opening a new connection when an existing connection reaches the maximum number of
         concurrent streams, requests will instead be sent to the existing connection.
      
       .. note::
         The coalesced connections might be to upstreams that would not be otherwise
         selected by Envoy. See the section `Connection Reuse in RFC 7540
         <https://datatracker.ietf.org/doc/html/rfc7540#section-9.1.1>`_
       
      bool allow_coalesced_connections = 3;
      Returns:
      The allowCoalescedConnections.
    • getClusterImplementationSpecifierCase

      ClusterConfig.ClusterImplementationSpecifierCase getClusterImplementationSpecifierCase()