-
Notifications
You must be signed in to change notification settings - Fork 226
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
Support kustomize
hydration in skaffold
#1447
Comments
HI @yuwenma I think that kind of a request is more of a project than a feature. Are we talking about making it easy for people who use kustomize to use kpt? What is the user scenario here? |
I think this is too broad of an issue and we would need to decompose this to make it actionable. I am going to close this as "won't fix" for now but happy to talk in more detail about the workflows we want to support. |
@mikebz Yeah, agree this would be a big effort. This is for skaffold to use kustomize in a kpt hydration pipeline. We would need a progress tracker. What do you suggest on tracking the kustomize function? |
I suggest we keep this open until we can create a project for it. Kustomize support is a very high priority |
There are scenarios other than skaffold for using kpt and kustomize together. Ideally, custom integrations of kpt and kustomize wouldn't be needed for each such scenario. What's the most challenging part of wrapping kustomize with a KRM function? |
I think there are different approaches to solving this problem. If we are talking about just creating a function that calls kustomize that this task is not as big. If we are talking about having feature parity between kpt and kustomize then it's a bigger issue. I read it as the latter at first. I am reactivating this and looping in @mengqiy for the function implementation. Just so the community is clear about our goal here I would suggest updating the original request text - I am happy to do that as well @yuwenma if you don't mind me doing the edits. |
It should fairly straightforward to wrap kustomize in a kpt function. We can use kustomize's existing CRD ( |
@selfmanagingresource mentioned large customers demand, now we have strong signal from @bgrant0607 and @yuwenma . I'd consider this as a higher priority. CC: @frankfarzan |
We used to have a kustomize function in the function catalog but for some reason (I don't remember) we removed it. |
is this something we can potentially restore and provide a support path? Seems like an easy way to create a bridge for folks who have some of their config done with kustomize to adopt kpt hydration pipeline. |
Ref: #1078 |
Do we have a way to measure how many times functions are used? That could help us assess utility. |
No at the moment. |
There are multiples aspects to consider here:
(Depending on UX questions above) If running declaratively, the function need to mount the local filesystem or can all the resources be passed in as input KRM? The reason previous function 1 was removed because: a) There weren't clears answers to UX questions above. As a result, it was confusing to users. |
@frankfarzan we find this direction of stripping away native kustomize support confusing (i.e. #1078 and this following discussion). I opened up #1545 separately because I didn't want to derail this discussion with my naivety towards the situation.
I understand the challenge from To us it feels like many challenges arise from lack of native kustomize support. Here is an example workflow that proves challenging: # cat my-package/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- inventory-template.yaml
- subpackage-1/
- ingress-nginx/
components:
- ingress-nginx/aws/
---
# cat my-package/ingress-nginx/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- upstream/
---
# cat my-package/ingress-nginx/aws/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1alpha1
kind: Component
configMapGenerator:
# https://kubernetes.github.io/ingress-nginx/user-guide/nginx-configuration/configmap/
- name: ingress-nginx-controller
behavior: merge
literals:
- use-proxy-protocol="true"
- real-ip-header=proxy_protocol
patches:
- path: aws-service-annotations.yaml
target:
kind: Service
name: ingress-nginx-controller $ kustomize build my-package/ | kpt live apply # this is slightly annoying, but fine
$ kpt live diff my-package/ingress-nginx # something like this is basically impossible
$ kpt live destroy my-package/ingress-nginx # this is similarly impossible In other words, because In case that example wasn't clear, note that the root |
Thank you for the input @marshall007, just a tip for your $ kpt live init tmp-dir
$ kustomize build my-package/ >> tmp-dir/manifests.yaml
$ kpt live apply/diff/destroy tmp-dir |
@marshall007 just had more time to think through your scenario. First of all I want to say that kpt is focused on in place hydration while kustomize by design does out of place hydration. I think the functionality where one issues commands like Let's say there was a kustomize function that given a folder to do a kustomize build and an output of that folder could enable someone to produce the WET config. The question then becomes if the source of kustomize build (DRY) and the result are in the same kpt package (maybe as sub-packages) how do you then let kpt know to ignore the DRY config? When you have the pattern of
The communication from step 2 to step 3 generally happens by having a separate output directory (as @yuwenma mentions) or via STDIN/STDOUT. There are solutions here by telling kpt to ignore directories or maybe making sure that the kustomize sources are remote, but then is the solution more straight forward than the problem? |
Here are my use cases: Use Case 1(Roughly 70% of all k8s users fit in this boat)
Use Case 2
|
@viglesiasce there is a way to introduce kpt to kustomize users that is covered by this example: https://github.com/GoogleContainerTools/kpt/tree/main/package-examples/kustomize |
kustomize build
features.The text was updated successfully, but these errors were encountered: