WEBKT

Terraform实战:如何自动化部署AKS与GKE的联合集群

89 0 0 0

DevOps工程师的云原生自动化挑战

跨云Terraform模块设计精髓

1. Provider的芭蕾舞步

2. 集群配置的"不对称之美"

网络互联的黑暗艺术

3. 打通VNet与VPC的四种姿势

部署验证的自动化陷阱

4. 用Terratest构建验证围墙

进阶玩家的双云秘籍

终极生存指南

DevOps工程师的云原生自动化挑战

当你的微服务需要同时跑在Azure和GCP上时,凌晨三点的跨云故障排查会让你深刻理解什么叫"云的代价"。上周我们团队就遇到这种噩梦场景——某个关键组件在AKS运行正常,但在GKE却频繁OOM。用Terraform实现基础设施双活部署,不只是为了简历上多一行炫技,而是真正能让你多睡两小时的生存技能。

跨云Terraform模块设计精髓

1. Provider的芭蕾舞步

# 这就像同时操作两台不同操作系统的笔记本
tprovider "azurerm" {
  features {}
  subscription_id = var.azure_sub_id
  client_id       = var.azure_client_id
  client_secret   = var.azure_client_secret
  tenant_id       = var.azure_tenant_id
}

tprovider "google" {
  project     = var.gcp_project_id
  region      = "us-central1"
  credentials = file(var.gcp_cred_path)
}

常见坑点:AZ和Zone的命名差异会让模块复用变成灾难。GCP的"us-central1-a"对应Azure的"eastus",我曾在变量转换上浪费整整一天。最佳实践是抽象location映射表:

locals {
  region_map = {
    "eastus" = "us-central1"
    "westus" = "us-west1" 
  }
  aks_location = "eastus"
  gke_location = local.region_map[local.aks_location]
}

2. 集群配置的"不对称之美"

Azure的节点池叫"node pool",GCP叫"node_pool"(注意下划线)。这些细微差别会导致:

# AKS配置
resource "azurerm_kubernetes_cluster_node_pool" "aks" {
  kubernetes_cluster_id = azurerm_kubernetes_cluster.main.id
  vm_size               = "Standard_D2_v2"
}

# GKE配置
resource "google_container_node_pool" "gke" {
  cluster    = google_container_cluster.main.name
  node_config {
    machine_type = "e2-medium"
  }
}

血泪经验:永远不要在两地使用相同的节点规格。Azure的Standard_D2_v2(2核7G内存)性能表现与GCP的e2-medium(2核8G内存)完全不同,我们的Java服务在GCP就因为这小1G内存频繁崩溃。

网络互联的黑暗艺术

3. 打通VNet与VPC的四种姿势

  1. VIP方案:用负载均衡器暴露服务,简单但延迟高
  2. VPN网关:适合初期验证,但带宽受限
  3. 专用互联(Azure ExpressRoute + GCP Partner Interconnect)
  4. 服务网格(Istio多集群方案)
# Azure VPN网关配置示例
resource "azurerm_virtual_network_gateway" "vpn" {
  sku = "VpnGw1"
  ip_configuration {
    public_ip_address_id = azurerm_public_ip.vpn.id
  }
}

# GCP对应配置
resource "google_compute_vpn_tunnel" "to_azure" {
  peer_ip = azurerm_public_ip.vpn.ip_address
  shared_secret = "supersecret"
}

真实案例:某电商大促期间,VPN带宽打满导致跨云订单同步延迟。后来我们改用GCP的Cloud Interconnect,月费$200但带宽提升10倍。

部署验证的自动化陷阱

4. 用Terratest构建验证围墙

func TestAKSandGKEConnectivity(t *testing.T) {
terraformOptions := &terraform.Options{
TerraformDir: ".",
}
defer terraform.Destroy(t, terraformOptions)
terraform.InitAndApply(t, terraformOptions)
// 验证AKS pod能否访问GKE服务
kubeConfig := terraform.Output(t, terraformOptions, "aks_kubeconfig")
podCmd := "curl -s http://${GKE_SERVICE_IP}:8080/health"
_, err := RunKubectlWithConfigE(t, kubeConfig, "default", "exec", "test-pod", "--", "/bin/sh", "-c", podCmd)
require.NoError(t, err)
}

特别注意:Azure默认出站IP会被GCP防火墙拦截。我们曾在测试环境浪费三天,最后发现需要显式配置GCP防火墙规则:

resource "google_compute_firewall" "allow_azure" {
  network = google_compute_network.main.name
  source_ranges = ["${azurerm_public_ip.aks.outbound_ip}"]
}

进阶玩家的双云秘籍

  • 成本杀手:用Terraform的lifecycle块实现GKE Spot节点与Azure Spot实例联动

    lifecycle {
      ignore_changes = [
        node_count # 让Cluster Autoscaler接管
      ]
    }
    
  • 密钥管理:Vault的Azure Key Vault与GCP KMS联合引擎配置

  • 监控统一:通过Terraform部署OpenTelemetry Collector,将指标同时发往Azure Monitor和GCP Cloud Monitoring

终极生存指南

当我第一次成功从AKS Pod直接ping通GKE Service时,那种快感堪比第一次写出能运行的Hello World。但有三个忠告:

  1. 永远在两个云上都保留独立的后备部署方案
  2. 跨云DNS解析延迟可能比你想象的更严重(我们遇到过的200ms延迟)
  3. 准备双倍预算——不是给云服务商,是给团队买咖啡缓解调试压力
被云厂商混合双打的SRE Terraform多云部署Kubernetes

评论点评

打赏赞助
sponsor

感谢您的支持让我们更好的前行

分享

QRcode

https://www.webkt.com/article/9071