1. 为什么选择腾讯云TCRTKE构建DevOps流水线刚接触云原生的开发者常会问为什么要把代码变成容器镜像再部署直接上传代码到服务器不行吗这里有个真实案例去年我们团队有个Node.js服务频繁崩溃排查发现测试环境用Node 14而生产环境用Node 12。这种环境差异问题在容器化后彻底消失——因为镜像里已经锁定了所有依赖版本。腾讯云TCR容器镜像服务就像个智能集装箱码头企业级镜像仓库支持多架构镜像amd64/arm64和Helm Chart存储安全扫描自动检测镜像漏洞我上个月就拦截过一个包含高危漏洞的Redis镜像全球同步北京构建的镜像可以秒级同步到新加坡区域TKE容器服务则是自动化调度专家智能扩缩容根据CPU/内存指标自动调整Pod数量混合部署同一集群可运行在线业务和离线计算任务成本优化使用竞价实例能节省60%以上的计算成本2. 环境准备与基础配置2.1 创建TKE集群的避坑指南第一次创建集群时我踩过网络配置的坑选错VPC网段导致后期无法与现有服务互通。建议按这个配置# 创建生产环境集群上海区域 tkeectl create cluster prod-cluster \ --region ap-shanghai \ --vpc-id vpc-123456 \ --container-cidr 172.16.0.0/16 \ --max-pods 256 \ --worker-config {InstanceType:SA2.4XLARGE32,InstanceCount:3}关键参数说明container-cidr不要与现有VPC网段重叠max-pods每个节点最大Pod数建议(IP数量-5)/2worker-config生产环境建议4核16G起步2.2 TCR企业版实例配置开通TCR时有个隐藏技巧选择与TKE同地域的实例这样镜像拉取走内网且免流量费。通过控制台创建时注意实例类型选企业版 2 访问控制选私有读写生产环境必选安全策略开启漏洞扫描和镜像防篡改3. 从代码到镜像的自动化构建3.1 编写高效的Dockerfile见过最典型的反例是直接COPY整个项目目录这会导致镜像体积暴涨。正确的做法应该是# 多阶段构建示例Go项目 FROM golang:1.18 as builder WORKDIR /app COPY go.mod go.sum ./ RUN go mod download COPY . . RUN CGO_ENABLED0 GOOSlinux go build -o /server FROM alpine:3.15 COPY --frombuilder /server /server EXPOSE 8080 ENTRYPOINT [/server]实测这个优化让镜像从1.2GB降到28MBTCR的加速构建功能还能缓存中间层使后续构建速度提升70%以上。3.2 配置自动化构建规则在TCR控制台配置构建规则时我推荐这种版本命名策略${BRANCH_NAME}-${DATETIME}-${COMMIT_ID:0:8}例如master-20220715-3a8b2c4d这样通过镜像tag就能清晰知道代码来源分支构建时间对应的commit版本4. 从镜像到部署的自动化交付4.1 使用TKE工作负载自动更新最让我惊喜的是TKE的镜像更新触发功能。在控制台创建工作负载时选择使用TCR企业版镜像开启自动更新开关设置更新策略为RollingUpdate这样当TCR中有新镜像推送时TKE会自动分批更新Pod整个过程无需人工干预。上周我们前端发布时50个Pod的滚动更新只用了2分钟用户完全无感知。4.2 配置健康检查探针很多部署失败是因为没配探针。这是我常用的配置模板livenessProbe: httpGet: path: /healthz port: 8080 initialDelaySeconds: 30 periodSeconds: 10 readinessProbe: exec: command: - curl - -f - http://localhost:8080/ready failureThreshold: 3特别注意initialDelaySeconds要给应用留足启动时间readinessProbe比liveness更宽松避免频繁重启5. 全链路监控与排错5.1 构建日志实时查看某次构建失败时通过TCR的实时日志发现是npm源超时。现在我会在构建规则中预置环境变量# 前端项目构建环境变量 - key: NPM_CONFIG_REGISTRY value: https://mirrors.cloud.tencent.com/npm/5.2 部署事件追踪在TKE控制台有个隐藏功能事件持久化存储。通过这个命令查看历史事件kubectl get events --sort-by.metadata.creationTimestamp -n production曾经用这个方法发现某个Node磁盘空间不足导致Pod反复漂移及时扩容避免了线上事故。6. 高级技巧与性能优化6.1 镜像按需加载当单个镜像超过1GB时可以使用TCR的按需加载功能。在Pod模板中添加注解annotations: tke.cloud.tencent.com/image-lazy-load: true实测这个功能让大型AI模型的启动时间从8分钟降到40秒。6.2 合理设置资源限制见过太多OOMKilled的案例。建议按照这个公式设置内存限制容器实际内存需求 × 1.5例如应用平时占用1GB内存就设limit为1.5GB。太宽松会导致资源浪费太紧又容易触发OOM。7. 安全加固实践7.1 镜像签名验证在TCR中开启内容信任功能后所有镜像推送都需要签名。部署时在TKE添加策略apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: verify-signature spec: imagePolicy: keyPaths: - name: tke publicKey: | -----BEGIN PUBLIC KEY----- YOUR_PUBLIC_KEY -----END PUBLIC KEY-----7.2 网络策略隔离生产环境一定要配置NetworkPolicy。比如这个配置只允许前端访问后端服务apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: backend-allow-frontend spec: podSelector: matchLabels: app: backend ingress: - from: - podSelector: matchLabels: app: frontend ports: - protocol: TCP port: 80808. 成本控制方案8.1 使用弹性节点池通过这个命令创建包含竞价实例的节点池tkeectl create nodepool spot-pool \ --cluster prod-cluster \ --instance-type S5.LARGE8 \ --spot \ --max-price 0.2 \ --min-size 1 \ --max-size 10我们用来跑CI/CD任务比按量计费节省75%成本。关键是要设置合理的max-price避免被强制回收。8.2 镜像仓库清理策略TCR的存储费用很容易被忽视。建议设置自动清理规则保留最近10个tag排除所有带release的tag清理超过180天的镜像在控制台配置后每月节省了300GB的存储空间。