kubernetes基于二进制最新发行版的安装

写在前面

博客好久都没有更新了，~~惰情的我啊~~即使鸽了那么久也是理直气壮、理所当然。（再不更新，会被清友链了吧喂！！每当我博客处于这种情况时，不用怀疑🤨，就是金老师说的

除了工作什么都没做除了做爱什么都做了

就是这种状态了。

看到大家都在写自己的2019年度总结，依然是没有啥总结的一年，技术、感情、理财都平淡无奇，或许更能接受自己的普通了吧。年龄加了一，有过茫然，有过黑暗，见识了更大的世界，和很多人告了别，也遇见了很多人，亦是值得过的一年。

那么，这一篇算是新年除草文吧，也祝能看到这篇文的朋友2020身体健康！（没看到的朋友~~新年新对象~~也身体健康✌）

废话了那么多，说正经事。

看到标题，你点进来了，以为我是写k8s的安装，事实上我真的是写k8s的安装🙃

所以大概标题已经劝退了80%想要点进来的人，都2020年了，怎么还有人写k8s的安装教程啊（emmmmm

由于本人一惯的记录为主风格，所以有些地方并不是很详细，不足之处请指正。

为什么选择二进制安装

请输入图片描述

嗯，明明有更简单简单的安装方式（kubemini、kubeadm、Rancher、Kubespray、kops等等）为啥还要用二进制发行版啊？

而官方也有不同实践建议不同部署方案

比如Rancher,只要在已经安装过docker的主机上运行

1

sudo docker run -d --restart=unless-stopped -p 80:80 -p 443:443 rancher/rancher

然后进入web界面就可以无脑的建立一个集群了，多方便啊！

我也使用过kubeadm，实话说就算你会科学上网访问Google的服务，依然不可避免的踩很多坑🕳

使用二进制包安装部署过程可能比较复杂、繁琐，但是下载方便、灵活定制，更有助与你对k8s架构以及非工具包装的底层工作模式的理解，甚至，你会知道执行完一行命令，文件系统会发生怎样的改变。

这里并不是批评脚本以及工具，而是建议初次安装尽量选择二进制包安装。

脚本和工具很便捷，但我选择不便捷，并建议入门者也这样选择。

前戏

OS&Software

在安装之前，先明确一下已经做好的前置工作，有一台Linux主机，已安装好docker： Linux OS : CentOS Linux release 7.6.1810 (Core) docker : Docker version 19.03.1, build 74b1e89

kubernetes的最新发行版本，你可以在此页面获取，当前我使用的是v1.17

kubernetes组件和架构使用一个工具先了解架构和组件，下图是官网扒过来的

可以看到一个集群有Master、Nodes、Cloud节点，集群是一组计算机，至少一个工作节点和至少一个主节点。

工作节点托管作为应用程序组件的Pod。主节点管理集群中的工作节点和Pod。多个主节点用于为群集提供故障转移和高可用性。

不要忘了还有插件，比如Web UI (Dashboard)。请输入图片描述

Master节点

Master节点上面主要由四个模块组成（apiserver，schedule，controller-manager，etcd）为了简便起见，建议第一次就放在一台机器上吧。

（以下内容来自网络，讲得有什么不对的地方你~~有本事顺着网线过来打死我~~可以参看官方说明）

kube-apiserver: 负责对外提供RESTful的kubernetes API 的服务，它是系统管理指令的统一接口，任何对资源的增删该查都要交给apiserver处理后再交给etcd。kubectl(kubernetes提供的客户端工具，该工具内部是对kubernetes API的调用）是直接和apiserver交互的。

kube-scheduler: 负责调度Pod到合适的Node上，如果把scheduler看成一个黑匣子，那么它的输入是pod和由多个Node组成的列表，输出是Pod和一个Node的绑定。kubernetes目前提供了调度算法，同样也保留了接口。用户根据自己的需求定义自己的调度算法。

kube-controller-manager: 如果apiserver做的是前台的工作的话，那么controller-manager就是负责后台的。每一个资源都对应一个控制器。而control manager就是负责管理这些控制器的，比如我们通过APIServer创建了一个Pod，当这个Pod创建成功后，apiserver的任务就算完成了。

etcd：etcd是一个高可用的键值存储系统，kubernetes使用它来存储各个资源的状态，从而实现了Restful的API。

Node节点

每个Node节点主要由二个模块组成：kublet, kube-proxy。

（同样，以下内容来自网络，讲得有什么不对的地方你~~有本事顺着网线过来打死我~~可以参看官方说明）

kube-proxy: 该模块实现了kubernetes中的服务发现和反向代理功能。kube-proxy支持TCP和UDP连接转发，默认基Round Robin算法将客户端流量转发到与service对应的一组后端pod。服务发现方面，kube-proxy使用etcd的watch机制监控集群中service和endpoint对象数据的动态变化，并且维护一个service到endpoint的映射关系，从而保证了后端pod的IP变化不会对访问者造成影响，另外，kube-proxy还支持session affinity。

kublet：kublet是Master在每个Node节点上面的agent，是Node节点上面最重要的模块，它负责维护和管理该Node上的所有容器，但是如果容器不是通过kubernetes创建的，它并不会管理。本质上，它负责使Pod的运行状态与期望的状态一致。

工作模式

到网上扒了一张工作模式图（水文真方便啊，我也是专业的面向谷歌搜索写文工程师了）

嗯~ o(￣▽￣)o ，图片很清楚，不解释了。

就是干它

下载

完成了前戏热身，现在可以开始干了。

kubernetes 还记得最新发行版本下载页面吧，可以开始下载了

到Server Binaries挑一个最合适自己的包下载（不要问我哪个最合适你！） 注意，假如你的服务器在国内，这里你必须掌握科学上网的方法，否则包是下不下来的！

你可以在wget前添加一个https_proxy=http://IP:PORT/或者在自己电脑下载好上传至服务器。

1
2
3


cd /usr/local/src
wget https://dl.k8s.io/v1.17.0/kubernetes-server-linux-amd64.tar.gz
tar zxvf kubernetes-server-linux-amd64.tar.gz

看下目录结构

 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


.
├── addons
├── kubernetes-src.tar.gz
├── LICENSES
└── server
    └── bin
        ├── apiextensions-apiserver
        ├── kubeadm
        ├── kube-apiserver
        ├── kube-apiserver.docker_tag
        ├── kube-apiserver.tar
        ├── kube-controller-manager
        ├── kube-controller-manager.docker_tag
        ├── kube-controller-manager.tar
        ├── kubectl
        ├── kubelet
        ├── kube-proxy
        ├── kube-proxy.docker_tag
        ├── kube-proxy.tar
        ├── kube-scheduler
        ├── kube-scheduler.docker_tag
        ├── kube-scheduler.tar
        └── mounter

3 directories, 19 files

上面的插件，以及源码现在都不需要太过关注，bin内是需要的内容。

可以看到kube-apiserver、kube-scheduler、kube-controller-manager三大组件都在，唯独缺少etcd。

etcd 事实上etcd的官网在这里，可以选择下载二进制文件与自己编译，这里选择二进制文件

1
2


wget https://github.com/etcd-io/etcd/releases/download/v3.3.18/etcd-v3.3.18-linux-amd64.tar.gz
tar etcd-v3.3.18-linux-amd64.tar.gz

etcd支持自动TLS以及通过客户端证书进行的身份验证，以实现客户端到服务器以及对等（服务器到服务器/群集）的通信。

要启动并运行，首先要获得一个成员的CA证书和签名密钥对。建议为集群中的每个成员创建并签名一个新的密钥对。

cfssl

为了方便起见，cfssl工具提供了一个简单的接口来生成证书。

同样也下载下来备用。

1
2
3
4
5
6


mkdir ~/bin
curl -L -o ~/bin/cfssl https://pkg.cfssl.org/R1.2/cfssl_linux-amd64
curl -L -o ~/bin/cfssljson https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64
curl -L -o ~/bin/cfssl-certinfo https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64
chmod +x ~/bin/{cfssl,cfssljson,cfssl-certinfo}
export PATH=$PATH:~/bin

证书准备

容器内部使用的证书类型 客户端证书用于通过服务器对客户端进行身份验证。例如etcdctl，etcd proxy或者docker客户端。服务器证书由服务器使用，并由客户端验证服务器身份。例如docker服务器或kube-apiserver。 etcd集群成员以两种方式相互通信时使用对等证书。

本章节参考这个页面的内容

CA证书 使用默认的配置生成json文件(后续可根据具体需求修改json)

1
2
3
4


mkdir ~/cfssl
cd ~/cfssl
cfssl print-defaults config > ca-config.json
cfssl print-defaults csr > ca-csr.json

我使用的配置

 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


#ca-config.json
cat <<EOF >ca-config.json
{
    "signing": {
        "default": {
            "expiry": "43800h"
        },
        "profiles": {
            "server": {
                "expiry": "43800h",
                "usages": [
                    "signing",
                    "key encipherment",
                    "server auth"
                ]
            },
            "client": {
                "expiry": "43800h",
                "usages": [
                    "signing",
                    "key encipherment",
                    "client auth"
                ]
            },
            "peer": {
                "expiry": "43800h",
                "usages": [
                    "signing",
                    "key encipherment",
                    "server auth",
                    "client auth"
                ]
            }
        }
    }
}
EOF
#ca-csr.json
cat <<EOF >ca-csr.json
{
    "CN": "Lvmoo CA",
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "L": "Shanghai",
            "O": "Lvmoo Group",
            "ST": "Shanghai",
            "OU": "Di'an",
            "OU": "Houfeng"
        }
    ]
}
EOF
#生成证书
cfssl gencert -initca ca-csr.json | cfssljson -bare ca

会生成三个文件，ca.csr不需要太多关注，ca-key.pem是CA证书密钥，ca.pem即CA证书

请保持ca-key.pem文件安全。使用此密钥可以在您的CA中创建任何种类的证书。

服务器证书 同样看看默认json长什么样再修改

1

cfssl print-defaults csr > server.json

服务器证书最重要的值是通用名称（CN）和hosts。必须修改它们，hosts里面必须包含所有节点的ip例如：

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


#server.json
cat <<EOF >server.json
{
    "CN": "coreos1",
    "hosts": [
        "HOSTNAME",
        "10.3.1.2",
        "10.3.1.3",
        "10.3.1.4"
    ],
    "key": {
        "algo": "ecdsa",
        "size": 256
    },
    "names": [
        {
            "C": "CN",
            "L": "Shanghai",
            "ST": "Shanghai"
        }
    ]
}
EOF

可以生成服务器证书和私钥了

1

cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=server server.json | cfssljson -bare server

得到三个文件server-key.pem服务器证书密钥，server.csrcsr文件，server.pem服务器证书。同样证书密钥也是需要注意安全的。

对等证书 对等证书和服务器证书一样的步骤

1

cfssl print-defaults csr > member1.json

修改CN和hosts

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


#member1.json
cat <<EOF >member1.json
{
    "CN": "member1",
    "hosts": [
        "HOSTNAME1",
        "HOSTNAME2"
    ],
    "key": {
        "algo": "ecdsa",
        "size": 256
    },
    "names": [
        {
            "C": "CN",
            "L": "Shanghai",
            "ST": "Shanghai"
        }
    ]
}
EOF
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=peer member1.json | cfssljson -bare member1

客户端证书

重要的事情上述步骤已经重复很多次了，再来一次

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


#client.json
cat <<EOF >client.json
{
    "CN": "client",
    "hosts": [],
    "key": {
        "algo": "ecdsa",
        "size": 256
    },
    "names": [
        {
            "C": "CN",
            "L": "Shanghai",
            "ST": "Shanghai"
        }
    ]
}
EOF
cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=client client.json | cfssljson -bare client

验证证书

1
2
3
4


openssl x509 -in ca.pem -text -noout 
openssl x509 -in server.pem -text -noout 
openssl x509 -in member1.pem -text -noout 
openssl x509 -in client.pem -text -noout

高潮

配置etcd

网上找来的脚本，真香🙂 （这种脚本对于理解来说并不会构成太大的阻碍）

 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


#! /usr/local/env bash
etcd_01_ip=10.3.1.3
etcd_02_ip=10.3.1.2
etcd_03_ip=10.3.1.4
ETCD_CONF=/etc/etcd/etcd.conf
ETCD_SSL=/etc/etcd/ssl
ETCD_SYSTEMD=/usr/lib/systemd/system/etcd.service
SSL_DIR=/etc/cfssl
cp /usr/local/src/etcd-v3.3.18-linux-amd64/etcd* ~/bin/
mkdir /etc/etcd
#上面一步注释一下，就是将二进制文件放到家目录下的bin，上面已经创建过的哦
ln -sv ~/bin/* /usr/local/bin
#软链接到系统目录下，方便下面的脚本路径书写,需要root权限
ln -sv ~/cfssl /etc/cfssl

# The etcd configuration file. 
cat <<EOF >$ETCD_CONF
#[Member]
ETCD_NAME="etcd-01"
ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
ETCD_LISTEN_PEER_URLS="https://$etcd_01_ip:2380"
ETCD_LISTEN_CLIENT_URLS="https://$etcd_01_ip:2379"

#[Clustering]
ETCD_INITIAL_ADVERTISE_PEER_URLS="https://$etcd_01_ip:2380"
ETCD_ADVERTISE_CLIENT_URLS="https://$etcd_01_ip:2379"
ETCD_INITIAL_CLUSTER="etcd-01=https://$etcd_01_ip:2380,etcd-02=https://$etcd_02_ip:2380,etcd-03=https://$etcd_03_ip:2380"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
ETCD_INITIAL_CLUSTER_STATE="new"
EOF

. $ETCD_CONF
# The etcd servcie configuration file.
cat <<EOF >$ETCD_SYSTEMD
[Unit]
Description=Etcd Server
After=network.target
After=network-online.target
Wants=network-online.target

[Service]
Type=notify
EnvironmentFile=$ETCD_CONF
ExecStart=/usr/local/bin/etcd \
--name=${ETCD_NAME} \
--data-dir=${ETCD_DATA_DIR} \
--listen-peer-urls=${ETCD_LISTEN_PEER_URLS} \
--listen-client-urls=${ETCD_LISTEN_CLIENT_URLS},http://127.0.0.1:2379 \
--advertise-client-urls=${ETCD_ADVERTISE_CLIENT_URLS} \
--initial-advertise-peer-urls=${ETCD_INITIAL_ADVERTISE_PEER_URLS} \
--initial-cluster=${ETCD_INITIAL_CLUSTER} \
--initial-cluster-token=${ETCD_INITIAL_CLUSTER_TOKEN} \
--initial-cluster-state=new \
--cert-file=$SSL_DIR/server.pem \
--key-file=$SSL_DIR/server-key.pem \
--peer-cert-file=$SSL_DIR/member1.pem \
--peer-key-file=$SSL_DIR/member1-key.pem \
--trusted-ca-file=$SSL_DIR/ca.pem \
--peer-trusted-ca-file=$SSL_DIR/ca.pem
Restart=on-failure
RestartSec=5
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target
EOF

而后设置启动以及开机启动，并查看状态

1
2
3


systemctl daemon-reload
systemctl enable etcd.service --now
systemctl status etcd

其它节点请修改/etc/etcd/etcd.conf的配置,如节点二：

1
2
3
4
5


sed -i '/ETCD_NAME/{s/etcd-01/etcd-02/g}' /etc/etcd/etcd.conf
sed -i '/ETCD_LISTEN_PEER_URLS/{s/1.3/1.2/g}' /etc/etcd/etcd.conf
sed -i '/ETCD_LISTEN_CLIENT_URLS/{s/1.3/1.2/g}' /etc/etcd/etcd.conf
sed -i '/ETCD_INITIAL_ADVERTISE_PEER_URLS/{s/1.3/1.2/g}' /etc/etcd/etcd.conf
sed -i '/ETCD_ADVERTISE_CLIENT_URLS/{s/1.3/1.2/g}' /etc/etcd/etcd.conf

以及/lib/systemd/system/etcd.service文件除--initial-cluster项的ip地址修改为本机ip地址 --name项修改本机标识。

有了两个节点，都运行了etcd就可以进行测试了。

etcd的检验

查看集群成员

1
2
3
4
5


etcdctl \
--ca-file=/etc/cfssl/ca.pem \
--cert-file=/etc/cfssl/server.pem \
--key-file=/etc/cfssl/server-key.pem \
member list

返回信息

1
2


ac4fa4c43c567f2: name=etcd-02 peerURLs=https://10.3.1.2:2380 clientURLs=https://10.3.1.2:2379 isLeader=false
ada0b2c111734ace: name=etcd-01 peerURLs=https://10.3.1.3:2380 clientURLs=https://10.3.1.3:2379 isLeader=true

看到etcd-01被选为了Leader

查看节点健康状态

1
2
3
4
5


etcdctl \
--ca-file=/etc/cfssl/ca.pem \
--cert-file=/etc/cfssl/server.pem \
--key-file=/etc/cfssl/server-key.pem \
cluster-health

返回信息

1
2


member ac4fa4c43c567f2 is healthy: got healthy result from https://10.3.1.2:2379
member ada0b2c111734ace is healthy: got healthy result from https://10.3.1.3:2379

或者指定格式输出

1
2
3
4
5


ETCDCTL_API=3 etcdctl -w table \
--endpoints=https://10.3.1.2:2379,https://10.3.1.3:2379 \
--cacert=/etc/cfssl/ca.pem --cert=/etc/cfssl/server.pem \
--key=/etc/cfssl/server-key.pem \
endpoint health

返回表格

执行

1
2
3
4
5


ETCDCTL_API=3 etcdctl -w table \
--endpoints=https://10.3.1.2:2379,https://10.3.1.3:2379 \
--cacert=/etc/cfssl/ca.pem --cert=/etc/cfssl/server.pem \
--key=/etc/cfssl/server-key.pem \
endpoint status

+———————–+——————+———+———+———–+———–+————+ | ENDPOINT | ID | VERSION | DB SIZE | IS LEADER | RAFT TERM | RAFT INDEX | +———————–+——————+———+———+———–+———–+————+ | https://10.3.1.2:2379 | ac4fa4c43c567f2 | 3.3.18 | 16 kB | false | 1952 | 35 | | https://10.3.1.3:2379 | ada0b2c111734ace | 3.3.18 | 20 kB | true | 1952 | 35 | +———————–+——————+———+———+———–+———–+————+

节点说明

上面测试只有两个节点，实际推荐使用奇数个节点

主要是在选主leader的时候，不会发生脑裂的情况。一般情况是如果有3个，那么可以容许一个挂掉；如果有五个，那么容许2个挂掉；也就是N/2+1个活着就行。

节点数量看起来越多越好，但是在通信的时候，首先是leader要发送很多信息给follower，从而导致网络可能有压力；另外就是写的时候，必须全部首先写到leader之中，然后从leader进行同步，这样会造成写的性能下降。

部署Master节点

首先将Master节点的工具建立软链接

1
2


cp /usr/local/src/kubernetes/server/bin/{kube-apiserver,kube-scheduler,kube-controller-manager,kubeadm,kubelet,kubectl} ~/bin
ln -sv ~/bin/* /usr/local/bin/

创建配置文件夹 mkdir /etc/kubernetes

部署kube-apiserver

 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


#! /usr/local/env bash
etcd_01_ip=10.3.1.3
etcd_02_ip=10.3.1.2
etcd_03_ip=10.3.1.4
KUBE_ETC=/etc/kubernetes
KUBE_API_CONF=$KUBE_ETC/apiserver.conf
ETCD_SSL=/etc/cfssl
# Create a token file.
cat <<EOF >$KUBE_ETC/token.csv
$(head -c 16 /dev/urandom | od -An -t x | tr -d ' '),kubelet-bootstrap,10001,"system:kubelet-bootstrap"
EOF

# Create a kube-apiserver configuration file.
cat <<EOF >$KUBE_API_CONF
KUBE_APISERVER_OPTS="--logtostderr=true \
--v=4 \
--etcd-servers=https://$etcd_01_ip:2379,https://$etcd_02_ip:2379,https://$etcd_03_ip:2379 \
--bind-address=$etcd_01_ip \
--secure-port=6443 \
--advertise-address=$etcd_01_ip \
--allow-privileged=true \
--service-cluster-ip-range=10.0.0.0/24 \
--enable-admission-plugins=NamespaceLifecycle,LimitRanger,SecurityContextDeny,ServiceAccount,ResourceQuota,NodeRestriction \
--authorization-mode=RBAC,Node \
--enable-bootstrap-token-auth \
--token-auth-file=$KUBE_ETC/token.csv \
--service-node-port-range=30000-50000 \
--tls-cert-file=$ETCD_SSL/server.pem  \
--tls-private-key-file=$ETCD_SSL/server-key.pem \
--client-ca-file=$ETCD_SSL/ca.pem \
--service-account-key-file=$ETCD_SSL/ca-key.pem \
--etcd-cafile=$ETCD_SSL/ca.pem \
--etcd-certfile=$ETCD_SSL/server.pem \
--etcd-keyfile=$ETCD_SSL/server-key.pem"
EOF

# Create the kube-apiserver service.
. $KUBE_API_CONF
cat <<EOF >/usr/lib/systemd/system/kube-apiserver.service
[Unit]
Description=Kubernetes API Server
Documentation=https://github.com/kubernetes/kubernetes
After=etcd.service
Wants=etcd.service

[Service]
EnvironmentFile=$KUBE_API_CONF
ExecStart=/usr/local/bin/kube-apiserver $KUBE_APISERVER_OPTS
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable kube-apiserver.service --now
systemctl status kube-apiserver.service

部署kube-scheduler

 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


#! /usr/local/env bash
KUBE_ETC=/etc/kubernetes
KUBE_SCHEDULER_CONF=$KUBE_ETC/kube-scheduler.conf
cat <<EOF >$KUBE_SCHEDULER_CONF
KUBE_SCHEDULER_OPTS="--logtostderr=true \
--v=4 \
--master=127.0.0.1:8080 \
--leader-elect"
EOF
. $KUBE_SCHEDULER_CONF
cat>/usr/lib/systemd/system/kube-scheduler.service<<EOF
[Unit]
Description=Kubernetes Scheduler
Documentation=https://github.com/kubernetes/kubernetes

[Service]
EnvironmentFile=$KUBE_SCHEDULER_CONF
ExecStart=/usr/local/bin/kube-scheduler $KUBE_SCHEDULER_OPTS
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable kube-scheduler.service --now
systemctl status kube-scheduler.service

部署kube-controller

 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


#! /usr/local/env bash
KUBE_ETC=/etc/kubernetes
KUBE_CONTROLLER_CONF=$KUBE_ETC/kube-controller-manager.conf
ETCD_SSL=/etc/cfssl

cat<<EOF >$KUBE_CONTROLLER_CONF
KUBE_CONTROLLER_MANAGER_OPTS="--logtostderr=true \
--v=4 \
--master=127.0.0.1:8080 \
--leader-elect=true \
--address=127.0.0.1 \
--service-cluster-ip-range=10.0.0.0/24 \
--cluster-name=kubernetes \
--cluster-signing-cert-file=$ETCD_SSL/ca.pem \
--cluster-signing-key-file=$ETCD_SSL/ca-key.pem  \
--root-ca-file=$ETCD_SSL/ca.pem \
--service-account-private-key-file=$ETCD_SSL/ca-key.pem"
EOF
. $KUBE_CONTROLLER_CONF
cat>/usr/lib/systemd/system/kube-controller-manager.service<<EOF
[Unit]
Description=Kubernetes Controller Manager
Documentation=https://github.com/kubernetes/kubernetes

[Service]
EnvironmentFile=$KUBE_CONTROLLER_CONF
ExecStart=/usr/local/bin/kube-controller-manager $KUBE_CONTROLLER_MANAGER_OPTS
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable kube-controller-manager.service --now
systemctl status kube-controller-manager.service

集群查看

使用命令kubectl get cs可查看当前集群状态

返回的信息如下：

1
2
3
4
5


NAME                 STATUS    MESSAGE             ERROR
scheduler            Healthy   ok
controller-manager   Healthy   ok
etcd-0               Healthy   {"health":"true"}
etcd-1               Healthy   {"health":"true"}

节点自动签署证书

创建bootstrap和kube-proxy的kubeconfig文件 Master apiserver启用TLS认证后，Node节点kubelet组件想要加入集群，必须使用CA签发的有效证书才能与apiserver通信，当Node节点很多时，签署证书是一件很繁琐的事情，因此有了TLS Bootstrapping机制，kubelet会以一个低权限用户自动向apiserver申请证书，kubelet的证书由apiserver动态签署。在前面创建的token文件在这一步派上了用场。

 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


#! /usr/local/env bash
BOOTSTRAP_TOKEN=$(awk -F "," '{print $1}' /etc/kubernetes/token.csv)
KUBE_SSL=/etc/cfssl/
KUBE_APISERVER="https://10.3.1.3:6443"

cd $KUBE_SSL
# Set cluster parameters.
kubectl config set-cluster kubernetes \
  --certificate-authority=./ca.pem \
  --embed-certs=true \
  --server=${KUBE_APISERVER} \
  --kubeconfig=bootstrap.kubeconfig

# Set client parameters.
kubectl config set-credentials kubelet-bootstrap \
  --token=${BOOTSTRAP_TOKEN} \
  --kubeconfig=bootstrap.kubeconfig

# Set context parameters. 
kubectl config set-context default \
  --cluster=kubernetes \
  --user=kubelet-bootstrap \
  --kubeconfig=bootstrap.kubeconfig

# Set context.
kubectl config use-context default --kubeconfig=bootstrap.kubeconfig

# Create kube-proxy kubeconfig file. 
kubectl config set-cluster kubernetes \
  --certificate-authority=./ca.pem \
  --embed-certs=true \
  --server=${KUBE_APISERVER} \
  --kubeconfig=kube-proxy.kubeconfig

kubectl config set-credentials kube-proxy \
  --client-certificate=./client.pem \
  --client-key=./client-key.pem \
  --embed-certs=true \
  --kubeconfig=kube-proxy.kubeconfig

kubectl config set-context default \
  --cluster=kubernetes \
  --user=kube-proxy \
  --kubeconfig=kube-proxy.kubeconfig

kubectl config use-context default --kubeconfig=kube-proxy.kubeconfig

# Bind kubelet-bootstrap user to system cluster roles.
kubectl create clusterrolebinding kubelet-bootstrap \
  --clusterrole=system:node-bootstrapper \
  --user=kubelet-bootstrap

贤者模式

暂时只水到主节点了，node节点的部署再说吧（就是没有了🤣

怎么跟想象中的不一样😅

越写越乱，感觉看起来也是一头雾水吧？

也可以看这篇Kubernetes二进制方式v1.13.2生产环境的安装与配置（HTTPS+RBAC）本文其实也主要参看了这篇文章，除已标注的官方链接，其余主要参考文章有：

etcd集群之序搭建k8s的etcd集群 Kubernetes高可用Master节点安装

由于仓促，可能会有不对的地方，后续可能会进行一次勘误。