以下内容出自Rancher的meetup， available on Youtube link

Thanks to Rancher. Rancher是一家提供基于open source的Container服务商。Rancher会管理各种云上的（aws，google，azure）和本地的K8s。可以把它认为是在K8s之上的一层软件。

这个Video是介绍K8s网络的，以下是我的笔记。

基础的linux和container虚拟网络（以Docker为例子）

Container内部可以创建veth。veth是Linux提供的虚拟以太网设备。
veth可以接入docker0 bridge。bridge是不做路由的，是最底层的接入设备。这里的bridge也是虚拟的。
所有的docker containers都接入这个bridge， container有自己的内部IP地址，host有自己的“公网”（外部网络IP地址，可能仍然是内部但是不同的内网）

• 通过NAT-source rules，做NAT地址转换，可以接往外部世界
• 通过NAT-destination rules，做NAT地址转换，暴露内部container服务给外部，比如做IP端口到container IP的映射。

使用iptables chains, RAW table, mangle table, nat table, filter etc
Docker插入了自己定义的Rules，比如端口转换

docker0作为default gateway做出口，（20分左右）整个egress过程。Ingress也是借助NAT的port映射表，把packet送回container。

VM可以定义虚拟网卡，采用tap建立和物理网卡的绑定。TAP是建立虚拟bridge的二层协议，wikipedia

overlay network is confined to the nodes. 这篇文章 介绍了如何建立一个跨节点，跨网段的overlay network。
overlay网络是建立在其它网络协议上的网络（可以运行不同的协议）。比如Docker/Swarm建立的overlay network就是建立在IP层（layer3）的一个layer2 overlay network。使用的是VXLAN协议（2层overlay）。IPSec（3层overlay）

docker networking vs K8s networking

K8s内部container不像Docker那样用NAT把内部的IP封装隐藏起来。而是直接把内部的IP地址和端口暴露出来。比如web container的内部地址是10.42.1.2:8080，那么外部就用这个地址去访问它。
POD=pause+real containers
Pause container拥有真正的网络namespace。其它的container只是使用pause container提供的网络namespace。
Pause container只是把网络拉起来，然后就进入睡眠了。免得一个active container把网络给搞死了。

POD网络的IP编址是自己选的。比如Rancher用10.42.0.0/24，不同的node地址可以分一段，比如10.42.0.0/24(node1), 10.42.1.0/24(node2)， 只要不重复（内外）

Cluster IP提供了一层indirect。把服务的scale in/out。Cluster IP range不能和外面的网络重复。

service的名字。是反过来的，越具体的越在前面。
service-name.namespace-name
DNS record: service-name.namespace-name.svc.cluster.local, where cluster.local is the default domain

kube-dns自己就是个POD，提供naming service。

HostPort/NodePort。HostPort和Docker一样把port映射在Host级别。NodePort把这个Port映射在所有的Node. 所以无论怎么迁移都可以。HostPort可以指定任意端口，NodePort只能从30000–30xxxx。

K8s和docker的互动

K8s启动Docker的时候用了-net=none，所以docker inspect不会show出NetworkSettings

提供网络的CNI插件可以采用overlay或者non-overlay模式

Flannel

VXLAN or IPSec
Host-gw 更好的性能。没有Overlay的encapsulation开销。

// 两个命令，在worknode执行，看Flannel是如何把几台机器组合到一起的，形成一个互联的网络。每个node可能是一个子网比如
// 10.42.1.0/24（node1），10.42.2.0/24（node2）
# ip addr
# ip route
# bridge fdb show
# ip neigh

Calico

提供BGP
Network policy

Canal

Flannel + Calico的Network policy部分

通过CNI的插件，K8s的节点就组成了一个Cluster，是一个一体的系统。
只是内部有网络routing。K8s的federation是另外的概念。

==========================================================================

load balancing and K8s

internal load balancing

ClusterIP service 可以提供Load balancing through Kube-proxy
定义一个Service。
spec.selector.app: MyApp
spec.ports.protocol: TCP
spec.ports.port: 80
spec.ports.targetPort: 9376

external load balancing

也是定义一个service. 需要Cloud provider来实现和deploy这个YAML

layer 4 LB via Service

spec:
	ports:
	-  protocol: TCP
		port: 80
		targetPort: 9376
	clusterIP： 10.0.171.239  # this is an internal IP, representing the K8s nodes
	loadBalancerIP： 78.11.24.19   # this is the IP of the LB instance that you purchased in the cloud
	type: LoadBalancer
status:
	loadBalancer:
		ingress:
		- ip: 146.148.47.155    # This is the IP address that you use to access your application.

Layer 7 LB via Ingress

通过定义Ingress，我们可以实现一个7层的HTTP path接入不同service集群的LB

spec:
	rules:
	-  host: k8s.io
		http:
		-	path: /foo
			backend:
				serviceName: fooSvc
				servicePort: 80
		-	path: /bar
			backend:
				serviceName: barSvc
				servicePort: 80

Load balancer (ingress controller) runs outside of K8s cluster BUT works with K8s

for example, amazon ALB

Google GLBC,

F5
Netscaler
Openstack Octavia