This release introduces a beta version of a new container networking fabric called "silk" and contains significant changes to job and property names. In order to deploy silk you must upgrade to Diego release v1.15.0 or higher.
Silk is a replacement for flannel, which uses a central controller node backed by a SQL database. Etcd is no longer required by CF Networking Release when running Silk.
There are several manifest changes required to enable Silk, and we highly recommend reading the manifest changelog to understand the changes.
We do not recommend using cf-networking-release in production yet, but give it a try and give us your feedback in the #container-networking channel on cloudfoundry.slack.com.
Take a look at known issues for current limitations and known issues. Verified with the following:
Manifest Changes
Too many to list here - please take a look at the manifest changelog
Significant Changes
Silk Controller and daemon
- Containers use sensible defaults for MTU
- Subnets are reclaimed once they expire
- I can ping from one container to the other on the overlay network
- Routing rules are cleaned up when Diego cells are removed
- silkd crashes if there is a subnet theft
- silkd is deployed by BOSH
- Error handling in silkd when it cannot get routes from silk controller
- Container networking with silk is reliable at 20K app instances across 100 Diego cells
- Operators can override the pre-encap MTU
- Silk controller does not return expired leases
- Manifest changelog has instructions to deploy silkd and silk controller
- diego manifest generation scripts work with silk
- Client config LoadConfig is covered by unit tests
- silk-teardown deletes VTEP even when release fails
- Standardize names across BOSH user surface area