📚 课程目录第4章微服务与容器化部署

4. 微服务与容器化部署

Active Workspace（AWC）在 Teamcenter 的现代部署体系中，通常以一组相互协作的微服务形态运行：前端 Web 层、会话与认证代理、与 Teamcenter 服务端交互的适配层、以及若干支撑组件。把这些服务放进 Docker 容器、再由 Kubernetes 统一编排，是当前较常见的落地方式。本节围绕“环境准备—镜像部署—编排与健康检查”这条主线，讲清楚每一步实际要做什么、关键参数如何设置、结果如何判断。

一、环境准备：先确定集群与镜像仓库

Kubernetes 环境准备的核心不是“装一个 K8s”，而是先明确三件事：集群形态、节点资源、镜像仓库。教学示例中可采用一个 3 节点集群：1 个控制面节点（4 vCPU / 8 GB）、2 个工作节点（各 8 vCPU / 16 GB），操作系统为 Linux，容器运行时使用 containerd。AWC 各服务对内存较敏感，工作节点建议不低于 16 GB，否则在并发会话较多时容易出现 OOMKilled。

镜像仓库建议使用私有 Registry（如 Harbor 或 registry:2），因为 AWC 镜像通常来自 Teamcenter 安装介质或官方交付包，需要先导入再分发。示例中先在一台具备 Docker 的构建机上加载镜像并打标签：

docker load -i awc-web-6.3.0.tar
docker tag awc-web:6.3.0 registry.corp.local/tc/awc-web:6.3.0
docker push registry.corp.local/tc/awc-web:6.3.0

同时需要在集群中创建拉取镜像所需的 Secret，供后续 Pod 引用：

kubectl create secret docker-registry regcred \
  --docker-server=registry.corp.local \
  --docker-username=admin \
  --docker-password=Harbor12345 \
  -n tc-awc

命名空间建议按环境隔离，例如 tc-awc-dev、tc-awc-prod，避免测试与生产互相干扰。此外要提前确认 DNS 解析、NTP 时间同步和存储类（StorageClass），因为 AWC 的日志、会话缓存和配置卷都依赖持久化或共享存储。

二、AWC 微服务镜像部署：从镜像到 Pod

AWC 的微服务通常包括：awc-web（前端静态资源与反向代理）、awc-session（会话管理）、awc-tc-adapter（与 Teamcenter 服务端通信）、以及可选的 awc-cache（Redis 类缓存）。部署时不要把所有服务塞进一个 Pod，而应按职责拆分为独立 Deployment，便于单独扩缩容和滚动升级。

以 awc-web 为例，Deployment 的关键字段包括副本数、镜像地址、容器端口、环境变量和资源限制。示例片段如下：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: awc-web
  namespace: tc-awc
spec:
  replicas: 2
  selector:
    matchLabels:
      app: awc-web
  template:
    metadata:
      labels:
        app: awc-web
    spec:
      imagePullSecrets:
      - name: regcred
      containers:
      - name: awc-web
        image: registry.corp.local/tc/awc-web:6.3.0
        ports:
        - containerPort: 8080
        env:
        - name: TC_SERVER_URL
          value: "http://tcserver.corp.local:7001"
        resources:
          requests:
            memory: "1Gi"
            cpu: "500m"
          limits:
            memory: "2Gi"
            cpu: "1"

这里 TC_SERVER_URL 指向 Teamcenter 服务端地址，是 AWC 适配层能否连通后端的关键。部署后可用 kubectl get pods -n tc-awc 观察状态，正常应为 Running 且 READY 1/1。若长期处于 ImagePullBackOff，优先检查 Secret 与镜像标签；若为 CrashLoopBackOff，则查看 kubectl logs 中的启动报错，常见原因是后端地址不可达或配置卷缺失。

三、服务编排：Service、Ingress 与配置管理

Pod 本身地址不稳定，必须通过 Service 暴露。AWC 前端通常用 Ingress 对外提供 HTTPS 访问，内部服务之间用 ClusterIP Service 通信。示例中为 awc-web 创建 Service 与 Ingress：

apiVersion: v1
kind: Service
metadata:
  name: awc-web-svc
  namespace: tc-awc
spec:
  selector:
    app: awc-web
  ports:
  - port: 80
    targetPort: 8080

配置管理方面，建议把后端地址、会话超时、日志级别等放入 ConfigMap，把密码类信息放入 Secret，再以环境变量或卷的方式注入容器。这样切换开发/生产环境时只需替换 ConfigMap，而不必重建镜像。编排时还要注意启动顺序：awc-tc-adapter 依赖 Teamcenter 服务端可用，awc-web 依赖 session 与 adapter，可通过 initContainer 或就绪探针间接控制流量进入时机。

四、健康检查：让编排系统知道服务是否可用

健康检查是容器化部署能否稳定运行的分水岭。Kubernetes 提供两类探针：livenessProbe 判断容器是否存活，失败会重启容器；readinessProbe 判断容器是否可接收流量，失败会从 Service 端点中摘除。AWC 各服务应分别暴露 /healthz 与 /ready 接口。

示例配置如下：

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
  failureThreshold: 3
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 10
  periodSeconds: 5
  failureThreshold: 2

参数含义需要结合实际调整：initialDelaySeconds 太短会导致服务尚未启动就被判定失败，太长则故障恢复慢；failureThreshold 过小容易因瞬时抖动误杀。判断健康检查是否生效，可观察 kubectl describe pod 中的 Events，以及 kubectl get endpoints awc-web-svc 是否包含全部就绪 Pod 的 IP。若 Endpoints 为空，说明 readiness 未通过，应优先检查 /ready 返回内容与后端连通性。

建议在正式上线前做一次“故障演练”：手动停掉一个 awc-tc-adapter Pod，观察 Service 是否自动摘除该端点、剩余副本是否承接流量、以及恢复后是否重新加入。这比只看 Pod 状态更能验证编排与健康检查是否真正生效。

五、结果判读与常见问题

部署完成后，可用以下命令快速核对整体状态：

kubectl get pods -n tc-awc -o wide
kubectl get svc,ingress -n tc-awc
kubectl get endpoints -n tc-awc

若 Pod 全部 Running 且 Endpoints 完整，再通过浏览器访问 Ingress 地址，确认能正常进入 AWC 登录页并完成一次登录。常见问题中，ImagePullBackOff 多与 Secret 或镜像标签有关；CrashLoopBackOff 多与后端地址、配置卷或内存限制有关；Readiness probe failed 则要区分是服务自身未就绪，还是依赖的 Teamcenter 服务端不可达。把这三类现象与对应排查方向建立映射，是本节最值得掌握的实践判断能力。