Kubernetes微服务部署：Spring Cloud 应用迁移到 K8s，服务发现配置​

在微服务的世界里，Spring Cloud家族曾长期稳坐Java服务治理的王座。但云原生时代的到来，让Kubernetes（K8s）成为了基础设施层的"万磁王"。今天咱们就来聊聊，如何把Spring Cloud的"传统手艺"平滑迁移到K8s的现代航母上，尤其是服务发现这个"灵魂部件"的配置诀窍。

1. 原有架构的"甜蜜负担"

典型Spring Cloud架构通常会采用Eureka + Ribbon + Config Server组合拳：

// Spring Cloud服务提供者配置（application.yml）
spring:
  application:
    name: user-service
eureka:
  client:
    service-url:
      defaultZone: http://eureka-server:8761/eureka/

这个模式的问题逐渐显现：

• 注册中心运维成本：单独的Eureka集群需要监控和维护
• 配置中心局限：动态更新需要配合Spring Cloud Bus
• 弹性能力受限：流量治理依赖于客户端负载均衡

2. K8s的"降维打击"方案

Kubernetes通过控制面组件提供原子能力：

kubectl get endpoints user-service
NAME           ENDPOINTS                         
user-service   10.244.1.3:8080,10.244.2.5:8080

完全不用单独维护注册中心，DNS自动解析的魔法背后：

• Service：逻辑服务的抽象（VIP）
• Endpoint Controller：持续跟踪Pod状态
• kube-proxy：维护节点网络规则

3. 迁移实战：三部曲

3.1 解除Eureka绑定

改造前的服务消费者代码示例：

@Bean
@LoadBalanced  // 基于Ribbon的客户端负载均衡
public RestTemplate restTemplate() {
    return new RestTemplate();
}

改造后的K8s原生方式：

// 直接使用K8s服务名访问
String url = "http://user-service/api/v1/profile";

3.2 服务暴露的标准化

K8s部署文件（user-service-deployment.yaml）：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: user-service
  template:
    metadata:
      labels:
        app: user-service
    spec:
      containers:
      - name: user-service
        image: registry.example.com/user-service:1.2.0
        ports:
        - containerPort: 8080
        readinessProbe:  # 健康检查关键！
          httpGet:
            path: /actuator/health
            port: 8080
          initialDelaySeconds: 20
          periodSeconds: 5

配套的Service定义（user-service-svc.yaml）：

apiVersion: v1
kind: Service
metadata:
  name: user-service
spec:
  selector:
    app: user-service
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
  type: ClusterIP  # 默认内部服务类型

3.3 配置管理的进化

Spring Cloud Config的K8s替代方案：

# configmap示例（global-config.yaml）
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
data:
  application.yaml: |
    logging:
      level:
        root: INFO
    feature:
      newPayment: true

Pod中的挂载使用：

volumeMounts:
- name: app-config
  mountPath: "/app/config"
volumes:
- name: app-config
  configMap:
    name: app-config

4. 服务发现的深度调优

4.1 DNS解析的玄机

在Java代码中可直接使用K8s服务名：

// 直接访问K8s Service
restTemplate.getForObject("http://order-service/api/orders", List.class);

背后的解析规则：

• service.namespace.svc.cluster.local 标准域名格式
• 跨namespace访问需全称调用

4.2 金丝雀发布的艺术

通过Deployment标签实现：

# 金丝雀版本部署
apiVersion: apps/v1
kind: Deployment
metadata:
  name: user-service-canary
spec:
  replicas: 1  # 小流量版本
  selector:
    matchLabels:
      app: user-service
      version: v2.0
  template:
    metadata:
      labels:
        app: user-service
        version: v2.0

使用Service选择器实现流量分割：

apiVersion: v1
kind: Service
metadata:
  name: user-service
spec:
  selector:
    app: user-service
    version: v1.0  # 默认路由到稳定版

5. 避坑指南：血的教训

数据一致性陷阱：
某电商大促期间，K8s自动扩缩容导致数据库连接池爆满。解决方案：

env:
- name: MAX_POOL_SIZE
  valueFrom:
    resourceFieldRef:
      resource: requests.memory
      divisor: 1Mi

网络策略暗礁：
使用NetworkPolicy控制服务间访问：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: user-service-policy
spec:
  podSelector:
    matchLabels:
      app: user-service
  ingress:
  - from:
    - podSelector:
        matchLabels:
          app: order-service

6. 技术雷达扫描

优势对比：

• 弹性能力：K8s HPA vs Spring Cloud熔断器
• 服务发现：KubeDNS vs Eureka服务列表
• 配置管理：ConfigMap热更新 vs Spring Cloud Config

性能指标（实测数据）：

7. 总结：在变革中寻找平衡

当完成迁移后，你会获得：

• 基础设施层的自动驾驶能力
• 与云原生生态的无缝集成
• 混合云场景的统一管理

但别忘了保留Spring Cloud的精华：

• 优雅停机机制
• 接口级的熔断降级
• 分布式事务支持

正如某位大师所说："架构演进不是替换，而是扬弃。"