容器化部署

大致来说，在部署应用程序的方式上，我们主要经历了三个发展阶段：

物理机部署：早期，企业直接将应用程序部署在物理机上。由于物理机上不能为应用程序定义资源使用边界，我们也就很难合理地分配计算资源。例如：如果多个应用程序运行在同一台物理机上，可能发生这样的情况：其中的一个应用程序消耗了大多数的计算资源，导致其他应用程序不能正常运行。应对此问题的一种解决办法是，将每一个应用程序运行在不同的物理机上。然而，这种做法无法大规模实施，因为资源利用率很低，且企业维护更多物理机的成本昂贵。

虚拟机部署：针对上述问题，虚拟化技术应运而生。用户可以在单台物理机上运行多个虚拟机（Virtual Machine）。

虚拟化技术使得应用程序被虚拟机相互分隔开，限制了应用程序之间的非法访问，进而提供了一定程度的安全性。

虚拟化技术提高了物理机的资源利用率，可以更容易地安装或更新应用程序，降低了硬件成本，因此可以更好地规模化实施。

每一个虚拟机可以认为是被虚拟化的物理机之上的一台完整的机器，其中运行了一台机器的所有组件，包括虚拟机自身的操作系统。

虚拟机虽然提高了资源利用率，但是仍然需要在虚拟机中维护从操作系统到上层应用的所有组件，导致灵活性仍然有所欠缺，另外虚拟机的镜像文件普遍较大，大规模部署虚拟机所需的时间还是较长。

容器化部署：容器与虚拟机类似，但是降低了隔离层级，共享了操作系统。因此，容器可以认为是轻量级的。

与虚拟机相似，每个容器拥有自己的文件系统、CPU、内存、进程空间等。

运行应用程序所需要的资源都被容器包装，并和底层基础架构解耦。

容器化的应用程序可以跨云服务商、跨Linux操作系统发行版进行部署。

容器化部署越来越流行，主要原因是它带来的诸多好处：

敏捷地创建和部署应用程序：相较于创建虚拟机镜像，创建容器镜像更加容易和快速

持续构建集成：可以更快更频繁地构建容器镜像、部署容器化的应用程序、并且轻松地回滚应用程序

分离开发和运维的关注点：在开发构建阶段就完成容器镜像的构建，构建好的镜像可以部署到多种基础设施上。这种做法将开发阶段需要关注的内容包含在如何构建容器镜像的过程中，将部署阶段需要关注的内容聚焦在如何提供基础设施以及如何使用容器镜像的过程中。降低了开发和运维的耦合度

可监控性：不仅可以查看操作系统级别的资源监控信息，还可以查看应用程序健康状态以及其他信号的监控信息

开发、测试、生产不同阶段的环境一致性：开发阶段在笔记本上运行的容器与测试、生产环境中运行的容器一致

跨云服务商、跨操作系统发行版的可移植性：容器可运行在 Ubuntu、RHEL、CoreOS、CentOS等不同的操作系统发行版上，可以运行在私有化部署、Google Kubernetes Engine、AWS、阿里云等不同的云供应商的环境中

以应用程序为中心的管理：虚拟机时代的考虑的问题是在虚拟硬件上运行一个操作系统，而容器化时代，问题的焦点则是在操作系统的逻辑资源上运行一个应用程序

松耦合、分布式、弹性、无约束的微服务：应用程序被切分成更小的、独立的微服务，并可以动态部署和管理，而不是一个部署在专属机器上的庞大的单片应用程序

资源隔离：确保应用程序性能不受干扰

资源利用：资源高效、高密度利用

Kubernetes 概述

Kubernetes 起源于Google，当时Google的一个工程师团队开发了一个名为 Borg 的集群管理系统。2014 年，Google推出了名为 Kubernetes 的 Borg 开源版本。

下图是Borg的架构

Kubernetes 的第一版于 2015 年发布，旨在为分布式应用程序提供容器编排。与此同时，Google与 Linux 基金会合作成立了“云原生计算基金会 CNCF”(Cloud Native Computing Foundation)，并提供了 Kubernetes 作为种子技术。

下图是 Kubernetes 架构

Kubernetes 可以帮助开发人员利用容器技术，实现跨系统的可移植性，自首次亮相以来，变得越来越受欢迎。

Kubernetes只是几种可用的容器编排平台之一，其他受欢迎的选项包括Docker Swarm和Mesos Marathon。但是随着近几年的发展，得益于Google强大的影响力和持续的投入，Kubernetes已经成了事实的标准容器编排平台。

Kubernetes 发行版

作为一个开源项目，Kubernetes的源代码可在GitHub上免费获得。任何人都可以使用此源代码在自己的基础设施上下载、编译和安装Kubernetes。但是大多数想要安装Kubernetes的用户却不会下载和编译源代码，其原因如下：

•省时省力：从头开始构建都将需要大量时间和精力。另外，无论何时需要更新安装，都必须重新构建所有内容。

•多个组件：Kubernetes不是单一应用程序，它是一套不同的应用程序和工具。如果从源代码安装，则必须在用于构建Kubernetes集群的所有服务器上分别安装所有这些组件。

•复杂的配置：由于Kubernetes没有安装向导或自动配置脚本，因此还必须人工配置Kubernetes的所有各种组件。

大多数用户采用Kubernetes发行版来满足他们的容器编排需求。Kubernetes发行版是一个软件包，提供了Kubernetes的预构建版本。大多数的Kubernetes发行版还提供安装工具，以简化安装过程。有些发行版还带有其他软件集成，以帮助处理诸如监视和安全性之类的任务。从这个意义上来说，可以认为Kubernetes发行版类似于Linux发行版。当大多数用户想要在个人电脑或服务器上安装Linux时，他们使用的发行版提供了与各种其他软件包集成在一起的预构建Linux内核。因此几乎没有人下载全部的Linux源代码。

从技术上来说，任何包含Kubernetes预先构建版本的软件包或平台都可以算作Kubernetes发行版。就像任何人都可以构建自己的Linux发行版一样，任何人都可以创建Kubernetes发行版。

但是，如果用户希望使用Kubernetes发行版来完成重要的工作，目前主要有以下几个选项：

•OpenShift：OpenShift是一个容器化平台，其中包括Kubernetes以及运行、部署和管理容器所需的各种其他工具。OpenShift几乎附带了所有需要的东西。用户将获得接近全包的Kubernetes。OpenShift由Red Hat公司开发，可以在内部部署数据中心和云平台中运行。

•Rancher：Rancher的容器平台现在基于Kubernetes。Rancher公司的Kubernetes发行版特别着重于多集群Kubernetes部署，如果用户想跨多个云平台部署Kubernetes或出于某些其他原因不想使用命名空间，这可能会很有用(Kubernetes功能可让用户划分单个集群服务器划分为虚拟区域)。Rancher可以在内部部署数据中心、云平台中甚至跨基础设施(包括两者)进行工作。

除了在内部部署，几乎所有的公有云服务商都提供了运行在公有云上的容器平台服务，例如：

•Google Kubernetes引擎：当其他云计算供应商专注于他们自己的编排工具时，谷歌云押注Kubernetes(这并不奇怪，因为从项目开始，谷歌公司就是Kubernetes的主要支持者)。如今，Google Kubernetes Engine是一种灵活、简单的Kubernetes发行版。

•Azure Kubernetes服务：微软Azure曾经将赌注押在Docker Swarm上，但Azure Kubernetes服务(AKS)现在是Azure云平台中的主要编排解决方案。这是只能在云中运行的Kubernetes发行版。

•AWS Elastic Kubernetes服务：尽管AWS云平台上的Elastic Container Service(ECS)具有自己的编排器，但AWS公司还提供Elastic Kubernetes Services(EKS)，它是围绕Kubernetes构建的替代方案。像Azure Kubernetes Services(AKS)一样，Elastic Kubernetes Services(EKS)只能在云中运行。

OpenShift 4 架构

OpenShift是由RedHat公司推出的企业级容器云PaaS平台，2015年，RedHat推出完全重构后基于Docker和Kubernetes的OpenShift 3.0，完善了强大的用户界面，以及诸如源代码到镜像(S2I-source to image)和构建管道等OpenShift独有组件，极大简化了云原生应用的构建部署和DevOps理念文化的落地实践。2019年，RedHat推出了OpenShift 4，集成了CoreOS、Istio、Knative、Kubernetes Operator等技术，将OpenShift推向了全栈融合云和应用全生命周期自动化管理时代。可见，作为当今最为成熟和主流的容器云PaaS平台，OpenShift的架构也一直在演进。

从技术堆栈的角度分析，OpenShift自下而上包含了以下几个层次：

基础架构层：提供计算、网络、存储、安全等基础设施，支持在物理机、虚拟化、私有云和公有云等环境上部署OpenShift。

容器引擎层：采用Docker镜像为应用打包方式，采用Docker作为容器运行时，负责容器的创建和管理。Docker利用各种Linux内核资源，为每个Docker容器中的应用提供一个隔离的运行环境。

容器编排和集群管理层：为部署高可用、可扩展的应用，容器云平台需要具有跨多台服务器部署应用容器的能力。OpenShift采用Kubernetes作为其容器编排引擎，同时负责管理集群。事实上，Kubernetes正是OpenShift的内核。

PaaS服务层：OpenShift在PaaS服务层提供了丰富的开发语言、开发框架、数据库、中间件及应用支持，支持构建自动化（Build Automation）、部署自动化（Deployment Automation）、应用生命周期管理（Application Lifecycle Management，CI/CD）、服务目录（Service Catalog，包括各种语言运行时、中间件、数据库等）、内置镜像仓库等，以构建一个以应用为中心的、更加高效的容器平台。

界面及工具层：向用户提供Web Console、API及命令行工具等，以便于用户使用OpenShift容器云平台。

在 OpenShift Container Platform 4.3 中，所有控制平面（control plane） 都需要使用 RHCOS。Red Hat Enterprise Linux CoreOS (RHCOS) 是一款面向容器的操作系统，类似的包括 Alpine , Photon OS。RHCOS 结合了 CoreOS 和 Red Hat Atomic Host 操作系统的一些最佳特性和功能。RHCOS 是专门为从 OpenShift Container Platform 运行容器化应用程序而设计的，能够与新工具配合，提供快速安装、基于 Operator 的管理和简化的升级。RHCOS 包括 Ignition，OpenShift Container Platform 将 Ignition用作首次启动系统配置来进行机器的初次上线和配置。

另外，OpenShift 4 使用 CRI-O 作为运行、停止和重启容器的工具。它完全取代了 OpenShift Container Platform 3 中使用的 Docker Container Engine。

下图是 OpenShift 4 的架构：

OpenShift 4 on K1 power 部署方式

OpenShift 4 在 K1 Power上的部署方式根据是否使用虚拟化和虚拟化技术不同主要有下面几种：

裸机

裸机部署应该是最简单的，最直接的部署方式。这种部署方式时，K1 Power最显而易见的一个优势就是超多的逻辑核，以一款产品 S922 为例，可以提供多达192个逻辑核，很显然可以支撑更高的容器密度。

基于PowerVM虚拟化

使用PowerVC来创建和管理逻辑分区（LPAR Logical PARtition 可以简单理解为虚机的对应概念），将 OpenShift 4 部署在这些LPAR 上。这种部署方式，K1 Power 又增加了一个优势是LPAR分区资源的动态分配，可以简单的认为这些LPAR的CPU ，内存资源是集中在一个资源池中的，LPAR真正使用的资源是根据LPAR本身的工作负载来决定的，假设某一个LPAR中由于工作负载增加，需要多启动N个容器，此时它也可以从CPU，内存资源池中获取到更多资源，这无疑会降低容器因为资源不足而启动失败的概率。

基于KVM虚拟化

可以将 OpenShift 4 部署在 KVM 虚拟机上。这种部署方式，K1 Power的优势只是由裸机部署时的更高的容器密度，变成更高的虚拟机密度，同样以S922 为例，如果虚拟机的配置是 4C / 8G 的配置，一台 S922 可以提供 192/4 = 48 个虚拟机。

OpenShift 4 on K1 power 推荐场景和优势

DBaaS 数据库即服务平台

K1 Power平台是运行各种数据库的最佳平台，以高可靠性，高性能著称，虽然新兴的分布式数据库一直强调对硬件平台可靠性的要求降低，但是毫无疑问，使用高可靠的硬件平台仍然可以带来很多益处，省心，省事。OpenShift 4 提供多种主流的开源数据库供客户选择，例如 MongoDB ,PostgreSQL, MariaDB, Redis等。利用 OpenShift 4 + K1 Power，可以很方便的搭建一个高可用，高性能，高伸缩性的数据库层服务，无论是将其部署在私有环境，还是放在公有云环境中。

下一步的发展，K1 Power将联合更多的国产数据库厂商，在 OpenShift 4 上提供更多的数据库选择。

纯Java应用

Java 语言以良好的跨平台特性，得到越来越广泛的应用，尤其以 WebSphere, WebLogic，TongWeb 为代表的商业Java中间件，以 JBoss, Tomcat ,Apache为代表的开源Java中间件，以 Spring 为代表的主流微服务开发框架，以 Hadoop，Spark为代表的大数据应用都得到了大量的使用。Java语言本身以多线程为其核心特色，这与Power芯片的SMT技术达到很好的匹配，大量的实际测试都表明了，Java应用运行在Power平台都有明显的性价比优势。利用 OpenShift + K1 Power 可以为此类应用提供一个支持高并发，低延迟，高弹性的Java应用平台。

分布式存储

OpenShift 4 的底层存储目前可以使用本地盘，也可以使用类似 Spectrum Scale 这样的软件定义存储软件，将来还会支持例如Ceph 这样的开源软件定义存储软件。大量的测试表明， K1 Power 结合主流软件定义存储软件，可以为容器平台提供一个高吞吐， 高IOPS，低延迟的存储层，尤其在镜像仓库这样的关键之处，得益于 K1 Power 的高并发支持能力，能够更好的支撑大量的容器镜像Pull/Push 操作。

互联网应用

最早以LAMP (Linux Apache MySQL PHP) 技术栈为代表的互联网应用，经过近三十年的发展，虽然各种新技术的应用使得整个基础架构越来越复杂，但是大的逻辑架构仍然没有逃脱 接入-》应用-》数据库-》存储 经典架构。

对于小型互联网应用来说，目前小型互联网应用仍然大量使用LAMP技术栈开发， 利用OpenShift 4， 因为 OpenShift 4 本身已经提供了LAMP技术栈，开发人员完全可以基于OpenShift 4进行云原生开发， 再结合K1 Power服务器的性能优势，最终将一个小型互联网应用架设到几台Power服务器上，理论上可以是 OpenShift 4 的最小集群规模，部署时可以用裸机，也可以使用PowerVM，KVM虚拟化。

对于大型互联网应用，可以按照架构层次，接入和应用使用虚拟化，数据库层使用裸机或者虚拟化，独立为几个OpenShift 4 集群，或者通过 OpenShift 4 的域与namespace 进行隔离。

一言概括之，OpenShift 4 与 K1 Power 可谓强强联手，如何用对地方，发挥最大效益才是我们应该思考的问题，希望本文的一些建议能够抛砖引玉一下，更多应用场景只能是实践出真知了。