ConfigMap 实践:文件挂载、自定义文件名、权限与 optional
除了环境变量,ConfigMap 还非常适合直接把配置文件挂进容器。文件挂载、自定义文件名、默认权限以及 optional 行为,是这类用法里最容易踩坑、也最值得一次讲透的部分。
共找到 320 篇相关文章
除了环境变量,ConfigMap 还非常适合直接把配置文件挂进容器。文件挂载、自定义文件名、默认权限以及 optional 行为,是这类用法里最容易踩坑、也最值得一次讲透的部分。
ConfigMap 最常见的使用姿势之一,就是把配置变成容器里的环境变量。valueFrom 适合精确取单个键,envFrom 更适合批量注入,理解两者差异很关键。
当配置来源不再只是单个文件时,ConfigMap 也可以通过 literal、YAML 清单和自定义 conf 文件来组织。掌握这几种方式后,配置管理会更加灵活,也更适合实际项目落地。
创建 ConfigMap 的方式很多,但最终都会落到键值对模型上。基于目录、文件和环境变量导入,是最常见也最容易直接接入现有应用配置的三种做法。
ConfigMap 是 Kubernetes 里最基础的配置管理能力之一。只有先理解它为什么会出现、它解决了什么问题,以及它和 Secret 的边界在哪里,后面的创建和挂载实践才不会停留在“会用命令”的层面。
普通 Service 提供的是稳定虚拟入口,而 Headless Service 提供的是“直接看见后端实例”的能力。再配合 Kubernetes 自带的环境变量和 DNS 机制,服务发现这件事就从“找一个入口”变成了“按需要找入口或找实例”。
现实里的服务并不总是只有一个端口。有的中间件既要开放业务端口,又要开放管理端口;有的业务还希望客户端多次访问尽量落到同一后端实例。多端口 Service 和会话保持,就是这两类问题的直接答案。
不是所有服务都在 Kubernetes 里。有时你只是想给外部系统一个统一的集群内名字,有时你想让不同命名空间通过同名服务访问各自环境资源。这时最值得掌握的就是 ExternalName,以及 Service 加 Endpoints 代理外部服务的两种方式。
当集群外部需要直接访问 Kubernetes 里的服务时,NodePort 是最基础也最直接的一种暴露方式。它不依赖云厂商负载均衡,思路非常简单:在每个节点上打开同一个端口,把流量转发到对应 Service。
ClusterIP 是 Kubernetes 默认的 Service 类型,也是集群内东西向流量最常见的入口。只要服务只打算在集群内部被调用,ClusterIP 往往就是第一选择。