如何在Linux系统中使用Kubernetes容器编排？

在Linux服务器上跑起成百上千个容器之后，最让人头疼的往往不是写镜像，而是怎么让这些容器互相发现、自动重启、按需扩容。Kubernetes就是为解决这类问题而生的容器编排系统，它把多台Linux机器组成一个逻辑集群，由控制平面统一决定哪个容器跑在哪台机器上。理解这套机制，比单纯背kubectl命令更有价值。

Linux环境准备与Kubernetes安装

要在Linux中使用Kubernetes，第一步是选好发行版并关闭可能影响容器网络的内核功能。大多数生产环境使用Ubuntu 22.04或CentOS Stream，两者都支持主流的containerd运行时。安装前必须确保swap已经关闭，因为kubelet默认不允许节点使用交换分区，否则会启动失败。同时需要加载br_netfilter模块，让桥接流量经过iptables规则，这是Kubernetes网络插件正常工作的前提。

使用kubeadm是最省心的安装方式，它把证书生成、静态Pod编排等复杂步骤封装成一条命令。在控制平面节点执行kubeadm init时，工具会拉取核心组件镜像并写入/etc/kubernetes/admin.conf。节点加入集群则靠kubeadm join配合初始化时打印的令牌完成。下面是一段在Ubuntu上禁用swap并安装kubeadm的示例：

# 临时关闭swap
sudo swapoff -a
# 永久禁用，注释fstab中的swap行
sudo sed -i '/ swap / s/^(.*)$/#1/g' /etc/fstab

# 安装kubeadm、kubelet、kubectl
sudo apt-get update
sudo apt-get install -y apt-transport-https ca-certificates curl
curl -fsSL https://pkgs.k8s.io/core:/stable:/v1.29/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg
echo 'deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/v1.29/deb/ /' | 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

安装完成后，不要用root直接操作集群，而应将admin.conf拷贝到普通用户目录。很多初学者在Linux上遇到权限错误，就是因为误用了root环境变量。通过kubectl get nodes能看到节点处于NotReady状态，这通常是网络插件未部署导致，属于正常现象，后面装上Calico或Flannel即可变绿。

容器运行时与资源隔离原理

Kubernetes自身并不直接创建容器，它依赖Linux上的容器运行时，比如containerd或CRI-O。kubelet作为节点上的代理，通过CRI接口调用运行时，运行时再操作内核的namespace和cgroup。namespace负责隔离进程的视图，比如每个容器以为自己独占PID 1；cgroup则限制CPU和内存上限，防止某个容器吃光整台机器资源。

在Linux系统里看资源限制非常直观，cgroup v2的目录通常挂在/sys/fs/cgroup下，kubelet会为每一个Pod生成独立子树。当你用kubectl describe pod看到OOMKilled，本质就是该Pod的cgroup内存上限被突破，内核主动杀掉进程。理解这点后，我们在写资源请求和限制时就有了依据：requests影响调度器选节点，limits才是真正的硬墙。

apiVersion: v1
kind: Pod
metadata:
  name: demo-pod
spec:
  containers:
  - name: app
    image: nginx:1.25
    resources:
      requests:
        memory: "64Mi"
        cpu: "100m"
      limits:
        memory: "128Mi"
        cpu: "200m"

上面的yaml里，引号包裹的值是字符串，Kubernetes会解析成对应资源量。如果节点剩余可分配内存小于64Mi，调度器就不会把Pod放上去。这种基于Linux cgroup的硬隔离，比传统虚拟机轻量，却又比裸跑进程安全，是容器编排能规模化的根基。值得注意的是，containerd的配置文件中也要开启SystemdCgroup=true以适配cgroup v2，否则kubelet会报运行时不匹配。

用Deployment与Service编排应用

单纯跑一个Pod没有编排意义，Kubernetes真正强的地方在控制器。Deployment是最常用的控制器，它维护一个ReplicaSet，保证指定数量的Pod副本始终存在。当你修改镜像版本，Deployment会按策略一批批替换旧Pod，实现滚动更新。如果新版本启动报错，还能一键回滚到上一个稳定Revision。

Service则解决Pod IP漂移的问题。因为Pod随时可能被调度到别的节点并重获IP，外部访问不能写死地址。Service通过label selector把一组Pod聚成一个虚拟IP，Linux的iptables或IPVS规则把流量转发过去。ClusterIP只在集群内可达，NodePort会在每个节点开端口，LoadBalancer则依赖云厂商。下面给出最小可用的Deployment加Service定义：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: nginx:1.25
        ports:
        - containerPort: 80
---
apiVersion: v1
kind: Service
metadata:
  name: web-svc
spec:
  selector:
    app: web
  ports:
  - protocol: TCP
    port: 80
    targetPort: 80
  type: ClusterIP

应用这套配置后，在Linux节点上用kubectl exec进任意Pod，通过curl http://web-svc都能拿到响应，这就是编排带来的网络抽象。对比手动用docker run起三个容器再写nginx反向代理，Kubernetes用声明式文件消除了大量重复劳动。当流量上涨，只需改replicas数值，控制器会自动补齐Pod，配合HPA还能根据CPU指标自动伸缩。

从架构思考角度看，Kubernetes把Linux单机的管理能力放大到了机器池。它不神秘，核心就是调度加控制器加网络代理。在Linux系统中用好它，重点在于理解kubelet与运行时如何协作、cgroup怎样兜底资源、Service怎么屏蔽后端变化。把这些串起来，容器编排就从黑盒变成了可调试的平常工具。

KubernetesLinux容器容器编排修改时间：2026-08-16 12:14:30