I followed the guide in the following link:
http://blog.kubernetes.io/2017/01/running-mongodb-on-kubernetes-with-statefulsets.html
and set up a mongo DB replica set on Kubernetes with StatefulSets. So far so good, but how do I expose that static hostnames outside the cluster so that I can access them from a Google instance for example?
If I use the IPs of the nodes it will work fine but those can change anytime (upon pod failure and restart with a different IP etc.)...
Thanks in advance!
Adam :
It looks like the answer is present in the StatefulSet Basics documentation section Using Stable Network Identities:\n\n\n The Pods’ ordinals, hostnames, SRV records, and A record names have\n not changed, but the IP addresses associated with the Pods may have\n changed. In the cluster used for this tutorial, they have. This is why\n it is important not to configure other applications to connect to Pods\n in a StatefulSet by IP address.\n \n If you need to find and connect to the active members of a\n StatefulSet, you should query the CNAME of the Headless Service\n (nginx.default.svc.cluster.local). The SRV records associated with the\n CNAME will contain only the Pods in the StatefulSet that are Running\n and Ready.\n \n If your application already implements connection logic that tests for\n liveness and readiness, you can use the SRV records of the Pods ( web-> 0.nginx.default.svc.cluster.local, web-1.nginx.default.svc.cluster.local), \n as they are stable, and your\n application will be able to discover the Pods’ addresses when they\n transition to Running and Ready.\n",
2017-02-21T17:27:34
Spets :
I would strongly suggest taking a glance at the service docs to make sure you're familiar with what is happening:\n\nhttps://kubernetes.io/docs/concepts/services-networking/service/\n\n\n A Kubernetes Service is an abstraction which defines a logical set of Pods and a policy by which to access them - sometimes called a micro-service.\n\n\nWith that in mind and the guide you're using, note the following:\n\n\n You can tell this is a Headless Service because the clusterIP is set to “None.” Other than that, it looks exactly the same as any normal Kubernetes Service.\n\n\nSo what you've created is a headless service(no load balancer or exposed IPs)\n\nSo instead of the configuration given for a headless service:\n\n apiVersion: v1\n kind: Service\n metadata:\n name: mongo\n labels:\n name: mongo\n spec:\n ports:\n - port: 27017\n targetPort: 27017\n clusterIP: None\n selector:\n role: mongo\n\n\nWhat you actually want is:\n\n apiVersion: v1\n kind: Service\n metadata:\n name: mongo\n labels:\n name: mongo\n spec:\n ports:\n - protocol: TCP\n port: 27017\n targetPort: 27017\n selector:\n role: mongo\n\n\nVery subtle but you'll notice that the clusterIP property no longer exists.\n\nI also prefer to specify the protocol, for completeness, even though TCP is the default.",
2017-08-30T07:41:47