Accept render output in skaffold deploy

[ekupershlak]

Using skaffold render to produce a static configuration that can later be deployed (and redeployed) is useful in delivery workflows. However, there is currently no way to provide a rendered manifest to skaffold deploy.

Expected behavior

skaffold deploy can be run with a previously rendered manifest

[viglesiasce]

As a stop gap you could set up a re-deployment profile and use skaffold deploy -p re-deploy

apiVersion: skaffold/v2beta8
kind: Config
deploy:
  kustomize:
    paths:
    - dev/
profiles:
- name: re-deploy
  deploy:
    kubectl:
      manifests:
      - manifest.yaml

[briandealwis]

So this essentially means: ignore the manifests listed in the skaffold.yaml and instead pipe in the manifest provided on the command-line into the deployer? And so Skaffold shouldn't apply any of its transforms to the output (digestifying image references according to the build artifacts, and adding labels/annotations).

This means that we assume the deployer can take and safely re-render previously-rendered input (e.g., not Helm).

[ekupershlak]

The intention of this FR is to seperate the rendering and deployment operation, so that the render from a deployer with non-trivial logic (e.g.kpt) can still be applied. I would expect some of th details from the original skaffold.yaml to be needed (i.e. which deployer to use) though perhaps this could be included in the manifest.

I'm not well versed in the details of helm - could you elaborate a bit more on the issues around using a previous render?

[gsquared94]

AFAIK helm doesn't support ^{[^1]} taking a rendered manifest and re-rendering like the ask in #4874. So we can't have this as a deploy level feature without it working for all deployers. But isn't it just kubectl apply -f? How does skaffold enrich a rendered manifest in the deploy pipeline any better than what could be achieved by applying the manifests directly?

^{[^1]}: Might change with the helm deployer rework in the plans.

[briandealwis]

@ekupershlak It would help me to understand to have a concrete example (even if just a toy). I too wondered how what you're asking for is different from kubectl apply -f < your-previous-yaml or kpt apply your-previous-yaml. More specifically, what do you expect Skaffold to do?

Re: Helm: I only meant that Helm doesn't really have a notion of ignore-the-chart-and-use-this-yaml-instead.

[ekupershlak]

@briandealwis Let me try to provide a sample workflow:

• Use skaffold render to produce a manifest and store it
• Use skaffold deploy to deploy this manifest
• Some time later, use skaffold deploy to deploy the manifest to revert to that state

The intetion of this FR is to enable using skaffold as part of a workflow. Otherwise I need to inspect skaffold.yaml to determine what deployer to use, and also to understand how skaffold would call it (i.e. any additional args).

I can definitely see kubectl being used for deployment, but I'd like skaffold to make that determination based on configuration and the rendered manifest. By having skaffold do so, I'm also able to use any deployment features built into skaffold.

[briandealwis]

Ah, ok. So having the manifest be processed, either by Skaffold or by kpt (for example), is not required.

@yuwenma: what would we do with kpt? Would we use kpt live apply?
@nkubala: what would we do with Helm? Just use kubectl apply?

Maybe we should call this skaffold redeploy :-) I wonder if it should support a --build-artifacts to update a previous rendered manifest. Maybe that should be pushed to the (internal) skaffold filter.

[yuwenma]

@briandealwis
kpt live apply can understand and apply the rendered manifest just like kubectl. The main difference is that it does a more accurate apply since it keeps track of the previous resource statuses.

[nkubala]

I think this only poses a problem with helm. we'd have to be careful since the output of helm template is not deterministic as chart dependencies can change. it's true that skaffold render for a project configured with helm will spit out some hydrated kubernetes manifests, but telling skaffold to deploy those manifests when the default configuration is setup with helm bypasses some of the release tracking infrastructure that differentiates helm install from helm template > kubectl apply -f.

this might not be the end of the world, but maybe we could use helm package for helm apps instead?