Skip to content

Files

Latest commit

wizardforcelwizardforcel
2021-12-29 23:59:32
Dec 29, 2021
f87fb9e · Dec 29, 2021

History

History
208 lines (126 loc) · 20.1 KB

11.md

File metadata and controls

208 lines (126 loc) · 20.1 KB

十一、运行无服务器工作负载

在这一章，也就是我们的最后一章，我们将讨论一些您希望托管自己的无服务器工作负载的不同场景，以及选择工具时需要考虑的事项。我们将从讨论使用一项仍处于起步阶段且仍在经历大量积极开发的技术的优缺点开始。

不断发展的软件和平台

我们在这本书里看到的几乎所有技术目前都在开发中。正如我们已经讨论过的，有些项目处于非常早期的开发阶段，而另一些项目则更加成熟。让我们从讨论 Kubernetes 本身开始。

KubernetesKubernetesKubernetesKubernetesKubernetesKubernetesKubernetesKubernetesKubernetesKubernetes

Kubernetes 正在积极开发，尽管它已经进入开发周期很久了。我从 2017 年 9 月初开始写这本书，现在，当我写完最后一章时，已经是 2017 年 12 月底了。

在此期间，总共发布了 48 个版本，您可以从下面的截图中看到:

这些更新涵盖了从维护版本 v1.5、v1.6 和 v1.7 的所有内容；v.1.8 和 v1.9 的实际版本；以及后续的维护版本一直到 1.10 的第一个 alpha 版本，有了这样一个活跃的发布周期，保持在版本之上有多容易？

好吧，考虑到发布的频率，没有你想象的那么糟糕，尽管可能会变得复杂。从表中可以看出，每个 Kubernetes 版本都有一个主要版本、一个次要版本和一个补丁版本。例如，在编写本报告时，当前的版本包括:

  • v1.6.13(旧版本)
  • v1.7.11(旧版本)
  • v1.8.6(当前版本)
  • v1.9.0(开发版本)

所以，截止到2017 年 12 月 12 日，同一个主版本有四个小版本正在积极的工作和打补丁。Kubernetes 本身一次支持三个小版本；即当前版本(v1.8)和两个旧版本(v1.6 和 v1.7)。这意味着:

  • 运行当前版本的主节点应该可以与运行前两个版本的节点一起工作。也就是说，您的集群中可以有一个 v1.8 主节点以及 v1.7 和 v1.6 混合节点。
  • 运行当前版本的主节点应该与一个客户机一起工作，比如 kubectl，它比当前版本落后一个版本，领先一个版本；这意味着我们可以将我们的 v1.8 主服务器与 v1.9 和 v1.10 客户端进行交互。
  • 建议您无论运行哪个版本，都始终运行最新的修补程序版本，因为修补程序通常包含关键的错误和安全修复。

这种支持模式意味着 v1.6.13 版本中可能存在的功能在 v1.9.0 版本中可能不可用。对于大约每两个月一次的新的次要版本，您有大约四个月的时间来计划更新，然后有两个月的时间来执行它们——这可能意味着检查并可能更新部署在您的集群中的现有应用，以确保它们没有使用任何正在从最近版本中淘汰的功能。

这就是阅读发行说明变得非常有价值的地方，因为新的次要版本总是有一个“升级前”部分，确切地确认自上一个版本以来有哪些潜在的打破集群的变化。例如，当前的开发版本是 v1.9.0。我知道它将在大约两个月后成为当前版本，因此为了做好准备，我需要工作我的集群，并确保在升级之前，我考虑到了在https://github . com/kubernetes/kubernetes/blob/master/CHANGELOG-1.9 . MD #中详述的所有更改。

仅在次要版本中添加、弃用和删除功能。补丁发布只是现有功能的补丁。我也推荐通读 Kubernetes 折旧政策，里面解释了移除/禁用功能的规则。该政策可在https://kubernetes.io/docs/reference/deprecation-policy/找到。

通过运行以下命令，您可以列出可以使用 Minikube 部署的 Kubernetes 版本:

$ minikube get-k8s-versions

谷歌云支持的 Kubernetes 版本可以在https://Cloud . Google . com/Kubernetes-engine/supported-versions找到。Microsoft Azure 支持所有当前版本；这种支持的一个例子可以在的 AKS 介绍性博客文章中找到，该文章的网址为 https://azure . Microsoft . com/en-us/blog/introduction-azure-container-service-AKS-managed-kubernetes-and-azure-container-registry-geo-replication/，其中的例子显示了从 v1.7.7 到 v1.8.1 的实时升级。

无服务器工具

那么，Kubernetes 正在进行的开发周期如何影响我们一直在关注的无服务器工具的开发，以及这如何影响他们自己的开发周期？

首先，让我们看看工具的类型。在上一章中，当我们看安全性时，我们发现基本上有两种类型的工具。第一种是在 Kubernetes 中添加和扩展功能，如 Kubernetes 和 Funktion。第二种类型的工具消耗 Kubernetes 服务，基本上是坐在 Kubernetes 上面进行 API 调用，比如 Apacheopen 晶须、Fission 和 OpenFaaS。

与 Kubernetes 紧密结合的工具将始终不仅必须根据 Kubernetes 计划其发布，而且必须非常密切地关注 Kubernetes 正在走的道路，因为 Kubernetes 特殊利益集团做出的决定将直接影响他们自己的路线图。

例如，2017 年 9 月，Kubernetes 发布了一个更新，从使用ThirdPartyResources(TPR)更改为customresources definitions(CRD)，因为 TPR 在 Kubernetes v.1.7 中被弃用，并在 v1.8 中被删除。

这确实意味着你选择的工具需要一些研究。你应该问自己的问题是:

  • 我正在评估的工具是否适用于我将在集群中部署的 Kubernetes 版本？如果有疑问，您可以通过用 Minikube 做一些测试安装来检查。
  • 是否有任何未解决的问题会影响我的部署？在您提交该工具之前，我建议在工具 GitHub 项目页面上查看任何未解决的问题；这些问题听起来熟悉吗？它们是否适用于您的安装？
  • 我正在考虑的工具是否部署在主动开发中，新版本的发布频率如何？是否有社区支持该工具？查看 GitHub 上的发布页面；发布的频率有多高，是否有任何破坏服务的发布？
  • 工具的安全性如何？根据前一章，默认配置的安全性如何，使其安全将如何影响您使用该工具？

下面是一些有用的链接，可以帮助你回答前面的问题。

无内胎的

对 Kubeless 有用的链接如下:

Apache OpenWhisk

open 晶须的有用链接如下:

分裂

Fission 的有用链接如下:

OpenFaaS

OpenFaaS 的有用链接如下:

function-函数

功能的有用链接如下:

Since this book was first started, Funktion has been sandboxed. The source code remains available for anyone to use, or fork their own version to continue development. The authors recommend two alternatives: either Kubeless or Apache OpenWhisk.

未来发展

三个月在技术上是很长的时间。自从我第一次开始写这本书以来，Kubernetes 生态系统发生了一些变化；最引人注目的两个目前处于私人测试阶段，预计将于 2018 年初开放供公众使用。

第一种是使用 Minikube 在本地运行 Kubernetes 的替代方法，它来自一个意想不到的来源:Docker。在 DockerCon Europe 2017 期间，宣布 Docker 将在 macOS Docker 和 Windows Docker 的社区版和企业版中支持 Kubernetes 和 Docker swarm。

你可以在https://www.docker.com/kubernetes找到更多关于这个即将发布的信息，或者在https://www.youtube.com/watch?v=jWupQjdjLN0观看埃尔顿·斯通曼的服务介绍视频。

第二项服务毫无意外地推出了亚马逊弹性集装箱服务，简称为“T1”服务，即“T2”亚马逊 EKS“T3”。亚马逊在他们的年度 re:Invent 大会上宣布了这一消息，正如您所料，它与其他 AWS 服务有着深度的集成，例如亚马逊 VPC、IAM、弹性负载平衡和 AWS CloudTrail 等——您可以在https://aws.amazon.com/eks/了解更多关于该服务的信息，也可以在https://www.youtube.com/watch?v=gUFtUU7qvSQ观看公告。

为什么在 Kubernetes 上充当服务

在前几章中，我们谈到了无服务器函数和 Kubernetes 以及使用它们的优势:

  • Kubernetes :使用 Kubernetes 部署应用的最大用例是，它允许您开发一次，然后以一致的方式跨多个平台部署，无论是自托管裸机服务器，还是在 VMWare、OpenStack、KVM、Hyper-V 等平台上运行虚拟机的私有云。谷歌云、微软 Azure 和现在的 AWS 等公共云供应商也是如此，它们都提供自己的本机管理的 Kubernetes 服务，一直到运行 Minikube 或即将发布的 macOS Docker 或 Windows Docker 版本的本地机器。
  • 无服务器:将应用的全部或部分部署为无服务器功能可以帮助其轻松扩展。突然间，您不需要担心您的虚拟机或容器是否有足够的资源来处理大量传入的连接，或者这些连接是如何路由到您的应用的。每个请求将被发送到一个单独的或集群的容器中，在那里您的请求将被处理——一旦完成，该容器将被终止或回收用于下一个请求。
  • Kubernetes plus 无服务器:如前所述，您的应用的无服务器部分可以轻松扩展，这可以与 Kubernetes 相结合，在 Kubernetes 中，可以手动或通过脚本快速启动额外的节点并将其添加到集群中。一旦附加资源成为集群的一部分，您的无服务器功能将自动安排在新资源上，您需要对应用路由或代码进行任何进一步的更改。

现在，将这一点与您可以在任何主要的公共云供应商中部署您的应用的知识结合起来，您将获得一致的体验，而不是必须调整您的代码来使用供应商自己的功能即服务产品，例如我们在第 1 章、无服务器环境中讨论的产品。

您对无服务器工具的选择很可能取决于两个因素，第一个因素是您的应用是用什么语言编写的——例如，您的应用是用 Python、Node.js、PHP、Java、.NET，还是 Go？

第二个因素是个人喜好。在阅读本书的各个章节时，您可能已经形成了一个观点，即哪种工具最适合您，哪种工具将适合您的开发工作流和您自己的工作方式。安全之类的问题总是一个促成因素，但正如前一章所讨论的，有办法克服这些问题。

固定点

到目前为止，我们已经讨论了许多潜在的小运动部件。数据库和文件存储等大型固定点怎么办？他们如何适应库伯内斯的 FaaS 服务？

数据库

关于是否应该在容器中运行数据库服务，仍然存在争论——自从 Docker 第一次获得关注以来，这个问题就一直存在，不幸的是，没有简单的是或否的答案。

每当我接近一个项目时，我倾向于查看使用情况以及数据库对应用本身的整体性能有什么影响，然后再从那里开始工作。

Kubernetes 允许你运行一个 PetSet 回想一下本书开头的宠物与牛的类比。在 Kubernetes v1.5 中，随着功能离开 alpha，它被称为 StatefulSet。该功能在 Kubernetes v1.9 中的测试版中推出。

See the following GitHub issue for a discussion about the change of name from PetSet to StatefulSet kubernetes/kubernetes#27430.

StatefulSet 允许您运行传统上很难在像 Kubernetes 这样的集群服务中运行的东西。使用 pods 和持久存储的组合，它基本上在 Kubernetes 集群中创建了一个固定点，该点:

  • 有一个稳定的唯一网络标识符，如果 StatefulSet 需要在主机之间移动或者 pod 由于错误需要重新启动，该标识符将保持不变
  • 具有专用于 StatefulSet 的稳定持久存储，可用于存储数据库、配置等
  • 拥有有序且优雅的部署和扩展、删除和终止以及自动滚动更新，所有这些都意味着您可以控制需要在软件启动、移动或关闭时进行控制的软件

所有这些都意味着可以在 Kubernetes 集群中托管数据库。这样做意味着您将能够在相同的名称空间内连接到您的数据库，但是这个解决方案可能并不适合所有的场景。

例如，如果您有一个大型数据集，或者您的数据库需要在 Kubernetes 集群之外被其他应用访问，那么您最好使用公共云供应商提供的本地数据库服务。这些服务包括:

虽然使用这些服务会让您受到一些供应商的限制，因为您将有很大一部分数据在 Kubernetes 集群之外，但这三种服务都提供开源数据库引擎，从应用的角度来看，这意味着它们仍然在使用相同的数据库服务，无论是托管在您的集群内还是作为您的公共云供应商服务之一。

有关 StatefulSets 的更多信息，我建议阅读 Kubernetes 网站上的以下两个示例:

请记住，在 Kubernetes v1.9 之前，此功能处于测试阶段，因此如果您的集群运行的是旧版本，您可能需要查看文档。

储存；储备

大多数现代应用不应该存储本地驱动器上生成的文件，而应该使用对象存储。通常，一个对象提供了一个应用编程接口，允许应用将文件写入服务，还可以查询服务以找到文件的元数据，包括检索一个可以通过 HTTP 访问文件的网址。

三大公共云供应商都提供对象存储:

亚马逊 S3 是它们的鼻祖；很有可能在过去 48 小时内的某个时候，您访问了一个直接从亚马逊 S3 服务的文件，或者间接使用了一个内容交付网络，亚马逊 S3 是该文件的来源。

如果您希望将您的应用保留在 Kubernetes 中，包括对象存储，该怎么办？别担心，有可能运行自己的对象存储；事实上，您可以运行一个与亚马逊 S3 有高度兼容性的应用，这意味着您的应用应该在很少甚至没有修改的情况下继续工作。

Minio 是一个多云对象存储，可以部署到 Kubernetes 以及其他云和服务供应商；甚至可以使用 Minikube 在本地运行它。

有关 Kubernetes 上 Minio 的更多信息，请参见以下链接:https://www.minio.io/kubernetes.html。

摘要

所以，我们在这本书的结尾。我们已经了解了无服务器的含义，并解决了在服务器上运行无服务器功能的困惑。

我们已经了解了 Kubernetes 是如何开始的及其一些核心概念，以及如何使用 Kubernetes 自己提供的工具以及云供应商的本机解决方案在本地和公共云中部署集群。

使用这些集群，我们使用了几个工具，这些工具都提供了功能即服务功能，或者通过用新功能扩展 Kubernetes，或者通过利用 Kubernetes 的平台即服务功能并将其安装在 Kubernetes 之上。

然后，我们讨论了这些部署的潜在安全问题以及如何监控这些问题，然后讨论了我们如何尝试并保持领先于不断发展的技术，以及在 Kubernetes 上自行部署无服务器功能时需要考虑的事项。