TMC Self-Managed 提升跨多云环境安全性
作为云原生技术栈的关键技术之一，Kubernetes 被企业用户广泛试用并开始支撑实际业务应用运行，实现技术先进性带来的生产力提升。但与此同时，随着 Kubernetes 技术的不断广泛与深化使用，企业用户也开始面临诸多技术上的挑战，诸如在不同的基础架构环境中 （私有数据中心、公有云或边缘计算）统一管理的复杂度高，跨不同环境将 Kubernetes 作为一项标准服务交付到不同团队极具挑战性，不同环境和团队的运维方式不一致会导致安全性和合规性风险等等。
面对如此诸多挑战，VMware 推出了面向多云 / 混合云环境的 Kubernetes 资源统一管理的产品解决方案，VMware Tanzu Mission Control（简称 TMC）。这是一个集中式的管理平台，可跨多云环境和多集群进行一致的运维管理和安全保护。它为运维人员提供了单一控制点，使开发人员能够根据需要独立地推进业务向前发展，同时确保跨不同环境实现一致的管理和运维，以提升安全性和监管效果。
长久以来，TMC 只能以提供 SaaS 服务的方式供客户订阅使用。但是在很多情况下，尤其是一些对网络隔离性要求极高的用户，不允许将私有的 Kubernetes 集群开放给公网，导致这些用户无法使用 TMC 解决方案。所以，VMware 针对这种场景正式发布了 TMC 自管理版本（TMC Self-managed，TMC-SM) ，它将 TMC 作为本地部署的方式推向市场，使原先无法使用 TMC SaaS 服务的用户能够尝试使用该 Kubernetes 管理平台，或者原有 SaaS 用户在一些特殊情况下（比如断网）能够作为管理平台的高可用性备份。
本文将主要介绍 TMC-SM 的高层次架构以及部署步骤，让读者快速掌握和了解 TMC-SM 的功能。
高层次架构
TMC-SM 部署全部基于云原生，所以需要一个遵循 CNCF 规范的 Kubernetes 集群。TMC-SM 的高层次架构用一张图来表示如下：
其中：
- 灰色的部分需要用户自己提供，主要包括：基础架构的 CNI 组件，CSI 组件以及外部负载均衡器（LB）；遵循 OIDC 标准的身份管理服务；私有镜像仓库；证书管理器和相关 secrets 等。
- 紫色的部分是自带的支撑服务组件，主要包括 Ingress 控制器 - Contour，登录服务 - Pinniped，S 3 存储服务 - Minio，消息服务 - Kafka 以及 SQL 服务 - Postgres 等。
- 黄色的部分是集群代理，需要被管辖的集群都必须安装。
- 绿色的部分是 TMC-SM 服务本体，所有的与用户交互的功能，例如集群生命周期管理，健康观测，数据保护，集群一致性检查，审计等等都在此处实现。TMC-SM 不仅包含交互式 Web 界面，而且还提供命令行工具 TMC CLI 来进行操作，以便集成进一些自动化流程中。
部署准备
在部署之前，我们需要做一些准备工作，主要清单如下：
- 一个遵循 CNCF 标准的 Kubernetes 集群，Api 版本 1.23.X，至少 1 个 Master 节点和 3 个 Worker 节点，每个节点的配置在 4 核 / 8 G 内存 / 40 G 本地磁盘以上。本文使用了 vSphere with Tanzu 7u3L 作为 Kubernetes 集群来源。
- 外部负载均衡器。本文使用 NSX-ALB 作为外部负载均衡器。
- 创建 DNS 记录。假设部署的子域名是 ，分配到的负载均衡器虚拟 IP 为 < load-balancer-ip>，那么需要创建的 DNS 记录清单如下：
- 遵循 OIDC 标准的身份管理服务。此项可以集成现有客户环境的身份服务，或者自建。因为仅做示范之用，本文使用了 OKTA 的 SaaS 服务作为身份管理服务:
前往
注册开发者账户，然后创建新的 app integration：
注意设置参数：
1)Grant Type:
a.Client Credentials
b.Authorization Code
c.Refresh Token
d.Resource Owner Password (optional)
2)Sign-in Redirect URI: https://pinniped-supervisor./provider/pinniped/callback
3)创建新的组 tmc:admin 并把自己的 ID 加入该组。然后把 tmc:admin 加入存取 app 的权限。
4)创建 custom claim mapping。增加名字为 groups 的新 claim，正则表达式 regex 可以是 tmc.* 或者 (tmc:admin|tmc:member) 或者仅仅是 .* 以保证 tmc:admin 和 tmc:member 组都能被选中。
-
私有镜像仓库。本文使用了自建的 Harbor 镜像服务器 harbor-tanzu.eng.vmware.com，并建立了公共项目 tmc。安装镜像将存储在该项目中。
-
安装证书管理器。本文使用 cert-manager 作为证书管理器，并创建相应的 ClusterIssuer，如下：
- 直接安装 cert-manager 如下，本文使用 1.10.2 版本：
#kubectl apply -f https://github.com/cert-manager/cert-manager/releases/download/v1.10.2/cert-manager.yaml
如需离线安装，则须下载相应的容器镜像并推送私有镜像仓库，修改 yaml 文件重定向容器镜像后再执行 kubectl apply。
- 创建自签名证书，获得 ca 证书和私钥 key，此步骤可以通过多种方法获得，常用的就是使用 openssl 命令。然后将 ca 证书和私钥 key 放入 secret/ca-key-pair：
apiVersion: v1
kind: Secret
metadata:
name: ca-key-pair
namespace: cert-manager
data:
tls.crt: LS0tLS1CRUdJTiBDR…
tls.key: LS0tLS1CRUdJTiBFQ…
a) 创建名为 letsencrypt-prod 的 ClusterIssuer，样本 yaml 文件如下：
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
name: letsencrypt-prod
spec:
ca:
secretName: ca-key-pair
部署
在准备好上述的部署前置条件之后，我们下载 TMC-SM 安装包并解压到 tmc 目录中，然后推送安装镜像到私有镜像仓库中：
#tmc/tmc-local push-images harbor --project harbor-tanzu.eng.vmware.com/tmc --username admin --password vmware
从安装程序中解出缺省的部署配置文件 values.yaml：
#tmc/tmc-local generate-values-schema --output-file values.yaml.tmpl
对 values.yaml 文件做相应的配置，主要的配置点有：
- oidc 服务配置
- 信任 ca 证书配置，包括 tls 和 harbor 的 ca 证书：
然后执行部署安装，并观察 tmc-local 命名空间中 pod 的运行情况，如果都在 running 状态表示部署成功：
#tmc/tmc-local deploy --image-prefix harbor-tanzu.eng.vmware.com/tmc --kubeconfig ~/.kube/config --values=values.yaml
访问 TMC-SM 控制台
使用浏览器访问 https://，并通过身份验证后，便进入了 TMC-SM 的主界面：
你会发现，TMC-SM 和 TMC SaaS 服务的界面几乎一样。同样的，两者的功能也几乎一致，完全可以作为高可用性备份。
总结
TMC 从单一控制点管理所有 Kubernetes 集群，涵盖打包 Kubernetes 发行版、代管 Kubernetes 服务和 DIY 服务。运维人员可以全面了解所有 Kubernetes 资源的状态，随时了解每个集群的运行状况，掌握访问策略、容器镜像仓库策略、网络策略和安全策略等。
TMC Self-managed 版本的推出，将 TMC 的使用范围扩大到了企业的私有环境，而且支持和原有的 SaaS 版本互为备份，提供管理平台的高可用性。
本文作者：熊铭杰，应用现代化解决方案架构师
内容来源｜公众号：VMware 中国研发中心
有任何疑问，欢迎扫描下方公众号联系我们哦～
