本文还有配套的精品资源，点击获取

简介：Kubernetes（K8s）是Google开源的容器编排系统，用于自动化部署、扩展和管理容器化应用。本指南详细介绍了Kubernetes集群的搭建流程，包括节点配置、网络设置、核心组件安装与验证，以及扩展组件CoreDNS的安装与配置。通过本指南操作，可帮助用户构建一个功能完善、可扩展的Kubernetes环境，适用于容器化应用的部署与管理实战。

1. Kubernetes基础概念介绍

Kubernetes（简称K8s）是当前最主流的容器编排平台，其核心目标是实现容器化应用的自动化部署、扩展与管理。它通过声明式API定义应用期望状态，并持续驱动实际状态向目标对齐。系统架构上，K8s采用主从模式，由Master节点负责集群控制平面，Worker节点运行用户工作负载。核心组件包括Pod（最小调度单位）、Service（服务发现与负载均衡）、Controller（维持应用状态）、Scheduler（资源调度）以及etcd（集群状态存储）。这些组件协同工作，实现高可用、弹性伸缩的容器管理能力。

# 示例：一个简单的Pod定义
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pod
spec:
  containers:
  - name: nginx
    image: nginx:latest

该YAML描述了一个运行Nginx的Pod，体现了K8s以资源对象为核心的管理方式。后续章节将基于此理论基础展开实操部署。

2. Kubernetes集群安装环境准备

在构建一个稳定、高效的 Kubernetes 集群之前，必须完成系统层面的全面准备工作。这一过程不仅涉及硬件资源的合理规划与操作系统的选择，还包括网络通信策略的确立和关键软件组件的安装配置。只有在这些基础条件充分满足的前提下，后续 Master 节点与 Worker 节点的部署才能顺利进行。本章将深入探讨 Kubernetes 集群搭建前的各项前置要求，涵盖从物理资源配置到内核参数调优的完整链条，并结合实际操作场景提供可落地的技术指导。

Kubernetes 对运行环境的要求并非随意设定，而是基于其分布式架构特性所决定的。控制平面组件（如 API Server、etcd）需要高可用性和低延迟访问；Worker 节点则依赖稳定的容器运行时与高效的 Pod 网络互通机制。因此，在正式使用 kubeadm 初始化集群前，必须确保所有节点处于一致且优化的状态。这包括统一的操作系统版本、关闭可能干扰通信的安全模块（如 SELinux）、配置静态 IP 地址以避免动态变化带来的连接中断等。

此外，随着云原生生态的发展，越来越多的企业选择在虚拟化或私有云环境中部署 Kubernetes。尽管底层基础设施可能有所不同，但基本的环境准备原则仍然通用。无论是物理服务器、VM 还是容器实例，只要遵循本章所述的标准流程，均可为后续集群的稳定性打下坚实基础。以下将从硬件与操作系统要求、网络环境配置以及软件依赖安装三个维度展开详细说明。

2.1 硬件与操作系统要求

在规划 Kubernetes 集群时，首先需要明确各个节点类型的资源需求。不同的角色对 CPU、内存、存储及 I/O 性能有着显著差异。Master 节点承担着集群状态管理的核心职责，运行 etcd、API Server 等关键组件，通常需要更高的内存容量和更可靠的磁盘性能。而 Worker 节点主要用于运行应用容器，其资源配置应根据预期负载进行弹性调整。

2.1.1 节点配置建议

为确保集群具备良好的响应能力与容错性，推荐采用差异化资源配置策略。对于生产环境中的 Master 节点，建议至少配备 2 核 CPU、4GB 内存，理想情况下应达到 4 核 CPU 和 8GB 内存以上。etcd 数据库对磁盘 IOPS 敏感，因此应优先选用 SSD 存储设备，并预留足够的空间用于快照与 WAL 日志写入。若计划部署多副本 etcd 集群（推荐做法），还需保证各节点间网络延迟低于 5ms。

Worker 节点的配置则更具灵活性。轻量级微服务场景下，2 核 CPU + 4GB 内存足以支撑多个 Pod 并发运行；但对于大数据处理或 AI 推理类工作负载，则需配置更高规格的实例，例如 16 核 CPU + 32GB 内存甚至更多。同时，应考虑启用交换分区（swap）禁用策略，防止因内存不足导致 kubelet 触发驱逐逻辑而影响业务连续性。

下表列出了常见部署模式下的节点资源配置参考：

节点类型	最低配置	推荐配置	典型用途
Master（单节点测试）	2C/4G/50GB SSD	4C/8G/100GB SSD	开发测试环境
Master（HA 生产）	4C/8G/100GB SSD	8C/16G/200GB SSD	多节点 etcd 集群
Worker（通用）	2C/4G/50GB HDD	4C/8G/100GB SSD	Web 应用、中间件
Worker（高性能）	8C/16G/100GB SSD	16C/32G/500GB NVMe	数据分析、GPU 计算

值得注意的是，上述配置仅为基准建议，实际部署中应结合监控数据持续优化。例如，通过 Prometheus 收集节点资源使用率后，可利用 Horizontal Pod Autoscaler（HPA）与 Cluster Autoscaler 协同实现自动化扩缩容。

2.1.2 操作系统兼容性与版本要求

Kubernetes 官方支持多种 Linux 发行版，但不同版本之间的兼容性存在差异。目前主流支持的操作系统包括：

• Ubuntu ：18.04 LTS、20.04 LTS、22.04 LTS
• CentOS ：7.x（已停止维护）、8.x（Stream）
• Red Hat Enterprise Linux (RHEL) ：7.9+、8.x、9.x
• Debian ：10、11、12
• SUSE Linux Enterprise Server (SLES) ：15+

其中，Ubuntu 20.04 LTS 因其长期支持周期、丰富的社区文档和良好的 Docker 兼容性，成为大多数用户的首选。相比之下，CentOS 8 已于 2021 年底终止维护，转向 CentOS Stream 后稳定性有所下降，故不建议用于关键生产环境。

操作系统内核版本也至关重要。Kubernetes v1.24 及以后版本要求内核版本不低于 3.10，且推荐使用 4.18 或更高版本以获得更好的 cgroups v2 支持与安全补丁。可通过以下命令检查当前系统的内核信息：

uname -r

输出示例：

5.4.0-150-generic

此外，还需确认系统时间同步服务是否启用。Kubernetes 组件间依赖精确的时间戳进行证书验证与事件排序，建议配置 NTP（Network Time Protocol）服务以保持各节点时间一致：

sudo timedatectl set-ntp true

该命令会自动启用 systemd-timesyncd 服务并与默认 NTP 服务器同步。也可手动指定企业内部 NTP 服务器：

sudo timedatectl set-ntp false
echo "server ntp.internal.example.com iburst" | sudo tee -a /etc/systemd/timesyncd.conf
sudo systemctl restart systemd-timesyncd

代码逻辑解析 ：
- 第一行禁用自动 NTP 同步，以便自定义配置。
- 第二行将指定的 NTP 服务器地址追加至配置文件 /etc/systemd/timesyncd.conf 。
- 第三行重启时间同步服务以应用更改。

参数说明：
- iburst ：加快初始同步速度，在前几次请求中发送多个数据包。
- timedatectl ：systemd 提供的统一时间管理工具，替代传统的 ntpdate 与 rdate。

为提升安全性，建议定期更新系统补丁并关闭不必要的服务。例如，移除未使用的图形界面组件、限制 SSH 登录方式仅允许密钥认证，并设置防火墙规则最小化暴露面。

以下是典型系统加固流程的 Mermaid 流程图：

graph TD
    A[开始] --> B[选择LTS操作系统]
    B --> C[更新系统补丁]
    C --> D[配置NTP时间同步]
    D --> E[关闭SELinux或设为permissive]
    E --> F[禁用Swap]
    F --> G[配置主机名与静态IP]
    G --> H[安装Docker/kubelet/kubeadm/kubectl]
    H --> I[完成环境准备]

此流程清晰展示了从操作系统选型到核心组件安装的完整路径，确保每一步都符合 Kubernetes 的最佳实践标准。

2.2 网络环境配置

网络是 Kubernetes 集群能否正常运行的关键因素之一。所有节点之间必须能够自由通信，尤其是 Master 与 Worker 之间的 API 请求、Pod 到 Pod 的跨节点通信，均依赖于底层网络的连通性。任何防火墙策略不当或 DNS 解析失败都可能导致集群初始化失败或服务无法发现。

2.2.1 节点间通信与防火墙设置

Kubernetes 控制平面组件监听多个端口，必须在防火墙中显式放行。以下是主要组件所需的端口列表：

组件	协议	端口号	说明
kube-apiserver	TCP	6443	集群内外部通信主入口
etcd server client API	TCP	2379	etcd 客户端访问端口
etcd peer communication	TCP	2380	etcd 节点间通信
kubelet	TCP	10250	kubelet API，用于健康检查
kube-scheduler	TCP	10259	scheduler metrics
kube-controller-manager	TCP	10257	controller manager metrics

在使用 ufw （Ubuntu）或 firewalld （CentOS/RHEL）时，需添加相应规则。以 Ubuntu 为例：

sudo ufw allow 6443/tcp
sudo ufw allow 2379:2380/tcp
sudo ufw allow 10250/tcp
sudo ufw allow 10259/tcp
sudo ufw allow 10257/tcp
sudo ufw enable

代码逻辑解析 ：
- 前五条命令分别开放 Kubernetes 所需的关键端口。
- 最后一条启用防火墙并持久化规则。

参数说明：
- allow ：允许指定流量通过。
- 范围表示法 2379:2380 表示连续端口区间。
- enable ：激活防火墙，此前规则仅处于待生效状态。

对于使用 firewalld 的系统：

sudo firewall-cmd --permanent --add-port=6443/tcp
sudo firewall-cmd --permanent --add-port=2379-2380/tcp
sudo firewall-cmd --permanent --add-port=10250/tcp
sudo firewall-cmd --permanent --add-port=10259/tcp
sudo firewall-cmd --permanent --add-port=10257/tcp
sudo firewall-cmd --reload

注意：某些云平台（如 AWS、阿里云）还需在安全组层面配置入站规则，否则即使本地防火墙放行也无法通信。

2.2.2 静态IP分配与DNS配置

为了避免因 DHCP 导致 IP 变更引发的集群故障，强烈建议为所有节点配置静态 IP 地址。以 Ubuntu 20.04 使用 Netplan 配置为例：

# /etc/netplan/01-netcfg.yaml
network:
  version: 2
  renderer: networkd
  ethernets:
    enp0s3:
      dhcp4: no
      addresses:
        - 192.168.1.10/24
      gateway4: 192.168.1.1
      nameservers:
        addresses:
          - 8.8.8.8
          - 1.1.1.1

应用配置：

sudo netplan apply

代码逻辑解析 ：
- dhcp4: no 表示禁用 IPv4 动态获取。
- addresses 定义静态 IP 与子网掩码。
- gateway4 设置默认网关。
- nameservers 配置 DNS 解析服务器。

参数说明：
- renderer: networkd 使用 systemd-networkd 作为后端驱动。
- enp0s3 是网卡名称，可通过 ip a 查看。

同时，应在 /etc/hosts 中添加节点映射，便于主机名解析：

192.168.1.10 master-node
192.168.1.11 worker-node-1
192.168.1.12 worker-node-2

此举可避免因 DNS 故障导致 kubeadm join 失败。此外，建议配置反向 DNS（PTR 记录），部分组件（如 kube-controller-manager）在某些场景下会执行反向查找。

2.3 软件依赖安装

完成硬件与网络准备后，下一步是安装 Kubernetes 的核心组件及其依赖项。主要包括容器运行时（Docker 或 containerd）、kubelet、kubeadm 和 kubectl。这些工具共同构成了集群的“启动引擎”。

2.3.1 Docker引擎安装与配置

虽然 Kubernetes 已逐步转向使用 containerd 作为默认运行时，但 Docker 仍被广泛使用，尤其在开发环境中。以下是在 Ubuntu 上安装 Docker 的标准流程：

# 更新包索引并安装依赖
sudo apt-get update
sudo apt-get install -y ca-certificates curl gnupg lsb-release

# 添加Docker官方GPG密钥
sudo mkdir -p /etc/apt/keyrings
curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

# 添加仓库源
echo \
  "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
  $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

# 安装Docker Engine
sudo apt-get update
sudo apt-get install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

代码逻辑解析 ：
- 前两步准备系统环境并导入可信签名密钥。
- 第三步生成指向 Docker 官方仓库的源配置。
- 最后更新缓存并安装全套 Docker 工具链。

参数说明：
- signed-by ：指定用于验证包完整性的 GPG 公钥路径。
- $(dpkg --print-architecture) 自动识别系统架构（amd64/arm64等）。
- docker-buildx-plugin 支持多平台镜像构建。

安装完成后，需配置 Docker 使用 systemd 作为 cgroup 驱动，以匹配 kubelet 的默认设置：

# /etc/docker/daemon.json
{
  "exec-opts": ["native.cgroupdriver=systemd"],
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "100m"
  },
  "storage-driver": "overlay2"
}

然后重启服务：

sudo systemctl daemon-reload
sudo systemctl restart docker
sudo systemctl enable docker

2.3.2 kubeadm、kubelet与kubectl的安装

Kubernetes 官方提供了一个标准化的安装脚本，适用于 Debian/Ubuntu 系统：

# 添加Google GPG密钥
curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg

# 添加APT源
echo "deb [signed-by=/usr/share/keyrings/kubernetes-archive-keyring.gpg] https://apt.kubernetes.io/ kubernetes-xenial main" | sudo tee /etc/apt/sources.list.d/kubernetes.list

# 安装三大组件
sudo apt-get update
sudo apt-get install -y kubelet kubeadm kubectl

# 锁定版本防止意外升级
sudo apt-mark hold kubelet kubeadm kubectl

代码逻辑解析 ：
- 第一步下载 Kubernetes 软件源的签名密钥，确保包来源可信。
- 第二步注册 APT 源，使其能识别 kubeadm 等组件。
- 第三步安装核心工具。
- 最后使用 apt-mark hold 阻止自动更新，避免版本冲突。

参数说明：
- hold ：标记包为“保留”，APT 不会在 upgrade 时自动升级它。

2.3.3 系统参数调优与SELinux设置

为提升系统稳定性，需调整部分内核参数。创建配置文件：

cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
overlay
br_netfilter
EOF

sudo modprobe overlay
sudo modprobe br_netfilter

# sysctl params required by setup
cat <<EOF | sudo tee /etc/sysctl.d/99-kubernetes-cri.conf
net.bridge.bridge-nf-call-iptables  = 1
net.ipv4.ip_forward                 = 1
net.bridge.bridge-nf-call-ip6tables = 1
EOF

sudo sysctl --system

代码逻辑解析 ：
- 加载 overlay 和 br_netfilter 内核模块，支持容器镜像分层与桥接过滤。
- 启用 IP 转发与桥接 netfilter，使 Pod 网络流量可被 iptables 正确处理。
- sysctl --system 重新加载所有配置文件。

参数说明：
- bridge-nf-call-iptables=1 ：允许 iptables 处理经过网桥的数据包，CNI 插件依赖此功能。

关于 SELinux，在大多数 Linux 发行版中默认启用，可能会阻止 kubelet 或容器进程访问必要资源。建议将其设置为 permissive 模式：

sudo setenforce 0
sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

代码逻辑解析 ：
- setenforce 0 立即将 SELinux 设为宽容模式（不阻止操作但记录警告）。
- sed 命令修改配置文件，确保重启后仍保持该状态。

注意：生产环境中可根据最小权限原则定制 SELinux 策略，而非完全关闭。

最终，可通过下表验证各项准备工作是否就绪：

检查项	验证命令	预期结果
Docker 是否运行	systemctl is-active docker	active
kubelet 是否启用	systemctl is-enabled kubelet	enabled
swap 是否关闭	free -h \| grep Swap	total: 0B
防火墙端口开放	sudo ufw status verbose	显示相关端口允许
时间同步状态	timedatectl status	Network time on: yes

至此，所有节点均已满足 Kubernetes 集群部署的前提条件，可进入下一阶段的 Master 节点初始化操作。

3. Master节点配置与控制平面部署

Kubernetes的控制平面是整个集群的大脑，负责管理所有节点、调度工作负载、维护集群状态以及对外提供API接口。Master节点作为控制平面的核心载体，其正确配置和稳定运行直接决定了集群的可用性与可靠性。在完成前期环境准备后，本章节将深入探讨如何通过 kubeadm 工具初始化Master节点，部署核心控制组件，建立安全通信机制，并对系统状态进行有效监控与问题排查。

控制平面的构建不仅是命令执行的过程，更涉及底层架构理解、证书体系设计、服务间依赖协调等多个技术维度。尤其在生产环境中，安全性、高可用性和可观测性成为必须考量的关键因素。因此，本章内容从初始化流程切入，逐步展开至证书管理、服务启动逻辑及日志分析方法，力求为具备5年以上运维或开发经验的技术人员提供一套可落地、可扩展、可调试的Master节点部署方案。

3.1 初始化Master节点

Master节点的初始化标志着Kubernetes集群生命周期的正式开始。该过程由 kubeadm init 命令驱动，自动完成控制平面各组件的配置、容器化部署与自检流程。此阶段不仅需要确保前置条件满足（如Docker/CRI运行时正常、网络插件未提前加载），还需合理规划Pod子网、Service子网等关键参数，以避免后续扩容冲突。

3.1.1 使用kubeadm init命令初始化集群

kubeadm init 是官方推荐的集群初始化方式，它封装了etcd、API Server、Controller Manager和Scheduler的复杂配置，简化了部署流程。其核心优势在于标准化操作、内置健康检查和证书自动生成机制。

以下是一个典型的 kubeadm init 执行示例：

sudo kubeadm init \
  --pod-network-cidr=10.244.0.0/16 \
  --service-cidr=10.96.0.0/12 \
  --apiserver-advertise-address=192.168.10.10 \
  --kubernetes-version=v1.28.0

参数说明：

参数	说明
--pod-network-cidr	指定Pod使用的IP地址段，需与后续CNI插件匹配（如Flannel默认使用10.244.0.0/16）
--service-cidr	Service虚拟IP范围，用于分配ClusterIP
--apiserver-advertise-address	API Server对外广播的IP地址，通常为主节点内网IP
--kubernetes-version	明确指定Kubernetes版本，防止自动升级导致不一致

执行成功后，终端会输出如下关键信息：

Your Kubernetes control-plane has initialized successfully!

To start using your cluster, you need to run the following as a regular user:

  mkdir -p $HOME/.kube
  sudo cp -i /etc/kubernetes/admin.conf $HOME/.kube/config
  sudo chown $(id -u):$(id -g) $HOME/.kube/config

Alternatively, if you are the root user, you can run:

  export KUBECONFIG=/etc/kubernetes/admin.conf

You should now deploy a pod network to the cluster.
Run "kubectl apply -f [podnetwork].yaml" with one of the options listed at:
  https://kubernetes.io/docs/concepts/cluster-administration/addons/

Then you can join any number of worker nodes by running the following on each as root:

kubeadm join 192.168.10.10:6443 --token abcdef.0123456789abcdef \
    --discovery-token-ca-cert-hash sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

上述输出包含三个重要部分：
1. kubeconfig配置 ：使 kubectl 能够连接API Server；
2. CNI部署提示 ：强调必须先部署网络插件才能让Pod通信；
3. Worker节点加入命令 ：供其他节点注册使用。

⚠️ 注意事项：若未指定 --pod-network-cidr ，某些CNI插件（如Calico）可能无法正常工作；此外，多网卡环境下务必明确设置 --apiserver-advertise-address ，否则可能导致API Server绑定到错误接口。

内部执行流程解析（Mermaid流程图）

graph TD
    A[kubeadm init 开始] --> B[预检环境]
    B --> C{是否通过预检?}
    C -->|否| D[输出错误并终止]
    C -->|是| E[生成TLS证书]
    E --> F[生成静态Pod清单文件]
    F --> G[启动etcd和API Server]
    G --> H[启动Controller Manager和Scheduler]
    H --> I[等待API Server就绪]
    I --> J[上传集群配置至ConfigMap]
    J --> K[生成join令牌]
    K --> L[输出成功信息与下一步指引]

该流程体现了 kubeadm 的高度自动化能力——它并不直接运行服务进程，而是通过 静态Pod 的方式交由本地 kubelet 来托管控制平面组件。这些Pod定义位于 /etc/kubernetes/manifests/ 目录下，例如：

• etcd.yaml
• kube-apiserver.yaml
• kube-controller-manager.yaml
• kube-scheduler.yaml

kubelet 会监视此目录并创建对应的容器实例，实现控制平面的“自我托管”。

静态Pod与DaemonSet的区别对比表

特性	静态Pod	DaemonSet
管理者	kubelet	kube-apiserver + controller-manager
存储位置	节点本地文件系统	etcd中存储的资源对象
是否可见于 kubectl get pods	是（但带有 -static 后缀）	是
更新机制	修改YAML文件即可触发重建	通过更新DaemonSet资源触发滚动更新
典型用途	控制平面组件（Master节点专属）	日志采集、Node监控代理等

由此可见，静态Pod是一种轻量级、无需API Server介入即可运行的机制，非常适合用于启动初始控制平面。

3.1.2 API Server、etcd、Controller Manager与Scheduler的启动

控制平面由四大核心组件构成，它们协同工作以维持集群状态一致性。

各组件职责详解

组件	功能描述
API Server	所有请求的统一入口，提供RESTful接口，验证并处理来自 kubectl 、控制器或其他组件的请求
etcd	分布式键值存储，保存集群所有对象的状态（如Pod、Service、Deployment等）
Controller Manager	包含多个控制器（Node Controller、Replication Controller等），持续观测实际状态并与期望状态同步
Scheduler	负责将未调度的Pod分配到合适的Worker节点上

这些组件均以容器形式运行，可通过以下命令查看其运行状态：

kubectl get pods -n kube-system

预期输出类似：

NAME                             READY   STATUS    RESTARTS   AGE
etcd-master                      1/1     Running   0          10m
kube-apiserver-master            1/1     Running   0          10m
kube-controller-manager-master   1/1     Running   0          10m
kube-scheduler-master            1/1     Running   0          10m

容器启动逻辑分析（以kube-apiserver为例）

查看 /etc/kubernetes/manifests/kube-apiserver.yaml 中的部分内容：

apiVersion: v1
kind: Pod
metadata:
  name: kube-apiserver
  namespace: kube-system
spec:
  containers:
  - command:
    - kube-apiserver
    - --advertise-address=192.168.10.10
    - --allow-privileged=true
    - --authorization-mode=Node,RBAC
    - --enable-admission-plugins=NodeRestriction
    - --enable-bootstrap-token-auth=true
    - --etcd-servers=https://127.0.0.1:2379
    - --secure-port=6443
    - --tls-cert-file=/var/lib/minikube/certs/apiserver.crt
    - --tls-private-key-file=/var/lib/minikube/certs/apiserver.key
    image: k8s.gcr.io/kube-apiserver:v1.28.0
    name: kube-apiserver

逐行逻辑解读：

• --advertise-address : API Server向集群其他成员宣告自己的地址；
• --allow-privileged=true : 允许特权容器运行（某些系统组件需要）；
• --authorization-mode=Node,RBAC : 启用两种授权模式，Node专用于kubelet认证，RBAC用于用户权限控制；
• --enable-admission-plugins=NodeRestriction : 启用准入控制插件，限制kubelet只能修改自身Node和Pod；
• --etcd-servers : 指定etcd服务地址，当前为单节点本地部署；
• --secure-port=6443 : HTTPS监听端口，所有外部请求从此进入；
• --tls-* : TLS加密通信所需证书与私钥路径，保障API Server通信安全。

这些参数共同构建了一个安全、可控、可扩展的API服务入口。

组件依赖关系图（Mermaid）

graph LR
    Client(kubectl / UI) --> API[kube-apiserver]
    API --> ETCD[(etcd)]
    CM[kube-controller-manager] --> API
    SCHED[kube-scheduler] --> API
    KUBELET --> API
    API --> CM
    API --> SCHED

可以看出， API Server处于中心地位 ，所有组件都通过它读写集群状态，而不会直接访问etcd。这种设计实现了松耦合与集中管控。

此外，在初始化完成后， kubeadm 还会执行一项关键操作：将 ClusterConfiguration 写入 kubeadm-config ConfigMap，以便未来执行 kubeadm upgrade 时能获取原始配置。

kubectl get cm kubeadm-config -n kube-system -o yaml

这一机制使得集群具备了可追溯性和可升级性，极大提升了长期维护效率。

3.2 证书与安全配置

Kubernetes的安全体系高度依赖于TLS证书机制，几乎所有的内部通信（如API Server与etcd之间、kubelet与API Server之间）都基于双向SSL加密。因此，掌握证书生成、管理与轮换机制对于保障集群安全至关重要。

3.2.1 TLS证书的生成与管理

kubeadm 在初始化过程中会自动生成一套完整的PKI体系，存放于 /etc/kubernetes/pki/ 目录下。主要证书包括：

文件	用途
ca.crt , ca.key	根CA证书与私钥，用于签发其他组件证书
apiserver.crt , apiserver.key	API Server证书，客户端连接时验证服务身份
front-proxy-ca.crt , front-proxy-client.crt	聚合API服务器代理相关证书
sa.pub , sa.key	Service Account密钥对，用于Pod身份认证

所有证书默认有效期为一年，可通过以下命令查看过期时间：

openssl x509 -in /etc/kubernetes/pki/apiserver.crt -noout -dates

输出示例：

notBefore=Jan  1 00:00:00 2023 GMT
notAfter=Jan  1 00:00:00 2024 GMT

🔐 生产建议：应定期监控证书有效期，并制定自动续期策略。可使用 kubeadm certs check-expiration 命令批量检查。

自定义CA证书场景

若企业已有内部CA体系，可将自定义CA证书放入 /etc/kubernetes/pki/ 目录并命名为 ca.crt 和 ca.key ， kubeadm 会在初始化时优先使用现有CA签发其余证书，从而实现与组织PKI体系集成。

证书签名请求（CSR）机制

当Worker节点加入集群时，其 kubelet 会向API Server发起CSR请求，申请客户端证书。管理员可通过以下命令审批：

# 查看待审批的CSR
kubectl get csr

# 批准某个CSR
kubectl certificate approve node-csr-xxxxx

此机制支持细粒度控制节点接入权限，适用于严格合规环境。

3.2.2 安全加固与访问控制策略

除了传输层加密，还需从多个层面实施安全加固。

常见安全配置项汇总表

加固方向	措施	实现方式
访问控制	启用RBAC	--authorization-mode=RBAC
减少攻击面	关闭匿名访问	--anonymous-auth=false
审计追踪	启用审计日志	配置 --audit-log-path 等参数
私钥保护	限制文件权限	chmod 600 /etc/kubernetes/pki/*.key
最小权限原则	使用非root用户运行组件	systemd服务配置User字段

示例：启用审计日志记录

编辑 /etc/kubernetes/manifests/kube-apiserver.yaml ，添加以下参数：

- --audit-log-path=/var/log/apiserver-audit.log
- --audit-log-maxage=30
- --audit-log-maxbackup=3
- --audit-policy-file=/etc/kubernetes/audit-policy.yaml

其中 audit-policy.yaml 定义哪些操作需要记录，例如：

apiVersion: audit.k8s.io/v1
kind: Policy
rules:
- level: Metadata
  resources:
  - group: ""
    resources: ["secrets", "configmaps"]

该策略表示对Secret和ConfigMap的操作仅记录元数据，有助于平衡安全性与性能。

安全基线检查工具集成

推荐引入 kube-bench 工具，依据CIS Kubernetes Benchmark标准自动检测配置合规性：

docker run --pid=host -v /etc:/etc:ro -v /var:/var:ro -t aquasec/kube-bench:latest

输出将列出不符合项及其修复建议，极大提升安全治理效率。

3.3 集群状态查看与日志分析

成功的初始化只是起点，持续监控集群健康状况才是保障稳定运行的关键。

3.3.1 使用kubectl查看组件状态

Kubernetes提供了多种原生命令用于诊断控制平面状态。

查看节点与组件状态

# 查看Master节点状态
kubectl get nodes

# 查看控制平面组件健康情况（注意：Deprecated in v1.19+）
kubectl get componentstatuses

尽管 componentstatuses 已被弃用，但仍可通过Prometheus+Metrics Server实现更精细的指标采集。

获取静态Pod状态

由于控制平面以静态Pod运行，其名称通常带有节点名后缀：

kubectl get pods -n kube-system | grep master

若发现某组件频繁重启（RESTARTS > 0），应立即检查日志。

3.3.2 日志排查与常见问题处理

日志是故障定位的第一手资料。以下是常用日志查看方式：

查看etcd日志

journalctl -u etcd.service --since "5 minutes ago"

或进入容器查看：

docker ps | grep etcd
docker logs <container_id>

常见错误包括：
- connection refused ：etcd未启动或端口被占用；
- permission denied ：证书路径错误或权限不足。

查看API Server日志

kubectl logs kube-apiserver-master -n kube-system

典型问题：
- Unauthorized ：客户端证书无效或缺失；
- timeout connecting to etcd ：网络不通或etcd崩溃。

故障排查流程图（Mermaid）

graph TB
    Start(集群无法初始化) --> CheckPrecheck{预检失败？}
    CheckPrecheck -->|是| FixPrecheck[解决kubeadm preflight错误]
    CheckPrecheck -->|否| CheckPodStatus{控制平面Pod是否Running?}
    CheckPodStatus -->|否| CheckLogs[查看对应容器日志]
    CheckPodStatus -->|是| CheckAPIService{能否执行kubectl命令?}
    CheckAPIService -->|否| CheckKubeconfig[确认KUBECONFIG路径正确]
    CheckAPIService -->|是| Success[集群正常]

结合此流程图，技术人员可快速定位问题层级，避免盲目试错。

常见初始化失败原因汇总表

错误现象	可能原因	解决方案
[ERROR Port-6443]: Port 6443 is in use	kube-apiserver残留进程	ps aux | grep kube-apiserver && kill
failed to pull image	镜像拉取失败（墙问题）	使用国内镜像源或提前load镜像
x509: certificate has expired	证书过期	kubeadm certs renew all
no matching cipher suite for client	TLS协商失败	检查OpenSSL版本兼容性

综上所述，Master节点的配置是一项集自动化工具使用、安全策略设定与深度排错能力于一体的综合性任务。只有深入理解每一步背后的原理，才能在面对复杂环境时游刃有余。

4. Worker节点配置与Kubelet安装

Kubernetes 集群的核心功能依赖于 Master 节点与 Worker 节点的协同工作。Worker 节点是实际承载容器化应用运行的节点，它通过 Kubelet 与 Master 节点通信，接收调度指令并执行容器的生命周期管理。本章将从 Worker 节点的加入流程、Kubelet 的配置优化，以及容器网络和 Pod 环境的初步理解出发，深入剖析 Worker 节点的配置与管理方式。

4.1 Worker节点加入集群

Worker 节点的加入是构建 Kubernetes 集群的最后一步。该过程不仅需要确保节点能够成功连接到 Master，还需要完成身份验证、网络配置和状态同步等关键操作。

4.1.1 获取join命令并执行节点注册

当 Master 节点初始化完成后， kubeadm init 命令会输出一个用于 Worker 节点加入的 kubeadm join 指令，例如：

kubeadm join 192.168.1.100:6443 --token abcdef.1234567890abcdef \
    --discovery-token-ca-cert-hash sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

⚠️ 注意 ：Token 有效期为 24 小时，如需重新生成可使用 kubeadm token create --print-join-command 。

执行步骤：

1. 在 Worker 节点上安装 kubeadm 、 kubelet 、 kubectl （如未安装）。
2. 执行上述 kubeadm join 命令。
3. 等待节点完成注册并进入 Ready 状态。

代码逻辑分析：

kubeadm join 192.168.1.100:6443 \
    --token abcdef.1234567890abcdef \
    --discovery-token-ca-cert-hash sha256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

• 192.168.1.100:6443 ：Master 节点的 API Server 地址。
• --token ：用于身份验证的临时 Token。
• --discovery-token-ca-cert-hash ：用于验证 Master 节点证书的哈希值，防止中间人攻击。

执行完成后，Worker 节点会自动启动 Kubelet 服务，并向 API Server 注册自身信息。

4.1.2 检查节点状态与标签管理

Worker 节点加入后，Master 节点可以通过 kubectl get nodes 查看节点状态：

NAME       STATUS   ROLES    AGE   VERSION
worker-1   Ready    <none>   5m    v1.26.1

✅ 状态说明 ：
- STATUS ：当前节点状态， Ready 表示健康。
- ROLES ：角色，默认为空，可通过标签添加。
- AGE ：节点加入时间。
- VERSION ：Kubernetes 版本。

标签管理

为节点添加标签，便于后续调度控制：

kubectl label nodes worker-1 node-role.kubernetes.io/worker=

也可以移除标签：

kubectl label nodes worker-1 node-role.kubernetes.io/worker- 

📌 标签用途 ：在部署 Pod 时，可通过 nodeSelector 指定 Pod 运行在特定标签的节点上，实现精细化调度。

4.2 Kubelet服务配置与优化

Kubelet 是运行在每个 Worker 节点上的核心组件，负责与 Master 节点通信，管理本节点上的容器生命周期。

4.2.1 Kubelet启动参数与运行配置

Kubelet 的配置文件通常位于 /var/lib/kubelet/config.yaml ，也可以通过命令行参数进行配置。

常用配置参数：

参数名	说明
--address	监听地址，默认 0.0.0.0
--port	监听端口，默认 10250
--read-only-port	只读端口，默认 10255
--cgroup-driver	Cgroup 驱动类型，通常为 systemd 或 cgroupfs
--network-plugin	网络插件名称，如 cni
--runtime-cgroups	容器运行时的 cgroup 路径
--kube-reserved	保留资源，用于 kube 组件自身运行
--system-reserved	系统级资源保留

示例配置文件：

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
address: 0.0.0.0
port: 10250
cgroupDriver: systemd
networkPluginName: cni
kubeReserved:
  memory: "512Mi"
systemReserved:
  memory: "256Mi"

启动命令：

/usr/bin/kubelet --config=/var/lib/kubelet/config.yaml \
  --kubeconfig=/etc/kubernetes/kubelet.conf \
  --network-plugin=cni \
  --cgroup-driver=systemd

🔍 逻辑分析 ：
- --config ：指定主配置文件路径。
- --kubeconfig ：指定与 API Server 通信的认证配置。
- --network-plugin ：指定使用的网络插件类型。
- --cgroup-driver ：必须与 Docker 使用的 cgroup 驱动一致，否则可能导致 kubelet 启动失败。

4.2.2 节点资源监控与自动恢复机制

Kubelet 提供了丰富的资源监控和自动恢复能力，确保节点稳定运行。

资源监控

Kubelet 默认监听 /metrics 接口（默认端口 10255 ），暴露节点资源使用情况：

curl http://localhost:10255/metrics

输出包括：
- node_cpu_seconds_total
- node_memory_MemFree_bytes
- container_fs_usage_bytes

可通过 Prometheus 等监控系统采集这些指标，实现资源可视化监控。

自动恢复机制

Kubelet 内置健康检查机制，当检测到容器崩溃、Pod 异常或节点失联时，会尝试重启容器或上报状态。

• Pod 自动重启 ：若容器崩溃，Kubelet 会根据重启策略（ Always 、 OnFailure ）决定是否重启。
• 节点健康检查 ：若节点失联超过 node-monitor-grace-period （默认 40s），Master 会标记其为 NotReady 。
• 驱逐机制 ：若节点资源不足，Kubelet 会触发 Pod 驱逐策略，优先驱逐低优先级 Pod。

配置自动恢复参数：

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
evictionHard:
  memory.available:  "100Mi"
  nodefs.available:  "10%"
  nodefs.inodesFree: "5%"
evictionPressureTransitionPeriod: 30s

📌 作用说明 ：
- evictionHard ：设置资源阈值，达到则触发驱逐。
- evictionPressureTransitionPeriod ：压力状态转换时间，防止频繁切换。

4.3 容器网络与Pod运行环境

Worker 节点的网络环境直接影响 Pod 的通信与调度，因此理解其运行机制对集群稳定性至关重要。

4.3.1 Pod IP分配机制

每个 Pod 在集群中拥有一个独立的 IP 地址，Pod 内部容器共享此 IP，可通过 CNI 插件实现。

IP 分配流程：

1. Pod 创建请求发送到 API Server。
2. API Server 通知调度器选择节点。
3. 调度器选择节点后，将 Pod 信息发送给该节点的 Kubelet。
4. Kubelet 调用 CNI 插件分配 IP 地址。
5. CNI 将 IP 信息写入 Pod 网络命名空间。

示例流程图（Mermaid）：

graph TD
    A[API Server] --> B(调度器)
    B --> C{选择Worker节点}
    C --> D[Kubelet]
    D --> E[CNI插件]
    E --> F[分配Pod IP]
    F --> G[写入网络命名空间]

📌 IP 分配特点 ：
- 每个 Pod 独占 IP。
- 同一 Pod 内容器共享网络命名空间。
- Pod 间可以直接通信，无需 NAT。

4.3.2 CRI（容器运行时接口）支持与配置

Kubernetes 通过 CRI（Container Runtime Interface）与底层容器运行时交互。常见的运行时包括 Docker、containerd、CRI-O。

支持的 CRI 实现：

运行时	说明
Docker	早期主流，使用 dockershim 适配 CRI
containerd	原生支持 CRI，性能更优
CRI-O	针对 Kubernetes 优化的轻量级运行时

配置 containerd 作为 CRI：

1. 安装 containerd：

apt install containerd

2. 配置 CRI 插件：

编辑 /etc/containerd/config.toml ：

[plugins."io.containerd.grpc.v1.cri"]
  disable_tcp_service = true
  stream_server_address = "127.0.0.1"
  stream_server_port = "0"
  enable_selinux = false
  sandbox_image = "k8s.gcr.io/pause:3.6"

3. 重启 containerd：

systemctl restart containerd

4. 验证 CRI 接口：

crictl info

📌 关键参数说明 ：
- sandbox_image ：Pod 沙箱镜像，用于初始化 Pod 网络命名空间。
- disable_tcp_service ：禁用 TCP 服务，提高安全性。

示例：查看运行中的容器

crictl ps

输出示例：

CONTAINER ID        IMAGE               CONTAINER NAME    PID   STATUS
abc123456789      nginx:latest        my-nginx-pod     1234   Running

📌 作用 ： crictl 是 CRI 的调试工具，可替代 docker ps ，实现对容器的管理。

本章从 Worker 节点的加入流程、Kubelet 的配置优化，到容器网络与 Pod 运行环境进行了深入剖析，帮助读者掌握 Worker 节点的完整配置流程与优化方法，为后续集群稳定运行奠定坚实基础。

5. CNI网络插件配置（Calico/Flannel）

Kubernetes中的网络通信是集群稳定运行的核心要素之一，而CNI（Container Network Interface）作为容器网络的标准接口，为Pod之间的通信提供了统一的插件机制。本章将深入探讨CNI网络插件的选择与部署，重点分析Calico与Flannel两种主流方案的配置方法、功能差异及优化策略，并通过实际测试与排错方法帮助读者构建一个稳定、高效的容器网络环境。

5.1 CNI网络插件概述

5.1.1 CNI标准与插件选择原则

CNI是一种开放的容器网络接口标准，定义了容器运行时（如Docker或containerd）与网络插件之间的交互方式。其核心目标是为每个Pod分配唯一的IP地址，并确保Pod之间可以无NAT地直接通信。

选择CNI插件时应考虑以下因素：

评估维度	说明
性能	是否支持高效的跨节点通信机制
网络策略支持	是否支持NetworkPolicy进行细粒度的网络访问控制
可维护性	插件是否易于部署、升级与故障排查
社区活跃度	是否有活跃的社区支持与持续更新
安全性	是否支持网络隔离、加密等安全机制

5.1.2 Calico与Flannel的功能对比

特性	Calico	Flannel
网络模型	BGP路由 + IP-in-IP或VXLAN	VXLAN、Host-GW、UDP等
网络策略支持	原生支持NetworkPolicy	依赖其他插件（如Cilium）实现
性能	高性能（尤其在BGP模式下）	一般（VXLAN模式性能略低）
部署复杂度	相对较高	简单
适用场景	多租户、大规模集群	中小型集群、快速部署场景

5.2 Calico网络部署与配置

5.2.1 安装Calico并配置网络策略

Calico支持灵活的网络模型，适用于需要网络策略和高性能通信的场景。以下为使用 kubectl apply 部署Calico的示例：

# 下载Calico清单文件
curl https://docs.projectcalico.org/manifests/calico.yaml -O

# 修改Calico配置（可选）：
# 例如修改Pod CIDR范围（默认为192.168.0.0/16），在清单中搜索`CALICO_IPV4POOL_CIDR`进行修改

# 应用配置
kubectl apply -f calico.yaml

参数说明：

• CALICO_IPV4POOL_CIDR ：定义Pod网络的IP段，需与集群配置一致。
• CALICO_NODE_TO_NODE_MESH_ENABLED ：启用BGP节点间直连模式（默认为true）。
• CALICO_IPV4POOL_MODE ：IP分配模式，支持 BGP 、 VXLAN 等。

部署完成后，使用以下命令验证Calico状态：

kubectl get pods -n kube-system -l k8s-app=calico-node

5.2.2 跨节点通信与网络隔离设置

Calico支持基于 NetworkPolicy 的细粒度网络隔离。例如，限制某命名空间中Pod只能与特定服务通信：

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: restrict-egress
  namespace: dev
spec:
  podSelector: {}
  policyTypes:
    - Egress
  egress:
    - to:
        - namespaceSelector: {}
          podSelector:
            matchLabels:
              role: backend

上述策略表示：在 dev 命名空间中，所有Pod只能与带有 role=backend 标签的Pod通信。

5.3 Flannel网络部署与优化

5.3.1 安装Flannel并配置Backend模式

Flannel是一个轻量级的CNI插件，适用于中小型集群。支持多种后端模式，包括：

• VXLAN ：性能较好，推荐使用。
• Host-GW ：基于路由，性能最佳，但要求节点处于同一子网。
• UDP ：兼容性好但性能较低，不推荐用于生产。

安装Flannel示例：

# 应用Flannel清单（使用VXLAN后端）
kubectl apply -f https://raw.githubusercontent.com/coreos/flannel/master/Documentation/kube-flannel.yml

查看Flannel配置：

kubectl get cm -n kube-system kube-flannel-cfg -o yaml

配置文件中可修改Backend类型：

"Backend": {
  "Type": "vxlan"
}

5.3.2 性能调优与VXLAN配置技巧

VXLAN模式下可进行如下优化：

• MTU设置 ：建议将节点网络接口的MTU设置为至少1450，以避免分片。
• 内核参数优化 ：

# 修改sysctl配置
echo "net.ipv4.conf.all.rp_filter=宽松" >> /etc/sysctl.conf
sysctl -p

• 日志级别调整 ：在Flannel DaemonSet中添加环境变量 "FLANNELD_LOG_LEVEL": "5" 以提升日志详细度。

5.4 网络测试与问题排查

5.4.1 Pod间通信测试

部署两个Pod进行跨节点通信测试：

kubectl run test-pod1 --image=busybox -- sleep 3600
kubectl run test-pod2 --image=busybox -- sleep 3600

获取Pod IP：

kubectl get pods -o wide

进入Pod1并尝试ping Pod2的IP：

kubectl exec -it test-pod1 -- ping <pod2-ip>

5.4.2 常见网络问题与解决方案

问题现象	原因分析	解决方案
Pod无法跨节点通信	CNI插件未正确部署或配置错误	检查CNI配置、Pod CIDR是否一致
NodeIP无法访问PodIP	路由表或NAT规则配置错误	检查iptables规则、路由表配置
Flannel启动失败，报错 no subnet allocated	etcd中未正确写入子网信息	删除Flannel子网锁并重启服务
Calico BGP邻居状态为Idle	网络不通或BGP配置错误	检查节点间网络连通性和BGP端口（179）

可通过以下命令查看CNI插件日志辅助排查：

# 查看Calico节点日志
journalctl -u kubelet | grep calico

# 查看Flannel日志
kubectl logs -n kube-system <flannel-pod-name>

本文还有配套的精品资源，点击获取

简介：Kubernetes（K8s）是Google开源的容器编排系统，用于自动化部署、扩展和管理容器化应用。本指南详细介绍了Kubernetes集群的搭建流程，包括节点配置、网络设置、核心组件安装与验证，以及扩展组件CoreDNS的安装与配置。通过本指南操作，可帮助用户构建一个功能完善、可扩展的Kubernetes环境，适用于容器化应用的部署与管理实战。

本文还有配套的精品资源，点击获取