0

The operator is https://operatorhub.io/operator/keycloak-operator version 11.0.0.

The cluster is Kubernetes version 1.18.12.

I was able to follow the steps from OperatorHub.io to install the Operator Lifecycle Manager and the Keycloak "OperatorGroup" and "Subscription". It took much longer than I was expecting (maybe 20 minutes?), but eventually the corresponding "ClusterServiceVersion" was created.

However, now when I try to use it by creating the following resource, it doesn't seem to be doing anything at all:

apiVersion: keycloak.org/v1alpha1
kind: Keycloak
metadata:
  name: example-keycloak
  namespace: keycloak
  labels:
    app: sso
spec:
  instances: 1
  externalAccess:
    enabled: true
  extensions:
    - https://github.com/aerogear/keycloak-metrics-spi/releases/download/1.0.4/keycloak-metrics-spi-1.0.4.jar

It accepts the new resource, so I know the CRD is in place. The documentation states that it should create a stateful set, an ingress, and more, but it just doesn't seem to create anything.

I checked the cluster logs and this is the error that is jumping out to me:

olm-operator ERROR controllers.operator Could not update Operator status {"request": "/keycloak-operator.my-keycloak-operator", "error": "Operation cannot be fulfilled on operators.operators.coreos.com \"keycloak-operator.my-keycloak-operator\": the object has been modified; please apply your changes to the latest version and try again"}

I have quite a bit of experience with plain kubernetes, but I'm brand new to "operators" and so I'm really not sure where to look next wrt what might be going wrong.

Any hints/suggestions/explanations?

UPDATE: I was creating the keycloak resource in a namespace OTHER than the one I installed the operator into. Since it allowed me to create the custom resource (Kind: Keycloak) into this namespace, I thought this was supported. However, when I created the keycloak resource to the same namespace where the operator was installed (my-keycloak-operator), then it actually tried to do something. Its still failing to bring up the pod, mind you, but at least its trying to do something. Will leave this question open for a bit to see if the "Could not update Operator status" is something I should be concerned about or not...

dreamcrash
  • 47,137
  • 25
  • 94
  • 117
lmsurprenant
  • 1,723
  • 2
  • 14
  • 28

1 Answers1

1

It looks like the operator or/and the components that it wants to bring up cannot do a write (POST/PUT) to the kube-apiserver.

From what you describe, it appears that the first time when you installed the operator on a different namespace it just didn't have permissions to bring up anything at all. The second time when you installed it on the right namespace it looks like the operator was able to talk to the kube-apiserver but the components that it's bring up (Keycloak, etc) are not able to.

I would check the logs on the kube-apiserver (control plane) to see if you have some unauthorized requests, also check the log files of the components (pods, deployments, etc) that the operator is trying to bring up.

If you have unauthorized requests you may have to manually update the RBAC rules. Finally, I would check with IBM cloud to see what specific permission its K8s control plane could have that is preventing applications to talk to it (the kube-apiserver).

✌️

Rico
  • 58,485
  • 12
  • 111
  • 141