[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

What would be security risk and limitation of using external ip on openshift.



What would be security risk and limitation of using external ip on openshift. 

I have found belowlexplanations and have additional questions as following 

Q1) Where external ip could be assigned ? Will it be Hardware L4( in my case) or openshift node itself. 
      If node itself should have external ip, Can cluster ip(service network) be external ip without one more ip address for external ip?
Q2) not sure that what below explanation means.  
 First, the proxy is inherently multi-tenant and its resources are not charged to any pod.
Q3) Does below explanation means, if there is any changes of services, we should re-deploy all pods which is using external ip? 
Fourth, environment variables can not be dynamically updated, so running pods can not know about services started after the pod itself
Q3) As far as i know, pods doesn't do live-mgration on openshift curretly. so Is this some worries about something would be happened when pods is able to be live-migrated?  
 Fifth, should a pod ever live-migrate it may have to take two network hops to reach a service instead of one, and will be forever subject to the availability of the first minion on which it ran
Q4) more explanation needed for below sentence. 
but is problematic for the long term because it depends on a flat service-port namespace
Q5) more explanation needed for below sentence. 

 because it uses two levels of balancing, which is not good for performance or predictability.




Today this is implemented as a per-minion proxy process which listens on the minion’s primary IP for every service in the cluster, on each service’s port. To be clear: the IP assigned to a service is the IP of the minion the caller is running on. This is exposed as an environment variable, but is effectively a constant. This has a number of drawbacks. First, the proxy is inherently multi-tenant and its resources are not charged to any pod. Second, it forces all services in a cluster to have different port numbers - if any service tries to use a previously consumed port it will fail, but this can not be known a priori. Third service ports potentially collide with any pods that use HostPorts and any daemons that run on the minions. Fourth, environment variables can not be dynamically updated, so running pods can not know about services started after the pod itself. Fifth, should a pod ever live-migrate it may have to take two network hops to reach a service instead of one, and will be forever subject to the availability of the first minion on which it ran.


This design was easy to establish as a prototype, but is problematic for the long term because it depends on a flat service-port namespace, which we want to make go away (see #1107), and because it uses two levels of balancing, which is not good for performance or predictability.

We should be able to establish a more performant and direct pattern for externalizing kubernetes-hosted applications.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]