Michael:
When working with the course in the area of “Monitoring Kubernetes” you come into contact with CRDs again (Alertmanager Rules). I know:
k get crd customresourcename
k describe crd customresourcename
I mean you can also use:
k get customresourcename
k get <http://alertmanagers.monitoring.coreos.com|alertmanagers.monitoring.coreos.com> -o yaml
apiVersion: v1
items: []
kind: List
metadata:
resourceVersion: ""
But in this case nothing really makes sense, anyway this is how it is useed in the course.
If I hadn’t already seen the spelling, I would say it is wrong. For the course, and with an actual Kubernetes version it doesn’t work.
Can someone please explain this
Alistair Mackay:
I am not sure what your question is.
k get <http://alertmanagers.monitoring.coreos.com|alertmanagers.monitoring.coreos.com> -o yaml
The result you are getting indicates that there are no alertmanager resources deployed.
This particular CRD controls the creation of alertmanager instances by the prometheus operator.
Michael:
My question is based on this and other slides. I suspect that the kubectl line is not completely wrong in the slide,
just because it doesn’t work for me. If so, I would like to know the difference between
kubectl get crd
and that in the Screenshot. So whether that in the screenshot shows a diffent output.
Michael:
The output on my lab cluster is, i think there are resources deployed:
$ k get crd
NAME CREATED AT
<http://alertmanagerconfigs.monitoring.coreos.com|alertmanagerconfigs.monitoring.coreos.com> 2023-06-19T17:30:53Z
<http://alertmanagers.monitoring.coreos.com|alertmanagers.monitoring.coreos.com> 2023-06-19T17:30:53Z
...
$ k get crd <http://alertmanagers.monitoring.coreos.com|alertmanagers.monitoring.coreos.com> -o yaml | head -10
apiVersion: <http://apiextensions.k8s.io/v1|apiextensions.k8s.io/v1>
kind: CustomResourceDefinition
metadata:
annotations:
<http://controller-gen.kubebuilder.io/version|controller-gen.kubebuilder.io/version>: v0.11.1
creationTimestamp: "2023-06-19T17:30:53Z"
generation: 1
name: <http://alertmanagers.monitoring.coreos.com|alertmanagers.monitoring.coreos.com>
resourceVersion: "51049"
uid: a8c15d79-5e4e-4249-a7cf-76961f2cbea1
lard@grafana ~ k get crd <http://alertmanagers.monitoring.coreos.com|alertmanagers.monitoring.coreos.com> -o yaml | head -20
apiVersion: <http://apiextensions.k8s.io/v1|apiextensions.k8s.io/v1>
kind: CustomResourceDefinition
metadata:
annotations:
<http://controller-gen.kubebuilder.io/version|controller-gen.kubebuilder.io/version>: v0.11.1
creationTimestamp: "2023-06-19T17:30:53Z"
generation: 1
name: <http://alertmanagers.monitoring.coreos.com|alertmanagers.monitoring.coreos.com>
resourceVersion: "51049"
uid: a8c15d79-5e4e-4249-a7cf-76961f2cbea1
spec:
conversion:
strategy: None
group: <http://monitoring.coreos.com|monitoring.coreos.com>
names:
categories:
- prometheus-operator
kind: Alertmanager
listKind: AlertmanagerList
plural: alertmanagers
Alistair Mackay:
k get crd
lists all custom resource definitions (CRDs) installed in the cluster
k get crd alertmanagers.monitoring.coreos.com -o yaml
is just getting the YAML for that particular custom resource definition.
k get alertmanagers.monitoring.coreos.com
Is getting any resources that have been deployed using the alertmanagers CRD. If you had deployed one, then it would look like this (with -o yaml)
apiVersion: monitoring.coreos.com/v1
kind: Alertmanager
metadata:
name: example
spec:
replicas: 3
Prometheus operator would create a 3 replica deployment of Alert Manager.
This is covered in CKAD, however a custom resource definition is custom because it is not one of the built-in resources (e.g. Pod, Deployment etc) that are managed by kube-controller-manager.
A custom resource definition allows you to extend the capabilities of API server allowing it to accept and validate the custom resource - which it then stores in etcd.
A CRD will have an associated operator (usually running as a deployment, and in this case it is the Prometheus operator), which runs its own controller loop that will be notified that one of its custom resources has been applied, so it will then act upon it.
I have even created an operator to manage image pull secrets for AWS ECR - for which AWS changes the password every 12 hours.
The custom resource is this https://github.com/fireflycons/ecr-secret-operator#custom-resources
The CRD is this: https://github.com/fireflycons/ecr-secret-operator/blob/master/config/crd/bases/secrets.fireflycons.io_ecrsecrets.yaml
And the controller is this: https://github.com/fireflycons/ecr-secret-operator/blob/master/controllers/ecrsecret_controller.go#L70
Michael:
That’s really a great explanation.
I’ll probably check my Prometheus installation again. So far I haven’t had any problems with it.
Thank you very much!
