文章目录
-
- 部署组件
- 方案概述
- 集群部署
- 集群初始化
- 安装NIC插件
- 添加Worker节点
- Metrics部署
- Helm部署
- [Nginx ingress部署](#Nginx ingress部署)
- Dashboard部署
- Longhorn存储部署
- Prometheus监控部署
-
- Prometheus简介
- 获取资源
- 创建prometheus持久卷
- 创建grafana持久卷
- nodeport暴露服务
- 策略配置
- 正式部署
- ingress暴露服务
-
- 创建secret
- [创建alertmanager-main ingress策略](#创建alertmanager-main ingress策略)
- [创建prometheus ingress策略](#创建prometheus ingress策略)
- [创建grafana ingress策略](#创建grafana ingress策略)
- 确认验证
- 配置grafana
- Prometheus相关指标
- Harbor仓库部署
部署组件
该 Kubernetes 部署过程中，对于部署环节，涉及多个组件，主要有 kubeadm 、kubelet 、kubectl。
提示：本文基于资源有限的情况下，使用三个节点部署Kubernetes，对于master而言，丧失了高可用。
kubeadm介绍
Kubeadm 为构建 Kubernetes 提供了便捷、高效的"最佳实践" ，该工具提供了初始化完整 Kubernetes 过程所需的组件，其主要命令及功能有：
- kubeadm init：用于搭建 Kubernetes 控制平面节点；
- kubeadm join：用于搭建 Kubernetes 工作节点并将其加入到集群中；
- kubeadm upgrade：用于升级 Kubernetes 集群到新版本；
- kubeadm token：用于管理 kubeadm join 使用的 token；
- kubeadm reset：用于恢复（重置）通过 kubeadm init 或者 kubeadm join 命令对节点进行的任何变更；
- kubeadm certs：用于管理 Kubernetes 证书；
- kubeadm kubeconfig：用于管理 kubeconfig 文件；
- kubeadm version：用于显示（查询）kubeadm 的版本信息；
- kubeadm alpha：用于预览当前从社区收集到的反馈中的 kubeadm 特性。
更多参考：Kubeadm介绍
kubelet介绍
kubelet 是 Kubernetes 集群中用于操作 Docker 、containerd 等容器运行时的核心组件，需要在每个节点运行。通常该操作是基于 CRI 实现，kubelet 和 CRI 交互，以便于实现对 Kubernetes 的管控。
kubelet 主要用于配置容器网络、管理容器数据卷等容器全生命周期，对于 kubelet 而言，其主要的功能核心有：
- Pod 更新事件；
- Pod 生命周期管理；
- 上报 Node 节点信息。
更多参考：kubelet介绍
kubectl介绍
kubectl 控制 Kubernetes 集群管理器，是作为 Kubernetes 的命令行工具，用于与 apiserver 进行通信，使用 kubectl 工具在 Kubernetes 上部署和管理应用程序。
使用 kubectl，可以检查群集资源的创建、删除和更新组件。
同时集成了大量子命令，可更便捷的管理 Kubernetes 集群，主要命令如下：
- Kubetcl -h：显示子命令；
- kubectl option：查看全局选项；
- kubectl <command> --help：查看子命令帮助信息；
- kubelet [command] [PARAMS] -o=<format>：设置输出格式，如json、yaml等；
- Kubetcl explain [RESOURCE]：查看资源的定义。
更多参考：kubectl介绍
方案概述
方案介绍
本方案基于 kubeadm 部署工具实现完整生产环境可用的 Kubernetes 高可用集群，同时提供相关 Kubernetes 周边组件。
其主要信息如下：
- 版本：Kubernetes 1.34.3 版本；
- kubeadm：采用 kubeadm 部署Kubernetes；
- OS：CentOS Stream 10；
- etcd：采用融合方式；
- 其他主要部署组件包括：
- Metrics：度量组件，用于提供相关监控指标；
- Dashboard：Kubernetes 集群的前端图形界面；
- Helm：Kubernetes Helm 包管理器工具，用于后续使用 helm 整合包快速部署应用；
- Ingress：Kubernetes 服务暴露应用，用于提供7层的负载均衡，类似 Nginx，可建立外部和内部的多个映射规则；
- kuboard：用于管理Kubernetes集群；
- Prometheus：普罗米修斯监控；
- harbor：镜像仓库；
- containerd：Kubernetes底层容器时；
- Longhorn：Kubernetes 动态存储组件，用于提供 Kubernetes 的持久存储。
提示：本方案部署所使用脚本均由本人提供，可能不定期更新。
部署规划
节点规划
| 节点主机名 | IP | 类型 | 运行服务 |
|---|---|---|---|
| master01 | 172.24.8.21 | Kubernetes master节点 | kubeadm、kubelet、kubectl、KeepAlived、HAProxy、containerd、etcd、kube-apiserver、kube-scheduler、kube-controller-manager、calico、WebUI、metrics、ingress、Longhorn ui节点 |
| worker01 | 172.24.8.22 | Kubernetes worker节点 | kubelet、containerd、calico、Longhorn存储节点、harbor、Prometheus、kuboard |
| worker02 | 172.24.8.23 | Kubernetes worker节点 | kubelet、containerd、calico、Longhorn存储节点、harbor、Prometheus、kuboard |
Kubernetes三节点板的etcd与Master节点组件位于同一个节点：
- 所需服务器节点资源少，具备超融合架构特点
- 部署简单，利于管理
- 容易进行横向扩展
- etcd复用Kubernetes的高可用
- 存在一定风险，这一台master主机挂了，master和etcd都异常，集群会崩溃
提示：本实验缺少高可用性，仅基于资源太少情况构建试验环境。
主机名配置
需要对所有节点主机名进行相应配置。
shell
[root@localhost ~]# hostnamectl set-hostname master01 #其他节点依次修改提示：如上需要在所有节点修改对应的主机名。
生产环境通常建议在内网部署dns服务器，使用dns服务器进行解析，本指南采用本地hosts文件名进行解析。
如下hosts文件修改仅需在master01执行，后续使用批量分发至其他所有节点。
shell
[root@master01 ~]# cat >> /etc/hosts << EOF
172.24.8.21 master01
172.24.8.22 worker01
172.24.8.23 worker02
EOF提示：如上仅需在master01节点上操作。
变量准备
为实现自动化部署，自动化分发相关文件，提前定义相关主机名、IP组、变量等。
shell
[root@master01 ~]# wget http://down.linuxsb.com/mydeploy/k8s/v1.34.3/c3nodesenv.sh
[root@master01 ~]# vi c3nodesenv.sh #确认相关主机名和IP
#!/bin/bash
#***************************************************************#
# ScriptName: c3nodesenv.sh
# Author: xhy
# Create Date: 2025-07-23 17:49
# Modify Author: xhy
# Modify Date: 2025-12-21 22:51
# Version: v1
#***************************************************************#
# 集群 MASTER 机器 IP 数组
export MASTER_IPS=(172.24.8.21)
# 集群 MASTER IP 对应的主机名数组
export MASTER_NAMES=(master01)
# 集群 NODE 机器 IP 数组
export NODE_IPS=(172.24.8.22 172.24.8.23)
# 集群 NODE IP 对应的主机名数组
export NODE_NAMES=(worker01 worker02)
# 集群所有机器 IP 数组
export ALL_IPS=(172.24.8.21 172.24.8.22 172.24.8.23)
# 集群所有IP 对应的主机名数组
export ALL_NAMES=(master01 worker01 worker02)提示：如上仅需在master01节点上操作。
互信配置
为了方便远程分发文件和执行命令，本方案配置master01节点到其它节点的 ssh信任关系，即免秘钥管理所有其他节点。
shell
[root@master01 ~]# source c3nodesenv.sh #载入变量
[root@master01 ~]# wget http://down.linuxsb.com/mydeploy/k8s/common/mkpublickey.sh
[root@master01 ~]# vim mkpublickey.sh #修改集群节点IP
#!/bin/bash
#***************************************************************#
# ScriptName: mkpublickey.sh
# Author: xhy
# Create Date: 2025-07-01 23:55
# Modify Author: xhy
# Modify Date: 2025-07-23 17:53
# Version: v1
#***************************************************************#
# 检查参数
if [ $# -ne 1 ]; then
echo "该脚本需要带上主机密码: $0 <密码>"
exit 1
fi
# 主机列表（直接内置）
HOSTS=(
172.24.8.21
172.24.8.22
172.24.8.23
)
PASSWORD=$1
#......
[root@master01 ~]# bash mkpublickey.sh redhat123提示：如上仅需在master01节点上操作。
环境初始化
kubeadm本身仅用于部署Kubernetes集群，在正式使用kubeadm部署Kubernetes集群之前需要对操作系统环境进行准备，即环境初始化准备。
环境的初始化准备本方案使用脚本自动完成。
使用如下脚本对基础环境进行初始化，主要功能包括：
- 安装containerd，Kubernetes平台底层的容器组件
- 关闭SELinux及防火墙
- 优化相关内核参数，针对生产环境Kubernetes集群的基础系统调优配置
- 关闭swap
- 设置相关模块，主要为转发模块
- 配置相关基础软件，部署Kubernetes集群所需要的基础依赖包
- 创建container所使用的独立目录
- 配置crictl和运行时的连接，便于后期使用crictl命令
提示：后续ctr命令下载镜像的时候，若需要使用containerd的加速，必须带上--hosts-dir，ctr当前环境所管理的镜像都属于k8s.io，因此创建一个别名。
shell
[root@master01 ~]# wget http://down.linuxsb.com/mydeploy/k8s/v1.34.3/ck8spreconfig.sh
[root@master01 ~]# vim ck8spreconfig.sh
#!/bin/bash
#***************************************************************#
# ScriptName: ck8spreconfig.sh
# Author: xhy
# Create Date: 2025-07-15 01:08
# Modify Author: xhy
# Modify Date: 2025-12-11 20:51
# Version: v1
#***************************************************************#
# openEuler OS
OPENEULER_OS=no
# Initialize the machine. This needs to be executed on every machine.
rm -f /var/lib/rpm/__db.00*
rpm -vv --rebuilddb
#yum clean all
#yum makecache
sleep 2s
# Install containerd
CONVERSION=2.2.0
yum -y install yum-utils device-mapper-persistent-data lvm2
yum-config-manager --add-repo https://mirrors.aliyun.com/docker-ce/linux/centos/docker-ce.repo
sudo sed -i 's+download.docker.com+mirrors.aliyun.com/docker-ce+' /etc/yum.repos.d/docker-ce.repo
if [ "$OPENEULER_OS" = "yes" ]; then
sed -i 's/\$releasever/9/g' /etc/yum.repos.d/docker-ce.repo
fi
sleep 2s
yum -y install containerd.io-${CONVERSION}
mkdir -p /etc/containerd/certs.d/docker.io
mkdir -p /data/containerd
cat > /etc/containerd/config.toml <<EOF
disabled_plugins = ["io.containerd.internal.v1.restart"]
root = "/data/containerd"
version = 2
[plugins]
[plugins."io.containerd.grpc.v1.cri"]
# sandbox_image = "registry.k8s.io/pause:3.10"
sandbox_image = "registry.aliyuncs.com/google_containers/pause:3.10"
[plugins."io.containerd.grpc.v1.cri".containerd]
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes]
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc]
runtime_type = "io.containerd.runc.v2"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.runc.options]
SystemdCgroup = true
[plugins."io.containerd.grpc.v1.cri".registry]
config_path = "/etc/containerd/certs.d"
[plugins."io.containerd.runtime.v1.linux"]
shim_debug = true
EOF
cat > /etc/containerd/certs.d/docker.io/hosts.toml <<EOF
server = "https://registry-1.docker.io"
[host."https://image.cloudlayer.icu"]
capabilities = ["pull", "resolve", "push"]
[host."https://docker.sunzishaokao.com"]
capabilities = ["pull", "resolve", "push"]
[host."https://docker.m.daocloud.io"]
capabilities = ["pull", "resolve", "push"]
[host."https://docker.1ms.run"]
capabilities = ["pull", "resolve", "push"]
[host."https://docker.hlmirror.com"]
capabilities = ["pull", "resolve", "push"]
[host."https://docker.melikeme.cn"]
capabilities = ["pull", "resolve", "push"]
EOF
# config crictl & containerd
cat > /etc/crictl.yaml <<EOF
runtime-endpoint: unix:///run/containerd/containerd.sock
image-endpoint: unix:///run/containerd/containerd.sock
timeout: 10
debug: false
EOF
echo 'alias ctrpull="ctr -n k8s.io images pull --hosts-dir /etc/containerd/certs.d"' >> /etc/profile.d/ctr_bash.sh
systemctl restart containerd
systemctl enable containerd --now
# Disable the SELinux.
sed -i 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config
# Turn off and disable the firewalld.
systemctl stop firewalld
systemctl disable firewalld
# Modify related kernel parameters & Disable the swap.
cat > /etc/sysctl.d/k8s.conf << EOF
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
vm.swappiness = 0
vm.overcommit_memory = 1
vm.panic_on_oom = 0
net.ipv6.conf.all.disable_ipv6 = 1
EOF
sysctl -p /etc/sysctl.d/k8s.conf >&/dev/null
swapoff -a
sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab
echo -e "#/bin/bash \nswapoff -a" > /etc/profile.d/disabled_swap.sh
# Add ipvs modules
cat > /etc/modules-load.d/ipvs.conf <<EOF
ip_vs
ip_vs_rr
ip_vs_wrr
ip_vs_sh
nf_conntrack
br_netfilter
overlay
xt_CT
EOF
sysctl --system
systemctl restart systemd-modules-load.service
# Install rpm
yum install -y conntrack curl ipvsadm iproute-tc ipset iptables jq libseccomp pcre2 pcre2-devel sysstat wget提示：containerd 镜像加速配置更多可参考：
containerd配置镜像加速器
containerd官方加速配置
提示：如上仅需在master01节点上操作，建议初始化完后进行重启。
- 执行初始化配置
执行批量初始化。
shell
[root@master01 ~]# source c3nodesenv.sh
[root@master01 ~]# chmod +x *.sh
[root@master01 ~]# for all_ip in ${ALL_IPS[@]}
do
echo -e "\n\n\033[33m[INFO] >>> ${all_ip}...\033[0m"
sleep 2
scp -rp /etc/hosts root@${all_ip}:/etc/hosts
scp -rp ck8spreconfig.sh root@${all_ip}:/root/
ssh root@${all_ip} "bash /root/ck8spreconfig.sh"
done提示：如上仅需在master01节点上操作。
Cgroup v2开启
建议开启cgroup v2特性，同时确认cpuset在内核中存在，部分高版本可能此内核需要手动打开，更多cgroup v2知识参考： 升级systemd并启用cgroup v2 容器新体验 - Rootless Container + cgroup V2
shell
[root@master01 ~]# source c3nodesenv.sh
[root@master01 ~]# for all_ip in ${ALL_IPS[@]}
do
echo -e "\n\n\033[33m[INFO] >>> ${all_ip}...\033[0m"
ssh root@${all_ip} "grep cgroup /proc/filesystems"
ssh root@${all_ip} "sed -i 's/GRUB_CMDLINE_LINUX=\"/GRUB_CMDLINE_LINUX=\"systemd.unified_cgroup_hierarchy=1 /g' /etc/default/grub"
ssh root@${all_ip} "grub2-mkconfig -o /boot/grub2/grub.cfg"
done提示：如上仅需在master01节点上操作。
验证预配置
验证所有预配置，并建议在全部节点重启一次后进行检查。
重启所有节点，然后等待所有节点重新启动，并验证 cgroup v2 的启用。
shell
[root@master01 ~]# source c3nodesenv.sh
[root@master01 ~]# for all_ip in ${ALL_IPS[@]}
do
echo -e "\n\n\033[33m[INFO] >>> ${all_ip}...\033[0m"
sleep 1
ssh root@${all_ip} "nohup bash -c 'sleep 10; shutdown -r now' >/dev/null 2>&1 </dev/null &"
done重启后如下方式进行验证。
shell
[root@master01 ~]# source c3nodesenv.sh
[root@master01 ~]# for all_ip in ${ALL_IPS[@]}
do
echo -e "\n\n\033[33m[INFO] >>> ${all_ip}...\033[0m"
sleep 2
ssh root@${all_ip} "getenforce"
ssh root@${all_ip} "systemctl status firewalld containerd | grep -E 'service|Active'"
ssh root@${all_ip} "lsmod | grep -E 'ip|nf_conn*'"
ssh root@${all_ip} "cat /proc/cgroups | grep cpuset"
ssh root@${all_ip} "mount | grep cgroup"
ssh root@${all_ip} "stat -fc %T /sys/fs/cgroup/"
done提示：如上仅需在master01节点上操作。
创建配置文件
创建集群部署所需的相关组件配置，采用脚本自动化创建相关配置文件。
shell
[root@master01 ~]# wget http://down.linuxsb.com/mydeploy/k8s/v1.34.3/c3k8sconfig.sh #拉取自动部署脚本
[root@master01 ~]# vim c3k8sconfig.sh #确认相关配置
#!/bin/bash
#***************************************************************#
# ScriptName: c3k8sconfig.sh
# Author: xhy
# Create Date: 2025-03-29 13:01
# Modify Author: xhy
# Modify Date: 2025-12-21 23:02
# Version: v1
#***************************************************************#
#######################################
# 全局变量配置区
#######################################
echo -e "\n\033[33m[INFO] 开始定义全局参数...\033[0m"
sleep 1
declare -A NODES=(
[master01]="172.24.8.21"
[master02]="172.24.8.22"
[master03]="172.24.8.23"
)
# 公共参数
K8SHA_VERSION=v1.34.3
K8SHA_VIP="${NODES[master01]}"
K8SHA_PORT="6443"
K8SHA_AUTH="ilovek8s"
K8SHA_PODCIDR="10.10.0.0/16"
K8SHA_SVCCIDR="10.20.0.0/16"
K8SHA_DNSIP="10.20.0.10"
K8SHA_NETINF="eth0"
echo -e "\n\033[32m[SUCCESS] 全局参数定义已完成...\033[0m"
#......执行配置文件自动生成脚本。
shell
[root@master01 ~]# bash c3k8sconfig.sh解释：如上操作仅需Master01上执行，执行c3k8sconfig.sh脚本后会在当前目录的k8sdir下生成如下配置文件清单：
- kubeadm-config.yaml：kubeadm初始化配置文件，位于kubeadm/目录，可参考 kubeadm 配置
集群部署
相关组件包
需要在每台机器上都安装以下的软件包：
- kubeadm: 用来初始化集群的指令；
- kubelet: 在集群中的每个节点上用来启动 pod 和 container 等；
- kubectl: 用来与集群通信的命令行工具。
kubeadm不能安装或管理 kubelet 或 kubectl ，因此在初始化集群之前必须完成kubelet和kubectl的安装，且能保证他们满足通过 kubeadm 安装的 Kubernetes控制层对版本的要求。
如果版本没有满足匹配要求，可能导致一些意外错误或问题。
具体相关组件安装见；附001.kubectl介绍及使用书
提示 ：Kubernetes 1.34.3 版本所有兼容相应组件的版本参考：https://github.com/kubernetes/kubernetes/blob/master/CHANGELOG/CHANGELOG-1.34.md
正式安装
快速安装所有节点的kubeadm、kubelet、kubectl组件。
shell
[root@master01 ~]# for all_ip in ${ALL_IPS[@]}
do
echo -e "\n\n\033[33m[INFO] >>> ${all_ip}...\033[0m"
ssh root@${all_ip} "cat <<EOF | sudo tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes-new/core/stable/v1.34/rpm/
enabled=1
gpgcheck=1
gpgkey=https://mirrors.aliyun.com/kubernetes-new/core/stable/v1.34/rpm/repodata/repomd.xml.key
EOF"
ssh root@${all_ip} "yum install -y kubelet-1.34.3 kubectl-1.34.3 kubeadm-1.34.3 --disableexcludes=kubernetes"
ssh root@${all_ip} "systemctl enable kubelet"
done
[root@master01 ~]# yum search -y kubelet --showduplicates #查看相应版本 提示：如上仅需Master01节点操作，从而实现所有节点自动化安装，同时此时不需要启动kubelet，初始化的过程中会自动启动的，如果此时启动了会出现报错，忽略即可。
说明 ：同时安装了cri-tools, kubernetes-cni, socat三个依赖：
socat：kubelet的依赖；
cri-tools：即CRI(Container Runtime Interface)容器运行时接口的命令行工具。
集群初始化
预配置检查
使用 c3k8sconfig.sh 创建配置的时候会创建主要如下配置文件，集群初始化之前建议再次检查和确认集群配置文件。
- kubeadm-config.yaml：kubeadm初始化配置文件，位于kubeadm/目录，设置了Kubernetes版本、Pod IP段、SVC IP段、nodeport端口范围等，可参考 kubeadm 配置
shell
[root@master01 ~]# cat k8sdir/init/kubeadm-config.yaml #检查集群初始化配置
# =========================
# 1) 集群级配置（全局）
# =========================
apiVersion: kubeadm.k8s.io/v1beta4
kind: ClusterConfiguration
kubernetesVersion: "v1.34.3" # 要部署的 Kubernetes 主版本，kubeadm 会按此拉取镜像/生成静态 Pod
controlPlaneEndpoint: "172.24.8.21:6443" # 所有 apiserver 对外统一访问入口（通常是 VIP+端口，用于高可用）
imageRepository: registry.aliyuncs.com/google_containers # 核心组件镜像仓库前缀，国内环境常用阿里云镜像避免拉取失败
networking:
serviceSubnet: "10.20.0.0/16" # Service 虚拟 IP 网段（ClusterIP），初始化后不可随意修改
podSubnet: "10.10.0.0/16" # Pod 网段，必须与 CNI 插件配置一致
dnsDomain: "cluster.local" # 集群内 DNS 根域名，Service 会以 xxx.namespace.svc.cluster.local 形式解析
etcd:
local:
dataDir: "/data/etcd" # 本地 etcd 数据目录，注意磁盘性能与可靠性（建议独立磁盘或 SSD）
apiServer:
certSANs: # 为 apiserver 证书增加的额外 Subject Alt Name，保证通过这些地址访问证书不报错
- localhost
- 127.0.0.1
- master01
- 172.24.8.21
extraArgs: # 传给 kube-apiserver 的额外命令行参数（v1beta4 推荐用 name/value 列表）
- name: service-node-port-range
value: "80-65535" # NodePort 可开放的端口范围，默认 30000-32767，这里扩展到 80-65535 方便对外暴露服务
- name: default-not-ready-toleration-seconds
value: "180" # Pod 默认对 NotReady 节点的容忍时间，超过后才会重新调度（降低短暂抖动影响）
- name: default-unreachable-toleration-seconds
value: "180" # Pod 默认对 Unreachable 节点的容忍时间，超过后认为节点不可达并触发重调度
controllerManager:
extraArgs: # 传给 kube-controller-manager 的额外参数
- name: node-monitor-period
value: "3s" # controller manager 检查节点状态的周期（心跳检测间隔），默认 5s
- name: node-monitor-grace-period
value: "30s" # 允许节点在多长时间内不汇报心跳仍被视为存活，过期后判定为 NotReady/Unknown
certificatesDir: "/etc/kubernetes/pki" # 存放集群证书和密钥的目录（kubeadm 默认也是此路径）
# clusterName: "example-cluster" # 集群名称，不写默认为 "kubernetes"，用于区分多集群场景
---
# =========================
# 2) init 当前节点配置: 只在 kubeadm init 这台 master01 上用
# =========================
apiVersion: kubeadm.k8s.io/v1beta4
kind: InitConfiguration
localAPIEndpoint:
advertiseAddress: 172.24.8.21 # 当前 master01 对外通告的 apiserver IP（该节点自身的管理网 IP）
bindPort: 6443 # apiserver 在本机监听的端口，通常保持默认 6443
nodeRegistration:
name: master01 # 该节点在集群中的名称（默认为主机名，显式指定更清晰）
criSocket: /var/run/containerd/containerd.sock # 指定容器运行时的 CRI socket，使用 containerd 时为此路径
kubeletExtraArgs: # 传给 kubelet 的附加参数（key/value 形式）
- name: cgroup-driver
value: systemd # kubelet 使用的 cgroup 驱动，需与容器运行时和系统配置一致（推荐 systemd）
---
# =========================
# 3) kubelet 配置（全局模板）
# =========================
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration # kubelet 的全局配置模板，kubeadm 会写入每个节点的 /var/lib/kubelet/config.yaml
cgroupDriver: systemd # kubelet 默认 cgroup 驱动，建议与 systemd 对齐，便于资源管理和稳定性
imageGCHighThresholdPercent: 95 # 触发镜像垃圾回收的上限百分比，磁盘使用超过此值开始删旧镜像
imageGCLowThresholdPercent: 90 # GC 回收到低于该百分比后停止，95→90 避免频繁回收/加载引起抖动
podSandboxImage: registry.aliyuncs.com/google_containers/pause:3.10.1
---
# =========================
# 4) kube-proxy 配置
# =========================
apiVersion: kubeproxy.config.k8s.io/v1alpha1 # kube-proxy 配置 API 版本
kind: KubeProxyConfiguration # kube-proxy 的配置对象
mode: ipvs # 使用 IPVS 模式，实现 Service 负载均衡（性能和功能优于 iptables 模式）Kubernetes默认的端口范围为30000-32767，为便于后期大量的应用，建议做端口扩展，如ingress的80、443端口，然后开放全部高端口号。
同时开放全端口范围后，使用的时候需要注意外部应用端口和Kubernetes使用的nodeport端口冲突的情况。
提示 ：更多config文件参考：kubeadm 配置 (v1beta4)
默认kubeadm配置可使用kubeadm config print init-defaults > config.yaml生成。
Master01上初始化
Master01节点上执行初始化，即完成单节点的Kubernetes，其他节点采用添加的方式部署。
提示 ：kubeadm init过程会执行系统预检查，预检查通过则继续init，也可以提前执行如下命令进行预检查操作： kubeadm init phase preflight
shell
[root@master01 ~]# kubeadm init --config=k8sdir/init/kubeadm-config.yaml --upload-certs #保留如下命令用于后续节点添加
[init] Using Kubernetes version: v1.34.3
[preflight] Running pre-flight checks
[preflight] Pulling images required for setting up a Kubernetes cluster
[preflight] This might take a minute or two, depending on the speed of your internet connection
[preflight] You can also perform this action beforehand using 'kubeadm config images pull'
[certs] Using certificateDir folder "/etc/kubernetes/pki"
[certs] Generating "ca" certificate and key
[certs] Generating "apiserver" certificate and key
[certs] apiserver serving cert is signed for DNS names [kubernetes kubernetes.default kubernetes.default.svc kubernetes.default.svc.cluster.local localhost master01 master02 master03] and IPs [10.20.0.1 172.24.8.21 172.24.8.100 127.0.0.1 172.24.8.23 172.24.8.22]
......
Your Kubernetes control-plane has initialized successfully!
To start using your cluster, you need to run the following as a regular user:
mkdir -p $HOME/.kube
sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
sudo chown $(id -u):$(id -g) $HOME/.kube/config
Alternatively, if you are the root user, you can run:
export KUBECONFIG=/etc/kubernetes/admin.conf
You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
https://kubernetes.io/docs/concepts/cluster-administration/addons/
You can now join any number of control-plane nodes running the following command on each as root:
kubeadm join 172.24.8.21:6443 --token p4bbey.sisuvvyfid4pydj5 \
--discovery-token-ca-cert-hash sha256:d7109b7f1af3e02ae98432350006c6a9fafa347f8d19d494cd4e0f2a061f7f0e \
--control-plane --certificate-key 5dc870735fdaa18352ddda81f4a19200224d1f0f6c7f6482c625ca56c7d8ed76
Please note that the certificate-key gives access to cluster sensitive data, keep it secret!
As a safeguard, uploaded-certs will be deleted in two hours; If necessary, you can use
"kubeadm init phase upload-certs --upload-certs" to reload certs afterward.
Then you can join any number of worker nodes by running the following on each as root:
kubeadm join 172.24.8.21:6443 --token p4bbey.sisuvvyfid4pydj5 \
--discovery-token-ca-cert-hash sha256:d7109b7f1af3e02ae98432350006c6a9fafa347f8d19d494cd4e0f2a061f7f0e注意 ：如上token具有默认24小时的有效期，token和hash值可通过如下方式获取：
kubeadm token list
如果 Token 过期以后，可以输入以下命令，生成新的 Token:
shell
kubeadm token create
openssl x509 -pubkey -in /etc/kubernetes/pki/ca.crt | openssl rsa -pubin -outform der 2>/dev/null | openssl dgst -sha256 -hex | sed 's/^.* //'附加：初始化过程大致步骤如下：
-
certs\]：生成相关的各种证书
-
etcd\]：创建ETCD的静态Pod
-
kubeconfig\]：生成相关的kubeconfig文件
-
addons\]：附带的相关插件
添加kubectl环境
给所有master节点创建相关Kubernetes集群配置文件保存目录，以及相关登录凭证，kubectl命令补全等。
shell
[root@master01 ~]# source c3nodesenv.sh
[root@master01 ~]# for master_ip in "${MASTER_IPS[@]}"; do
echo -e "\n\n\033[33m[INFO] >>> ${master_ip}...\033[0m"
ssh -T root@${master_ip} << 'EOF'
mkdir -p $HOME/.kube
cp -f /etc/kubernetes/admin.conf $HOME/.kube/config
chown $(id -u):$(id -g) $HOME/.kube/config
cat << EOB > /etc/profile.d/custom_kubectl.sh
export KUBECONFIG=\$HOME/.kube/config
source <(kubectl completion bash)
EOB
chmod 644 /etc/profile.d/custom_kubectl.sh
EOF
done
[root@master01 ~]# source /etc/profile安装NIC插件
NIC插件介绍
- Calico 是一个安全的 L3 网络和网络策略提供者。
- Canal 结合 Flannel 和 Calico， 提供网络和网络策略。
- Cilium 是一个 L3 网络和网络策略插件， 能够透明的实施 HTTP/API/L7 策略。 同时支持路由（routing）和叠加/封装（ overlay/encapsulation）模式。
- Contiv 为多种用例提供可配置网络（使用 BGP 的原生 L3，使用 vxlan 的 overlay，经典 L2 和 Cisco-SDN/ACI）和丰富的策略框架。Contiv 项目完全开源。安装工具同时提供基于和不基于 kubeadm 的安装选项。
- Flannel 是一个可以用于 Kubernetes 的 overlay 网络提供者。
+Romana 是一个 pod 网络的层 3 解决方案，并且支持 NetworkPolicy API。Kubeadm add-on 安装细节可以在这里找到。 - Weave Net 提供了在网络分组两端参与工作的网络和网络策略，并且不需要额外的数据库。
- CNI-Genie 使 Kubernetes 无缝连接到一种 CNI 插件，例如：Flannel、Calico、Canal、Romana 或者 Weave。
提示 ：本方案使用Calico插件。更多calico介绍参考：About Calico 。
镜像准备
建议提前安装后续部署所需镜像，可通过如下使用加速器的脚本，在各节点提前将镜像下载。
- 镜像列表
shell
[root@master01 ~]# cat >> images.list<EOF
quay.io/calico/apiserver:v3.31.2
quay.io/calico/cni:v3.31.2
quay.io/calico/csi:v3.31.2
quay.io/calico/goldmane:v3.31.2
quay.io/calico/kube-controllers:v3.31.2
quay.io/calico/node-driver-registrar:v3.31.2
quay.io/calico/node:v3.31.2
quay.io/calico/pod2daemon-flexvol:v3.31.2
quay.io/calico/typha:v3.31.2
quay.io/calico/whisker-backend:v3.31.2
quay.io/calico/whisker:v3.31.2
EOF- 脚本下载
该脚本支持docker和containerd，默认为containerd。
shell
[root@master01 ~]# wget https://down.linuxsb.com/myshell/js_pull_lists_images.sh
[root@master01 ~]# for all_ip in ${ALL_IPS[@]}
do
echo -e "\n\n\033[33m[INFO] >>> ${all_ip}...\033[0m"
sleep 1
scp -rp js_pull_lists_images.sh images.list root@${all_ip}:/root/
ssh root@${all_ip} "chmod u+x /root/js_pull_lists_images.sh"
ssh root@${all_ip} "nohup bash -c '/root/js_pull_lists_images.sh' >/dev/null 2>&1 </dev/null &"
done提示：如上仅需在 master01 节点执行。
部署calico
确认相关配置，如MTU，网卡接口，Pod的IP地址段。
calico支持operator和manifests方式部署，本方案operator部署，对于manifests也也可参考：https://raw.githubusercontent.com/projectcalico/calico/v3.31.2/manifests/calico.yaml
| 维度 | Operator 模式 | Manifest 模式 |
|---|---|---|
| 管理方式 | 通过 Kubernetes Operator 动态管理 Calico 生命周期 | 通过静态 YAML 文件直接部署资源 |
| 适用场景 | 生产环境、需要自动化运维和高级功能（如自动升级、配置热更新） | 快速部署、测试环境、需要完全手动控制配置的场合 |
| 复杂度 | 较高（需理解 CRD 和 Operator 逻辑） | 较低（直接应用 YAML） |
| 灵活性 | 高（通过 CRD 动态调整配置） | 中（需手动修改 YAML 并重新部署） |
| 升级维护 | 自动化升级（Operator 负责版本迁移） | 手动升级（需下载新版本 Manifest 并重新应用） |
| 监控与自愈 | 内置健康检查和故障恢复机制 | 依赖 Kubernetes 原生机制（如 livenessProbe） |
Operator相对Manifest有如下优势：
- 自动证书轮换
- 配置热更新
- 多版本兼容管理
- 细粒度组件监控指标
- 一键式集群扩展
shell
[root@master01 ~]# kubectl apply -f https://raw.githubusercontent.com/projectcalico/calico/v3.31.2/manifests/tigera-operator.yaml
[root@master01 ~]# mkdir calico
[root@master01 ~]# cd calico/
[root@master01 calico]# wget https://raw.githubusercontent.com/projectcalico/calico/v3.31.2/manifests/custom-resources.yaml
[root@master01 calico]# vim custom-resources.yaml
#......
apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
name: default
spec:
# Configures Calico networking.
calicoNetwork:
mtu: 1450 #根据实际情况配置mtu
nodeAddressAutodetectionV4:
interface: "eth0" #建议指定网卡
ipPools:
- name: default-ipv4-ippool
blockSize: 26
cidr: 10.10.0.0/16 #配置网段，kubeadm匹配
#......
[root@master01 calico]# kubectl apply -f custom-resources.yaml提示：其他配置建议保持默认，MTU建议为网卡当前MTU减去50。
shell
[root@master01 calico]# kubectl get pods --all-namespaces -o wide #查看部署的所有Pod
NAMESPACE NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
calico-system calico-apiserver-55466bcd8f-2n6rk 1/1 Running 0 47s 10.10.241.72 master01 <none> <none>
calico-system calico-apiserver-55466bcd8f-rntjl 1/1 Running 0 47s 10.10.241.66 master01 <none> <none>
calico-system calico-kube-controllers-7d967b579b-p6bwl 1/1 Running 0 46s 10.10.241.67 master01 <none> <none>
calico-system calico-node-vjgsm 1/1 Running 0 47s 172.24.8.21 master01 <none> <none>
calico-system calico-typha-5b44fbff7-zxwnx 1/1 Running 0 47s 172.24.8.21 master01 <none> <none>
calico-system csi-node-driver-cfj8p 2/2 Running 0 46s 10.10.241.65 master01 <none> <none>
calico-system goldmane-76cd845459-kghkq 1/1 Running 0 47s 10.10.241.70 master01 <none> <none>
calico-system whisker-dc98c8747-q6s24 2/2 Running 0 27s 10.10.241.73 master01 <none> <none>
kube-system coredns-7cc97dffdd-pz8fc 1/1 Running 0 3m22s 10.10.241.71 master01 <none> <none>
kube-system coredns-7cc97dffdd-qfmfn 1/1 Running 0 3m22s 10.10.241.69 master01 <none> <none>
kube-system etcd-master01 1/1 Running 0 3m29s 172.24.8.21 master01 <none> <none>
kube-system kube-apiserver-master01 1/1 Running 0 3m29s 172.24.8.21 master01 <none> <none>
kube-system kube-controller-manager-master01 1/1 Running 0 3m30s 172.24.8.21 master01 <none> <none>
kube-system kube-proxy-jr4q6 1/1 Running 0 3m22s 172.24.8.21 master01 <none> <none>
kube-system kube-scheduler-master01 1/1 Running 0 3m29s 172.24.8.21 master01 <none> <none>
tigera-operator tigera-operator-675679649b-6wqpq 1/1 Running 0 2m6s 172.24.8.21 master01 <none> <none>
[root@master01 calico]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
master01 Ready control-plane 3m42s v1.34.3提示：官方calico参考：https://docs.projectcalico.org/manifests/calico.yaml
添加Worker节点
添加Worker节点
shell
[root@master01 ~]# source c3nodesenv.sh
[root@master01 ~]# for node_ip in ${NODE_IPS[@]}
do
echo -e "\n\n\033[33m[INFO] >>> ${node_ip}...\033[0m"
ssh root@${node_ip} "kubeadm join 172.24.8.21:6443 --token p4bbey.sisuvvyfid4pydj5 \
--discovery-token-ca-cert-hash sha256:d7109b7f1af3e02ae98432350006c6a9fafa347f8d19d494cd4e0f2a061f7f0e"
ssh root@${node_ip} "systemctl enable kubelet.service"
done提示：如上仅需Master01节点操作，从而实现所有Worker节点添加至集群，若添加异常可通过如下方式重置：
shell
[root@worker01 ~]# kubeadm reset
[root@worker01 ~]# ifconfig kube-ipvs0 down
[root@worker01 ~]# ip link delete kube-ipvs0
[root@worker01 ~]# ifconfig tunl0@NONE down
[root@worker01 ~]# ip link delete tunl0@NONE
[root@worker01 ~]# rm -rf /var/lib/cni/确认验证
shell
[root@master01 ~]# kubectl get nodes #节点状态
[root@master01 ~]# kubectl get serviceaccount #服务账户
[root@master01 ~]# kubectl cluster-info #集群信息
[root@master01 ~]# kubectl get pod -n kube-system -o wide #所有服务状态
提示 ：更多Kubetcl使用参考：https://kubernetes.io/docs/reference/kubectl/kubectl/
https://kubernetes.io/docs/reference/kubectl/overview/
更多kubeadm使用参考：https://kubernetes.io/docs/reference/setup-tools/kubeadm/kubeadm/
Metrics部署
Metrics介绍
在Kubernetes新的监控体系中，Metrics Server用于提供核心指标（Core Metrics），包括Node、Pod的CPU和内存使用指标，对其他自定义指标（Custom Metrics）的监控则由Prometheus等组件来完成。
Metrics Server是一个可扩展的、高效的容器资源度量，通常可用于Kubernetes内置的自动伸缩，即自动伸缩可依据metrics的度量指标。
Metrics Server从Kubelets收集资源指标，并通过Metrics API将它们暴露在Kubernetes apisserver中，供Pod水平或垂直自动伸缩使用。
kubectl top也可以访问Metrics API，可查看相关对象资源使用情况。
提示：当前官方建议Metrics Server仅用于自动伸缩，不要使用它来当做对Kubernetes的监控解决方案，或者监控解决方案的上游来源，对于完整的Kubernetes监控方案，可直接从Kubelet的/metrics/resource endpoint收集指标。
Metrics Server建议场景
- 使用Metrics Server的场景:
- 基于CPU/内存的水平快速自动缩放；
- 自动调整/建议容器所需的资源。
Metrics Server不建议场景
不建议使用Metrics Server的场景:
- 非Kubernetes集群；
- 集群资源对象资源消耗的准确依据；
- 基于CPU/内存以外的其他资源的水平自动缩放。
对于整个集群的准备监控，可参考 Prometheus 。
Metrics特点
Metrics Server主要特点:
- 在大多数集群上可以以单Pod工作；
- 快速自动伸缩，且每15秒收集一次指标；
- 资源消耗极低，在集群中每个节点上仅需1分片CPU和2 MB内存；
- 可扩展支持最多5000个节点集群。
Metrics需求
Metrics Server对集群和网络配置有特定的需求依赖，这些需求依赖并不是所有集群默认开启的。
在使用Metrics Server之前，需要确保集群支持这些需求：
- kube-apiserver必须启用聚合层（aggregation layer）；
- 节点必须启用Webhook身份验证和授权；
- Kubelet证书需要由集群证书颁发机构签名(或者通过向Metrics Server传递--kubelet-insecure-tls禁用证书验证)；
- 容器运行时必须实现容器度量rpc(或有cAdvisor支持)；
- 网络应支持以下通信:
- 控制平面到Metrics Server通信要求：控制平面节点需要到达Metrics Server的pod IP和端口10250(如果hostNetwork开启，则可以是自定义的node IP和对应的自定义端口，保持通信即可）；
- Metrics Server到所有节点的Kubelete通信要求：Metrics Server需要到达node节点地址和Kubelet端口。地址和端口在Kubelet中配置，并作为Node对象的一部分发布。.status.address和.status.daemonEndpoints.kubeletEndpoint.port定义地址和端口（默认10250）。Metrics Server将根据kubelet-preferred-address-types命令行标志提供的列表选择第一个节点地址（默认InternalIP，ExternalIP，Hostname）。
获取部署文件
根据实际生产环境，对Metrics Server的部署进行个性化修改，其他保持默认即可。
主要涉及：部署副本数为3，追加--kubelet-insecure-tls配置。
shell
[root@master01 ~]# mkdir metrics
[root@master01 ~]# cd metrics/
[root@master01 metrics]# wget https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml
[root@master01 metrics]# vi components.yaml
......
apiVersion: apps/v1
kind: Deployment
# ......
spec:
replicas: 1 #根据集群规模调整副本数
# ......
spec:
containers:
- args:
- --cert-dir=/tmp
- --kubelet-insecure-tls #自签名证书场景必须追加此行
# ......
image: registry.aliyuncs.com/google_containers/metrics-server:v0.8.0 #使用阿里云镜像
imagePullPolicy: IfNotPresent
# ......提示 ：，metrics-server 官方默认配置中 --secure-port 为 10250，这会导致如果部署的时候配置了 hostNetwork: true ，则 metrics-server 会直接在宿主机网络上监听 10250，就会和 kubelet 的 10250 冲突，则需要修改此端口。
正式部署
shell
[root@master01 metrics]# kubectl apply -f components.yaml
[root@master01 metrics]# kubectl -n kube-system get pods -l k8s-app=metrics-server -o wide
NAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES
metrics-server-7bffb549c5-h9b54 1/1 Running 0 35s 10.10.30.67 worker02 <none> <none>查看资源监控
可使用kubectl top查看相关监控项。
shell
[root@master01 ~]# kubectl top nodes
[root@master01 ~]# kubectl top pods --all-namespaces
提示 ：Metrics Server提供的数据也可以供HPA控制器使用，以实现基于CPU使用率或内存使用值的Pod自动扩缩容功能。
有关metrics更多部署参考：
资源指标管道
Kubernetes API 聚合层
配置聚合层
Helm部署
helm介绍
Helm 是 Kubernetes 的软件包管理工具。包管理器类似 Ubuntu 中使用的apt、Centos中使用的yum 或者Python中的 pip 一样，能快速查找、下载和安装软件包。通常每个包称为一个Chart，一个Chart是一个目录（一般情况下会将目录进行打包压缩，形成name-version.tgz格式的单一文件，方便传输和存储）。
Helm 由客户端组件 helm 和服务端组件 Tiller 组成, 能够将一组K8S资源打包统一管理, 是查找、共享和使用为Kubernetes构建的软件的最佳方式。
Helm优势
在 Kubernetes中部署一个可以使用的应用，需要涉及到很多的 Kubernetes 资源的共同协作。
如安装一个 WordPress 博客，用到了一些 Kubernetes 的一些资源对象。包括 Deployment 用于部署应用、Service 提供服务发现、Secret 配置 WordPress 的用户名和密码，可能还需要 pv 和 pvc 来提供持久化服务。并且 WordPress 数据是存储在mariadb里面的，所以需要 mariadb 启动就绪后才能启动 WordPress。这些 k8s 资源过于分散，不方便进行管理。
基于如上场景，在 k8s 中部署一个应用，通常面临以下几个问题：
如何统一管理、配置和更新这些分散的 k8s 的应用资源文件；
如何分发和复用一套应用模板；
如何将应用的一系列资源当做一个软件包管理。
对于应用发布者而言，可以通过 Helm 打包应用、管理应用依赖关系、管理应用版本并发布应用到软件仓库。
对于使用者而言，使用 Helm 后不用需要编写复杂的应用部署文件，可以以简单的方式在 Kubernetes 上查找、安装、升级、回滚、卸载应用程序。
前置准备
Helm 将使用 kubectl 在已配置的集群上部署 Kubernetes 资源，因此需要如下前置准备：
- 正在运行的 Kubernetes 集群；
- 预配置的 kubectl 客户端和 Kubernetes 集群正确交互。
二进制安装Helm
建议采用二进制安装helm。
shell
[root@master01 ~]# mkdir helm
[root@master01 ~]# cd helm/
[root@master01 helm]# HELMVERSION=v3.19.0
[root@master01 helm]# wget https://repo.huaweicloud.com/helm/${HELMVERSION}/helm-${HELMVERSION}-linux-amd64.tar.gz
[root@master01 helm]# tar -zxvf helm-${HELMVERSION}-linux-amd64.tar.gz
[root@master01 helm]# cp linux-amd64/helm /usr/local/bin/
[root@master01 helm]# helm version #查看安装版本
[root@master01 helm]# echo 'source <(helm completion bash)' > /etc/profile.d/custom_helm.sh #helm自动补全
[root@master01 helm]# source /etc/profile提示 ：更多安装方式参考官方手册： Installing Helm
Helm操作
查找chart
helm search：可以用于搜索两种不同类型的源。
helm search hub：搜索 Helm Hub，该源包含来自许多不同仓库的Helm chart。
helm search repo：搜索已添加到本地头helm客户端（带有helm repo add）的仓库，该搜索是通过本地数据完成的，不需要连接公网。
shell
[root@master01 ~]# helm search hub #可搜索全部可用chart
[root@master01 ~]# helm search hub wordpress添加repo
类似CentOS添加yum源，可以给helm仓库添加相关源。
shell
[root@master01 ~]# helm repo list #查看repo
[root@master01 ~]# helm repo add azure https://mirror.azure.cn/kubernetes/charts
[root@master01 ~]# helm repo add aliyun https://kubernetes.oss-cn-hangzhou.aliyuncs.com/charts
[root@master01 ~]# helm search repo azure
[root@master01 ~]# helm search repo aliyun
[root@master01 ~]# helm repo update #更新repo的chart提示 ：bitnami chart更多信息参考：Kubernetes Bitnami chart
提示 ：更多helm知识可参考： Kubernetes集群管理-Helm部署及使用 。
Nginx ingress部署
ingress介绍
Kubernetes中的应用通常以Service对外暴露，而Service的表现形式为IP:Port，即工作在TCP/IP层。
对于基于HTTP的服务来说，不同的URL地址经常对应到不同的后端服务（RS）或者虚拟服务器（Virtual Host），这些应用层的转发机制仅通过Kubernetes的Service机制是无法实现的。
从Kubernetes 1.1版本开始新增Ingress资源对象，用于将不同URL的访问请求转发到后端不同的Service，以实现HTTP层的业务路由机制。
Kubernetes使用了一个Ingress策略规则和一个具体的Ingress Controller，两者结合实现了一个完整的Ingress负载均衡器。
使用Ingress进行负载分发时，Ingress Controller基于Ingress策略规则将客户端请求直接转发到Service对应的后端Endpoint（Pod）上，从而跳过kube-proxy的转发功能，kube-proxy不再起作用。
简单的理解就是：ingress使用DaemonSet或Deployment在相应Node上监听80或443，然后配合相应规则，因为Nginx外面绑定了宿主机80端口（就像 NodePort），本身又在集群内，那么向后直接转发到相应ServiceIP即可实现相应需求。
ingress controller + ingress 策略规则 ----> services。
同时当Ingress Controller提供的是对外服务，则实际上实现的是边缘路由器的功能。
典型的HTTP层路由的架构：
设置标签
建议对于非业务相关的应用，构建集群所需的应用（如Ingress），部署在master节点，从而复用master节点的高可用。
采用标签，结合部署的yaml中的tolerations，实现ingress部署在master节点的配置。
shell
[root@master01 ~]# kubectl label nodes master01 ingress=enable获取资源
获取部署所需的yaml资源。
shell
[root@master01 ~]# mkdir hmingress
[root@master01 ~]# cd hmingress/
[root@master01 hmingress]# helm repo add ingress-nginx https://kubernetes.github.io/ingress-nginx/
[root@master01 hmingress]# helm repo list | grep ingress-nginx
ingress-nginx https://kubernetes.github.io/ingress-nginx/
[root@master01 hmingress]# helm search repo ingress-nginx
NAME CHART VERSION APP VERSION DESCRIPTION
ingress-nginx/ingress-nginx 4.14.1 1.14.1 Ingress controller for Kubernetes using NGINX a...
[root@master01 hmingress]# helm show values ingress-nginx --repo https://kubernetes.github.io/ingress-nginx > defaults-values.yaml #查看默认配置提示 ：ingress官方参考：https://github.com/kubernetes/ingress-nginx
ingress部署参考：Installation Guide
修改配置
为方便后续管理和排障，对相关Nginx ingress挂载时区，以便使Pod时间正确，从而相关记录日志能具有时效性。
同时对ingress做了简单配置，如日志格式等。
shell
[root@master01 ingress]# vim myvalues.yaml
global:
image:
registry: registry.cn-hangzhou.aliyuncs.com
controller:
image:
image: google_containers/nginx-ingress-controller
digest: ""
config:
# ====================== 安全与功能控制 ======================
allow-snippet-annotations: "false" # 禁用Ingress注解中的代码片段功能，防止恶意用户注入危险Nginx配置
use-gzip: "true" # 启用Gzip压缩传输，减少30%-70%网络带宽消耗
use-geoip: "false" # 禁用GeoIP模块，避免加载地理位置数据库节省内存（约减少10MB内存占用）
server-tokens: "false" # 隐藏Nginx版本信息，防止攻击者利用特定版本漏洞进行定向攻击
# ====================== 连接与超时优化 ======================
keep-alive: "75" # 客户端连接保持时间（秒），减少TCP握手开销，平衡资源占用
keep-alive-requests: "1000" # 单个keepalive连接允许的最大请求数，提高连接复用率（默认100）
upstream-keepalive-connections: "50" # 到后端服务的连接池大小，减少频繁建立后端连接的开销
proxy-connect-timeout: "8" # 与后端服务建立连接的超时时间（秒），防止因网络问题导致worker阻塞
proxy-read-timeout: "30" # 从后端服务读取响应的超时时间，防止慢速后端占用连接资源
proxy-send-timeout: "30" # 向后端服务发送请求的超时时间，确保请求及时送达
# ====================== 缓冲区优化（针对2核4G内存） ======================
client-header-buffer-size: "16k" # 存储客户端请求头的缓冲区大小
large-client-header-buffers: "4 32k" # 处理超大请求头的缓冲区配置
client-body-buffer-size: "128k" # 存储客户端请求体的缓冲区大小
proxy-buffer-size: "16k" # 代理响应头缓冲区大小
proxy-buffers: "8 16k" # 代理响应内容缓冲区配置
proxy-busy-buffers-size: "32k" # 忙碌响应缓冲区限制，防止单个大响应阻塞整个worker
proxy-body-size: "20m" # 允许的客户端请求体最大尺寸
# ====================== 哈希表优化 ======================
server-name-hash-bucket-size: "128" # 服务器名哈希表桶大小
map-hash-bucket-size: "128" # map指令哈希表桶大小
# ====================== SSL安全强化 ======================
ssl-protocols: "TLSv1.2 TLSv1.3" # 仅允许现代安全协议，禁用已知漏洞的TLSv1.0/1.1
ssl-ciphers: "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384" # 现代加密套件
ssl-session-tickets: "false" # 禁用Session Tickets，强制完全前向保密（PFS）
ssl-buffer-size: "16k" # SSL握手缓冲区大小
# ====================== 日志与监控 ======================
log-format-upstream: '{"time": "$time_iso8601", "remote_addr": "$proxy_protocol_addr", "x-forward-for": "$proxy_add_x_forwarded_for", "request_id": "$req_id","remote_user": "$remote_user", "bytes_sent": $bytes_sent, "request_time": $request_time, "status": $status, "vhost": "$host", "request_protocol": "$server_protocol", "path": "$uri", "query": "$args", "request_length": $request_length, "duration": $request_time,"method": "$request_method", "referrer": "$http_referer", "agent": "$http_user_agent", "upstream_addr": "$upstream_addr", "upstream_status": "$upstream_status" }' # 新增upstream状态
# ====================== Worker进程优化 ======================
worker-connections: "2048" # 单个worker进程允许的最大并发连接数
worker-rlimit-nofile: "65535" # worker进程可打开的文件描述符上限
extraEnvs:
- name: TZ
value: Asia/Shanghai
kind: DaemonSet
tolerations:
- key: node-role.kubernetes.io/control-plane
effect: NoSchedule
nodeSelector:
kubernetes.io/os: linux
ingress: enable
service:
type: NodePort
externalTrafficPolicy: "Local"
nodePorts:
http: "80"
https: "443"
admissionWebhooks:
patch:
image:
image: google_containers/kube-webhook-certgen
digest: ""提示：添加默认backend需要等待default-backend创建完成controllers才能成功部署，新版本ingress不再推荐添加default backend。
正式部署
通常对于国外的包有可能直接安装会失败，可提前wget或者pull至本地，然后进行安装。
bash
[root@master01 hmingress]# helm pull ingress-nginx/ingress-nginx
[root@master01 hmingress]# ll
total 128K
-rw-r--r-- 1 root root 53K Dec 12 15:41 defaults-values.yaml
-rw-r--r-- 1 root root 62K Dec 12 16:03 ingress-nginx-4.14.1.tgz
-rw-r--r-- 1 root root 4.4K Dec 12 16:02 myvalues.yaml
[root@master01 hmingress]# helm upgrade --install ingress-nginx ./ingress-nginx-4.14.1.tgz --namespace ingress-nginx --create-namespace -f myvalues.yaml提示：提示：如上本地安装命令等效于：
shell
[root@master01 hmingress]# helm upgrade --install ingress-nginx ingress-nginx/ingress-nginx --namespace ingress-nginx --create-namespace -f myvalues.yaml确认验证
查看Pod部署进度，是否成功完成。
shell
[root@master01 hmingress]# kubectl get pods -n ingress-nginx -o wide
[root@master01 hmingress]# kubectl get svc -n ingress-nginx -o wide
提示 ：其他更多ingress学习知识可参考此博客： Ingress-Nginx使用指南上篇 。
Dashboard部署
dashboard介绍
dashboard是基于Web的Kubernetes用户界面，即WebUI。
可以使用dashboard将容器化应用程序部署到Kubernetes集群，对容器化应用程序进行故障排除，以及管理集群资源。
可以使用dashboard来查看群集上运行的应用程序，以及创建或修改单个Kubernetes资源（例如部署、任务、守护进程等）。
可以使用部署向导扩展部署，启动滚动更新，重新启动Pod或部署新应用程序。
dashboard还提供有关群集中Kubernetes资源状态以及可能发生的任何错误的信息。
通常生产环境中建议部署dashboard，以便于图形化来完成基础运维。
从7.0.0版本开始，社区已放弃了对基于manifest安装的支持，现在只支持基于helm的安装。
由于多容器设置和对Kong网关API代理的严重依赖，原有基于yaml清单安装的方式已不可行。
同时基于helm的安装，部署速度更快，并且可以更好地控制Dashboard运行所需的所有依赖项。并且已经改变了版本控制方案，并从Helm chart中删除了appVersion。
因为，使用多容器设置，每个模块现在都是单独的版本，Helm chart版本现在可以被视为应用版本。
设置标签
基于最佳实践，非业务应用，或集群自身的应用都部署在Master节点。
shell
[root@master01 ~]# kubectl label nodes master01 dashboard=enable提示：建议对于Kubernetes自身相关的应用（如dashboard），此类非业务应用部署在master节点。
创建证书
默认dashboard会自动创建证书，同时使用对应证书创建secret。生产环境可以启用相应的域名进行部署dashboard，因此需要将对于的域名制作为TLS证书。
证书可通过如下任意一种方式获取。
-
申请免费证书
多个渠道可获取免费90天的证书，免费证书获取可参考：https://freessl.cn 。或者腾讯云 SSL证书 板块。
将已获取的证书上传至对应目录。
-
脚本快速自签名
基于实验目的，采用自签名证书。
shell
[root@master01 ~]# mkdir -p /root/dashboard/certs
[root@master01 ~]# cd /root/dashboard/
[root@master01 dashboard]# wget http://down.linuxsb.com/myshell/signcert.sh
[root@master01 dashboard]# vim signcert.sh
#!/bin/sh
#***************************************************************#
# ScriptName: signcert.sh
# Author: xhy
# Create Date: 2025-02-25 21:49
# Modify Author: xhy
# Modify Date: 2025-04-27 19:11
# Version: v1
#***************************************************************#
# 配置参数
#PARENT_DOMAIN="linuxsb.com" # 父级域名
#SUB_DOMAINS=("aaa" "bbb" "ccc") # 子域名列表，可选配置
PARENT_DOMAIN="k8sy.com"
SUB_DOMAINS=("web")
#...... #其他保持默认
[root@master01 dashboard]# bash signcert.sh
[root@master01 dashboard]# ll certs/
total 24K
-rw-r--r-- 1 root root 2.4K Jul 19 20:50 fullchain.crt
-rw-r--r-- 1 root root 1.3K Jul 19 20:50 k8sy.com.crt
-rw------- 1 root root 1.7K Jul 19 20:50 k8sy.com.key
-rw-r--r-- 1 root root 1.2K Jul 19 20:50 myCA.crt
-rw------- 1 root root 1.7K Jul 19 20:50 myCA.key
-rw-r--r-- 1 root root 41 Jul 19 20:50 myCA.srl- 方式二：命令快速自签名
shell
[root@master01 dashboard]# openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./certs/k8sy.com.key -out ./certs/k8sy.com.crt -subj "/C=CN/ST=ZheJiang/L=HangZhou/O=Xianghy/OU=Xianghy/CN=web.k8sy.com"
[root@master01 dashboard]# ll certs/提示：本指南采用申请免费证书进行创建。
手动创建secret
自定义证书的场景，建议提前使用对应的证书创建 secret 。
后续用于使用 https 暴露 dashboard 。
shell
[root@master01 dashboard]# kubectl create ns kubernetes-dashboard #dashboard独立ns
[root@master01 dashboard]# kubectl -n kubernetes-dashboard create secret tls kubernetes-dashboard-certs \
--cert=/root/dashboard/certs/web.k8sy.com.crt \
--key=/root/dashboard/certs/web.k8sy.com.key
[root@master01 dashboard]# kubectl -n kubernetes-dashboard get secret kubernetes-dashboard-certs -o yaml #查看证书信息获取部署文件
添加kubernetes-dashboard的repo仓库。
shell
[root@master01 dashboard]# helm repo add kubernetes-dashboard https://kubernetes.github.io/dashboard/
[root@master01 dashboard]# helm repo list
NAME URL
......
kubernetes-dashboard https://kubernetes.github.io/dashboard/
[root@master01 dashboard]# helm search repo kubernetes-dashboard
NAME CHART VERSION APP VERSION DESCRIPTION
#......
kubernetes-dashboard/kubernetes-dashboard 7.14.0 General-purpose web UI for Kubernetes clusters 创建自定义配置
根据实际情况修改默认的chart values，未配置的项表示使用默认值。
如下yaml主要做了几项自定义配置：
- 指定dashboard部署在master节点，将其归属为集群自有应用，而非业务应用；
- 指定了使用自有的TLS证书，及https的ingress域名；
- 指定了污点能接受master节点；
- 指定了Pod时钟环境变量，使Pod时间正确。
kubernetes-dashboard默认的values值参考 Kubernetes dashboard chart values ，没有自定义的参数将自动沿用默认配置。
shell
[root@master01 ~]# cd /root/dashboard/
[root@master01 dashboard]# helm show values kubernetes-dashboard/kubernetes-dashboard > defaults-values.yaml #查看默认配置
[root@master01 dashboard]# vim myvalues.yaml
app:
scheduling:
nodeSelector: {"dashboard": "enable"}
ingress:
enabled: true
hosts:
# - localhost
- web.k8sy.com
ingressClassName: nginx
annotations:
nginx.ingress.kubernetes.io/ssl-redirect: "true"
tls:
enabled: true
secretName: "kubernetes-dashboard-certs"
tolerations:
- key: node-role.kubernetes.io/control-plane
effect: NoSchedule
auth:
nodeSelector: {"dashboard": "enable"}
# API deployment configuration
api:
scaling:
replicas: 2
containers:
env:
- name: TZ
value: Asia/Shanghai
nodeSelector: {"dashboard": "enable"}
tolerations:
- key: node-role.kubernetes.io/control-plane
operator: "Exists"
effect: "NoSchedule"
# WEB UI deployment configuration
web:
scaling:
replicas: 2
containers:
env:
- name: TZ
value: Asia/Shanghai
nodeSelector: {"dashboard": "enable"}
tolerations:
- key: node-role.kubernetes.io/control-plane
operator: "Exists"
effect: "NoSchedule"
# Metrics Scraper
metricsScraper:
scaling:
replicas: 2
containers:
env:
- name: TZ
value: Asia/Shanghai
nodeSelector: {"dashboard": "enable"}
tolerations:
- key: node-role.kubernetes.io/control-plane
operator: "Exists"
effect: "NoSchedule"提示：当前版本kong不能完全关闭，否则后续部署成功后无法正常访问。
正式部署
根据生产环境最佳实践进行调优，调优完成后开始部署。
shel
[root@master01 dashboard]# helm upgrade --install kubernetes-dashboard kubernetes-dashboard/kubernetes-dashboard --create-namespace --namespace kubernetes-dashboard -f myvalues.yaml提示：对于国内环境，可能如上直接部署会由于网络原因失败，可单独将dashboard包下载至本地，然后通过命令部署。
shell
[root@master01 dashboard]# helm pull kubernetes-dashboard/kubernetes-dashboard
[root@master01 dashboard]# helm upgrade --install kubernetes-dashboard ./kubernetes-dashboard-7.14.0.tgz \
--create-namespace --namespace kubernetes-dashboard \
-f myvalues.yaml确认验证
shell
[root@master01 dashboard]# helm -n kubernetes-dashboard list
[root@master01 dashboard]# kubectl -n kubernetes-dashboard get pods -o wide
[root@master01 dashboard]# kubectl -n kubernetes-dashboard get svc -o wide
[root@master01 dashboard]# kubectl -n kubernetes-dashboard get ingress -o wide
NAME CLASS HOSTS ADDRESS PORTS AGE
kubernetes-dashboard nginx web.k8sy.com 10.20.45.69 80, 443 22m
创建管理员账户
建议创建管理员账户，dashboard默认没有创建具有管理员权限的账户，同时v7版本登录只支持token方式。
因此建议创建管理员权限的用户，然后创建此用户的token，然后使用此token进行登录。
shell
[root@master01 dashboard]# cat <<EOF > dashboard-admin.yaml
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: admin
namespace: kubernetes-dashboard
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: admin
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin
subjects:
- kind: ServiceAccount
name: admin
namespace: kubernetes-dashboard
---
apiVersion: v1
kind: Secret
type: kubernetes.io/service-account-token
metadata:
name: admin
namespace: kubernetes-dashboard
annotations:
kubernetes.io/service-account.name: "admin"
EOF
[root@master01 dashboard]# kubectl apply -f dashboard-admin.yaml查看token
最新版dashboard只支持token的方式访问dashboard。
shell
[root@master01 dashboard]# cat >getlogintoken.sh<<'EOF'
#!/bin/bash
#***************************************************************#
# ScriptName: getlogintoken.sh
# Author: xhy
# Create Date: 2025-12-12 21:03
# Modify Author: xhy
# Modify Date: 2025-12-12 21:04
# Version: v1
#***************************************************************#
ADMIN_SECRET=$(kubectl -n kubernetes-dashboard get secret | grep admin | awk '{print $1}')
DASHBOARD_LOGIN_TOKEN=$(kubectl describe secret -n kubernetes-dashboard ${ADMIN_SECRET} | grep -E '^token' | awk '{print $2}')
echo ${DASHBOARD_LOGIN_TOKEN}
EOF
[root@master01 dashboard]# chmod u+x getlogintoken.sh && bash getlogintoken.sh提示 ：也可通过如下方式获取name为admin的secret的token。
kubectl -n kubernetes-dashboard get secret admin -o jsonpath={".data.token"} | base64 -d
将web.k8sy.com.crt证书文件导入，以便于浏览器正确识别该自签名证书，若证书是合法 CA 颁发的，不需要额外再导入。
导入证书
将web.k8sy.com.crt证书导入浏览器，并设置为信任，可规避证书不受信任的弹出。
测试访问dashboard
本实验采用ingress所暴露的域名： https://web.k8sy.com
使用对应admin用户的token进行访问。
登录后默认进入的是default命名空间，可切换至其他对应的namespace，对整个Kubernetes进行管理和查看。
提示 ：更多dashboard访问方式及认证可参考：Kubernetes Dashboard简介及使用 。
dashboard登录整个流程可参考：https://www.cnadn.net/post/2613.html
Longhorn存储部署
Longhorn概述
Longhorn是用于Kubernetes的开源分布式块存储系统。
当前Kubernetes 1.34.3版本建议使用Longhorn 1.10.1 。
提示 ：更多介绍参考：longhorn 。
安装要求
安装 Longhorn 的 Kubernetes 集群中的每个节点都必须满足以下要求：
- 与 Kubernetes 兼容的容器运行时，如Docker v1.13+、containerd v1.3.7+ ；
- Kubernetes >= v1.25；
- open-iscsi已安装，并且iscsid守护程序在所有节点上运行，此为必要条件，Longhorn 依赖 iscsiadm 主机为 Kubernetes 提供持久卷；
- RWX 支持要求每个节点都安装 NFSv4 客户端；
- 有关安装 NFSv4 客户端；
- 主机文件系统支持file extents存储数据的功能，当前支持：ext4、xfs；
- 其他必要命令工具：bash、curl、findmnt、grep、awk、blkid、lsblk；
- 为了正确部署和运行 Longhorn，Longhorn 工作负载必须能够以 root 身份运行。
本指南旨在使用longhorn给Kubernetes提供持久化存储，通常由Kubernetes的应用操作Longhorn，Longhorn也支持直接通过longhornctl命令操作存储。
longhornctl命令更多使用参考：longhornctl命令工具 。
shell
curl -sSfL -o /usr/local/bin/longhornctl https://github.com/longhorn/cli/releases/download/v1.10.1/longhornctl-linux-amd64
chmod +x /usr/local/bin/longhornctlroot权限说明可参考： Root和特权权限说明
安装准备
- 环境准备
后续业务应用可能运行在任意节点位置，挂载操作需要在任何节点可正常执行。
所有节点均需要安装基础以来软件。
shell
[root@master01 ~]# source c3nodesenv.sh
[root@master01 ~]# for all_ip in ${ALL_IPS[@]}
do
echo -e "\n\n\033[33m[INFO] >>> ${all_ip}...\033[0m"
ssh root@${all_ip} "cat /boot/config-`uname -r`| grep CONFIG_NFS_V4"
ssh root@${all_ip} "yum -y install iscsi-initiator-utils nfs-utils cryptsetup &"
ssh root@${all_ip} "systemctl enable iscsid --now && modprobe iscsi_tcp"
ssh root@${all_ip} "cat > /etc/modules-load.d/iscsid.conf <<EOF
iscsi_tcp
nfs
nfsv4
EOF"
ssh root@${all_ip} "systemctl daemon-reload && systemctl restart systemd-modules-load.service"
ssh root@${all_ip} "systemctl enable iscsid --now"
done提示：如上仅需Master01节点操作，从而实现所有Worker节点的组件安装。
设置标签
本实验规划 master 和 worker 节点都用于提供存储，实现超融合架构，同时 Longhorn UI 只部署在 master 节点。
在Master节点上部署 Longhorn UI 。
在worker节点上部署 Longhorn Manager。
在所有节点上部署 Longhorn Driver 。
shell
[root@master01 ~]# kubectl label nodes master01 longhorn-ui=enabled
[root@master01 ~]# kubectl label nodes worker0{1,2} longhorn-storage=enabled
[root@master01 ~]# kubectl label nodes master01 longhorn-storage=enabled提示：ui图形界面可复用master高可用，因此部署在master节点。
准备磁盘
Longhorn的分布式存储，建议独立磁盘设备专门作为存储卷，可提前挂载。
longhorn默认使用/var/lib/longhorn/作为设备路径，可提前挂载 /dev/sdb 设备。
不同环境下裸磁盘的设备名不一样，且根据启动时识别的顺序可能设备名不一样，因此建议采用UUID挂载设备，保持挂载一致性。
注意：执行如下自动挂载脚本前必须检查所有节点的数据盘设备，必须和脚本设置的一致。
shell
[root@master01 ~]# mkdir -p longhorn/certs
[root@master01 ~]# cd longhorn/
[root@master01 longhorn]# vim automountdev.sh
#!/bin/bash
#***************************************************************#
# ScriptName: automountdev.sh
# Author: xhy
# Create Date: 2025-07-20 01:31
# Modify Author: xhy
# Modify Date: 2025-07-20 01:31
# Version: v1
#***************************************************************#
# 定义设备路径和挂载点
DEVICE="/dev/nvme0n3"
MOUNT_POINT="/var/lib/longhorn"
# 检查设备是否存在
if [ ! -e "$DEVICE" ]; then
echo "错误：设备 $DEVICE 不存在！"
exit 1
fi
# 检查是否已格式化
if ! blkid "$DEVICE" | grep -q 'TYPE="xfs"'; then
echo "格式化 $DEVICE 为 XFS 文件系统..."
mkfs.xfs -f "$DEVICE"
if [ $? -ne 0 ]; then
echo "格式化失败！"
exit 1
fi
echo "格式化完成"
fi
# 获取 UUID
UUID=$(blkid -s UUID -o value "$DEVICE")
if [ -z "$UUID" ]; then
echo "无法获取设备 UUID！"
exit 1
fi
# 创建挂载点目录
mkdir -p "$MOUNT_POINT"
# 检查是否已挂载
if grep -q "$MOUNT_POINT" /etc/fstab; then
echo "挂载点 $MOUNT_POINT 已在 fstab 中存在"
else
# 备份原始 fstab
cp /etc/fstab /etc/fstab.bak
# 添加挂载配置
echo "UUID=$UUID $MOUNT_POINT xfs defaults 0 0" | tee -a /etc/fstab
echo "已添加持久化挂载配置"
fi
# 挂载设备
mount -a
if [ $? -eq 0 ]; then
echo "挂载成功！"
echo "设备信息："
df -hT "$MOUNT_POINT"
else
echo "挂载失败，请检查！"
exit 1
fi
[root@master01 longhorn]# source /root/c3nodesenv.sh
[root@master01 longhorn]# for node_ip in "${ALL_IPS[@]}"
do
echo ">>> ${all_ip}"
scp -rp /root/longhorn/automountdev.sh root@${all_ip}:/root/
ssh root@${all_ip} "bash /root/automountdev.sh"
done提示：如上操作仅需在master01上执行，可实现所有worker节点自动格式化磁盘设备，自动完成挂载。
根据实际生产环境，对Longhorn进行优化配置。
存储节点使用worker01、worker02、worker03，图形界面可部署在master节点，复用Kubernetes的高可用。
提示 ：也可使用kubectl进行安装，kubectl安装参考官方： Install with Kubectl
kubectl和helm安装时均可自定义相关配置，更多自定义配置可参考官方：Longhorn自定义配置
获取部署文件
shell
[root@master01 longhorn]# helm repo add longhorn https://charts.longhorn.io
[root@master01 longhorn]# helm repo list | grep longhorn
longhorn https://charts.longhorn.io
[root@master01 longhorn]# helm search repo longhorn
NAME CHART VERSION APP VERSION DESCRIPTION
longhorn/longhorn 1.10.1 v1.10.1 Longhorn is a distributed block storage system ...手动创建secret
自定义证书的场景，建议提前使用对应的证书创建 secret 。
后续用于使用 https 暴露 longhorn 管理界面。
shell
[root@master01 longhorn]# kubectl create ns longhorn-system
[root@master01 longhorn]# kubectl -n longhorn-system create secret tls longhorn-web-certs \
--cert=/root/longhorn/certs/longhorn.k8sy.com.crt \
--key=/root/longhorn/certs/longhorn.k8sy.com.key
[root@master01 longhorn]# kubectl -n longhorn-system get secret longhorn-web-certs -o yaml #查看证书信息创建Longhorn UI密码
使用已部署完成的ingress将Longhorn UI暴露，以便于使用URL形式访问Longhorn图形界面进行Longhorn的基础管理。
使用helm部署Longhorn中，可直接在自定义 values中直接配置ingress，若开启认证，则需要提前创建好用户密码。
shell
[root@master01 longhorn]# USER=admin; PASSWORD=admin1234; echo "${USER}:$(openssl passwd -stdin -apr1 <<< ${PASSWORD})" > auth提示：也可通过如下命令创建用户名和密码：
shell
[root@master01 longhorn]# yum -y install httpd-tools
[root@master01:~/longhorn# htpasswd -c auth admin #创建用户名和密码
New password: [输入密码]
Re-type new password: [输入密码]创建secret。
shell
[root@master01 longhorn]# kubectl -n longhorn-system create secret generic longhorn-basic-auth --from-file=auth创建自定义配置
shell
[root@master01 longhorn]# helm show values longhorn --repo https://charts.longhorn.io > defaults-values.yaml #查看默认配置
[root@master01 longhorn]# vim myvalues.yaml
# 默认的StorageClass为3副本，存储消耗过大，可调整为2
persistence:
defaultClassReplicaCount: 2
defaultSettings:
storageMinimalAvailablePercentage: "10" #默认集群预留百分比
storageReservedPercentageForDefaultDisk: "0" #默认磁盘预留百分比
longhornManager:
nodeSelector:
longhorn-storage: enabled
extraVolumeMounts:
- name: timeconfig
mountPath: /etc/localtime
readOnly: true
extraVolumes:
- name: timeconfig
hostPath:
path: /etc/localtime
longhornDriver:
nodeSelector:
longhorn-storage: enabled
longhornUI:
replicas: 2
nodeSelector:
longhorn-ui: enabled
tolerations:
- key: node-role.kubernetes.io/control-plane
effect: NoSchedule
extraVolumeMounts:
- name: timeconfig
mountPath: /etc/localtime
readOnly: true
extraVolumes:
- name: timeconfig
hostPath:
path: /etc/localtime
ingress:
enabled: true
ingressClassName: "nginx"
host: "longhorn.k8sy.com"
tls: true
tlsSecret: longhorn-web-certs
path: /
pathType: Prefix
annotations:
nginx.ingress.kubernetes.io/auth-type: basic
nginx.ingress.kubernetes.io/auth-secret: longhorn-basic-auth
nginx.ingress.kubernetes.io/auth-realm: 'Authentication Required'
nginx.ingress.kubernetes.io/proxy-body-size: 50m
nginx.ingress.kubernetes.io/ssl-redirect: "true"对于longhorn-ui的svc不建议直接通过nodeport暴露，保持默认的ClusterIP，然后通过ingress对外暴露。
正式部署
基于自定义的 helm values 进行部署。
shell
[root@master01 longhorn]# helm upgrade --install longhorn longhorn/longhorn --create-namespace --namespace longhorn-system -f myvalues.yaml
[root@master01 longhorn]# kubectl -n longhorn-system get pods -o wide #查看所有已部署的Pod
[root@master01 longhorn]# kubectl -n longhorn-system get svc
[root@master01 longhorn]# kubectl -n longhorn-system get svc longhorn-frontend
[root@master01 longhorn]# kubectl -n longhorn-system get ingress longhorn-ingress
[root@master01 longhorn]# kubectl -n longhorn-system describe svc longhorn-frontend
[root@master01 longhorn]# kubectl -n longhorn-system describe ingress longhorn-ingress
提示：若部署异常可删除重建，若出现无法删除namespace，可通过如下操作进行删除：
方式一：
shell
[root@master01 longhorn]# helm -n longhorn-system uninstall longhorn
[root@master01 longhorn]# kubectl -n longhorn-system edit settings.longhorn.io deleting-confirmation-flag
#......
value: "true"方式二：
shell
wget https://github.com/longhorn/longhorn/blob/master/uninstall/uninstall.yaml
kubectl apply -f uninstall.yaml
kubectl get job/longhorn-uninstall -n longhorn-system -w
kubectl delete -f uninstall.yaml #等待任务完成再次执行delete
rm -rf /var/lib/longhorn/*动态sc创建
部署Longhorn后，默认已创建一个名为longhorn的sc。
shell
[root@master01 longhorn]# kubectl get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
longhorn (default) driver.longhorn.io Delete Immediate true 8h
longhorn-static driver.longhorn.io Delete Immediate true 8h也可以通过如下方式创建一个新的sc，测试Longhorn部署结果。
shell
[root@master01 longhorn]# cat <<EOF > longhornpsc.yaml
kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
name: longhorn-test
provisioner: driver.longhorn.io
allowVolumeExpansion: true
parameters:
numberOfReplicas: "3"
staleReplicaTimeout: "2880" # 48 hours in minutes
fromBackup: ""
fsType: "ext4"
EOF
[root@master01 longhorn]# kubectl apply -f longhornpsc.yaml测试PV及PVC
使用常见的Nginx Pod进行测试，模拟生产环境常见的Web类应用的持久性存储卷。
shell
[root@master01 longhorn]# cat <<EOF > longhorntest.yaml
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: longhorn-pvc
spec:
accessModes:
- ReadWriteOnce
storageClassName: longhorn
resources:
requests:
storage: 50Mi
---
apiVersion: v1
kind: Pod
metadata:
name: longhorn-pod
namespace: default
spec:
containers:
- name: volume-test
image: uhub.service.ucloud.cn/imxhy/nginx:1.29.0
imagePullPolicy: IfNotPresent
volumeMounts:
- name: volv
mountPath: /usr/share/nginx/html
ports:
- containerPort: 80
volumes:
- name: volv
persistentVolumeClaim:
claimName: longhorn-pvc
EOF #创建Pod
[root@master01 longhorn]# kubectl apply -f longhorntest.yaml
[root@master01 longhorn]# kubectl get pods -o wide
[root@master01 longhorn]# kubectl get pvc -o wide
[root@master01 longhorn]# kubectl get pv -o wide
确认验证
浏览器访问：longhorn.k8sy.com ，并输入设置的账号和密码，使用admin/[密码]登录查看。
Prometheus监控部署
Prometheus简介
参考：
Kubernetes集群管理-Prometheus+Grafana监控方案
获取资源
[root@master01 ~]# git clone https://github.com/prometheus-operator/kube-prometheus.git
[root@master01 ~]# cd kube-prometheus/manifests/
[root@master01 manifests]# grep -rn 'image:' ./ | awk '{print $3}' | grep -v ^$ | sort | uniq > images.list #提前通过脚本下载镜像
[root@master01 manifests]# wget https://down.linuxsb.com/myshell/js_pull_lists_images.sh
[root@master01 manifests]# source /root/c3nodesenv.sh
[root@master01 manifests]# for all_ip in ${ALL_IPS[@]}
do
echo -e "\n\n\033[33m[INFO] >>> ${all_ip}...\033[0m"
sleep 1
scp -rp js_pull_lists_images.sh images.list root@${all_ip}:/root/
ssh root@${all_ip} "chmod u+x /root/js_pull_lists_images.sh"
ssh root@${all_ip} "nohup bash -c '/root/js_pull_lists_images.sh' >/dev/null 2>&1 </dev/null &"
done创建prometheus持久卷
prometheus 默认是通过 emptyDir 进行挂载的，emptyDir 挂载的数据的生命周期和 Pod 生命周期一致的，为了实现数据持久化，本方案建议提前生成持久卷。
prometheus是一种 StatefulSet 有状态集的部署模式，可直接将 StorageClass 配置到如下yaml 中。
本环境已创建动态存储longhorn，longhorn部署参考《附034.Kubernetes_v1.21.0高可用部署架构二》。
[root@master01 manifests]# kubectl get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
longhorn driver.longhorn.io Delete Immediate true 12d
[root@master01 manifests]# vim prometheus-prometheus.yaml #追加如下持久化配置
......
storage:
volumeClaimTemplate:
spec:
storageClassName: longhorn
resources:
requests:
storage: 1Gi优化grafana
当前grafana可能会由于资源过低，刷新会异常夯死，建议增大资源申请。
shell
[root@master01 manifests]# vi grafana-deployment.yaml
#......
resources:
limits:
cpu: 500m
memory: 600Mi
requests:
cpu: 400m
memory: 500Mi
#......创建grafana持久卷
grafana默认的SQLite数据库，部分非SSD固态硬盘下，性能一般。
可根据实际情况选择默认的SQLite数据库方式部署，或者优化为MySQL数据库，本指南建议使用MySQL数据库进行优化部署，两者选其一即可。
优化部署-使用MySQL数据库
提示 ：grafana默认使用sqlite充当数据库，但经常会遇到性能问题，所以可做下改造（可选）。
优化部署步骤是在正常部署后新增的可选，而不是和正常部署二选一。
- 创建PVC
Grafana 是部署模式为 Deployment，所以我们提前为其创建一个 grafana-local-storage 文件，用于持久化 Grafana 本地文件。
shell
[root@master01 manifests]# vim grafana-pvc.yaml
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: grafana-local-storage
namespace: monitoring
spec:
accessModes:
- ReadWriteOnce
storageClassName: longhorn
resources:
requests:
storage: 1Gi- 创建MySQL部署
创建MySQL部署配置文件，同时使用 volumeClaimTemplates 直接创建对应的PVC，该pvc创建一个用于持久化 MySQL 的数据所需的PVC。
shell
[root@master01 manifests]# vim grafana-mysql-deployment.yaml
---
apiVersion: v1
kind: Secret
metadata:
name: grafana-mysql-secret
namespace: monitoring
type: Opaque
stringData:
MYSQL_ROOT_PASSWORD: "rootpass"
MYSQL_DATABASE: "grafana"
MYSQL_USER: "grafana"
MYSQL_PASSWORD: "grafanapass"
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: grafana-mysql
namespace: monitoring
labels:
app: grafana-mysql
spec:
serviceName: grafana-mysql-service
replicas: 1
selector:
matchLabels:
app: grafana-mysql
volumeClaimTemplates:
- kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: mysql-data
spec:
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
storageClassName: longhorn
template:
metadata:
labels:
app: grafana-mysql
spec:
containers:
- name: mysql
image: 'docker.1ms.run/library/mysql:8.4.7'
env:
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: grafana-mysql-secret
key: MYSQL_ROOT_PASSWORD
- name: MYSQL_DATABASE
valueFrom:
secretKeyRef:
name: grafana-mysql-secret
key: MYSQL_DATABASE
- name: MYSQL_USER
valueFrom:
secretKeyRef:
name: grafana-mysql-secret
key: MYSQL_USER
- name: MYSQL_PASSWORD
valueFrom:
secretKeyRef:
name: grafana-mysql-secret
key: MYSQL_PASSWORD
args:
- "--character-set-server=utf8mb4"
- "--collation-server=utf8mb4_unicode_ci"
ports:
- name: mysql-port
containerPort: 3306
protocol: TCP
volumeMounts:
- mountPath: /var/lib/mysql
name: mysql-data
startupProbe:
exec:
command:
- /bin/sh
- -c
- "mysql -uroot -p${MYSQL_ROOT_PASSWORD} -e 'SELECT 1'"
periodSeconds: 5
timeoutSeconds: 3
failureThreshold: 60
livenessProbe:
exec:
command:
- /bin/sh
- -c
- "mysql -uroot -p${MYSQL_ROOT_PASSWORD} -e 'SELECT 1'"
initialDelaySeconds: 60
periodSeconds: 10
timeoutSeconds: 5
readinessProbe:
exec:
command:
- /bin/sh
- -c
- "mysql -uroot -p${MYSQL_ROOT_PASSWORD} -e 'SELECT 1'"
initialDelaySeconds: 10
periodSeconds: 5
timeoutSeconds: 3
securityContext:
runAsNonRoot: false
---
apiVersion: v1
kind: Service
metadata:
name: grafana-mysql-service
namespace: monitoring
spec:
selector:
app: grafana-mysql
ports:
- name: mysql-port
port: 3306
targetPort: 3306
clusterIP: None
EOF- 修改grafana默认配置
修改grafana默认配置文件，追加MySQL数据库的配置，以便于正式启用MySQL数据库作为默认数据库。
shell
[root@master01 manifests]# vim grafana-config.yaml
apiVersion: v1
kind: Secret
metadata:
labels:
#......
stringData:
grafana.ini: |
[database]
type = mysql
host = grafana-mysql-service.monitoring.svc.cluster.local:3306
name = grafana
user = grafana
password = grafanapass
ssl_mode = disable
[date_formats]
default_timezone = UTC
type: Opaque- 修改grafana持久化
修改grafana持久挂载。
shell
[root@master01 manifests]# vim grafana-deployment.yaml
#......
serviceAccountName: grafana
volumes:
# - emptyDir: {} #注释此两行
# name: grafana-storage
- name: grafana-storage
persistentVolumeClaim:
claimName: grafana-local-storage
#......提示 ：根据实际情况，可将grafana-deployment.yaml调整为 replicas: 2 。
默认部署-使用SQLite数据库
Grafana 是部署模式为 Deployment，所以我们提前为其创建一个 grafana-pvc.yaml 文件，加入下面 PVC 配置。
shell
[root@master01 manifests]# vim grafana-pvc.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: grafana-local-storage
namespace: monitoring
spec:
accessModes:
- ReadWriteOnce
storageClassName: longhorn
resources:
requests:
storage: 1Gi
[root@master01 manifests]# vim grafana-deployment.yaml
#......
serviceAccountName: grafana
volumes:
# - emptyDir: {} #注释此两行
# name: grafana-storage
- name: grafana-storage
persistentVolumeClaim:
claimName: grafana-local-storage
#......提示：如上部署会基于grafana默认的SQLite数据库，部分非SSD固态硬盘下，性能一般。
nodeport暴露服务
需要修改的是alertmanager-main，grafana，prometheus-k8s。
采用nodeport暴露服务，验证相关服务是否正常。
若采用ingress服务暴露，此步骤可跳过。
[root@master01 manifests]# vim alertmanager-service.yaml
apiVersion: v1
kind: Service
metadata:
#......
name: alertmanager-main
namespace: monitoring
spec:
type: NodePort #SVC暴露模式设为NodePort
ports:
- name: web
port: 9093
targetPort: web
nodePort: 30010 #指定nodePort
- name: reloader-web
port: 8080
targetPort: reloader-web
#......
[root@master01 manifests]# vim grafana-service.yaml
apiVersion: v1
kind: Service
metadata:
#......
name: grafana
namespace: monitoring
spec:
type: NodePort #SVC暴露模式设为NodePort
ports:
- name: http
port: 3000
targetPort: http
nodePort: 30011 #指定nodePort
#......
[root@master01 manifests]# vim prometheus-service.yaml
apiVersion: v1
kind: Service
#......
name: prometheus-k8s
namespace: monitoring
spec:
type: NodePort #SVC暴露模式设为NodePort
ports:
- name: web
port: 9090
targetPort: web
nodePort: 30012 #指定nodePort
- name: reloader-web
port: 8080
targetPort: reloader-web
#......策略配置
若要使用端口访问，由于kube-Prometheus默认会创建networkpolicy，因此在不额外配置放通规则的情况下，可删除相应的策略。
shell
[root@master01 manifests]# mv alertmanager-networkPolicy.yaml{,.bak}
[root@master01 manifests]# mv grafana-networkPolicy.yaml{,.bak}
[root@master01 manifests]# mv prometheus-networkPolicy.yaml{,.bak}正式部署
[root@master01 manifests]# kubectl apply --server-side -f ./setup #创建monitoring命名空间和CRD模板
[root@master01 manifests]# kubectl apply -f .
[root@master01 manifests]# kubectl -n monitoring get pods提示 ：如上操作会创建monitoring 的命名空间，以及相关的 Prometheus Operator 控制器。
创建 Operator 后，可以创建自定义资源清单（CRD），若需要自定义资源对象生效就需要安装对应的 Operator 控制器，因此如上创建operator需要在创建CRD之前。
提示 ：kube-Prometheus安装和使用完全教程 中提到了给Prometheus提权，可参考。
ingress暴露服务
创建secret
创建用于ingress暴露的TLS secret，用于后续将所有管家服务以ingress形式暴露出来。
提前将相关证书上传至服务器。
shell
[root@master01 manifests]# mkdir /root/kube-prometheus/certs
[root@master01 manifests]# ll /root/kube-prometheus/certs/
total 36K
-rw-r--r-- 1 root root 4.4K Dec 14 2025 alertmanager.k8sy.com.crt
-rw-r--r-- 1 root root 1.7K Dec 14 2025 alertmanager.k8sy.com.key
-rw-r--r-- 1 root root 4.4K Dec 12 20:54 grafana.k8sy.com.crt
-rw-r--r-- 1 root root 1.7K Dec 12 20:54 grafana.k8sy.com.key
-rw-r--r-- 1 root root 4.4K Dec 12 20:54 prometheus.k8sy.com.crt
-rw-r--r-- 1 root root 1.7K Dec 12 20:54 prometheus.k8sy.com.key
[root@master01 manifests]# kubectl -n monitoring create secret tls alertmanager-k8sy-certs \
--cert=/root/kube-prometheus/certs/alertmanager.k8sy.com.crt \
--key=/root/kube-prometheus/certs/alertmanager.k8sy.com.key
[root@master01 manifests]# kubectl -n monitoring create secret tls grafana-k8sy-certs \
--cert=/root/kube-prometheus/certs/grafana.k8sy.com.crt \
--key=/root/kube-prometheus/certs/grafana.k8sy.com.key
[root@master01 manifests]# kubectl -n monitoring create secret tls prometheus-k8sy-certs \
--cert=/root/kube-prometheus/certs/prometheus.k8sy.com.crt \
--key=/root/kube-prometheus/certs/prometheus.k8sy.com.key创建alertmanager-main ingress策略
shell
[root@master01 manifests]# cat >alertmanager-ingress.yaml<<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: alertmanager-ingress
namespace: monitoring
labels:
kubernetes.io/name: alertmanager
spec:
ingressClassName: "nginx"
rules:
- host: alertmanager.k8sy.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: alertmanager-main
port:
number: 9093
tls:
- hosts:
- alertmanager.k8sy.com
secretName: alertmanager-k8sy-certs
EOF
[root@master01 manifests]# kubectl apply -f alertmanager-ingress.yaml创建prometheus ingress策略
[root@master01 manifests]# cat >prometheus-ingress.yaml<<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: prometheus-ingress
namespace: monitoring
annotations:
kubernetes.io/ingress.class: "nginx"
labels:
kubernetes.io/name: prometheus
spec:
ingressClassName: "nginx"
rules:
- host: prometheus.k8sy.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: prometheus-k8s
port:
number: 9090
tls:
- hosts:
- prometheus.k8sy.com
secretName: prometheus-k8sy-certs
EOF
[root@master01 manifests]# kubectl apply -f prometheus-ingress.yaml创建grafana ingress策略
[root@master01 manifests]# cat >grafana-ingress.yaml<<EOF
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: grafana-ingress
namespace: monitoring
labels:
kubernetes.io/name: grafana
spec:
ingressClassName: "nginx"
rules:
- host: grafana.k8sy.com
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: grafana
port:
number: 3000
tls:
- hosts:
- grafana.k8sy.com
secretName: grafana-k8sy-certs
EOF
[root@master01 manifests]# kubectl apply -f grafana-ingress.yaml确认验证
确认部署
[root@master01 manifests]# kubectl -n monitoring get pods -o wide
[root@master01 manifests]# kubectl -n monitoring get svc -o wide
端口访问
访问alertmanager，http://172.24.8.100:30010/ 。
访问grafana，http://172.24.8.100:30011/ ，默认用户名密码都为admin。
访问prometheus，http://172.24.8.100:30012/ 。
域名访问
访问 alertmanager，https://alertmanager.k8sy.com 。
访问 prometheus，https://prometheus.k8sy.com 。
访问 grafana，https://grafana.k8sy.com 。
配置grafana
配置源数据
浏览器访问：http://grafana.k8sy.com ，Connections ----> Data Sources。
本项目grafana默认已经添加了Prometheus数据源，可以直接使用。
配置Grafana
配置dashboard，本实验使用315号模板，此Dashboard 模板来展示 Kubernetes 集群的监控信息。
设置相关dashboard页面名称，以及选择数据源。
提示：14518也是一个针对Kubernetes的dashboard模板。
Grafana其他配置
建议配置对应的时区和语言。
提示：本文参考：https://blog.csdn.net/zuozewei/article/details/108358460
Prometheus相关指标
结合 Prometheus 可以通过 Metrics 数据源实现针对Kubernetes的各种监控，主要有：
-
宿主机（worker）：对于 worker 节点的监控数据，需要借助 Node Exporter 。一般来说，Node Exporter 会以 DaemonSet 的方式运行在宿主机上。
Exporter，就是代替被监控对象来对 Prometheus 暴露出可以被"抓取"的 Metrics 信息的一个辅助进程。而 Node Exporter 可以暴露给 Prometheus 采集的 Metrics 数据，Metrics 指标非常丰富，包括但不限于节点的负载（Load）、CPU 、内存、磁盘以及网络这样的常规信息。
-
Kubernetes API：主要包括 kubernetes 的 API Server、kubelet 等组件的 /metrics API。
除了常规的 CPU、内存的信息外，这部分信息还主要包括了各个组件的核心监控指标。比如，对于 API Server 来说，它就会在 /metrics API 里，暴露出各个 Controller 的工作队列（Work Queue）的长度、请求的 QPS 和延迟数据等等。此类指标，是检查 Kubernetes 本身工作情况的主要依据。
-
Kubernetes 业务：这部分数据，一般叫作 Kubernetes 核心监控数据（core metrics）。这其中包括了 Pod、Node、容器、Service 等主要 Kubernetes 核心概念的 Metrics。其中，容器相关的 Metrics 主要来自于 kubelet 内置的 cAdvisor 服务。在 kubelet 启动后，cAdvisor 服务也随之启动，而它能够提供的信息，可以细化到每一个容器的 CPU 、文件系统、内存、网络等资源的使用情况。需要注意的是，这里提到的是 Kubernetes 核心监控数据。