kubernetes crd - ghdrako/doc_snipets GitHub Wiki
Usually CRDs are combined with custom controllers. Custom controllers under the hood are just applications or scripts written in your programming language of choice. They’re deployed on the cluster as pods, and their job is to listen to the Kubernetes API and perform some actions based on defined logic.
list all custom resource definitions installed on your cluster
$ kubectl get crd
addons.k3s.cattle.io 2022-01-23T12:48:31Z
helmcharts.helm.cattle.io 2022-01-23T12:48:31Z
$ kubectl api-resources | grep addons
output comes in the form of <object>.<group>. We canexecute commands like kubectl get addons, kubectl get helmcharts.
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
# Name of your CRD. Must match the spec block below, and be in the form: <plural>.<group>
name: routers.example.com
spec:
# Group name to use for REST API: /apis/<group>/<version>
group: example.com
names:
# Plural name to be used in the URL: /apis/<group>/<version>/<plural>
plural: routers
# Singular name to be used as an alias on the CLI and for display
singular: router
# Kind is normally the CamelCased singular type. Your resource manifests use this.
kind: Router
# ShortNames allow shorter string to match your resource on the CLI
shortNames:
- rt
# Scope can be either Namespaced or Cluster-wide
scope: Cluster
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:
dataCenter:
type: string
rack:
type: integer
type:
type: string
enum:
- f5
- virtual
required: ["dataCenter", "rack", "type"]
required: ["spec"]
apiVersion: example.com/v1
kind: Router
metadata:
name: example-router
spec:
dataCenter: eu-1
rack: 3
type: virtual
kubectl apply -f router-CRD.yaml
kubectl apply - f example-router.yaml
kubectl get routers