crd in Kubernetes

Lesedauer < 1 Minute

Die Kubernetes API ist bekannt dafür das sie ziemlich leicht erweitert werden kann.

Eine Funktion, die ich hier sehr gerne nutze, sind sogenannte CRD aka  Custom Resource Definitions.

Das ermöglicht die API um weitere eigene schematas zu erweitern.

Ich nutze sowas um Automatisierungen wie z.b ansible playbooks als entity der API bekannt zu machen z. B.

kubectl get jobtemplate

So lässt sich über kubectl im Cluster abfragen welche CRD hinterlegt ist.

NAME         STATUS      MESSAGE
helloworld   Succeeded   Hello world

So würde die Definition einer CRD aussehen, zusammen mit HELM als Package Manager lassen sich so super solche Objekte automatisieren und nutzen.

# jobtemplate-crd.yaml
apiVersion: apiextensions.k8s.io/v1
kind: CustomResourceDefinition
metadata:
  name: jobtemplates.myorg.io
spec:
  group: myorg.io
  versions:
    - name: v1
      served: true
      storage: true
      schema:
        openAPIV3Schema:
          type: object
          properties:
            spec:
              type: object
              properties:
                playbook:
                  type: string
      additionalPrinterColumns:
        - name: Status
          type: string
          jsonPath: .status.status
        - name: Message
          type: string
          jsonPath: .status.message
  scope: Namespaced
  names:
    plural: jobtemplates
    singular: jobtemplate
    kind: JobTemplate
    shortNames:
      - jt

Als Content würde das ganze dann ungefähr so aussehen:

# hello-world-jobtemplate.yaml
apiVersion: myorg.io/v1
kind: JobTemplate
metadata:
  name: hello-world
spec:
  playbook: |
    - name: Hello world playbook
      hosts: localhost
      gather_facts: false
      tasks:
        - name: Say Hello
          debug:
            msg: "Hello world"


Nutzt Ihr auch eigene CRD in Kubernetes?

0 Comments

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert