I'm working on the microservices project that is the dockerized Spring Cloud Netflix project and contains 3 microservices except for some Netflix services which are turbine,zipkin,discovery,configserver etc , yet.
(Its just working on locally now..)
Soon, I decided to deploy my project to a cloud provider with an orchestration tool.
After some researches, I decided to use Kuberenetes.
But, both of Spring Cloud Netflix and Kubernetes have some solutions for distributed systems: service discovery, load balancing, fault-tolerance, etc..
In that case, using Netflix libs. seem unnecessary with Kubernetes.
I read this and this. I think Spring Cloud Kubernetes looks like a workaround solution.
So my questions are :
I think that Christian Posta article you refer to is very good. As he says, you can deal with the most common use-cases with the out of the box Kubernetes solutions for discovery (kub dns), load-balancing (with Services) and edge services/gateway (Ingress).
As Christian also points out, if you need to dynamically discover services by actively querying rather than knowing what you are looking for then Spring Cloud Kubernetes can be better than going directly to Kubernetes Apis. If you need to refresh your app from a config change and see it update quickly without going through a rolling update (which would be needed if you were mounting the configmap as a volume) then Spring cloud Kubernetes config client could be of value. The ribbon integration could also be of value if you need client-side load-balancing. So you could start out without Spring Cloud Kubernetes and add parts of it if and when you find that it would help. I think it is better to think of the project as adding extra options and conveniences rather than alternatives to Kubernetes-native solutions.
It is also worth noting that you can deploy a Netflix stack app to Kubernetes (including using Zuul and eureka) and there isn't necessarily anything wrong with that. It has the advantage that you can work with it outside Kubernetes and it might be more convenient for your particular team if it's Java team. The main downside is that the Netflix stack is very tied to Java, whereas Kubernetes is language neutral.