How to alias my domain's subdomain with my jelastic environment subdomain?

Question

I have a kubernetes cluster hosted on a Jelastic environment env.jelastic-provider.com. In that k8s cluster, I am exposing a frontend app on app.env.jelastic-provider.com. I would like to use a CNAME record to alias my custom domain www.example.com to the frontend subdomain app.env.jelastic-provider.com. How can I achieve that? My DNS provider does not propose ANAME records.

Currently, I have defined a CNAME record aliasing www.example.com to app.env.jelastic-provider.com on my dns provider. On the Jelastic side, I've bound www.example.com to env.jelastic-provider.com with the jelastic.environment.Binder.BindExtDomain api method, which of course doesn't work, because I'd need to bind to app.env.jelastic-provider.com, which does not seem to be possible.

Do I have a way out not involving:

• serving my frontend e.g. through CDN instead of my cluster
• using ANAME record

?

Edit

Following the advice of Jelastic and of my Jelastic provider, I was able to make some good progress. Today, it turns out attaching external IPs to the k8s cluster worker nodes is not supported yet. It will come in a later release of the jelastic kubernetes jps. We can see in that manifest that most of the configuration is there, just the attachment of the IP to the worker nodes isn't done, as it is pretty involved.

Therefore, the only solution I am left with, according to this answer from Jelastic, is that I add an nginx load-balancer in front of my k8s cluster and configure the dns for it. To do so, I need to configure SSL on that nginx instance, as the cluster will not work correctly without https. So the first steps are

1. Add nginx node in front of the cluster
2. Install let's encrypt addon on the nginx node
3. Configure an A record on my domain provider panel, where I link the IPv4 address resulting from the previous let's encrypt installation with www.example.com
4. When the A record is valid, update the let's encrypt addon so that it takes the domain into account.

Also, I got rid of my domain bindings, as they are useless with A records.

If I do all that, then I can again access a working k8s cluster. The kubernetes dashboard as well as the kubernetes api are working.

What is, however, not working, is the access to my cluster's subdomains. As I stated in my original post, I need to access app.env.jelastic-provider.com. This is where I am now stuck. How can I now access that subdomain?

Answer 1

Usage of CNAME together with Public IP the only way out you are looking for.

Custom Domain Name

Public IP

Answer 2

So, long story short. After the initial configuration mentioned in the edit of my initial post,

1. Add nginx node in front of the cluster
2. Install let's encrypt addon on the nginx node
3. Configure an A record on my domain provider panel, where I link the IPv4 address resulting from the previous let's encrypt installation with www.example.com
4. When the A record is valid, update the let's encrypt addon so that it takes the domain into account.

the address https://www.example.com leads to my cluster back again, with working k8s dashboard and api. Then,

1. in my domain provider, I've added another A record for app.env.jelastic-provider.com pointing to the IPv4 of the nginx load-balancer with name app
2. in the let's encrypt configuration of the nginx load-balancer, I've added the app.example.com external domain
3. in the nginx-jelastic.conf file, I've added

server {
    listen *:80;
    listen [::]:80;
    server_name  app.example.com;

    location / {
            proxy_pass http://app.env.jelastic-provider.com;
    }
}

4. in the ssl.conf, I've added

server {
  listen 443 ssl;
  server_name app.example.com;
  ssl_certificate      /var/lib/jelastic/SSL/jelastic.chain;
  ssl_certificate_key  /var/lib/jelastic/SSL/jelastic.key;
  ssl_protocols TLSv1.2 TLSv1.3;
  ssl_ciphers HIGH:!aNULL:!MD5;

  location / {
    proxy_pass http://app.env.jelastic-provider.com;
  }
}

Of course, the above SSL config is not perfect, it must be tuned for production purposes.

EDIT

I noticed there is one downside to this way of proceeding with the frontal nginx load-balancer. Whatever headers / config you set in the load-balancer will be somehow overriden by the cluster's own ingress controller. If you go down this way, make sure both configs are kept consistent...