TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Show HN: Holos – Configure Kubernetes with CUE data structures instead of YAML

77 点作者 JeffMcCune5 个月前
Hi HN! I’m excited to share Holos, a Go command line tool we wrote to fill the configuration management gap in Kubernetes. Holos uses CUE to configure software distributed with Helm and Kustomize using a well defined, type safe language eliminating the need to template YAML. You probably know (or are) someone who has suffered with the complexity of plain text YAML templates and merging multiple values.yaml files together to configure software running in Kubernetes. We built Holos so we don’t have to template YAML but we can still integrate software distributed with Helm and Kustomize holistically into one unified configuration.<p>At the start of the pandemic I was migrating our platform to Kubernetes from virtual machines managed by Puppet. My primary goal was to build an observability system similar to what we had when we managed Puppet at Twitter prior to the acquisition. I started building the observability system with the official prometheus community charts [1], but quickly ran into issues where the individual charts didn’t work with each other. I was frustrated with how difficult it was to configure these charts. They weren’t well integrated, so I switched to the kube-prometheus-stack [2] umbrella chart which attempts to solve this integration problem.<p>The umbrella chart got us further but we quickly ran into operational challenges. Upgrading the chart introduced breaking changes we couldn’t see until they were applied, causing incidents. We needed to manage secrets securely so we mixed in ExternalSecrets with many of the charts. We decided to handle these customizations by implementing the rendered manifests pattern [3] using scripts in our CI pipeline.<p>These CI scripts got us further, but we found them costly to maintain. We needed to be careful to execute them with the same context they were executed in CI. We realized we were reinventing tools to manage a hierarchy of helm values.yaml files to inject into multiple charts.<p>We saw the value in the rendered manifests pattern but could not find an agreed upon implementation. I’d been thinking about the comments from the <i>Why are we templating YAML?</i> [4][5] posts and wondering what an answer to this question would look like, so I built a Go command line tool to implement the pattern as a data pipeline. We still didn’t have a good way to handle the data values. We were still templating YAML which didn’t catch errors early enough. It was too easy to render invalid resources Kubernetes rejected.<p>I searched for a solution to manage and merge helm values. A few HN comments mentioned CUE [6], and an engineer we worked with at Twitter used CUE to configure Envoy at scale, so I gave it a try. I quickly appreciated how CUE provides both strong type checking and validation of constraints, unifies all configuration data, and provides clarity into where values originate from.<p>Take a look at Holos if you’re looking to implement the rendered manifests pattern or can’t shake that feeling it should be easier to integrate third party software into Kubernetes like we felt. We recently overhauled our docs to be easier to get started and work locally on your device.<p>In the future we’re planning to use Holos much like Debian uses APT, to integrate open source software into a holistic k8s distribution.<p>[1]: &lt;<a href="https:&#x2F;&#x2F;github.com&#x2F;prometheus-community&#x2F;helm-charts">https:&#x2F;&#x2F;github.com&#x2F;prometheus-community&#x2F;helm-charts</a>&gt;<p>[2]: &lt;<a href="https:&#x2F;&#x2F;github.com&#x2F;prometheus-community&#x2F;helm-charts&#x2F;tree&#x2F;main&#x2F;charts&#x2F;kube-prometheus-stack">https:&#x2F;&#x2F;github.com&#x2F;prometheus-community&#x2F;helm-charts&#x2F;tree&#x2F;mai...</a>&gt;<p>[3]: &lt;<a href="https:&#x2F;&#x2F;akuity.io&#x2F;blog&#x2F;the-rendered-manifests-pattern" rel="nofollow">https:&#x2F;&#x2F;akuity.io&#x2F;blog&#x2F;the-rendered-manifests-pattern</a>&gt;<p>[4]: <i>Why are we templating YAML? (2019)</i> - &lt;<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19108787">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=19108787</a>&gt;<p>[5]: <i>Why are we templating YAML? (2024)</i> - &lt;<a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=39101828">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=39101828</a>&gt;<p>[6]: &lt;<a href="https:&#x2F;&#x2F;cuelang.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;cuelang.org&#x2F;</a>&gt;

9 条评论

eloip5 个月前
This is wonderful, thank you! A relieve for devops&#x2F;YAML engineers that need to reason about many key&#x2F;values coming from many places. Because in the end this is all there is for the user interface of IaC&#x2F;XaaS, k8s and all cloud apis. There was some effort for &quot;configuration management&quot; but few realizes the complexity, the many layers and aspects there is to &quot;it&quot;. YAML ain&#x27;t mearly enough... But the space of &quot;configuration PLs&quot; (Dhall,Nickel,Pkl,KCL,CUE,Jsonnet,etc.) is still young. Biggest problem I see is usability, CUE focuses on it so people shouldn&#x27;t be afraid. But it is also little behind the others in term of features, but also have the greatest potential! IMO any new tool in the cloud space that uses code abstractions cannot be serious by not thinking about the language. Transitions may be though but they ough to happen.
nosefrog5 个月前
I got burned so bad by config languages at Google (specifically gcl) that we&#x27;re generating Kubernetes yamls using the Kubernetes python client now.<p>My unpopular opinion is that config languages with logic are bad because they&#x27;re usually very hard to debug. The best config language I&#x27;ve used is Bazel&#x27;s starlark, which is just python with some additional restrictions.
评论 #42382296 未加载
评论 #42381977 未加载
hbogert5 个月前
Personally I love using Cuelang, but there&#x27;s something about it that makes, at least my colleagues really reluctant to adopt it. Not sure what it is. They don&#x27;t see the benefit.<p>My gut feeling so far is that they don&#x27;t know the benefits of using strictly typed languages. They only see upfront cost of braincycles and more typing. They rather forego that and run into problems once it&#x27;s deployed.
评论 #42405816 未加载
jtmcn5 个月前
We already have an existing project with a bunch of Helm charts deployed using ArgoCD. What would be the benefit of using Holos now?
评论 #42369593 未加载
Kinrany5 个月前
Still waiting for a unified abstraction that covers both frontend libraries like React and GitOps. Where an application is composed out of components that communicate via declarative descriptions of desired states.
woile5 个月前
Hey congrats for the launch!<p>How does it compare to timoni[0]?<p>[0]: <a href="https:&#x2F;&#x2F;github.com&#x2F;stefanprodan&#x2F;timoni">https:&#x2F;&#x2F;github.com&#x2F;stefanprodan&#x2F;timoni</a>
评论 #42381912 未加载
评论 #42382206 未加载
评论 #42382991 未加载
movedx5 个月前
The diagram on the front page immediately makes me question why all of this is so complex given the end goal is to run a process.
评论 #42384710 未加载
评论 #42383741 未加载
评论 #42383455 未加载
_def5 个月前
tangent: how do people in general manage their k8s yaml? Do you keep manifests around, or stuff them away in helm charts? Something completely different? I especially wonder about ways to manage deduplication
评论 #42385143 未加载
评论 #42384362 未加载
评论 #42384619 未加载
cantoni5 个月前
Love this, putting in my back pocket for future Kubernetes integrations.