-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Doesn't work reject for scaling in StatefulSet. #120
Comments
Hi @ttsrg, Also, are you deploying the ModRule and the StatefulSet at the same time to the same namespace? If so, you might want to make sure the ModRule is deployed ahead of time. You can also deploy the ModRule as a cluster-wide rule (by deploying it to namespace |
Hi @vassilvk
No, I don't.
Yes, i did. "namespace: redis" confirms it.
No, I've investigated only UPDATE func via changing scale.
Shure, I'll be do it.
But does not work when changes scale in sts , I guess it has to exec UPDATE admission. Also I've faced problem with "Reject" rule: operator log writes redundant data. Should I open another issue? 16 same messages on 1 event: |
Just so I understand, the rule does reject a StatefulSet
If this is about a rejection ModRule you placed on |
Yes, I used such commands: |
Ah, I see. This might be because scaling of Kubernetes scalable resources is performed through update operations against the You might be able to reject updates to the scale of StatefulSet by targeting the Scale sub-resource. Since the Scale manifest's Spec has Replicas, the logic of your original ModRule should work, but we need to change the kind to target the Scale subresource. The only tricky part is to figure out how Kubernetes encodes the Scale kind in the body of the webhook request. First, you need to add Then I would try this (same as your original ModRule, but targets kind apiVersion: api.kubemod.io/v1beta1
kind: ModRule
metadata:
name: reject-sts-scale-control-clients
namespace: redis
spec:
type: Reject
rejectMessage: 'More than 3 pods are not allowed, but ordered are - {{ .Target.spec.replicas }}'
admissionOperations:
- UPDATE
match:
- select: '$.kind'
matchValues:
- 'StatefulSet/Scale'
- select: '$.spec.replicas > 3' If kind ...
match:
- select: '$.kind'
matchRegex: '(?i)scale'
... Then I would modify the reject message to include the Note that scaling works like this for all scalable objects - including Deployments, so you might want to rethink your Deployment scale out rejection and instead of blocking it at the ReplicaSet, you block it at Kind Deployment and the Scale subresource of Deployment, using the same ModRule, but for kind Deployment and Deployment/Scale (or whatever the name of the Scale kind turns out to be). If you decide to control deployments Scale the same way, don't forget to add |
:( No one variant hadn't worked. |
Also I faced problems w non-working probes,/metrics - may be necessary rebuild container using any extra options? |
Not sure what you mean by this. Are you having trouble installing/running the |
Regarding:
Hopefully I'll have some time soon to take a closer look and try to reproduce. |
That's great |
Happy NY |
Hello. Thanks a million for your operator.
But i can't realize reject for sts.
I use next modrule:
And it doesn't work ( instead of the Deployment via replicaset).
The text was updated successfully, but these errors were encountered: