Networking

Routing, Switching, Gateways

To find gateway:

route
# or
ip route list

To add entries into the routing table. Where 2nd ip is gateway

ip route add 192.168.1.0/24 via 192.168.2.1

If forwarding between machines required for communication without a router:

/proc/sys/net/ipv4/ip_forward must be enabled:

echo 1 > /proc/sys/net/ipv4/ip_forward

To persist:

# /etc/sysctl.conf
net.ipv4.ip_forward=1

DNS

In /etc/resolv.conf set DNS server:

nameserver 192.168.1.100

We can set order for /etc/hosts or DNS server in:

/etc/nsswitch.conf:

We can use nslookup, dig to query DNS servers:

Network Namespaces

Lets us have isolated routing and arp tables along with virtual interfaces.

Run in ns:

To connect namespaces we can use a virtual pair (or pipe):

To create a virtual cable

To attach with the network namespaces

To add an IP address

To set up ns interfaces

Check the connectivity

When we have many NS, we create a switch (bridge)


Putting this all together we can have the bridge reach the external network by talking to our host as the Gateway, and have connections go back in to the private network by implementing NAT on our host via:

Pod Networking

The rules of kubernetes pod networking are that:

  • every pod should have an IP address

  • every pod should be able to communicate with every other pod in the same node

  • every pod should be able to communicate with every other pod on other nodes without NAT

We create a bridge on each node for the containers. Each bridge has a private subnet. To allow cross-node communications we add routes between nodes or use a router.

See kube-controller-manager --cluster-cidr= for pod range.

CNI in Kubernetes

We specify CNI plugin on container runtime in /etc/cni/net.d, bins in /opt/cni/bin

Kubernetes networking Solutions will typically install agents on every node (DaemonSet) along with bridges and then deal with peer-to-peer communication

IP Address Managements (IPAM)

Who assigns IPs to containers. CNI plugin manages the IP management.

Service Networking

Pods communicate via services and each gets a cluster-wide IP.

kube-proxy watches for service creation, and creates one. This is done by each node setting up forwarding rules on each node.

proxy-mode defines how forwarding rules are created on kube-proxy.

service-cluster-ip-range defines ip range for services.

DNS in Kubernetes

Whenever we create services they get a DNS entry so any pod can access.

If in same namespace, can use just service name, eg 'service'

In different namespace add namespace suffix, eg 'service.default'.

Full domain is 'service.default.svc' or FQDN 'service.default.svc.cluster.local'

By default pods do not get entry, but we can enable DNS enties for them, thry get entry:

'IP-WITH-DASHES.namespace.pod'

eg '10-244-2-5.default.pod'

CoreDNS

Config in /etc/coredns/Corefile

Kubelet configures DNS server for pods by setting nameserver in /etc/resolv.conf

resolv.conf also contains a search query to allow PARTIAL FQDN:

Ingress Controllers

Native internal loadbalancing.

Not deployed by default.

GCE, nginx maintained by k8s (currently)

Create an ingress service account, and service.

Create a deployment with:

To configure ingress, create an ingress-resource:

To define rules for paths:

For domain name rules:

Last updated