利用混合云实现数字化转型

思维导图

前言

采用混合云的主要原因包括灵活性、可扩展性和安全性。

混合云允许组织将敏感数据保存在私有云中，同时仍能利用公共云的成本节约和可扩展性，从而提高了安全性。

彩色屏幕截图：https://packt.link/pgupD

采用正确的策略构建混合云

云计算类型和服务提供模型

云计算类型

1. 公共云：由第三方提供商通过互联网提供的云服务，任何付费者都可以访问
2. 私有云：专用于单个组织且不与任何其他组织共享的云服务
3. 混合云：公共和私有云服务的组合，作为一个系统协同工作
4. 多云：使用多个云提供商来满足不同的云计算需求

服务交付模型

1. 基础设施即服务（IaaS）：作为服务提供给客户的云计算基础设施（如服务器、存储和网络）
2. 软件即服务（SaaS）：作为服务提供给客户并通过互联网访问的基于云的应用程序
3. 平台即服务（PaaS）：提供一个平台，使开发人员能够创建、评估和启动应用程序，而无需管理复杂的基础设施

图1.1：云计算模型和服务交付模型

公共云模式和SaaS模式无疑分别是最受欢迎和广泛采用的云计算和服务交付模式。以下是公有云和SaaS服务模式的优势：

1. 可扩展性
2. 成本效益
3. 自动更新和减少维护
4. 灵活性

混合云常见误解

一些组织可能在公共云提供商（如AWS、GCP或Azure）上运行某些工作负载，同时在其私人数据中心运行其他工作负载。虽然这些工作负载同时在公共和私有云环境中运行，但这种托管设置并不是真正的混合云。相反，这些环境是孤立的竖井。 真正的混合云是指在多个环境中创建一个一致的平台。

根据Gartner Glossary的说法，“混合云计算是指跨内部和外部云服务的混合，基于策略和协调的服务提供、使用和管理。”

混合云是一个计算能力、存储和服务池，可从多个环境中获得，包括以下环境：

1. 多个公共云
2. 多个私有云
3. 私有和公共云组合

混合云的变化——同质和异质

1. 同质混合云：当您在公共云和私有云中运行相同的技术堆栈时，它是同质的。传统上，单个软件供应商（如Red Hat或VMware）为两个云提供包括操作系统、系统管理程序和管理层的软件堆栈。
2. 异构混合云：当您运行来自不同供应商的不同组件并将其集成时，这将是一个异构的云。您将拥有公共云提供商，如AWS和Azure，私有云功能将来自Red Hat、VMware等，并将在不同级别与公共云集成。

许多企业希望将本地虚拟机移植到公共云。下图取自AWS，是反映AWS上VMware Cloud的高级组件体系结构：

不仅如此，公共云提供商还构建了扩展，将云解决方案推送到组织的私人数据中心。例如，AWS Outposts通过在完全管理的产品中将AWS基础设施、服务和API扩展到本地，提供混合体验。谷歌安卓、Azure Stack也是云提供商提供的类似产品：

企业采用不同的云，因为没有一个适合所有人的云：

混合云在不同行业中的多功能性和灵活性

1. 安全：政府机构使用混合云方法将敏感的国家安全数据存储在私有云上，以实现最大的安全性，同时利用公共云对非敏感数据进行经济高效的数据存储和处理。
2. 专有技术：一家科技公司使用混合云方法在私有云上存储和管理其专有软件，以实现最大的安全性和控制，同时利用公共云进行经济高效的开发和测试。例如，金融服务公司在私有云上管理交易平台以实现最大控制，同时使用公有云运行模拟和回测算法。
3. 竞争优势：零售公司使用混合云解决方案将关键的销售和客户信息存储在私有云上，以实现安全和合规，同时利用公有云进行实时数据分析，通过提供个性化的客户体验和见解来获得竞争优势。
4. 电信：电信公司使用混合云方法将敏感的客户信息安全地存储在私有云上，同时利用公有云进行实时数据处理和分析，以提高网络性能和客户体验。这种方法通过为客户提供卓越的网络体验，帮助公司在电信行业保持竞争优势。

混合云考虑的关键事项

1. 操作系统：跨云的一致操作系统是基础。它提供了使用一组工具在任何地方托管、管理和监视应用程序的能力。
2. 应用程序分类和合理化：建立应用程序清单，并根据它们所提供的功能对它们进行分类。确定如何处理这些应用程序。在接下来的部分中，我们将探讨对应用程序进行分类的R框架。
3. 自动化：一条不需要太多干预就能正常工作的装配线是充分利用云的必要条件。测试环境的自动化创建、持续集成和持续交付是提高运营效率的必要条件。
4. 数据驱动的方法：数据传统上存在于数据中心。在数字时代，您的客户需要实时的见解和体验，因此计算需要在您的数据所在的位置。这是数字化转型的下一阶段，使数据更接近消费和创建数据的用户。确定您需要计算池的位置，并围绕您的数据需求设计混合云。
5. 管理：为了执行策略并减少运营开销，统一管理是混合云的战略选择。
6. 技术合作伙伴：技能差距是最大的障碍，很难吸引人才并填补技能差距。通过与经验丰富的软件供应商合作，组织可以从他们的最佳实践中受益，并提供混合云。

6-R框架

标准的框架和迁移工厂有助于加速实现混合云

6-R框架是确定云迁移初始步骤的一种非常有效的方法

前两个R用于Retire和Retain。这两种策略适用于对组织的未来可能没有那么战略性的应用程序

退役Retire

这是关于现在或不久的将来不需要的退役或退役应用程序。这可以被视为一个很好的机会来识别和关闭某些不能为业务带来足够投资回报（ROI）的应用程序。通过停用此类应用程序，您可以专注于更需要并产生价值的服务。

保留Retain

这是关于保持当前的封装外形。这可能是因为您无法摆脱它，但也看不到将此类应用程序迁移到云的任何巨大好处。由于安全性、投资回报率或技术堆栈使用的原因，您投资组合的某一部分将属于这一类别。

重新安置Rehost/Relocate

组织中最常用的策略是重新安置。即使在使用云之前，由于成本或技术差距，应用程序所有者和IT团队在使用当前平台时也会遇到某些障碍，因此最终会重新托管。这可以被认为是一个简单的迁移，可以带来显著的好处。它也被称为提升和移位。顾名思义，您可以从当前平台提升/导出应用程序，并将其部署到新平台上，立即产生影响，并获得ROI。

举几个例子，可以将您的本地虚拟机迁移到云上的VMware或KubeVirtualt（KubeVirtualT使您可以在Kubernetes托管的容器平台中运行虚拟机）。

重新托管可能不会像重新规划/重构那样使您的应用程序云原生，也不会带来好处，但如果阻力和摩擦更小，成本更低，回报也会很快实现。

此外，重新定位（也称为系统管理程序级别的提升和转移）是指将基础设施移动到云的过程，而无需购买新硬件、重写应用程序或修改现有操作。此术语通常用于VMware Cloud on AWS产品的上下文中。

Replatform

这可以看作是重新托管的进一步附加组件。对于某些应用程序，重要的是进行额外的优化并执行一些调整和编码，以从云功能中获得好处，如弹性、规模、自我修复等。

重构Refactor

当某些应用程序需要大量改进以提供性能、可用性和可靠性时，此策略更适合。应用程序团队必须进行广泛的设计思考，并提出一个符合新的非功能需求的体系结构。这可能是一项耗时的任务，但也是最有益的策略，需要技能和专业知识才能利用云原生功能。

回购Repurchase

最后一种策略是从现有供应商或技术转向采用新供应商。这意味着出于成本、安全或技术原因终止您现有的订阅和许可证，例如，放弃您的内部客户关系经理（CRM）系统，采用Salesforce或Workday的基于云的SaaS。另一个例子是移动或减少专有数据库的使用，并采用基于云的数据库。

混合云工具

租户的期望是能够请求云资源、管理用户权限和自动控制。租户可以在不同的层请求不同的资源，如图所示：

图1.7 一切皆服务

要了解某些特性，才能实现混合云：

通用平台和操作环境：需要一个通用的操作环境，这样当用户转向任何云时，他们在平台和操作级别都有统一的体验。这将允许用户以简化的方式连接和管理应用程序。

1. 自动化：在混合云环境中，自动化对于实现公共和私有云基础设施的一致和高效管理至关重要。Puppet、Chef和Ansible等与云无关的工具为IT团队提供了自动化基础设施配置、应用程序部署和日常管理的能力，而无需考虑底层云提供商。这些工具有助于组织将其操作标准化，减少手动错误，并确保其基础架构和应用程序安全、可扩展且高度可用。此外，当与GitOps相结合时，与云无关的工具可以帮助组织实现以Git为中心的基础设施代码方法，使他们能够通过单一的真相来源和自动化的工作流程来管理其基础设施和应用程序。这为管理其基础设施提供了一种清晰一致的方法，同时也使他们能够利用公共云和私有云的优势
2. 实施全面安全：安全是一项复杂而富有挑战性的工作。虽然最终目标应该是确保每一层的安全，但方法应该是简化安全管理。当您的环境和基础架构不同时，在不同的云中应用相同的安全策略、应用修补程序和更改管理会变得乏味。最好有一个横跨多个云的工具。获取跨基础设施的集中和精细级别的安全和补丁管理工具将有助于加快云的采用。OpenSCAP就是这样一个工具。

OpenSCAP是一项全面的开源计划，它提供了一套强大的工具，用于无缝实施和实施由NIST精心维护的安全内容自动化协议（SCAP）标准。

OpenSCAP执行漏洞扫描并验证安全合规性内容以生成报告。这是一个快速且可重复的安全性的绝佳解决方案。

1. 统一管理：团队将使用一个单一的控制平面来管理与底层平台无关的多个集群的生命周期，以跨集群创建资源。混合云管理领域的行业领导者包括Microsoft、Red Hat和VMware。这提供了从不同来源部署应用程序、在所有集群中拥有一致体验、管理风险和应用安全策略以及维护治理的能力。
2. 政策和治理：政策和治理在混合云战略的成功中发挥着至关重要的作用。一套定义明确的策略和治理框架有助于组织有效管理多个云环境中的安全性、合规性和资源分配。这些策略需要足够灵活，以适应不断变化的业务需求，同时确保数据和应用程序保持安全。治理框架有助于定义角色、职责和决策过程，从而使不同团队之间更好地协调一致。此外，强大的治理框架确保混合云战略与整体业务目标保持一致，从而实现更好的成本优化、风险缓解和整体性能。总之，政策和治理构成了成功的混合云战略的支柱，组织必须优先考虑这些方面，以便无缝高效地部署和运营混合云解决方案。
3. 使应用程序现代化：有许多这样的工具可以帮助迁移以使应用程序现代化。一个这样的例子是开源工具Konveyor。Konveyor（https://www.Konveyor.io/）是一套工具，专注于Kubernetes目标平台的各种用例，这些工具的主要贡献者是IBM Research和Red Hat，微软也参与其中。这是一个开源的云原生计算基金会（CNCF）沙盒项目。它包括Konveyor旗下的一系列不同工具。Konveyor网站上的下图很好地描述了不同的Konveyol工具：

Konveyor

1. Konveyor Move2Kube：将应用程序重新发送到Kubernetes
2. Konveyor Crane：在Kubernetes集群之间重新托管应用程序
3. Konveyor Tackle：评估、优先排序和重构应用程序
4. Konveyor Forklift：将虚拟机重新托管到KubeVirt
5. Konveyor Pelorus：衡量软件交付性能

其他混合云解决方案

1. 公共云供应商产品：为了最大限度地提高开发人员的生产力，公共云供应商推出了AWS Outposts、Azure Stack、Google Anthos和Google cloud的操作套件（以前的Stackdriver）等产品，允许您在本地和公共云上正常构建和部署应用程序。
2. 平台供应商产品：各种供应商提供跨越公共和私有云的解决方案。Scaler、Cisco Cloud Center、Red Hat OpenShift和VMware Tanzu Application Service等供应商提供的某些工具提供了该领域的重要工具。

例如，Red Hat Advanced Cluster Management将为您的大型混合环境提供所需的功能。要从单个控制台控制集群和应用程序，Red Hat Advanced Cluster Management发挥了重要作用。

该解决方案为您的集群和应用程序生命周期提供了全面的管理、可见性和控制，并增强了跨多个数据中心和公共云的整个Kubernetes域的安全性。它还提供了对行业法规的遵守。

因为这些是互补和集成的技术，所以它们有助于自助服务并解放您的IT部门。

1. Kubernetes:Kubernetes（俗称k8s或kube）是一个容器编排平台。这是一项开源技术，它来自谷歌。尽管最初由谷歌开发，但Kubernetes项目目前由CNCF管理。

它是事实上的标准，本质上是声明性的，也是混合云的理想基础。它将您的工作负载从底层硬件中抽象出来。因此，您可以使用k8s在任何地方提供相同的环境，并在任何位置运行容器化的应用程序，而无需任何修改。

跨任何云操作的灵活性和云的弹性（因为您可以根据工作负载需求动态地向上或向下扩展Kubernetes集群）是它在组织中流行的原因。

处理VM、容器、Kubernetes

虚拟化

图2.1–1型和2型管理程序

两种管理程序差异

1. 类型1虚拟机监控程序：也称为裸机监控程序。它直接在物理机器上运行，不加载或使用操作系统。因此，它是性能最好的系统管理程序，因为它没有操作系统或驱动程序需要处理。

此外，由于没有中间操作系统层，因此消除了与操作系统相关的漏洞。1型管理程序因其安全性而得到广泛认可。他们依靠配备了加速技术的专业硬件来高效处理诸如内存管理、存储、网络资源和CPU操作等要求苛刻的任务。

类型1管理程序的示例有VMware ESXi和Microsoft Hyper-V。

1. 类型2虚拟机监控程序：这也被称为托管虚拟机监控，它在现有的操作系统上运行。因此，类型2管理程序会引入一定的延迟。

此外，由于操作系统层的原因，诸如管理内存、存储、网络资源和CPU调用之类的操作被委托给操作系统，因此类型2管理程序可以在各种硬件上运行。

类型2管理程序的示例有Oracle Virtual Box、Microsoft Virtual PC、VMware Workstation和VMware Fusion。

除了类型1和类型2管理程序之外，我们还混合了类型1和2管理程序，称为基于内核的虚拟机（KVM）。

KVM是一个集成到Linux内核中的虚拟化模块，使内核能够起到管理程序的作用。KVM是在Linux内核2.6.20版本中引入的，由于它与操作系统直接集成，因此被认为是一种类型1的系统管理程序。但是，由于它使用Linux操作系统，因此也被归类为2类系统管理程序。这项独特的技术结合了类型1和类型2管理程序的优点，使其成为基于Linux环境中虚拟化的一个有趣的选择。

KVM将Linux转换为Type 1裸机管理程序，并且只使用一个内核（Linux内核），如下图所示：

类型1、类型2和KVM管理程序的示意图

容器

容器化类似于应用程序级别的虚拟化，为应用程序提供了一个功能齐全的可移植环境。容器技术与虚拟化的不同之处在于，容器与相同的底层主机操作系统共享资源，而虚拟机中封装了自己的操作系统。

容器已经存在了10多年。从根本上讲，容器是Linux的一部分，或者说是Linux的特性，它们是在Linux上运行的进程。但是这些进程与同一主机操作系统上的其他进程是隔离的。

容器是由于某些组件而被隔离的，例如名称空间、cgroups和SELinux。这些组件使容器具有安全性和企业级。下图显示了容器的组件：

1. 命名空间：命名空间限制了进程可以看到的内容，并且是使用系统调用创建的。Linux内核使用名称空间来提供进程隔离。
2. Cgroups：因为容器在单个主机上运行，所以总是担心一个或多个容器会消耗大量资源，从而剥夺其他容器的使用权。cgroups确保为每个容器分配自己的资源——CPU时间、网络带宽和系统内存。
3. Seccomp：它代表安全计算，其目的是限制应用程序允许进行的系统调用。容器不需要更改主机的各种属性（例如，修改内核模块），因此create_module等系统调用将被阻止。
4. SELinux：SELinux应用策略和标签来定义应用程序、进程和文件的访问控制，从而通过将它们分开来保护容器资源。

OCI

OCI是容器镜像格式和运行时规范的行业标准，旨在确保容器在不同平台和工具之间的互操作性和可移植性。OCI由包括Docker股份有限公司在内的一批行业领导者于2015年成立，旨在促进集装箱化的通用、开放标准。

另一方面，Docker是OCI标准的专有实现，为开发、打包和部署容器化应用程序提供了一套工具和服务。Docker一直是集装箱化生态系统中的关键参与者，帮助普及集装箱的使用，并为OCI标准的发展做出贡献。

OCI规范定义了两个关键组成部分：

1. 容器镜像格式（OCI图像规范）：描述容器镜像的布局和内容，包括如何构建、分层和分发图像。
2. 容器运行时规范（OCI运行时规范）：它定义了如何执行容器镜像以及容器如何与主机操作系统和其他容器交互。

Buildah

Buildah是一个命令行工具，用于构建容器镜像，而不需要Docker守护进程或Dockerfile。以下是使用Buildah的一些基本命令：

创建新容器：

buildah from <base-image>

在容器中运行命令

buildah run <container> <command>

虚拟机和容器之间的差异

容器编排

当您的组织正在扩展并拥有数百个容器时，您需要工具来自动化容器的部署、管理和扩展。

容器编排涉及以下任务：

1. 部署和资源调配
2. 资源分配
3. 交通路线
4. 可用性和容错性
5. 监测集装箱的健康状况
6. 集装箱通信/网络
7. 缩放比例

容器的寿命不会很长；因此，重要的是要考虑以下内容：

1. 高可用性
2. 可扩展性
3. 安全
4. 网络
5. IP分配
6. 发现

Kubernetes

Kubernetes组件

1. Pod：一组部署的一个或多个容器称为Pod。Pod是最小的可部署单元，具有共享存储和网络资源。Kubernetes管理Pods而不是管理容器。最常见的场景是在一个Pod中运行一个容器。但是，一个Pod中可以有多个容器。例如，在Istio的情况下，一个充当代理的sidecar容器在您的应用程序容器旁边运行，这两个容器都在同一个Pod中。Kubernetes允许在不影响用户的情况下从一个Pod到另一个Pod的透明故障切换。
2. 控制平面：在Kubernetes集群中，工作节点负责托管应用程序容器，而控制平面管理和监督工作节点和Pod。控制平面充当集群的“大脑”，做出全局决策并监控集群的整体健康和状态。它维护一个名为etcd的数据库，该数据库用作存储整个集群的配置和状态信息的集中存储。
3. kubelet：kubelet是在每个节点上运行的代理。当Pod启动时，需要一个连接kubelet。kubelet使用容器运行时来启动Pod，监控其生命周期，并检查准备情况。

为了在Kubernetes中运行容器，使用了一个称为容器运行时接口（CRI）的接口，该接口基于gRPC。实现CRI的容器运行时可以在kubelet控制的节点上使用。

OpenShift

OpenShift是Red Hat（现已被IBM收购）的旗舰产品，它建立在Kubernetes之上。除了Kubernetes提供的功能外，OpenShift还添加了各种企业级功能，以扩展和保护Kubernete。

OpenShift是100%开源的。它是为开放混合云策略而设计的，为部署在数据中心、云中或边缘的应用程序提供一致性。

VMware Tanzu Kubernetes网格（TKG）

VMware TKG是一个强健且可扩展的Kubernetes解决方案，专为企业设计。TKG使组织能够轻松地在不同的云环境中部署、操作和管理Kubernetes集群，如本地数据中心、公共云和边缘位置。有了TKG，企业可以跨多个基础设施无缝管理其Kubernetes部署，无论底层云环境如何，都能实现一致和统一的体验。

使用TKG，用户可以在多个环境中使用标准化、一致的体系结构快速轻松地部署可用于生产的Kubernetes集群。这使团队能够专注于开发和部署容器化应用程序，而不是管理底层基础设施。

HashiCorp Nomad

HashiCorp有一个支持容器的产品，在某些方面，它的工作方式与Kubernetes的工作方式和管理应用程序的方式类似。但除了容器，它还支持非容器工作负载。

通过与其他HashiCorp产品（如Consul、Vault和Terraform）的强大集成，应用程序管理和编排变得简单起来。

开始使用Nomad非常简单，您可以按照https://www.nomadproject.io/上的教程进行操作。

谷歌Kubernetes引擎（GKE）

GKE是谷歌云提供的一种可扩展的容器服务，是一种托管服务。它使用Kubernetes和其他功能，您可以在GKE上使用所有Kubernete功能。

混合云上的CI/CD

容器堆栈由不同的层组成，这些层在不影响其他团队原则的情况下，为开发人员和IT运营所需的控制级别之间提供了清晰的边界。

运维和开发职责边界

在云和DevOps的世界里，两个最流行的缩写词是CI和CD。CI表示持续集成，CD表示持续交付。

持续交付（continuous delivery）与持续部署（continuous deployment）的区别，然后我们可以跨容器进行连续交付：

1. 持续交付：完成CI后，代码合并发生在中央存储库中，下一步是将更改部署到生产环境中。持续交付可确保按需或自动发布您的代码。
2. 持续部署：一旦您的软件准备好进行部署，您就必须将其从一个环境升级到另一个环境，以便在不同的环境中测试应用程序。因此，连续部署就是跨环境部署。它不涉及任何人为干预。您正在部署供最终用户使用的代码。

传统CI/CD和云原生CI/CD的区别：

Docker镜像可以以完全相同的方式部署在目标环境上，无论它是物理、虚拟、私有还是公共云基础设施。

对于混合云，CI/CD起着重要作用。使用相同的方法和流程，开发团队可以在内部部署和公共云上运行的复杂和异构环境中部署和促进软件和更改。

组织还希望使用云原生技术来构建应用程序，从而在不同的云上提供一致性的开发。

CNCF对云原生v1的官方定义 https://github.com/cncf/toc/blob/main/DEFINITION.md#%E4%B8%AD%E6%96%87%E7%89%88%E6%9C%AC

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。 这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。 云原生计算基金会（CNCF）致力于培育和维护一个厂商中立的开源生态系统，来推广云原生技术。我们通过将最前沿的模式民主化，让这些创新为大众所用。

容器通过以下方式帮助实现云原生：

1. 可移植性：容器允许您将应用程序代码从一个环境移动到另一个环境——从开发到测试再到生产——并提供可移植性。
2. 一致的环境：但它在我的环境中有效，这是我们在生产系统中出现问题时听到的最常见的说法之一。应用程序团队可以使用容器，并确保他们编写的代码在部署和运行容器的任何地方都能运行相同的代码。
3. 控制：由于应用程序代码依赖于某些库和依赖项，容器使您能够决定容器镜像的内容，从而提供完全的控制权。

资源调配基础架构

供应基础设施的典型过程包括开发人员（用户）创建一个票证以请求基础设施（运行其应用程序的web服务器），该票证需要得到其经理的批准，然后发送给运营团队。然后，操作团队将此票证记录在他们的请求系统数据库中。最终，这个票证被分配给一个系统管理员，该管理员使用管理控制台来设置具有所请求特性的资源（一个具有适当计算/内存、网络、存储、操作系统、运行库等的服务器）。一旦请求得到满足，就会通知开发人员。 如下图所示，该过程在每个阶段都需要相当繁重的手动干预，这增加了时间和成本。

使用SDI虚拟化硬件

虚拟化普及了将物理硬件（计算、网络和存储）抽象为软件或SDI的概念。这使企业能够提高资源利用率和灵活性，同时减少资源调配时间和成本。通过将硬件与操作系统解耦，虚拟化可以通过虚拟机提供对抽象资源的访问。

OpenStack汇集了大量资源来提供基础设施即服务（IaaS）。这些资源可以是裸机、虚拟机或容器。图3.3显示了OpenStack，一个部署为IaaS的开源云计算平台。

尽管SDI提高了硬件的资源利用率，但供应过程仍然需要开发人员（用户）创建一个票证来请求基础设施，然后由运营团队进行供应。这一过程仍然需要手动步骤，增加了时间和成本。

使用IaC

IaC通过使用代码而不是手动流程或交互式配置工具来管理IT基础设施，将SDI方法提升到了一个新的水平。使用IaC，您可以将混合云基础设施作为代码进行设计、构建、部署和管理。所需的基础设施规范在配置文件中定义，该配置文件存储在版本控制系统中。然后由协调器来实现该规范，协调器提供所需的资源。IaC使运营团队能够自动化基础设施的供应和管理

IaC的一些好处：

1. 一致性：由于可以一次又一次地部署相同的基础架构，这减少了漂移。这使基础架构能够在不同的环境（如开发、测试和生产）中保持一致。
2. 经济高效：在软件中测试所需的基础设施比在实际硬件上测试更具成本效益。
3. 速度：自动化允许更快的生产时间，因为部署基础架构不需要手动干预。
4. 稳定和安全：在部署基础设施代码前后自动测试和安全扫描基础设施代码，可提供更稳定和安全的基础设施。
5. 可扩展：可重复的过程，具有从1个实例到n个实例的确定性结果。
6. 版本控制：将配置文件保存在版本控制系统中允许共享、源跟踪、版本控制和更改历史记录。这些更改是可审核的，如果出现问题，可以恢复。
7. 开发人员友好型：开发人员可以为本地开发环境提供与生产环境相同的配置。
8. 文档化：配置是文档化的，并且可用，而不是只有系统管理员才知道的黑魔法。

Pulumi：这是一个允许用多种编程语言定义配置的工具，允许IT团队使用现有的IDE和CI/CD来提供基础设施。它是一个声明性工具，使用命令式语言来定义基础设施的最终状态。

为了避免由于配置错误而导致的安全漏洞，可以使用checkov等安全扫描工具。这些扫描工具可以扫描系统、网络和应用程序中可能存在的安全漏洞。

使用DevOps加速IT服务交付

分析公司Gartner的数据：“DevOps代表着IT文化的变革，通过在面向系统的方法中采用敏捷、精益的实践，专注于快速提供IT服务。DevOps强调人（和文化），并寻求改善运营和开发团队之间的协作。DevOps的实现利用了技术，尤其是自动化工具，这些工具可以从生命周期的角度利用日益可编程和动态的基础设施。” 来源https://www.gartner.com/en/information-technology/glossary/devops

与传统的软件发布实践不同，DevOps需要少量但频繁的更新。一些组织通过采用基于微服务的架构进一步实现了这一点，在这种架构中，一个大型单片应用程序被分解为许多独立的组件（微服务），为单个功能提供服务。这些微服务可以独立于其他微服务进行放大或缩小。由于每个微服务都由一个小团队所有，组织的灵活性和敏捷性显著提高。

以下是典型的DevOps流程：

应在整个软件开发生命周期中进行漏洞扫描，以识别和修复漏洞。安全内容自动化协议（SCAP）提供了一套用于自动化漏洞评估、漏洞管理和策略遵从性的标准。本规范由美国国家标准与技术研究所（NIST）负责维护。OpenSCAP是针对Linux系统的SCAP的免费实现：https://www.open-scap.org/features/standards/。

CICD

图3.8–CD的工作流程

一些流行的CI工具包括Jenkins、OpenShift Pipelines、GitLab CI/CD、GitHub Actions、Circle CI、AWS CodePipeline和Azure Pipelines。

持续测试

通过自动化构建和单元测试不断测试代码，以便尽早发现缺陷。QA团队与开发人员密切合作，并可以访问最新的代码库，以确保每个阶段的软件质量。运营部还与QA团队合作，以确保测试环境的配置与生产环境类似，从而使应用程序在测试和生产过程中的行为相同。

通过连续测试，整个测试过程实现自动化，以减少软件交付时间。一些常见的连续测试工具是Selenium、RationalFunctionalTester和Cucumber。

连续操作

连续运营旨在通过减少任何计划内停机时间（如计划内维护）实现全天候IT服务可用性。如果发现任何异常，基础设施将迅速恢复到所需状态。所有这些都是通过自动化的基础设施供应和监控来实现的。

监测和可观测性

尽管不断进行测试，但DevOps中的大量发布意味着生产中总是有可能出现问题。这意味着需要持续监控和观察系统行为，以识别和修复基础设施、应用程序或服务中的任何异常。需要有一个自动通知流程来处理任何影响正常运行时间、速度或功能的问题，以便在不影响服务的情况下解决这些问题。

用于监视和可观察性的一些常见工具是Prometheus、Nagios、Splunk和DataDog。

使用GitOps实现交付和部署自动化

简单地说，GitOps是一种实现应用程序和基础设施生命周期管理自动化的方法。它将DevOps的最佳实践带到了基础设施运营中。GitOps通常用于云原生环境，是Kubernetes等各种基础设施和应用程序部署平台的不错选择。一个很好的例子是Kubernetes控制器，它负责确保集群的当前状态与清单文件中定义的所需状态相匹配。

GitOps的主要特征包括以下几点：

1. 版本控制：所有的代码（应用程序和基础设施的期望状态）和配置都存储在版本控制系统中，如Git。Git存储库成为真理的唯一来源——IaC所需状态的主记录。使用Git存储库作为配置的真相来源是GitOps的主要特征。
2. 更改机制：对存储库中的代码或配置文件的任何更改都是使用“拉取请求”（PR）或“合并请求”（MR）完成的。团队中的任何人都可以创建PR，在单独的分支中进行更改，测试更改，获得审查/批准，并进行MR，将更改推送到主分支，在那里可以使用CD管道进行部署。
3. 声明性：GitOps使用声明性方法，因此与IaC原则非常一致。对基础设施的任何所需更改都只能通过修改Git存储库中相应的配置文件来完成。
4. 自动化：自动化的管道和工具可以监控Git存储库中的任何更改，并可以自动将这些更改应用于目标基础设施。减少了对手动干预的需求，消除了人为错误的风险。

以下是GitOps的一些好处：

1. 可审计且安全：Git存储库可以跟踪一段时间内的所有更改，因此很容易跟踪谁随时间更改了什么。此Git提交历史记录使审查、审核和逆转更改变得容易。这也减少了授予管理员访问权限以直接更改基础设施的需要。
2. 可复制性：在Git repo中定义的基础设施之外，不对所需的基础设施进行任何更改，每次都可以生成相同的基础设施。这也有助于消除开发、测试和生产环境之间的漂移。这可以包括平台配置和应用程序配置。
3. 更快的部署：GitOps能够根据CI/CD原则实现应用程序和基础设施的小型和频繁部署。这不仅可以加快部署速度，还可以在需要时快速回滚/恢复。

GitOps工作流的示例：

1. 在配置文件中定义所需的基础结构状态。
2. 将配置文件存储在Git存储库中，该存储库在各个团队之间共享。
3. 完成并提交对配置文件的任何更改。
4. 通过CI/CD管道启动配置文件的部署（推送或拉式部署）以进行测试。
5. 一旦部署测试成功，就触发部署到生产环境。
6. 持续监控部署（目标环境）和配置文件（真相来源），以检测任何更改。

推式部署与拉式部署

推送部署：任何时候Git存储库有更新，它都会触发CI/CD管道将更新推送到目标基础设施。此工作流是大多数CI/CD管道的工作方式，例如Jenkins、GitLab CI/CD和Tekton。

拉式部署：部署环境中的软件代理根据部署的实际状态持续监控Git存储库中的所需状态。当在Git存储库中检测到更改（例如，新提交）时，会从Git存储库中提取更新并将其应用于部署的环境。此工作流程用于FluxCD和ArgoCD。

使用ArgoCD启用GitOps

https://argo-cd.readthedocs.io/en/stable/

ArgoCD是Kubernetes的CD工具，它使集群和应用程序能够维护配置文件中声明的所需状态。集群和应用程序配置文件在Git存储库中进行版本控制。有了ArgoCD，应用程序部署的整个过程及其生命周期管理都可以实现自动化。ArgoCD充当Kubernetes的扩展，并帮助维护Git存储库中指定的声明状态。

ArgoCD可以跟踪Git存储库（或特定分支、标签和版本）的更改，并将其与目标环境中的部署同步。ArgoCD作为Kubernetes控制器实现，根据Git repo中的期望状态持续监控应用程序的实时状态。如果应用程序的活动状态偏离了所需的状态，它就会变得不同步，并被可视化为这样。然后，ArgoCD会自动将部署同步到所需状态。

ArgoCD可以使用具有多个Kubernetes集群及其应用程序配置的中央Git存储库来大规模管理集群和应用程序，并帮助进行灾难恢复。

ArgoCD提供了部署、服务、pod、容器和ReplicaSets方面的最终配置的可视化概述。以下是一个名为datacenter gitops的应用程序的可视化表示：

GitOps的最佳实践

1. 单独的存储库：应用程序及其配置（Kubernetes清单）和系统配置应该有单独的Git存储库。应用程序源代码与其部署配置完全分离。配置包括所需的部署状态，并包括机密、ConfigMaps等，它们独立于应用程序源代码。如果源代码没有更改，则对配置的任何更改都不应触发应用程序的CI管道。分离还限制了对配置回购的提交访问，并防止开发人员意外地错误配置应用程序。
2. 避免临时更改：有时，团队会走捷径（处理紧急问题或出于习惯），直接更改运行Kubernetes集群，而无需经过Git存储库。当生产环境偏离过渡环境时，这些更改可能会导致配置漂移，并对部署产生不利影响。ArgoCD等工具通过用Git存储库中指定的配置覆盖任何临时更改来帮助避免这种配置漂移，因为这是唯一的真相来源。
3. 避免分支：当将应用程序部署到多个集群（如开发、测试、暂存和生产）时，通常会为每个环境使用单独的分支。这使部署工作流程复杂化，因为每个环境都有自己的唯一配置（机密和ConfigMaps）。更好的方法是将一组核心清单定义为基础，并将特定于环境的配置作为覆盖。
4. 安全性：使用Git安全功能和RBAC来管理对Git存储库的访问和权限。这确保了只有授权用户才能对存储库进行更改——例如，初级开发人员可以向应用程序提交更新PR，但只有管理员才能将代码合并到主分支中。

跨Kubernetes通信

有四种不同的方法可供多个接口使用：

1. 容器到容器（C2C）通信
2. Pod-to-Pod（P2P）通信
3. Pod到Service（P2S）通信
4. 外部（External）到服务（E2S）通信

Pod设计模式

Kubernetes节点、命名空间、pod和服务

1. Pod：这是Kubernetes中最小、最简单的部署单元，可以包含一个或多个容器
2. 命名空间：这是一种在物理Kubernetes集群中创建虚拟集群的方法，用于分离资源并提供访问控制和命名范围
3. 节点：这是一个运行容器化应用程序的物理或虚拟机，为Kubernetes集群提供计算资源
4. 服务：这是一个抽象层，为一组pod提供稳定的IP地址和DNS名称，并允许从集群的其他部分或集群外部访问pod

容器、Pod、Kubernetes

一个pod可以有一个或多个容器

将容器捆绑在一起可以减轻业务应用程序开发人员的操作负担。

有三种多容器pod网络设计模式，涉及两个紧密相关的容器。在下图中，您可以看到主要的应用程序容器，每个容器都有一个标记为sidecar、adapter和ambassador的第二个容器：

Sidecar模式

sidecar模式是Kubernetes中使用的一种设计模式，它涉及在同一个pod中运行一个容器和一个主容器。在这种情况下，主容器通常是需要运行的应用程序，而sidecar容器提供了补充主容器的附加功能。sidecar模式是使用sidecar容器实现的。

sidecar容器在与主应用程序容器一起运行时共享资源，如网络接口和pod存储。一个巨大的好处是低延迟，因为它们使用localhost或netns IP地址在同一网络上通信。它们提供的功能是非业务逻辑的，这意味着在不更改应用程序代码的情况下，它们可以提供跟踪、安全等功能。sidecar不必使用与主应用程序容器相同的编程语言进行编码。当您查看行业中的服务网格解决方案时，您会发现它们利用了sidecar模式。

Sidecar Kubernetes清单文件

apiVersion: v1kind: Podmetadata:  name: myapp-podspec:  containers:    - name: myapp      image: myapp-image      ports:        - containerPort: 8080    - name: sidecar      image: sidecar-image      ports:        - containerPort: 9090

Kubernetes中的sidecar模式可以用于为pod中的主容器提供额外的功能。在本例中，我们使用sidecar模式通过运行sidecar容器为myapp容器提供日志记录和监控功能，该容器收集日志和度量并将其转发到日志记录或监控系统。

适配器模式

适配器模式与sidecar模式相同，因为两个容器都在同一个pod中运行。

对于外部可插拔的可观测性解决方案，适配器模式用于提供简单的集成点。为了标准化主应用程序容器和外部可观察性服务（如日志或调用没有语言绑定的库）之间的接口，适配器模式可能会有很大帮助。

在Kubernetes（K8s）清单文件的上下文中，适配器模式的一个示例可以是使用ConfigMaps来调整应用程序的配置，使其与Kubernetesneneneba API兼容。

假设我们有一个现有的应用程序，它从磁盘上的文件中读取其配置。然而，我们希望在Kubernetes上部署此应用程序，并使用ConfigMaps来存储其配置。在这种情况下，我们可以使用适配器模式，通过创建包含应用程序配置的ConfigMap，使应用程序的接口适应Kubernetes API。

my-app-config的ConfigMap

apiVersion: v1kind: ConfigMapmetadata  name: my-app-configdata:  app-config.yaml: |    key1: value1    key2: value2

这个YAML文件创建一个部署，将应用程序部署在容器中。它还创建一个卷，将ConfigMap作为文件装载到容器的文件系统中。configMap部分中的items字段指定要装载configMap中的哪个密钥以及将其装载到容器的文件系统中的何处。

apiVersion: v1kind: Deploymentmetadata:  name: my-appspec:  replicas: 1  selector:    matchLabels:      app: my-app  template:    metadata:      labels:        app: my-app    spec:      containers:      - name: my-app        image: my-app-image        volumeMounts:        - name: config-volume          mountPath: /app/config      volumes:      - name: config-volume        configMap:          name: my-app-config          items:          - key: app-config.yaml            path: app-config.yaml

通过以这种方式使用适配器模式，我们能够使应用程序的接口适应Kubernetes API，并使用ConfigMaps将其部署在Kubernete上以存储其配置。

最终，适配器将异构容器转换为外部服务的一致统一接口。

ambassador大使模式

大使容器允许外部服务访问，而无需实现服务。这有助于将主容器与外部世界连接起来，例如将localhost连接代理到网络结构的外部世界。对于分布式外部系统的系统集成，大使模式可以提供一种直接的方法。

apiVersion: getambassador.io/v2kind: Ambassadormetadata:  name: my-ambassadorspec:  config: |    ---    apiVersion: ambassador/v0    kind: Mapping    name: service-a-mapping    prefix: /service-a/    service: service-a    --apiVersion: ambassador/v0    kind: Mapping    name: service-b-mapping    prefix: /service-b/    service: service-b

这个YAML文件创建了一个名为my ambassador的大使资源，并定义了两个映射，将传入的请求映射到适当的Kubernetes服务。第一个映射将前缀为/service-a/的请求映射到service-aKubernetes服务。第二个映射将前缀为/service-b/的请求映射到service-b Kubernetes服务。

现在，当大使资源接收到传入请求时，它会检查请求路径，并根据映射规则将其转发到适当的服务。例如，如果传入请求的路径为/service-a/foo，那么它将被转发到service-aKubernetes服务。

这种模式在我们需要在单个IP地址和端口上公开多个服务的情况下很有用，例如当我们有一个微服务架构，其中有许多小服务需要向外界公开时。通过使用大使模式，我们可以简化这些服务的配置和管理，还可以提供与外部世界一致的接口。

理解这三种模式之间差异的最快方法如下图所示

容器到容器的通信

pod可以有多个容器，并且一个pod有其网络名称空间（netns）。

网络命名空间使您能够拥有独立于主机环境（即K8s工作节点）的网络接口和IP表。

pod中的容器共享相同的网络名称空间。由于共享的网络命名空间，容器可以通过相同的IP表路由逻辑访问相同的网络资源，例如IP地址和端口。

pod中的每个容器都可以通过localhost进行通信，就好像它们是同一网络的一部分一样。

Pod间通信

虽然pod可以使用直接IP地址进行通信，但这不是推荐的通信方式。播客是短暂的，应该被取代，而不是直接管理。

在Kubernetes中，pod可以通过几种不同的方式相互通信：

1. 在同一个节点内：Pod可以使用localhost或它们自己的IP地址相互通信，就像普通主机上的进程一样。
2. 跨节点：Pod可以使用自己的IP地址跨节点相互通信，就像不同主机上的进程一样。然而，这可能很难设置和管理，因此通常更容易使用服务来促进pod之间的通信。
3. 使用服务：Kubernetes服务是一组pod上的逻辑抽象，它为这些pod提供了稳定的IP地址和DNS名称。Pod可以使用服务的DNS名称而不是单个Pod的IP地址进行通信。这使得与一组pod进行通信变得容易，即使pod被重新创建或移动到不同的节点。

总之，在Kubernetes中，pod之间最常见的通信方式是使用服务。服务提供了一种稳定的方式来访问一组pod，并且可以使用DNS名称或环境变量来访问它们。

Kubernetes提供了一个称为容器网络接口（CNI）的网络模型。换句话说，Kubernetes利用CNI来建立网络，通过使用网络插件，可以实现它。

许多CNI插件都可用（Flannel、Calico、Weave Net等），您可以根据用例的需要进行选择。CNI通常在初始集群设置期间进行配置，并被称为主集群网络运营商（CNO）——通常是Pod中的eth0接口。

CNI是配置容器网络接口的标准，而CNO是管理Kubernetes集群中与网络相关的资源和配置的Kubernete运营商。

为了实现pod之间的通信，网络流量需要在pod的网络命名空间和节点/主机（也称为工作者）的网络命名空间之间传输，并在整个集群中保持在租户的命名空间内。

为了实现这一点，使用虚拟以太网（veth）设备或veth对来连接Pod命名空间和主机网络。然后，这些虚拟Pod接口通过虚拟网桥进行链接，这有助于通过项目/租户名称空间使用地址解析协议（ARP）在它们之间交换流量。下图描述了Kubernetes的网络。

要利用容器（位于同一个pod中）的多个网络，首先，您需要在K8s集群中规划、设计并实现您的网络结构。然后，您可以参考K8s网络定义中的网络参数：

当使用Kubernetes本地网络结构时，有几个选项/解决方案可用于管理Multus附加CNI接口（即NetworkAttachments）上的IP地址。这些解决方案包括以下内容：

1. Host-local主机本地：此解决方案仅在单个节点上管理指定范围内的IP分配。IP地址分配的存储是在每个主机上的平面文件中指定的，因此它被称为主机本地。
2. DHCP：此解决方案使用“外部”DHCP服务器分配IP地址，该服务器可以与群集集成。
3. Whereabouts：何处模式有效地管理Kubernetes集群中指定范围内的IP分配。它利用Kubernetes自定义资源来存储IP地址分配信息，从而实现集群内任何主机的IP分配。
4. 静态Static：该解决方案为每个pod静态分配IP地址，这些IP在pod YAML上分配或使用Kubernetes配置。

Pod到服务的通信

Kubernetes中的Pod是临时的，可以根据流量需求创建、终止和放大或缩小。这意味着pod的IP地址可能会频繁更改，使客户端很难连接到它们。

Kubernetes网络通过利用其服务功能来解决这个问题，该功能为前端分配一个稳定的虚拟IP地址，用于与链接到服务的后端pod建立连接。此外，该服务以负载平衡的方式将指向该虚拟IP的流量分配给相关吊舱组。

Pod通过服务通信

服务跟踪pod的IP地址，因此即使pod的IP IP地址发生变化，客户端仍然可以毫无问题地连接到它，因为它们只与服务的静态虚拟IP地址通信。这使得客户端可以连接到应用程序，而无需知道pod的特定IP地址，从而减少了pod更改时所需的重新配置量。

外部服务通信

除了在集群内路由流量外，Kubernetes还允许您将应用程序公开到外部网络。主要有两种方法：

1. 出口：此功能使您能够将流量从Kubernetes服务引导到互联网。它利用iptables来执行源NAT，从而使流量看起来像是来自节点而不是Pod。
2. 入口：此功能便于管理从外部来源到服务的传入流量。它还提供了通过连接规则来规范对服务的访问的能力。通常，两个独立的入口解决方案在不同的网络堆栈区域中运行：服务负载均衡器和入口控制器。

入口和出口

如何发布服务

Kubernetes使用Services来访问一组共享公共标签选择器的pod。这允许集群内的应用程序之间进行通信，并使在集群中运行的应用程序可以公开给外部实体，如下图所示：

Kubernetes提供了不同的服务类型，允许您指定如何公开服务。以下是三种主要类型：

1. ClusterIP:ClusterIP是默认的服务类型，它将对服务的访问限制为仅在群集中。这对于需要在集群内相互通信但不需要从集群外访问的应用程序非常有用。
2. NodePort：通过使用此配置，可以从集群外的外部源访问服务。为了实现这一点，在所有节点上打开一个特定的端口，将流量转发到服务。除非集群占用空间小且网络可访问性有限，否则不建议将其用于生产环境。
3. LoadBalancer：这是一种服务类型，允许通过内部部署或云提供商的负载平衡器对外公开服务。负载均衡器接收到的流量被转发到后端pod。如果您使用的是公共云基础设施，如AWS或GCP，这可能是一个额外的成本项目，但它也减轻了维护负载均衡器的负担。一些企业级Kubernetes解决方案（如OpenShift）包括集成的负载均衡器，以便于配置和维护。

ClusterIP是P2P通信的最佳选择，它避免了将服务与外部世界隔离，而且从成本角度来看也是如此。另外两个选项将带来一些额外的成本——NodePort的扩展成本和LoadBalancer的SaaS成本。

多个Kubernetes通信

1. 潜艇Submariner
2. Skupper–使用通用应用程序网络（第7层）
3. 服务网格

潜艇Submariner-使用第3层网络

Submariner是一个软件组件，可以实现不同集群中运行的吊舱和服务的无缝连接。它允许运行在不同集群上的pod和服务像在同一网络上一样相互通信。

潜艇由几个不同的组件组成，这些组件协同工作以提供这种连接。此处列出了这些组件：

1. 灯塔：这是一个关键组件，在每个集群中作为一个吊舱运行，负责发现和维护在其他集群中运行的其他灯塔吊舱的状态。
2. 网关：另一个组件是网关，它运行在每个集群上，负责在集群之间路由流量。
3. 潜艇代理：最后，潜艇代理在每个集群上运行，并负责配置必要的网络规则，以允许集群间通信。

这些潜艇组件协同工作以路由流量并管理吊舱之间的连接。

潜艇结构

它的工作原理是Submariner在每个集群之间创建一个VPN连接，允许集群通过互联网安全地相互通信。控制平面在现有网络基础设施之上创建虚拟网络覆盖，并且数据平面使用该覆盖在集群之间转发业务。通过将服务名称解析为适当的IP地址，可以从另一个集群访问在一个集群中运行的服务。Submariner还允许应用程序/命名空间跨越多个集群，从而提供高可用性和灾难恢复等额外优势。

组件：

1. IPsec流量：使用IPsec协议对群集之间的流量进行安全加密。
2. VLAN流量：通过第2层网络，使用VLAN实现集群之间的通信。
3. 集群节点：通过Submariner互连的Kubernetes集群中的节点。
4. Broker：处理集群之间的发现和连接。
5. Submariner CRD：一个定义全局Submariner配置的Kubernetes自定义资源定义。
6. Submariner路由代理：管理集群节点上的路由表条目。
7. 潜艇网关引擎：建立安全的集群间通信。使用Submariner的好处包括能够轻松连接在不同集群中运行的服务，无论其物理位置如何，以及能够利用多个集群的资源来扩展和平衡工作负载。这在各种场景中都很有用，例如多云部署和灾难恢复。

Skupper–使用通用应用程序网络（第7层）

Skupper是一种允许您连接和公开在不同Kubernetes集群或不同环境中运行的服务的软件。它使用服务网格体系结构来提供服务之间安全可靠的通信，无论它们在哪里运行。Skupper构建在Kubernetes API之上，可以使用Kubernetes命令行工具（kubectl）进行安装和管理。

Skupper使用虚拟应用网络（VAN）处理多集群通信。让我们也试着去了解VAN。VAN可以提供跨多个云环境的无缝连接，因为它们在网络堆栈（应用层）的最高级别发挥作用。这些网络使用称为第7层应用程序路由器的专用路由器，在不同基础设施上运行的不同应用程序之间进行通信。这些路由器充当VAN的主干，类似于传统网络路由器是虚拟专用网络（VPN）的主干。然而，与在网络端点之间路由数据包的VPN不同，VAN使用这些路由器在特定的应用程序端点（称为第7层应用程序地址）之间引导消息。

Skupper架构

Skupper的主要组件是Skupper控制平面和Skupper边缘路由器。控制平面负责管理服务到服务的连接，边缘路由器负责管理进出服务的流量。边缘路由器使用一组暴露在外部世界的虚拟IP地址和端口，然后将这些地址和端口转换为集群或环境中的适当服务端点。

Skupper的工作原理是创建一个连接不同集群或环境的虚拟覆盖网络。这与Submariner类似，但它不需要相同级别的网络知识，并且使用了一种更简单的方法。Skupper可以作为Kubernetes插件进行部署，这使得它易于管理和自动化。它还允许您创建跨不同环境的服务网格，这有助于服务发现、负载平衡和安全通信。

局限性和缺点 Skupper的缺点之一是它只支持Kubernetes，因此不能用于将不同的编排系统连接在一起。此外，与其他服务网格解决方案（如Istio）相比，Skupper可能被认为不太成熟，功能也不丰富。此外，在集群上运行Skupper的开销可能会占用资源，这可能会影响系统的整体性能。

服务网格

服务网格是为微服务应用程序设计的可适应性基础设施层，它提高了服务实例之间通信的速度、可靠性和灵活性。

在Kubernetes中，服务网格被实现为与应用程序代码一起部署并由编排平台管理的代理的集合。这些代理（或“sidecars”）处理服务到服务通信的细节，如流量管理、监控和安全性。

服务网格的主要组件是控制平面和数据平面。控制平面负责管理和配置代理，而数据平面是拦截和处理流量的实际代理集。代理使用控制平面提供的配置来做出路由决策并应用策略。请注意下图中的服务网格通用体系结构，它描述了代理、控制平面和各种重要组件。

图4.21–Istio服务网格架构

在这个体系结构图中，您将注意到Istio的不同组件和sidecar正在启用pod连接。

尽管sidecar提供了优于应用程序重构的优势，但它们并不能确保应用程序和Istio数据平面之间的完全分离。因此，这导致了某些限制：

1. 紧密耦合：为了将sidecar合并到应用程序中，有必要修改Kubernetes pod规范并重定向pod内的流量。因此，安装或更新sidecar可能需要重新启动应用程序pod，从而对应用程序用户造成潜在的中断。
2. 限制范围：Istio的sidecar通常执行流量捕获和HTTP处理，这是计算密集型的，并引入了延迟开销。此外，此进程可能会干扰使用HTTP以外的协议（如SCTP）的应用程序。
3. 资源利用不足：每个边车都会配备足够的CPU和内存，但随着时间的推移，它的利用率会不足。

更好的服务网格（环境网格）

环境网格处于早期阶段，旨在将传统网格功能分离为两层。底层为流量路由和零信任安全提供了一个安全的覆盖层。顶层提供了对Istio所有功能的访问，可以在必要时启用。

尽管第7层处理模式比安全覆盖更耗费资源，但它仍然作为基础设施的环境组件运行，不需要对应用程序吊舱进行任何更改。

图4.22——切片的新网格

环境网格为Istio的采用提供了一种分层的方法，允许从无网格到安全覆盖的平滑过渡，并根据用户的需求在每个命名空间的基础上进行完整的L7处理。不同模式或侧车的工作负载可以轻松地进行互操作，并且可以根据不断发展的需求根据需要混合和匹配功能。

环境网格依赖于安装在每个Kubernetes集群节点上的共享代理，该代理充当负责安全连接和验证网格元素的零信任隧道（或ztunnel）。该节点的网络堆栈通过ztunnel代理路由来自相关工作负载的所有流量，确保Istio的数据平面和应用程序问题完全分离。ztunnel代理不对工作负载流量执行任何L7处理，这导致了一种比使用sidecars更高效、更具成本效益的方法。这种简化的方法能够提供共享基础设施。

环境覆盖

ztunnels构成了服务网格的基本框架，提供了一个零信任环境。一旦为命名空间激活了环境网格，它就会生成一个安全覆盖，使工作负载能够使用诸如mTLS、身份验证、授权和遥测等功能，而无需检查L7流量。当需要L7功能时，可以允许命名空间使用它们，并使用路点代理来处理该命名空间中应用程序的L7处理。

服务网格控制平面负责在集群内设置称为ztunnels的通信路径，以处理所有需要高级处理的网络流量。这些路径被称为路点代理，本质上是常规的pod，可以像Kubernetes中的任何其他部署一样自动缩放。这种设计允许更好的资源利用率，因为航路点代理可以根据其服务的名称空间的实际流量需求进行缩放，而不必预测和提供最大或最坏情况下的流量负载。以下是一个ztunnel的描述：

环境连接

环境网格使用HTTP CONNECT over mTLS来建立安全隧道，并利用基于HTTP的覆盖网络环境（HBONE）模式沿路径实现航路点代理。与TLS相比，这种方法确保了更精简的流量封装，同时还实现了与负载均衡器基础设施的无缝互操作性。

将sidecar和环境网格组合在单个网格中不会对集群造成任何限制或安全问题。Istio控制平面确保策略的实现是一致的，无论选择何种部署模型。环境网格提供了用于管理应用程序流量需求的附加选项，具有增强的可配置性和更有效的方法。

服务网格联邦

服务网格联合是在多个服务网格之间连接和共享服务和工作负载的一种方式，每个服务网格都由自己的管理员管理和控制。默认情况下，网格之间不允许通信和信息共享，只允许在明确的选择加入基础上进行。这与云时代的最低特权原则是一致的。

要启用联合，必须在每个网格上配置服务网格控制平面，以便为联合创建特定的入口和出口点，并标记整个网格的信任边界。联合还需要其他对象，如ServiceMeshPeer、ExportedServiceSet和ImportedServiceSet：

1. ServiceMeshPeer对象定义两个或多个服务网格之间的连接
2. ExportedServiceSet对象指定一个网格中的哪些服务可以由另一个网格使用
3. ImportedServiceSet对象定义要导出的服务和要导入的服务

用于通信的服务网格控制平台

服务网格框架是专门的基础设施层，可以简化基于微服务的应用程序的配置和管理。这些框架通常利用sidecar容器作为代理，提供基于双向TLS的安全性、断路和金丝雀部署等功能。

大多数流行的服务网格解决方案也支持多集群部署，允许通过代理在集群之间路由流量。它们还可以提供跨集群的双向TLS连接，并公开具有跨集群流量路由等功能的服务。然而，使用这样的解决方案

通常需要多个步骤和新的特定API。下图描述了跨集群通信的服务网格：

图4.26——通过出口和进口进行通信的服务

服务网格联邦允许跨不同集群管理多个服务网格，从而实现服务之间的无缝通信和控制。这种方法可以简化复杂分布式系统的管理，同时实现高效的扩展和恢复能力。

电信和工业部门的设计模式

5G核心解决方案堆栈可分为以下几类：

1. 基础设施
2. 应用程序平台
3. 5G应用
4. 部署和生命周期管理

图5.1–5G核心解决方案

基础设施

这包括云服务提供商和内部数据中心提供的服务和资源。其中包括核心资源，如计算、网络、存储和服务，如NTP源、防火墙、负载均衡器以及身份管理和自动化工具。基础架构包括裸机服务器实例、虚拟机或基础架构即服务（IaaS）产品。以下是基础设施提供的服务和资源示例：

应用程序平台

该应用平台为5G应用程序和NFs独立于底层基础设施运行提供了基础。基于容器的应用程序平台包括容器执行、编排平台以及用于度量和仪表板（如Prometheus）的相关工具。Kubernetes是最受欢迎的平台，用于在混合云中部署应用程序，保持它们的运行，并确保它们可以根据不同的用户需求进行扩展。以下是基于Kubernetes的应用程序平台提供的服务和工具的示例：

图5.3–应用程序平台堆栈

5G应用

5G应用程序提供核心5G功能，可分为以下几类：

1. 主要功能：这些NFs提供设备/用户注册和会话管理。这些功能包括用于处理连接和移动管理的接入和移动管理功能（AMF）、用于与数据平面交互的会话管理功能（SMF）、提供策略规则的策略控制功能（PCF）、，以及用于管理用户订阅和认证数据的统一数据管理（UDM）。
2. 补充功能：这些网络功能有助于设备/用户订阅和增值服务，如存储用户信息的统一数据存储库（UDR），用于选择网络切片实例的网络切片选择功能（NSSF），以及用于NF注册和发现的网络储存库功能（NRF）。

部署和生命周期管理

部署在混合云上的解决方案堆栈需要得到管理工具（混合云管理器）、安全和策略管理工具（RBAC）、运营商和服务网格的支持。以下是部署基础设施、应用程序平台、5G应用程序和生命周期管理（第二天操作）所需组件的示例：

这些组件通过跟踪各种集群的资源利用率、可用性和响应时间等关键指标来监控混合云的性能。他们还负责多集群管理、GitOps和安全性。

5G核心解决方案堆栈摘要

电信公司可以通过采用分离控制平面和用户平面功能的CUPS架构来构建灵活高效的5G核心。这些功能可以部署为云原生应用程序或可以通过标准接口进行通信的NFs。每个NF可以根据服务需求和资源可用性动态地且独立于其他NF进行扩展。

这使得电信公司能够支持广泛的5G用例，而无需额外的操作复杂性和成本。通过利用应用程序平台管理工具，电信公司可以轻松地协调、操作和监控网络的每一层。

5G RAN

RAN负责将移动设备连接到服务提供商的网络。移动设备连接到无线电塔顶部的天线，这些天线向基站发送信号，在基站中信号被数字化并路由到核心网络。这些移动设备，也称为用户设备（UE），可以包括汽车、无人机、农业机械，甚至是非移动设备，如监控摄像头或工业设备（见图5.8）。

图5.8–移动网络概述

图5.9——网络技术发展

保护混合云

安全原则

核心安全原则——信任。安全不应该事后才考虑，而应该从头开始。内置安全模型的一种非常常见的方法是零信任方法。

混合云中的不同安全组件

图6.3-混合云基础设施中的安全组件

图6.4-单一混合云架构

上图显示了一个在Kubernetes集群内运行的简单web应用程序，用户可以从台式机、笔记本电脑和移动设备访问该应用程序。该应用程序将其数据存储在通过数据管道填充的云原生数据库中。它从运行Kubernetes的边缘集群接收数据，该集群处理来自物联网设备的数据预处理，也从运行在批量发送数据的预处理数据中心中的遗留数据源接收数据。我们将在本节中使用此示例来解释安全性如何与这些组件中的每一个相关。

对安全性有某种影响的组件：

1. 硬件
2. 启动程序
3. 硬件内核
4. 存储和加密
5. 底层物理网络
6. 审核日志记录
7. 用户操作系统
8. 网络安全
9. 平台安全性
10. 平台操作
11. 平台标识和访问管理（IAM）
12. 部署和使用
13. 应用程序配置
14. AuthN和AuthZ
15. 内容和数据

图6.5——责任界限

平台层

将最新的安全补丁应用于正在使用的数据库版本非常重要。

随着时间的推移，保持平台安全的最佳实践之一是不断更新和修补您的Kubernetes版本。

Kubernetes上游社区每年发布三个主要版本，然后还有较小的安全更新和补丁，通常在全年作为次要版本发布。在进行主要升级的同时，跟上安全性和修补次要版本的发布是非常重要的。同样，作为最佳实践，遵循主要版本的升级节奏也很重要，因为落后太多意味着从安全修复的角度来看，新版本将不再受支持。同样，这将使升级周期的管理更加复杂，因为它们需要较小的增量升级。

应用层

就安全最佳实践而言，这是应用标准化和强制执行最困难的一层。造成这种情况的主要原因是存在不同类型的应用程序。

应用程序安全性的一个非常重要的方面包括保护应用程序在下面访问的数据。

应用程序安全包括整个软件交付生命周期的安全最佳实践

（SDLC）管道。这个管道通常被称为DevOps管道。

当DevOps管道与安全实践集成时，它被称为DevSecOps CI/CD管道。一些可能需要额外工具的集成实践包括以下内容：

1. 静态代码分析（一种在不执行程序的情况下分析计算机程序代码的方法）
2. 容器的漏洞扫描（将容器的内容与已知安全漏洞的数据库进行比较）
3. 威胁建模（一种对可能的安全威胁和防御进行建模的评估形式）
4. 威胁情报（了解为获取安全攻击情报而收集的数据）
5. 法规遵从性要求的策略强制执行（自动强制执行法规遵从性所需的安全策略，我们将在本章后面更详细地了解这一方面）
6. 集装箱图像签名验证（集装箱图像的数字签名验证，以验证真实性）

配置安全

配置标识

身份涵盖了安全性的所有组成部分。我们之前提到过零信任的概念以及跨多个系统的信任边界扩展。因此，所有组件始终呈现一个标识是很重要的。身份会影响混合云世界中的许多角色（用户角色，如开发人员、系统管理员等），在提供访问、服务和数据的同时，在所有实体中一致、适当地应用安全原则非常重要。在遵守业务合规性和监管要求的同时坚持这些原则是构建安全混合云解决方案的关键。

身份是安全各个方面的切入点。在混合云的世界中有多个人物角色，在本节中，我们将从安全的角度来考虑所有这些角色。每个角色都可以被视为一组用户，每个组通常都有一组访问控制和权限。向实体授予权限以允许它们访问、读取或写入系统中的数据和更改的过程称为身份和访问管理（IAM）。这些权限被绑定到定义访问级别的角色中，并且可以根据所需访问权限的粒度进行预定义或定制。身份本身由两部分组成：身份验证（AuthN）和授权（AuthZ），本质上分别意味着谁可以做什么：

AuthN决定你是谁，并且来自一个身份平台：

1. 最终用户（人类）
2. 通过社交平台联合登录
3. 不同系统和云提供商的服务帐户（GCP–服务帐户，Azure–服务主体，AWS–IAM用户）
4. API密钥凭据（通常与用户或服务帐户关联）
5. SSL/TLS证书

AuthZ决定您可以做什么，并受以下内容控制：

1. 角色（管理员、用户等）
2. 小组（开发、QA、SRE、运营）
3. 访问控制列表（ACL）
4. 上下文
5. 位置（例如，受限制的国家/地区）

IAM的一些最佳实践：

1. 通过单一身份平台实现单一登录或联合身份
2. 使用单个存储库集中AuthZ
3. 遵循有关超级管理员帐户的安全最佳实践
4. 自动化用户生命周期管理过程
5. 以编程方式管理用户帐户、服务帐户和组
6. 在分配权限时使用最小权限原则，并考虑在公共云中创建自定义角色以实现细粒度访问控制
7. 不断监控和审核针对相应用户/服务帐户或组的使用和活动授予的权限
8. 自动轮换用户管理的服务帐户密钥
9. 对服务帐户的请求提出质疑，以分析和了解所请求的内容是否确实必要
10. 始终考虑使用短期凭据
11. 使用凭据保护所有API访问权限
12. 为用户帐户创建密码策略并配置2FA

保护Kubernetes平台

Kubernetes平台内的层

基础设施安全

Kubernetes作为一个平台，在抽象基础设施的同时，很好地提供了分布式计算。以下是保持该层安全的一些最佳实践建议：

•使用仅适用于运行容器的优化操作系统来限制攻击面

•限制平台对底层操作系统的访问（即限制系统调用和文件路径访问）

•在节点引导期间（即，将新节点加入集群时）集成云提供商提供的加密验证功能

确保集群安全的最佳方法是确保您运行的是最新版本的Kubernetes。

平台安全性

Kubernetes集群的一个关键安全控制是强大的基于角色的访问控制（RBAC），以确保集群用户和在集群上运行的工作负载都具有执行其角色所需的适当访问级别。对Kubernetes数据存储（etcd）的访问尤其应仅限于控制平面，并且etcd应仅通过TLS访问。在静止时对所有存储进行加密是一种很好的做法；etcd也不例外，因为它是你集群的大脑。

图6.9-请求到容器的安全路径

API认证

所有集群都必须设置身份验证机制，并且在API服务器处理任何请求之前，所有API客户端都必须经过正确的身份验证。较低级别的测试环境，如dev，有时只有一个用户，可以使用静态承载令牌方法，而更高、更大、更安全的环境集群可以与现有的OIDC或LDAP服务器集成，这允许基于组的更细粒度的访问控制。

API授权

一旦通过身份验证，所有API调用都将通过授权检查。Kubernetes提供了一个全面的RBAC堆栈，有助于将传入请求的用户或组与绑定为角色的一组权限或操作相匹配。这些权限是get、create或delete等动词与Kubernetes资源（如pod、服务或节点）的组合，这些资源的作用域要么将它们限制在命名空间中，要么在集群范围内实现权限。

工作负载安全性

当谈到实现零信任战略时，可审计性和自动化是两个关键原则。推荐的工作负载安全性最佳实践也围绕着这些关键原则。

Kubernetes提供了准入控制器，这些控制器有助于在对Kubernete对象存储的更改持久化之前对进入API服务器的请求执行验证（本质上是对配置文件的更改，因为Kubernets是一个声明性系统）。这有助于我们积极主动地进行与安全相关的预检查。这个用例的一个很好的例子是，在允许在集群中部署这些图像之前，检查图像的签名或显式元数据的存在。准入控制器的另一个例子是pod安全准入，它有助于执行pod安全标准。

应用程序容器镜像实际上也被视为基础结构。这些镜像存在安全漏洞，因此有效管理其库存非常重要。

图6.10——漏洞管理的生命周期

漏洞威胁分析不能仅限于扫描注册表中的容器镜像。漏洞扫描必须扩展到生产中运行的容器，这一过程也称为动态威胁分析。从这次扫描中发现的漏洞可以分为不同的关键级别。镜像是否符合要求取决于企业自己定义的对这些关键级别的响应。在您的软件交付生命周期内，可以自动检查镜像签名和扫描漏洞。

代码安全性

代码的一些最佳实践建议：

1. 如果任何应用程序服务需要通过TCP进行通信，请确保仅通过TLS进行访问。加密传输中的所有内容也是一种很好的做法。
2. 仅显示通信或收集度量绝对必要的端口。
3. 如果应用程序使用任何第三方库，最好扫描它们以查找已知的安全漏洞。
4. 将静态代码分析和动态探测集成到您的DevSecOps流程中。
5. 将软件物料清单作为软件供应链中工件的一部分也是一种很好的做法。

配置网络安全

无论是公共云、私有云还是边缘，网络总是有两个组成部分。一个是物理网络，而另一个是软件定义的网络，即物理网络之上的覆盖网络。在混合云的前置和边缘部分，安全责任由企业承担，而公共云提供商保证基本的网络安全水平，并提供网络服务和将安全集成到设计中的能力。下图显示了创建网络体系结构时通常实现的网络边界：

上图说明了在设计网络时需要牢记的两个重要注意事项。两者在混合云架构中都至关重要：

1. 配置网络周边控制
2. 配置网络分段

这些可以通过使用网络防火墙规则来创建完全限制互联网访问的气隙网络，并创建DMZ（或非军事区）来实现，DMZ是一种外围网络，为所有不受信任的流量在内部网络周围添加一层安全层。

在更深入地探讨这些考虑因素之前，确定应用程序的入口点是很重要的。换句话说，提供对我们的应用程序的访问的公共端点位于哪里？网络设计的细分取决于此位置。该端点可以在公共云的公共地址空间中，也可以在企业的数据中心或私有云中。为了保持一致性，我们将回到混合云中安全性的不同组件部分中使用的相同示例。基于示例中的架构，我们将假设我们的公共端点位于其中一个公共云提供商中。

假设端点位于公共云提供程序中，它通常会由安全负载均衡器公开。云提供商有自己的web应用程序防火墙，可保护此端点免受分布式拒绝服务（DDoS）攻击。企业还可以灵活选择与云无关的WAF解决方案，以根据其战略，在其预处理系统和多个云环境中保持设计和可用性的一致性。负载均衡器可以位于第7层或第4层，具体取决于应用程序的要求。

确保流量安全以实现安全和法规遵从性目标非常重要。最佳做法建议使用安全套接字层（SSL）或传输层安全性（TLS）协议来保护通过网络传输的数据。此外，暴露的端点将具有与其关联的DNS名称。另一个最佳实践建议是使用域名安全扩展（DNSSEC）来保护您的DNS数据。DNSSEC从源提供数据真实性的加密验证，并为DNS协议提供完整性保护（保证在传输过程中不受数据修改）。

现在，我们进入虚拟私有云（如果云是GCP或AWS）和托管应用程序和数据管道的虚拟网络（如果云为Azure）。这就是我们有另外两个与核心VPC集成的网络的地方——我们有托管Kubernetes集群的边缘网络，我们的企业数据中心有我们的遗留数据库。这就是网络周边控制变得非常重要的地方。防火墙规则在控制整个网络的进出流量方面发挥着非常重要的作用。除了防火墙规则之外，我们还可以对网络进行划分，将由此产生的子网络分为可公开访问的子网络和完全私有的子网络。我们在网络中也有路由的概念，它定义了网络数据包从源地址到目的地址的路径。使用网络周边控制和网络分割的组合，当我们的应用程序中有多层时，我们能够提供网络隔离。以下是网络分段和隔离的几个常见示例：

混合云最佳实践

混合云挑战

1. 不同系统之间的不同连接
2. 集成
3. 云和数据中心之间的应用程序可移植性
4. 优化资源利用和消耗
5. 基础架构和应用程序生命周期协调
6. 存储

了解各种体系结构注意事项

在讨论混合云的架构考虑因素之前，首先要了解我们试图使用混合云实现解决的问题或挑战。

1. 可移植性和可管理性有助于避免供应商锁定
2. 数据驻留和监管要求
3. 区域和全局冗余的应用程序要求
4. 跨整个基础架构的高效软件交付供应链流程

Kubernetes混合云的价值主张

混合云的开发和部署

混合云需要关心的事

在整个列表中，让我们特别关注关键项目（基础设施即代码、配置即代码、策略即代码和DevOps），因为它们在该架构的部署中发挥着非常重要的作用。

IaC的基本工作流程

对整个混合云架构进行建模并将其转换为代码有助于实现与可重复过程的一致性。它还有助于快速创建和销毁按需环境。可以从生产环境代码中准确地创建相同的灾难恢复克隆。其他优点包括：

1. 稳定的环境
2. 速度和灵活性
3. 易于维护和访问不同版本
4. 基础架构即代码的集中存储库
5. 在灾难恢复期间轻松地重新创建环境
6. 可以扩展到软件供应、配置管理和应用程序部署
7. 减少人为错误

配置为代码

Kubernetes为维护和扩展混合云环境提供了最大的灵活性、灵活性和控制能力。我们还知道Kubernetes是一个完全基于配置的声明性分布式系统。在适用的情况下，所有在容器内运行的云原生和现代应用程序都将转向Kubernetes，这是容器编排的行业标准。配置YAML文件是定义平台的整个配置的资产。就像基础设施一样，我们现在能够将我们的平台（如果是Kubernetes）配置表示为代码。下图显示了Git版本控制存储库在持续集成和持续部署中发挥着重要作用

图7.7 Kubernetes的GitOps工作流程

配置不需要仅限于平台，也可以扩展到应用程序。所有基于Kubernetes的应用程序代码都是一组表示应用程序状态的YAML文件。因此，它已经以“配置即代码”的形式存在。当涉及到应用程序时，除了核心应用程序配置，它们还有环境配置。如果采用“按代码配置”方法，将应用程序代码和环境配置分离到单独的存储库中也是一种很好的做法。

1. 更大的安全性，因为我们明确划分了开发和运营边界
2. 审计的详细可追溯性
3. 更好地管理软件交付生命周期

为了进一步简化代码的使用和扩展，有一些开源工具，如Kustoize、ArgoCD和Helm等，它们引入了一种使用模板管理应用程序配置的方法。尽管参数化解决方案很容易实现，但它们通常仅在小范围内有效。随着时间的推移，参数化模板变得复杂且难以维护。使用这些工具集的组合有助于有效地实现GitOps和Kubernetes基础设施和应用程序的持续交付。

作为代码的策略

自动化在帮助我们控制和管理混合云架构的安全态势方面的重要性。策略即代码是指使用代码来管理安全管理的规则和条件。在确定适当保护混合云架构后，然后使用Python或Rego等编程语言编写策略，这取决于用于实施策略的工具。一旦我们有了作为代码表示的资产，我们就能够使用软件编程的最佳实践，如版本控制和模块化设计，并轻松地将其扩展到云资源的治理中。受监管行业的企业认为，违规行为处理起来非常昂贵和耗时。因此，这些方法是积极主动的，将为他们节省数百万美元用于补救这些违规行为并对其品牌产生不利影响。将策略用作代码的一些优点如下：

1. 将安全最佳实践和检查集成到DevOps工具和流程中
2. 不再需要在软件代码中硬编码安全策略
3. 删除手动步骤并将自动化扩展到安全性的实施

图7.8–策略控制器的工作流程

图7.9——混合多云的DevOps——一次一点

DevOps的许多方面包括以下方面：

1. 软件配置管理
2. 变更管理
3. 需求管理
4. 软件交付管道
5. 整个输送管道的环境管理
6. 持续集成
7. 连续测试
8. 持续部署
9. 安全检查
10. 持续监控
11. 运营和现场可靠性工程（SRE）

图7.10——DevOps自动化的最大优势

混合云的经济性

我们必须考虑投资回报率（ROI）和总拥有成本（TCO）。

资本支出与运营支出

资本支出的定义是通过一次资产收购来经营企业，并使企业受益数年。这些可以指收购的房地产、空调和发电机，专门用于运行IT；用于建造数据中心的所有服务器和设备都将归CapEx所有。所有签署的有助于延长这些资产使用寿命的维护合同也属于资本支出类别。

OpEx是日常经营业务所产生的成本。这可能包括打印机的纸张、建筑的电力或商业网站的域名注册。他们是根据使用情况使用或支付费用的消耗品。这些是业务的必需品，但不是组织的资产。在混合云中，OpEx将对应于公共云，在公共云中，业务根据其资源消耗产生费用。

下图显示了CapEx和OpEx之间的简单比较：

了解CapEx和OpEx对于清楚地理解混合云的经济性非常重要。这将帮助我们确定ROI和TCO。

ROI和TCO

ROI是指投资对整个业务的影响。回报大于TCO。准确估计ROI非常困难，尤其是在混合云的情况下，因为有形（效率和收入）和无形（复杂的DevOps流程和多个工具）是如何在内部部署和云上部署的。

TCO是指与建立基础设施相关的总投资成本。它包括资产在其使用寿命内的购买、运营和维护。同样，这对混合云来说真的很有挑战性，因为云是一个动态的生态系统，估计TCO是云基础设施、云迁移或管理以及运营成本的组合。这些必须针对公共云和私有云分别进行。

混合云实施

图7.12-与云管理相关的任务

实现混合云的步骤：

网络连接

设计网络连接时的关键要素：

1. 为最终用户提供对应用程序的访问
2. 如果有多个服务在Kubernetes集群中运行，那么提供服务之间相互通信的能力
3. 为应用程序组件提供了与其他地方可能存在的任何第三方应用程序或后端数据库对话的能力
4. 如果任何数据摄取管道是应用程序的一部分，则为边缘设备和端点提供推送数据的能力

下图显示了不同网络汇聚在一起的简单示意图，并显示了混合云架构中公共和私有网络边界的分离：

所有网络安全方面，连接可以通过几种不同的方式进行：

1. 如果要通过常规互联网进行连接，则需要通过VPN连接。在这种类型的连接中，两侧都有一个网关组件，它提供了一个连接管道，所有流量都在传输过程中加密。由于VPN连接是通过互联网实现的，它支持前面提到的所有三种类型的混合连接要求。然而，也有一个关键的限制需要强调。VPN连接的最大带宽范围为3-5 Gbps。选择此选项时应考虑网络延迟和应用程序容差。
2. 然而，如果需要额外的安全层和更高的带宽，那么云提供商提供了在本地网络和云网络之间建立物理连接的方法。这提供了在两个网络之间传输大量数据的能力，有时比通过互联网服务购买额外带宽更具成本效益。物理网络连接通常通过两个网络连接在一起的同位置设施进行。即使带宽在100到200 Gbps之间，这些连接也是极其昂贵的。除非企业有此要求，否则成本通常是一个令人望而却步的因素。
3. 还有第三种选择，这是专用互连的高成本和VPN连接的低带宽之间的权衡。这是云提供商的合作伙伴提供的互连选项。本地网络和云提供商之间的连接是通过直接连接到云提供商的网络的服务提供商实现的。

安全认证

从企业的角度来看，应该制定适当的治理流程：

1. 不断审查安全策略
2. 进行适当的风险评估
3. 识别潜在漏洞

混合云架构中的数据流经许多系统。需要在数据的整个生命周期中维护合规性和法规要求。它需要在运输、存储等过程中得到保护。数据存储在许多分段存储系统中，因此必须格外小心地保护这些数据存储位置。常见的可能性是中间人类型的攻击，因为它流经不同的云和本地环境。应该巧妙地使用加密来向未经授权的用户隐藏数据。

图7.15-工作负载安全组件

通过自动化和代码进行管理成为实现最佳实践推荐的安全态势的唯一途径。

费用

由于复杂的混合云架构及其相关的最佳实践的所有实现，成本本身就很高。

以下是所有混合云成本考虑因素的列表：

1. 管理和支持费
2. 数据传输
3. 仓储费
4. 混合云软件和服务器费用
5. 定制和集成费用
6. 合规费用

最后，归根结底是企业是否能够负担得起混合云的成本。当收益大于成本时，会选择混合云架构。OpEx和CapEx都有组合，我们详细讨论了混合云的经济性，这意味着有足够的效率可以根据工作负载和业务的要求来实现。