-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Auto import images for containerd image store #10973
Auto import images for containerd image store #10973
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Users can now add images in the embedded registry auto import folder while k3s is running
To avoid confusion, remove any references to importing things into the embedded registry - the embedded registry does not have a discrete image store to import into. We import images into the containerd image store, and images in the containerd image store can be used by Kubernetes pods without needing to be pulled from a remote registry, and they can also be shared between nodes by the embedded registry.
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #10973 +/- ##
==========================================
- Coverage 46.98% 45.37% -1.61%
==========================================
Files 179 180 +1
Lines 18610 18812 +202
==========================================
- Hits 8743 8536 -207
- Misses 8505 8972 +467
+ Partials 1362 1304 -58
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
88b30cb
to
d605c59
Compare
We probably shouldn't do it in this PR, but it would be nice if whatever we used for watching image file changes was generic, and could be reused by the deploy controller - right now it just re-scans everything once a minute: Lines 85 to 100 in 8ce04d3
|
fa7e775
to
10251df
Compare
5218084
to
1893d58
Compare
e9755b6
to
c806d29
Compare
pkg/agent/containerd/containerd.go
Outdated
if os.IsNotExist(err) { | ||
err := os.MkdirAll(cfg.Images, 0744) | ||
if err != nil { | ||
logrus.Errorf("Unable to create agent/images folder in %s: %v", cfg.Images, err) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are we creating this now? Must the folder exist in order to watch it? Is there any other way to handle this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if the user makes the images dir a symlink to another path? What happens if the image dir is deleted and recreated while the watcher is going? These are all things that users are going to try at some point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The behavior after the changes now are that the image watcher will watch the k3s/agent
and only work with the events that contains the agent/images, if the image folder is already created, the preloadImages will load the images, so the watcher will not need to load, but if the image folder is created or symlink with a folder with images inside, the watcher will send to the workqueue for the images to be loaded.
If the folder is deleted, fsnotify can auto delete and because we are watching the /k3s/agent
, if the user creates the folder again, we will watch it.
7f194f4
to
28919f5
Compare
Signed-off-by: Vitor Savian <vitor.savian@suse.com>
Signed-off-by: Vitor Savian <vitor.savian@suse.com>
Signed-off-by: Vitor Savian <vitor.savian@suse.com>
Signed-off-by: Vitor Savian <vitor.savian@suse.com>
Signed-off-by: Vitor Savian <vitor.savian@suse.com> Set local false in the test Signed-off-by: Vitor Savian <vitor.savian@suse.com>
Signed-off-by: Vitor Savian <vitor.savian@suse.com>
Signed-off-by: Vitor Savian <vitor.savian@suse.com>
Signed-off-by: Vitor Savian <vitor.savian@suse.com>
Signed-off-by: Vitor Savian <vitor.savian@suse.com>
Signed-off-by: Vitor Savian <vitor.savian@suse.com>
Signed-off-by: Vitor Savian <vitor.savian@suse.com>
Signed-off-by: Vitor Savian <vitor.savian@suse.com>
c8f01d2
to
98f3c9b
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
minor nit, lgtm otherwise!
Signed-off-by: Vitor Savian <vitor.savian@suse.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the late review. I'm a bit confused about the use case. My guess is: we have a cluster where we would like only one (or more) node(s) to pull the images for the whole cluster. The rest of the nodes would pull the images from these selected nodes by using the embedded registry mirror. We can't easily do this today because containerd will only pull the images if there is a local pod requiring it. This feature would "force" containerd to pull the image, even if no local pod requires it. Is my understanding correct?
|
||
## Context | ||
|
||
Since the feature for embedded registry, the users appeared with a question about having to manually import images, specially in edge environments. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would users have to manually import images? Aren't they automatically pulled by containerd once the pod is scheduled in the node?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is an improvement to the existing mechanism of importing images via the existingagent/images
folder. Prior to this this change, you could specify the image tar or image list only at k3s boot. now it'll be possible to continuously check for changes to the image list. This is very helpful in cases like airgap installs where you'd want to update the images for a new deployment instead of restarting k3s or doing outproc processing to import images manually.
|
||
Eventually(func(g Gomega) { | ||
cmd := `k3s ctr images list | grep library/redis` | ||
g.Expect(e2e.RunCmdOnNode(cmd, serverNodeNames[0])).Should(ContainSubstring("io.cattle.k3s.pinned=pinned")) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does the pinned
tag mean? That is was manually pulled?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Kubelet garbage collector removes the image if it's not used, so to prevent images that k3s imported from being removed, we pin them.
You can see more here -> https://kubernetes.io/docs/concepts/architecture/garbage-collection/#containers-images
}) | ||
|
||
It("Restarts normally", func() { | ||
errRestart := e2e.RestartCluster(append(serverNodeNames, agentNodeNames...)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do we need to restart the cluster?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The first restart is to ensure the image file was imported and pinned
as expected, the second restart is to ensure if the image that was removed from the /agent/images
was not pinned
by k3s.
Signed-off-by: Derek Nola <derek.nola@suse.com>
Proposed Changes
Types of Changes
Verification
Testing
Linked Issues
User-Facing Change
Further Comments