Kubernetes具有许多核心抽象（有时称为原语），这些抽象使部署和管理应用程序的体验比以前更好。 理解这些抽象可以帮助您充分利用Kubernetes并避免复杂性-特别是在运行有状态的应用程序（例如数据库，数据分析，大数据应用程序，流引擎，机器学习和AI应用程序）时。
在本文中，我将回顾Kubernetes存储中的一些基本抽象，并逐步介绍Portworx PX-Enterprise如何帮助解决因Kubernetes中持久存储需求而引起的重要挑战。
Kubernetes抽象和Kubernetes存储
Pod是核心Kubernetes抽象的一个很好的例子。 它实际上是第一个示例-起点。
早在2015年，其他容器编排系统便以单个容器作为基本抽象。 Kubernetes从Pods开始 。 Pod是一组需要一起运行才能有用的一个或多个容器。 一个简单的类比是，豆荚就像衣服。 穿上衬衫和袜子真是太好了，但不要穿裤子不要走出大门！
豆荚就是这样-他们让我们专注于有用的东西（跑步的衣服），而不会把簿记细节（鞋带，一只袜子）堆满。 别误会，调度程序和Kubelet （Kubernetes代理）正在跟踪细节。 但是正是这种抽象允许生态系统建立在Kubernetes上，并允许管理员自动化其基础架构。 今天，我们看到大多数其他调度程序都采用了Pods概念，这无疑是其有用性的标志。
Kubernetes中的存储世界也有其原始元素，乍一看其中有些听起来很复杂。 这些抽象组合在一起带来了一个复杂的问题-如何在无法预测应用程序需求时有效地进行调度-并提供可靠的解决方案。 最终，如果没有这些抽象，您将不想在生产中运行。
这是描述和控制存储的Kubernetes抽象：
- PersistentVolume（PV） –表示保存数据的位置。 您的基础架构提供商或存储供应商将实现此目的。 PV是通过标准方式（例如备份，复制和加密）保护的。
- PersistentVolumeClaim（PVC） – Pod如何请求PersistentVolume，包括描述所需PV的大小。 请求后，PVC成为Pod及其PersistentVolume之间的引用。
- 现在，您可能会问，为什么不跳过PVC而让Pods直接使用PersistentVolume？ 如果没有PVC概念，应用程序的可移植性就会降低，我们将在后面解释。
- StorageClass（SC） –描述基础结构提供的存储类型。 例如，您的提供商可能提供两种类型：带加密的快速SSD和不带加密的慢速HDD。
- 就像PVC一样，您可能会问为什么需要这样做？ 同样，这些抽象有助于可移植性，并使管理员可以防止草率应用程序的滥用。 我们还将在下面解释这一点。
这是描述和控制应用程序的Kubernetes抽象：
- Pod –在同一服务器上运行，一起工作并一起构成基本工作单元的一个或多个容器。
- 部署 –一种控制器，该控制器确保所需数量的应用程序Pod正在运行，并管理Pod的生命周期。 生命周期事件可能是添加更多Pod或更新版本。 Pod定义包含在Deployment的书面规范中。
- 对于客户来说，一个常见的问题是何时使用Deployment与StatefulSet。 这是一个很好的问题，我们将继续讨论。
- StatefulSet –管理整个数据库，而不是单个Pod及其PVC。
- 重要的是要记住，水平扩展的数据库（例如Cassandra）与多个可协同工作的Pod一起运行。 使用StatefulSet，您不必考虑每个Cassandra节点（实例）如何与另一个节点相关联。 Kubernetes为您做到了。
这些是可移植性和可伸缩性的基本Kubernetes原语。 这些抽象如何协同工作具有微妙而强大的美。 由于StatefulSets包装了许多基础原语，因此让我们从使用PostgreSQL的更基本示例开始。 然后，我们将直接涉及一些基元，从PVC开始，然后向上构建。
在Kubernetes上部署PostgreSQL
客户喜欢Kubernetes如何在其基础架构上管理应用程序。 当我们遍历PostgreSQL的示例时，我们看到Kubernetes原语被设计为尽可能可移植。 甚至在我们尝试将可移植性与多云等同之前，我们已经看到可移植性意味着适当的原语使应用程序可以跨服务器运行，重新运行和重新运行。
因此，可移植性和健壮性是同一枚硬币的两个方面，如果我们考虑一下，这是有道理的。 为了使应用程序能够承受故障，应用程序必须可跨服务器移植。
回到我们的PostgreSQL示例。 Pod标识容器图像和PVC。 在这里，我们将运行PostgreSQL数据库，因此容器映像适用于PostgreSQL 10.1版。 在此示例中，将Pod编写为Deployment规范中的一部分。 如果我们选择了Cassandra，我们会将Pod编写为StatefulSet的一部分。
部署不仅包含Pod定义，还允许我们在运行时对该Pod进行更新。 让我们在Deployment规范中查看所有这些内容。 我添加了评论以供解释。
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
name: postgres
spec:
template:
# Pod definition portion of this deployment specification
metadata:
labels:
app: postgres
spec:
# Container to use the application image PostgreSQL 10.1
containers:
- image: "postgres:10.1"
name: postgres
envFrom:
- configMapRef:
name: example-config
ports:
- containerPort: 5432
name: postgres
volumeMounts:
# Container to use the PVC below called ‘postgres-data’
- name: postgres-data
# Container sees itself as writing to the directory below
mountPath: /var/lib/postgresql/data
volumes:
- name: postgres-data
# PVC available to any containers in this Pod spec
persistentVolumeClaim:
claimName: postgres-data-claim在上面的示例中，Pod知道其PVC，但不（也不需要）知道PersistentVolume。 这部分可能会有点回旋，所以请耐心等待。 PVC要求一定数量的存储容量和要使用的存储类型。 PVC看起来像这样：
apiVersion: v1
metadata:
# Create a Persistent Volume using this Storage Class definition
annotations:
volume.beta.kubernetes.io/storage-class: px-postgres-sc
spec:
accessModes:
- ReadWriteOnce
resources:
# Create a Persistent Volume with 5 GB of storage capacity
requests:
storage: 5Gi到目前为止，应用程序所有者一直在描述他们的应用程序和要求。 现在，基础架构管理员可以通过发布StorageClasses定义可用的存储类型来参与其中。
将应用程序要解决的关注点与基础架构的关注点分开是很重要的：基础架构管理员需要定义共享集群中的可持续性。 如果没有这样的原语，应用程序可能会互相残废-一些Kubernetes替代品容易受到这个问题的困扰。
在下面的StorageClass规范中，所有指定此StorageClass的PVC将具有复制和加密功能，并将针对数据库I / O工作负载进行配置。 StorageClasses是特定于存储提供程序的。 在幕后，提供PersistentVolume的供应商实现了这些功能。
apiVersion: storage.k8s.io/v1beta1
metadata:
name: px-postgres-sc
provisioner: kubernetes.io/portworx-volume
parameters:
# Replicate three copies using Portworx
repl: "3"
# Tune the I/O for the volume for databases
io_profile: "db"
# Encrypt the data using a key from Key Management System
secure: "true”在Kubernetes上运行PostgreSQL
现在要安装上述所有原语，管理员将从StorageClass开始。 通常，管理员会设计几个StorageClass，从而在不同应用程序需要什么和基础架构可以支持什么之间进行权衡。
要发布第一个StorageClass，管理员对相应的YAML文件运行以下命令：
$ kubectl create -f px-storage-class.yaml
storageclass.storage.k8s.io "px-postgres-sc" created应用程序所有者现在可以使用由StorageClass定义的存储。 应用程序Pod将使用PVC请求存储。 由于这是一个新应用程序，因此将创建一个满足PVC的新PersistentVolume。 要创建PVC，我们对PVC文件运行以下命令：
$ kubectl create -f pvc.yaml
persistentvolumeclaim "postgres-data-claim" created现在我们准备部署PostgreSQL数据库。 我们的数据库将作为其中装有PostgreSQL容器的Pod运行。 由于Pod是在Deployment规范中定义的，因此我们只需在Deployment YAML文件上运行命令即可创建所有这些容器：
$ kubectl create -f postres-deployment.yaml
deployment.extensions "postgres" created我们可以向后看，看看创建了什么。 首先，我们通过运行以下命令来请求所有PVC。 在下面，我们看到我们创建的PVC处于绑定状态，这意味着它正在使用PersistentVolume。 换句话说，存储原语已准备好使用。
$ kubectl get pvc
NAME STATUS VOLUME CAPACITY STORAGE CLASS AGE
postgres... Bound pvc-3... 5Gi px-... 17s接下来，我们可以查看运行PostgreSQL容器的Pod。 在下面，我们看到PostgreSQL Pod已准备好处理请求。
$ kubectl get pods
NAME READY STATUS RESTARTS AGE
postgres-dff54d66d... 1/1 Running 0 6s退后一步，我们看到我们创建了运行数据库所需的所有原语。 不仅如此，我们还标准化了基础架构为应用程序提供的存储，从而改善了所有后续Pod的体验。 现在，我们可以使用Deployment对象控制数据库Pod，从而自动执行部分升级过程。
下图显示了整个堆栈和原语集。
最终结果是我们拥有表达生产中期望状态的语言。 我们有Kubernetes来管理应用程序以达到该目的。 而且我们有一种方法可以与其他应用程序共享我们的存储基础架构。
Portworx如何应对Kubernetes存储挑战
我们只是使用Kubernetes进行了有状态服务的部署。 在处理数据丰富的工作负载时，深入研究生产需求非常重要。 我们如何调整PersistentVolume的大小？ 在允许可移植性好处的同时，我们如何加密微服务数据？ 让我们深入研究生产中重要的这些主题。
Kubernetes原语之所以功能强大，是因为每个应用程序现在都可以轻松且独立于其他应用程序进行横向扩展（处理更多请求）。 此外，您可以使用类似的细粒度控制来更新特定组件。 但是，与任何应用程序平台一样，您需要支持这种灵活性的基础结构。 对于寻求Kubernetes收益的有状态工作负载，存储基础架构中存在许多常见的问题（与供应商无关），这带来了挑战。
影响Kubernetes上有状态工作负载的基础架构限制：
- 应用程序区分 —根据应用程序隔离和调整I / O行为，尤其是现在服务器在应用程序之间共享时。 示例：控制何时Elasticsearch删除或Cassandra压缩。
- 群集操作 -当Pod跨服务器和跨可用区域（在公共云中）扩展时，允许进行数据访问。 通常，访问存储的速度变得令人担忧。
- 监视和可见性 -在应用程序共享基础结构时了解性能。 在这里，我们可以受益于如何使用标签在Pod上进行标记，然后再对磁盘进行标记。
- 保护 -确保备份，快照和数据保护机制处理的应用程序现在是数十个Pod，而不是几个大型VM。
- 可移植性 —帮助团队在移动计算时移动其数据，以将开发集群升级为测试环境或多云工作负载。
存储和基础架构解决方案可以通过多种方式使Kubernetes成为运行有状态应用程序的最佳方法。 在Portworx，我们一直在努力使有状态工作负载与使用Kubernetes进行无状态工作负载一样容易和灵活。
以下是我们一直在其中进行投资的一些方法。
微服务优先
与过去的企业存储系统不同，PX-Enterprise是专为微服务应用程序而设计的。 我们的许多工作都用于扩展Kubernetes用户的体验，并且可以使用Kubernetes来安装，扩展和控制Portworx本身。
From: https://www.infoworld.com/article/3387982/how-to-run-stateful-applications-on-kubernetes.html
192
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
