Kubernetes: Routing Internal Services Through FQDN

Jonathan Campos
Jul 10, 2018 · 4 min read
Image for post
Image for post
Photo by Jason Rosewell on Unsplash

What Does Routing Internal Services Through FQDN Look Like?

When calling external services you may be used to writing fully qualified domain names (FQDN), like the following.

// FQDN = some.url.com
// port = 80
// endpoint = /service


http.get('some.url.com/service', (response) => {
//simplified
res.status(200).json(response);
});
apiVersion: v1
kind: Service # a way for the outside world to reach the Pods
metadata:
# any Pods with matching labels are included in this Service
name: service-1 # service name
spec:
# Service ports
ports:
service-1.default.svc.cluster.local
service-1.default.svc.cluster.local
service-1.default

Why Use FQDN Routing In Your Application?

As you will see from the example provided below, it is really simple to insert parameterized routing into your application. This is extremely helpful with Kubernetes as you might want to have slightly different routing based on environments or other rules.

Run An Internal FQDN Route

I’ve created an example project to highlight this feature. For this example I used pod environment variables and a single application to inject the necessary variables into the application so we can see how one service can call another.

- name: FOREIGN_SERVICE
value: service-2.default.svc.cluster.local
- name: FOREIGN_PATH
value: /service-2
router.get('/foreign', function (req, res, next) {
const url = config.get('FOREIGN_SERVICE') + config.get('FOREIGN_PATH');
http.get(url, response => {
let data = '';
response.on('data', chunk => {
data += chunk;
});
response.on('end', () => {
res.status(200).json(JSON.parse(data));
});
}).on('error', err => {
throw err;
});
});
$ git clone https://github.com/jonbcampos/kubernetes-series.git
$ cd ~/kubernetes-series/communication/scripts
$ sh startup.sh
$ sh deploy.sh
$ sh check-endpoint.sh service-1
Image for post
Image for post

Teardown

Before you leave make sure to cleanup your project so you aren’t charged for the VMs that you’re using to run your cluster. Return to the Cloud Shell and run the teardown script to cleanup your project. This will delete your cluster and the containers that we’ve built.

$ cd ~/kubernetes-series/communication/scripts # if necessary
$ sh teardown.sh


Google Cloud - Community

Google Cloud community articles and blogs

Jonathan Campos

Written by

Excited developer and lover of pizza. CTO at Alto. Google Developer Expert.

Google Cloud - Community

A collection of technical articles and blogs published or curated by Google Cloud Developer Advocates. The views expressed are those of the authors and don't necessarily reflect those of Google.

Jonathan Campos

Written by

Excited developer and lover of pizza. CTO at Alto. Google Developer Expert.

Google Cloud - Community

A collection of technical articles and blogs published or curated by Google Cloud Developer Advocates. The views expressed are those of the authors and don't necessarily reflect those of Google.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store