部署至AKS的容器是否需要选择特定Linux基础镜像？

首先你对容器资源特性的认知是准确的：容器不携带独立内核，不会运行完整的独立OS实例，靠namespace、cgroup做资源隔离，直接复用宿主机内核，只打包应用运行需要的用户态依赖，比虚拟机省很多内存资源，这个理解没有偏差。

关于AKS选基础镜像的问题，直接给结论：

完全不需要刻意选标注适配Ubuntu 18.04的基础镜像，Alpine这类任意主流Linux基础镜像都能在你这套Ubuntu 18.04节点的AKS上正常跑。

你推测的「只要基础镜像和AKS节点的Linux内核版本兼容就可以正常使用」基本是对的。容器和宿主机的交互只有系统调用层，用户态是完全隔离的：不管是用musl libc的Alpine、用glibc的Debian/Ubuntu，甚至不同版本的CentOS、Fedora镜像，自带全套用户态库和依赖，不会碰宿主机的用户态文件，根本不需要和宿主机的Ubuntu 18.04用户态环境做适配。只要镜像里的程序发起的系统调用能被节点内核支持，就能正常运行。

实际选镜像需要注意的点 #

只有几个特殊情况需要额外关注，和节点是不是Ubuntu 18.04没关系：

• 内核特性依赖：如果你的程序要用到高版本内核才有的能力，比如高版本支持的eBPF特性、cgroup v2专属接口、新加入的系统调用，才会出兼容性问题。Ubuntu 18.04默认搭载的是4.15版本LTS内核，常规Web、后端、数据处理类业务用到的系统调用早就支持，绝大多数官方维护的基础镜像跑起来都没问题。
• CPU架构匹配：选的镜像架构要和AKS节点池的CPU架构一致，x86_64节点别选arm64镜像，arm节点别选x86镜像，这是CPU指令集层面的硬性要求，和节点操作系统无关。
• 特权容器场景：如果你要跑特权容器做加载内核模块、操作宿主机硬件、调用内核调试接口这类特殊操作，才需要考虑容器内工具和宿主机内核版本的匹配，普通业务容器完全碰不到这类场景。
• 安全要求：尽量选官方维护、还在支持周期内的镜像，别用停更多年、有一堆未修复高危漏洞的过期镜像，这是安全规范要求，和运行兼容性没关系。

要是拿不准某款镜像能不能跑，在本地找个装了4.15版本内核的测试环境拉起镜像验证下，确认业务进程正常、核心功能可用就行，完全不用纠结基础镜像的发行版是不是和节点一致。

内容的提问来源于stack exchange，提问作者Gladik