Proposal: Achieve Docker-Compose Network functionality using NetworkPolicy in Kubernates

[mudverma]

Currently Kompose does not support Network Key Translation. However, Network functionality is widely used is Docker World.

Consider the following interactions:

Services A1, A2 are part of net_a while Services B1, B2 are part of Net_B, there is also a gateway that is part of Both the networks (net_a and net_b). This provides an isolated environment to a subset of services. It would be interesting to achieve equivalent functionality in Kubernates via translated artefacts.

Since Kubernates follows a flat networking structure, where every pod can talk to each other by default, achieving direct Network key translation is not straight forward.

There is a proposal to treat Docker-Compose network as Namespaces in Kubernates, however, we feel that an alternate approach is required for the following reasons. #1066

We propose that using "Labels" and "NetworkPolicy" in Kubernates we can achieve same functionality as multi Networks in Docker world.

We can extract network information from docker-compose and persist them as Labels in generated/translated kubernates artefacts. Along-with, we can also generate a networkPolicy that limits the communications amongst pods with same Network Labels.

Input:
docker-compose.yaml

networks:
  app:
    external:
      name: app-network
  web:
    external:
      name: web-network
services:
  appFoo:
    image: foo:latest
    command: sh -c "echo Hello Foo"
    networks:
      app: {}
      web: {}

Output:
appfoo-deployment.yaml

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  annotations:
    kompose.cmd: kompose -f docker-compose.yaml convert
    kompose.version: 1.18.0 (06a2e56)
  creationTimestamp: null
  labels:
    io.kompose.service: appfoo
  name: appfoo
spec:
  replicas: 0
  strategy: {}
  template:
    metadata:
      annotations:
        kompose.cmd: kompose -f docker-compose.yaml convert
        kompose.version: 1.18.0 (06a2e56)
      creationTimestamp: null
      labels:
        io.kompose.network/app-network: "true"
        io.kompose.network/web-network: "true"
        io.kompose.service: appfoo
    spec:
      containers:
      - args:
        - sh
        - -c
        - echo Hello Foo
        image: foo:latest
        name: appfoo
        resources: {}
      restartPolicy: Always
status: {}

web-network-networkpolicy.yaml:

apiVersion: extensions/v1beta1
kind: NetworkPolicy
metadata:
  creationTimestamp: null
  name: web-network
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          io.kompose.network/web-network: "true"
  podSelector:
    matchLabels:
      io.kompose.network/web-network: "true"

app-network-networkpolicy.yaml:

apiVersion: extensions/v1beta1
kind: NetworkPolicy
metadata:
  creationTimestamp: null
  name: app-network
spec:
  ingress:
  - from:
    - podSelector:
        matchLabels:
          io.kompose.network/app-network: "true"
  podSelector:
    matchLabels:
      io.kompose.network/app-network: "true"

[mudverma]

The reason we chose 'label' over 'namespace' is the following:
a) 'Namespace' is a much harder segregation than 'label'. When somebody thinks of 'Namespace', they are looking at the level of two different projects. For example, in Openshift, each project is defined as a namespace.
b) There can be pod that is shared across multiple networks, which is much easier to implement using labels.
c) When a user gets access to a cluster to deploy a project, in many cases the infra teams give access to a single namespace, and the user does not have access to creating a new namespace. A single project in many cases have multiple networks.
d) 'network' segregation does not mean 'namespace' segregation, and this helps us keep the concepts separate.

[hangyan]

Agreed.

[mudverma]

@hangyan If possible, could you please review the merge request #1195 for network key translation.

[hangyan]

@mudverma Thanks!

[mudverma]

Thanks @hangyan. Much appreciated your prompt review. May you also please review minor change in network integration tests that I forgot to add in earlier PR. Issue is #1196 PR is #1197

[paularah]

@mudverma I know this issue has been closed and implemented. In the case that the network is an external network, I don't think network polices are exactly the right k8s abstraction for this