这是关于即将发布的红帽 OpenShift 平台 4.0 更新中的更改、改进和添加的系列文章中的第一篇，该更新将帮助您为过渡到新版本做好准备。
从 2014 年秋天刚刚起步的 Kubernetes 社区首次聚集在 Google 西雅图办事处的那一刻起，很明显 Kubernetes 项目注定要彻底改变当今软件开发和部署的方式。 与此同时，公有云服务提供商继续积极投资基础设施和服务的开发，这使得与IT合作和创建软件变得更加容易和容易，并且变得非常容易访问，这是在年初很少有人能够想象到的。十年。
当然，每一项新的云服务的发布都会伴随着 Twitter 上专家们的大量讨论，争论的主题多种多样——包括开源时代的结束、本地 IT 的衰落以及其必然性。云中的新软件垄断，以及新范式 X 将如何取代所有其他范式。
不用说，所有这些争论都是非常愚蠢的
现实是，什么都不会消失，今天，由于我们生活中新软件的不断出现，我们可以看到最终产品及其开发方式呈指数级增长。 尽管事实上周围的一切都会改变，但同时，本质上，一切都将保持不变。 软件开发人员仍然会编写有错误的代码，运营工程师和可靠性专家仍然会拿着寻呼机四处走动并在 Slack 中接收自动警报，管理人员仍然会根据运营支出和资本支出进行操作，每次发生故障时，高级开发人员都会悲伤地叹了口气：“我告诉过你了”......
哦真的吗 应该讨论，是我们可以使用哪些工具来创建更好的软件产品，以及它们如何提高安全性并使开发更容易、更可靠。 随着项目复杂性的增加，新的风险也随之增加，而当今人们的生活如此依赖于软件，开发人员必须努力做得更好。
Kubernetes 就是这样的工具之一。 目前正在努力将红帽 OpenShift 与其他工具和服务整合到一个平台中，从而使软件对用户来说更可靠、更易于管理、更安全。
话虽如此，OpenShift 团队提出了一个简单的问题：
如何让 Kubernetes 的使用变得更轻松、更方便？
答案出人意料地明显：
- 自动化云上或云外部署的复杂方面；
- 注重可靠性，同时隐藏复杂性；
- 继续不断努力发布简单且安全的更新；
- 实现可控性和可审计性；
- 力求最初确保高安全性，但不以牺牲可用性为代价。
OpenShift 的下一个版本应该考虑到创建者的经验以及在世界上最大的公司大规模实施软件的其他开发人员的经验。 此外，它还必须考虑到构成当今现代世界基础的开放生态系统所积累的所有经验。 同时，有必要放弃业余开发者的旧心态，转向自动化未来的新理念。 它需要弥合新旧软件部署方式之间的差距，并充分利用所有可用的基础设施——无论是由最大的云提供商托管还是在边缘的微型系统上运行。
如何达到这个结果呢？
在红帽，为了维护已建立的社区并防止公司参与的项目被关闭，人们习惯于长期从事无聊且吃力不讨好的工作。 开源社区包含大量才华横溢的开发人员，他们创造了最非凡的事物 - 娱乐性、教育性、开辟新机会和简单美丽，但是，当然，没有人期望每个人都朝着同一个方向前进或追求共同的目标。 有时有必要利用这种能量并将其引导到正确的方向，以开发有利于我们用户的领域，但同时我们必须监控社区的发展并向他们学习。
2018 年初，红帽收购了 CoreOS 项目，该项目对未来有着类似的看法——更安全、更可靠，基于开源原则创建。 公司一直致力于进一步发展这些想法并实施它们，将我们的理念付诸实践——努力确保所有软件安全运行。 所有这些工作都建立在 Kubernetes、Linux、公共云、私有云以及支撑我们现代数字生态系统的数千个其他项目的基础上。
新版本的 OpenShift 4 将更加清晰、自动化、更加自然
OpenShift 平台将与最好、最可靠的 Linux 操作系统配合使用，具有裸机硬件支持、方便的虚拟化、自动基础设施编程，当然还有容器（本质上只是 Linux 映像）。
该平台必须从一开始就是安全的，但仍允许开发人员轻松迭代，即足够灵活和安全，同时仍允许管理员轻松审核和管理它。
它应该允许软件“作为服务”运行，并且不会导致运营商无法管理的基础设施增长。
它将允许开发人员专注于为用户和客户创建真正的产品。 您无需费力地穿过硬件和软件设置的丛林，所有意外的并发症都将成为过去。
OpenShift 4：无需维护的 NoOps 平台
В 描述了那些有助于塑造公司 OpenShift 4 愿景的任务。该团队的目标是尽可能简化操作和维护软件的日常任务，使这些流程变得简单轻松——无论是对于参与实施的专家还是开发人员来说。 但怎样才能更接近这个目标呢？ 如何创建一个需要最少干预的运行软件的平台？ 在这种情况下，NoOps 到底意味着什么？
如果您尝试抽象，那么对于开发人员来说，“无服务器”或“NoOps”的概念意味着允许您隐藏“操作”组件或最大限度地减少开发人员负担的工具和服务。
- 不是使用系统，而是使用应用程序接口 (API)。
- 不必费心实施软件——让提供商为您做。
- 您不应该立即开始创建一个大型框架 - 首先编写充当“构建块”的小块，尝试使该代码与数据和事件一起工作，而不是与磁盘和数据库一起工作。
与以前一样，目标是加快软件开发的迭代速度，提供创建更好产品的机会，以便开发人员不必担心其软件运行的系统。 经验丰富的开发人员都清楚，关注用户可以快速改变现状，因此除非您完全确定需要它，否则您不应该在编写软件上投入太多精力。
对于维护和运营专业人员来说，“NoOps”这个词听起来可能有点可怕。 但在与现场工程师沟通时，很明显他们使用的旨在确保可靠性和可靠性的模式和技术（站点可靠性工程，SRE）与上述模式有许多相似之处：
- 不要管理系统——自动化他们的管理流程。
- 不要实施软件 - 创建一个管道来部署它。
- 避免将所有服务捆绑在一起，并让其中一个服务出现故障而导致整个系统出现故障——使用自动化工具将它们分散到整个基础设施中，并以可监控的方式将它们连接起来。
SRE 知道某些事情可能会出错，他们必须追踪并解决问题，因此他们会自动化日常工作并提前设置错误预算，以便他们准备好在问题出现时确定优先级并做出决策。
OpenShift 中的 Kubernetes 是一个旨在解决两个主要问题的平台：它不强迫您了解虚拟机或负载均衡器 API，而是与更高阶的抽象（部署流程和服务）配合使用。 您可以运行容器，而不是安装软件代理，也不必编写自己的监控堆栈，而是使用平台中已有的工具。 因此，OpenShift 4 的秘诀实际上并不是什么秘密 - 只需采用 SRE 原则和无服务器概念，并得出符合逻辑的结论，以帮助开发人员和运维工程师：
- 自动化和标准化应用程序使用的基础设施
- 将部署和开发流程链接在一起，而不限制开发人员本身
- 确保启动、审核和保护第 XNUMX 个服务、功能、应用程序或整个堆栈并不比第一个困难。
但 OpenShift 4 平台与其前身以及解决此类问题的“标准”方法有何区别？ 是什么推动了实施和运营团队的规模化？ 因为在这种情况下，王者就是集群。 所以，
- 我们确保集群的目的明确（亲爱的云，我选择了这个集群，因为我可以）
- 机器和操作系统的存在是为了服务集群（陛下）
- 管理集群中主机的状态，最大限度地减少它们的重建（漂移）。
- 对于系统的每个重要元素，都需要一个保姆（机制）来监控和消除问题
- 系统的“每个”方面或元素以及相关的恢复机制出现故障是生活中正常的一部分
- 整个基础设施必须通过 API 进行配置。
- 使用 Kubernetes 来运行 Kubernetes。 （是的，是的，这不是错字）
- 更新的安装应该简单、无忧。 如果需要多次点击才能安装更新，那么显然我们做错了什么。
- 监视和调试任何组件都不应该成为问题，因此整个基础设施的跟踪和报告也应该简单方便。
想要了解该平台的实际功能吗？
OpenShift 4 的预览版已向开发人员开放。 通过易于使用的安装程序，您可以在 Red Had CoreOS 之上的 AWS 上运行集群。 要使用预览版，您只需要一个 AWS 账户来配置基础设施和一组账户来访问预览映像。
- 要开始使用，请访问 并单击“开始”。
- 登录您的 Red Hat 帐户（或创建一个新帐户）并按照说明设置您的第一个集群。
安装成功后，查看我们的教程 更深入地了解使 OpenShift 4 平台成为运行 Kubernetes 的简单便捷方式的系统和概念。
尝试新的 OpenShift 版本并分享您的意见。 我们致力于让与 Kumbernetes 的合作尽可能轻松便捷——NoOps 的未来从今天开始。
而现在关注！
在会议上 20 月 37 日，OpenShift 开发人员之一 Vadim Rutkovsky 将举办大师班 - 他将破坏 XNUMX 个集群并迫使他们修复它们。 会议已付费，但使用促销代码 #RedHat 可享受 XNUMX% 的折扣
大师班时间为17:15-18:15，展位全天开放。 T 恤、帽子、贴纸——常见的！
2号厅
“这里整个系统需要改变：我们与经过认证的机械师一起修复损坏的 k8s 集群。”
来源： habr.com