PaaS平台OpenShift企业部署的“脑图”


【编者的话】这篇文章是来自红帽,是关于OpenShift企业部署的“蓝图”,通过“脑图”帮助客户实现企业级部署OpenShift。

【烧脑式Kubernetes实战训练营】本次培训理论结合实践,主要包括:Kubernetes架构和资源调度原理、Kubernetes DNS与服务发现、基于Kubernetes和Jenkins的持续部署方案 、Kubernetes网络部署实践、监控、日志、Kubernetes与云原生应用、在CentOS中部署Kubernetes集群、Kubernetes中的容器设计模式、开发Kubernetes原生应用步骤介绍等。

如下是构建高分布式平台的大部分依赖:
  • 战略目标 (Strategy)
  • 存储计划(Storage)
  • 业务操作(Operation)
  • 业务连续性弹性与灾难恢复 (BCR&DR)
  • 应用开发 (AppDev)
  • 安全(Security)
  • 自动化(Automation)
  • 网络(Networking)
  • 提供(Provisioning)
  • 外部依赖 (External dependencies)


其中每类都包含多个子区域。下面我们将逐一说明。

即使你熟悉这个话题,你也会发现脑图的价值。

如果你想要更多,点击放大图片或查看https://github.com/mangirdaz/ocp-mindmap
appcoup-pod-150-150-768x1159.png

策略目标(Strategy)

开始采用新平台之前,你的策略应该是你想到的第一件事情。你需要知道谁将使用你建立的这个平台。利益相关者是谁,最后谁负责?确定利益相关者通常是构建策略的最简单的部分。建立实践社区(CoP)将有助于制定战略和方向。一个精心设计和维护的CoP可以帮助您利用自己组织力量推动实现“正确解决方案”的进程。封闭式解决方案往往会错过组织需求。考虑对CoP进行一些研究。

其次,你需要“微服务标准化”策略。在将服务放在新平台之前,强烈建议您定义一些标准。这里的挑战是旧的标准不适用于这个新的世界。尝试“复制 粘贴”,某些功能可能无法正常工作。

存储计划(Storage)

计划构建一个成功的平台,存储或持久性是关键考虑。你不仅需要简单的存储,而且需要可以高扩展的存储空间。你将需要为平台内部组件提供存储,如:日志、度量和容器镜像仓库。当然,你可以根据将要构建的解决方案选择不同的实现方式,如:对象存储、基于消息传递的日志服务,有时可能不需要考虑存储,但你无法完全消除对存储的需求。一旦我们开始说“持久性”,就意味着存储。开始思考如何做,谁将为你提供,以及你将拥有的存储空间(SSD,Magnetic,SAN,NAS等)。

业务操作(Operation)

操作部分与本文的下一节紧密相连。业务主要由以下两个领域组成:通常和无计划的行为(BCR&DR)。我们将在下一节中介绍无计划的行为。

通常业务操作包括出口(egress)路由器配置、平台维护、补丁、调度规则创建、平台管理以及对平台上发生的事件的主动反应等内容。所有这一切,你将需要一个非常好的日志和监视。没有日志和监控,你将会“失明”,在高分布式系统中变得盲目。

在分布式系统中,事情可能会从坏到更坏变得非常快,与“独立服务器”的基础架构相比,系统变得更糟糕。例如,如果出现故障,你的容器将重新调度(假设你没有自动伸缩功能,即使可以自动伸缩,你也可能花费巨大的费用)。在当前配置中重新调度=高密度,将意味着会遇到滚动失败情况。

因此,你需要为运营定义标准运行手册,创建仪表盘,确保你了解你的环境,这是运营中最重要的事情之一。

业务连续性弹性与灾难恢复(BCR&DR)

我将业务连续性和弹性(BCR)和灾难恢复(DR)从业务中分开,它是非常重要的。即使在提供生产流量之前,我建议你知道你的“失败域”,及如何失败恢复。你需要制定一个计划。例如:如果你在分布式、可靠的、键值存储集群(如:在OpenShift / Kubernetes的etcd)中丢失了仲裁,或者知道外部DNS或存储提供发生故障。同时,存在多种不同的场景,如:不同的环境有所不同,某些内部/外部依赖关系具有较少或更成熟的提供,这些都取决于你所在的组织。

应用开发(AppDev)

你也需要考虑开发者。一些组织忘记了平台将主要由开发人员使用。只有开发者才知道他们想要在一个平台上运行什么。尽管事实上你将有很多工具,但你可能希望对模式和蓝图进行标准化。你应该考虑如下:
  • 应用开发人员将如何监控应用程序和节点性能?
  • 他们将如何推广和部署?
  • CI / CD管道(现有和新的)将如何与平台集成。
  • 你将如何推广来自环境的镜像?
  • 如何进行配置推广?
  • 最后,开发人员将会使用哪些开发工具?


开发人员的经验非常重要。得到这个权利,你的平台将被使用。错了,没有人会想使用它。

自动化(Automation)

这个特定的领域与其他领域有许多关系。你将需要使用CI / CD工具自动化你的应用程序、进行镜像测试和推广等。此外,你的基础设施应该被视为与你的应用程序相同 - 自动化无处不在。为此,你可以使用配置管理工具或仅依赖于部署工具。但是,如果你从一开始就以自动化的思想开始构建,那么即使在开始时它看起来很慢,它会变得想要的更快。

网络(Networking)

你需要考虑如何访问应用程序、出口(egress)和入口(ingress)流量,以及如何配置负载平衡器。决定是否将运行 “主动-被动” 或 “主动-主动”,及如何负载均衡所有的堆栈。容器是“网络中的第一个公民”或依赖SDN抽象?如何处理DNS?是否需要相互SSL?你的集群在2 - 5年内有多大?一个节点上运行多少个容器?所有这些问题都将定义你的平台的网络设计。

安全(Security)

尽管平台构建要考虑是安全的,但你仍然会有很多公开的问题。例如,你如何管理你的私密凭据(密码,证书)以及如何更新它们?你将如何将你的应用程序暴露给外界?最后,最重要的是,如何验证你正在运行的镜像?运行多租户、基于微服务的应用程序,镜像扫描和生命周期是关键问题。

提供(Provisioning)

提供非常广泛,与你的组织中的如下有很高的联系:
  • 配置管理:使用哪一个配置管理,以及它如何与平台支持的工具一起使用?一旦你确定了所使用的配置管理后,需要选择使用什么工具?你是否需要什么额外的工具?你是否需要红帽的订阅和生命周期管理吗?是否需要CloudForms控制台、能力和主动管理?需要什么可视化提供商及其功能?
  • 基础设施本身:你是否使用容器化部署或基于包/ RPM?如何满足你组织的补丁策略?例如,如果你的组织是基于RPM的,你选择了基于容器化/OSTree的平台,你的运维工程师如何知道它们的生命周期?
    最后,你需要为平台做什么定制(预先及后期操作),使其符合你的需求?


外部依赖(External dependencies)

你会有很多外部依赖,请确保这些外部依赖的弹性和它们提供的SLA。外部依赖将包括如下:
  • 记录和监控:日志如何归档?集成哪些外部日志和监控解决方案?提供哪些元数据?
  • 存储:你将如何使用它?是否足够快?每秒输入/输出操作(IOPS)?如何扩缩?
  • 容器镜像仓库:如果你计划运行全局分布式集群,确定你的镜像的一致性?镜像仓库是否需要外部存储?如果是,什么格式?
  • 身份验证和授权:你将如何验证你的用户和应用程序?首选的身份验证提供商?如何进行基于角色的访问控制(RBAC)?
  • ITSM / CMDB:你需要在配置管理数据库中注册你的应用程序吗?如何自动化(或自动化解决方案?)。如何考虑变化?


架构

最后,一旦你知道你想去哪里(策略),你需要开始考虑更广泛的架构,例如基础设施密度、数据中心和可用性区域。已经覆盖的大部分领域与平台本身的架构有关。你需要在开始时做出正确的选择,因为分布式平台(OpenShift / Kubernetes等)构建和使用数百甚至数千个应用程序,难以修改。如果你网络错误,以后再进行更改是不可能的。如果平台不适应外部依赖关系与平台扩展的能力,将遇到瓶颈。

至此,我们介绍了这个旅程,你需要考虑什么。需要明白一点:公共云不能解决所有这些问题。这些可能看起来很难、不值得。但是,最终的结果就是全云不可知、水平和垂直可扩展的自助服务基础设施 ,这些将使开发人员开心。

原文出处:Enterprise OpenShift Deployment: What do you need to know?(翻译:范彬)

===============================================================
译者介绍:范彬,从事微服务、Docker和Kubernetes容器技术等方面的工作。可以关注译者的微信公众号:范范米饭。

0 个评论

要回复文章请先登录注册