This subject was raised over on Reddit; anyone debating investing time in implementing kOps or learning to use it really needs to read my answer.
Q: Would you recommend kOps or EKS?
A: EKS, and here's why.
I'm 6 years deep consulting supporting dozens of customers using Kubernetes, and while I've used KOPS before and setup masters before, in the last 4 years I haven't touched a master node, and why would I?
Honestly, in this day-in-age, unless you plan to support some on-premises clients, there's no reason to learn to setup and maintain masters. I would say save your time/energy/effort and learn "everything else" about Kubernetes. There's so much to learn, controllers, admissions controllers, ingresses, rbac, network policies, (aws-specific) pod security groups, RBAC->OIDC mapping to IAM roles, services, mesh networks, ingress controllers, etc.
Same reason why I wouldn't recommend an sysadmin/devops person learn to setup and manage a highly-available database any more. Use a cloud providers' managed service and call it a day. You shouldn't need to specialize and learn things that you can push off to someone else who is inevitably better at it than you. It's the "buy-it vs build-it mentality". I lean heavily in the buy/rent/lease it. It allows you, as a professional and business focus solely on your bottom line, on your business, on your core service offering, and not have to have a whole bunch of snowflakes of things that you and your team manage that could have been left to AWS, Microsoft, or Google to manage. Same reason why you don't setup and maintain your own mail server in this day-in-age.
Unfortunately, most engineers LOVE to build things, they love to show this awesome thing they spent so many hours on. When in reality, this only impresses other junior engineers. Senior engineers and architects actually look poorly on this person and their DiY attitude. "Why, sir, did you think you could manage a highly available database better than AWS?". Don't think I haven't asked questions like this to people I manage and work with.
Here's another way to state this. I regularly help in some advisory capacity to companies. If I were to consider acquiring your company, and I saw you, the lead architect, setup your company's services on self-managed nodes it would be a huge "ding" against you, both personally (you, as a fellow engineer and professional) and you as a company. If you set this up, say, 6-7 years ago before EKS existed and haven't had the chance to migrate yet that would be understandable. My advice to the acquiring company is that you have made poor decisions in setting things up that will require significantly more time and effort to maintain over time and would need to be replaced with EKS as quickly as possible.
Also, Kubernetes is the best thing to happen to this industry, period.