Kubernetes CRD：自定义资源类型

最新推荐文章于 2024-07-19 17:27:36 发布

Spring_java_gg

最新推荐文章于 2024-07-19 17:27:36 发布

阅读量782

点赞数

分类专栏： Kubernetes 文章标签： python java 大数据编程语言数据库

原文链接：https://mp.weixin.qq.com/s?__biz=MzI3NTEwOTA4OQ==&mid=2649181115&idx=1&sn=842381c69528625a10a9daeab67a2f83&chksm=f31a2e35c46da723d7adbcd3ed6f03317fd94f208a1cd8ddc60616914d532ef26aa575dc0091&scene=126&&sessionid=0

版权

Kubernetes 专栏收录该内容

86 篇文章 0 订阅

订阅专栏

Kubernetes 是一个功能强大的基础设施，具有很多功能，但有时您可能需要扩展该功能以更好地适应您的用例。这就是自定义资源定义 (CRD) 的用武之地。CRD 允许您引入自己的资源类型，这些类型遵循第一方核心资源设置的相同模式。在本文中，您将看到如何定义 CRD 并使用它来创建自定义资源。您还将看到一些非常适合 CRD 的用例示例，以及一些不适合的用例。

什么是 CRD？

在 Kubernetes 中，资源本质上是一个类似对象的集合，可以通过 Kubernetes API 访问。Kubernetes 默认有几种资源，你可能很熟悉，包括 Pods、Deployments、ReplicaSets 等。CRD 是 Kubernetes 允许你扩展 Kubernetes API 的方式，以存储和访问你自己的 API 对象。这意味着你可以用与核心资源相同的方式来处理它们。

以这种方式创建自定义资源有一些好处。CRD 与核心资源一起存储在 etcd 中，可以利用相同的功能，如创建副本集和生命周期管理。这可以节省大量的精力，因为你不必自己建立它，而是可以依靠一个众所周知的、稳定的 K8s 基础设施。

值得注意的是，CRD 本身只是数据。它们没有附加任何逻辑，也没有任何特殊行为。它们的主要目的是提供一种机制，用于创建、存储和公开包含你认为有用的数据的 Kubernetes API 对象。通过为这些自定义资源实现控制器或 operators，可以将更多高级功能带入其中，这使得你可以扩展 Kubernetes 的行为，而不需要修改底层代码。这与 CRD 搭配得很好，在两者之间，你可以实现一些相对高级的特性和功能。本文将不涉及控制器和 operators，但请记住，它们将是许多涉及 CRD 的工作流程的行为方面。

创建 CRD 和 Kubernetes 中的大多数事情一样，都是通过 YAML 文件完成的。以下面这个来自官方文档的基本资源定义为例。

apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  # name must match the spec fields below, and be in the form: <plural>.<group>
  name: crontabs.stable.example.com
spec:
  # group name to use for REST API: /apis/<group>/<version>
  group: stable.example.com
  # list of versions supported by this CustomResourceDefinition
  versions:
 - name: v1
   # Each version can be enabled/disabled by Served flag.
   served: true
   # One and only one version must be marked as the storage version.
   storage: true
   schema:
     openAPIV3Schema:
       type: object
       properties:
         spec:
           type: object
           properties:
             cronSpec:
                 type: string
             image:
                 type: string
             replicas:
                 type: integer
  # either Namespaced or Cluster
  scope: Namespaced
  names:
 # plural name to be used in the URL: /apis/<group>/<version>/<plural>
 plural: crontabs
 # singular name to be used as an alias on the CLI and for display
 singular: crontab
 # kind is normally the CamelCased singular type. Your resource manifests use this.
 kind: CronTab
 # shortNames allow shorter string to match your resource on the CLI
 shortNames:
   - ct

这本质上是一个赤裸裸的 CRD，它具有进行有意义的解析所需的最小属性集。这里最有趣的部分是名称和模式。名称是字符串，我们将能够使用 API 或 kubectl 与该资源互动。在这种情况下，你可以用kubectl get crontabs，它将显示任何这种类型的自定义资源。这些资源中的每一个都会根据这里指定的模式包含数据。记住，如果没有控制器或其他东西来使用它们，自定义资源本质上只是声明性 API。所以声明是相当重要的，因为它将定义该对象的形状。在本例中，模式包含一个 "cronSpec"，它表示 CronJob 应该多长时间运行一次，以及一个镜像，CronJob 大概会运行这个镜像。

如果你自己跟着做，把这个片段的内容保存到一个文件里，比如crd.yaml，然后运行以下命令：kubectl create -f crd.yaml。

这将在你的集群上创建自定义资源类型。从这里，你可以使用 CRD 创建资源对象，其 YAML 如下。

apiVersion: "stable.example.com/v1"
kind: CronTab
metadata:
  name: my-crontab
spec:
  cronSpec: "* * * * */5"
  image: hello-world

将其保存为一个文件，如cron.yaml，然后运行kubectl apply -f cron.yaml。这将使用你的 CRD 创建一个资源。同样，如果没有一个控制器来处理这个自定义资源，它只是一个数据对象，不会像传统的 CronJob 那样在时间表上实际做任何事情。你可以通过运行kubectl get crontabs看到你刚刚创建的新资源。

因为 CRD 本质上是简单的数据对象，所以很多用例都可以使用它们，但也有很多场景可能是不合适的。要确定 CRD 是否适合你的场景，需要考虑多种因素。与其他机制相比，CRD 的主要好处是，它在 Kubernetes 集群中拥有自然的、一等公民的身份。这意味着它可以利用命名空间等东西，可以通过 kubectl 进行交互，并可以用 Kubernetes UI 工具进行监控。

检查这些特征是否对你的场景有好处是很重要的。例如，在许多情况下，将资源范围设定为特定命名空间是有益的。考虑一下这样的情况：你在多个命名空间中运行同一个应用程序，也许是生产和非生产命名空间。像上面的 CronTab 例子那样在不同的命名空间中运行将是有利的。你不太可能想在生产和非生产之间混合你的 CronJob。这使得它在这种情况下成为自定义资源的一个很好的选择。

另一方面，你可能有一些东西可以被所有的应用程序实例共享，而不管命名空间如何。以通配符 SSL 证书细节为例。虽然在技术上可以将这些数据存储在自定义资源中，但在这种情况下，这并不是最好的方法。同样的细节可能会被多个命名空间共享，所以命名空间限制可能并不可取。

有效地使用 CRD

与任何工具一样，CRD 也存在一定约束。CRD 提供了一种强大的方式，可以将 Kubernetes 与用例整合在一起，但应该充分考虑场景是否合适。如前所述，CRD 提供的最重要的优势是它们与 Kubernetes 生态系统的紧密集成，包括 UI 工具、CLI 和 API 客户端，以及像 Finalizers 这样的支持功能。如果这些特征对你的场景都没有好处，你最好避免使用 CRD，而选择更传统的实现。

当评估你对 CRD 的潜在使用场景时，考虑复杂性也是至关重要的。一般来说，如果复杂的解决方案不能提供相对的受益，还是建议建议避免使用。考虑到这一点，评估那些可能帮助你解决问题的最佳实践。虽然完全可以用 CRD 来解决你的问题，但当付出的代价高于受益时，需要谨慎选择。考虑一个案例，你可以创建一个 CRD，将部署、服务和入口资源全部捆绑到一个自定义资源中。即你需要一个自定义的控制器或 operator 才能工作，这种方法为一个已经解决的问题增加了不必要的复杂性。因为当人们使用 Kubernetes 时，他们希望这些东西都是独立的。即使你设法把它们合并到一个 CRD 中，对于项目的新人来说，难以理解，而且也不会增加额外的收益。出于这个原因，这个场景可能不太适合 CRD。

总结

如您所见，如果场景合适，创建 CRD 是一个相对简单的过程。评估您的场景以确保 CRD 能够很好地解决您的问题并且不会使事情变得不必要地复杂，这一点至关重要。如果 CRD 非常适合您的场景，那么它们可能非常有价值，因为它们与您的 Kubernetes 集群提供了比其他方式更紧密的集成。如果 CRD 看起来很适合您，您可以进一步研究控制器，为它们添加一些自定义行为和功能，而不仅仅是简单的对象。如果您只是在寻找一种“以 Kubernetes 方式”处理某些数据的方法，那么 CRD 很可能会满足您的需求。

原文：https://loft-sh.medium.com/kubernetes-crds-custom-resource-definitions-5147ed3d9299