Kubernetes

Was super excited to play around with cilium and hubble when the dashboard feature was expired. Meanwhile, I thought of: is there possibility of exporting the metrics to prometheus from the hubble! It would be nice to have that feature - which enable monitoring various aspect of the clusters.

I just saw the email regarding the built in kubernetes dashboard deprecation. This is incredibly disappointing. I chose to use DO because of the guarantees of simplicity and assistance that your web UI and service provide such as built-in web-based tools that go above and beyond. When I use DO, I trust that your service is just going to work and be easy when I need to go in and make changes, add services, or debug. Dashboards for databases and even k8s are a huge part of that. Setting it up on my own is a pain. With that in mind: it is incredibly sad to see the k8s dashboard go away. For many users, having a convenience (even if rare) of the dashboard already working is a big deal. Especially for people that aren't k8s experts, or find that even getting their own dash installed is a headache. I really wish that DO reconsiders this, and that they understand that having a built-in tool to make k8s easier is exactly the type of thing that differentiates DO from other cloud providers (!). Just because the dashboard is rarely used doesn't mean it isn't immensely valued when needed. Maybe you can do a better job advertising that it exists -- or maybe you can survey people and ask them: "Even if you didn't know it existed, are you happy that the k8s dash exists? If you had a production incident and you were on the run with limited tools at your disposal to debug quickly from your browser, would the k8s dash be helpful?" In my case I've used it rarely. But when I did, it was a godsend. Please don't mistake rare usage from the value it provides WHEN it is needed. Thank you for the consideration- I hope to see you reverse this decision.

A way to preserve the real client IP when forwarding UDP traffic through DigitalOcean’s Load Balancer. If that's not currently supported, we would like to know: If there's any workaround supported by DigitalOcean. If there's any plan to support UDP Proxy Protocol . If disabling NAT is possible for UDP services.

Currently, upgrading a Kubernetes cluster with surge upgrade enabled on DigitalOcean still results in downtime, even though the feature is intended to prevent this. We are requesting improvements to the upgrade process to ensure zero-downtime deployments as the cluster scales. Current Behavior: When performing a cluster upgrade: 1. Upgrade is initiated via the dashboard. 2. New nodes are created (takes 1–2 minutes). 3. New nodes appear in management tools (e.g., Lens) after 20–30 seconds. 4. New nodes are tainted as not ready. 5. Old nodes are immediately marked as SchedulingDisabled —this kills all pods before new nodes are ready. 6. New nodes become ready 20–30 seconds later and begin running pods. 7. Full recovery takes several minutes, resulting in noticeable downtime. Expected/Ideal Behavior: The upgrade process should ensure that old nodes are only drained after new nodes are fully ready, minimizing or eliminating downtime. A more robust upgrade flow would be: 1. Start upgrade in the dashboard. 2. New nodes are created (ideally, this should also be faster). 3. New nodes appear in management tools. 4. New nodes are tainted as not ready. 5. Wait until new nodes are fully ready. 6. Only then, drain the old nodes, and wait for the drain process to complete (or timeout after 5 minutes). 7. Once drained, remove old nodes from the cluster. 8. Mark the update as complete. Why this matters: Zero-downtime upgrades are a critical expectation for Kubernetes users, especially as clusters scale and host production workloads. The current process undermines the value of surge upgrades and may force teams to consider alternative providers. Request: • Please adjust the upgrade workflow so that old nodes are only drained after new surge nodes are fully ready. • Consider optimizing node provisioning speed. • Provide more transparency or documentation if there are best practices or settings that can help achieve zero-downtime upgrades. After a chat with support, they told us about Pod Disruption Budgets, however we still strongly encourage prioritizing this feature. Thank you!

Your cluster-lint tool is good; I appreciate its insights. It flags webhooks with timeouts greater than 29 seconds as blocking upgrades. By itself, this is reasonable. Cert-manager ( https://cert-manager.io/ ) is a popular tool for automating renewal of TLS certificates. It installs two webhooks with timeouts of 30 seconds. By itself, this is reasonable. However, this means an unmodified install of cert-manager will block upgrading a DOKS cluster. As an application developer, with no real opinion on how long webhook timeouts should be, this is frustrating. (I was able to edit my cert-manager template to change the timeouts to 29 seconds, so I am able to proceed with my work.) As you and they are only one second apart, it appears that there is not an actual professional disagreement here. Please coordinate with the cert-manager project in setting standards so everyone's tools interoperate.

Even though Kubernetes does not support IPv6, pods running with host networking enabled can make use of the IPv6 address. IPv6 should be enabled by default or there can be an option to enable it for a Kubernetes node pool.

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.

Containerd allows setting a directory for its CRI mirror configuration. Any configuration placed in this directory will be hot reloaded by Containerd. Unfortunately the directory setting requires a restart of Containerd to take effect. Including the following in the Containerd configuration by default would solve this. ```toml version = 2 [plugins."io.containerd.grpc.v1.cri".registry] config_path = "/etc/containerd/certs.d" ``` Having this set is useful for projects like Spegel which makes use of CRI mirror configuration to function. https://spegel.dev/docs/getting-started/

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

Currently Cilium is running in partial mode. Having Cilium replace kube-proxy completely would allow customers to use important features such as socket-based load balancing (which is much more reliable than the current kube-proxy iptables based load balancing) or the use of Cilium Local Redirect Policies, which is required for e.g. NodeLocal DNSCache to seamlessly replace kube-dns.