1. 7
  1.  

  2. 2

    This seems to be a nice way to Install/Uninstall k8s resources but the lack of Upgrade path is perplexing. Most tools manipulating the Kubernetes YAML usually do that exactly for this specific use case, including the dreaded diff feature…

    1. 2

      In our company, we have started to generate the k8s resources with the language that we use in our backends: kotlin

      We check in the generated resources as yamls. The yamls are applied with fluxcd.

      This feels incredibly nice, e. g. :

      • you can easily inspect the resulting resources,
      • you can easily diff in for what you deploy,
      • you can make quick emergency adjustments by editing the generated files directly (haven’t needed that yet but nice to have),
      • you can easily unit test your resources.
      1. 1

        This is cool, almost like creating a “mini operator” e.g. you can manage k8s resources with their Go APIs directly, and have application logic that runs if the install doesn’t execute as expected. Having unit tests for all the possible results is a great idea too (what if there is a secret with <x-name> already, I’ll just install with this generated name so as to not conflict).

        I think they’re pitching it wrong though - I understand that getting away from YAML is a goal for some people, but the real perk of this is the extra logic around deployments/resource creation (and being able to test it).

        1. 1

          Using a full programming language for configuring k8s works for complex scenarios, or scenarios which involve a “systems team” providing an API for “development team” so they can configure their services in the organization infrastructure, while staying abstracted away.

          But I wouldn’t use Go for that, I think it’s kinda overkill and don’t think it’s a good language for the task. You’ll appreciate many data manipulation mechanisms and Go is lacking those.