Unless I'm mistaken, 100 pulls per 6 hours per IP is a lot - You would/should be caching most of the images from dockerhub anyways, so subsequential builds shouldn't count against your limit.
Internal repo that does caching of images is rather obvious and a good practice, but it still doesn't mean that 100 pulls are that many.
Maybe we understand something different by a "small" team, but IMHO a smaller team uses more ready public images, to save time and costs. Also even not that big project on Kubernetes that includes internal software will also have a lot of other software.
Let's speculate: I had a look at some teams I know and how they work (or they would like to work soon) and it's easily 15-30 images in a CI/CD pipeline. Plus tools used to develop, but not exactly released in a build (source code management, PM, communication etc). All teams I know have 2-3 cycles developed at all times (next release, hotfix, future release after the next one). This means a lot of these tools are multiplied by 2-3 (upgrading tools as well, so multiple versions of same tool needed). If you have a few clusters that have different requirements it can also be multiplied by 2 or 3.
I would not dare to think what would happen if someone used "latest" tag in their daily work, or organized a docker/kubernetes workshop for new people :)
At one point, Docker's announcement said that all 'docker pull' requests would count towards the rate limit, even if you had every layer cached and no layers ended up being downloaded.
I may be wrong but I interpreted that to mean that even caching won't prevent you from hitting the limit.
> Unless I'm mistaken, 100 pulls per 6 hours per IP is a lot
It really depends on your usecase. I mean, each CICD stage can involve building a brand new image and running a couple of them, sometimes more. 100 pulls per 6 hours corresponds to a constant rate of 3 min between pulls, which would require between 15 to 20 minutes for each commit.
Anyway, the primary practical implications of this sort of change is a) rate limiting suddenly becomes a requirement, b) we can no longer count on Docker Hub to provide a reliable service, thus we plan accordingly.
Maybe we understand something different by a "small" team, but IMHO a smaller team uses more ready public images, to save time and costs. Also even not that big project on Kubernetes that includes internal software will also have a lot of other software.
Let's speculate: I had a look at some teams I know and how they work (or they would like to work soon) and it's easily 15-30 images in a CI/CD pipeline. Plus tools used to develop, but not exactly released in a build (source code management, PM, communication etc). All teams I know have 2-3 cycles developed at all times (next release, hotfix, future release after the next one). This means a lot of these tools are multiplied by 2-3 (upgrading tools as well, so multiple versions of same tool needed). If you have a few clusters that have different requirements it can also be multiplied by 2 or 3.
I would not dare to think what would happen if someone used "latest" tag in their daily work, or organized a docker/kubernetes workshop for new people :)