Kubernetes Configuration– Scaling Up

by Ali Axelrod Advantages of Cloud, Command Line Interface, Deletion of bucket, Exams of Google Cloud, Google Cloud Certification Exams

The project also contains several generic Kubernetes YAML configurations in the k8s directory. These would be the same for any Kubernetes platform and define how to deploy the application:

namespace.yaml

A namespace is a way to group resources in Kubernetes much like a project does in Google Cloud. This configuration defines a facts namespace.

deployment.yaml

In Kubernetes, the smallest deployable unit is a pod. This is made up of one or more containers. In this configuration, the pod contains two containers: the fact service instance and the Cloud SQL Proxy. A deployment is a way to deploy and scale an identical set of pods. It contains a template section with the actual pod spec.

service.yaml

A Kubernetes service is a way to provide a stable network endpoint for the pod with an IP address and port. If there are multiple instances of pods, it also distributes traffic between them and stops routing traffic if a readiness or liveness probe fails.

ingress.yaml

An ingress is a way to expose a Kubernetes services to the internet. Here you are using it to expose the fact service.

serviceaccount.yaml

A Kubernetes service account is a way to grant a pod access to other services. It is a way to provide a stable identity for the pod.

Implementation

With the preparation done, you are now ready to deploy the application to GKE Autopilot. First, you will deploy the application to connect to Cloud SQL, as you did with the Cloud Run implementation. Then you will configure Cloud Spanner and use that as an alternative.

Create a GKE Autopilot Cluster

Unlike Cloud Run, GKE Autopilot is a Kubernetes cluster, albeit a highly managed one, not a serverless service. You need to provision a cluster to run your application on.

If you have the kubectx command installed, you can enter it to list all the contexts in the kubeconfig file. This is all the clusters available to you. You should see the context for the cluster you just created and possibly any other Kubernetes clusters you have, for example, a local Minikube.

As GKE Autopilot is a fully managed Kubernetes cluster, the nodes are managed by Google, and you do not have access to them. For most people, this is a good thing, as managing a Kubernetes cluster yourself can get complicated very quickly.

Service Account Binding with Workload Identity

Kubernetes, like Google Cloud, has the concept of service accounts. These are a way to grant permissions to pods running in the cluster. You will create a Kubernetes service account and bind it to the Google service account you created earlier using Workload Identity. This will allow the pods to access the Cloud SQL instance.

This is not particularly straightforward, but when working, it provides a nice way of integrating workloads on Kubernetes with Google Cloud services without an explicit dependency on Google Cloud.

Executing this command isn’t directly creating the service account. Instead, it’s sending a declarative configuration to the Kubernetes API server. This configuration describes the desired state for a service account, namely how you intend it to exist within your Kubernetes environment.

The kubectl apply command allows you to assert control over the system configuration. When invoked, Kubernetes compares your input (the desired state) with the current state of the system, making the necessary changes to align the two.

To put it simply, by running kubectl apply -f k8s/serviceaccount.yaml, you’re instructing Kubernetes, “This is how I want the service account setup to look. Please make it so.”