openEuler 云原生进阶：K3s 轻量级 Kubernetes 集群实战

一、openEuler 22.03 LTS-SP1：为云原生而生

1.1 为什么选择 openEuler 22.03 LTS-SP1

前面两篇文章，我分别用 openEuler 部署了 WordPress 和 Nextcloud，对这个系统有了不少认识。这次要上 K3s 了，心里其实有点打鼓——Kubernetes 对系统的要求可不低，openEuler 能不能扛得住？

抱着这个疑问，我去翻了下 openEuler 22.03 LTS-SP1 的官方文档，结果发现这个版本在云原生方面的能力，真的超出了我的预期。

1.2 openEuler 22.03 LTS-SP1 的核心特性

这个版本是 openEuler 社区在 2023 年发布的长期支持版本，主打的就是稳定和高效。我挑几个和云原生相关的重点说一下：

1. Linux 5.10 LTS 内核

这个内核版本不是随便选的。5.10 是 Linux 的长期支持版本，集成了大量针对容器和虚拟化的优化：

• cgroup v2 支持完善，资源隔离更精准
• namespace 机制优化，容器启动更快
• 内存管理改进，适合高密度容器部署

我之前用的时候就感觉 Docker 容器起得特别快，现在想想应该就是内核的功劳。

1. NestOS 容器操作系统

这个是 openEuler 22.03 专门为云原生场景设计的特性。它采用了双根文件系统和原子化更新：

• rpm-ostree 支持：系统更新像 Git 一样，可以回滚
• ignition 配置：容器化环境的自动配置
• 与容器编排技术深度集成

虽然我这次没用 NestOS，但知道 openEuler 有这个东西，心里就踏实多了——说明他们是真的在针对容器场景做优化。

1. HybridSched 虚拟化混合调度

这个特性挺厉害的，可以根据业务的优先级进行智能调度：

• CPU 干扰控制：支持微秒级抢占
• 缓存和内存带宽控制：高优先级业务不会被低优先级拖累
• 功耗控制：在保证性能的同时降低能耗

对于跑 K8s 这种多容器混合部署的场景，这个特性应该很有用。

1. 硬件兼容性强

支持 x86 和 ARM 架构，我这台 x86 服务器用起来没啥问题。而且官方文档里说，对鲲鹏芯片有专门的优化。

1.3 从 Docker 到 K8s 的思考

前两篇文章，我用 Docker 和 Docker Compose 部署了两个应用。这两个工具确实好用，但有个问题：都是单机方案。

如果我想：

• 同时运行十几个容器应用，怎么统一管理？
• 某个容器挂了，能不能自动重启？
• 能不能根据负载自动扩容？
• 多台服务器之间怎么协同工作？

这些需求，Docker Compose 就搞不定了。得上 Kubernetes。

但标准的 K8s 太重了：

• 安装复杂，组件一大堆
• 资源占用大，小服务器跑不动
• 学习曲线陡峭，上手困难

所以我选了 K3s。它是 Rancher 搞的轻量级 K8s：

• 二进制文件只有 70MB（标准 K8s 几个 GB）
• 单节点就能跑完整集群
• 完全兼容标准 K8s API
• 安装简单，一条命令搞定

最关键的是，我想验证一下 openEuler 在容器编排场景下的表现。

二、K3s 部署实战

2.1 服务器环境

还是那台服务器，配置没变：

• CPU：16核 Intel Xeon Gold 6138 @ 2.00GHz
• 内存：16GB
• 存储：40GB SSD
• 操作系统：openEuler 22.03 (LTS-SP1)
• 内核版本：5.10.0-136.12.0.86.oe2203sp1.x86_64

这台服务器上已经跑着 WordPress 和 Nextcloud 两个 Docker 应用了。K3s 默认用 containerd，和 Docker 不冲突，可以共存。

2.2 安装 K3s：第一次踩坑

一开始我按照官方文档，直接执行：

curl -sfL https://get.k3s.io | sh -

结果报错了：

K3s安装报错

错误信息很明确：

Error: cannot install the best candidate for the job
- nothing provides container-selinux >= 3:2.191.0-1 needed by k3s-selinux-1.6-1.el9.noarch

问题出在 SELinux 上。K3s 需要 container-selinux >= 3:2.191.0-1，但 openEuler 22.03 LTS-SP1 的软件仓库里只有更老的版本。

这个坑其实挺常见的。不同发行版的软件包版本不一样，直接装容易遇到依赖问题。

2.3 解决方案：跳过 SELinux

对于学习和测试环境，可以跳过 SELinux 支持。修改安装命令：

curl -sfL https://get.k3s.io | INSTALL_K3S_SKIP_SELINUX_RPM=true sh -

这次就顺利了：

K3s安装成功

安装过程很快，大概 1 分钟就完成了。可以看到：

• 下载了 K3s v1.33.5+k3s1 版本
• 创建了 kubectl、crictl 等命令的软链接
• 创建了 systemd 服务文件
• 自动启动了 k3s 服务

这个过程比装标准 K8s 简单太多了。标准 K8s 要装 kubeadm、kubelet、kubectl，还要配置容器运行时、网络插件，折腾半天。K3s 一条命令全搞定。

2.4 验证安装

先看看服务状态：

sudo systemctl status k3s

K3s服务状态

服务是 active (running)，看起来没问题。可以看到 K3s 是以 systemd 服务的形式运行的，开机会自动启动。

三、配置 kubectl

3.1 配置 kubeconfig

K3s 安装完会自动创建 kubeconfig 文件，但默认路径需要 root 权限。为了方便使用，把它复制到用户目录：

# 创建 .kube 目录
sudo mkdir -p ~/.kube

# 复制配置文件
sudo cp /etc/rancher/k3s/k3s.yaml ~/.kube/config

# 修改权限
sudo chown $USER:$USER ~/.kube/config

3.2 验证集群状态

配置好后，用 kubectl 看看集群状态：

kubectl version
kubectl get nodes

kubectl配置和节点状态

输出显示：

• Client 版本：v1.33.5+k3s1
• Server 版本：v1.33.5+k3s1
• 节点状态：Ready

节点名称是 ser563963324474（我的服务器主机名），角色是 control-plane,master。这说明这是一个单节点集群，既是控制平面，也是工作节点。

3.3 查看系统组件

K8s 集群启动后，会在 kube-system 命名空间运行一些系统组件。看看都有啥：

kubectl get pods -A

系统Pods运行状态

可以看到这些组件都在运行：

• coredns：DNS 服务，负责集群内的域名解析
• metrics-server：资源监控，提供 kubectl top 命令的数据
• local-path-provisioner：本地存储，为 Pod 提供持久化存储
• traefik：Ingress 控制器，负责外部流量路由
• svclb-traefik：Traefik 的负载均衡器

这些都是 K3s 内置的。标准 K8s 需要自己装，K3s 直接给你配好了，省了不少事。

再用 kubectl describe node 看看节点的详细信息，可以看到很多 K8s 的标签和注解，内部 IP 是 10.1.226.3，K3s 还配置了 flannel 网络插件（vxlan 模式）。

四、部署第一个应用

4.1 创建 Deployment

理论讲完了，来点实际的。部署一个 Nginx 测试一下：

kubectl create deployment nginx-test --image=nginx:alpine

创建Deployment

命令执行后，K8s 会：

1. 创建一个 Deployment 对象
2. Deployment 创建一个 ReplicaSet
3. ReplicaSet 创建一个 Pod
4. Pod 里运行 nginx:alpine 容器

等几秒钟，Pod 就从 ContainerCreating 变成 Running 了。用 kubectl get deployments 和 kubectl get pods 可以看到：

• Deployment 状态是 1/1（期望1个，实际1个）
• Pod 状态是 Running

这个过程比 Docker 慢一点，因为多了一层编排。但好处是，如果这个 Pod 挂了，K8s 会自动重启；如果需要多个副本，改个数字就行。

4.2 暴露服务

Pod 创建好了，但外部还访问不了。需要创建一个 Service：

kubectl expose deployment nginx-test --port=80 --type=NodePort

暴露Service

Service 创建成功后，可以看到：

• 类型是 NodePort
• 内部 IP 是 10.43.240.192
• 端口映射是 80:32245/TCP

这里的 32245 是 K8s 自动分配的 NodePort（范围是 30000-32767）。只要访问服务器的 <IP>:80 就能访问到 Nginx 了。

4.3 访问测试

在浏览器里访问 http://<服务器IP>:80：

成功了！看到了 Nginx 的欢迎页面。这说明整个链路都通了：

• 浏览器 → 服务器 IP:32245
• NodePort Service → ClusterIP 10.43.240.192:80
• ClusterIP → Pod IP 10.42.0.9:80
• Pod → nginx 容器

K8s 的网络模型确实复杂，但也很强大。

4.4 查看 Pod 详情

用 kubectl describe pod 看看 Pod 的详细信息：

Pod详细信息

可以看到：

• Pod 名称：nginx-test-69fbd4bd85-lnmbj
• 命名空间：default
• 节点：ser563963324474
• Pod IP：10.42.0.9
• 容器 ID：containerd://a0714eb5e9db62ed...
• 镜像：nginx:alpine
• 镜像 ID：docker.io/library/nginx@sha256:b3c656d55d7ad751...
• 状态：Running

Events 部分（虽然截图截不完）会显示 Pod 的启动过程，比如调度到哪个节点、拉取镜像、启动容器等。这对排查问题很有用。

五、K3s on openEuler 的性能表现

5.1 资源占用分析

部署完应用，最关心的就是资源占用。看看 K3s 吃了多少内存：

ps aux | grep k3s | head -5
kubectl top pods -A

资源占用情况

从截图可以看到：

K3s 主进程：

• CPU：97.9%（这个是启动时的瞬时值，实际运行时很低）
• 内存：603MB（约 590MB）

各 Pod 的资源占用：

• nginx-test：CPU 0m，内存 10MB
• coredns：CPU 5m，内存 18MB
• local-path-provisioner：CPU 1m，内存 12MB
• metrics-server：CPU 6m，内存 22MB
• traefik：CPU 1m，内存 44MB

加起来，整个 K3s 集群（包括所有系统组件）大概占用 700MB 内存左右。

对比一下标准 K8s，控制平面组件（apiserver、controller-manager、scheduler、etcd）就要吃掉 1.5GB+。K3s 的资源占用确实低很多。

我这台 16GB 内存的服务器，跑 K3s + 几个应用完全没压力。

5.2 openEuler 的优势体现

用了几个小时 K3s，我对 openEuler 在云原生场景的表现有了更深的感受。

1. 稳定性一流

从安装到部署应用，整个过程没有任何报错（除了一开始的 SELinux 依赖，那个不算系统的问题）。Pod 启动很快，没有出现过 Pending 或 CrashLoopBackOff 的情况。

K3s 的主进程运行了几个小时，内存占用一直很稳定，没有出现内存泄漏或 CPU 飙高的情况。

1. 内核调度优化

5.10 内核在容器场景下的表现确实不错。Pod 的启动速度很快，从 ContainerCreating 到 Running 只需要几秒钟。

我之前在 CentOS 7（3.10 内核）上试过 K8s，Pod 启动明显要慢一些。openEuler 的 5.10 内核，应该是做了不少针对 cgroup 和 namespace 的优化。

1. 资源管理效率高

系统本身占用的资源很少。我用 free -h 看了下，整个系统（包括 K3s、WordPress、Nextcloud）只用了 4GB 左右内存，还有 12GB 可用。

这说明 openEuler 在资源调度上确实有优势。同样的硬件，能跑更多的容器。

1. 容器生态完善

K3s 用的是 containerd 作为容器运行时，和 openEuler 的集成没有任何问题。镜像拉取、容器启动、网络配置，都很流畅。

而且 openEuler 的软件仓库里，Docker、containerd、runc 这些容器相关的包都有，版本也比较新。不用担心兼容性问题。

5.3 与其他发行版对比

我之前在 Ubuntu 20.04 上也部署过 K3s，对比一下：

Ubuntu 20.04：

• 优点：软件包新，社区资料多
• 缺点：apt 源在国内慢，系统占用内存稍多（1GB+）

openEuler 22.03 LTS-SP1：

• 优点：系统占用少，性能好，dnf 源快
• 缺点：社区资料相对少一些（但在快速增长）

六、从 Docker 到 K3s 的感悟

6.1 技术进阶的收获

这次从 Docker Compose 跨到 K3s，学到了不少东西。

Deployment、ReplicaSet、Pod 的关系：

• Deployment 是声明式的部署配置
• ReplicaSet 负责维护 Pod 的副本数量
• Pod 是实际运行容器的地方

这种分层设计，比 Docker Compose 灵活多了。想要扩容？改 Deployment 的 replicas 就行。想要滚动更新？Deployment 自动帮你搞定。

Service 的网络模型：

• ClusterIP：集群内部访问
• NodePort：从节点端口访问
• LoadBalancer：云平台的负载均衡器（本地环境用不了）

这套网络模型虽然复杂，但很强大。多个服务之间的通信，通过 Service 名称就能互相访问，不用管 IP 地址。

声明式配置的魅力：

K8s 的核心理念是"声明式"。我告诉 K8s 我想要什么状态，K8s 负责把实际状态调整到期望状态。

比如我声明 Deployment 的 replicas 是 3，K8s 就会确保始终有 3 个 Pod 在运行。有 Pod 挂了？自动重启。节点挂了？自动在其他节点启动。

这种思路和 Docker 的"命令式"完全不同。Docker 是你告诉它做什么，它就做什么。K8s 是你告诉它要什么，它自己想办法。

6.2 openEuler 的云原生能力

通过这次实战，我对 openEuler 22.03 LTS-SP1 在云原生场景的能力有了更全面的认识。

内核优化是基础：

5.10 LTS 内核确实很稳。容器启动快、调度准、资源隔离好。

NestOS 是亮点：

虽然这次没用 NestOS，但知道 openEuler 有专门为容器设计的操作系统，说明社区在云原生方向是认真的。以后有机会一定要试试 NestOS + K3s 的组合。

生态在完善：

openEuler 的软件包生态越来越好了。K3s、Docker、containerd 这些容器相关的软件都能顺利安装。社区文档也在不断完善，遇到问题能找到解决方案。

七、总结

这次从 Docker Compose 跨到 K3s，算是在云原生的路上又进了一步。K3s 的轻量和易用，让我没有什么心理负担就上手了 K8s。

openEuler 22.03 LTS-SP1 在整个过程中的表现，超出了我的预期。内核稳定、资源占用低、容器生态完善，这些优势在 K3s 场景下体现得很明显。

作为一个从 CentOS、Ubuntu 转到 openEuler 的用户，我越来越觉得：openEuler 不仅仅是"能用"，而是"好用"。特别是在云原生场景，openEuler 已经是一个很成熟的选择了。