Last night we had the good fortune to be invited to present one of the Lightening Talks at the Bay Area Kubernetes Meetup.
Tim Hockin was there with an overview of the upcoming v1.2 release and had some very good live demos of the new features.
Here are his slides.
Chris Marino gave an overview of Romana and described how Cloud Native applications are different from legacy Enterprise apps and how this drove very different network requirements for software defined networking. You can see his slides here.
Robert Starmer from Kumul.us then gave a live demo of Kubernetes running with Romana networks. The demo included a first tenant (t1) launching two individual Pods each with a tier label ‘frontend’ and ‘backend’ as show below:
apiVersion: v1 kind: Pod metadata: name: nginx-frontend labels: app: nginx owner: t1 tier: frontend spec: containers: - name: nginx image: nginx ports: - containerPort: 80 apiVersion: v1 kind: Pod metadata: name: nginx-frontend labels: app: nginx owner: t1 tier: backend spec: containers: - name: nginx image: nginx ports: - containerPort: 80
There is work being done in the Kubernetes Network SIG to define Network Policy and a way to isolate networks for multi-tenancy. The latest proposal is to use a namespace to define a tenant. However, in this demo we simply use the label ‘owner’ to specify tenancy. In addition, there is still ongoing discussion around the default policy that describes which Pods can communicate within a namespace
A second tenant (t2) was created with three nginx Pods using a replication controller.
apiVersion: v1 kind: ReplicationController metadata: name: nginx-default spec: replicas: 3 template: metadata: labels: app: guestbook tier: default owner: t2 spec: containers: - name: nginx-default image: nginx ports: containerPort: 80
Network Policy in Kubernetes takes advantage of ThirdPartyResource objects. By creating a ThirdPartyResource, a new API endpoint is creates that can be watched for activity on those resources.
name: network-policy.romana.io apiVersion: extensions/v1beta1 kind: ThirdPartyResource description: 'Romana Network Policy Third Party Resource Schema' versions: - name: demo/v1
Results in the creation of this API endpoint
Romana has built a Policy Manager that listens for activity on this API endpoint and configures the network with the specified policy.
A NetworkPolicy such as the one shown below can then be specified to apply specific network policy to selected Pods.
kind: NetworkPolicy apiVersion: romana.io/demo/v1 metadata: name: policy1 namespace: default labels: - owner: t1 spec: podSelector: // Standard label selector - selects pods. tier: backend allowIncoming: // (Optional) List of allow rules. - toPorts: // (Optional) List of dest ports to open. - port: 80 // (Optional) Numeric or named port protocol: TCP // [ TCP | UDP] from: // (Optional) List of sources. - pods: // (Optional) Standard label selector. tier: frontend // (Optional) Standard label selector.
This particular policy allows TCP traffic on port 80 to arrive from Tenant t1’s Pods labeled ‘frontend’ to the Pods labeled ‘backend’
In the demo, Robert started the replication controller and the frontend and backend Pods. He then showed that traffic could not reach either the frontend or backend Pods from tenant t2’s Pods. This showed network multi-tenancy.
Then, he showed that tenant t1 traffic could not reach the backend Pods from the frontend Pods. Then he applied the NetworkPolicy at which point traffic could reach the pods. This showed the application of the specified network policy and enforcement across application tiers.
There’s still a lot more work to do for complete policy based networking, but this is an exciting start. We’ll be releasing the code for this as soon as possible so that you can try it out for youself.
The Meetup was recorded and you can watch the Romana presentation and demo starting at 37:00.