丰富的线上&线下活动，深入探索云世界
做任务，得社区积分和周边
最真实的开发者用云体验
让每位学生受益于普惠算力
让创作激发创新
资深技术专家手把手带教
遇见技术追梦人
技术交流，直击现场
海量开发者使用工具、手册，免费下载
极速、全面、稳定、安全的开源镜像
开发手册、白皮书、案例集等实战精华
为开发者定制的Chrome浏览器插件
建设公司云原生研发基础设施，为研发部门提供安全、可靠、高效的基础资源、数据存储服务、DevOps流水线以及运维自动化服务等。
OpenStack社区对Ubuntu支持比较完善，Ubuntu更新速度快，内核版本比较新，可以支持更高版本的KVM，对OpenStack使用者来说，Ubuntu可以提供更好的性能。就系统的稳定性而言，CentOS来自Redhat商业版本的重新编译，稳定性和系统优化以及兼容性方面，CentOS有着比较完善的测试和发型流程。CentOS7以后，也换用了Linux3.x内核版本。鉴于系统可靠性的选择和之前公司的技术积累，还是选用CentOS系列，比Ubuntu管理更为方便。
OpenStack主要是面向资源分配，虚拟机创出来了就基本没有责任了，至于服务高可用，自动伸缩，监控等这类的功能完全由应用方来处理，平台不提供支持，适合传统的部署模式，对应用而言和物理机时代没有区别；而k8s容器云主要面向的是服务，强调服务能力，具有弹性与高可用保障，而不是简单地提供IT资源。对应的，应用服务也要使用云原生的理念来进行改造拆分，以更好地利用k8s提供的平台能力。就咱们公司而言目前还需要OpenStack，因为很多老系统没有容器化，所以到了现实环境下就要妥协。
但是无论是OpenStack还是k8s上手技术门槛较高，最痛苦的事情，莫过于看它的架构。
不信？好，扔个OpenStack架构图给你看：
我还是用一个简单的图吧，看得更明白些。如下：
k8s架构图如下：
看上去比OpenStack的架构图稍微好点，不过从技术上来说也是比较复杂的。
云计算发展到今天，无论是在技术、服务层面，还是在商业层面都已经相对比较成熟。当前绝大多数初创公司在基础设施上的策略一定是公有云，已经极少再有自建或托管IDC的情况，所以不会存在是否上云这样的纠结。但是对于我们这样体量的公司，全部上云，就必须要考虑得更全面：考虑基础设施的变化，业务的平稳过度，运维模式的转变，成本管控的调整，以及众多的细节问题。
虽然需要比较和考虑的因素非常多，主要从人员能力、技术掌控、未来发展等方面进行说明。人的因素是放在第一位的，企业中一般是业务开发应用及基础架构运维人员（比如系统、网络管理等），采用开源的方案的话，如果仅仅是在开发、测试环境去试着安装、使用是没有问题的，但是当准备在生产上进行实施部署，并且后续为了进一步提升开源平台化的能力（比如生产遇到问题需要分析、内部系统集成、进行前端定制、跟随社区优化/升级等），会发现这些均需要能力较强的既懂开发也懂基础架构的人员团队时候就寸步难行了。
越是底层的技术，技术门槛就越高、越复杂，也越离不开高端人才的投入。比如硬件资源虚拟化，就需要有懂内核、懂网络、懂OpenStack、懂k8s、懂分布式存储如Ceph等等的专业人才。但是真正精通的人却不多，加上要搞定整套解决方案，还需要一个完整的团队，这就难上加难，在团队组建上面临更大的困难。人才紧缺，就意味着人力成本会很高，这个就是技术投入的隐性成本。而且因为技术门槛高，一旦发生人员流动，那么，对于原有技术平台来说，无人能把控的风险就会更高。这一点往往会是最大的隐性管理成本所在。
当然，在人才招揽上，我们可以加大人力成本投入，招聘最优秀的人才。但是作为像咱们这样以更加聚焦于业务，以业务发展为生命线的公司，我们更期望能够在业务上取得创新和发展，而不是在技术上取得多么非凡的成就（这一点与公司的发展诉求是不一致的）。所以这就从根本上决定了，我们不会无限度地投入，或投入非常大的成本在这些基础技术的研究上。
大致来说，在部署应用程序的方式上，我们现在主要经历了三个时代：
前面我们说了，我们公司目前正处于「虚拟化部署时代」到「容器化部署时代」的过渡阶段，那么它必然带来了更高的要求：
针对上述更高诉求，我们在建设私有云的过程中需要重点考虑并逐一落地。
私有云建设很少有一步到位的，往往最开始的阶段是满足最基础的需求，例如计算虚拟化，存储虚拟化，然后网络虚拟化，然后容器，监控，大数据，编排，数据库，等等公共应用。其实，这个和云计算的分层也是有很大关系的。从IaaS到PaaS，再到SaaS，层层递进。研发云的建设，往往也是遵循这个规律。在实践中，可能会有一些交集。通常都是分几期的。第一期为试点项目，第二期根据一期结果形成规范，标准，成为新开发应用的标准平台。第三期逐渐将老应用迁移到私有云上。
对于私有云实施：
私有云的容量需要根据公司业务来评估，以一般行业来说，都有web区，有app，有db。需要根据运行在私有云上的业务的多少，来统计所需要的资源的多少。例如，web区需要nginx，需要考虑HA和LB，那么就需要2台以上；如果多个业务共享nginx，那么就需要多个nginx集群来分担压力。
首先我们要了解监控的必要性，如果没有监控数据，运维侧无从谈起，没有数据，那么如何去度量一个指标呢？所以，在建设研发私有云尽量搭建一套适合的监控体系是必要的。而从监控分类来说，常见的是以下几种：
综上所述，我们可以通过下图来简单概况全栈监控这块的设计：
在实践中，大家经常问到的一个问题是我们公司应该选择一个还是多个k8s集群？
我们可以比较一下这两种选择：
选择后者典型的场景是：
采用以多个小集群的主要原因在于爆炸半径比较小，可以有效提升系统的可用性。同时通过集群也可以比较好地进行资源隔离。管理、运维复杂性的增加是采用多个小集群的一个不足之处。
值得一提的是源自GoogleBorg的理念，Kubernetes的愿景是成为DataCenterOperatingSystem，而且Kubernetes也提供了RBAC、namespace等管理能力，支持多用户共享一个集群，并实现资源限制。但是这些更多是“软多租”能力，不能实现不同租户之间的强隔离。在多租户最佳实践中，我们可以有如下的一些建议：
目前而言，Kubernetes对硬隔离的支持存在很多局限性，同时社区也在积极探索一些方向。
另一个需要考虑的方案是Kubernetes自身的可扩展性，我们知道一个Kubernetes集群的规模在保障稳定性的前提下受限于多个维度，一般而言Kubernetes集群小于5000节点。云厂商Kubernetes规模化上有丰富的经验，但是对于绝大多数公司而言，是无法解决超大集群的运维和定制化复杂性的。
另外值得一提的是可以利用Istio服务网格轻松实现对多个k8s集群的应用的统一路由管理。
k8s集群计算资源考量可以参考下表：
一般而言建议：
在压力引擎这块，目前还是倾向选择开源压测工具一哥：Jmeter。
目前常规Jmeter存在的问题：
Jmeter容器云带来的改变：
这里我们对默认的首页定制成了阿里云首页的风格：
可视化UI的方式一键创建云主机：
支持简单编辑云网络：
很容易的挂载云硬盘：
定制的操作系统可以轻松上传：
支持webVNC访问桌面：
傻瓜式的创建k8s集群，并支持集群扩展：
基于Kubernetes的容器编排和管理能力，整合DevOps工具链、微服务和应用框架，来帮助研发团队实现敏捷化的应用交付和自动化的运营管理：
基于Git的项目管理平台。提供网页版和客户端版接口，提供给用户空间存储git仓储，保存用户的一些数据文档或者代码等数据。一个开源的分布式版本控制系统，用于处理项目中的版本迭代问题：
提供微服务分布式追踪、服务网格遥测分析、度量聚合和可视化一体化解决方案：
提供了一组简单易用的特性集，快速实现动态服务发现和服务监控检查。
SpringBoot服务应用可以通过Actuator来暴露应用运行过程中的各项指标，SpringBootAdmin通过这些指标来监控SpringBoot应用，通过图形化界面呈现出来：
ELK即Elasticsearch、Logstash、Kibana，组合起来搭建日志聚合系统：
微服务聚合Swagger文档，支持在线接口调试：
动态配置服务可以让以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置：
提供maven私服和二进制制品仓库：
提供存储、管理和分发Docker镜像的企业级仓库：
代码质量分析平台，便于管理代码的质量，可检查出项目代码的漏洞和潜在的逻辑问题。同时提供了丰富的插件，支持多种语言的检测：