GKE Autopilot: Clarification about cluster configuration outages

Lets say I have a configuration cluster that goes down:
1. Before switching config cluster to another cluster, I would first need to somehow sync the Gateway, HealthCheckPolicy, HTTPRoute, etc.. to the secondary cluster beforehand since configuration isn't applied to new cluster automatically? I also ask because

"The Ingress controller will reconcile whatever resources exist in the config cluster. When migrating the config cluster from the current one to the next one, MultiClusterIngress and MultiClusterService resources must be identical. If the resources are not identical, the Compute Engine Load Balancers may be updated or destroyed after the config cluster update."
It doesn't really specify conditions for update or destruction if not identical so I would like to avoid the situation.

2. When the configuration cluster goes down, but not switched yet, the traffic should still flow as defined in HTTPRoute and Gateway HealthCheckPolicy (and any other)?

3. If I wanted to change the weight of traffic, healthpolicy, or other configuration on the cluster that is down I couldn't?

0 3 131
3 REPLIES 3

Hi g3289ds,

Welcome to Google Cloud Community,

To answer your [1] question, yes it's necessary to sync your configuration/resources before switching. 

It's crucial to sync (HealthCheckPolicy, Gateways, HTTPRoute, etc.) to the secondary cluster beforehand, as this is to prevent any potential issues with the Load Balancers during the transitions and also maintain its consistency.

As per MCI documentation it will reconcile resources defined in the config cluster for the Ingress controller in the secondary cluster.

Take note that if the resources are not identical between clusters, the outcome would be that the reconciliation process might lead to unexpected updates or even worse, the deletion of the Compute Engine Load Balancers.

[2] Yes, Traffic flow during downtime should still flow as defined in the existing configurations (Gateway, HTTPRoute, HealthCheckPolicy, etc.) ensuring that service will be uninterrupted based on the existing settings.

[3] Unfortunately, modifying configuration during downtime is not possible as the cluster is currently down. Changes in health policies, weights, or other configurations changes in the config cluster will not be possible. As having a down cluster disrupts real-time communication channels.

But you may try to venture on some alternatives such as having a planned fail over, or an alternative management interface and lastly you can wait for cluster recovery.

If I had clusters in different regions with different names would I need to create separate configuration directories for those in the config repo and limit them to specific clusters either by NamespaceSelector or ClusterSelector?

@AlfredBAdditionally, when would the resources ever be identical if different clusters have different names and different regions?

Top Labels in this Space