Implementing a Microservice on Kubernetes typically comprises of:
In terms of Kubernetes JSON resources; a micro service is a Replication Controller and Service metadata.
Check the service discovery docs.
Namespaces are a great way in kubernetes to group related pods and services together to get easy service discovery without requiring environment-specific configuration or service linking. They also provide role based authentication (RBAC).
The more related apps (pods and services) are in the same namespace, the easier it is for service discovery and the less configuration or service linking you need to do. The flip side is, the more namespaces you have, the easier it is to get finer grained RBAC policies on who can view or change apps in the namespace.
So our recommendation is use a namespace for each environment (e.g. Dev, Test, Staging, Production) for each team. You can then define who has what roles in each team; then you can define the environments for each team.
You may find that namespaces can be shared across teams (e.g. maybe Staging contains the apps from multiple teams) so use your best judgement. There’s nothing stopping you just having, say, 1 namespace for all your production apps; but given companies often split ‘all of production’ into separate teams who look after different parts; its probably a case where you refactor “production” into separate production teams and they each have their own namespace per environment (they may want a Staging and Production environment for example).
In a pure Microservice world, you may have 1 namespace per environment per Microservice; though that might be a bit granular for every environment (you may wish to colocate multiple Microservices in the same namespace). Though even a single Microservice might be a collection of pods and services - whether its cassandra, kafka, riak, elasticsearch or whatever. Really a Microservice just represents a ‘chunk’ of a monolith thats built, released & managed by a separate independent team.
If you do go the direction of one Microservice per namespace; you’ll have all the Kubernetes Services you need for your app in your namespace; but they will be remote (implemented typically outside your namespace) so you’ll use external services or service linking to point to the implementations you need (using Endpoints rather than using the usual pod selectors in Kubernetes services
You can browse the Kubernetes REST API using the Swagger Site.
To browse the OpenShift Swagger docs for your installation:
Proceed to vagrant.f8 (unsafe)
Explorebutton and profit!