Expose a Kubernetes service on your own custom domain
Tags: kubernetes, nginx, tutorial
Published: 2018-09-28 20:13:52

---
title: Expose a Kubernetes service on your own custom domain
published: true
description: This articles shows you how to access your app running in Kubernetes through your custom domain
tags: kubernetes, nginx, tutorial
cover_image: https://cdn-images-1.medium.com/max/2000/0*BloVesNWR4KulwnN
---

You have finally deployed your app to Kubernetes and you bought a cool domain name — ever wondered how to point your cool domain like www.mydomain.com, but cooler, to an app running inside Kubernetes? Well, read on and I’ll try to explain how to do just that!

# What do you need?
Before we get started, make sure you have the following:

* Kubernetes cluster and access to it (i.e. you can deploy stuff)
* Your app* running in the Kubernetes cluster
* Registered domain name (I am using Name.com for my domains, but any other registrar works as well)
* Helm

>Note: I am using the word **app** to represent your code that runs in your cluster and you want to access it through the domain name. Your code is running inside of a Docker image and a Kubernetes pod that’s part of a deployment and is exposed through a Kubernetes service. But **app** is what I’ll use to refer to all this.

Here are the rough steps to follow to hook up the domain with your service:

* Create an Ingress resource
* Deploy the Ingress controller
* Update the domain records to point to the cluster

# Accessing Kubernetes from the outside

A Kubernetes resource called **Ingress** is what manages external access to the apps running inside the cluster. With ingress, you can define rules that tell Kubernetes how to route external traffic to your app. Here’s how an example Ingress resource looks like:

```yaml
apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: my-ingress
  annotations:
     kubernetes.io/ingress.class: nginx
spec:
  rules:
  - host: www.mycoolapp.mydomain.com
    http:
      paths:
      - path: /
        backend:
          serviceName: mycoolapp
          servicePort: 80
```

However, this resource alone is not enough — you also need a controller that knows how to direct the traffic. I will be using the NGINX Ingress Controller, but there are others you could use as well (check out more docs [here](https://kubernetes.io/docs/concepts/services-networking/ingress/)). We will be using [Helm](https://helm.sh) to deploy the nginx-ingress chart like this:

```bash
helm install stable/nginx-ingress
```

The above command takes care of installing the NGINX controller and a default backend. Default backend is an ‘app’ that the ingress will point to by default or in case there are no services defined. As part of the NGINX controller you will also get a service with type LoadBalancer — this is where we you point your domain to.

>Note that there are a plethora of buttons and knobs you can adjust and twist when deploying the controller — there’s a whole list of them here.

With the NGINX ingress controller deployed, let’s figure out what the IP address of the cluster is by running this command:

```bash
kubectl get services --all-namespaces
```

Above command will list out all Kubernetes services running in all namespaces. What you are interested in is any service of type **LoadBalancer** and any service that has an **external IP** set (it’s usually the same service). Here’s how a sample output of the command would look like:

![virtuous-gopher is the name Helm picked for the NGINX controller](https://cdn-images-1.medium.com/max/1000/1*hREGYMrC658q8fiu6UOTkA.png)

The value that’s grayed out next to the `*nginx-ingress-controller` service in the image above is what you need. This is the IP address you will point your domain to.

Or, if you want to be more fancy, you can also run the command below that will filter all services by their type (LoadBalancer) and return you the name and the IP address:

```bash
kubectl get svc --all-namespaces -o jsonpath='{range .items[?(@.spec.type=="LoadBalancer")]}{.metadata.name}:{.status.loadBalancer.ingress[0].ip}{"\n"}{end}'
```

# Pointing your domain to the cluster

Depending on where you registered your domain, the steps might be a bit different, but the gist is the same — you need to create an `A` and `CNAME DNS` records to point your domain (host) to the cluster.

My registrar is Name.com, but I am pretty sure other registrars have some good docs on how to do this as well.

![Heavily redacted view of the DNS records for my domain](https://cdn-images-1.medium.com/max/800/1*sX7VWV8fB1IBxmAvI8jhqw.png)

Here’s what I did: on Name.com I went to my domain and opened the DNS records tab. From there, I was able to add an A record with the host called `www.mycoolapp.mydomain.com` and as an answer, I entered my clusters IP address.

Similarly, I created a `CNAME` record and pointed `mycoolapp.mydomain.com` to the cluster host name (usually, you can find this in your cloud providers settings). You don’t have to provide a `CNAME`, an `A` record is enough. Note that if you don’t provide the `CNAME`, then `mycoolapp.mydomain.com` will not resolve to your app!

# Test it out!
Fire up your favorite terminal or browser and navigate to `mycoolapp.mydomain.com`. Tadaaa — you should be able to get a response back (in my case, the app I deployed was a simple NGINX container, thus the default NGINX page)

![Yes, I own containers.social domain… and bunch more that I’ll never use](https://cdn-images-1.medium.com/max/1000/1*N2GNi8lAGWwzru_4MYeHDQ.png)