Drain mode is a configuration for backend services and instance groups that gracefully stops new connections while allowing existing sessions to complete, enabling maintenance without service interruption. When you enable drain mode on a backend service, the Application Load Balancer stops sending new traffic to the draining backends but continues to forward traffic for existing, in-flight connections until they finish. This process ensures a smooth transition for users and allows you to perform maintenance, such as software updates or instance replacements, without dropping active client sessions.
The primary purpose of drain mode is to facilitate controlled backend maintenance. When you put a backend into draining state, the load balancer's data plane immediately stops including that backend in its pool for new connection requests. However, the control plane continues to honor the existing, long-lived connections (like WebSocket sessions or file uploads) that are already established to that backend. Traffic flow for new requests is redirected to other healthy backends in the same region or to the next closest healthy cluster in a global setup, according to the load balancer's configured policies. This redirection happens automatically, but you must evaluate the impact on the load balancing algorithm to ensure the remaining backends have sufficient capacity to handle the shifted load, which may trigger autoscaling in other clusters.
You can configure drain mode through several Google Cloud interfaces aligned with how you manage your Application Load Balancer. Using the Google Cloud CLI or Compute Engine APIs, you imperatively set a backend's draining state via commands. In Google Kubernetes Engine (GKE), you can use the declarative GKE Gateway API or Multi-cluster Ingress controllers, where the underlying load balancer configuration is managed automatically. The transition to drain mode is a deliberate lifecycle state change you initiate; the backend does not automatically return to a healthy state afterward. You must explicitly take the backend out of drain mode once maintenance is complete and it is ready to receive new traffic again.
Enabling drain mode directly affects health checks and traffic distribution. The Application Load Balancer continues to perform health checks on a draining backend, but a draining state overrides a healthy status for the purpose of new traffic distribution. This means a backend can be simultaneously healthy (passing health checks) and draining (not accepting new connections). During the drain period, the load balancing algorithm excludes the draining backend from its calculations for new requests. This exclusion can impact global capacity management, as traffic is redistributed to other backends, potentially causing cascading load effects that require evaluation of the remaining backends' capacity and may lead to autoscaling events in other zones or clusters.
Weighted backend services allow operators to gradually shift traffic from one backend to another by assigning a weight value to each backend service in a route rule. When traffic flows through the load balancer, the percentage of requests routed to each backend is proportional to its configured weightâfor example, setting weight to 95 on the current version and 5 on a new version sends only 5% of traffic to the new version initially. After validating that the new version handles traffic correctly, the weights can be adjusted incrementally until all traffic flows to the updated backend. This approach supports zero-downtime deployments, A/B testing, service migrations, and gradual rollouts of new software versions.
Health checks determine whether backend instances are capable of handling traffic, and the backend service uses these health statuses to make routing decisions. When an instance fails a health check, the load balancer stops sending new traffic to it while allowing existing connections to drain. The backend service configuration includes settings such as the balancing mode (utilization or rate), capacity scaler, and maximum utilization threshold that control how traffic is distributed among healthy backends. Custom health checks can be configured to match the specific protocol and port that the application uses, ensuring accurate health assessment of backend instances.
Connection draining is a backend service setting that allows existing client connections to complete normally when a backend instance is removed from service or during planned maintenance. When connection draining is enabled with a timeout period, the load balancer stops sending new traffic to the draining instance but allows in-flight requests to finish within the timeout window. This ensures that users experience no service interruption during backend instance replacements or software updates, and the draining period can be configured based on the expected duration of in-flight requests.
Application Load Balancers support failover configurations that automatically redirect traffic when primary backends become unavailable. For regional external Application Load Balancers, you can configure an active-passive failover where traffic fails over to a backup regional external Application Load Balancer when health checks detect an outage, using Cloud DNS failover routing policies to direct traffic. Alternatively, active-active configurations deploy multiple regional external Application Load Balancers in different regions, with Cloud DNS geolocation routing policies sending clients to the closest healthy region. Global external Application Load Balancers and classic Application Load Balancers similarly support active-passive failover to backup regional load balancers, with health checks detecting failures and Cloud DNS routing traffic to the standby.
A URL map serves as the central control plane resource that evaluates incoming request attributesâsuch as the domain name, URL path, query parameters, and HTTP headersâto determine whether to forward traffic to a backend service, send it to a backend bucket, rewrite the request, or issue an HTTP redirect response. Incoming traffic reaches a forwarding rule, which directs traffic to a target HTTP proxy or target HTTPS proxy that references the URL map. The URL map first evaluates host rules against the domain name specified in the request; once a matching host is identified, the request is delegated to the designated path matcher.
Each component within the URL map provides default fallback destinations to ensure unmatched traffic is handled without service disruption. The top-level URL map contains a default service (defaultService) or default redirect (defaultUrlRedirect) that receives traffic when none of the defined host rules match the incoming request host. Within each path matcher, a separate default service or default URL redirect catches any traffic that matches the host rule but fails to match any specific path or route rules defined within that matcher.
Google Cloud Application Load Balancers support two mutually exclusive routing modes within URL maps: simple host and path rules using path rules (pathRules), or advanced request routing using route rules (routeRules). Simple path routing evaluates requests strictly on a longest-path-matches-first basis, meaning the order of rules within the configuration does not affect routing decisions. In contrast, advanced routing evaluates route rules sequentially in ascending order of their defined integer priority (priority) values, with 0 representing the highest priority.
Advanced route rules allow granular traffic steering based on URL paths, HTTP request headers, and query parameters. Administrators can define prefix matches (prefixMatch), header matches (such as routing mobile devices via user-agent headers), and query parameter matches (queryParameterMatches) for A/B testing. When using weighted traffic splitting within a route rule action across multiple backend services, the weighted traffic splitting configuration takes precedence and overrides any session affinity configured on the destination backend services.
URL redirection actions instruct the client browser to submit a new request to a different location, whereas URL rewrite actions modify request elements before passing them to backend targets. A redirect configuration uses a default redirect action (defaultUrlRedirect) or a route-level redirect action to define parameters such as host redirection (hostRedirect), path redirection (pathRedirect), HTTPS enforcement (httpsRedirect), and query stripping (stripQuery). Redirection configurations support specific HTTP response codes:
StudyCerts
StudyCertsMOVED_PERMANENTLY_DEFAULT (HTTP 301) for permanent URL relocations.FOUND (HTTP 302) for standard temporary redirects.PERMANENT_REDIRECT (HTTP 308) to redirect permanently while retaining the original HTTP request method.TEMPORARY_REDIRECT (HTTP 307) to redirect temporarily while retaining the original HTTP request method.SEE_OTHER (HTTP 303) for redirecting following HTTP POST requests.For HTTP-to-HTTPS redirection, Google Cloud creates a partial HTTP load balancer on port 80 that shares the exact same IP address as the primary HTTPS load balancer on port 443. The HTTP frontend attaches to a target HTTP proxy and a redirect URL map with httpsRedirect: True and a redirect response code such as MOVED_PERMANENTLY_DEFAULT. When rewriting paths, Application Load Balancers support path prefix replacements rather than full path alterations, replacing the matched prefix before the request flows to the target backend service or backend bucket.
Traffic redirection and routing components must strictly align with the regional or global scope and load balancing scheme of the load balancer. Global external Application Load Balancers and cross-region internal Application Load Balancers use the global URL map API (urlMaps) and reference global backend services (backendServices), operating under the EXTERNAL_MANAGED or INTERNAL_MANAGED load balancing schemes. Conversely, regional external Application Load Balancers and regional internal Application Load Balancers require the regional URL map API (regionUrlMaps) and must reference regional backend services (regionBackendServices) residing in the exact same region.
Forwarding rules bind the load balancer frontend IP address and ports to the target proxy, enforcing protocol and network tier boundaries. For global external load balancers, forwarding rules operate globally in Premium Tier, whereas regional external load balancers operate in Standard Tier. A regional target proxy can only reference a regional URL map located in the same region, and a global target proxy can only reference a global URL map.
URL maps support automated testing to prevent configuration errors from impacting live traffic during updates. Administrators can define a tests (tests) array directly within the URL map YAML configuration, specifying test scenarios with an input host, path, and expected destination backend service or output URL. Running the command gcloud compute url-maps validate evaluates the provided YAML configuration against these test cases without applying or saving any changes to the active deployment.
Configuration testing and the validation command are supported for global external and classic Application Load Balancers, enabling pre-deployment validation for header matches, query parameter steering, URL rewrites, and redirects. Once validation succeeds, running gcloud compute url-maps import deploys the new YAML configuration to the load balancer. If a test fails during validation or import, the control plane generates an error identifying the mismatch between the expected and actual backend service, blocking erroneous rules from taking effect.
gcloud compute url-maps validate command allows pre-deployment testing of URL map YAML configurations against defined test scenarios without applying changes to live traffic.Drain mode is a deliberate lifecycle state you initiate on a backend to stop new connections while allowing existing sessions to complete, and the backend is simultaneously healthy and draining. Connection draining is a backend service setting with a configurable timeout that allows in-flight requests to finish when a backend instance is removed from service, but it does not involve the explicit lifecycle state change that drain mode uses.
When using weighted traffic splitting within a route rule action across multiple backend services, the weighted traffic splitting configuration takes precedence and overrides any session affinity configured on the destination backend services. This means session affinity will not maintain sticky sessions during a weighted split.
When a test fails during URL map validation using gcloud compute url-maps validate or during a gcloud compute url-maps import, the control plane generates an error identifying the mismatch between the expected backend service and the actual result. This blocks erroneous rules from taking effect, preventing misconfigurations from impacting live traffic.
No. Global external Application Load Balancers must use a global URL map (urlMaps) referencing global backend services (backendServices), while regional external Application Load Balancers require a regional URL map (regionUrlMaps) referencing regional backend services (regionBackendServices) in the exact same region. A regional target proxy can only reference a regional URL map, and a global target proxy can only reference a global URL map.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills