Networking question regarding Minikube and the 172.17.0.0/16 range

[Lena Brüder]

Hi together,

I'm just starting with Kubernetes and have a problematic case with our company-internal networking that I do not know how to solve. I'm unsure if this is the right place to ask, so here it goes:

Our internal network uses the 172.17.0.0/16 range. We have an artifactory installation that is running at 172.17.130.51 and serves our docker images internally. Whenever I try to start a kubernetes cluster locally using minikube / kompose (using an already-existing an working docker-compose.yml), the pods cannot load the docker images from the artifactory. I think there is a conflict because the 172.17.0.0/16 range is also used by docker inside minikube, which causes the routing to be "broken" for my use case.

How can I change the range that is used by minikube? I sadly cannot change the internal network. I did not find documentation so far around changing that - most people do not seem to use that network range for their LAN. It would most probably not be an issue for production in the end, but it is for lcoal development currently. Images being pulled off the official docker registry work without problems.

$ kubectl describe po/testing-service-1800640680-jpz24

Name: testing-service-1800640680-jpz24

Namespace: default

Node: minikube/192.168.99.100

Start Time: Fri, 28 Jul 2017 15:03:00 +0200

Labels: io.kompose.service=testing-service

pod-template-hash=1800640680

Annotations: kubernetes.io/created-by={"kind":"SerializedReference","apiVersion":"v1","reference":{"kind":"ReplicaSet","namespace":"default","name":"testing-service-1800640680","uid":"14ff771f-7395-11e7-b744-08002...

Status: Pending

IP: 172.17.0.9

Created By: ReplicaSet/testing-service-1800640680

Controlled By: ReplicaSet/testing-service-1800640680

Containers:

  testing-service:

    Container ID:

    Image: artifactory.e-spirit.de:6556/testing-service-prototype:1.1.0-SNAPSHOT

    Image ID:

    Port: <none>

    State: Waiting

      Reason: ImagePullBackOff

    Ready: False

    Restart Count: 0

    Environment:

      HTTP_PORT: 9000

      PROFILE_SERVICE_URL: http://profile-service:9000/

    Mounts:

      /var/run/secrets/kubernetes.io/serviceaccount from default-token-pk7s2 (ro)

Conditions:

  Type Status

  Initialized True 

  Ready False 

  PodScheduled True 

Volumes:

  default-token-pk7s2:

    Type: Secret (a volume populated by a Secret)

    SecretName: default-token-pk7s2

    Optional: false

QoS Class: BestEffort

Node-Selectors: <none>

Tolerations: <none>

Events:

  FirstSeen LastSeen Count From SubObjectPath Type Reason Message

  --------- -------- ----- ---- ------------- -------- ------ -------

  58s 58s 1 default-scheduler Normal Scheduled Successfully assigned testing-service-1800640680-jpz24 to minikube

  58s 58s 1 kubelet, minikube Normal SuccessfulMountVolume MountVolume.SetUp succeeded for volume "default-token-pk7s2" 

  41s 41s 1 kubelet, minikube spec.containers{testing-service} Warning Failed Failed to pull image "artifactory.e-spirit.de:6556/testing-service-prototype:1.1.0-SNAPSHOT": rpc error: code = 2 desc = Error response from daemon: Get https://artifactory.e-spirit.de:6556/v1/_ping: dial tcp 172.17.130.51:6556: getsockopt: no route to host

  41s 39s 2 kubelet, minikube Warning FailedSync Error syncing pod

  39s 39s 1 kubelet, minikube spec.containers{testing-service} Normal BackOff Back-off pulling image "artifactory.e-spirit.de:6556/testing-service-prototype:1.1.0-SNAPSHOT"

  57s 24s 2 kubelet, minikube spec.containers{testing-service} Normal Pulling pulling image "artifactory.e-spirit.de:6556/testing-service-prototype:1.1.0-SNAPSHOT"

I am happy to provide more info if needed :).

Cheers,

Lena

[Matt Rickard]

You can configure arbitrary docker options on a fresh `minikube start` with the `--docker-opts` flag.  It takes a list of key=values that it will pass into the docker daemon on startup.  In your case, you want the `bip` flag, which takes a CIDR.

So something like `minikube start --docker-opt "bip=144.144.1.5./24".  If your still having trouble, we'd be happy to help in the #minikube kubernetes slack channel.

[Lena Brüder]

Hi Matt,

I tried using the bip parameter, but that did not have any effect on the IPs that get assigned to the pods. We had the same problem locally with the windows hosts of some colleagues which started to ignore the bip flag since some recent update of docker, but no solution so far at that end either (did not affect me on linux though).

I'll move to the slack channel!

Cheers,

Lena

[Anonymous]

I am facing the same issue. Did you reach to any solution? Any help is much appreciated :)