Building Small Containers
HTML-код
- Опубликовано: 30 сен 2024
- In this episode of Kubernetes Best Practices, Sandeep Dinesh shows how you can build small containers to make your Kubernetes deployments faster and more secure.
See the associated article here → goo.gl/zjejFj
Google Container Registry → goo.gl/ilwubv
Google Container Builder → goo.gl/l1Obc1
Container Registry Vulnerability Scanning → goo.gl/5EiyLe
Google Kubernetes Engine → goo.gl/2V8yah
Docker Multistage Builds → goo.gl/nQmwW4
Subscribe to the Cloud channel → goo.gl/S0AS51
#KubernetesBestPractices 
Наука
Everytime he snaps, the container image size is reduced by 50%.
I ran to the comments to make this exact joke, and you beat me to it.
Good to see school mate
this guy is amazing. let him know that!
its very hard for this type of hosts not to be boring neither annoying. and when it happens, it often go unnoticed.
He works in Google, only the best are able to reach that goal.
When using alpine you can use apk --no-cache to avoid using update and then removing the cached apk files.
I never used kubernetes before but I still finish the video 😂 looks awesome
This is a great video. What is it, how does it work, why do I care? Perfectly addressed, perfect level of detail, and outstanding technical embellishments in the side panel. Well done!
For Go binaries you can use scratch, without alpine
But you need to include some additional Go required binaries in first stage. And go mod download dependencies. Only Go 1.11
what i hate about my job is that i always have to discuss about normal things like performance or memory usage to get time for it.
This was clear, concise, and useful. Your 8:44 minutes made my teams' job much easier.
I've actually found one benefit of larger images. If I build a single image that contains all of my services, that is the only image my nodes will ever need; instead of having dozens of different 50-100MB images, I have a single copy of one 500MB image running my entire cluster.
Note that that's exactly how kubernetes itself is usually deployed, as a best-practice - hyperkube contains all of kubernetes' different parts, and runs the correct one given its command line parameters.
Hundreds of megabytes!
Just curious about the builder best practices. In the multi stages way, do you guys normally rm the dangling image that generated by builder container?
Nope, though they are still part of the cache layer image like the base image. Just that they won't be part of the image that you use for your container.
Super useful. Thanks for posting.
You, the GCP team should make your documentations clearly and make GCP stable. Then, everything will work fine.
could you please make some tutorials of kubernetes using rancher? its gonna be awesome!!
You actually dont want to use Node Alpine images; the C library is different on those and they are considered experimental builds of Node because of it. Instead you want to use the "slim" variant; ideally the newest debian version of it. For Node 18 right now this would be node:18-bullseye-slim.
I like the vulnerability scanning on images. Think always ahead. This will simplify a lot of process with current development models.
You can use twistlock scanner too ..
can someone tell me what is "image" here?
It's worth mentioning that many of the Linux distros on docker hub now have smaller images (it may have not been the case when this video was made).
hub.docker.com/_/ubuntu?tab=tags is 25.9mb and Debian is less than 1mb bigger. The point is that it's no longer an order of 1-2 magnitudes different.
If you were to run Python on Alpine you may find that it doesn't use glibc by default and this will change how it performs on tasks that use an alternate library (or you can a custom Alpine that installs GlibC). Dependency management can be a little easier with Ubuntu or Debian.
It's best to research your actual use case.
Good Video. With docker, I can launch a container with UID 0. How do I disable this launch? Basically, I want to disable -it option and also launching as UID 0. Can you please recommend best practices in this area?
74 People liked this so much they turned their device upside down to click thumbs up again.
Great video
On the 7:24 you say's that pulling time of the huge container like "go:onbuild" on the large machine is two times faster than on the small machine. But as I know, the pulling operation needs only the fast connection and fast hard drive and nothing else. So my questions is: 1. What is the large machine and small machine? 2. Why are the numbers so far? 3. Am I wrong about the resources needed for the pulling process?
Wow so simple and so well explain!
So can this only be done with compiled languages? Or could this be done with Interpreted languages as well using the builder pattern?
The "increased surface area for attacks" is related to what we've been called TCB: total computing base. And, if the unused parts of the image trigger an alarm - how practical is that scanning anyway?
It's good he started building those containers months ago, because I can confirm that vulnerability scanning takes days, if not weeks, to get from state 'queued' to actually displaying something. And then, it seems to me, it's no real scanning but going through the package manager's database. You can easily spot that by patching the binary yourself, retaining its version number, or removing a binary that's usually part of the package.
this video was AMAZING! thank you
huh, so that's what all that extra code in .NET Core's dockerfiles is.
Really cool, enjoying this series so far! I just hope that Gitlab support is added to Container Builder, at the moment I have to build on Gitlab CI and push to Google Container Registry because only Github and BitBucket are supported. There are workarounds but it introduces possible bottlenecks
You can just use "scratch" image if you are using a compiled binary
Are the times correct on 7:30 ?
Do I get this wrong or the "Large Machine" and "Small Machine" comparisons are mixed up
05:20 building the "Small Machine" seems to take a longer time than the "Large Machine", but the guy says; "The smaller container has a huge advantage over the large containers"
this goes on and on through the comparison
Building the image on a Large/Small machine. The container image sure are the rows with the go base image
Is another advantage with smaller containers saving on memory on the node? Or it doesn’t matter?
where can I buy that tshirt?
LOL thank you!
Very informative and useful material. Also thanks for making the content simple it is easy even for beginners to follow. Just one correction.I think the tabular data to compare performance between Large and Small machines have the wrong headings.
Thx for the vid
You can tell what a person does for a living by the words they use:
+ "to reason about" = React.js
+ "attack surface" = Docker
Outstanding presentation. Sandeep you are as good as it gets!
Any production example of builder pattern for node/laravel/Python?
great！
if goapp is in /app, how is it run using ./goapp?
Excellent Tutorial. Looking forward to new ones. Thanks Sandeep
Use intel clear linux 😉
Had no idea about the Builder pattern. Thanks!
Great tips, thanks you
wow for the amount of vulnerabilities, nice tool no GKE
Saved on my favourites
is it me ? or is the table metrics wrong ?? large | small ...
Yes, I think the columns may be the wrong way round ( reversed ) OR they are correct and it reflects the slower CPU ( smaller machine ) ?
the build pattern was really useful to me :)
thanks!
This is great video, keep it up with the good work ;)
Wonderful! Thank you
very greate video
Awesome video!
“ADD . /app” line should be “COPY . /app”
really practical perspective
this was excellent loved it
greate video
shameless plug
Well done
Woww!!, I'm beginner and this is very useful! Thanks
I like the snap effect
lol
Pine Fe what's wrong with being gay?
3:14 Perfectly Smaller Container
great tip!
great stuff
Excellent video! What version of small container do you recommend for Ruby language?
Useful for series. Congrats for @Sandeep Dinesh.
nice accent
This is great,thanks :)!
awesome! Thnx
Bhai hindi me banate to achcha hota bro
Sandip
we proud of indian
dude, i just hope you have not peed in your pants..
.
.
.
PS - Google please dont take this personally ( if your team is behind demotivating this kid, I am really gonna kick your teams ass very soon ) be it any technology you are working on. Keep the motivation going.