Linux运维：Docker、K8s与CI/CD实战
阶段四：运维与部署
一、Linux 基础操作
Linux 作为开源操作系统，核心操作依赖命令行终端，掌握基础命令是高效使用 Linux 的关键。以下从文件管理、目录操作、用户权限、系统管理、文件查看 / 编辑、软件管理 6 大核心模块，总结常用基础操作，附带语法，方便快速上手。
文件管理：创建、复制、移动、删除
文件是 Linux 系统的核心数据载体，以下命令覆盖文件全生命周期操作。
| 命令 | 功能 | 语法 | 示例 |
|---|---|---|---|
touch |
创建空文件 / 更新文件修改时间 | touch [文件名1] [文件名2]... |
touch note.txt（创建空文件）touch old.txt（更新 old.txt 的修改时间） |
cp |
复制文件 / 目录 |
复制文件：cp [源文件] [目标路径]复制目录（需 -r 递归）：cp -r [源目录] [目标路径] |
cp note.txt /home/user/（复制文件到指定目录）cp -r docs/ /backup/（复制 docs 目录到 backup） |
mv |
移动文件 / 目录 / 重命名 |
mv [源文件/目录] [目标路径/新名称] |
mv note.txt /tmp/（移动文件到 tmp 目录）mv old.txt new.txt（将 old.txt 重命名为 new.txt） |
rm |
删除文件 / 目录（谨慎使用，删除后难恢复） |
删除文件：rm [文件名]强制删除（忽略提示）：rm -f [文件名]删除目录（需 -r 递归）：rm -r [目录名] |
rm temp.txt（删除文件，会提示确认）rm -rf old_dir/（强制删除 old_dir 目录及所有内容） |
目录操作：切换、创建、查看、删除
Linux 采用树形目录结构（根目录为 /），目录操作是导航系统的基础。
| 命令 | 功能 | 语法 | 示例 |
|---|---|---|---|
cd |
切换当前工作目录 | cd [目标目录路径]（. 表示当前目录，.. 表示上级目录，~ 表示用户主目录） |
cd /home（切换到 /home 目录）cd ..（回到上级目录）cd ~（回到当前用户的主目录） |
pwd |
显示当前工作目录的绝对路径 | pwd（无额外参数） |
pwd → 输出：/home/user/docs |
mkdir |
创建目录 | 普通创建：mkdir [目录名]递归创建多级目录：mkdir -p [目录1/目录2] |
mkdir docs（在当前目录创建 docs 目录）mkdir -p a/b/c（创建 a 目录，且在 a 内创建 b，b 内创建 c） |
rmdir |
删除空目录（若目录有内容，需先删内容或用 rm -r） |
rmdir [空目录名] |
rmdir empty_dir（删除空目录 empty_dir） |
ls |
列出目录下的文件 / 目录 | 基础列表：ls详细信息（权限、大小、时间）：ls -l（可简写为 ll）显示隐藏文件（以 . 开头）：ls -a |
ls → 列出当前目录所有非隐藏文件 / 目录ll → 显示详细信息（如：-rw-r--r-- 1 user user 1024 Oct 5 14:30 note.txt）ls -a → 显示包括 .bashrc 在内的隐藏文件 |
用户与权限：控制文件访问权限
Linux 是多用户系统，权限机制确保不同用户对文件 / 目录的访问可控。权限分为三类：r（读，4）、w（写，2）、x（执行，1），对应所有者（user）、所属组（group）、其他用户（other）。
1. 查看权限
通过 ls -l 或 ll 查看文件 / 目录的权限，示例输出解析：
-rw-r--r-- 1 user group 1024 Oct 5 14:30 note.txt
# 权限位 所有者 所属组 大小 修改时间 文件名
# 第1位：-（文件）/ d（目录）；后9位分3组：所有者(rw-)、所属组(r--)、其他用户(r--)
2. 修改权限：chmod
-
符号法：
chmod [用户类型][+/-/=][权限] [文件/目录]用户类型：u（所有者）、g（所属组）、o（其他）、a（所有用户）示例：chmod u+x note.txt（给所有者增加执行权限）chmod g-w,o-r note.txt（给所属组移除写权限，给其他用户移除读权限）chmod a=rwx docs/（给所有用户赋予目录 docs 的读、写、执行权限）
-
数字法：用 3 位数字（分别对应 u、g、o 的权限和）表示，示例：
chmod 755 note.txt（u:7=rwx，g:5=rx，o:5=rx）chmod 700 private/（仅所有者有 rwx 权限，其他用户无任何权限）
3. 修改所有者 / 所属组：chown / chgrp
-
chown：修改文件 / 目录的所有者（需 root 权限，或所有者为当前用户）语法：chown [新所有者] [文件/目录]示例：sudo chown root note.txt（将 note.txt 的所有者改为 root） -
chgrp：修改文件 / 目录的所属组语法：chgrp [新所属组] [文件/目录]示例：chgrp devs docs/（将 docs 目录的所属组改为 devs）
系统管理：查看状态、进程控制
1. 查看系统信息
| 命令 | 功能 | 示例 |
|---|---|---|
uname |
查看系统内核信息 | uname -a（显示完整信息：内核版本、主机名、架构等） |
hostname |
查看 / 设置主机名 | hostname（查看主机名）sudo hostname new-host（临时设置主机名，重启失效） |
df |
查看磁盘空间使用情况 | df -h（-h 以人类可读格式显示：GB/MB） |
free |
查看内存使用情况 | free -h（显示总内存、已用、空闲等） |
top |
实时查看系统进程和资源占用（按 q 退出） |
top（默认按 CPU 占用排序，按 P 手动切换） |
2. 进程控制
进程是运行中的程序，通过以下命令管理：
-
ps：查看当前用户的进程（静态快照）语法：ps aux（a：所有用户进程，u：显示所有者，x：包括非终端进程）示例：ps aux | grep python（查看所有 python 相关进程） -
kill：终止进程（需知道进程 ID，即 PID，可通过ps或top获取）语法：kill [PID]（正常终止）、kill -9 [PID]（强制终止，无法恢复）示例：kill -9 1234（强制终止 PID 为 1234 的进程）
文件查看与编辑：读取、搜索内容
1. 查看文件内容（不修改）
| 命令 | 功能 | 语法 | 示例 |
|---|---|---|---|
cat |
一次性显示文件全部内容（适合小文件） | cat [文件名] |
cat note.txt（显示 note.txt 所有内容） |
more |
分页显示文件内容（按 Enter 下一行，q 退出） |
more [文件名] |
more large.log（分页查看大日志文件） |
less |
更灵活的分页查看（支持上下滚动、搜索，q 退出） |
less [文件名] |
less large.log（按 /关键词 搜索内容，按 n 找下一个） |
head |
显示文件前 N 行（默认前 10 行） | head -n [行数] [文件名] |
head -5 note.txt（显示 note.txt 前 5 行） |
tail |
显示文件后 N 行（默认后 10 行，常用于查看日志） | tail -n [行数] [文件名]tail -f [文件名]（实时跟踪文件新增内容，Ctrl+C 退出） |
tail -20 access.log（显示日志后 20 行）tail -f access.log（实时查看日志新增内容） |
2. 搜索文件内容：grep
在文件或命令输出中搜索关键词，支持正则表达式。语法：grep [选项] "关键词" [文件/目录]常用选项：
-i：忽略大小写-n：显示匹配行的行号-r：递归搜索目录下所有文件
示例：
grep "error" log.txt（在 log.txt 中搜索含 "error" 的行）grep -in "warning" /var/log/（递归搜索 /var/log 目录下所有文件，忽略大小写找含 "warning" 的行，并显示行号）
3. 简单文件编辑：nano
nano 是 Linux 自带的轻量文本编辑器，操作简单（适合新手）：
- 打开 / 创建文件：
nano [文件名]（如nano note.txt，若文件不存在则创建） - 编辑内容：直接输入文字即可（类似记事本）
- 保存退出：按
Ctrl+O（写入文件）→ 按Enter确认文件名 → 按Ctrl+X退出 - 放弃退出：按
Ctrl+X→ 按N确认不保存
软件管理：安装、卸载程序
不同 Linux 发行版（如 Ubuntu、CentOS）的软件包管理器不同，以下是两大主流体系：
1. Debian/Ubuntu 系列（apt 包管理器）
| 操作 | 命令 | 说明 |
|---|---|---|
| 更新软件源 | sudo apt update |
同步远程软件仓库的最新包信息（必须先执行，否则可能安装旧版本） |
| 安装软件 | sudo apt install [软件名] |
示例：sudo apt install firefox（安装火狐浏览器） |
| 卸载软件 | sudo apt remove [软件名] |
仅卸载软件，保留配置文件；若需彻底删除配置：sudo apt purge [软件名] |
| 升级已装软件 | sudo apt upgrade |
升级所有已安装的软件到最新版本 |
2. RedHat/CentOS 系列（yum 包管理器，CentOS 8+ 用 dnf）
| 操作 | 命令 | 说明 |
|---|---|---|
| 安装软件 | sudo yum install [软件名] |
示例：sudo yum install nginx（安装 Nginx 服务器） |
| 卸载软件 | sudo yum remove [软件名] |
示例：sudo yum remove nginx |
| 更新软件 | sudo yum update |
升级所有已安装软件 |
常用快捷键与技巧
- 命令补全：按
Tab键自动补全文件名 / 目录名 / 命令（输入前几个字符，按 Tab 即可），避免拼写错误。 - 命令历史：按
↑/↓键查看之前执行过的命令；用history命令查看所有历史命令，用!命令序号重复执行（如!100执行第 100 条历史命令）。 - 终止当前命令：按
Ctrl+C（若命令卡住或不需要继续执行）。 - 清屏：输入
clear或按Ctrl+L清空终端屏幕。 - 管道符
|：将前一个命令的输出作为后一个命令的输入，示例：ls -l | grep "txt"（列出当前目录文件，仅显示含 "txt" 的行）。
二、Docker
Docker 是一款开源的容器化平台，核心作用是将应用程序及其依赖（如库、配置文件、环境变量）打包成标准化的 “容器”，确保应用在任何支持 Docker 的环境中（开发机、测试机、服务器）都能 “一次构建，到处运行”，解决了传统开发中 “在我这能跑，在你那不行” 的环境一致性问题。
Docker 核心概念
理解以下 4 个核心概念是掌握 Docker 的基础，它们之间的关系可概括为：镜像（Image）是模板，容器（Container）是镜像的运行实例，仓库（Repository）是镜像的存储地址，Dockerfile 是构建镜像的 “说明书”。
| 概念 | 作用 | 类比 |
|---|---|---|
|
镜像 （Image） |
只读的模板，包含运行应用所需的代码、依赖、环境配置等（如 “Ubuntu 镜像”“Nginx 镜像”）。镜像不能直接运行，需基于它创建容器。 | 类似操作系统的 “ISO 安装包”（模板） |
| 容器（Container） | 镜像的运行实例（可读可写），是独立的应用运行环境。多个容器可基于同一镜像创建，且相互隔离（文件、网络、资源互不干扰）。 | 类似基于 ISO 安装好的 “操作系统实例”（可启动、停止、删除） |
| 仓库（Repository） | 存储镜像的远程服务器（类似代码仓库 GitHub），分为公开仓库（如官方的 Docker Hub）和私有仓库（企业内部自建）。 | 类似 “应用商店”（存储和分发镜像） |
| Dockerfile | 文本文件，包含一系列指令（如 “基于哪个基础镜像”“安装哪些软件”“执行哪些命令”），用于自动化构建自定义镜像。 | 类似 “食谱”（步骤明确，可重复生成相同镜像） |
Docker 核心命令（高频使用）
Docker 命令格式：docker [选项] [命令] [参数]，以下按 “镜像管理”“容器管理”“仓库交互” 分类总结。
1. 镜像管理：拉取、查看、构建、删除
| 命令 | 功能 | 语法 / 示例 |
|---|---|---|
docker pull |
从远程仓库拉取镜像（默认从 Docker Hub） | docker pull [镜像名:标签]（标签不写默认拉取 latest 最新版）示例：docker pull ubuntu:22.04（拉取 Ubuntu 22.04 镜像）docker pull nginx（拉取 Nginx 最新版镜像） |
docker images |
查看本地所有镜像 | docker images（显示镜像 ID、标签、大小等）docker images -q（仅显示镜像 ID，用于批量操作） |
docker build |
基于 Dockerfile 构建自定义镜像 | docker build -t [镜像名:标签] [Dockerfile 所在目录]（-t 给镜像打标签）示例：docker build -t my-nginx:v1 .（在当前目录 . 找 Dockerfile，构建名为 my-nginx、标签 v1 的镜像） |
docker rmi |
删除本地镜像（需先停止 / 删除基于该镜像的容器） | docker rmi [镜像名:标签] 或 docker rmi [镜像ID]示例：docker rmi ubuntu:22.04（删除指定镜像）docker rmi -f $(docker images -q)（强制 -f 删除所有本地镜像，谨慎使用） |
docker tag |
给镜像打新标签（不创建新镜像，仅添加别名） | docker tag [原镜像名:标签] [新镜像名:新标签]示例：docker tag my-nginx:v1 my-nginx:latest（给 my-nginx:v1 加 latest 标签） |
2. 容器管理：创建、启动、停止、进入、删除
容器是镜像的运行实例，核心操作围绕 “生命周期管理” 和 “交互” 展开。
（1）创建并启动容器（常用 docker run）
docker run 是最核心的容器命令，功能：若本地无指定镜像则先拉取，再创建并启动容器。
常用选项：
-i：保持容器标准输入（STDIN）打开，支持交互；-t：为容器分配伪终端（Terminal），常与-i组合为-it（进入容器交互模式）；-d：后台运行容器（守护模式，不占用当前终端）；-p：端口映射（将容器内端口映射到主机端口，格式：主机端口:容器端口）；-v：目录挂载（将主机目录挂载到容器内，实现文件共享，格式：主机目录:容器目录）；--name：给容器指定名称（默认自动生成随机名）。
示例：
- 启动交互式 Ubuntu 容器（退出后容器停止）：
docker run -it --name my-ubuntu ubuntu:22.04 /bin/bash # 进入容器后，可执行 Linux 命令（如 ls、cat），输入 exit 退出容器 - 后台启动 Nginx 容器（端口映射 8080→80，外部可通过主机 8080 访问 Nginx）：
docker run -d -p 8080:80 --name my-nginx nginx # 访问：浏览器输入 http://主机IP:8080，可看到 Nginx 欢迎页 - 启动 MySQL 容器（挂载主机目录存数据，设置 root 密码）：
docker run -d -p 3306:3306 -v /my/mysql/data:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=123456 --name my-mysql mysql:8.0 # -e：设置环境变量（MYSQL_ROOT_PASSWORD 是 MySQL 镜像的默认变量，用于设置 root 密码） # /my/mysql/data：主机目录，容器内 /var/lib/mysql 是 MySQL 数据存储路径，挂载后数据持久化（容器删除后数据不丢）
（2）查看容器状态
| 命令 | 功能 | 示例 |
|---|---|---|
docker ps |
查看运行中的容器 | docker ps（显示容器 ID、名称、端口映射等） |
docker ps -a |
查看所有容器（包括已停止的） | docker ps -a |
docker inspect |
查看容器详细信息（IP、挂载、环境变量等） | docker inspect my-nginx（查看 my-nginx 容器的详细配置） |
（3）启动 / 停止 / 重启容器
| 命令 | 功能 | 示例 |
|---|---|---|
docker start |
启动已停止的容器 | docker start my-ubuntu（启动名为 my-ubuntu 的容器） |
docker stop |
停止运行中的容器（优雅停止，类似关机） | docker stop my-nginx |
docker restart |
重启容器 | docker restart my-mysql |
docker kill |
强制停止容器（类似断电，不推荐，除非 stop 无效） | docker kill my-nginx |
（4）进入运行中的容器（交互）
当容器以 -d 后台运行时，需用 docker exec 进入容器交互模式：
# 格式：docker exec -it [容器名/ID] [命令]
docker exec -it my-nginx /bin/bash # 进入 my-nginx 容器，执行 bash 命令
docker exec -it my-mysql mysql -uroot -p # 直接进入 my-mysql 容器的 MySQL 命令行（需输入密码）
（5）删除容器
# 删除已停止的容器
docker rm my-ubuntu
# 强制删除运行中的容器（-f 强制）
docker rm -f my-nginx
# 删除所有已停止的容器
docker rm $(docker ps -a -q)
3. 仓库交互：推送镜像到远程仓库
若需将自定义镜像分享到 Docker Hub 或私有仓库，需先 “登录仓库”，再 “推送镜像”（镜像名需符合仓库命名规范：仓库地址/用户名/镜像名:标签）。
示例（推送到 Docker Hub）：
- 登录 Docker Hub（需先在 Docker Hub 注册账号）：
docker login # 输入用户名和密码，成功提示 "Login Succeeded" - 给镜像打符合规范的标签（以用户名
testuser、镜像名my-nginx为例）：docker tag my-nginx:v1 testuser/my-nginx:v1 - 推送镜像到 Docker Hub：
docker push testuser/my-nginx:v1 - 推送完成后，可在 Docker Hub 账号的 “Repositories” 中看到该镜像，其他人可通过
docker pull testuser/my-nginx:v1拉取。
Dockerfile 基础：构建自定义镜像
Dockerfile 是构建镜像的 “脚本”，通过指令定义镜像的层级（每一条指令对应一个镜像层，层可复用，提高构建效率）。以下是常用指令及一个完整示例。
1. 常用 Dockerfile 指令
| 指令 | 作用 | 示例 |
|---|---|---|
FROM |
指定基础镜像（必须是 Dockerfile 的第一条指令，除非用 ARG） | FROM ubuntu:22.04（基于 Ubuntu 22.04 构建）FROM nginx:latest（基于最新 Nginx 构建） |
WORKDIR |
设置容器启动后的默认工作目录（后续指令如 RUN、COPY 都在此目录执行） | WORKDIR /app（设置工作目录为 /app，若不存在则自动创建） |
COPY |
将主机文件 / 目录复制到镜像中（仅复制本地文件，不支持网络文件） | COPY index.html /usr/share/nginx/html/（将主机的 index.html 复制到 Nginx 默认网页目录） |
ADD |
类似 COPY，但支持自动解压压缩包、下载网络文件（功能更强，推荐优先用 COPY） | ADD app.tar.gz /app/（将主机的 app.tar.gz 复制到 /app 并自动解压） |
RUN |
在构建镜像时执行命令（如安装软件、配置环境，属于 “构建时” 指令） | RUN apt-get update && apt-get install -y python3（安装 Python3） |
CMD |
指定容器启动时执行的命令（每个 Dockerfile 仅最后一个 CMD 生效，属于 “运行时” 指令，可被 docker run 后的命令覆盖） |
CMD ["nginx", "-g", "daemon off;"]（Nginx 镜像默认 CMD，启动 Nginx 前台运行） |
EXPOSE |
声明容器运行时监听的端口（仅为文档说明，不实际映射，需配合 docker run -p 映射） |
EXPOSE 80（声明容器监听 80 端口） |
ENV |
设置环境变量（构建时和运行时都生效，容器内可通过 $变量名 引用） |
ENV APP_PORT=8080（设置环境变量 APP_PORT=8080） |
ARG |
定义构建时的变量（仅在构建过程中生效，构建完成后消失，可通过 docker build --build-arg 传值） |
ARG VERSION=1.0（定义变量 VERSION，默认值 1.0）构建时传值：docker build --build-arg VERSION=2.0 -t my-app:v2 . |
Docker 常用技巧与注意事项
-
容器数据持久化：容器默认是 “临时的”，删除后数据会丢失，需通过以下方式持久化数据：
- 用
docker run -v 主机目录:容器目录挂载主机目录（推荐，数据存在主机，容器删除不影响）； - 使用 Docker 数据卷（
docker volume create创建卷，挂载时用卷名替代主机目录，适合多容器共享数据）。
- 用
-
查看容器日志：后台运行的容器，可通过
docker logs查看输出日志：docker logs my-nginx # 查看 my-nginx 容器的所有日志 docker logs -f my-nginx # 实时跟踪日志（类似 tail -f） docker logs --tail 100 my-nginx # 查看最后 100 行日志 -
清理无用资源：Docker 运行久了会产生大量无用镜像、容器、卷，可通过以下命令清理：
# 清理停止的容器、无用的镜像、网络、卷（谨慎使用，会删除未使用的资源） docker system prune -a # 仅清理未使用的卷（需额外确认） docker volume prune -
注意权限问题：挂载主机目录时，容器内用户（如 Nginx 默认用
nginx用户）可能没有主机目录的读写权限，导致报错。解决方法：- 调整主机目录权限：
chmod 777 /my/nginx/html（简单但不安全，适合测试）；
- 调整主机目录权限：
三、Kubernetes（K8s）
Kubernetes（简称 K8s，因 "Kubernetes" 中间有 8 个字母而得名）是一个开源的容器编排平台，用于自动化部署、扩展和管理容器化应用程序。它解决了 Docker 等容器技术在大规模应用时面临的容器集群管理、服务发现、负载均衡、自动伸缩、故障恢复等问题，是容器化时代的核心基础设施。
K8s 核心概念与架构
1. 核心目标
K8s 的核心是为容器化应用提供一个稳定、可靠、可扩展的运行环境，通过声明式配置实现 "你定义目标状态，K8s 负责实现并维持这个状态"。
2. 基本架构（Master + Node 节点）
K8s 集群由两类节点组成：控制平面（Control Plane，即 Master 节点） 和工作节点（Node），节点通常是虚拟机或物理机。
（1）控制平面（Master 节点）：负责集群管理
| 组件 | 作用 |
|---|---|
| API Server | 所有操作的统一入口（通过 RESTful API 暴露），是 K8s 组件间通信的枢纽。 |
| etcd | 集群的 "数据库"，存储集群所有配置信息（键值对形式），强一致性、高可用。 |
| Scheduler | 调度器，负责根据节点资源（CPU、内存等）、亲和性规则等，将 Pod 分配到合适的 Node 上。 |
| Controller Manager | 运行各种控制器进程（如 Deployment 控制器、StatefulSet 控制器、Node 控制器等），确保集群状态与期望状态一致（如自动重启故障 Pod）。 |
| Cloud Controller Manager | （可选）对接云服务提供商的接口（如 AWS、GCP），管理云资源（如负载均衡、存储卷）。 |
（2）工作节点（Node）：运行容器化应用
| 组件 | 作用 |
|---|---|
| Kubelet | 运行在每个 Node 上的代理，确保容器（Pod 中的）按照 Pod 规格（Spec）运行，并向控制平面汇报节点和容器状态。 |
| Kube-proxy | 网络代理，运行在每个 Node 上，负责维护节点上的网络规则（如 Service 与 Pod 的端口映射、负载均衡），实现 Pod 间及外部与 Pod 的通信。 |
| 容器运行时（Container Runtime） | 负责运行容器的软件，如 Docker、containerd、CRI-O 等（K8s 通过 CRI 接口与运行时交互）。 |
3. 核心资源对象（K8s 中的 "数据实体"）
K8s 中所有内容都被抽象为 "资源对象"，通过 YAML 或 JSON 定义其 "期望状态"，常见核心资源如下：
| 资源对象 | 作用 | 核心特点 |
|---|---|---|
| Pod | 最小部署单元，包含一个或多个容器（共享网络和存储）。 | - 容器的 "包装器"，是 K8s 调度的最小单位- 生命周期短暂（重启会生成新 Pod，IP 可能变化）- 通常不直接创建 Pod，而是通过控制器管理 |
| Service | 定义 Pod 的访问方式，提供固定访问地址（IP: 端口），实现 Pod 切换时的服务连续性。 | - 为一组 Pod（通过标签选择器关联）提供稳定的网络端点- 自动实现 Pod 间的负载均衡- 类型：ClusterIP（仅集群内访问）、NodePort（暴露节点端口）、LoadBalancer（对接云负载均衡） |
| Deployment | 最常用的控制器，用于管理无状态应用，支持滚动更新、回滚等。 | - 声明式管理 Pod 和 ReplicaSet（确保指定数量的 Pod 副本运行）- 支持 "滚动更新"（不中断服务）和 "回滚" 到历史版本- 适合无状态应用（如 Web 服务） |
| StatefulSet | 管理有状态应用（如数据库），确保 Pod 名称、网络标识、存储的稳定性。 | - 每个 Pod 有固定名称（如 web-0、web-1）和网络标识- 存储与 Pod 绑定（删除 Pod 后存储保留）- 支持有序部署、扩展和更新 |
| ConfigMap/Secret | 存储配置信息（ConfigMap 存明文，Secret 存敏感信息如密码）。 | - 与 Pod 解耦，避免配置硬编码到镜像或 Pod 定义中- 可通过环境变量或文件挂载到 Pod 中 |
| Namespace | 实现集群内资源的逻辑隔离（如开发、测试、生产环境分离）。 | - 不同 Namespace 中的资源名称可重复- 默认 Namespace 为 default |
| Volume | 定义 Pod 中的存储，解决容器内数据临时存储的问题。 | - 生命周期与 Pod 一致（Pod 删除，普通 Volume 数据丢失）- 支持多种类型：emptyDir（临时目录）、hostPath（主机目录）、PersistentVolume（持久卷）等 |
| PersistentVolume(PV)/ PersistentVolumeClaim (PVC) | 持久化存储的抽象，PV 是集群级别的存储资源，PVC 是 Pod 对存储的请求。 | - 解耦存储提供者（管理员）和使用者（开发人员）- PV 与 PVC 通过 "存储类（StorageClass）" 动态绑定 |
K8s 核心操作（kubectl 命令）
kubectl 是 K8s 的命令行工具，用于与 API Server 交互，管理集群资源。命令格式：kubectl [命令] [资源类型] [资源名称] [选项]。
1. 集群信息查看
# 查看集群信息（控制平面地址、版本等）
kubectl cluster-info
# 查看节点列表（包括状态、角色、资源使用情况）
kubectl get nodes
kubectl get nodes -o wide # 显示更多信息（如节点 IP）
# 查看节点详细信息（如标签、污点）
kubectl describe node <节点名称>
2. 资源对象管理（以 Deployment、Pod、Service 为例）
（1）创建资源（通过 YAML 文件）
创建一个简单的 Nginx 部署示例（nginx-deploy.yaml）：
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deploy # Deployment 名称
labels:
app: nginx
spec:
replicas: 2 # 期望的 Pod 副本数
selector:
matchLabels:
app: nginx # 关联标签为 app:nginx 的 Pod
template:
metadata:
labels:
app: nginx # Pod 的标签
spec:
containers:
- name: nginx
image: nginx:latest # 容器镜像
ports:
- containerPort: 80 # 容器内端口
执行创建命令：
kubectl apply -f nginx-deploy.yaml
（2）查看资源
# 查看 Deployment 列表
kubectl get deployments
kubectl get deploy nginx-deploy # 查看指定 Deployment
# 查看 Pod 列表（-o wide 显示节点、IP 等信息）
kubectl get pods
kubectl get pods -o wide
# 查看 Service 列表
kubectl get services
kubectl get svc # 简写
# 查看所有资源（按 Namespace 分组）
kubectl get all -n <namespace名称> # 不指定 -n 则默认 default
（3）查看资源详情
# 查看 Pod 详细信息（事件、容器日志、挂载等）
kubectl describe pod <pod名称>
# 查看 Deployment 详情（更新策略、历史版本等）
kubectl describe deploy nginx-deploy
（4）创建 Service 暴露应用
创建 nginx-svc.yaml 暴露 Nginx 服务：
apiVersion: v1
kind: Service
metadata:
name: nginx-svc
spec:
selector:
app: nginx # 关联标签为 app:nginx 的 Pod
ports:
- port: 8080 # Service 暴露的端口
targetPort: 80 # 映射到 Pod 的端口
type: NodePort # 类型为 NodePort（集群外可通过节点 IP:端口访问）
创建并查看：
kubectl apply -f nginx-svc.yaml
kubectl get svc nginx-svc # 输出中 NodePort 字段显示暴露的节点端口（如 30080）
此时，可通过 节点IP:NodePort（如 192.168.1.100:30080）访问 Nginx 服务。
（5）进入 Pod 容器
# 格式：kubectl exec -it <pod名称> -c <容器名称> -- <命令>
kubectl exec -it nginx-deploy-7f89d65f4d-2xqk9 -- /bin/bash # 进入 Nginx Pod 的 bash
（6）查看 Pod 日志
# 查看 Pod 日志（-f 实时跟踪）
kubectl logs <pod名称>
kubectl logs -f <pod名称> -c <容器名称> # 若 Pod 有多个容器，需指定容器名
（7）更新资源（修改 YAML 后重新应用）
# 修改 nginx-deploy.yaml 中的 replicas 为 3（扩展副本数），然后执行：
kubectl apply -f nginx-deploy.yaml
# 或直接用命令更新（如修改镜像版本）
kubectl set image deployment/nginx-deploy nginx=nginx:1.23
（8）删除资源
# 通过 YAML 文件删除
kubectl delete -f nginx-deploy.yaml
kubectl delete -f nginx-svc.yaml
# 直接删除指定资源
kubectl delete deploy nginx-deploy
kubectl delete svc nginx-svc
kubectl delete pod <pod名称>
3. 其他常用命令
# 查看 Namespace
kubectl get namespaces
kubectl create namespace <ns名称> # 创建 Namespace
# 切换默认 Namespace（需安装 kubens 工具）
kubens <ns名称>
# 回滚 Deployment 到上一版本
kubectl rollout undo deployment/nginx-deploy
# 查看 Deployment 历史版本
kubectl rollout history deployment/nginx-deploy
# 暂停/恢复 Deployment 更新
kubectl rollout pause deployment/nginx-deploy
kubectl rollout resume deployment/nginx-deploy
三、K8s 核心功能场景
1. 服务发现与负载均衡
- 通过 Service 为 Pod 提供固定访问地址，自动关联标签匹配的 Pod。
- 当 Pod 因故障重启或扩缩容时，Service 会自动更新关联的 Pod 列表，实现无缝切换和负载均衡。
2. 自动扩缩容（HPA）
Horizontal Pod Autoscaler（HPA）可根据 CPU 使用率、内存使用率或自定义指标自动调整 Pod 副本数。
示例：创建 HPA 使 Nginx 副本数在 2-10 之间，基于 CPU 使用率（目标 50%）自动伸缩：
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: nginx-hpa
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: nginx-deploy
minReplicas: 2
maxReplicas: 10
metrics:
- type: Resource
resource:
name: cpu
target:
type: Utilization
averageUtilization: 50
应用后，当 Pod 平均 CPU 使用率超过 50% 时，HPA 会自动增加副本数；低于阈值时则减少。
3. 滚动更新与回滚
- 滚动更新：Deployment 会逐步替换旧 Pod（先创建新 Pod，再删除旧 Pod），确保服务不中断。
- 回滚：若更新后出现问题，可通过
kubectl rollout undo快速回滚到之前的稳定版本。
4. 配置管理与密钥
- ConfigMap：存储非敏感配置（如应用参数），可通过环境变量或文件挂载到 Pod。
- Secret：存储敏感信息（如数据库密码），数据会被 Base64 编码（注意：并非加密，生产环境需配合外部密钥管理工具）。
四、CI/CD（Jenkins、GitHub Actions）
CI/CD 是自动化软件交付的核心流程，能大幅减少手动操作、降低出错率，让代码从 “开发完成” 到 “上线运行” 更高效。先理清基础概念，再聚焦 Jenkins 和 GitHub Actions 两大工具的核心用法。
先懂 CI/CD：核心概念
- CI（持续集成）：开发者频繁将代码提交到代码仓库（如 Git），工具自动触发 “代码检查、编译、测试”，提前发现错误（比如语法错、测试用例失败）。目标：避免 “代码合并时发现大量冲突 /bug”，保证代码随时可集成。
- CD（持续交付 / 部署）：
- 持续交付（Delivery）：CI 通过后，自动将代码打包成可部署的产物（如 Jar 包、Docker 镜像），手动触发 “上线”；
- 持续部署（Deployment）：产物打包后，全自动部署到目标环境（测试 / 生产），无需手动干预。目标：缩短 “代码到上线” 的周期，实现 “一键 / 自动上线”。
工具 1：Jenkins（老牌 CI/CD 工具）
Jenkins 是开源、可扩展的 CI/CD 平台，通过 “插件” 支持几乎所有开发工具（Git、Maven、Docker、K8s 等），适合复杂、定制化的自动化流程。
1. 核心优势
- 插件生态极丰富（超过 1800 个插件），能对接任何你用的工具；
- 支持分布式构建（多台机器一起跑任务，提速）；
- 适合大型团队、复杂项目（如多环境部署、多步骤流水线）。
2. 核心概念
- 流水线（Pipeline）：将 CI/CD 流程（拉代码→编译→测试→打包→部署）用代码定义（Jenkinsfile），可提交到 Git 仓库，实现 “流程即代码”。
- 任务（Job）：Jenkins 中最小的执行单元，早期用 “自由风格任务”，现在推荐用 “流水线任务”（更灵活）。
- 节点（Node）：执行任务的机器（Jenkins 主节点 + 从节点，从节点用于分担主节点压力）。
3. 关键操作（核心流程）
以 “Java 项目 CI/CD” 为例，步骤如下：
-
安装 Jenkins：用 Docker 快速启动（推荐）：
docker run -d -p 8080:8080 -p 50000:50000 -v jenkins_data:/var/jenkins_home jenkins/jenkins:lts访问
http://服务器IP:8080，按提示输入初始密码、安装基础插件（如 Git、Pipeline、Maven 插件）。 -
配置工具：在 Jenkins 后台（“全局工具配置”）添加：
- Git（拉代码用）；
- Maven/Gradle（编译 Java 项目用）；
- Docker（打包镜像用，若需）。
-
写 Jenkinsfile（定义流水线）：在代码仓库根目录创建
Jenkinsfile，示例（Java 项目 CI 流程）：pipeline { agent any // 在任意可用节点执行 stages { // 1. 拉取代码 stage('拉取代码') { steps { git url: 'https://github.com/your-name/your-java-project.git', branch: 'main' } } // 2. 编译代码 stage('编译打包') { steps { sh 'mvn clean package -DskipTests' // Maven 编译，跳过测试（快速演示） } } // 3. 运行测试 stage('单元测试') { steps { sh 'mvn test' } } // 4. （可选）打包 Docker 镜像 stage('构建镜像') { steps { sh 'docker build -t my-java-app:${BUILD_NUMBER} .' } } } } -
创建流水线任务：
- Jenkins 后台→“新建任务”→选 “流水线”→配置 “流水线来源” 为 “Git”，填写仓库地址和
Jenkinsfile路径； - 点击 “立即构建”，Jenkins 会自动拉取代码、执行
Jenkinsfile中的步骤，在 “控制台输出” 查看进度。
- Jenkins 后台→“新建任务”→选 “流水线”→配置 “流水线来源” 为 “Git”，填写仓库地址和
工具 2：GitHub Actions（轻量 CI/CD 工具）
GitHub Actions 是 GitHub 内置的 CI/CD 工具，无需单独部署服务器，直接关联 GitHub 仓库，适合中小型项目、开源项目，配置简单。
1. 核心优势
- 零部署：GitHub 自带，无需搭建服务器；
- 与 GitHub 深度集成：代码提交 / PR/Tag 等事件可直接触发流程（如 “推代码到 main 分支自动跑测试”）；
- 配置简单：用 YAML 文件定义流程，语法直观，社区有大量现成 “动作（Action）” 可复用。
2. 核心概念
- 工作流（Workflow）：一个完整的 CI/CD 流程（如 “测试流程”“部署流程”），用 YAML 文件定义，存放在仓库的
.github/workflows/目录下。 - 事件（Event）：触发工作流的条件（如
push（代码推送）、pull_request（PR 提交）、schedule（定时触发））。 - 作业（Job）：工作流中的执行单元，一个工作流可包含多个作业（默认并行执行，可配置依赖），每个作业跑在一个 “运行器（Runner）” 上。
- 步骤（Step）：作业的细分步骤，每个步骤可执行 “命令” 或调用 “动作（Action）”。
- 动作（Action）：可复用的代码片段（如 “拉取代码”“设置 Java 环境”“推送 Docker 镜像”），社区有大量现成 Action（在 GitHub Marketplace 查找）。
3. 关键操作（核心流程）
以 “Node.js 项目 CI + 自动部署到 GitHub Pages” 为例：
-
创建工作流文件：在代码仓库根目录创建目录
.github/workflows/，并新建文件ci-deploy.yml。 -
编写 YAML 配置：示例（代码推送触发测试，测试通过后部署到 GitHub Pages）：
# 工作流名称 name: Node.js CI & Deploy to Pages # 触发条件：推代码到 main 分支，或 PR 到 main 分支 on: push: branches: [ main ] pull_request: branches: [ main ] # 定义作业 jobs: # 作业1：测试（跑单元测试） test: runs-on: ubuntu-latest # 用 Ubuntu 运行器 steps: # 步骤1：拉取代码（复用官方 Action） - uses: actions/checkout@v4 # 步骤2：设置 Node.js 环境（复用官方 Action，指定版本） - name: Set up Node.js uses: actions/setup-node@v4 with: node-version: '18' cache: 'npm' # 缓存 npm 依赖，加速下次构建 # 步骤3：安装依赖 - name: Install dependencies run: npm ci # 步骤4：运行测试 - name: Run tests run: npm test # 作业2：部署到 GitHub Pages（依赖 test 作业，test 通过才执行） deploy: needs: test # 依赖 test 作业 runs-on: ubuntu-latest # 只在 main 分支推送时执行（PR 不部署） if: github.ref == 'refs/heads/main' steps: - uses: actions/checkout@v4 - name: Set up Node.js uses: actions/setup-node@v4 with: node-version: '18' cache: 'npm' # 步骤：构建项目（比如 React/Vue 项目打包） - name: Build run: | npm ci npm run build # 打包产物在 dist 目录 # 步骤：部署到 GitHub Pages（复用现成 Action） - name: Deploy to GitHub Pages uses: peaceiris/actions-gh-pages@v4 with: github_token: ${{ secrets.GITHUB_TOKEN }} # GitHub 自动生成的令牌，无需手动配置 publish_dir: ./dist # 要部署的目录（打包后的产物目录） -
提交配置并触发：将
.github/workflows/ci-deploy.yml提交到 GitHub 仓库，当你：- 推代码到
main分支：自动触发test作业，测试通过后触发deploy作业，部署到 GitHub Pages； - 提交 PR 到
main分支：仅触发test作业，不部署（避免影响线上）。在 GitHub 仓库的 “Actions” 标签页可查看工作流运行状态和日志。
- 推代码到
Jenkins vs GitHub Actions：怎么选？
| 对比维度 | Jenkins | GitHub Actions |
|---|---|---|
| 部署成本 | 需自己搭服务器（或用 Docker），需维护 | 零部署，GitHub 自带 |
| 集成友好度 | 支持所有代码仓库（GitLab、GitHub 等） | 仅支持 GitHub 仓库（深度集成） |
| 复杂度 / 灵活性 | 配置复杂，适合定制化、复杂流程 | 配置简单，适合标准、轻量流程 |
| 生态 | 插件极多，支持所有工具 | Action 丰富，满足多数场景 |
| 团队 / 项目场景 | 大型团队、多仓库、复杂部署流程 | 中小型团队、开源项目、GitHub 单仓库 |
结论：
- 若代码存在 GitHub，且流程不复杂：选 GitHub Actions（快、省事儿）；
- 若代码在 GitLab/Gitee，或需要复杂定制（如多环境部署、分布式构建）：选 Jenkins。
码道开发者社区，聚焦华为云码道 CodeArts 代码智能体，沉淀 Agent、Skill、鸿蒙开发实战内容，供开发者查阅资料、交流技术、分享工程实践
更多推荐
16
0- 0
已为社区贡献2条内容
所有评论(0)