我想在应用Kubernetes yaml文件之前对它们进行服务器端验证。
我知道在我的Jenkins代理中，我可以使用以下kubectl命令在服务器端验证yaml文件，但我有点担心访问控制：
- Kubernetes<v1.18：
kubectl apply --server-dry-run -f ... - Kubernetes>=v1.18：
kubectl apply --dry-run=server -f ...
Kubernetes文档说明如下：
对干式运行和非干式运行请求的授权是相同的。因此要进行试运行请求，必须授权用户进行非试运行请求。
我不希望任何詹金斯特工对我的EKS集群拥有超强能力。一个坏演员可以恶意使用我的詹金斯代理，并应用他们想要的任何清单。现在，出于安全性/稳定性/管理的原因，创建Kubernetes对象是由另一个系统而不是Jenkins完成的。
我检查了一些其他选项，但我可以看到缺点：
- Kubeval不知道实际集群中安装了任何CRD
- 客户端验证并不是真正的端到端验证
- 我可以开发一个rest api，它公开一个验证rest端点并访问Kubernetes api，或者在后台运行一个kubectl
--run-dry。然而，这需要比我们的能力更多的开发工作
您有什么想法吗？或者您知道我可以在我们的CI系统中安全地使用任何验证工具来验证端到端的Kubernetes yaml文件吗？
我自己一直在寻找，但没有找到足够的工具。然而，也有一些变通办法：
- 将所有对象部署到dev/stage集群中的临时
ci-job-id命名空间。它们应该和刺激一样，但不会带来你提到的安全风险。这带来了一个额外的好处——你可以检查是否所有的东西都创建好了，所有的pod都在运行。它有助于发现资源请求不足、图像丢失、Service选择器配置错误等问题。此外，它还可以让您在顶部添加烟雾测试 - 用专门用于CI验证的所有CRD旋转一个小型迷你库。这种方法可以减少覆盖范围，但维护成本要低得多
不幸的是，我最初想要做的事情并不可行。无法对包含具有依赖关系的对象(例如命名空间和部署(的清单应用服务器端验证。请参阅本期。
因此，客户端验证是前进的解决方案。要么是Kubeval，要么是任何其他客户端机制。Kubeval不会验证CRD，但可以忽略它们，这样验证就不会失败：
目前kubeval依赖于从Kubernetes API生成的模式。这意味着无法使用CRD验证资源。不过，目前您需要传递一个标志来忽略丢失的模式这可能会在未来的主要版本中发生变化。
客户端验证(使用kubectl --dry-run(没有什么价值，因为它缺少一些琐碎的模式错误配置。
如果使用kubeval执行验证(如您所述，您可以跳过CRD(，或者使用支持CRD的kubeconform，您将获得更好的结果。