K8S部署（单节点master）

本文转载自查看原文 2021-10-28 23:39 798

一、常见的K8S部署方式
二、kubernetes二进制部署
- 2.1、环境准备
- 2.2、部署etcd集群
三、部署docker引擎
- 3.1、所有node节点部署docker引擎
四、flannel网络配置
五、部署master组件
六、部署worker node组件

一、常见的K8S部署方式

1.1、Minikube

Minikube是一个工具，可以在本地快速运行一个单节点微型K8S，仅用于学习、预览K8S的一些特性使用
部署地址：https://kubernetes.io/docs/setup/minikube

1.2、Kubeadmin

Kubeadmin也是一个工具，提供kubeadm init和Kubeadm join，用于快速部署K8S集群，相对简单
https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/

1.3、二进制安装部署

生产首选，从官方下载发行版的二进制包，手动部署每个组件和自签TLS证书，组成K8S集群，新手推荐
https://github.com/kubernetes/kubernetes/releases

小结：kubeadm降低部署门槛，但屏蔽了很多细节，遇到问题很难排查。如果想更容易可控，推荐使用二进制包部署kubernetes集群，虽然手动部署麻烦点，期间可以学习很多工作原理，也利于后期维护

二、kubernetes二进制部署

2.1、环境准备

K8S集群master01:192.168.80.11 kube-apiserver kube-controller-manager kube-scheduler etcd cfssl cfssljson cfssl-certinfo 
K8S集群node1:192.168.80.12 kubelet kube-proxy docker flannel etcd cfssl cfssljson cfssl-certinfo
K8S集群node1:192.168.80.13 kubelet kube-proxy docker flannel etcd cfssl cfssljson cfssl-certinfo

2.1.1、关闭防火墙

systemctl stop firewalld
systemctl disable firewalld
setenforce 0

2.1.2、关闭selinux

setenforce 0
sed -i 's/enforcing/disabled/' /etc/selinux/config

2.1.3、关闭swap

swapoff -a
sed -ri 's/.*swap.*/#&/' /etc/fstab

2.1.4、根据规划设置主机名

hostnamectl set-hostname master01
hostnamectl set-hostname node1
hostnamectl set-hostname node2

2.1.5、在master添加hosts

cat >> /etc/hosts <<EOF
192.168.80.11 master01
192.168.80.12 node01
192.168.80.13 node02
EOF

2.1.6、将桥接的IPV4流量传递到iptables的链

cat > /etc/sysctl.d/k8s.conf <<EOF
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF

sysctl --system

2.1.7、时间同步

yum install ntpdate -y 
ntpdate time.windows.com

2.2、部署etcd集群

2.2.1、etcd简介

etcd是coreos团队于2013年6月发起的开源项目，它的目标是构建一个高可用的分布式键值数据库。etcd内部采用raft协议作为一致性算法，etcd是go语言编写的

etcd作为服务发现系统，有以下的特点
简单：安装配置简单，而且提供了http api进行交互，使用也很简单
安全：支持SSL证书验证
快速：单实例支持每秒2K+读操作
可靠：采用raft算法，实现分布式系统数据的可用性和一致性

etcd目前默认使用2379端口提供HTTP API服务，2380端口和peer通信（这两个端口已经被IANA（互联网数字分配机构）官方预留给etcd）。
即etcd默认使用2379端口对外客户端提供通讯，使用端口来进行服务器间内部通讯
etcd在生产环境中一般推荐集群方式部署。由于etcd的leader选举机制，要求至少为3台或以上的奇数台。

2.2.2、准备签发证书环境

CFSSL是CloudFlare 公司开源的一款PKI/TLS工具。CFSSL包含一个命令行工具和一个用于签名、验证和捆绑TLS证书的HTTP API服务。使用GO语言编写
CFSSL使用配置文件生成证书，因此自签之前，需要生成它识别的json格式的配置文件，CFSSL提供了方便的命令行生成配置文件
CFSSL用来为etcd提供TLS证书，它支持签三种类型的证书：
1，client证书，服务端连接客户端时携带的证书，用于客户端验证服务端身份，如kube-apiserver访问etcd
2，server证书，客户端连接服务端时携带的整数，用于服务端验证客户端身份，如etcd对外提供服务
3，peer证书，相互之间连接时使用的证书，如etcd节点之间进行验证和通信
这里全部都使用同一套证书认证

2.2.3、下载证书制作工具并生成证书（在master节点上操作（192.168.80.11））

wget https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -O /usr/local/bin/cfssl
wget https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -O /usr/local/bin/cfssljson
wget https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -O /usr/local/bin/cfssl-certinfo
或
curl -L https://pkg.cfssl.org/R1.2/cfssl_linux-amd64 -o /usr/local/bin/cfssl
curl -L https://pkg.cfssl.org/R1.2/cfssljson_linux-amd64 -o /usr/local/bin/cfssljson
curl -L https://pkg.cfssl.org/R1.2/cfssl-certinfo_linux-amd64 -o /usr/local/bin/cfssl-certinfo

chmod +x /usr/local/bin/cfssl*

cfssl:证书签发的工具命令
cfssljson：将cfssl生成的证书（json格式）变为文件承载式证书
cfssl-certinfo：验证证书的信息
cfssl-certinfo -cert <证书名称>	#查看证书的信息

2.2.4、创建K8S工作目录（在master节点上操作（192.168.80.11））

mkdir /opt/k8s
cd /opt/k8s/

2.2.5、编写etcd-cert.sh 和etcd.sh 到 /opt/k8s/目录中并给于权限（在master节点上操作（192.168.80.11））

chmod +x etcd-cert.sh etcd.sh	#etcd-cert用于签发证书、etcd用于启动etcd

etcd-cert.sh

cat etcd-cert.sh
#!/bin/bash
# example: ./etcd.sh etcd01 192.168.80.10 etcd02=https://192.168.80.11:2380,etcd03=https://192.168.80.12:2380

#创建etcd配置文件/opt/etcd/cfg/etcd
ETCD_NAME=$1
ETCD_IP=$2
ETCD_CLUSTER=$3

WORK_DIR=/opt/etcd

cat > $WORK_DIR/cfg/etcd  <<EOF
#[Member]
ETCD_NAME="${ETCD_NAME}"
ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
ETCD_LISTEN_PEER_URLS="https://${ETCD_IP}:2380"
ETCD_LISTEN_CLIENT_URLS="https://${ETCD_IP}:2379"

#[Clustering]
ETCD_INITIAL_ADVERTISE_PEER_URLS="https://${ETCD_IP}:2380"
ETCD_ADVERTISE_CLIENT_URLS="https://${ETCD_IP}:2379"
ETCD_INITIAL_CLUSTER="etcd01=https://${ETCD_IP}:2380,${ETCD_CLUSTER}"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
ETCD_INITIAL_CLUSTER_STATE="new"
EOF

#Member:成员配置
#ETCD_NAME：节点名称，集群中唯一。成员名字，集群中必须具备唯一性，如etcd01
#ETCD_DATA_DIR：数据目录。指定节点的数据存储目录，这些数据包括节点ID，集群ID，集群初始化配置，Snapshot文件，若未指定-wal-dir，还会存储WAL文件；如果不指定会用缺省目录
#ETCD_LISTEN_PEER_URLS：集群通信监听地址。用于监听其他member发送信息的地址。ip为全0代表监听本机所有接口
#ETCD_LISTEN_CLIENT_URLS：客户端访问监听地址。用于监听etcd客户发送信息的地址。ip为全0代表监听本机所有接口

#Clustering：集群配置
#ETCD_INITIAL_ADVERTISE_PEER_URLS：集群通告地址。其他member使用，其他member通过该地址与本member交互信息。一定要保证从其他member能可访问该地址。静态配置方式下，该参数的value一定要同时在--initial-cluster参数中存在
#ETCD_ADVERTISE_CLIENT_URLS：客户端通告地址。etcd客户端使用，客户端通过该地址与本member交互信息。一定要保证从客户侧能可访问该地址
#ETCD_INITIAL_CLUSTER：集群节点地址。本member使用。描述集群中所有节点的信息，本member根据此信息去联系其他member
#ETCD_INITIAL_CLUSTER_TOKEN：集群Token。用于区分不同集群。本地如有多个集群要设为不同
#ETCD_INITIAL_CLUSTER_STATE：加入集群的当前状态，new是新集群，existing表示加入已有集群。


#创建etcd.service服务管理文件
cat > /usr/lib/systemd/system/etcd.service <<EOF
[Unit]
Description=Etcd Server
After=network.target
After=network-online.target
Wants=network-online.target

[Service]
Type=notify
EnvironmentFile=${WORK_DIR}/cfg/etcd
ExecStart=${WORK_DIR}/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=${WORK_DIR}/ssl/server.pem \
--key-file=${WORK_DIR}/ssl/server-key.pem \
--trusted-ca-file=${WORK_DIR}/ssl/ca.pem \
--peer-cert-file=${WORK_DIR}/ssl/server.pem \
--peer-key-file=${WORK_DIR}/ssl/server-key.pem \
--peer-trusted-ca-file=${WORK_DIR}/ssl/ca.pem
Restart=on-failure
LimitNOFILE=65536

[Install]
WantedBy=multi-user.target
EOF

#--listen-client-urls：用于指定etcd和客户端的连接端口
#--advertise-client-urls：用于指定etcd服务器之间通讯的端口，etcd有要求，如果--listen-client-urls被设置了，那么就必须同时设置--advertise-client-urls，所以即使设置和默认相同，也必须显式设置
#--peer开头的配置项用于指定集群内部TLS相关证书（peer 证书），这里全部都使用同一套证书认证
#不带--peer开头的的参数是指定 etcd 服务器TLS相关证书（server 证书），这里全部都使用同一套证书认证


systemctl daemon-reload
systemctl enable etcd
systemctl restart etcd

etcd.sh

cat etcd.sh
#!/bin/bash
#配置证书生成策略，让 CA 软件知道颁发有什么功能的证书，生成用来签发其他组件证书的根证书
cat > ca-config.json <<EOF
{
  "signing": {
    "default": {
      "expiry": "87600h"
    },
    "profiles": {
      "www": {
         "expiry": "87600h",
         "usages": [
            "signing",
            "key encipherment",
            "server auth",
            "client auth"
        ]
      }
    }
  }
}
EOF

#ca-config.json：可以定义多个 profiles，分别指定不同的过期时间、使用场景等参数；
#后续在签名证书时会使用某个 profile；此实例只有一个 www 模板。
#expiry：指定了证书的有效期，87600h 为10年，如果用默认值一年的话，证书到期后集群会立即宕掉
#signing：表示该证书可用于签名其它证书；生成的 ca.pem 证书中 CA=TRUE；
#key encipherment：表示使用非对称密钥加密，如 RSA 加密；
#server auth：表示client可以用该 CA 对 server 提供的证书进行验证；
#client auth：表示server可以用该 CA 对 client 提供的证书进行验证；
#注意标点符号，最后一个字段一般是没有逗号的。


#-----------------------
#生成CA证书和私钥（根证书和私钥）
#特别说明： cfssl和openssl有一些区别，openssl需要先生成私钥，然后用私钥生成请求文件，最后生成签名的证书和私钥等，但是cfssl可以直接得到请求文件。
cat > ca-csr.json <<EOF
{
    "CN": "etcd",
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "L": "Beijing",
            "ST": "Beijing"
        }
    ]
}
EOF

#CN：Common Name，浏览器使用该字段验证网站或机构是否合法，一般写的是域名 
#key：指定了加密算法，一般使用rsa（size：2048）
#C：Country，国家
#ST：State，州，省
#L：Locality，地区,城市
#O: Organization Name，组织名称，公司名称
#OU: Organization Unit Name，组织单位名称，公司部门

cfssl gencert -initca ca-csr.json | cfssljson -bare ca

#生成的文件：
#ca-key.pem：根证书私钥
#ca.pem：根证书
#ca.csr：根证书签发请求文件

#cfssl gencert -initca <CSRJSON>：使用 CSRJSON 文件生成生成新的证书和私钥。如果不添加管道符号，会直接把所有证书内容输出到屏幕。
#注意：CSRJSON 文件用的是相对路径，所以 cfssl 的时候需要 csr 文件的路径下执行，也可以指定为绝对路径。
#cfssljson 将 cfssl 生成的证书（json格式）变为文件承载式证书，-bare 用于命名生成的证书文件。


#-----------------------
#生成 etcd 服务器证书和私钥
cat > server-csr.json <<EOF
{
    "CN": "etcd",
    "hosts": [
    "192.168.80.10",
    "192.168.80.11",
    "192.168.80.12"
    ],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "L": "BeiJing",
            "ST": "BeiJing"
        }
    ]
}
EOF

#hosts：将所有 etcd 集群节点添加到 host 列表，需要指定所有 etcd 集群的节点 ip 或主机名不能使用网段，新增 etcd 服务器需要重新签发证书。

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

#生成的文件：
#server.csr：服务器的证书请求文件
#server-key.pem：服务器的私钥
#server.pem：服务器的数字签名证书

#-config：引用证书生成策略文件 ca-config.json
#-profile：指定证书生成策略文件中的的使用场景，比如 ca-config.json 中的 www

2.2.6、创建用于生成CA证书、etcd服务器证书以及、私钥的目录（在master节点上操作（192.168.80.11））

mkdir /opt/k8s/etcd-cert
mv etcd-cert.sh etcd-cert/
cd /opt/k8s/etcd-cert/
./etcd-cert.sh	#生成CA证书、etcd服务器证书以及私钥

2.2.7、启动etcd服务（在master节点上操作（192.168.80.11））

上传 etcd-v3.3.10-linux-amd64.tar.gz 到 /opt/k8s/ 目录中，解压 etcd 压缩包
cd /opt/k8s/
tar zxvf etcd-v3.3.10-1jnux-amd64.tar.gz
ls etcd-v3.3.10-1inux-amd64
#etcd就是etcd 服务的启动命令，后面可跟各种启动参数
#etcdctl主要为etcd 服务提供了命令行操作

2.2.8、创建用于存放etcd配置文件，命令文件，证书文件目录（在master节点上操作（192.168.80.11））

mkdir -p /opt/etcd/{cfg,bin.ssl}
mv /opt/k8s/etcd-v3.3.10-1jnux-amd64/etcd /opt/k8s/etcd-v3.3.10-1jnux-amd64/etcdctl /opt/etcd/bin/
cp /opt/k8s/etcd-cert/*.pem /opt/etcd/ssl/

./etcd.sh etcd01 192.168.80.11 etcd02=https://192.168.80.12:2380,etcd03=https://192.168.8013:2380
#进入卡主状态等待其他节点加入，这里需要三台etcd服务同时启动，如果只启动其中一台后，服务会卡在哪里，知道集群中所有etcd节点都已启动，可忽略这个情况

#另外打开一个窗口查看etcd进程是否正常
ps -ef | grep etcd

2.2.9、把etcd相关证书文件和命令文件全部拷贝到另外两个etcd集群节点（在master节点上操作（192.168.80.11））

scp -r /opt/etcd root@192.168.80.12:/opt/
scp -r /opt/etcd root@192.168.80.13:/opt/

2.2.10、把ercd服务管理文件拷贝到另外两个etcd集群节点（在master节点上操作（192.168.80.11））

scp /usr/lib/systemd/system/etcd.service root@192.168.80.12:/usr/lib/systemd/system/
scp /usr/lib/systemd/system/etcd.service root@192.168.80.13:/usr/lib/systemd/system/

2.2.11、启动etcd服务

systemctl enable --now etcd.servcie 
systemctl status etcd.service

2.2.12、检查集群状态

ln -s /opt/etcd/bin/etcd* /usr/local/bin

#检查etcd群集状态
cd /opt/etcd/ssl
/opt/etcd/bin/etcdctl \
--ca-file=ca.pem \
--cert-file=server.pem \
--key-file=server-key.pem \
--endpoints="https://192.168.80.11:2379,https://192.168.80.12:2379,https://192.168.80.13:2379" \
cluster-health

--cert-file:识别https端使用ssl证书文件
--key-file：使用此ssl密钥文件标识https客户端
--ca-file：使用此ca证书验证启用https的服务器的证书
--endpoints：集群中以逗号分割的机器地址列表
cluster-health：检查etcd集群的运行状况

2.2.13、切换到etcd3版本查看集群节点状态和成员列表

export ETCDCTL_API=3	#v2和v3命令略有不同，etcd2和etcd3也是不兼容的，默认是v2版本
etcdctl --write-out=table endpoint status
etcdctl --write-out=table member list
export ETCDCTL_API=2	#再切回v2版本

三、部署docker引擎

3.1、所有node节点部署docker引擎

yum install -y yum-utils device-mapper-persistent-data lvm2
yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
yum install -y docker-ce docker-ce-cli containerd.io

systemctl enable docker 
systemctl start docker

四、flannel网络配置

4.1、K8S中pod网络通信

4.1.1、pod内容器与容器之间的通信

在同一个pod内的容器（pod内的容器是不会跨宿主机的）共享同一个网络命名空间，相当于他们在同一台机器上一样，可以用localhost地址访问彼此的端口

4.1.2、同一个node内pod之间的通信

每个pod都有一个真实的全局IP地址，同一个node内不同pod之间可以直接采用对方pod的IP地址进行通信，pod1和pod2都是通过veth连接到同一个docker0网桥，网段相同，所以它们之间可以直接通信

4.1.3、不同node上pod之间通信

pod地址与docker0在同一网段，docker0网段与宿主机网卡是两个不同的网段，且不同node之间的通信只能通过宿主机的物理网卡进行

要想实现不同node上pod之间的通信，就必须想办法通过主机的物理网卡IP地址进行寻址和通信，因此要满足两个条件；pod的ip不能冲突；将pod的IP和所在的node的IP关联起来，通过这个管理让不同node上pod之间直接通过内网IP地址通信

4.2、Overlay Network

叠加网络，在二层或者三层基础网络上叠加的一种虚拟网络技术模式，该网络中的主机通过虚拟链路隧道连接起来（类似于vpn）

4.3、VXLAN

将源数据包封装到UDP中，并使用基础网络的IP/MAC作为外层报文头进行封装，然后再以太网上传输，到达目的地后由隧道断点解封装并将数据发送给目标地址

4.4、Flannel

Flannle的功能是让集群中的不同节点主机创建的docker容器都具有全集群唯一的虚拟IP地址
Flannel是Overlay网络中的一种，也是将TCP源数据包封装在另一种网络包里面进行路由转发和通信，目前支持UDP、VXLAN、host-GW3中数据转发方式

4.5、flannel工作原理

数据从node01上pod的源容器中发出后，经由所在主机的docker0虚拟网卡转发到flannel1.1虚拟网卡，flanneld服务监听在flannel1.1虚拟网卡的另外一段

flannle通过etcd服务维护了一张节点间的路由表。源主机node01的flanneld服务将原本的数据北荣封装到UDP中后根据自己的路由表通过物理网卡投递给目的节点node2的flanneld服务，数据到达以后被解包，然后直接进入目的节点的flannel1.1虚拟网卡，之后被转发到目的主机的docker0虚拟网卡，最后就像本机容器通信一样由docker0转发到目标容器

4.6、flannel工作流程

数据从源node节点pod发出后，会经由docker0网卡转发到flannel0网卡，在flannel0网卡有个flanneld服务会把这个数据包封装到udp报文中，然后根据自己在etcd中维护路由表通过物理网卡转发到目标node节点，数据包到达目标node节点后会被flanneld服务解封装，然后经由flaanel0网卡和docker0网卡转发到目标pod的容器

4.7、ETCD之flannel提供说明

存储管理flannel可分配的IP地址段资源

监控ETCD中每个pod的实际地址，并在内存中建立维护pod节点路由表

4.8、flannel部署

4.8.1、添加flannel网络配置信息，写入分配的子网段到etcd中，供flannel使用（在master01节点上操作）

cd /opt/etcd/ssl
/opt/etcd/bin/etcdctl \
--ca-file=ca.pem \
--cert-file=server.pem \
--key-file=server-key.pem \
--endpoints="https://192.168.80.11:2379,https://192.168.80.12:2379,https://192.168.80.13:2379" \
set /coreos.com/network/config '{"Network":"172.17.0.0/16","Backend": {"Type": "vxlan"}}'

#查看写入的信息
/opt/etcd/bin/etcdctl \
--ca-file=ca.pem \
--cert-file=server.pem \
--key-file=server-key.pem \
--endpoints="https://192.168.80.11:2379,https://192.168.80.12:2379,https://192.168.80.13:2379" \
get /coreos.com/network/config

set <key> <value>
set /coreos.com/network/config 添加一条网络配置记录，这个配置将用于flannel分配给每个dockeer的虚拟IP地址段
get <key>
get /coreos.com/network/config 获取网络配置记录，后面不用再跟参数

Network：用于指定flannel地址池
Backend：用于指定数据包以什么方式转发，默认为udp模式，backend为vxlan比起预设的udp性能相对好一点

4.8.2、上传 flannel.sh 和 flannel-v0.10.0-linux-amd64.tar.gz 到/opt 目录中，解压 flannel 压缩包（在所有node节点上操作）

cd /opt
tar zxvf flannel-v0.10.0-linux-amd64.tar.gz 
flanneld                                                  #flanneld为主要的执行文件
mk-docker-opts.sh             #mk-docker-opts.sh脚本用于生成Docker启动网络环境参数
README.md

4.8.3、创建kubernetes工作目录（在所有node节点上操作）

mkdir -p /opt/kubernetes/{cfg,bin,ssl}
cd /opt
mv mk-docker-opts.sh flanneld /opt/kubernetes/bin/            #将主要执行文件和docker启动参数移动到工作目录中

4.8.4、启动flanneld服务，开启flannel网络功能（在所有node节点上操作）

cd /opt
chmod +x flannel.sh
./flannel.sh https://192.168.80.11:2379,https://192.168.80.12:2379,https://192.168.80.13:2379

--bip∶指定 docker 启动时的子网
--ip-masq∶ 设置 ipmasg=false 关闭 snat 伪装策略
--mtu=1450∶mtu 要留出50字节给外层的vxlan封包的额外开销使用


flannel启动后会生成一个docker网络相关信息配置文件/run/flannel/subnet.env，包含了docker要使用flannel通讯的相关参数，子网段，空间等
cat /run/flannel/subnet.env

flannel.sh

cat flannel.sh
#!/bin/bash
#定义etcd集群的端点IP地址和对外提供服务的2379端口
#${var:-string}：若变量var为空，则用在命令行中用string来替换；否则变量var不为空时，则用变量var的值来替换，这里的1代表的是位置变量$1
ETCD_ENDPOINTS=${1:-"http://127.0.0.1:2379"}

#创建flanneld配置文件
cat > /opt/kubernetes/cfg/flanneld <<EOF
FLANNEL_OPTIONS="--etcd-endpoints=${ETCD_ENDPOINTS} \\
-etcd-cafile=/opt/etcd/ssl/ca.pem \\
-etcd-certfile=/opt/etcd/ssl/server.pem \\
-etcd-keyfile=/opt/etcd/ssl/server-key.pem"
EOF

#flanneld 本应使用 etcd 客户端TLS相关证书（client 证书），这里全部都使用同一套证书认证。


#创建flanneld.service服务管理文件
cat > /usr/lib/systemd/system/flanneld.service <<EOF
[Unit]
Description=Flanneld overlay address etcd agent
After=network-online.target network.target
Before=docker.service

[Service]
Type=notify
EnvironmentFile=/opt/kubernetes/cfg/flanneld
ExecStart=/opt/kubernetes/bin/flanneld --ip-masq \$FLANNEL_OPTIONS
ExecStartPost=/opt/kubernetes/bin/mk-docker-opts.sh -k DOCKER_NETWORK_OPTIONS -d /run/flannel/subnet.env
Restart=on-failure

[Install]
WantedBy=multi-user.target

EOF

#flanneld启动后会使用 mk-docker-opts.sh 脚本生成 docker 网络相关配置信息
#mk-docker-opts.sh -k DOCKER_NETWORK_OPTIONS：将组合选项键设置为环境变量DOCKER_NETWORK_OPTIONS，docker启动时将使用此变量
#mk-docker-opts.sh -d /run/flannel/subnet.env：指定要生成的docker网络相关信息配置文件的路径，docker启动时候引用此配置

systemctl daemon-reload
systemctl enable flanneld
systemctl restart flanneld

4.8.5、进入docker启动项中配置（在所有node节点上操作）

进入docker启动项中添加flannel定义的相关网路参数，并将flannel添加到启动变量中

vim /usr/lib/systemd/system/docker.service    
EnvironmentFile=/run/flannel/subnet.env
ExecStart=/usr/bin/dockerd $DOCKER_NETWORK_OPTIONS -H fd:// --containerd=/run/containerd/containerd.sock

systemctl daemon-reload                                       #重载后重启服务
systemctl restart docker.service
ifconfig                                                                    #重启后docker网段与自定义的flannel网段一致

ping -I 172.17.38.1 172.17.72.1	#测试连通性

五、部署master组件

5.1、上传master.zip和k8s-cert.sh到 /opt/k8s目录中，解压master.zip压缩包

cd /opt/k8s/
unzip master.zip
chmod +x *.sh

k8s-cert.sh

#!/bin/bash
#配置证书生成策略，让 CA 软件知道颁发有什么功能的证书，生成用来签发其他组件证书的根证书
cat > ca-config.json <<EOF
{
  "signing": {
    "default": {
      "expiry": "87600h"
    },
    "profiles": {
      "kubernetes": {
         "expiry": "87600h",
         "usages": [
            "signing",
            "key encipherment",
            "server auth",
            "client auth"
        ]
      }
    }
  }
}
EOF

#生成CA证书和私钥（根证书和私钥）
cat > ca-csr.json <<EOF
{
    "CN": "kubernetes",
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "L": "Beijing",
            "ST": "Beijing",
      	    "O": "k8s",
            "OU": "System"
        }
    ]
}
EOF

cfssl gencert -initca ca-csr.json | cfssljson -bare ca -


#-----------------------
#生成 apiserver 的证书和私钥（apiserver和其它k8s组件通信使用）
#hosts中将所有可能作为 apiserver 的 ip 添加进去，后面 keepalived 使用的 VIP 也要加入
cat > apiserver-csr.json <<EOF
{
    "CN": "kubernetes",
    "hosts": [
      "10.0.0.1",
      "127.0.0.1",
      "192.168.80.10",		#master01
      "192.168.80.20",		#master02
      "192.168.80.100",		#vip，后面 keepalived 使用
      "192.168.80.14",		#load balancer01（master）
      "192.168.80.15",		#load balancer02（backup）
      "kubernetes",
      "kubernetes.default",
      "kubernetes.default.svc",
      "kubernetes.default.svc.cluster",
      "kubernetes.default.svc.cluster.local"
    ],
    "key": {
        "algo": "rsa",
        "size": 2048
    },
    "names": [
        {
            "C": "CN",
            "L": "BeiJing",
            "ST": "BeiJing",
            "O": "k8s",
            "OU": "System"
        }
    ]
}
EOF

cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes apiserver-csr.json | cfssljson -bare apiserver


#-----------------------
#生成 kubectl 的证书和私钥，具有admin权限
cat > admin-csr.json <<EOF
{
  "CN": "admin",
  "hosts": [],
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "CN",
      "L": "BeiJing",
      "ST": "BeiJing",
      "O": "system:masters",
      "OU": "System"
    }
  ]
}
EOF

cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes admin-csr.json | cfssljson -bare admin


#-----------------------
#生成 kube-proxy 的证书和私钥
cat > kube-proxy-csr.json <<EOF
{
  "CN": "system:kube-proxy",
  "hosts": [],
  "key": {
    "algo": "rsa",
    "size": 2048
  },
  "names": [
    {
      "C": "CN",
      "L": "BeiJing",
      "ST": "BeiJing",
      "O": "k8s",
      "OU": "System"
    }
  ]
}
EOF

cfssl gencert -ca=ca.pem -ca-key=ca-key.pem -config=ca-config.json -profile=kubernetes kube-proxy-csr.json | cfssljson -bare kube-proxy

5.2、创建kubernets工作目录

mkdir -p /opt/kubernetes/{cfg,bin,ssl}

5.3、创建用于生成CA证书、相关组件的证书和私钥的目录

mkdir /opt/k8s/k8s-cert
mv /opt/k8s/k8s-cert.sh /opt/k8s/k8s-cert
cd /opt/k8s/k8s-cert/
./k8s-cert.sh
#controller-manager 和 kube-scheduler设置为只调用当前机器的apiserver，使用127.0.0.1:8080通信，因此不需要签发证书

5.4、复制CA证书、apiserver相关证书和私钥到kubernetes工作目录的ssl子目录中

cp ca*pem apiserver*pem /opt/kubernetes/ssl/

5.5、上传kubernetes-server-linux-amd64.tar.gz 到/opt/k8s/ 目录中，解压kubernetes 压缩包

cd /opt/k8s/
tar zxvf kubernetes-server-linux-amd64.tar.gz

5.6、复制master组件的关键命令文件到kubernetes工作目录的bin子目录

cd /opt/k8s/kubernetes/server/bin 
cp kube-apiserver kubectl kube-controller-manager kube-scheduler /opt/kubernetes/bin/ 
1n -s /opt/kubernetes/bin/* /usr/local/bin/

5.7、创建bootstrap token 认证文件，apiserver 启动时会调用，然后就相当于在集群内创建了一个这个用户，接下来就可以用RBAC给他授权

cd /opt/k8s/

token.sh

#!/bin/bash
#获取随机数前16个字节内容，以十六进制格式输出，并删除其中空格
BOOTSTRAP_TOKEN=$(head -e 16 /dev/urandom | od -An -t x | tr -d ‘ ’)
#生成token.csv 文件，按照Token序列号,用户名,UID,用户组的格式生成
cat > /opt/kubernetes/cfg/token.csv <<EOF
$(BOOTSTRAP_TOKEN),kubelet-bootstrap,10001,"system: kubelet-bootstrap"
EOF

chmod +x token.sh
./token.sh

5.8、二进制文件、token、证书都准备好后，开启apiserver服务

cd /opt/k8s/
./apiserver.sh 192.168.80.11 https://192.168.80.11:2379,https://192.168.80.12:2379,https://192.168.80.13:2379

5.9、检查进程是否启动成功

ps aux | grep kube-apiserver
#k8s通过kube- apiserver这 个进程提供服务，该进程运行在单个master节点上。默认有两个端口6443和8080
#安全端口6443用于接收HTTPS请求，用于基于Token文件或客户端证书等认证
netstat -natp | grep 6443

#本地端口8080用于接收HTTP请求，非认证或授权的HTTP请求通过该端口访问APIServer
netstat -natp | grep 8080

5.10、查看版本信息(必须保证apiserver启动正常，不然无法查询到server的版本信息)

kubctl version

apiservice.sh

#!/bin/bash
#example: apiserver.sh 192.168.80.10 https://192.168.80.10:2379,https://192.168.80.11:2379,https://192.168.80.12:2379
#创建 kube-apiserver 启动参数配置文件
MASTER_ADDRESS=$1
ETCD_SERVERS=$2

cat >/opt/kubernetes/cfg/kube-apiserver <<EOF
KUBE_APISERVER_OPTS="--logtostderr=true \\
--v=4 \\
--etcd-servers=${ETCD_SERVERS} \\
--bind-address=${MASTER_ADDRESS} \\
--secure-port=6443 \\
--advertise-address=${MASTER_ADDRESS} \\
--allow-privileged=true \\
--service-cluster-ip-range=10.0.0.0/24 \\
--enable-admission-plugins=NamespaceLifecycle,LimitRanger,ServiceAccount,ResourceQuota,NodeRestriction \\
--authorization-mode=RBAC,Node \\
--kubelet-https=true \\
--enable-bootstrap-token-auth \\
--token-auth-file=/opt/kubernetes/cfg/token.csv \\
--service-node-port-range=30000-50000 \\
--tls-cert-file=/opt/kubernetes/ssl/apiserver.pem  \\
--tls-private-key-file=/opt/kubernetes/ssl/apiserver-key.pem \\
--client-ca-file=/opt/kubernetes/ssl/ca.pem \\
--service-account-key-file=/opt/kubernetes/ssl/ca-key.pem \\
--etcd-cafile=/opt/etcd/ssl/ca.pem \\
--etcd-certfile=/opt/etcd/ssl/server.pem \\
--etcd-keyfile=/opt/etcd/ssl/server-key.pem"
EOF

#--logtostderr=true：输出日志到标准错误控制台，不输出到文件
#--v=4：指定输出日志的级别，v=4为调试级别详细输出
#--etcd-servers：指定etcd服务器列表（格式：//ip:port），逗号分隔
#--bind-address：指定 HTTPS 安全接口的监听地址，默认值0.0.0.0
#--secure-port：指定 HTTPS 安全接口的监听端口，默认值6443
#--advertise-address：通过该 ip 地址向集群其他节点公布 api server 的信息，必须能够被其他节点访问
#--allow-privileged=true：允许拥有系统特权的容器运行，默认值false
#--service-cluster-ip-range：指定 Service Cluster IP 地址段
#--enable-admission-plugins：kuberneres集群的准入控制机制，各控制模块以插件的形式依次生效，集群时必须包含ServiceAccount，运行在认证（Authentication）、授权（Authorization）之后，Admission Control是权限认证链上的最后一环， 对请求API资源对象进行修改和校验
#--authorization-mode：在安全端口使用RBAC,Node授权模式，未通过授权的请求拒绝，默认值AlwaysAllow。RBAC是用户通过角色与权限进行关联的模式；Node模式（节点授权）是一种特殊用途的授权模式，专门授权由kubelet发出的API请求，在进行认证时，先通过用户名、用户分组验证是否是集群中的Node节点，只有是Node节点的请求才能使用Node模式授权
#--kubelet-https=true：kubelet通信使用https，默认值true
#--enable-bootstrap-token-auth：在apiserver上启用Bootstrap Token 认证
#--token-auth-file=/opt/kubernetes/cfg/token.csv：指定Token认证文件路径
#--service-node-port-range：指定 NodePort 的端口范围，默认值30000-32767


#创建 kube-apiserver.service 服务管理文件
cat >/usr/lib/systemd/system/kube-apiserver.service <<EOF
[Unit]
Description=Kubernetes API Server
Documentation=https://github.com/kubernetes/kubernetes

[Service]
EnvironmentFile=-/opt/kubernetes/cfg/kube-apiserver
ExecStart=/opt/kubernetes/bin/kube-apiserver \$KUBE_APISERVER_OPTS
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable kube-apiserver
systemctl restart kube-apiserver

5.11、启动scheduler 服务

cd /opt/k8s/
./scheduler.sh 127.0.0.1

kube-scheduler.sh

#!/bin/bash
#创建 kube-scheduler 启动参数配置文件
MASTER_ADDRESS=$1

cat >/opt/kubernetes/cfg/kube-scheduler <<EOF
KUBE_SCHEDULER_OPTS="--logtostderr=true \\
--v=4 \\
--master=${MASTER_ADDRESS}:8080 \\
--leader-elect=true"
EOF

#--master：监听 apiserver 的地址和8080端口
#--leader-elect=true：启动 leader 选举
#k8s中Controller-Manager和Scheduler的选主逻辑：k8s中的etcd是整个集群所有状态信息的存储，涉及数据的读写和多个etcd之间数据的同步，对数据的一致性要求严格，所以使用较复杂的 raft 算法来选择用于提交数据的主节点。而 apiserver 作为集群入口，本身是无状态的web服务器，多个 apiserver 服务之间直接负载请求并不需要做选主。Controller-Manager 和 Scheduler 作为任务类型的组件，比如 controller-manager 内置的 k8s 各种资源对象的控制器实时的 watch apiserver 获取对象最新的变化事件做期望状态和实际状态调整，调度器watch未绑定节点的pod做节点选择，显然多个这些任务同时工作是完全没有必要的，所以 controller-manager 和 scheduler 也是需要选主的，但是选主逻辑和 etcd 不一样的，这里只需要保证从多个 controller-manager 和 scheduler 之间选出一个 leader 进入工作状态即可，而无需考虑它们之间的数据一致和同步。


#创建 kube-scheduler.service 服务管理文件
cat >/usr/lib/systemd/system/kube-scheduler.service <<EOF
[Unit]
Description=Kubernetes Scheduler
Documentation=https://github.com/kubernetes/kubernetes

[Service]
EnvironmentFile=-/opt/kubernetes/cfg/kube-scheduler
ExecStart=/opt/kubernetes/bin/kube-scheduler \$KUBE_SCHEDULER_OPTS
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable kube-scheduler
systemctl restart kube-scheduler

5.12、启动controller-manager服务

cd /opt/k8s/
./controller-manager.sh 127.0.0.1

kube-controller-manager.sh

#!/bin/bash
#创建 kube-controller-manager 启动参数配置文件
MASTER_ADDRESS=$1

cat >/opt/kubernetes/cfg/kube-controller-manager <<EOF
KUBE_CONTROLLER_MANAGER_OPTS="--logtostderr=true \\
--v=4 \\
--master=${MASTER_ADDRESS}: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=/opt/kubernetes/ssl/ca.pem \\
--cluster-signing-key-file=/opt/kubernetes/ssl/ca-key.pem  \\
--root-ca-file=/opt/kubernetes/ssl/ca.pem \\
--service-account-private-key-file=/opt/kubernetes/ssl/ca-key.pem \\
--experimental-cluster-signing-duration=87600h0m0s"
EOF

#--cluster-name=kubernetes：集群名称，与CA证书里的CN匹配
#--cluster-signing-cert-file：指定签名的CA机构根证书，用来签名为 TLS BootStrapping 创建的证书和私钥
#--root-ca-file：指定根CA证书文件路径，用来对 kube-apiserver 证书进行校验，指定该参数后，才会在 Pod 容器的 ServiceAccount 中放置该 CA 证书文件
#--experimental-cluster-signing-duration：设置为 TLS BootStrapping 签署的证书有效时间为10年，默认为1年


#创建 kube-controller-manager.service 服务管理文件
cat >/usr/lib/systemd/system/kube-controller-manager.service <<EOF
[Unit]
Description=Kubernetes Controller Manager
Documentation=https://github.com/kubernetes/kubernetes

[Service]
EnvironmentFile=-/opt/kubernetes/cfg/kube-controller-manager
ExecStart=/opt/kubernetes/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
systemctl restart kube-controller-manager

5.13、查看master节点状态

kubectl get componentstatuses
kubectl get cs

六、部署worker node组件

6.1、把kublet、kube-proxy拷贝到node节点（在master01节点上操作）

cd /opt/k8s/kubernetes/server/bin
scp kubelet kube-proxy root0192.168.80.12:/opt/kubernetes/bin/
scp kubelet kube-proxy root@192.168.80.13:/opt/kubernetes/bin/

6.2、上传node.zip到/opt目录中，解压node.zip压缩包，获得kubelet.sh、proxy.sh（在node01节点上操作）

cd /opt
unzip node.zip

proxy.sh

#!/bin/bash

NODE_ADDRESS=$1

#创建 kube-proxy 启动参数配置文件
cat >/opt/kubernetes/cfg/kube-proxy <<EOF
KUBE_PROXY_OPTS="--logtostderr=true \\
--v=4 \\
--hostname-override=${NODE_ADDRESS} \\
--cluster-cidr=172.17.0.0/16 \\
--proxy-mode=ipvs \\
--kubeconfig=/opt/kubernetes/cfg/kube-proxy.kubeconfig"
EOF

#--hostnameOverride: 参数值必须与 kubelet 的值一致，否则 kube-proxy 启动后会找不到该 Node，从而不会创建任何 ipvs 规则
#--cluster-cidr：指定 Pod 网络使用的聚合网段，Pod 使用的网段和 apiserver 中指定的 service 的 cluster ip 网段不是同一个网段。 kube-proxy 根据 --cluster-cidr 判断集群内部和外部流量，指定 --cluster-cidr 选项后 kube-proxy 才会对访问 Service IP 的请求做 SNAT，即来自非 Pod 网络的流量被当成外部流量，访问 Service 时需要做 SNAT。
#--proxy-mode：指定流量调度模式为 ipvs 模式
#--kubeconfig: 指定连接 apiserver 的 kubeconfig 文件	


#----------------------
#创建 kube-proxy.service 服务管理文件
cat >/usr/lib/systemd/system/kube-proxy.service <<EOF
[Unit]
Description=Kubernetes Proxy
After=network.target

[Service]
EnvironmentFile=-/opt/kubernetes/cfg/kube-proxy
ExecStart=/opt/kubernetes/bin/kube-proxy \$KUBE_PROXY_OPTS
Restart=on-failure

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable kube-proxy
systemctl restart kube-proxy

kubelet.sh

#!/bin/bash

NODE_ADDRESS=$1
DNS_SERVER_IP=${2:-"10.0.0.2"}

#创建 kubelet 启动参数配置文件
cat >/opt/kubernetes/cfg/kubelet <<EOF
KUBELET_OPTS="--logtostderr=true \\
--v=4 \\
--hostname-override=${NODE_ADDRESS} \\
--kubeconfig=/opt/kubernetes/cfg/kubelet.kubeconfig \\
--bootstrap-kubeconfig=/opt/kubernetes/cfg/bootstrap.kubeconfig \\
--config=/opt/kubernetes/cfg/kubelet.config \\
--cert-dir=/opt/kubernetes/ssl \\
--pod-infra-container-image=registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64:3.0"
EOF

#--hostname-override：指定kubelet节点在集群中显示的主机名或IP地址，默认使用主机hostname；kube-proxy和kubelet的此项参数设置必须完全一致
#--kubeconfig：指定kubelet.kubeconfig文件位置，用于如何连接到apiserver，里面含有kubelet证书，master授权完成后会在node节点上生成 kubelet.kubeconfig 文件
#--bootstrap-kubeconfig：指定连接 apiserver 的 bootstrap.kubeconfig 文件
#--config：指定kubelet配置文件的路径，启动kubelet时将从此文件加载其配置
#--cert-dir：指定master颁发的客户端证书和密钥保存位置
#--pod-infra-container-image：指定Pod基础容器（Pause容器）的镜像。Pod启动的时候都会启动一个这样的容器，每个pod之间相互通信需要Pause的支持，启动Pause需要Pause基础镜像


#----------------------
#创建kubelet配置文件（该文件实际上就是一个yml文件，语法非常严格，不能出现tab键，冒号后面必须要有空格，每行结尾也不能有空格）
cat >/opt/kubernetes/cfg/kubelet.config <<EOF
kind: KubeletConfiguration
apiVersion: kubelet.config.k8s.io/v1beta1
address: ${NODE_ADDRESS}
port: 10250
readOnlyPort: 10255
cgroupDriver: cgroupfs
clusterDNS:
- ${DNS_SERVER_IP} 
clusterDomain: cluster.local.
failSwapOn: false
authentication:
  anonymous:
    enabled: true
EOF

#PS：当命令行参数与此配置文件（kubelet.config）有相同的值时，就会覆盖配置文件中的该值。


#----------------------
#创建 kubelet.service 服务管理文件
cat >/usr/lib/systemd/system/kubelet.service <<EOF
[Unit]
Description=Kubernetes Kubelet
After=docker.service
Requires=docker.service

[Service]
EnvironmentFile=/opt/kubernetes/cfg/kubelet
ExecStart=/opt/kubernetes/bin/kubelet \$KUBELET_OPTS
Restart=on-failure
KillMode=process

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable kubelet
systemctl restart kubelet

6.3、创建kubectl管理员权限（在master01节点上操作）

cd /opt/k8s
./admin.sh

admin.sh

#!/bin/bash
mkdir /root/.kube
KUBE_CONFIG="/root/.kube/config"
KUBE_APISERVER="https://192.168.80.11:6443"

cd /opt/k8s/k8s-cert/

kubectl config set-cluster kubernetes \
  --certificate-authority=/opt/kubernetes/ssl/ca.pem \
  --embed-certs=true \
  --server=${KUBE_APISERVER} \
  --kubeconfig=${KUBE_CONFIG}
kubectl config set-credentials cluster-admin \
  --client-certificate=./admin.pem \
  --client-key=./admin-key.pem \
  --embed-certs=true \
  --kubeconfig=${KUBE_CONFIG}
kubectl config set-context default \
  --cluster=kubernetes \
  --user=cluster-admin \
  --kubeconfig=${KUBE_CONFIG}
kubectl config use-context default --kubeconfig=${KUBE_CONFIG}

6.4、创建用于生成kubelet的配置文件的目录（在master01节点操作）

mkdir /opt/k8s/kubeconfig

6.5、上传kubeconfig.sh 文件到/opt/k8s/kubeconfig 目录中（在master01节点操作）

#kubeconfig.sh文件包含集群参数(CA 证书、API Server 地址)，客户端参数(上面生成的证书和私钥)，集群context
#上下文参数(集群名称、用户名)。Kubenetes 组件(如kubelet、 kube-proxy) 通过启动时指定不同的kubeconfig文件可以切换到不同的集群，连接到apiserver
cd /opt/k8s/kubeconfig
chmod +x kubeconfig.sh

kubeconfig.sh

#!/bin/bash
#example: kubeconfig 192.168.122.10 /opt/k8s/k8s-cert/
#创建bootstrap.kubeconfig文件
#该文件中内置了 token.csv 中用户的 Token，以及 apiserver CA 证书；kubelet 首次启动会加载此文件，使用 apiserver CA 证书建立与 apiserver 的 TLS 通讯，使用其中的用户 Token 作为身份标识向 apiserver 发起 CSR 请求
 
BOOTSTRAP_TOKEN=$(awk -F ',' '{print $1}' /opt/kubernetes/cfg/token.csv)
APISERVER=$1
SSL_DIR=$2
 
export KUBE_APISERVER="https://$APISERVER:6443"
# 设置集群参数
kubectl config set-cluster kubernetes \
  --certificate-authority=$SSL_DIR/ca.pem \
  --embed-certs=true \
  --server=${KUBE_APISERVER} \
  --kubeconfig=bootstrap.kubeconfig
#--embed-certs=true：表示将ca.pem证书写入到生成的bootstrap.kubeconfig文件中
# 设置客户端认证参数，kubelet 使用 bootstrap token 认证
kubectl config set-credentials kubelet-bootstrap \
  --token=${BOOTSTRAP_TOKEN} \
  --kubeconfig=bootstrap.kubeconfig
# 设置上下文参数
kubectl config set-context default \
  --cluster=kubernetes \
  --user=kubelet-bootstrap \
  --kubeconfig=bootstrap.kubeconfig
# 使用上下文参数生成 bootstrap.kubeconfig 文件
kubectl config use-context default --kubeconfig=bootstrap.kubeconfig
#----------------------
#创建kube-proxy.kubeconfig文件
# 设置集群参数
kubectl config set-cluster kubernetes \
  --certificate-authority=$SSL_DIR/ca.pem \
  --embed-certs=true \
  --server=${KUBE_APISERVER} \
  --kubeconfig=kube-proxy.kubeconfig
# 设置客户端认证参数，kube-proxy 使用 TLS 证书认证
kubectl config set-credentials kube-proxy \
  --client-certificate=$SSL_DIR/kube-proxy.pem \
  --client-key=$SSL_DIR/kube-proxy-key.pem \
  --embed-certs=true \
  --kubeconfig=kube-proxy.kubeconfig
# 设置上下文参数
kubectl config set-context default \
  --cluster=kubernetes \
  --user=kube-proxy \
  --kubeconfig=kube-proxy.kubeconfig
# 使用上下文参数生成 kube-proxy.kubeconfig 文件
kubectl config use-context default --kubeconfig=kube-proxy.kubeconfig

6.6、生成kubelet的配置文件（在master01节点操作）

cd /opt/k8a/kubeconfig
./kubeconfig.sh 192.168.80.11 /opt/k8s/k8s-cert/

6.7、把配置文件bootstrap.kubeconfig、kube-proxy.kubeconfig拷贝到node节点（在master01节点操作）

cd /opt/k8s/kubeconfig
scp bootstrap.kubeconfig kube-proxy-kubeconfig root0192.168.80.12:/opt/kubernetes/cfg/
proxy.kubeconfig root@192.168.80.13:/opt/kubernetes/cfg/

6.8RBAC授权，将预设用户kubelet-bootatrap 与内置的ClusterRole system:node-bootatrapper 绑定到一起，使其能够发起CSR请求（在master01节点操作）

kubectl create clusterrolebinding kubelet-bootstrap --clusterrole=system:node-bootstrapper --user=kubelet-bootstrap

kubelet采用TLS Bootstrapping 机制，自 动完成到kube -apiserver的注册，在node节点量较大或者后期自动扩容时非常有用。
Master apiserver 启用TLS 认证后，node 节点kubelet 组件想要加入集群，必须使用CA签发的有效证书才能与apiserver 通信，当node节点很多时，签署证书是一件很繁琐的事情。因此Kubernetes 引入了TLS bootstraping 机制来自动颁发客户端证书，kubelet会以一个低权限用户自动向apiserver 申请证书，kubelet 的证书由apiserver 动态签署。

kubelet首次启动通过加载bootstrap.kubeconfig中的用户Token 和apiserver CA证书发起首次CSR请求，这个Token被预先内置在apiserver 节点的token.csv 中，其身份为kubelet-bootstrap 用户和system: kubelet- bootstrap用户组:想要首次CSR请求能成功(即不会被apiserver 401拒绝)，则需要先创建一个ClusterRoleBinding， 将kubelet-bootstrap 用户和system:node - bootstrapper内置ClusterRole 绑定(通过kubectl get clusterroles 可查询)，使其能够发起CSR认证请求。

TLS bootstrapping 时的证书实际是由kube-controller-manager组件来签署的，也就是说证书有效期是kube-controller-manager组件控制的; kube-controller-manager 组件提供了一个--experimental-cluster-signing-duration
参数来设置签署的证书有效时间:默认为8760h0m0s， 将其改为87600h0m0s， 即10年后再进行TLS bootstrapping 签署证书即可。

也就是说kubelet 首次访问API Server 时，是使用token 做认证，通过后，Controller Manager 会为kubelet生成一个证书，以后的访问都是用证书做认证了。

6.9、查看角色

kubectl get clusterroles | grep system:node-bootstrapper

#查看已授权角色
kubectl get clusterrolebinding

6.10、使用kubelet.sh脚本启动kubelet服务（在node01节点上操作）

cd /opt
chmod +x kubelet.sh
./kubelet.sh 192.168.80.12

#检查kubelet服务启动
ps aux | grep kubelet

#此时还没有生成证书

6.11、检查到node02节点的kublet发起的csr请求，pending表示等待集群给该节点签发证书（在master01节点上操作）

kubectl get csr

#通过csr请求
kubectl certificate approve NAME

#再次查看CSR请求状态，Approved，issued表示已授权CSR请求并签发证书
kubectl get csr

#查看群集节点状态，成功加入node01节点
kubectl get nodes

6.12、node01自动生成证书和kubelet.kubeconfig文件

ls /opt/kubernetes/cfg/kubelet.kubeconfig 
ls /opt/kubernetes/ssl

6.12、加载ip_vs模块（在node01节点上操作）

for i in $(ls /usr/lib/modules/$(uname -r)/kernel/net/netfilter/ipvs|grep -o "^[^.]*");do echo $i; /sbin/modinfo -F filename $i > /dev/null 2>&1 && /sbin/modprobe $i;done

6.13、使用proxy.sh脚本启动proxy服务

cd /opt
chmod +x proxy.sh 
./proxy.sh 192.168.80.13
systemctl status kube-proxy.service

6.14、node02节点部署

方法一

在node01节点上将kubelet.sh、proxy.sh文件拷贝到node02节点

cd /opt/
scp kubelet.sh proxy.sh root@192.168.80.13:`pwd`

使用kubelet.sh脚本启动kubelet服务

cd /opt
chmod +x kubelet.sh
./kubelet.sh 192.168.80.13

检查到node02节点的kublet发起的csr请求，pending表示等待集群给该节点签发证书

kubectl get csr

通过csr请求（master01上操作）

kubectl certificate approve NAME

再次查看CSR请求状态，Approved，issued表示已授权CSR请求并签发证书（master01上操作）

kubectl get csr

查看群集节点状态，成功加入node01节点（master01上操作）

kubectl get nodes

加载ip_vs模块（node02上操作）

for i in $(ls /usr/lib/modules/$(uname -r)/kernel/net/netfilter/ipvs|grep -o "^[^.]*");do echo $i; /sbin/modinfo -F filename $i > /dev/null 2>&1 && /sbin/modprobe $i;done

使用proxy.sh脚本启动proxy服务

cd /opt
chmod +x proxy.sh 
./proxy.sh 192.168.80.13
systemctl status kube-proxy.service

方法二

在node01节点操作

把现成的/opt/kubernetes目录和Kubelet、kube-proxy的service服务管理文件复制到其他节点
scp -r /opt/kubernetes/ root:192.168.80.13:/opt/
scp /usr/lib/systemd/system/{kubelet,kube-proxy}.service root@192.168.80.13:/usr/lib/systemd/system/

在node02节点操作

cd /opt/kubernetes/ssl/
rm -rf *
#修改配置文件kubelet、kubelet.config、kube-proxy的相关IP地址配置为当前节点的IP地址

加载ipvs模块

modeprobe ip_vs

启动kubelet和kube-proxy服务并设置开机自启

systemctl enable --now kubelet.service
systemctl enable --now kube-proxy.service

在master01操作

#查看CSR申请
kubectl get csr
#通过CSR申请
kubectl certificate approve NAME

6.15、 K8S单节点测试

#master01
kubectl create deployment nginx-test --image=nginx:1.14
kubectl get pod
kubectl get pod

#查看pod详情
kubectl describe pod nginx-

#查看pod额外信息（包括IP）
kubectl get pod -o wide

#使用任意node节点访问pod测试
curl 172.17.54.3

免责声明！

本站转载的文章为个人学习借鉴使用，本站对版权不负任何法律责任。如果侵犯了您的隐私权益，请联系本站邮箱yoyou2525@163.com删除。

猜您在找 K8S(四)——部署master节点服务 K8s集群部署（二）------ Master节点部署【k8s部署】5. 部署 master 节点 k8s多节点master部署（负载均衡+keepalived） k8s单节点部署（master ，node部分）【K8S】基于单Master节点安装K8S集群二进制部署1.23.4版本k8s集群-5-部署Master节点服务 kubeadm 之k8s 多master 部署 Kubernetes1.91（K8s）安装部署过程（四）--Master节点安装 k8s集群安装学习笔记十——Kubernetes高可用安装部署(3个master节点)