本文介绍几种在阿里云 K8S 中管理 TLS 证书的方案。
证书申请方案
先看如何申请证书。
cert-manager
cert-manager 是一个集成在 k8s 中的工具，它可以做到自动从 Let’s encrypt 申请证书、自动更新证书、与 Ingress 无缝结合。
大多数情况下建议与 Ingress 集成的方式使用它，后面会讲。如果你仅需要签发功能，不需要和 Ingress 集成，则可参考 Setting up Issuers 和 Issuing Certificates。
优点：
- 自动签发
- 自动续期
- 与 K8S 集成良好
- 免费
缺点：
- 只能签发 Server Auth 证书，不能签发 Client Auth 证书
- 证书仅用做认证，没有商业版证书更高级的功能
阿里云平台购买
比如你可以在阿里云上购买 SSL 证书，一个账号的最多申请 100 个证书
优点：
- 多种类型证书可以供选择，有免费的有收费的
- 可在平台上管理
- 申请的证书可用在其他产品上，比如 SLB
缺点：
- 与 K8S 集成不好，需要手动导入到 Secret 中才能使用
- 只能签发 Server Auth 证书，不能签发 Client Auth 证书
用 CFSSL 自签发
你可以使用 CFSSL 自签发证书，有一篇参考文档。
优点：
- 可签发 Client Auth 证书
缺点：
- 手动管理证书
- 与 K8S 集成不好，需要手动导入到 Secret 中才能使用
- 自签发的 Server Auth 证书在浏览器端会报警告
总结
对于 Server Auth 证书：
- 如果只是开发或者演示环境，cert-manager 方案更适合你
- 如果是生产环境或者对证书有更高要求的，可以采用从平台购买的方案
对于 Client Auth 证书：
- 你只能选择用 CFSSL 自签发的方式
证书部署方案
下面介绍几种部署方案。
部署在阿里云 SLB 上
虽然本小节讲的是部署在阿里云的 SLB 的产品上，但是它的思路和优缺点在其他云平台上基本是一致的。
做法是在 SLB 上配置 HTTPS 监听，ACK（阿里云 Kubernetes）在创建集群的时候会自动创建几个 SLB 实例，不要在这几个实例上配置 HTTPS 监听，因为在 ACK 中创建 Type=LoadBalancer 的 Service 的时候会把你做的配置刷新掉。
支持：
- Server Auth
- Client Auth
优点：
- 可利用阿里云的 SSL 证书管理功能
- 可用在阿里云的其他产品上，比如 ECS
缺点：
-
不支持 SNI，如果你有多个域名，因为一个 SLB 只会有一个公网 IP，此时你就有两种选择：
- 在一个 SLB 上配置多个监听端口，这样 URL 中就会携带端口
- 配置多个 SLB，避免前面一个方案的问题
- 要自己手动配置服务器组之类的信息
- K8S Service 类型得是 Node Port，意味着在同一 VPC 子网内部流量不受保护
- K8S 集群内部流量不受保护
LoadBalancer Service
创建 Type=LoadBalancer 的 Service 来暴露服务，然后在 Deployment/StatefulSets 里部署证书。
支持：
- Server Auth
- Client Auth
优点：
- 集群内部流量受保护
- VPC 子网内部流量受保护
缺点：
- 不支持 SNI，而且因为你只可能有一个公网 IP，因此 URL 中必定要携带端口
- 在应用中配置证书，且方式方法与应用所使用架构 / 类库有关
Ingress 配合 cert-manager
前面说过 cert-manager 支持与 Ingress 集成，你很少的工作能够配置 Server Auth，和一个稍微复杂一点的步骤配置 Client Auth，详情可参考这篇文章。
支持：
- TLS Server Auth
- TLS Client Auth
- SNI，即一个 443 端口对应多个域名
优点：
- Server Auth 证书自动签发、自动续期
- Client Auth 手动配置
- 对应用的侵入性为 0
缺点：
- 集群内部流量不受保护，这个问题可以通过 Network Policy 做 namespace 隔离来缓解
总结
优先考虑 Ingress 配合 cert-manager 的方案。
如果你对安全性有很高的要求，那么考虑 LoadBalancer Service。