Open richardbischof opened 1 year ago
/cc @Sgitario (kubernetes), @geoand (knative,kubernetes), @iocanel (knative,kubernetes)
@Sgitario would you like to point @richardbischof in the right direction please?
But Knative (and IBM Cloud Code Engine) expect those from the Knative Services Types and don't support creation of own Service Accounts, see https://github.com/knative/specs/blob/main/specs/serving/knative-api-specification-1.0.md#spec-3
I don't fully follow what you mean by this (I see both fields serviceAccountName
and imagePullSecrets
in the Revision spec).
Anyways, I guess you want to avoid the creation of the ServiceAccount altogether (my doubt is whether is because of Knative or because of your use case?).
At the moment, if you set the quarkus.knative.image-pull-secrets
property, this ServiceAccount resource will always be created. If you want to fix yourself, here is the logic that controls the image-pull-secrets
property: https://github.com/quarkusio/quarkus/blob/715ea8ba0862996220fea0d72eec3d90f1c88f4a/extensions/kubernetes/vanilla/deployment/src/main/java/io/quarkus/kubernetes/deployment/KnativeProcessor.java#L329.
From my point of view, the less magic we do, the better, so I would skip the service account creation when setting this property, but let me include @iocanel into the discussion that was who implemented this feature.
With this option I get an additional ServiceAccount generated, which is configured to use the secret.
Can you please elaborate what you mean by additional? It sounds as if you end up with two ServiceAccount
resources in your manifest?
But Knative (and IBM Cloud Code Engine) expect those from the Knative Services Types and don't support creation of own Service Accounts, see https://github.com/knative/specs/blob/main/specs/serving/knative-api-specification-1.0.md#spec-3
I don't see something in the provided link that suggest that creating ServiceAccounts
is not supported. So, I am thinking that I've got it completely wrong.
Let me try to these configuration options and see what the end result is, maybe then it will become clearer.
I played a little bit with it and didn't have any issues. The steps I followed where:
kubectl create secret generic my-secret --from-file=.dockerconfigjson=/home/iocanel/.docker/config.json --type=kubernetes.io/dockerconfigjson
### 2. create the app
```sh
quarkus create app hello-quarkus
cd hello quarkus
quarkus ext add kubernetes
quarkus ext add container-image-docker
quarkus.kubernetes.deployment-target=knative
quarkus.knative.image-pull-secrets=my-secret
quarkus.container-image.registry=docker.io
mvn clean package -Dquarkus.knative.deploy=true
I even experimented with adding kubernetes-client
extension that also populates a ServiceAccount
just to make sure we only get a single SA generated.
So, we would need more details in order to understand the problem.
Thank you all so far!
I want Quarkus to generate an Knative Service Definition / Revision, that references the necessary ImagePullSecret directly. Actually by now Quarkus generates an additionally ServiceAccount, that references the ImagePullSecret. Because IBM Code Engine does not allow the creation of ServiceAccounts, I can't apply the generated Manifests directly.
Hope, that this information helps. Thank you!
Description
Hello,
I want to use Quarkus with the Kubernetes Extension to Deploy to IBM Cloud Code Engine, which is basically a managed Knative. Therefore I have to build the image, push it to my private registry and then build Knative-Deployment Descriptors.
Because my image is saved in a private registry, I have to provide an ImagePullSecret. I configured in my applications.properties
quarkus.knative.image-pull-secrets=ibm-container-registry
With this option I get an additional ServiceAccount generated, which is configured to use the secret.
But Knative (and IBM Cloud Code Engine) expect those from the Knative Services Types and don't support creation of own Service Accounts, see https://github.com/knative/specs/blob/main/specs/serving/knative-api-specification-1.0.md#spec-3
If you point me in the right direction, I would love to solve this issue by myself and provide a patch.
Implementation ideas
If the Deployment Target is Knative, then don't create a new service account and instead set the image pull secret in the Service Object.