K8s集群搭建全流程详解

一、服务器环境及初始化

1、架构分析

集群角色	主机名	操作系统	IP地址
master	k8s-master	OpenEuler24.03	192.168.238.128
node	k8s-node1	OpenEuler24.03	192.168.238.129
node	k8s-node2	OpenEuler24.03	192.168.238.130

2、初始化

所有节点都需要初始化！

2.1、清空Iptales默认规则及关闭防火墙

复制代码

iptables -t nat -F
iptables -t filter -F
systemctl disable --now firewalld

2.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-node2

2.5、编写hosts文件

复制代码

cat <<EOF > /etc/hosts 
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
192.168.238.128   k8s-master
192.168.238.129   k8s-node1
192.168.238.130   k8s-node2
EOF

###拷贝到node节点
scp /etc/hosts 192.168.238.129:/etc
scp /etc/hosts 192.168.238.130:/etc

2.6、设置内核参数

复制代码


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、配置阿里源

复制代码

cat <<EOF >> /etc/yum.repos.d/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/gpg
EOF

1.2、安装docker

复制代码

yum install -y docker-ce-28.0.3

1.3、启动docker

复制代码

cat <<EOF >>/etc/docker/daemon.json
{
    "registry-mirrors": [
        "https://0vmzj3q6.mirror.aliyuncs.com",
        "https://docker.m.daocloud.io",
        "https://mirror.baidubce.com",
        "https://dockerproxy.com",
        "https://mirror.iscas.ac.cn",
        "https://huecker.io",
        "https://dockerhub.timeweb.cloud",
        "https://noohub.ru",
        "https://vlgh0kqj.mirror.aliyuncs.com"
    ]
}
EOF
systemctl daemon-reload
systemctl enable --now docker

2、安装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
#或者
yum localinstall 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
EOF

2、安装

复制代码

yum install -y kubelet kubeadm kubectl

3、设置kubectl开机自启动

复制代码

systemctl enable kubelet && systemctl start kubelet

4、启动kubeadm和kubectl命令补齐功能（OpenEuler不用）

复制代码

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.238.128 --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.238.128:6443 --token lc8z1k.j8lnrixca1e61cgp \
        --discovery-token-ca-cert-hash sha256:662fecb08139e912c204c079902a8ed310f460ed6971d6537406d8740eb316b7

配置管理集群文件

复制代码

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.238.128:6443 --token yfpfev.qcwe566xkv0v646b \
        --discovery-token-ca-cert-hash sha256:17288e006a6f1c0a8c4ac6b1311c1f3792edc93179d3fc84a0efb4a10ffc19fa   --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.26.0/manifests/tigera-operator.yaml [root@k8s-master ~]# kubectl create -f tigera-operator.yaml
wget https://raw.githubusercontent.com/projectcalico/calico/v3.26.0/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

资源提交后，使用下述命令列出所需的镜像文件：

复制代码

[root@k8s-master ~]# kubectl -n calico-system describe pod | grep "Image:" | sort | uniq 
    Image:           docker.io/calico/cni:v3.26.0
    Image:           docker.io/calico/csi:v3.26.0
    Image:           docker.io/calico/kube-controllers:v3.26.0

复制代码

[root@k8s-master ~]# kubectl -n calico-system describe pod | grep "Image:" | sort | uniq 
    Image:           docker.io/calico/cni:v3.26.0
    Image:           docker.io/calico/csi:v3.26.0
    Image:           docker.io/calico/kube-controllers:v3.26.0
    Image:           docker.io/calico/node-driver-registrar:v3.26.0
    Image:           docker.io/calico/node:v3.26.0
    Image:           docker.io/calico/pod2daemon-flexvol:v3.26.0
    Image:           docker.io/calico/typha:v3.26.0
 [root@k8s-master ~]# kubectl -n calico-apiserver describe pod calico-apiserver-894947d4b-bqc7x  | grep -i 'image:'
    Image:           docker.io/calico/apiserver:v3.26.0

七、部署Dashboard

复制代码

下载Dashboard资源清单：

wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml
修改Service类型：

vim recommended.yaml 
...
kind: Service 
apiVersion: v1 
metadata: 
 labels: 
 k8s-app: kubernetes-dashboard 
 name: kubernetes-dashboard 
 namespace: kubernetes-dashboard 
spec: 
 type: NodePort # 指定 NodePort 类型
 ports: 
 - port: 443 
 targetPort: 8443 
 nodePort: 30001 # 指定访问端口
 selector: 
 k8s-app: kubernetes-dashboard
在集群中创建资源：

[root@k8s-master ~]# kubectl apply -f recommended.yaml 
查看 Pod 对象：

[root@k8s-master ~]# kubectl get pods -n kubernetes-dashboard

复制代码

所有 Pod 的状态都显示为"Running"，说明 Dashboard 安装成功。在浏览器中访问 "https://<节点 IP 地址>:30001"即可看到WEB UI界面。

创建一个服务账号并授予集群管理员权限：

复制代码

[root@k8s-master ~]# kubectl create serviceaccount admin-user -n kubernetes-dashboard 

[root@k8s-master ~]# kubectl create clusterrolebinding admin-user --clusterrole=cluster-admin --serviceaccount=kubernetes-dashboard:admin-user

根据服务账号创建 Token：

复制代码

[root@k8s-master ~]# kubectl create token admin-user -n kubernetes-dashboard

将输出的 Token 复制到输入框中，然后单击登录，进入 Dashboard 首页，如图所示。

八、Metrics部署

系统资源的采集需要使用Metrics-server，能够采集节点和pod的内存、磁盘、CPU、网络的使用率！

复制代码

######将k8s-master01的front-proxy-ca.crt文件复制到所有NODE节点
[root@k8s-master01 ~]# scp /etc/kubernetes/pki/front-proxy-ca.crt k8s-node1:/etc/kubernetes/pki/
[root@k8s-master01 ~]# scp /etc/kubernetes/pki/front-proxy-ca.crt k8s-node2:/etc/kubernetes/pki/

##下载0.7版本的metrics
#下载地址：https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.7.0/components.yaml
#或者网络方式安装：
[root@k8s-master01 ~]# kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.7.0/components.yaml

###修改yaml文件镜像源及探针模式
[root@k8s-master01 metrics]# cat components.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    k8s-app: metrics-server
    rbac.authorization.k8s.io/aggregate-to-admin: "true"
    rbac.authorization.k8s.io/aggregate-to-edit: "true"
    rbac.authorization.k8s.io/aggregate-to-view: "true"
  name: system:aggregated-metrics-reader
rules:
- apiGroups:
  - metrics.k8s.io
  resources:
  - pods
  - nodes
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  labels:
    k8s-app: metrics-server
  name: system:metrics-server
rules:
- apiGroups:
  - ""
  resources:
  - nodes/metrics
  verbs:
  - get
- apiGroups:
  - ""
  resources:
  - pods
  - nodes
  verbs:
  - get
  - list
  - watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server-auth-reader
  namespace: kube-system
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: extension-apiserver-authentication-reader
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server:system:auth-delegator
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:auth-delegator
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  labels:
    k8s-app: metrics-server
  name: system:metrics-server
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:metrics-server
subjects:
- kind: ServiceAccount
  name: metrics-server
  namespace: kube-system
---
apiVersion: v1
kind: Service
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
spec:
  ports:
  - name: https
    port: 443
    protocol: TCP
    targetPort: https
  selector:
    k8s-app: metrics-server
---
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    k8s-app: metrics-server
  name: metrics-server
  namespace: kube-system
spec:
  selector:
    matchLabels:
      k8s-app: metrics-server
  strategy:
    rollingUpdate:
      maxUnavailable: 0
  template:
    metadata:
      labels:
        k8s-app: metrics-server
    spec:
      containers:
      - args:
        - --cert-dir=/tmp
        - --secure-port=10250
        - --kubelet-preferred-address-types=InternalIP,ExternalIP,Hostname
        - --kubelet-use-node-status-port
        - --metric-resolution=15s
        - --kubelet-insecure-tls     ##增加证书验证
        image: registry.aliyuncs.com/google_containers/metrics-server:v0.7.2   ##修改为国内镜像源
        imagePullPolicy: IfNotPresent
        livenessProbe:
          failureThreshold: 3
          tcpSocket:     ###修改探针模式
            port: 10250  ###修改探测端口
          periodSeconds: 10
        name: metrics-server
        ports:
        - containerPort: 10250
          name: https
          protocol: TCP
        readinessProbe:
          failureThreshold: 3
          tcpSocket:		###修改探针模式
            port: 10250	###修改探测端口
          initialDelaySeconds: 20
          periodSeconds: 10
        resources:
          requests:
            cpu: 100m
            memory: 200Mi
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            drop:
            - ALL
          readOnlyRootFilesystem: true
          runAsNonRoot: true
          runAsUser: 1000
          seccompProfile:
            type: RuntimeDefault
        volumeMounts:
        - mountPath: /tmp
          name: tmp-dir
      nodeSelector:
        kubernetes.io/os: linux
      priorityClassName: system-cluster-critical
      serviceAccountName: metrics-server
      volumes:
      - emptyDir: {}
        name: tmp-dir
---
apiVersion: apiregistration.k8s.io/v1
kind: APIService
metadata:
  labels:
    k8s-app: metrics-server
  name: v1beta1.metrics.k8s.io
spec:
  group: metrics.k8s.io
  groupPriorityMinimum: 100
  insecureSkipTLSVerify: true
  service:
    name: metrics-server
    namespace: kube-system
  version: v1beta1
  versionPriority: 100

九、核心镜像作用

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节点优化。

总结

无固定比例，需结合集群规模、工作负载及监控数据动态规划。小型集群可轻量配置，中大型需HA及独立etcd，超大规模建议托管方案。定期性能调优是关键。