标签 k8s 下的文章

Hello，WireGuard

2020年1月28日，Linux之父Linus Torvalds正式将WireGuard merge到Linux 5.6版本内核主线：

img{512x368}

图：WireGuard被加入linux kernel 5.6主线的commit log

这意味着在Linux 5.6内核发布时，linux在内核层面将原生支持一个新的VPN协议栈：WireGuard。

img{512x368}

图：WireGuard Logo

一. VPN与WireGuard的创新

VPN，全称Virtual Private Network（虚拟专用网络）。提起VPN，大陆的朋友想到的第一件事就是fan qiang。其实fan qiang只是VPN的一个“小众”应用罢了^_^，企业网络才是VPN真正施展才能的地方。VPN支持在不安全的公网上建立一条加密的、安全的到企业内部网络的通道（隧道tunnel），这就好比专门架设了一个专用网络那样。在WireGuard出现之前，VPN的隧道协议主要有PPTP、L2TP和IPSec等，其中PPTP和L2TP协议工作在OSI模型的第二层，又称为二层隧道协议；IPSec是第三层隧道协议。

既然已经有了这么多的VPN协议，那么Why WireGuard？

WireGuard的作者Jason A. Donenfeld在WireGuard官网给出了很明确地理由：

  • 简单、易用、无连接、无状态：号称目前最易用和最简单的VPN解决方案

WireGuard可以像SSH一样易于配置和部署。只需交换非常简单的公钥就可以建立VPN连接，就像交换SSH密钥一样，其余所有由WireGuard透明处理。并且WireGuard建立的VPN连接是基于UDP的，无需建立和管理连接，无需关心和管理状态的。

  • 先进加密协议

WireGuard充分利用安全领域和密码学在这些年的最新成果，使用noise framework，Curve25519，ChaCha20，Poly1305，BLAKE2，SipHash24等构建WireGuard的安全方案。

  • 最小的攻击面(最少代码实现)

WireGuard的内核模块c代码仅不足5k行，便于代码安全评审。也使得WireGuard的实现更不容易被攻击（代码量少，理论上漏洞相对于庞大的代码集合而言也会少许多）。

  • 高性能

密码学最新成果带来的高速机密原语和WireGuard的内核驻留机制，使其相较于之前的VPN方案更具性能优势。

以上这些理由，同时也是WireGuard这个协议栈的特性。

这么说依然很抽象，我们来实操一下，体验一下WireGuard的简洁、易用、安全、高效。

二. WireGuard安装和使用

WireGuard将在linux 5.6内核中提供原生支持，也就是说在那之前，我们还无法直接使用WireGuard，安装还是不可避免的。在我的实验环境中有两台Linux VPS主机，都是ubuntu 18.04，内核都是4.15.0。因此我们需要首先添加WireGuard的ppa仓库：

sudo add-apt-repository ppa:wireguard/wireguard

更新源后，即可通过下面命令安装WireGuard：

sudo apt-get update

sudo apt-get install wireguard

安装的WireGuard分为两部分：

  • WireGuard内核模块(wireguard.ko)，这部分通过动态内核模块技术DKMS安装到ubuntu的内核模块文件目录下：
$ ls /lib/modules/4.15.0-29-generic/updates/dkms/
wireguard.ko
  • 用户层的命令行工具

类似于内核netfilter和命令行工具iptables之间关系，wireguard.ko对应的用户层命令行工具wireguard-tools：wg、wg-quick被安装到/usr/bin下面了：

$ ls -t /usr/bin|grep wg|head -n 2
wg
wg-quick

1. peer to peer vpn

在两个linux Vps上都安装完WireGuard后，我们就可以在两个节点(peer)建立虚拟专用网络(VPN)了。我们分为称两个linux节点为peer1和peer2：

img{512x368}

图：点对点wireguard通信图

就像上图那样，我们只分别需要在peer1和peer2建立/etc/wireguard/wg0.conf。

peer1的/etc/wireguard/wg0.conf：

[Interface]
PrivateKey = {peer1's privatekey}
Address = 10.0.0.1
ListenPort = 51820

[Peer]
PublicKey = {peer2's publickey}
EndPoint = {peer2's ip}:51820
AllowedIPs = 10.0.0.2/32

peer2的/etc/wireguard/wg0.conf：

[Interface]
PrivateKey = {peer2's privatekey}
Address = 10.0.0.2
ListenPort = 51820

[Peer]
PublicKey = {peer1's publickey}
EndPoint = {peer1's ip}:51820
AllowedIPs = 10.0.0.1/32

我们看到每个peer上WireGuard所需的配置文件wg0.conf包含两大部分：

  • [Interface]部分

    • PrivateKey – peer自身的privatekey

    • Address – peer的wg0接口在vpn网络中绑定的路由ip范围，在上述例子中仅绑定了一个ip地址

    • ListenPort – wg网络协议栈监听UDP端口

  • [Peer]部分（描述vpn网中其他peer信息，一个wg0配置文件中显然可以配置多个Peer部分）

    • PublicKey – 该peer的publickey

    • EndPoint – 该peer的wg网路协议栈地址(ip+port)

    • AllowedIPs – 允许该peer发送过来的wireguard载荷中的源地址范围。同时本机而言，这个字段也会作为本机路由表中wg0绑定的ip范围。

每个Peer自身的privatekey和publickey可以通过WireGuard提供的命令行工具生成：

$ wg genkey | tee privatekey | wg pubkey > publickey
$ ls
privatekey  publickey

注：这两个文件可以生成在任意路径下，我们要的是两个文件中内容。

在两个peer上配置完/etc/wireguard/wg0.conf配置文件后，我们就可以使用下面命令在peer1和peer2之间建立一条双向加密VPN隧道了：

peer1:

$ sudo wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.0.0.1 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] ip -4 route add 10.0.0.2/32 dev wg0

peer2:

$ sudo wg-quick up wg0
[#] ip link add wg0 type wireguard
[#] wg setconf wg0 /dev/fd/63
[#] ip -4 address add 10.0.0.2 dev wg0
[#] ip link set mtu 1420 up dev wg0
[#] ip -4 route add 10.0.0.1/32 dev wg0

执行上述命令，每个peer会增加一个network interface dev: wg0，并在系统路由表中增加一条路由，以peer1为例：

$ ip a

... ...

4: wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.0.0.1/32 scope global wg0
       valid_lft forever preferred_lft forever

$ ip route
default via 172.21.0.1 dev eth0 proto dhcp metric 100
10.0.0.2 dev wg0 scope link
... ...

现在我们来测试两个Peer之间的连通性。WireGuard的peer之间是对等的，谁发起的请求谁就是client端。我们在peer1上ping peer2，在peer2上我们用tcpdump抓wg0设备的包：

Peer1:

$ ping -c 3 10.0.0.2
PING 10.0.0.2 (10.0.0.2) 56(84) bytes of data.
64 bytes from 10.0.0.2: icmp_seq=1 ttl=64 time=34.9 ms
64 bytes from 10.0.0.2: icmp_seq=2 ttl=64 time=34.7 ms
64 bytes from 10.0.0.2: icmp_seq=3 ttl=64 time=34.6 ms

--- 10.0.0.2 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 34.621/34.781/34.982/0.262 ms

Peer2:

# tcpdump -i wg0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wg0, link-type RAW (Raw IP), capture size 262144 bytes
13:29:52.659550 IP 10.0.0.1 > instance-cspzrq3u: ICMP echo request, id 20580, seq 1, length 64
13:29:52.659603 IP instance-cspzrq3u > 10.0.0.1: ICMP echo reply, id 20580, seq 1, length 64
13:29:53.660463 IP 10.0.0.1 > instance-cspzrq3u: ICMP echo request, id 20580, seq 2, length 64
13:29:53.660495 IP instance-cspzrq3u > 10.0.0.1: ICMP echo reply, id 20580, seq 2, length 64
13:29:54.662201 IP 10.0.0.1 > instance-cspzrq3u: ICMP echo request, id 20580, seq 3, length 64
13:29:54.662234 IP instance-cspzrq3u > 10.0.0.1: ICMP echo reply, id 20580, seq 3, length 64

我们看到peer1和peer2经由WireGuard建立的vpn实现了连通：在peer2上ping peer1(10.0.0.1)亦得到相同结果。

这时如果我们如果在peer2(vpn ip: 10.0.0.2)上启动一个http server(监听0.0.0.0:9090):

//httpserver.go
package main

import "net/http"

func index(w http.ResponseWriter, r *http.Request) {
    w.Write([]byte("hello, wireguard\n"))
}

func main() {
    http.Handle("/", http.HandlerFunc(index))
    http.ListenAndServe(":9090", nil)
}

那么我们在peer1(vpn ip:10.0.0.1)去访问这个server：

$ curl http://10.0.0.2:9090
hello, wireguard

在peer2(instance-cspzrq3u)上的tcpdump显示(tcp握手+数据通信+tcp拆除)：

14:15:05.233794 IP 10.0.0.1.43922 > instance-cspzrq3u.9090: Flags [S], seq 1116349511, win 27600, options [mss 1380,sackOK,TS val 3539789774 ecr 0,nop,wscale 7], length 0
14:15:05.233854 IP instance-cspzrq3u.9090 > 10.0.0.1.43922: Flags [S.], seq 3504538202, ack 1116349512, win 27360, options [mss 1380,sackOK,TS val 2842719516 ecr 3539789774,nop,wscale 7], length 0
14:15:05.268792 IP 10.0.0.1.43922 > instance-cspzrq3u.9090: Flags [.], ack 1, win 216, options [nop,nop,TS val 3539789809 ecr 2842719516], length 0
14:15:05.268882 IP 10.0.0.1.43922 > instance-cspzrq3u.9090: Flags [P.], seq 1:78, ack 1, win 216, options [nop,nop,TS val 3539789809 ecr 2842719516], length 77
14:15:05.268907 IP instance-cspzrq3u.9090 > 10.0.0.1.43922: Flags [.], ack 78, win 214, options [nop,nop,TS val 2842719551 ecr 3539789809], length 0
14:15:05.269514 IP instance-cspzrq3u.9090 > 10.0.0.1.43922: Flags [P.], seq 1:134, ack 78, win 214, options [nop,nop,TS val 2842719552 ecr 3539789809], length 133
14:15:05.304147 IP 10.0.0.1.43922 > instance-cspzrq3u.9090: Flags [.], ack 134, win 224, options [nop,nop,TS val 3539789845 ecr 2842719552], length 0
14:15:05.304194 IP 10.0.0.1.43922 > instance-cspzrq3u.9090: Flags [F.], seq 78, ack 134, win 224, options [nop,nop,TS val 3539789845 ecr 2842719552], length 0
14:15:05.304317 IP instance-cspzrq3u.9090 > 10.0.0.1.43922: Flags [F.], seq 134, ack 79, win 214, options [nop,nop,TS val 2842719586 ecr 3539789845], length 0
14:15:05.339035 IP 10.0.0.1.43922 > instance-cspzrq3u.9090: Flags [.], ack 135, win 224, options [nop,nop,TS val 3539789880 ecr 2842719586], length 0

如果要拆除这个vpn，只需在每个peer上分别执行如下命令：

$ sudo wg-quick down wg0
[#] ip link delete dev wg0

2. peer to the local network of other peer

上面两个peer虽然实现了点对点的连通，但是如果我们想从peer1访问peer2所在的局域网中的另外一台机器（这显然是vpn最常用的应用场景），如下面示意图：

img{512x368}

图：从一个peer到另外一个peer所在局域网的节点的通信图

基于目前的配置是否能实现呢？我们来试试。首先我们在peer1上要将192.168.1.0/24网段的路由指到wg0上，这样我们在peer1上ping或curl 192.168.1.123:9090，数据才能被交给wg0处理并通过vpn网络送出，修改peer1上的wg0.conf：

// peer1's /etc/wireguard/wg0.conf

... ...
[Peer]
PublicKey = {peer2's publickey}
EndPoint = peer2's ip:51820
AllowedIPs = 10.0.0.2/32,192.168.1.0/24

重启peer1上的wg0使上述配置生效。然后我们尝试在peer1上ping 192.168.1.123：

$ ping -c 3 192.168.1.123
PING 192.168.1.123 (192.168.1.123) 56(84) bytes of data.

--- 192.168.1.123 ping statistics ---
3 packets transmitted, 0 received, 100% packet loss, time 2038ms

我们在peer2上的tcpdump显示：

# tcpdump -i wg0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wg0, link-type RAW (Raw IP), capture size 262144 bytes
14:33:38.393520 IP 10.0.0.1 > 192.168.1.123: ICMP echo request, id 30426, seq 1, length 64
14:33:39.408083 IP 10.0.0.1 > 192.168.1.123: ICMP echo request, id 30426, seq 2, length 64
14:33:40.432079 IP 10.0.0.1 > 192.168.1.123: ICMP echo request, id 30426, seq 3, length 64

我们看到peer2收到来自10.0.0.1的到192.168.1.123的ping包都没有对应的回包，通信失败。Why？我们分析一下。

peer2在51820端口收到WireGuard包后，去除wireguard包的包裹，露出真实数据包。真实数据包的目的ip地址为192.168.1.123，该地址并非peer2自身地址(其自身局域网地址为192.168.1.10)。既然不是自身地址，就不能送到上层协议栈(tcp)处理，那么另外一条路是forward(转发)出去。但是是否允许转发么？显然从结果来看，从wg0收到的消息无权转发，于是消息丢弃，这就是没有回包和通信失败的原因。

为了支持转发（这是vpn常用场景的功能哦），我们需要为peer2的wg0.conf增加些转发配置：

// peer2's  wg0.conf

[Interface]

... ...
PostUp   = iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT; iptables -t nat -A POSTROUT  ING -o eth0 -j MASQUERADE
PostDown = iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT; iptables -t nat -D POSTROUT  ING -o eth0 -j MASQUERADE

... ...

重启peer2的wg0。在peer2的内核层我们也要开启转发开关：

// /etc/sysctl.conf

net.ipv4.ip_forward=1

net.ipv6.conf.all.forwarding=1

执行下面命令临时生效：

# sysctl -p
net.ipv4.ip_forward = 1
net.ipv6.conf.all.forwarding = 1

接下来，我们再来测试一下连通性。我们在peer1上再次尝试ping 192.168.1.123：

$ ping -c 3 192.168.1.123
PING 192.168.1.123 (192.168.1.123) 56(84) bytes of data.
64 bytes from 192.168.1.123: icmp_seq=1 ttl=46 time=200 ms
64 bytes from 192.168.1.123: icmp_seq=2 ttl=46 time=200 ms
64 bytes from 192.168.1.123: icmp_seq=3 ttl=46 time=200 ms

--- 192.168.1.123 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 200.095/200.239/200.396/0.531 ms

这回通了！peer2上的Tcpdump输出中也看到了回包：

14:49:58.808467 IP 10.0.0.1 > 192.168.1.123: ICMP echo request, id 402, seq 1, length 64
14:49:58.974035 IP 192.168.1.123 > 10.0.0.1: ICMP echo reply, id 402, seq 1, length 64
14:49:59.809747 IP 10.0.0.1 > 192.168.1.123: ICMP echo request, id 402, seq 2, length 64
14:49:59.975240 IP 192.168.1.123 > 10.0.0.1: ICMP echo reply, id 402, seq 2, length 64
14:50:00.810802 IP 10.0.0.1 > 192.168.1.123: ICMP echo request, id 402, seq 3, length 64
14:50:00.976202 IP 192.168.1.123 > 10.0.0.1: ICMP echo reply, id 402, seq 3, length 64

我们在192.168.1.123上运行上面的那个httpserver程序，再在peer1上用curl访问这个程序：

$ curl 192.168.1.123:9090
hello, wireguard

我们看到httpserver的应答成功返回。peer2上的tcpdump也抓到了整个通信过程：

14:50:36.437259 IP 10.0.0.1.47918 > 192.168.1.123.9090: Flags [S], seq 3235649864, win 27600, options [mss 1380,sackOK,TS val 101915019 ecr 0,nop,wscale 7], length 0
14:50:36.593554 IP 192.168.1.123.9090 > 10.0.0.1.47918: Flags [S.], seq 2420552016, ack 3235649865, win 28960, options [mss 1460,sackOK,TS val 2323314775 ecr 101915019,nop,wscale 7], length 0
14:50:36.628315 IP 10.0.0.1.47918 > 192.168.1.123.9090: Flags [.], ack 1, win 216, options [nop,nop,TS val 101915210 ecr 2323314775], length 0
14:50:36.628379 IP 10.0.0.1.47918 > 192.168.1.123.9090: Flags [P.], seq 1:84, ack 1, win 216, options [nop,nop,TS val 101915210 ecr 2323314775], length 83
14:50:36.784550 IP 192.168.1.123.9090 > 10.0.0.1.47918: Flags [.], ack 84, win 227, options [nop,nop,TS val 2323314822 ecr 101915210], length 0
14:50:36.784710 IP 192.168.1.123.9090 > 10.0.0.1.47918: Flags [P.], seq 1:134, ack 84, win 227, options [nop,nop,TS val 2323314822 ecr 101915210], length 133
14:50:36.820339 IP 10.0.0.1.47918 > 192.168.1.123.9090: Flags [.], ack 134, win 224, options [nop,nop,TS val 101915401 ecr 2323314822], length 0
14:50:36.820383 IP 10.0.0.1.47918 > 192.168.1.123.9090: Flags [F.], seq 84, ack 134, win 224, options [nop,nop,TS val 101915401 ecr 2323314822], length 0
14:50:36.977226 IP 192.168.1.123.9090 > 10.0.0.1.47918: Flags [F.], seq 134, ack 85, win 227, options [nop,nop,TS val 2323314870 ecr 101915401], length 0
14:50:37.011927 IP 10.0.0.1.47918 > 192.168.1.123.9090: Flags [.], ack 135, win 224, options [nop,nop,TS val 101915594 ecr 2323314870], length 0

3. WireGuard的用户层实现

在linux上，我们务必使用WireGuard的内核模式，这显然是最高效的。在macOS、Windows上，WireGuard无法以内核模块驻留模式运行，但WireGuard项目提供了WireGuard的用户层实现。其作者Jason A. Donenfeld亲自实现了Go语言版本的wireguard-go。macOS上使用的就是wireguard的Go实现。我们可以使用brew在macOS上按照WireGuard：

$brew install wireguard-tools

配置好/etc/wireguard/wg0.conf后(和linux上的配置方式一致)，同样可以通过wg-quick命令启动wireguard：

$sudo wg-quick up wg0

wg-quick实际上会通过wireguard-go来实现linux wireguard在内核中完成的功能：

$ps -ef|grep wireguard

    0 57783     1   0  3:18下午 ttys002    0:00.01 wireguard-go utun

三. WireGuard性能如何

关于WireGuard性能如何，官方给出了一个性能基准测试的对比数据（相较于其他vpn网络栈）：

img{512x368}

图：WireGuard性能与其他vpn网络栈的对比（来自官方截图）

我们看到和IPSec、OpenVPN相比，无论从吞吐还是延迟，WireGuard都领先不少。

我们这里用microsoft开源的带宽测试工具ethr来直观看一下走物理网络和走WireGuard VPN的带宽差别。

在peer2上运行：

$ ethr -s

然后在peer1上分别通过物理网络和VPN网络向peer2发起请求：

  • peer1 -> peer2 (物理网络)
$ ethr -c  peer2's ip
Connecting to host [peer2 ip], port 9999
[  6] local 172.21.0.5 port 46108 connected to  peer2 ip port 9999
- - - - - - - - - - - - - - - - - - - - - - -
[ ID]   Protocol    Interval      Bits/s
[  6]     TCP      000-001 sec     1.54M
[  6]     TCP      001-002 sec     1.54M
[  6]     TCP      002-003 sec     1.54M
[  6]     TCP      003-004 sec     1.54M
[  6]     TCP      004-005 sec     1.54M

.... ...
  • peer1 -> peer2 (vpn网络)
$ ethr -c 10.0.0.2
Connecting to host [10.0.0.2], port 9999
[  6] local 10.0.0.1 port 36010 connected to 10.0.0.2 port 9999
- - - - - - - - - - - - - - - - - - - - - - -
[ ID]   Protocol    Interval      Bits/s
[  6]     TCP      000-001 sec     1.79M
[  6]     TCP      001-002 sec      640K
[  6]     TCP      002-003 sec     1.15M
[  6]     TCP      003-004 sec      512K
[  6]     TCP      004-005 sec     1.02M
[  6]     TCP      005-006 sec     1.02M
[  6]     TCP      006-007 sec     1.02M

我们看到走vpn的带宽相当于走物理网络的66%(1.02/1.54)左右。这里peer1(腾讯云)、peer2(百度云)之间走的是互联网，而在局域网测试的效果可能更好（留给大家^_^）。

四. 小结

经过上面的实验，我们看到了WireGuard的配置的确十分简单，这也是我目前使用过的配置过程最为简单的vpn。随着linux kernel 5.6内置对WireGuard的原生支持，WireGuard在vpn领域势必会有更为广泛的应用。

在容器网络方面，目前WireGuard已经给出了跨容器的网络通信方案，基于wireguard的k8s cni网络插件wormhole可以让pod之间通过wireguard实现的overlay网络通信。

国外的tailscale公司正在实现一种基于Wireguard的mesh vpn网络，该网络以WireGuard为数据平面的承载体，该公司主要实现控制平面。该公司目前聚集了一些Go核心开发人员，这里就包括著名的go核心开发团队成员、net/http包的最初作者和当前维护者的Brad Fitzpatrick。

五. 参考资料

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网上线了，感谢小伙伴们学习支持！

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/
smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite

微信赞赏：
img{512x368}

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

Kubernetes Deployment故障排除图解指南

img{512x368}

下面是一个示意图，可帮助你调试Kubernetes Deployment（你可以在此处下载它的PDF版本）。

img{512x368}

当你希望在Kubernetes中部署应用程序时，你通常会定义三个组件：

  • 一个Deployment – 这是一份用于创建你的应用程序的Pod副本的”食谱”；
  • 一个Service – 一个内部负载均衡器，用于将流量路由到内部的Pod上；
  • 一个Ingress – 描述如何流量应该如何从集群外部流入到集群内部的你的服务上。

下面让我们用示意图快速总结一下要点。

img{512x368}

在Kubernetes中，你的应用程序通过两层负载均衡器暴露服务：内部的和外部的

img{512x368}

内部的负载均衡器称为Service，而外部的负载均衡器称为Ingress

img{512x368}

Pod不会直接部署。Deployment会负责创建Pod并管理它们

假设你要部署一个简单的”HelloWorld”应用，该应用的YAML文件的内容应该类似下面这样：

// hello-world.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
      labels:
        any-name: my-app
    spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    name: app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
        serviceName: app
        servicePort: 80
      path: /

这个定义很长，组件之间的相互关系并不容易看出来。

例如：

  • 什么时候应使用端口80，又是何时应使用端口8080？
  • 你是否应该为每个服务创建一个新端口以免它们相互冲突？
  • 标签(label)名重要吗？它们是否在每一处都应该是一样的？

在进行调试之前，让我们回顾一下这三个组件是如何相互关联的。

让我们从Deployment和Service开始。

一. 连接Deployment和Service

令人惊讶的消息是，Service和Deployment之间根本没有连接。

事实是：Service直接指向Pod，并完全跳过了Deployment。

因此，你应该注意的是Pod和Service之间的相互关系。

你应该记住三件事：

  • Service selector应至少与Pod的一个标签匹配；
  • Service的targetPort应与Pod中容器的containerPort匹配；
  • Service的port可以是任何数字。多个Service可以使用同一端口号，因为它们被分配了不同的IP地址。

下面的图总结了如何连接端口：

img{512x368}

考虑上面被一个服务暴露的Pod

img{512x368}

创建Pod时，应为Pod中的每个容器定义containerPort端口

img{512x368}

当创建一个Service时，你可以定义port和targetPort，但是哪个用来连接容器呢？

img{512x368}

targetPort和containerPort应该始终保持匹配

img{512x368}

如果容器暴露3000端口(containerPort)，那么targetPort应该匹配这一个端口号

再来看看YAML，标签和ports/targetPort应该匹配：

// hello-world.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-deployment
  labels:
    track: canary
spec:
  selector:
    matchLabels:
      any-name: my-app
  template:
    metadata:
      labels:
        any-name: my-app
    spec:
      containers:
      - name: cont1
        image: learnk8s/app:1.0.0
        ports:
        - containerPort: 8080
---
apiVersion: v1
kind: Service
metadata:
  name: my-service
spec:
  ports:
  - port: 80
    targetPort: 8080
  selector:
    any-name: my-app

那deployment顶部的track: canary标签呢?

它也应该匹配吗？

该标签属于deployment，service的选择器未使用它来路由流量。

换句话说，你可以安全地删除它或为其分配其他值。

那matchLabels选择器呢？

它必须始终与Pod的标签匹配，并且被Deployment用来跟踪Pod。

假设你已经进行了所有正确的设置，该如何测试它呢？

你可以使用以下命令检查Pod是否具有正确的标签：

$ kubectl get pods --show-labels

或者，如果你拥有属于多个应用程序的Pod：

$ kubectl get pods --selector any-name=my-app --show-labels

any-name=my-app就是标签：any-name: my-app。

还有问题吗？

你也可以连接到Pod！

你可以使用kubectl中的port-forward命令连接到service并测试连接。

$ kubectl port-forward service/<service name> 3000:80
  • service/ 是服务的名称- 在上面的YAML中是“my-service”
  • 3000是你希望在计算机上打开的端口
  • 80是service通过port字段暴露的端口

如果可以连接，则说明设置正确。

如果不行，则很可能是你填写了错误的标签或端口不匹配。

二. 连接Service和Ingress

接下来是配置Ingress以将你的应用暴露到集群外部。

Ingress必须知道如何检索服务，然后检索Pod并将流量路由给它们。

Ingress按名字和暴露的端口检索正确的服务。

在Ingress和Service中应该匹配两件事：

  • Ingress的servicePort应该匹配service的port；
  • Ingress的serviceName应该匹配服务的name。

下面的图总结了如何连接端口：

img{512x368}

你已经知道servive暴露一个port

img{512x368}

Ingress有一个字段叫servicePort

img{512x368}

service的port和Ingress的service应该始终保持匹配

img{512x368}

如果你为service指定的port是80，那么你也应该将ingress的servicePort改为80

实践中，你应该查看以下几行(下面代码中的my-service和80)：

// hello-world.yaml

apiVersion: v1
kind: Service
metadata:
  name: my-service   --- 需关注
spec:
  ports:
  - port: 80       --- 需关注
    targetPort: 8080
  selector:
    any-name: my-app
---
apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: my-ingress
spec:
  rules:
  - http:
    paths:
    - backend:
        serviceName: my-service --- 需关注
        servicePort: 80 --- 需关注
      path: /

你如何测试Ingress是否正常工作呢？

你可以使用与以前相同的策略kubectl port-forward，但是这次你应该连接到Ingress控制器，而不是连接到Service。

首先，使用以下命令检索Ingress控制器的Pod名称：

$ kubectl get pods --all-namespaces
NAMESPACE   NAME                              READY STATUS
kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
kube-system etcd-minikube                     1/1   Running
kube-system kube-apiserver-minikube           1/1   Running
kube-system kube-controller-manager-minikube  1/1   Running
kube-system kube-proxy-zvf2h                  1/1   Running
kube-system kube-scheduler-minikube           1/1   Running
kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

标识Ingress Pod（可能在其他命名空间中）并描述它以检索端口：

$ kubectl describe pod nginx-ingress-controller-6fc5bcc \
 --namespace kube-system \
 | grep Ports
Ports:         80/TCP, 443/TCP, 18080/TCP

最后，连接到Pod：

$ kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

此时，每次你访问计算机上的端口3000时，请求都会转发到Ingress控制器Pod上的端口80。

如果访问http://localhost:3000，则应找到提供网页服务的应用程序。

回顾Port

快速回顾一下哪些端口和标签应该匹配：

  • service selector应与Pod的标签匹配
  • service的targetPort应与Pod中容器的containerPort匹配
  • service的端口可以是任何数字。多个服务可以使用同一端口，因为它们分配了不同的IP地址。
  • ingress的servicePort应该匹配service的port
  • serivce的名称应与ingress中的serviceName字段匹配

知道如何构造YAML定义只是故事的一部分。

出了问题后该怎么办？

Pod可能无法启动，或者正在崩溃。

三. kubernetes deployment故障排除的3个步骤

在深入研究失败的deployment之前，我们必须对Kubernetes的工作原理有一个明确定义的思维模型。

由于每个deployment中都有三个组件，因此你应该自下而上依次调试所有组件。

  • 你应该先确保Pods正在运行
  • 然后，专注于让service将流量路由到到正确的Pod
  • 然后，检查是否正确配置了Ingress

img{512x368}

你应该从底部开始对deployment进行故障排除。首先，检查Pod是否已就绪并正在运行。

img{512x368}

如果Pod已就绪，则应调查service是否可以将流量分配给Pod。

img{512x368}

最后，你应该检查service与ingress之间的连接。

1. Pod故障排除

在大多数情况下，问题出在Pod本身。

你应该确保Pod正在运行并准备就绪。

该如何检查呢？

$ kubectl get pods
NAME                    READY STATUS            RESTARTS  AGE
app1                    0/1   ImagePullBackOff  0         47h
app2                    0/1   Error             0         47h
app3-76f9fcd46b-xbv4k   1/1   Running           1         47h

在上述会话中，最后一个Pod处于就绪并正常运行的状态；但是，前两个Pod既不处于Running也不是Ready。

你如何调查出了什么问题？

有四个有用的命令可以对Pod进行故障排除：

  • kubectl logs 有助于检索Pod容器的日志
  • kubectl describe pod 检索与Pod相关的事件列表很有用
  • kubectl get pod 用于提取存储在Kubernetes中的Pod的YAML定义
  • kubectl exec -ti bash 在Pod的一个容器中运行交互式命令很有用

应该使用哪一个呢？

没有一种万能的。

相反，我们应该结合着使用它们。

常见Pod错误

Pod可能会出现启动和运行时错误。

启动错误包括：

  • ImagePullBackoff
  • ImageInspectError
  • ErrImagePull
  • ErrImageNeverPull
  • RegistryUnavailable
  • InvalidImageName

运行时错误包括：

  • CrashLoopBackOff
  • RunContainerError
  • KillContainerError
  • VerifyNonRootError
  • RunInitContainerError
  • CreatePodSandboxError
  • ConfigPodSandboxError
  • KillPodSandboxError
  • SetupNetworkError
  • TeardownNetworkError

有些错误比其他错误更常见。

以下是最常见的错误列表以及如何修复它们的方法。

ImagePullBackOff

当Kubernetes无法获取到Pod中某个容器的镜像时，将出现此错误。

共有三个可能的原因：

  • 镜像名称无效-例如，你拼错了名称，或者image不存在
  • 你为image指定了不存在的标签
  • 你尝试检索的image属于一个私有registry，而Kubernetes没有凭据可以访问它

前两种情况可以通过更正image名称和标记来解决。

针对第三种情况，你应该将私有registry的访问凭证通过Secret添加到k8s中并在Pod中引用它。

官方文档中有一个有关如何实现此目标的示例。

CrashLoopBackOff

如果容器无法启动，则Kubernetes将显示错误状态为：CrashLoopBackOff。

通常，在以下情况下容器无法启动：

  • 应用程序中存在错误，导致无法启动
  • 你未正确配置容器
  • Liveness探针失败太多次

你应该尝试从该容器中检索日志以调查其失败的原因。

如果由于容器重新启动太快而看不到日志，则可以使用以下命令：

$ kubectl logs <pod-name> --previous

这个命令打印前一个容器的错误消息。

RunContainerError

当容器无法启动时，出现此错误。

甚至在容器内的应用程序启动之前。

该问题通常是由于配置错误，例如：

  • 挂载不存在的卷，例如ConfigMap或Secrets
  • 将只读卷安装为可读写

你应该使用kubectl describe pod 命令收集和分析错误。

处于Pending状态的Pod

当创建Pod时，该Pod保持Pending状态。

为什么？

假设你的调度程序组件运行良好，可能的原因如下：

  • 集群没有足够的资源（例如CPU和内存）来运行Pod
  • 当前的命名空间具有ResourceQuota对象，创建Pod将使命名空间超过配额
  • 该Pod绑定到一个处于pending状态的 PersistentVolumeClaim

最好的选择是检查kubectl describe命令输出的“事件”部分内容：

$ kubectl describe pod <pod name>

对于因ResourceQuotas而导致的错误，可以使用以下方法检查集群的日志：

$ kubectl get events --sort-by=.metadata.creationTimestamp

处于未就绪状态的Pod

如果Pod正在运行但未就绪(not ready)，则表示readiness就绪探针失败。

当“就绪”探针失败时，Pod未连接到服务，并且没有流量转发到该实例。

就绪探针失败是应用程序的特定错误，因此你应检查kubectl describe中的“ 事件”部分以识别错误。

2. 服务的故障排除

如果你的Pod正在运行并处于就绪状态，但仍无法收到应用程序的响应，则应检查服务的配置是否正确。

service旨在根据流量的标签将流量路由到Pod。

因此，你应该检查的第一件事是服务关联了多少个Pod。

你可以通过检查服务中的端点(endpoint)来做到这一点：

$ kubectl describe service <service-name> | grep Endpoints

端点是一对，并且在服务（至少）以Pod为目标时，应该至少有一个端点。

如果“端点”部分为空，则有两种解释：

  • 你没有运行带有正确标签的Pod（提示：你应检查自己是否在正确的命名空间中）
  • service的selector标签上有错字

如果你看到端点列表，但仍然无法访问你的应用程序，则targetPort可能是你服务中的罪魁祸首。

你如何测试服务？

无论服务类型如何，你都可以使用kubectl port-forward来连接它：

$kubectl port-forward service/<service-name> 3000:80

这里：

  • 是服务的名称
  • 3000 是你希望在计算机上打开的端口
  • 80 是服务公开的端口

3.Ingress的故障排除

如果你已到达本节，则：

  • Pod正在运行并准备就绪
  • 服务会将流量分配到Pod

但是你仍然看不到应用程序的响应。

这意味着最有可能是Ingress配置错误。

由于正在使用的Ingress控制器是集群中的第三方组件，因此有不同的调试技术，具体取决于Ingress控制器的类型。

但是在深入研究Ingress专用工具之前，你可以用一些简单的方法进行检查。

Ingress使用serviceName和servicePort连接到服务。

你应该检查这些配置是否正确。

你可以通过下面命令检查Ingress配置是否正确：

$kubectl describe ingress <ingress-name>

如果backend一列为空，则配置中必然有一个错误。

如果你可以在“backend”列中看到端点，但是仍然无法访问该应用程序，则可能是以下问题：

  • 你如何将Ingress暴露于公共互联网
  • 你如何将集群暴露于公共互联网

你可以通过直接连接到Ingress Pod来将基础结构问题与Ingress隔离开。

首先，获取你的Ingress控制器Pod（可以位于其他名称空间中）：

$ kubectl get pods --all-namespaces
NAMESPACE   NAME                              READY STATUS
kube-system coredns-5644d7b6d9-jn7cq          1/1   Running
kube-system etcd-minikube                     1/1   Running
kube-system kube-apiserver-minikube           1/1   Running
kube-system kube-controller-manager-minikube  1/1   Running
kube-system kube-proxy-zvf2h                  1/1   Running
kube-system kube-scheduler-minikube           1/1   Running
kube-system nginx-ingress-controller-6fc5bcc  1/1   Running

描述它以检索端口：

# kubectl describe pod nginx-ingress-controller-6fc5bcc
 --namespace kube-system \
 | grep Ports

最后，连接到Pod：

$ kubectl port-forward nginx-ingress-controller-6fc5bcc 3000:80 --namespace kube-system

此时，每次你访问计算机上的端口3000时，请求都会转发到Pod上的端口80。

现在可以用吗？

  • 如果可行，则问题出在基础架构中。你应该调查流量如何路由到你的集群。
  • 如果不起作用，则问题出在Ingress控制器中。你应该调试Ingress。

如果仍然无法使Ingress控制器正常工作，则应开始对其进行调试。

目前有许多不同版本的Ingress控制器。

热门选项包括Nginx，HAProxy，Traefik等。

你应该查阅Ingress控制器的文档以查找故障排除指南。

由于Ingress Nginx是最受欢迎的Ingress控制器，因此在下一部分中我们将介绍一些有关调试ingress-nginx的技巧。

调试Ingress Nginx

Ingress-nginx项目有一个Kubectl的官方插件。

你可以用kubectl ingress-nginx来：

  • 检查日志，后端，证书等。
  • 连接到ingress
  • 检查当前配置

你应该尝试的三个命令是：

  • kubectl ingress-nginx lint，它会检查 nginx.conf
  • kubectl ingress-nginx backend，以检查后端（类似于kubectl describe ingress ）
  • kubectl ingress-nginx logs，查看日志

请注意，你可能需要为Ingress控制器指定正确的名称空间–namespace 。

四. 总结

如果你不知道从哪里开始，那么在Kubernetes中进行故障排除可能是一项艰巨的任务。

你应该始终牢记从下至上解决问题：从Pod开始，然后通过Service和Ingress向上移动堆栈。

你在本文中了解到的调试技术也可以应用于其他对象，例如：

  • failing Job和CronJob
  • StatefulSets和DaemonSets

本文翻译自learnk8s上的文章A visual guide on troubleshooting Kubernetes deployments。

我的网课“Kubernetes实战：高可用集群搭建、配置、运维与应用”在慕课网上线了，感谢小伙伴们学习支持！

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/
smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展； 短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite

微信赞赏：
img{512x368}

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

  1. « Previous
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12
  13. ...
  14. Next »
如发现本站页面被黑，比如：挂载广告、挖矿等恶意代码，请朋友们及时联系我。十分感谢！ Go语言第一课 Go语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站，只要有新文章发布，就会第一时间发送邮件通知你哦！

这里是 Tony Bai的个人Blog，欢迎访问、订阅和留言！ 订阅Feed请点击上面图片。

如果您觉得这里的文章对您有帮助，请扫描上方二维码进行捐赠 ，加油后的Tony Bai将会为您呈现更多精彩的文章，谢谢！

如果您希望通过微信捐赠，请用微信客户端扫描下方赞赏码：

如果您希望通过比特币或以太币捐赠，可以扫描下方二维码：

比特币：

以太币：

如果您喜欢通过微信浏览本站内容，可以扫描下方二维码，订阅本站官方微信订阅号“iamtonybai”；点击二维码，可直达本人官方微博主页^_^：
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机，即可获得10美元现金充值，可 免费使用两个月哟！ 著名主机提供商Linode 10$优惠码：linode10，在 这里注册即可免费获 得。阿里云推荐码： 1WFZ0V， 立享9折！


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

Blog Blogger C Cpp docker GC GCC github GNU Go Golang Google Gopher goroutine http Interface Java k8s Kubernetes Linux Opensource Package Programmer Python runtime RussCox Ubuntu Unix Windows 博客 容器 工作 巴萨 开源 思考 感悟 接口 摄影 标准库 梅西 泛型 生活 程序员 编译器 足球

归档



View My Stats