Can "kpt live" work with generated manifests?
62 views
Skip to first unread message
Steven Harris
May 11, 2020, 1:09:59 PM5/11/20
to kpt-users
I'm interested in learning whether kpt works with generated Kubernetes manifests, and what limitations I'll likely face in trying to mate the two. I brought this up first in the "kustomize" channel in the "Kubernetes" Slack team, as I fumbled my way through experimenting with kpt live preview, kpt fn source, and kpt fn sink. My findings so far confused me, so I'd like to explore the topic further here.
I've had good experience using tools like Jsonnet to prepare Kubernetes manifests, feeding them into tools like kubecfg, qbec, or tanka. Knitting these together with Bazel, it's possible to generate and transform inputs that feed either into tools like those or even just kubectl apply -f -, throwing away the generated content and storing only the primary source in the VCS. The kpt live command family appears to want to take a directory of files as input, as opposed to being able to read from standard input, expecting that we've committed our manifests there as input, or maybe just dumped the generated output there. There's also a lot of documentation about how kpt fn can transform or generate manifests, but it's not clear to me whether we're supposed to dump its output to files and commit those to the VCS.
I'd appreciate talking through an example that includes taking a generating tool like jsonnet (but it doesn't have to be that one, just something that can spit out JSON or YAML either to standard output or to files) and integrating that with kpt live. Should this involve kpt fn? If so, how?
I also learned of two potential stumbling blocks:
- kpt live can only operate on zero or one namespaces.
Is there any intention to lift that restriction? - kpt fn sink can't prune files.
This is deemed as "working as intended," but this poses a challenge for generated content that flows through kpt fn. The pruning behavior of kpt live apply is the main attraction here, approximating kubecfg's garbage collection feature. I wouldn't want to use kpt without this pruning capability. Is there a plan to make these two work together?
Frank Farzan
May 15, 2020, 5:58:07 PM5/15/20
to Steven Harris, kpt-users, Morten Torkildsen
Hi Steven,
"kpt live command family appears to want to take a directory of files as input, as opposed to being able to read from standard input"
This is something on our roadmap, we want `kpt live apply` to also be a kpt function, and be used as a sink in a pipeline.
--
You received this message because you are subscribed to the Google Groups "kpt-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kpt-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kpt-users/0785e1b8-659f-4079-8b67-dd64fa3880b5%40googlegroups.com.
Sean Sullivan
May 15, 2020, 6:12:58 PM5/15/20
to Steven Harris, kpt-users
Hello Steven,
Just a quick note, that kpt live apply (as well as preview, destroy, and diff) now works on stdin. If there are no args, we assume stdin. As of:
An example would look like:
kustomize build | kpt live apply
Additionally, as noted earlier, we intend to work on more than one namespace, but we kept (no pun intended) it simple for the MVP.
Sean Sullivan
On Mon, May 11, 2020 at 10:10 AM Steven Harris <seha...@gmail.com> wrote:
--
Steven Harris
May 16, 2020, 8:46:20 PM5/16/20
to kpt-users
On Friday, May 15, 2020 at 5:58:07 PM UTC-4, Frank Farzan wrote:
This is something on our roadmap, we want `kpt live apply` to also be a kpt function, and be used as a sink in a pipeline.
That's good to hear, and it makes sense conceptually. I'm still wondering about my second question, though, concerning pruning: Used as a sink in a pipeline, downstream from generated manifests, could kpt live apply still prune objects? Which part of this pipeline would be responsible for keeping track of changes in the object set, to note that some object generated previously is no longer part of the latest generated set?
Steven Harris
May 17, 2020, 5:39:21 PM5/17/20
to kpt-users
On Saturday, May 16, 2020 at 8:46:20 PM UTC-4, Steven Harris wrote:
Used as a sink in a pipeline, downstream from generated manifests, could kpt live apply still prune objects?
Answering my own question, using a freshly built shows that kpt kpt live apply does work correctly on piped input, pruning objects that are no longer present in that input.
I noticed a few oddities, though, that I hope you can address.
- kpt live preview threatens to "configure" existing objects, even when there's no change necessary.
Running kpt live apply subsequently confirms that the object was "unchanged," but why is kpt live preview not able to see that low likelihood of change ahead of time? If used as part of code review or deployment rehearsal, it raises a threat that we need to investigate. That leads me to the next one. - kpt live diff fails on piped input.
It displays the following:% ... | kpt live diff
error: lstat -: no such file or directory
Sean Sullivan
May 18, 2020, 10:45:11 PM5/18/20
to kpt-users
Hi Steven,
Sorry for the delay in getting back to you. Thanks for your high quality feedback.
1) kpt live preview: reports "configured", when it should be "unchanged". It correctly reports "unchanged" when it actually applies. This is a known problem with kubectl. We re-use kubectl apply code. If you run "kubectl apply -f <DIR> --dry-run" on a config directory that is not changed you will see the same problem. The problem stems from the fact that you currently have to actually apply the client-side patch to see if any bytes have been patched (changed). The code is here:
I will create a kubectl issue for this, since I don't think one exists right now. Honestly, I'm not sure how soon anyone will get to this.
2) kpt live diff on piped output is a bug. I will create an issue for it. Thanks for bringing it to our attention. I'll prioritize this one.
Cheers,
Sean Sullivan
Steven Harris
May 19, 2020, 8:18:17 AM5/19/20
to kpt-users
On Monday, May 18, 2020 at 10:45:11 PM UTC-4, Sean Sullivan wrote:
The problem stems from the fact that you currently have to actually apply the client-side patch to see if any bytes have been patched (changed). The code is here:
Thanks for the pointer. I remember this "configured" message from using kubectl apply long ago, but thought we'd be past this now that server-side apply and dry run were in place. Looking at that applyOneObject method, why is it that we don't find the patch to be empty, and print "unchanged" instead?
Oh, I guess we take that path if we're not in client-side dry run mode, as would be the case when we're either using server-side dry run mode or are actually applying the change. Is it possible to activate server-side dry run mode from kpt live preview? I don't see a command-line flag that looks appropriate.
Reply all
Reply to author
Forward
0 new messages