Kubernetes1.28-单Master集群部署一OpenEuler24.03系统保姆级教程
本文详细介绍了在OpenEuler 24.03操作系统上部署Kubernetes 1.28单Master集群的完整流程。主要内容包括：环境初始化（关闭防火墙、Swap等）、Docker和CRI-Docker安装、Kubeadm组件配置、Master节点初始化、Worker节点加入、Calico网络插件部署等关键步骤。教程特别针对国内环境优化，使用阿里云镜像源加速组件下载，并提供了内核参数调整建议。
前言：
Kubernetes（K8s）作为云原生时代的核心容器编排平台，已成为企业构建高可用、可扩展应用的首选方案。然而，对于初学者而言，Kubernetes 的部署过程可能充满挑战，尤其是在不同 Linux 发行版上的适配问题。
本教程以 OpenEuler 24.03 操作系统为基础，详细讲解 Kubernetes 1.28 单 Master 集群 的部署流程，涵盖从环境准备、Kubeadm 初始化、CNI 网络插件（如 Flannel/Calico）安装到 Worker 节点加入的全过程。教程采用 阿里云镜像源 加速组件拉取，并针对 OpenEuler 系统优化内核参数，确保部署顺利。
无论你是 运维工程师、DevOps 开发者，还是 Kubernetes 初学者，本教程都将提供清晰的步骤和排错指南，帮助你快速搭建一个可用的 K8s 集群，为后续学习或生产环境部署奠定基础。
目录
一、 服务器环境及初始化
1、架构分析
| 集群角色 | 主机名 | 操作系统 | IP地址 |
|---|---|---|---|
| master | k8s-master | OpenEuler24.03 | 192.168.72.166 |
| node | k8s-node1 | OpenEuler24.03 | 192.168.72.167 |
| node | k8s-node2 | OpenEuler24.03 | 192.168.72.168 |
2、初始化
所有节点都需要初始化！
2.1、清空Iptales默认规则及关闭防火墙
iptables -t nat -F
iptables -t filter -F
systemctl disable --now firewalld2.2、关闭SELINUX
setenforce 0
sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/selinux/config 2.3、关闭Swap交换空间
swapoff -a
sed -i 's/.*swap.*/#&/' /etc/fstab 2.4、设置主机名
hostnamectl set-hostname k8s-master
hostnamectl set-hostname k8s-node1
hostnamectl set-hostname k8s-node22.5、编写hosts文件
vim /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.72.166 k8s-master
192.168.72.167 k8s-node1
192.168.72.168 k8s-node2
###拷贝到node节点
scp /etc/hosts 192.168.72.167:/etc
scp /etc/hosts 192.168.72.168:/etc2.6、设置内核参数
注意：安装完成docker-ce并启动之后方可设置！
vim /etc/sysctl.conf
cat <<EOF>> /etc/sysctl.conf
net.ipv4.ip_forward=1
net.bridge.bridge-nf-call-ip6tables = 1
net.bridge.bridge-nf-call-iptables = 1
EOF
###########
modprobe br_netfilter
sysctl net.bridge.bridge-nf-call-ip6tables=1
sysctl net.bridge.bridge-nf-call-iptables=1
sysctl -p二、安装Docker环境
所有节点都需要安装！
1、安装Docker
1.1、配置阿里源
[root@localhost yum.repos.d]# cat docker-ce.repo
[docker-ce-stable]
name=Docker CE Stable - $basearch
baseurl=https://mirrors.aliyun.com//docker-ce/linux/centos/9/x86_64/stable/
enabled=1
gpgcheck=1
gpgkey=https://mirrors.aliyun.com/docker-ce/linux/centos/gpg1.2、安装docker
yum install -y docker-ce1.3、启动docker
systemctl enable --now docker2、安装cri-docker
下载地址：https://github.com/Mirantis/cri-dockerd/releases
yum install -y libcgroup
rpm -ivh cri-dockerd-0.3.8-3.el8.x86_64.rpm修改CRI启动脚本
vim /usr/lib/systemd/system/cri-docker.service
ExecStart=/usr/bin/cri-dockerd --container-runtime-endpoint fd:// --pod-infra-container-image=registry.aliyuncs.com/google_containers/pause:3.9启动cri
systemctl daemon-reload
systemctl enable --now cri-docker三、安装kubeadm和kubectl
所有节点都需要安装！
1、配置yum源
cat <<EOF | tee /etc/yum.repos.d/kubernetes.repo
[kubernetes]
name=Kubernetes
baseurl=https://mirrors.aliyun.com/kubernetes-new/core/stable/v1.28/rpm/
enabled=1
gpgcheck=1
gpgkey=https://mirrors.aliyun.com/kubernetes-new/core/stable/v1.28/rpm/repodata/repomd.xml.key
EOF2、安装
yum install -y kubelet kubeadm kubectl3、设置kubectl开机自启动
systemctl enable kubelet && systemctl start kubelet4、启动kubeadm和kubectl命令补齐功能
###低版本可能存在命令不能补齐 则进行部署
source <(kubeadm completion bash)
source <(kubectl completion bash)
echo -e "source <(kubeadm completion bash)\nsource <(kubectl completion bash)" >> /root/.bashrc
source /root/.bashrc四、部署Master节点
在k8s-master节点执行下述命令：
kubeadm init --apiserver-advertise-address=192.168.72.166 --image-repository=registry.aliyuncs.com/google_containers --kubernetes-version=v1.28.15 --pod-network-cidr=10.244.0.0/16 --service-cidr=10.96.0.0/12 --cri-socket=unix:///var/run/cri-dockerd.sock命令解析：
--apiserver-advertise-address：指定 API Server 监听的 IP 地址。如果没有设置，则将使用默认的网络接口。
--image-repository：指定镜像仓库地址。默认值为“registry.k8s.io”，但该仓库在中国无法访问，因此这里指定阿里云仓库。
--kubernetes-version：指定 Kubernetes 版本。
--pod-network-cidr：指定 Pod 网络的 CIDR 地址范围。
--service-cidr：指定 Service 网络的 CIDR 地址范围。
--cri-socket：指定 kubelet 连接容器运行时的 UNIX 套接字文件。
执行命令后，kubeadm 会执行一系列任务，具体如下：
[preflight]：该阶段执行一系列检查，验证当前系统环境是否满足 Kubernetes 的安装要求，包括：
CPU 和内存是否满足最低要求。
网络是否正常。
操作系统版本是否满足要求。
容器运行时是否可以连接。
内核参数是否正确配置。
下载所需的容器镜像。
[certs]：生成 Kubernetes 组件所需的 HTTPS 证书和密钥，并将其存储到“/etc/ kubernetes/pki”目录中。
[kubeconfig]：生成 kubeconfig 文件，其中包含 API Server 地址、客户端证书等信息，并将其存储在“/etc/kubernetes”目录中。
[kubelet-start]：生成 kubelet 配置文件“/var/lib/kubelet/config.yaml”并启动 kubelet服务。
[control-plane]：为 kube-apiserver、kube-controller-manager 和 kube-scheduler 创建静态 Pod 资源文件，并将其存储到“/etc/kubernetes/manifests”目录中。
[etcd]：为 etcd 创建静态 Pod 资源文件，并将其存储在“/etc/kubernetes/manifests”目录中。
[wait-control-plane]：等待 kubelet 从目录“/etc/kubernetes/manifest”中以静态 Pod的形式启动 Master 组件。
[apiclient]：检查 Master 组件是否健康。
[upload-config]：将 kubeadm 配置存储在 ConfigMap 对象中。
[kubelet]：将 kubelet 配置存储在 ConfigMap 对象中。
[upload-certs]：提示用户跳过证书上传。
[mark-control-plane]：给 Master 节点添加标签和污点。
[bootstrap-token]：生成引导令牌，供 Node 节点在加入集群时使用。
[kubelet-finalize]：更新 kubelet 配置文件（/etc/kubernetes/kubelet.conf）。
[addons]：安装 CoreDNS 和 kube-proxy 插件。出问题后，集群还原
kubeadm reset --cri-socket=unix:///var/run/cri-dockerd.sock注意保存证书文件
每个人的证书是不一致的，注意查看自己的证书。
kubeadm join 192.168.72.166:6443 --token 5a8kir.uig3tr5a2obzhtq5 \
--discovery-token-ca-cert-hash sha256:562a76a8d82f161c32f7db42ab35b96c9d02993952800cf11d2c5f4862413617 配置管理集群文件
mkdir -p $HOME/.kube
cd /root/.kube
cp /etc/kubernetes/admin.conf ./config
###查看集群状态
kubectl get nodes五、部署node节点
分别在k8s-node1和k8s-node2中执行：
kubeadm join 192.168.72.166:6443 --token 5a8kir.uig3tr5a2obzhtq5 \
--discovery-token-ca-cert-hash sha256:562a76a8d82f161c32f7db42ab35b96c9d02993952800cf11d2c5f4862413617 --cri-socket=unix:///var/run/cri-dockerd.sock查看集群状态：
[root@k8s-master ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
k8s-master NotReady control-plane 2d16h v1.28.15
k8s-node1 NotReady <none> 2d16h v1.28.15
k8s-node2 NotReady <none> 2m14s v1.28.15目前看到的是NotReady状态，是由于没有安装网络插件的原因。ROLES角色一栏显示“none”，可以通过一下命令修改角色名称：
kubectl label node k8s-master node-role.kubernetes.io/master=master
kubectl label node k8s-node1 node-role.kubernetes.io/worker=worker
kubectl label node k8s-node2 node-role.kubernetes.io/worker=worker六、部署网络插件
calico组件的相关镜像，目前在国内无法下载。需要在master主机先创建calico的相关资源，然后查看所需镜像，最后通过外网服务器进行下载。具体的操作流程如下：
提交资源清单：
wget https://raw.githubusercontent.com/projectcalico/calico/v3.29.2/manifests/tigera-operator.yaml
[root@k8s-master ~]# kubectl create -f tigera-operator.yaml
wget https://raw.githubusercontent.com/projectcalico/calico/v3.29.2/manifests/custom-resources.yaml
##编辑网络信息
vim custom-resources.yaml
apiVersion: operator.tigera.io/v1
kind: Installation
metadata:
name: default
spec:
calicoNetwork:
ipPools:
- blockSize: 26
cidr: 10.244.0.0/16 # 修改此值，与“kubeadm init”命令中指定的 Pod 网络CIDR 地址范围保持一致
encapsulation: VXLANCrossSubnet
natOutgoing: Enabled
nodeSelector: all()
...
[root@k8s-master ~]# kubectl create -f custom-resources.yaml
###此时可以查看到Kubernetes 集群 运行正常，所有核心组件和网络插件（Calico）均处于健康状态
[root@k8s-master ~]# kubectl -n calico-system get pod
NAME READY STATUS RESTARTS AGE
calico-kube-controllers-788b599b55-c7sjs 1/1 Running 0 62m
calico-node-4p9jj 1/1 Running 0 62m
calico-node-r8qfn 1/1 Running 0 62m
calico-node-wwprj 1/1 Running 0 62m
calico-typha-7b999544fb-nnl54 1/1 Running 0 62m
calico-typha-7b999544fb-q4dxn 1/1 Running 0 62m
csi-node-driver-4xhvj 2/2 Running 0 62m
csi-node-driver-j79jt 2/2 Running 0 62m
csi-node-driver-kxr74 2/2 Running 0 62m
[root@k8s-master ~]# kubectl -n kube-system get pod
NAME READY STATUS RESTARTS AGE
coredns-66f779496c-hbf4r 1/1 Running 0 5h30m
coredns-66f779496c-nffqw 1/1 Running 0 5h30m
etcd-k8s-master 1/1 Running 0 5h30m
kube-apiserver-k8s-master 1/1 Running 0 5h30m
kube-controller-manager-k8s-master 1/1 Running 0 5h30m
kube-proxy-6gg98 1/1 Running 0 4h53m
kube-proxy-99b7h 1/1 Running 0 5h30m
kube-proxy-kmsgl 1/1 Running 0 4h53m
kube-scheduler-k8s-master 1/1 Running 0 5h30m
[root@k8s-master ~]# kubectl get node
NAME STATUS ROLES AGE VERSION
k8s-master Ready control-plane,master 5h30m v1.28.15
k8s-node1 Ready worker 4h53m v1.28.15
k8s-node2 Ready worker 4h53m v1.28.15资源提交后，使用下述命令列出所需的镜像文件：
[root@k8s-master ~]# kubectl -n calico-system describe pod | grep "Image:" | sort | uniq
Image: docker.io/calico/cni:v3.29.2
Image: docker.io/calico/csi:v3.29.2
Image: docker.io/calico/kube-controllers:v3.29.2
Image: docker.io/calico/node-driver-registrar:v3.29.2
Image: docker.io/calico/node:v3.29.2
Image: docker.io/calico/pod2daemon-flexvol:v3.29.2
Image: docker.io/calico/typha:v3.29.2
[root@k8s-master ~]# kubectl -n calico-apiserver describe pod calico-apiserver | grep -i 'image:'
Image: docker.io/calico/apiserver:v3.29.2七、核心镜像作用
pause镜像
容器进程组的管理
在Kubernetes（k8s）集群中，pause容器是一种特殊的基础容器。它主要用于管理容器进程组。每个Pod中都会有一个pause容器，其进程ID（PID）为1。在Linux操作系统中，PID为1的进程比较特殊，它会成为所在进程组的组长，并且会接收一些系统信号，如SIGCHLD信号。当一个Pod中的其他容器的进程退出时，pause容器作为PID为1的进程可以正确地处理这些信号，避免出现僵尸进程等问题。
例如，假设一个Pod中有两个容器，一个是业务容器（如运行一个Web服务），另一个是pause容器。如果业务容器因为某种原因（如发生错误或者正常退出），pause容器会确保其退出后的资源回收和状态处理等工作能够正确进行，这就像一个管家一样，维护着整个Pod内进程的正常秩序。
共享命名空间的维护
pause容器的另一个核心作用是维护Pod内的共享命名空间。在Kubernetes中，一个Pod中的所有容器共享一些Linux命名空间，包括网络（net）、进程（pid）和挂载（mnt）等命名空间。pause容器作为一个基础容器，在创建时就会创建这些共享的命名空间。
以网络命名空间为例，当Pod中的业务容器（如容器A和容器B）需要进行网络通信时，它们共享pause容器创建的网络命名空间。这使得容器A和容器B可以通过localhost（127.0.0.1）互相访问，就好像它们在同一个主机上一样。pause容器在其中起到了类似于网络命名空间“锚点”的作用，确保了容器之间的网络通信能够正常进行。同时，对于挂载命名空间，pause容器确保了Pod中的容器可以共享存储卷等资源，方便容器之间的数据共享和交互。
资源隔离和协调
pause容器还能够帮助实现Pod内容器之间的资源隔离和协调。虽然Pod中的容器共享某些命名空间，但在资源使用方面，pause容器可以起到一定的限制和协调作用。
例如，在内存和CPU资源的使用上，pause容器可以作为一个参考点。Kubernetes的调度器在分配资源时，会考虑整个Pod（包括pause容器和其他业务容器）的资源需求。pause容器本身占用一定的资源（尽管资源占用量相对较小），它可以帮助调度器更好地评估Pod整体的资源消耗情况，从而实现更合理的资源分配。同时，在资源紧张的情况下，pause容器也可以通过一些机制（如cgroup等）来协调各个容器之间的资源使用，避免某个容器过度占用资源而导致其他容器无法正常运行。
kube - apiserver
集群控制入口：kube - apiserver是Kubernetes API的服务器，它是整个集群的控制平面入口。它对外暴露了Kubernetes的REST API，允许用户、集群内的其他组件（如kube - scheduler、kube - controller - manager等）以及外部工具（如kubectl命令行工具）通过HTTP/HTTPS协议与之交互。例如，当你使用kubectl命令创建一个Deployment时，kubectl会将请求发送到kube - apiserver，然后由kube - apiserver负责处理这个请求，将其转发到合适的组件进行后续操作。
资源管理和验证：它负责存储、管理和验证集群中的各种资源对象，包括但不限于Pods、Services、Deployments、ConfigMaps等。在接收资源创建、更新或删除请求时，kube - apiserver会验证请求的合法性，例如检查资源对象的格式是否正确、用户是否有足够的权限进行操作等。如果验证不通过，会返回相应的错误信息。
集群状态存储和查询：kube - apiserver维护着集群的状态信息。它将资源对象的状态存储在后端存储系统（通常是etcd）中，并且可以被其他组件查询。例如，kube - scheduler需要从kube - apiserver获取节点资源信息和待调度的Pod信息，以便做出合理的调度决策。
kube - controller - manager
控制器的管理核心：kube - controller - manager是一系列控制器的管理者。这些控制器负责维护集群的期望状态。例如，它包含了ReplicaSet控制器，当你定义了一个ReplicaSet，指定需要运行3个副本的某个Pod，ReplicaSet控制器会持续监控实际运行的Pod数量。如果发现实际运行的Pod数量小于3个，它会通过kube - apiserver创建新的Pod来满足期望的副本数量；反之，如果发现多于3个，它会删除多余的Pod。
资源同步和修复：它会不断地将集群的实际状态与期望状态进行对比。对于像Node（集群中的节点）这样的资源，它会检查节点是否健康。如果一个节点长时间没有心跳信息（表明可能出现故障），kube - controller - manager会将该节点标记为不可用，并调整在该节点上运行的资源（如将该节点上的Pods重新调度到其他健康节点），以确保集群的稳定性和资源的合理利用。
事件处理和记录：kube - controller - manager还负责处理和记录集群中的各种事件。当某个资源发生变化（如Pod状态从Running变为Failed）时，它会产生相应的事件，并将事件信息存储在集群中，用户可以通过kubectl命令查询这些事件，以了解集群中资源的动态变化情况。
kube - scheduler
资源调度决策：kube - scheduler的主要任务是为新创建的Pods选择合适的节点来运行。它会考虑多种因素进行调度决策，包括节点的资源可用性（如CPU、内存、磁盘空间等）、节点的负载情况、Pod对节点的亲和性和反亲和性要求、节点的标签等。例如，如果一个Pod需要大量的内存资源，kube - scheduler会选择内存资源充足的节点来运行这个Pod。
优化资源分配：通过合理的调度策略，kube - scheduler可以优化集群的资源分配。它可以平衡各个节点的负载，避免某些节点过度繁忙而其他节点空闲的情况。例如，它可以采用bin - packing策略，将多个小的Pods尽可能紧凑地安排在一个节点上，以提高节点的资源利用率；或者采用spreading策略，将相同类型的Pods分散在不同的节点上，以降低单点故障的风险。
调度算法和插件支持：kube - scheduler支持多种调度算法和插件。它可以根据用户的需求和集群的特点选择合适的调度算法，如基于优先级的调度算法、公平调度算法等。同时，用户也可以开发自己的调度插件来扩展kube - scheduler的功能，以满足特殊的调度需求，如根据特定的业务逻辑或硬件特性进行调度。
kube - proxy
服务代理和负载均衡：kube - proxy主要负责实现Kubernetes服务（Service）的代理和负载均衡功能。在集群中，当创建一个服务时，kube - proxy会在每个节点上运行，并监听服务相关的事件。它会为服务创建相应的虚拟IP（VIP），这个VIP会被集群内的其他组件用来访问服务。例如，对于一个名为my - service的服务，kube - proxy会确保通过my - service的VIP访问时，请求能够被正确地负载均衡到后端对应的Pods上。
网络规则维护：kube - proxy会维护网络规则，以实现服务的访问控制。它可以根据服务的类型（如ClusterIP、NodeIP、LoadBalancer等）设置不同的网络访问规则。对于ClusterIP类型的服务，它会设置规则使得只有集群内部的组件可以访问；对于NodeIP类型的服务，它会允许通过节点的IP访问服务；对于LoadBalancer类型的服务，它会与外部的负载均衡器（如云平台提供的负载均衡器）协作，将外部流量引入集群并正确地分配到后端Pods。
IPVS和iptables支持：kube - proxy支持多种实现方式，如基于iptables和IPVS（IP Virtual Server）。当使用IPVS时，它可以提供更高效的负载均衡性能，尤其是在处理大量并发连接时。kube - proxy会根据集群的配置和实际需求选择合适的实现方式，并且可以动态地切换实现方式以优化服务的代理和负载均衡功能。
etcd
集群状态存储后端：etcd是一个分布式的键值存储系统，它是Kubernetes集群的存储后端。它存储了集群中所有资源对象的状态信息，包括Pods、Services、Nodes等各种资源的配置、状态和元数据。例如，当kube - apiserver接收到一个新的Pod创建请求并处理完成后，会将Pod的相关信息（如Pod的名称、所在节点、容器配置等）存储到etcd中。
一致性和可靠性保障：etcd通过分布式一致性算法（如Raft算法）来保证数据的一致性和可靠性。在集群中有多个etcd节点的情况下，即使部分节点出现故障，只要多数节点（通常是超过半数）正常工作，集群就能够正常运行，数据也不会丢失。这对于存储集群的关键状态信息至关重要，因为任何数据不一致或丢失都可能导致集群的不稳定或错误的操作。
数据查询和更新支持：其他集群组件（如kube - apiserver）可以方便地从etcd中查询和更新数据。例如，kube - scheduler在进行调度决策时，需要从etcd中获取节点资源信息和待调度的Pod信息；kube - controller - manager在检查和更新资源状态时，也需要与etcd进行交互。etcd提供了高效的键值查询和更新接口，支持通过键（如资源对象的名称或唯一标识符）来获取或修改对应的状态信息。
coredns
集群内域名解析服务：CoreDNS是Kubernetes集群内的域名解析服务。它负责将服务名称（如my - service）解析为对应的IP地址（如服务的虚拟IP或者后端Pods的IP）。在集群中，当一个容器需要访问另一个服务时，它会向CoreDNS发送域名解析请求。例如，一个运行在Pod中的应用程序想要访问名为my - service的服务，它会通过容器内配置的DNS服务器（通常是CoreDNS）将my - service解析为实际可访问的IP地址，然后建立连接进行通信。
服务发现支持：CoreDNS通过与Kubernetes API交互，动态地获取服务的信息，从而实现服务发现功能。它可以根据服务的创建、更新或删除事件及时更新DNS记录。例如，当一个新的服务被创建，CoreDNS会立即将其添加到DNS记录中；当一个服务的后端Pods发生变化（如增加或减少副本），CoreDNS也会相应地更新解析记录，确保服务的访问始终是准确和最新的。
灵活的配置和插件机制：CoreDNS支持灵活的配置和插件机制。用户可以通过配置文件来定制DNS解析规则和行为。例如，可以添加插件来实现自定义的域名过滤、缓存策略等功能。它还可以与外部的DNS系统进行集成，将部分域名解析请求转发到外部DNS服务器，从而扩展集群DNS服务的功能和范围。
calico
-
calico - typha
- 核心作用
- 优化API访问性能：在Calico网络方案中，Typha充当一个代理，用于优化集群中大量节点对Calico API服务器的访问。当集群规模较大时，众多节点频繁地访问Calico API会产生较大的负载。Typha通过聚合这些请求，减少了直接对Calico API服务器的并发连接数，从而提高了网络配置和策略分发的效率。
- 减轻Calico API服务器压力：它作为中间层接收来自各个节点的请求，如节点获取网络策略、IP地址分配等相关请求。通过缓存部分信息并批量处理请求，避免每个节点的请求都直接冲击Calico API服务器，使得Calico API服务器能够更高效地处理重要的网络配置任务，保证了整个网络系统的稳定性。
-
calico - kube - controllers
- 核心作用
- Kubernetes资源与Calico集成管理：它主要负责将Calico网络策略和Kubernetes资源进行集成。例如，当在Kubernetes中创建一个新的Namespace，并为该Namespace定义了网络隔离策略时，calico - kube - controllers会将这些策略转换为Calico能够理解的网络规则，并确保这些规则在Calico网络中得到正确的应用。
- 网络策略同步与更新：它会持续监控Kubernetes资源（如Pods、Services等）的变化和Calico网络状态。如果Kubernetes中的资源发生变化（如Pod的标签更新导致网络访问权限改变）或者Calico网络策略需要更新（如安全策略的升级），calico - kube - controllers会及时同步这些变化，确保网络策略始终与Kubernetes资源的实际需求相匹配。
-
calico - cni
- 核心作用
- 容器网络接口实现：Calico CNI（Container Network Interface）是Calico用于在Kubernetes集群中为容器配置网络的关键组件。它遵循CNI规范，负责为每个新创建的Pod分配IP地址，并将Pod连接到Calico网络。例如，当一个Pod在节点上启动时，calico - cni会根据预先配置的IP地址池为Pod分配一个唯一的IP地址，就像给每个新入住的居民分配一个唯一的家庭住址一样。
- 网络配置与连接建立：它会为Pod配置网络接口，包括设置IP地址、子网掩码、网关等网络参数。同时，calico - cni还会建立Pod与Calico网络之间的连接，确保Pod能够与集群内的其他Pod以及外部网络进行通信。例如，它会通过配置路由规则和网络隧道（如IP - in - IP隧道或VXLAN隧道，取决于Calico的配置）来实现Pod之间的跨节点通信。
-
calico - node - driver - registrar
- 核心作用
- 设备驱动注册与管理：主要用于在节点级别注册和管理Calico网络相关的设备驱动。在一些复杂的网络环境或者需要特殊硬件支持的场景下，设备驱动是实现网络功能的关键。calico - node - driver - registrar会确保这些设备驱动能够正确地在节点上注册，使得Calico网络能够利用这些驱动来实现高效的网络通信。
- 与节点资源交互协作：它与节点的其他资源（如内核模块、网络设备等）紧密协作。例如，当Calico网络需要使用一种新的网络设备来提高网络性能时，calico - node - driver -registrar会负责将该设备的驱动程序注册到节点上，并协调其他组件（如calico - cni）来利用这个设备为Pod提供网络服务。
-
calico - csi
- 核心作用
- 容器存储接口支持：Calico CSI（Container Storage Interface）是Calico用于提供容器存储功能的组件。它使得Kubernetes集群能够使用Calico的存储资源来满足容器的存储需求。例如，当一个Pod需要持久化存储来保存数据（如数据库容器需要存储数据文件），calico - csi会与存储系统（如Calico支持的分布式存储）协作，为Pod提供合适的存储卷，并完成存储卷的挂载和卸载等操作。
- 存储资源管理与分配：负责管理和分配Calico的存储资源。它会根据Pod的存储请求（如存储大小、存储类型等要求），从可用的存储资源池中选择合适的存储卷，并将其分配给Pod。同时，calico - csi还会维护存储资源的状态信息，如存储卷的使用情况、健康状态等，确保存储资源的合理利用和数据安全。
-
calico - pod2daemon - flexvol
- 核心作用
- 灵活卷插件功能扩展：它是一种灵活卷（FlexVol）插件，用于在Pod和守护进程（Daemon）之间实现更灵活的存储交互。例如，在一些需要共享存储资源的场景下，如日志收集守护进程需要访问多个Pod产生的日志文件，calico - pod2daemon - flexvol可以提供一种灵活的存储连接方式，使得守护进程能够方便地访问Pod的存储卷。
- 存储共享与访问优化：这个插件可以优化存储共享的过程。它通过特殊的存储访问机制，减少了存储共享过程中的资源开销和复杂性。例如，它可以避免不必要的存储卷挂载和卸载操作，提高存储资源的使用效率，并且能够更好地适应不同类型的Pod和守护进程对存储的需求。
-
calico - node
- 核心作用
- 节点网络功能实现：Calico - node是Calico网络在每个节点上的核心组件。它负责维护节点的网络配置，包括设置节点的IP地址、子网掩码、网关等基本网络参数，以及建立和维护节点与其他节点之间的网络连接。例如，它会在节点上配置Calico网络所需的路由规则，使得该节点上的Pods能够与其他节点上的Pods进行通信。
- 网络策略执行与监控：在节点层面执行Calico网络策略。当有网络流量进出节点上的Pods时，calico - node会根据预先定义的网络策略（如允许或禁止某些IP地址段的访问、限制某些端口的通信等）进行检查和过滤。同时，它还会监控节点上的网络流量情况，及时发现异常流量（如可能的网络攻击或违规访问）并采取相应的措施。
八、master节点与node节点配置比例
在Kubernetes集群中，master节点与node节点的性能比例并非固定，需根据集群规模、工作负载类型及高可用性需求动态调整。以下是关键指导原则：
1. 核心组件资源需求
-
Master节点：运行API Server、Scheduler、Controller Manager和etcd（可能独立部署）。资源消耗受集群规模、API请求频率、Pod调度频率等影响。
-
Node节点：运行工作负载，资源需求由应用决定（CPU/内存密集型等）。
2. 配置建议
-
小型集群（≤10 nodes）：
-
Master：2-4核CPU，4-8GB内存。
-
可单master，无需HA，etcd可与master共置（但建议SSD磁盘）。
-
-
中型集群（10-50 nodes）：
-
Master：4-8核CPU，8-16GB内存。
-
建议HA部署（3 masters），etcd独立部署并使用SSD。
-
-
大型集群（50+ nodes）：
-
Master：8+核CPU，16+GB内存。
-
必须HA部署，etcd集群独立（3-5节点，高性能存储）。
-
需监控控制平面组件，动态调整资源。
-
3. 关键因素
-
etcd性能：对I/O敏感，需低延迟存储（SSD），独立部署以避免资源竞争。
-
API Server负载：高频API请求（如微服务场景）需更高CPU。
-
高可用性（HA）：多master节点增加资源开销，但提升可靠性。
4. 示例比例
-
非HA环境：每50-100 nodes配置1个master（4核8GB）。
-
HA环境：3 masters支撑100+ nodes，每master至少8核16GB。
-
超大规模：需分片或使用云托管方案（如EKS、GKE）减轻控制平面压力。
5. 监控与优化
-
使用工具（Prometheus、kube-state-metrics）监控资源使用。
-
根据实际负载调整配置，而非依赖静态比例。
6. 托管服务简化
-
使用云托管Kubernetes（如EKS、GKE）可将master节点管理交由云厂商，专注node节点优化。
总结
通过本教程，我们成功在 OpenEuler 24.03 系统上部署了 Kubernetes 1.28 单 Master 集群，并完成了以下关键步骤：
1.环境准备：配置主机名、禁用 Swap、优化内核参数（如 br_netfilter、ip_forward）。
2.容器运行时（CRI）安装：使用 containerd或 cri-dockerd作为 Kubernetes 的运行时接口。
3.Kubeadm 初始化：通过阿里云镜像源快速拉取组件，并初始化控制平面。
4.CNI 网络插件部署：安装 Flannel/Calico 实现 Pod 网络互通。
5.Worker 节点加入：使用 kubeadm join将节点纳入集群管理。
关键经验
镜像加速：使用国内镜像源（如阿里云、华为云）可大幅提升组件拉取速度。
内核适配：OpenEuler 需额外关注 br_netfilter和 ipvs模块的加载。
网络选择：Flannel 适合简单场景，Calico 更适合需要网络策略的生产环境。
后续建议
探索 高可用集群（多 Master + Keepalived）。
部署 Ingress Controller（如 Nginx/Traefik） 管理服务暴露。
结合 Prometheus + Grafana 实现集群监控。
本教程旨在提供 开箱即用 的部署方案，助你快速进入 Kubernetes 的世界。如有问题，欢迎在评论区交流！
鲲鹏昇腾开发者社区是面向全社会开放的“联接全球计算开发者，聚合华为+生态”的社区，内容涵盖鲲鹏、昇腾资源，帮助开发者快速获取所需的知识、经验、软件、工具、算力，支撑开发者易学、好用、成功，成为核心开发者。
更多推荐
18
0- 0
已为社区贡献1条内容
所有评论(0)