插播一个备忘录
sudo apt install docker.io
sudo usermod -a -G docker lizhe
然后正常退出，重启docker保证能正常使用
distribution=$(. /etc/os-release;echo $ID$VERSION_ID)
curl -s -L https://nvidia.github.io/nvidia-docker/gpgkey | sudo apt-key add -
curl -s -L https://nvidia.github.io/nvidia-docker/$distribution/nvidia-docker.list | sudo tee /etc/apt/sources.list.d/nvidia-docker.list
sudo apt-get update
sudo apt-get install -y nvidia-container-toolkit
要连接两个以上的 namespace ， 需要使用 Linux bridge。
网桥是二层网络设备，两个端口分别有一条独立的交换信道，不共享背板总线，可以隔离冲突 （比集线器性能好一些，集线器共享同一条背板总线）
不过目前网桥已经被具有更多端口、可隔离冲突域的交换机取代了。
Linux 网桥 和 其他的网络设备区别在于， 普通设备（例如网卡）只有两端，从一端进去从另一端出来。
物理网卡从网络中收到数据，转发给 内核协议栈 ， 从内核协议栈过来的数据会转发到外面的物理网络中。
Linux 网桥 有多个端口，数据可以从任何端口进来，然后取决于 MAC 地址，选择从哪个口出去，原理和交换机差不多
创建一个网桥
root@ubuntu:/home/lizhe# ip link add name br0 type bridge
root@ubuntu:/home/lizhe# ip link set br0 up
root@ubuntu:/home/lizhe#
刚创建的网桥只有一端连接着协议栈
之前创建了一个 veth pair
veth0 10.10.10.1
veth1 10.10.10.2
这里他们都在一个网段上，如果你使用 ping 命令直接 ping 它们都可以ping通
但是 ping -I veth0 10.10.10.2 使用 veth0 ping veth1 是 ping不通的
我们尝试使用 tcpdump 来看看发生了什么
veth 是虚拟以太网卡 （ Virtual Ethemet ）的缩写。
veth 设备总是成对的，因此我们称之为 veth pair。 veth pair 常被用于 跨 network namespace 之间的通信，即分别将 veth pair 的两端放在不同的 namespace 里
仅有veth pair设备，容器是无法访问外部网络的。
从容器发出的数据包，实际上是直接进了 veth pair 设备的协议栈。
如果容器需要访问网络，则需要使用网桥等技术将 veth pair 设备接收的数据包转发出去。
这里我创建一个新仓库
然后分别提交3次，依次提交 file1、file2 和 file3
bae637edfecf634185f6dc3cf51d251a8d27aad0 file1 第一次提交
39defcb06a20910ee01cf2dd688b6d2b1ce0a411 file2 第二次提交
f8f10774bbb0c7faab1190bd173e763b0cca34cc file3 第三次提交
显示所有提交
git log
如果你熟悉docker的namespace隔离机制，你应该知道docker的network也是通过 namespace隔离的
要了解kubernetes的网络原理，不得不提到 linux 的network namespace
Linux的 namespace 的作用是 隔离内核资源，命名空间会给其中的进程造成两个错觉
1. 它是系统内唯一的进程
2. 它独享系统的所有资源
network namespace是从 2.6 开始引入的，作用是隔离 Linux 系统的设备，ip 地址、端口、路由表 和 防火墙规则等网络资源
创建一个名为 netns1 的 新命名空间
sudo ip netns add netns1
当 ip 命令 创建了一个 新命名空间 之后，系统会在 /var/run/netns 目录下生成一个新的挂载点
挂载点的作用在于一方面是为了方便 命名空间管理，另一个方面是使 命名空间 可以在没有进程运行时也能继续存在
Kubernetes三种弹性伸缩：
我们先来看一下HPA
这里不会演示如何创建HPA，我关注的是一些具体细节
Kubernetes 的自动伸缩特性在1.6和1.7本本之间重写过一次，有一些特性发生了变化
自动伸缩分为3个步骤
1. 获取被伸缩资源对象所管理的所有pod度量
2. 计算使度量数值达到（或接近）所指定的目标数值所需的pod数量
3. 更新被伸缩资源的 replicas 字段
度量数据的流向
Pod -> cAdvisor -> Heapster -> Horizontal Pod AutoScaler
ResourceQuota 的接纳控制插件会检查将要创建的Pod 是否会引起 总资源量 超出 ResourceQuota。
ResourceQuota 也无法影响已经创建的 pod
apiVersion: v1
kind: ResourceQuota
metadata:
namespace: lizhe
name: lizhe-rq
spec:
hard:
pods: 5
requests.cpu: 1
requests.memory: 1Gi
limits.cpu: 1.5
limits.memory: 1Gi
configmaps: 2
persistentvolumeclaims: 5
replicationcontrollers: 5
secrets: 2
services: 2
这一节讨论 LimitRange 和 ResourceQuota
API Server 在接收到带有 pod 描述信息的 POST 请求时，LimitRanger 插件对 Pod spec 进行校验。如果校验失败，会直接拒绝。
LimitRange 对象的一个广泛应用场景就是阻止用户创建大于 单个节点资源量的 pod。如果没有LimitRange，API Server 将接受任何请求，然后永远无法调度成功。
LimitRange 资源中的 limits 应用于同一个命名空间中的 每一个 独立 Pod、容器或者其他类型对象。但是它并不会限制这个命名空间中所有pod的可用资源总量
ResourceQuota 才是控制总量的配置。
实验一
如果你像我一样使用的是 rancher，那么rancher界面上只能配置默认 requests 和 limits，但是并没有影响 min 和 max
上一节中我们出现了 OOM kill ，pod 的状态会变成
CrashLoopBackOff
CrashLoopBackOff 状态表示 Kubelet 还没有放弃，它意味着在崩溃之后Kubelet会增加下次重启的间隔时间
间隔时间会按照 10秒，20秒，40秒，80秒，160秒，最终收敛于 300 秒
一旦间隔时间到达 300 秒，Kubelet 将会以固定的 300 秒 为间隔时间对容器进行无限重启
在容器中看到的始终是节点的整体内存，而不是容器被限制使用的内存
在容器中看到的始终是节点的整体cpu内核，而不是容器被限制使用的内核，而且容器的进程会随机在node的内核上调用
下面的内容也很重要
Qos 等级直接影响当资源耗尽时，哪些容器会被优先杀死的问题
需要特别注意的是，QoS 等级是作用于 Pod 的， 但是决定 QoS等级的是 运行在 Pod 上的所有 容器，并且被杀死的是容器，而不是 pod，运行在同一个pod上的容器，拥有相同的QoS