Skip to content

network-restrictions.md

Latest commit

 

History

History
54 lines (40 loc) · 1.9 KB

network-restrictions.md

File metadata and controls

54 lines (40 loc) · 1.9 KB

Running behind a proxy

If nodes only have access via a HTTP proxy, you can let the machine-controller configure all new nodes to use this proxy. For this the following flag must be set on the machine-controller side:

-node-http-proxy="http://192.168.1.1:3128"

This will set the following environment variables via /etc/environment on all nodes (lower & uppercase):

  • HTTP_PROXY
  • HTTPS_PROXY

NO_PROXY can be configured using a dedicated flag:

-node-no-proxy="10.0.0.1"

-node-http-proxy & -node-no-proxy must only contain IP addresses and/or domain names.

Using a custom image registry

Except for custom workload, the kubelet requires access to the "pause" container. This container is being used to keep the network namespace for each Pod alive.

By default the image k8s.gcr.io/pause:3.1* will be used. If that image won't be accessible from the node, a custom image can be specified on the machine-controller:

-node-pause-image="192.168.1.1:5000/kubernetes/pause:3.1"

Kubelet images

Flatcar Linux

For Flatcar Linux nodes, kubelet image must be accessible as well. This is due to the fact that kubelet is running as a docker container.

By default the image quay.io/kubermatic/kubelet will be used. If that image won't be accessible from the node, a custom image can be specified on the machine-controller:

# Do not set a tag. The tag depends on the used Kubernetes version of a machine.
-node-kubelet-image="192.168.1.1:5000/my-custom/kubelet-amd64"

Insecure registries

If nodes require access to insecure registries, all registries must be specified via a flag:

-node-insecure-registries="192.168.1.1:5000,10.0.0.1:5000"