发表于 |

背景

最近发现一直使用的机房网络不稳定，时常出现网络无法联通，过一会又可以联通的情况，今天又遇到了，要彻底解决它。

问题

在机房网络规划中，地区 A 和地区 B 是通过 OpenVPN 连接的，也就是说每个地区的网关是一台虚拟机，提供 DHCP 服务。
今天地区 A 的机器又无法连接地区 B 了，我登陆网关尝试从网关 ping 目标主机，发现直接提示 :

1
No buffer space available

根据这个提示，感觉像是某些系统参数配置的小了，于是查了一下，发现跟 arp 有关。什么是 arp ？

相信对网络稍微有些概念的同学都不陌生，这里我直接引用维基百科：

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

另外，当发送主机和目的主机不在同一个局域网中时，即便知道对方的MAC地址，两者也不能直接通信，必须经过路由转发才可以。所以此时，发送主机通过ARP协议获得的将不是目的主机的真实MAC地址，而是一台可以通往局域网外的路由器的MAC地址。于是此后发送主机发往目的主机的所有帧，都将发往该路由器，通过它向外发送。这种情况称为委托ARP或ARP代理（ARP Proxy）。

解决

知道了原因，那么我们来调整参数就好：

1
2
3
4
5
6
gc_thresh1 (since Linux 2.2)
The minimum number of entries to keep in the ARP cache. The garbage collector will not run if there are fewer than this number of entries in the cache. Defaults to 128.
gc_thresh2 (since Linux 2.2)
The soft maximum number of entries to keep in the ARP cache. The garbage collector will allow the number of entries to exceed this for 5 seconds before collection will be performed. Defaults to 512.
gc_thresh3 (since Linux 2.2)
The hard maximum number of entries to keep in the ARP cache. The garbage collector will always run if there are more than this number of entries in the cache. Defaults to 1024.
1
2
3
4
5
6
7
8
9
10
11
12
yiran@test:~$ cat /etc/sysctl.conf |grep -v ^# |grep -v ^$
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq
net.ipv4.neigh.default.gc_thresh1 = 4096
net.ipv4.neigh.default.gc_thresh2 = 8192
net.ipv4.neigh.default.gc_thresh3 = 8192
yiran@test:~$ sudo sysctl -p
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq
net.ipv4.neigh.default.gc_thresh1 = 4096
net.ipv4.neigh.default.gc_thresh2 = 8192
net.ipv4.neigh.default.gc_thresh3 = 8192

发表于 |

准备工作

本文所有节点 OS 均为 CentOS 7.4 。

1.关闭 selinux

所有节点执行：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[root@node211 ~]# cat /etc/selinux/config 

# This file controls the state of SELinux on the system.
# SELINUX= can take one of these three values:
#     enforcing - SELinux security policy is enforced.
#     permissive - SELinux prints warnings instead of enforcing.
#     disabled - No SELinux policy is loaded.
SELINUX=disabled
# SELINUXTYPE= can take one of three two values:
#     targeted - Targeted processes are protected,
#     minimum - Modification of targeted policy. Only selected processes are protected. 
#     mls - Multi Level Security protection.
SELINUXTYPE=targeted 


[root@node211 ~]# getenforce 
Disabled

2. 关于 firewalld

所有节点执行：

1
2
3
4
5
6
7
8
[root@node211 ~]# systemctl disable firewalld
[root@node211 ~]# systemctl stop firewalld
[root@node211 ~]# systemctl status firewalld
[root@node211 ~]# systemctl status firewalld
● firewalld.service - firewalld - dynamic firewall daemon
   Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
   Active: inactive (dead)
     Docs: man:firewalld(1)

3. 安装必要 yum 源：epel-release

所有节点执行：

1
2
3
[root@node211 ~]# yum install epel-release
[root@node211 ~]# ls /etc/yum.repos.d/epel.repo 
/etc/yum.repos.d/epel.repo

4. 关闭节点 swap 空间

所有节点执行：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[root@node211 ~]# cat /etc/fstab 

#
# /etc/fstab
# Created by anaconda on Thu Jun 13 09:45:52 2019
#
# Accessible filesystems, by reference, are maintained under '/dev/disk'
# See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info
#
/dev/mapper/centos-root /                       xfs     defaults        0 0
UUID=c0f0a31a-0c36-42cf-b52a-8f3b027ef948 /boot                   xfs     defaults        0 0
#/dev/mapper/centos-swap swap                    swap    defaults        0 0
[root@node211 ~]# free -h
              total        used        free      shared  buff/cache   available
Mem:           3.7G        102M        3.3G        8.3M        230M        3.3G
Swap:            0B          0B          0B

5. 安装 docker-ce

所有节点执行：

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@node211 ~]# 
[root@node211 ~]# head -n 6 /etc/yum.repos.d/docker-ce.repo
[docker-ce-stable]
name=Docker CE Stable - $basearch
baseurl=https://download.docker.com/linux/centos/7/$basearch/stable
enabled=1
gpgcheck=1
gpgkey=https://download.docker.com/linux/centos/gpg
[root@node211 ~]# rpm -q docker
docker-1.13.1-96.gitb2f74b2.el7.centos.x86_64
[root@node211 ~]# systemctl enable docker
[root@node211 ~]# systemctl start docker
[root@node211 ~]# systemctl status docker
● docker.service - Docker Application Container Engine
   Loaded: loaded (/usr/lib/systemd/system/docker.service; enabled; vendor preset: disabled)
   Active: active (running) since Fri 2019-06-14 19:48:40 CST; 3s ago
     Docs: http://docs.docker.com
 Main PID: 11488 (dockerd-current)
   CGroup: /system.slice/docker.service
           ├─11488 /usr/bin/dockerd-current --add-runtime docker-runc=/usr/libexec/docker/docker-runc-current --default-runtime=docker-runc --exec-opt native.cgroupdriver=systemd --userland-proxy-path=/usr/libexec/docker/docker-proxy-current --init-path=/usr...
           └─11495 /usr/bin/docker-containerd-current -l unix:///var/run/docker/libcontainerd/docker-containerd.sock --metrics-interval=0 --start-timeout 2m --state-dir /var/run/docker/libcontainerd/containerd --shim docker-containerd-shim --runtime docker-r...

Jun 14 19:48:40 node211 dockerd-current[11488]: time="2019-06-14T19:48:40.282909889+08:00" level=info msg="Docker daemon" commit="b2f74b2/1.13.1" graphdriver=overlay2 version=1.13.1
Jun 14 19:48:40 node211 dockerd-current[11488]: time="2019-06-14T19:48:40.293315055+08:00" level=info msg="API listen on /var/run/docker.sock"
Jun 14 19:48:40 node211 systemd[1]: Started Docker Application Container Engine.

6. 开启必要系统参数 sysctl

所有节点执行：

1
2
3
[root@node211 ~]# sysctl -p
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1

kubeadm

因为 kubeadm 官方文档中没有详细步骤，因此相关描述尽量具体到命令行。

环境信息

ip role
192.168.77.211 master
192.168.77.212 master
192.168.77.213 master
192.168.77.214 node

1. 安装 kubeadm

所有节点执行：

1
2
3
4
5
6
7
8
9
10
11
12
[root@node211 ~]# cat /etc/yum.repos.d/kubernetes.repo 
[kubernetes]
name=Kubernetes
baseurl=https://packages.cloud.google.com/yum/repos/kubernetes-el7-x86_64
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://packages.cloud.google.com/yum/doc/yum-key.gpg https://packages.cloud.google.com/yum/doc/rpm-package-key.gpg
proxy=socks5://127.0.0.1:1080
[root@node211 ~]# yum install kubeadm kubelet
[root@node211 ~]# which kubeadm 
/usr/bin/kubeadm

2. 安装 keepalived

所有 master 节点执行：

1
2
3
[root@node211 ~]# yum install keepalived
[root@node212 ~]# yum install keepalived 
[root@node213 ~]# yum install keepalived

编辑 node211 配置文件：

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@node211 ~]# cat /etc/keepalived/keepalived.conf 
! Configuration File for keepalived

global_defs {
   notification_email {
        feng110498@163.com
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_1
}

vrrp_instance VI_1 {
    state MASTER          
    interface eth0
    lvs_sync_daemon_inteface eth0
    virtual_router_id 79
    advert_int 1
    priority 100         
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
      192.168.77.219/20
    }
}

编辑 node212 配置文件：

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@node212 ~]# cat /etc/keepalived/keepalived.conf 
! Configuration File for keepalived

global_defs {
   notification_email {
        feng110498@163.com
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_1
}

vrrp_instance VI_1 {
    state MASTER          
    interface eth0
    lvs_sync_daemon_inteface eth0
    virtual_router_id 79
    advert_int 1
    priority 90         
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
      192.168.77.219/20
    }
}

编辑 node213 配置文件：

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@node213 ~]# cat /etc/keepalived/keepalived.conf 
! Configuration File for keepalived

global_defs {
   notification_email {
        feng110498@163.com
   }
   notification_email_from Alexandre.Cassen@firewall.loc
   smtp_server 127.0.0.1
   smtp_connect_timeout 30
   router_id LVS_1
}

vrrp_instance VI_1 {
    state MASTER          
    interface eth0
    lvs_sync_daemon_inteface eth0
    virtual_router_id 79
    advert_int 1
    priority 70         
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    virtual_ipaddress {
      192.168.77.219/20
    }
}

node211, node212, node213 重启 keepalived：

1
2
3
[root@node211 ~]# systemctl restart keepalived
[root@node212 ~]# systemctl restart keepalived
[root@node213 ~]# systemctl restart keepalived

因为 node211 优先级最高，此时 VIP 192.168.77.219 应该在 node211 节点，查看 node211 节点 IP：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
[root@node211 ~]# ip ad 
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 52:54:00:42:fd:a6 brd ff:ff:ff:ff:ff:ff
    inet 192.168.77.211/20 brd 192.168.79.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 192.168.77.219/20 scope global secondary eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::5554:b212:7895:c8ad/64 scope link tentative dadfailed 
       valid_lft forever preferred_lft forever
    inet6 fe80::3e97:25b9:cc1a:809c/64 scope link tentative dadfailed 
       valid_lft forever preferred_lft forever
    inet6 fe80::7a4f:3726:af17:18bf/64 scope link tentative dadfailed 
       valid_lft forever preferred_lft forever
3: docker0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN 
    link/ether 02:42:6f:0e:81:59 brd ff:ff:ff:ff:ff:ff
    inet 172.17.0.1/16 scope global docker0
       valid_lft forever preferred_lft forever

配置无异常，node211,node212,node213 设置开机自启动：

1
2
3
4
5
6
[root@node211 ~]# systemctl enable keepalived
Created symlink from /etc/systemd/system/multi-user.target.wants/keepalived.service to /usr/lib/systemd/system/keepalived.service.
[root@node212 ~]# systemctl enable keepalived
Created symlink from /etc/systemd/system/multi-user.target.wants/keepalived.service to /usr/lib/systemd/system/keepalived.service.
[root@node213 ~]# systemctl enable keepalived
Created symlink from /etc/systemd/system/multi-user.target.wants/keepalived.service to /usr/lib/systemd/system/keepalived.service.

3. 安装 haproxy

所有 master 节点执行：

1
2
3
[root@node211 ~]# yum install haproxy
[root@node212 ~]# yum install haproxy
[root@node213 ~]# yum install haproxy

编辑所有 master 节点配置文件：

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@node211 ~]# cat /etc/haproxy/haproxy.cfg 
global
        chroot  /var/lib/haproxy
        daemon
        group haproxy
        user haproxy
        log 127.0.0.1:514 local0 warning
        pidfile /var/lib/haproxy.pid
        maxconn 20000
        spread-checks 3
        nbproc 8

defaults
        log     global
        mode    tcp
        retries 3
        option redispatch

listen https-apiserver
        bind *:8443
        mode tcp
        balance roundrobin
        timeout server 900s
        timeout connect 15s

        server m1 192.168.77.211:6443 check port 6443 inter 5000 fall 5
        server m2 192.168.77.212:6443 check port 6443 inter 5000 fall 5
        server m3 192.168.77.213:6443 check port 6443 inter 5000 fall 5

所有 master 节点启动 haproxy，并设置 开机自启动：

1
2
3
4
5
6
7
8
9
[root@node211 ~]# systemctl start haproxy 
[root@node211 ~]# systemctl enable haproxy
Created symlink from /etc/systemd/system/multi-user.target.wants/haproxy.service to /usr/lib/systemd/system/haproxy.service.
[root@node212 ~]# systemctl start haproxy 
[root@node212 ~]# systemctl enable haproxy
Created symlink from /etc/systemd/system/multi-user.target.wants/haproxy.service to /usr/lib/systemd/system/haproxy.service.
[root@node213 ~]# systemctl start haproxy 
[root@node213 ~]# systemctl enable haproxy
Created symlink from /etc/systemd/system/multi-user.target.wants/haproxy.service to /usr/lib/systemd/system/haproxy.service.

4. 编写 kubeadm 配置文件

在 node211 节点编写 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
[root@node211 ~]# cat kubeadm-init.yaml
apiVersion: kubeadm.k8s.io/v1beta1
kind: ClusterConfiguration
apiServer:
  timeoutForControlPlane: 4m0s
certificatesDir: /etc/kubernetes/pki
clusterName: kubernetes
controlPlaneEndpoint: "192.168.77.219:8443"
dns:
  type: CoreDNS
etcd:
  local:
    dataDir: /var/lib/etcd
imageRepository: registry.cn-hangzhou.aliyuncs.com/google_containers
kubernetesVersion: v1.14.3
networking:
  dnsDomain: cluster.local
  podSubnet: "10.123.0.0/16"
scheduler: {}
controllerManager: {}
---
apiVersion: kubeproxy.config.k8s.io/v1alpha1
kind: KubeProxyConfiguration
mode: "ipvs"

5. 初始化

在 node211 节点执行初始化操作：

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
[root@node211 ~]# kubeadm init --config=kubeadm-init.yaml --experimental-upload-certs
[init] Using Kubernetes version: v1.14.3
[preflight] Running pre-flight checks
	[WARNING Hostname]: hostname "node211" could not be reached
	[WARNING Hostname]: hostname "node211": lookup node211 on 192.168.64.215:53: no such host
	[WARNING Service-Kubelet]: kubelet service is not enabled, please run 'systemctl enable kubelet.service'
	[WARNING RequiredIPVSKernelModulesAvailable]: 

The IPVS proxier may not be used because the following required kernel modules are not loaded: [ip_vs_rr ip_vs_wrr ip_vs_sh]
or no builtin kernel IPVS support was found: map[ip_vs:{} ip_vs_rr:{} ip_vs_sh:{} ip_vs_wrr:{} nf_conntrack_ipv4:{}].
However, these modules may be loaded automatically by kube-proxy if they are available on your system.
To verify IPVS support:

   Run "lsmod | grep 'ip_vs|nf_conntrack'" and verify each of the above modules are listed.

If they are not listed, you can use the following methods to load them:

1. For each missing module run 'modprobe $modulename' (e.g., 'modprobe ip_vs', 'modprobe ip_vs_rr', ...)
2. If 'modprobe $modulename' returns an error, you will need to install the missing module support for your kernel.

[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
[kubelet-start] Writing kubelet environment file with flags to file "/var/lib/kubelet/kubeadm-flags.env"
[kubelet-start] Writing kubelet configuration to file "/var/lib/kubelet/config.yaml"
[kubelet-start] Activating the kubelet service
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [node211 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.77.211 192.168.77.219]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-ca" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/ca" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [node211 localhost] and IPs [192.168.77.211 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [node211 localhost] and IPs [192.168.77.211 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "sa" key and public key
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[kubeconfig] Writing "admin.conf" kubeconfig file
[endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[kubeconfig] Writing "kubelet.conf" kubeconfig file
[endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[etcd] Creating static Pod manifest for local etcd in "/etc/kubernetes/manifests"
[wait-control-plane] Waiting for the kubelet to boot up the control plane as static Pods from directory "/etc/kubernetes/manifests". This can take up to 4m0s
[kubelet-check] Initial timeout of 40s passed.
[apiclient] All control plane components are healthy after 107.014141 seconds
[upload-config] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[kubelet] Creating a ConfigMap "kubelet-config-1.14" in namespace kube-system with the configuration for the kubelets in the cluster
[upload-certs] Storing the certificates in ConfigMap "kubeadm-certs" in the "kube-system" Namespace
[upload-certs] Using certificate key:
1436c652cc6bb7e91386b4f744e3376df7b3b6ffd5e9a1a2930f9b6241daac4a
[mark-control-plane] Marking the node node211 as control-plane by adding the label "node-role.kubernetes.io/master=''"
[mark-control-plane] Marking the node node211 as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]
[bootstrap-token] Using token: ptuvy5.hl4rzxugpxpgkgkh
[bootstrap-token] Configuring bootstrap tokens, cluster-info ConfigMap, RBAC Roles
[bootstrap-token] configured RBAC rules to allow Node Bootstrap tokens to post CSRs in order for nodes to get long term certificate credentials
[bootstrap-token] configured RBAC rules to allow the csrapprover controller automatically approve CSRs from a Node Bootstrap Token
[bootstrap-token] configured RBAC rules to allow certificate rotation for all node client certificates in the cluster
[bootstrap-token] creating the "cluster-info" ConfigMap in the "kube-public" namespace
[addons] Applied essential addon: CoreDNS
[endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[addons] Applied essential addon: kube-proxy

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, 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

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.77.219:8443 --token ptuvy5.hl4rzxugpxpgkgkh \
    --discovery-token-ca-cert-hash sha256:2a190612b1e3a68a549d02b42335bfba4dd4af3bb1361124ad46862e1ab418d4 \
    --experimental-control-plane --certificate-key 1436c652cc6bb7e91386b4f744e3376df7b3b6ffd5e9a1a2930f9b6241daac4a

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 --experimental-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.77.219:8443 --token ptuvy5.hl4rzxugpxpgkgkh \
    --discovery-token-ca-cert-hash sha256:2a190612b1e3a68a549d02b42335bfba4dd4af3bb1361124ad46862e1ab418d4

按照说明，拷贝 kubectl 配置文件并验证：

1
2
3
4
5
6
[root@node211 ~]# mkdir -p $HOME/.kube
[root@node211 ~]# sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
[root@node211 ~]# sudo chown $(id -u):$(id -g) $HOME/.kube/config
[root@node211 ~]# kubectl get node
NAME      STATUS     ROLES    AGE   VERSION
node211   NotReady   master   82s   v1.14.3

6. 部署 flannel 网络插件

在 node211 节点部署 flannel 插件：

1
2
3
4
5
6
7
8
9
10
[root@node211 ~]# kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/a70459be0084506e4ec919aa1c114638878db11b/Documentation/kube-flannel.yml
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.extensions/kube-flannel-ds-amd64 created
daemonset.extensions/kube-flannel-ds-arm64 created
daemonset.extensions/kube-flannel-ds-arm created
daemonset.extensions/kube-flannel-ds-ppc64le created
daemonset.extensions/kube-flannel-ds-s390x created

查看部署状态：

1
2
3
4
5
6
7
8
9
10
[root@node211 ~]# kubectl get pod -n kube-system
NAME                              READY   STATUS    RESTARTS   AGE
coredns-d5947d4b-rn2wl            0/1     Pending   0          3m17s
coredns-d5947d4b-zdptx            0/1     Pending   0          3m17s
etcd-node211                      1/1     Running   0          2m48s
kube-apiserver-node211            1/1     Running   0          2m28s
kube-controller-manager-node211   1/1     Running   0          2m59s
kube-flannel-ds-amd64-vzk7c       1/1     Running   0          36s
kube-proxy-w5gsg                  1/1     Running   0          3m16s
kube-scheduler-node211            1/1     Running   0          2m41s

7. 添加其他 master 节点

按照 node211 初始化提示，在 node212 节点及 node213 节点添加到集群，角色为 master：

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
[root@node212 ~]# kubeadm join 192.168.77.219:8443 --token ptuvy5.hl4rzxugpxpgkgkh \
>     --discovery-token-ca-cert-hash sha256:2a190612b1e3a68a549d02b42335bfba4dd4af3bb1361124ad46862e1ab418d4 \
>     --experimental-control-plane --certificate-key 1436c652cc6bb7e91386b4f744e3376df7b3b6ffd5e9a1a2930f9b6241daac4a
[preflight] Running pre-flight checks
	[WARNING Hostname]: hostname "node212" could not be reached
	[WARNING Hostname]: hostname "node212": lookup node212 on 192.168.64.215:53: no such host
	[WARNING Service-Kubelet]: kubelet service is not enabled, please run 'systemctl enable kubelet.service'
[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'
	[WARNING RequiredIPVSKernelModulesAvailable]: 

The IPVS proxier may not be used because the following required kernel modules are not loaded: [ip_vs_sh ip_vs_rr ip_vs_wrr]
or no builtin kernel IPVS support was found: map[ip_vs:{} ip_vs_rr:{} ip_vs_sh:{} ip_vs_wrr:{} nf_conntrack_ipv4:{}].
However, these modules may be loaded automatically by kube-proxy if they are available on your system.
To verify IPVS support:

   Run "lsmod | grep 'ip_vs|nf_conntrack'" and verify each of the above modules are listed.

If they are not listed, you can use the following methods to load them:

1. For each missing module run 'modprobe $modulename' (e.g., 'modprobe ip_vs', 'modprobe ip_vs_rr', ...)
2. If 'modprobe $modulename' returns an error, you will need to install the missing module support for your kernel.

[preflight] Running pre-flight checks before initializing the new control plane instance
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
[download-certs] Downloading the certificates in Secret "kubeadm-certs" in the "kube-system" Namespace
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [node212 localhost] and IPs [192.168.77.212 127.0.0.1 ::1]
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [node212 localhost] and IPs [192.168.77.212 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [node212 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.77.212 192.168.77.219]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Generating "front-proxy-client" certificate and key
[certs] Valid certificates and keys now exist in "/etc/kubernetes/pki"
[certs] Using the existing "sa" key
[kubeconfig] Generating kubeconfig files
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[check-etcd] Checking that the etcd cluster is healthy
[kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.14" 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...
[etcd] Announced new etcd member joining to the existing etcd cluster
[etcd] Wrote Static Pod manifest for a local etcd member to "/etc/kubernetes/manifests/etcd.yaml"
[etcd] Waiting for the new etcd member to join the cluster. This can take up to 40s
[upload-config] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[mark-control-plane] Marking the node node212 as control-plane by adding the label "node-role.kubernetes.io/master=''"
[mark-control-plane] Marking the node node212 as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]

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.

按照说明，拷贝 kubectl 配置文件并验证：

1
2
3
4
5
6
7
[root@node212 ~]# mkdir -p $HOME/.kube
[root@node212 ~]# sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
[root@node212 ~]# sudo chown $(id -u):$(id -g) $HOME/.kube/config
[root@node212 ~]# kubectl get node
NAME      STATUS   ROLES    AGE     VERSION
node211   Ready    master   7m48s   v1.14.3
node212   Ready    master   66s     v1.14.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
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
[root@node213 ~]# kubeadm join 192.168.77.219:8443 --token ptuvy5.hl4rzxugpxpgkgkh \
>     --discovery-token-ca-cert-hash sha256:2a190612b1e3a68a549d02b42335bfba4dd4af3bb1361124ad46862e1ab418d4 \
>     --experimental-control-plane --certificate-key 1436c652cc6bb7e91386b4f744e3376df7b3b6ffd5e9a1a2930f9b6241daac4a
[preflight] Running pre-flight checks
	[WARNING Hostname]: hostname "node213" could not be reached
	[WARNING Hostname]: hostname "node213": lookup node213 on 192.168.64.215:53: no such host
	[WARNING Service-Kubelet]: kubelet service is not enabled, please run 'systemctl enable kubelet.service'
[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'
	[WARNING RequiredIPVSKernelModulesAvailable]: 

The IPVS proxier may not be used because the following required kernel modules are not loaded: [ip_vs_wrr ip_vs_sh ip_vs_rr]
or no builtin kernel IPVS support was found: map[ip_vs:{} ip_vs_rr:{} ip_vs_sh:{} ip_vs_wrr:{} nf_conntrack_ipv4:{}].
However, these modules may be loaded automatically by kube-proxy if they are available on your system.
To verify IPVS support:

   Run "lsmod | grep 'ip_vs|nf_conntrack'" and verify each of the above modules are listed.

If they are not listed, you can use the following methods to load them:

1. For each missing module run 'modprobe $modulename' (e.g., 'modprobe ip_vs', 'modprobe ip_vs_rr', ...)
2. If 'modprobe $modulename' returns an error, you will need to install the missing module support for your kernel.

[preflight] Running pre-flight checks before initializing the new control plane instance
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action in beforehand using 'kubeadm config images pull'
[download-certs] Downloading the certificates in Secret "kubeadm-certs" in the "kube-system" Namespace
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "front-proxy-client" certificate and key
[certs] Generating "etcd/server" certificate and key
[certs] etcd/server serving cert is signed for DNS names [node213 localhost] and IPs [192.168.77.213 127.0.0.1 ::1]
[certs] Generating "etcd/peer" certificate and key
[certs] etcd/peer serving cert is signed for DNS names [node213 localhost] and IPs [192.168.77.213 127.0.0.1 ::1]
[certs] Generating "etcd/healthcheck-client" certificate and key
[certs] Generating "apiserver-etcd-client" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [node213 kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local] and IPs [10.96.0.1 192.168.77.213 192.168.77.219]
[certs] Generating "apiserver-kubelet-client" certificate and key
[certs] Valid certificates and keys now exist in "/etc/kubernetes/pki"
[certs] Using the existing "sa" key
[kubeconfig] Generating kubeconfig files
[kubeconfig] Using kubeconfig folder "/etc/kubernetes"
[endpoint] WARNING: port specified in controlPlaneEndpoint overrides bindPort in the controlplane address
[kubeconfig] Writing "admin.conf" kubeconfig file
[kubeconfig] Writing "controller-manager.conf" kubeconfig file
[kubeconfig] Writing "scheduler.conf" kubeconfig file
[control-plane] Using manifest folder "/etc/kubernetes/manifests"
[control-plane] Creating static Pod manifest for "kube-apiserver"
[control-plane] Creating static Pod manifest for "kube-controller-manager"
[control-plane] Creating static Pod manifest for "kube-scheduler"
[check-etcd] Checking that the etcd cluster is healthy
[kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.14" 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...
[etcd] Announced new etcd member joining to the existing etcd cluster
[etcd] Wrote Static Pod manifest for a local etcd member to "/etc/kubernetes/manifests/etcd.yaml"
[etcd] Waiting for the new etcd member to join the cluster. This can take up to 40s
[upload-config] storing the configuration used in ConfigMap "kubeadm-config" in the "kube-system" Namespace
[mark-control-plane] Marking the node node213 as control-plane by adding the label "node-role.kubernetes.io/master=''"
[mark-control-plane] Marking the node node213 as control-plane by adding the taints [node-role.kubernetes.io/master:NoSchedule]

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.

按照说明，拷贝 kubectl 配置文件并验证：

1
2
3
4
5
6
7
8
[root@node213 ~]# mkdir -p $HOME/.kube
[root@node213 ~]# sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
[root@node213 ~]# sudo chown $(id -u):$(id -g) $HOME/.kube/config
[root@node213 ~]# kubectl get node
NAME      STATUS   ROLES    AGE     VERSION
node211   Ready    master   11m     v1.14.3
node212   Ready    master   4m39s   v1.14.3
node213   Ready    master   72s     v1.14.3

8. 添加其他 node 节点

按照 node211 初始化提示，添加 node214 节点到集群，角色为 node：

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
[root@node214 ~]# kubeadm join 192.168.77.219:8443 --token ptuvy5.hl4rzxugpxpgkgkh \
>     --discovery-token-ca-cert-hash sha256:2a190612b1e3a68a549d02b42335bfba4dd4af3bb1361124ad46862e1ab418d4 
[preflight] Running pre-flight checks
	[WARNING Hostname]: hostname "node214" could not be reached
	[WARNING Hostname]: hostname "node214": lookup node214 on 192.168.64.215:53: no such host
	[WARNING Service-Kubelet]: kubelet service is not enabled, please run 'systemctl enable kubelet.service'
[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'
	[WARNING RequiredIPVSKernelModulesAvailable]: 

The IPVS proxier may not be used because the following required kernel modules are not loaded: [ip_vs_wrr ip_vs_sh ip_vs_rr]
or no builtin kernel IPVS support was found: map[ip_vs:{} ip_vs_rr:{} ip_vs_sh:{} ip_vs_wrr:{} nf_conntrack_ipv4:{}].
However, these modules may be loaded automatically by kube-proxy if they are available on your system.
To verify IPVS support:

   Run "lsmod | grep 'ip_vs|nf_conntrack'" and verify each of the above modules are listed.

If they are not listed, you can use the following methods to load them:

1. For each missing module run 'modprobe $modulename' (e.g., 'modprobe ip_vs', 'modprobe ip_vs_rr', ...)
2. If 'modprobe $modulename' returns an error, you will need to install the missing module support for your kernel.

[kubelet-start] Downloading configuration for the kubelet from the "kubelet-config-1.14" 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.

至此 kubeadm 配合 keepalived & haproxy 搭建高可用集群就完成了。

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
[root@node211 ~]# kubectl get node
NAME      STATUS   ROLES    AGE     VERSION
node211   Ready    master   4h10m   v1.14.3
node212   Ready    master   4h3m    v1.14.3
node213   Ready    master   4h      v1.14.3
node214   Ready    <none>   3h57m   v1.14.3
[root@node211 ~]# kubectl get pod -n kube-system
NAME                              READY   STATUS    RESTARTS   AGE
coredns-d5947d4b-rn2wl            1/1     Running   0          4h10m
coredns-d5947d4b-zdptx            1/1     Running   0          4h10m
etcd-node211                      1/1     Running   0          4h9m
etcd-node212                      1/1     Running   0          4h3m
etcd-node213                      1/1     Running   0          4h
kube-apiserver-node211            1/1     Running   0          4h9m
kube-apiserver-node212            1/1     Running   1          4h3m
kube-apiserver-node213            1/1     Running   0          3h59m
kube-controller-manager-node211   1/1     Running   1          4h9m
kube-controller-manager-node212   1/1     Running   0          4h2m
kube-controller-manager-node213   1/1     Running   0          3h59m
kube-flannel-ds-amd64-gchpj       1/1     Running   0          4h
kube-flannel-ds-amd64-mx44p       1/1     Running   0          3h57m
kube-flannel-ds-amd64-vzk7c       1/1     Running   0          4h7m
kube-flannel-ds-amd64-x9rm7       1/1     Running   0          4h3m
kube-proxy-fj448                  1/1     Running   0          4h
kube-proxy-jmhm7                  1/1     Running   0          4h3m
kube-proxy-s7jdf                  1/1     Running   0          3h57m
kube-proxy-w5gsg                  1/1     Running   0          4h10m
kube-scheduler-node211            1/1     Running   1          4h9m
kube-scheduler-node212            1/1     Running   0          4h2m
kube-scheduler-node213            1/1     Running   0          3h59m

HA 机制

由集群节点上运行的 keepalived & haproxy 提供 VIP & LB，集群中所有节点的 kubelet 连接至 VIP: EndPoints。

当 VIP 所在节点发生故障，VIP 切换到集群中其他 master 节点，即可正常提供服务。

坑

  1. kubeadm 需要正常网络支持，需要确保自己处于正常网络环境下；
  2. kubeadm 在添加节点时，有可能会 hang 住，未查明原因；
  3. kubeadm 默认生成证书有效期为 1年，若想要修改，则需要手动生成证书替换；
  4. …

kubespray

因为 kubespray 项目主要使用 ansible 配合 kubeadm 部署，具体内容可以直接查看 github 文档，因此不详细记录具体步骤。

环境信息

ip role
192.168.77.201 master
192.168.77.202 master
192.168.77.203 master
192.168.77.204 node

1. 安装 kubespray

在 GitHub 项目链接上下载最新 Release 版本代码。

1
[root@node201 ~]# wget https://github.com/kubernetes-sigs/kubespray/archive/v2.10.3.tar.gz

2. 安装必要依赖

项目依赖于 Python3，所以这里采用 Python3.6 版本进行安装。

1
2
3
[root@node201 kubespray-2.10.3]# yum install python36
[root@node201 kubespray-2.10.3]# yum install python36-pip
[root@node201 kubespray-2.10.3]# pip3 install -r requirements.txt
  1. 生成 ansible inventory

项目默认提供了一个 Python 脚本用于自动生成 inventory，该脚本生成 inventory 通常需要根据实际情况自己调整。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
[root@node201 kubespray-2.10.3]# cp -rfp inventory/sample inventory/mycluster
[root@node201 kubespray-2.10.3]# declare -a IPS=(192.168.77.201 192.168.77.202 192.168.77.203 192.168.77.203)
[root@node201 kubespray-2.10.3]# CONFIG_FILE=inventory/mycluster/hosts.yml python3 contrib/inventory_builder/inventory.py ${IPS[@]}
DEBUG: Adding group all
DEBUG: Adding group kube-master
DEBUG: Adding group kube-node
DEBUG: Adding group etcd
DEBUG: Adding group k8s-cluster
DEBUG: Adding group calico-rr
DEBUG: Skipping existing host 192.168.77.203.
DEBUG: adding host node1 to group all
DEBUG: adding host node2 to group all
DEBUG: adding host node3 to group all
DEBUG: adding host node1 to group etcd
DEBUG: adding host node2 to group etcd
DEBUG: adding host node3 to group etcd
DEBUG: adding host node1 to group kube-master
DEBUG: adding host node2 to group kube-master
DEBUG: adding host node1 to group kube-node
DEBUG: adding host node2 to group kube-node
DEBUG: adding host node3 to group kube-node

查看生成 inventory 结果：

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
[root@node201 kubespray-2.10.3]# cat inventory/mycluster/hosts.yml 
all:
  hosts:
    node1:
      ansible_host: 192.168.77.201
      ip: 192.168.77.201
      access_ip: 192.168.77.201
    node2:
      ansible_host: 192.168.77.202
      ip: 192.168.77.202
      access_ip: 192.168.77.202
    node3:
      ansible_host: 192.168.77.203
      ip: 192.168.77.203
      access_ip: 192.168.77.203
  children:
    kube-master:
      hosts:
        node1:
        node2:
    kube-node:
      hosts:
        node1:
        node2:
        node3:
    etcd:
      hosts:
        node1:
        node2:
        node3:
    k8s-cluster:
      children:
        kube-master:
        kube-node:
    calico-rr:
      hosts: {}

可以看到跟我们计划中的有所差别，根据实际情况调整 kube-master 数量即可。

4. 编写部署配置参数

在 [root@node201 kubespray-2.10.3]# ls inventory/mycluster/group_vars/all/all.yml 路径下包含了一些全局配置，比如 proxy 之类的，可以手动调整。

5. 编写 k8s 配置参数

在 [root@node201 kubespray-2.10.3]# ls inventory/mycluster/group_vars/k8s-cluster/k8s-cluster.yml 路径下包含了 k8s 所有配置项，根据实际情况编辑修改。

6. 部署

在所有准备工作完成后，执行部署操作。

注意， Kubespray 部署的前提条件是你的网络是一个正常的网络，可以正常访问所有网站，若无法访问，则根据自身实际情况，调整配置，配置路径为： roles/download/defaults/main.yml 。

1
ansible-playbook -i inventory/mycluster/hosts.yml --become --become-user=root cluster.yml

等待部署完成即可。

HA 机制

集群中所有的 Node 节点自己启动一个 Nginx Static Pod，用于代理转发，将所有指定 127.0.0.1:6443 的请求转发至所有 master 节点真实 apiserver ，这样所有的 kubelet 只需要自己节点即可，无需其他节点参与。

坑

  1. CentOS 默认 Python2.7，需要单独安装 Python3.6
  2. 通过 pip 安装依赖，部分软件包需要 gcc,python36-devel,openssl-devel 等依赖包，需要根据错误提示自行安装，文档中没有提到
  3. 默认会安装 docker & containerd 服务，但是 containerd 服务未设置开机自启动，会导致 docker 无法自动运行
  4. 在安装过程中，会安装 selinux 相应 Python 库，但是该依赖未在 requirements.txt 声明
  5. …

总结

无论是直接只用 kubeadm + vip 方式部署 HA 集群，还是通过 Kubespray 部署，在网络正常情况下，是很快可以完成的。

在使用 kubeadm 过程中，因为无需引入第三方依赖库，导致整体流程顺畅，体验极佳。

在 Kubespray 过程中，因为采用 Python3 方式，但相关依赖又未显示声明，导致部署过程繁琐。但是也比较好理解，Kubespray 作为一个致力于部署企业级 k8s 集群的项目，需要处理大量的边界条件了，这个项目中 YAML 就写了 15k 行，可见一斑。

发表于 |

磁盘扇区

引用维基百科：

In computer disk storage, a sector is a subdivision of a track on a magnetic disk or optical disc. Each sector stores a fixed amount of user-accessible data, traditionally 512 bytes for hard disk drives (HDDs) and 2048 bytes for CD-ROMs and DVD-ROMs. Newer HDDs use 4096-byte (4 KiB) sectors, which are known as the Advanced Format (AF).

扇区大小常见的可以分为 512 bytes, 2048 bytes 和 4096 bytes。

查看扇区大小

通过 lsblk 命令可以查看。

物理扇区 512 byte：

1
2
3
4
5
6
7
[root@yiran 20:51:59 ~]$lsblk -o NAME,PHY-SEC,LOG-SEC /dev/sdg
NAME      PHY-SEC LOG-SEC
sdg           512     512
├─sdg1        512     512
├─sdg2        512     512
├─sdg3        512     512
└─sdg4        512     512

物理扇区 4096 byte：

1
2
3
4
5
6
7
[root@yiran 20:52:03 ~]$lsblk -o NAME,PHY-SEC,LOG-SEC /dev/sdb
NAME      PHY-SEC LOG-SEC
sdb          4096     512
├─sdb1       4096     512
├─sdb2       4096     512
├─sdb3       4096     512
└─sdb4       4096     512

CDROM 比较特殊，是 2048 byte：

1
2
3
[root@yiran 21:07:35 ~]$lsblk -o NAME,PHY-SEC,LOG-SEC /dev/sr0
NAME PHY-SEC LOG-SEC
sr0     2048    2048

发表于 |

背景

本来计划这周写一下如何定制 UEFI Linux 发行版的，但是计划赶不上变化，加上 UEFI 的改动比想象中的多，这周还是继续 k8s 系列好了。

说起来 k8s 写了 3 篇博客一直没有写集群部署相关的，一是当时对 k8s 了解不多，集群搭建大多是 GitHub 上的开源项目或 Rancher 快速搭建起来的；二是 k8s 官方工具 kubeadm 现在还有很多的不确定性，随着 v1.14 版本的发布，可用性大大提高，虽然还不支持 HA，但是要写一下了。

本文并不会介绍具体的部署步骤，望周知。

Kubernetes 主要组件

因为主要说集群部署相关的，因此只列出 Master 和 Node 的主要组件，k8s 内部资源不再罗列：

Master

  • apiserver： 集群中所有其他组件通过 apiserver 进行交互

  • scheduler： 按照 Pod 配置来对 Pod 进行节点调度

  • controller-manager：负责节点管理，资源的具体创建动作， desired state management 具体实行者

  • etcd：用于存储集群中数据的键值存储

Node

  • kubelet：处理 master 及其上运行的 node 之间的所有通信。它与容器运行时配合，负责部署和监控容器

  • kube-proxy：负责维护 node 的网络规则，还负责处理 Pod,Node和外部之间的通信

  • 容器运行时：在节点上运行容器的具体实现，常见的有 Docker/rkt/CRI-O

Kubernetes 集群准备

所需资源

大部分的安装文档中，都会先写明 os 要求，计算 & 存储资源需求，k8s 自身对资源消耗很低，通常的 2c4g + 30GiB 足够运行起来。

上面说完了硬件资源，那么我们来说下软件资源， k8s 作为一个容器编排系统，它需要的软件资源也是很重要的一部分，这里我们来说一下网络部分。

假设我们集群中存在 5 个节点，使用 kubeadm init 方式部署集群，那么最基本的，需要 5 个节点的 IP。那如果是高可用的集群呢？我们需要加一个 VIP，也就是 6 个 IP 地址。

在考虑了 IP 地址之后，我们来说下网段划分，以 flannel 为例，在创建网络时，每个 k8s 节点都会分配一段子网用于 Pod 分配 IP，这里的网段是不可以跟宿主机的网络重叠的，所以这里的网络划分也是一个很重要的资源。

具体其他网络类型，我会在之后的网络部分详细的写一下。

部署方式

好了，现在我们已经有了资源了（无论是硬件资源还是软件资源），那么我们可以部署了，那此时采用什么方式部署，或者说怎么部署成了问题。

首先说下最特殊的服务，kubelet，它作为节点的实际管控者，它如果运行在容器中，那么谁来控制kubelet 容器的启停呢？当节点故障恢复后，又如何自启动呢？最开始我使用 Rancher 部署的时候发现他们是将 kubelet 直接部署在容器中的，那是因为他们在节点上还有其他 Agent 用于管理节点，Rancher 相当于 k8s 集群之外的上帝，管控着一切。

当我们没有 Rancher 这类管理工具时，还是老老实实将 kubelet 以服务的形式部署在宿主机上吧。

官方推荐使用 kubeadm 进行集群部署，简单快捷，只是还在快速迭代中，存在较多不确定性，那么现在那些大厂是如何部署的呢？

我花了点时间阅读了下 Github 上面一些关于 k8s 部署项目，简单的罗列一下：

项目名称 项目地址 星 服务运行方式 ha
ansible-kubeadm https://github.com/4admin2root/ansible-kubeadm 3 Static Pod -
ansible-kubeadm-ha-cluster https://github.com/sv01a/ansible-kubeadm-ha-cluster 5 Docker keepvalied
kubeadm-playbook https://github.com/ReSearchITEng/kubeadm-playbook 117 Static Pod keepalived
Kubernetes-ansible https://github.com/zhangguanzhang/Kubernetes-ansible 208 Service keepalived & Haproxy
kubeadm-ansible https://github.com/kairen/kubeadm-ansible 281 Static Pod -
kubeadm-ha https://github.com/cookeem/kubeadm-ha 502 Service keepalived & nginx
kubeasz https://github.com/easzlab/kubeasz 2987 Service keepalived & Haproxy

可以看到虽然有些细微的差别，但是大家做的都围绕着一个目的，就是把上一节提到的 k8s 所有必要组件部署到集群中，我们根据服务运行方式和 HA 方式来说一下。

服务运行方式

根据我上面总结的各个项目，大体分为 3 类，分别是：Host Service、Docker、Static Pod。我们一个一个的过一下。

Host Service

在没有容器的时代，我们要部署一个服务，都是采用 Host Service 方式，我们在宿主机的 OS 上配置一个服务，管理方式可能是 init.d ，也可能是 systemd 。k8s 所有的服务都可以通过 Host Service 方式运行。

优点：

在 systemd 大法加持下，所有服务均可通过 systemd 统一管理，可以配置随着系统进行启停。

缺点：

如果通过 systemd 方式部署，那么服务配置修改、服务升级是一个大麻烦。

Docker

既然我们觉得 Host Service 的方式服务配置修改、升级都比较麻烦，那我们直接通过 Docker 启动就好了，升级直接更新 image 重新启动，一切问题放佛都解决了。

但是考虑一个问题，当集群全部掉电，系统开机后，k8s 如何自启动？以 Docker 作为容器运行时的基础上，Docker 比较让人诟病的一点就是它是一个 Daemon，在这里反而是优点，我们可以设置 Docker 随开机自启动，并将 k8s 所有服务对应镜像设置为 --restart=always，就可以解决这个问题。

优点：

服务配置、升级方便。

缺点：

依赖于 Docker，若更换其他 CRI，无法处理极端情况。

Static Pod

最后我们来说说 Static Pod，这种方式是 kubeadm 目前所采用的方式，也是 k8s 所推荐的方式。

什么是 Static Pod？其实就是字面意义， 静态 Pod，k8s 不去调度的 Pod，而是由 kubelet 直接管理。前面我们在讨论 kubelet 提到，kubelet 是以服务的形式运行在宿主机上的，那么也就是 kubelet 的启停是通过 systemd 控制的，不受 k8s 控制。

Static Pod 由 kubelet 控制，当 kubelet 启动后，会自动拉起 Static Pod，且 Static Pod 不受 k8s 控制，无论是通过 kubectl 进行删除，还是通过 docker 对该 Pod 进行 stop 动作，kubelet 都会保证 Static Pod 正常运行。

这个方式很适合我们来处理 k8s 自身的服务，比如 apiserver/scheduler ，每个 master 节点上通过 Static Pod 配置，当 kubelet 启动后，自动拉起 apiserver/scheduler 等服务，那么 k8s 集群也就自启动了，也就解决了我们上面提到的集群全部掉电的情况。

优点：

跟随 kubelet 启停，完美适配 k8s 升级场景。

缺点：

因为随着 kubelet 启停，所以导致更新 kubelet 配置时需要指定 manifest 文件路径。

HA 配置

k8s 作为一个基础架构服务，它的可用性关乎着我们整个业务的稳定，所以一定要保证不会出现单点故障。

在公有云场景下，由公有云提供 LB 的支持，只要我们部署了多个 master 节点，就不用担心了。

那在裸机场景下怎么办呢？

目前通用解决方案是 VIP 配合 LB（也就是 keepalived & haproxy/nginx）。

keepalived 提供了 VIP。在 k8s 集群部署过程中，所有节点都指定 controlPlaneEndpoint 为 VIP，而 VIP 在集群中的一个 master 节点上。当 VIP 所在节点故障时， VIP 自动漂浮到集群中其他 master 节点上，保证高可用。

haproxy/nginx 作为 LB，当我们 k8s 集群中所有节点都连接一个 apiserver 时，通过 LB 按照既定策略将请求分发到集群中多个 master 节点上，保证性能。

总结

关于 k8s 集群的部署大概就是上述这些内容，具体的操作步骤都可以通过官网或者 github 找到相关资料。目前如果个人学习的话，直接通过 kubeadm 部署就好；如果想要在生产环境中部署，那么需要根据自身业务类型，仔细考虑自己是否需要 HA，如何配置 HA。

发表于 |

背景

大家应该都安装过操作系统，PC 或者服务器上。那么我们在安装操作系统时通常需要进入到 BIOS 或 UEFI 界面去安装。之前维护的一个 ISO 版本只支持 BIOS，最近有了支持 UEFI 安装的需求，今天来了解一下其中的差异，之后尝试编写一个支持 UEFI 的 KickStart 配置。

Legacy BIOS

按照惯例，引用维基百科中（不同语言对于名词解释信息可能是完全不同的，最好直接看英文）的解释：

BIOS (/ˈbaɪɒs/ BY-oss; an acronym for Basic Input/Output System and also known as the System BIOS, ROM BIOS or PC BIOS) is non-volatile firmware used to perform hardware initialization during the booting process (power-on startup), and to provide runtime services for operating systems and programs.[1] The BIOS firmware comes pre-installed on a personal computer’s system board, and it is the first software to run when powered on. The name originates from the Basic Input/Output System used in the CP/M operating system in 1975.[2][3] The BIOS originally proprietary to the IBM PC has been reverse engineered by companies looking to create compatible systems. The interface of that original system serves as a de facto standard.

主要功能有：

  • POST - 在加载操作系统之前， 检测硬件确保没有错误
  • Bootstrap Loader - 寻找引导加载程序，并将控制权转
  • BIOS 驱动程序 - 低级驱动程序，使计算机可以对计算机硬件进行基本操作控制
  • BIOS/CMOS 设置 - 允许配置硬件设置，包括系统设置，如计算机密码，硬件时钟等

BIOS vs CMOS

更改BIOS配置时，设置不会存储在BIOS芯片本身。相反，它们存储在一个特殊的存储芯片上，称为CMOS。

与大多数RAM芯片一样，存储BIOS设置的芯片使用CMOS工艺制造。它包含少量数据，通常为256 个字节。CMOS 芯片上的信息包括计算机上安装的磁盘驱动器类型，系统时钟的当前日期和时间以及计算机的引导顺序。

BIOS是非易失性的：即使计算机没电也会保留其信息，因为即使计算机已关闭，计算机也需要记住其BIOS设置。这就是为什么CMOS有自己的专用电源，即CMOS电池。 通常我们在使用电脑的时候，如果忘记了 BIOS 密码，无法更改 BIOS 设置时， 那么可以通过拔掉 CMOS 电池，再安装即可恢复。

(U)EFI

The Unified Extensible Firmware Interface (UEFI) is a specification that defines a software interface between an operating system and platform firmware. UEFI replaces the Basic Input/Output System (BIOS) firmware interface originally present in all IBM PC-compatible personal computers,[1][2] with most UEFI firmware implementations providing legacy support for BIOS services. UEFI can support remote diagnostics and repair of computers, even with no operating system installed.[3]

Intel 为了解决 BIOS 的一些缺点，提出了 EFI ，后来由于各种历史原因，EFI 转变为了 UEFI，其中的 U 是 Unified 。

那么 BIOS 有啥缺点呢？ 对于服务器级别来说，最大的缺点可能就是不支持 2TiB 以上空间的磁盘引导，关于为什么不支持大家可以自己查阅下 MBR vs GPT 相关资料，这里不详细解释。

那么老大哥提出了 UEFI，除了解决了引导磁盘的容量限制，还有如下优点（这几点看上去就跟普通用户没啥关系）：

  • 独立于CPU的架构
  • 独立于CPU的驱动程序
  • 灵活的pre-OS环境，包括网络功能
  • 模块化设计
  • 向后和向前兼容性

Linux 安装识别

了解了大概的概念，那么我们来实际看看 Linux 分别从 BIOS 启动和 UEFI 启动安装有什么不同吧，接下来示例以 CentOS 为例。

首先我们看下 CentOS ISO 中的目录结构：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
[root@dell-r720xd-1 CentOS-7.4]# tree . -d 1
.
├── EFI # EFI 模式下引导程序路径
│   └── BOOT
│       └── fonts
├── images # 系统启动镜像
│   └── pxeboot
├── isolinux   # 默认引导程序路径，包括引导选项配置，引导背景图片，引导内核镜像等
├── LiveOS    # 临时加载镜像
├── Packages   # ISO 附带所有软件包，以 RPM 形式存放
└── repodata    # ISO 中 YUM Repo 配置文件，保存了在只做 YUM Repo 时指定的软件组，支持语言等信息
1 [error opening dir]

9 directories

BIOS

我们来看下在 BIOS 下如何指定安装 KickStart 配置：

在 isolinux/isolinux.cfg 中指定即可

1
2
3
4
5
label linux
  menu label ^Install yiran'OS
  menu default
  kernel vmlinuz
  append initrd=initrd.img inst.stage2=hd:LABEL=YIRANOS-2 ks=hd:LABEL=YIRANOS-2:/ks_yiranos.cfg quiet

UEFI

跟 BIOS 一样，只是换了一个配置位置，只需要在 EFI/BOOT/grub.cfg 中指定 KS 配置即可。

1
2
3
4
5
### BEGIN /etc/grub.d/10_linux ###
menuentry 'Install CentOS 7' --class fedora --class gnu-linux --class gnu --class os {
        linuxefi /images/pxeboot/vmlinuz inst.stage2=hd:LABEL=CentOS\x207\x20x86_64 inst.ks=hd:LABEL=YIRANOS-2:/ks_yiranos.cfg quiet
        initrdefi /images/pxeboot/initrd.img
}

总结

随着越来越多服务器厂商将 UEFI 设置为默认模式，哪怕我们没有用到 UEFI 的高级功能，也最好将自己的 ISO 支持到 UEFI，避免因为 BIOS 的一些历史遗留问题导致后续技术支持出现困难。后续找时间写一下关于 UEFI 的 KickStart 配置文件。主要变化应该是在 /boot 分区部分有些变化，之后再说啦。

发表于 |

镜像组织形式

镜像默认采用 OverlayFS 方式挂载，最终效果是将多个目录结构合并为一个。

其中 lowerdir 为只读路径，最右层级最深。最终容器运行时会将 lowerdir 和 upperdir 合并挂在为 merged，对应容器中的路径为 / 。
举例：
镜像 testadd:0.5 版本的层级挂载如下：

1
2
3
4
5
6
7
[root@node111 16:02:24 overlay2]$docker inspect testadd:0.5 |grep Dir
            "WorkingDir": "",
            "WorkingDir": "",
                "LowerDir": "/var/lib/docker/overlay2/693c140b9c70744a7a6ce93de56d3ac7549dae84195cbfac3486062d1ceaccf1/diff",
                "MergedDir": "/var/lib/docker/overlay2/e2f2ad8332a9567ad28495b28342b5f5712218e235b0129435abfc3c781be957/merged",
                "UpperDir": "/var/lib/docker/overlay2/e2f2ad8332a9567ad28495b28342b5f5712218e235b0129435abfc3c781be957/diff",
                "WorkDir": "/var/lib/docker/overlay2/e2f2ad8332a9567ad28495b28342b5f5712218e235b0129435abfc3c781be957/work"

运行该容器后，可以看到多了一个 overlay 方式挂载的路径：

1
2
3
[root@node111 16:05:53 overlay2]$mount |grep overlay
/dev/md127 on /var/lib/docker/overlay2 type ext4 (rw,relatime,data=ordered)
overlay on /var/lib/docker/overlay2/e1378dc042b534fe00ca6f4565e399f30d56c81d434a30a6137cfae6b5355d00/merged type overlay (rw,relatime,lowerdir=/var/lib/docker/overlay2/l/3NA23BH5OMSSXWTHGPRS6YENB7:/var/lib/docker/overlay2/l/QQVS7UVPGRBVHRZOBDPMMO4EQM:/var/lib/docker/overlay2/l/E7HTYBVD5SXSZRLVTETODOIANT,upperdir=/var/lib/docker/overlay2/e1378dc042b534fe00ca6f4565e399f30d56c81d434a30a6137cfae6b5355d00/diff,workdir=/var/lib/docker/overlay2/e1378dc042b534fe00ca6f4565e399f30d56c81d434a30a6137cfae6b5355d00/work)

查看对应关系：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
[root@node111 16:05:53 overlay2]$mount |grep overlay
/dev/md127 on /var/lib/docker/overlay2 type ext4 (rw,relatime,data=ordered)
overlay on /var/lib/docker/overlay2/e1378dc042b534fe00ca6f4565e399f30d56c81d434a30a6137cfae6b5355d00/merged type overlay (rw,relatime,lowerdir=/var/lib/docker/overlay2/l/3NA23BH5OMSSXWTHGPRS6YENB7:/var/lib/docker/overlay2/l/QQVS7UVPGRBVHRZOBDPMMO4EQM:/var/lib/docker/overlay2/l/E7HTYBVD5SXSZRLVTETODOIANT,upperdir=/var/lib/docker/overlay2/e1378dc042b534fe00ca6f4565e399f30d56c81d434a30a6137cfae6b5355d00/diff,workdir=/var/lib/docker/overlay2/e1378dc042b534fe00ca6f4565e399f30d56c81d434a30a6137cfae6b5355d00/work)
[root@node111 16:06:07 overlay2]$docker inspect testadd:0.5 |grep Dir                                                             
            "WorkingDir": "",
            "WorkingDir": "",
                "LowerDir": "/var/lib/docker/overlay2/693c140b9c70744a7a6ce93de56d3ac7549dae84195cbfac3486062d1ceaccf1/diff",
                "MergedDir": "/var/lib/docker/overlay2/e2f2ad8332a9567ad28495b28342b5f5712218e235b0129435abfc3c781be957/merged",
                "UpperDir": "/var/lib/docker/overlay2/e2f2ad8332a9567ad28495b28342b5f5712218e235b0129435abfc3c781be957/diff",
                "WorkDir": "/var/lib/docker/overlay2/e2f2ad8332a9567ad28495b28342b5f5712218e235b0129435abfc3c781be957/work"
[root@node111 16:06:54 overlay2]$docker ps 
CONTAINER ID        IMAGE               COMMAND             CREATED              STATUS              PORTS               NAMES
e53180ddcd03        testadd:0.5         "bash"              About a minute ago   Up About a minute                       compassionate_roentgen
[root@node111 16:07:06 overlay2]$docker inspect e53180ddcd03 |grep Dir
                "LowerDir": "/var/lib/docker/overlay2/e1378dc042b534fe00ca6f4565e399f30d56c81d434a30a6137cfae6b5355d00-init/diff:/var/lib/docker/overlay2/e2f2ad8332a9567ad28495b28342b5f5712218e235b0129435abfc3c781be957/diff:/var/lib/docker/overlay2/693c140b9c70744a7a6ce93de56d3ac7549dae84195cbfac3486062d1ceaccf1/diff",
                "MergedDir": "/var/lib/docker/overlay2/e1378dc042b534fe00ca6f4565e399f30d56c81d434a30a6137cfae6b5355d00/merged",
                "UpperDir": "/var/lib/docker/overlay2/e1378dc042b534fe00ca6f4565e399f30d56c81d434a30a6137cfae6b5355d00/diff",
                "WorkDir": "/var/lib/docker/overlay2/e1378dc042b534fe00ca6f4565e399f30d56c81d434a30a6137cfae6b5355d00/work"
            "WorkingDir": "",

查看容器内根分区，并在容器内创建文件，查看容器挂载 merged 路径下文件

1
2
3
4
5
[root@e53180ddcd03 /]# ls 
anaconda-post.log  bin  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  test  tmp  usr  var
[root@e53180ddcd03 /]# touch yiran
[root@e53180ddcd03 /]# ls anaconda-post.log  bin  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  test  tmp  usr  var  yiran
[root@e53180ddcd03 /]#
1
2
3
4
5
6
[root@node111 16:07:13 overlay2]$cd e1378dc042b534fe00ca6f4565e399f30d56c81d434a30a6137cfae6b5355d00/merged/
You have mail in /var/spool/mail/root
[root@node111 16:09:31 merged]$ls 
anaconda-post.log  bin  dev  etc  home  lib  lib64  media  mnt  opt  proc  root  run  sbin  srv  sys  test  tmp  usr  var  yiran
[root@node111 16:09:32 merged]$pwd
/var/lib/docker/overlay2/e1378dc042b534fe00ca6f4565e399f30d56c81d434a30a6137cfae6b5355d00/merged

在容器中创建的文件 yiran 在宿主机相应的挂载路径下是可以看到的。

镜像管理

下载

默认从 docker.io 获取最新镜像，可以在 /etc/docker/daemon.json 中指定 registry-mirrors 或 insecure-registries 获取私有镜像。

下载完成后可以看到镜像下载完成后会在 /var/lib/docker/overlay2/ 下保存一份镜像真实内容。

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@node111 16:17:15 docker]$docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
[root@node111 16:17:19 docker]$du -sh . 
624K    .
[root@node111 16:17:21 docker]$docker pull centos
Using default tag: latest
Trying to pull repository docker.io/library/centos ... 
latest: Pulling from docker.io/library/centos
8ba884070f61: Pull complete 
Digest: sha256:b5e66c4651870a1ad435cd75922fe2cb943c9e973a9673822d1414824a1d0475
Status: Downloaded newer image for docker.io/centos:latest
[root@node111 16:18:06 docker]$docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
docker.io/centos    latest              9f38484d220f        2 months ago        202 MB
[root@node111 16:18:17 docker]$du -sh . 
214M    .
[root@node111 16:18:19 docker]$ll overlay2/*
overlay2/6061bd16e5de86e56298bee1496e02998e6a029c34374b21bc0fa3c30202db55:
total 8
drwxr-xr-x 16 root root 4096 May 22 16:18 diff
-rw-r--r--  1 root root   26 May 22 16:17 link

overlay2/l:
total 4
lrwxrwxrwx 1 root root 72 May 22 16:17 A3LUDFNM6LHHPQ6DVXCEI2KFYQ -> ../6061bd16e5de86e56298bee1496e02998e6a029c34374b21bc0fa3c30202db55/diff

构建

在不同服务构建镜像时，应保证最小化且合理分层，这样可以在最底层使用相同的 overlay 缓存，比较空间浪费。
参考 OpenStack Kolla 项目层级结构，openstack 所有服务镜像均基于 CentOS，60+服务镜像打包占用总空间为 5.48G：

注意：
尽量使用最精简基础镜像，只安装必要软件包
合理拆分服务
尽量保证 Dockerfile 中上层指令相同，若顺序不同则会构建出不同的层级，无法利用缓存特性
保证层级处于最精简状态
…

上传

当我们本地存在一份镜像，想要将其上传至指定仓库，我们需要先对镜像打 tag，举例：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
[root@node111 16:24:55 image]$docker images
REPOSITORY          TAG                 IMAGE ID            CREATED             SIZE
testadd             0.2                 4e47f016385b        35 seconds ago      202 MB
docker.io/centos    latest              9f38484d220f        2 months ago        202 MB
[root@node111 16:25:07 image]$cat /etc/docker/daemon.json 
{
  "insecure-registries": [
    "192.168.27.146"
  ]
}
[root@node111 16:25:12 image]$docker tag testadd:0.2 192.168.27.146/testadd:0.2
[root@node111 16:25:28 image]$docker images
REPOSITORY               TAG                 IMAGE ID            CREATED             SIZE
192.168.27.146/testadd   0.2                 4e47f016385b        58 seconds ago      202 MB
testadd                  0.2                 4e47f016385b        58 seconds ago      202 MB
docker.io/centos         latest              9f38484d220f        2 months ago        202 MB
[root@node111 16:25:31 image]$docker push 192.168.27.146/testadd:0.2
The push refers to a repository [192.168.27.146/testadd]
f5011c15a820: Pushed 
d69483a6face: Layer already exists 
0.2: digest: sha256:072611b154402d0760d7860374eb5dc706712319331710b4f046e043ba2cc26a size: 736

上传到指定仓库之后，其他节点可以修改 docker 配置文件，重启 docker 后即可直接下载指定镜像。

Kubernetes 镜像管理

下载

在 k8s 中，没有针对镜像仓库的集群级别配置，节点各自维护自己的仓库地址，如果需要增加仓库地址，需要修改集群中所有节点配置文件，重启 docker 生效。

20190531 更新

针对 k8s 中私有仓库的使用更新：

  1. 当 k8s 想要配置 http 私有仓库时，只能通过在节点上修改 docker 配置文件 /etc/docker/daemon.json ，添加 “insecure-registries” 字段，并重启 docker 后，k8s 可以自动拉取所需镜像；
  2. 当 k8s 配置 https 私有仓库时，只需将根证书拷贝到 k8s 节点的 /etc/docker/certs.d/<domain.com>/ 下，创建 k8s secret docker-registry ，在 YAML 中指定拉取镜像所需的 secret，就可以自动拉取了。

可以在 k8s 中配置指定仓库的 secret 类型为 docker-registry 来配置私有仓库的用户名密码，在之后创建 Pod 时指定该 secret 名称即可自动下载，具体操作如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[root@node3 ~]# kubectl create secret docker-registry regsecret --docker-server=192.168.30.111 --docker-username=admin --docker-password=Harbor12345 --docker-email=yiran@smartx.com
[root@node3 ~]# kubectl get secret regsecret -o yaml
[root@node3 ~]# cat private-reg-pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  name: private-reg
spec:
  nodeSelector:
    type: "233"
  containers:
  - name: private-reg-container
    image: 192.168.30.111/test/busybox:latest
    args: [/bin/sh, -c,
           'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done']
  imagePullSecrets:
  - name: regsecret

删除

k8s 自身不提供主动删除节点中无用镜像操作，默认通过配置 GC 参数删除无用镜像。

不推荐使用其它管理工具或手工进行容器和镜像的清理，因为kubelet需要通过容器来判断pod的运行状态，如果使用其它方式清除容器有可能影响kubelet的正常工作。

  • –image-gc-high-threshold int32
    当用于存储镜像的磁盘使用率达到百分之–image-gc-high-threshold时将触发镜像回收(default 85)

  • –image-gc-low-threshold int32
    删除最近最久未使用（LRU，Least Recently Used）的镜像直到磁盘使用率降为百分之–image-gc-low-threshold或无镜像可删为止 (default 80)

CNCF-Harbor

Harbor项目是一个具有存储、签署和扫描内容功能的开源云原生registry。Harbor 由 VMware 创建，通过添加用户所需功能（如安全性，身份认证和管理）来扩展开源Docker Distribution，并支持在registry之间复制镜像。Harbor还提供高级安全功能，比如漏洞分析，基于角色的访问控制，活动审计等等。
主要功能：

  • 角色控制/身份校验
  • 镜像复制
  • 漏洞扫描
  • …

资源消耗情况：

1
2
3
4
5
6
7
8
9
10
11
[root@node111 11:09:02 harbor]$docker stats --no-stream
CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
90dcf1505eb0        nginx               0.02%               4.152MiB / 15.51GiB   0.03%               6.53MB / 6.77MB     0B / 0B             7
75945a1aa004        harbor-jobservice   0.12%               9.109MiB / 15.51GiB   0.06%               1.24MB / 15.1MB     0B / 0B             13
000f6f349708        harbor-portal       0.07%               1.676MiB / 15.51GiB   0.01%               200kB / 5.47MB      0B / 0B             2
84635df4fe51        harbor-core         0.53%               12.96MiB / 15.51GiB   0.08%               3.62MB / 2.84MB     0B / 0B             14
c6e53b654127        redis               0.18%               6.816MiB / 15.51GiB   0.04%               15.4MB / 1.41MB     0B / 180kB          5
9048a587cf29        registryctl         0.06%               3.031MiB / 15.51GiB   0.02%               114kB / 87.8kB      0B / 0B             7
d88f7c4b36c5        harbor-db           0.03%               8.09MiB / 15.51GiB    0.05%               929kB / 1.57MB      0B / 4.65MB         11
83c474625566        registry            0.20%               19.45MiB / 15.51GiB   0.12%               1.04MB / 335kB      0B / 1.65MB         16
5a3d2707e96f        harbor-log          0.00%               2.152MiB / 15.51GiB   0.01%               766kB / 147kB       81.9kB / 16.4kB     12

默认推荐部署方式：docker-composer
k8s 推荐部署方式：Helm

总结

在日常开发过程中，公司内部部署私有仓库（比如 Harbor）可以控制用户角色，方便测试同学快速获取最新版本镜像。
在融合产品生命周期中，只有升级场景涉及到镜像的导入、上传、下载、删除操作，因此没必要在集群中持续运行一个仓库服务，浪费资源。

参考链接

openstack kolla 项目，目标是通过容器化方式部署 openstack，便于 openstack 滚动升级。

发表于 |

基础日志处理

在 Kubernetes（简称 k8s）中，所有应用在 Pod（k8s 管理容器最小单位）中运行，标准处理方式为将日志打印到标准日志输出和标准错误输出，这样我们可以通过 kuberctl logs 关键字获取容器运行时日志，根据容器运行时的类型不同，日志保存路径也不同，以 Docker 为例，所有真实日志均在 /var/lib/docker/ 路径下，下面我们来看一个例子：

在 k8s 中创建一个 Pod，Pod 中指定打印当前时间到标准输出中：

1
2
3
4
5
6
7
8
9
10
apiVersion: v1
kind: Pod
metadata:
  name: counter
spec:
  containers:
  - name: count
    image: busybox
    args: [/bin/sh, -c,
            'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done']

运行该 Pod，通过 kubectl logs 获取当前 Pod 日志：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[root@node1 blog]# kubectl get pod |grep counter
counter            1/1     Running   0          9s
[root@node1 blog]# kubectl logs counter
0: Fri May 17 00:34:01 UTC 2019
1: Fri May 17 00:34:02 UTC 2019
2: Fri May 17 00:34:03 UTC 2019
3: Fri May 17 00:34:04 UTC 2019
4: Fri May 17 00:34:05 UTC 2019
5: Fri May 17 00:34:06 UTC 2019
6: Fri May 17 00:34:07 UTC 2019
7: Fri May 17 00:34:08 UTC 2019
8: Fri May 17 00:34:09 UTC 2019
9: Fri May 17 00:34:10 UTC 2019
10: Fri May 17 00:34:11 UTC 2019
11: Fri May 17 00:34:12 UTC 2019
12: Fri May 17 00:34:13 UTC 2019

这里如果使用 -f 选项，可以持续输出该 Pod 日志。

那么我们如何找到该容器对应的实际日志文件呢？

我们可以现在 Docker 中找到该容器信息：

1
2
[root@node1 blog]# docker ps |grep count
012e0352b193        busybox                                             "/bin/sh -c 'i=0; wh…"   2 minutes ago       Up 2 minutes                            k8s_count_counter_default_75792a2a-783b-11e9-a3d9-525400aea01a_0

可以看到在 Docker 中该容器名称为 k8s_count_counter_default_75792a2a-783b-11e9-a3d9-525400aea01a_0 ，我们先不去管最后的 UUID 是什么含义，先看前几个字段，跟集群信息关联可以看到，分别是：k8s，容器名称，Pod 名称，namespaces 名称。那么我们来看下这个容器在 Docker 中的配置文件：

1
2
3
4
5
6
[root@node1 containers]# pwd
/var/lib/docker/containers
[root@node1 containers]# ls
012e0352b19387170b903aff7c73c02fcd023c2f53cbe5b908392ff4e1a126e2  
...
5c9e765f68a15d5510870179160c59d45d0287b9f92265687d6c37a3557a1017  c563c36b0d3d28ea611b270bc1609ae9c0e720c1c1f85ba669cdab5f7099b77b

在 Docker 容器路径下，我们看到了很多以不知道什么 ID 明明的子目录，最开始以为是我们 docker ps 中看到的最后 uuid，但是发现对不上，那么我们可以查看下 Pod 的详细信息来试图获取:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
[root@node1 containers]# kubectl describe pod counter
Name:         counter
Namespace:    default
Node:         192.168.27.231/192.168.27.231
Start Time:   Fri, 17 May 2019 08:33:58 +0800
Labels:       <none>
Annotations:  <none>
Status:       Running
IP:           172.20.2.13
Containers:
  count:
    Container ID:  docker://012e0352b19387170b903aff7c73c02fcd023c2f53cbe5b908392ff4e1a126e2
    Image:         busybox
    Image ID:      docker-pullable://busybox@sha256:4b6ad3a68d34da29bf7c8ccb5d355ba8b4babcad1f99798204e7abb43e54ee3d

忽略掉无关信息，我们可以看到 Container ID 字段，这里对应的 ID 就是在 /var/lib/docker/containers/ 下的 ID，找到了 ID，我们可以来看看具体的配置：

1
2
3
4
5
6
7
8
9
[root@node1 012e0352b19387170b903aff7c73c02fcd023c2f53cbe5b908392ff4e1a126e2]# tree .
.
├── 012e0352b19387170b903aff7c73c02fcd023c2f53cbe5b908392ff4e1a126e2-json.log
├── checkpoints
├── config.v2.json
├── hostconfig.json
└── mounts

2 directories, 3 files

可以看到有配置文件和日志文件，我们今天只来讨论日志，那么我们看下这个日志文件的内容：

1
2
3
4
5
6
7
[root@node1 012e0352b19387170b903aff7c73c02fcd023c2f53cbe5b908392ff4e1a126e2]# tail 012e0352b19387170b903aff7c73c02fcd023c2f53cbe5b908392ff4e1a126e2-json.log
{"log":"706: Fri May 17 00:45:48 UTC 2019\n","stream":"stdout","time":"2019-05-17T00:45:48.913451073Z"}
{"log":"707: Fri May 17 00:45:49 UTC 2019\n","stream":"stdout","time":"2019-05-17T00:45:49.915605471Z"}
{"log":"708: Fri May 17 00:45:50 UTC 2019\n","stream":"stdout","time":"2019-05-17T00:45:50.917823388Z"},
{"log":"713: Fri May 17 00:45:55 UTC 2019\n","stream":"stdout","time":"2019-05-17T00:45:55.928645971Z"}
{"log":"714: Fri May 17 00:45:56 UTC 2019\n","stream":"stdout","time":"2019-05-17T00:45:56.930660054Z"}
{"log":"715: Fri May 17 00:45:57 UTC 2019\n","stream":"stdout","time":"2019-05-17T00:45:57.932763561Z"}

可以看到这里日志输出是 JSON 格式的，这里跟 kubectl logs 输出不一致啊，为啥这里是 JSON 呢？ 其实这跟你的 Docker 配置有关，具体的配置可以在 Docker 配置中看到，比如：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[root@node1 docker]# pwd
/etc/docker
[root@node1 docker]# cat daemon.json
{
  "registry-mirrors": [
    "https://dockerhub.azk8s.cn",
    "https://docker.mirrors.ustc.edu.cn",
    "http://hub-mirror.c.163.com"
  ],
  "max-concurrent-downloads": 10,
  "log-driver": "json-file",
  "log-level": "warn",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
    },
  "data-root": "/var/lib/docker"
  }

Docker 默认的日志格式是 JSON，这里我猜测是 k8s 通过 Docker 接口获取日志类型，然后进行相应的解析输出（希望之后对 k8s 更深入的了解来验证猜想）。

在了解了标准日志处理，那么我们来看下节点级别的日志处理是怎样的。

节点级别日志

标准处理

我们现在知道了 Pod 的日志其实是存放在容器真正运行所在节点上的，那么如果 Pod 一直运行，日志会不断增大，占用很多的日志空间，这个在节点上是怎么控制的呢？

因为这种方式不是 k8s 推荐的方式，这里并没有采用集群级别的控制方式，而是以节点为粒度的，各个节点通过 logrotate 自己处理日志轮询，logrotate 相信大部分同学都使用过，这里不详细说了。

特殊处理

如果我们不想将应用日志都输出到标准输出，想将日志打印到 /var/log/ 下的自定义路径下怎么办？我们可以在 Pod 启动时挂载一个 Volume，这个 Volume 就是Pod 所在的节点真实路径，这样我们在容器中就可以直接将日志打印到该路径下，哪怕 Pod 被销毁，日志也会一直存在。

我们创建一个 Deployment 类型的资源，在创建之前，我们需要先创建出指定的挂载路径: /var/log/yiran/，资源配置如下：

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@node1 blog]# cat log.yaml
apiVersion: apps/v1beta1
kind: Deployment
metadata:
  name: counter
spec:
  replicas: 1
  template:
    metadata:
      labels:
        run: helloworldanilhostpath
    spec:
      containers:
      - name: count
        image: busybox
        args: [/bin/sh, -c,
              'i=0; while true; do echo "$i: $(date)" >> /var/log/yiran/test.log; i=$((i+1)); sleep 1; done']
        volumeMounts:
        - name: yiran-test-log
          mountPath: /var/log/yiran
      volumes:
      - name: yiran-test-log
        hostPath:
          path: /var/log/yiran
          type: Directory

创建完成后，我们来查看下该 Pod 的日志：

1
2
3
4
5
[root@node1 blog]# kubectl get pod
NAME                       READY   STATUS    RESTARTS   AGE
counter-76b584fd8f-7fq99   1/1     Running   0          2m30s
testlog-rs-lwxts           1/1     Running   0          2d1h
[root@node1 blog]# kubectl logs counter-76b584fd8f-7fq99

可以看到没有标准日志输出，我们按照上面描述，去看下容器对应的 Docker 日志是否为空：

1
2
3
4
5
6
7
8
9
[root@node2 166103275a89df918b3240ede911192357f7256c1f23b4311b6db44c0f800cc2]# pwd
/var/lib/docker/containers/166103275a89df918b3240ede911192357f7256c1f23b4311b6db44c0f800cc2
[root@node2 166103275a89df918b3240ede911192357f7256c1f23b4311b6db44c0f800cc2]# ll
total 12
-rw-r-----. 1 root root    0 May 18 17:39 166103275a89df918b3240ede911192357f7256c1f23b4311b6db44c0f800cc2-json.log
drwx------. 2 root root    6 May 18 17:39 checkpoints
-rw-------. 1 root root 5173 May 18 17:39 config.v2.json
-rw-r--r--. 1 root root 2064 May 18 17:39 hostconfig.json
drwx------. 2 root root    6 May 18 17:39 mounts

这里是符合预期的，因为我们将所有的日志输出到指定日志： /var/log/yiran/test.log 中了，我们去看看节点日志是否存在：

1
2
3
4
5
6
7
[root@node2 yiran]# pwd
/var/log/yiran
[root@node2 yiran]# tailf test.log
327: Sat May 18 09:45:23 UTC 2019
328: Sat May 18 09:45:24 UTC 2019
329: Sat May 18 09:45:25 UTC 2019
330: Sat May 18 09:45:26 UTC 2019

可以看到这里已经按照预期打印在 Pod 所在节点上了，满足我们的需求。

接下来是重头戏，集群级别的日志控制。

集群级别日志

我们为什么需要日志？对于开发者，可以通过日志进行快速的错误排查；对于运维同学可以根据日志来了解程序运行状态。一句话就是日志非常重要。

那么既然日志这么重要，那么在 k8s 上如何处理日志，尤其是 k8s 提供了 ReplicaSet/DeploymentSet 这类可以自动缩扩容，自动 ha 的资源，我们如果仅仅通过节点级别的日志管理，集群规模小还好，当集群规模变大之后，对于使用日志的同学简直是灾难。

在看过了标准日志处理和节点日志处理后，我们来看看一个标准的 k8s 集群是如何处理服务日志和应用日志的。

这里的前提是，我们有一个日志中心（如 ES)去处理日志，有几种配置方式可以选择：

节点级别日志代理

在 k8s 集群中运行一个 DaemonSet，启动的容器运行日志转发器，用于将节点上的日志转发到日志中心，日志转发器可以根据各自资源情况和需求自由选择，如 Logstash,Fluentd,Fluent-bit 等等。

k8s 标准配置中推荐该方案，无论是从资源使用还是从配置管理上都是最佳方案。

对应配置在 kubernetes/cluster/addons/fluentd-elasticsearch 路径下，我们可以直接创建部署，部署后状态如下：

1
2
3
4
5
6
7
[root@node1 fluentd-elasticsearch]# kubectl -n kube-system get rs |grep kibana
kibana-logging-f4d99b69f          1         1         1       2d6h
[root@node1 fluentd-elasticsearch]# kubectl -n kube-system get ds |grep fluent
fluentd-es-v2.4.0       3         3         3       3            3           <none>                          2d6h
[root@node1 fluentd-elasticsearch]# kubectl -n kube-system get statefulset
NAME                    READY   AGE
elasticsearch-logging   2/2     2d6h

可以看到 Fluentd 是以 DaemonSet 方式运行的；ElasticSearch 是以 StatefulSet 方式运行的；Kibana 是以 ReplicaSet 方式运行的。

其中 Fluentd 配置文件中监控的是 /var/log/container 路径下的所有日志，所以我们理论上可以在 ES 中看到所有应用的日志，那么看到日志之后，我们如何与实际的应用对应呢？这里可以看下具体示例：

创建 ReplicaSet 类型资源，指定 replica 为 1：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
[root@node1 ~]# cat log.yaml
apiVersion: apps/v1beta2
kind: ReplicaSet
metadata:
  name: testlog-rs
spec:
  replicas: 1
  selector:
    matchLabels:
      app: testlog-label
  template:
    metadata:
      labels:
        app: testlog-label
    spec:
      containers:
        - name: testlog-container-name
          image: busybox
          args: [/bin/sh, -c,
                 'i=0; while true; do echo "$i: $(date)"; i=$((i+1)); sleep 1; done']

我们将涉及到名称的字段均加上对应 key，便于在 ES 中查看对应关系，那么接下来看看在 ES 中该容器对应的日志是什么形式的：

根据上述对应关系，哪怕 Pod 重建了，我们仍可以通过 container_name 字段来查看对应应用日志，便于调试。

节点级别日志代理配合伴生容器

我们知道，标准容器日志应该输出到 stdout 和 stderr 中，那么如果我们一个 Pod 中输出多份日志怎么办？虽然这种情况是我们应该极度避免的，我们应该始终保证一个 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
27
28
29
30
31
32
33
34
35
36
37
38
39
40
admin/logging/two-files-counter-pod-streaming-sidecar.yaml 

apiVersion: v1
kind: Pod
metadata:
  name: counter
spec:
  containers:
  - name: count
    image: busybox
    args:
    - /bin/sh
    - -c
    - >
      i=0;
      while true;
      do
        echo "$i: $(date)" >> /var/log/1.log;
        echo "$(date) INFO $i" >> /var/log/2.log;
        i=$((i+1));
        sleep 1;
      done
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  - name: count-log-1
    image: busybox
    args: [/bin/sh, -c, 'tail -n+1 -f /var/log/1.log']
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  - name: count-log-2
    image: busybox
    args: [/bin/sh, -c, 'tail -n+1 -f /var/log/2.log']
    volumeMounts:
    - name: varlog
      mountPath: /var/log
  volumes:
  - name: varlog
    emptyDir: {}

这种方法是极度不推荐的，如果我们配置了 EFK，那么我们 1 份日志相当于写了 3 份，如果我们 ES 的后端存储是一个副本机制的分布式存储，那么我们 1 份日志相当于写了 3 * 2(或 3，存储副本数)份，这是极大的浪费了存储资源的，且会大大影响 SSD 磁盘寿命。

Pod 级别日志代理

如果觉得节点级别日志代理粒度太粗，我们也可以选择 Pod 级别，在每个 Pod 中都启动一个伴生容器作为日志代理，将日志直接转发到日志中心。

若以该形式部署，则我们的应用程序配置不仅要配置应用自身，还要考虑日志处理策略；节点计算能力现在大幅提升，每个节点的 Pod 数量很大，浪费了大量的计算资源。

应用自处理日志代理

如标题，我们当然可以在应用中直接将日志转发到指定的日志中心，这种情况也是极度糟糕的， Make each program do one thing well.。

总结

到这里我们关于日志部分的介绍就到这里，总的来说我们需要集中式的日志中心，且推荐以节点级别日志代理方式配置，前提是我们能够预留足够的计算资源和存储资源。后续有机会我们可以了解下日志与事件审计关联使用。

下一篇我们来看下 Kubernetes 中镜像相关管理与使用。

发表于 |

微服务

在 《Kubernetes In Action》的开始，先要了解 k8s 的需求来自于哪里，为什么我们需要 k8s。

引用维基百科解释：

微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信。

说一说我的理解，在项目早期，都是单体应用，随着功能越来越多，项目越来越大，虽然保证了部署运维的方便，但对于组内同学并不友好，新同学往往要在一坨代码中找自己想要的一点，本地修改提交跑 CI 也是以项目为单位的执行（前段时间 B 站不小心泄露的 Golang 代码就是这种）。当后续升级产品时，因为是以项目为最小粒度，哪怕无关代码，也要被迫进行代码升级，服务重启等操作，带来了额外的风险。

在 2014年，Martin Fowler 与 James Lewis 共同提出了微服务的概念，把单体应用改为通过接口产生的远程方法调用，将项目拆分，一个项目保证只做一件事情，独立部署和维护。

优点：

  • 高度可维护和可测试
  • 松散耦合
  • 可独立部署
  • 围绕业务能力进行组织

缺点：

  • 服务数量大幅增加，部署维护困难
  • 服务间依赖管理
  • 服务故障处理

容器

那么我们提到了项目演进，在同一时间，容器技术的标准化统一也间接促成了微服务的推广（我猜的），Docker 在 2013.03.13 发布第一个版本，容器化技术让我们产品发布形态有了新的选择，开发直接将容器镜像发布，运维同学通过镜像进行产品上线，确保了环境的统一，无须纠结环境配置相关问题（不用吵架了）。

当我们产品发布采用容器化上线后，我们面临一些其他的问题了：

  • 微服务追求的是将服务解耦，拆分为多个服务，那么最终发布形态对应的也是多个镜像，运维同学管理这些镜像之间的关系难度增加。
  • 同时当镜像运行在不同的物理节点上，对计算资源和网络资源的要求是一致的，运维同学需要做到让镜像无感知。
  • 当产品要进行升级时，镜像之间的依赖关系，故障切换等操作紧靠现有容器功能实现困难。

这么一看，与之前单体应用比也没好哪里去。于是有了各种容器编排系统，比如 Swarm，Mesos等等，但都不是很好用且各家一个标准，这时候老大哥谷歌发话了，我来把我们内部用了很多年要淘汰的东西拿出来给大家解决问题吧，于是有了 Kubernetes。

Kubernetes 功能上提供了解决微服务引入的问题，并更好的配合微服务去提供稳定高可用的统一容器化环境，具体如何解决的我们后续可以通过了解 Pod，ConfigMap，ReplicaSet 等功能去详细了解。

总结

可能是因为我考虑问题都是从运维角度去看的，网上的一些文章讲的带来的好处反而没看太清，可能作为 2C 产品，追求敏捷开发，产品不断快速迭代的目标比较适合，但是如果本身作为一个追求稳定可靠的 2B 产品来说，引入 k8s 带来的好处和维护 k8s 带来的成本真的要仔细的从产品层面考虑清楚，这里感觉跟具体的技术关系不大，而是说从产品面向的客户对象考虑，客户想要的是一个什么产品，而 k8s 作为一个还在不断（频繁）迭代的产品来说（可以去看看 release notes 的更新速度），后续若出现某些 API 不兼容等情况，如何去应对，感觉还是个灾难。

参考链接

在学习过程中，通过阅读 cch123 的博客对微服务有了更深的了解，这里列一下相关的系列博客链接：

  1. 微服务的灾难-通用语言

  2. 微服务的灾难-技术栈

  3. 微服务的灾难-拆分

  4. 微服务的灾难-依赖地狱

  5. 微服务的灾难-最终一致

  6. 微服务的灾难-康威定律和 KPI 冲突

发表于 |

Kubernetes 实战-前言

自从 Kubernetes 大热之后，一直没跟着版本去了解具体的功能及使用，只是大概了解其中概念。之前推特上有人推荐《Kubernetes In Action》这本书，说是对入门同学很友好，利用五一假期和这个周末，终于看完了，打算把学习过程和其中的一些想法记录下来。

《Kubernetes In Action》

就想推荐人说的那样，这本书作为 101 系列来说，是很称职的，你跟着官方示例做，90%以上都是可以成功的，且讲解门槛不高，推荐。

中文版是由七牛团队翻译的，虽然其中有一些小的翻译错误，但是整体读下来还是很顺畅的，不影响阅读，当然现在网上已经有原版资源，想读的同学可以去 SaltTiger 搜索下载。

本书章节较多，分为 3 部分：What？How？Why？首先讲解 k8s 及容器的基本概念，然后讲解 k8s 基本使用，最后介绍了一些 k8s 工作原理及最佳实践。

当你了解了什么是 k8s，及 k8s 能带来什么好处之后，我们去使用 k8s，从而真实的感受到 k8s 带来的便利，这种感觉是很美好的（表面美好的东西肯定会有某些限制），对我来说这种美好截止到第二部分就停止了。在第三部分中，我们在之前感受到的便利隐藏着很多没有考虑到的边界因素，也意味着我们从一个传统的单节点服务切换到微服务架构上，会新增很多需要去考虑的因素，如果 k8s 内部提供了解决方案，那么很简单，我们直接编写 YAML 就可以了，如果 k8s 没有解决方案呢？我不知道，可能当我真正体验过之后才能给出感受吧（即将发生的事）。

下一篇我们来说下什么是微服务。

发表于 |

工作上用 Shell 的频率是很高的，哪怕现在有了 Ansible 或者其他配置工具，Shell 仍是一个以 Linux 作为工作环境的同学的必备技能。
之前写过 GitHub 上的 Pure Bash Bible 的博客，看到 LeetCode 上的 Shell 题目好久不更新了，只有 4 道，今天记录一下题解。

192. Word Frequency

统计文本文件中单词出现次数，倒序输出。

words.txt

1
2
the day is sunny the the
the sunny is is

利用 tr sort uniq awk 解决。

1
2
# Read from the file words.txt and output the word frequency list to stdout.
cat words.txt | tr -s ' ' '\n' | sort | uniq -c | sort -rn | awk '{ print $2, $1 }'

193. Valid Phone Numbers

校验电话号码正确性。

file.txt

1
2
3
987-123-4567
123 456 7890
(123) 456-7890

主要是利用 grep 匹配正则，注意转义符。

1
2
# Read from the file file.txt and output all valid phone numbers to stdout.
grep -P '^(\d{3}-|\(\d{3}\) )\d{3}-\d{4}$' file.txt

194. Transpose File

行和列转换。

file.txt

1
2
3
name age
alice 21
ryan 30

1
2
3
4
5
6
7
# Read from the file file.txt and print its transposed content to stdout.
ncol=`head -n1 file.txt | wc -w`

for i in `seq 1 $ncol`
do
    echo `cut -d' ' -f$i file.txt`
done

195. Tenth Line

显示文件第 10 行。

file.txt

1
2
3
4
5
6
7
8
9
10
Line 1
Line 2
Line 3
Line 4
Line 5
Line 6
Line 7
Line 8
Line 9
Line 10

如果直接使用 head tail 的话不能方便处理文件为空的情况。

1
2
# Read from the file file.txt and output the tenth line to stdout.
sed -n '10p' file.txt

总结

其实编写 Shell 在熟知 Linux 内置命令就可以处理大部分场景了，如果处理不来，只能求助于 sed 和 awk, 但我脑子可能不太好使，awk 的语法总是记不住，每次写之前都要查一下语法。 - -

如果不想在代码中充斥着各种转义处理的话，还是老老实实使用 Python 编写脚本吧。