We have been asked for over a year now what our "Kubernetes Strategy" is, and our answer has always been the same:
"Portainer's sole reason for being is to simplify container platform operations; when Kubernetes gets simplified, we will integrate it into Portainer".
Well, we have come to a point where we now believe that its impossible to simplify Kubernetes to a level where we can verbosely pass through and visualize its plethora of functions 1:1, akin to what Kubernetes' native dashboard does. We need to take a different approach.
Our approach is going to be controversial, and those that truly love Kubernetes (in all its glory) are more than likely going to hate our approach - we are OK with that. Portainer has always been focused on enabling the masses, and as such, we want to make Kubernetes usable by the masses too.
Cloud providers (and some software solutions) are doing a really good job at making Kubernetes easy to use through their "Managed Kubernetes Service" solution. These managed solutions take a lot of the operational pain away from having to actually run a Kubernetes platform. However, an operator does still (really) need to know how to deploy (and support/troubleshoot) an application atop Kubernetes for maximum resilience, scale, security, and performance.
Portainer is not about trying to simplify the process of building a Kubernetes (or a Docker Swarm for that matter) cluster. We are about simplifying the end user's consumption of the technology. This means that a combination of a managed Kubernetes service PLUS Portainer, will provide an incredibly easy-to-use Kubernetes landscape.
So, what is our strategy then?
Simple: We'll abstract away as much of the end-user-irrelevant Kubernetes terminology from the front-end as possible.
This means we won't have a notion of PODs, Deployments, DaemonSets, ReplicaSets or StatefulSets; we won't expect the user to be familiar with VolumeClaims, Taints or Tolerations. What we will do is ask plain English (or IT generalized) questions via the UI, which will allow us to ascertain how best to deploy your application on Kubernetes.
We'll then handle the deployment complexity for you. We call this being "opinionated" and those who have used Portainer for a while will be aware that we already do this for Docker Swarm too (to a lesser degree though, as swarm is already relatively simple).
When do we plan to release a version of Portainer with support for Kubernetes?
Well, that's the million dollar question.. and the answer is... it depends. There is a LOT of development needed, and then a lot of testing to complete as well... We are targeting this year (2019), but in parallel, we need to keep improving the as-is platform, releasing more extensions, releasing an enterprise supportable version, and releasing a version tailored for Edge Compute use cases...So there's lots to do, and the pace of our Kubernetes development depends to some degree on community response to the strategy stated above.
Hope this helps clarify what we are doing with Kubernetes.