kubernetes安装部署流程

一、 服务器环境及初始化

1、架构分析

| 集群角色 | 主机名 | 操作系统 | IP地址 |

| --- | --- | --- | --- |

| master | k8s-master | OpenEuler24.03 | 192.168.166.128 |

| node | k8s-node1 | OpenEuler24.03 | 192.168.166.129 |

| node | k8s-node2 | OpenEuler24.03 | 192.168.166.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.166.128 k8s-master

192.168.166.129 k8s-node1

192.168.166.130 k8s-node2

EOF

###拷贝到node节点

scp /etc/hosts 192.168.166.129:/etc

scp /etc/hosts 192.168.166.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不用)

yum install -y bash-completion

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.166.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.166.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.166.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 \ 2d16h v1.28.15 k8s-node2 NotReady \ 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 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界面。 !\[image20250310232353540\](/D:\\ovf\\运维工程师课件\\3、Kubernetes运维\\1、K8S集群部署与应用/1、K8S-单Master集群部署-OpenEuler24.03.assets/image-20250310232353540.png) \*\*创建一个服务账号并授予集群管理员权限:\*\* \[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 首页,如图所示。 !\[image20250310232453872\](/D:\\ovf\\运维工程师课件\\3、Kubernetes运维\\1、K8S集群部署与应用/1、K8S-单Master集群部署-OpenEuler24.03.assets/image-20250310232453872.png) # 八、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 1. \*\*calico - typha\*\*\\- \*\*核心作用\*\*\\- \*\*优化API访问性能\*\*:在Calico网络方案中,Typha充当一个代理,用于优化集群中大量节点对Calico API服务器的访问。当集群规模较大时,众多节点频繁地访问Calico API会产生较大的负载。Typha通过聚合这些请求,减少了直接对Calico API服务器的并发连接数,从而提高了网络配置和策略分发的效率。\\- \*\*减轻Calico API服务器压力\*\*:它作为中间层接收来自各个节点的请求,如节点获取网络策略、IP地址分配等相关请求。通过缓存部分信息并批量处理请求,避免每个节点的请求都直接冲击Calico API服务器,使得Calico API服务器能够更高效地处理重要的网络配置任务,保证了整个网络系统的稳定性。 2. \*\*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资源的实际需求相匹配。 3. \*\*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之间的跨节点通信。 4. \*\*calico - node - driver - registrar\*\*\\- \*\*核心作用\*\*\\- \*\*设备驱动注册与管理\*\*:主要用于在节点级别注册和管理Calico网络相关的设备驱动。在一些复杂的网络环境或者需要特殊硬件支持的场景下,设备驱动是实现网络功能的关键。calico - node - driver - registrar会确保这些设备驱动能够正确地在节点上注册,使得Calico网络能够利用这些驱动来实现高效的网络通信。\\- \*\*与节点资源交互协作\*\*:它与节点的其他资源(如内核模块、网络设备等)紧密协作。例如,当Calico网络需要使用一种新的网络设备来提高网络性能时,calico - node - driver -registrar会负责将该设备的驱动程序注册到节点上,并协调其他组件(如calico - cni)来利用这个设备为Pod提供网络服务。 5. \*\*calico - csi\*\*\\- \*\*核心作用\*\*\\- \*\*容器存储接口支持\*\*:Calico CSI(Container Storage Interface)是Calico用于提供容器存储功能的组件。它使得Kubernetes集群能够使用Calico的存储资源来满足容器的存储需求。例如,当一个Pod需要持久化存储来保存数据(如数据库容器需要存储数据文件),calico - csi会与存储系统(如Calico支持的分布式存储)协作,为Pod提供合适的存储卷,并完成存储卷的挂载和卸载等操作。\\- \*\*存储资源管理与分配\*\*:负责管理和分配Calico的存储资源。它会根据Pod的存储请求(如存储大小、存储类型等要求),从可用的存储资源池中选择合适的存储卷,并将其分配给Pod。同时,calico - csi还会维护存储资源的状态信息,如存储卷的使用情况、健康状态等,确保存储资源的合理利用和数据安全。 6. \*\*calico - pod2daemon - flexvol\*\*\\- \*\*核心作用\*\*\\- \*\*灵活卷插件功能扩展\*\*:它是一种灵活卷(FlexVol)插件,用于在Pod和守护进程(Daemon)之间实现更灵活的存储交互。例如,在一些需要共享存储资源的场景下,如日志收集守护进程需要访问多个Pod产生的日志文件,calico - pod2daemon - flexvol可以提供一种灵活的存储连接方式,使得守护进程能够方便地访问Pod的存储卷。\\- \*\*存储共享与访问优化\*\*:这个插件可以优化存储共享的过程。它通过特殊的存储访问机制,减少了存储共享过程中的资源开销和复杂性。例如,它可以避免不必要的存储卷挂载和卸载操作,提高存储资源的使用效率,并且能够更好地适应不同类型的Pod和守护进程对存储的需求。 7. \*\*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,超大规模建议托管方案。定期性能调优是关键。

相关推荐
SilentSamsara3 小时前
Kubernetes 网络模型:CNI 插件与 Pod 间通信的底层实现
网络·云原生·容器·架构·kubernetes·k8s
Nice__J5 小时前
ISO26262功能安全——顶层设计之“安全架构”
安全·安全架构
Flittly6 小时前
【SpringSecurity新手村系列】(6)基于角色的权限控制、权限拦截注解与自定义无权限页面
java·spring boot·安全·spring·安全架构
jinanwuhuaguo1 天前
OpenClaw智能体的涌现与异化——复杂系统演化、知识权力重构与文明纪元跃迁(第五篇)
大数据·开发语言·人工智能·重构·安全架构·openclaw
上海云盾-小余1 天前
出海业务安全架构搭建:跨境云主机合规部署与全域抗攻击策略
安全·安全架构
久绊A1 天前
在K8s中构建Apache服务的弹性伸缩防线
k8s
white-persist2 天前
逆向入门经典题:从 IDA 反编译坑点到 Python 解题详细分析解释
c语言·开发语言·数据结构·python·算法·逆向·安全架构
梵得儿SHI2 天前
SpringCloud 生产级落地:Docker 容器化 + K8s 编排部署全攻略(含完整 yaml + 避坑指南)
docker·云原生·kubernetes·k8s·springcloud·微服务部署·java 后端
Agent手记2 天前
等保三级合规:企业级智能体全链路数据安全落地方案 —— 2026年企业级AI Agent安全架构实战
人工智能·安全·ai·安全架构