gke frontendのdns設定

GKEバックエンドに対してAレコードとCNAMEレコードを4種類のコンテナ向けに設定するベストプラクティスについて説明します。

マルチコンテナ環境のためのDNS設定ベストプラクティス

4種類のコンテナ用に効率的かつ管理しやすいDNS設定を構築するには、以下のアプローチがベストプラクティスとなります：

1. ドメイン構造の設計

example.com         # メインドメイン (A レコード → ロードバランサーIP)
api.example.com     # API ゲートウェイ/エントリーポイント (CNAME → example.com)
service1.example.com # コンテナ1 (CNAME → api.example.com)
service2.example.com # コンテナ2 (CNAME → api.example.com)
service3.example.com # コンテナ3 (CNAME → api.example.com)
service4.example.com # コンテナ4 (CNAME → api.example.com)

2. Terraformでの実装例

locals {
  domain_name = "example.com"
  lb_ip       = "203.0.113.1"  # ロードバランサーのIP
  services    = ["service1", "service2", "service3", "service4"]
  ttl         = 300
}

resource "google_dns_managed_zone" "main_zone" {
  name        = "example-zone"
  dns_name    = "${local.domain_name}."
  description = "Main DNS zone for services"
}

# メインドメインのAレコード
resource "google_dns_record_set" "main_domain" {
  name         = "${local.domain_name}."
  managed_zone = google_dns_managed_zone.main_zone.name
  type         = "A"
  ttl          = local.ttl
  rrdatas      = [local.lb_ip]
}

# APIゲートウェイのCNAMEレコード
resource "google_dns_record_set" "api_gateway" {
  name         = "api.${local.domain_name}."
  managed_zone = google_dns_managed_zone.main_zone.name
  type         = "CNAME"
  ttl          = local.ttl
  rrdatas      = ["${local.domain_name}."]
}

# 各サービス用のCNAMEレコード
resource "google_dns_record_set" "services" {
  for_each     = toset(local.services)
  name         = "${each.value}.${local.domain_name}."
  managed_zone = google_dns_managed_zone.main_zone.name
  type         = "CNAME"
  ttl          = local.ttl
  rrdatas      = ["api.${local.domain_name}."]
}

3. Ingressの設定

GKE側でIngressリソースを設定して、ホストベースのルーティングを行います：

resource "kubernetes_ingress_v1" "main_ingress" {
  metadata {
    name = "main-ingress"
    annotations = {
      "kubernetes.io/ingress.class" = "gce"
    }
  }
  
  spec {
    rule {
      host = "service1.${local.domain_name}"
      http {
        path {
          path = "/*"
          backend {
            service {
              name = "service1"
              port {
                number = 80
              }
            }
          }
        }
      }
    }
    
    # 他のサービスも同様に設定
    rule {
      host = "service2.${local.domain_name}"
      http {
        path {
          path = "/*"
          backend {
            service {
              name = "service2"
              port {
                number = 80
              }
            }
          }
        }
      }
    }
    
    # service3, service4も同様
  }
}

4. モジュール化

多くの環境で再利用する場合は、Terraformモジュールとして定義するとよいでしょう：

module "dns_records" {
  source      = "./modules/dns"
  domain_name = local.domain_name
  lb_ip       = local.lb_ip
  services    = local.services
}

その他のベストプラクティス

1. TTLの最適化: 開発環境では短いTTL（300秒程度）、本番環境ではより長いTTL（3600秒など）を設定

2. ヘルスチェックの統合: Google Cloudのヘルスチェックと連携させ、障害時に自動的にトラフィックをリダイレクト

3. DNSレコードのバージョン管理: Terraformの状態ファイルをリモートバックエンドで管理し、チーム間で共有

4. 個別のサービスエントリポイント: 各サービスに個別のロードバランサーが必要な場合は、サービスごとにAレコードを設定することも検討

5. ワイルドカードDNSの活用: 開発環境などでは *.dev.example.com のようなワイルドカードレコードも有用

このアプローチにより、各コンテナサービスを個別のサブドメインで公開しながら、効率的に管理できる構成が実現できます。