目录
引言
二进制部署安装kubernetes是对每一个新手，非常具有挑战性的工作，二进制部署需要了解数据流向以及繁琐的操作，一不小心就得推到重来，本章就带领新手小白，逐步进行搭建
一、常见的K8S按照部署方式
（一）Minikube
Minikube是一个工具，可以在本地快速运行一个单节点微型K8S，仅用于学习、预览K8S的一些特性使用。
部署地址：Install Tools | Kubernetes
（二）Kubeadmin
Kubeadmin也是一个工具，提供kubeadm init和kubeadm join，用于快速部署K8S集群，相对简单。
（三）二进制安装部署
生产首选，从官方下载发行版的二进制包，手动部署每个组件和自签TLS证书，组成K8S集群，新手推荐。
Releases · kubernetes/kubernetes · GitHub
二、二进制安装
（一）环境准备
| IP地址 | 主机名 | 安装组件 | 运行内存 |
| 192.168.83.30 | master01 | kube-apiserver kube-controller-manager kube-scheduler etcd集群节点1 | 4G |
| 192.168.83.40 | master01 | kubelet kube-proxy docker | 4G |
| 192.168.83.50 | node01 | kubelet kube-proxy docker etcd集群节点2 Dashboard CoreDNS flannel | 4G |
| 192.168.83.60 | node02 | kubelet kube-proxy docker etcd集群节点3 Dashboard CoreDNS flannel | 4G |
| 192.168.83.70 | nginx01 | nginx-1.18.0 keepalived | 2G |
| 192.168.83.80 | nginx02 | nginx-1.18.0 keepalived | 2G |
| 192.168.83.200 | VIP |
1.部署安装环境
所有机器操作
1.1 关闭防火墙与selinux
[root@master01 ~]#systemctl stop firewalld.service
[root@master01 ~]#systemctl disable firewalld.service
[root@master01 ~]#setenforce 0
[root@master01 ~]#iptables -F && iptables -t nat -F && iptables -t mangle -F && iptables -X
#清空防火墙规则1.2 关闭swap分区
# 临时关闭，重启恢复
[root@master01 ~]# swapoff -a
# 永久关闭
root@master01 ~]#echo vm.swappiness = 0 >> /etc/sysctl.conf
[root@master01 ~]# sysctl -p
#注释分区挂载信息
[root@master01 ~]sed -ri 's/.*swap.*/#&/' /etc/fstab
1.3 部署docker引擎
在所有node节点服务器上安装docker
[root@node01 ~]#yum install -y yum-utils device-mapper-persistent-data lvm2
#获取安装工具
[root@node01 ~]#yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
#获取aliyun的docker下载源
[root@node01 ~]#yum install -y docker-ce docker-ce-cli containerd.io
#下载docker最新版本，可以指定下载版本，如docker-ce-20.10.18
[root@node01 ~]#systemctl start docker.service
[root@node01 ~]#systemctl enable docker.service
#启动服务，并设置开机自启1.4 调整内核参数
[root@master01 ~]#cat /etc/sysctl.d/k8s.conf
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv6.conf.all.disable_ipv6=1
net.ipv4.ip_forward=1
[root@master01 ~]#sysctl --system
net.bridge.bridge-nf-call-ip6tables = 1
#当数据包通过网桥时，应该调用ip6tables（IPv6的防火墙规则）来处理这些数据包。
#如果设置为0，则ip6tables规则不会被应用到通过网桥的数据包上。
net.bridge.bridge-nf-call-iptables = 1
#与ip6tables类似，但这个参数是关于IPv4的
#它告诉内核，当数据包通过网桥时，应该调用iptables（IPv4的防火墙规则）来处理这些数据包。
#如果设置为0，则iptables规则不会被应用到通过网桥的数据包上。
net.ipv6.conf.all.disable_ipv6=1
#这个参数用于全局禁用IPv6。设置为1意味着所有的网络接口都不会启用IPv6。
#1.24之前不支持ipv6，1.24版本之后支持ipv6
net.ipv4.ip_forward=1
#开启路由转发。这个参数允许Linux系统转发IPv4数据包。
#sysctl --system
运行sysctl --system或重启系统来应用更改。
1.5 进行时间同步
[root@master01 ~]#yum install ntpdate -y
[root@master01 ~]#ntpdate time.windows.com #时间同步1.6 添加地址解析信息
[root@master01 ~]#cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.83.30 master01
192.168.83.50 node01
192.168.83.60 node02（二）搭建ETCD集群
部署ETCD集群可以提供服务发现和配置管理、高可用性、键值存储、监控和告警、分布式锁和同步、容器编排和集群管理以及安全性等方面的功能，为分布式系统提供强大的支持和保障
环境准备
| IP地址 | 主机名 | 安装组件 | 运行内存 |
| 192.168.83.30 | master01 | etcd集群节点1 | 4G |
| 192.168.83.50 | node01 | etcd集群节点2 | 4G |
| 192.168.83.60 | node02 | etcd集群节点3 | 4G |
etcd集群是一个为高可用、持久化数据存储和检索而设计的系统。etcd的名字来源于Unix的“/etc”文件夹和分布式系统"d"istributed的组合。etcd集群主要由多个etcd实例（Member）构成，这些实例可以协同工作，并通过Raft算法实现数据的一致性。
1.master01节点操作
1.1 添加解析信息
1.2 准备签发证书工具
下载地址：GitHub - cloudflare/cfssl: CFSSL: Cloudflare's PKI and TLS toolkit
[root@master01 data]#ls
cfssl cfssl-certinfo cfssljson
[root@master01 data]#chmod +x cfssl*
#添加执行权限
[root@master01 data]#ls
cfssl cfssl-certinfo cfssljson
[root@master01 data]#mv cfssl* /usr/local/bin
#移动到系统环境变量目录下，便于直接执行
[root@master01 data]#ls /usr/local/bin
cfssl cfssl-certinfo cfssljson
1.3 生成ETCD证书
[root@master01 ~]#mkdir /opt/k8s/etcd-cert #建立k8s工作目录
[root@master01 ~]#cd /opt/k8s/
[root@master01 k8s]#ls
etcd-cert.sh #上传生成证书的脚本文件
[root@master01 k8s]#chmod +x etcd-cert.sh #添加执行权限
[root@master01 k8s]#mkdir /opt/k8s/etcd-cert #建立证书存放目录
etcd-cert etcd-cert.sh
[root@master01 k8s]#mv etcd-cert.sh ./etcd-cert/ #将生成证书脚本，存放在etcd-cert目录中etcd-cert.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：可以定义多个文件，分别指定不同的过期时间、使用场景等参数；
#signing：表示该证书可用于签名其它证书；生成的 ca.pem 证书中 CA=TRUE；
#default: 这是一个对象，它定义了默认的签名配置
#expiry：指定了证书的有效期，87600h 为10年，如果用默认值一年的话，证书到期后集群会立即宕掉
#后续在签名证书时会使用某个 profile；此实例只有一个 www 模板。
#usages: 这是一个数组，定义了证书的预期用途
#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.83.30",
"192.168.83.50",
"192.168.83.60"
],
"key": {
"algo": "rsa",
"size": 2048
},
"names": [
{
"C": "CN",
"L": "BeiJing",
"ST": "BeiJing"
}
]
}
EOF
#hosts：将所有 etcd 集群节点添加到 host 列表，需要指定所有 etcd 集群的节点 ip 或主机名
#不能使用网段，新增 etcd 服务器需要重新签发证书。
#注意更改IP地址
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生成证书
[root@master01 k8s]#cd etcd-cert/
[root@master01 etcd-cert]#ls
etcd-cert.sh
[root@master01 etcd-cert]#./etcd-cert.sh
2024/05/13 15:46:43 [INFO] generating a new CA key and certificate from CSR
2024/05/13 15:46:43 [INFO] generate received request
......
[root@master01 etcd-cert]#ls
ca-config.json ca-csr.json ca.pem server.csr server-key.pem
ca.csr ca-key.pem etcd-cert.sh server-csr.json server.pem| ca-config.json | 这是一个JSON文件，包含了证书颁发机构（CA）的配置信息，比如证书的有效期、用途等。它用于指导如何生成和签名证书。 |
| ca-csr.json | 这是一个证书签名请求（CSR）的JSON模板，用于生成CA的证书签名请求。它包含了需要被包含在证书中的信息，如组织名称、通用名称等。 |
| ca.pem | 这是CA的公钥证书。它用于验证由该CA签名的其他证书的有效性。 |
| ca.csr | 这是CA的证书签名请求（CSR）。它包含了需要被包含在CA证书中的信息，并且被发送到证书颁发机构（在这里是自己）进行签名。 |
| ca-key.pem | 这是CA的私钥。它用于签名其他证书，并且应该被严格保护，以防止未经授权的访问。 |
| server-csr.json | 这是etcd服务器证书的CSR模板。它包含了需要被包含在服务器证书中的信息，如服务器的主机名或IP地址。 |
| server.csr | 这是etcd服务器的证书签名请求（CSR）。它包含了需要被包含在服务器证书中的信息，并且被发送到证书颁发机构（在这里是CA）进行签名。 |
| server-key.pem | 这是etcd服务器的私钥。它用于在TLS/SSL握手过程中与客户端进行通信，并且应该被严格保护。 |
| server.pem | 这是etcd服务器的公钥证书。它用于在TLS/SSL握手过程中验证服务器的身份，并且可以被客户端用来加密发送到服务器的数据。 |
1.4 安装、启动etcd
1.4.1 上传etcd数据包
数据包下载地址：
https://github.com/etcd-io/etcd/releases/download/v3.4.9/etcd-v3.4.9-linux-amd64.tar.gz
[root@master01 ~]#cd /opt/k8s/
[root@master01 k8s]#ls
etcd-cert etcd.sh etcd-v3.4.9-linux-amd64.tar.gz
[root@master01 k8s]#tar xf etcd-v3.4.9-linux-amd64.tar.gz
[root@master01 k8s]#ls
etcd-cert etcd.sh etcd-v3.4.9-linux-amd64 etcd-v3.4.9-linux-amd64.tar.gz
[root@master01 k8s]#cd etcd-v3.4.9-linux-amd64/
[root@master01 etcd-v3.4.9-linux-amd64]#ls
Documentation etcd etcdctl README-etcdctl.md README.md READMEv2-etcdctl.md
[root@master01 etcd-v3.4.9-linux-amd64]#
-------------------------------------------------------------------------------
#该数据包主要提供两个文件
#etcd： etcd服务的启动命令，后面可跟各种启动参数
#etcdctl 主要为etcd服务提供了命令行操作1.4.2 创建工作目录
创建用于存放 etcd 配置文件，命令文件，证书的目录
[root@master01 k8s]#mkdir -p /opt/etcd/{cfg,bin,ssl}
#创建etcd工作目录
[root@master01 k8s]#cd /opt/k8s/etcd-v3.4.9-linux-amd64/
[root@master01 etcd-v3.4.9-linux-amd64]#ls
Documentation etcd etcdctl README-etcdctl.md README.md READMEv2-etcdctl.md
[root@master01 etcd-v3.4.9-linux-amd64]#mv etcd etcdctl /opt/etcd/bin/
#将etcd与etcdctl命令移动到/opt/etcd/bin目录下
[root@master01 etcd-v3.4.9-linux-amd64]#cp /opt/k8s/etcd-cert/*.pem /opt/etcd/ssl/
#将所有以.pem结尾的文件，也就是公、私钥证书，拷贝到/opt/etcd/ssl/目录下
[root@master01 etcd-v3.4.9-linux-amd64]#ln -s /opt/etcd/bin/* /usr/local/bin/
[root@master01 etcd-v3.4.9-linux-amd64]#tree /opt/etcd/
/opt/etcd/
├── bin
│ ├── etcd
│ └── etcdctl
├── cfg
└── ssl
├── ca-key.pem
├── ca.pem
├── server-key.pem
└── server.pem
3 directories, 6 files1.4.3 启动服务
上传或创建启动etcd脚本文件，并启动服务
[root@master01 ~]#ls /opt/k8s/etcd.sh
/opt/k8s/etcd.sh
[root@master01 k8s]#./etcd.sh etcd01 192.168.83.30 etcd02=https://192.168.83.50:2380,etcd03=https://192.168.83.60:2380
#按照脚本定义内容
#etcd01：第一个位置参数，为$1，表示节点名称，集群中唯一。集群中必须具备唯一性
#192.168.83.30：指明本节点的IP地址
etcd02=https://192.168.83.50:2380,etcd03=https://192.168.83.60:2380
#为集群中其它节点的IP地址与端口号，2380端口用于集群中的内部通信etcd脚本内容
#!/bin/bash
#example: ./etcd.sh etcd01 192.168.83.30 etcd02=https://192.168.83.50:2380,etcd03=https://192.168.83.60: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 \
--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 \
--logger=zap \
--enable-v2
Restart=on-failure
LimitNOFILE=65536
[Install]
WantedBy=multi-user.target
EOF
#--enable-v2：开启 etcd v2 API 接口。当前 flannel 版本不支持 etcd v3 通信
#--logger=zap：使用 zap 日志框架。zap.Logger 是go语言中相对日志库中性能最高的
#--peer开头的配置项用于指定集群内部TLS相关证书（peer 证书），这里全部都使用同一套证书认证
#不带--peer开头的的参数是指定 etcd 服务器TLS相关证书（server 证书），这里全部都使用同一套证书认证
systemctl daemon-reload
systemctl enable etcd
systemctl restart etcd
执行完启动文件后，打开新的终端查看状态
等待其他节点加入，这里需要三台etcd服务同时启动，如果只启动其中一台后，服务会卡在那里，直到集群中所有etcd节点都已启动，可忽略这个情况
2.node01节点操作
2.1 准备文件
把etcd相关证书文件、命令文件和服务管理文件全部拷贝到另外两个etcd集群节点，或者在另外两个etcd节点，按master01节点操作，重新生成
[root@master01 ~]#scp -r /opt/etcd/ node01:/opt/
[root@master01 ~]#scp -r /opt/etcd/ node02:/opt/
[root@master01 ~]#scp /usr/lib/systemd/system/etcd.service node01:/usr/lib/systemd/system/
[root@master01 ~]#scp /usr/lib/systemd/system/etcd.service node02:/usr/lib/systemd/system/2.2 修改配置文件
[root@node01 ~]#cat /opt/etcd/cfg/etcd
#[Member]
ETCD_NAME="etcd02" #修改集群节点名称，需要与master01节点启动etcd服务时指定名称一致
ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
ETCD_LISTEN_PEER_URLS="https://192.168.83.50:2380" #修改为本机的IP地址
ETCD_LISTEN_CLIENT_URLS="https://192.168.83.50:2379" #修改为本机的IP地址
#[Clustering]
ETCD_INITIAL_ADVERTISE_PEER_URLS="https://192.168.83.50:2380" #修改为本机的IP地址
ETCD_ADVERTISE_CLIENT_URLS="https://192.168.83.50:2379" #修改为本机的IP地址
ETCD_INITIAL_CLUSTER="etcd01=https://192.168.83.30:2380,etcd02=https://192.168.83.50:2380,etcd03=https://192.168.83.60:2380"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
ETCD_INITIAL_CLUSTER_STATE="new2.3 启动服务
[root@node01 opt]#systemctl start etcd.service #启动服务
[root@node01 opt]#systemctl enable etcd.service
3.node02节点操作
3.1 修改配置文件
[root@node02 ~]#cat /opt/etcd/cfg/etcd
#[Member]
ETCD_NAME="etcd03" #修改集群节点名称，需要与master01节点启动etcd服务时指定名称一致
ETCD_DATA_DIR="/var/lib/etcd/default.etcd"
ETCD_LISTEN_PEER_URLS="https://192.168.83.60:2380" #修改为本机的IP地址
ETCD_LISTEN_CLIENT_URLS="https://192.168.83.60:2379" #修改为本机的IP地址
#[Clustering]
ETCD_INITIAL_ADVERTISE_PEER_URLS="https://192.168.83.60:2380" #修改为本机的IP地址
ETCD_ADVERTISE_CLIENT_URLS="https://192.168.83.60:2379" #修改为本机的IP地址
ETCD_INITIAL_CLUSTER="etcd01=https://192.168.83.30:2380,etcd02=https://192.168.83.50:2380,etcd03=https://192.168.83.60:2380"
ETCD_INITIAL_CLUSTER_TOKEN="etcd-cluster"
ETCD_INITIAL_CLUSTER_STATE="new"
3.2 启动服务
[root@node02 ~]#systemctl start etcd.service
[root@node02 ~]#systemctl enable etcd.service
Created symlink from /etc/systemd/system/multi-user.target.wants/etcd.service to /usr/lib/systemd/system/etcd.service.
[root@node02 ~]#systemctl status etcd.service
4.检查集群状态
使用etcd的v3 API，通过HTTPS和双向TLS与etcd集群的三个节点通信，并检查这些节点的健康状态，然后将结果以表格格式输出
4.1 health查看状态
ETCDCTL_API=3 /opt/etcd/bin/etcdctl --cacert=/opt/etcd/ssl/ca.pem --cert=/opt/etcd/ssl/server.pem --key=/opt/etcd/ssl/server-key.pem --endpoints="https://192.168.83.30:2379,https://192.168.83.50:2379,https://192.168.83.60:2379" endpoint health --write-out=table
+----------------------------+--------+-------------+-------+
| ENDPOINT | HEALTH | TOOK | ERROR |
+----------------------------+--------+-------------+-------+
| https://192.168.83.30:2379 | true | 23.859132ms | |
| https://192.168.83.60:2379 | true | 58.692187ms | |
| https://192.168.83.50:2379 | true | 60.800843ms | |
+----------------------------+--------+-------------+-------+
--------------------------------'命令行字段'---------------------------------------
ETCDCTL_API=3
#这是一个环境变量，用于指定etcdctl应该使用etcd的v3 API。
/opt/etcd/bin/etcdctl
#这是etcdctl的完整路径。etcdctl是etcd的命令行工具，用于与etcd集群进行交互。
--cacert=/opt/etcd/ssl/ca.pem
#指定用于验证etcd服务器证书的CA（证书颁发机构）证书的路径。
--cert=/opt/etcd/ssl/server.pem
#指定客户端证书的路径。当etcd使用双向TLS认证时，客户端也需要提供证书来证明其身份。
--key=/opt/etcd/ssl/server-key.pem
#指定与客户端证书关联的私钥的路径。私钥用于解密发送到etcd服务器的消息。
--endpoints="https://192.168.83.30:2379,https://192.168.83.50:2379,https://192.168.83.60:2379"
#这个参数指定了etcd集群中节点的地址和端口。集群中以逗号分隔的机器地址列表
endpoint health
#这是etcdctl的一个子命令，用于检查etcd集群中每个节点的健康状态。
--write-out=table
#指定etcdctl命令输出的格式。它请求命令以表格格式输出结果，这通常使输出更易于阅读。
---------------------------------'输出信息字段'------------------------------------
ENDPOIN #这是etcd集群中每个成员的地址和端口。
HEALTH #表示etcd成员的健康状态。true，表示成员是健康的，false，表示成员可能存在问题。
TOOK #这是etcdctl命令与每个etcd成员建立连接并检查其健康状态所需的时间
ERROR #如果与etcd成员建立连接或检查其健康状态时发生错误，这个字段将包含错误信息4.2 status查看状态
使用endpoint status指令获取信息
[root@master01 k8s]#ETCDCTL_API=3 /opt/etcd/bin/etcdctl --cacert=/opt/etcd/ssl/ca.pem --cert=/opt/etcd/ssl/server.pem --key=/opt/etcd/ssl/server-key.pem --endpoints="https://192.168.83.30:2379,https://192.168.83.50:2379,https://192.168.83.60:2379" endpoint status --write-out=table
+----------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
| ENDPOINT | ID | VERSION | DB SIZE | IS LEADER | IS LEARNER | RAFT TERM | RAFT INDEX | RAFT APPLIED INDEX | ERRORS |
+----------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
| https://192.168.83.30:2379 | eebcdf842d133d30 | 3.4.9 | 20 kB | true | false | 1186 | 9 | 9 | |
| https://192.168.83.50:2379 | 294d7572d3227cfb | 3.4.9 | 20 kB | false | false | 1186 | 9 | 9 | |
| https://192.168.83.60:2379 | 9996739f129cb7b7 | 3.4.9 | 20 kB | false | false | 1186 | 9 | 9 | |
+----------------------------+------------------+---------+---------+-----------+------------+-----------+------------+--------------------+--------+
-----------------------------------'命令行字段'-------------------------------------
#与上述字段信息一致，上条命令使用endpoint health参数，在这里使用endpoint status
#区别在于看到信息字段略有不同
-----------------------------------'输出信息字段'----------------------------------
ENDPOINT #这是etcd集群中每个成员的地址和端口。
ID #这是etcd成员的唯一标识符。
VERSION #这是etcd成员运行的etcd版本。
DB SIZE #这是etcd成员上存储的数据库大小。
IS LEADER #表示etcd成员是否是集群的领导者。
#在一个etcd集群中，只有一个成员是领导者，它负责处理客户端的请求，并将这些请求复制到其他成员。
#在这个例子中，https://192.168.83.30:2379是领导者。
IS LEARNER #表示etcd成员是否是一个学习者节点。
#学习者节点不参与投票或提交新的日志条目，但会接收并存储来自领导者的日志条
RAFT TERM #这是Raft算法中的当前任期号。
#当领导者失去权力或出现故障时，集群会进入一个新的任期，并尝试选举一个新的领导者。
#在这个例子中，所有成员的任期号都是1186，表示它们都处于同一任期。
RAFT INDEX #这是Raft日志的当前索引号。Raft使用日志来复制和持久化状态机变更。
#在这个例子中，所有成员的日志索引都是9，这意味着它们都已经应用了9个日志条目。
RAFT APPLIED INDEX #这是已经应用到状态机的最新日志条目的索引号。
#在这个例子中，由于RAFT INDEX和RAFT APPLIED INDEX的值相同，
#这意味着所有成员都已经将最新的日志条目应用到了它们的状态机上。
ERRORS #如果与etcd成员建立连接或检查其健康状态时发生错误，这个字段将包含错误信息。
4.3 查看集群成员列表
[root@master01 k8s]#ETCDCTL_API=3 /opt/etcd/bin/etcdctl --cacert=/opt/etcd/ssl/ca.pem --cert=/opt/etcd/ssl/server.pem --key=/opt/etcd/ssl/server-key.pem --endpoints="https://192.168.83.30:2379,https://192.168.83.50:2379,https://192.168.83.60:2379" --write-out=table member list
+------------------+---------+--------+----------------------------+----------------------------+------------+
| ID | STATUS | NAME | PEER ADDRS | CLIENT ADDRS | IS LEARNER |
+------------------+---------+--------+----------------------------+----------------------------+------------+
| 294d7572d3227cfb | started | etcd02 | https://192.168.83.50:2380 | https://192.168.83.50:2379 | false |
| 9996739f129cb7b7 | started | etcd03 | https://192.168.83.60:2380 | https://192.168.83.60:2379 | false |
| eebcdf842d133d30 | started | etcd01 | https://192.168.83.30:2380 | https://192.168.83.30:2379 | false |
+------------------+---------+--------+----------------------------+----------------------------+------------+
------------------------------'命令行字段'--------------------------------
member list #用于列出集群成员信息
------------------------------'输出信息字段'------------------------------
ID #这是etcd成员的唯一标识符。
STATUS #etcd成员的状态
NAME #etcd成员的名称
PEER ADDRS #etcd成员用于与其他成员通信的对等端点地址，端口号为2380
CLIENT ADDRS #etcd成员用于与客户端通信的地址，端口号为2379
IS LEARNER #表示etcd成员是否是一个学习者节点（三）部署master组件
在master节点上操作
| IP地址 | 主机名 | 安装组件 | 运行内存 |
| 192.168.83.30 | master01 | kube-apiserver kube-controller-manager kube-scheduler etcd集群节点1 | 4G |
1.准备相关文件
上传 master.zip 和 k8s-cert.sh 到 /opt/k8s/master目录中，解压 master.zip 压缩包
[root@master01 k8s]#mkdir /opt/k8s/master
[root@master01 k8s]#cd /opt/k8s/master/
#上传文件到该目录
[root@master01 master]#ls
k8s-cert.sh master.zip
[root@master01 master]#unzip master.zip
Archive: master.zip
inflating: admin.sh
inflating: apiserver.sh
inflating: controller-manager.sh
inflating: scheduler.sh
[root@master01 master]#ls
admin.sh apiserver.sh controller-manager.sh k8s-cert.sh master.zip scheduler.sh
[root@master01 master]#chmod +x ./*.sh #给所有脚本文件添加执行权限
[root@master01 master]#mkdir -p /opt/kubernetes/{bin,cfg,ssl,logs}
#创建k8s工作目录2.生成证书、公私钥
[root@master01 master]#mkdir /opt/k8s/master/k8s-cert
#创建证书存放目录
[root@master01 master]#ls
admin.sh apiserver.sh controller-manager.sh k8s-cert.sh master.zip scheduler.sh
[root@master01 master]#mv ./k8s-cert.sh /opt/k8s/master/k8s-cert/
#将生成证书脚本文件移动到新建目录
[root@master01 master]#cd /opt/k8s/master/k8s-cert
[root@master01 k8s-cert]#ls
k8s-cert.sh
[root@master01 k8s-cert]#./k8s-cert.sh #执行脚本生成证书、公私钥等文件
[root@master01 k8s-cert]#ls
admin.csr admin.pem apiserver-key.pem ca.csr ca.pem kube-proxy-csr.json
admin-csr.json apiserver.csr apiserver.pem ca-csr.json k8s-cert.sh kube-proxy-key.pem
admin-key.pem apiserver-csr.json ca-config.json ca-key.pem kube-proxy.csr kube-proxy.pem
2.1 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.83.30", #master01
"192.168.83.40", #master02
"192.168.83.200", #vip，后面 keepalived 使用
"192.168.83.70", #load balancer01（master）
"192.168.83.80", #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复制CA证书、apiserver相关证书和私钥到 kubernetes工作目录的 ssl 子目录中
[root@master01 k8s-cert]#cp ca*pem apiserver*pem /opt/kubernetes/ssl/
[root@master01 k8s-cert]#ls /opt/kubernetes/ssl/
apiserver-key.pem apiserver.pem ca-key.pem ca.pem
3.安装master组件
上传 kubernetes-server-linux-amd64.tar.gz 到 /opt/k8s/ 目录中，解压 kubernetes 压缩包
下载地址：
kubernetes/CHANGELOG/CHANGELOG-1.20.md at release-1.20 · kubernetes/kubernetes · GitHub
注释：打开链接你会发现里面有很多包，下载一个server包就够了，包含了Master和Worker Node二进制文件。
3.1 准备组件文件
[root@master01 k8s]#ls kubernetes-server-linux-amd64.tar.gz
kubernetes-server-linux-amd64.tar.gz
[root@master01 k8s]#tar xf kubernetes-server-linux-amd64.tar.gz
#解压源码包
[root@master01 k8s]#ls
etcd-cert etcd-v3.4.9-linux-amd64 kubernetes master
etcd.sh etcd-v3.4.9-linux-amd64.tar.gz kubernetes-server-linux-amd64.tar.gz
[root@master01 k8s]#cd kubernetes/server/bin/
[root@master01 bin]#ls
apiextensions-apiserver kube-apiserver.tar kubelet kube-scheduler.docker_tag
kubeadm kube-controller-manager kube-proxy kube-scheduler.tar
kube-aggregator kube-controller-manager.docker_tag kube-proxy.docker_tag mounter
kube-apiserver kube-controller-manager.tar kube-proxy.tar
kube-apiserver.docker_tag kubectl kube-scheduler
[root@master01 bin]#cp kube-apiserver kubectl kube-controller-manager kube-scheduler /opt/kubernetes/bin/
#复制master组件的关键命令文件到 kubernetes工作目录的 bin 子目录中
[root@master01 bin]#ln -s /opt/kubernetes/bin/* /usr/local/bin/
#做软链接到环境变量目录下3.2 创建token认证
创建 bootstrap token 认证文件，apiserver 启动时会调用，然后就相当于在集群内创建了一个这个用户，接下来就可以用 RBAC 给他授权
[root@master01 k8s]#vim /opt/k8s/token.sh
[root@master01 k8s]#cat /opt/k8s/token.sh
#!/bin/bash
#获取随机数前16个字节内容，以十六进制格式输出，并删除其中空格
BOOTSTRAP_TOKEN=$(head -c 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
[root@master01 k8s]#chmod +x /opt/k8s/token.sh #添加执行权限
[root@master01 k8s]#./token.sh
#执行文件，生成token令牌信息文件
[root@master01 k8s]#cat /opt/kubernetes/cfg/token.csv
3d7228570fe59540e11343be2d03f17a,kubelet-bootstrap,10001,"system:kubelet-bootstrap"
#查看文件信息
#3d7228570fe59540e11343be2d03f17a：16进制序列号
#kubelet-bootstrap：用户名
#10001：UID号
#system:kubelet-bootstrap：用户组4.启动服务
4.1 启动apiserver服务
4.1.1 查看apiserver启动文件
#!/bin/bash
#example: apiserver.sh 192.168.83.30 https://192.168.83.30:2379,https://192.168.83.50:2379,https://192.168.83.60:2379
#创建 kube-apiserver 启动参数配置文件
MASTER_ADDRESS=$1
ETCD_SERVERS=$2
cat >/opt/kubernetes/cfg/kube-apiserver <<EOF
KUBE_APISERVER_OPTS="--logtostderr=false \\
--v=2 \\
--log-dir=/opt/kubernetes/logs \\
--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 \\
--enable-bootstrap-token-auth=true \\
--token-auth-file=/opt/kubernetes/cfg/token.csv \\
--service-node-port-range=30000-50000 \\
--kubelet-client-certificate=/opt/kubernetes/ssl/apiserver.pem \\
--kubelet-client-key=/opt/kubernetes/ssl/apiserver-key.pem \\
--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 \\
--service-account-issuer=api \\
--service-account-signing-key-file=/opt/kubernetes/ssl/apiserver-key.pem \\
--etcd-cafile=/opt/etcd/ssl/ca.pem \\
--etcd-certfile=/opt/etcd/ssl/server.pem \\
--etcd-keyfile=/opt/etcd/ssl/server-key.pem \\
--requestheader-client-ca-file=/opt/kubernetes/ssl/ca.pem \\
--proxy-client-cert-file=/opt/kubernetes/ssl/apiserver.pem \\
--proxy-client-key-file=/opt/kubernetes/ssl/apiserver-key.pem \\
--requestheader-allowed-names=kubernetes \\
--requestheader-extra-headers-prefix=X-Remote-Extra- \\
--requestheader-group-headers=X-Remote-Group \\
--requestheader-username-headers=X-Remote-User \\
--enable-aggregator-routing=true \\
--audit-log-maxage=30 \\
--audit-log-maxbackup=3 \\
--audit-log-maxsize=100 \\
--audit-log-path=/opt/kubernetes/logs/k8s-audit.log"
EOF
#--logtostderr=true：启用日志。输出日志到标准错误控制台，不输出到文件
#--v=4：日志等级。指定输出日志的级别，v=4为调试级别详细输出
#--etcd-servers：etcd集群地址。指定etcd服务器列表（格式：//ip:port），逗号分隔
#--bind-address：监听地址。指定 HTTPS 安全接口的监听地址，默认值0.0.0.0
#--secure-port：https安全端口。指定 HTTPS 安全接口的监听端口，默认值6443
#--advertise-address：集群通告地址。通过该 ip 地址向集群其他节点公布 api server 的信息，必须能够被其他节点访问
#--allow-privileged=true：启用授权。允许拥有系统特权的容器运行，默认值false
#--service-cluster-ip-range：Service虚拟IP地址段。指定 Service Cluster IP 地址段
#--enable-admission-plugins：准入控制模块。kuberneres集群的准入控制机制，各控制模块以插件的形式依次生效，集群时必须包含ServiceAccount，运行在认证（Authentication）、授权（Authorization）之后，Admission Control是权限认证链上的最后一环， 对请求API资源对象进行修改和校验
#--authorization-mode：认证授权，启用RBAC授权和节点自管理。在安全端口使用RBAC,Node授权模式，未通过授权的请求拒绝，默认值AlwaysAllow。RBAC是用户通过角色与权限进行关联的模式；Node模式（节点授权）是一种特殊用途的授权模式，专门授权由kubelet发出的API请求，在进行认证时，先通过用户名、用户分组验证是否是集群中的Node节点，>只有是Node节点的请求才能使用Node模式授权
#--enable-bootstrap-token-auth：启用TLS bootstrap机制。在apiserver上启用Bootstrap Token 认证
#--token-auth-file=/opt/kubernetes/cfg/token.csv：指定bootstrap token认证文件路径
#--service-node-port-range：指定 Service NodePort 的端口范围，默认值30000-32767
#–-kubelet-client-xxx：apiserver访问kubelet客户端证书
#--tls-xxx-file：apiserver https证书
#1.20版本必须加的参数：–-service-account-issuer，–-service-account-signing-key-file
#--etcd-xxxfile：连接Etcd集群证书
#–-audit-log-xxx：审计日志
#启动聚合层相关配置：–requestheader-client-ca-file，–proxy-client-cert-file，–proxy-client-key-file，–requestheader-allowed-names，–requestheader-extra-headers-prefix，–requestheader-group-headers，–requestheader-username-headers，–enable-aggregator-routing
#创建 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
4.1.2 启动服务
[root@master01 master]#./apiserver.sh 192.168.83.30 https://192.168.83.30:2379,https://192.168.83.50:2379,https://192.168.83.60:2379
./apiserver.sh #执行脚本
192.168.83.30 #第一个位置参数，为kube-apiserver的绑定地址和广告地址
https://192.168.83.30:2379,https://192.168.30.50:2379,https://192.168.83.60:2379
#第二个位置变量，以逗号分隔的etcd集群地址列表。4.1.3 查看启动状态
4.2 启动scheduler服务
4.2.1 查看scheduler启动文件
#!/bin/bash
##创建 kube-scheduler 启动参数配置文件
MASTER_ADDRESS=$1
cat >/opt/kubernetes/cfg/kube-scheduler <<EOF
KUBE_SCHEDULER_OPTS="--logtostderr=false \\
--v=2 \\
--log-dir=/opt/kubernetes/logs \\
--leader-elect=true \\
--kubeconfig=/opt/kubernetes/cfg/kube-scheduler.kubeconfig \\
--bind-address=127.0.0.1"
EOF
#KUBE_SCHEDULER_OPTS 是一个环境变量，它包含了kube-scheduler启动时需要使用的参数。
#--logtostderr=false：不将日志输出到标准错误输出，而是将其发送到指定的日志文件。
#--v=2：设置日志级别为 2，以获取更详细的日志输出
#--log-dir=/opt/kubernetes/logs：指定日志文件的目录。
#--leader-elect=true：启用 leader 选举功能。
#在高可用性的设置中，如果有多个 kube-scheduler 实例在运行，
#此选项允许它们通过选举来确保只有一个实例处于活动状态，而其他实例则处于备用状态
#--kubeconfig=/opt/kubernetes/cfg/kube-scheduler.kubeconfig
#指定 kube-scheduler 使用的 kubeconfig 文件的路径。
#kubeconfig 文件包含了与 API 服务器通信所需的凭据和配置信息。
#-bind-address=127.0.0.1：指定 kube-scheduler 绑定的 IP 地址。
#在这里，它被设置为 127.0.0.1，意味着 kube-scheduler 只监听本地主机的连接请求
##生成kube-scheduler证书
cd /opt/k8s/master/k8s-cert/
#创建证书请求文件
cat > kube-scheduler-csr.json << EOF
{
"CN": "system:kube-scheduler",
"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 kube-scheduler-csr.json | cfssljson -bare kube-scheduler
#生成kubeconfig文件
KUBE_CONFIG="/opt/kubernetes/cfg/kube-scheduler.kubeconfig"
#生成的配置文件存放路径
KUBE_APISERVER="https://192.168.83.30:6443"
#指定本机的apiserver的IP地址与端口号
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 kube-scheduler \
--client-certificate=./kube-scheduler.pem \
--client-key=./kube-scheduler-key.pem \
--embed-certs=true \
--kubeconfig=${KUBE_CONFIG}
kubectl config set-context default \
--cluster=kubernetes \
--user=kube-scheduler \
--kubeconfig=${KUBE_CONFIG}
kubectl config use-context default --kubeconfig=${KUBE_CONFIG}
##创建 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
知识扩展
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 进入工作状态即可，而无需考虑它们之间的数据一致和同步
4.2.2 启动服务
[root@master01 master]#./scheduler.sh
.........
[root@master01 master]#ps aux | grep kube-scheduler
#查看进程状态
root 43585 17.7 0.6 748468 24920 ? Ssl 18:46 0:02 /opt/kubernetes/bin/kube-scheduler --logtostderr=false --v=2 --log-dir=/opt/kubernetes/logs --leader-elect=true --kubeconfig=/opt/kubernetes/cfg/kube-scheduler.kubeconfig --bind-address=127.0.0.1
4.3 启动controller-manager服务
4.3.1 查看controller-manager启动文件
#!/bin/bash
##创建 kube-controller-manager 启动参数配置文件
MASTER_ADDRESS=$1
cat >/opt/kubernetes/cfg/kube-controller-manager <<EOF
KUBE_CONTROLLER_MANAGER_OPTS="--logtostderr=false \\
--v=2 \\
--log-dir=/opt/kubernetes/logs \\
--leader-elect=true \\
--kubeconfig=/opt/kubernetes/cfg/kube-controller-manager.kubeconfig \\
--bind-address=127.0.0.1 \\
--allocate-node-cidrs=true \\
--cluster-cidr=10.244.0.0/16 \\
--service-cluster-ip-range=10.0.0.0/24 \\
--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 \\
--cluster-signing-duration=87600h0m0s"
EOF
#––leader-elect：当该组件启动多个时，自动选举（HA）
#-–kubeconfig：连接 apiserver 用的配置文件，用于识别 k8s 集群
#--cluster-cidr=10.244.0.0/16：pod资源的网段，需与pod网络插件的值设置一致。通常，Flannel网络插件的默认为10.244.0.0/16，Calico插件的默认值为192.168.0.0/16
#--cluster-signing-cert-file/–-cluster-signing-key-file：自动为kubelet颁发证书的CA，与apiserver保持一致。指定签名的CA机构根证书，用来签名为 TLS BootStrapping 创建的证书和私钥
#--root-ca-file：指定根CA证书文件路径，用来对 kube-apiserver 证书进行校验，指定该参数后，才会在 Pod 容器的 ServiceAccount 中放置该 CA 证书文件
#--experimental-cluster-signing-duration：设置为 TLS BootStrapping 签署的证书有效时间为10年，默认为1年
##生成kube-controller-manager证书
cd /opt/k8s/master/k8s-cert/
#创建证书请求文件，确认好路径位置
cat > kube-controller-manager-csr.json << EOF
{
"CN": "system:kube-controller-manager",
"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 kube-controller-manager-csr.json | cfssljson -bare kube-controller-manager
#生成kubeconfig文件
KUBE_CONFIG="/opt/kubernetes/cfg/kube-controller-manager.kubeconfig"
KUBE_APISERVER="https://192.168.83.30:6443"
#设置apiserver服务地址与端口号
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 kube-controller-manager \
--client-certificate=./kube-controller-manager.pem \
--client-key=./kube-controller-manager-key.pem \
--embed-certs=true \
--kubeconfig=${KUBE_CONFIG}
kubectl config set-context default \
--cluster=kubernetes \
--user=kube-controller-manager \
--kubeconfig=${KUBE_CONFIG}
kubectl config use-context default --kubeconfig=${KUBE_CONFIG}
##创建 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
4.3.2 启动服务
[root@master01 master]#./controller-manager.sh
2024/05/13 18:59:56 [INFO] generate received request
2024/05/13 18:59:56 [INFO] received CSR
......4.3.3 查看启动状态
4.4 生成连接集群文件
生成kubectl连接集群的kubeconfig文件，即bootstrap.kubeconfig文件
该文件中内置了 token.csv 中用户的 Token，以及 apiserver CA 证书；kubelet 首次启动会加载此文件，使用 apiserver CA 证书建立与 apiserver 的 TLS 通讯，使用其中的用户 Token 作为身份标识向 apiserver 发起 CSR 请求
生成kubectl连接集群的kubeconfig文件
4.1.1 查看admin.sh脚本文件
#!/bin/bash
mkdir /root/.kube
#建立配置文件路径
KUBE_CONFIG="/root/.kube/config"
KUBE_APISERVER="https://192.168.83.30:6443"
cd /opt/k8s/master/k8s-cert/
#使用kubelet命令，指定集群的CA证书文件位置以及配置文件存放位置
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}
4.1.2 执行脚本
[root@master01 master]#./admin.sh4.1.3 查看当前集群组件状态
通过kubectl工具查看当前集群组件状态
[root@master01 master]#kubectl get cs
Warning: v1 ComponentStatus is deprecated in v1.19+
NAME STATUS MESSAGE ERROR
controller-manager Healthy ok
scheduler Healthy ok
etcd-0 Healthy {"health":"true"}
etcd-2 Healthy {"health":"true"}
etcd-1 Healthy {"health":"true"} （四）部署node组件
| IP地址 | 主机名 | 安装组件 | 运行内存 |
| 192.168.83.50 | node01 | kubelet kube-proxy docker etcd集群节点2 | 4G |
1.准备文件
1.1 准备kubelet.sh与proxy.sh脚本文件
用户执行kubelet进程与kube-proxy代理
在所有node节点上进行操作
[root@node01 opt]#mkdir -p /opt/kubernetes/{bin,cfg,ssl,logs}
#创建kubernetes工作目录
[root@node01 opt]#cd /opt
[root@node01 opt]#ls *.sh
kubelet.sh proxy.sh
[root@node01 opt]#chmod +x *.sh[root@node02 opt]#mkdir -p /opt/kubernetes/{bin,cfg,ssl,logs}
#创建kubernetes工作目录
[root@node02 opt]#cd /opt
[root@node02 opt]#ls *.sh
kubelet.sh proxy.sh
[root@node02 opt]#chmod +x *.sh1.2 准备kubelet与kube-proxy执行文件
可从官网下载的kubernetes-server-linux-amd64.tar.gz包中获取，或者直接从master服务器上拷贝
[root@master01 ~]#cd /opt/k8s/kubernetes/server/bin
[root@master01 ~]#scp kubelet kube-proxy node01:/opt/kubernetes/bin/
[root@master01 ~]#scp kubelet kube-proxy node02:/opt/kubernetes/bin/
1.3 准备kubeconfig.sh脚本文件
在master01节点上进行操作
上传kubeconfig.sh文件到master01节点上/opt/k8s/kubeconfig目录中，生成kubelet初次加入集群引导kubeconfig文件和kube-proxy.kubeconfig文件
kubeconfig 文件包含集群参数（CA 证书、API Server 地址），客户端参数（上面生成的证书和私钥），集群 context 上下文参数（集群名称、用户名）。Kubenetes 组件（如 kubelet、kube-proxy）通过启动时指定不同的 kubeconfig 文件可以切换到不同的集群，连接到 apiserver。
[root@master01 opt]#mkdir /opt/k8s/kubeconfig
[root@master01 opt]#cd /opt/k8s/kubeconfig
[root@master01 kubeconfig]#ls
kubeconfig.sh
[root@master01 kubeconfig]#chmod +x kubeconfig.shkubeconfig.sh文件内容
#!/bin/bash
#example: kubeconfig 192.168.83.30 /opt/k8s/master/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
将生成的kubelet初次加入集群引导kubeconfig文件(即bootstrap.kubeconfig)和kube-proxy.kubeconfig文件远程拷贝的node节点上
[root@master01 kubeconfig]#./kubeconfig.sh 192.168.83.30 /opt/k8s/master/k8s-cert/
......
#生成配置文件
[root@master01 kubeconfig]#ls
bootstrap.kubeconfig kubeconfig.sh kube-proxy.kubeconfig
[root@master01 kubeconfig]#scp bootstrap.kubeconfig kube-proxy.kubeconfig node01:/opt/kubernetes/cfg/
[root@master01 kubeconfig]#scp bootstrap.kubeconfig kube-proxy.kubeconfig node02:/opt/kubernetes/cfg/
#将生成的配置文件远程拷贝到node节点上2.用户授权
在master01节点上进行用户授权
RBAC授权，使用户 kubelet-bootstrap 能够有权限发起 CSR 请求证书
[root@master01 ~]#kubectl create clusterrolebinding kubelet-bootstrap --clusterrole=system:node-bootstrapper --user=kubelet-bootstrap
clusterrolebinding.rbac.authorization.k8s.io/kubelet-bootstrap created
kubectl create clusterrolebinding
#使用kubectl命令行工具来创建一个新的ClusterRoleBinding。
kubelet-bootstrap
#给这个ClusterRoleBinding起的名字。
--clusterrole=system:node-bootstrapper
#指定了要绑定的ClusterRole的名称。
#这个ClusterRole通常用于允许kubelet节点在加入集群时执行必要的引导操作。
--user=kubelet-bootstrap
#这指定了要绑定的用户。
#当kubelet尝试以kubelet-bootstrap用户的身份连接到API服务器时，API服务器会检查是否有ClusterRoleBinding允许该用户执行必要的操作。
#若上述命令执行失败，可先给kubectl绑定默认cluster-admin管理员集群角色，授权集群操作权限
kubectl create clusterrolebinding cluster-system-anonymous --clusterrole=cluster-admin --user=system:anonymous注释信息：
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 生成一个证书，以后的访问都是用证书做认证了。
3.启动kubelet服务
在node01节点上进行操作
3.1 查看启动文件
kubelet.sh文件内容
#!/bin/bash
NODE_ADDRESS=$1
DNS_SERVER_IP=${2:-"10.0.0.2"}
#-表示判断。
#如果 $2 已设置并且非空，则返回 $2 的值。
#如果 $2 未设置或为空，则返回 "10.0.0.2"。
#创建 kubelet 启动参数配置文件
cat >/opt/kubernetes/cfg/kubelet <<EOF
KUBELET_OPTS="--logtostderr=false \\
--v=2 \\
--log-dir=/opt/kubernetes/logs \\
--hostname-override=${NODE_ADDRESS} \\
--network-plugin=cni \\
--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的此项参数设置必须完全一致
#--network-plugin：启用CNI
#--kubeconfig：指定kubelet.kubeconfig文件位置，当前为空路径，会自动生成，用于如何连接到apiserver，里面含有kubelet证书，master授权完成后会在node节点上生成 kubelet.kubeconfig 文件
#--bootstrap-kubeconfig：指定连接 apiserver 的 bootstrap.kubeconfig 文件
#--config：指定kubelet配置文件的路径，启动kubelet时将从此文件加载其配置
#--cert-dir：指定master颁发的kubelet证书生成目录
#--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
3.2 启动服务
[root@node01 opt]#./kubelet.sh 192.168.83.50
Created symlink from /etc/systemd/system/multi-user.target.wants/kubelet.service to /usr/lib/systemd/system/kubelet.service.3.3 通过CSR请求
在master01节点上操作
检查到 node01 节点的 kubelet 发起的 CSR 请求，Pending 表示等待集群给该节点签发证书
[root@master01 ~]#kubectl get csr
NAME AGE SIGNERNAME REQUESTOR CONDITION
node-csr-Cg2PqUevBe5PZcsPOxNEH6td7hsKjAI9ZndZKDdPKXo 73s kubernetes.io/kube-apiserver-client-kubelet kubelet-bootstrap Pending通过CSR请求
[root@master01 ~]#kubectl certificate approve node-csr-Cg2PqUevBe5PZcsPOxNEH6td7hsKjAI9ZndZKDdPKXo
#kubectl：使用kubectl命令行工具。
#certificate approve：调用certificate approve命令来批准一个CSR。
#指定了CSR的名称node-csr-Cg2PqUevBe5PZcsPOxNEH6td7hsKjAI9ZndZKDdPKXo
certificatesigningrequest.certificates.k8s.io/node-csr-Cg2PqUevBe5PZcsPOxNEH6td7hsKjAI9ZndZKDdPKXo approved使用kubectl get csr命令来检查CSR的状态是否已更新为“Approved,Issued”
Approved,Issued 表示已授权 CSR 请求并签发证书
[root@master01 ~]#kubectl get csr
NAME AGE SIGNERNAME REQUESTOR CONDITION
node-csr-Cg2PqUevBe5PZcsPOxNEH6td7hsKjAI9ZndZKDdPKXo 6m40s kubernetes.io/kube-apiserver-client-kubelet kubelet-bootstrap Approved,Issued
查看节点，由于网络插件还没有部署，节点会没有准备就绪 NotReady
[root@master01 ~]#kubectl get node
NAME STATUS ROLES AGE VERSION
192.168.83.50 NotReady <none> 7m48s v1.20.11
4.启动porxy服务
在node01节点上操作
4.1 加载ip_vs模块
[root@node01 opt]#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
ip_vs_dh
ip_vs_ftp
ip_vs
ip_vs_lblc
ip_vs_lblcr
ip_vs_lc
ip_vs_nq
ip_vs_pe_sip
ip_vs_rr
ip_vs_sed
ip_vs_sh
ip_vs_wlc
ip_vs_wrr4.2 启动proxy服务
4.2.1 查看启动文件
[root@node01 opt]#cat 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模式，可添加--ipvs-scheduler选项指定ipvs调度算法（rr|wrr|lc|wlc|lblc|lblcr|dh|sh|sed|nq）
#--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
4.2.2 启动服务
[root@node01 opt]#./proxy.sh 192.168.83.50 #指定本机的IP地址，与kubelet保持一致
Created symlink from /etc/systemd/system/multi-user.target.wants/kube-proxy.service to /usr/lib/systemd/system/kube-proxy.service.
4.2.3 查看启动状态
[root@node01 opt]#ps aux | grep kube-proxy
（五）部署 CNI 网络组件
| IP地址 | 主机名 | 安装组件 | 运行内存 |
| 192.168.83.30 | master01 | kube-apiserver kube-controller-manager kube-scheduler etcd集群节点1 | 4G |
| 192.168.83.50 | node01 | kubelet kube-proxy docker etcd集群节点2 flannel | 4G |
| 192.168.83.60 | node02 | kubelet kube-proxy docker etcd集群节点3 flannel | 4G |
1. CNI网络理论
1.1 k8s中的网络定义
Pod IP：
Pod IP是Kubernetes中Pod的IP地址。
每个Pod都有一个独立的IP地址，这个地址是由Docker Engine根据docker0网络的IP段进行分配的，通常是一个虚拟的二层网络地址。
Pod IP是虚拟IP地址，用于Pod之间的通信。在默认情况下，Kubernetes集群内不同节点上的Pod是不能直接通信的，需要通过集群网络进行管理和配置，以确保Pod之间可以互相通信。
Service IP（Server IP）
Service IP是Kubernetes中Service的IP地址。
Service是对一组具有相同功能的Pods的抽象，它提供负载均衡以及服务发现的能力。
Service IP是虚拟IP地址，用于集群内部访问Service。
当外部网络请求访问某个Service时，请求会首先到达Node节点网络，然后转发到Service网络，最后由Service代理给对应的Pod网络。
节点IP（Node IP）
节点IP是Kubernetes集群中每个节点（服务器）的物理网卡的IP地址。
这是一个真实存在的物理网络地址（也可能是虚拟机网络地址），用于节点之间的通信以及Kubernetes集群与外部网络的通信。
节点IP可以是内部IP和外部IP。内部IP用于集群节点之间的互相访问，而外部IP则提供了从外部网络访问Kubernetes集群的功能。
1.2 k8S中Pod网络通信
● Pod 内容器与容器之间的通信
在同一个 Pod 内的容器（Pod 内的容器是不会跨宿主机的）共享同一个网络命名空间，相当于它们在同一台机器上一样，可以用 localhost 地址访问彼此的端口
● 同一个Node内 Pod之间的通信
每个 Pod 都有一个真实的全局 IP 地址，同一个 Node 内的不同 Pod 之间可以直接采用对方 Pod 的 IP 地址进行通信，Pod1 与 Pod2 都是通过 Veth 连接到同一个 docker0/cni0 网桥，网段相同，所以它们之间可以直接通信。
● 不同Node上Pod 之间的通信
Pod 地址与 docker0 在同一网段，docker0 网段与宿主机网卡是两个不同的网段，且不同 Node 之间的通信只能通过宿主机的物理网卡进行。
要想实现不同 Node 上 Pod 之间的通信，就必须想办法通过主机的物理网卡 IP 地址进行寻址和通信。因此要满足两个条件：Pod 的 IP 不能冲突；将 Pod 的 IP 和所在的 Node 的 IP 关联起来，通过这个关联让不同 Node 上 Pod 之间直接通过内网 IP 地址通信
● Overlay Network
叠加网络，在二层或者三层基础网络上叠加的一种虚拟网络技术模式，该网络中的主机通过虚拟链路隧道连接起来。
通过Overlay技术（可以理解成隧道技术），在原始报文外再包一层四层协议（UDP协议），通过主机网络进行路由转发。这种方式性能有一定损耗，主要体现在对原始报文的修改
1.3 Flannel
1.3.1 主要作用
在Kubernetes（k8s）中，Flannel是一个网络插件，其作用和含义主要体现在以下几个方面：
网络隔离：Flannel提供了基于VXLAN、UDP隧道等技术的网络隔离能力，可以将容器隔离在不同的虚拟网络中，防止不同租户或服务之间的干扰或攻击。
Overlay网络：Flannel支持overlay网络，这是一种将TCP数据包封装在另一种网络包里面进行路由转发和通信的技术。这使得跨节点的容器之间可以直接通信，无需经过外部网络或网络代理，从而提升了网络传输效率和性能。
容器跨主机通信：Flannel还提供了容器跨主机通信的能力。通过使用overlay技术和路由配置，可以实现跨节点的容器互联，并提供了多种配置选项，例如使用静态路由或BGP协议来进行容器之间的通信。
IP分配与管理：Flannel通过与Kubernetes API Server或独立的etcd集群交互，负责在整个集群范围内动态分配和管理子网IP地址空间，确保每个Node节点上的Pod获得唯一且可以互相通信的IP地址
1.3.2 工作模式
Flannel提供了基于VXLAN、UDP隧道、host-gw等技术的网络隔离能力
①UDP工作模式
在UDP模式下，每个Flannel节点都会启动一个UDP服务器，用于监听来自其他节点的数据包。这些数据包会被封装在一个UDP数据包中，并通过UDP协议进行传输
● 数据从主机A上Pod的源容器中发出后，经由所在主机的docker0/cni0网络接口转发到flannel0接口，flanneld服务监听在flannel0虚拟网卡的另外一端
● Flannel通过Etcd 服务维护了一张节点间的路由表
● 源主机A的flanneld服务将原本的数据内容封装到UDP报文中，检查数据包的目标IP地址，并确定它属于哪个远程节点的网段。根据自己的路由表通过物理网卡投递给目的节点主机B的flanneld服务
● 当目标节点的UDP服务器收到数据包时，它会解析这个UDP数据包，并提取出原始的IP数据包。
● 这个IP数据包会被传递给目标节点上的Flannel守护进程（flanneld）。Flanneld会检查数据包的目标IP地址，并确定它属于哪个容器。然后直接进入目的节点的 flannel0 接口，最后，将这个数据包转发给目标容器
由于 UDP 模式是在用户态做转发，会多一次报文隧道封装，因此性能上会比在内核态做转发的 VXLAN 模式差
②VXLAN工作模式
Flannel 的 VXLAN 工作原理主要涉及在物理网络之上创建一个覆盖网络，以支持容器之间的跨主机通信
Flannel VXLAN 模式跨主机的工作原理：
● 数据帧从主机 A 上 Pod 的源容器中发出后，经由所在主机的 docker0/cni0 网络接口转发到 flannel.1 接口
● flannel.1 收到数据帧后添加 VXLAN 头部，封装在 UDP 报文中。这个封装过程包括添加 VXLAN 头部、目的 VTEP（VXLAN Tunnel Endpoint）地址、源 VTEP 地址等信息。
● VTEP转发。VTEP 是 VXLAN 隧道端点，负责在物理网络上传输 VXLAN 数据包。发送端的 VTEP 将封装后的数据包发送到物理网络上，接收端的 VTEP 则负责解封装数据包，并将其转发给目标容器
● 路由和转发：主机 A 在物理网络上，数据包会根据路由规则进行转发，确保它们能够到达目标 VTEP。这些路由规则通常由网络管理员配置，以确保 VXLAN 数据包能够正确地传输到目标节点
● 当目标 VTEP 收到数据包后，通过 VXLAN 默认端口 4789 转发到 flannel.1 接口进行解封装
● 解封装以后，内核将数据帧发送到cni0，最后由cni0发送到桥接到此接口的容器 B 中。
③host-gw工作模式
host-gw（主机网关）是一个在Kubernetes（特别是K3s、Kubeadmin等轻量级Kubernetes发行版）和某些网络插件（如Flannel）中使用的网络模式。在这种模式下，Kubernetes节点之间通过主机的网络直接进行通信，而不需要额外的覆盖网络（如VXLAN、IPSec等）。
以下是关于host-gw的一些关键点：
直接通信：使用host-gw模式的节点可以直接通过主机的网络接口进行通信，而不需要通过额外的隧道或封装。
性能：由于直接通信，host-gw通常比使用覆盖网络的模式具有更高的性能。
路由：为了使这种直接通信工作，每个节点都需要配置适当的路由规则，以便知道如何将数据包路由到集群中的其他节点。
限制：host-gw模式通常要求所有节点都在同一个L2域（例如，同一个VLAN或子网）中，因为它们依赖于底层的路由来确保数据包能够到达目的地。在云环境中，这可能是一个问题，因为云提供商通常不允许用户跨多个子网或VPC进行L2通信。另一个限制是，如果节点跨多个地理位置分布，使用host-gw可能会导致延迟增加。
配置：具体的配置取决于你使用的Kubernetes发行版和网络插件。但是，通常你需要在每个节点上配置适当的路由规则，并可能需要在网络插件的配置中指定使用host-gw模式。
1.4 Calico
1.4.1 k8s 组网方案对比
flannel方案
需要在每个节点上把发向容器的数据包进行封装后，再用隧道将封装后的数据包发送到运行着目标Pod的node节点上。目标node节点再负责去掉封装，将去除封装的数据包发送到目标Pod上。数据通信性能则大受影响。
calico方案
Calico不使用隧道或NAT来实现转发，而是把Host当作Internet中的路由器，使用BGP同步路由，并使用iptables来做安全访问策略，完成跨Host转发。
采用直接路由的方式，这种方式性能损耗最低，不需要修改报文数据，但是如果网络比较复杂场景下，路由表会很复杂，对运维同事提出了较高的要求。
1.4.2 Calico组成部分
Felix：Felix是Calico的核心组件，运行在每个节点上。
它负责配置和维护本地网络策略、路由规则以及ARP表项等。
Felix为内核编写一些接口信息，以便让内核能正确地处理主机endpoint的流量，特别是主机之间的ARP请求和处理IP转发。
Felix负责将ACL（访问控制列表）策略写入到Linux内核中，确保主机endpoint的有效流量不能绕过Calico的安全措施。
它还负责提供关于网络健康状况的数据。
Calico CNI插件：CNI（容器网络接口）插件负责在Pod创建时动态配置网络。这包括分配IP地址、设置网络命名空间以及应用网络策略。
BIRD/BGP Daemon：Calico使用BIRD（BIRD Internet Routing Daemon）来实现节点间的BGP（边界网关协议）路由传播。BGP客户端（Bird）在每个节点上运行，它的作用是将Felix的路由信息读入内核，并通过BGP协议在集群中分发，使得集群内的Pod可以直接通信且流量可以跨主机进行转发。
Confd：配置管理组件。
1.4.3 Calico工作原理
IP地址管理：Calico会为每个节点分配一个唯一的IP地址段，并使用BGP（边界网关协议）来分发路由表。这样，容器之间就可以通过IP地址相互通信，而不会与其他节点或集群发生冲突。
网络隔离：Calico提供基于iptables规则和Linux内核功能的网络隔离能力。通过这种隔离，容器可以被放置在不同的虚拟网络中，从而防止不同租户或服务之间的干扰和攻击。
BGP路由协议：Calico使用BGP协议来管理网络路由。当新的节点或容器被添加到集群中时，BGP协议可以自动发现这些变化，并动态调整路由表。这使得Calico能够快速适应网络变化，并实现高效的流量转发和负载均衡。
纯三层方法：Calico不使用重叠网络（如Flannel和libnetwork重叠网络驱动），而是采用纯三层的方法。它使用虚拟路由代替虚拟交换，每台虚拟路由都通过BGP协议传播可达信息（路由）到整个数据中心。这确保了所有工作负载之间的数据流量都是通过IP包的方式完成互联的。
Calico 是通过路由表来维护每个 pod 的通信。Calico 的 CNI 插件会为每个容器设置一个 veth pair 设备， 然后把另一端接入到宿主机网络空间，由于没有网桥，CNI 插件还需要在宿主机上为每个容器的 veth pair 设备配置一条路由规则， 用于接收传入的 IP 包。
有了这样的 veth pair 设备以后，容器发出的 IP 包就会通过 veth pair 设备到达宿主机，然后宿主机根据路由规则的下一跳地址， 发送给正确的网关，然后到达目标宿主机，再到达目标容器。
2.部署网络组件
2.1 上传文件
在所有node节点上操作
上传cni-plugins-linux-amd64-v0.8.6.tgz 和 flannel.tar 到 /opt 目录中
[root@node01 opt]#ll cni-plugins-linux-amd64-v0.8.6.tgz flannel.tar
-rw-r--r--. 1 root root 36878412 11月 8 2021 cni-plugins-linux-amd64-v0.8.6.tgz
-rw-r--r--. 1 root root 68921344 10月 6 2021 flannel.tar
2.2 加载容器镜像
[root@node01 opt]#docker load -i flannel.tar
777b2c648970: Loading layer [==================================================>] 5.848MB/5.848MB
815dff9e0b57: Loading layer [==================================================>] 11.42MB/11.42MB
2e16188127c8: Loading layer [==================================================>] 2.267MB/2.267MB
eb738177d102: Loading layer [==================================================>] 49.34MB/49.34MB
b613d890216c: Loading layer [==================================================>] 5.12kB/5.12kB
8a984b390686: Loading layer [==================================================>] 9.216kB/9.216kB
814fbd599e1f: Loading layer [==================================================>] 7.68kB/7.68kB
Loaded image: quay.io/coreos/flannel:v0.14.0
[root@node01 opt]#docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
quay.io/coreos/flannel v0.14.0 8522d622299c 2 years ago 67.9MB2.3 获取命令
[root@node01 opt]#mkdir /opt/cni/bin -p
[root@node01 opt]#tar xf cni-plugins-linux-amd64-v0.8.6.tgz -C /opt/cni/bin
[root@node01 opt]#ls /opt/cni/bin/
bandwidth dhcp flannel host-local loopback portmap sbr tuning
bridge firewall host-device ipvlan macvlan ptp static vlan2.4 部署CNI网络
在master01节点上操作
上传 kube-flannel.yml 文件到 /opt/k8s 目录中，部署 CNI 网络
1 ---
2 apiVersion: policy/v1beta1
3 kind: PodSecurityPolicy
4 metadata:
5 name: psp.flannel.unprivileged
6 annotations:
7 seccomp.security.alpha.kubernetes.io/allowedProfileNames: docker/default
8 seccomp.security.alpha.kubernetes.io/defaultProfileName: docker/default
9 apparmor.security.beta.kubernetes.io/allowedProfileNames: runtime/default
10 apparmor.security.beta.kubernetes.io/defaultProfileName: runtime/default
11 spec:
12 privileged: false
13 volumes:
14 - configMap
15 - secret
16 - emptyDir
17 - hostPath
18 allowedHostPaths:
19 - pathPrefix: "/etc/cni/net.d"
20 - pathPrefix: "/etc/kube-flannel"
21 - pathPrefix: "/run/flannel"
22 readOnlyRootFilesystem: false
23 # Users and groups
24 runAsUser:
25 rule: RunAsAny
26 supplementalGroups:
27 rule: RunAsAny
28 fsGroup:
29 rule: RunAsAny
30 # Privilege Escalation
31 allowPrivilegeEscalation: false
32 defaultAllowPrivilegeEscalation: false
33 # Capabilities
34 allowedCapabilities: ['NET_ADMIN', 'NET_RAW']
35 defaultAddCapabilities: []
36 requiredDropCapabilities: []
37 # Host namespaces
38 hostPID: false
39 hostIPC: false
40 hostNetwork: true
41 hostPorts:
42 - min: 0
43 max: 65535
44 # SELinux
45 seLinux:
46 # SELinux is unused in CaaSP
47 rule: 'RunAsAny'
48 ---
49 kind: ClusterRole
50 apiVersion: rbac.authorization.k8s.io/v1
51 metadata:
52 name: flannel
53 rules:
54 - apiGroups: ['extensions']
55 resources: ['podsecuritypolicies']
56 verbs: ['use']
57 resourceNames: ['psp.flannel.unprivileged']
58 - apiGroups:
59 - ""
60 resources:
61 - pods
62 verbs:
63 - get
64 - apiGroups:
65 - ""
66 resources:
67 - nodes
68 verbs:
69 - list
70 - watch
71 - apiGroups:
72 - ""
73 resources:
74 - nodes/status
75 verbs:
76 - patch
77 ---
78 kind: ClusterRoleBinding
79 apiVersion: rbac.authorization.k8s.io/v1
80 metadata:
81 name: flannel
82 roleRef:
83 apiGroup: rbac.authorization.k8s.io
84 kind: ClusterRole
85 name: flannel
86 subjects:
87 - kind: ServiceAccount
88 name: flannel
89 namespace: kube-system
90 ---
91 apiVersion: v1
92 kind: ServiceAccount
93 metadata:
94 name: flannel
95 namespace: kube-system
96 ---
97 kind: ConfigMap
98 apiVersion: v1
99 metadata:
100 name: kube-flannel-cfg
101 namespace: kube-system
102 labels:
103 tier: node
104 app: flannel
105 data:
106 cni-conf.json: |
107 {
108 "name": "cbr0",
109 "cniVersion": "0.3.1",
110 "plugins": [
111 {
112 "type": "flannel",
113 "delegate": {
114 "hairpinMode": true,
115 "isDefaultGateway": true
116 }
117 },
118 {
119 "type": "portmap",
120 "capabilities": {
121 "portMappings": true
122 }
123 }
124 ]
125 }
126 net-conf.json: |
127 {
128 "Network": "10.244.0.0/16",
129 "Backend": {
130 "Type": "vxlan"
131 }
132 }
133 ---
134 apiVersion: apps/v1
135 kind: DaemonSet
136 metadata:
137 name: kube-flannel-ds
138 namespace: kube-system
139 labels:
140 tier: node
141 app: flannel
142 spec:
143 selector:
144 matchLabels:
145 app: flannel
146 template:
147 metadata:
148 labels:
149 tier: node
150 app: flannel
151 spec:
152 affinity:
153 nodeAffinity:
154 requiredDuringSchedulingIgnoredDuringExecution:
155 nodeSelectorTerms:
156 - matchExpressions:
157 - key: kubernetes.io/os
158 operator: In
159 values:
160 - linux
161 hostNetwork: true
162 priorityClassName: system-node-critical
163 tolerations:
164 - operator: Exists
165 effect: NoSchedule
166 serviceAccountName: flannel
167 initContainers:
168 - name: install-cni
169 image: quay.io/coreos/flannel:v0.14.0
170 command:
171 - cp
172 args:
173 - -f
174 - /etc/kube-flannel/cni-conf.json
175 - /etc/cni/net.d/10-flannel.conflist
176 volumeMounts:
177 - name: cni
178 mountPath: /etc/cni/net.d
179 - name: flannel-cfg
180 mountPath: /etc/kube-flannel/
181 containers:
182 - name: kube-flannel
183 image: quay.io/coreos/flannel:v0.14.0
184 command:
185 - /opt/bin/flanneld
186 args:
187 - --ip-masq
188 - --kube-subnet-mgr
189 resources:
190 requests:
191 cpu: "100m"
192 memory: "50Mi"
193 limits:
194 cpu: "100m"
195 memory: "50Mi"
196 securityContext:
197 privileged: false
198 capabilities:
199 add: ["NET_ADMIN", "NET_RAW"]
200 env:
201 - name: POD_NAME
202 valueFrom:
203 fieldRef:
204 fieldPath: metadata.name
205 - name: POD_NAMESPACE
206 valueFrom:
207 fieldRef:
208 fieldPath: metadata.namespace
209 volumeMounts:
210 - name: run
211 mountPath: /run/flannel
212 - name: flannel-cfg
213 mountPath: /etc/kube-flannel/
214 volumes:
215 - name: run
216 hostPath:
217 path: /run/flannel
218 - name: cni
219 hostPath:
220 path: /etc/cni/net.d
221 - name: flannel-cfg
222 configMap:
223 name: kube-flannel-cfg
[root@master01 k8s]#kubectl apply -f kube-flannel.yml
podsecuritypolicy.policy/psp.flannel.unprivileged created
clusterrole.rbac.authorization.k8s.io/flannel created
clusterrolebinding.rbac.authorization.k8s.io/flannel created
serviceaccount/flannel created
configmap/kube-flannel-cfg created
daemonset.apps/kube-flannel-ds created
[root@master01 k8s]#kubectl get pods -n kube-system
NAME READY STATUS RESTARTS AGE
kube-flannel-ds-kvb2d 1/1 Running 0 27s
[root@master01 k8s]#kubectl get nodes
NAME STATUS ROLES AGE VERSION
192.168.83.50 Ready <none> 13h v1.20.11
3.加入node02节点
3.1 准备文件
在node01节点操作
将node01节点中的kubelet.sh文件与proxy.sh文件以及部署cni有关文件的目录，拷贝到node02节点当中
[root@node01 opt]#scp kubelet.sh node02:/opt
[root@node01 opt]#scp proxy.sh node02:/opt
[root@node01 opt]#scp -r cni node02:/opt3.2 启动kubelet
在node02节点上操作
[root@node02 opt]#./kubelet.sh 192.168.83.60
Created symlink from /etc/systemd/system/multi-user.target.wants/kubelet.service to /usr/lib/systemd/system/kubelet.service.3.3 通过CSR请求
在master节点上操作
[root@master01 k8s]#kubectl get csr #查看请求信息
NAME AGE SIGNERNAME REQUESTOR CONDITION
node-csr-M06PzuDFBMKDz8BnhclkkQwto-EC4OdZSVGC9yAu31Q 31s kubernetes.io/kube-apiserver-client-kubelet kubelet-bootstrap Pending
[root@master01 k8s]#kubectl certificate approve node-csr-M06PzuDFBMKDz8BnhclkkQwto-EC4OdZSVGC9yAu31Q #通过请求
certificatesigningrequest.certificates.k8s.io/node-csr-M06PzuDFBMKDz8BnhclkkQwto-EC4OdZSVGC9yAu31Q approved
[root@master01 k8s]#kubectl get csr 查看请求状态
NAME AGE SIGNERNAME REQUESTOR CONDITION
node-csr-M06PzuDFBMKDz8BnhclkkQwto-EC4OdZSVGC9yAu31Q 57s kubernetes.io/kube-apiserver-client-kubelet kubelet-bootstrap Approved,Issued
3.4 加载ipvs模块
在node02节点上操作
[root@node02 opt]#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
ip_vs_dh
ip_vs_ftp
ip_vs
ip_vs_lblc
ip_vs_lblcr
ip_vs_lc
ip_vs_nq
ip_vs_pe_sip
ip_vs_rr
ip_vs_sed
ip_vs_sh
ip_vs_wlc
ip_vs_wrr
[root@node02 opt]#3.5 启动proxy服务
[root@node02 opt]#./proxy.sh 192.168.83.60
Created symlink from /etc/systemd/system/multi-user.target.wants/kube-proxy.service to /usr/lib/systemd/system/kube-proxy.service.
3.6 查看集群节点信息
[root@master01 k8s]#kubectl get nodes
NAME STATUS ROLES AGE VERSION
192.168.83.50 Ready <none> 14h v1.20.11
192.168.83.60 Ready <none> 2m58s v1.20.11
（六）部署CoreDNS
| IP地址 | 主机名 | 安装组件 | 运行内存 |
| 192.168.83.30 | master01 | kube-apiserver kube-controller-manager kube-scheduler etcd集群节点1 | 4G |
| 192.168.83.50 | node01 | kubelet kube-proxy docker etcd集群节点2 flannel coredns | 4G |
| 192.168.83.60 | node02 | kubelet kube-proxy docker etcd集群节点3 flannel coredns | 4G |
CoreDNS：可以为集群中的 service 资源创建一个域名 与 IP 的对应关系解析
1.生成镜像文件
在所有 node 节点上操作
上传 coredns.tar 到 /opt 目录中
[root@node01 opt]#ls coredns.tar
coredns.tar
[root@node01 opt]#docker load -i coredns.tar
#生成镜像文件k8s.gcr.io/coredns
2.部署CoreDNS
在master01节点上操作
上传coredns.yaml文件到 /opt/k8s 目录中，部署 CoreDNS
[root@master01 k8s]#ls coredns.yaml
coredns.yaml
[root@master01 k8s]#kubectl apply -f coredns.yaml
serviceaccount/coredns created
clusterrole.rbac.authorization.k8s.io/system:coredns created
clusterrolebinding.rbac.authorization.k8s.io/system:coredns created
configmap/coredns created
deployment.apps/coredns created
service/kube-dns created
-------------------------------命令行--------------------------------
kubectl
#这是 Kubernetes 的命令行工具，用于与 Kubernetes 集群进行交互。
apply
#这是 kubectl 的一个子命令，用于应用或更新 Kubernetes 集群中的资源。
#与 create 命令不同，apply 命令会尝试应用你提供的定义，但如果资源已经存在并且其配置没有更改，
#那么它通常不会采取任何操作。但如果资源的定义发生了更改，apply 命令会更新该资源以匹配新的定义。
-f coredns.yaml：
-f #这是一个标志，表示你希望从文件中读取资源定义。
coredns.yaml
#这是你希望从中读取资源定义的 YAML 文件的名称。coredns.yaml文件内容
# __MACHINE_GENERATED_WARNING__
apiVersion: v1
kind: ServiceAccount
metadata:
name: coredns
namespace: kube-system
labels:
kubernetes.io/cluster-service: "true"
addonmanager.kubernetes.io/mode: Reconcile
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
labels:
kubernetes.io/bootstrapping: rbac-defaults
addonmanager.kubernetes.io/mode: Reconcile
name: system:coredns
rules:
- apiGroups:
- ""
resources:
- endpoints
- services
- pods
- namespaces
verbs:
- list
- watch
- apiGroups:
- ""
resources:
- nodes
verbs:
- get
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
annotations:
rbac.authorization.kubernetes.io/autoupdate: "true"
labels:
kubernetes.io/bootstrapping: rbac-defaults
addonmanager.kubernetes.io/mode: EnsureExists
name: system:coredns
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: system:coredns
subjects:
- kind: ServiceAccount
name: coredns
namespace: kube-system
---
apiVersion: v1
kind: ConfigMap
metadata:
name: coredns
namespace: kube-system
labels:
addonmanager.kubernetes.io/mode: EnsureExists
data:
Corefile: |
.:53 {
errors
health {
lameduck 5s
}
ready
kubernetes cluster.local in-addr.arpa ip6.arpa {
pods insecure
fallthrough in-addr.arpa ip6.arpa
ttl 30
}
prometheus :9153
forward . /etc/resolv.conf {
max_concurrent 1000
}
cache 30
loop
reload
loadbalance
}
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: coredns
#与node节点操作生成的镜像名称一致
namespace: kube-system
labels:
k8s-app: kube-dns
kubernetes.io/cluster-service: "true"
addonmanager.kubernetes.io/mode: Reconcile
kubernetes.io/name: "CoreDNS"
spec:
# replicas: not specified here:
# 1. In order to make Addon Manager do not reconcile this replicas parameter.
# 2. Default is 1.
# 3. Will be tuned in real time if DNS horizontal auto-scaling is turned on.
strategy:
type: RollingUpdate
rollingUpdate:
maxUnavailable: 1
selector:
matchLabels:
k8s-app: kube-dns
template:
metadata:
labels:
k8s-app: kube-dns
spec:
securityContext:
seccompProfile:
type: RuntimeDefault
priorityClassName: system-cluster-critical
serviceAccountName: coredns
affinity:
podAntiAffinity:
preferredDuringSchedulingIgnoredDuringExecution:
- weight: 100
podAffinityTerm:
labelSelector:
matchExpressions:
- key: k8s-app
operator: In
values: ["kube-dns"]
topologyKey: kubernetes.io/hostname
tolerations:
- key: "CriticalAddonsOnly"
operator: "Exists"
nodeSelector:
kubernetes.io/os: linux
containers:
- name: coredns
image: k8s.gcr.io/coredns:1.7.0
imagePullPolicy: IfNotPresent
resources:
limits:
memory: 170Mi
requests:
cpu: 100m
memory: 70Mi
args: [ "-conf", "/etc/coredns/Corefile" ]
volumeMounts:
- name: config-volume
mountPath: /etc/coredns
readOnly: true
ports:
- containerPort: 53
name: dns
protocol: UDP
- containerPort: 53
name: dns-tcp
protocol: TCP
- containerPort: 9153
name: metrics
protocol: TCP
livenessProbe:
httpGet:
path: /health
port: 8080
scheme: HTTP
initialDelaySeconds: 60
timeoutSeconds: 5
successThreshold: 1
failureThreshold: 5
readinessProbe:
httpGet:
path: /ready
port: 8181
scheme: HTTP
securityContext:
allowPrivilegeEscalation: false
capabilities:
add:
- NET_BIND_SERVICE
drop:
- all
readOnlyRootFilesystem: true
dnsPolicy: Default
volumes:
- name: config-volume
configMap:
name: coredns
items:
- key: Corefile
path: Corefile
---
apiVersion: v1
kind: Service
metadata:
name: kube-dns
namespace: kube-system
annotations:
prometheus.io/port: "9153"
prometheus.io/scrape: "true"
labels:
k8s-app: kube-dns
kubernetes.io/cluster-service: "true"
addonmanager.kubernetes.io/mode: Reconcile
kubernetes.io/name: "CoreDNS"
spec:
selector:
k8s-app: kube-dns
clusterIP: 10.0.0.2
#DNS解析地址
ports:
- name: dns
port: 53
protocol: UDP
- name: dns-tcp
port: 53
protocol: TCP
- name: metrics
port: 9153
protocol: TCP获取在 kube-system命名空间中的 Pods 的列表
[root@master01 k8s]#kubectl get pods -n kube-system
NAME READY STATUS RESTARTS AGE
coredns-6954c77b9b-hndh8 1/1 Running 0 3m8s
kube-flannel-ds-kvb2d 1/1 Running 0 22h
kube-flannel-ds-mx2q4 1/1 Running 3 22h
#coredns-6954c77b9b-hndh8 ：此pod为k8sDNS解析服务
3.DNS解析测试
3.1 角色授权
需要添加rbac的权限。直接使用kubectl绑定 clusteradmin 管理员集群角色 ，权操作权限
[root@master01 k8s]#kubectl create clusterrolebinding cluster-system-anonymous --clusterrole=cluster-admin --user=system:anonymous
clusterrolebinding.rbac.authorization.k8s.io/cluster-system-anonymous created #创建成功
3.2 解析测试
[root@master01 k8s]#kubectl run -it --rm dns-test --image=busybox:1.28.4 sh
If you don't see a command prompt, try pressing enter.
/ # nslookup kubernetes #解析kubernetes,这是
Server: 10.0.0.2
Address 1: 10.0.0.2 kube-dns.kube-system.svc.cluster.local
Name: kubernetes
Address 1: 10.0.0.1 kubernetes.default.svc.cluster.local
kubectl run -it --rm dns-test --image=busybox:1.28.4 sh#这个命令是在 Kubernetes 集群中运行一个临时的 Pod，并立即连接到它的一个容器来执行一个命令
#kubectl run: 这是
kubectl的一个子命令，用于在集群中运行一个新的容器化的应用#-it: 这两个标志组合在一起。
-i表示“交互式”#--rm: 这个标志告诉 Kubernetes 在 Pod 退出后自动删除它
#dns-test: 自定义Pod名称
#--image=busybox:1.28.4: 指定要运行的容器的镜像和版本。BusyBox 是一个非常小的 Linux 实用程序集，通常用于嵌入式系统或作为 Docker 容器的基础镜像。
#sh: 这是你希望在容器内部执行的命令
3.3 查看地址
[root@master01 k8s]#kubectl get svc
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.0.0.1 <none> 443/TCP 41h
- NAME：服务的名称。
- TYPE：服务的类型，如 ClusterIP、NodePort、LoadBalancer、ExternalName 等。
- CLUSTER-IP：服务的集群内部 IP 地址（仅当服务类型为 ClusterIP 或 LoadBalancer 时显示）。
- EXTERNAL-IP：服务的外部 IP 地址（仅当服务类型为 LoadBalancer 时显示）。
- PORT(S)：服务暴露的端口。
- AGE：服务自创建以来已经存在的时间。
（七）部署master02节点
| IP地址 | 主机名 | 安装组件 | 运行内存 |
| 192.168.83.30 | master01 | kube-apiserver kube-controller-manager kube-scheduler etcd集群节点1 | 4G |
| 192.168.83.40 | master02 | kube-apiserver kube-controller-manager kube-scheduler | 4G |
| 192.168.83.50 | node01 | kubelet kube-proxy docker etcd集群节点2 flannel coredns | 4G |
| 192.168.83.60 | node02 | kubelet kube-proxy docker etcd集群节点3 flannel coredns | 4G |
1.准备文件
在master01节点上操作
将有关配置文件，全部拷贝到master02节点上
[root@master01 k8s]#scp -r /opt/etcd/ master02:/opt
#etcd相关文件
[root@master01 k8s]#scp -r /opt/kubernetes/ master02:/opt
#kubernetes相关文件，包含执行文件与配置文件
[root@master01 k8s]#scp -r /root/.kube master02:/root
#kubernetes集群配置文件。在执行admin.sh脚本生成
[root@master01 k8s]#scp /usr/lib/systemd/system/{kube-apiserver,kube-controller-manager,kube-scheduler}.service master02:/usr/lib/systemd/system/
#system管理文件2. 修改配置文件
在master02节点上操作
修改配置文件kube-apiserver中的IP
[root@master02 opt]#vim /opt/kubernetes/cfg/kube-apiserver
1 KUBE_APISERVER_OPTS="--logtostderr=false \
2 --v=2 \
3 --log-dir=/opt/kubernetes/logs \
4 --etcd-servers=https://192.168.83.30:2379,https://192.168.83.50:2379,https://192.168.83.60:2379 \
5 --bind-address=192.168.83.40 \ #修改为本机IP
6 --secure-port=6443 \
7 --advertise-address=192.168.83.40 \ #修改为本机IP
8 --allow-privileged=true \
9 --service-cluster-ip-range=10.0.0.0/24 \
.......
3.启动服务
在 master02 节点 上启动各服务并设置开机自启
[root@master02 opt]#systemctl start kube-apiserver.service
[root@master02 opt]#systemctl enable kube-apiserver.service
[root@master02 opt]#systemctl start kube-controller-manager.service
[root@master02 opt]#systemctl enable kube-controller-manager.service
[root@master02 opt]#systemctl start kube-scheduler.service
[root@master02 opt]#systemctl enable kube-scheduler.service4.查看node节点状态
[root@master02 opt]#ln -s /opt/kubernetes/bin/* /usr/local/bin/
[root@master02 opt]#kubectl get nodes
NAME STATUS ROLES AGE VERSION
192.168.83.50 Ready <none> 37h v1.20.11
192.168.83.60 Ready <none> 23h v1.20.11
[root@master02 opt]#
[root@master02 opt]#kubectl get nodes -o wide
NAME STATUS ROLES AGE VERSION INTERNAL-IP EXTERNAL-IP OS-IMAGE KERNEL-VERSION CONTAINER-RUNTIME
192.168.83.50 Ready <none> 37h v1.20.11 192.168.83.50 <none> CentOS Linux 7 (Core) 3.10.0-693.el7.x86_64 docker://26.1.2
192.168.83.60 Ready <none> 23h v1.20.11 192.168.83.60 <none> CentOS Linux 7 (Core) 3.10.0-693.el7.x86_64 docker://26.1.2
#-o=wide：输出额外信息；对于Pod，将输出Pod所在的Node名（八）负载均衡
| IP地址 | 主机名 | 安装组件 | 运行内存 |
| 192.168.83.30 | master01 | kube-apiserver kube-controller-manager kube-scheduler etcd集群节点1 | 4G |
| 192.168.83.40 | master01 | kubelet kube-proxy docker | 4G |
| 192.168.83.50 | node01 | kubelet kube-proxy docker etcd集群节点2 CoreDNS flannel | 4G |
| 192.168.83.60 | node02 | kubelet kube-proxy docker etcd集群节点3 CoreDNS flannel | 4G |
| 192.168.83.70 | nginx01 | nginx-1.18.0 keepalived | 2G |
| 192.168.83.80 | nginx02 | nginx-1.18.0 keepalived | 2G |
| 192.168.83.200 | VIP |
此时在master02节点查到的node节点状态仅是从etcd查询到的信息，而此时node节点实际上并未与master02节点建立通信连接，因此需要使用一个VIP把node节点与master节点都关联起来
通过nignx服务进行负载关联
注意：在生成master公私钥以及证书的时候，指定了nignx的地址与VIP地址，在安装nginx服务时，需要在对应地址上进行安装，以及使用的VIP地址也是设置为指定的IP地址
1.安装nginx
可以通过搭建nginx的yum仓库、使用epel源或者编译安装的方式安装nginx
首先在nginx01上进行操作
脚本编译安装nginx
#/bin/bash
systemctl start nginx >>/dev/null
if [ $? -eq 0 ];then
echo "nginx服务已安装"
else
useradd -M -s /sbin/nologin nginx
cd /opt
wget http://nginx.org/download/nginx-1.18.0.tar.gz >>/dev/null
echo "正在安装，请耐心等待"
tar xf nginx-1.18.0.tar.gz
cd /opt/nginx-1.18.0
yum -y install gcc pcre-devel openssl-devel zlib-devel openssl openssl-devel &>>/dev/null
./configure --prefix=/usr/local/nginx \
--user=nginx \
--group=nginx \
--with-http_ssl_module \
--with-http_v2_module \
--with-http_realip_module \
--with-http_stub_status_module \
--with-http_gzip_static_module \
--with-pcre \
--with-stream \ #编译steram模块
--with-stream_ssl_module \
--with-stream_realip_module
make -j `lscpu|sed -n '4p'|awk '{print $2}'`&>>/dev/null
make install &>>/dev/null
ln -s /usr/local/nginx/sbin/nginx /usr/local/sbin/
cat > /usr/lib/systemd/system/nginx.service <<EOF
[Unit]
Description=nginx
After=network.target
[Service]
Type=forking
PIDFile=/usr/local/nginx/logs/nginx.pid
ExecStart=/usr/local/nginx/sbin/nginx
ExecReload=/bin/kill -1 $MAINPID
ExecStop=/bin/kill -3 $MAINPID
PrivateTmp=true
[Install]
WantedBy=multi-user.target
EOF
chown -R nginx.nginx /usr/local/nginx
systemctl daemon-reload &>>/dev/null
systemctl enable --now nginx
echo "nginx服务已开启"
fi
2.添加代理信息
[root@nginx01 opt]#vim /usr/local/nginx/conf/nginx.conf
......
stream {
log_format main '$remote_addr $upstream_addr - [$time_local] $status
$upstream_bytes_sent';
#自定义日志格式
access_log /usr/local/nginx/logs/k8s-access.log main;
#自定义日志存放路径
upstream kubernetes {
server 192.168.83.30:6443;
server 192.168.83.40:6443;
}
#定义代理目标，为两台master的6443端口，即apiserver的监听端口
server {
listen 6443;
proxy_pass kubernetes;
}
}
http {
include mime.types;
......
[root@nginx01 opt]#systemctl restart nginx.service
#重启服务
[root@nginx01 opt]#netstat -natp | grep nginx #查看监听端口
tcp 0 0 0.0.0.0:6443 0.0.0.0:* LISTEN 6731/nginx: master
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 6731/nginx: master 在nginx02机器上同样操作
[root@nginx02 opt]#bash nginx.sh #安装nginx服务
[root@nginx02 opt]#vim /usr/local/nginx/conf/nginx.conf
......
stream {
log_format main '$remote_addr $upstream_addr - [$time_local] $status
$upstream_bytes_sent';
access_log /usr/local/nginx/logs/k8s-access.log main;
upstream kubernetes {
server 192.168.83.30:6443;
server 192.168.83.40:6443;
}
server {
listen 6443;
proxy_pass kubernetes;
}
}
[root@nginx02 opt]#systemctl restart nginx
3.实现nginx高可用
首先在nginx01机器上进行操作
做高可用之前，首先需要停止nginx服务
[root@nginx01 opt]#systemctl stop nginx3.1 下载keepalived
[root@nginx01 opt]#yum install keepalived -y3.2 修改keepalived配置文件
[root@nginx01 opt]#vim /etc/keepalived/keepalived.conf
! Configuration File for keepalived
global_defs {
notification_email {
[email protected]
[email protected]
[email protected]
notification_email_from [email protected]
smtp_server 127.0.0.1 #邮箱地址设置为本地IP地址
smtp_connect_timeout 30
router_id nginx01 #自定义名称，主备不同相同
vrrp_skip_check_adv_addr
# vrrp_strict #注释或者删除
vrrp_garp_interval 0
vrrp_gna_interval 0
}
vrrp_script nginx_test { #使用script模块，并自定义名称为nginx_test
script "/usr/loca/nginx/conf/nginx_test.sh"
#指定要执行的shell脚本路径，通过脚本，判断nginx状态。
#这个脚本应该返回0表示成功，意味着nginx服务停止；非零值表示失败，nginx服务正常运行
interval 1 #设置每隔1秒执行一次该脚本以检查服务状态
timeout 30 #如果脚本在30秒内没有响应（即超时），则认为它执行失败
weight -50 #当脚本执行成功时，VRRP实例的优先级权重减50
fall 3 #当连续3次检查失败后，将触发VRRP实例状态变更，可能导致主备切换
rise 3 #当连续3次检查成功后，恢复VRRP实例到正常状态
}
vrrp_instance VI_1 {
state MASTER #设置为MASTER表示为主
interface ens33 #指定心跳报文从ens33网卡发送
virtual_router_id 51 #实例表示符，默认即可，BACKUP与其一致
priority 100 #设置优先级，其值需要比BACKUP高
advert_int 1 #每间隔一秒发送一次VRRP报文
authentication { #定义密码认证方式，并设置密码，BACKUP需要与其一致
auth_type PASS
auth_pass 1111
}
virtual_ipaddress {
192.168.83.200/24 #设置集群VIP地址
}
track_script {
nginx_test.sh #调用脚本模块nginx_test.sh
}
} 3.3 添加脚本文件
[root@nginx01 opt]#vim /usr/local/nginx/conf/nginx_test.sh
#注意文件要与keepalived配置文件中script定义的路径、名称一致
[root@nginx01 opt]#cat /usr/local/nginx/conf/nginx_test.sh
#!/bin/bash
killall -0 nginx
#脚本表示使用killall -0，
#这是Linux命令行中用于检查指定进程名是否存在且至少有一个实例在运行的命令。
#这里的参数 -0 具有特殊含义，它不会发送任何信号给进程，而是仅仅测试这些进程是否存在
[root@nginx01 opt]#chmod +x /usr/local/nginx/conf/nginx_test.sh
#给脚本添加执行权限将脚本文件以及配置文件远程复制到nginx02机器上，并进行修改
[root@nginx01 opt]#scp /etc/keepalived/keepalived.conf 192.168.83.80:/etc/keepalived/keepalived.conf
[root@nginx01 opt]#scp /usr/local/nginx/conf/nginx_test.sh 192.168.83.80:/usr/local/nginx/conf/在nginx02上操作
另一台nginx02服务器与其配置一致，需要修改优先级、state、router_id信息
[root@nginx02 opt]#vim /etc/keepalived/keepalived.conf
.......
smtp_server 127.0.0.1
smtp_connect_timeout 30
router_id nginx02 #修改为与MASTER不同的标识符
vrrp_skip_check_adv_addr
# vrrp_strict
vrrp_garp_interval 0
vrrp_gna_interval 0
}
vrrp_script nginx_test {
script "/usr/local/nginx/conf/nginx_test.sh"
interval 1
timeout 30
weight -50
fall 3
rise 3
}
vrrp_instance VI_1 {
state BACKUP #设置状态为BACKUP，表示此主机为备
interface ens33
virtual_router_id 51
priority 80
#设置优先为80，需要比MASTER的优先级低
#且在MASTER的测试脚本执行成功，减去设定的优先级数值，此数值需要比它大
advert_int 1
.......3.4 启动服务
在两台nginx的服务器上进行操作
nginx01启动服务
[root@nginx01 opt]#systemctl start nginx #先启动nginx服务
[root@nginx01 opt]#systemctl start keepalived.service #再启动keepalived服务
[root@nginx02 opt]#systemctl enable keepalived查看VIP是否生成
nginx02启动服务
[root@nginx02 opt]#systemctl start nginx
[root@nginx02 opt]#systemctl start keepalived.service
[root@nginx02 opt]#systemctl enable keepalived4.修改node节点文件
修改node节点上的bootstrap.kubeconfig,kubelet.kubeconfig配置文件为VIP
首先再node01服务器上操作
[root@node01 opt]#vim /opt/kubernetes/cfg/bootstrap.kubeconfig
[root@node01 opt]#sed -n '5p' /opt/kubernetes/cfg/bootstrap.kubeconfig
server: https://192.168.83.200:6443
#修改kubelet初次加入集群引导kubeconfig文件,即bootstrap.kubeconfig
[root@node01 opt]#vim /opt/kubernetes/cfg/kubelet.kubeconfig
[root@node01 opt]#sed -n '5p' /opt/kubernetes/cfg/kubelet.kubeconfig
server: https://192.168.83.200:6443
#修改kubelet配置文件
[root@node01 opt]#vim /opt/kubernetes/cfg/kube-proxy.kubeconfig
[root@node01 opt]#sed -n '5p' /opt/kubernetes/cfg/kube-proxy.kubeconfig
server: https://192.168.83.200:6443
#修改proxy配置文件修改完毕后重新启动服务
[root@node01 opt]#systemctl restart kubelet.service
[root@node01 opt]#systemctl restart kube-proxy.service
在node02节点上操作
[root@node02 opt]#vim /opt/kubernetes/cfg/bootstrap.kubeconfig
[root@node02 opt]#sed -n '5p' /opt/kubernetes/cfg/bootstrap.kubeconfig
server: https://192.168.83.200:6443
[root@node02 opt]#vim /opt/kubernetes/cfg/kubelet.kubeconfig
[root@node02 opt]#sed -n '5p' /opt/kubernetes/cfg/kubelet.kubeconfig
server: https://192.168.83.200:6443
[root@node02 opt]#vim /opt/kubernetes/cfg/kube-proxy.kubeconfig
[root@node02 opt]#sed -n '5p' /opt/kubernetes/cfg/kube-proxy.kubeconfig
server: https://192.168.83.200:6443
5.查看连接状态
在nginx01节点操作
在nginx01节点上，即master，查看nginx和 node 、master节点的连接状态
[root@nginx01 opt]#netstat -natp | grep nginx
tcp 0 0 0.0.0.0:6443 0.0.0.0:* LISTEN 6731/nginx: master
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 6731/nginx: master
tcp 0 0 192.168.83.70:38022 192.168.83.30:6443 ESTABLISHED 6732/nginx: worker
tcp 0 0 192.168.83.200:6443 192.168.83.50:53298 ESTABLISHED 6732/nginx: worker
tcp 0 0 192.168.83.70:35922 192.168.83.40:6443 ESTABLISHED 6732/nginx: worker
tcp 0 0 192.168.83.200:6443 192.168.83.60:36856 ESTABLISHED 6732/nginx: worker
tcp 0 0 192.168.83.200:6443 192.168.83.60:36834 ESTABLISHED 6732/nginx: worker
tcp 0 0 192.168.83.200:6443 192.168.83.60:36860 ESTABLISHED 6732/nginx: worker
tcp 0 0 192.168.83.200:6443 192.168.83.50:53304 ESTABLISHED 6732/nginx: worker
tcp 0 0 192.168.83.200:6443 192.168.83.60:36854 ESTABLISHED 6732/nginx: worker
tcp 0 0 192.168.83.70:38002 192.168.83.30:6443 ESTABLISHED 6732/nginx: worker
tcp 0 0 192.168.83.70:35926 192.168.83.40:6443 ESTABLISHED 6732/nginx: worker
tcp 0 0 192.168.83.200:6443 192.168.83.60:36852 ESTABLISHED 6732/nginx: worker
tcp 0 0 192.168.83.200:6443 192.168.83.50:53292 ESTABLISHED 6732/nginx: worker
tcp 0 0 192.168.83.70:37990 192.168.83.30:6443 ESTABLISHED 6732/nginx: worker
tcp 0 0 192.168.83.200:6443 192.168.83.50:53276 ESTABLISHED 6732/nginx: worker
tcp 0 0 192.168.83.70:37994 192.168.83.30:6443 ESTABLISHED 6732/nginx: worker
tcp 0 0 192.168.83.70:38006 192.168.83.30:6443 ESTABLISHED 6732/nginx: worker
tcp 0 0 192.168.83.70:38018 192.168.83.30:6443 ESTABLISHED 6732/nginx: worker
tcp 0 0 192.168.83.200:6443 192.168.83.50:53300 ESTABLISHED 6732/nginx: worker
tcp 0 0 192.168.83.70:35918 192.168.83.40:6443 ESTABLISHED 6732/nginx: worker
tcp 0 0 192.168.83.70:38014 192.168.83.30:6443 ESTABLISHED 6732/nginx: worker
tcp 0 0 192.168.83.200:6443 192.168.83.50:53302 ESTABLISHED 6732/nginx: worker
tcp 0 0 192.168.83.200:6443 192.168.83.60:36862 ESTABLISHED 6732/nginx: worker
tcp 0 0 192.168.83.200:6443 192.168.83.60:36840 ESTABLISHED 6732/nginx: worker
tcp 0 0 192.168.83.70:35934 192.168.83.40:6443 ESTABLISHED 6732/nginx: worker
tcp 0 0 192.168.83.70:35910 192.168.83.40:6443 ESTABLISHED 6732/nginx: worker
tcp 0 0 192.168.83.70:35914 192.168.83.40:6443 ESTABLISHED 6732/nginx: worker 6.进行测试
在master01节点上操作
6.1 测试创建pod
[root@master01 k8s]#kubectl run nginx --image=nginx
pod/nginx created6.2 查看pod状态
[root@master01 k8s]#kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 0/1 ContainerCreating 0 8s
#ContainerCreating表示正在创建
[root@master01 k8s]#kubectl get pods
NAME READY STATUS RESTARTS AGE
nginx 1/1 Running 0 66s
#Running表示创建成功并正在运行
[root@master01 k8s]#kubectl get pods -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
nginx 1/1 Running 0 3m29s 10.244.0.2 192.168.83.50 <none> <none>
#NAME：表示Pod的名称是nginx
#READY：Pod中的容器数量与期望运行的容器数量之比，1/1表示Pod中有一个容器，并且这个容器已经准备好了
#STATUS：Pod的当前状态是Running，表示Pod正在运行
#RESTARTS：Pod中的容器已经重启的次数。这里显示为0，表示容器没有重启过
#AGE：Pod已经运行的时长
#IP：Pod 在集群中的IP地址是10.244.0.2，通常用于集群内部的服务发现和通信
#NODE：Pod正在运行的节点IP地址是 192.168.83.50。这表示Pod被调度到了IP地址为 192.168.83.50的 Kubernetes节点上
#NOMINATED NODE：这里显示为 <none>，表示没有为 Pod 指定备选的节点。在某些情况下，例如当 Pod 调度失败时，调度器可能会选择一个备选的节点，并在稍后的时间尝试重新调度 Pod 到这个备选的节点上。
#READINESS GATES：这里也显示为 <none>，表示没有设置就绪门控（Readiness Gates）。就绪门控是一种用于控制 Pod 就绪性的机制，它允许你根据自定义的条件来决定 Pod 是否被视为就绪6.3 访问pod
在对应网段的node节点上进行访问
6.4 查看日志
在master01节点上使用kubectl logs 指令查看你信息
在master02节点上同样可以进行操作
（九）部署Dashboard
| IP地址 | 主机名 | 安装组件 | 运行内存 |
| 192.168.83.30 | master01 | kube-apiserver kube-controller-manager kube-scheduler etcd集群节点1 | 4G |
| 192.168.83.40 | master01 | kubelet kube-proxy docker | 4G |
| 192.168.83.50 | node01 | kubelet kube-proxy docker etcd集群节点2 Dashboard CoreDNS flannel | 4G |
| 192.168.83.60 | node02 | kubelet kube-proxy docker etcd集群节点3 Dashboard CoreDNS flannel | 4G |
| 192.168.83.70 | nginx01 | nginx-1.18.0 keepalived | 2G |
| 192.168.83.80 | nginx02 | nginx-1.18.0 keepalived | 2G |
| 192.168.83.200 | VIP |
1.基本介绍
Kubernetes Dashboard 是一个基于Web的交互式界面，用于管理和监控Kubernetes集群。它是Kubernetes官方提供的组件之一，可以帮助用户更轻松地管理和操作Kubernetes集群中的各种资源和服务。
Kubernetes Dashboard提供了一种直观的方式来查看和管理Kubernetes集群的状态和资源。它提供了一个集中式的仪表板，可以显示集群中的节点、部署、服务、副本集等各种资源的信息。通过这个仪表板，用户可以方便地进行资源的创建、删除、修改等操作，以及监控资源的运行状态和性能指标
关于Kubernetes Dashboard的部署和使用
部署Kubernetes Dashboard：通过执行相应的命令（如使用kubectl apply命令和Dashboard的YAML文件）来部署Dashboard。
启动Kubernetes Dashboard：使用kubectl proxy命令启动Dashboard的代理服务
访问Kubernetes Dashboard：通过浏览器访问Dashboard的URL（通常是localhost的某个端口），并使用相应的令牌进行登录。
2.部署Dashboard
2.1 准备文件
上传recommended.yaml 文件到master01节点/opt/k8s 目录中
[root@master01 k8s]#ll -h recommended.yaml
-rw-r--r-- 1 root root 7.5K 11月 8 2021 recommended.yaml上传dashboard.tar与metrics-scraper.tar包到node01节点与node02节点的/opt/目录下,用于生成镜像文件
dashboard:
Kubernetes Dashboard 是一个基于 Web 的用户界面，用于管理 Kubernetes 集群。通过 Dashboard，用户可以查看集群的状态、管理资源（如部署、Pod、服务等）、以及查看集群的日志和事件。
metrics-scraper:
在 Kubernetes Dashboard 中，Metrics Scraper 是一个用于从 Kubernetes 集群中收集度量数据（如 Pod 和节点的 CPU、内存使用情况）的组件。这些数据然后可以在 Dashboard 中显示，帮助用户更好地了解集群的状态和性能。
[root@node01 opt]#ll -h dashboard.tar metrics-scraper.tar
-rw-r--r--. 1 root root 215M 1月 17 2022 dashboard.tar
-rw-r--r--. 1 root root 36M 1月 17 2022 metrics-scraper.tar2.2 生成镜像
在node01节点上操作
[root@node01 opt]#docker load -i dashboard.tar
69e42300d7b5: Loading layer [==================================================>] 224.6MB/224.6MB
Loaded image: kubernetesui/dashboard:v2.0.0
[root@node01 opt]#docker load -i metrics-scraper.tar
57757cd7bb95: Loading layer [==================================================>] 238.6kB/238.6kB
14f2e8fb1e35: Loading layer [==================================================>] 36.7MB/36.7MB
52b345e4c8e0: Loading layer [==================================================>] 2.048kB/2.048kB
Loaded image: kubernetesui/metrics-scraper:v1.0.4
[root@node01 opt]#docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
nginx latest e784f4560448 11 days ago 188MB
quay.io/coreos/flannel v0.14.0 8522d622299c 2 years ago 67.9MB
k8s.gcr.io/coredns 1.7.0 bfe3a36ebd25 3 years ago 45.2MB
kubernetesui/dashboard v2.0.0 8b32422733b3 4 years ago 222MB
kubernetesui/metrics-scraper v1.0.4 86262685d9ab 4 years ago 36.9MB
registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64 3.0 99e59f495ffa 8 years ago 747kB
在node02节点上操作
[root@node02 opt]#docker load -i dashboard.tar
69e42300d7b5: Loading layer [==================================================>] 224.6MB/224.6MB
Loaded image: kubernetesui/dashboard:v2.0.0
[root@node02 opt]#docker load -i metrics-scraper.tar
57757cd7bb95: Loading layer [==================================================>] 238.6kB/238.6kB
14f2e8fb1e35: Loading layer [==================================================>] 36.7MB/36.7MB
52b345e4c8e0: Loading layer [==================================================>] 2.048kB/2.048kB
Loaded image: kubernetesui/metrics-scraper:v1.0.4
[root@node01 opt]#docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
nginx latest e784f4560448 11 days ago 188MB
quay.io/coreos/flannel v0.14.0 8522d622299c 2 years ago 67.9MB
k8s.gcr.io/coredns 1.7.0 bfe3a36ebd25 3 years ago 45.2MB
kubernetesui/dashboard v2.0.0 8b32422733b3 4 years ago 222MB
kubernetesui/metrics-scraper v1.0.4 86262685d9ab 4 years ago 36.9MB
registry.cn-hangzhou.aliyuncs.com/google-containers/pause-amd64 3.0 99e59f495ffa 8 years ago 747kB
2.3 修改yaml文件
在master01节点上操作
修改 recommended.yaml文件
默认Dashboard只能集群内部访问，修改Service为NodePort类型，暴露到外部
apiVersion: v1
kind: Namespace
metadata:
name: kubernetes-dashboard
---
apiVersion: v1
kind: ServiceAccount
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard
namespace: kubernetes-dashboard
---
kind: Service
apiVersion: v1
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard
namespace: kubernetes-dashboard
spec:
ports:
- port: 443
targetPort: 8443
nodePort: 30001 #自定义对外端口
type: NodePort #修改类型
selector:
k8s-app: kubernetes-dashboard
---
apiVersion: v1
kind: Secret
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard-certs
namespace: kubernetes-dashboard
type: Opaque
---
apiVersion: v1
kind: Secret
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard-csrf
namespace: kubernetes-dashboard
type: Opaque
data:
csrf: ""
---
apiVersion: v1
kind: Secret
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard-key-holder
namespace: kubernetes-dashboard
type: Opaque
---
kind: ConfigMap
apiVersion: v1
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard-settings
namespace: kubernetes-dashboard
---
kind: Role
apiVersion: rbac.authorization.k8s.io/v1
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard
namespace: kubernetes-dashboard
rules:
# Allow Dashboard to get, update and delete Dashboard exclusive secrets.
- apiGroups: [""]
resources: ["secrets"]
resourceNames: ["kubernetes-dashboard-key-holder", "kubernetes-dashboard-certs", "kubernetes-dashboard-csrf"]
verbs: ["get", "update", "delete"]
# Allow Dashboard to get and update 'kubernetes-dashboard-settings' config map.
- apiGroups: [""]
resources: ["configmaps"]
resourceNames: ["kubernetes-dashboard-settings"]
verbs: ["get", "update"]
# Allow Dashboard to get metrics.
- apiGroups: [""]
resources: ["services"]
resourceNames: ["heapster", "dashboard-metrics-scraper"]
verbs: ["proxy"]
- apiGroups: [""]
resources: ["services/proxy"]
resourceNames: ["heapster", "http:heapster:", "https:heapster:", "dashboard-metrics-scraper", "http:dashboard-metrics-scraper"]
verbs: ["get"]
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard
rules:
# Allow Metrics Scraper to get metrics from the Metrics server
- apiGroups: ["metrics.k8s.io"]
resources: ["pods", "nodes"]
verbs: ["get", "list", "watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard
namespace: kubernetes-dashboard
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: kubernetes-dashboard
subjects:
- kind: ServiceAccount
name: kubernetes-dashboard
namespace: kubernetes-dashboard
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: kubernetes-dashboard
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: kubernetes-dashboard
subjects:
- kind: ServiceAccount
name: kubernetes-dashboard
namespace: kubernetes-dashboard
---
kind: Deployment
apiVersion: apps/v1
metadata:
labels:
k8s-app: kubernetes-dashboard
name: kubernetes-dashboard
namespace: kubernetes-dashboard
spec:
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
k8s-app: kubernetes-dashboard
template:
metadata:
labels:
k8s-app: kubernetes-dashboard
spec:
containers:
- name: kubernetes-dashboard
image: kubernetesui/dashboard:v2.0.0
imagePullPolicy: Always
ports:
- containerPort: 8443
protocol: TCP
args:
- --auto-generate-certificates
- --namespace=kubernetes-dashboard
# Uncomment the following line to manually specify Kubernetes API server Host
# If not specified, Dashboard will attempt to auto discover the API server and connect
# to it. Uncomment only if the default does not work.
# - --apiserver-host=http://my-address:port
volumeMounts:
- name: kubernetes-dashboard-certs
mountPath: /certs
# Create on-disk volume to store exec logs
- mountPath: /tmp
name: tmp-volume
livenessProbe:
httpGet:
scheme: HTTPS
path: /
port: 8443
initialDelaySeconds: 30
timeoutSeconds: 30
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
runAsUser: 1001
runAsGroup: 2001
volumes:
- name: kubernetes-dashboard-certs
secret:
secretName: kubernetes-dashboard-certs
- name: tmp-volume
emptyDir: {}
serviceAccountName: kubernetes-dashboard
nodeSelector:
"kubernetes.io/os": linux
# Comment the following tolerations if Dashboard must not be deployed on master
tolerations:
- key: node-role.kubernetes.io/master
effect: NoSchedule
---
kind: Service
apiVersion: v1
metadata:
labels:
k8s-app: dashboard-metrics-scraper
name: dashboard-metrics-scraper
namespace: kubernetes-dashboard
spec:
ports:
- port: 8000
targetPort: 8000
selector:
k8s-app: dashboard-metrics-scraper
---
kind: Deployment
apiVersion: apps/v1
metadata:
labels:
k8s-app: dashboard-metrics-scraper
name: dashboard-metrics-scraper
namespace: kubernetes-dashboard
spec:
replicas: 1
revisionHistoryLimit: 10
selector:
matchLabels:
k8s-app: dashboard-metrics-scraper
template:
metadata:
labels:
k8s-app: dashboard-metrics-scraper
annotations:
seccomp.security.alpha.kubernetes.io/pod: 'runtime/default'
spec:
containers:
- name: dashboard-metrics-scraper
image: kubernetesui/metrics-scraper:v1.0.4
ports:
- containerPort: 8000
protocol: TCP
livenessProbe:
httpGet:
scheme: HTTP
path: /
port: 8000
initialDelaySeconds: 30
timeoutSeconds: 30
volumeMounts:
- mountPath: /tmp
name: tmp-volume
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
runAsUser: 1001
runAsGroup: 2001
serviceAccountName: kubernetes-dashboard
nodeSelector:
"kubernetes.io/os": linux
# Comment the following tolerations if Dashboard must not be deployed on master
tolerations:
- key: node-role.kubernetes.io/master
effect: NoSchedule
volumes:
- name: tmp-volume
emptyDir: {}2.4 创建资源
[root@master01 k8s]#kubectl apply -f recommended.yaml
namespace/kubernetes-dashboard created
serviceaccount/kubernetes-dashboard created
service/kubernetes-dashboard created
secret/kubernetes-dashboard-certs created
secret/kubernetes-dashboard-csrf created
secret/kubernetes-dashboard-key-holder created
configmap/kubernetes-dashboard-settings created
role.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrole.rbac.authorization.k8s.io/kubernetes-dashboard created
rolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
clusterrolebinding.rbac.authorization.k8s.io/kubernetes-dashboard created
deployment.apps/kubernetes-dashboard created
service/dashboard-metrics-scraper created
deployment.apps/dashboard-metrics-scraper created
----------------------------命令行-------------------------------
kubectl #Kubernetes 命令行工具，用于与 Kubernetes 集群进行交互。
apply #该子命令用于应用或更新一个或多个资源。
#apply 命令使用资源定义文件来确定资源的最终状态。
#如果资源已存在，apply会更新它以匹配文件中定义的状态；如果资源不存在，apply会创建它
-f recommended.yaml:
-f #标志后面跟着的是资源定义文件的路径
recommended.yaml #资源定义文件。包含Kubernetes资源的定义，如Deployments、Services、Pods、ConfigMaps等。2.5 创建服务账户
创建service account并绑定默认cluster-admin管理员集群角色
kubectl create serviceaccount dashboard-admin -n kube-system
#kubectl create：创建
#ServiceAccount：创建类型为服务账号
#dashboard-admin：创建服务账号名称，一般为dashboard-admin，具有管理员权限的服务账号
#-n kube-system：指定命名空间kube-system
'命令含义'
#在kube-system命名空间中创建了一个名为dashboard-admin的ServiceAccount(服务账号)
#ServiceAccount是Kubernetes中用于Pod访问API资源的身份。
kubectl create clusterrolebinding dashboard-admin --clusterrole=cluster-admin --serviceaccount=kube-system:dashboard-admin
#kubectl create：创建资源
#clusterrolebinding：用于将ClusterRole绑定到一个或多个服务账号、用户或者组，从而授予它们对集群中资源的访问权限
#dashboard-admin：创建的ClusterRoleBinding的自定义名称，在整个集群中必须是唯一的
#--clusterrole=cluster-admin：标志，用于指定要绑定的ClusterRole的名称
#--serviceaccount=kube-system:dashboard-admin：标志，用于指定服务账号的名称和命名空间
'命令含义'
#这个命令创建了一个ClusterRoleBinding，将cluster-admin这个ClusterRole绑定到kube-system命名空间中的dashboard-admin这个ServiceAccount上。
#cluster-admin是一个预定义的ClusterRole，它拥有集群中几乎所有的权限。这意味着与dashboard-admin这个ServiceAccount关联的Pod将能够执行集群中的任何操作。
2.6 列出令牌的详细信息
列出令牌详细信。获取token输出的内容，用于登录dashboard
kubectl describe secrets -n kube-system $(kubectl -n kube-system get secret | awk '/dashboard-admin/{print $1}')
#kubectl -n kube-system get secret：列出kube-system命名空间中的所有secrets。
'Secret 是 Kubernetes 中的一个资源对象，用于存储敏感信息，如密码、OAuth令牌和SSH密钥。
这些信息可以以明文或加密的形式存储在Secret中，通常它们会被Base64编码以符合Secret的数据格式'
#awk '/dashboard-admin/{print $1}'：
使用awk命令过滤输出，只打印与dashboard-adminServiceAccount相关的secret的名称
#默认是dashboard-admin-token-xxxxx，其中xxxxx是一个随机字符串。
kubectl describe secrets -n kube-system $(...)：
#使用上一步得到的secret名称，描述这个secret的详细信息。
#这通常包括secret的类型（在这种情况下是kubernetes.io/service-account-token），
#以及与ServiceAccount关联的token（这个token通常用于身份验证和授权）。3.登录Dashboard
3.1 访问界面
使用浏览器访问https://NodeIP:30001
3.2 创建pod
在shell环境使用命令查看
