CRDs¶
CustomResourceDefinition (CRD) is a Kubernetes built-in resource for creating custom resources to further extend the Kubernetes API. Kubean provides four built-in CRDs: Cluster, ClusterOperation, Manifest, and LocalArtifact.
Cluster¶
In Kubean, you can declare (uniquely identify) a Kubernetes cluster with a Cluster
CRD. Clusters will be deployed according to their Cluster
CRDs.
Here's an example of the Cluster
CRD:
apiVersion: kubean.io/v1alpha1
kind: Cluster
metadata:
name: cluster1-offline-demo
spec:
hostsConfRef:
namespace: kubean-system
name: cluster1-offline-demo-hosts-conf
varsConfRef:
namespace: kubean-system
name: cluster1-offline-demo-vars-conf
Each field in this CRD is explained as follows:
Metadata Section¶
name
: declares a globally unique cluster.
Spec Section¶
-
hostConfRef
: a ConfigMap resource in the format of ansible inventory. It includes information about nodes in a cluster, types, and groups. For further details, refer to demo. -
name
: name of the ConfigMap referenced byhostConfRef
. -
namespace
: namespace of the ConfigMap referenced byhostConfRef
. -
varsConfRef
: a ConfigMap resource to initialize or override variable values declared in Kubespray. This is very useful if you need to execute actions offline. For its specific content, refer to demo. -
name
: name of the ConfigMap referenced byvarsConfRef
. -
namespace
: namespace of the ConfigMap referenced byvarsConfRef
. -
sshAuthRef
: a Secret resource used only in the SSH private key mode. -
name
: name of the Secret referenced bysshAuthRef
. namespace
: namespace of the Secret referenced bysshAuthRef
.
ClusterOperation¶
In Kubean, you can declare actions (deployment, upgrade, etc.) against a Kubernetes cluster with a ClusterOperation
CRD. This CRD must be correctly associated with the corresponding Cluster
CRD, which provides necessary information for executing these actions.
Here's an example of the ClusterOperation
CRD:
apiVersion: kubean.io/v1alpha1
kind: ClusterOperation
metadata:
name: cluster1-demo-ops-1
spec:
cluster: cluster1-demo
image: ghcr.m.daocloud.io/kubean-io/spray-job:latest
actionType: playbook
action: cluster.yml
preHook:
- actionType: playbook
action: ping.yml
- actionType: playbook
action: disable-firewalld.yml
postHook:
- actionType: playbook
action: kubeconfig.yml
- actionType: playbook
action: cluster-info.yml
Each field in this CRD is explained as follows:
Metadata Section¶
name
: uniquely identifies an action against the associated cluster.
Spec¶
cluster
: name of the cluster against which this action will be executed. It should be the same as the value declared in the Cluster CRD.image
: address of the Kubespray image. You can use the image in the Kubean repo or your own image.actionType
: type of the action. It currently can be set as eitherplaybook
orshell
.action
: the action to be executed. It currently can be set as either a playbook file path or a shell command.preHook
: what should be done before executing theaction
. Allow multiple values, such as test connectivity.actionType
: refer to the aboveactionType
.action
: refer to the aboveaction
.postHook
: what to do after executing theaction
. Allow multiple values, such as get the cluster status.actionType
: refer to the aboveactionType
.action
: refer to the aboveaction
.
Manifest¶
In Kubean, you can use a Manifest
CRD to create and maintain a record of components, packages, and versions used by or compatible with the current version of Kubean. You don't need to do this job manually. Kubean will take care of it for you.
Here's an example of the Manifest
CRD:
apiVersion: kubean.io/v1alpha1
kind: Manifest
metadata:
name: kubeaninfomanifest-v0-4-0-rc2
spec:
components:
- defaultVersion: v1.1.1
name: cni
versionRange:
- v1.0.1
- v1.1.1
- defaultVersion: 1.6.9
name: containerd
versionRange:
.......
- 1.6.7
- 1.6.8
- 1.6.9
- defaultVersion: ""
name: kube
versionRange:
- v1.25.3
- v1.25.2
- v1.25.1
........
- defaultVersion: v3.23.3
name: calico
versionRange:
- v3.23.3
- v3.22.4
- v3.21.6
- defaultVersion: v1.12.1
name: cilium
versionRange: []
- defaultVersion: "null"
name: etcd
versionRange:
- v3.5.3
- v3.5.4
- v3.5.5
docker:
- defaultVersion: "20.10"
os: redhat-7
versionRange:
- latest
- "18.09"
- "19.03"
- "20.10"
- stable
- edge
- defaultVersion: "20.10"
os: debian
versionRange:
- latest
- "18.09"
- "19.03"
- "20.10"
- stable
- edge
- defaultVersion: "20.10"
os: ubuntu
versionRange:
- latest
- "18.09"
- "19.03"
- "20.10"
- stable
- edge
kubeanVersion: v0.4.0-rc2
kubesprayVersion: c788620
Each field in this CRD is explained as follows:
components
: declares versions of images or binary files.name
: name of a component.defaultVersion
: default versions of the component.versionRange
: supported component versions.docker
: manages Docker versions.os
: supported operating systems.defaultVersion
: the default version used.versionRange
: supported versions.kubeanVersion
: version of Kubean.kubesprayVersion
: version of the Kubespray used in Kubean.
LocalArtifact¶
In Kubean, you can use a LocalArtifact
CRD to record components and their versions supported by Kubean's offline package. You don't need to do this job manually. Kubean will take care of it for you.
Here's an example of the LocalArtifact
CRD:
apiVersion: kubean.io/v1alpha1
kind: LocalArtifactSet
metadata:
name: "localartifactset-1709796014"
labels:
kubean.io/sprayRelease: master
spec:
kubespray: "989ba207e9da2e1364f375450561d08af80c8535"
items:
- name: cilium
versionRange:
- "v1.13.4"
- name: flannel
versionRange:
- "v0.22.0"
- name: kube_ovn
versionRange:
- "v1.11.5"
- name: runc
versionRange:
- "v1.1.12"
- name: kube
versionRange:
- "v1.1.12"
- name: cni
versionRange:
- "v1.3.0"
- name: calico
versionRange:
- "v3.26.4"
- name: containerd
versionRange:
- "1.7.13"
Each field in this CRD is explained as follows:
arch
: a list of supported CPU architectures.kubespray
: Kubespray version used.docker
: manages Docker versions.os
: operating systems supported by DockerversionRange
: a list of supported Docker versions.items
: manages versions of other components.name
: name of a component.versionRange
: a list of supported versions of the component.