Replace the disclaimer part with an in-text paragraph.

Signed-off-by: Milan Plzik <[email protected]>

Author: mplzik

content/en/blog/_posts/2023-11-16-the-case-for-kubernetes-limits/index.md

@@ -7,14 +7,10 @@ slug: the-case-for-kubernetes-resource-limits
 
 **Author:** Milan Plžík (Grafana Labs)
 
-
-
-_Milan Plzik is a Site Reliability Engineer on the [Grafana Labs](http://grafana.com) platform team, which maintains and improves internal infrastructure and tooling used by the product teams. As part of the infrastructure squad, he is primarily trying to make Kubernetes upgrades as smooth as possible. He likes going down the rabbit hole of various interesting Kubernetes issues._
-
-_Disclaimer: This article reflects the author's personal opinion; feel free to disagree. Also, there are a lot of subjective ideas that have not made it through any kind of rigorous testing. Use at your own risk._
-
 There’s been quite a lot of posts suggesting that not using Kubernetes resource limits might be a fairly useful thing (for example, [For the Love of God, Stop Using CPU Limits on Kubernetes](https://home.robusta.dev/blog/stop-using-cpu-limits/) or [Kubernetes: Make your services faster by removing CPU limits](https://erickhun.com/posts/kubernetes-faster-services-no-cpu-limits/) ). The points made there are totally valid – it doesn’t make much sense to pay for compute power that will not be used due to limits, nor to artificially increase latency. This post strives to argue that limits have their legitimate use as well.
 
+As a Site Reliability Engineer on the [Grafana Labs](https://grafana.com/) platform team, which maintains and improves internal infrastructure and tooling used by the product teams, I primarily try to make Kubernetes upgrades as smooth as possible. But I also spend a lot of time going down the rabbit hole of various interesting Kubernetes issues. This article reflects my personal opinion, and others in the community may disagree.
+
 Let’s flip the problem upside down. Every pod in a Kubernetes cluster has inherent resource limits – the actual CPU, memory, and other resources of the machine it’s running on. If those physical limits are reached by a pod, it will experience throttling similar to what is caused by reaching Kubernetes limits.
 
 ## The problem