第 7 页的文章列表

简介

VXLAN 全称 Virtual eXtensible Local Area Network, 是一种基于三层网络构建虚拟的二层网络的方案。它使用 UDP 封装二层的数据帧，实现了 overlay 网络。所有处于 overlay 网络中的设备均感觉不到底层和传统网络的差别。

相关知识点

OSI七层网络模型

OSI 的七层网络模型从下到上依次是: 物理层，数据链路层，网络层，传输层、会话层、表示层、应用层 我们在简介中提到的二层、三层都是这七层中的，二层是数据链路层，它主要抽象了根据mac地址来传输数据帧这一过程。三层是网络层，典型的是ipv4, ipv6这样的网络协议，根据 ip 地址来传输 ip 数据报。 注意虽然 VXLAN 是基于 UDP 封装了数据帧，但是我们一般说它是基于三层而不是四层。因为在这里我们关注的是数据的是如何传输到指定地址的，而不是如何封装的。

overlay 的含义

overlay 字面含义就是上层的，还有一个对应的词，也就是underlay。结合在一起就好理解了， VXLAN 是 overlay 网络，说的是它实现的二层（数据链路层）是 overlay 的，这二层是基于三层（网络层）的 underlay 网络。

单播和多播

下面的定义来源于维基百科

• 单播: 英文 unicast, 是指数据包在计算机网络的传输中，目的地址为单一目标的一种传输方式。它是现今网络应用最为广泛，通常所使用的网络协议或服务大多采用单播传输，例如一切基于TCP的协议。

• 多播（组播）: 英文 multicast，是指把信息同时传递给一组目的地址。它使用的策略是最高效的，因为消息在每条网络链路上只需传递一次，且只有在链路分叉的时候，消息才会被复制。

数据帧

以常见的 EthernetII 帧为例，其帧格式如下： D.MAC: 6byte，目标 MAC 地址 S.MAC: 6byte, 来源 MAC 地址 Type: 2byte, 0x0800是 IP 类型，0x0806 是 ARP 类型 Data: 数据 FCS: 为了进行差错检验而添加的冗余码。 以下是我用 wireshark 抓的 arp 帧: 我在笔记本(192.168.31.243)上 ping 了 192.168.31.133 这个地址，因为我的笔记本不知道 192.168.31.133 的mac地址，因此使用 arp 帧来查找目的mac地址。

VLAN

VLAN(Virtual Local Area Network) 和本文介绍的 VXLAN 从名称上看就很相似，中文名称叫做虚拟局域网，它们的作用也是一样的，可以用来划分子网。下面采用维基百科上关于虚拟局域网的介绍。

虚拟区域网络（Virtual Local Area Network或简写VLAN, V-LAN）是一种建构于局域网交换技术（LAN Switch）的网络管理的技术，网管人员可以借此透过控制交换机有效分派出入局域网的报文到正确的出入端口，达到对不同实体局域网中的设备进行逻辑分群（Grouping）管理，并降低局域网内大量数据流通时，因无用报文过多导致壅塞的问题，以及提升局域网的信息安全保障。

但是 VLAN 是基于二层的方案，它会在数据帧头部添加4个字节的 VLAN Tag，其中 12bit 用来标识不同的二层网络，这样总共是 4000 多个。其次 VLAN 会使用 MAC 地址表来记录 VLAN ID、 MAC 和 Port 这三者之间的关系，因此一旦网络中主机数量多起来，会导致 MAC 地址表占用很大的内存。 关于 VLAN 和 VXLAN的区别，可以参考这篇文章: VXLAN vs VLAN

VXLAN 协议

上图从整体上来看，是一个 UDP 的报文，在 UDP 的数据部分的前8位是 VXLAN Header，表明这个 UDP 封装的是 VXLAN 的数据帧，后面则是原始的2层数据帧了。在 VXLAN Header中，有下面几个字段:

• VXLAN RRRR1RRR: VXLAN 的标记位
• Reserved: 保留位
• VNID: 24位的 VNI 字段
• Reserved: 保留字段

VXLAN 的实现原理

VXLAN 将以太网数据帧封装在 UDP 内，进而在三层网络传输。VXLAN 数据的封装和解封发生在 VTEP(VXLAN Tunnel EndPoint)。VTEP 是 VXLAN 网络的边缘设备。同时每个 VXLAN 网络都有唯一的 VNI(VXLAN Network Identifier) 标识，这样在一个物理网络上可以构建多个 VXLAN 虚拟网络，满足多租户的要求。下图是 VXLAN 的网络架构示意图。 这里面有两个比较重要的概念:

• VTEP: VTEP 和传统交换机类似，也是基于 MAC 地址表工作，是 VXLAN 网络的边缘设备，用来对 VXLAN 报文封包和解包。VTEP 可以是网络设备（比如交换机），也可以是一台机器（比如虚拟化集群中的宿主机）。在 VTEP 中，可以认为有两个表: 一个是 VLAN 和 VXLAN 的对应关系表；另一个是 MAC 地址表，里面包含了很多 MAC 地址，VXLAN ID 和远端 VTEP IP 地址的对应关系。 VTEP 收到下面主机的网络数据帧时，会先根据 VLAN 查第一个表获取对应的 VXLAN ID，之后根据 VXLAN ID和目的 MAC 地址，查 MAC 地址表获取远端 VTEP 的 IP 地址。最后， VTEP 会剥离VLAN Tag，按照 VXLAN 格式封装数据帧，发往远端的 VTEP。远端的 VTEP 收到该数据后进行解包，根据 MAC 地址将数据帧发往其所连接的主机。

• VNI: VNI 是每个VXLAN的标识，也就是上面说的 VXLAN ID，共24位，那么就可以表示 2^24=16777216 个 VXLAN 网络。每个 VXLAN ID 对应一个租户，那么理论上可以支撑千万级别的租户。

图例: VXLAN VTEP 这里又引出另外一个问题， VXLAN 中的一台主机在只知道 ip 的情况下，如何获取对方的 MAC 地址。在传统网络中，ARP 请求是用来解决这个问题的。

• VXLAN 网络中，主机发出的 ARP 请求会被 VTEP(1) 接收到，VTEP(1) 发现虚拟机目的 MAC 为广播地址，封装上 VXLAN 协议头部之后，发送给多播组，支持多播的底层网络设备会把报文发送给组内的所有成员
• VTEP(2) 接收到 VXLAN 封装的 ARP 请求，去掉 VXLAN 头部，并通过报文学习到发送方 <虚拟机MAC-VNI-VTEP IP>这个对应关系，并把原来的 ARP 报文广播给主机。
• 主机接受到 ARP 请求报文，如果 ARP 报文请求的是自己的 MAC 地址，就返回 ARP 应答
• VTEP(2) 此时已经知道发送方的虚拟机 MAC 和 VTEP 信息，把 ARP 应答添加上 VXLAN 头部之后通过单播发送出去
• VTEP(1)接收到报文，并学习到报文中的的对应关系，记录下来。然后 VTEP 进行解包，知道内部的 IP 和 MAC 地址，并转发给虚拟机。
• 虚拟机拿到 ARP 应答报文，就知道了对方 IP 对应的 MAC 地址。

在这次多播之后，两台虚拟机之间的通信就可以通过单播了。VTEP 在这中间担任了一个代理的角色，使得虚拟机之间可以透明的进行网络通信。这和 nginx 担任反向代理的角色有点类似。同时我们可以发现，在一个大规模的 VXLAN 网络中，多播会是一件很消耗性能的事。

资料地址

VXLAN vs VLAN VXLAN in OpenStack Neutron VXLAN 协议原理简介 linux 上实现vxlan网络

简介

linux 下的 ip 命令是一个很强大的工具，在这之前，我通常只会使用 ifconfig 命令来查看本机网络接口和 ip 地址等等。或者 netstat 命令查看端口占用等等。ip 命令属于 iproute2 套件中的一个命令，关于 iproute2 和 linux net-tools 中的命令对比如下（图片来源:https://linux.cn/article-3144-1.html)： 可以看出，除了部分 netstat 命令用 ss 来替代，其它都可以用 ip 命令替代。并且，iproute2 已经是大多数 linux 发行版默认安装了，而 net-tools 则需要另外安装。 ip 命令可以分为下面几个模块:

• 网卡设备相关: ip link
• 网卡地址相关: ip addr
• 路由表相关: ip route
• arp 相关: ip neigh

下面会列出一些常用的操作，最好在虚拟机中操作，防止影响个人机器。

ip link

查看 ip link 的帮助

$ ip link help

查看网络接口

$ ip link list

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 52:54:00:8a:fe:e6 brd ff:ff:ff:ff:ff:ff
3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether 08:00:27:15:ee:5c brd ff:ff:ff:ff:ff:ff

这里显示了三个网络接口，lo代表的本机的回环网卡，eth0 和 eth1 分别是两个网卡 添加网络接口

$ sudo ip link add link eth0 mydev type bridge

这里添加了一个网桥，连接在 eth0 上。使用 ip link list 查看可以发现多了下面一个设备

6: mydev: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
    link/ether 5e:0c:36:7b:ce:0d brd ff:ff:ff:ff:ff:ff

删除网络接口

$ sudo ip link delete link dev mydev

关闭网络接口

$ sudo ip link set eth1 down

打开网络接口

$ sudo ip link set eht1 up

ip addr

查看帮助

$ ip addr help

查看网络地址

$ ip addr list

查看某一个网络接口的地址

$ ip addr show eth1

添加 ip 地址

$ sudo ip addr add 192.168.31.131/24 dev eth1

查看 eth1 的地址

$ ip addr show eth1

3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether 08:00:27:15:ee:5c brd ff:ff:ff:ff:ff:ff
    inet 192.168.31.77/24 brd 192.168.31.255 scope global noprefixroute dynamic eth1
       valid_lft 42769sec preferred_lft 42769sec
    inet 192.168.31.131/24 scope global secondary eth1
       valid_lft forever preferred_lft forever
    inet6 fe80::a00:27ff:fe15:ee5c/64 scope link 
       valid_lft forever preferred_lft forever

我们也可以 ping 一下这个地址:

$ ping 192.168.31.131

PING 192.168.31.131 (192.168.31.131) 56(84) bytes of data.
64 bytes from 192.168.31.131: icmp_seq=1 ttl=64 time=0.109 ms
64 bytes from 192.168.31.131: icmp_seq=2 ttl=64 time=0.155 ms

删除 ip 地址

$ sudo ip addr del 192.168.31.131/24 dev eth1

改变设备地址的配置 这里有一篇很好的文章: understanding ip addr change and ip addr replace commands 为了演示的方便，我添加了一个网卡设备

$ sudo ip link add link eth0 name dummy0 type dummy

为它分配地址:

$ sudo ip addr add 192.168.31.132/24 dummy0
$ ip addr show dummy0

5: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 9e:dc:6e:0b:70:99 brd ff:ff:ff:ff:ff:ff
    inet 192.168.31.132/24 scope global dummy0
       valid_lft forever preferred_lft forever

如果你想要修改 valid_lft 和 preferred_lft 配置，可以使用 ip change命令:

$ sudo ip addr change 192.168.31.132 dev dummy0 preferred_lft 300 valid_lft 300
$ ip addr show dummpy0

5: dummy0: <BROADCAST,NOARP> mtu 1500 qdisc noop state DOWN group default qlen 1000
    link/ether 9e:dc:6e:0b:70:99 brd ff:ff:ff:ff:ff:ff
    inet 192.168.31.132/24 scope global dynamic dummy0
       valid_lft 299sec preferred_lft 299sec

ip route

查看帮助

$ ip route help

查看路由

$ ip route list

添加路由 添加一条普通的路由

$ sudo ip route add 39.156.0.0/16 via 192.168.31.133 dev dummy0

添加默认路由

$ sudo ip route add default via 192.168.31.133 dev dummy0

删除路由 删除默认路由

$ sudo ip route del default via 192.168.31.133 dev dummy0

删除普通路由

$ sudo ip route del 39.156.0.0/16 via 192.168.31.133 dev dummy0 

**查看一个 ip 地址的路由包来源

$ ip route get 39.156.69.79

39.156.69.79 via 10.0.2.2 dev eth0 src 10.0.2.15 
    cache 

ip neigh

查看帮助

$ ip neigh help

查看同一个网络的邻居设备

$ ip neigh show

192.168.31.1 dev eth1 lladdr 34:ce:00:2e:88:b9 STALE
10.0.2.2 dev eth0 lladdr 52:54:00:12:35:02 REACHABLE
10.0.2.3 dev eth0 lladdr 52:54:00:12:35:03 STALE

pod 基础概念

在 Kubernetes 中， Pod 是一个非常重要的概念，它由一个或多个容器组成，这些容器共享存储、网络、进程空间，以及可以使用进程间通信。 Pod 是集群中最小的调度单位，如果把 Kubernetes 集群比作操作系统，那么 Pod 则是一个进程。一个 Pod 被创建出来之后，它会被调度到集群中的某一个节点上开始运行，Pod 中的 Container 都会在该节点上启动。 Pod 是短暂的，就跟进程一样，在被创建之后可能会随时被终止。但是 Kubernetes 会根据需求来的及时的重新创建一个 Pod，所以单独从 Pod 的层面来说，它应该是一个无状态的应用。 集群中的每个 Pod 都会有唯一的 ID (UID)，这跟进程的进程号是唯一的一样。

共享命名空间

这里以 docker 在 linux 下的实现为例，docker 主要使用了 linux namespace 做的资源隔离。在 pod 中，所有的 docker 容器都可以共享同一个 network, ipc, pid命名空间，并且可以通过挂载同一个卷的方式来共享文件系统。需要注意的是，默认情况下只有 network 这个命名空间是开启的，其他的需要通过 shareProcessNamespace、 SYS_PTRACE 和 emptyDir 等字段来开启。 为了说明，可以在 kubernetes 集群中创建下面这个 pod

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  shareProcessNamespace: true
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
      - mountPath: /cache
        name: cache-volume
  - name: shell
    image: busybox
    volumeMounts:
      - mountPath: /cache
        name: cache-volume
    securityContext:
      capabilities:
        add:
        - SYS_PTRACE
    stdin: true
    tty: true
  volumes:
  - name: cache-volume
    emptyDir: {}

上面创建的 Pod 有两个容器，一个是 nginx，另一个是 shell。我们使用以下命令进入到 shell 容器中。

kubectl exec -it nginx -c shell sh

network

为了验证同一个 Pod 下 network 是共享的，可以使用以下命令验证

$ wget localhost
Connecting to localhost (127.0.0.1:80)
saving to 'index.html'
index.html           100% |******************************************|   612  0:00:00 ETA
'index.html' saved

很明显，这里的 localhost 指向了 nginx 容器。

pid

$ ps -el
PID   USER     TIME  COMMAND
    1 root      0:00 /pause
    6 root      0:00 nginx: master process nginx -g daemon off;
   11 101       0:00 nginx: worker process
   12 root      0:00 sh
   20 root      0:00 sh
   26 root      0:00 ps

在 shell 容器中查看进程可以看到 /pause 和 nginx 等进程。因为共享了 pid 命名空间，所以可以看到其他容器的进程。这里的 pause 是一个很特殊的进程，在后文章会单独解释。

ipc

$ kill -9 11
$ ps -el
PID   USER     TIME  COMMAND
    1 root      0:00 /pause
    6 root      0:00 nginx: master process nginx -g daemon off;
   12 root      0:00 sh
   20 root      0:00 sh
   29 101       0:00 nginx: worker process
   30 root      0:00 ps -el

接着上面的命令，我们杀死了 nginx 的 worker 进程，nginx master 进程又重启了 worker，重启后的 worker PID 是 29。可以在 shell 容器中使用信号杀死 nginx 中的进程，说明 IPC 命名空间是共享的。

shared volume

$ cd cache
$ touch test
$ kubectl exec -it nginx -c nginx sh
$ ls /cache
test

我们在 shell 容器中 cache 文件夹下创建了文件 test, 在 nginx 容器中也能看到，说明两个容器可以共享文件系统的某些目录。

容器探针

之所以特地提到容器探针是因为容器探针是一个非常好的检查服务是否正确运行的方式。 TODO: 几种探针的使用场景和 探针是由 kubelet 周期性对容器执行的诊断措施。kubernetes 提供了三种方式:

• ExecAction: 在容器中执行命令，如果命令的 exit code 是 0 则代表成功。
• TCPSocketAction: 在容器的ip和端口上执行 tcp 连接检查，如果端口是打开的则表明诊断成功。
• HTTPGetAction: 在容器的ip和制定端口和路径上执行，如果返回的状态码大于等于 200 ,小于400就表明成功。

直到 kubernetes v1.16 止，共有三种探针可以使用，分别是 livenessProbe, readinessProbe, startupProbe.

• livenessProbe: 检查容器是否在运行，如果 liveness 探针失败，kubelet 会杀死这个容器，这个容器会遵循它的重启策略。如果一个容器没有提供 liveness 探针，默认状态是 Success。

• readinessProbe: 表明容器是否准备好接收请求了。如果 readiness 探针失败，endpoints 控制器会从符合这个 Pod 的所有 service 的 endpoint 列表中移除该 Pod。默认状态是 Failure。如果容器没有提供 readiness 探针，默认状态就是 Success。

• startupProbe: 表明容器中的应用是否启动完成。如果提供了 startup 探针，其他的探针都被禁用直到 startup 探针成功。如果 startup 探针失败，kuberlet 杀死容器，容器会遵循它的重启策略。是否容器没有提供 startup 探针，默认状态是 Success。

init container

我们都知道 Pod 可以有多个容器，其中 init 容器是比较特殊的一个，它由 spec.initContainers 指定，与普通容器不同的是，只有在 init 容器运行完成之后，Kubernetes 才会初始化 Pod 和运行应用容器。 实际应用中，init 容器的职责基本上都是和它名字描述的一样，用来做初始化用。比如在 argo 这个工作流调度应用中，它会为每个调度的 Pod 初始化一个 init 容器，用来载入该步骤需要使用的文件资源等等。

pause container

在上面提到了 pid namespace 共享中，有一个 PID 为 1 的 Pause 进程，这就是现在提到的 pause container，pause container 对 kubernetes 用户是不感知的。但是我们在 kubernetes 节点上使用 docker ps来查看，会发现很多的 pause 容器。pause 容器的作用主要有两点：

• 在 pod 中作为 linux namespace 共享的基础容器
• 在 PID namespace 共享的前提下，作为每个 pod 中的PID 1，然后回收僵尸进程

为了研究pause的作用，可以在电脑上执行以下的命令：

docker run -d --ipc=shareable --name pause -p 8080:80 warrior/pause-amd64:3.0

docker run -d --name nginx -v /home/jiang/projects/testk8s/nginx.conf:/etc/nginx/nginx.conf --net=container:pause --ipc=container:pause --pid=container:pause nginx

docker run -d --name ghost --net=container:pause --ipc=container:pause --pid=container:pause ghost

nginx.conf 如下:

error_log stderr;
events {worker_connections 1024;}
http {
    access_log /dev/stdout combined;
    server {
        listen 80 default_server;
        server_name example.com;
        location / {
            proxy_pass http://127.0.0.1:2368;
        }
    }
}

我们首先启动了一个 pause 容器，并且开始了 ipc 的共享。然后又启动了 nginx 和 ghost 容器，并且这两个容器都加入了 pause 的network、ipc和pid命名空间。 在浏览器中打开地址: http://localhost:8080, 发现打开了 ghost 博客网页。我们在容器 pause 中开启的 8080 端口，然后经过 nginx 容器代理到了 ghost 容器。我们的应用容器 pause 容器完成了命名空间的共享。 我们再来看一下 pause 的代码:

/*
Copyright 2016 The Kubernetes Authors.
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
    http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
*/

#include <signal.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/wait.h>
#include <unistd.h>

static void sigdown(int signo) {
  psignal(signo, "Shutting down, got signal");
  exit(0);
}

static void sigreap(int signo) {
  while (waitpid(-1, NULL, WNOHANG) > 0);
}

int main() {
  if (getpid() != 1)
    /* Not an error because pause sees use outside of infra containers. */
    fprintf(stderr, "Warning: pause should be the first process\n");

  if (sigaction(SIGINT, &(struct sigaction){.sa_handler = sigdown}, NULL) < 0)
    return 1;
  if (sigaction(SIGTERM, &(struct sigaction){.sa_handler = sigdown}, NULL) < 0)
    return 2;
  if (sigaction(SIGCHLD, &(struct sigaction){.sa_handler = sigreap,
                                             .sa_flags = SA_NOCLDSTOP},
                NULL) < 0)
    return 3;

  for (;;)
    pause();
  fprintf(stderr, "Error: infinite loop terminated\n");
  return 42;
}

这段代码在监听了三个信号量，在 SIGINT 和　SIGTERM　时调用 sigdown() 来退出。在接收到　SIGCHLD 信号时使用 waitpid，因为 pause 进程的 PID 是１，所以所有的僵尸进程都会被挂到 pause 进程之下，因此 waitpid 可以回收僵尸进程。

multi containers design pattern

在大多数情况下，Pod 往往只有一个容器，因为一个 Pod 的职责是唯一的。但是同样的，也有一些值得借鉴的多容器设计模式。 常用的模式有三种: sidecar, adapter, ambassador, 下图是常见的三种设计模式图，图片来源于网络:

sidecar 模式

在 sidecar 模式中，通常有一个主要的容器A–比如我们的 web 应用，然后有另外一个重要的容器B，负责处理 A 容器的一些功能，但是 B 容器又不是必须的。这个 B 容器我们通常称它为 sidecar 容器。 常见的 sidecar 容器有 日志，同步服务，监控等职责。当应用容器不在运行时，日志容器的运行是没有意义的，所以我们通常会创建一个 Pod 包含主要的容器和一个 sidecar 容器，来协同工作。这样的好处就是减少应用容器的功能需求，将通用的功能交给 sidecar 容器去执行，而又不会侵入应用容器。

adapter 模式

adapter 模式就是程序设计中常用的适配器模式，负责将应用容器中一些不兼容的功能调整成兼容的格式。比如一个大型系统中有很多小的系统，每个系统输出的日志格式都不同。而我们的统一监控系统只接受一种日志格式。这时候就可以使用 adapter 模式在 Pod 的加入一个负责适配的容器，将各种格式的日志调整成相同的统一发送给日志系统。

ambassador 模式

ambassador 模式常用来将应用容器连接到容器之外的网络。比如数据库，我们的应用容器只负责连接 localhost 的地址，然后由 ambassador 容器判断当前的环境，将应用容器的数据库请求代理到不同的数据库上。这样，我们在开发环境，测试环境，生产环境都只需要一套配置。

pod lifecycle

pod 的状态包含一个 phase 属性，这个属性用来描述当前 pod 的状态，可能的值有:

• Pending: Pod 已经被 Kubernetes 系统接受，但是有一个或多个容器镜像尚未创建。等待时间包括调度 Pod 的时间和通过网络下载镜像的时间。
• Running: Pod 已经绑定到一个节点上，Pod 中所有的容器都已经被创建，至少有一个容器正在运行，或者正处于启动或重启状态。
• Succeeded: Pod中的所有容器都被成功终止，并且不会再重启。
• Failed: Pod中所有容器都已经终止，并且至少有一个容器是因为失败终止。也就是说，容器以非0状态退出或被系统终止。
• Unknown: 因为某些原因无法取得 Pod 的状态，通过是因为与 Pod 所在的主机通信失败。

下图是一个 Pod 的生命周期状态，图片来源于网络： 在 Pod 的整个生命周期中，我们可以通过容器的生命周期钩子来在某些阶段处理一些工作。

• PostStart: 当容器被创建的时候，这个钩子会立刻执行。

• PreStop: 当容器退出时执行

在两种钩子触发时我们可以选择调用脚本执行还是发送HTTP请求。

参考资料

Pods-Kubernetes Pod状态与生命周期管理 The Almighty Pause Container The Distributed System Toolkit: Patterns for Composite Containers Container Design Patterns Multi-Container Pod Design Patterns in Kubernetes

简介

tensorflow-serving是一个tensorflow模型部署的方案，其在设计时，就考虑了非常灵活的设计，比如：

• 支持不同的文件系统，并且易扩展
• 将模型发现、加载、使用和卸载和模型生命周期的管理，以及对外提供服务解耦合，因此非常容易扩展它的模型发现方式，以及同样可以支持其他框架下模型的整合。
• 整个服务是无状态的，因此方便在k8s上进行部署

下图是 tensorflow serving 的整体架构:

模型加载方式

tensorflow-serving支持从不同的地方，以不同的方式去加载模型。比如我们可以直接在启动tensorflow-serving时加上模型的地址，也可以提供模型配置文件来启动服务。 启动时加上参数:

tensorflow_model_server --port=9000 --rest_api_port=8500 --model_name=resnet --model_base_path=/home/jiang/data/yolov3

从配置文件中加载模型: /etc/config/models.config

model_config_list {
    config {
        name: 'fashion'
        base_path: 's3://models/fashion/'
        model_platform: 'tensorflow'
    }
    config {
        name: 'resnet'
        base_path: 's3://models/resnet/'
        model_platform: 'tensorflow'
    }
}

执行以下命令来加载fashion和resnet两个模型：

tensorflow_model_server --port=9000", "--rest_api_port=8500", "--model_config_file=/etc/config/models.config"

模型存储系统

tensorflow-serving的另一个特点就是支持从不同类型的存储系统中加载模型。比如本地的文件系统、s3、hdfs等等 从本地文件系统中加载

tensorflow_model_server --port=9000 --rest_api_port=8500 --model_name=resnet --model_base_path=/home/jiang/data/yolov3

从s3加载 从s3（兼容s3的对象存储系统都可以）中加载模型，需要配置一些环境变量

export AWS_ACCESS_KEY_ID=<key id>
export AWS_SECRET_ACCESS_KEY=<key>
export S3_ENDPOINT=minio-service.minio:9000
export S3_USE_HTTPS=0
export S3_VERIFY_SSL=0
export AWS_REGION=us-west-1
export S3_REGION=us-west-1
export AWS_LOG_LEVEL=3

然后通过以下命令启动服务即可

tensorflow_model_server --port=9000 --rest_api_port=8500 --model_name=resnet --model_base_path=s3://models/resnet/

从hdfs中加载 从hdfs中加载需要设置以下的环境变量

• JAVA_HOME: Java 的安装路径

• HADOOP_HDFS_HOME: HDFS 的安装路径，如果在LD_LIBRARY_PATH中设置了 libhdfs.so 的路径，那么这个环境变量可以不要。

• LD_LIBRARY_PATH: 引入 libjvm.so 的路径。如果你的 HADOOP 发行版在 ${HADOOP_HDFS_HOME}/lib/native 这个目录下没有包含 libhdfs.so，也需要引入它。

export LD_LIBRARY_PATH=${LD_LIBRARY_PATH}:${JAVA_HOME}/jre/lib/amd64/server

• CLASSPATH: 注意仅仅是设置 CLASSPATH 环境变量是不行的，需要用以下的方式使用:

CLASSPATH=$(${HADOOP_HDFS_HOME}/bin/hadoop classpath --glob) tensorflow_model_server --port=9000 --rest_api_port=8500 --model_name=yolov3 --model_base_path=hdfs://worknode2:9000/pipeline/models/yolov3

在k8s中部署

s3 tensorflow-serving 官方提供了docker镜像，因此使用 s3 的方式加载模型部署是很简单的。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: tfserving-deployment
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: tfserving
    spec:
      containers:
      - name: serving-container
        image: tensorflow/serving:1.14.0  
        ports:
        - containerPort: 8500
        - containerPort: 9000
        env:
        - name: AWS_ACCESS_KEY_ID
          value: J5WW5NKKV7AE9S0WZCM1
        - name: AWS_SECRET_ACCESS_KEY
          value: TbG0Y6nnUV8nQNLL9n4B3u3UPMMCJvqs2COx3and
        - name: S3_ENDPOINT
          value: minio-service.minio:9000
        - name: S3_USE_HTTPS
          value: "0"
        - name: S3_VERIFY_SSL
          value: "0"
        - name: AWS_REGION
          value: us-west-1
        - name: S3_REGION
          value: us-west-1
        - name: AWS_LOG_LEVEL
          value: "3"
        command: ["/usr/bin/tensorflow_model_server"]
        args: ["--port=9000", "--rest_api_port=8500", "--model_name=resnet", "--model_base_path=s3://models/resnet/"]

---
apiVersion: v1
kind: Service
metadata:
  labels:
    run: tf-service 
  name: tf-service
spec:
  ports:
  - name: rest-api-port
    port: 8500
    targetPort: 8500
  - name: grpc-port
    port: 9000
    targetPort: 9000
  selector:
    app: tfserving 
  type: NodePort

hdfs 在官方提供的 docker 镜像中，并没有打包 hdfs 的环境，因此我们需要自己构建一个镜像: Dockerfile 所在目录如下:

hdfs_dockerfile
├── Dockerfile
└── hadoop-2.10.0
    ├── bin
    ├── etc
    ├── include
    ├── lib
    ├── libexec
    ├── LICENSE.txt
    ├── logs
    ├── NOTICE.txt
    ├── README.txt
    ├── sbin
    └── share

Dockerfile 如下:

FROM tensorflow/serving:1.14.0

RUN apt update && apt install -y openjdk-8-jre

COPY hadoop-2.10.0 /root/hadoop

ENV JAVA_HOME /usr/lib/jvm/java-8-openjdk-amd64/
ENV HADOOP_HDFS_HOME /root/hadoop
ENV LD_LIBRARY_PATH ${LD_LIBRARY_PATH}:${JAVA_HOME}/jre/lib/amd64/server

RUN echo '#!/bin/bash \n\n\
CLASSPATH=$(${HADOOP_HDFS_HOME}/bin/hadoop classpath --glob) tensorflow_model_server --port=8500 --rest_api_port=9000 \
--model_name=${MODEL_NAME} --model_base_path=${MODEL_BASE_PATH}/${MODEL_NAME} \
"$@"' > /usr/bin/tf_serving_entrypoint.sh \
&& chmod +x /usr/bin/tf_serving_entrypoint.sh

EXPOSE 8500
EXPOSE 9000
ENTRYPOINT ["/usr/bin/tf_serving_entrypoint.sh"]

进行构建:

docker build -t tensorflow_serving:1.14-hadoop-2.10.0 .

运行:

docker run -p 9000:9000 --name tensorflow-serving -e MODEL_NAME=yolov3 -e MODEL_BASE_PATH=hdfs://192.168.50.166:9000/pipeline/models -t tensorflow_serving:1.14-hadoop-2.10.0

这样将上面的部署文件稍微修改一下即可使用。

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: tfserving-deployment
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: tfserving
    spec:
      containers:
      - name: serving-container
        image: joyme/tensorflow_serving:1.14-hadoop-2.10.0
        ports:
        - containerPort: 8500
        - containerPort: 9000
        env:
        - name: MODEL_NAME
          value: yolov3
        - name: MODEL_BASE_PATH
          value: hdfs://192.168.50.166:9000/pipeline/models

---
apiVersion: v1
kind: Service
metadata:
  labels:
    run: tf-service 
  name: tf-service
spec:
  ports:
  - name: rest-api-port
    port: 8500
    targetPort: 8500
  - name: grpc-port
    port: 9000
    targetPort: 9000
  selector:
    app: tfserving 
  type: NodePort

模型调用

tensorflow-serving 支持两种方式调用模型进行预测: GRPC 和 RESTful api GRPC的方式如下:

from __future__ import print_function

import grpc
import requests
import tensorflow as tf

from tensorflow_serving.apis import predict_pb2
from tensorflow_serving.apis import prediction_service_pb2_grpc

IMAGE_URL = 'https://tensorflow.org/images/blogs/serving/cat.jpg'

tf.app.flags.DEFINE_string('server', '192.168.50.201:30806', 'PredictionService host:port')
tf.app.flags.DEFINE_string('image', '', 'path to image in jpeg format')
FLAGS = tf.app.flags.FLAGS

def main(_):
    if FLAGS.image:
        with open(FLAGS.image, 'rb') as f:
            data = f.read()
    else:
        dl_request = requests.get(IMAGE_URL, stream=True)
        dl_request.raise_for_status()
        data = dl_request.content

    channel = grpc.insecure_channel(FLAGS.server)
    stub = prediction_service_pb2_grpc.PredictionServiceStub(channel)

    # Send request
    request = predict_pb2.PredictRequest()
    request.model_spec.name = 'resnet'
    request.model_spec.signature_name = 'serving_default'
    request.inputs['image_bytes'].CopyFrom(
            tf.contrib.util.make_tensor_proto(data, shape=[1]))

    result = stub.Predict(request, 10.0) # 10 secs timeout
    print(result)

if __name__ == '__main__':
    tf.app.run()

RESTful API的方式如下

import requests
import json
import base64

with open("cat.jpg", "rb") as image_file:
    encoded_string = base64.b64encode(image_file.read())

headers = {"content-type": "application/json"}
body = {
        "instances": [
            {'b64': encoded_string}
           ]
        }
r = requests.post('http://192.168.50.201:32063/v1/models/resnet:predict', data = json.dumps(body), headers = headers)

print(r.text)

概述

我认为容器标准化可以分为两个角度去讲： 一个是容器的使用和镜像的格式需要规范，这叫做OCI(open container initiative)，也就是说，不同技术实现的容器，都可以使用同一种方式运行，同一个镜像也可以在不同的容器技术上运行。 另外一个就是因为Kubernetes的流行，Kubernetes推出了一个CRI(container runtime interface)的接口规范，凡是直接或间接实现了这个接口规范的容器都可以作为Kubernetes的默认容器运行时。 OCI和CRI的制定也意味着容器技术迎来了高速发展。

CRI: container runtime interface

CRI是kubernetes推出的容器运行时接口，有了CRI，不论各种容器化技术是如何实现的，都可以用一个共同的接口对外提供服务。CRI中定义了容器和镜像的接口的接口，基于gRPC调用。具体的可以查看api.proto。下面简单的列一下:

// Runtime service defines the public APIs for remote container runtimes
service RuntimeService {
    // Version returns the runtime name, runtime version, and runtime API version.
    rpc Version(VersionRequest) returns (VersionResponse) {}

    // RunPodSandbox creates and starts a pod-level sandbox. Runtimes must ensure
    // the sandbox is in the ready state on success.
    rpc RunPodSandbox(RunPodSandboxRequest) returns (RunPodSandboxResponse) {}
    // StopPodSandbox stops any running process that is part of the sandbox and
    // reclaims network resources (e.g., IP addresses) allocated to the sandbox.
    // If there are any running containers in the sandbox, they must be forcibly
    // terminated.
    // This call is idempotent, and must not return an error if all relevant
    // resources have already been reclaimed. kubelet will call StopPodSandbox
    // at least once before calling RemovePodSandbox. It will also attempt to
    // reclaim resources eagerly, as soon as a sandbox is not needed. Hence,
    // multiple StopPodSandbox calls are expected.
    rpc StopPodSandbox(StopPodSandboxRequest) returns (StopPodSandboxResponse) {}
    // RemovePodSandbox removes the sandbox. If there are any running containers
    // in the sandbox, they must be forcibly terminated and removed.
    // This call is idempotent, and must not return an error if the sandbox has
    // already been removed.
    rpc RemovePodSandbox(RemovePodSandboxRequest) returns (RemovePodSandboxResponse) {}
    // PodSandboxStatus returns the status of the PodSandbox. If the PodSandbox is not
    // present, returns an error.
    rpc PodSandboxStatus(PodSandboxStatusRequest) returns (PodSandboxStatusResponse) {}
    // ListPodSandbox returns a list of PodSandboxes.
    rpc ListPodSandbox(ListPodSandboxRequest) returns (ListPodSandboxResponse) {}

    // CreateContainer creates a new container in specified PodSandbox
    rpc CreateContainer(CreateContainerRequest) returns (CreateContainerResponse) {}
    // StartContainer starts the container.
    rpc StartContainer(StartContainerRequest) returns (StartContainerResponse) {}
    // StopContainer stops a running container with a grace period (i.e., timeout).
    // This call is idempotent, and must not return an error if the container has
    // already been stopped.
    // TODO: what must the runtime do after the grace period is reached?
    rpc StopContainer(StopContainerRequest) returns (StopContainerResponse) {}
    // RemoveContainer removes the container. If the container is running, the
    // container must be forcibly removed.
    // This call is idempotent, and must not return an error if the container has
    // already been removed.
    rpc RemoveContainer(RemoveContainerRequest) returns (RemoveContainerResponse) {}
    // ListContainers lists all containers by filters.
    rpc ListContainers(ListContainersRequest) returns (ListContainersResponse) {}
    // ContainerStatus returns status of the container. If the container is not
    // present, returns an error.
    rpc ContainerStatus(ContainerStatusRequest) returns (ContainerStatusResponse) {}
    // UpdateContainerResources updates ContainerConfig of the container.
    rpc UpdateContainerResources(UpdateContainerResourcesRequest) returns (UpdateContainerResourcesResponse) {}
    // ReopenContainerLog asks runtime to reopen the stdout/stderr log file
    // for the container. This is often called after the log file has been
    // rotated. If the container is not running, container runtime can choose
    // to either create a new log file and return nil, or return an error.
    // Once it returns error, new container log file MUST NOT be created.
    rpc ReopenContainerLog(ReopenContainerLogRequest) returns (ReopenContainerLogResponse) {}

    // ExecSync runs a command in a container synchronously.
    rpc ExecSync(ExecSyncRequest) returns (ExecSyncResponse) {}
    // Exec prepares a streaming endpoint to execute a command in the container.
    rpc Exec(ExecRequest) returns (ExecResponse) {}
    // Attach prepares a streaming endpoint to attach to a running container.
    rpc Attach(AttachRequest) returns (AttachResponse) {}
    // PortForward prepares a streaming endpoint to forward ports from a PodSandbox.
    rpc PortForward(PortForwardRequest) returns (PortForwardResponse) {}

    // ContainerStats returns stats of the container. If the container does not
    // exist, the call returns an error.
    rpc ContainerStats(ContainerStatsRequest) returns (ContainerStatsResponse) {}
    // ListContainerStats returns stats of all running containers.
    rpc ListContainerStats(ListContainerStatsRequest) returns (ListContainerStatsResponse) {}

    // UpdateRuntimeConfig updates the runtime configuration based on the given request.
    rpc UpdateRuntimeConfig(UpdateRuntimeConfigRequest) returns (UpdateRuntimeConfigResponse) {}

    // Status returns the status of the runtime.
    rpc Status(StatusRequest) returns (StatusResponse) {}
}

// ImageService defines the public APIs for managing images.
service ImageService {
    // ListImages lists existing images.
    rpc ListImages(ListImagesRequest) returns (ListImagesResponse) {}
    // ImageStatus returns the status of the image. If the image is not
    // present, returns a response with ImageStatusResponse.Image set to
    // nil.
    rpc ImageStatus(ImageStatusRequest) returns (ImageStatusResponse) {}
    // PullImage pulls an image with authentication config.
    rpc PullImage(PullImageRequest) returns (PullImageResponse) {}
    // RemoveImage removes the image.
    // This call is idempotent, and must not return an error if the image has
    // already been removed.
    rpc RemoveImage(RemoveImageRequest) returns (RemoveImageResponse) {}
    // ImageFSInfo returns information of the filesystem that is used to store images.
    rpc ImageFsInfo(ImageFsInfoRequest) returns (ImageFsInfoResponse) {}
}

共包含了两个服务: - RuntimeService：容器和Sandbox运行时管理。 - ImageService：提供了从镜像仓库拉取、查看、和移除镜像的RPC。 再看一下CRI的架构图： 在kubernetes中，CRI扮演了kubelet和container runtime的通信桥梁。也因为CRI的存在，container runtime和kubelet解耦，就有了多种选择，比如: docker、 CRI-O、containerd、frakti等等。

OCI: open container initiative

这个是由docker和其他的公司推动的容器标准，为了围绕容器格式和运行时制定一个开放的工业化标准，目前主要有两个标准文档：容器运行时标准 （runtime spec）和 容器镜像标准（image spec）。这两个协议通过 OCI runtime filesytem bundle 的标准格式连接在一起，OCI 镜像可以通过工具转换成 bundle，然后 OCI 容器引擎能够识别这个 bundle 来运行容器 下面引用一下其他博客的文字（https://www.jianshu.com/p/62e71584d1cb）：

设计考量 操作标准化：容器的标准化操作包括使用标准容器创建、启动、停止容器，使用标准文件系统工具复制和创建容器快照，使用标准化网络工具进行下载和上传。 内容无关：内容无关指不管针对的具体容器内容是什么，容器标准操作执行后都能产生同样的效果。如容器可以用同样的方式上传、启动，不管是PHP应用还是MySQL数据库服务。 基础设施无关：无论是个人的笔记本电脑还是AWS S3，亦或是OpenStack，或者其它基础设施，都应该对支持容器的各项操作。 为自动化量身定制：制定容器统一标准，是的操作内容无关化、平台无关化的根本目的之一，就是为了可以使容器操作全平台自动化。 工业级交付：制定容器标准一大目标，就是使软件分发可以达到工业级交付成为现实 image spec（容器标准包） OCI 容器镜像主要包括几块内容： 文件系统：以 layer 保存的文件系统，每个 layer 保存了和上层之间变化的部分，layer 应该保存哪些文件，怎么表示增加、修改和删除的文件等 config 文件：保存了文件系统的层级信息（每个层级的 hash 值，以及历史信息），以及容器运行时需要的一些信息（比如环境变量、工作目录、命令参数、mount 列表），指定了镜像在某个特定平台和系统的配置。比较接近我们使用 docker inspect 看到的内容 manifest 文件：镜像的 config 文件索引，有哪些 layer，额外的 annotation 信息，manifest 文件中保存了很多和当前平台有关的信息 index 文件：可选的文件，指向不同平台的 manifest 文件，这个文件能保证一个镜像可以跨平台使用，每个平台拥有不同的 manifest 文件，使用 index 作为索引 runtime spec（容器运行时和生命周期） 容器标准格式也要求容器把自身运行时的状态持久化到磁盘中，这样便于外部的其它工具对此信息使用和演绎。该运行时状态以JSON格式编码存储。推荐把运行时状态的JSON文件存储在临时文件系统中以便系统重启后会自动移除。 基于Linux内核的操作系统，该信息应该统一地存储在/run/opencontainer/containers目录，该目录结构下以容器ID命名的文件夹（/run/opencontainer/containers//state.json）中存放容器的状态信息并实时更新。有了这样默认的容器状态信息存储位置以后，外部的应用程序就可以在系统上简便地找到所有运行着的容器了。 state.json文件中包含的具体信息需要有： 版本信息：存放OCI标准的具体版本号。 容器ID：通常是一个哈希值，也可以是一个易读的字符串。在state.json文件中加入容器ID是为了便于之前提到的运行时hooks只需载入state.json就- - 可以定位到容器，然后检测state.json，发现文件不见了就认为容器关停，再执行相应预定义的脚本操作。 PID：容器中运行的首个进程在宿主机上的进程号。 容器文件目录：存放容器rootfs及相应配置的目录。外部程序只需读取state.json就可以定位到宿主机上的容器文件目录。 容器创建：创建包括文件系统、namespaces、cgroups、用户权限在内的各项内容。 容器进程的启动：运行容器进程，进程的可执行文件定义在的config.json中，args项。 容器暂停：容器实际上作为进程可以被外部程序关停（kill），然后容器标准规范应该包含对容器暂停信号的捕获，并做相应资源回收的处理，避免孤儿进程的出现。

CRI和OCI的对比

OCI是容器技术的开放性标准，而CRI是Kubernetes为了更方便的支持不同的容器技术，而推出的接口标准，与CRI类似的还有CNI和CSI，分别是网络和存储的接口。 可以看一下这张图: kubelet有了CRI的接口，可以通过cri-containerd和containerd通信，也可以通过docker-shim和docker通信。注意这里的cri-containerd在containerd v1.2的时候就已经不再使用了，因为containerd本身就支持了CRI的规范。 同时kubernetes还孵化了cri-o这个项目，cri-o直接打通了cri和oci。runc和kata都是oci的具体实现。 所以，用一句话理解：实现了CRI就可以保证被kubernetes使用，实现了OCI就可以在各种设备上无差别的使用各种镜像。

docker、containerd和runc

containerd从docker中分出来的一部分。containerd是负责管理容器生命周期的常驻进程，而runc则是真正负责容器运行的部分。可以通过以下的图来看三者之间的关系： containerd会调用多个runc实例来管理多个容器。docker engine则是提供接口给用户使用。

kubernetes当前支持的CRI后端

containerd

containerd的地址：https://github.com/containerd/containerd 先用官网的图片来看一下containerd的架构： containerd处于os和clients之间，它使用CRI API提供给Kubelet调用，使用containerd API提供给containerd client调用，使用Metrics API提供给Prometheus监控数据。然后有一层containerd Service Interfaces提供给上层api使用。注意到其中还有一个container-shim打通了Runtime manager和OCI runtime的具体实现，比如runc、runhcs、kata。 containerd实现了以下的特性：

• OCI Image规范的支持
• OCI Runtime规范的支持(通过runc等)
• Image的上传和下载
• 容器运行时和生命周期的支持
• 创建、修改和删除网络
• 管理网络命名空间以及将容器加入到现有的网络命名空间
• 全部镜像的CAS存储的多租户模式支持

cri-o

项目地址：https://github.com/cri-o/cri-o cri-o项目是Kubernetes CRI接口的实现，同时可以兼容OCI标准的容器运行时。这样的能力就使得它可以作为Docker的轻量级的容器运行时的替代方案，使得Kubernetes可以接入符合OCI标准的所有容器运行时，同时也减少了容器开发者们的额外工作量（只需实现OCI标准即可）。

frakti

项目地址：https://github.com/kubernetes/frakti frakti是Kubernetes官方推出的一个容器运行时，但是不同于docker这样的利于linux namespace的技术，它是基于虚拟化技术的容器，因此可以带来更好的环境隔离以及独享的内核。

rkt

项目地址：https://github.com/rkt/rkt/ rkt是coreos推出的和Docker抗衡的容器产品，不同于现在的Docker往更大更全的方向，不仅仅是容器功能，更集成了Swarm这样的集群方案，rkt注重的是作为运行在linux系统上的容器组件。上图可以看出Docker的架构要更加的复杂。

docker

官网地址: https://docker.com docker作为Kubernetes的默认容器运行时，其本身在容器领域也占据了绝对的领导地位。

实现了OCI，可以通过cri-o接入kubernetes的项目

runc

项目地址: https://github.com/opencontainers/runc opencontainers组织推出了OCI的规范，同时也开发了runc作为OCI规范的实现。runc是docker贡献出来的容器运行时，runc不仅是containerd的默认运行时，同时也可以接入到cri-o中。

Clear Containers

https://github.com/clearcontainers/runtime，项目已经不在维护，推荐迁移到Kata Containers

Kata Containers

https://github.com/kata-containers/runtime Kata Containers和runc这种技术栈是不同的。runc使用的是linux namespace和cgroup来做环境隔离和资源限制，缺点在于使用的仍然是宿主机的内核，这样一旦受到了内核层的影响，会扩散到所有的容器。而Kata Containers使用的是虚拟化的技术，它实际上是一个虚拟机，但是可以像容器那样使用。 Kata Containers是2017年12月启动的项目，结合了Intel Clear Containers和 Hyper.sh RunV的优点，支持不同的主流架构，除x86_64外，还支持AMD64, ARM, IBM p-series and IBM z-series。 下图是kata Containers和传统容器技术的对比: 主要特点如下：

• 安全性: 使用专用内核，提供了网络、IO和内存的独立，在虚拟化VT扩展的基础上利用硬件强制隔离
• 性能: 提供与标准Linux容器一致的性能；提高隔离度，而无需增加标准虚拟机的性能。
• 兼容性: 支持行业标准，包括OCI容器格式，Kubernetes CRI接口以及旧版虚拟化技术。
• 简单: 消除了在完整的虚拟机内部嵌套容器的要求；标准接口使插入和入门变得容易

下图是Kata Containers的架构: Kubernetes可以通过Hypervisor VSOCK Socket和容器交互。

gVisor

gVisor提供的是一个沙箱容器环境，可以说是传统容器技术和虚拟机容器技术的折中。它使用Go编写了一个可以作为普通非特权进程运行的内核，这个内核实现了大多数的系统调用。所以相比于namespace和cgroup实现的容器，它可以屏蔽掉容器内应用程序的内核调用。相比于虚拟机实现的容器，它更轻量级（作为系统的一个进程运行）。

理解service的角度

这篇文章不是关于如何使用kubernetes中的service，而是尝试整理我自己对service的看法，然后加深对service的理解。那么，我是从哪几个角度去看待service呢？

• service是服务的稳定性保证
• service是集群中的load balance
• 通过无selector的service去理解VIP(虚拟ip)
• service的设计，和不同实现方式的性能

service是服务的稳定性保证

在k8s集群中，无状态的pod副本是可以随时删除、随时创建的，并且重新创建的pod不再保留旧的pod的任何信息，包括ip地址。在这样的情况下，前端应用如何使用后端的这些pod来提供服务就成了问题，因此k8s实现了service这样一个抽象的概念。对于有selector的service，它在被创建的时候会自动创建endpoint资源，这个endpoint中包含了所有的pod的ip和端口，并且在之后的pod的删除、创建中，这个endpoint中会立即更新相关pod的ip和端口信息。同时，service的ip地址是永远固定的，service和endpoint是一一对应的关系。这样，如果前端应用通过固定的service ip来访问pod提供的服务，那么就可以在endpoint中找到一个可用的pod的ip和端口，然后通过一些操作（这个在后面会整理）将数据包转发到指定的pod上即可。

# 你可以通过kubectl查看service和endpoint来加深理解

$ kubectl -n h2o describe svc h2o

Name:              h2o
Namespace:         h2o
Labels:            app=h2o
Annotations:       kubectl.kubernetes.io/last-applied-configuration:
                     {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"labels":{"app":"h2o"},"name":"h2o","namespace":"h2o"},"spec":{"clusterIP...
Selector:          app=h2o
Type:              ClusterIP
IP:                None
Port:              web  54321/TCP
TargetPort:        54321/TCP
Endpoints:         10.42.1.33:54321,10.42.2.139:54321
Session Affinity:  None
Events:            <none>


$ kubectl -n h2o get endpoints h2o
NAME   ENDPOINTS                            AGE
h2o    10.42.1.33:54321,10.42.2.139:54321   4h45m

service通过ip地址的固定来保证服务的稳定性。那为啥service就是可以固定不变的呢？这是因为service本身就是一个抽象的概念啊，它不是一个正在运行的进程，只是一条数据，也正因为如此，它的ip地址和端口号也是不存在的，这些都是存储在etcd中的一条数据。那么k8s是如何通过这样一个虚假的ip和端口将请求转发到真实存在的pod中呢？这就是后面要说的内容了。

service是集群中的load balance

在上一节说到，一个service会对应一个endpoint，这个endpoint中会保存所有当前匹配到的pod的ip和端口号。那么现在有一个http请求过来了，发现endpoint中有三个待选的pod，那么我们使用一定的方式比较公平的选择出一个pod，就轻松的达到了负载均衡的效果。 那么k8s中，load balance的策略是什么样的呢？因为不同的service实现方式使用的方法不同，这个内容会在后面整理。

通过无selector的service去理解VIP(虚拟ip)

在前面的内容中，service一直和endpoint、pod关联在一起，那么如果我们的service没有selector，就不会创建endpoint了，也不会关联pod。前面也提到了service是一个抽象的概念，其拥有的ip和port都是假的。其实这个叫做VIP(virtual ip)。那么，如何通过无selector的service来理解VIP呢？ 在k8s中创建无selector service的时候，不会自动创建关联的endpoint，更不会去匹配pod了。但是这样的service仍然是拥有ip和port的。我们可以尝试一下： svc-without-selector.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
    - protocol: TCP
      port: 8081
      targetPort: 8081

kubectl apply -f svc-without-selector.yaml

查看一下这个svc的详情:

$ kubectl describe svc my-service

Name:              my-service
Namespace:         default
Labels:            <none>
Annotations:       kubectl.kubernetes.io/last-applied-configuration:
                     {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"my-service","namespace":"default"},"spec":{"ports":[{"port":8081,...
Selector:          <none>
Type:              ClusterIP
IP:                10.43.12.208
Port:              <unset>  8081/TCP
TargetPort:        8081/TCP
Endpoints:         <none>
Session Affinity:  None
Events:            <none>

除了拥有ip和端口号，就什么都没有了。这就是说service为什么就是一条数据的原因，10.43.12.208也就是一个VIP。 对于无selector的service还有一个用处，就是让集群内部的应用可以稳定的访问到集群外部的服务。因为service是稳定的，那么集群内部都可以访问这个service，然后让这个service将请求转发到集群外。 这里我们可以手动创建一个endpoint，这个endpoint包含了集群外的两个http服务

apiVersion: v1
kind: Endpoints
metadata:
  name: my-service
subsets:
  - addresses:
      - ip: 192.168.50.99
      - ip: 192.168.50.201
    ports:
      - port: 8081

然后我们先检查一下service，发现endpoints已经更新了。

$ kubectl describe svc my-service

Name:              my-service
Namespace:         default
Labels:            <none>
Annotations:       kubectl.kubernetes.io/last-applied-configuration:
                     {"apiVersion":"v1","kind":"Service","metadata":{"annotations":{},"name":"my-service","namespace":"default"},"spec":{"ports":[{"port":8081,...
Selector:          <none>
Type:              ClusterIP
IP:                10.43.12.208
Port:              <unset>  8081/TCP
TargetPort:        8081/TCP
Endpoints:         192.168.50.201:8081,192.168.50.99:8081
Session Affinity:  None
Events:            <none>

我们在集群内部访问一下(使用kubectl exec到一个pod上):

$ wget my-service:8081 -q -O out | cat out
server 2
$ wget my-service:8081 -q -O out | cat out
server 1
$ wget my-service:8081 -q -O out | cat out
server 2
$ wget my-service:8081 -q -O out | cat out
server 1

service的设计，和不同实现方式的性能

service的设计是以提高性能为前提不断的演进的，这里是关于Service的设计讨论: DESIGN: Services v2。感兴趣的还可以看看k8s-release-v1.0的时候对service的描述: Service service的设计中有4个角色: Pod、 Service、Ambassador、Portal

• Pod: k8s集群中的最小调度单位，包含一个或多个容器
• Service: 一组pod的集合，由标签选择器来关联
• Ambassador: 中文翻译是大使，是一段可执行的逻辑，它负责实现客户端访问Service，然后将请求转发到一个对应的Pod上。这个Ambassador可以是一个云服务商的服务，也可以是一个单独的pod(比如haproxy)，或者是每个节点都有的共享进程(kube-proxy)。
• Portal: 固定的ip:port对，客户端只要访问这个Portal，请求自然会被转发到Ambassador上，客户端不需要理解Ambassador的具体实现。

最初的设计中是有三种方案， 方案一: 每个服务一个ip，共享的Ambassador。这个ip就是上面说的Portal ip。将服务以及ip、端口广播给所有的kube-proxy实例。kube-proxy设置好iptables来“窃取”所有到Portal(ip,port)的请求，然后将这个请求转发到自己的某个端口上。这里kube-proxy扮演的是Ambassador角色，它会使用round-robin的方法来把请求均衡的分发到Service后面的Pod上。这个方案里，有以下的优点和缺点： 优点： - 不会有端口冲突 - Service的ip和port都是固定的，方便做DNS A (forward) 和 PTR (reverse)和 SRV 记录。 - iptables可以放在root namespace，即使pods重启了也不需要更新iptables(这是因为iptables是负责将到service ip:port的流量转发到kube-proxy的一个端口上即可)。 - 不需要在pod上预先声明需要的Service。 缺点：

• kube-proxy是多租户的(需要为所有的service做流量转发)
• 从kube-proxy转发的流量的源ip不是真实的源ip，
• 需要为portal预留虚拟ip空间
• 需要master跟踪和检查所有的portal ip
• 当service数量级上千后可扩展性不高

方案二： 每个服务一个ip，私有的Ambassador。对每个pod来说，都有一个_私有_的的ambassador，这要求pod需要先声明它们想先访问那个服务（否则的话，对于集群中的每次Service的添加和删除，都需要kubelet或其他的root-namespace、true-root的用户代理变动到每个pod的namespace下。[iptables规则需要root用户])，这样才能在pod的命名空间下建立iptables规则。 优点:

• 不会有端口冲突
• Service的ip和port都是固定的，方便做DNS A (forward) 和 PTR (reverse)和 SRV 记录。
• 代理不是多租户的
• 从kube-proxy转发的流量的源ip是真实的源ip，
• 容易从方案一迁移
• 需要pod预先声明服务（结构良好)

缺点:

• iptables是配置在pod的namespace下，但是pod的命名空间重启了就必须重新运行一次
• 需要为portal预留虚拟ip空间
• 需要master跟踪和检查所有的portal ip
• 需要pod预先声明服务（目前还没实现）

方案三：localhost的portal，私有的ambassador 不同于给service分配ip，而是使用本地的端口号作为portal。 介绍完这三种方案后，就可以引入service最终的演进了: userspace->iptables->ipvs。 这里先放一张iptables的工作流程图，方便理解： userspace模式 这里的userspace就是方案一的实现，在k8s 1.0的发布中正式启用。userspace的工作原理图如下： 这种模式，kube-proxy 会监视 Kubernetes master 对 Service 对象和 Endpoints 对象的添加和移除。 对每个 Service，它会在本地 Node 上打开一个端口（随机选择）。 任何连接到“代理端口”的请求，都会被代理到 Service 的backend Pods 中的某个上面（如 Endpoints 所报告的一样）。 使用哪个 backend Pod，是 kube-proxy 基于 SessionAffinity 来确定的。 最后，它安装 iptables 规则，捕获到达该 Service 的 clusterIP（是虚拟 IP）和 Port 的请求，并重定向到代理端口，代理端口再代理请求到 backend Pod。默认情况下，用户空间模式下的kube-proxy通过round-robin选择后端。 这里有一个问题在于，client访问service的clusterIP时，iptables会把流量转发到kube-proxy的某个端口上，这样的话，每次转发都有一个内核态到用户态的转换。 iptables模式 这种模式，kube-proxy 会监视 Kubernetes 控制节点对 Service 对象和 Endpoints 对象的添加和移除。 对每个 Service，它会安装 iptables 规则，从而捕获到达该 Service 的 clusterIP 和端口的请求，进而将请求重定向到 Service 的一组 backend 中的某个上面。 对于每个 Endpoints 对象，它也会安装 iptables 规则，这个规则会选择一个 backend 组合。 默认的策略是，kube-proxy 在 iptables 模式下随机选择一个 backend。类似于这样

iptables -t nat -A PREROUTING -p tcp -d 15.45.23.67 --dport 80 -j DNAT --to-destination 192.168.1.1-192.168.1.10

使用 iptables 处理流量具有较低的系统开销，因为流量由 Linux netfilter 处理，而无需在用户空间和内核空间之间切换。 这种方法也可能更可靠。 如果 kube-proxy 在 iptable s模式下运行，并且所选的第一个 Pod 没有响应，则连接失败。 这与用户空间模式不同：在这种情况下，kube-proxy 将检测到与第一个 Pod 的连接已失败，并会自动使用其他后端 Pod 重试。 您可以使用 Pod readiness 探测器 验证后端 Pod 可以正常工作，以便 iptables 模式下的 kube-proxy 仅看到测试正常的后端。 这样做意味着您避免将流量通过 kube-proxy 发送到已知已失败的Pod。 ipvs模式 ipvs是在Kubernetes v1.11正式可用的。ipvs也是依赖于iptables的，但是它的性能更高。 在ipvs模式下，kube-proxy监视Kubernetes服务和端点，调用netlink接口相应地创建IPVS规则，并定期将IPVS规则与Kubernetes服务和端点同步。该控制循环可确保IPVS状态与所需状态匹配。访问服务时，IPVS　将流量定向到后端Pod之一。 IPVS代理模式基于类似于iptables模式的netfilter挂钩函数，但是使用哈希表作为基础数据结构，并且在内核空间中工作。 这意味着，与iptables模式下的 kube-proxy 相比，IPVS 模式下的 kube-proxy 重定向通信的延迟要短，并且在同步代理规则时具有更好的性能。与其他代理模式相比，IPVS 模式还支持更高的网络流量吞吐量。 IPVS提供了更多选项来平衡后端Pod的流量。 这些是：

• rr: round-robin
• lc: least connection (smallest number of open connections)
• dh: destination hashing
• sh: source hashing
• sed: shortest expected delay
• nq: never queue

注意： 要在IPVS模式下运行kube-proxy，必须在启动kube-proxy之前使IPVS Linux在节点上可用。 当 kube-proxy 以 IPVS 代理模式启动时，它将验证 IPVS 内核模块是否可用。 如果未检测到 IPVS 内核模块，则 kube-proxy 将退回到以 iptables 代理模式运行。

ipvs在同步规则、网络带宽、cpu/内存消耗上都明显优于iptables，关于具体的性能数据可以看这篇文章: 华为云在 K8S 大规模场景下的 Service 性能优化实践。ipvs的详细介绍可以看这篇文章:ipvs 基本介绍。ipvs和iptables的对比:kube-proxy 模式对比：iptables 还是 IPVS？

感谢打赏～ 微信付款码 支付宝付款码

问题

在开发可视化机器学习平台时，集成的FastRCNN实验一直跑不到结束就会出错。有时候是在下载基础模型以及代码包时出错，有时候在train结束后向predict传递artifacts出错。

过程

首先这个问题出现在局域网内，处于开发环境，因此ceph没有做高可用的部署。其次，ceph是用rook这个项目部署在k8s集群中的。 最后，在使用argo做机器学习的资源调度时，会出现大的数据资源下载和转移出现错误。具体表现为：大量数据下载会出现connectiion refused,日志如下：

2019-10-25 02:35:24 (20.1 MB/s) - Connection closed at byte 528482304. Retrying.
--2019-10-25 02:35:25--  (try: 2)  http://rook-ceph-rgw-my-store.rook-ceph/workflow-storage/tho6wHm0UmZeZYbfWBv5lkOZ576838763
Connecting to rook-ceph-rgw-my-store.rook-ceph (rook-ceph-rgw-my-store.rook-ceph)|10.43.126.166|:80... failed: Connection refused.
Resolving rook-ceph-rgw-my-store.rook-ceph (rook-ceph-rgw-my-store.rook-ceph)... 10.43.126.166
Connecting to rook-ceph-rgw-my-store.rook-ceph (rook-ceph-rgw-my-store.rook-ceph)|10.43.126.166|:80... failed: Connection refused.

大量数据上传时也会中断，导致argo无法调用下一步： 日志如下：

NAME            custom-workflow-43-6rhlb.api-train-faster-1699
TYPE            Pod
PHASE           Error
MESSAGE         failed to save outputs: timed out waiting for the condition
START TIME      2019-10-24T06:15:56Z
END TIME        2019-10-24T06:30:34Z
DURATION        14:38 min

这里可能是网络问题，argo的问题或者是ceph的问题。但是当数据量不大的时候不会出现错误。因此检查ceph是否正常

~ » kubectl -n rook-ceph get pods                                                
NAME                                           READY   STATUS      RESTARTS   AGE
csi-cephfsplugin-964zm                         3/3     Running     27         46d
csi-cephfsplugin-dxnbg                         3/3     Running     12         46d
csi-cephfsplugin-provisioner-b66d48bc8-fglq9   4/4     Running     0          12d
csi-cephfsplugin-provisioner-b66d48bc8-x67pd   4/4     Running     0          12d
csi-rbdplugin-5fs2x                            3/3     Running     27         46d
csi-rbdplugin-bddlt                            3/3     Running     12         46d
csi-rbdplugin-provisioner-95dd85d6-7kc4c       5/5     Running     0          12d
csi-rbdplugin-provisioner-95dd85d6-mpjtj       5/5     Running     0          12d
rook-ceph-agent-fs4xq                          1/1     Running     9          46d
rook-ceph-agent-wx6r4                          1/1     Running     4          46d
rook-ceph-mds-myfs-a-774974c8c4-xt2ls          1/1     Running     0          12d
rook-ceph-mds-myfs-b-748d7d7f7d-wftt5          1/1     Running     0          12d
rook-ceph-mgr-a-5f54d44c98-57qcb               1/1     Running     0          12d
rook-ceph-mon-a-6f9fbfc99d-lmb6c               1/1     Running     0          17d
rook-ceph-operator-6f556bcbff-glvt6            1/1     Running     0          12d
rook-ceph-osd-0-7c489dc87b-wkt7x               1/1     Running     0          17d
rook-ceph-osd-1-86cc67cc45-25h4q               1/1     Running     0          12d
rook-ceph-osd-prepare-worknode1-xnmpw          0/1     Completed   0          12d
rook-ceph-rgw-my-store-a-66b7d8cc9d-vrhkm      1/1     Running     65         12d
rook-ceph-tools-5f5dc75fd5-52jbj               1/1     Running     0          12d
rook-discover-g95ws                            1/1     Running     6          46d
rook-discover-vs5fs                            1/1     Running     13         46d

发现ceph rgw重启了65次，这个肯定是不正常的。查看ceph rgw的日志:

$ kubectl -n rook-ceph logs -p rook-ceph-rgw-my-store-a-66b7d8cc9d-vrhkm

# 截取了一部分日志
debug 2019-10-25 02:35:13.473 7f4880b98700  1 ====== starting new request req=0x55aa678c48e0 =====
debug 2019-10-25 02:35:14.549 7f4880b98700  0 ERROR: client_io->complete_request() returned Broken pipe
debug 2019-10-25 02:35:14.549 7f4880b98700  1 ====== req done req=0x55aa678c48e0 op status=0 http_status=200 latency=1.076s ======
debug 2019-10-25 02:35:19.949 7f48e345d700  1 ====== starting new request req=0x55aa54a488e0 =====
debug 2019-10-25 02:35:19.949 7f48e345d700  1 ====== req done req=0x55aa54a488e0 op status=0 http_status=404 latency=0s ======

在我的理解中broken pipe一般出现在向已关闭的连接中写入数据时，会出现这个问题。但是通过日志可以发现，出现broken pipe的错误之后，rgw仍然是在处理请求的，但是部分请求的latency很高。因此这里的broken pipe是表示着rgw开始出现一些异常情况，但不是pod重启的直接原因。 真正导致rgw被杀死的原因是因为rgw进程收到了sigterm信号，然后进程被杀死。

debug 2019-10-25 02:35:24.525 7f494c52f700 -1 received  signal: Terminated from Kernel ( Could be generated by pthread_kill(), raise(), abort(), alarm() ) UID: 0
debug 2019-10-25 02:35:24.525 7f494c52f700  1 handle_sigterm
debug 2019-10-25 02:35:24.525 7f494c52f700  1 handle_sigterm set alarm for 120
debug 2019-10-25 02:35:24.525 7f4962116780 -1 shutting down
debug 2019-10-25 02:35:24.629 7f488cbb0700  0 iterate_obj() failed with -9

使用kubectl describe查看pod的event:

Events:
  Type     Reason     Age                  From                Message
  ----     ------     ----                 ----                -------
  Normal   Killing    15m (x65 over 12d)   kubelet, worknode1  Container rgw failed liveness probe, will be restarted
  Warning  Unhealthy  15m (x249 over 12d)  kubelet, worknode1  Liveness probe failed: Get http://10.42.2.44:80/: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
  Normal   Pulled     15m (x66 over 12d)   kubelet, worknode1  Container image "ceph/ceph:v14.2.2-20190826" already present on machine
  Normal   Created    15m (x66 over 12d)   kubelet, worknode1  Created container rgw
  Normal   Started    15m (x66 over 12d)   kubelet, worknode1  Started container rgw

这里才是真正的重启原因，kubelet检查pod是否存活，但是请求超时了。意味pods出现的故障，因此杀死了pod并重启。 pod的liveness设置:

Liveness:       http-get http://:80/ delay=10s timeout=1s period=10s #success=1 #failure=3

k8s的liveness机制是检查pod中应用程序存活状态并在出错后自动重启的一种机制。提供了三种方式：

• 在容器内执行命令，如果执行成功，则表示容器是存活并且健康的。否则就重启容器使得应用程序恢复正常。
• 使用http请求检查，如果返回的状态码是200则表示正常，否则表示失败。
• 使用tcp连接检查，如果kubelet可以打开指定端口的socket连接，则表示正常，否则表示失败。

在这个场景下出现Warning Unhealthy 15m (x249 over 12d) kubelet, worknode1 Liveness probe failed: Get http://10.42.2.44:80/: net/http: request canceled (Client.Timeout exceeded while awaiting headers)，表示kubelet使用http get检查pod的80端口，但是这个请求却超时了。因此杀死了容器并重启，导致大文件(700MB以上)上传/下载失败。 这里kubelet检查的是http://10.42.2.44:80这个地址，我们回过头看一下argo那边的报错信息，Connecting to rook-ceph-rgw-my-store.rook-ceph (rook-ceph-rgw-my-store.rook-ceph)|10.43.126.166|:80... failed: Connection refused.。都是80端口，当然这里千万不能被ip地址误导了，10.42.2.44是pod的ip地址，10.43.126.166是service的ip地址，我们可以验证一下:

~ » kubectl -n rook-ceph get svc                                                 
NAME                              TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)             AGE
rook-ceph-rgw-my-store            ClusterIP   10.43.126.166   <none>        80/TCP              46d

然后再结合之前debug 2019-10-25 02:35:14.549 7f4880b98700 1 ====== req done req=0x55aa678c48e0 op status=0 http_status=200 latency=1.076s ======这条日志，latency已经超过了1s，而kubelet的liveness超时时间是1s。 现在基本可以得出以下异常流程:

1. 因为某些原因，导致rgw出现broken pipe的出错，并且部分请求的lantency时间大大提高。
2. kubelet周期性的对rgw做liveness的检查，并且检查的http就是rgw的80端口，这个端口因为上面的原因导致lantency超过了1s，而liveness检查的timeout只有1s。因此kubelet认为该pod不健康，选择重启。
3. kubelet向rgw发送了sigterm信号，rgw关闭进程，pod重启。

猜测可能造成这个问题的原因:

1. ceph所在机器的性能不够，导致响应请求出现问题。
2. 局域网的网络问题，因为内部的最高带宽只有10MB/s，但是局域网内的设备很多，网络这部分导致了瓶颈。

关于机器性能的问题，我认为是可以排除的，因为机器性能本身很好，并且开发环境几乎没有请求量，接下来就是验证是因为网络问题导致瓶颈，造成部分接口延迟过高被杀死。 为了验证这个猜想，假设这里有三台机器A,B,C，组成了一个k8s集群，ceph是部署在k8s之上的。在A之上，我用dd命令产生一个40G的大文件，然后在B之上使用wget下载。然后在C上面观察ping的延迟是否上升。 A:

$ dd if=/dev/zero of=test bs=1M count=0 seek=40000

$ python -m SimpleHTTPServer 8999

B:

$ wget http://192.168.50.37:8999/test

--2019-10-25 14:18:30--  http://192.168.50.37:8999/test
正在连接 192.168.50.37:8999... 已连接。
已发出 HTTP 请求，正在等待回应... 200 OK
长度： 41943040000 (39G) [application/octet-stream]
正在保存至: “test”

test      3%[==>            ]   1.54G  11.1MB/s    剩余 73m 5s

C:

$ ping 192.168.50.37
PING 192.168.50.37 (192.168.50.37) 56(84) bytes of data.
64 bytes from 192.168.50.37: icmp_seq=1 ttl=64 time=0.384 ms
64 bytes from 192.168.50.37: icmp_seq=2 ttl=64 time=0.373 ms
64 bytes from 192.168.50.37: icmp_seq=3 ttl=64 time=0.336 ms
64 bytes from 192.168.50.37: icmp_seq=4 ttl=64 time=4.90 ms
64 bytes from 192.168.50.37: icmp_seq=5 ttl=64 time=1.18 ms
64 bytes from 192.168.50.37: icmp_seq=6 ttl=64 time=7.74 ms
64 bytes from 192.168.50.37: icmp_seq=7 ttl=64 time=3.51 ms
64 bytes from 192.168.50.37: icmp_seq=8 ttl=64 time=6.66 ms
64 bytes from 192.168.50.37: icmp_seq=9 ttl=64 time=6.31 ms

网络延迟增加的还是很明显的。 这时候使用argo开始一个新的机器学习的实验，但是这个实验的数据量较小，在之前的使用中都没有问题。结果确实出现了问题：

2019-10-25 06:21:04 (8.10 MB/s) - Connection closed at byte 136314880. Retrying.
--2019-10-25 06:21:05--  (try: 2)  http://rook-ceph-rgw-my-store.rook-ceph/workflow-storage/maC8Om6Y3QbSJxSTT9x82rp8908272441
Connecting to rook-ceph-rgw-my-store.rook-ceph (rook-ceph-rgw-my-store.rook-ceph)|10.43.126.166|:80... failed: Connection refused.
Resolving rook-ceph-rgw-my-store.rook-ceph (rook-ceph-rgw-my-store.rook-ceph)... 10.43.126.166
Connecting to rook-ceph-rgw-my-store.rook-ceph (rook-ceph-rgw-my-store.rook-ceph)|10.43.126.166|:80... failed: Connection refused.

那么为了有对照实验，将下载关闭，重新做这个机器学习的实验，结果正常。

解决方法

因为缺少了对ceph这块源代码的研究，上面的结论并不一定正确。但是可以大概得出如何解决，可以先尝试将liveness检测的timeout时间增加。

kubectl -n rook-ceph edit deployment rook-ceph-rgw-my-store-a

把liveness的timeout时间调成5s，这样就解决了这个问题。

理解context

在我刚接触context包时，我是有一点迷惑的。因为在其他的编程语言中很少有接触到context包类似的用法。比如在js绘制canvas中的context，也只是作为保留上下文操作来用的。在go语言的context包中，同样也可以当成上下文来理解，但是在看待context提供的能力时，要从以下两点来理解：

• context提供了一种管理多个goroutine的机制。
• context最终形成了一种树形结构。

在深入之前，让我们回忆一下多线程/进程模型中，主线程/进程是如何管理子线程/进程的。如果子线程/进程又派生了其他的线程/进程呢？这一定是一个头疼的问题。 在go语言中，协程也面临了同样的问题。因此官方在go1.7版本中引入了context包。那么context提供了什么样的能力来管理协程呢？先看一个withCancel的简单的例子

func watch(ctx context.Context) {
    for {
        select {
        case <-ctx.Done():
            log.Println("退出")
            return

        default:
            log.Println("执行逻辑")
            time.Sleep(2 * time.Second)
        }
    }
}

func withCancel() {
    ctx, cancel := context.WithCancel(context.Background())

    go watch(ctx)
    go watch(ctx)
    go watch(ctx)

    time.Sleep(6 * time.Second)
    fmt.Println("可以了，通知子协程停止")
    cancel()
    //为了检测子协程是否停止，如果没有输出，就表示停止了
    time.Sleep(5 * time.Second)
}

调用withCancel的输出如下:

2019/09/30 00:18:48 执行逻辑
2019/09/30 00:18:48 执行逻辑
2019/09/30 00:18:48 执行逻辑
2019/09/30 00:18:50 执行逻辑
2019/09/30 00:18:50 执行逻辑
2019/09/30 00:18:50 执行逻辑
2019/09/30 00:18:52 执行逻辑
2019/09/30 00:18:52 执行逻辑
2019/09/30 00:18:52 执行逻辑
可以了，通知子协程停止
2019/09/30 00:18:54 退出
2019/09/30 00:18:54 退出
2019/09/30 00:18:54 退出

可以看到，我们通过context.WithCancel方法生成了一个ctx和一个cancel，然后主动调用cancel就可以通过所有的子协程退出了。在watch方法的实现中，我们是通过select机制来实现的，一旦context的Done()方法有值，就会调用return退出，否则的话就执行default中我们的业务逻辑。 这样我们就可以随时通知所有的子协程退出了。在上面说到，context最终形成了一种树形结构，是因为在子协程中也可以继续使用新的协程，这样就形成了一个树形的调用了。 我们在1中使用cancel方法，就可以向下传播，在2~10号协程中全部退出。 简单的了解context包的使用后，可以看一下context.Context这个接口，为了简洁，我删除了源代码中的注释。

type Context interface {
    Deadline() (deadline time.Time, ok bool)
    Done() <-chan struct{}
    Err() error
    Value(key interface{}) interface{}
}

Context接口总共提供了4个方法。

• Deadline()用来获取当前context的取消时间，第二个返回值ok等于false的时候，表示没有设置。
• Done()方法返回了一个chan，当chan中读取到值的时候，表示父context已经发起了取消的请求，那么当前协程开始做相关的清理工作然后退出。
• Err()返回context的取消原因
• Value()方法用来通过一个key获取当前Context上与之对应的值。

理解Context的树形结构

go中大量的库都使用了context机制，比如database/sql库，net/http库等等，因为这些库都支持了context，使得我们在程序中很容易通过context来管理所有新建的协程，而不用自己实现复杂的机制来管理。一旦我们需要取消，只需要在root context调用cancel方法即可。

一些基本使用

在上面的例子中，我们使用了withCancel来实例化一个可以手动取消的context。context包中同样提供了一些其他的方法。

func WithDeadline(parent Context, d time.Time) (Context, CancelFunc)
func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc)

WithDeadline可以设置截止时间。会到达指定时间时自动取消。当然也可以调用CancelFunc来手动取消。 WithTimeout可以设置在一段时间后自动取消，和WithDeadline类似。

参考

Go语言实战笔记(二十) Golang Context深入理解 Go Concurrency Patterns: context

一、概述

在etcd的clientv3包中，实现了分布式锁。使用起来和mutex是类似的，为了了解其中的工作机制，这里简要的做一下总结。

二、使用方式

etcd分布式锁的实现在go.etcd.io/etcd/clientv3/concurrency包中，主要提供了以下几个方法：

• func NewMutex(s *Session, pfx string) *Mutex， 用来新建一个mutex
• func (m *Mutex) Lock(ctx context.Context) error，它会阻塞直到拿到了锁，并且支持通过context来取消获取锁。
• func (m *Mutex) Unlock(ctx context.Context) error，解锁

因此在使用etcd提供的分布式锁式非常简单，通常就是实例化一个mutex，然后尝试抢占锁，之后进行业务处理，最后解锁即可。 一个简单的例子如下：

package main

import (
    "context"
    "github.com/coreos/etcd/clientv3"
    "github.com/coreos/etcd/clientv3/concurrency"
    "log"
    "sync"
    "time"
)

var n = 0

// 使用worker模拟锁的抢占
func worker(key string) error {
    endpoints := []string{"127.0.0.1:2379"}

    cfg := clientv3.Config{
        Endpoints:            endpoints,
        DialTimeout:          3 * time.Second,
    }

    cli, err := clientv3.New(cfg)
    if err != nil {
        log.Println("new cli error:", err)
        return err
    }

    sess, err := concurrency.NewSession(cli)
    if err != nil {
        return err
    }

    m := concurrency.NewMutex(sess, "/"+key)

    err = m.Lock(context.TODO())
    if err != nil {
        log.Println("lock error:", err)
        return err
    }

    defer func() {
        err = m.Unlock(context.TODO())
        if err != nil {
            log.Println("unlock error:", err)
        }
    }()

    log.Println("get lock: ", n)
    n++
    time.Sleep(time.Second) // 模拟执行代码


    return nil
}

func main() {
    var wg sync.WaitGroup
    wg.Add(3)
    go func() {
        defer wg.Done()
        err := worker("lockname")
        if err != nil {
            log.Println(err)
        }
    }()


    go func() {
        defer wg.Done()
        err := worker("lockname")
        if err != nil {
            log.Println(err)
        }
    }()

    go func() {
        defer wg.Done()
        err := worker("lockname")
        if err != nil {
            log.Println(err)
        }
    }()

    wg.Wait()
}

三、实现机制

Lock()函数的实现很简单。这里可以贴出来看一下：

// Lock locks the mutex with a cancelable context. If the context is canceled
// while trying to acquire the lock, the mutex tries to clean its stale lock entry.
func (m *Mutex) Lock(ctx context.Context) error {
    s := m.s
    client := m.s.Client()

    m.myKey = fmt.Sprintf("%s%x", m.pfx, s.Lease())
    cmp := v3.Compare(v3.CreateRevision(m.myKey), "=", 0)
    // put self in lock waiters via myKey; oldest waiter holds lock
    put := v3.OpPut(m.myKey, "", v3.WithLease(s.Lease()))
    // reuse key in case this session already holds the lock
    get := v3.OpGet(m.myKey)
    // fetch current holder to complete uncontended path with only one RPC
    getOwner := v3.OpGet(m.pfx, v3.WithFirstCreate()...)
    resp, err := client.Txn(ctx).If(cmp).Then(put, getOwner).Else(get, getOwner).Commit()
    if err != nil {
        return err
    }
    m.myRev = resp.Header.Revision
    if !resp.Succeeded {
        m.myRev = resp.Responses[0].GetResponseRange().Kvs[0].CreateRevision
    }
    // if no key on prefix / the minimum rev is key, already hold the lock
    ownerKey := resp.Responses[1].GetResponseRange().Kvs
    if len(ownerKey) == 0 || ownerKey[0].CreateRevision == m.myRev {
        m.hdr = resp.Header
        return nil
    }

    // wait for deletion revisions prior to myKey
    hdr, werr := waitDeletes(ctx, client, m.pfx, m.myRev-1)
    // release lock key if wait failed
    if werr != nil {
        m.Unlock(client.Ctx())
    } else {
        m.hdr = hdr
    }
    return werr
}

首先通过一个事务来尝试加锁，这个事务主要包含了4个操作: cmp、put、get、getOwner。需要注意的是，key是由pfx和Lease()组成的。

• cmp: 比较加锁的key的修订版本是否是0。如果是0就代表这个锁不存在。
• put: 向加锁的key中存储一个空值，这个操作就是一个加锁的操作，但是这把锁是有超时时间的，超时的时间是session的默认时长。超时是为了防止锁没有被正常释放导致死锁。
• get: get就是通过key来查询
• getOwner: 注意这里是用m.pfx来查询的，并且带了查询参数WithFirstCreate()。使用pfx来查询是因为其他的session也会用同样的pfx来尝试加锁，并且因为每个LeaseID都不同，所以第一次肯定会put成功。但是只有最早使用这个pfx的session才是持有锁的，所以这个getOwner的含义就是这样的。

接下来才是通过判断来检查是否持有锁

m.myRev = resp.Header.Revision
if !resp.Succeeded {
    m.myRev = resp.Responses[0].GetResponseRange().Kvs[0].CreateRevision
}
// if no key on prefix / the minimum rev is key, already hold the lock
ownerKey := resp.Responses[1].GetResponseRange().Kvs
if len(ownerKey) == 0 || ownerKey[0].CreateRevision == m.myRev {
    m.hdr = resp.Header
    return nil
}

m.myRev是当前的版本号，resp.Succeeded是cmp为true时值为true，否则是false。这里的判断表明当同一个session非第一次尝试加锁，当前的版本号应该取这个key的最新的版本号。 下面是取得锁的持有者的key。如果当前没有人持有这把锁，那么默认当前会话获得了锁。或者锁持有者的版本号和当前的版本号一致， 那么当前的会话就是锁的持有者。

// wait for deletion revisions prior to myKey
hdr, werr := waitDeletes(ctx, client, m.pfx, m.myRev-1)
// release lock key if wait failed
if werr != nil {
    m.Unlock(client.Ctx())
} else {
    m.hdr = hdr
}

上面这段代码就很好理解了，因为走到这里说明没有获取到锁，那么这里等待锁的删除。

// waitDeletes efficiently waits until all keys matching the prefix and no greater
// than the create revision.
func waitDeletes(ctx context.Context, client *v3.Client, pfx string, maxCreateRev int64) (*pb.ResponseHeader, error) {
    getOpts := append(v3.WithLastCreate(), v3.WithMaxCreateRev(maxCreateRev))
    for {
        resp, err := client.Get(ctx, pfx, getOpts...)
        if err != nil {
            return nil, err
        }
        if len(resp.Kvs) == 0 {
            return resp.Header, nil
        }
        lastKey := string(resp.Kvs[0].Key)
        if err = waitDelete(ctx, client, lastKey, resp.Header.Revision); err != nil {
            return nil, err
        }
    }
}

waitDeletes方法的实现也很简单，但是需要注意的是，这里的getOpts只会获取比当前会话版本号更低的key，然后去监控最新的key的删除。等这个key删除了，自己也就拿到锁了。 这种分布式锁的实现和我一开始的预想是不同的。它不存在锁的竞争，不存在重复的尝试加锁的操作。而是通过使用统一的前缀pfx来put，然后根据各自的版本号来排队获取锁。效率非常的高。 如图所示，共有4个session来加锁，那么根据revision来排队，获取锁的顺序为session2 -> session3 -> session1 -> session4。 当然，这里为什么可以通过revision来判定获取锁的顺序，就需要更深入的了解etcd的内部机制以及raft协议了。