HN

Comments (43)

• postalrat
  I think many people have the wrong idea what a container is (or i do) and make it sound more exotic than it is. Sure they have some level of isolation but for someone learning this stuff its better to think of them as just a process, like all the other processes running on your computer. And kubernetes as a system that runs and networks processes running on multiple computers.
• paddw
  > Thinking of Kubernetes as a runtime for declarative infrastructure instead of a mere orchestrator results in very practical approaches to operate your cluster.This is a pretty good definition.I think part of the challenge is the evolution of K8s over time sometimes makes it feel less like a coherent runtime and more like a pile of glue amalgamated from several different components all stuck together. That and you will have to be aware of how those abstractions stick together with the abstractions from your cloud provider, etc...
• Menu

  liampulles
  On the use of GitOps for k8s, I think it makes sense for application workloads, and less sense for raw infrastructure definitions (unless you are running at such a scale that your infrastructure is often scaled like an application).For my infrastructure definition repo, I will apply it in my terminal with kubectl, watch, and then merge the PR/commit to master. I often need to do this progressively just to roll back if I see resource consumption or other issues, it would be quite dangerous to let the CI pipeline apply everything and then for me to try and change declarations whilst the control plane API is totally starved for resources.Also (and maybe this is me not doing "proper devops", I don't care), I will often want to tinker a bit with the declaration, trying a bunch of little changes, and then commiting once all is satisfactory. That "dev loop" is less productive if I have to wait for a CI pipeline for every step.
• oogali
  I sometimes joke that Kubernetes is a mass experiment in teaching people how to write Go via YAML.The giant nested YAML you come across is the input (pre-deserialization)/output (post-serialization) for the declared types:https://github.com/kubernetes/api/blob/master/core/v1/types....Fortunately, or unfortunately, I am the only person that finds humor in this.
• btown
  One approach if "dang it, someone/I needed to use kubectl during the outage, how do we get gitops/poor-mans-gitops back in place to match reality" is, either agentically-looping or artisanally-looping, to try simple gitops configurations (or diffs to current gitops configurations) until a dry-run diff with your live configuration results in no changes.For instance, with Helm, I've had success using Helmfile's diffs (which in turn use https://github.com/databus23/helm-diff) to do this.There's more of a spectrum between these than you think, in a way that can be agile for small teams without dedicated investment in gitops. Even with the messes that can occur, I'd take it over the Heroku CLI any day.
• tbrownaw
  It's an application server for multi-part containerized applications, like Tomcat is an application server for applications that can be turned into .war files.
• Menu

  websiteapi
  I always wonder if things can be simpler. When you think of a really simple DB you think of SQLite. What's the really simple K8s? Even doing a single node deployment these days seems complicate with Prometheus, Grafana, etc. etc. docker/podman compose up with quadlets and all of this stuff just seems so eh.I really like the idea of something like Firebase, but it never seems to work out or just move the complexity to the vendor, which is fine, but I like knowing I can roll my own.
• Menu

  NewJazz
  Love the HN title mod here lol
• Menu

  zsoltkacsandi
  > Thinking of Kubernetes as a runtime for declarative infrastructure instead of a mere orchestrator results in very practical approaches to operate your cluster.Unpopular opinion, but the source of most of the problems I've seen with infrastructures using Kubernetes came from exactly this kind of approach.Problems usually come when we use tools to solve things that they weren't made for. That is why - in my opinion - it is super important to treat a container orchestrator a container orchestrator.
• blackjack_
  Yes, there is a term for a system that handles a declarative state of infrastructure and does reconciliation versus current state; a control plane. We have been talking about control planes in devops/ SRE for a number of years now! Welcome to the conversation.
• Menu

  anymouse123456
  The allure of declarative approaches to complex problem solving has finally been worn down to nothing for me and Kubernetes was the last straw, nearly 10 years ago.The mental gymnastics required to express oneself in yaml, rather than, say, literally anything else, invariably generates a horror show of extremely verbose boilerplate, duplication, bloat, delays and pain.If you're not Google, please for the love of god, please consider just launching a monolith and database on a Linux box (or two) in the corner and see how beautifully simple life can be.They'll hum along quietly serving many thousands of actual customers and likely cost less to purchase than a single month (or at worst, quarter) of today's cloud-based muggings.When you pay, you'll pay for bandwidth and that's real value that also happens to make your work environment more efficient.