GKEにおけるCloud SQL Proxyの完全ガイド。

1年 ago
結衣, 春花
3 minutes

こんにちは、読者の皆さん！この記事では、実演を交えながらGKEでのCloud SQL Proxyのセットアップについて説明しています。

管理されたKubernetesホスティングサービスをお探しの場合は、成長に向けたシンプルで管理されたKubernetesサービスをご覧ください。

さあ、始めましょう！😊 (Sā, hajimemashō!)

クラウドSQLプロキシの利点

アプリケーションが現代化の進路へ進んでいる中で、アプリケーションの構成要素は今やGoogle、Azure、Amazonなど、パブリッククラウド環境上でリソースをホストするように移行しています。

データベースやキャッシュストレージなどの重要な要素は、現代化への道を確立しました。 (Dētabēsu ya kyasshu sutorēji nado no jūyōna yōso wa, gendai-ka e no michi o kakuritsu shimashita.)

ほとんどのアプリケーションは現在、最適化と炭素排出量の削減のためにコンテナ化されています。

このシナリオを見ると、コンテナとしてホストされているアプリケーションとクラウドデータベースインスタンスの間に接続を形成する方法や経路があるはずです。

同じために、Cloud SQL Proxyが登場します。

Cloud SQL Proxyを使用することで、コンテナ化されたアプリケーションとクラウドデータベースインスタンスの間の接続を開始することができます。

私たちはインスタンスのプライベートIPアドレスを使って接続することもできますが、以下の利点から、Cloud SQL Proxyを使ってアプリケーションをクラウドデータベースインスタンスに接続する方が適しています。

  • Establishes secure connections- The Cloud SQL proxy enables secure connections by encrypting the traffic from and to the database instances.
  • IAM based database authentication- It enables the authentication by using service accounts/workload identity and thus replicate the access through IAM.

実用的な実装 – GKE内でコンテナ/ポッドとしてCloud SQL Proxyをセットアップします。

クラウドSQLプロキシポッドを構築するための前提条件のリストが以下に示されています。

  • A full-fledged Google Kubernetes Engine Cluster with the kubectl tool installed.
  • In case we wish to use the connections over a private IP, we need to ensure that the Cloud SQL Proxy and the database instance share the same VPC network.
  • A Cloud SQL Instance (MYSQL, PostgreSQL, SQL Server)
  • An account in the PostgreSQL instance. The application running within the GKE cluster will make use of these account credentials to connect to the database.

ステップ1: データベース設定で秘密を作成する

クラスタ内で実行されるアプリケーションには、サイドカーとしてクラウドSQLプロキシを設定します。このシナリオでは、アプリケーションはプロキシ自体を介してデータベースインスタンスと通信します。

したがって、アプリケーションコンテナにデータベースの構成値を設定して、カスタマイズされたデータベースに接続する必要があります。

それを実現するためには、以下に示すように、アプリケーションコンテナと共有される同じ名前空間内に秘密を作成する必要があります。

kubectl create secret generic <YOUR-DB-SECRET> \
  --from-literal=username=<YOUR-DATABASE-USER> \
  --from-literal=password=<YOUR-DATABASE-PASSWORD> \
  --from-literal=database=<YOUR-DATABASE-NAME>

ステップ2: Cloud SQLインスタンスの設定値を取得する

アプリケーションをデータベースインスタンスに接続するためには、VMまたはコンテナ（サイドカー）としてCloud SQLプロキシを設定する必要があります。そのために、以下のCloud SQLインスタンスに関する情報が必要です。

  • The instance connection name
  • Enable the Cloud SQL Admin API in the project which holds your GKE cluster
  • The JSON key (credential) file of the service account which has necessary permission on the Google Project which holds the Cloud SQL Instance resource.

ステップ3: GKEで使用するために、Cloud SQL Proxyに使用されるサービスアカウントを生成する。

GKEクラスタ内でCloud SQL Proxyインスタンスを実行するには、サービスアカウントを作成し、必要な権限を付与する必要があります。

アプリケーションごとに個別のサービスアカウントを使用することをおすすめします。これにより、より安全な使用と移行が可能となります。

サービスアカウントの要件

    1. 同じプロジェクトで動作するクラウドSQLインスタンスと同じプロジェクトで作成される必要があります。

 

    1. 少なくともクラウドSQLクライアントIAMロールが与えられる必要があります。

 

    接続にプライベートIPを使用する場合、クラウドSQLインスタンスとGKEは同じVPCネットワークを共有する必要があります。

サービスアカウントを作成したら、サービスアカウントの鍵をシークレットからボリュームとしてCloud SQLプロキシコンテナにマウントする必要があります。

以下の例を通じて理解しましょう！(Ineru no rei o tsūjite rikai shimashou!)

gcloudコマンドを使用して資格情報キーファイルを作成してください。

gcloud iam service-accounts keys create ~/key.json \

--iam-account=YOUR-SA-NAME@project-id.iam.gserviceaccount.com

資格情報ファイルからk8のシークレットを作成してください。

kubectl create secret generic YOUR-SA-SECRET \

--from-file=service_account.json=~/key.json

上記の秘密をプロキシコンテナのボリュームとして使用してください。

volumes:

- name: <YOUR-SA-SECRET-VOLUME>

  secret:

    secretName: <YOUR-SA-SECRET>

ステップ4：サイドカー/ポッドとしてCloud SQL Proxyを実行してください。

ステップ4に到達したら、以下の利点により、アプリケーションポッド内にサイドカープロキシコンテナを作成する必要があります。

  • Because of the IAM database permissions, using the sidecar reduces the exposure of the instance to the entire cluster.
  • It reduces and prevents the local exposure to the SQL outbound traffic by encrypting it.

コード


apiVersion: apps/v1
kind: Deployment
metadata:
  name: <YOUR-DEPLOYMENT-NAME>
spec:
  selector:
    matchLabels:
      app: <YOUR-APPLICATION-NAME>
  template:
    metadata:
      labels:
        app: <YOUR-APPLICATION-NAME>
    spec:
      containers:
      - name: <YOUR-APPLICATION-NAME>
        # ... other container configuration
        env:
        - name: DB_USER
          valueFrom:
            secretKeyRef:
              name: <YOUR-DB-SECRET>
              key: username
        - name: DB_PASS
          valueFrom:
            secretKeyRef:
              name: <YOUR-DB-SECRET>
              key: password
        - name: DB_NAME
          valueFrom:
            secretKeyRef:
              name: <YOUR-DB-SECRET>
              key: database
      - name: cloud-sql-proxy
        
        image: gcr.io/cloudsql-docker/gce-proxy:1.28.0 # make sure the use the latest version
        command:
          - "/cloud_sql_proxy"
          - "-ip_address_types=PRIVATE"

          # Replace DB_PORT with the port the proxy should listen on
          # Defaults: MySQL: 3306, Postgres: 5432, SQLServer: 1433
          - "-instances=<INSTANCE_CONNECTION_NAME>=tcp:<DB_PORT>"

          
          - "-credential_file=/secrets/service_account.json"
        securityContext:
          
          runAsNonRoot: true
        volumeMounts:
        - name: <YOUR-SA-SECRET-VOLUME>
          mountPath: /secrets/
          readOnly: true
        resources:
          requests:
            
            memory: "2Gi"
          
            cpu:    "1"
      volumes:
      - name: <YOUR-SA-SECRET-VOLUME>
        secret:
          secretName: <YOUR-SA-SECRET>

結論

これにより、このトピックの終わりに近づきました。もし質問がある場合は、下のコメント欄で自由にコメントしてください。

クラウドデータベースやKubernetes関連情報についての他の投稿をご覧になりたい方は、ぜひお楽しみにお待ちください。

それまで、楽しく学習を続けてくださいね！😊

参考文献

    1. Cloud SQL Proxyについて

 

    GKEにおけるCloud SQL Proxy
コメントを残す 0

Your email address will not be published. Required fields are marked *