Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Launch HN: Parity (YC S24) – AI for on-call engineers working with Kubernetes

news.ycombinator.com

Post reply on HN
Print view View original

11–20 of 78 posts

Re: Launch HN: Parity (YC S24) – AI for on-call engineers working with Kubernetes

#11

Post by pmccarren »

stackskipton wrote: post #6

Azure Kubernetes Wrangler (SRE) here, before I turn some LLM loose on my cluster, I need to know what it supports, how it supports it and how I can integrate into my workflow. Videos show CrashLoopBackOff pod and analyzing logs. This works if Pod is writing to stdout but I've got some stuff doing straight to ElasticSearch. Does LLM speak Elastic Search? How about Log Files in the Pod? (Don't get me started on that ni…

> CertManager is on strike and certificate has expired

Had a good chuckle here, hah.

Re: Launch HN: Parity (YC S24) – AI for on-call engineers working with Kubernetes

#13

Post by wilson090 »

stackskipton wrote: post #6

Azure Kubernetes Wrangler (SRE) here, before I turn some LLM loose on my cluster, I need to know what it supports, how it supports it and how I can integrate into my workflow. Videos show CrashLoopBackOff pod and analyzing logs. This works if Pod is writing to stdout but I've got some stuff doing straight to ElasticSearch. Does LLM speak Elastic Search? How about Log Files in the Pod? (Don't get me started on that ni…

Your comment brings up a good point (and also one of our big challenges): there is a huge diversity in the tools teams use to setup and operate their infra. Right now our platform only speaks to your cluster directly through kubectl commands. We’ll build other integrations so it can communicate with things like Elastic Search to broaden its context as needed, but we’ll have to be somewhat thoughtful in picking the highest ROI integrations to build.

Currently, we only handle the investigation piece and suggest a remediation to the on-call engineer. But to properly move into automatically applying a fix, which we hope to do at some point, we’ll need to integrate into CI/CD

As for the demo example, I agree that the issue itself isn’t the most compelling. We used it as an example since it is easy to visualize and set up for a demo. The agent is capable of investigating more complex issues we've seen in our customer's production clusters, but we're still looking for a way to better simulate these on our test environment, so if you/anyone has ideas we’d love to hear them.

We do think this has more value for engineers/teams with less expertise in k8s, but we think SREs will still find it useful

Re: Launch HN: Parity (YC S24) – AI for on-call engineers working with Kubernetes

#14

Post by stackskipton »

wilson090 wrote: post #13
stackskipton wrote: post #6

Azure Kubernetes Wrangler (SRE) here, before I turn some LLM loose on my cluster, I need to know what it supports, how it supports it and how I can integrate into my workflow. Videos show CrashLoopBackOff pod and analyzing logs. This works if Pod is writing to stdout but I've got some stuff doing straight to ElasticSearch. Does LLM speak Elastic Search? How about Log Files in the Pod? (Don't get me started on that ni…

Your comment brings up a good point (and also one of our big challenges): there is a huge diversity in the tools teams use to setup and operate their infra. Right now our platform only speaks to your cluster directly through kubectl commands. We’ll build other integrations so it can communicate with things like Elastic Search to broaden its context as needed, but we’ll have to be somewhat thoughtful in picking the hi…

>we're still looking for a way to better simulate these on our test environment, so if you/anyone has ideas we’d love to hear them.

Pick Kubernetes offering from big 3, deploy it then blow it up.

(I couldn't get HackerNews to format properly and done fighting it)

On Azure, deploy a Kubernetes cluster with following:

Azure CNI with Network Policies

Application Gateway for Containers

External DNS hooked to Azure DNS

Ingress Nginx

Flexible PostGres Server (outside the cluster)

FluxCD/Argo

Something with using Workload Identity

Once all that is configured, put some fake workloads on it and start misconfiguring it with your LLM wired up. When the fireworks start, identify the failures and train your LLM properly.

Re: Launch HN: Parity (YC S24) – AI for on-call engineers working with Kubernetes

#15

Post by jtsaw »

Atotalnoob wrote: post #10
upon_drumhead wrote: post #9

Earlier quoted context omitted.

If an issue can be automatically detected and remediated, do you really need a runbook? That space has to be huge. I don't see a purpose for documenting it. That said, a tool that runs through existing runbooks and improves them or suggests new ones would be extremely useful IMHO.

Improving documentation. Keep in mind, they are suggestions. It sounds like the product will automatically execute runbooks but hold suggestions for engineer input. This would move it from “suggestion” to “automatically do X” Also, sometimes LLMs are wrong.

The product will automatically execute runbooks for you. So far we've focused on using runbooks customers already have, since they know they work for them. We've also added the ability to turn of automatic execution for cases like a suggested runbook, so the customer can make any edits if necessary before approving it to be executed automatically.

Yea, this is a big challenge for us. We're using a variety of strategies to make sure hallucinations are rare, but that's why we're also committed to not executing actions that modify your cluster unless explicitly specified in a runbook

Re: Launch HN: Parity (YC S24) – AI for on-call engineers working with Kubernetes

#19

Post by threeseed »

> This agent is a combination of separate LLM agents each responsible for a single step of the runbook

Someone needs to explain to me how this is expected to work.

Percentage of Hallucinations/Errors x Steps in Runbook = Total Errors

0.05 x 10 = 0.5 = 50%

Re: Launch HN: Parity (YC S24) – AI for on-call engineers working with Kubernetes

#20

Post by threeseed »

upon_drumhead wrote: post #9
Atotalnoob wrote: post #2

It would be kind of interesting if, based on an engineer accepting the suggestion, parity generated a new run book. This would allow repeated issues to be well documented. On iOS Firefox, when clicking “pricing” on the menu, it scrolls to the proper location, but does not close the menu. Closing the menu causes it to jump to the top of the page. Super annoying.

If an issue can be automatically detected and remediated, do you really need a runbook? That space has to be huge. I don't see a purpose for documenting it. That said, a tool that runs through existing runbooks and improves them or suggests new ones would be extremely useful IMHO.

> I don't see a purpose for documenting it.

Enterprises implement stringent Change Management procedures.

If you are making any change to a Prod environment it needs to be thoroughly documented.

Post reply on HN