yes got it. Yes that’s right.

--
Srinivas Kotaru

From: "[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Date: Friday, March 11, 2016 at 10:59 AM
To: skotaru <[email protected]<mailto:[email protected]>>
Cc: Aleksandar Lazic 
<[email protected]<mailto:[email protected]>>,
 Jordan Liggitt <[email protected]<mailto:[email protected]>>, 
"[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Subject: Re: api and console port : 8443

I mean, low TTL for the DNS, so that if you want to dynamically update them you 
can at least in theory change them.  If you have those being VIPS, less of a 
concern.

On Fri, Mar 11, 2016 at 1:48 PM, Srinivas Naga Kotaru (skotaru) 
<[email protected]<mailto:[email protected]>> wrote:
Thanks Clayton. Am also excited to see how it works. As you said, it should as 
per theory

Sure will keep a low TTL for master VIP. Just curios, any reason why low TTL ?


--
Srinivas Kotaru

From: "[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Date: Friday, March 11, 2016 at 10:33 AM
To: skotaru <[email protected]<mailto:[email protected]>>
Cc: Aleksandar Lazic 
<[email protected]<mailto:[email protected]>>,
 Jordan Liggitt <[email protected]<mailto:[email protected]>>, 
"[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>

Subject: Re: api and console port : 8443

It should, although I would set a low TTL on the load balancer.  We'll make 
sure to test with this configuration as well.

On Fri, Mar 11, 2016 at 1:17 PM, Srinivas Naga Kotaru (skotaru) 
<[email protected]<mailto:[email protected]>> wrote:
Thanks for sharing your experience and writeup

We decided to go with different route. don’t want to involve run time layer 
with management traffic and also simplify as much as possible since we have 
multiple clusters in each life cycle ( non prod, prod etc)

This is final approach we decided to go

1.  Change port 8443 to 443 during ansible fresh installation ( Our Dev builds 
starting this week onwards)
2. Use a DNS based load balancer to forward to 3 masters in each cluster.

Hope this works. Pl comment if it doesn’t work so we can a fresh look.

--
Srinivas Kotaru

From: Aleksandar Lazic 
<[email protected]<mailto:[email protected]>>
Date: Friday, March 11, 2016 at 2:29 AM

To: skotaru <[email protected]<mailto:[email protected]>>, Jordan Liggitt 
<[email protected]<mailto:[email protected]>>, 
"[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Subject: Re: api and console port : 8443


Hi.


I have read this post and the solution works.

The handycap from my point of view is that you will need to use official 
certificates in the master(s).

I have written a more or less detailed description how we at cloudwerkstatt 
solved this issue.


https://alword.wordpress.com/2016/03/11/make-openshift-console-available-on-port-443-https/

[X]<https://alword.wordpress.com/2016/03/11/make-openshift-console-available-on-port-443-https/>

Make OpenShift console available on port 443 
(https)<https://alword.wordpress.com/2016/03/11/make-openshift-console-available-on-port-443-https/>
alword.wordpress.com<http://alword.wordpress.com>
Introduction The main reason why this blog post exist is that OpenShift V3 and 
Kubernetes is very close binded to port 8443. This could be changed in the 
future. We at Cloudwerkstatt GmbH use a ded…


Feedback is very welcome.


Best Regards

Aleks

________________________________
From: Srinivas Naga Kotaru (skotaru) 
<[email protected]<mailto:[email protected]>>
Sent: Thursday, March 10, 2016 18:47
To: Aleksandar Lazic; Jordan Liggitt; Clayton Coleman
Cc: [email protected]<mailto:[email protected]>
Subject: Re: api and console port : 8443

Got it  thanks

Someone write a decent article on how to run master on 443 by taking advantage 
of service and external end point.
https://blog.openshift.com/run-openshift-console-port-443/
[X]<https://blog.openshift.com/run-openshift-console-port-443/>

Run OpenShift console on port 443 – OpenShift 
Blog<https://blog.openshift.com/run-openshift-console-port-443/>
blog.openshift.com<http://blog.openshift.com>
This post, will help you to make the OpenShift console run on port 443 by using 
the openshift-router facilities, service and endpoints.


Your setup or article content is pretty much inline with hosting a simple tcp 
based load balancer and listen on VIP:443 for client requests and forward it to 
masters:8443.

I knew api and console can be load balanced for HA. Am not tested we can use 
the same VIP for controller. I knew it is still active/passive.

--
Srinivas Kotaru

From: Aleksandar Lazic 
<[email protected]<mailto:[email protected]>>
Date: Thursday, March 10, 2016 at 1:20 AM
To: skotaru <[email protected]<mailto:[email protected]>>, Jordan Liggitt 
<[email protected]<mailto:[email protected]>>, 
"[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Subject: Re: api and console port : 8443


Hi.


                                   [tls passthrough]

openshift-default-router ---> [POD own haproxy with ssl] --> master:8443


you can think on this like a reverse proxy, which it is ;-)


BR Aleks

________________________________
From: Srinivas Naga Kotaru (skotaru) 
<[email protected]<mailto:[email protected]>>
Sent: Thursday, March 10, 2016 09:41
To: Aleksandar Lazic; Jordan Liggitt; Clayton Coleman
Cc: [email protected]<mailto:[email protected]>
Subject: Re: api and console port : 8443

Aleksandar

Thanks for reply. I didn’t quite understand the flow how it works. Can you 
please explain me a little brief?


--
Srinivas Kotaru

From: Aleksandar Lazic 
<[email protected]<mailto:[email protected]>>
Date: Thursday, March 10, 2016 at 12:18 AM
To: skotaru <[email protected]<mailto:[email protected]>>, Jordan Liggitt 
<[email protected]<mailto:[email protected]>>, 
"[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Cc: "[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Subject: Re: api and console port : 8443


Hi.


We solved this issue with a own haproxy pod in front of the master and added 
the following variables into ansible/hosts file.


#####

...

openshift_master_public_api_url=https://manage.{{ osm_default_subdomain }}
openshift_master_public_console_url={{ openshift_master_public_api_url 
}}/console
openshift_master_metrics_public_url={{ openshift_master_public_api_url 
}}/hawkular/metrics

...

#####


In this haproxy you can add the manage.{{ osm_default_subdomain }} or the 
wildcard certificate into a secret.


###

oc secrets new wildcard-cloud-cert cloud.pem=...cloud_all.pem
oc secrets add serviceaccount/default secret/


###


With this solution you don't need to expose your master to the internet ;-)


Best Regards

Aleks

________________________________
From:[email protected]<mailto:[email protected]>
 
<[email protected]<mailto:[email protected]>>
 on behalf of Srinivas Naga Kotaru (skotaru) 
<[email protected]<mailto:[email protected]>>
Sent: Wednesday, March 09, 2016 21:37
To: Jordan Liggitt; Clayton Coleman
Cc: [email protected]<mailto:[email protected]>
Subject: Re: api and console port : 8443

Thanks Jordan/Jason/Clayton for quick replies

Good to knew that we can change port during provision time using ansible 
environment variables mentioned by Jason

However, this seems to be messy and confusing that user wont’ be able to change 
after the provision. At least too difficult unless all files across board 
reflect the new port

Can we run a simple load balancer and listen on 443 and forward to all masters 
on port 8443.  All the users will use standard vip:443.  Openshift might create 
all kubeconfig files with 8443 reference.

Can you validate above approach? It might ok to run load balance also on 8443 
and forward to 8443 but am thinking clients should’t bother about always enter 
8443 while connecting API or console

The idea is run a simple load balancer for balancing multiple API masters.



--
Srinivas Kotaru

From: Jordan Liggitt <[email protected]<mailto:[email protected]>>
Date: Wednesday, March 9, 2016 at 12:05 PM
To: "[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Cc: skotaru <[email protected]<mailto:[email protected]>>, 
"[email protected]<mailto:[email protected]>" 
<[email protected]<mailto:[email protected]>>
Subject: Re: api and console port : 8443

also would need to adjust the port in the kubeconfig files used to connect to 
the master

On Wed, Mar 9, 2016 at 3:03 PM, Clayton Coleman 
<[email protected]<mailto:[email protected]>> wrote:
As long as you change the config, no.  We chose 8443 in case you
wanted to run a local TLS proxy, or in case you are running as a
developer.

On Wed, Mar 9, 2016 at 2:55 PM, Srinivas Naga Kotaru (skotaru)
<[email protected]<mailto:[email protected]>> wrote:
> Any reason why api and console exposed as 8443 rather 443?
>
> Any impact if we change 8443 to 443 by find and replace 8443 with 443 on
> /etc/origin/master/master-config.yaml and restart master service?
>
> Do we need to change anything on node or etcd  side?
>
> --
> Srinivas Kotaru
>
> _______________________________________________
> users mailing list
> [email protected]<mailto:[email protected]>
> http://lists.openshift.redhat.com/openshiftmm/listinfo/users
>

_______________________________________________
users mailing list
[email protected]<mailto:[email protected]>
http://lists.openshift.redhat.com/openshiftmm/listinfo/users



_______________________________________________
users mailing list
[email protected]
http://lists.openshift.redhat.com/openshiftmm/listinfo/users

Reply via email to