CCE 提供基于原生 Kubernetes 的容器管理服务,为方便用户更好的使用 CCE,我们从集群、应用、问题排查三个方面,总结出来一些最佳实践的 checklist,强烈建议 CCE 用户在开始使用或服务上线前,能对照 checklist 过一遍,以帮忙您顺利的将服务迁移到 CCE 上,降低因为使用不当导致应用异常或需重建集群的风险。
类型 | 项目 | 建议 | 参考文档 |
---|---|---|---|
集群 | 节点数 | 不管服务规模多小,对于线上服务,强烈建议集群节点数至少大于1,且需要预留一定的资源 buffer,避免单点故障导致业务受损 | |
节点密码 | 节点的 root 密码请务必设置为强密码 | ||
节点网络 | 如果集群有对外访问需求,不建议节点直接绑定 EIP,节点对外暴露有安全风险,可以将集群的节点子网创建为 NAT 子网类型. | ||
VPC 路由 | CCE 容器网络实现依赖 VPC 路由,CCE 创建的路由规则描述为 auto generated by cce ,新建路由请不要和 CCE 的路由规则冲突,如无法避免,可以发工单进行咨询. | ||
安全组 | 如果有设置安全组需求,安全组需要放通节点网络、容器网络、以及网段100.64.230.0/24和端口22、6443、30000-32768,否则可能出现容器引擎网络不通的问题. | ||
磁盘容量 | 创建集群时,强烈建议为节点挂载至少 100GB 的 CDS(CCE 已默认勾选). | ||
节点升降配 | 考虑到升降配需要重启机器,可能导致集群容量不足,CCE 未直接支持虚机的升降配,用户可在 BCC 页面操作,但还是建议用户通过先扩容再缩容的方式实现,减少业务影响. | ||
虚机监控 | 虚机 CPU、MEM、磁盘使用率等过高,会影响集群稳定性,CCE 有 Evicted 机制,在节点负载过高时,会将一部分实例迁移走,所以强烈建议用户在 BCM 给节点添加监控报警. | BCM 添加报警 | |
百度智能云三方资源 | 强烈建议 CCE 用户不要直接在 BCC、DCC、VPC、BLB、EIP 等产品页,修改 CCE 创建资源的相关配置,包括名字等,可能导致非预期结果. |
类型 | 项目 | 建议 | 参考文档 |
---|---|---|---|
应用 | 镜像 | 建议用户构建 Docker 镜像时,可以在镜像中安装一些常用的 debug 工具,比如:ping、telnet、curl、vim 等,可自行定制. | |
私有镜像 | 容器使用私有镜像时,需要设置 secret | CCE集群中使用私有镜像实践 | |
实例副本数 | 如果是无状态服务,且不存在冲突情况,建议实例服务本 > 2,避免单点故障造成实例迁移,服务短暂不可用. | ||
资源限制 | 强烈建议所有上线的服务,必须设置 resource.limits . | kubernetes 资源限制 | |
健康检查 | 建议所有上线的服务,设置 livenesss 和 readiness probe 健康检查方式,保证服务自动 Failover. | kubernetes 健康检查 | |
服务暴露方式 | 集群内访问:ClusterIP Service; 集群外访问:LB Service; 集群外访问(HTTP/HTTPS):Ingress. | LoadBalancer 接入网络流量 Ingress 接入网络流量 | |
服务数据持久化 | 服务有数据持久化需求,建议通过 PV 和 PVC 方式使用,目前 CCE 已经支持通过 PV/PVC 方式使用文件存储(CFS)、块存储(CDS)、对象存储(BOS). | 通过 PV/PVC 方式使用 CFS 通过 PV/PVC 方式使用 CDS 通过 PV/PVC 方式使用 BOS |
通常可通过下面两种方式查看错误信息:
如果通过上述方式看不到明显错误,可以在 YAML 中修改容器的启动命令,比如设置为 sleep 3600:
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
labels:
app: nginx
spec:
replicas: 1
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
containers:
- name: nginx
image: hub.baidubce.com/cce/nginx-alpine-go:latest
command: ["/bin/sh", "-c", "sleep 3600"]
启动服务后,通过 kubectl exec -it podName /bin/sh 进入容器,手动执行启动命令,查看服务报错信息.
可以通过 kubectl describe service serviceName,查看Events排查失败原因,一般是 EIP、BLB 的配额超过限制,可以发工单申请加大配额.
注意:用户可以购买的EIP实例数 <= 当前已存在的BCC实例数 + 当前已存在的BLB实例数 + 2
容器网络访问失败具体表现分很多情况:
容器网络问题,一般最终都是 PodIP 不通,导致 Service 的各种访问问题。首选分别在节点和 Pod 中检查 PodIP 是否可以 ping 通,如果不行,需要检查两个地方:
如果确定没有,可以发工单联系管理员进行排查.
注意:Service clusterIP 不能直接 ping 通,需要通过 ip:port 访问;PodIP 可以 ping 通.