Kubernetes

Since DOKS already uses Cilium as its CNI, it would be helpful to join multiple DOKS clusters together with Cilium Cluster Mesh. This is especially nice to have a super cluster spread across multiple data centers or regions, with telemetry that encompasses everything.

We're using DOKS with Cilium/Hubble and Prometheus scraping Hubble metrics. Today, the cluster exposes a fixed static set of metrics through cilium-config (dns, drop, flow, flows-to-world, httpV2, icmp, kafka, port-distribution, tcp). We're on DOKS 1.36.0-do.0 and see that enable-dynamic-config is already set to true, but Hubble is still using the static exporter and there is no supported dynamic Hubble metrics ConfigMap wired in. What we want is a supported way to add or change Hubble metrics without editing the managed Cilium config and without restarting Cilium. Right now that isn't possible on our cluster, and it makes observability changes risky for a managed setup.

Please release a way to make k8s users authenticating through an OpenID Connect Identity provider, it would greatly enhance the maneageability for those organization already using this way of authenticating. I really like DO k8s, but I'm not sure I'm going to use it on a wider scale due to this limitation; as you know for sure, other cloud providers allow it.

Ubuntu takes up a lot of background resources which makes it uneconomic for horizontal scaling with small instances. I suggest having more options for managed kubernetes. Some of my suggestions: Talos OS Bottlerocket Debian Fedora

as The DOKS use a Cilium as the default CNI, currently the cluster does not work with Istio ambient mode due to the Bpf masquerade is enabled by default in the cilium configmap, which prevents kubelet from doing the health check to pods. When the bpf masquerade is disabled(manually change the configmap), all are working as expected. In the offical Istio document, they also said that when the cluster uses Cilium as the CNI, the bpf masquerade need to be disabled, view more details here https://istio.io/latest/docs/ambient/install/platform-prerequisites/#cilium

Implement the IPmode Proxy in the cloud-controller-manager to solve the problem of flow to a load balancer from a pod in the case of using the proxy protocol, see https://github.com/digitalocean/digitalocean-cloud-controller-manager/issues/811

Cilium includes built-in WireGuard transparent encryption for securing pod-to-pod and node-to-node traffic, but this feature isn’t available on DOKS today. Adding an option to enable it at the cluster level would make it much easier to improve in-cluster security without extra components or custom setups.

It would be great if DigitalOcean Kubernetes supported optional sandbox runtimes such as gVisor for enhanced security isolation. Currently, DOKS allows only the default containerd runtime, but sandboxed runtimes like gVisor can greatly improve multi-tenant workload safety and protect the host from untrusted or AI-generated code. As a proof of concept, I managed to deploy gVisor manually using a privileged DaemonSet that installs the runsc and containerd-shim-runsc-v1 binaries on each node, updates the containerd configuration, and enables a RuntimeClass: gvisor. It works, but it’s not officially supported and would break with node replacements or upgrades.

Problem When using a DOKS cluster with a LoadBalancer type Service, the CCM automatically manages a k8s-public-access-* firewall and adds inbound rules for the service ports (e.g. 80, 443) with source hardcoded to 0.0.0.0/0 / ::/0. There is no way to restrict these rules to private or specific CIDRs only. Any manual changes to the firewall are reverted by the controller on the next reconcile. Expected behavior Allow specifying allowed source CIDRs for the auto-managed firewall inbound rules, for example via a Service annotation or a CCM environment variable — similar to how spec.loadBalancerSourceRanges works for the Load Balancer itself. Use case Clusters behind Cloudflare (or any CDN/proxy) should only accept traffic from the CDN IP ranges — not from the entire internet. Right now this is only possible at the Load Balancer level (spec.loadBalancerSourceRanges), but the node-level firewall stays wide open regardless.

Pod limit is same - 110 pods. No matter do you run 1cpu ram instance or 32cpu. We run many tiny idle pods for our "review apps" cluster and utilize large nodes to save on control plane memory overhead. And we became capped by pod count limit while having plenty of CPU and RAM. We'd like to have pods count limit scaled with cores count or allow user to overwrite it (i.e. let user be responsible for node stability).