阿里云上的容器技术实践总结
为什么选择阿里云
现在的公有云如雨后春笋，国外如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临时解决
