Kubernetes and flannel network setup

1
votes

I hope someone can enlighten me on Kubernetes network setup. I want to use flannel as the Kubernetes network layer.

I'm on Kubernetes: 1.5.5 btw.

The problem is, there are so many places you can(should?) define a cidr, I'm not seeing the woods for the trees anymore.

To give you some info about my setup:

  • my hosts are deployed in the 10.9.0.0/24 range.
  • I want to use 10.254.0.0/16 as the flannel range
  • at the moment, docker on the worker nodes uses the 172.17.0.0/16 range

kube-apiserver has the following options for cidr's:

--service-cluster-ip-range

kube-controller-manager has the following options for cidr's:

--cluster-cidr
--service-cluster-ip-range

what's the difference between those two?

kube-proxy has this one:

--cluster-cidr={{ kubernetes_cluster_cidr }}

what ip range goes where exactly?

1
dockerkubernetesflannel

1 Answers

1
votes

Actually, you have 2 different network layers there:

  • Cluster-cidr: the pods layer (where you want to use 10.254.0.0/16): Once you have your flannel network up and running, you will have to configure Docker to use it (via systemd drop-in or with something like: echo "DOCKER_OPTS="--bip=${FLANNEL_SUBNET} --mtu=${FLANNEL_MTU}"" >> /etc/default/docker). This way all the "docker0" interfaces in your cluster will be connected within the flannel network.
  • Service-cluster-ip-range: the service layer. Services are used to abstract a logical set of pods. As long as you don't know where a pod is going to be located, or the IP that is going to be assigned to it... You need some kind of abstraction to reach a pod/set of pods, wherever they are.

A Kubernetes Service is an abstraction which defines a logical set of Pods and a policy by which to access them - sometimes called a micro-service. The set of Pods targeted by a Service is (usually) determined by a Label Selector (see below for why you might want a Service without a selector). As an example, consider an image-processing backend which is running with 3 replicas. Those replicas are fungible - frontends do not care which backend they use. While the actual Pods that compose the backend set may change, the frontend clients should not need to be aware of that or keep track of the list of backends themselves. The Service abstraction enables this decoupling.

NOTE: The service layer must not overlap with your cluster pods network (flannel) or any other existing network infrastructure.