Is Google Cloud Config Connector the solution?

Today we are going to learn and understand how Config Connector is working, and if it is a tool that, for example, can replace Terraform. But let's start from the beginning.

Config Connector is a Kubernetes add-on that allows you to manage and create objects in Google Cloud using Kubernetes components. For example, when you want to create a pub/sub message queue in your Google Cloud account, instead of using Terraform code or Google Cloud Deployment, you create an object like the one that you can see here.

  apiVersion: pubsub.cnrm.cloud.google.com/v1beta1
  kind: PubSubTopic
  metadata:
    labels:
      environment:production
    name: test

Then you only need to execute kubectl apply and in a few seconds your pub/sub message queue will be created and working.

This sounds super cool. If you want to deploy all the infrastructure in your company, you only need to have a helm chart to deploy everything. If you want to see what infrastructure you deploy, you only need to execute a Kubectl command, but let’s see if everything is as beautiful as it seems.

We are going to start with a chicken and egg issue. If we want to deploy all our infrastructure with Config Connector, we currently need to have infrastructure already deployed, because we need a Kubernetes Cluster deployed and working and, in our case, a GKE Kubernetes Cluster. So we need to decide how to deploy this cluster, for example with Terraform. So we end up with a problem:

• First, we create the GCP project, service account, IAM and GCS bucket to deploy Terraform.
• We use Terraform to deploy our Kubernetes cluster.
• Setup Components to be able to use Config Connector like a config connector object in our Kubernetes cluster.
• Now we use a helm chart to deploy our infrastructure.

Really, sounds complex.

There is another known problem and it is related to the way that Config Connector updates parameters. Normally, when you are working with whatever other Infrastructure as a Code tool, like Terraform, when you modify some parameter in a currently deployed object, you only need to apply new code to see what changes are there, but Config Connector does not always work this way.

In Config Connector we have something called immutable fields and they are really immutable fields. That’s mean that if you want to modify any of those fields you have 2 options:

• Delete the object in case that it is not used and re-create the object. And this is an issue, because if the object is blocked, it can’t be removed in Kubernetes, because point to an object Google Cloud and will end in a state called “DeletedFailed”.
• The second way is to do that in a funny way. Because as soon as you change an immutable fields, Kubernetes object will be blocked and will end in a state called “UpdatedFailed”.

So we have a cool technology, but with some problems that make it not valid for production. We have a technology that maybe needs to be revised, but we need to understand that trying to fight against Terraform or Ansible is sometimes hard.

Original article by Pablo Inigo Sanchez on mkdev.me