阿里云上的容器技术实践总结
为什么选择阿里云
现在的公有云如雨后春笋,国外如AWS、Azure、Bluemix,国内如BAT、DaoCloud、goodrain,都可以给大家提供丰富的云基础设施和上层服务,那为什么选择阿里云呢?主要有三点想法:
- 我们使用阿里云的服务已经有5年了,从企业级PaaS平台合作开始,再到帮助我们的一些客户逐步迁云,对阿里云的能力还是比较熟悉的。
- 因为要做的是容器,国外AWS,Azure虽然有,但AWS在中国一直没“正规”数据中心(唯一的一个前几天还被查了),Azure是微软体系(也许是心里作祟,总感觉不对口…);而国内虽然一些公有云有容器能力,但规模普遍偏小;再者,阿里云反正也开始做容器了,说明人家底层还是有支持能力的。
- 当然,还有一个做法,自建数据中心或租赁IDC,不过做事情还是的慢慢来(我们又不是暴发户…),不到一定规模,这个前期投入还是有点大的。
遇到的问题
千万别气馁,因为都有CoreOS镜像了,不支持docker谁信(其实阿里云还是蛮务实的,没有经过严格测试不敢说支持),好歹也得试一试,于是就先买了几台CoreOS机器,接下来做的一些事情就不那么顺利了:
- 先做系统升级(默认版本比较低了,681.2.0 64位),那大家都知道外网流量很贵,所以最好搭个内部升级服务器,在升级后发现网络有问题,进不去,内部进入发现原因是网络没起来,这工作只有先手工做了(systemctlrestart systemd-networkd.service)
- 升级完了,最好的习惯是去打快照(当然,这个服务过些天就要收钱了,还挺贵的…),发现没打出来,这个问题排了好久,最后的原因是自作孽啊,删了个自认为没用的yunservice,后来想想也觉得自己幼稚了,都叫yun了,肯定是阿里云留下做事情的呀
- kubernetes安装,一般来说有三种安装方式,命令型、服务型、容器型,技术成本考虑,最终我们先用了前两种的混合态,然后setup-network-enviroment辅助验证,还好没遇到大问题,容器间网络很快通了(我们用了container模式,端口映射出去)
- 因为在VPC环境,我们使用了EIP,但IP资源实在是宝贵(20个),所以留了一个做堡垒机,其他的大部分给了计算节点,由kubernetes的service public IP消费了,这点告诉我们,宝贵资源大家前期一定要做好规划
- 内部DNS能力,用了skyDNS,一个比较坑的问题,一定要用最新版本,之前哪怕是release版本都有问题,服务注册后进不去出不来的,反正挺诡异的,一直也没见说哪个版本修复的
- 跑服务过程中遇到了棘手问题,大家都知道kubernetes的容器调度能力,会结合自身的一些分析,在运行时把pod做热迁,放到他认为合适的机器上,这就使得容器用宿主机本地磁盘不现实了,持久化数据没法迁移或共享呀(当然,有同学说可以通过label强制运行在某处,但好特性还是想用一用,不然什么都规划好,这和云的宗旨就貌合神离了),这怎么办?分布式存储是个好方案,但阿里的块存储服务还没发布,虽然我们一直是决定的自己搭,但那也是下个版本的事情了,这边先low了一下,只能先用NFS临时解决