Release freqeuncy for GKE addon?

[jetersen]

Checking the GKE releases I could not find a mention of Config Connector addon updates in recent times. Yet you recommend the update channel for Config Connector is GKE release or manually installing the operator.

Seems like on GKE Rapid channel it is stuck on 1.67.0 the same as GKE stable channel.
Recent version have added a lot of new GCP resources, would be great to see more frequent updates for Config Connector 👏

Maybe addons deserve a version picker? 😅

[diviner524]

@jetersen Thank you for the suggestion! And sorry about this lagged update in GKE release. To share a bit more context, we are aware of this issue, and we are working on some optimization to expedite the updates of Config Connector addon in GKE.

Alternatively, you can consider:

• Switch from the add-on to a manual installation, more details here.
• Use Config Controller (which is a hosted version of Config Connector.) In most cases Config Controller should be able to pick up the latest version of Config Connector from previous week. The latest Config Controller has Config Connector v1.72.1.

[jetersen]

Option two would require managed Anthos clusters pricing? 😅

[diviner524]

@jetersen It's not exactly Anthos clusters pricing. You can find more details on pricing of config controller here:

https://cloud.google.com/anthos-config-management/docs/pricing

We will update config controller documents to provide more clarity.

[jetersen]

@diviner524 if I understand the docs correctly regarding deployments example.

If we already have a "management" gke cluster we can use deployment 2 without the need for a separate config controller cluster?

But ya, in our management cluster we are already using Argo CD with gitops so the config controller would only serve as fast update channel for config connector, seems a little excessive to pay 70$ a month for a updater 😅

I might go with the manual install since I can have Argo CD manage that :)

[diviner524]

@jetersen Sorry the document might be a bit misleading since it describes more than just Config Controller pricing.

If you go with example deployment 2, then you are not using config controller. This means you don't have that "managed by GCP" GKE cluster (we call it Config Controller instance) with weekly Config Connector updates.

example deployment 2 is only about pricing of Policy Controller alone, which can be enabled in any GKE cluster and is unrelated to Config Controller. (And you may or may not need Policy Controller based on your requirement/setup.)

What you have described (a management GKE cluster with Argo CD) totally makes sense, and if this solution is already working for you then it seems you don't need another Config Controller instance. Manual installation of Config Connector might be a better option for you at the moment.

[jcanseco]

Hi @jetersen, just jumping in here.

Yes we hear our users that the upgrade frequency for the GKE add-on is too slow for a significant subset of our users who demand more frequent upgrades.

We are, right now, in the process of rolling out changes to our release pipeline aimed at reducing the time delay between a new version release and a GKE add-on user receiving that version from >1 month down to <1.5 weeks.

However, for stability and safety reasons, this improvement will be available to clusters on the RAPID channel only.

It will still take some time for these changes to take effect, but the changes are already being rolled out.

We understand that the above still won't be good enough for some users, and we also understand that migrating to Config Controller is not an option for some. If these factors hold true for you, then the best recommendation we can give is to manually install Config Connector as @diviner524 recommended -- this approach would give you full control over your upgrade frequency.

[jetersen]

We are, right now, in the process of rolling out changes to our release pipeline aimed at reducing the time delay between a new version release and a GKE add-on user receiving that version from >1 month down to <1.5 weeks.

However, for stability and safety reasons, this improvement will be available to clusters on the RAPID channel only.

If that holds true, for our management cluster we properly could stay with the addon because it would be fine to be on the rapid channel 👏

[jcanseco]

Great, thanks for confirming! In that case, please sit tight then as we roll out the changes. We'll check back on you for confirmation later.

[jcanseco]

@jetersen it seems this change has now been rolled out.

We will now be able to (and aim to) upgrade GKE clusters (on GKE minor versions found in RAPID only) to the latest KCC version 1-2 weeks after the KCC version is released.

Note: Technically though, we can only target GKE minor versions. Sometimes, GKE minor versions straddle across RAPID and REGULAR, and when that happens, we cannot upgrade that GKE minor version for safety reasons.

So for example, if you're on a GKE 1.23 cluster, you should be getting (or already have) the latest KCC version soon (1.75.0).

To check which GKE minor versions exist on RAPID, REGULAR, etc., you can use the command:

gcloud container get-server-config # Make sure to add a --region or --zone flag too that reflects your cluster's location

[jetersen]

@jcanseco upgraded to 1.23.4-gke.300 in europe-west4 yet the deployment still says cnrm.cloud.google.com/version=1.67.0

[jcanseco]

Hi @jetersen, if you just upgraded your cluster, it might take time for GKE to upgrade KCC. Can you let us know early next week if your cluster is still stuck at KCC 1.67.0?

[jetersen]

@jcanseco will do :)

[jetersen]

🥳 cnrm.cloud.google.com/version: 1.75.0 🎉

Patience is the key I guess 😅

[jcanseco]

Great, happy to hear it worked!

[jsok]

@jcanseco sorry to comment on a closed issue, but is there any intention of including Config Connector version updates in GKE release notes? It would be nice to know what minimum GKE version I need to get a corresponding Config Connector version.

[jcanseco]

@jsok No worries. Yes, we will want to eventually surface a table that shows the mapping between GKE minor versions and KCC add-on versions.

I can't say we'll get to working on such an improvement for a while due to capacity constraints, but yes that is something we wnat to do at some point.

[jsok]

@jcanseco I've been waiting a few weeks for an update to my clusters now... I'm still on GKE v1.21.x and still seeing config connector v1.69.0.

Can you possibly give any indication about what versions we should expect to see?
Motivating engineering effort in my team to upgrade our GKE version is hard because even if I managed to get all my clusters to 1.23.x it's still not clear which version of config connector and when (days, weeks?) it'll be upgraded.

Prioritising new functionality in config connector while half your customers are stuck on old versions seems counterproductive, e.g. many customers are stuck on some old version without a clear path forward to getting access to the new releases.

[jcanseco]

Hi @jsok, yes we definitely hear you.

First, please allow me to point you to this section about how KCC add-on upgrades work which we recently updated specifically to address this confusion.

Basically, if you are able to either (1) use Config Controller (best and recommended way to use KCC moving forward) OR (2) stay on a RAPID-only GKE minor version, you will get the latest KCC version every 1-2 weeks.

If you are on a GKE minor version that is NOT RAPID-only (e.g. GKE 1.21.X, or a GKE minor version that straddles across RAPID and REGULAR), your KCC won't be upgraded. What you already have is what you will always have while you stay in that GKE minor version. The one exception is when there is a widespread issue where we need to upgrade customer clusters to mitigate it.

The last paragraph will sound non-ideal for you if, for example, you prefer to use the STABLE or REGULAR channels. We are also not quite satisfied with that either since many of our users on REGULAR want faster KCC upgrades as well. That said, it works this way today for safety reasons: many customers do prefer stability over recency. This is a result of a GKE stability policy we have to abide by.

Please let me know if that did not sufficiently answer your question.