Linux搭建K8s集群教程详解

Kubernetes作为容器编排的事实标准，在Linux上搭建集群是许多企业的首选。本文详解了基于kubeadm搭建Kubernetes集群的步骤，包括系统环境准备、containerd安装、kubeadm/kubelet/kubectl安装、Master节点初始化、Worker节点加入及集群状态验证。同时，文章还深入探讨了集群部署中常见的网络配置、资源规划、版本兼容性等挑战，以及容器运行时和网络插件（如containerd、Flannel、Calico）的选择对集群性能的影响。此外，文章还提出了确保Kubernetes集群在生产环境中高可用性和可维护性的关键措施，如多Master节点、etcd集群健壮性、Worker节点冗余、存储和网络高可用，以及全面的监控告警和自动化部署管理等策略。

首选答案是Kubernetes，其为容器化应用部署和管理的事实标准，尽管初期复杂，但效率和稳定性优势显著。搭建基于kubeadm的Kubernetes集群流程如下：1. 系统环境准备：选择Ubuntu Server或CentOS Stream的LTS版本，禁用Swap，配置内核参数启用IPv4转发和br_netfilter模块，关闭防火墙和SELinux，设置主机名和hosts文件；2. 安装容器运行时containerd：安装必要工具，添加Docker官方GPG密钥和仓库，安装containerd并配置SystemdCgroup为true；3. 安装kubeadm、kubelet和kubectl：添加Kubernetes官方GPG密钥和仓库，安装并锁定版本；4. 初始化Master节点：提前拉取镜像，使用kubeadm init初始化集群，配置kubectl，安装Flannel或Calico网络插件；5. 加入Worker节点：执行kubeadm join命令；6. 验证集群状态：运行kubectl get nodes和kubectl get pods -A确认节点和核心Pod状态。常见挑战包括网络配置复杂性、资源消耗与规划、版本兼容性、镜像拉取问题、存储方案选型、证书和Token管理。容器运行时的选择影响性能、资源利用率和安全性，containerd轻量高效，CRI-O适用于特定生态；网络插件Flannel适合简单场景，Calico适合生产环境，Cilium提供高性能和高级功能。确保高可用性和可维护性的措施包括多Master节点、etcd集群健壮性、Worker节点冗余、存储和网络高可用，全面监控与告警、日志管理、备份与恢复策略、版本升级策略、自动化部署与管理、安全加固及文档和Runbook维护。

在Linux上搭建容器编排环境，我的首选答案是Kubernetes。它几乎是当前容器化应用部署和管理的事实标准，虽然初次接触会觉得有些复杂，但一旦掌握，你会发现它带来的效率和稳定性是其他方案难以比拟的。整个过程涉及到系统准备、组件安装、集群初始化和网络配置等多个环节，一步步来，其实并没有想象中那么遥不可及。

解决方案

要搭建一个基于kubeadm的Kubernetes集群，以下是我个人推荐的一个相对稳妥的流程，兼顾了通用性和一些细节考量。

1. 系统环境准备： 这是基础中的基础，如果这一步没做好，后面遇到的问题会让你抓狂。

• 操作系统选择： 我通常选择Ubuntu Server（LTS版本，比如20.04或22.04）或者CentOS Stream。它们社区活跃，文档丰富。

• 禁用Swap： Kubernetes对Swap非常敏感，必须禁用。

  

  sudo swapoff -a
  # 永久禁用，编辑 /etc/fstab，在Swap行前面加 # 注释掉
  sudo sed -i '/ swap / s/^\(.*\)$/#\1/g' /etc/fstab

• 配置内核参数： 启用IPv4转发和br_netfilter模块，这是CNI插件工作的前提。

  cat <<EOF | sudo tee /etc/modules-load.d/k8s.conf
  br_netfilter
  EOF
  cat <<EOF | sudo tee /etc/sysctl.d/k8s.conf
  net.bridge.bridge-nf-call-ip6tables = 1
  net.bridge.bridge-nf-call-iptables = 1
  net.ipv4.ip_forward = 1
  EOF
  sudo sysctl --system

• 关闭防火墙和SELinux： 虽然生产环境建议配置防火墙规则和SELinux策略，但为了初次部署的顺利，我通常会先关闭它们，等集群跑起来再逐步加固。

  # 关闭防火墙 (以ufw为例，CentOS是firewalld)
  sudo ufw disable
  # 或者对于CentOS/RHEL
  sudo systemctl stop firewalld
  sudo systemctl disable firewalld
  
  # 关闭SELinux (CentOS/RHEL)
  sudo setenforce 0
  sudo sed -i 's/^SELINUX=enforcing$/SELINUX=permissive/' /etc/selinux/config

• 设置主机名和hosts文件： 确保每台机器的主机名唯一，并且在/etc/hosts中添加所有节点的IP和主机名映射，这对于集群内部通信和DNS解析很重要。

2. 安装容器运行时 (Containerd)： Kubernetes 1.24+版本已经移除了对Docker Shim的支持，推荐使用containerd或CRI-O。我个人更倾向于containerd，因为它轻量且稳定。

• 安装必要的工具：

  sudo apt update && sudo apt install -y apt-transport-https ca-certificates curl gnupg lsb-release

• 添加Docker官方GPG密钥和仓库： (containerd通常随Docker Engine一起分发，或者单独安装)

  curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg
  echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

• 安装containerd：

  sudo apt update
  sudo apt install -y containerd.io

• 配置containerd： 生成默认配置文件，并修改SystemdCgroup = true，这是kubelet的要求。

  sudo mkdir -p /etc/containerd
  sudo containerd config default | sudo tee /etc/containerd/config.toml
  sudo sed -i 's/SystemdCgroup = false/SystemdCgroup = true/' /etc/containerd/config.toml
  sudo systemctl restart containerd
  sudo systemctl enable containerd

3. 安装kubeadm、kubelet和kubectl： 这三个是Kubernetes的核心工具集。

• 添加Kubernetes官方GPG密钥和仓库：

  sudo curl -fsSLo /usr/share/keyrings/kubernetes-archive-keyring.gpg https://packages.cloud.google.com/apt/doc/apt-key.gpg
  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

• 安装： 我通常会指定版本，以确保所有组件兼容。例如，安装1.26版本。

  sudo apt update
  sudo apt install -y kubelet=1.26.0-00 kubeadm=1.26.0-00 kubectl=1.26.0-00
  sudo apt-mark hold kubelet kubeadm kubectl

  apt-mark hold是为了防止它们被意外升级。

4. 初始化Master节点： 在作为Master的机器上执行。

• 拉取所需镜像： 提前拉取可以避免kubeadm init时因网络问题卡住。

  sudo kubeadm config images pull

• 初始化集群： pod-network-cidr参数非常重要，它定义了Pod网络的IP段，后续安装CNI插件时需要用到。我通常用10.244.0.0/16，这是Flannel的默认CIDR。

  sudo kubeadm init --pod-network-cidr=10.244.0.0/16 --apiserver-advertise-address=<Master节点IP>

  替换为你的Master节点实际IP地址。

• 配置kubectl： 初始化完成后，会提示你如何配置kubectl来与集群交互。

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

• 安装网络插件 (CNI)： 我个人偏爱Flannel，因为它简单易用，适合初学者或小型集群。

  kubectl apply -f https://raw.githubusercontent.com/flannel-io/flannel/master/Documentation/kube-flannel.yml

  如果你需要更高级的网络策略或性能，可以考虑Calico。

5. 加入Worker节点： 在每个Worker节点上执行，kubeadm init成功后会输出一个kubeadm join命令，直接复制执行即可。

• 确保Worker节点也完成了步骤1、2、3。
• 执行join命令：

  sudo kubeadm join <Master节点IP>:6443 --token <token> --discovery-token-ca-cert-hash sha256:<hash>

  这个命令包含了token和hash，它们用于Worker节点向Master节点认证。

6. 验证集群状态： 在Master节点上运行：

kubectl get nodes
kubectl get pods -A

如果所有节点状态为Ready，所有核心Pod（如kube-system命名空间下的）都处于Running状态，那么恭喜你，集群搭建成功了！

在Linux上部署Kubernetes集群，有哪些常见的挑战或坑点？

搭建Kubernetes集群，说实话，很少有一次性完美成功的，总会遇到这样那样的问题。我个人在部署过程中，遇到最多的就是以下这些“坑”：

• 网络配置的复杂性： 这是个大头。CNI插件的选择（Flannel、Calico、Cilium等）直接影响集群的网络行为和性能。我曾因Pod CIDR与Service CIDR规划不当，或者与宿主机网络冲突，导致Pod之间无法通信。防火墙规则（尤其是iptables或firewalld）如果没处理好，也会阻断内部通信。SELinux更是个隐形杀手，它默认的强制模式经常会阻止容器或Kubernetes组件的正常操作，导致各种奇怪的权限拒绝错误，所以我通常会先把它设为permissive或直接禁用。
• 资源消耗与规划： 别看Kubernetes只是个编排工具，它自身也是个资源大户，特别是Master节点上的kube-apiserver、etcd等组件。我曾因给Master节点分配的内存和CPU不足，导致API响应缓慢，甚至集群不稳定。etcd的磁盘IO性能也至关重要，如果磁盘IO跟不上，整个集群的性能都会受影响。
• 版本兼容性： kubeadm、kubelet、kubectl这三剑客的版本必须与你计划部署的Kubernetes版本高度匹配，否则会出现各种不兼容的错误。比如，用1.26的kubeadm去初始化一个1.25的集群，或者kubelet版本比kube-apiserver高太多，都可能导致节点无法加入或不健康。我一般会严格按照官方文档的推荐版本来安装。
• 镜像拉取问题： 国内网络环境下，拉取k8s.gcr.io（现在是registry.k8s.io）的镜像经常会遇到超时或失败。我通常会配置Docker或containerd的镜像加速器，或者提前手动kubeadm config images pull来规避这个问题。
• 存储方案的选型： 部署有状态应用时，存储是个绕不开的话题。选择NFS、Ceph、或者云厂商的CSI插件，每种都有其复杂性。我曾因为对PV/PVC的理解不够深入，导致有状态Pod无法正常启动或数据丢失。本地存储（hostPath或local-path-provisioner）虽然简单，但缺乏高可用性，不适合生产。
• 证书和Token管理： kubeadm会生成大量的证书和Token，这些都是集群安全的关键。如果Token过期或者不小心丢失，加入新节点会变得很麻烦。对于高可用集群，kube-apiserver的负载均衡器配置也需要格外小心。

这些坑点，很多时候需要你具备一定的Linux基础、网络知识和耐心去排查。日志（journalctl -u kubelet、kubectl logs）是最好的帮手。

选择合适的容器运行时和网络插件对Kubernetes集群性能有何影响？

选择合适的容器运行时和网络插件，对Kubernetes集群的性能、资源利用率、安全性和功能性都有着决定性的影响。这就像给你的房子选地基和水电系统，基础打不好，上层建筑再华丽也容易出问题。

容器运行时 (Container Runtime)： 在Kubernetes生态中，容器运行时负责真正运行容器镜像。现在主流选择是containerd和CRI-O，它们都是轻量级的容器运行时接口（CRI）实现，而Docker Engine（或更准确地说，Docker Daemon）虽然曾经是主流，但现在其内部的Docker Shim已被弃用，官方更推荐直接使用CRI兼容的运行时。

• containerd： 这是Docker公司贡献给CNCF的项目，也是Docker Engine底层实际使用的容器运行时。它非常轻量、稳定、高效。

  • 性能影响： 相较于完整的Docker Engine，containerd不包含那么多上层管理功能，因此其自身资源消耗更小，启动容器的速度通常更快。这对于大规模集群或需要快速扩缩容的场景非常有利。
  • 资源利用率： 更低的运行时开销意味着节点上可以运行更多的业务Pod，提高了资源利用率。
  • 安全性： 减少了攻击面，因为它只专注于容器运行的核心功能。
  • 我的看法： 我个人现在部署集群时，几乎都选择containerd。它简单、直接，与Kubernetes的集成度也很好，能满足绝大多数需求。

• CRI-O： 这是一个专门为Kubernetes设计的CRI运行时，目标是成为一个轻量级的替代方案。

  • 性能影响： 与containerd类似，也注重轻量和高效。
  • 我的看法： 如果你对Red Hat系的生态比较熟悉，或者对容器运行时有特殊需求（比如更紧密的OpenShift集成），CRI-O也是个不错的选择。但在通用场景下，containerd的社区支持和生态成熟度可能略胜一筹。

网络插件 (CNI - Container Network Interface)： CNI插件负责Pod之间的网络通信，以及Pod与外部网络的连接。它的选择直接影响网络的性能、隔离性、安全策略和可观测性。

• Flannel：

  • 特点： 最简单、易于部署的CNI插件之一。通常采用VXLAN或UDP模式构建overlay网络。
  • 性能影响： 由于是overlay网络，数据包会经过额外的封装和解封装，这会带来一定的性能开销（通常是几个百分点的延迟增加和吞吐量下降）。对于网络吞吐量要求不是极致的场景，影响不大。
  • 我的看法： 对于初学者、开发测试环境或小型集群，Flannel是我的首选。它足够简单，能让你快速看到Pod通信起来。但如果你的应用对网络延迟非常敏感，或者需要复杂的网络策略，Flannel可能就不够了。

• Calico：

  • 特点： 功能强大，支持BGP路由模式和IP-in-IP模式。提供丰富的网络策略功能，可以精确控制Pod间的流量。
  • 性能影响： 在BGP模式下，Calico可以直接利用底层网络路由，避免了overlay网络的封装开销，性能通常优于Flannel。但在IP-in-IP模式下，性能与Flannel类似。其网络策略的实现可能会引入一些CPU开销，但通常可以忽略。
  • 我的看法： Calico是我在生产环境或需要精细网络控制时经常选择的方案。它的网络策略功能非常实用，可以帮助实现微服务间的隔离和安全。部署和调试比Flannel略复杂，但功能上的提升是值得的。

• Cilium：

  • 特点： 基于eBPF技术，提供高性能的网络、安全和可观测性。支持更高级的网络策略，如L7策略。
  • 性能影响： 利用eBPF在内核层进行数据包处理，性能通常非常出色，能够显著降低网络延迟和提高吞吐量。
  • 我的看法： Cilium是未来的趋势，尤其是在对网络性能和安全有极致追求的场景。但它的复杂性也最高，对内核版本有要求，调试起来也相对困难。如果你的团队有足够的经验和资源，并且对网络有高要求，可以尝试Cilium。

总而言之，容器运行时和网络插件的选择，应该根据你的集群规模、应用特性、性能要求以及团队的技术栈来综合考量。没有“最好”的选择，只有“最适合”的选择。

如何确保Kubernetes集群在生产环境中的高可用性和可维护性？

在生产环境中，Kubernetes集群的高可用性和可维护性是核心考量，它直接关系到业务的连续性和运维效率。我个人在设计和管理生产K8s集群时，会从以下几个方面着手：

高可用性 (High Availability)：

• 多Master节点： 这是最基本的HA策略。单个Master节点是单点故障。我通常会部署至少三个Master节点，让它们组成一个高可用的控制平面。kubeadm支持这种模式，通过外部负载均衡器（如HAProxy、Keepalived，或者云服务商的LB）将请求分发到多个API Server。这样，即使一个Master节点宕机，集群控制面也能继续对外提供服务。
• etcd集群的健壮性： etcd是Kubernetes集群的“大脑”，存储着集群的所有状态数据。我一般会让etcd和Master节点一起部署（即stacked etcd），并确保etcd集群的节点数是奇数（3个或5个），以保证仲裁机制的健壮性。etcd的性能和数据安全至关重要，需要独立的存储和定期备份。
• Worker节点冗余： 确保有足够的Worker节点来承载Pod负载，并且有冗余。例如，N+1或N+2的策略，即使有节点故障，Pod也能调度到其他健康节点。我还会利用节点亲和性、反亲和性等调度策略，将关键应用的Pod分散到不同的节点上，避免单点故障。
• 存储高可用： 对于有状态应用，存储的高可用性同样关键。我通常会选择分布式存储方案（如Ceph、Rook、Longhorn），或者使用云服务商提供的持久卷服务，它们通常自带数据冗余和故障恢复能力。
• 网络高可用： 确保底层网络基础设施的冗余，包括交换机、路由器和网络链路。如果使用负载均衡器，也要确保其自身是高可用的。

可维护性 (Maintainability)：

• 全面的监控与告警： 没有监控的集群就像盲人摸象。我一定会部署Prometheus和Grafana来监控集群的各项指标（节点资源、Pod状态、API Server延迟、etcd性能等），并配置Loki或ELK Stack来收集和分析日志。关键指标达到阈值时，必须有告警通知到运维人员。这能帮助我们及时发现问题，甚至在问题发生前进行预测。
• 日志管理： 集中式的日志收集系统是必须的。通过Fluentd、Fluent Bit或Logstash将Pod日志收集到Elasticsearch或Loki中，便于检索、分析和故障排查。我发现很多时候，解决问题的第一步就是查看相关的Pod日志。
• 备份与恢复策略： 定期备份etcd数据是灾难恢复的最后一道防线。我通常会编写脚本，定时对etcd进行快照备份，并存储到安全的位置。同时，也要有明确的恢复流程和演练，确保在极端情况下能够快速恢复集群。
• 版本升级策略： Kubernetes版本更新很快，定期升级是必要的，可以获取新功能和安全补丁。我通常会遵循官方的升级指南，使用kubeadm upgrade命令，并严格遵循“先升级Master，再逐个升级Worker”的原则。升级前务必做好备份，并在测试环境充分验证。
• 自动化部署与管理： 手动部署和维护集群是噩梦。我强烈推荐使用自动化工具，如Ansible、Terraform或Helm。Ansible可以用来自动化安装和配置节点，Terraform可以管理基础设施资源，Helm则用于管理Kubernetes应用部署。自动化不仅能提高效率，还能减少人为错误。
• 安全加固： 生产环境的集群安全不容忽视。我会关注RBAC（Role-Based Access Control）的最小权限原则，限制用户和Service Account的权限。Pod Security Policies（虽然已被弃用，但其理念仍重要，现在转向Pod Security Admission）和网络策略也是我用来增强集群安全性的重要手段。
• 文档和Runbook： 维护一份清晰的集群架构

本篇关于《Linux搭建K8s集群教程详解》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！