架构组件简介

1、控制平面结构

etcd

分布式键值对数据库，go语言
etcd v3 版本默认使用 gRPC 作为客户端与服务端的通信协议
存储目录默认在 /var/lib/etcd。
- wal/：WAL 日志目录（实时写入，保障数据不丢失）
- snap/：快照目录（定期生成，压缩存储）
- member/：节点元数据与 MVCC 数据文件

etcdctl ls /registry                                     # 获取资源列表，按类展示
etcdctl ls /registry/pods                                # 获取pod，按命名空间存放
etcdctl ls /registry/pods/default                        # 查看该命名空间下的pod
etcdctl get /registry/pods/default/kubia-632228-fdsen    # pod以json格式定义
etcdctl get /registry --prefix=true                      # 获取指定前缀的资源

# 生产环境配置建议
etcd \
  --data-dir=/data/etcd  # 自定义数据存储目录（建议挂载独立磁盘）
  --wal-dir=/data/etcd/wal  # 单独指定 WAL 目录（提升写入性能，建议用 SSD）
  --snapshot-count=5000  # 每 5000 次操作生成一次快照（默认 10000）
  --auto-compaction-mode=periodic  # 自动压缩模式（periodic=定期，default=按空间）
  --auto-compaction-retention=1h  # 保留 1 小时的历史数据（默认 1h）

# 手动备份etcd数据（全量备份）
etcdctl --endpoints=https://192.168.1.10:2379 \
  --cacert=/etc/kubernetes/pki/etcd/ca.crt \
  --cert=/etc/kubernetes/pki/etcd/server.crt \
  --key=/etc/kubernetes/pki/etcd/server.key \
  snapshot save /backup/etcd-snapshot-$(date +%Y%m%d).db

# 验证备份文件
etcdctl snapshot status /backup/etcd-snapshot-20240520.db

# 从备份恢复 etcd 集群
etcd --data-dir=/var/lib/etcd-restore \
  --initial-cluster=etcd-restore=https://192.168.1.10:2380 \
  --initial-cluster-token=etcd-cluster-1 \
  --initial-advertise-peer-urls=https://192.168.1.10:2380 \
  --snapshot=/backup/etcd-snapshot-20240520.db

# 查看快照生成频率
etcdctl --endpoints=https://192.168.1.10:2379 endpoint status -w json | jq '.[] | .status.snapshotIndex'

kube-scheduler

负责将新创建的pod调度到node上，考虑的因素有节点的资源（例如：CPU、内存）可用性、节点的亲和性和反亲和性、节点的污点和容忍
也可以编写自定义的调度器，实现定制化pod调度策略，例如pod不会调度到cpu负载超过70%的Node上。

kube-apiserver

是K8S集群一切访问的入口，负责接受整个集群的所有内部请求，K8S各组件通过它来与etcd通信
API Server和其他组件间的通信，一般由组件发起连接
获取日志（kubectl get log），连接容器（kubectl attach），转发端口（kubectl port-forward），均由API Server发起连接
etcd和API Server可以多实例同时运行，Scheduler和controller manager在给定时间内只有一个实例起作用，其他实例处于待命状态

kube-controller manager

它是一个单独的控制平面组件，内部集成了所有 Kubernetes 内置控制器的逻辑，统一负责它们的启动、运行和协调
内部核心控制器示例：NodeController、ReplicaSetController、DeploymentController、ServiceController、NamespaceController、PersistentVolumeController
从运维角度看，只需部署和监控 kube-controller-manager 这一个组件，就能确保所有内置控制器正常工作
自定义控制器如 Operator，需单独部署，且独立于controller-manager

# 查看 kube-controller-manager Pod
kubectl get pods -n kube-system | grep kube-controller-manager

# 查看组件日志（验证内部控制器运行状态）
kubectl logs -n kube-system kube-controller-manager-<节点名> | grep -E "Controller|Starting controller"

# 查看组件健康状态。输出 "ok" 表示正常
kubectl get --raw /healthz/controller-manager

# 典型启动参数（简化版，实际部署时包含更多配置）
kube-controller-manager \
  --kubeconfig=/etc/kubernetes/controller-manager.conf \    # 连接 APIServer 的配置
  --leader-elect=true \                                     # 启用 leader 选举（高可用必需）
  --controllers=*,bootstrapsigner,tokencleaner \            # 指定要启用的控制器（默认全部启用）
  --cluster-signing-cert-file=/etc/kubernetes/pki/ca.crt \  # 集群签名证书
  --cluster-signing-key-file=/etc/kubernetes/pki/ca.key

2、工作平面架构结构

kubelet

在集群中的每一个node上运行，具体作用如下
容器生命周期管理：负责创建、启动、停止和销毁容器
资源监控：定期检查节点上的资源利用情况，然后报告给Master。
健康检查：定期检查容器健康状况，如果不健康，则重启容器或者通知Master节点以采取措施。
与API-Server通信：通过与API-Server的通信来同步本Node上的对象状态更新，以及获取其他对象的更新。
kubelet也负责容器的存活探针，探针报错它重启容器

kube proxy

是集群中每个节点上的网络代理，维护节点网络规则，具体作用如下
负载均衡：根据不同的负载均衡策略将请求分发给对应的后端Pod。
集群外部访问：可以将外部流量路由到集群内部的服务

CRI

容器运行时，是负责运行容器的软件（continer runtime interfices），例如docker

3、附属组件

CoreDNS

为集群提供域名解析

4、管理命令

# 检查组件状态
kubectl get componentStatus

# 自定义显示列并排序（POD和NODE是自定义的列标题）
kubectl get pod -o custom-columns=POD:metadata.name,NODE:spec.nodeName \
  -n kube-system \
  --sort-by spec.nodeName

posted @ 2026-03-27 11:34 立勋阅读(46) 评论(0) 收藏举报

刷新页面返回顶部

题

架构 组件简介