Our great sponsors
-
WorkOS
The modern identity platform for B2B SaaS. The APIs are flexible and easy-to-use, supporting authentication, user identity, and complex enterprise features like SSO and SCIM provisioning.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
The first link in this article is about switching from fluentbit to fluentd.
Me too. I have issue with fluenbit. Especially around their JSON processing. As in this issue: https://github.com/fluent/fluent-bit/issues/1588
If you want a simple log forwarding, fluentbit is really good. But if you found yourself started to tweak fluentbit config, or write custom plugin in C and (recompile yourself) then it's time to move to fluentd.
What, like the [Cluster API](https://cluster-api.sigs.k8s.io/), [RedHat Advanced Cluster Mgmt](https://www.redhat.com/en/resources/advanced-cluster-managem...), [Rancher](https://rancher.com/), [VMware Tanzu Mission Control](https://tanzu.vmware.com/mission-control)?
Most large enterprises that have been using Kubernetes for a while, have many dozens or hundreds of Kubernetes clusters running.
Clusters for different Business Groups, environments or clouds.
Something needs to manage User Access, Network policies, storage policies/quotas, Security Policies across those clusters.
Something needs to provision, scale, patch and upgrade those clusters in an automated way.
In a way this reminds me of Kubernetes Virtual Clusters. Each virtual cluster has its own tenant control plane, namespaces. Multiple virtual clusters exist in a super cluster.
https://github.com/kubernetes-sigs/multi-tenancy/tree/master...
Isn't that basically what `helmfile`[0] does?
It lets you declaratively define helm deployments, which in turn orchestrate k8s infrastructure.
0 - https://github.com/roboll/helmfile
Disclaimer, I am a CNCF Ambassador (voluntary) - so it's in my interest to promote CNCF projects like Kubernetes.
It seems like a good time to mention my blog post from last year "Then he asked me βIs Kubernetes right for us?" -> https://alexellisuk.medium.com/then-he-asked-me-is-kubernete...
Some of the feedback I've had so far is that it was refreshing to get "permission" to consider alternatives vs. the current hype. I use K8s and K3s quite broadly myself, but increasingly see consulting prospects and customers who are not comfortable to make the leap, but are very happy on managed services with their chosen vendor - Azure / AWS / GCP.
GitLab recently released a bunch of terraform to show you how to run side projects in the free tier of a cloud - https://gitlab.com/gitlab-org/5-minute-production-app/deploy...
The OpenFaaS project again is very coupled to Kubernetes, making it easier to use and more reliable is important to the community and project's future. However, we created a version called faasd that works more like docker-compose. It's received much more traction than we expected and companies and individuals are putting it into production. It does't have clustering, and supports only 1 replica per function, so it's surprising.
I'll keep doing my bit to promote solutions that make K8s easier to understand like K3s (see also k3sup.dev) and to look into alternatives. But as you will see in my blog post - I don't think it's right to assume Kubernetes is the right solution for every team, and every project, without first talking about the problem being solved.
> I'll keep doing my bit to promote solutions that make K8s easier to understand like K3s (see also https://k3sup.dev) and to look into alternatives. But as you will see in my blog post - I don't think it's right to assume Kubernetes is the right solution for every team, and every project, without first talking about the problem being solved.
Thanks for doing your part. Frankly I don't believe the message is being spread enough. At least in the circles I circle, the unspoken expectation to use k8s for "everything" is persistent. The energy that I save by not dealing with it is sometimes spent on explaining why I'm not dealing with it. Yes, entirely an outcome of my circles. I will however share your links in the future, so thanks.