Aggressive Keycloak polling/high bandwidth usage #65
Comments
|
Thanks for bringing that up - I did not investigate yet, but will do asap. |
|
@Tuhis can you give us the resource with a --show-managed-fields ? wonder if we have a diff all the time which causes an update |
|
@haarchri which resource you're referring to? |
|
There iare currently 5 Protocolmapper, 3 Client and 6 Role resources managed by the provider |
|
Maybe this snippet of logs helps to limit the number or type of resources you'd need for closer analysis? |
|
And here is one of the ProtocolMappers: apiVersion: client.keycloak.crossplane.io/v1alpha1
kind: ProtocolMapper
metadata:
annotations:
crossplane.io/external-create-pending: "2024-02-22T20:52:52Z"
crossplane.io/external-create-succeeded: "2024-02-22T20:52:52Z"
crossplane.io/external-name: d1006a4f-3943-440a-8a08-eeb7bf4f2f82
upjet.crossplane.io/provider-meta: "null"
creationTimestamp: "2024-02-22T20:52:52Z"
finalizers:
- finalizer.managedresource.crossplane.io
generation: 2
labels:
kustomize.toolkit.fluxcd.io/name: grafana-iam
kustomize.toolkit.fluxcd.io/namespace: flux-system
managedFields:
- apiVersion: client.keycloak.crossplane.io/v1alpha1
fieldsType: FieldsV1
fieldsV1:
f:metadata:
f:labels:
f:kustomize.toolkit.fluxcd.io/name: {}
f:kustomize.toolkit.fluxcd.io/namespace: {}
f:spec:
f:forProvider:
f:clientIdSelector:
f:matchLabels:
f:crossplane.io/claim-name: {}
f:crossplane.io/claim-namespace: {}
f:policy:
f:resolution: {}
f:config:
f:access.token.claim: {}
f:claim.name: {}
f:id.token.claim: {}
f:introspection.token.claim: {}
f:jsonType.label: {}
f:multivalued: {}
f:user.attribute: {}
f:userinfo.token.claim: {}
f:usermodel.clientRoleMapping.clientId: {}
f:usermodel.clientRoleMapping.rolePrefix: {}
f:name: {}
f:protocol: {}
f:protocolMapper: {}
f:realmId: {}
manager: kustomize-controller
operation: Apply
time: "2024-02-22T20:52:52Z"
- apiVersion: client.keycloak.crossplane.io/v1alpha1
fieldsType: FieldsV1
fieldsV1:
f:metadata:
f:annotations:
.: {}
f:crossplane.io/external-create-pending: {}
f:crossplane.io/external-create-succeeded: {}
f:crossplane.io/external-name: {}
f:upjet.crossplane.io/provider-meta: {}
f:finalizers:
.: {}
v:"finalizer.managedresource.crossplane.io": {}
f:spec:
f:forProvider:
f:clientId: {}
f:clientIdRef:
.: {}
f:name: {}
f:initProvider: {}
manager: provider
operation: Update
time: "2024-02-22T20:52:53Z"
- apiVersion: client.keycloak.crossplane.io/v1alpha1
fieldsType: FieldsV1
fieldsV1:
f:status:
.: {}
f:atProvider:
.: {}
f:clientId: {}
f:config:
.: {}
f:access.token.claim: {}
f:claim.name: {}
f:id.token.claim: {}
f:introspection.token.claim: {}
f:jsonType.label: {}
f:multivalued: {}
f:user.attribute: {}
f:userinfo.token.claim: {}
f:usermodel.clientRoleMapping.clientId: {}
f:id: {}
f:name: {}
f:protocol: {}
f:protocolMapper: {}
f:realmId: {}
f:conditions:
.: {}
k:{"type":"AsyncOperation"}:
.: {}
f:lastTransitionTime: {}
f:reason: {}
f:status: {}
f:type: {}
k:{"type":"LastAsyncOperation"}:
.: {}
f:lastTransitionTime: {}
f:reason: {}
f:status: {}
f:type: {}
k:{"type":"Ready"}:
.: {}
f:lastTransitionTime: {}
f:reason: {}
f:status: {}
f:type: {}
k:{"type":"Synced"}:
.: {}
f:lastTransitionTime: {}
f:reason: {}
f:status: {}
f:type: {}
manager: provider
operation: Update
subresource: status
time: "2024-03-11T20:27:09Z"
name: grafana-client-roles-mapper
resourceVersion: "71952824"
uid: 85a38f7a-ee17-452b-be8d-48cde774c3f9
spec:
deletionPolicy: Delete
forProvider:
clientId: c9e7418d-eeb9-4278-8e04-3f1521464581
clientIdRef:
name: grafana-4dlnw-pmfpf
clientIdSelector:
matchLabels:
crossplane.io/claim-name: grafana
crossplane.io/claim-namespace: monitoring
policy:
resolution: Required
config:
access.token.claim: "false"
claim.name: resource_access.$${client_id}.roles
id.token.claim: "true"
introspection.token.claim: "false"
jsonType.label: String
multivalued: "true"
user.attribute: foo
userinfo.token.claim: "false"
usermodel.clientRoleMapping.clientId: redacted-grafana
usermodel.clientRoleMapping.rolePrefix: ""
name: client roles
protocol: openid-connect
protocolMapper: oidc-usermodel-client-role-mapper
realmId: redacted-prod
initProvider: {}
managementPolicies:
- '*'
providerConfigRef:
name: default
status:
atProvider:
clientId: c9e7418d-eeb9-4278-8e04-3f1521464581
config:
access.token.claim: "false"
claim.name: resource_access.${client_id}.roles
id.token.claim: "true"
introspection.token.claim: "false"
jsonType.label: String
multivalued: "true"
user.attribute: foo
userinfo.token.claim: "false"
usermodel.clientRoleMapping.clientId: redacted-grafana
id: d1006a4f-3943-440a-8a08-eeb7bf4f2f82
name: client roles
protocol: openid-connect
protocolMapper: oidc-usermodel-client-role-mapper
realmId: redacted-prod
conditions:
- lastTransitionTime: "2024-02-22T20:52:54Z"
reason: Available
status: "True"
type: Ready
- lastTransitionTime: "2024-03-11T13:44:11Z"
reason: ReconcileSuccess
status: "True"
type: Synced
- lastTransitionTime: "2024-03-11T20:27:09Z"
reason: Finished
status: "True"
type: AsyncOperation
- lastTransitionTime: "2024-03-11T13:44:11Z"
reason: Success
status: "True"
type: LastAsyncOperation |
|
In addition to the bandwidth usage, the provider used about 4 vCPUs and 4 GiB memory before applying limits of 1 vCPU and 2 GiB memory. |
|
Looks Like that is Not in status.atProvider - so this causes the diff ?! |
|
@haarchri you are right! That plus few other similar differences in ProtocolMapper resources was the diff. Once removing the empty value from input, the reconciliation quieted down. Thank you for your help in figuring this one out! It seems that Keycloak API sends only the config params for which the value differs from Keycloak default value. However, the Keycloak web console sends to the Keycloak all the config options visible in the UI, no matter whether they're at default or not. As I've used the web console requests as reference for defining ProtocolMapper resources, I defined also those config options with default or empty value too. My issue is now solved, but the question remains whether the provider should be updated to ignore the diff for fields where API doesn't give any value? |
|
Yeah, we have to evaluate if initProvider or ignoring the fields in lateInitializers help to avoid the issue. |
Open
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The provider seems to authenticate to keycloak at least tens of times per minute. I've no further insight whether it is polling something, but compared to other crossplane providers the network I/O seems to be quite high at roughly 3.4 MB/s. There iare currently 5 Protocolmapper, 3 Client and 6 Role resources managed by the provider. In comparison aws family providers use 5-20 kB/s with more resources managed by them.
This sounds pretty excessive to me. Is this expected behavior of the provider? Is there something I could help with to get into the root cause of the behavior and possibly get rid of that?
The text was updated successfully, but these errors were encountered: