Docker和Kubernetes的技术架构.docx

Docker和Kubernetes的技术架构.docx

《Docker和Kubernetes的技术架构.docx》由会员分享，可在线阅读，更多相关《Docker和Kubernetes的技术架构.docx（18页珍藏版）》请在冰豆网上搜索。

Docker和Kubernetes的技术架构

Docker和Kubernetes的技术架构

前言

在Docker和Kubernetes时代，软件开发的世界发生了怎样的变化？

有可能使用这些技术一劳永逸地构建一个放之四海而皆准的架构吗？

当所有东西都“打包”在容器中时，有可能统一开发和集成的过程吗？

这些决策有什么要求？

它们会带来什么限制？

它们会让开发人员的生活变得更轻松，还是会增加不必要的复杂性？

是时候讨论和阐明这些（以及其它一些）问题了！

本文将带您踏上从现实到开发过程到架构再回到现实的旅程，在沿途的每一站回答最重要的问题。

我们将尝试确定一些应该成为体系架构一部分的组件和原则，并在不过多深入实现细节的情况下展示一些示例。

这篇文章的结论可能会让你不高兴或高兴。

这完全取决于你的个人经验，你对这个分为三章的故事的看法，甚至可能取决于你阅读时的心情。

请在文末发表评论或提出问题，让我知道你的想法！

一、从现实到开发流程

在很大程度上，我所见过或有幸参与建立的所有开发过程都服务于一个简单的目标 

— 降低将一个想法变成现实、并交付生产的时间，同时保持一定程度的代码质量。

这个想法是好是坏并不重要。

坏主意来来去去，你可能只是尝试一下，然后拒绝它们，让它们自生自灭。

值得一提的是，从一个坏主意中回退（rollingback）的责任落在将你的开发流程自动化的机器人肩上。

持续集成和交付（CI/CD）似乎是软件开发世界中的一根救命稻草。

毕竟，还有什么比这更简单的呢？

你有想法，你有代码，所以去做吧！

如果不是存在一个小问题的话，这将会是完美无缺的—如果与贵公司特有的技术和业务流程相分离，集成和交付流程将很难正规化。

然而，尽管这个任务看起来很复杂，生活还是在不断引入优秀的想法，让我们（当然是我自己）更接近于建立一个几乎在任何场合都有用的完美机制。

对我来说，实现这种机制的最近一步是Docker和Kubernetes，它们的抽象层次和意识形态方法让我认为现有问题中的80%都可以通过几乎相同的方法来解决。

剩下的20%我们也无法忽视。

但是这正是你可以把你内在的创造性天才集中于其上的有趣的工作，而不是用于处理重复性的日常任务。

专注于“架构框架”（architecturalframework）可以让你忘记那80%已经解决掉的问题。

所有这些意味着什么，Docker是如何解决开发流程中的问题的？

让我们来看一个简单的流程，这对于大多数工作环境来说也是足够的：

通过适当的方法，你可以自动化和统一以下序列中的所有内容，并在未来几个月内忘掉它。

建立开发环境

一个项目应该包含一个docker-compose.yml文件，这样你就不用考虑在本地机器上运行应用程序/服务需要做什么和怎么做了。

一个简单的docker-composeup命令就能启动你的应用程序及其所有依赖项，用预制数据填充数据库，上传本地代码到容器内，启用代码跟踪以便动态编译，并最终在预期的端口开始接收和响应请求。

即使是在设置新服务时，你也不必担心如何启动、向哪里提交代码更改或使用哪些框架。

所有这些都应该在标准说明中预先描述，并由不同配置的服务模板决定:

frontend,backend和worker。

自动化测试

关于“黑盒”你只需要知道，所有该有的东西都已经打包到里面了。

是或否，1或0。

更多关于我为什么将容器称为黑盒的信息，将在本文的后面介绍。

有了有限数量的可以在容器内执行的命令，以及描述其所有依赖关系的docker-compose.yml，你就可以轻松地自动化和统一测试工作，而无需过多关注实现细节。

例如，像下面这样！

在这里，测试不仅意味着单元测试，还意味着功能测试、集成测试、检查代码风格和重复代码、检查过时的依赖关系、可能使用违反许可证（license）的软件包以及许多其他事情。

关键是所有这些都应该封装在你的Docker镜像中。

系统交付

你想在何时何地安装项目并不重要。

结果，就像安装过程一样，应该总是相同的。

至于你将安装整个生态系统中的哪个部分，或者从哪个git代码库中获取代码，也没有任何区别。

这里最重要的组成部分是幂等性（idempotence）。

唯一应该指定的是控制安装的变量。

以下是在我看来解决这个问题非常有效的算法：

1.从你所有的Dockerfile中收集镜像（例如，像这样）

2.使用一个元项目，通过KubeAPI接口将这些镜像传递给Kubernetes。

启动交付过程通常需要如下几个输入参数：

•KubeAPI的访问入口（endpoint）

•一个Secret对象，因不同的上下文而异（local/showroom/staging/production）

•要显示的系统的名称和这些系统的Docker镜像的标签（在前面的步骤中获得）

作为一个包含所有系统和服务的元项目的例子（换句话说，一个描述生态系统是如何安排的以及更新是如何传递给它的项目），我更喜欢使用Ansible playbooks与这个模块 同KubeAPI进行集成。

然而，复杂的自动机（automators）可以引用其他选项，我将在后面详述我自己的选择。

但是，您必须考虑一种集中/统一的架构管理方法。

拥有一个这样的方法可以让你方便和统一地管理所有服务/系统，中和即将到来的执行类似功能的技术和系统丛林可能带给你的任何复杂性。

通常，在以下情况下需要安装环境：

•ShowRoom—测试环境， 对系统进行了一些手动检查或调试

•Staging — 准生产环境，和外部系统的集成（通常位于DMZ非军事区，而不是ShowRoom）

•Production —生产环境，供最终用户使用的实际环境

集成和交付的连续性

如果你有一个统一的测试方法对Docker镜像（或“黑盒”）进行测试，你就可以假设这样的测试结果将允许你无缝地（并且问心无愧地）将特性分支（feature-branch）集成到git存储库的上游（upstream）或主分支（master）中。

或许，这里唯一的障碍是集成和交付的顺序。

当没有发布时，你如何在一个拥有一组并行功能分支（feature-branches）的系统上防止“竞争条件”的发生？

因此，只有在没有竞争的情况下，这个过程才应该开始，否则“竞争条件”会一直萦绕在你的脑海中：

1.尝试将功能分支（feature-branch）更新到上游分支（upstream）（gitrebase/merge）

2.使用Dockerfile构建镜像

3.测试所有构建好的镜像

4.启动并等待，直到使用第2步中构建的镜像的系统成功完成部署

5.如果前一步失败，将生态系统回滚到之前的状态

6.将功能分支（feature-branch）合并进上游分支（upstream），并将其提交到代码库

任何步骤中发生的任何失败都应该终止交付过程，并将任务返回给开发人员来修复错误，不管是测试失败还是代码合并冲突。

你可以使用此流程来在多个代码库上工作。

只需一次对所有代码库执行每个步骤（在A库和B库上执行步骤1，在A库和B库上执行步骤2，如此类推），而不是在每个单独的代码库上重复执行整个过程（在A库上执行步骤1-6，在B库上执行步骤1-6，如此类推）。

此外，Kubernetes还允许你进行部分更新，以便执行各种A/B测试和风险分析。

Kubernetes在内部通过分离服务（访问点）和应用程序来实现这一点。

你总是可以按期望的比例平衡组件的新版本和旧版本，以便于问题分析并为潜在的回滚提供可能。

回滚系统

架构框架的强制性要求之一是回滚任何部署过程的能力。

这反过来又会带来一些显而易见和隐含的细微差别。

以下是其中一些最重要的：

•服务应该能够设置其环境以及回滚更改。

例如，数据库迁移、RabbitMQ的schema等等。

•如果无法回滚环境，那么服务应该是多态的（polymorphic），并且支持旧版本和新版本的代码同时共存部署。

例如：

数据库迁移不应该导致旧版本服务的中断（通常是之前的2到3个旧版本）。

•任何服务更新的向后兼容性。

通常，这是应用编程接口API的兼容性、消息格式等等。

在Kubernes集群中的回滚状态非常简单（运行kubectlrolloutundodeployment/some-deployment，Kubernes将恢复到以前的“快照”（snapshot）），但是为了有效地做到这一点，你的元项目应该包含关于该快照的信息。

非常不鼓励使用更复杂的交付回滚算法，尽管它们有时是必要的。

以下是触发回滚机制的因素：

•发布后应用程序发生错误的百分比很高

•来自关键监控点的信号

•冒烟测试（smoke tests）失败

•手工模式— 人为因素

确保信息安全和审计

没有一个工作流可以神奇地“构建”防弹车级别的安全并保护你的生态系统免受外部和内部威胁，因此你需要确保你的架构框架在执行时着眼于公司在每个级别和所有子系统中的标准和安全策略。

稍后，我将在关于监控和告警的章节中讨论建议的所有三个级别解决方案，它们对系统完整性也至关重要。

Kubernetes有一套良好的内置访问控制机制、网络策略、事件审计和其它与信息安全相关的强大工具，可用于构建出色的周界保护（perimeterofprotection），抵御和防止攻击以及数据泄漏。

二、从开发工作流到架构

应该认真对待在开发流程和生态系统之间建立紧密集成的尝试。

将这种集成的需求添加到传统架构需求集（灵活性、可伸缩性、可用性、可靠性、防威胁等）中，可以极大地增加架构框架的价值。

这是非常关键的一个方面，它导致了DevOps（DevelopmentOperation）这个概念的出现。

DevOps是实现基础设施完全自动化和优化的一个合乎逻辑的步骤。

然而，一个设计良好的架构架构和可靠的子系统，可以让DevOps任务最小化。

微服务架构（Micro-servicearchitecture）

没有必要赘述面向服务的架构（SOA）的好处，包括为什么服务应该是“微”（micro）粒度的。

我只想说，如果你已经决定使用Docker和Kubernetes，那么你很可能会理解（并接受）这样的观点：

维护一个单体（monolithic）架构是困难的，甚至在意识形态上是错误的。

Docker被设计成运行单进程（singleprocess）应用，并和持久层一起工作。

它迫使我们在DDD（Domain-DrivenDevelopment，领域驱动开发）框架内思考。

在Docker中，被打包的代码被视为一个暴露部分访问端口的黑盒。

生态系统的关键组成部分和解决方案

根据我设计可用性和可靠性更高的系统的经验，有几个组件对微服务的运行至关重要。

稍后我将列出并讨论这些组件，即使以下我只是在Kubernetes环境中引用它们，你也可以将我的这个列表作为任何其他平台的检查表使用。

如果你（和我一样）能得出这样的结论，也即将这些组件作为一个常规Kubernetes服务来管理是非常好的，那么我建议你在不同于“生产集群”（production）的单独集群中运行它们。

例如，“预生产/准生产”（staging）集群可以在生产环境不稳定时挽救你的生命，因为这种情况下你会迫切需要一个能提供镜像、代码或监控工具的环境。

可以说，这解决了鸡和蛋的问题。

身份服务

和往常一样，一切开始于对服务器、虚拟机、应用程序、办公室邮件的访问。

如果你现在就是或想要成为主要企业平台之一（IBM、谷歌、微软）的客户，访问问题将由服务提供商提供的服务来处理。

然而，如果你想有自己的解决方案，那么这一切就只能由你自己搞定，并且不能超出你的预算？

这个关于单点登录的列表（https:

//en.wikipedia.org/wiki/List_of_single_sign-on_implemen