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.*
https://github.com/kubernetes/kubernetes/issues/1107
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.*
https://github.com/kubernetes/kubernetes/issues/1161
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
<https://github.com/kubernetes/kubernetes/issues/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.
_______________________________________________
dev mailing list
[email protected]
http://lists.openshift.redhat.com/openshiftmm/listinfo/dev
