client-go
helmfile
Our great sponsors
client-go | helmfile | |
---|---|---|
38 | 39 | |
8,530 | 4,020 | |
1.7% | - | |
9.3 | 0.0 | |
8 days ago | 11 months ago | |
Go | Go | |
Apache License 2.0 | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
client-go
-
The Inner Workings of Kubernetes Management Frontends — A Software Engineer’s Perspective
The Kubernetes clients (e.g., Go client) support developers with both methods to connect to a cluster, as we can see in the following examples.
-
Has anyone ever tried to learn how k8s works?
My suggestion would be to start looking at things like https://github.com/kubernetes/client-go first in order to get a feel for the API and how data plane k8s components interact with the apiserver (it's the same thing that kubelet uses). Then move on to trying to build your own k8s operator to get a feel for how people expand and customize k8s functionality without having to modify upstream at all. IMO the codebase itself is too messy and in constant flux to make too much sense of it unless you are planning to contribute to upstream.
-
CUE compared to helm/kustomize...
CUE is cool and all but as soon as I start writing real code structures I want to reach for client-go.
-
Go 1.21 will (probably) download newer toolchains on demand by default
I'm... really not sure I agree with this, from a philosophical point of view. It feels like this is making "eh, we'll just upgrade our Go version next quarter" too easy; ultimately some responsibility toward updating your application's Go version to work with what new dependencies require should fall on Us, the application developers. Sure, we're bad at it. Everyone's lived through running years-old versions of some toolchain. But I think this just makes the problem worse, not better.
Its compounded by the problem that, when you're setting up a new library, the `go` directive in the mod file defaults to your current toolchain; most likely a very current one. It would take a not-insignificant effort on the library author's part to change that to assert the true-minimum version of Go required, based on libraries and language features and such. That's an effort most devs won't take on.
I'd also guess that many developers, up-to this point if not indefinitely because education is hard, interpreted that `go` directive to mean more-of "the version of go this was built with"; not necessarily "the version of go minimally required". There are really major libraries (kubernetes/client-go [1]) which assert a minimum go version of 1.20; the latest version (see, for comparison, the aws-sdk, which specifies a more reasonable go1.11 [2]). I haven't, you know, fully audited these libraries, but 1.20 wasn't exactly a major release with huge language and library changes; do they really need 1.20? If devs haven't traditionally operated in this world where keeping this value super-current results in actually significant downstream costs in network bandwidth (go1.20 is 100mb!) and CI runtime, do we have confidence that the community will adapt? There's millions of Go packages out there.
Or, will a future version of Go patch a security update, not backport it more than one version or so, and libraries have to specify the newest `go` directive version, because manifest security scanning and policy and whatever? Like, yeah, I get the rosy worldview of "your minimum version encodes required language and library features", but its not obvious to me that this is how this field is, or even will be, used.
Just a LOT of tertiary costs to this change which I hope the team has thought through.
[1] https://github.com/kubernetes/client-go/blob/master/go.mod#L...
-
My LFX Mentorship experience with OpenELB
Then on June 18th, 2022, I got a chance to meet our mentors and the other mentee of OpenELB (the mentee and the mentors of OpenFunction were also there). There I was informed about how to start working on the project, so I started learning about using the Kubernetes API client. After experimenting with the official Kubernetes Client, I learned that it's not very feasible to use that for dealing with CRDs (custom resource definitions), so I explored the controller-runtime client as per what I found in many sources, and found that it was a great fit for the backend of our project. During that time, I also built a simple project to see if everything would work as expected or not (as this was the first time I dealt with a Kubernetes client, I considered that debugging would be easier in a smaller project).
- Automatically import Secrets INTO Vault
-
Using client-go to `kubectl apply` against the Kubernetes API directly with multiple types in a single YAML file
I'm using https://github.com/kubernetes/client-go and all works well.
- 深入解析kubernetes中的选举机制
-
Golang for devops
with this https://github.com/kubernetes/client-go (get, delete, create deployments, secrets, pods...)
-
k8s controller to scale up and down namespaces on demand, with an embedded friendly UI
I directly used the client-go package from Kubernetes, as we wrote a controller which does not handle CRDs. If you are already a little bit comfortable with Go (I'm definitely not an expert), you should be able to get on the rails pretty quickly, especially with their examples. I'll be happy to help if needed!
helmfile
-
Deploy IRIS Application to Azure Using CircleCI
What we’re going to install into the newly created AKS cluster is located in the helm directory. The descriptive Helmfile approach enables us to define applications and their settings in the helmfile.yaml file.
-
[2022] [Updated] Alternative to Helmfile
Is there any alternative to https://github.com/roboll/helmfile you are currently using in your company.
-
Projectsveltos: Manage Kubernetes addons in multiple clusters
Interesting, I have approached this problem using Helmfile (https://github.com/roboll/helmfile) to define a “platform release package.”
-
How to Build Software Like an SRE
I agree; helm is too declarative.
Whenever I can, I use helmfile[0] for storing variables for helm since it does add a declarative layer on top of helm.
-
Managing multiple repos
helmfile is something i’ve used in the past for this https://github.com/roboll/helmfile
-
Helm is both "package manager" and "templating engine" - probably the best package manager but horrible template engine
I always felt like dependencies in helm are for very simple non-coupled packages. I many times use Helmfile (https://github.com/roboll/helmfile) to manage dependencies instead of banging my head with vanilla Helm.
-
So I've installed grafana, loki, and prometheus on the personal Kubernetes cluster via Terraform. Now what?
Once you do that, learn to create dynamic helm charts that use go templating and conditionals: https://github.com/roboll/helmfile
-
Interesting tools?
helmfile is not widely known but awesomeme
-
How to keep track of 3d party applications helm chart on K8S?
Not exactly an answer to your question, but we have created a separate project called "cluster" where we define all cluster dependencies via https://github.com/roboll/helmfile, meaning that you always know what (+versions) you have in the cluster and can easily reproduce it. It does not solve an issue with knowing what project has a new version now but at least you can be sure what version is in your cluster
-
Requesting guidance. Helm deployment and structure.
Dont.Use.Umbrella.Charts. If you need to deploy multiple things at once, but you dont wanna deal with relative complexity of Flux or ArgoCD - use helmfile. https://github.com/roboll/helmfile
What are some alternatives?
flux2 - Open and extensible continuous delivery solution for Kubernetes. Powered by GitOps Toolkit.
cdk8s - Define Kubernetes native apps and abstractions using object-oriented programming
helmsman - Helm Charts as Code
kustomize - Customization of kubernetes YAML configurations
helm-operator - Successor: https://github.com/fluxcd/helm-controller — The Flux Helm Operator, once upon a time a solution for declarative Helming.
terraform - Terraform enables you to safely and predictably create, change, and improve infrastructure. It is a source-available tool that codifies APIs into declarative configuration files that can be shared amongst team members, treated as code, edited, reviewed, and versioned.
kubebuilder - Kubebuilder - SDK for building Kubernetes APIs using CRDs
helm - The Kubernetes Package Manager
argocd-image-updater - Automatic container image update for Argo CD
controller-runtime - Repo for the controller-runtime subproject of kubebuilder (sig-apimachinery)
terraform-provider-flux - Terraform provider for bootstrapping Flux
helmwave - New 🌊 wave for @helm