Baslamadan once; yakin zamanda klavye ve bilgisayarimi degistirdim. Malesef Turkce karakterleri yazamiyorum.

Kucuk bir uygulamamiz oldugunu varsayalim.Onde bir frontend arkada bir backend, bu backend de iliskisel veritabani ve redise baglandigini dusunelim. Uygulamalarimiz kubernetes icersinde, stateful yapilarimiz ise GCP managed servis olsun. Tabi load balancer, logging ve monitoring de unutmamak lazim.

Google Cloud kaynaklarini yonetmek icin terraform, Kubernetes icin flux/argocd ve ya herhangi bir baska tool, uygulamlar icin baska baska derken maintance maliyeti ve karmasikligi arttikca artiyor. Bu maliyetleri disurmek, GCP yi kubernetes native cozumler ile yonetmek icin Google'un guzel bir cozumunu anlatacagim size: Google Cloud Config Connector.

Config Connector'e Genel Bakis

Daha once kubernetes addons(eklentilerini) duymayan varsa baslamadan once soyle bir googleyalip fikir sahibi olmasini tavsiye ederim.

Ozunde Config Connector, kubernetes eklentisidir. Kubernetes native cozumlerini kullanarak GCP kaynaklarini yonetmemizi saglar.

Daha baska bir ifade ile Config Connector, GCP icin ozellestirilmis kubernetes CRD koleksiyonudur. Tipki bir prometheus ve grafana operatori yukler gibi yukleyip sonrasinda yamllar kullanarak hem gitops mantigi ile tek elden GCP kaynaklarimizi yonetmemizi sagliyor.

Cloud Config Connector Yuklenmesi

Terminalinizde biraz sonraki komutlari calistirmadan once su degiskenleri tanimlamalisiniz.

export PROJECT_ID= < burayi doldurun >
Henuz bir servis accountunuz yoksa sikinti degil IAM bolumunu okuyup bir tane olusturabilirsiniz.
export SERVICE_ACCOUNT_NAME= < burayi doldurun >
export CLUSTER_NAME= < burayi doldurun >

Enable Addon

gcloud container clusters update ${CLUSTER_NAME} \
    --update-addons ConfigConnector=ENABLED

IAM

Henuz olusturmadiysaniz service account olusturalim;

  gcloud iam service-accounts create sa_cofig_connector
  gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member="serviceAccount:${SERVICE_ACCOUNT_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" \
    --role="roles/owner"

Bu service accountun workloadIdentityUser rolu ekliyoruz. Yakin zamanda workloadidentity uzerine bir yazi yazmayi planliyorum, belki mail ile yeni yazi cikti diye bir servis de yapabiliriz bakalim.

gcloud iam service-accounts add-iam-policy-binding \
${SERVICE_ACCOUNT_NAME}@${PROJECT_ID}.iam.gserviceaccount.com \
    --member="serviceAccount:${PROJECT_ID}.svc.id.goog[cnrm-system/cnrm-controller-manager]" \
    --role="roles/iam.workloadIdentityUser"

Resource olusturulmasi

Not: Bu adimlari takip edebilmeniz icin GKE kaldirmis ve bu cluster'a kubectl ile erisebiliyor olmaniz gerekiyor. Aksi halde su adimlari takip ederek Google uzerinde cluster olusturabilirsiniz. ->
https://cloud.google.com/kubernetes-engine/docs/quickstart#defaults
https://cloud.google.com/kubernetes-engine/docs/quickstart#create_cluster

Asagidaki yamlin icerisinde 'googleServiceAccount' bolumunu kendi bilgileriniz ile degistirip kaydedin.

# configconnector.yaml
apiVersion: core.cnrm.cloud.google.com/v1beta1
kind: ConfigConnector
metadata:
  # ONEMLI; Clusterinizda sadece bir tane ConfigConnector olabilir.
  name: configconnector.core.cnrm.cloud.google.com
spec:
 mode: cluster
 googleServiceAccount: "$SERVICE_ACCOUNT_NAME@${PROJECT_ID}.iam.gserviceaccount.com"

Verelim coskuyu.

kubectl apply -f configconnector.yaml

Namespace

Config connector, terraform gibi GCP kaynaklarini organizasyon, proje vb gibi alt katmanlarda yonetir. Bunu da namespaceler ile ayirip bu ayirdigi namespacelere verdigi annotaionlar araciligi ile yapar. Namespace olustururken verdigimiz annotainlar daha sonra bu namespacelerde olusturdugumuz GCP kaynaklarinda varsayilan olarak otomatik olusurlar.

Yaml ile;

apiVersion: v1
kind: Namespace
metadata:
  annotations:
    cnrm.cloud.google.com/project-id: ${PROJECT_ID}
  name: config-connector

Folder ve organization olarak da ayirmak isterseniz;
cnrm.cloud.google.com/organization-id:
cnrm.cloud.google.com/folder-id:
annotaionlarini kullanabilirsiniz.

Cli ile;

kubectl annotate namespace \
NAMESPACE cnrm.cloud.google.com/project-id=PROJECT_ID

Ornek Kullanim

Staging ve prod diye kubernetes uzerinde 2 namespace'imiz olsun. Cloudsql ve Pubsub gereksinimleri oldugunu varsayalim.

Podlari ve k8s kaynaklarini nasil namespace ile izole edip calistirip, yonetiyorsak yine ayni namespace'i bu sefer GCP kaynaklarini ayni sekilde yonetiyoruz.

Prod cloudsql'i prod namespace'inde
Staging cloudsql'i staging namespace'inde.

Kontrol

Config Connector, tüm bileşenlerini cnrm-system namespace'inde çalıştırır.

Devam etmeden once bakalim butun podlar calisiyor mu?

kubectl wait -n cnrm-system \
      --for=condition=Ready pod --all

Her sey sorunsuz kurulduysa eger, soyle bir cikti almaniz gerekir;

pod/cnrm-controller-manager-0 condition met

CloudSQL Olusturalim

  apiVersion: sql.cnrm.cloud.google.com/v1beta1
  kind: SQLInstance
  metadata:
    name: sqlinstance-kubernetesturkey
  spec:
    databaseVersion: MYSQL_5_7
    region: us-central1
    settings:
      tier: db-f1-micro

Nasil Silerim?

Kubernetes'den silip;

kubectl delete ConfigConnector configconnector.core.cnrm.cloud.google.com --wait=true

Sonra GKE uzerinde disable etmek;

gcloud container clusters update $CLUSTER_NAME --update-addons ConfigConnector=DISABLED