Minutes

[9:04] startmeeting

[9:04] agenda

(20m) Overview of Itsio (https://istio.io/) from Google.
(10m) Status of deploying Kubernetes infrastructure as part of standard CORD install
(30m) Planning for starting CORD via Kubernetes (assuming a Kubernetes cluster is deployed and available).

[9:06] topic Istio learnings from Google, presented by @gopinatht

[9:08] istio started by many of the big contributors in the container world, google, mesos, etc. (edited)

[9:08] meant to be container and VM orchestration, only supports containers currently

[9:08] meant to abstract out existing container orchestration frameworks

[9:09] will start as an LCD, but being modeled closely against k8s

[9:11] k8s, nomad/Consul, meso, eurika, no mention of docker swarm at this point

[9:12] the why? google didn't have good handle on security on their containers. istio uses envoy to help regulate and control over access and security.

[9:13] the why? abstraction of orchestration frameworks

[9:15] envoy is an l2/l3 load balancer, with weighting capability (edited)

[9:16] envoy allows persistent connections

[9:17] pattern being use is that every micro server (pod) that is deployed includes an envoy "sidecar" proxy that intercepts all traffic in/out of the pod. (edited)

[9:18] envoy allows encryption between services, allowing secure comms even over un-secure networks.

[9:18] envoy goes through a "pilot" that is a global proxy manager and uses policy to perform traffic management operations. (edited)

[9:21] istio control plane consists of pilot, mixer, and auth. implemented in cooperation with envoy proxies

[9:21] google planning to make control plane extensible.

[9:24] question when connecting to something outside of k8s, is there an envoy proxy in front of that?

[9:24] answer ootb no envoy proxy, but you can manually deploy a proxy in front of it.

[9:27] kubespray can be used to deploy and start k8s and istio containers

[9:28] question where are the sidecars defined?

[9:29] answer not in the pod definition, sidecar automatically added to each pod

[9:29] sidecars are a new k8s pattern (in alpha)

[9:30] question can you have multiple sidecar

[9:30] answer not sure, but maybe

[9:37] pilot routing is configured in separate config (yaml) and uses labels to control traffic management

[9:42] need to understand how rule conflict resolution is is handled.

[9:44] @gopinatht recommends that a low hanging fruit is to use as XOS infrastructure piece

[9:45] pilot + mixer is l3/l4 chaining.

[9:45] question how does this apply to l2 chaining

[9:46] question is sidecar per port or per service, service can be a collection of ports (edited)

[9:54] topic status of existing container work in CORD

[9:55] 99cloud, no update, they want to create a repo in cord to start moving cord to kolla, @llp was to create the repo

[9:55] action @gopinatht to send email to 99cloud to get status

[9:56] linker networks working with @jono. currently have open source CNI implementation for OVS based network, with its own IP addr mgmt framework

[9:57] @jono attempting to get VTN to take over OVS network. and was able to ping to micro-service VNFs

[9:57] next step to create a daemon that watches for new mservice ports and pushes that to VTN (CORD-2253) (edited)

[9:58] plan is to be able to deploy r-cord on this OVS network as an example, and then integrate into full cord deployment (edited)

[9:59] endmeeting

Questions