在 Kubernetes 中常用 Cert Manager 生成并管理自签名证书，常见的 CR 有👇

1. Issuer: 用于定义如何生成证书
2. ClusterIssuer: 用于定义如何生成集群级别的证书
3. Certificate: 用来请求和管理证书的主要资源
4. CertificateRequest: 是用于手动请求证书的资源
5. Order: 当使用 ACME 协议时会生成，
6. Challenge: 是 ACME 协议中的一部分，用于表示 ACME 服务对域名所有权的验证

一个自签的简单实用例子

自签名生成 CA 证书和私钥

1
2
3
4
5
6
7
8
9

# 生成 CA 的私钥
openssl genrsa -out ca.key 2048

# 生成自签名的 CA 证书
openssl req -x509 -new -nodes -key ca.key -subj "/CN=nginx-ca" -days 365 -out ca.crt

kubectl create secret tls tls-nginx \
  --cert=ca.crt \
  --key=ca.key

通过 Issue 创建自签名

1
2
3
4
5
6
7
8
9
10

cat <<EOF | kubectl apply -f -
apiVersion: cert-manager.io/v1
kind: Issuer
metadata:
  name: nginx-issuer
  namespace: default
spec:
  ca:
    secretName: tls-nginx
EOF

通过 Certificate 创建证书请求

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

cat <<EOF | kubectl apply -f -
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
  name: nginx-certificate
  namespace: default
spec:
  secretName: tls-nginx
  duration: 24h
  renewBefore: 12h
  commonName: nginx.warnerchen.io
  dnsNames:
    - nginx.warnerchen.io
  issuerRef:
    name: nginx-issuer
    kind: Issuer
EOF

给 Ingress 挂载后，尝试请求

生产集群的节点内核模块被异常修改，导致集群服务与服务之间网络通信异常，产生了较大规模的生产事故。

此次事故涉及到两个主要的内核模块被修改:

1. net.ipv4.ip_forward: 用于启用 IP 转发，当此模块加载时，Linux 内核会允许将数据包转发到其他网络

尝试复现

在一个集群中启用两个 Pod，通过这两个 Pod 模拟业务

修改 controller-node-2 节点的 /etc/sysctl.d/99-sysctl.conf 文件，并加载(sysctl -p)

1

net.ipv4.ip_forward=0

此时再去测试连通性，已经不通了

尽管是在同一个宿主机上的 Pod，也无法进行通信

节点之间能够正常通信

查看 calico 组网状态，显示正常

通过正常节点的 Pod 去 ping 异常节点的 Pod，正常节点抓包，发现没有回包

1
2
3
4
5
6
7
8
9
10
11
12
13
14

[root@controller-node-1 ~]# tcpdump -i any host 10.233.74.83 or 10.233.76.142 -nnvvv
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
16:14:10.762727 IP (tos 0x0, ttl 64, id 37977, offset 0, flags [DF], proto ICMP (1), length 84)
    10.233.74.83 > 10.233.76.142: ICMP echo request, id 265, seq 0, length 64
16:14:10.762787 IP (tos 0x0, ttl 63, id 37977, offset 0, flags [DF], proto ICMP (1), length 84)
    10.233.74.83 > 10.233.76.142: ICMP echo request, id 265, seq 0, length 64
16:14:11.762953 IP (tos 0x0, ttl 64, id 38291, offset 0, flags [DF], proto ICMP (1), length 84)
    10.233.74.83 > 10.233.76.142: ICMP echo request, id 265, seq 1, length 64
16:14:11.763002 IP (tos 0x0, ttl 63, id 38291, offset 0, flags [DF], proto ICMP (1), length 84)
    10.233.74.83 > 10.233.76.142: ICMP echo request, id 265, seq 1, length 64
16:14:12.763208 IP (tos 0x0, ttl 64, id 38345, offset 0, flags [DF], proto ICMP (1), length 84)
    10.233.74.83 > 10.233.76.142: ICMP echo request, id 265, seq 2, length 64
16:14:12.763253 IP (tos 0x0, ttl 63, id 38345, offset 0, flags [DF], proto ICMP (1), length 84)
    10.233.74.83 > 10.233.76.142: ICMP echo request, id 265, seq 2, length 64

异常节点抓包，发现 icmp 包有到达该节点上，但目标地址没有进行响应，说明流量没有抵达目的地 Pod

1
2
3
4
5
6
7
8

[root@controller-node-2 ~]# tcpdump -i any host 10.233.74.83 or 10.233.76.142 -nnvvv
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
16:15:00.019656 IP (tos 0x0, ttl 63, id 42391, offset 0, flags [DF], proto ICMP (1), length 84)
    10.233.74.83 > 10.233.76.142: ICMP echo request, id 271, seq 0, length 64
16:15:01.019960 IP (tos 0x0, ttl 63, id 43082, offset 0, flags [DF], proto ICMP (1), length 84)
    10.233.74.83 > 10.233.76.142: ICMP echo request, id 271, seq 1, length 64
16:15:02.020072 IP (tos 0x0, ttl 63, id 43594, offset 0, flags [DF], proto ICMP (1), length 84)
    10.233.74.83 > 10.233.76.142: ICMP echo request, id 271, seq 2, length 64

通过异常节点的 Pod 去 ping 正常节点的 Pod，正常节点抓包，发现没有任何包，说明流量没有从异常节点转发出来

1
2

[root@controller-node-1 ~]# tcpdump -i any host 10.233.74.83 or 10.233.76.142 -nnvvv
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes

异常节点，进入 Pod 对应的网络命名空间进行抓包，可以看到有 icmp 的请求包，但依旧没有收到响应

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

[root@controller-node-2 ~]# nsenter -n -t 23056
[root@controller-node-2 ~]# ip -4 a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
4: eth0@if12: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1480 qdisc noqueue state UP group default qlen 1000 link-netnsid 0
    inet 10.233.76.142/32 scope global eth0
       valid_lft forever preferred_lft forever
[root@controller-node-2 ~]# tcpdump -i any host 10.233.74.83 or 10.233.76.142 -nnvvv
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
16:22:42.911202 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 169.254.1.1 tell 10.233.76.142, length 28
16:22:43.913783 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 169.254.1.1 tell 10.233.76.142, length 28
16:22:44.915789 ARP, Ethernet (len 6), IPv4 (len 4), Request who-has 169.254.1.1 tell 10.233.76.142, length 28
16:22:45.917834 IP (tos 0xc0, ttl 64, id 52805, offset 0, flags [none], proto ICMP (1), length 112)
    10.233.76.142 > 10.233.76.142: ICMP host 10.233.74.83 unreachable, length 92
	IP (tos 0x0, ttl 64, id 26248, offset 0, flags [DF], proto ICMP (1), length 84)
    10.233.76.142 > 10.233.74.83: ICMP echo request, id 90, seq 0, length 64
16:22:45.917839 IP (tos 0xc0, ttl 64, id 52806, offset 0, flags [none], proto ICMP (1), length 112)
    10.233.76.142 > 10.233.76.142: ICMP host 10.233.74.83 unreachable, length 92
	IP (tos 0x0, ttl 64, id 26601, offset 0, flags [DF], proto ICMP (1), length 84)
    10.233.76.142 > 10.233.74.83: ICMP echo request, id 90, seq 1, length 64
16:22:45.917841 IP (tos 0xc0, ttl 64, id 52807, offset 0, flags [none], proto ICMP (1), length 112)
    10.233.76.142 > 10.233.76.142: ICMP host 10.233.74.83 unreachable, length 92
	IP (tos 0x0, ttl 64, id 26809, offset 0, flags [DF], proto ICMP (1), length 84)
    10.233.76.142 > 10.233.74.83: ICMP echo request, id 90, seq 2, length 64

尝试重启该节点的 calico-node，内核模块会被 calico-node 修改回来，此时网络恢复，但 /etc/sysctl.d/99-sysctl.conf 中的 net.ipv4.ip_forward 还是 0，所以在下次重新加载(sysctl -p)的时候，仍然会被设置为关闭状态

事故总结

此次事故的排障思路是:

1. 通过两个在不同宿主机的 Pod，测试跨节点的连通性，不通
2. 测试节点之间的连通性，能够正常通信
3. 在这两个宿主机进行同一宿主机不同 Pod 的连通性测试，一台通，一台不通 – 确定问题节点
4. 通过 calicoctl node status 查看组网状态，显示正常 – 暂且排除是 calico 的问题
5. 通过 tcpdump 进行抓包，获取正常节点 Pod 到异常节点 Pod 的数据包 – icmp 数据包能够到达异常节点，但异常节点的 Pod 没有响应
6. 通过 tcpdump 进行抓包，获取异常节点 Pod 到正常节点 Pod 的数据包 – 异常节点宿主机层面无法获取 icmp 包，通过 nsenter 进入 Pod 的网络命名空间发现，icmp 有发出但无响应，且 icmp 数据包无法到达正常节点，正常节点抓包观察没有任何包
7. 尝试重启异常节点 calico-node，网络恢复 – calico-node 启动会修改内核参数，但不会持久化到 /etc/sysctl.d/99-sysctl.conf 中
8. 查看 /etc/sysctl.d/99-sysctl.conf 发现 net.ipv4.ip_forward 被设置为了 0
9. 通过 ansible 检查所有节点的 /etc/sysctl.d/99-sysctl.conf 文件

是指在特定命名空间下部署的 Pod 都会被调度到指定标签的节点上，这个功能需要在 kube-apiserver 添加 PodNodeSelector 参数

1
2
3
4
5
6
7
8
9
10
11

apiVersion: v1
kind: Pod
metadata:
  labels:
    component: kube-apiserver
    tier: control-plane
  name: kube-apiserver
  namespace: kube-system
...
    - --enable-admission-plugins=NodeRestriction,PodNodeSelector
...

然后给命名空间添加 annotation

1
2
3
4
5

apiVersion: v1
kind: Namespace
metadata:
  annotations:
    scheduler.alpha.kubernetes.io/node-selector: test.io/app=true

在 K8s 中，DNS 的解析主要用这两个工具:

1. CoreDNS: 主要负责集群内部域名解析
2. NodeLocalDNS: 提供 DNS 缓存

首先看一下集群中节点的 /etc/resolv.conf 配置文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# 指定了搜索域，当使用域名解析主机名时，如果主机名没有完全限定，系统会依次尝试在指定的搜索域中追加搜索后缀进行解析
# 例如解析 test，则会尝试解析 test.default.svc.cluster.local 和 test.svc.cluster.local
search default.svc.cluster.local svc.cluster.local

# nodelocaldns 服务器的地址，如果集群中没有 nodelocaldns，那么这个地址就会替换成 CoreDNS 的 SVC ClusterIP
nameserver 169.254.25.10

# 其他 DNS 服务器地址
nameserver 192.168.0.5
nameserver 223.5.5.5

# 解析的域名最多包涵 2 个点，最多超时 2s，最多重试 2 次
# 假设解析a，会尝试追加 default.svc.cluster.local 和 svc.cluster.local
# 假设解析a.b，则不会，除非 ndots > 2
options ndots:2 timeout:2 attempts:2

在 K8s 中，workload 的 dnsPolicy 有四种类型:

1. ClusterFirst: 与配置的集群域后缀不匹配的任何 DNS 查询（例如 “www.kubernetes.io"） 都会由 DNS 服务器转发到上游名称服务器
2. Default: 从运行所在的节点继承名称解析配置
3. ClusterFirstWithHostNet: 对于以 hostNetwork 方式运行的 Pod，应将其 DNS 策略显式设置为 ClusterFirstWithHostNet。否则，以 hostNetwork 方式和 ClusterFirst 策略运行的 Pod 将会做出回退至 Default 策略的行为
4. None: 会使用 dnsConfig 提供的 DNS 配置

CoreDNS

CoreDNS 主要是复杂集群内部域名的解析，保证 Pod 与 Pod 只见可以通过 Service Name 进行通信。当然也可以为它添加配置，使其能够解析静态的一些 Host 👇

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

kind: ConfigMap
apiVersion: v1
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors {
        }
        health {
            lameduck 5s
        }
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
          pods insecure
          fallthrough in-addr.arpa ip6.arpa
        }
        prometheus :9153
        forward . /etc/resolv.conf {
          prefer_udp
          max_concurrent 1000
        }
        hosts /etc/coredns/Hosts {
          ttl 60
          reload 1m
          fallthrough
        }
        cache 30
        loop
        reload
        loadbalance
    }
  Hosts: |+
    192.168.0.10 cqm.com

创建一个 dnsPolicy 为 ClusterFirst 的 busybox

通过这个 busybox 解析集群内部域名，通过 tcpdump 获取 53 端口的包

可以看到会根据 search 对 CoreDNS 发起多次请求

Pod -> CoreDNS -> Pod

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

[root@controller-node-1 ~]# tcpdump -i any host 10.233.0.3 and 10.233.74.83 and port 53 -nnvvv
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
22:52:20.447820 IP (tos 0x0, ttl 64, id 37856, offset 0, flags [DF], proto UDP (17), length 82)
    10.233.74.83.58663 > 10.233.0.3.53: [bad udp cksum 0x6077 -> 0x753d!] 33482+ A? kubernetes.default.svc.cluster.local. (54)
22:52:20.447950 IP (tos 0x0, ttl 64, id 37857, offset 0, flags [DF], proto UDP (17), length 74)
    10.233.74.83.58663 > 10.233.0.3.53: [bad udp cksum 0x606f -> 0xdd2e!] 53027+ A? kubernetes.svc.cluster.local. (46)
22:52:20.447978 IP (tos 0x0, ttl 64, id 37858, offset 0, flags [DF], proto UDP (17), length 70)
    10.233.74.83.58663 > 10.233.0.3.53: [bad udp cksum 0x606b -> 0x0aa3!] 30769+ A? kubernetes.cluster.local. (42)
22:52:20.447999 IP (tos 0x0, ttl 64, id 37859, offset 0, flags [DF], proto UDP (17), length 82)
    10.233.74.83.58663 > 10.233.0.3.53: [bad udp cksum 0x6077 -> 0x2dde!] 51726+ AAAA? kubernetes.default.svc.cluster.local. (54)
22:52:20.448017 IP (tos 0x0, ttl 64, id 37860, offset 0, flags [DF], proto UDP (17), length 74)
    10.233.74.83.58663 > 10.233.0.3.53: [bad udp cksum 0x606f -> 0xba24!] 61970+ AAAA? kubernetes.svc.cluster.local. (46)
22:52:20.448038 IP (tos 0x0, ttl 64, id 37861, offset 0, flags [DF], proto UDP (17), length 70)
    10.233.74.83.58663 > 10.233.0.3.53: [bad udp cksum 0x606b -> 0x7758!] 2913+ AAAA? kubernetes.cluster.local. (42)
22:52:20.448407 IP (tos 0x0, ttl 63, id 32091, offset 0, flags [DF], proto UDP (17), length 163)
    10.233.0.3.53 > 10.233.74.83.58663: [bad udp cksum 0x60c8 -> 0xd926!] 2913 NXDomain*- q: AAAA? kubernetes.cluster.local. 0/1/0 ns: cluster.local. [5s] SOA ns.dns.cluster.local. hostmaster.cluster.local. 1711809447 7200 1800 86400 5 (135)
22:52:20.448557 IP (tos 0x0, ttl 63, id 32092, offset 0, flags [DF], proto UDP (17), length 175)
    10.233.0.3.53 > 10.233.74.83.58663: [bad udp cksum 0x60d4 -> 0x8faf!] 51726*- q: AAAA? kubernetes.default.svc.cluster.local. 0/1/0 ns: cluster.local. [5s] SOA ns.dns.cluster.local. hostmaster.cluster.local. 1711809447 7200 1800 86400 5 (147)
22:52:20.448654 IP (tos 0x0, ttl 63, id 32093, offset 0, flags [DF], proto UDP (17), length 163)
    10.233.0.3.53 > 10.233.74.83.58663: [bad udp cksum 0x60c8 -> 0x6c71!] 30769 NXDomain*- q: A? kubernetes.cluster.local. 0/1/0 ns: cluster.local. [5s] SOA ns.dns.cluster.local. hostmaster.cluster.local. 1711809447 7200 1800 86400 5 (135)
22:52:20.448699 IP (tos 0x0, ttl 63, id 32094, offset 0, flags [DF], proto UDP (17), length 167)
    10.233.0.3.53 > 10.233.74.83.58663: [bad udp cksum 0x60cc -> 0x1bf3!] 61970 NXDomain*- q: AAAA? kubernetes.svc.cluster.local. 0/1/0 ns: cluster.local. [5s] SOA ns.dns.cluster.local. hostmaster.cluster.local. 1711809447 7200 1800 86400 5 (139)
22:52:20.448761 IP (tos 0x0, ttl 63, id 32095, offset 0, flags [DF], proto UDP (17), length 134)
    10.233.0.3.53 > 10.233.74.83.58663: [bad udp cksum 0x60ab -> 0x24fc!] 33482*- q: A? kubernetes.default.svc.cluster.local. 1/0/0 kubernetes.default.svc.cluster.local. [5s] A 10.233.0.1 (106)
22:52:20.448811 IP (tos 0x0, ttl 63, id 32096, offset 0, flags [DF], proto UDP (17), length 167)
    10.233.0.3.53 > 10.233.74.83.58663: [bad udp cksum 0x60cc -> 0x3efd!] 53027 NXDomain*- q: A? kubernetes.svc.cluster.local. 0/1/0 ns: cluster.local. [5s] SOA ns.dns.cluster.local. hostmaster.cluster.local. 1711809447 7200 1800 86400 5 (139)

通过这个 busybox 解析集群公网域名

可以看到对 www.baidu.com 域名的解析返回结果，是通过 192.168.0.5 获取到的

Pod -> CoreDNS -> 192.168.0.5 -> CoreDNS -> Pod

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

[root@controller-node-1 ~]#  tcpdump -i any host 10.233.74.83 and 10.233.0.3 or 192.168.0.5 and port 53 -nnvvv
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
22:58:29.405332 IP (tos 0x0, ttl 64, id 48447, offset 0, flags [DF], proto UDP (17), length 59)
    10.233.74.83.38430 > 10.233.0.3.53: [bad udp cksum 0x6060 -> 0xdcc6!] 28765+ A? www.baidu.com. (31)
22:58:29.405423 IP (tos 0x0, ttl 64, id 48448, offset 0, flags [DF], proto UDP (17), length 59)
    10.233.74.83.38430 > 10.233.0.3.53: [bad udp cksum 0x6060 -> 0xcdcd!] 25686+ AAAA? www.baidu.com. (31)
22:58:29.405881 IP (tos 0x0, ttl 64, id 42712, offset 0, flags [DF], proto UDP (17), length 59)
    10.233.74.66.56555 > 192.168.0.5.53: [bad udp cksum 0x1611 -> 0x2f90!] 1558+ AAAA? www.baidu.com. (31)
22:58:29.405950 IP (tos 0x0, ttl 63, id 42712, offset 0, flags [DF], proto UDP (17), length 59)
    192.168.159.41.56555 > 192.168.0.5.53: [bad udp cksum 0x20b8 -> 0x24e9!] 1558+ AAAA? www.baidu.com. (31)
22:58:29.406110 IP (tos 0x0, ttl 64, id 42713, offset 0, flags [DF], proto UDP (17), length 59)
    10.233.74.66.58403 > 192.168.0.5.53: [bad udp cksum 0x1611 -> 0xf518!] 21589+ A? www.baidu.com. (31)
22:58:29.406191 IP (tos 0x0, ttl 63, id 42713, offset 0, flags [DF], proto UDP (17), length 59)
    192.168.159.41.58403 > 192.168.0.5.53: [bad udp cksum 0x20b8 -> 0xea71!] 21589+ A? www.baidu.com. (31)
22:58:29.410592 IP (tos 0x0, ttl 63, id 39983, offset 0, flags [DF], proto UDP (17), length 118)
    192.168.0.5.53 > 192.168.159.41.58403: [udp sum ok] 21589 q: A? www.baidu.com. 3/0/0 www.baidu.com. [2m9s] CNAME www.a.shifen.com., www.a.shifen.com. [2m9s] A 183.2.172.185, www.a.shifen.com. [2m9s] A 183.2.172.42 (90)
22:58:29.410637 IP (tos 0x0, ttl 62, id 39983, offset 0, flags [DF], proto UDP (17), length 118)
    192.168.0.5.53 > 10.233.74.66.58403: [udp sum ok] 21589 q: A? www.baidu.com. 3/0/0 www.baidu.com. [2m9s] CNAME www.a.shifen.com., www.a.shifen.com. [2m9s] A 183.2.172.185, www.a.shifen.com. [2m9s] A 183.2.172.42 (90)
22:58:29.410972 IP (tos 0x0, ttl 63, id 64831, offset 0, flags [DF], proto UDP (17), length 166)
    10.233.0.3.53 > 10.233.74.83.38430: [bad udp cksum 0x60cb -> 0xe43e!] 28765 q: A? www.baidu.com. 3/0/0 www.baidu.com. [30s] CNAME www.a.shifen.com., www.a.shifen.com. [30s] A 183.2.172.42, www.a.shifen.com. [30s] A 183.2.172.185 (138)
22:58:29.413159 IP (tos 0x0, ttl 63, id 39984, offset 0, flags [DF], proto UDP (17), length 142)
    192.168.0.5.53 > 192.168.159.41.56555: [udp sum ok] 1558 q: AAAA? www.baidu.com. 3/0/0 www.baidu.com. [3m29s] CNAME www.a.shifen.com., www.a.shifen.com. [3m29s] AAAA 240e:ff:e020:9ae:0:ff:b014:8e8b, www.a.shifen.com. [3m29s] AAAA 240e:ff:e020:966:0:ff:b042:f296 (114)
22:58:29.413203 IP (tos 0x0, ttl 62, id 39984, offset 0, flags [DF], proto UDP (17), length 142)
    192.168.0.5.53 > 10.233.74.66.56555: [udp sum ok] 1558 q: AAAA? www.baidu.com. 3/0/0 www.baidu.com. [3m29s] CNAME www.a.shifen.com., www.a.shifen.com. [3m29s] AAAA 240e:ff:e020:9ae:0:ff:b014:8e8b, www.a.shifen.com. [3m29s] AAAA 240e:ff:e020:966:0:ff:b042:f296 (114)
22:58:29.413922 IP (tos 0x0, ttl 63, id 64833, offset 0, flags [DF], proto UDP (17), length 190)
    10.233.0.3.53 > 10.233.74.83.38430: [bad udp cksum 0x60e3 -> 0x9ac9!] 25686 q: AAAA? www.baidu.com. 3/0/0 www.baidu.com. [30s] CNAME www.a.shifen.com., www.a.shifen.com. [30s] AAAA 240e:ff:e020:966:0:ff:b042:f296, www.a.shifen.com. [30s] AAAA 240e:ff:e020:9ae:0:ff:b014:8e8b (162)

NodeLocalDNS

来自官方文档: NodeLocal DNSCache 通过在集群节点上作为 DaemonSet 运行 DNS 缓存代理来提高集群 DNS 性能。

NodeLocalDNS Pod 中的 /etc/resolv.conf 与宿主机是相同的

节点上也会有对应的网卡，这个地址取决于启动参数

在集群有 NodeLocalDNS 的情况下，在对集群内部域名进行解析，可以看到 DNS 请求会先经过 NodeLocalDNS，然后直接返回请求

Pod -> NodeLocalDNS -> Pod

1
2
3
4
5
6
7
8
9
10

[root@controller-node-1 ~]# tcpdump -i any host 10.233.74.83 and 169.254.25.10 or 10.233.0.3 and port 53 -nnvvv
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
23:19:46.273718 IP (tos 0x0, ttl 64, id 61227, offset 0, flags [DF], proto UDP (17), length 82)
    10.233.74.83.36711 > 169.254.25.10.53: [bad udp cksum 0x1894 -> 0x3f9b!] 22032+ A? kubernetes.default.svc.cluster.local. (54)
23:19:46.273793 IP (tos 0x0, ttl 64, id 61228, offset 0, flags [DF], proto UDP (17), length 82)
    10.233.74.83.36711 > 169.254.25.10.53: [bad udp cksum 0x1894 -> 0xb26b!] 58148+ AAAA? kubernetes.default.svc.cluster.local. (54)
23:19:46.275678 IP (tos 0x0, ttl 64, id 60479, offset 0, flags [DF], proto UDP (17), length 134)
    169.254.25.10.53 > 10.233.74.83.36711: [bad udp cksum 0x18c8 -> 0xef59!] 22032*- q: A? kubernetes.default.svc.cluster.local. 1/0/0 kubernetes.default.svc.cluster.local. [5s] A 10.233.0.1 (106)
23:19:46.275946 IP (tos 0x0, ttl 64, id 60480, offset 0, flags [DF], proto UDP (17), length 175)
    169.254.25.10.53 > 10.233.74.83.36711: [bad udp cksum 0x18f1 -> 0x5d58!] 58148*- q: AAAA? kubernetes.default.svc.cluster.local. 0/1/0 ns: cluster.local. [5s] SOA ns.dns.cluster.local. hostmaster.cluster.local. 1711802462 7200 1800 86400 5 (147)

然后在对集群外部域名进行解析

Pod -> NodeLocalDNS -> CoreDNS -> 192.168.0.5 -> CoreDNS -> NodeLocalDNS -> Pod

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

23:27:25.569362 IP (tos 0x0, ttl 64, id 36019, offset 0, flags [DF], proto UDP (17), length 60)
    10.233.74.83.42419 > 169.254.25.10.53: [bad udp cksum 0x187e -> 0x94cd!] 7676+ A? www.google.com. (32)
23:27:25.569423 IP (tos 0x0, ttl 64, id 36020, offset 0, flags [DF], proto UDP (17), length 60)
    10.233.74.83.42419 > 169.254.25.10.53: [bad udp cksum 0x187e -> 0xb5c9!] 64740+ AAAA? www.google.com. (32)
23:27:25.569823 IP (tos 0x0, ttl 64, id 65347, offset 0, flags [DF], proto UDP (17), length 71)
    192.168.159.11.57457 > 192.168.0.5.53: [bad udp cksum 0x20a6 -> 0x7971!] 52418+ [1au] AAAA? www.google.com. ar: . OPT UDPsize=2048 DO (43)
23:27:25.569841 IP (tos 0x0, ttl 64, id 65348, offset 0, flags [DF], proto UDP (17), length 71)
    192.168.159.11.33304 > 192.168.0.5.53: [bad udp cksum 0x20a6 -> 0xa430!] 120+ [1au] A? www.google.com. ar: . OPT UDPsize=2048 DO (43)
23:27:25.571423 IP (tos 0x0, ttl 63, id 18081, offset 0, flags [DF], proto UDP (17), length 152)
    192.168.0.5.53 > 192.168.159.11.57457: [udp sum ok] 52418 q: AAAA? www.google.com. 0/1/1 ns: www.google.com. [10s] SOA fake-for-negative-caching.adguard.com. hostmaster.www.google.com. 100500 1800 60 604800 86400 ar: . OPT UDPsize=2048 DO (124)
23:27:25.571763 IP (tos 0x0, ttl 64, id 40563, offset 0, flags [DF], proto UDP (17), length 172)
    169.254.25.10.53 > 10.233.74.83.42419: [bad udp cksum 0x18ee -> 0x3576!] 64740 q: AAAA? www.google.com. 0/1/0 ns: www.google.com. [10s] SOA fake-for-negative-caching.adguard.com. hostmaster.www.google.com. 100500 1800 60 604800 86400 (144)
23:27:25.573701 IP (tos 0x0, ttl 63, id 18082, offset 0, flags [DF], proto UDP (17), length 87)
    192.168.0.5.53 > 192.168.159.11.33304: [udp sum ok] 120 q: A? www.google.com. 1/0/1 www.google.com. [1m30s] A 216.58.203.68 ar: . OPT UDPsize=2048 DO (59)
23:27:25.573927 IP (tos 0x0, ttl 64, id 40564, offset 0, flags [DF], proto UDP (17), length 90)
    169.254.25.10.53 > 10.233.74.83.42419: [bad udp cksum 0x189c -> 0xe2c7!] 7676 q: A? www.google.com. 1/0/0 www.google.com. [30s] A 216.58.203.68 (62)

kube-proxy 以 DaemonSet 的形式运行在集群的所有节点中，负责管理集群外到 Service，以及 Service 到 Pod 的流量转发。

kube-proxy 有三种模式:

1. userspace
2. iptables
3. ipvs

在运行了 kube-proxy 的节点上，可以通过下面的命令查看 kube-proxy 的运行模式:

1

curl localhost:10249/proxyMode

iptables

通过 kube-proxy 的 cm 可以查看 mode

我们都知道 SVC 有多种类型，常用的有 ClusterIP、NodePort、Headless、LoadBalancer 等等，这里我们通过创建类型的 SVC，查看 kube-proxy 下发的iptables 规则

ClusterIP

通过 iptables-save 命令打印这个 SVC 的规则

PodIP: 10.233.74.106
ClusterIP: 10.233.54.175

1
2
3
4
5
6
7
8
9
10
11
12
13
14

# 将来自 Pod IP 10.233.74.106 的流量标记为服务 default/nginx，并转发到 KUBE-MARK-MASQ 链中
-A KUBE-SEP-EUB75IW55XDW6EHN -s 10.233.74.106/32 -m comment --comment "default/nginx:tcp-80" -j KUBE-MARK-MASQ

# 将匹配的 TCP 流量进行 DNAT，转发到后端 Pod 10.233.74.106:80
-A KUBE-SEP-EUB75IW55XDW6EHN -p tcp -m comment --comment "default/nginx:tcp-80" -m tcp -j DNAT --to-destination 10.233.74.106:80

# 匹配目标地址为服务 default/nginx 的 cluster IP 10.233.54.175 的 TCP 80 端口流量
-A KUBE-SERVICES -d 10.233.54.175/32 -p tcp -m comment --comment "default/nginx:tcp-80 cluster IP" -m tcp --dport 80 -j KUBE-SVC-XX3NNXKPRC7N6OJH

# 标记来自外部网络（除了 PodCIDR 10.233.64.0/18）的、目标地址为服务 default/nginx 的 cluster IP 10.233.54.175 的 TCP 80 端口的流量
-A KUBE-SVC-XX3NNXKPRC7N6OJH ! -s 10.233.64.0/18 -d 10.233.54.175/32 -p tcp -m comment --comment "default/nginx:tcp-80 cluster IP" -m tcp --dport 80 -j KUBE-MARK-MASQ

# 将匹配的流量转发到 KUBE-SEP-EUB75IW55XDW6EHN 链中，进行 DNAT 地址转换
-A KUBE-SVC-XX3NNXKPRC7N6OJH -m comment --comment "default/nginx:tcp-80 -> 10.233.74.106:80" -j KUBE-SEP-EUB75IW55XDW6EHN

NodePort

把这个 SVC 类型改成 NodePort

通过 iptables-save 命令打印这个 SVC 的规则，多了两条规则

1
2
3
4
5

# 用于标记来自外部的、目标地址为服务 default/nginx 的 NodePort 流量
-A KUBE-EXT-XX3NNXKPRC7N6OJH -m comment --comment "masquerade traffic for default/nginx:tcp-80 external destinations" -j KUBE-MARK-MASQ

# 用于匹配目标端口为 32594 的 TCP 流量，并将该流量转发到上面的规则进行 MASQ 标记
-A KUBE-NODEPORTS -p tcp -m comment --comment "default/nginx:tcp-80" -m tcp --dport 32594 -j KUBE-EXT-XX3NNXKPRC7N6OJH

IPVS

通过 kube-proxy 的 cm 可以查看 mode

来自 GPT 的回答: IPVS 是 Linux 内核中实现的虚拟服务器技术，它可以将网络流量负载均衡到多台服务器上，从而提高服务性能和可靠性。

ClusterIP

PodIP: 10.233.76.138
ClusterIP: 10.233.27.36

通过 ipvsadm 命令查看这个虚拟服务器

1
2
3
4
5
6
7
8
9
10

Prot LocalAddress:Port Scheduler Flags
  -> RemoteAddress:Port           Forward Weight ActiveConn InActConn

# 将目标地址为 nginx.default.svc.cluster.lo:80 的 TCP 流量转发到后端 Pod 10.233.76.138:80
TCP  nginx.default.svc.cluster.lo rr
  -> 10-233-76-138.nginx.default. Masq    1      0          0

# 将目标地址为 10.233.27.36:80 的 TCP 流量转发到后端 Pod 10.233.76.138:80
TCP  10.233.27.36:80 rr
  -> 10.233.76.138:80             Masq    1      0          0

NodePort

通过 ipvsadm 命令查看这个虚拟服务器，多了三条规则

1
2
3
4
5
6
7
8
9
10
11

# 10.233.74.64 为 nodelocaldns 网卡的 IP，由于 NodePort 是全监听，所以也有对应的规则
TCP  169.254.25.10:30229 rr
  -> 10.233.76.138:80             Masq    1      0          0

# 节点IP
TCP  192.168.159.11:30229 rr
  -> 10.233.76.138:80             Masq    1      0          0

# 10.233.74.64 为 tun0 网卡的 IP，由于 NodePort 是全监听，所以也有对应的规则
TCP  10.233.74.64:30229 rr
  -> 10.233.76.138:80             Masq    1      0

CNI 即容器网络接口，通过 CNI 能够使 K8s 支持不同的网络模式。

CNI 常见的实现模式大致分为两种:

1. overlay: 通过隧道打通网络，不依赖底层网络，如 calico
2. underlay: 通过底层打通网络，强依赖底层网络，如 macvlan

CNI 如何使用

CNI 的实现通常需要两个部分:

1. CNI 二进制文件去配置 Pod 的网卡和 IP

2. DaemonSet 进程去管理 Pod 之间的网络打通

3. 配置 CNI 配置文件(/etc/cni/net.d/*.conf)

4. 安装 CNI 二进制文件(/opt/cni/bin/*)

5. 节点上创建 Pod

6. kubelet 根据 CNI 配置文件执行 CNI 二进制文件

7. Pod 网络配置完成

CSI 即容器存储接口，借助 CSI 就可以很容易的给工作负载提供存储使用。K8s 的存储插件又分为 in-tree 和 out-of-tree 两种类型，前者是与 K8s 主库共同迭代维护，后者则是独立维护的存储插件。

out-of-tree 类型的插件则是通过 gRPC 与 K8s 的组件进行交互，为了简化 CSI 的开发与部署，K8s 也提供了多个 sidecar 组件:

1. node-driver-registrar: 监听来自 kubelet 的 gRPC 请求，从 CSI driver 获取驱动程序信息（通过 NodeGetInfo 方法），并使用 kubelet 插件注册机制在该节点上的 kubelet 中对其进行注册
2. provisioner: 监听来自 kube-apiserver 的 gRPC 请求，监听 PVC 的创建和删除，调用 CSI driver 创建和删除 PV（通过 CreateVolume 和 Delete Volume）方法
3. attacher: 监听来自 kube-apiserver 的 gRPC 请求，监听 volumeAttachment 对象并触发 CSI 执行 ControllerPublishVolume 和 ControllerUnpublishVolume 的操作
4. resizer: 监听来自 kube-apiserver 的 gRPC 请求，监听 PVC 的修改，调用 CSI Controller 执行 ExpandVolume 方法，来调整 Volume 的大小
5. livenessProbe: 检查 CSI 程序的健康状态，如不健康则会进行重启

CSI 工作流程

CSI 的工作流分为三个阶段:

1. Provision/Delete
2. Attach/Detach
3. Mount/Unmount

这三个阶段会用到 Sidecar 组件，也会用到 K8s 的 PV Controller 和 AD Controller 组件

当然并不是所有的 CSI 都会经历这三个阶段，如 NFS CSI 的工作流就没有涉及 volumeAttachment

Privision 阶段

在此阶段，Sidecar provisioner 和 PV Controller 都会监听 PVC 资源

1. 当 PV Controller 观察到新的 PVC 被创建时，就会去判断是否有与之匹配的 in-tree 插件，如果没有则判定为 out-of-tree，并为该 PVC 添加 annotation
   
2. provisioner 观察到 PVC 的 annotation 与自己的 CSI 是相匹配的时候，就会去调用 CreateVolume 方法
3. 当 CreateVolume 调用返回成功时，provisioner 就会创建 PV
4. PV Controller 监听到该 PV 时，就会将其与 PVC 做绑定

Attach 阶段

在此阶段，会将数据卷附在一个节点上

1. AD Controller 监听到 Pod 被调度到某个节点后，会调用 in-tree 内部接口创建 volumeAttachment 资源
2. attacher 监听到 volumeAttachment 就会调用 ControllerPublishVolume 接口
3. 当接口返回成功时就会将 volumeAttachment 资源的 status.attached 设置为 true
   

Mount 阶段

在此阶段，会将数据卷挂载到 Pod 上

1. kubelet 观察到 volumeAttachment 资源的 status.attached 设置为 true 时，就会调用 in-tree 内部接口进行实际的卷挂载操作

Unmount 阶段

在此阶段，会将数据卷从 Pod 上取消挂载

1. kubelet 监听到节点上的 Pod 被删除，就会调用 in-tree 内部接口进行实际的卷卸载操作

Detach 阶段

在此阶段，会将对应的 volumeAttachment 资源删除

1. attacher 会讲被删除 Pod 对应的 volumeAttachment 进行删除
2. AD Controller 监听到 volumeAttachment 被删除后，会去更新节点的 status.volumesInUse，将对应的卷信息摘除

Delete 阶段

在此阶段，会判断 PV 的回收策略进行不同的操作

1. provisioner 观察 PV 的 persistentVolumeReclaimPolicy，如果为 Retain 则保留，Delete 则删除

K8s 本身不提供容器创建的实现，容器的创建是通过 CRI 接口调用外部插件实现的，常见的 CRI 有这几种:

1. docker
2. containerd
3. cri-dockerd

Pod 是如何被创建出来的

1. 客户端通过 kubectl 等将创建 pod 的请求发送给 kube-apiserver
2. kube-apiserver 将 pod 信息写入 etcd，etcd 将写入的结果返回给 kube-apiserver，然后 kube-apiserver 再返回给客户端
3. kube-scheduler 通过 kube-apiserver 的 watch 接口，获取到未被调度的 pod 信息，根据调度算法选择集群内的一个节点，然后将节点信息发送给 kube-apiserver
4. kube-apiserver 将这个 pod 和节点的绑定信息写入到 etcd，etcd 将结果返回给 kube-apiserver
5. kubelet 通过 kube-apiserver 的 watch 接口，获取到本节点有创建 pod 的信息，然后会调用 CRI 创建容器，并将 pod 的运行状态发送给 kube-apiserver
6. kube-apiserver 将 pod 状态信息更新到 etcd

记录刷题- -

Job：创建一个固定结束次数的并行 Job，共 2 个 pod，运行 45 completion，Job pod 打印“Beijing”，镜像自选。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

apiVersion: batch/v1
kind: Job
metadata:
  name: job
spec:
  parallelism: 2
  completions: 45
  restartPolicy: Never
  template:
    metadata:
      name: job
    spec:
      containers:
      - name: job
        image: busybox:latest
        command:
        - 'sh'
        - '-c'
        - 'echo Beijing'

initContainer：pod 的 container 在启动时会检查 volume 中某个目录是否存在某个文件，若不存在则退出，若存在，则运行。要求修改 pod 的 yaml，通过 initContainer 创建该文件，使pod运行。

1

将名为 ek8s-node-1 的 node 设置为不可用，并重新调度该 node 上所有运行的 pods。

1
2
3
4

# cordon:将node设置为不可用，将阻止新pod调度到该节点之上，但不会影响任何已经在其上的 pod，这是重启节点或者执行其他维护操作之前的一个有用的准备步骤，DaemonSet创建的pod能够容忍节点的不可调度属性。
kubectl cordon ek8s-node-1
# drain:从节点安全的驱逐所有pods。
kubectl drain ek8s-node-1 --delete-local-data --ignore-daemonsets --force

在现有的 namespace app-team1 中创建一个名为 cicd-token 的新 ServiceAccount，创建一个 deployment-clusterrole 且只能够创建 Deployment、DaemonSet、StatefulSet 资源的 Cluster Role，并将新的 deployment-clusterrole 绑定到 cicd-token。

1
2
3
4
5

kubectl create sa cicd-token -n app-team1

kubectl create clusterrole deployment-clusterrole --verb=create --resource=Deployment,StatefulSet,DaemonSet

kubectl create rolebinding cicd-rolebinding --clusterrole=deployment-clusterrolr --serviceaccount=app-team1:cicd-token

k8s master 1.20.0 升级到 1.20.1，并升级 kubelet、kubectl。

1
2
3
4
5
6
7
8
9
10

# 将节点设为不可调度性
kubectl cordon mk8s-master-0
kubectl drain mk8s-master-0 --igonre-daemonsets
# 升级
apt-get update
apt-get -y install kubeadm=1.20.1-00
kubeadm update apply v1.20.1 --etcd-upgrade=false
apt-get -y install kubelet=1.20.1-00 kubectl=1.20.1-00
# 将不可调度性去除
kubectl uncordon mk8s-master-0

etcd 备份/恢复。

1
2
3
4

# 备份
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=<trusted-ca-file> --cert=<cert-file> --key=<key-file> snapshot save <backup-file-location>
# 恢复
ETCDCTL_API=3 etcdctl --endpoints=https://127.0.0.1:2379 --cacert=<trusted-ca-file> --cert=<cert-file> --key=<key-file> snapshot restore <backup-file-location>

在 internal 的命名空间下创建一个名为 allow-port-from-namespace 的 NetworkPolicy，此 NetworkPolicy 允许 internal 中的 pod 访问 echo 命名空间中 9000 的端口。

1
2
3

# 先获取echo租户的labels
kubectl get ns echo --show-labels
echo-key: echo-value

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: allow-port-from-namespace
  namespace: internal
spec:
  podSelector: {}
  policyTypes:
  - Ingress
  ingress:
  - from:
    - namespaceSelector:
        matchLabels:
          echo-key: echo-value
    ports:
    - protocol: TCP
      port: 9000

在 ing-internal 下创建一个 ingress 名为 ping，通过 5678 端口暴露 hello svc 下的 /hello。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
  name: ping
  namespace: ing-internal
spec:
  rules:
  - http:
      paths:
      - path: /hello
        backend:
          service:
            name: hello
            port:
              number: 5678

将 deployment webserver 扩展至 6 pods。

1

kubectl scale deployment webserver --replicas 6

创建一个名为 nginx-kusc00401 的 pod，镜像为 nginx，调度到 disk=ssd 的节点上。

1
2
3
4
5
6
7
8
9
10
11
12
13
14

apiVersion: v1
kind: Pod
metadata:
  name: nginx-kusc00401
spec:
  containers:
  - name: nginx
    image: nginx:1.20.1
    imagePullPolicy: Always
    ports:
    - name: http
      containerPort: 80
  NodeSelector:
    disk=ssd

将一个现有的 pod 集成到 k8s 内置日志记录体系结构中（kubectl logs），使用 busybox 来将名为 sidecar 容器添加到名为 11-factor-app 的 pod 中，sidecar 需运行 /bin/sh -c tail -n+1 -f /var/log/11-factor-app.log ，使用安装在 /var/log 的 volume，使日志文件 11-factor-app.log 可用于 sidecar 容器。

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

apiVersion: v1
kind: Pod
metadata:
  name: 11-factor-app
spec:
  volumes:
  - name: log
    emptyDir: {}
  containers:
  - name: count
    image: busybox
    command:
    - /bin/sh
    - -c
    - >
      i=0;
      while true;
      do
        echo "$i: $(date)" >> /var/log/11-factor-app.log;
        i=$((i+1));
        sleep 1;
      done
    volumeMounts:
    - name: log
      mountPath: /var/log
  - name: sidecar
    image: busybox
    command:
    - /bin/sh
    - -c
    - 'tail -n+1 -f /var/log/11-factor-app.log'
    volumeMounts:
    - name: log
      mountPath: /var/log

通过 pod label name=cpu-utilizer 寻找 cpu 占用最多的 pod，并写入 /opt/tmp/tmp.txt。

1

kubectl top pod -A -l name=cpu-utilizer --sort-by=cpu >> /opt/tmp/tmp.txt

一、概念

1.1 k8s概述

Kubernetes 是一个可移植的、可扩展的开源平台，用于管理容器化的工作负载和服务，可促进声明式配置和自动化。 Kubernetes 拥有一个庞大且快速增长的生态系统。Kubernetes 的服务、支持和工具广泛可用。

容器是打包和运行应用程序的好方式。在生产环境中，你需要管理运行应用程序的容器，并确保不会停机。 例如，如果一个容器发生故障，则需要启动另一个容器。如果系统处理此行为，会不会更容易？

这就是 Kubernetes 来解决这些问题的方法！ Kubernetes 为你提供了一个可弹性运行分布式系统的框架。 Kubernetes 会满足你的扩展要求、故障转移、部署模式等。 例如，Kubernetes 可以轻松管理系统的 Canary 部署。

Kubernetes 简称 k8s，主要功能有：

• 服务发现和负载均衡
• 存储编排
• 自动部署和回滚
• 自动完成装箱计算
• 自我修复
• 密钥与配置管理

1.2 k8s组件

一个 Kubernetes 集群由一组被称作节点的机器组成。这些节点上运行 Kubernetes 所管理的容器化应用。集群具有至少一个工作节点。

工作节点托管作为应用负载的组件的 Pod 。控制平面管理集群中的工作节点和 Pod 。 为集群提供故障转移和高可用性，这些控制平面一般跨多主机运行，集群跨多个节点运行。

1.2.1 控制平面组件

kube-apiserver：

API 服务器是 Kubernetes 控制面的组件，该组件公开了 Kubernetes API。API 服务器是 Kubernetes 控制面的前端。

etcd：

etcd 是兼具一致性和高可用性的键值数据库，可以作为保存 Kubernetes 所有集群数据的后台数据库。

kube-scheduler：

控制平面组件，负责监视新创建的、未指定运行节点（node）的 Pods，选择节点让 Pod 在上面运行。

调度决策考虑的因素包括单个 Pod 和 Pod 集合的资源需求、硬件/软件/策略约束、亲和性和反亲和性规范、数据位置、工作负载间的干扰和最后时限。

kube-controller-manager：

在主节点上运行控制器的组件。

控制器包括：

• 节点控制器（Node Controller）: 负责在节点出现故障时进行通知和响应
• 任务控制器（Job controller）: 监测代表一次性任务的 Job 对象，然后创建 Pods 来运行这些任务直至完成
• 端点控制器（Endpoints Controller）: 填充端点(Endpoints)对象(即加入 Service 与 Pod)
• 服务帐户和令牌控制器（Service Account & Token Controllers）: 为新的命名空间创建默认帐户和 API 访问令牌

cloud-controller-manager：

云控制器管理器是指嵌入特定云的控制逻辑的控制平面组件。云控制器管理器允许您链接聚合到云提供商的应用编程接口中，并分离出相互作用的组件与您的集群交互的组件。

下面的控制器都包含对云平台驱动的依赖：

• 节点控制器（Node Controller）: 用于在节点终止响应后检查云提供商以确定节点是否已被删除
• 路由控制器（Route Controller）: 用于在底层云基础架构中设置路由
• 服务控制器（Service Controller）: 用于创建、更新和删除云提供商负载均衡器

1.2.2 Node组件

节点组件在每个节点上运行，维护运行的 Pod 并提供 Kubernetes 运行环境。

kubelet：

一个在集群中每个节点（node）上运行的代理。它保证容器（containers）都运行在 Pod 中。

kubelet 接收一组通过各类机制提供给它的 PodSpecs，确保这些 PodSpecs 中描述的容器处于运行状态且健康。 kubelet 不会管理不是由 Kubernetes 创建的容器。

容器运行时（Container Runtime）：

容器运行环境是负责运行容器的软件，例如 Docker 。

1.2.3 插件（Addons）

插件使用 Kubernetes 资源（DaemonSet、Deployment等）实现集群功能。 因为这些插件提供集群级别的功能，插件中命名空间域的资源属于 kube-system 命名空间。

DNS：

尽管其他插件都并非严格意义上的必需组件，但几乎所有 Kubernetes 集群都应该 有集群 DNS， 因为很多示例都需要 DNS 服务。

Web 界面（仪表盘）：

Dashboard 是Kubernetes 集群的通用的、基于 Web 的用户界面。 它使用户可以管理集群中运行的应用程序以及集群本身并进行故障排除。

容器资源监控：

容器资源监控将关于容器的一些常见的时间序列度量值保存到一个集中的数据库中，并提供用于浏览这些数据的界面。

集群层面日志：

集群层面日志机制负责将容器的日志数据 保存到一个集中的日志存储中，该存储能够提供搜索和浏览接口。

1.3 Pod

1.3.1 Pod概念

Pod 是 k8s 中的最小单元，一个 Pod 包含一个或多个容器，一个 Pod 不会跨越多个节点（Node）。

而每个 Pod 里都会有一个根容器 pause，Pod 中的其他容器都共享 pause 根容器的网络栈和volume挂载卷，因此容器之间的通信和数据交换会更为高效。

1.3.2 RC、RS、Deployment

k8s 管理 Pod 主要用到以下三个组件：

• Replication Controller（RC）：用来确保容器应用的副本数始终保持在用户定义的副本数，如果有容器异常退出，会自动创建新的 Pod 来代替，如果有异常多出的容器也会自动回收。
• ReplicaSet（RS）：相比 RC 多了支持 selector，推荐使用 RS。
• Deployment：用来管理 RS。

来看看 Deployment 和 RS 是如何实现更新的：

1. Deployment 创建新的 RS

2. RS1删除一个容器，接着 RS2 新建一个新版本的 Pod

3. 全部更新完之后，RS1 并不会删除，而是保留着处于停用状态，如果新版本出了问题需要回滚，就可以反过来操作实现回滚

1.3.3 Horizontal Pod Autoscaler

Horizontal Pod Autoscaler（HPA）在k8s集群中用于 Pod 水平自动弹性伸缩，它是基于 CPU 和内存利用率对 Deployment 和 RS 中的 Pod 数量进行自动扩缩容（除了 CPU 和内存利用率之外，也可以基于其他应程序提供的度量指标 custom metrics 进行自动扩缩容）。

假如 HPA 检测到当前 Deployment 和 RS 所管理的 Pod 的 CPU 或内存使用率超过了设定之后，就会创建新的 Pod 来实现降压，新建 Pod 的数量限制由 Max 和 Min 设定。

1.3.4 StatefulSet

RS 和 Deployment 都是面向无状态的服务，它们所管理的 Pod 的 IP、名字，启停顺序等都是随机的，而 StatefulSet 是有状态的集合，管理所有有状态的服务，比如 MySQL、MongoDB 集群等。

StatefulSet 的特点有：

Pod 的一致性：包含次序（启停顺序，例如 mysql -> php-fpm -> nginx 的启动顺序）、网络一致性（与 Pod 相关，与被调度的 Node 节点无关）。

稳定的存储：即 Pod 重新调度之后还是访问到相同的持久化数据，基于 PVC（PV 是集群中由管理员提供或使用存储类动态提供的一块存储。它是集群中的资源，就像节点是集群资源一样。而 PVC 是用户对存储的请求。它类似于 Pod，Pod 消耗 Node 资源，而 PVC 消耗 PV 资源。） 来实现。

稳定的次序：对于N个副本的 StatefulSet，每个 Pod 都在 [0，N) 的范围内分配一个数字序号，且是唯一的。

稳定的网络：Pod 的 hostname 模式为：( StatefulSet 名称 ) - ( 序号 )。

1.3.5 DaemonSet

DaemonSet 确保全部或者一部分 Node 上运行一个 Pod 的副本，当有 Node 加入集群时，也会为他们新增一个 Pod，当这些 Node 退出集群时，这些 Pod 也会被回收。

DaemonSet 的一些典型用法：

• 运行集群存储 daemon，例如在每个 Node 上运行 glusterd、ceph等。
• 运行日志收集daemon，例如fluentd、logstash等。
• 运行监控daemon，例如 Prometheus 的 Node exporter、zabbix等。

1.3.6 Job和Cron Job

Job 负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个 Pod 成功结束。

这里可能有人会想，那在 linux 上直接执行脚本不就行了吗？其实这就会有个问题，如果脚本执行失败那么久退出且不会再执行了，需要执行就必须手动，但 Job 设置的任务只有在正常执行结束后才会结束，否则一直执行到成功为止。Job 也可以设置成功的次数要达到几次才允许退出。

Cron Job 是基于时间管理控制 Job，即在给定的时间只运行一次、周期性的在指定时间运行。

1.3.7 Service

Pod 的生命是有限的，如果 Pod 重启 IP 也可能会发生变化。如果我们将 Pod 的 IP 写死，Pod 如果挂了或重启，其它的服务也会不可用。我们可以把我们的服务（各种 Pod）注册到服务发现中心去，让服务发现中心去动态更新其它服务的配置就可以了，k8s 就给我们提供了这么一个服务，即 Service。

我们这样就可以不用去管后端的 Pod 如何变化，只需要指定 Service 的地址就可以了，因为我们在中间添加了一层服务发现的中间件，Pod 销毁或者重启后，把这个 Pod 的地址注册到这个服务发现中心去。

1.4 k8s的网络通讯方式

k8s 的网络模型假定了所有的 Pod 都在一个可以直接连通的扁平化网络空间中，在这 GCE（Google Compute Engine）里面是现成的网络模型。

Flannel 是 CoreOS 团队针对 Kubernetes 设计一个网络规划服务，简单来说，它的功能是让集群中的不同节点主机创建 Docker 容器都具有全集群唯一的虚拟 IP 地址。而且它还能在这些 IP 地址之间建立一个覆盖网络（Overlay Network），通过覆盖网络将数据包原封不动的传递到目标容器内。

通过一个架构图来看看不同情况下的通讯是怎么样的：

通讯情况主要分为以下几种：

1. 同一 Pod 不同容器之间的通信：采用 pause 网络栈。
2. 同一 Node 不同 Pod 之间的通信：通过 docker0 网桥进行通信。

1. 不同 Node 的 Pod 之间的通信：不同 Node 的 Pod 之间的通信是 k8s 网络通信的难点，是通过 Flannel 网络通讯方式来实现的，通讯的过程分为以下几个步骤：
   • 数据包从 Node1 的 Pod 到达 docker0 网桥
   • Flanneld 会开启一个 Flannel0 的网桥，用来抓取到达 docker0 的数据，可以理解为一个钩子函数
   • Flanneld 会有很多路由表信息，是存储在 etcd 中由 Flanneld 自动获取的，通过路由表知道了转发信息后就通过物理网卡进行转发
   • 发送到目标主机的物理网卡后，就会再通过 Flanneld -> Flannel0网桥 -> docker0网桥，最终到达目的 Pod

1. Pod 与 service 之间的通信：采用各节点的 iptables 规则来实现。
2. Pod 到外网：通过 Flanneld 到达物理网卡，经过路由选择后，iptables 执行 Masquerade，把Pod 的虚拟 IP 改为 物理网卡的 IP，在向外网服务器发出请求。
3. 外网到 Pod：通过 service 进行访问，一般使用 NodePort。

二、k8s部署

本次 k8s 部署为以下环境

2.1 基本环境配置（所有节点）

1. 在各主机设置主机名以及host文件解析

1
2
3
4
5
6
7

hostnamectl set-hostname k8s-master01
hostnamectl set-hostname k8s-node01
hostnamectl set-hostname k8s-node02
vim /etc/hosts
192.168.88.10 k8s-master01
192.168.88.20 k8s-node01
192.168.88.21 k8s-node02

2. 安装依赖

1

yum -y install conntrack ntpdate ntp ipvsadm ipset jp iptables curl stsstat libseccomp wget vim net-tools git

3. 设置防火墙为iptables并设置空规则

1
2
3
4
5

systemctl stop firewalld && systemctl disable firewalld
yum -y install iptables-services
systemctl start iptables
systemctl enable iptables
iptables -F && service iptables save

4. 关闭虚拟内存和selinux

1
2

swapoff -a && sed -i '/ swap / s/^\(.*\)$/#/g' /etc/fstab
setenforce 0 && sed -i 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config

5. 调整内核参数

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

cat > kubernetes.conf <<EOF
net.bridge.bridge-nf-call-iptables=1
net.bridge.bridge-nf-call-ipv6tables=1
net.ipv4.ip_forward=1
net.ipv4.tcp_tw_recycle=0
vm.swappiness=0 # 禁用swap，只有系统OOM时才允许使用
vm.overcommit_memory=1 # 不检查物理内存是否够用
vm.panic_on_oom=0 # 开启OOM
fs.inotify.max_user_instances=8192
fs.inotify.max_user_watches=1048576
fs.file-max=52706963
fs.nr_open=52706963
net.ipv6.conf.all.disable_ipv6=1
net.netfilter.nf_conntrack_max=2310720
EOF
cp kubernetes.conf /etc/sysctl.d/kubernetes.conf
sysctl -p /etc/sysctl.d/kubernetes.conf

6. 调整系统时区

1
2
3
4
5
6
7

# 设为中国/上海
timedatectl set-timezone Asia/Shanghai
# 将当前UTC时间写入硬件时钟
timedatectl set-local-rtc 0
# 重启依赖于时间的服务
systemctl restart rsyslog
systemctl restart crond

7. 关闭不需要的服务

1
2

# 关闭邮件服务
systemctl stop postfix && systemctl disable postfix

8. 设置rsyslog和systemd journald

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

# 持久化保存日志目录
mkdir /var/log/journal
mkdir /etc/systemd/journald.conf.d
cat > /etc/systemd/journald.conf.d/99-prophet.conf <<EOF
[Journal]
#持久化保存到磁盘
Storage=persistent

#压缩历史日志
Compress=yes
 
SyncIntervalSec=5m
RateLimitInterval=30s
RateLimitBurst=1000

#最大占用空间 10G
SystemMaxUse=10G

#单日志文件最大 200M
SystemMaxFileSize=200M

#日志保存时间 2 周
MaxRetentionSec=2week

#不将日志转发到 syslog
ForwardToSyslog=no
EOF

systemctl restart systemd-journald

9. 升级内核

1
2
3
4
5
6
7
8
9
10

# 导入公钥
rpm --import https://www.elrepo.org/RPM-GPG-KEY-elrepo.org
# 安装elrepo源
yum -y install https://www.elrepo.org/elrepo-release-7.el7.elrepo.noarch.rpm
# 升级内核
yum --enablerepo=elrepo-kernel install -y kernel-lt
# 设置开机从新内核启动
grub2-set-default "CentOS Linux (5.4.116-1.e17.elrepo.x86_64) 7 (Core)"
# 查看内核启动项
grub2-editenv list

2.2 kubeadm部署（所有节点）

1. kube-proxy开启ipvs前置条件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

modprobe br_netfilter

vim /etc/sysconfig/modules/ipvs.modules
#!/bin/bash
ipvs_modules="ip_vs ip_vs_lc ip_vs_wlc ip_vs_rr ip_vs_wrr ip_vs_lblc ip_vs_lblcr ip_vs_dh ip_vs_sh ip_vs_fo ip_vs_nq ip_vs_sed ip_vs_ftp nf_conntrack"

for kernel_module in ${ipvs_modules};
do
    /sbin/modinfo -F filename ${kernel_module} > /dev/null 2>&1
    if [ $? -eq 0 ]; then
        /sbin/modprobe ${kernel_module}
    fi
done

chmod 755 /etc/sysconfig/modules/ipvs.modules && bash /etc/sysconfig/modules/ipvs.modules && lsmod | grep -e ip_vs -e nf_conntrack

2. 安装docker

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

yum -y install yum-utils device-mapper-persistent-data lvm2

yum-config-manager --add-repo https://mirrors.tuna.tsinghua.edu.cn/docker-ce/linux/centos/docker-ce.repo

yum makecache fast
yum -y install docker-ce docker-ce-cli

mkdir /etc/docker
cat > /etc/docker/daemon.json <<EOF
{
        "registry-mirrors": ["http://f1361db2.m.daocloud.io"],
        "exec-opts":["native.cgroupdriver=systemd"],
        "log-driver":"json-file",
        "log-opts":{
                "max-size":"100m"
        }
}
EOF
mkdir -p /etc/systemd/system/docker.service.d

systemctl daemon-reload && systemctl start docker && systemctl enable docker

2.3 安装kubeadm（所有节点）

1. 安装 kubeadm kubectl kubelet

1
2
3
4
5
6
7
8
9
10
11
12

cat <<EOF > /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
EOF

yum -y install kubeadm kubectl kubelet
systemctl enable kubelet

2. 通过kubeadm查看目前各镜像版本

1
2
3
4
5
6
7
8

kubeadm config images list
k8s.gcr.io/kube-apiserver:v1.21.0
k8s.gcr.io/kube-controller-manager:v1.21.0
k8s.gcr.io/kube-scheduler:v1.21.0
k8s.gcr.io/kube-proxy:v1.21.0
k8s.gcr.io/pause:3.4.1
k8s.gcr.io/etcd:3.4.13-0
k8s.gcr.io/coredns/coredns:v1.8.0

3. 编写脚本，通过阿里镜像安装

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

vim k8s_images.sh

#!/bin/bash
apiserver_var=v1.21.0
controller_manager_var=v1.21.0
scheduler_var=v1.21.0
proxy_var=v1.21.0
pause_var=3.4.1
etcd_var=3.4.13-0
coredns_var=v1.8.0
image_aliyun=(kube-apiserver:$apiserver_var kube-controller-manager:$controller_manager_var kube-scheduler:$scheduler_var kube-proxy:$proxy_var pause:$pause_var etcd:$etcd_var coredns/coredns:$coredns_var)

for image in ${image_aliyun[@]}
do
    docker pull registry.cn-hangzhou.aliyuncs.com/google_containers/$image
    docker tag  registry.cn-hangzhou.aliyuncs.com/google_containers/$image k8s.gcr.io/${image}
    docker rmi  registry.cn-hangzhou.aliyuncs.com/google_containers/$image
done

./k8s_images.sh

# 问题
# 由于杭州阿里源里目前没有coredns:v1.8.0版本，所以在北京阿里源下载
docker pull registry.cn-beijing.aliyuncs.com/dotbalo/coredns:1.8.0
docker tag  registry.cn-beijing.aliyuncs.com/dotbalo/coredns:1.8.0 k8s.gcr.io/coredns/coredns:v1.8.0
docker rmi  registry.cn-beijing.aliyuncs.com/dotbalo/coredns:1.8.0

2.4 初始化Master节点

1

kubeadm config print init-defaults > kubeadm.config.yml

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

vim kubeadm.config.yml
apiVersion: kubeadm.k8s.io/v1beta2
bootstrapTokens:
- groups:
  - system:bootstrappers:kubeadm:default-node-token
  token: abcdef.0123456789abcdef
  ttl: 24h0m0s
  usages:
  - signing
  - authentication
kind: InitConfiguration
localAPIEndpoint:
  # 改成master节点IP地址
  advertiseAddress: 192.168.88.10
  bindPort: 6443
nodeRegistration:
  criSocket: /var/run/dockershim.sock
  name: node
  taints: null
---
apiServer:
  timeoutForControlPlane: 4m0s
apiVersion: kubeadm.k8s.io/v1beta2
certificatesDir: /etc/kubernetes/pki
clusterName: kubernetes
controllerManager: {}
dns:
  type: CoreDNS
etcd:
  local:
    dataDir: /var/lib/etcd
imageRepository: k8s.gcr.io
kind: ClusterConfiguration
kubernetesVersion: 1.21.0
networking:
  dnsDomain: cluster.local
  podSubnet: 10.244.0.0/16
  serviceSubnet: 10.96.0.0/12
scheduler: {}
# 添加这一段
---
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
kubeproxy:
  config:
    mode: ipvs

1
2
3
4
5
6

kubeadm init --config=kubeadm.config.yml --upload-certs | tee kubeadm-init.log
...
# 初始化后操作
mkdir -p $HOME/.kube
cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
chown $(id -u):$(id -g) $HOME/.kube/config

2.5 部署网络

1
2
3

mkdir -p k8s/plugin/flannel && cd k8s/plugin/flannel
wget https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml
kubectl create -f kube-flannel.yml

kube-flannel.yml文件内容

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
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223

---
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: psp.flannel.unprivileged
  annotations:
    seccomp.security.alpha.kubernetes.io/allowedProfileNames: docker/default
    seccomp.security.alpha.kubernetes.io/defaultProfileName: docker/default
    apparmor.security.beta.kubernetes.io/allowedProfileNames: runtime/default
    apparmor.security.beta.kubernetes.io/defaultProfileName: runtime/default
spec:
  privileged: false
  volumes:
  - configMap
  - secret
  - emptyDir
  - hostPath
  allowedHostPaths:
  - pathPrefix: "/etc/cni/net.d"
  - pathPrefix: "/etc/kube-flannel"
  - pathPrefix: "/run/flannel"
  readOnlyRootFilesystem: false
  # Users and groups
  runAsUser:
    rule: RunAsAny
  supplementalGroups:
    rule: RunAsAny
  fsGroup:
    rule: RunAsAny
  # Privilege Escalation
  allowPrivilegeEscalation: false
  defaultAllowPrivilegeEscalation: false
  # Capabilities
  allowedCapabilities: ['NET_ADMIN', 'NET_RAW']
  defaultAddCapabilities: []
  requiredDropCapabilities: []
  # Host namespaces
  hostPID: false
  hostIPC: false
  hostNetwork: true
  hostPorts:
  - min: 0
    max: 65535
  # SELinux
  seLinux:
    # SELinux is unused in CaaSP
    rule: 'RunAsAny'
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: flannel
rules:
- apiGroups: ['extensions']
  resources: ['podsecuritypolicies']
  verbs: ['use']
  resourceNames: ['psp.flannel.unprivileged']
- apiGroups:
  - ""
  resources:
  - pods
  verbs:
  - get
- apiGroups:
  - ""
  resources:
  - nodes
  verbs:
  - list
  - watch
- apiGroups:
  - ""
  resources:
  - nodes/status
  verbs:
  - patch
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: flannel
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: flannel
subjects:
- kind: ServiceAccount
  name: flannel
  namespace: kube-system
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: flannel
  namespace: kube-system
---
kind: ConfigMap
apiVersion: v1
metadata:
  name: kube-flannel-cfg
  namespace: kube-system
  labels:
    tier: node
    app: flannel
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"
      }
    }
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: kube-flannel-ds
  namespace: kube-system
  labels:
    tier: node
    app: flannel
spec:
  selector:
    matchLabels:
      app: flannel
  template:
    metadata:
      labels:
        tier: node
        app: flannel
    spec:
      affinity:
        nodeAffinity:
          requiredDuringSchedulingIgnoredDuringExecution:
            nodeSelectorTerms:
            - matchExpressions:
              - key: kubernetes.io/os
                operator: In
                values:
                - linux
      hostNetwork: true
      priorityClassName: system-node-critical
      tolerations:
      - operator: Exists
        effect: NoSchedule
      serviceAccountName: flannel
      initContainers:
      - name: install-cni
        image: quay.io/coreos/flannel:v0.14.0-rc1
        command:
        - cp
        args:
        - -f
        - /etc/kube-flannel/cni-conf.json
        - /etc/cni/net.d/10-flannel.conflist
        volumeMounts:
        - name: cni
          mountPath: /etc/cni/net.d
        - name: flannel-cfg
          mountPath: /etc/kube-flannel/
      containers:
      - name: kube-flannel
        image: quay.io/coreos/flannel:v0.14.0-rc1
        command:
        - /opt/bin/flanneld
        args:
        - --ip-masq
        - --kube-subnet-mgr
        resources:
          requests:
            cpu: "100m"
            memory: "50Mi"
          limits:
            cpu: "100m"
            memory: "50Mi"
        securityContext:
          privileged: false
          capabilities:
            add: ["NET_ADMIN", "NET_RAW"]
        env:
        - name: POD_NAME
          valueFrom:
            fieldRef:
              fieldPath: metadata.name
        - name: POD_NAMESPACE
          valueFrom:
            fieldRef:
              fieldPath: metadata.namespace
        volumeMounts:
        - name: run
          mountPath: /run/flannel
        - name: flannel-cfg
          mountPath: /etc/kube-flannel/
      volumes:
      - name: run
        hostPath:
          path: /run/flannel
      - name: cni
        hostPath:
          path: /etc/cni/net.d
      - name: flannel-cfg
        configMap:
          name: kube-flannel-cfg

部署完后可以看到 flannel 网卡

通过命令查看各模块运行情况

1

kubectl get pod -n kube-system

2.6 添加Node节点

1. 查看kubeadm-init.log

1
2
3

...
kubeadm join 192.168.88.10:6443 --token abcdef.0123456789abcdef \
    --discovery-token-ca-cert-hash sha256:37c9645a7a2ee75301f132537240157ecd4f464494022cc442f77489c1978989

2. 在node主机上执行

1
2

kubeadm join 192.168.88.10:6443 --token abcdef.0123456789abcdef \
    --discovery-token-ca-cert-hash sha256:37c9645a7a2ee75301f132537240157ecd4f464494022cc442f77489c1978989

3. 在master主机查看是否加入成功

1
2
3
4

kubectl get node
...
kubectl get pod -n kube-system -o wide
...

三、k8s资源清单

在 k8s 中，一般使用 yaml 格式的文件来创建符合我们预期期望的 pod，这样的 yaml 文件我们一般称为资源清单。

3.1 资源类型

名称空间级别

工作负载型资源：Pod、RS、Deployment、StatefulSet、DaemonSet、Job、CronJob

服务发现及负载均衡型资源：Service

配置与存储型资源：Volume、CSI

特殊类型的存储卷：ConfigMap(当配置中心来使用的资源类型)、Secret(保存敏感数据)、DownwarAPI(把外部环境中的信息输出给容器)

集群级资源：Namespace、Node、Role、ClusterRole、RoleBinding、ClusterRoleBinding

元数据型资源：HPA、PodTemplate、LimitRange

3.2 常用字段

必要属性

spec 主要对象

额外的参数项

辅助命令

1
2

# 查看资源对象用法
kubectl explain <资源对象> 

例子：

1. 创建 yaml 文件

1
2
3
4
5
6
7
8
9
10
11
12

vim nginx.yaml
# 此处只有必要字段
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
  labels:
    app: nginx
spec:
  containers:
  - name: nginx
    image: daocloud.io/library/nginx:latest

2. 创建pod

1

kubectl apply -f nginx.yaml

3. 查看状态

1
2
3
4
5
6
7
8
9

# 查看是否生成pod
kubectl get pod
...
# 查看pod详细信息
kubectl describe pod nginx-pod
...
# 测试能否访问
curl 10.244.1.2 # 此处为flannel分配的地址
...

3.3 容器生命周期

每一个 Pod 被成功创立之前，都会进行初始化，会运行零个或若干个 init 容器，init 容器运行完就释放，接着才会运行 main 主容器，当然在 init 容器运行之前会先运行 pause 容器，以保证存储和网络的可用。

init 容器与普通的容器非常相似，除了以下两点：

• init 容器总是运行到完成。
• 每个 init 容器都要在下一个容器启动之前完成。

如果 Pod 的 Init 容器失败，kubelet 会不断地重启该 Init 容器直到该容器成功为止。 然而，如果 Pod 对应的 restartPolicy 值为 “Never”，Kubernetes 不会重新启动 Pod。

如果为一个 Pod 指定了多个 Init 容器，这些容器会按顺序逐个运行。 每个 Init 容器必须运行成功，下一个才能够运行。当所有的 Init 容器运行完成时， Kubernetes 才会为 Pod 初始化应用容器并像平常一样运行。

init 容器的使用

因为 Init 容器具有与应用容器分离的单独镜像，其启动相关代码具有如下优势：

• Init 容器可以包含一些安装过程中应用容器中不存在的实用工具或个性化代码。 例如，没有必要仅为了在安装过程中使用类似 sed、awk、python 或 dig 这样的工具而去 FROM 一个镜像来生成一个新的镜像。
• Init 容器可以安全地运行这些工具，避免这些工具导致应用镜像的安全性降低。
• 应用镜像的创建者和部署者可以各自独立工作，而没有必要联合构建一个单独的应用镜像。
• Init 容器能以不同于 Pod 内应用容器的文件系统视图运行。因此，Init 容器可以访问应用容器不能访问的 Secret 的权限。
• 由于 Init 容器必须在应用容器启动之前运行完成，因此 Init 容器提供了一种机制来阻塞或延迟应用容器的启动，直到满足了一组先决条件。 一旦前置条件满足，Pod 内的所有的应用容器会并行启动。

init 容器使用例子

1. 编写 yaml 文件

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

vim busybox.yaml
apiVersion: v1
kind: Pod
# 定义了一个 Pod 叫 busybox-pod，busybox 封装了 linux 的大量命令
metadata:
  name: busybox-pod
  labels:
    app: busybox
# 定义该 Pod 下的资源，也就是容器
spec:
  # 定义了一个 busybox 容器
  containers:
  - name: busybox
    image: busybox:latest
    command: ['sh','-c','echo The busybox app is running! && sleep 3600']
  # 定义 init 容器，init 容器全部执行完前不会执行 busybox 容器
  initContainers:
    # 第一个 init 容器，如果检查 service 中没有注册 myservice，则休眠2秒继续执行，直到成功
  - name: init-myservice
    image: busybox
    command: ['sh','-c','until nslookup myservice; do echo waiting for myservice; sleep 2; done']
    # 第一个 init 容器运行完就运行该 init 容器，检查 service 中有没有注册 mydb
  - name: init-mydb
    image: busybox
    command: ['sh','-c','until nslookup mydb; do echo waiting for mydb; sleep 2; done']

2. 运行

1

kubectl create -f busybox.yaml

3. 可以看到一直处于 Init:0/2 状态，因为第一个 init 容器一直没完成

4. 编写 yaml 文件添加 service

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

vim service.yaml
apiVersion: v1
kind: Service
metadata:
  name: myservice
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9376
---
apiVersion: v1
kind: Service
metadata:
  name: mydb
spec:
  ports:
  - protocol: TCP
    port: 80
    targetPort: 9377

5. 运行

1

kubectl create -f service.yaml

6. 可以看到两个 init 容器都执行完，main 主容器也就运行了

3.4 探针

探针（probe）是由 kubelet 对容器执行的定期诊断。 要执行诊断，kubelet 调用由容器实现的 Handler （处理程序）。有三种类型的处理程序：

• ExecAction： 在容器内执行指定命令。如果命令退出时返回码为 0 则认为诊断成功。
• TCPSocketAction： 对容器的 IP 地址上的指定端口执行 TCP 检查。如果端口打开，则诊断被认为是成功的。
• HTTPGetAction： 对容器的 IP 地址上指定端口和路径执行 HTTP Get 请求。如果响应的状态码大于等于 200 且小于 400，则诊断被认为是成功的。

每次探测都将获得以下三种结果之一：

• Success（成功）：容器通过了诊断。
• Failure（失败）：容器未通过诊断。
• Unknown（未知）：诊断失败，因此不会采取任何行动。

探针可以分为以下三种：

• livenessProbe：指示容器是否正在运行。如果存活态探测失败，则 kubelet 会杀死容器， 并且容器将根据其重启策略决定未来。如果容器不提供存活探针， 则默认状态为 Success。
• readinessProbe：指示容器是否准备好为请求提供服务。如果就绪态探测失败， 端点控制器将从与 Pod 匹配的所有服务的端点列表中删除该 Pod 的 IP 地址。 初始延迟之前的就绪态的状态值默认为 Failure。 如果容器不提供就绪态探针，则默认状态为 Success。
• startupProbe: 指示容器中的应用是否已经启动。如果提供了启动探针，则所有其他探针都会被禁用，直到此探针成功为止。如果启动探测失败，kubelet 将杀死容器，而容器依其重启策略进行重启。 如果容器没有提供启动探测，则默认状态为 Success。

3.4.1 readinessProbe就绪检测

1. 编写 yaml 文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

vim readinessProbe.yaml
apiVersion: v1
kind: Pod
metadata:
  name: readiness-httpget-pod
  namespace: default
spec:
  containers:
    - name: readiness-httpget-container
      image: daocloud.io/library/nginx:latest
      # 调用readinessProbe探针
      readinessProbe:
        httpGet:
          # 检查80端口
          port: 80
          # 检查该目录下的网页
          path: /test.html
        # 容器启动1秒后才进行检测
        initialDelaySeconds: 1
        # 每3秒检测一次
        periodSeconds: 3

2. 生成 Pod

1

kubectl create -f readinessProbe.yaml

3. 可以看到虽然 Pod 运行了，但 ready 状态是不对的

4. 进入容器创建文件，问题即可解决

1
2

kubectl exec -it readiness-httpget-pod -- /bin/sh
echo 'this is test' > /usr/share/nginx/html/test.html

3.4.2 livenessProbe存活检测

livenessProbe-exec

1. 编写 yaml 文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

vim livenessProbe_exec.yaml
apiVersion: v1
kind: Pod
metadata:
  name: liveness-exec-pod
  namespace: default
spec:
  containers:
  - name: liveness-exec-container
    image: busybox
    command: ['sh','-c','touch /tmp/test; sleep 60; rm -rf /tmp/test; sleep 3600']
    # 查看本地是否有镜像，有则使用，没有则下载
    imagePullPolicy: IfNotPresent
    livenessProbe:
      exec:
        command: ['test','-e','/tmp/test']
      initialDelaySeconds: 1
      periodSeconds: 3

2. 生成 Pod

1

kubectl create -f livenessProbe.yaml

3. 可以看到当 test 文件给删除的时候，Pod 就会重启，重启后又会有 test 文件，一直循环下去

livenessProbe-httpget

1. 编写 yaml 文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

vim livenessProbe_httpget.yaml
apiVersion: v1
kind: Pod
metadata:
  name: liveness-httpget-pod
  namespace: default
spec:
  containers:
    - name: liveness-httpget-container
      image: daocloud.io/library/nginx:latest
      ports:
      - name: http
        containerPort: 80
      # Pod生成1秒之后会每3秒检测一次是否存在index.html文件，如果超过10秒没有则重启Pod
      livenessProbe:
        httpGet:
          port: http
          path: /index.html
        initialDelaySeconds: 1
        periodSeconds: 3
        # 允许超时时间
        timeoutSeconds: 10

2. 创建容器，可以看到是在正常运行的

1

kubectl create -f livenessProbe_httpget.yaml

3. 删除 index.html 文件，可以看到会执行重启

1
2

kubectl exec -it liveness-httpget-pod -- /bin/sh
rm -rf /usr/share/nginx/html/index.html

livenessProbe-tcp

1. 编写 yaml 文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

vim livenessProbe_tcp.yaml
apiVersion: v1
kind: Pod
metadata:
  name: liveness-tcp-pod
  namespace: default
spec:
  containers:
  - name: liveness-tcp-container
    image: daocloud.io/library/nginx:latest
    livenessProbe:
      initialDelaySeconds: 5
      timeoutSeconds: 1
      tcpSocket:
        port: 8080
      periodSeconds: 3

2. 生成 Pod，会发现一直处于重启状态

1

kubectl create -f livenessProbe_tcp.yaml

3.4.3 Start 和 Stop

Start 和 Stop 是指 Pod 在生成后执行和结束前执行的命令

1. 编写 yaml 文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

vim start_stop.yml
apiVersion: v1
kind: Pod
metadata:
  name: start-stop-pod
  namespace: default
spec:
  containers:
  - name: start-stop-container
    image: daocloud.io/library/nginx:latest
    lifecycle:
      postStart:
        exec:
          command: ['/bin/sh','-c','echo this is postStart test > /usr/share/message']
      preStop:
        exec:
          command: ['/bin/sh','-c','echo this is preStop test > /usr/share/message']

2. 生成 Pod，进入 Pod 可以看到 Start 执行的命令，由于 Pod 停止后就没有了，所以看不到 Stop 执行的命令

1

kubectl exec -it start-stop-pod -- /bin/sh

四、k8s控制器

4.1 什么是控制器

k8s 中内置了很多 controller，用来控制 Pod 的具体状态和行为。

控制器的类型有：

• ReplicationController（已弃用） 和 ReplicaSet
• Deployment
• DaemonSet
• StateFulSet
• Job 和 CronJob
• Horizontal Pod Autoscaling

4.2 RS 与 Deployment

k8s 管理 Pod 主要用到以下三个组件：

• Replication Controller（RC）：用来确保容器应用的副本数始终保持在用户定义的副本数，如果有容器异常退出，会自动创建新的 Pod 来代替，如果有异常多出的容器也会自动回收。
• ReplicaSet（RS）：相比 RC 多了支持 selector，推荐使用 RS。
• Deployment：用来管理 RS。

RS 单独使用

1. 编写 yaml 文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

vim rs_test.yaml
apiVersion: apps/v1
kind: ReplicaSet
metadata:
  # RS名称
  name: rs-test
spec:
  # 设置副本数
  replicas: 3
  selector:
    # 设置标签
    matchLabels:
      tier: rs-test
  # 设置模板，会根据此模板生成Pod
  template:
    metadata:
      # 与上边RS设置的标签相对应，说明根据该模板创建的Pod都由标签相对RS管理
      labels:
        tier: rs-test
    spec:
      containers:
      - name: rs-nginx-container
        image: daocloud.io/library/nginx:latest

2. 生成 RS，可以看到会根据 replicas设置的数量创建 Pod

1

kubectl create -f rs_test.yaml

3. 删除这些 Pod，RS 也会按照副本数重新建立新的 Pod

1

kubectl delete pod --all

RS 与 Deployment

1. 编写 yaml 文件

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

vim nginx_deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
# Deployment详细信息
spec:
  # 副本数
  replicas: 3
  # 选择标签
  selector:
    # 标签匹配，与Deployment对应
    matchLabels:
      app: nginx-deployment
  # Pod模板
  template:
    metadata:
      # 定义标签
      labels:
        app: nginx-deployment
    spec:
      containers:
      - name: nginx-deployment-container
        image: daocloud.io/library/nginx:latest
        ports:
        - containerPort: 80

2. 生成 Deployment

1
2

kubectl create -f nginx_deployment.yaml --record
record:记录命令，方便每次 reversion 的变化

3. 可以看到会生成对应的 RS 和 Pod

4. 扩容

1

kubectl scale deployment nginx-deployment --replicas 5

5. 更新镜像

1

kubectl set image deployment/nginx-deployment nginx-deployment-container=daocloud.io/library/nginx:1.19.1

可以看到会创建一个新的 RS，以实现灰度更新

6. 回滚

1

kubectl rollout undo deployment/nginx-deployment

7. 查看回滚状态

1

kubectl rollout status deployment/nginx-deployment

8. 查看历史版本

1

kubectl rollout history deployment/nginx-deployment

9. 回到历史指定版本

1

kubectl rollout undo deployment/nginx-deployment --to-revision=1

10. 暂停更新

1

kubectl rollout pause deployment/nginx-deployment

4.3 DaemonSet

DaemonSet 确保全部或者一部分 Node 上运行一个 Pod 的副本，当有 Node 加入集群时，也会为他们新增一个 Pod，当这些 Node 退出集群时，这些 Pod 也会被回收。

DaemonSet 的一些典型用法：

• 运行集群存储 daemon，例如在每个 Node 上运行 glusterd、ceph等。
• 运行日志收集daemon，例如fluentd、logstash等。
• 运行监控daemon，例如 Prometheus 的 Node exporter、zabbix等。

1. 编写 yaml 文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

vim daemonset_test.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  # DaemonSet名称
  name: daemonset-test
  # 设置标签
  labels:
    app: daemonset-nginx
spec:
  selector:
    # 该标签要与上边标签一致
    matchLabels:
      name: daemonset-nginx
  template:
    metadata:
      labels:
        name: daemonset-nginx-pod
    spec:
      containers:
      - name: daemonset-nginx-container
        image: daocloud.io/library/nginx:latest

2. 生成 DaemonSet

1

kubectl create -f daemonset_test.yaml

3. 删除一个 Pod 之后 DaemonSet 为保证每个节点都至少有一个副本，就会重新创建新的 Pod

4.4 Job 和 CronJob

4.4.1 Job

Job 负责批处理任务，即仅执行一次的任务，它保证批处理任务的一个或多个 Pod 成功结束。

Job spec

• spec.template格式同 Pod 相同

• RestartPolicy仅支持Never和OnFailure

• 单个 Pod 时，默认 Pod 成功运行后 Job 即结束

• spec.completions标志 Job 结束时需要成功运行的 Pod 个数，默认为1

• spec.parallelism标志并行运行的 Pod 个数，默认为1

• spec.activeDeadlineSeconds标志失败 Pod 的重试最大时间，超过该时间就不会再重试

1. 编写 yaml 文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

vim job.yaml
apiVersion: batch/v1
kind: Job
metadata:
  name: job
spec:
  template:
    metadata:
      name: job-pod
    spec:
      containers:
      - name: job-pod-container
        image: perl
        imagePullPolicy: IfNotPresent
        # 通过perl语言进行圆周率计算，计算小数点后2000位
        command: ['perl','-Mbignum=bpi','-wle','print bpi(2000)']
      restartPolicy: Never

2. 生成 Job，可以看到开始是 Running，接着就是 Completed，代表 Job 已经完成

1

kubectl create -f job.yaml

3. 查看日志可以看到计算好的圆周率

4.4.2 CronJob

Cron Job 是基于时间管理控制 Job，即在给定的时间只运行一次、周期性的在指定时间运行。

CronJob spec

• 所有 CronJob 的 schedule: 时间都是基于 kube-controller-manager 的时区。
• .spec.schedule 是 .spec 需要的域。它使用了 Cron 格式串，例如 0 * * * * or @hourly ，做为它的任务被创建和执行的调度时间。
• .spec.jobTemplate是任务的模版，是必须项。
• .spec.startingDeadlineSeconds 域是可选项。它表示任务如果由于某种原因错过了调度时间，开始该任务的截止时间的秒数。过了截止时间，CronJob 就不会开始任务。 不满足这种最后期限的任务会被统计为失败任务。如果该域没有声明，那任务就没有最后期限。
• .spec.suspend域也是可选的。如果设置为 true ，后续发生的执行都会挂起。 这个设置对已经开始的执行不起作用。默认是关闭的。
• .spec.successfulJobsHistoryLimit 和 .spec.failedJobsHistoryLimit是可选的。 这两个字段指定应保留多少已完成和失败的任务。 默认设置为3和1。限制设置为0代表相应类型的任务完成后不会保留。

并发性规则

.spec.concurrencyPolicy声明了 CronJob 创建的任务执行时发生重叠如何处理。 spec 仅能声明下列规则中的一种：

• Allow (默认)：CronJob 允许并发任务执行。
• Forbid： CronJob 不允许并发任务执行；如果新任务的执行时间到了而老任务没有执行完，CronJob 会忽略新任务的执行。
• Replace：如果新任务的执行时间到了而老任务没有执行完，CronJob 会用新任务替换当前正在运行的任务。

并发性规则仅适用于相同 CronJob 创建的任务。如果有多个 CronJob，它们相应的任务总是允许并发执行的。

1. 编写 yaml 文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

vim crontjob.yaml
apiVersion: batch/v1
kind: CronJob
metadata:
  name: cronjob
spec:
  # CronJob必要字段，格式为分时日月周
  schedule: "*/1 * * * *"
  # job模板
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: crontab-pod
            image: busybox
            imagePullPolicy: IfNotPresent
            command:
            - /bin/sh
            - -c
            - date; echo 'Welcome My K8s'
          restartPolicy: OnFailure

2. 生成 CronJob，可以看到每分钟都会创建一个 Job 和 Pod

1

kubectl create -f cronjob.yaml

五、Service

5.1 什么是Service

到这里我们都知道，Deployment 会根据 replicas保证 Pod 的数量，当上图的其中一个 php-fpm Pod 出现问题时，就会新建一个来代替。但这时候会会出现一个问题，新的 Pod 的地址与旧的很可能不一样，那 nginx 也无法连接到新的 Pod，除非修改 nginx 的配置，这样的 k8s 集群效率是非常低的。

Service 就能解决该问题，在 nginx 和 php-fpm 中间添加一个 Service，由该 Service 来管理各 php-fpm Pod 的信息，每个 Pod 会设置一个标签，只要与 SVC 中设置的标签相匹配，就可以进行管理，其它 Pod（例如下图的 nginx）想要访问该 SVC 管理的 Pod，只要通过 SVC 的地址就可以访问到。

Service 定义了这样一种抽象：逻辑上的一组 Pod，一种可以访问它们的策略 —— 通常称为微服务。

5.2 Service发布服务（服务类型)

对一些应用的某些部分（如前端），可能希望将其暴露给 Kubernetes 集群外部 的 IP 地址。

Kubernetes ServiceTypes 允许指定你所需要的 Service 类型，默认是 ClusterIP。

Type 的取值以及行为如下：

• ClusterIP：通过集群的内部 IP 暴露服务，选择该值时服务只能够在集群内部访问。 这也是默认的 ServiceType。
• NodePort：通过每个节点上的 IP 和静态端口（NodePort）暴露服务。 NodePort 服务会路由到自动创建的 ClusterIP 服务。 通过请求 <节点 IP>:<节点端口>，你可以从集群的外部访问一个 NodePort 服务。
• LoadBalancer：使用云提供商的负载均衡器向外部暴露服务。 外部负载均衡器可以将流量路由到自动创建的 NodePort 服务和 ClusterIP 服务上。
• ExternalName：通过返回 CNAME 和对应值，可以将服务映射到 externalName 字段的内容（例如，foo.bar.example.com）。 无需创建任何类型代理。

ClusterIP

NodePort

LoadBalancer

ExternalName

5.3 虚拟 IP 和 Service 代理

在 Kubernetes 集群中，每个 Node 运行一个 kube-proxy 进程。 kube-proxy 负责为 Service 实现了一种 VIP（虚拟 IP）的形式，而不是 ExternalName 的形式。

代理模式分类：

userspace 代理模式

在该模式下，所有操作都要通过 kube-proxy 进行一个代理的操作，kube-proxy 的压力相对会较大。

iptables 代理模式

在该模式下，所有的访问都通过 iptables 来处理，kube-proxy 的压力就会减小很多。

IPVS 代理模式

在该模式下，iptables 换成了 IPVS，通过内核模块来实现负载均衡。

在 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），即打开链接数量最少者优先
• dh：目标地址哈希（Destination Hashing）
• sh：源地址哈希（Source Hashing）
• sed：最短预期延迟（Shortest Expected Delay）
• nq：从不排队（Never Queue）

注意：当 kube-proxy 以 IPVS 代理模式启动时，它将验证 IPVS 内核模块是否可用。 如果未检测到 IPVS 内核模块，则 kube-proxy 将退回到以 iptables 代理模式运行。