Changes to direct container to container communication
Usha Ramachandran
Hi everyone,
The container networking incubation project netman-release
<https://github.com/cloudfoundry-incubator/netman-release> enables direct,
policy-driven connectivity between containers on Cloud Foundry by making
them directly addressable on a Layer 3 overlay network. Having this
capability will give operators and users a secure and supported way of
enabling use cases that require direct container communications.
As part of this effort we plan to stop supporting containers communicating
directly with each other using the Diego cell IP address and NAT’ed port.
Please note, there is **no change** to communications through the Gorouter.
We don’t anticipate direct container communication being used in many
environments today, since it requires opening up ASGs to allow all cells on
all ports to talk to each other. However, if you are using this, it would
be great if you could help us with the following -
-
We would like to understand your use case so we can provide guidance on
how it would work in the new world.
-
CF_INSTANCE_IP and CF_INSTANCE_PORT today contain the Diego cell IP
address and the port mapping from the container port to the NAT’ed port. We
are considering changing CF_INSTANCE_IP to reflect the actual container IP
address. Please let us know if you are using these variables.
Also, in case you are wondering if this affects you today - there is no
action or changes to existing deployments required at this time.
As always, if you have any questions about this change please don’t
hesitate to reach out on the #container-networking channel on CF OSS Slack
or respond to this email.
Thanks,
Usha Ramachandran
CF Container Networking PM
--
Usha Ramachandran | Senior Product Manager | Pivotal Cloud Foundry - San
Francisco
The container networking incubation project netman-release
<https://github.com/cloudfoundry-incubator/netman-release> enables direct,
policy-driven connectivity between containers on Cloud Foundry by making
them directly addressable on a Layer 3 overlay network. Having this
capability will give operators and users a secure and supported way of
enabling use cases that require direct container communications.
As part of this effort we plan to stop supporting containers communicating
directly with each other using the Diego cell IP address and NAT’ed port.
Please note, there is **no change** to communications through the Gorouter.
We don’t anticipate direct container communication being used in many
environments today, since it requires opening up ASGs to allow all cells on
all ports to talk to each other. However, if you are using this, it would
be great if you could help us with the following -
-
We would like to understand your use case so we can provide guidance on
how it would work in the new world.
-
CF_INSTANCE_IP and CF_INSTANCE_PORT today contain the Diego cell IP
address and the port mapping from the container port to the NAT’ed port. We
are considering changing CF_INSTANCE_IP to reflect the actual container IP
address. Please let us know if you are using these variables.
Also, in case you are wondering if this affects you today - there is no
action or changes to existing deployments required at this time.
As always, if you have any questions about this change please don’t
hesitate to reach out on the #container-networking channel on CF OSS Slack
or respond to this email.
Thanks,
Usha Ramachandran
CF Container Networking PM
--
Usha Ramachandran | Senior Product Manager | Pivotal Cloud Foundry - San
Francisco