community VS k8s-config-connector

Multiple container runtimes are supported, like conatinerd, cri-o, or other CRI compliant runtimes.

More recently, the Kubernetes SIG Network has been evolving the Gateway API to support service meshes.

https://github.com/kubernetes/kubernetes https://www.kubernetes.dev/resources/calendar/ https://github.com/kubernetes/community/blob/master/governance.md https://github.com/kubernetes/steering https://github.com/kubernetes/community/blob/master/sig-list.md

According to this doc it takes the average of CPU utilization of a pod (average across the last 1 minute) divided by the CPU requested by the pod. Then it computes the arithmetic mean of all the pods' CPU.

metrics-server has not supported kubectl top Resource Metrics API

With the Gateway API being a superset of the Ingress API, it might make sense to consolidate both. Thanks to the SIG Network community, Gateway API is still growing and will soon be production ready.

Projects in/around Kubernetes and the CNCF are generally where I spend what little time I can these days. Most communities are incredibly welcoming and provide timely feedback. But the problem space of "managing a cloud platform" can take several years to really wrap ones head around, setting aside focused topics via SIGs like networking, storage, observability, API design, etc.

Krew is a plugin manager maintained by the Kubernetes Special Interest Group (SIG) CLI community. Krew makes it easy to use kubectl plugins and helps you discover, install, and manage them on your machine. It is similar to tools like apt, dnf, or brew. Today, over 200 kubectl plugins are available on Krew - and that number is only increasing. Some projects are actively used and some get deprecated over time, but are still accessible via Krew.

[1] https://k8s.devstats.cncf.io/d/9/companies-table?orgId=1&var-period_name=Last%20decade&var-metric=contributions [2] https://kubernetes.io/releases/release/ [3] https://github.com/kubernetes/community/blob/master/governance.md [4] https://github.com/kubernetes/community/blob/master/sig-list.md

If your company is k8s centric and the developers are most comfortable with k8s, you might want to focus more on something specific to k8s such as helm, or even if you don't get into helm you may want to use config connector in your yaml to manage GCP resources in an IaC compliant method. You can manage k8s resources with terraform, but if your developers are currently comfortable working directly with k8s you are going to see significant pushback getting them to add terraform as a middleware. You probably still want to manage your GKE clusters and VPCs with terraform since you can't really use config connector.

Config Connector [1] is also an option in this space for GCP, it supports many GCP resources and thus far our experience with it has been largely positive.

[1] https://cloud.google.com/config-connector/docs/overview

We use it heavily with GCP's Kubernetes Config Connector to provision architecture. It could similarly be used for Cloud Functions, etc. given a repo URL that GCP can access. GitOps + operator pattern is a pretty powerful mechanism to let k8s continuously seek state towards your ideal. https://cloud.google.com/config-connector/docs/overview

For K8s, we were using Cloud Composer to do it for us but wanted more fine control over CI/CD, so we decided to go with Airflow on K8s. That's all hosted in GKE now and deployed using ArgoCD with helm. This also led down the IaC rabbit hole which has been a ton of fun too. We use the GCP ConfigConnector resources for that which is a little challenging at first, but gets a lot easier as time goes on.

Terraform is 90% of cloud IaC. But there are newer Kubernetes Operators like Config Connector that can create cloud specific resources.

It works particularly well with Google Config Connector as then it's all just manifests.