-
Notifications
You must be signed in to change notification settings - Fork 193
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
Extend TektonConfig with spec.config.affinity inputs #1824
Comments
Hi @jsteenb2 thanks to reach us. from apiVersion: operator.tekton.dev/v1alpha1
kind: TektonConfig
metadata:
name: config
spec:
pipeline:
options:
deployments:
tekton-pipelines-controller:
spec:
template:
spec:
affinity:
nodeAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
nodeSelectorTerms:
- matchExpressions:
- key: kubernetes.io/os
operator: NotIn
values:
- windows
- key: node-role.kubernetes.io/restricted-egress
operator: In
values:
- ''
nodeSelector:
tolerations:
- effect: NoSchedule
key: node-role.kubernetes.io/restricted-egress
operator: Exists
topologySpreadConstraints: However the |
ohhh interesting, thank you! I'll give this a shot today 👍 |
would be great to see an example of what the pod_template woudl look like integrating into this. The options field was opaque in its structure to me. I never would have guessed I could have done what you outlined above. Extending the docs here would be immensely helpful 🙏 |
@jkandasa , is there a way to set the affinity and tolerations for all deployments? Or do we have to list them all out separately in the options? I'm using yaml references, but it feels suboptimal having to map this to each individually. |
@jsteenb2 you have to add the entry to each deployment separately in the options. |
gotcha, that's less than ideal, but workable on our end |
Feature request
We're actively deploying into restricted egress subnets. One thing we have to do now is update the tekton controller deployment resources with the affinity updates. What we want to do is add it into the tekton config alongside our tolerations. This would keep it concise, and remove a lot of burden of having to download and change the release.yaml resources. Looking at affinity assistant, and it doesn't look like it'll solve our needs. The following is our desired output:
Use case
We're usign tekton for a build pipeline, and we need to run that pipeline in a restricted egress subnet. Atm, it requires a lot of updates to the raw yaml releases, which is burdensome and error prone.
The text was updated successfully, but these errors were encountered: