container injection——容器技术

(一)容器技术为什么出现

  在很久很久以前,想要在线上服务器部署一个应用,首先需要购买一个物理服务器,在服务器安装一个操作系统,然后安装好应用所需要的各种依赖环境,最后才可以进行应用的部署,而且一台服务器只能部署一个应用。

这就造成了以下几个明显问题:

  • 部署应用非常慢
  • 需要花费的成本非常高
  • 而且容易造成资源的浪费,因为往往一个应用使用不了一个服务器的资源
  • 难于迁移和扩展
    • 迁移问题:要把应用进行迁移,又得重复部署应用的过程:买服务器 -> 安装os -> 配置环境 -> 部署应用
    • 扩展问题:只能购买新的硬件来升级物理服务器,或者购买更高性能的服务器,这就又涉及到迁移问题了
  • 可能会被限定硬件厂商,因为那时候有不同硬件平台

虚拟化技术出现以后,对于这种问题有所改变,虚拟化技术会在本地操作系统之上加多一层 Hypervisor层,Hypervisor是一种运行在物理服务器和操作系统之间的中间软件层,可以虚拟化硬件资源,例如cpu、硬盘、内存资源等。然后我们可以基于通过虚拟化出来的资源之上安装操作系统,这也就是所谓的虚拟机。

通过Hypervisor层,我们可以创建不同的虚拟机,并且可以限定每个虚拟机的物理资源,并且每个虚拟机都是分离、独立的。例如A虚拟机给它使用2个cpu、8g内存、100g磁盘,B虚拟机给它使用4个cpu、16g内存、300g磁盘。。。等等,这样就可以实现物理资源利用率的最大化。

如此一来:

  一台物理机就可以部署多个应用

  每个应用都可以独立运行在一个虚拟机里

虚拟化技术的优点:

  资源池——一个物理机的资源分配到了不同的虚拟机里

  很容易扩展——增加物理机或者虚拟机即可,因为虚拟机是可以复制的

  很容易云化——亚马孙AWS,阿里云,谷歌云等

即然虚拟化技术已经很强大了,为什么还需要容器技术呢?这就涉及到虚拟化技术所带来的局限性了:

每一个虚拟机都是一个完整的操作系统,所以需要给其分配物理资源,当虚拟机数量增多时,操作系统本身消耗的资源势必增多以上所提到的这个问题还不是真正促使容器技术出现的根本原因,真正使容器技术出现的是开发和运维所面临的挑战:开发与运维的环境都比较复杂,而且开发还分前后端以及测试等,运维环境则是基于服务器、交换机或者在云上的(这不是废话吗),这就导致了开发环境和线上环境的差异。所以开发环境与运维环境之间无法达到很好的桥接,在部署上线应用时,依旧需要花时间去处理环境不兼容的问题。而容器技术正是解决了这种环境不一致的问题:容器可以帮我们把开发环境及应用整个打包带走,打包好的容器可以在任何的环境下运行,这样就可以解决开发与运维环境不一致的问题了,所以:容器解决了开发和运维之间的矛盾在开发和运维之间搭建了一个桥梁,是实现devops的最佳解决方案以上只是描述是容器解决了什么问题,但是还没有说明什么是容器,不过其实简单几句话就可以说明容器了:

  对软件和其依赖环境的标准化打包

  应用之间相互隔离共享一个OS Kernel

  可以运行在很多主流操作系统上

以上转自https://blog.51cto.com/zero01/2074284

(二)容器技术未来发展趋势

  云计算技术发展至今,从最开始的硬件虚拟化、IaaS、OpenStack、PaaS、容器设置到如今的 Serverless,云计算已经越来约接近应用逻辑。容器实现了应用的分装,方便了应用在不同环境间的迁移,轻量级的特性又使它能够消耗更少的资源而带来更大的便利,容器编排领域在2016 年就已经成为了兵家必争之地。2016 年的时候容器领域还在为Swarm、Mesos、Kubernetes谁能够在容器编排调度大战中胜出而猜测。经过不到一年的发展,Kubernetes 就以超过 70% 的市场占有率(据TheNewStack的调研报告)将另外两者遥遥甩在身后。Kubernetes 已经成为容器编排调度的实际标准,不论 Docker 官方还是 Mesos 都已经支持了 Kubernetes,Docker 公司在今年 10 月 16 日至 19 日举办的 DockerCon EU 2017 大会上宣布支持 Kubernetes 调度,Mesos 的商业化公司 Mesosphere 也宣布 Kubernetes on DC/OS。

Kubernetes 产品迭代周期越来越快,从 2014 年开源,2015 年发布了两个版本,2016 年发布了三个版本,到2017一年内就发布了 4 个大版本,Kubernetes越来越受到关注,同时它也变得越来越稳定、易用。Kubernetes 已成为 GitHub 上参与和讨论人数最多的开源项目,在其官方 Slack 上有超过三万多名注册用户,国内外还有很多厂商、社区、爱好者组织的 meetup。

国外 Google 的 GKE、微软的 Azure ACS、AWS 的 Fargate 和 2018 年即将推出的 EKS、Rancher 联合 Ubuntu 推出的 RKE,国内的华为云、腾讯云、阿里云等都已推出了公有云上的 Kubernetes 服务,Kubernetes 已经成为公有云的容器部署的标配,私有云领域也有众多厂商在做基于 Kubernetes 的 PaaS 平台。随着企业落地 Kubernetes 的日益增长,相关的人才缺口也将显现。CNCF 又就此推出了 CKA(Certified Kubernetes Administrator)和 CKD(Certified Kubernetes Developer),假若在 Kubernetes 的生态构建与市场发展顺利的情况下,该证书将会展现其含金量。

同时,Cloud Native也是蓬勃发展和大发异彩,CNCF 中托管的一系列项目即致力于云原生应用整个生命周期的管理,从部署平台、日志收集、Service Mesh(服务网格)、服务发现、分布式追踪、监控以及安全等各个领域通过开源软件为我们提供一整套解决方案。Kubernetes 作为云应用的部署标准,直接面向业务应用,大大提高了云应用的可移植性,解决云厂商锁定的问题,让云应用可以在夸云之间无缝迁移,甚至用来管理混合云,成为企业 IT 云平台的新标准。

2018 年 Kubernetes 将结合 CI/CD 成为 DevOps 的得力工具,并成为高级开发人员的应用部署首选,也将成为 PaaS 层的重要组成部分。Kubernetes 将更加稳定好用,云原生将会出现更多的落地与最佳实践。

以上转自https://blog.csdn.net/Z4a9Gx/article/details/80972222

上一篇:如何组织较大项目的MVC文件夹结构


下一篇:Ubuntu18.04应用程序安装集锦