تعريفات الموارد المخصّصة (CRDs)

Welcome! In this lesson, we'll explore Custom Resource Definitions (CRDs). CRDs allow you to extend Kubernetes by defining your own custom resource types.

Think of it as teaching Kubernetes new words and concepts, so it can manage application-specific objects just like it manages built-in ones like Pods or Deployments.

Kubernetes provides powerful primitives like Pods, Deployments, and Services. But what if your application needs to manage a unique kind of object, like a database cluster, a serverless function, or a custom build pipeline?

• Domain-Specific Objects: Define resources tailored to your application's unique needs.
• Abstraction: Simplify complex application deployments into a single, manageable resource.
• Kubernetes Native: Leverage Kubernetes's declarative API, tooling (kubectl), and watch mechanisms for your custom objects.

Kubernetes comes with many built-in or 'core' resources you already know:

• Core Resources: Pod, Deployment, Service, ConfigMap. These are part of the standard Kubernetes API.
• Custom Resources: These are resources you define using CRDs. They behave just like core resources but represent your own application-specific concepts.

Once a CRD is created, you can create and manage instances of your custom resource using kubectl, just like any other Kubernetes object.

A CRD is itself a Kubernetes resource defined in YAML. Here's what some key fields mean:

• apiVersion: apiextensions.k8s.io/v1: Specifies the API version for the CRD itself.
• kind: CustomResourceDefinition: Identifies this YAML as a CRD definition.
• metadata.name: The unique name for your CRD, typically in the format <plural>.<group>.

Let's look at defining the core specification next.

The spec section of a CRD defines the custom resource's properties:

• spec.group: The API group for your custom resource (e.g., example.com). This helps organize your custom resources.
• spec.versions: A list of supported versions for your custom resource (e.g., v1alpha1, v1). Each version can have its own schema.
• spec.scope: Defines if your custom resource is Namespaced (like Pods) or Cluster (like Nodes).

More important fields in the spec:

• spec.names: Defines how your custom resource will be referred to:
  • plural: The plural name used in kubectl get (e.g., webservers).
  • singular: The singular name (e.g., webserver).
  • kind: The CamelCase name for the resource object (e.g., WebServer).
  • shortNames: Optional, short aliases (e.g., ws).
• spec.versions[].schema.openAPIV3Schema: This is crucial! It defines the structure and validation rules for your custom resource's data.

Here's a basic CRD for a WebServer resource. Notice how it defines the group, versions, names, and a simple schema for its properties (like image and replicas).

Once you have your CRD YAML file (e.g., webserver-crd.yaml), you can apply it to your Kubernetes cluster using kubectl. This registers your new resource type with Kubernetes.

It might take a few seconds for the API server to fully acknowledge the new type.

After the CRD is applied, you can create instances of your WebServer custom resource. This YAML defines a specific WebServer object with its own image and replicas values, conforming to the schema you defined.

You can manage this object just like any other Kubernetes resource.

Now that you've defined a CRD and created an instance, you can use standard kubectl commands to interact with your custom resources:

• kubectl get webservers: List all WebServer objects.
• kubectl get ws: Use the short name.
• kubectl describe webserver my-first-webserver: Get detailed information about a specific WebServer instance.

This seamless integration is a key benefit of CRDs!

Great job! You've learned about Custom Resource Definitions!

• CRDs allow you to extend the Kubernetes API with your own custom resource types.
• They enable Kubernetes to manage domain-specific objects using its native API and tooling.
• A CRD defines the schema and properties of your custom resource.
• Once defined, you can create and interact with instances of your custom resource using kubectl.

Next, we'll see how Operators leverage CRDs to automate complex application management!