91–100 of 162 posts
Earlier quoted context omitted.
Every time I read an article on k8 it feels like one of those last 90s XML “now you have two problems” jokes...
Frankly K8 reminds me more J2EE EJB 2.X. Horrific complexity that provides not that much after all.
I learned not to use it and wait until the k8s fad goes away.
My disappointment with Kubernetes as the next/current big thing is that it practically didn't change a thing for companies as a whole. You still need dedicated devops people / a dedicated team. There is so much to get wrong regarding security, reliability and performance. Most application developers stay away from k8 configuration and could not quickly replace a devops engineer. They are the wizards holding the power…
The practical results for me were:
* Having to write a CLI app to reduce the time wasted and spit out simple config templates for our actual (very much not Google-scale) use case
* Whenever something didn't work, throw it over the wall and hope the DevOps gods deemed us worthy
I like tools that have sensible defaults and try to stay out of your way. K8s fails on both counts in my experience.
I learned not to use it and wait until the k8s fad goes away.
Why would you think it would go away? Its literaly the best option currently for what it is doing. It has an unprecedented support behind it as well. Multiply Vendors support it through a certificate k8s managed service. It solves really problems out ouf the box like load balancing, ingress, cert management, autoscaling, health checks, autorepair. It allows for simple IaaC. Is it young? Yes. Do we need more people wi…
Earlier quoted context omitted.
Every time I read an article on k8 it feels like one of those last 90s XML “now you have two problems” jokes...
Frankly K8 reminds me more J2EE EJB 2.X. Horrific complexity that provides not that much after all.
Now you can have all this complexity even in other languages than Java.
Are containers providing enough long-term cost-effectiveness to a complete cloud-native application architecture?
Or is it just mapping VMs to something “like” VMs so your topology remains mostly the same?
Earlier quoted context omitted.
Why would you think it would go away? Its literaly the best option currently for what it is doing. It has an unprecedented support behind it as well. Multiply Vendors support it through a certificate k8s managed service. It solves really problems out ouf the box like load balancing, ingress, cert management, autoscaling, health checks, autorepair. It allows for simple IaaC. Is it young? Yes. Do we need more people wi…
I dunno, because of writeups like GitLabs? We're lucky GitLab is so transparent. It lets us see that their claims don't appear to always match the actual reality. Here's an example. Blog post says: "After transitioning each service, we enjoyed many benefits of using Kubernetes in production, including much faster and safer deploys of the application, scaling, and more efficient resource allocation" Wrong. Actual anal…
This is only one of the shards of one service that we migrated, and we migrated many more.
I did a high level writeup of this and many other things we've observed in https://about.gitlab.com/handbook/engineering/infrastructure...
if you are curious. I am happy to have a conversation with anyone about our experiences in more detail, not to convince anyone that k8s is the "one-true-way" (because I am still not convinced myself), but of the benefits this type of change can bring.
> They tried to use auto-scaling but failed completely and ended up disabling it
That issue is just one of many though. We disabled it at the time, but we have it enabled for a number of other services.
Regardless of how I personally feel about K8s, I have to say that the migration we are doing for GitLab.com is generating set of benefits that goes far beyond just moving to a new platform.
One of the largest benefits I've seen so far is that it was a great forcing function to resolve some long running architectural challenges, and is making us think more about how the application can run at a very large scale, without being at the very large scale. Things that we could get away before, like the issue you referenced there, we can't anymore.
Disclaimer: I am one of the people involved in this migration.
It reads like a press release, no gotchas, no complaints... https://k8s.af/
I think a lot of complaints we would usually have are reduced due to the fact that we use managed K8s with GKE.
All other complaints I can think of are related to our application and some architecture decisions we made early on, but that won't be interesting to anyone but people at GitLab.
Kubernetes works at its most efficient when you scale by adding more Pods, rather than scaling within a Pod. Requests and limits should be equal to each other, and a HorizontalPodAutoscaler (or KEDA Scales object) should be used to add more Pods as utilization increases. Using Cluster Autoscaler then makes sure that your cluster has sufficient Nodes to schedule the Pods. Then you just need to set up alerting to tell you if the autoscaling reaches minimums (indicating that you should consider lowering the minimum, to improve efficiency) or maximums (indicating that you should consider increasing the maximums), and you can leave things well enough alone, unless the speed at which scaling occurs is insufficiently slow for your use case.
I do have only very minimal xp in k8s, as I have tried to use it only once (and never again). To me it seem like mOst of the comments are about the unusable and unmaintainable yaml configuration files. This seems like exactly the issue I had a few years ago, when I was cursing, because I could not find a spec or docs for the yaml stuff in all the pages and pages of seemingly important documentation and thus could not…