+1 Before switching to Alpine completely, it would be worth running extensive system tests in production-like environments.
Alpine comes with musl, which makes the JVM behave slightly differently. One of the common DNS issues with Alpine was fixed in May 2023 with the Alpine 3.18 release. Alpine finally got full DNS protocol support that impacts usage when there are DNS responses larger than 512 bytes [1]. Alpine 3.18 comes with musl 1.2.4 with TCP fallback in the DNS resolver. The official Kubernetes docs also contain the recommendation [2] to upgrade Alpine to 3.18+ (newest is currently 3.19) on Kubernetes. I'm no longer concerned about possible DNS resolution issues with Alpine. However, one remaining concern related to DNS is the lack of local DNS caching in Alpine. In Pulsar, most of the DNS resolution happens with Netty's DNS resolver that has caching. I'm not sure what the broader impact could be when switching to Alpine that doesn't have DNS caching at the OS level. In Kubernetes environments, most DNS lookups go through a lot of search domains and it puts a lot of load on the DNS server unless clients do caching. It is possible to have a local caching DNS server in Alpine [1], but that doesn't seem to be very convenient. The third area where there are differences in musl is in malloc. It's hard to know beforehand how the different malloc algorithm impacts the actual resident memory (RSS) usage. Different malloc algorithms handle memory fragmentation in different ways and there are behavioral differences. System testing could help verify the actual impact. -Lari 1 - https://bell-sw.com/blog/how-to-deal-with-alpine-dns-issues/#mcetoc_1gtd8v3lt2b 2 - https://kubernetes.io/docs/tasks/administer-cluster/dns-debugging-resolution/#known-issues On 2023/12/12 18:58:49 Matteo Merli wrote: > Hello, > > I've created a new proposal to switch Pulsar base docker images from Ubuntu > to Alpine Linux. > > Details and motivation in the PIP: > https://github.com/apache/pulsar/pull/21716 > > Matteo > > -- > Matteo Merli > <mme...@apache.org> >
