HyScale有一个基于自定义YAML的文件，它将dev和OPS步骤结合起来，例如构建容器映像、创建豆荚并将其作为Kubernetes服务公开到单个文件中。这个名为hspec的文件具有提取工件的选项、安装支持库的配置命令以及重写cmd选项。在引擎盖下，如果需要，hyscaleCLI工具将生成一个Dockerfile，Kubernetes将用于部署、服务和输入。它还调用K8S API来应用YAML。规范文件还公开了部署选项，如CPU/RAM，卷，秘密等，当它部署到Kubernetes。

　　HyScale规范文件可以使用现有的Dockerfile，也可以使用指令从工件和Linux命令构建图像。Balakuntalam解释了为什么规范文件不同时支持这两个选项：

　　这里有两种类型的观众。一个-那些熟悉Dockerfiles的人。对于它们，HyScale接受Dockerfile作为图像构建的输入，并根据hspec生成K8S清单。两个-那些没有Dockerfile，只需要一个图像，有应用程序工件和堆栈来运行它。在这种情况下，hspec提供了一种简单的方法来指定所需的基本堆栈和工件位置，HyScale将创建Dockerfile和部署所需的所有东西。

　　在基于Kubernetes的开发部署工作流中，像Podman和Buildah这样可以在没有Docker守护进程开销的情况下工作并生成符合OCI的图像的工具正在作为香草Docker的替代方案出现。HyScale还不支持这些，但他们已经“开始支持Kaniko的工作”。此时，这一空间存在太多的碎片，不清楚哪些工具将得到牵引，原因是什么”，巴拉昆塔拉姆说。通过HyScale的Kaniko实现，图像构建“发生在一个吊舱内，因此这可能有助于在K8S中扩展图像构建吊舱”。

　　容器化应用程序的优点之一是应用程序开发人员可以将配置和环境指定为容器映像的一部分，而容器映像在通过管道-dev、分期、prod等过程中基本保持相同。然而，一些配置，例如。对于Java应用程序的堆大小，可能在envs之间是不同的。如果dev使用类似Minikube的dev，并且ops团队部署到一个完整的K8S集群中，这一点尤其正确。HyScale能管理这样的场景吗？巴拉昆他兰说，现在还没有，但他补充说，他们正在努力：

　　hspec提供了应用程序团队需要的抽象，作为部署应用程序的基础。在此基础上，我们将提供一种为每个环境添加配置文件的方法。一个hprof规范已经在工作中，它将允许重写hspec指令或为每个环境指定额外的指令选项。然后，HyScale将基于环境在hspec之上应用这样的差异。

　　在这个空间里有许多工具-无论是新兴的还是成熟的-比如Skaffold、Garden、Draft和Forge。与其中一些相比，HyScale如何？巴拉昆塔拉姆说：

​　　HyScale提供了一个以应用程序为中心的抽象和相关的布线来完成部署。此外，当问题发生时，它需要简化故障排除。我们希望能够说“给我服务A的服务日志”或“为服务X触发快照”，而不必担心服务运行在哪个吊舱或容器中，使用了哪些存储类，哪些PV/PVC ID相关联等等。