Skip to content
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 image pull cache for App CR to archieve 'imagePullPolicy: IfNotPresent' #1411

Open
jessehu opened this issue Nov 26, 2023 · 14 comments
Labels
carvel-accepted This issue should be considered for future work and that the triage process has been completed enhancement This issue is a feature request priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.

Comments

@jessehu
Copy link
Contributor

jessehu commented Nov 26, 2023

Describe the problem/challenge you have
Hello, is there an option similar to IfNotPresent in K8s for the image url used in fetch ?
https://carvel.dev/kapp-controller/docs/v0.48.x/packaging/

  # App template used to create the underlying App CR.
  # See 'App CR Spec' docs for more info
  template:
    spec:
      fetch:
      - imgpkgBundle:
          image: registry.tkg.vmware.run/tkg-fluent-bit@sha256:...

The reason for this feature is:

  • the image will be pulled so many times, e.g. 1403805 downloads shown in Harbor
  • when image registry goes offline temporarily, kapp-controller reports error when reconciling App, but it’s not needed since the tag is immutable

This is discussed in https://kubernetes.slack.com/archives/CH8KCCKA5/p1700836690956389

Describe the solution you'd like

vendir v0.36.0 supports Only run sync for stable versions, if vendir.yaml has changed since last sync · Issue #278 · carvel-dev/vendir. kapp-controller can utilize it.

Anything else you would like to add:
[Additional information that will assist in solving the issue.]


Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help working on this issue.

@jessehu jessehu added carvel-triage This issue has not yet been reviewed for validity enhancement This issue is a feature request labels Nov 26, 2023
Copy link

github-actions bot commented Jan 6, 2024

This issue is being marked as stale due to a long period of inactivity and will be closed in 5 days if there is no response.

@github-actions github-actions bot added the stale This issue has had no activity for a while and will be closed soon label Jan 6, 2024
@praveenrewar praveenrewar removed the stale This issue has had no activity for a while and will be closed soon label Jan 8, 2024
@praveenrewar
Copy link
Member

@jessehu Are you trying to pull a bundle or an image? We already have caching available for images and bundles, although, I think it doesn't work if the bundle is not colocated.
cc @joaopapereira

@jessehu
Copy link
Contributor Author

jessehu commented Jan 8, 2024

I'm pulling an image. It's not cached because kapp-controller reports not able to pull the image when the image registry server goes down.

@renuy renuy added carvel-accepted This issue should be considered for future work and that the triage process has been completed priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete. and removed carvel-triage This issue has not yet been reviewed for validity labels Jan 9, 2024
@renuy renuy moved this to Prioritized Backlog in Carvel Jan 9, 2024
@renuy
Copy link

renuy commented Jan 9, 2024

If the image size is huge, we would prefer not to cache it in kapp-controller as it will increase the size of the kc container.
Explore how vendir's functionality can be used here.

@100mik
Copy link
Contributor

100mik commented Jan 9, 2024

We can configure the max size by setting an env in the pod (ref). However, a higher cache max size is not recommended because of the reasons that Renu mentioned.

To make this easier we could start making this config more accessible via Kapp-controllers config, but we should definitely be conscious of the impact this has on the footprint.

@jessehu
Copy link
Contributor Author

jessehu commented Jan 9, 2024

Thank you. The images I need to pull is very small (n KB).

@joaopapereira
Copy link
Member

What version of kapp-controller are you using?
Starting on version 0.43 kapp-controller by default caches all images as long as they are referenced by a SHA, the size is smaller than 1MB and in case of a bundle if it is colocated or not.
Are all the above assumptions true in your case?

@jessehu
Copy link
Contributor Author

jessehu commented Jan 10, 2024

hi @joaopapereira I'm using kapp-controller 0.44.6. Here is the Package CR yaml which uses image tag name not SHA.

apiVersion: data.packaging.carvel.dev/v1alpha1
kind: Package
metadata:
  name: calico.sks.mydomain.com.3.26.3
  namespace: sks-system
spec:
  refName: calico.sks.mydomain.com
  version: 3.26.3
  releaseNotes: https://docs.tigera.io/calico/latest/release-notes/#v3.26.3
  licenses:
  - Apache 2.0
  template:
    spec:
      fetch:
      - image:
          url: registry.mydomain.com/kubesmart/packages/calico:3.26.3
          subPath: manifests
      template:
      - helmTemplate:
          path: charts/tigera-operator
          valuesFrom:
          - path: values.yaml
          - secretRef:
              name: calico-global-data-values
      - ytt:
          paths:
            # "-" is used for getting the output of 'helmTemplate' step as the input for 'ytt' step.
            - "-"
            - ytt
          valuesFrom:
            - path: values.yaml
            - secretRef:
                name: calico-global-data-values
            - secretRef:
                name: calico-data-values
      deploy:
      - kapp:
          rawOptions:
          - --wait-timeout=60s

@joaopapereira
Copy link
Member

Since you are using a tag vendir cannot guarantee that the image will be the same, so it will not cache it.

@jessehu
Copy link
Contributor Author

jessehu commented Jan 11, 2024

Got it. Is it reasonable to let vendir cache a image with tag as well (in addition to sha256) ? A tag is immutable.

@jessehu
Copy link
Contributor Author

jessehu commented Jan 11, 2024

@joaopapereira
Copy link
Member

The problem is that your particular tag might be immutable, but we cannot guarantee that all tags used in kapp-controller are. Because of this, we need to safeguard the kapp-controller from the generic case.
An excellent example is the latest tag all images have in dockerhub.

@jessehu
Copy link
Contributor Author

jessehu commented Jan 12, 2024

Yup, latest tag is not immutable but others should be especially in product env (e.g. docker hub). Or could we have an vendir or kapp-controller option to cache images with tag ?

@jessehu
Copy link
Contributor Author

jessehu commented Feb 7, 2024

Thank you all for the guidance. I managed to make the image fetch cache work by switching to image sha256 and optionally adding the following env var VENDIR_MAX_CACHE_SIZE for kapp-controller-sidecarexec pod:

          - args:
            - --sidecarexec
            env:
            - name: KAPPCTRL_SIDECAREXEC_SOCK
              value: /etc/kappctrl-mem-tmp/sidecarexec.sock
            - name: IMGPKG_ACTIVE_KEYCHAINS
              value: gke,aks,ecr
            - name: VENDIR_MAX_CACHE_SIZE
              value: 5Mi
            image: registry.example.com/project/kapp-controller:v0.44.6
            name: kapp-controller-sidecarexec

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
carvel-accepted This issue should be considered for future work and that the triage process has been completed enhancement This issue is a feature request priority/important-longterm Important over the long term, but may not be staffed and/or may need multiple releases to complete.
Projects
Status: Prioritized Backlog
Development

No branches or pull requests

5 participants