[toc]

K3s笔记1

使用的Linux系统是安装在windows11 wsl2 上的Ubuntu24.04

K3s 介绍

K3s中文官网 https://www.rancher.cn/k3s

K3s 是一个轻量级的 Kubernetes （k8s）发行版，专为边缘计算、物联网等资源受限场景设计。

它保留了 Kubernetes （k8s）的全部核心功能，同时通过裁剪非必要组件、内置依赖、优化资源占用，实现了轻量化部署。

为什么叫K3s ?

Kubernetes 是一个 10 个字母的单词，简写为 K8s。

而 K3s 作为 Kubernetes 的轻量版本，名字来源于 "Kubernetes 一半大小" 的概念（10字母的一半是5字母，Kubernetes → K8s，5字母的单词 → K3s）。

K3s 没有全称，也没有官方的标准发音。

K3s 和 Kubernetes（k8s）的区别

K3s 与 Kubernetes 并非两种不同技术，而是完整版与精简版的关系。

核心功能：K3s 保留了 K8s 的全部核心能力
使用方式：两者在使用层面完全一致（API、命令、YAML 语法相同）
差异点：仅在底层使用的组件、安装方式、使用场景上存在差异

总结：K3s 它保留了 Kubernetes （k8s）的全部核心功能，同时通过裁剪非必要组件、内置依赖、优化资源占用，实现了轻量化部署、一键安装、极低资源消耗。

使用场景对比

场景类型	推荐使用	原因
企业级大规模生产集群	K8s	全功能、高度定制、成熟稳定
云厂商托管集群	K8s	完整的云厂商集成
边缘计算	K3s	轻量、资源占用低
IoT设备	K3s	极低资源需求、易于部署
开发测试环境	K3s	一键安装、快速部署
小型项目	K3s	简单易用、维护成本低

K3s 和 K8s 技术详细对比

对比维度	K8s (标准 Kubernetes)	K3s (轻量 Kubernetes)
定位	工业级、全功能、可高度定制	轻量、极简、开箱即用
发行方	CNCF / 谷歌社区	Rancher（SUSE）
二进制大小	较大（百 MB 级别）	< 100MB（超轻量）
内存要求	高（至少 2GB+）	极低（512MB 可跑）
安装难度	复杂（多步、手动配置）	极简（1 条命令）
容器运行时	需自行安装（containerd/docker）	内置 containerd
默认存储	独立部署	内置 SQLite 代替
网络插件	需手动安装（Calico/Flannel）	内置 CNI
Ingress网关	需手动安装	内置 Traefik
DNS	需手动部署 CoreDNS	内置 CoreDNS
负载均衡	需手动配置	内置 LoadBalancer
组件数量	多	少
高可用	原生支持、复杂、成熟	支持，但更简单
云厂商集成	完整（AWS/GCP/ 阿里云）	较少（偏自建）
适合学习	不适合（太复杂）	最适合入门
生产场景	大型集群、核心业务、多节点	边缘、IoT、小集群、轻量微服务
命令/YAML	标准完整	标准完整
学习成本	高	极低

总结

K8s = 标准完整版 Kubernetes（企业生产、大规模集群）
K3s = 轻量版 Kubernetes（学习、边缘、小集群、IoT）

两者 100% 兼容 API、命令、YAML、概念。差异只在底层裁剪、组件、资源占用、安装方式上。

K8s 和 K3s 节点上的区别

K8s 只有两种节点类型

Master 节点：又称控制平面，负责集群管理、调度决策和API服务。一个集群至少 1 个 Master，高可用要 3 个。
Worker 节点：又称工作平面，主要负责运行容器化应用。一个集群可以有多个 Worker 节点。每个 Worker 节点上可以运行多个 Pod，每一个pod里面可以包含多个同类型容器。

K3s 只有两种节点类型

Server 节点：相当于 K8s 的 Master 节点。
Agent 节点：相当于 K8s 的 Worker 节点。

总结：K8s的 Master 节点 = K3s的 Server 节点，K8s的 Worker 节点 = K3s的 Agent 节点。本质完全一样，只是名字换了，职责一模一样

K3s 架构和组件

K3s 相比标准 Kubernetes，采用了精简但功能完整的架构设计，它通过整合和优化组件，实现了轻量级部署。

K3s 架构图

如图是K3s 架构图

K3s 架构优势

轻量紧凑：所有组件整合到单个二进制文件，体积小于100MB
简化部署：一键安装，自动配置所有组件
资源高效：最低仅需512MB内存即可运行
内置依赖：包含所有必要的组件，无需额外安装
高度兼容：与标准Kubernetes API完全兼容
灵活存储：支持多种存储后端，适应不同场景

K3s的架构设计使其成为边缘计算、IoT设备、小型部署的理想选择，同时保持了与标准Kubernetes的完全兼容性。

节点

K3s 架构主要有两种节点。

Server 节点（控制平面节点）

作用：集群的大脑，负责集群管理、调度决策和API服务。
数量：一个完整的K3s集群至少需要 1 个 Server节点，高可用部署需要 3 个或更多。
核心组件：包括 kube-apiserver、kube-scheduler、kube-controller-manager
内置服务：Traefik、CoreDNS、Metrics Server

Agent 节点（工作节点）

作用：负责运行容器化应用
数量：根据需求而定。一个集群可以有多个 Agent 节点，每个节点上可以运行多个 Pod。每一个pod里面可以包含多个同类型容器。
核心组件：kubelet、containerd、kube-proxy、Flannel
内置服务：Local Path Provisioner

K3s 单节点架构

单节点架构是K3s最常见的部署方式，适合开发、测试和小型生产环境：

特点：Server节点和Agent节点运行在同一台机器上
优势：部署简单，资源占用低
适用场景：开发环境、边缘设备、IoT设备

如图所示

K3s 多节点架构（高可用架构）

多节点架构提供更高的可用性和扩展性：

特点：多个Server节点和多个Agent节点，运行在不同的服务器上。
优势：高可用、负载均衡、更好的扩展性
适用场景：生产环境、边缘集群、需要高可用性的场景

如图所示

组件

Server 节点组件

Server 节点（又称 master 主节点或控制平面）是 K3s 集群的核心，包含以下关键组件。

组件	功能	职责
kube-apiserver	整个K3s的入口组件，提供API入口。	处理所有API请求、认证授权、资源验证。为集群内组件提供服务发现机制。所有其他组件都只与它通信，不直接互访
kube-scheduler	智能调度组件	监控Pod状态，评估节点资源和负载情况，为Pod选择最佳运行节点
kube-controller-manager	控制管理组件	管理副本、节点、端点等控制器
etcd (可选)	分布式键值存储	存储集群状态和配置（高可用部署时使用）。K3s默认使用SQLite作为存储，仅在高可用部署时推荐使用etcd
k3s-server	主进程	整合上述核心组件
Traefik	内置的Ingress控制器	提供路由和负载均衡
CoreDNS	内置的DNS服务	为集群提供域名解析
Metrics Server	监控服务	提供资源使用指标，支持HPA等功能

Agent 节点组件

Agent 节点（又称 Worker 工作节点）负责实际运行容器，包含以下组件。

组件	功能	职责
kubelet	节点代理组件	管理Pod生命周期、与容器运行时交互
containerd	容器运行时	拉取镜像、创建和管理容器。提供容器运行环境
Flannel	容器网络插件	为Pod分配IP、实现Pod之间的网络通信
kube-proxy	网络代理组件	实现Service负载均衡，处理Pod与Service之间的通信
k3s-agent	代理进程	负责与Server节点通信
Local Path Provisioner	存储服务	提供本地存储卷支持

各个组件的通信流程

用户请求流程：
- 用户通过kubectl命令行工具发送命令
- 请求到达kube-apiserver组件
- kube-apiserver组件开始验证请求并处理，然后转发给相关控制器
- 相关控制器执行相应操作
Pod创建流程：
- kube-apiserver组件接收创建Pod的请求
- kube-scheduler组件为Pod选择节点
- kube-apiserver组件通知目标节点的kubelet组件
- kubelet组件通过containerd容器运行时组件创建容器
- kubelet组件向kube-apiserver组件报告Pod状态
服务发现流程：
- Service创建后，CoreDNS组件记录服务信息
- Pod通过服务名访问其他服务
- kube-proxy组件维护网络规则实现负载均衡

安装K3s

注意:无论是 Kubernetes 还是K3s都是要安装在Linux操作系统中的。无法直接安装在windows系统上。

在Linux系统中，执行如下命令。下面三个安装命令，根据实际情况选择一个即可。

# 官方标准（最主流）即可一键快速安装 K3s（下载速度慢）
curl -sfL https://get.k3s.io | sh -

# 国内镜像加速（推荐），并安装特定版本的k3s
curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn INSTALL_K3S_VERSION=v1.35.2+k3s1 sh -

# 带有配置的安装命令（主要配置了pause镜像的下载地址 和 iptables模式等）
curl -sfL https://rancher-mirror.rancher.cn/k3s/k3s-install.sh | INSTALL_K3S_MIRROR=cn INSTALL_K3S_VERSION=v1.35.2+k3s1 sh -s server --pause-image registry.aliyuncs.com/google_containers/pause:3.6 --kube-proxy-arg proxy-mode=iptables

# 验证安装是否成功 ，显示 Ready → 成功 ✅ 
sudo kubectl get node

# 查看 K3s 服务状态，显示 active (running) → 成功 ✅
sudo systemctl status k3s

# 查看各个pod的状态信息，各个pod都显示 Running状态 → 成功 ✅
sudo kubectl get pods -n kube-system

# 查看集群信息
sudo kubectl cluster-info

该命令会自动下载并安装启动 K3s服务，并配置开机自启等。无需手动配置。

如图所示

常见问题与解决方案

各个pods始终无法启动运行（pod 不是Running状态）的问题？

如图所示，一键安装并启动K3s的时候，之后使用sudo kubectl get pods -n kube-system命令查询pod状态，发现各个pod处于ContainerCreating状态。

对于一个正常安装并运行的K3s服务来说。各个pod应该是Running状态,并且都是Ready。

解决方案

① 第一步查询pod的详细信息，找出问题

# 查询pod的详细信息
$ sudo kubectl describe pods <pod名称> -n kube-system

# 例如 查询coredns这个pod的详细信息
$ sudo kubectl describe pods coredns-7566b5ff58-jddcn -n kube-system

# 将会返回pod的详细信息，主要看其中的Events信息。
Name:                 coredns-7566b5ff58-jddcn
Namespace:            kube-system
Priority:             2000000000
Priority Class Name:  system-cluster-critical
Service Account:      coredns
Node:                 desktop-u7n8te2/172.22.111.149
Start Time:           Thu, 16 Apr 2026 15:59:31 +0800
Labels:               k8s-app=kube-dns
                      pod-template-hash=7566b5ff58
............
............
............

Events:
  Type     Reason                  Age                   From               Message
  ----     ------                  ----                  ----               -------
  Normal   Scheduled               13m                   default-scheduler  Successfully assigned kube-system/coredns-7566b5ff58-jddcn to desktop-u7n8te2
  Warning  FailedCreatePodSandBox  13m                   kubelet            Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "6cc93938aa0ae017638381ecff493db9172b325a5ce8a995f4f133563ca04330": plugin type="flannel" failed (add): failed to load flannel 'subnet.env' file: open /run/flannel/subnet.env: no such file or directory. Check the flannel pod log for this node.
  Warning  FailedCreatePodSandBox  12m                   kubelet            Failed to create pod sandbox: rpc error: code = DeadlineExceeded desc = failed to start sandbox "6b7d045f7671b55042c87c794ec620930ec118a3b5f3ad425415df9c8c69c907": failed to get sandbox image "rancher/mirrored-pause:3.6": failed to pull image "rancher/mirrored-pause:3.6": failed to pull and unpack image "docker.io/rancher/mirrored-pause:3.6": failed to resolve reference "docker.io/rancher/mirrored-pause:3.6": failed to do request: Head "https://registry-1.docker.io/v2/rancher/mirrored-pause/manifests/3.6": dial tcp 104.244.43.35:443: i/o timeout
  ..............
  ..............
  ..............
  Warning  FailedCreatePodSandBox  33s (x18 over 6m45s)  kubelet            (combined from similar events): Failed to create pod sandbox: rpc error: code = Unknown desc = failed to start sandbox "d59979400144b49aa83f123afaf3c46f1b9269fb552dda70200cf48ad8abeee4": failed to get sandbox image "rancher/mirrored-pause:3.6": failed to pull image "rancher/mirrored-pause:3.6": failed to pull and unpack image "docker.io/rancher/mirrored-pause:3.6": failed to resolve reference "docker.io/rancher/mirrored-pause:3.6": failed to do request: Head "https://registry-1.docker.io/v2/rancher/mirrored-pause/manifests/3.6": dial tcp 122.10.85.4:443: connect: connection refused

② 第二步分析问题

分析Events信息,可以发现主要原因就是国内网络无法访问 Docker Hub → mirrored-pause镜像拉取失败 → Pod 永远卡在 ContainerCreating 状态。

rancher/mirrored-pause:3.6 镜像是 Kubernetes 启动 Pod 必须的 “基础沙箱镜像”。

③ 解决方式修改K3s的镜像配置，将其换成国内能够访问的。

# 创建 K3s 配置目录
sudo mkdir -p /etc/rancher/k3s

# 写入国内docker镜像配置
sudo tee /etc/rancher/k3s/registries.yaml <<EOF
mirrors:
  docker.io:
    endpoint:
      - https://docker.xuanyuan.me
      - https://docker.1ms.run
      - https://docker.1panel.live
      - https://hub.uuukey.com
      - https://docker.m.daocloud.io
  k8s.gcr.io:
    endpoint:
      - https://registry.aliyuncs.com/google_containers
  gcr.io:
    endpoint:
      - https://registry.aliyuncs.com/google_containers
  quay.io:
    endpoint:
      - https://quay.1panel.live
EOF

# 重启K3
sudo systemctl restart k3s

# 重启查看各个pod的状态信息
sudo kubectl get pods -n kube-system

④ 查询结果

如图，所有pod都已经处于Running状态。

为什么有两个pod的是 Completed 状态?

其中有两个Pod 是 Completed 状态。这两个是 K3s 安装 Traefik 时需要的Job 类型的 Pod（一次性任务），执行完就会自动退出，属于正常现象。完全不影响整个K3s集群运行。

Traefik 真正需要的长期服务是下面这两个 Running 的 Pod：

svclb-traefik-xxx（负载均衡代理）
traefik-xxx（入口网关本体）

k3s 初次安装K3s后各个Pod的介绍

Pod 名称	作用	状态说明
coredns-xxx	K3s 内置的 DNS 服务，为集群内所有 Pod、Service 提供域名解析，是集群服务发现的核心组件，确保 Pod 之间能通过 Service 名互相通信。	Running表示正常运行
helm-install-traefik-crd-xxx	用于安装 Traefik 所需的CRD，是 Traefik 能在 K8s 中正常运行的前置依赖。	一次性任务。状态 Completed 代表安装成功
helm-install-traefik-xxx	在 CRD 安装完成后，执行 Traefik 本身的部署流程，完成 Ingress控制器的初始化。	一次性任务。状态 Completed 代表部署成功
local-path-provisioner-xxx	提供本地存储卷支持，适合单节点,轻量集群使用。	Running表示正常运行
metrics-server-xxx	集群监控指标服务，采集资源使用数据	Running表示正常运行
svclb-traefik-xxx	Traefik 的 Service LoadBalancer 辅助 Pod。Traefik 的负载均衡代理	Running表示正常运行
traefik-xxx	K3s 默认的 Ingress Controller，作为集群的入口网关，负责将外部 HTTP/HTTPS 请求转发到集群内对应的 Service，实现集群服务的对外暴露。	Running表示正常运行

卸载K3s（彻底干净）

# Server 节点卸载
sudo /usr/local/bin/k3s-uninstall.sh
# Agent 节点卸载
sudo /usr/local/bin/k3s-agent-uninstall.sh

# 额外清理残留（彻底重装）
sudo rm -rf /etc/rancher 
sudo rm -rf /var/lib/rancher
sudo rm -rf ~/.kube/config

# 验证是否卸载完成。若无输出 → 卸载成功 ✅
which k3s
which kubectl

K3s 入门案例 - 部署Nginx 集群服务

部署一个 Nginx Web 服务，用 K3s 运行，外部可以访问。

① 安装K3s

② 创建部署文件

创建文件 nginx-k3s.yaml。文件内容如下

yaml

# 1. 部署：负责启动并维持 Nginx 容器运行
apiVersion: apps/v1   # 告诉 K3s：我用的是哪个版本的 API
kind: Deployment      # 告诉 K3s：我要创建一个长期服务应用。必须用 Deployment
metadata:               
  name: nginx-deploy    # 给服务应用起名字
spec:
  replicas: 2           # 表示该服务应用会启动 2 个实例
  selector:
    matchLabels:
      app: nginx       # 给该服务应用打标签。标签为nginx
  template:
    metadata:
      labels:
        app: nginx          # Pod 的模板
    spec:
      containers:
      - name: nginx             # 容器名称。一个 Pod 可以有多个容器，必须区分名字。
        image: nginx:alpine     # 容器镜像。
        ports:
        - containerPort: 80     # 容器使用的端口。此处使用 80 端口

---
# 2. 服务的作用是 提供一个固定 IP + 固定端口，自动代理到后端 Pod。相当于负载均衡器 + 稳定入口
apiVersion: v1      # 告诉 K3s：我用的是哪个版本的 API
kind: Service       # 告诉 K3s：创建一个服务
metadata:
  name: nginx-svc       # 起名字
spec:
  type: NodePort        # 相当于在服务器上开一个端口，供外部访问
  selector:             # 作用是 Service 通过标签找到 Pod
    app: nginx          # 找到所有标签为 nginx 的 Pod
  ports:
  - port: 80                # Service 自己的端口
    targetPort: 80          # 容器使用的端口
    nodePort: 30080         # 外部访问端口 30080

文件说明

这个YAML文件定义了两个资源：

Deployment：负责运行2个Nginx容器实例
Service：负责为这些容器提供网络访问

通过这个配置，Kubernetes会：

创建2个运行Nginx的Pod
监控这些Pod的状态，确保始终有2个副本运行
创建一个服务，将外部请求转发到这些Pod
在每个节点上开放30080端口，允许外部访问

③ 开始部署（执行命令）

将该文件放到安装有K3s服务的Linux系统中，然后执行下面命令。

这段命令的作用是根据 YAML 文件，创建 Deployment 控制器和 Service服务。

# 若终端与文件是同一目录中，则执行下面命令。否则文件地址需要绝对路径。
# 部署应用
sudo kubectl apply -f nginx-k3s.yaml

# 输出下面，表示部署成功
# deployment.apps/nginx-deploy created
# service/nginx-svc created

④ 验证部署

# 查看部署状态
sudo kubectl get deployments

# 查看 Pod 状态
sudo kubectl get pods

# 查看 Service 状态
sudo kubectl get services

# 查询当前Linux系统的IP地址
hostname -I  或者 ip a

# 访问服务（在浏览器中打开）
# http://<IP地址>:30080

# 查看 Pod 详细信息
sudo kubectl describe pod <pod-name>

# 查看 Service 详细信息
sudo kubectl describe service nginx-svc

# 查看日志
sudo kubectl logs <pod-name>

如果看到Nginx欢迎页面，说明部署成功！

K3s YAML 文件详解

YAML文件的作用

YAML 是Kubernetes（包括K3s）中用于定义和管理资源的配置文件格式。它的核心作用包括：

资源定义：通过YAML文件定义各种Kubernetes资源（Pod、Deployment、Service等）
配置管理：集中管理配置信息，实现配置与代码分离
部署编排：描述应用的部署方式、副本数量、网络配置等
版本控制：YAML文件可以纳入版本控制系统，实现配置的可追溯性
声明式配置：只需要描述期望的状态，Kubernetes会自动实现状态转换

YAML文件的基本结构

一个完整的Kubernetes YAML文件通常包含以下部分：

yaml

# 1. API版本
apiVersion: apps/v1  # API版本，不同资源使用不同版本

# 2. 资源类型
kind: Deployment  # 资源类型，如Deployment、Service、Pod等

# 3. 元数据
metadata:
  name: nginx-deploy  # 资源名称
  labels:
    app: nginx  # 标签，用于资源选择

# 4. 规格
spec:
  replicas: 2  # 副本数量
  selector:
    matchLabels:
      app: nginx  # label选择器，用于匹配Pod
  template:
    metadata:
      labels:
        app: nginx  # Pod模板标签
    spec:
      containers:
      - name: nginx  # 容器名称
        image: nginx:alpine  # 容器镜像
        ports:
        - containerPort: 80  # 容器端口

如何编写YAML文件

第一步：确定资源类型和API版本

不同的资源类型对应不同的API版本：

资源类型	API 版本
Pod	`apiVersion: v1`
Deployment	`apiVersion: apps/v1`
Service	`apiVersion: v1`
ConfigMap	`apiVersion: v1`
Secret	`apiVersion: v1`
Ingress	`apiVersion: networking.k8s.io/v1`

第二步：定义元数据

元数据部分包含资源的基本信息：

name：资源的唯一名称
labels：用于资源选择的标签
namespace：资源所属的命名空间（可选）

第三步：编写规格部分

规格部分是YAML文件的核心，定义了资源的具体配置：

Pod：定义容器、端口、卷等
Deployment：定义副本数、选择器、Pod模板等
Service：定义服务类型、端口、选择器等
ConfigMap：定义配置数据
Secret：定义敏感信息

第四步：多资源定义

一个YAML文件可以包含多个资源定义，使用---分隔：

yaml

# 第一个资源：Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deploy
spec:
  # ...

---

# 第二个资源：Service
apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  # ...

为什么要使用YAML文件

前因

在Kubernetes出现之前，容器管理主要依靠命令行工具和脚本，存在以下问题：

配置分散：配置信息分散在各种脚本和命令中
难以版本控制：配置变更无法有效追踪
手动操作复杂：部署和管理需要大量手动操作
环境一致性差：不同环境的配置容易出现差异

后果

使用YAML文件带来了以下好处：

声明式配置：只描述目标状态，Kubernetes负责实现
配置集中化：所有配置集中在YAML文件中
版本控制友好：YAML文件可以纳入Git等版本控制系统
环境一致性：相同的YAML文件可以在不同环境中使用
自动化部署：支持CI/CD流水线自动化部署
可复用性：配置可以被复用和共享

YAML文件的总结

YAML文件是Kubernetes和K3s中管理资源的核心工具，它通过声明式的方式定义了集群中各种资源的期望状态。理解YAML文件的结构和编写方法，对于有效管理Kubernetes集群至关重要。

通过合理编写YAML文件，你可以：

模块化：将不同功能的配置分离到不同的YAML文件中
使用标签：合理使用标签组织和管理资源
版本控制：将YAML文件纳入版本控制系统
环境分离：为不同环境（开发、测试、生产）创建不同的配置
配置验证：使用kubectl apply --dry-run验证配置
注释：添加适当的注释提高可读性
使用Helm：对于复杂应用，使用Helm管理配置模板

YAML文件不仅是配置工具，更是Kubernetes思想的体现。通过声明式配置实现自动化管理，让容器编排变得更加简单和可靠。

K3s组件安装与资源管理详解

K3s安装后包含的组件

当你安装K3s后，以下组件会被自动安装和启动：

核心组件

kube-apiserver：集群的API入口，处理所有API请求
kube-scheduler：负责Pod的调度
kube-controller-manager：管理各种控制器
kubelet：节点代理，管理容器生命周期
kube-proxy：网络代理，实现Service的负载均衡
containerd：容器运行时，负责容器的创建和管理

内置服务

CoreDNS：提供集群内部的DNS服务
Traefik：作为Ingress控制器，提供路由功能
Metrics Server：提供资源使用指标
Local Path Provisioner：提供本地存储卷支持
Flannel：容器网络插件，实现Pod间通信

存储

SQLite：默认的轻量级存储，适用于单节点部署
可选的外部存储：支持MySQL、PostgreSQL、etcd等

K3s启动的节点

当你安装K3s时，根据安装方式不同，会启动不同类型的节点：

单节点部署

Server节点：同时作为控制平面和工作节点
Agent节点：在单节点模式下，Server节点同时扮演Agent节点的角色

多节点部署

Server节点：负责控制平面功能，至少需要1个，高可用部署需要3个
Agent节点：负责运行容器，数量根据需求而定

为什么需要Deployment和Service

Deployment的作用

Deployment是Kubernetes中最常用的控制器，主要作用包括：

副本管理：确保指定数量的Pod副本运行
自愈能力：当Pod失败时自动重启或重建
滚动更新：支持无停机的应用更新
版本回滚：当更新失败时可以回滚到之前的版本
扩缩容：根据需求调整Pod数量

为什么需要Deployment？

直接创建Pod时，Pod失败后不会自动重建
无法实现滚动更新和版本回滚
无法方便地进行扩缩容

Service的作用

Service是Kubernetes中用于暴露应用的资源，主要作用包括：

稳定访问入口：为Pod提供固定的访问地址
负载均衡：在多个Pod副本之间分配流量
服务发现：通过服务名实现集群内部的服务发现
外部访问：通过NodePort、LoadBalancer等方式暴露服务

为什么需要Service？

Pod的IP地址是动态的，会随着Pod的创建和销毁而变化
无法直接在集群外部访问Pod
无法在多个Pod副本之间实现负载均衡

完整的应用部署流程

在K3s中部署一个应用的完整流程通常包括以下步骤：

创建Deployment：定义应用的运行方式、副本数量等
创建Service：为应用提供稳定的访问入口
可选：创建Ingress：提供更高级的路由和域名管理
可选：创建ConfigMap/Secret：管理应用配置

各个组件之间的关系

Deployment → Pod：Deployment管理Pod的生命周期
Service → Pod：Service通过标签选择器找到并访问Pod
Ingress → Service：Ingress将外部请求路由到Service
ConfigMap/Secret → Pod：为Pod提供配置信息

实际案例分析

Nginx部署流程

创建Deployment：
- 定义2个Nginx副本
- 指定容器镜像和端口
- 配置资源限制
创建Service：
- 选择NodePort类型，允许外部访问
- 配置端口映射
- 通过标签选择器关联到Deployment
访问服务：
- 通过http://<节点IP>:30080访问Nginx

最佳实践

使用Deployment管理应用：确保应用的高可用性和可维护性
为每个应用创建Service：提供稳定的访问方式
合理使用标签：便于资源管理和选择
使用命名空间：隔离不同环境的资源
配置资源限制：避免资源竞争

通过理解这些组件的作用和关系，你可以更有效地管理K3s集群和部署应用。

总结

K3s 作为 Kubernetes 的轻量版本，为边缘计算、IoT 设备和小型部署场景提供了理想的解决方案。它保留了 Kubernetes 的全部核心功能，同时通过优化和精简，实现了更低的资源占用和更简单的部署方式。

对于学习 Kubernetes 的初学者来说，K3s 是一个绝佳的起点。它提供了与标准 Kubernetes 完全相同的使用体验，但配置更简单、资源需求更低，让你能够更快地掌握容器编排的核心概念和实践技能。

在实际使用中，你可以根据具体场景的需求，灵活运用 K3s 的各种特性，构建适合自己的容器化解决方案。

K3s笔记1 ​

K3s 介绍 ​

K3s 和 Kubernetes（k8s）的区别 ​

K3s 和 K8s 技术详细对比 ​

K8s 和 K3s 节点上的区别 ​

K3s 架构和组件 ​

K3s 架构图 ​

节点 ​

K3s 单节点架构 ​

K3s 多节点架构（高可用架构） ​

组件 ​

Server 节点组件 ​

Agent 节点组件 ​

各个组件的通信流程 ​

安装K3s ​

常见问题与解决方案 ​

各个pods始终无法启动运行（pod 不是Running状态）的问题？ ​

k3s 初次安装K3s后各个Pod的介绍 ​

卸载K3s（彻底干净） ​

K3s 入门案例 - 部署Nginx 集群服务 ​

K3s YAML 文件详解 ​

YAML文件的作用 ​

YAML文件的基本结构 ​

如何编写YAML文件 ​

为什么要使用YAML文件 ​

YAML文件的总结 ​

K3s组件安装与资源管理详解 ​

K3s安装后包含的组件 ​

核心组件 ​

内置服务 ​

存储 ​

K3s启动的节点 ​

单节点部署 ​

多节点部署 ​

为什么需要Deployment和Service ​

Deployment的作用 ​

Service的作用 ​

完整的应用部署流程 ​

各个组件之间的关系 ​

实际案例分析 ​

Nginx部署流程 ​

最佳实践 ​

总结 ​

K3s笔记1

K3s 介绍

K3s 和 Kubernetes（k8s）的区别

K3s 和 K8s 技术详细对比

K8s 和 K3s 节点上的区别

K3s 架构和组件

K3s 架构图

节点

K3s 单节点架构

K3s 多节点架构（高可用架构）

组件

Server 节点组件

Agent 节点组件

各个组件的通信流程

安装K3s

常见问题与解决方案

各个pods始终无法启动运行（pod 不是Running状态）的问题？

k3s 初次安装K3s后各个Pod的介绍

卸载K3s（彻底干净）

K3s 入门案例 - 部署Nginx 集群服务

K3s YAML 文件详解

YAML文件的作用

YAML文件的基本结构

如何编写YAML文件

为什么要使用YAML文件

YAML文件的总结

K3s组件安装与资源管理详解

K3s安装后包含的组件

核心组件

内置服务

存储

K3s启动的节点

单节点部署

多节点部署

为什么需要Deployment和Service

Deployment的作用

Service的作用

完整的应用部署流程

各个组件之间的关系

实际案例分析

Nginx部署流程

最佳实践

总结