发表于 |

背景

在部署应用时想要应用是高可用，通常会在应用前放置一个 HAProxy，当任何一个 Server 故障，HAProxy 会自动切换，但是 HAProxy 也存在单点故障，因此需要多个 HAProxy 来保证业务不中断，这时候我们需要另一个软件配合：Keepalived。通常我用 Keepalived 仅用来提供 VIP，保证当一个 Keepalived 故障，VIP 自动在其他 Keepalived 节点配置。

Keepalived 有一个问题是 virtual route ID 必须是同一网段内唯一的，当我们想要在一个网段内部署多个集群时，就需要人为的介入去分配 virtual route ID，不方便。这次来使用 Raft 自己实现 VIP 逻辑。

hashicorp/raft

Raft 有很多开源实现，其中 Hashicorp 实现的 Raft 库 已经被 Consul 等软件使用，且接口友善，选择使用它来实现。在 Github 上有很多 Raft 的使用示例，比较简单且完整的是 otoolep/hraftd，我们来看看他是怎么使用的。

otoolep/hraftd

main.go

在 main.go 中主要做了 4 件事情：store.New, store.Open, http.New, http.Start，先来看看程序是如何启动的：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
func init() {
    // 设置命令行参数
	flag.BoolVar(&inmem, "inmem", false, "Use in-memory storage for Raft")
	...
	flag.Usage = func() {
		fmt.Fprintf(os.Stderr, "Usage: %s [options] <raft-data-path> \n", os.Args[0])
		flag.PrintDefaults()
	}
}

func main() {
    // 解析命令行参数
	flag.Parse()
    ...
    // 创建一个 Store 对象
	s := store.New(inmem)
	s.RaftDir = raftDir
    s.RaftBind = raftAddr
    // 运行 Store 
	if err := s.Open(joinAddr == "", nodeID); err != nil {
		log.Fatalf("failed to open store: %s", err.Error())
	}
    // 新建一个 http 对象并运行
	h := httpd.New(httpAddr, s)
	if err := h.Start(); err != nil {
		log.Fatalf("failed to start HTTP service: %s", err.Error())
	}

	// 如果 joinAddr 参数不为空，则处理 join 请求
	if joinAddr != "" {
		if err := join(joinAddr, raftAddr, nodeID); err != nil {
			log.Fatalf("failed to join node at %s: %s", joinAddr, err.Error())
		}
	}

	log.Println("hraftd started successfully")
    // 监听系统信号，若接收到 os.Interrupt 则程序退出
	terminate := make(chan os.Signal, 1)
	signal.Notify(terminate, os.Interrupt)
	<-terminate
	log.Println("hraftd exiting")
}

http

看了 main.go 我们知道调用了 http.Start， 先不管 Store 是什么，先来看看 http 相关实现：

1
2
3
4
5
6
7
8
// Start starts the service.
func (s *Service) Start() error {
    // Service 实现了 ServeHTTP 方法
	http.Handle("/", s)
	go func() {
		err := server.Serve(s.ln)
    ...
}
1
2
3
4
5
func (s *Service) ServeHTTP(w http.ResponseWriter, r *http.Request) {
	if strings.HasPrefix(r.URL.Path, "/key") {
		s.handleKeyRequest(w, r)
    // 先忽略其他分支
}

主要处理请求的是 s.handleKeyRequest 方法：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
func (s *Service) handleKeyRequest(w http.ResponseWriter, r *http.Request) {
	...
	switch r.Method {
	case "GET":
		k := getKey()
		if k == "" {
			w.WriteHeader(http.StatusBadRequest)
		}
		v, err := s.store.Get(k)
		...
		io.WriteString(w, string(b))
	case "POST":
		// Read the value from the POST body.
		m := map[string]string{}
		if err := json.NewDecoder(r.Body).Decode(&m); err != nil {
			w.WriteHeader(http.StatusBadRequest)
			return
		}
		for k, v := range m {
			if err := s.store.Set(k, v); err != nil {
				w.WriteHeader(http.StatusInternalServerError)
				return
			}
        }
    ...

在 s.handleKeyRequest 中根据请求方法，去调用 store 对应的方法，那么 store 实现了哪些接口呢？这也是在 http 模块中定义的：

1
2
3
4
5
6
type Store interface {
	Get(key string) (string, error)
	Set(key, value string) error
	Delete(key string) error
	Join(nodeID string, addr string) error
}

除了 Join 看着比较奇怪，其他的都是一个 K/V 系统该有的接口，接下来就看看 Store 具体方法的实现。

store

这个模块的编写涉及到了 Raft 中的具体概念，建议先阅读 siddontang 写的 Raft 相关博客快速了解（链接在参考链接列出）。

以下以设置 Key 为例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
func (s *Store) Set(key, value string) error {
	if s.raft.State() != raft.Leader {
		return fmt.Errorf("not leader")
	}

    // 封装具体执行的动作
	c := &command{
		Op:    "set",
		Key:   key,
		Value: value,
	}
	b, err := json.Marshal(c)
    ...
    // 将 command 应用于 FSM
	f := s.raft.Apply(b, raftTimeout)
	return f.Error()
}

查看 FSM Apply 方法实现：

1
2
3
4
5
6
7
8
9
10
// Apply applies a Raft log entry to the key-value store.
func (f *fsm) Apply(l *raft.Log) interface{} {
	var c command
	// 根据操作动作的不同，执行不同的方法，这里以设置 Key 为例
	switch c.Op {
	case "set":
		return f.applySet(c.Key, c.Value)
	...
	}
}

1
2
3
4
5
6
7
8
func (f *fsm) applySet(key, value string) interface{} {
    // 互斥锁
    f.mu.Lock()
    defer f.mu.Unlock()
    // 设置 Map 中的 Key/Value
	f.m[key] = value
	return nil
}

raft

看了上面的具体动作实现，接下来看看 Raft 具体启动：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
func (s *Store) Open(enableSingle bool, localID string) error {
	// 设置 Raft 配置
	config := raft.DefaultConfig()
	config.LocalID = raft.ServerID(localID)
    // 设置 Raft 通信
	addr, err := net.ResolveTCPAddr("tcp", s.RaftBind)
    ...
	transport, err := raft.NewTCPTransport(s.RaftBind, addr, 3, 10*time.Second, os.Stderr)
    // 设置 Raft 存储对象
	snapshots, err := raft.NewFileSnapshotStore(s.RaftDir, retainSnapshotCount, os.Stderr)
	var logStore raft.LogStore
	var stableStore raft.StableStore
	if s.inmem {
		logStore = raft.NewInmemStore()
		stableStore = raft.NewInmemStore()
	} else {
		boltDB, err := raftboltdb.NewBoltStore(filepath.Join(s.RaftDir, "raft.db"))
		if err != nil {
			return fmt.Errorf("new bolt store: %s", err)
		}
		logStore = boltDB
		stableStore = boltDB
	}
    // 创建 raft 示例，并使用该 raft 实例启动集群
	ra, err := raft.NewRaft(config, (*fsm)(s), logStore, stableStore, snapshots, transport)
	if err != nil {
		return fmt.Errorf("new raft: %s", err)
	}
	s.raft = ra
	if enableSingle {
		...
		ra.BootstrapCluster(configuration)
	}
}

这里可以看到 Raft 所需接口为 FSM 和 Snapshot，具体的实现方式根据需求来实现，一般与 hraftd 相仿，大概了解了 hashicorp/raft 的使用，那么我们来实现具体的 VIP 功能。

VIP

network

既然是跟 IP 相关，那么肯定需要给对应网卡配置时间，在 Linux 中我们可以通过 ip 命令来设置，Golang 中使用 vishvananda/netlink 来实现。

netlink.AddrAdd 可以在指定的网络设备上添加 IP 地址。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
func (nc *NetworkConfig) addIP() error {
	res, err := nc.IsSet()
	if err != nil {
		return errors.Wrap(err, "ip check in AddIP failed")

	}
	if res {
		return nil
	}
	if err := netlink.AddrAdd(nc.link, nc.address); err != nil {
		return errors.Wrap(err, "could not add ip")
	}
	return nil
}

netlink.AddrDel 可以将 IP 从指定网络设备上删除：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
func (nc *NetworkConfig) delIP() error {
	res, err := nc.IsSet()
	if err != nil {
		return errors.Wrap(err, "ip check in DelIP failed")
	}

	if !res {
		return nil
	}

	if err := netlink.AddrDel(nc.link, nc.address); err != nil {
		return errors.Wrap(err, "could not delete ip")
	}

	return nil
}

raft

实现了 IP 设置相关，我们不需要提供 HTTP 接口，直接编写 Raft 相关实现，跟 hraftd 实现不同，在 hraftd 中需要进行信息写入读取，而我们的 VIP 仅依赖于 Raft 选举 Leader，所以只需要编写好对应的方法，不需要做额外操作：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
type FSM struct {
}

func (fsm FSM) Apply(log *raft.Log) interface{} {
	return nil
}

func (fsm FSM) Restore(snap io.ReadCloser) error {
	return nil
}

func (fsm FSM) Snapshot() (raft.FSMSnapshot, error) {
	return Snapshot{}, nil
}

type Snapshot struct {
}

func (snapshot Snapshot) Persist(sink raft.SnapshotSink) error {
	return nil
}

func (snapshot Snapshot) Release() {
}

serve

基础方法都已经实现了，那么接下来编写集群启动逻辑：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
func (manager *VIPManager) Start() error {
	// 初始化 raft 配置、存储对象、通信
	for id, ip := range manager.peers {
		configuration.Servers = append(configuration.Servers, raft.Server{ID: raft.ServerID(id), Address: raft.ServerAddress(ip)})
	}

	// 启动 Raft 集群，这里与 hraftd 不同，需要注意
	if error := raft.BootstrapCluster(config, logStore, stableStore, snapshots, transport, configuration); error != nil {
		return error
	}

	// 创建 raft 实例
	raftServer, error := raft.NewRaft(config, manager.fsm, logStore, stableStore, snapshots, transport)
    ...
	ticker := time.NewTicker(time.Second)
	isLeader := false
    // 服务启动时先删除 VIP，防止集群中同时存在节点都配置了 VIP
	manager.deleteIP(false)
	go func() {
		for {
			select {
            // 如果 当前节点是 Leader 节点，则设置 VIP
			case leader := <-raftServer.LeaderCh():
				if leader {
					isLeader = true
					log.Info("Leading")
					manager.addIP(true)

                }
            // 定时检测，如果是 Leader，则检测 VIP 是否正确设置，如果没有就再次配置 VIP
			case <-ticker.C:
				if isLeader {
					result, error := manager.networkConfigurator.IsSet()
					if error != nil {
						log.WithFields(log.Fields{"error": error, "ip": manager.networkConfigurator.IP(), "interface": manager.networkConfigurator.Interface()}).Error("Could not check ip")
					}

					if result == false {
						log.Error("Lost IP")

						manager.addIP(true)
					}
				}
            ...
			}
		}
	}()
}

这里与 hraftd 的实现不同，hraftd 先实例 raft，然后使用该 raft 实例启动集群，这样做的好处是哪怕集群只有一个节点，就是第一个节点，那么集群也是可以正常工作的，坏处是集群启动顺序是固定的，必须要先启动第一个节点，然后其他节点通过 Join 请求添加到 Raft 集群中（我们忽略了 Join 的走读）。

重新想一下我们的需求：集群、高可用、故障。当这几个词放在一起，我们就知道 hraftd 的方法不适合我们，有以下原因：

  1. 集群节点启动顺序要求
  2. 各个节点配置文件不同，有的需要 Join 参数

所以我们是直接使用 raft.BootstrapCluster 来启动集群，虽然只有一个节点集群无法正常工作，但是这个是可以容忍的。

ARP

在实现完上述功能后，我以为大功告成了，就开始自测，但是测试过程中发现了很诡异的现象，虽然我们通过 Raft 自身选举实现了 VIP 的故障自动漂移，但是实际测试中发现业务访问随着 VIP 的重建并没有立即恢复，，检查 ARP 记录发现集群中各个节点关于 VIP 的 ARP 记录各不相同，甚至是完全不同。

我们来重温下 ARP 协议内容：

地址解析协议（英語：Address Resolution Protocol，缩写：ARP）是一个通过解析网络层地址来找寻数据链路层地址的网络传输协议，它在IPv4中极其重要。ARP最初在1982年的RFC 826（征求意见稿）[1]中提出并纳入互联网标准 STD 37. ARP 也可能指是在多数操作系统中管理其相关地址的一个进程。

在以太网协议中规定，同一局域网中的一台主机要和另一台主机进行直接通信，必须要知道目标主机的MAC地址。而在TCP/IP协议中，网络层和传输层只关心目标主机的IP地址。这就导致在以太网中使用IP协议时，数据链路层的以太网协议接到上层IP协议提供的数据中，只包含目的主机的IP地址。于是需要一种方法，根据目的主机的IP地址，获得其MAC地址。这就是ARP协议要做的事情。所谓地址解析（address resolution）就是主机在发送帧前将目标IP地址转换成目标MAC地址的过程。

如果 VIP 与真实节点对应的 MAC 地址不同，就相当于 ARP 攻击了，所以我们的 Leader 节点设置完 VIP 后，还需要发送 ARP 请求广播，告诉广播域中的其他节点 VIP 正确的 MAC 地址。采用的方式是 gratuitous ARP（免费 ARP）。这里我们直接找一个开源的 ARP 实现来完成这个需求：

google/seesaw 是一个负载均衡器，里面实现了这个功能：

1
2
3
4
5
6
7
8
9
10
11
12
13
// ARPSendGratuitous sends a gratuitous ARP message via the specified interface.
func (ncc *SeesawNCC) ARPSendGratuitous(arp *ncctypes.ARPGratuitous, out *int) error {
	iface, err := net.InterfaceByName(arp.IfaceName)
	if err != nil {
		return fmt.Errorf("failed to get interface %q: %v", arp.IfaceName, err)
	}
	log.V(2).Infof("Sending gratuitous ARP for %s (%s) via %s", arp.IP, iface.HardwareAddr, iface.Name)
	m, err := gratuitousARPReply(arp.IP, iface.HardwareAddr)
	if err != nil {
		return err
	}
	return sendARP(iface, m)
}

总结

使用 hashicorp/raft 可以很简单方便的实现需要选举 Leader 的分布式应用，虽然我司的 Slogan 是 Make IT Simple ，但是愈发感觉 Hashicorp 才是这句话的忠实体现，他们的 Terraform、Vault、Consul、Nomad、Vagrant 等软件，都是让基础设施的适用与管理更简单方便的，还是很爽的。

本文的具体实现在 sparrow 可以看到。

参考链接

发表于 |

背景

平时工作使用的电脑是 ThinkPad T480，之前一直安装的 Win10，连接多显示器很正常，没有问题，后来重装为了 Ubuntu，发现连接多显示器很诡异，在我的这套设备之上，如果想要正常使用，需要按照一个奇怪的顺序，记录一下。

硬件设备

设备类型 设备 型号
笔记本 ThinkPad T480
拓展坞 联想/闪联 USB-C 集线器 C120
连接线 山泽 HDMI 数字高清线 SM-8855
连接线 VGA 高清视频线
显示器 DELL 24 寸 U2412Mb
显示器 DELL 24 寸 U2417H

（不要问我为啥 Type-C 遍地走的现在，还在用 VGA，现在这套还是东拼西凑出来的。。。

软件

设备接口

T480 作为 ThinkPad 的 T 系列产品，接口还是很丰富的：

  • 2 x USB 3.1 Gen 1** (one Always On)
  • 1 x USB 3.1 Gen 1** Type-C (Power Delivery, DisplayPort, Data transfer)
    • x USB 3.1 Gen 2** Type-C / Intel Thunderbolt 3 (Power Delivery, DisplayPort, Data transfer)
  • Headphone and microphone combo jack
  • 4-in-1 SD card reader (SD, MMC, SDHC, SDXC)
  • HDMI
  • RJ45 Gigabit Ethernet
  • Optional Smart card reader

ThinkPad T480 左视图：

  • 1 x USB 3.1 Gen 1** Type-C (Power Delivery, DisplayPort, Data transfer)
  • 1 x USB 3.1 Gen 2** Type-C / Intel Thunderbolt 3 (Power Delivery, DisplayPort, Data transfer)

这里分别用 Type-C1 和 Type-C2 代指从左到右的两个接口。

ThinkPad T480 右视图：

右侧有一个 HDMI 接口。

连接方式

连接顺序

  1. VGA 连接 U2412Mb
  2. HDMI 连接 U2417H
  3. VGA 连接 C120
  4. 电源连接 C120
  5. C120 连接 Type-C2
  6. 电源断开 C120
  7. 电源连接 Type-C1
  8. HDMI 连接 T480 HDMI

总结

这个顺序在尝试过程中感觉跟 T480 供电正相关，但是没有找到直接问题，只能用这种连接顺序来保证这套东西正常工作了。

发表于 |

背景

在用 K8s 的同学应该多少都使用过 Flannel 作为自己的网络插件，不讨论性能稳定性，在复杂的网络环境配置中 Flannel 的要求应该是最低的，所以我通常使用 Flannel 作为 让 K8s Ready 的最后一步。

在使用过程中，遇到过多次 flannel.1 这个 link 消失的情况，查看官方 Issue 中有人提到过： flannel.1 is deleted by service network restart, and never recreated again. ，但是这个 Issue 从 2017年创建一直到现在都处于 Open 状态，看上去社区也不打算去解决，其实不只是重启网络，如果没有特殊指定的话，找到默认网关所在的网卡，直接 ifdown ，flannel.1 也会丢失，并且不会重建，那为什么会出现这个问题，今天来看一看。

CNI Flannel Plugin

我们常说的 Flannel 分为两部分：CNI Flannel Plugin 及 Flannel。

CNI Flannel Plugin 是 Flannel CNI 插件的具体接口实现， CNI 要求实现的 cmdAdd cmdDel cmdCheck 都是在这里实现的，来看看具体的调用流程：

1
2
3
4
5
6
7
8
9
10
func cmdAdd(args *skel.CmdArgs) error {
    // 从标准输入加载配置
	n, err := loadFlannelNetConf(args.StdinData) 
    ...
    // 加载子网配置：/run/flannel/subnet.env
	fenv, err := loadFlannelSubnetEnv(n.SubnetFile) 
    ...
    // 执行添加动作
	return doCmdAdd(args, n, fenv) 
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
func doCmdAdd(args *skel.CmdArgs, n *NetConf, fenv *subnetEnv) error {
	n.Delegate["name"] = n.Name
	if !hasKey(n.Delegate, "type") {
		n.Delegate["type"] = "bridge"
	}
	...
	if n.CNIVersion != "" {
		n.Delegate["cniVersion"] = n.CNIVersion
	}
	n.Delegate["ipam"] = map[string]interface{}{
		"type":   "host-local",
		"subnet": fenv.sn.String(),
		"routes": []types.Route{
			{
				Dst: *fenv.nw,
			},
		},
	}
    // 进行配置解析及填充后，执行委托类型插件进行配置，默认是 bridge，创建过程中会将配置保存到 /var/lib/cni/flannel ，删除时会用到
	return delegateAdd(args.ContainerID, n.DataDir, n.Delegate)
}

到这里已经跟 Flannel Plugin 无关了，是调用的其他插件完成的具体动作，再来看看删除动作：

1
2
3
4
5
6
func cmdDel(args *skel.CmdArgs) error {
	nc, err := loadFlannelNetConf(args.StdinData)
    ...
    // 执行删除动作
	return doCmdDel(args, nc)
}
1
2
3
4
5
6
7
8
9
10
11
func doCmdDel(args *skel.CmdArgs, n *NetConf) error {
    // 从 /var/lib/cni/flannel 中根据 ContainerID 读取配置，并在读取后删除配置
    netconfBytes, err := consumeScratchNetConf(args.ContainerID, n.DataDir) 
    ...
	nc := &types.NetConf{}
	if err = json.Unmarshal(netconfBytes, nc); err != nil {
		return fmt.Errorf("failed to parse netconf: %v", err)
	}
    // 委托其他插件执行删除动作，默认 bridge
	return invoke.DelegateDel(context.TODO(), nc.Type, netconfBytes, nil) 
}

到这里我们来捋一捋整个流程：

  1. kubelet 启动时查找可用 CNI 插件，并根据配置加载
  2. kubelet 创建容器前，通过 CNI Interface 调用相应方法执行 cmdAdd/cmdDel 命令
  3. CNI 根据配置信息调用对应的 Plugin 执行 cmdAdd/cmdDel

相应文件路径

/var/lib/cni/flannel

每个 Pod 的具体网络配置，配置内容如下

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
[root@install2 09:29:48 cni]$pwd
/var/lib/cni
[root@install2 09:29:51 cni]$cat flannel/d3f1220d58a72ebe5a92f8febbe6dd45d3bff65dce0ff6960f732f202026c24c |jq
{
  "cniVersion": "0.3.1",
  "hairpinMode": true,
  "ipMasq": false,
  "ipam": {
    "routes": [
      {
        "dst": "10.244.0.0/16"
      }
    ],
    "subnet": "10.244.1.0/24",
    "type": "host-local"
  },
  "isDefaultGateway": true,
  "isGateway": true,
  "mtu": 1450,
  "name": "cbr0",
  "type": "bridge"
}

/var/lib/cni/networks

IP 地址分配配置路径，默认 Flannel 使用的 ipam 是 host-local，bridge 是 cbr0 ，在这下面是已分配的 IP 地址：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[root@install2 09:31:48 cni]$pwd
/var/lib/cni
[root@install2 09:31:49 cni]$tree networks/
networks/
└── cbr0
    ├── 10.244.1.160
    ├── 10.244.1.161
    ├── 10.244.1.162
    ├── last_reserved_ip.0
    └── lock

1 directory, 5 files
[root@install2 09:31:53 cni]$cat networks/cbr0/10.244.1.162
d3f1220d58a72ebe5a92f8febbe6dd45d3bff65dce0ff6960f732f202026c24c
[root@install2 09:32:07 cni]$cat networks/cbr0/last_reserved_ip.0
10.244.1.162

/etc/cni/net.d

CNI 插件配置文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
[root@install2 09:34:47 net.d]$pwd
/etc/cni/net.d
[root@install2 09:34:48 net.d]$cat 10-flannel.conflist
{
  "name": "cbr0",
  "cniVersion": "0.3.1",
  "plugins": [
    {
      "type": "flannel",
      "delegate": {
        "hairpinMode": true,
        "isDefaultGateway": true
      }
    },
    {
      "type": "portmap",
      "capabilities": {
        "portMappings": true
      }
    }
  ]
}

大概了解了 CNI Flannel Plugin ，说好的 flannel.1 呢？既然确定了 flannel.1 不是 CNI Plugin 里面实现的，那肯定就是 Flannel 自己的行为了，接下来看 Flannel 代码就可以了。

Flannel

提到 Flannel，就不得不拿出这张图：

目录结构

1
2
3
4
5
6
7
8
root@localhost:~/go/src/github.com/coreos/flannel
master ✗ $ tree . -L 1
├── backend # 后端实现：vxlan,udp,hostgw
├── main.go # 入口
├── network # IPtables 相关配置
├── pkg     # 辅助功能，如 IP，Namespace
├── README.md
├── subnet  # 子网管理，K8s 通信相关

使用方式

我们先来回想一下 K8s 集群部署，我们通过 kubeadm 指定了 Pod CIDR 为 10.244.0.0/16 ：

1
2
3
4
5
6
7
8
9
---
apiServer: {}
apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
kubernetesVersion: ""
networking:
  dnsDomain: ""
  podSubnet: 10.244.0.0/16
  serviceSubnet: ""

然后我们直接执行 kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml 等待 Node Ready 即可，这样做的前提是因为我们指定的 Pod 子网是 Flannel 默认子网，两者必须相同才可以配置正确。

代码入口

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
func main() {
  ...
	sm, err := newSubnetManager()
  ...
	// 从 K8s 中获取配置信息，主要是子网信息
	config, err := getConfig(ctx, sm)
  ...
  // 创建 backend manager 并创建用来创建 backend 和注册网络
	bm := backend.NewManager(ctx, sm, extIface)
	be, err := bm.GetBackend(config.BackendType)
  ...
	bn, err := be.RegisterNetwork(ctx, wg, config)
  ...
	// 运行 backend 
	log.Info("Running backend.")
	wg.Add(1)
	go func() {
		bn.Run(ctx)
		wg.Done()
	}()
  ...
}

在 main.go 中获取配置的来源是 ConfigMap：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
[root@install1 11:00:39 ~]$kubectl get cm kube-flannel-cfg -n kube-system -o yaml
apiVersion: v1
data:
  cni-conf.json: |
    {
      "name": "cbr0",
      "cniVersion": "0.3.1",
      "plugins": [
        {
          "type": "flannel",
          "delegate": {
            "hairpinMode": true,
            "isDefaultGateway": true
          }
        },
        {
          "type": "portmap",
          "capabilities": {
            "portMappings": true
          }
        }
      ]
    }
  net-conf.json: |
    {
      "Network": "10.244.0.0/16",
      "Backend": {
        "Type": "vxlan"
      }
    }
kind: ConfigMap
metadata:
  annotations:
  creationTimestamp: "2019-12-30T02:37:21Z"
  labels:
    app: flannel
    tier: node
  name: kube-flannel-cfg
  namespace: kube-system
  resourceVersion: "235454"
  selfLink: /api/v1/namespaces/kube-system/configmaps/kube-flannel-cfg
  uid: fd9f67ee-ee1b-411d-8403-23ab05de56c8

可以看到默认的 Backend 是 vxlan，我们接着看 backend 和 vxlan 相关处理，在 backend/ 路径下放着些统一的接口定义，vxlan 是接口的具体实现：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
root@localhost:~/go/src/github.com/coreos/flannel
master ✗ $ tree backend -L 1
backend
├── common.go
├── manager.go
├── route_network.go
├── route_network_test.go
├── route_network_windows.go
├── simple_network.go
├── udp
└── vxlan
    ├── device.go
    ├── device_windows.go
    ├── vxlan.go
    ├── vxlan_network.go
    ├── vxlan_network_windows.go
    └── vxlan_windows.go

如 RegisterNetwork：

1
2
3
4
type Backend interface {
	// Called when the backend should create or begin managing a new network
	RegisterNetwork(ctx context.Context, wg sync.WaitGroup, config *subnet.Config) (Network, error)
}

看看 vxlan RegisterNetwork 做了什么：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
func (be *VXLANBackend) RegisterNetwork(ctx context.Context, wg sync.WaitGroup, config *subnet.Config) (backend.Network, error) {
	// 解析配置
	cfg := struct {
		VNI           int
		Port          int
		GBP           bool
		Learning      bool
		DirectRouting bool
	}{
		VNI: defaultVNI,
	}

  // vtep 配置信息
	devAttrs := vxlanDeviceAttrs{
		vni:       uint32(cfg.VNI),
		name:      fmt.Sprintf("flannel.%v", cfg.VNI),
		vtepIndex: be.extIface.Iface.Index,
		vtepAddr:  be.extIface.IfaceAddr,
		vtepPort:  cfg.Port,
		gbp:       cfg.GBP,
		learning:  cfg.Learning,
	}

  // 创建 vtep
	dev, err := newVXLANDevice(&devAttrs)
	if err != nil {
		return nil, err
	}
	dev.directRouting = cfg.DirectRouting
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
func newVXLANDevice(devAttrs *vxlanDeviceAttrs) (*vxlanDevice, error) {
  // netlink 是 Golang 中操作网络相关的库，提供了创建 Vxlan 设备的接口
	link := &netlink.Vxlan{
		LinkAttrs: netlink.LinkAttrs{
			Name: devAttrs.name,
		},
		VxlanId:      int(devAttrs.vni),
		VtepDevIndex: devAttrs.vtepIndex,
		SrcAddr:      devAttrs.vtepAddr,
		Port:         devAttrs.vtepPort,
		Learning:     devAttrs.learning,
		GBP:          devAttrs.gbp,
	}

	link, err := ensureLink(link)
	if err != nil {
		return nil, err
	}
	return &vxlanDevice{
		link: link,
	}, nil
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
func ensureLink(vxlan *netlink.Vxlan) (*netlink.Vxlan, error) {
	err := netlink.LinkAdd(vxlan)
	if err == syscall.EEXIST {
		// it's ok if the device already exists as long as config is similar
    log.V(1).Infof("VXLAN device already exists")
    ...
		// 如果存在，则娇艳 原有设备是否兼容，如果不兼容则删除并重新创建设备
		if err = netlink.LinkAdd(vxlan); err != nil {
			return nil, fmt.Errorf("failed to create vxlan interface: %v", err)
		}
	} else if err != nil {
		return nil, err
	}

  ...
	return vxlan, nil
}

到这里我们就知道了是 Flannel 在进行 backend 注册的时候创建的 flannel.1 设备，如果我们想要简单粗暴的去修改代码实现，我们可以在 backend.Run() 方法中加入 ensureLink 检测逻辑，保证当发现对应 vtep 设备消失时，重新创建。但是这种实现方式就比较侵入，而且破坏了 backend 通用逻辑，我理解正确的处理方式应该是通过 health 探针去检测，如果检测到 Pod 处于 unhealthy 状态，自动重建 Pod，会重新进行 backend.RegisterNetwork 逻辑，就不存在这个问题了。

来看下默认的 Flannel YAML 文件，发现其中并没有 health 探针配置，还是有点奇怪的，这么一个基础的服务，居然没有做任何的健康检查，听上去有些不合道理。

于是我又去 Github 上查找相关的 Issue，果然发现了很多人遇到这个问题，倒是最终都没有提出比较好的方案来解决，其中 Eduard Català 分别提交了 2 个 PR 用来增加 Health Check 机制，但是不知道因为什么最终都没有合并：

我们来看看他的对应实现，通过检测对应的设备是否存在，如果不存在则不健康：

backend/vxlan/vxlan.go

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
func (be *VXLANBackend) CheckHealthz() error {
	_, err := net.InterfaceByName(be.extIface.Iface.Name)
	if err != nil {
		log.Errorf("Master interface %v disappeared. Waiting its return...", be.extIface.Iface.Name)
		for err != nil {
			time.Sleep(15 * time.Second)
			_, err = net.InterfaceByName(be.extIface.Iface.Name)
		}
		log.Errorf("Master interface: %v reappeared", be.extIface.Iface.Name)
	}

	_, err = net.InterfaceByName(be.network.dev.link.Name)
	if err != nil {
		log.Errorf("Flannel interface: %v not found - Requiring flannel restart ", be.network.dev.link.Name)
		return backend.FlannelRestart
	}
	return nil
}

总结

Flannel 社区活跃度不高，合并 PR 的速度更是慢的离谱，有很多存在很久的 Issue 也没有解决，感觉还是用着玩玩就好。

参考链接

发表于 |

2019

2019 年就要结束了，今年用数据记录了很多，可以很好的支撑我做一个年终总结碎碎念。

读书观影

一整年都是两点一线：家里和公司，没有什么特别大的变化，周末的时间也都给了书和电影。

读书记录之前已经发过了，上半年看的比较多，下半年忙起来时间上少了很多，加上看的书的质量也比上半年高，所以看的比较细，用了很多时间去查相关资料。因为年后有些计划，所以集中把自己刚刚工作的时候买的纸质书（一直没看）清理了一下，愈发觉得刚工作的自己真是个愣头青，买的书都是水书，还是应该多看些经典书籍，需要更多思考的书。

电影看的多，至少豆瓣上标记的数量很吓人，周末基本上都会看几部。今年看的种类都比较阴暗，自己本意是放松一下的，看着看着心情更加沉重了。电影是另外一种了解世界的方式，我们可以看到不同的人，不同的风景，同时也会代入思考如果是自己会怎么做。在现实世界很多观点无法表述的现在，还是很有趣的。

书籍推荐：

  • 《操作系统导论》
  • 《图解密码技术（第3版）》
  • 《编码的奥秘》

电影推荐：

  • 《平衡》
  • 《电话亭》
  • 《婚姻故事》

习惯

2019 年算是养成了 2 个好习惯：刷题和写博客。

因为自己一直习惯早起（6点钟左右），以前都是当天要做什么工作，早上起来做一些准备之类的事情，有两点不好：一是把自己的时间都给了工作，导致自己会有种抵触；二是不规律，我喜欢规律。

所以从 4 月份开始，每天早上会做一道 LeetCode 题，目前一直坚持到现在。要说刷题有带给我什么质的变化么，那显然是没有的，但是我上面提到的两点不好，在刷题这里都消失了。刷题让我去认真的学习数据结构和算法，去了解一道题的不同种解法（往往会冒出“这tm的真是个人才”的感叹），而且会让我的生活更加规律，能从工作中抽出来，强烈推荐大家去试试。像我从 Easy 开始分类的做，最开始不会花费太长时间，做不出来就看看其他人怎么做，后续就会有些自己的想法。但是最近我做 Medium 的题耗时就比之前长好多了，有些题及时看着答案也要想很久，导致我又起的更早了。。

2019 年自己定了每周更新一篇博客的目标，目标完成。一开始写博客是为了记录下自己的踩坑经历和一些经验分享，随后是自己发现一些新东西的时候自己学习了解的过程。要锻炼自己对外输出的能力，保证自己能够有逻辑的输出自己的观点，哪怕不能有逻辑的说出来，至少要有逻辑的写出来。

开销

没有买什么新玩具，也没有什么特别大的开支，当然也没有存到什么钱。

真实物品

主要的开销在吃饭和房租，年初买了一个 iPad 用来看 PDF，毕竟无论是 Kindle 还是手机都不能很好的阅读，iPad 看 PDF 的效果是很好的，我也用它来看了一些书，但是有个问题是完整在 iPad 看完的书不到 10本，也是一个 买前生产力，买后bilibili 的例子了。

虚拟物品

自己平时需要跑一些 crontab 做事情，所以有一个祖传搬瓦工一直在供着，但是今年上网格外的困难，搬瓦工 IP 被封，所以又在 Azure 上搞了一个 VPS，目前看上去这套东西运转的还算顺利。

趁着年底活动，买了 RescueTime 的会员，估计明年会买 Pocket，毕竟重度用户。

P.S. 从带给自己生活感受的提升上，VPS 性价比可太高了。

时间管理

平时总是感觉自己时间不够用，就用了 RescueTime 记录自己的时间开销，12月份是一个比较完整的记录：家里的电脑，公司的电脑以及自己的手机。

真实情况是自己一个月在公司的时间 218 小时，真正写代码的时间 96 小时，平均下来一天有 5小时的高产出时间，跟自己预想的偏差很小，没什么意外。

抛开工作时间不提，手机占用了比较多的时间，而具体占用时间的大头部分在微信、Twitter 和浏览器。这部分是有很大程度优化的空间的。除了必要的社交，平时用浏览器阅读的习惯大概是这样：看到不错的文章如果不长，就在手机上看完，如果稍长或者没时间，就会收藏到 Pocket 中，等到每周五晚上再集中处理。这样会面临一个问题是我的 Pocket 有时候变成了一个收藏夹，什么东西都往里面放，而且我的很多时间也都通过 Pocket 来绑定，那些博客有读的必要么，有收藏的必要么，要仔细想想了。

2020

都用数据记录下来的好处就是可以量化的改进：

  1. 保持看书状态，把部分观影时间也用来看书，并形成读书笔记
  2. 刷题不能停，把解题思路完整的记录下来，或文字，或图片
  3. 宁可不写也不要水博客，多记录些自己平时忽略的地方
  4. 合理利用软件，不依赖软件，尝试 GTD

发表于 |

背景

前几天同事找到我，说有一台服务器上的 cgroup 没有创建出来，导致其他程序出现了问题，记录一下。

现象

在我们的服务器上，通常会通过 libcgconfig 来进行 cgroup 的配置，供其他服务使用。结果发现对应的 cgroup 没有创建出来，于是查看 cgconfig.service 的状态，发现是异常退出的：

报错信息比较重要的是这一条：

failed to set /sys/fs/cgroup/cpuset/zbs/cpuset.mems: Invalid argument。

调查

检查下 /etc/cgconfig.conf 中的配置是否正确：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
group . {
    cpuset {
        cpuset.memory_pressure_enabled = "1";
    }
}

group zbs {
    cpu {
        cpu.rt_runtime_us = "950000";
        cpu.rt_period_us = "1000000";
    }
    cpuset {
        cpuset.cpus = "0,1,2,3,4,5";
        cpuset.mems = "0-1";
        cpuset.cpu_exclusive = "1";
        cpuset.mem_hardwall = "1";
    }
}

...

配置看上去没啥问题，这里的 cpuset.mems 指定的是 NUMA Node ID。

那么我们就来看看 NUMA 状态，使用 numactl 查看节点 NUMA 信息：

1
2
3
4
5
6
7
8
9
10
11
12
[root@node 21:53:25 ~]$numactl -H
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23
node 0 size: 0 MB
node 0 free: 0 MB
node 1 cpus: 8 9 10 11 12 13 14 15 24 25 26 27 28 29 30 31
node 1 size: 32654 MB
node 1 free: 10234 MB
node distances:
node   0   1
  0:  10  20
  1:  20  10

发现问题了，这个节点上有2个 CPU，但是其中的一个 CPU 上对应的节点内存出现了故障，导致 node0 对应的内存是 0MB。

解决

所以我们正确的姿势是将 cpuset.mems 从 0-1 改为 1 ，然后重启 cgconfig。

1
2
3
4
5
6
7
8
9
10
11
[root@node 22:09:43 ~]$systemctl status cgconfig
● cgconfig.service - Control Group configuration service
   Loaded: loaded (/usr/lib/systemd/system/cgconfig.service; enabled; vendor preset: disabled)
   Active: active (exited) since Fri 2019-12-20 16:41:24 CST; 5 days ago
 Main PID: 913 (code=exited, status=0/SUCCESS)
    Tasks: 0
   Memory: 0B
   CGroup: /system.slice/cgconfig.service

Dec 20 16:41:24 node systemd[1]: Starting Control Group configuration service...
Dec 20 16:41:24 node systemd[1]: Started Control Group configuration service.

发表于 |

背景

之前已经介绍过 ClusterAPI 及相应实现方式，但是针对使用 ClusterAPI 部署的 K8s 集群社区中一直没有升级方案，其中 vmware 实现了一个简单的升级工具，可以在社区没实现之前提供使用，今天来看下这个工具是如何实现的。

cluster-api-upgrade-tool

项目地址：https://github.com/vmware/cluster-api-upgrade-tool

因为这只是一个单独的工具，因此代码结构比较简单：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
yiran@t480:~/go/src/github.com/vmware/cluster-api-upgrade-tool 
master ✔ $ tree .
.
├── CODE-OF-CONDUCT.md
├── CONTRIBUTING.md
├── Dockerfile
├── go.mod
├── go.sum
├── hack
│   └── tools
│       ├── go.mod
│       ├── go.sum
│       └── main.go
├── LICENSE.txt
├── main.go # 命令行入口
├── Makefile
├── NOTICE.txt
├── pkg
│   ├── internal
│   │   └── kubernetes
│   │       ├── client.go # 获取 client
│   │       └── pod_exec.go
│   ├── logging
│   │   └── logrus_logr.go
│   └── upgrade
│       ├── config.go 
│       ├── control_plane.go # 主要升级逻辑
│       └── control_plane_test.go
├── README.md
└── test
    └── integration
        ├── go.mod
        ├── go.sum
        └── main_test.go

升级流程

首先在 main.go 封装了相应的命令行用于升级，获取到相应配置后，开始升级：

1
2
3
4
5
6
upgrader, err := upgrade.NewControlPlaneUpgrader(newLogger(), finalConfig)
if err != nil {
	return err
}

         return upgrader.Upgrade()

在 control_plane.go 文件中是升级的主要逻辑，所有的步骤都是顺序执行的，摘要下主要的步骤：

1
2
3
4
5
6
7
8
9
10
11
12
13
// Upgrade does the upgrading of the control plane.
func (u *ControlPlaneUpgrader) Upgrade() error {
	machines, err := u.listMachines()
	...
	if err := u.reconcileKubeadmConfigMapAPIEndpoints(); err != nil {
	err = u.updateKubeletConfigMapIfNeeded(u.desiredVersion)
	err = u.updateKubeletRbacIfNeeded(u.desiredVersion)
    if err := u.etcdClusterHealthCheck(15 * time.Second); err != nil {
    if err := u.UpdateProviderIDsToNodes(); err != nil {
	return updateKubeadmKubernetesVersion(in, "v"+u.desiredVersion.String())
	if err := u.updateMachines(machines); err != nil {
	if err := u.reconcileKubeadmConfigMapAPIEndpoints(); err != nil {
}
  1. u.listMachines获取 TargetCluster 所有的 ControlPlane 节点
    a. 通过 label 来进行 machine 过滤
    b. 如果 Machine 的 DeletionTimestamp 字段为 0，则追加到列表中
  2. u.reconcileKubeadmConfigMapAPIEndpoints 这里主要是确保对应的 APIEndpoints 节点都在 k8s 集群中，通过对比 nodeList 与 APIEndpoints 来进行过滤
  3. u.updateKubeletConfigMapIfNeeded 在 k8s 中，在 ConfigMap 中是有保存 kubelet 配置信息的，在升级过程中，需要重新创建对应版本的 kubelet 配置信息，这个函数中直接将原版本的 kubelet 复制了一份，创建一份目标版本的 kublet 配置 ConfigMap
  4. u.updateKubeletRbacIfNeeded 创建目标版本的 Role 和 RoleBinding 资源
  5. u.etcdClusterHealthCheck 检查 etcd 集群是否健康，这里主要通过 endpoint health --endpoints 来检查 etcd 是否健康
  6. u.UpdateProviderIDsToNodes 通过 Cluster-API 创建出来的节点，需要设置 node.ProviderID 才可以被 Cluster-API 识别为 running 状态，ProviderId 格式为：vmware://xxxxx ，这里根据 ProviderID 来检测出具体的 ID，并将其作为一个 map 返回
  7. u.updateKubeadmKubernetesVersion 将 kubeadm ConfigMap 中的 kubernetesVersion 字段更新为目标版本，便于后续添加节点时指定的是目标版本
  8. u.updateMachines 在所有配置文件已经准备、更新完成后，开始做整个升级中最重要的部分，节点（Machine）升级，首先遍历所有 Machine 资源，针对每个 Machine，进行如下动作：
    a. u.etcdClusterHealthCheck 检查 etcd 集群是否健康，如果不健康，则退出升级
    b. generateReplacementMachineName 生成替代 Machine 相应配置信息，如 MachineName
    c. u.updateInfrastructureReference 创建替代 Machine 的 Infrastructure Object
    d. u.updateBootstrapConfig 创建替代 Machine 的 Bootstrap Config，因为默认 Cluster-API 使用的 kubeadm Bootstrap，所以这里其实是生成替代 Machine 执行的 kubeadm 配置
    e. u.updateMachine 真正创建替代 Machine 的步骤，创建对应的目标虚拟机，等待目标虚拟机添加到 K8s 集群中且处于 Ready 后，将原虚拟机对应 etcd 节点从 etcd 集群中移除，随后将原虚拟机对应节点从 K8s 集群中移除
  9. u.reconcileKubeadmConfigMapAPIEndpoints 等待所有 Machine 替换完成后，重新配置 kubeadm ConfigMap 保证 kubeadm ConfigMap 中保存所有的 APIEndpoints 信息。

总结

Cluster-API 作为 K8s cluster-lifecycle SIG 的一个还处于 Alpha 阶段的项目，还处于一个快速更新迭代的状态，因此最终升级流程是怎样还不确定，但是从 vmware 的这个工具来看，后续很有可能采用这种方案，毕竟 Cluster-API 不想通过 SSH 这种比较麻（恶）烦（心）的方式对节点进行管理，从 kubeadm Bootstrap 使用 Cloud-init 就可以看出，尤其是当支持多种 Linux 发行版后，可以预想这是一个灾难。因此使用这种节点逐一替换的方式是很方便的，具体实现看 v1alpha3 发布之后社区的讨论结果吧。

吐槽：
Cluster-API 项目在代码中很少使用缩写，带来的好处很明显，易读易懂，上手容易，我自己的项目也一直秉承着这种观点，但是当我看到 reconcileKubeadmConfigMapAPIEndpoints 这种长度的变量名，还是很崩溃的。

参考链接

发表于 |

背景

之前写过一篇《Kubernetes 实战-高可用集群部署》 博客讲 K8S 高可用配置，当时采用的方式是使用 keepalived 配合 HAProxy 自建 LB 的方式，但是最近发现无论是 Kubespray 还是 Rancher RKE 都没有采用这种方式，而是在 worker node 上配置 nginx/haproxy 代理 APIServer 达到目的。今天来手动配置下这种方式，了解下注意事项。

本文配置方式参考 Kubespray，主要是想加深自己对这方面的理解，如果只是单纯的想要搭建环境，那么直接使用 Kubespray 就好。

环境

IP role
192.168.17.11 ControlPlane1
192.168.17.12 ControlPlane2
192.168.17.13 ControlPlane3
192.168.17.14 WorkerNode1

准备工作

软件安装

这部分准备工作与之前一样，没什么不同，因此不详细说明，需要安装 kubectl,kubeadm,kubelet 。

部署

ControlPlane1

kubeadm 配置文件如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
[root@install1 17:55:09 tmp]$cat kubeadm.yaml
---
apiServer: {}
apiVersion: kubeadm.k8s.io/v1beta1
certificatesDir: ""
clusterName: test
controlPlaneEndpoint: "192.168.17.11:6443"
controllerManager: {}
dns:
  type: ""
etcd: {}
imageRepository: registry.cn-hangzhou.aliyuncs.com/google_containers
kind: ClusterConfiguration
kubernetesVersion: ""
networking:
  dnsDomain: ""
  podSubnet: 10.244.0.0/16
  serviceSubnet: ""
scheduler: {}

---
apiVersion: kubeadm.k8s.io/v1beta1
kind: InitConfiguration
localAPIEndpoint:
  advertiseAddress: "192.168.17.11"
  bindPort: 6443
nodeRegistration:
  name: 'install1'

执行部署动作：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
[root@install1 17:55:10 tmp]$kubeadm init --config kubeadm.yaml --upload-certs
...
You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

You can now join any number of the control-plane node running the following command on each as root:

  kubeadm join 192.168.17.11:6443 --token 0xsbed.rcfk0ew0nlgrpjv0 \
    --discovery-token-ca-cert-hash sha256:1be9652019ef048fdd1d16385907c519e5559a1b786aa3ff1c46eeb489e1a6ef \
    --control-plane --certificate-key 2368ee7ebe6697164c46812e358539638de1d7665b3111afde949bce73275029

Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use 
"kubeadm init phase upload-certs --upload-certs" to reload certs afterward.

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.17.11:6443 --token 0xsbed.rcfk0ew0nlgrpjv0 \
    --discovery-token-ca-cert-hash sha256:1be9652019ef048fdd1d16385907c519e5559a1b786aa3ff1c46eeb489e1a6ef

ControlPlane2

kubeadm 配置文件如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[root@install2 17:40:52 tmp]$cat kubeadm.yaml
apiVersion: kubeadm.k8s.io/v1beta2
kind: JoinConfiguration
discovery:
  bootstrapToken:
    apiServerEndpoint: 192.168.17.11:6443
    token: 0xsbed.rcfk0ew0nlgrpjv0
    unsafeSkipCAVerification: true
  timeout: 5m0s
  tlsBootstrapToken: 0xsbed.rcfk0ew0nlgrpjv0
controlPlane:
  localAPIEndpoint:
    advertiseAddress: 192.168.17.12
    bindPort: 6443
  certificateKey: 2368ee7ebe6697164c46812e358539638de1d7665b3111afde949bce73275029
nodeRegistration:
  name: installer2

执行部署动作：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[root@install2 17:40:58 tmp]$kubeadm join --config kubeadm.yaml
...
This node has joined the cluster and a new control plane instance was created:

* Certificate signing request was sent to apiserver and approval was received.
* The Kubelet was informed of the new secure connection details.
* Control plane (master) label and taint were applied to the new node.
* The Kubernetes control plane instances scaled up.
* A new etcd member was added to the local/stacked etcd cluster.

To start administering your cluster from this node, you need to run the following as a regular user:

        mkdir -p $HOME/.kube
        sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
        sudo chown $(id -u):$(id -g) $HOME/.kube/config

Run 'kubectl get nodes' to see this node join the cluster.

ControlPlane3

kubeadm 配置文件如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[root@install3 17:47:24 tmp]$cat kubeadm.yaml
apiVersion: kubeadm.k8s.io/v1beta2
kind: JoinConfiguration
discovery:
  bootstrapToken:
    apiServerEndpoint: 192.168.17.11:6443
    token: 0xsbed.rcfk0ew0nlgrpjv0
    unsafeSkipCAVerification: true
  timeout: 5m0s
  tlsBootstrapToken: 0xsbed.rcfk0ew0nlgrpjv0
controlPlane:
  localAPIEndpoint:
    advertiseAddress: 192.168.17.13
    bindPort: 6443
  certificateKey: 2368ee7ebe6697164c46812e358539638de1d7665b3111afde949bce73275029
nodeRegistration:
  name: installer2

执行部署动作：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[root@install3 17:47:25 tmp]$kubeadm join --config kubeadm.yaml
...
This node has joined the cluster and a new control plane instance was created:

* Certificate signing request was sent to apiserver and approval was received.
* The Kubelet was informed of the new secure connection details.
* Control plane (master) label and taint were applied to the new node.
* The Kubernetes control plane instances scaled up.
* A new etcd member was added to the local/stacked etcd cluster.

To start administering your cluster from this node, you need to run the following as a regular user:

        mkdir -p $HOME/.kube
        sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
        sudo chown $(id -u):$(id -g) $HOME/.kube/config

Run 'kubectl get nodes' to see this node join the cluster.

node1

3 个 ControlPlane 节点已经部署完成，我们可以通过 kubectl 命令获取对应的状态信息，因为没有部署 CNI，所以这里还是 NotReady 的：

1
2
3
4
5
6
[root@install1 18:00:50 tmp]$kubectl get node -o wide
NAME         STATUS     ROLES    AGE     VERSION   INTERNAL-IP     EXTERNAL-IP   OS-IMAGE                KERNEL-VERSION                        CONTAINER-RUNTIME
install1     NotReady   master   5m2s    v1.16.3   172.18.19.11    <none>        CentOS Linux 7 (Core)   3.10.0-1062.1.2.el7.smartx.1.x86_64   docker://19.3.5
installer2   NotReady   master   4m22s   v1.16.3   192.168.17.12   <none>        CentOS Linux 7 (Core)   3.10.0-1062.1.2.el7.smartx.1.x86_64   docker://19.3.5
installer3   NotReady   master   3m1s    v1.16.3   192.168.17.13   <none>        CentOS Linux 7 (Core)   3.10.0-1062.1.2.el7.smartx.1.x86_64   docker://19.3.5
[root@install1 18:00:53 tmp]$

现在要来部署 worker node，当我们有可用的 LB，时，我们无需关心 APIServer 的可用性，由 LB 来决定。那么现在没有可用的 LB，我们的 worker node 想要与 k8s 进行通信，就需要每个 worker node 自身启动一个 proxy，将自己的 kubelet 连接到自己本地，然后通过 proxy 到集群中已有的 APIServer 。

配置 Proxy

这里以 nginx 举例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
[root@install4 18:05:03 ~]$mkdir /etc/nginx
[root@install4 18:06:02 ~]$chmod 700 /etc/nginx
[root@install4 18:14:23 ~]$cat /etc/nginx/nginx.conf
error_log stderr notice;

worker_processes 2;
worker_rlimit_nofile 130048;
worker_shutdown_timeout 10s;

events {
  multi_accept on;
  use epoll;
  worker_connections 16384;
}

stream {
  upstream kube_apiserver {
    least_conn;
    server 192.168.17.11:6443;
    server 192.168.17.12:6443;
    server 192.168.17.13:6443;
    }

  server {
    listen        127.0.0.1:6443;
    proxy_pass    kube_apiserver;
    proxy_timeout 10m;
    proxy_connect_timeout 1s;
  }
}

http {
  aio threads;
  aio_write on;
  tcp_nopush on;
  tcp_nodelay on;

  keepalive_timeout 5m;
  keepalive_requests 100;
  reset_timedout_connection on;
  server_tokens off;
  autoindex off;

  server {
    listen 8081;
    location /healthz {
      access_log off;
      return 200;
    }
    location /stub_status {
      stub_status on;
      access_log off;
    }
  }
  }
[root@install4 18:18:29 manifests]$vim /etc/sysctl.conf 
[root@install4 18:18:54 manifests]$sysctl -p 
net.ipv4.ip_forward = 1
net.ipv4.ip_local_reserved_ports = 30000-32767
net.bridge.bridge-nf-call-iptables = 1
net.bridge.bridge-nf-call-arptables = 1
net.bridge.bridge-nf-call-ip6tables = 1

加入 K8s 集群

执行部署动作：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
[root@install4 18:31:10 tmp]$kubeadm join 192.168.17.11:6443 --token 0xsbed.rcfk0ew0nlgrpjv0 \
    --discovery-token-ca-cert-hash sha256:1be9652019ef048fdd1d16385907c519e5559a1b786aa3ff1c46eeb489e1a6ef 
[preflight] Running pre-flight checks
        [WARNING IsDockerSystemdCheck]: detected "cgroupfs" as the Docker cgroup driver. The recommended driver is "systemd". Please follow the guide at https://kubernetes.io/docs/setup
/cri/
        [WARNING SystemVerification]: this Docker version is not on the list of validated versions: 19.03.5. Latest validated version: 18.09
        [WARNING Hostname]: hostname "install4" could not be reached
        [WARNING Hostname]: hostname "install4": lookup install4 on 192.168.31.215:53: no such host
[preflight] Reading configuration from the cluster...
[preflight] FYI: You can look at this config file with 'kubectl -n kube-system get cm kubeadm-config -oyaml'
[kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.16" ConfigMap in the kube-system namespace
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Activating the kubelet service
[kubelet-start] Waiting for the kubelet to perform the TLS Bootstrap...

This node has joined the cluster:
* Certificate signing request was sent to apiserver and a response was received.
* The Kubelet was informed of the new secure connection details.

Run 'kubectl get nodes' on the control-plane to see this node join the cluster.

此时在 K8s 集群中存在 4个节点，其中 3 个是 ControlPlane 节点，1 个是 worker 节点，但是此时 worker 节点是连接的 192.168.17.11:6443 APIServer，如果 这个 APIServer 故障了，那么的 worker 节点就无法正常与集群通讯了，需要进行以下操作：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
[root@install4 18:37:51 kubernetes]$systemctl stop kubelet docker
[root@install4 18:38:09 manifests]$pwd
/etc/kubernetes/manifests
[root@install4 18:38:12 manifests]$cat nginx-proxy.yml 
apiVersion: v1
kind: Pod
metadata:
  name: nginx-proxy
  namespace: kube-system
  labels:
    addonmanager.kubernetes.io/mode: Reconcile
    k8s-app: kube-nginx
  annotations:
spec:
  hostNetwork: true
  dnsPolicy: ClusterFirstWithHostNet
  nodeSelector:
    beta.kubernetes.io/os: linux
  priorityClassName: system-node-critical
  containers:
  - name: nginx-proxy
    image: docker.io/library/nginx:1.17
    imagePullPolicy: IfNotPresent
    resources:
      requests:
        cpu: 25m
        memory: 32M
    securityContext:
      privileged: true
    livenessProbe:
      httpGet:
        path: /healthz
        port: 8081
    readinessProbe:
      httpGet:
        path: /healthz
        port: 8081
    volumeMounts:
    - mountPath: /etc/nginx
      name: etc-nginx
      readOnly: true
  volumes:
  - name: etc-nginx
    hostPath:
      path: /etc/nginx

修改 kubelet 配置文件，将 Server 字段替换为 127.0.0.1:6443 ，启动 kubelet 和 docker 即可。

配置修改

最开始我以为到这里就结束了，结果在自己测试的过程中，发现了一点问题，使用 kubeadm 部署集群，在添加 ControlPlane 的时候，会将 kubelet 所连接的 APIServer 配置为 controlPlaneEndpoint 地址，这在没有 LB 的场景下是致命的，单点故障。

所以我们需要依次的修改所有节点的 kubelet 配置，修改内容如下：

ControlPlane

因为所有的 ControlPlane 节点都会自己运行 APIServer，那么 kubelet 连接自身即可。

Worker

Worker 节点因为没有 APIServer，所以我们刚刚通过配置本地的 Proxy 来达到相同的目的，这里无需再次修改。

总结

到这里我们的集群已经配置完成了，无论是 ControlPlane 节点故障，还是 Worker 节点故障，都不是单点的，可以起到高可用的作用。这种方式其实是没有 LB 的一种妥协，这里引用 Kubespray 关于 HA 模式的文档：

K8s components require a loadbalancer to access the apiservers via a reverse proxy. Kubespray includes support for an nginx-based proxy that resides on each non-master Kubernetes node. This is referred to as localhost loadbalancing. It is less efficient than a dedicated load balancer because it creates extra health checks on the Kubernetes apiserver, but is more practical for scenarios where an external LB or virtual IP management is inconvenient.

如果有 LB 肯定还是优先 LB 的，但是在没有 LB 的情况下我们如何选择，就看我们自己的场景了，如果真的是自建 Keepalived & HAProxy ，那么之后的集群管理是一个很麻烦的事情，而且 Keepalived 在使用上没有那么的友好，尤其是网络环境复杂之后（我之前碰到过一次 ovs & keepalived 不工作的情况）。

目前社区中关于 K8S 生命周期管理的工具越来越多，但是如果仔细看看，其实大家的做法都是大同小异。还是要自己了解一下具体的问题点在哪里，如何解决才是硬道理。

参考链接

发表于 |

背景

在做节点管理时，经常面临节点自动扫描，自动关联等功能，这时候需要 NDP 来帮助我们来完成，关于 NDP 的实现有几种方式，今天来聊一下这个。

邻居发现协议（NDP）

引用维基百科的介绍：

The Neighbor Discovery Protocol (NDP, ND)[1] is a protocol in the Internet protocol suite used with Internet Protocol Version 6 (IPv6). It operates at the link layer of the Internet model (RFC 1122), and is responsible for gathering various information required for internet communication, including the configuration of local connections and the domain name servers and gateways used to communicate with more distant systems.[2]

这里有两点需要关注：

  1. 与 IPv6 一起使用
  2. 工作在数据链路层（link layer）

IPv6 地址

在 IPv6 中，无论我们的网络环境是否存在 DHCP Server，我们只要配置网卡启动 IPv6 选项，将网卡置为 active 状态，就能获取到对应的 IPv6 地址，这是因为 IPv6中支持 IP 自动配置，大概流程如下：

  1. 根据 MAC 地址产生链路本地地址（link-local address）
  2. 发出邻居发现请求，进行重复地址检测，如果重复，则停止配置
  3. 链路本地地址生效，发送路由请求报文（RS）

单播地址

单播地址中又分为三类：

  1. 可聚合的全局单播地址，相当于公网 IPv4 地址
  2. 链路本地地址，相当于IPv4里面的169.254.0.0/16地址，一般自动生成
  3. 独特本地单播地址

组播地址

IPv6 常用组播地址 IPv4 常用组播地址 组播组
节点-本地范围 节点-本地范围 节点-本地范围
FF01::1 224.0.0.1 所有-节点地址
FF01::2 224.0.0.2 所有-路由器地址
链路-本地范围 链路-本地范围 链路-本地范围
FF02::1 224.0.0.1 所有-节点地址
FF02::2 224.0.0.2 所有-路由器地址
FF02::5 224.0.0.5 OSPF IGP
FF02::6 224.0.0.6 OSPF IGP DR

任播地址

在 IPv6 中，没有广播的概念，而是使用任播代替。在任播中，网络地址与网络节点之前存在一对多的关系：每一个地址对应一群接收节点，但是在任何给定时间，只有其中之一可以接收到传送端发来的信息。

邻居发现协议 NDP 是 IPv6 协议体系中一个重要的基础协议，替代了IPv4的 ARP 和 ICMP 路由器发现，定义了使用 ICMPv6 报文实现地址解析、跟踪邻居状态、重复地址检测、路由器发现以及重定向等功能。

IPv6 地址发现

因为我本人也没有完整阅读过相应 RFC 文档，在这里也不详细描述每个报文的具体格式及每个字段是什么意思了，直接看看怎么实现。

ping6 & 组播

如果我们知道了一个主机的 IPv6 地址，我们可以通过 ping6 来检测是否联通：

1
2
3
4
5
6
7
8
9
root@localhost:/tmp/nnn
 $ ping6 fe80::5054:ff:fe80:95d9%eth0
PING fe80::5054:ff:fe80:95d9%eth0(fe80::5054:ff:fe80:95d9%eth0) 56 data bytes
64 bytes from fe80::5054:ff:fe80:95d9%eth0: icmp_seq=1 ttl=64 time=0.045 ms
64 bytes from fe80::5054:ff:fe80:95d9%eth0: icmp_seq=2 ttl=64 time=0.055 ms
^C
--- fe80::5054:ff:fe80:95d9%eth0 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 999ms
rtt min/avg/max/mdev = 0.045/0.050/0.055/0.005 ms

那么有了这个 ping6 命令和上面提到的组播地址，我们就可以通过 ping6 直接 ping 组播地址就能知道那些地址可以联通了，那么应该选择哪个？应该选择 FF01::1 ，因为我们想要实现的是获取 IPv6 地址：

1
2
3
4
5
6
7
8
root@localhost:/tmp/nnn
 $ ping6 -c1 -I eth0 'ff02::1%eth0'
PING ff02::1%eth0(ff02::1%eth0) from fe80::5054:ff:fe80:95d9%eth0 eth0: 56 data bytes
64 bytes from fe80::5054:ff:fe80:95d9%eth0: icmp_seq=1 ttl=64 time=0.045 ms

--- ff02::1%eth0 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.045/0.045/0.045/0.000 ms

因为我的实验环境里节点太多，这里使用 -c 参数限制发送 ECHO_REQUEST 包的数量为 1。

在发送组播之后，如果能够联通，那么系统会记录对应的 ARP 信息，我们可以通过 ip 命令直接获取：

1
2
3
4
5
6
7
root@localhost:/tmp/nnn
 $ ip -6 neighbor show dev eth0 | head -n 5
fe80::8c6e:a0ff:fe19:f146 lladdr 8e:6e:a0:19:f1:46 DELAY
fe80::8010:f1ff:fe02:af40 lladdr 82:10:f1:02:af:40 DELAY
fe80::baca:3aff:feec:fdac lladdr b8:ca:3a:ec:fd:ac DELAY
fe80::f11c:e35a:912:dbc9 lladdr 52:54:00:0a:b3:fc DELAY
fe80::570d:aa51:dc3b:1f02 lladdr 00:50:56:9b:f6:6c DELAY

这样就拿到了自己节点在二层联通的所有 IPv6 地址了。

Nmap

既然已经使用了 ping6，那么可以使用一些更高级的工具，比如 Nmap，Nmap可以检测目标主机是否在线、端口开放情况、侦测运行的服务类型及版本信息、侦测操作系统与设备类型等信息。 它通常用来评估网络系统安全。

1
2
3
4
5
6
7
8
9
10
11
12
13
root@localhost:/tmp/nnn
 $ nmap -6 "--script=targets-ipv6-multicast-*" | head -n 10

Starting Nmap 6.40 ( http://nmap.org ) at 2019-12-12 07:22 CST
Pre-scan script results:
| targets-ipv6-multicast-echo:
|   IP: fe80::e4a5:4fff:fea7:79af  MAC: e6:a5:4f:a7:79:af  IFACE: eth0
|   IP: fe80::250:56ff:fe85:647e   MAC: 00:50:56:85:64:7e  IFACE: eth0
|   IP: fe80::250:56ff:fe9e:2473   MAC: 00:50:56:9e:24:73  IFACE: eth0
|   IP: fe80::ae53:a418:ca0:83e8   MAC: 00:50:56:9f:43:ca  IFACE: eth0
|   IP: fe80::250:56ff:fe9e:bcb6   MAC: 00:50:56:9e:bc:b6  IFACE: eth0
|   IP: fe80::250:56ff:fe9f:6153   MAC: 00:50:56:9f:61:53  IFACE: eth0
WARNING: No targets were specified, so 0 hosts scanned.

更进一步

往往我们的需求不只是获取到 IP 这么简单，我们现在更进一步，我们要求扫描的结果中与我们预期的版本相同，那么此时就需要与对应节点进行通信了。

HTTP

一个比较简单的实现，就是在目标节点开机的时候自动启动一个 API server，提供一个 Entrypoint，比如：

1
2
3
4
5
6
7
8
9
10
11
12
#!/usr/bin/python

from flask import jsonify
from flask import Flask
app = Flask(__name__)

@app.route('/api/v1/version')
def version():
    return jsonify({"version":"v1.0.0"})

if __name__ == '__main__':
    app.run(host='::', port=5000, debug=True) # 要兼容 IPv6

然后我们可以在得到 IPv6 地址后，通过 curl 或者 Python urllib2 来发送对应的请求：

1
2
3
4
5
root@localhost:/tmp/nnn
 $ curl -g -6 'http://fe80::5054:ff:fe80:95d9%eth0:5000/api/v1/version'
{
  "version": "v1.0.0"
}#
1
2
3
4
>>> import urllib2
>>> res = urllib2.urlopen("http://fe80::5054:ff:fe80:95d9%eth0:5000/api/v1/version")
>>> res.read()
'{\n  "version": "v1.0.0"\n}'

这样虽然可以达到我们想要的效果，但是效率太低了，要先后进行2次操作，一次是扫描对应的 IPv6 地址，一次是得到地址后进行 HTTP 请求。

Socket

我们可以通过 socket 通信来达到类似的效果，与 HTTP 不同的是，我们可以直接使用 socket 发送组播，来进行消息传递，这样上面的两步就可以通过一步来解决了，这里给出对应的 server 和 client 代码示例：

Server

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
import socket
import select
import json


def server():
    try:
        s = socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
        s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
        s.bind(('', 30000))
        s.setblocking(False)
        while True:
            rlist, _, _ = select.select([s], [], [s], 1)
            if rlist:
                string, address = s.recvfrom(20000)
                print string, address
                try:
                    data = json.loads(string)
                except Exception:
                    pass
                owner = data.get("owner")
                if owner == "yiran":
                    info = {"version": "v1.0",
                            "owner": "yiran",
                            "nic": address[0].split("%", 1)[1]}
                    s.sendto(json.dumps(info), address)
    except Exception:
        pass


if __name__ == "__main__":
    server()

Client

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
import json
import select
import socket

from pprint import pprint


def client():
    s= socket.socket(socket.AF_INET6, socket.SOCK_DGRAM)
    s.setsockopt(socket.SOL_SOCKET, socket.SO_RCVBUF, 5000000)
    nics = socket.getaddrinfo("%s%%%s" % ('ff02::1', 'eth0'), 30000, socket.AF_INET6, socket.SOCK_DGRAM)
    data = {"owner": "yiran"}
    string = json.dumps(data)
    results = {}
    for i in range(10):
        for nic in nics:
            _, _, _, _, address = nic
            try:
                s.sendto(string, address)
            except Exception:
                pass

        rlist, _, _ = select.select([s], [], [s], 1)
        if rlist:
            json_string, address = s.recvfrom(10000)
            results[address] = json_string

    s.close()
    ips = []
    for address, json_test in results.iteritems():
        try:
            data = json.loads(json_test)
            if data.get("version", None) == "v1.0":
                info = {}
                info['ipv6_address'] = address[0]
                info['test'] = data

                ips.append(info)
        except Exception:
            pass

    return ips


if __name__ == "__main__":
    pprint(client())

参考链接

发表于 |

年终总结

  • 2016
    • 计划读 5 本，实际读 13 本。
  • 2017
    • 计划 32 本，实际读完 23 本。
  • 2018
    • 计划 30 本，实际25本。
  • 2019
    • 计划 30 本，实际 43 本。

今年是第 4 年写读书记录了，感觉手上这本 TLPI 年底之前是看不完了，就总结一下。与之前不同的是今年把周末的时间利用的比较好，通常周末两天会拿出一整天的时间来看书，保证自己的精力集中，效率会高很多。

因为博客集成了豆瓣，所以就不列出 在读 和 想读 列表了，想的太多，耽误事。希望接下来读一些经典的技术书，把自己的基础知识补齐。

已读

  1. 《用Python写网络爬虫》
  2. 《Wireshark网络分析就这么简单》
  3. 《如何有效阅读一本书 : 超实用笔记读书法》
  4. 《冷场》
  5. 《Go程序设计语言》
  6. 《爱你就像爱生命》
  7. 《Go by Example》
  8. 《显微镜下的大明》
  9. 《流浪地球》
  10. 《情感勒索》
  11. 《Go语言实战》
  12. 《活着》
  13. 《悉达多》
  14. 《Go in Practice》
  15. 《奈飞文化手册》
  16. 《刻意练习》
  17. 《软件测试的艺术》
  18. 《Redis实战》
  19. 《雪崩》
  20. 《TCP/IP详解 卷1：协议》
  21. 《Structure and Interpretation of Computer Programs - 2nd Edition (MIT)》
  22. 《编码的奥秘》
  23. 《Kubernetes in Action》
  24. 《计算机组成：结构化方法》
  25. 《人月神话》
  26. 《自己动手写Docker》
  27. 《好文案一句话就够了》
  28. 《跟老男孩学Linux运维：Web集群实战》
  29. 《计算机组成与设计》
  30. 《简约至上》
  31. 《Go Web编程》
  32. 《大话数据结构》
  33. 《Python Web开发实战》
  34. 《Programming Kubernetes》
  35. 《Istio入门与实战》
  36. 《刷新》
  37. 《奇特的一生》
  38. 《图解密码技术（第3版）》
  39. 《细节》
  40. 《生活大爆炸里的科学》
  41. 《操作系统导论》
  42. 《RESTful Web APIs中文版》
  43. 《正则表达式必知必会》

发表于 |

背景

工作上使用的电脑因为各种各样的原因，被我安装为 Ubuntu 19.04，平时使用上没什么问题，但是最近发现它默认的 SSH 配置随着版本升级发生了变化，known_hosts 文件中记录的不再是 IP 地址，而是一串字符，这导致了当我想要删除某个主机的 key 时，无法准确的找到，因此想办法解决这个事情。

SSH

我们使用 Linux 系统的一个最基本的服务应该就是 SSH 了，除了偶尔我们通过 VNC 或者 KVM(Keyboard Virtual Manager)连接控制主机外，都是通过 SSH 到 Linux 主机上进行某些操作。那么 SSH 就是 Secure Shell，安全外壳协议。可在不安全的网络中为网络服务提供安全的传输环境。SSH 通过在网络中建立安全隧道来实现SSH客户端与服务器之间的连接。

SSH 最重要的就是安全，采用的是非对称加密，关于加密相关的部分，可以看我之前写的一篇《图解密码技术》读书笔记 里面有比较完整的相关知识。

这里主要说一下使用密码登陆和密钥登陆的流程。

密码登陆

  1. 客户端向服务端发起连接请求
1
2
3
4
root@test-hostname-ubuntu-s-1804:~# ssh 192.168.67.90
The authenticity of host '192.168.67.90 (192.168.67.90)' can't be established.
ECDSA key fingerprint is SHA256:ca9Zk/7pR4f6rrNP3wi1WK+CQMtG4Ka+kkouwQYU0nY.
Are you sure you want to continue connecting (yes/no)?
  1. 客户端会提示，知道服务端的唯一标示，确认连接么
  2. 确认连接，输入 yes
1
2
3
4
5
6
root@test-hostname-ubuntu-s-1804:~# ssh 192.168.67.90
The authenticity of host '192.168.67.90 (192.168.67.90)' can't be established.
ECDSA key fingerprint is SHA256:ca9Zk/7pR4f6rrNP3wi1WK+CQMtG4Ka+kkouwQYU0nY.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.67.90' (ECDSA) to the list of known hosts.
root@192.168.67.90's password:
  1. 服务端传输公钥给客户端，客户端输入密码，使用服务端公钥加密并发送给服务端
  2. 服务端使用私钥解密，验证密码正确，登陆成功
1
2
3
4
5
6
7
8
root@test-hostname-ubuntu-s-1804:~# ssh 192.168.67.90
The authenticity of host '192.168.67.90 (192.168.67.90)' can't be established.
ECDSA key fingerprint is SHA256:ca9Zk/7pR4f6rrNP3wi1WK+CQMtG4Ka+kkouwQYU0nY.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.67.90' (ECDSA) to the list of known hosts.
root@192.168.67.90's password:
Last login: Fri Dec  6 21:51:00 2019 from 192.168.73.54
[root@node90 22:30:29 ~]$

密钥登陆

  1. 客户端向服务端发起连接请求
  2. 服务端收到客户端的请求，找到对应客户端的公钥，生成随机数
  3. 服务端使用客户端的公钥对随机数进行加密，发送给客户端
  4. 客户端使用私钥进行解密，得到随机数，并将随机数与 session key 拼接，并将结果通过 MD5 算出散列值
  5. 服务端同样使用随机数与 session key 拼接，并将结果通过 MD5 算出散列值
  6. 服务端对两个散列值进行校验，如果想通，则登陆成功

相关文件

~/.ssh/id_rsa

当前节点生成的私钥，使用 RSA 算法。

~/.ssh/id_rsa.pub

当前节点生成的公钥，使用 RSA 算法，与 id_rsa 成对出现。

~/.ssh/authorized_keys

用于保存已经授权（信任）的客户端公钥。

~/.ssh/known_hosts

known_hosts 中存放 SSH 自动维护并检查的一个数据库，该数据库包含曾经连接过的所有主机的标识。

这个文件也是今天的主角。

known_hosts

当我们客户端尝试连接服务端，会有一条提示，服务端主机的唯一标示是xxx，确认连接么，如果输入yes，那么这个主机的标示就会记录到 known_hosts，一般我们的 known_hosts 会长这样：

1
2
root@test-hostname-ubuntu-s-1804:~# cat .ssh/known_hosts
|1|+YgY28AEikbKxdosHK1Cxb6zJqs=|yEi41f2MIl6hU9uQOvXyzK0hByM= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHJscGQ4nUV7b7+nUtHVFPgm38JrUJwMapVqkq+oF1RR7mniCGhrkIGpb2cqKINrcZFyKFRqWhuAgYtMyFALOrM=

或者长这样：

1
2
3
root@yiran-30-250:~
   head -n 1 .ssh/known_hosts
192.168.70.250 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHNWt8CDe7sPvATsqx5zH5v9wJzYrFhu9fmYnshIYLEnuoXmCmVu2cGU8s/IjK2jU8hnFad4T1gMhst7cXLmqAo=

了解 https 相关知识的同学应该知道，证书的重要性。在 SSH 场景下，我们没有证书，那么就需要我们自己人为的确保我们要连接的服务端是可信的。如果我们第一次登陆 192.168.1.1 后，系统保存了主机唯一标示到了 ~/.ssh/known_hosts，如果我们下一次登陆 192.168.1.1 客户端发现主机唯一标示产生了变化，那么就会禁止我们登陆了。

在工作中经常遇到这种场景，可能的原因有很多：系统重装、快照回滚、IP 冲突等等。通常我们的做法就是闭着眼睛删除 known_hosts 里面的对应主机信息，然后重新登陆就可以了。

但是最近发现 Ubuntu 19.04 中记录的 known_hosts 是这样的：

1
2
root@test-hostname-ubuntu-s-1804:~# cat .ssh/known_hosts
|1|+YgY28AEikbKxdosHK1Cxb6zJqs=|yEi41f2MIl6hU9uQOvXyzK0hByM= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHJscGQ4nUV7b7+nUtHVFPgm38JrUJwMapVqkq+oF1RR7mniCGhrkIGpb2cqKINrcZFyKFRqWhuAgYtMyFALOrM=

是的，我们无法在一堆看似乱码中找到我们想要的主机并删掉它，这其实是 OpenSSH 新版本中的一项安全改进。

在 记一次系统被入侵分析过程 博客中有提到，现在好多病毒在入侵之后都是通过 SSH 相关信息进行横向扩散的，所以我们应该尽可能的少在系统中保存明文的 IP 地址相关信息。

但是对我测试环境来说，是没什么关系的，因此我需要禁止这个安全配置，来达到我的目的。

正确的姿势是修改 SSH 客户端的配置，将 HashKnownHosts 置为 no ，清空 known_hosts 文件，再连接服务端，就可以看到 known_hosts 已经显示 IP 地址了。

1
2
3
4
root@test-hostname-ubuntu-s-1804:~# cat /etc/ssh/ssh_config |grep -i hash
    HashKnownHosts no
root@test-hostname-ubuntu-s-1804:~# cat .ssh/known_hosts
192.168.67.90 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBHJscGQ4nUV7b7+nUtHVFPgm38JrUJwMapVqkq+oF1RR7mniCGhrkIGpb2cqKINrcZFyKFRqWhuAgYtMyFALOrM=

当然如果你想搞破坏，可以尝试下这篇博客中提供的脚本：https://blog.rootshell.be/wp-content/uploads/2010/11/known_hosts_bruteforcer.pl.txt （谨慎使用）

参考链接