为Kubernetes Pod/服务生成自签名证书：IP变动下的替代方案咨询

方案1：ClusterIP Service + 集群内部DNS #

如果你的本地环境能直接接入集群网络（比如用kubectl proxy、在集群节点上访问，或者通过VPN连入集群），完全可以抛弃IP，用Service的集群内部固定域名生成证书：

• 比如default命名空间下的my-service，它的集群域名是my-service.default.svc.cluster.local，把这个域名作为证书的CN（通用名称）和SAN（备用名称）即可。
• 用openssl生成证书的示例命令：

  openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes -subj "/CN=my-service.default.svc.cluster.local" -addext "subjectAltName=DNS:my-service.default.svc.cluster.local"
  

• 优势：域名永久固定，只要Service不改名/换命名空间就一直有效，完全不用管IP变动。

方案2：NodePort Service + 本地hosts映射 #

如果是通过集群节点IP访问NodePort服务，不用纠结节点IP变动，直接在本地绑定固定域名：

1. 给Service设置NodePort类型，可选指定固定nodePort避免端口变动；
2. 在本地/etc/hosts（Linux/macOS）或C:\Windows\System32\drivers\etc\hosts（Windows）里加一行：[节点IP] my-service.local；
3. 用my-service.local作为CN和SAN生成SSL证书。

• 优势：不用修改集群配置，IP变动时只需要更新本地hosts文件就行，适合本地直接通过节点IP访问的场景。

方案3：Headless Service + Pod DNS域名 #

如果要直接访问Pod（绕开Service），可以用Headless Service：

• Pod的集群域名格式是[pod-name].[headless-service-name].[namespace].svc.cluster.local；
• 生成证书时可以把单个Pod域名加到SAN，或者用通配符（比如*.my-headless-svc.default.svc.cluster.local）覆盖同一Headless服务下的所有Pod，注意通配符只能匹配一级子域名。
• 适合需要直接访问特定Pod的场景，只要Pod命名规范固定，证书就能复用。

关于“集群有效证书” #

可以生成覆盖整个集群服务域名后缀的通配符证书，比如*.svc.cluster.local（覆盖所有命名空间的服务）或者*.default.svc.cluster.local（仅覆盖default命名空间），这样所有符合后缀的Service/Pod域名都能匹配这个证书。

• 通配符证书生成示例：

  openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes -subj "/CN=*.default.svc.cluster.local" -addext "subjectAltName=DNS:*.default.svc.cluster.local"
  

• 注意：这种证书仅对集群内部域名有效，需要你的本地环境能解析集群DNS才行。

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