【Linux运维大神系列】Kubernetes详解1（kubeadm部署k8s1.23单节点集群）
目录
Kubernetes介绍
kubernetes（k8s）是2015年由Google公司基于Go语言编写的一款开源的容器集群编排系统，用于自动化容器的部署、扩缩容和管理；
kubernetes（k8s）是基于Google内部的Borg系统的特征开发的一个版本，集成了Borg系统大部分优势
Kubernetes具备的功能
自我修复：k8s可以监控容器的运行状况，并在发现容器出现异常时自动重启故障实例；
弹性伸缩：k8s可以根据资源的使用情况自动地调整容器的副本数。例如，在高峰时段，k8s可以自动增加容器的副本数以应对更多的流量；而在低峰时段，k8s可以减少应用的副本数，节省资源；
资源限额：k8s允许指定每个容器所需的CPU和内存资源，能够更好的管理容器的资源使用量；
滚动升级：k8s可以在不中断服务的情况下滚动升级应用版本，确保在整个过程中仍有足够的实例在提供服务；
负载均衡：k8s可以根据应用的负载情况自动分配流量，确保各个实例之间的负载均衡，避免某些实例过载导致的性能下降；
服务发现：k8s可以自动发现应用的实例，并为它们分配一个统一的访问地址。这样，用户只需要知道这个统一的地址，就可以访问到应用的任意实例，而无需关心具体的实例信息；
存储管理：k8s可以自动管理应用的存储资源，为应用提供持久化的数据存储。这样，在应用实例发生变化时，用户数据仍能保持一致，确保数据的持久性；
密钥与配置管理：Kubernetes 允许你存储和管理敏感信息，例如：密码、令牌、证书、ssh密钥等信息进行统一管理，并共享给多个容器复用；
Kubernetes集群角色
k8s集群需要建⽴在多个节点上，将多个节点组建成一个集群，然后进⾏统⼀管理，但是在k8s集群内部，这些节点⼜被划分成了两类⻆⾊：
一类⻆⾊为管理节点，叫Master，负责集群的所有管理工作；
⼀类⻆⾊为⼯作节点，叫Node，负责运行集群中所有用户的容器应用 ；
Master管理节点组件：
API Server：作为集群的管理入口，处理外部和内部通信，接收用户请求并处理集群内部组件之间的通信；
Scheduler：作为集群资源调度计算，根据调度策略，负责将待部署的 Pods 分配到合适的 Node 节点上；
Controller Manager：管理集群中的各种控制器，例如 Deployment、ReplicaSet、DaemonSet等，管理集群中的各种资源；
etcd：作为集群的数据存储，保存集群的配置信息和状态信息；
Node工作节点组件：
Kubelet：负责与 Master 节点通信，并根据 Master 节点的调度决策来创建、更新和删除 Pod，同时维护 Node 节点上的容器状态；
容器运行时（如 Docker、containerd 等）：负责运行和管理容器，提供容器生命周期管理功能。例如：创建、更新、删除容器等；
Kube-proxy：负责为集群内的服务实现网络代理和负载均衡，确保服务的访问性；
kubernetes集群类型
一主多从集群：由一台Master管理节点和多台Node工作节点组成，生产环境下Master节点存在单点故障的风险，适合学习和测试环境使用；
多主多从集群：由多台Master管理节点和多Node工作节点组成，安全性高，适合生产环境使用；
Kubernetes集群实战
| 主机名 | IP地址 | 角色 | 操作系统 |
|---|---|---|---|
| master01 | 10.0.0.101 | 管理节点 | CentOS 7 |
| node01 | 10.0.0.102 | 工作节点 | CentOS 7 |
| node02 | 10.0.0.103 | 工作节点 | CentOS 7 |
前期准备
1.修改主机名，添加hosts解析
hostnamectl set-hostname xxx
echo "10.0.0.101 master01" >> /etc/hosts
echo "10.0.0.102 worker01" >> /etc/hosts
echo "10.0.0.103 worker02" >> /etc/hosts
2.开启bridge网桥过滤功能
cat > /etc/sysctl.d/k8s.conf <<EOF
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
EOF
#由于开启bridge功能，需要加载br_netfilter模块来允许在bridge设备上的数据包经过iptables防火墙处理
modprobe br_netfilter && lsmod | grep br_netfilter
#加载配置文件，使上述配置生效
sysctl -p /etc/sysctl.d/k8s.conf3.配置ipvs功能
k8s中Service有两种代理模式，一种是基于iptables的，一种是基于ipvs，两者对比ipvs负载均衡算法更加的灵活，且带有健康检查的功能，如果想要使用ipvs模式，需要手动载入ipvs模块。
ipset和ipvsadm是两个与网络管理和负载均衡相关的软件包，在k8s代理模式中，提供多种负载均衡算法，如轮询（Round Robin）、最小连接（Least Connection）和加权最小连接（Weighted Least Connection）等；
下载 ipset ipvsadm
yum -y install ipset ipvsadm
将需要加载的ipvs相关模块写入到文件中
cat > /etc/sysconfig/modules/ipvs.modules <<EOF
#!/bin/bash
modprobe -- ip_vs
modprobe -- ip_vs_rr
modprobe -- ip_vs_wrr
modprobe -- ip_vs_sh
modprobe -- nf_conntrack
EOF
执行文件来加载模块bash /etc/sysconfig/modules/ipvs.modules && lsmod | grep -e ip_vs -e nf_conntrack
4.关闭swap分区
#临时关闭
swapoff -a
#永久关闭
sed -ri 's/.*swap.*/#&/' /etc/fstab
grep ".*swap.*" /etc/fstab
#检查swap
[root@master01 ~]#free -h
total used free shared buff/cache available
Mem: 1.9G 164M 1.1G 9.5M 727M 1.6G
Swap: 0B 0B 0B
Docker环境准备
所有集群主机均需操作
docker安装教程：https://blog.csdn.net/2403_87491401/article/details/155647219?spm=1001.2014.3001.5501
1.配置Cgroup驱动程序
cat > /etc/docker/daemon.json <<EOF
{
"exec-opts": ["native.cgroupdriver=systemd"]
}
EOF
#启动服务并设置随机自启
systemctl enable docker ; systemctl start dockerkubeadm部署k8s集群
kubernetes集群有多种部署方式，目前常用的部署方式有如下两种：
kubeadm部署方式：kubeadm是一个快速搭建kubernetes的集群工具；
二进制包部署方式：从官网下载每个组件的二进制包，依次去安装，部署麻烦；
1.配置k8s仓库，使用阿里云yum源
cat > /etc/yum.repos.d/k8s.repo <<EOF
[kubernetes]
name=Kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64/
enabled=1
gpgcheck=1
repo_gpgcheck=1
gpgkey=https://mirrors.aliyun.com/kubernetes/yum/doc/yum-key.gpg https://mirrors.aliyun.com/kubernetes/yum/doc/rpm-package-key.gpg
EOF2.安装集群软件
本实验安装k8s 1.23.0版本软件
yum install -y --nogpgcheck kubeadm-1.23.0-0 kubelet-1.23.0-0 kubectl-1.23.0-0
- kubeadm：用于初始化集群，并配置集群所需的组件并生成对应的安全证书和令牌；
- kubelet：负责与 Master 节点通信，并根据 Master 节点的调度决策来创建、更新和删除 Pod，同时维护 Node 节点上的容器状态；
- kubectl：用于管理k8集群的一个命令行工具；3.配置kubelet启用Cgroup控制组
#用于限制进程的资源使用量，如CPU、内存等
[root@master01 ~]#tee > /etc/sysconfig/kubelet <<EOF
> KUBELET_EXTRA_ARGS="--cgroup-driver=systemd"
> EOF
[root@master01 ~]#cat ^C
[root@master01 ~]#cat /etc/sysconfig/kubelet
KUBELET_EXTRA_ARGS="--cgroup-driver=systemd"
#设置kubelet为开机自启动即可，集群初始化后自动启动
systemctl enable kubelet4.集群初始化
查看集群所需镜像文件
[root@master01 ~]#kubeadm config images list
#...以下就是集群初始化所需的集群组件镜像
k8s.gcr.io/kube-apiserver:v1.23.0
k8s.gcr.io/kube-controller-manager:v1.23.0
k8s.gcr.io/kube-scheduler:v1.23.0
k8s.gcr.io/kube-proxy:v1.23.0
k8s.gcr.io/pause:3.6
k8s.gcr.io/etcd:3.5.1-0
k8s.gcr.io/coredns/coredns:v1.8.6
创建集群初始化配置文件
[root@master01 ~]# kubeadm config print init-defaults > kubeadm-config.yaml
修改以下内容
[root@master01 ~]# cat kubeadm-config.yaml
#本机的IP地址
advertiseAddress: 192.168.0.10
#本机名称
name: master01
#集群镜像下载地址，修改为阿里云
imageRepository: registry.cn-hangzhou.aliyuncs.com/google_containers
集群初始化
[root@master01 ~]# kubeadm init --config /root/kubeadm-config.yaml --upload-certs
#选项说明：
--upload-certs //初始化过程将生成证书，并将其上传到etcd存储中，以便后续节点的加入
根据集群初始化后的提示，执行如下命令
[root@master01 ~]# mkdir -p $HOME/.kube
[root@master01 ~]# sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
[root@master01 ~]# sudo chown $(id -u):$(id -g) $HOME/.kube/config
[root@master01 ~]# export KUBECONFIG=/etc/kubernetes/admin.conf
根据提示将node节点加入集群，加入成功后在master节点验证
#在每个node节点执行命令，加入master集群
kubeadm join 10.0.0.101:6443 --token abcdef.0123456789abcdef \
--discovery-token-ca-cert-hash sha256:9cb2c0d96958bc5e547db15584fef9320c02a3798add01af4a0dcc576eb7ad1a
#master集群查看
[root@master01 ~]#kubectl get nodes
NAME STATUS ROLES AGE VERSION
master01 NotReady control-plane,master 9m38s v1.23.0
worker01 NotReady <none> 24s v1.23.0
worker02 NotReady <none> 18s v1.23.0
部署集群网络Calico
Calico和Flanner是两钟流行的k8s网络插件，它们都为集群中的pod提供网络功能。然而，它们在实现方式和功能上有一些重要区别：
网络模型的区别：
Calico 使用 BGP（边界网关协议）作为其底层网络模型。它利用 BGP 为每个 Pod 分配一个唯一的 IP 地址，并在集群内部进行路由。Calico 支持网络策略，可以对流量进行精细控制，允许或拒绝特定的通信。
Flannel 则采用了一个简化的覆盖网络模型。它为每个节点分配一个 IP 地址子网，然后在这些子网之间建立覆盖网络。Flannel 将 Pod 的数据包封装到一个更大的网络数据包中，并在节点之间进行转发。Flannel 更注重简单和易用性，不提供与 Calico 类似的网络策略功能。
性能的区别：由于 Calico 使用 BGP 进行路由，其性能通常优于 Flannel。Calico 可以实现直接的 Pod 到 Pod 通信，而无需在节点之间进行额外的封装和解封装操作。这使得 Calico 在大型或高度动态的集群中具有更好的性能。
Flannel 的覆盖网络模型会导致额外的封装和解封装开销，从而影响网络性能。对于较小的集群或对性能要求不高的场景，这可能并不是一个严重的问题。
1.master节点安装Calico网络
下载calico文件
[root@master01 ~]#wget https://raw.githubusercontent.com/projectcalico/calico/v3.24.1/manifests/calico.yaml
创建calico网络
[root@master01 ~]#kubectl apply -f calico.yaml
查看calico的Pod状态是否为Running
[root@master01 ~]#kubectl get pod -n kube-system
NAME READY STATUS RESTARTS AGE
calico-kube-controllers-66966888c4-6gl2f 1/1 Running 0 70m
calico-node-9596w 1/1 Running 0 70m
calico-node-pp9mq 0/1 Running 0 70m
calico-node-xzjdw 1/1 Running 0 70m
验证网络可用性
[root@master01 ~]#kubectl get nodes
NAME STATUS ROLES AGE VERSION
master01 Ready control-plane,master 4h4m v1.23.0
worker01 Ready <none> 3h55m v1.23.0
worker02 Ready <none> 3h55m v1.23.0
部署nginx测试
部署nginx程序
[root@master01 ~]#kubectl create deployment nginx --image=nginx:latest
deployment.apps/nginx created
#查看是否部署成功
[root@master01 ~]#kubectl describe pods -l app=nginx
Name: nginx-7c658794b9-9rr9x
Namespace: default
Priority: 0
Node: worker02/10.0.0.105
Start Time: Thu, 08 Jan 2026 21:48:56 +0800
Labels: app=nginx
pod-template-hash=7c658794b9
Annotations: cni.projectcalico.org/containerID: d0d8de100ed8a2d51401b8599b0085320982271457922ae3857212e784a90552
cni.projectcalico.org/podIP: 192.168.30.67/32
cni.projectcalico.org/podIPs: 192.168.30.67/32
Status: Running
IP: 192.168.30.67
IPs:
IP: 192.168.30.67
Controlled By: ReplicaSet/nginx-7c658794b9
Containers:
nginx:
Container ID: docker://c469db6d52bd56ce9ff3b0a1492b7055620b3e45869e2b8e0cae3556b4e53d62
Image: nginx:latest
Image ID: docker-pullable://nginx@sha256:ca871a86d45a3ec6864dc45f014b11fe626145569ef0e74deaffc95a3b15b430
Port: <none>
Host Port: <none>
State: Running
Started: Thu, 08 Jan 2026 21:49:10 +0800
Ready: True
Restart Count: 0
Environment: <none>
Mounts:
/var/run/secrets/kubernetes.io/serviceaccount from kube-api-access-w9rfc (ro)
Conditions:
Type Status
Initialized True
Ready True
ContainersReady True
PodScheduled True
Volumes:
kube-api-access-w9rfc:
Type: Projected (a volume that contains injected data from multiple sources)
TokenExpirationSeconds: 3607
ConfigMapName: kube-root-ca.crt
ConfigMapOptional: <nil>
DownwardAPI: true
QoS Class: BestEffort
Node-Selectors: <none>
Tolerations: node.kubernetes.io/not-ready:NoExecute op=Exists for 300s
node.kubernetes.io/unreachable:NoExecute op=Exists for 300s
Events:
Type Reason Age From Message
---- ------ ---- ---- -------
Normal Scheduled 37s default-scheduler Successfully assigned default/nginx-7c658794b9-9rr9x to worker02
Normal Pulling 36s kubelet Pulling image "nginx:latest"
Normal Pulled 24s kubelet Successfully pulled image "nginx:latest" in 12.635397234s
Normal Created 23s kubelet Created container nginx
Normal Started 23s kubelet Started container nginx
开放端口
[root@master01 ~]#kubectl expose deployment nginx --port=80 --type=NodePort
service/nginx exposed
查看service状态
[root@master01 ~]#kubectl get service
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
kubernetes ClusterIP 10.96.0.1 <none> 443/TCP 4h31m
nginx NodePort 10.110.193.62 <none> 80:30310/TCP 10m
浏览器访问测试：http://10.0.0.102:30310/
更多推荐
9
0- 0
已为社区贡献15条内容
所有评论(0)