Li的学习之路

 Li的学习之路

发表于 更新于 分类于
详细介绍Kubernetes中的核心概念Pod、Deployment、StatefulSet、DaemonSet、Service、Ingress等，以及相应的kubectl管理命令

🚀 Kubernetes核心概念详解

📦 Pod - 最小部署单元

概念：Kubernetes中最小的可部署计算单元，封装一个或多个共享网络和存储的容器。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 创建pod
kubectl run <pod-name> --image=<image-name>
# 查看pod列表
kubectl get pods
# 查看pod详情
kubectl describe pod <pod-name>
# 删除pod
kubectl delete pod <pod-name>
# 查看pod日志
kubectl logs <pod-name>
# 进入pod容器
kubectl exec -it <pod-name> -- /bin/sh
# 查看pod资源使用
kubectl top pod

🎮 Deployment - Pod管理器

概念：管理Pod副本，提供自愈、扩缩容、滚动更新和回滚能力。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# 创建deployment
kubectl create deployment <deployment-name> --image=<image-name>
# 查看deployment列表
kubectl get deployments
# 扩缩容副本数
kubectl scale deployment <deployment-name> --replicas=<number>
# 更新镜像版本
kubectl set image deployment/<deployment-name> <container-name>=<new-image>
# 查看更新状态
kubectl rollout status deployment/<deployment-name>
# 回滚版本
kubectl rollout undo deployment/<deployment-name>
# 删除deployment
kubectl delete deployment <deployment-name>

🎯 StatefulSet - 有状态应用管理

概念：管理有状态应用，保证Pod标识、网络、存储的稳定性。

1
2
3
4
5
6
# 查看statefulset列表
kubectl get statefulsets
# 扩缩容副本数
kubectl scale statefulset <statefulset-name> --replicas=<number>
# 删除statefulset
kubectl delete statefulset <statefulset-name>

🔄 DaemonSet - 节点守护进程

概念：在每个节点上运行一个Pod副本，适合日志收集、监控等系统级任务。

1
2
3
4
# 查看daemonset列表
kubectl get daemonsets
# 删除daemonset
kubectl delete daemonset <daemonset-name>

🔗 Service - 服务发现与负载均衡

概念：为Pod提供稳定的网络访问入口，支持服务发现和负载均衡。

1
2
3
4
5
6
7
8
9
10
# 创建service
kubectl expose deployment <deployment-name> --type=<service-type> --port=<port>
# 查看service列表
kubectl get services
# 查看service详情
kubectl describe service <service-name>
# 删除service
kubectl delete service <service-name>
# 查看端点
kubectl get endpoints

🌐 Ingress - HTTP路由规则

概念：配置HTTP/HTTPS路由规则，将外部流量路由到集群内部服务。

1
2
3
4
5
6
7
8
# 创建ingress
kubectl create ingress <ingress-name> --rule=<host>/<path>=<service>:<port>
# 查看ingress列表
kubectl get ingress
# 查看ingress详情
kubectl describe ingress <ingress-name>
# 删除ingress
kubectl delete ingress <ingress-name>

🛠️ 通用管理命令

配置文件管理

1
2
3
4
5
6
7
8
# 应用配置文件
kubectl apply -f <filename.yaml>
# 删除配置文件中的资源
kubectl delete -f <filename.yaml>
# 查看资源配置
kubectl get -o yaml <resource-type> <resource-name>
# 查看所有资源
kubectl get all

命名空间管理

1
2
3
4
5
6
7
8
# 查看命名空间
kubectl get namespaces
# 创建命名空间
kubectl create namespace <namespace-name>
# 设置默认命名空间
kubectl config set-context --current --namespace=<namespace-name>
# 删除命名空间
kubectl delete namespace <namespace-name>

故障排查

1
2
3
4
5
6
7
8
9
10
# 查看事件
kubectl get events
# 实时跟踪日志
kubectl logs -f <pod-name>
# 在pod中执行命令
kubectl exec -it <pod-name> -- <command>
# 查看节点资源使用
kubectl top nodes
# 查看pod资源使用
kubectl top pods

节点管理

1
2
3
4
5
6
7
8
# 查看节点
kubectl get nodes
# 标记节点不可调度
kubectl cordon <node-name>
# 恢复节点调度
kubectl uncordon <node-name>
# 驱逐节点上的pod
kubectl drain <node-name>

📝 文档说明

本文档整理了Kubernetes的核心概念和常用命令，涵盖了从基础的Pod管理到高级的服务发现和路由配置。所有命令都遵循小写命令、大写参数的规范，便于在实际工作中快速查阅和使用。

核心概念总结

  • Pod：最小部署单元，容器编排的基础
  • Deployment：无状态应用管理，支持滚动更新和回滚
  • StatefulSet：有状态应用管理，保证稳定标识和存储
  • DaemonSet：节点级守护进程，确保每个节点运行副本
  • Service：服务发现和负载均衡，提供稳定访问入口
  • Ingress：HTTP路由规则，管理外部流量访问

发表于 更新于 分类于
详细介绍Kubernetes中ConfigMap和Secret的使用方法，包括创建方式、注入机制和实际应用示例

ConfigMap配置管理 🔧

ConfigMap概述 💡

  • 概念: ConfigMap是Kubernetes中用于存储非敏感配置数据的API对象，以键值对形式存储配置信息
  • 实现: 提供了向Pod注入配置数据的标准方法，实现镜像与配置的解耦，提升应用的可移植性和可复用性

ConfigMap典型使用场景 🎯

  • 概念: ConfigMap在实际应用中的主要用途
  • 实现:
    • 填充环境变量的值
    • 设置容器内的命令行参数
    • 填充卷的配置文件

ConfigMap创建方式 🛠️

1. 使用字面值创建

1
kubectl create configmap my-config --from-literal=key1=config1 --from-literal=key2=config2

2. 使用文件创建

1
kubectl create configmap my-config --from-file=path/to/bar

3. 使用目录创建

1
kubectl create configmap my-config --from-file=path/to/bar

4. 编写YAML文件创建

通过定义完整的YAML清单文件来创建ConfigMap对象

1
2
3
4
5
6
7
8
apiVersion: v1 # API版本，指定使用的Kubernetes API版本
kind: ConfigMap # 资源类型，声明为ConfigMap对象
metadata: # 元数据，包含资源的名称、命名空间等信息
  name: my-config # ConfigMap的名称
  namespace: default # 所属命名空间
data: # 配置数据，以键值对形式存储
  key1: config1 # 配置键值对1
  key2: config2 # 配置键值对2

ConfigMap注入方式 🚀

1. 环境变量方式

通过spec.env或spec.envFrom进行引用配置数据

2. 卷挂载方式

通过spec.volumes引用，将ConfigMap挂载到容器内部的文件或目录

环境变量注入示例 📝

使用spec.env方式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
apiVersion: v1 # API版本，指定使用的Kubernetes API版本
kind: Pod # 资源类型，声明为Pod对象
metadata: # 元数据，包含资源的名称、命名空间等信息
  name: cm-pod-test001 # Pod的名称
spec: # Pod规格，定义Pod的配置
  containers: # 容器列表
    - name: cm-test # 容器名称
      image: tomcat:8 # 容器镜像
      command: ["/bin/sh", "-c", "env | grep APP"] # 容器启动命令
      env: # 环境变量配置
        - name: APPCONF01 # 环境变量名称
          valueFrom: # 值来源配置
            configMapKeyRef: # ConfigMap键引用
              name: cm-test01 # ConfigMap名称
              key: appconf01 # ConfigMap中的键名
        - name: APPCONF02 # 环境变量名称
          valueFrom: # 值来源配置
            configMapKeyRef: # ConfigMap键引用
              name: cm-test01 # ConfigMap名称
              key: appconf02 # ConfigMap中的键名

使用spec.envFrom方式

1
2
3
4
5
6
7
8
9
10
11
12
apiVersion: v1 # API版本，指定使用的Kubernetes API版本
kind: Pod # 资源类型，声明为Pod对象
metadata: # 元数据，包含资源的名称、命名空间等信息
  name: cm-pod-test002 # Pod的名称
spec: # Pod规格，定义Pod的配置
  containers: # 容器列表
    - name: cm-test2 # 容器名称
      image: tomcat:8 # 容器镜像
      command: ["/bin/sh", "-c", "env"] # 容器启动命令
      envFrom: # 环境变量来源配置
        - configMapRef: # ConfigMap引用
            name: cm-test01 # ConfigMap名称，所有键值对都会作为环境变量注入

Volume挂载示例 📁

指定items的方式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
apiVersion: v1 # API版本，指定使用的Kubernetes API版本
kind: Pod # 资源类型，声明为Pod对象
metadata: # 元数据，包含资源的名称、命名空间等信息
  name: cm-pod-test003 # Pod的名称
spec: # Pod规格，定义Pod的配置
  containers: # 容器列表
    - name: cm-test3 # 容器名称
      image: tomcat:8 # 容器镜像
      volumeMounts: # 卷挂载配置
        - name: vm-01-1 # 卷名称，与volumes中的name对应
          mountPath: /conf # 挂载路径，容器内的目录路径
  volumes: # 卷定义列表
    - name: vm-01-1 # 卷名称
      configMap: # ConfigMap卷配置
        name: cm-test-file # ConfigMap名称
        items: # 指定要挂载的键值对
          - key: key-testproperties # ConfigMap中的键名
            path: test.properties # 挂载后的文件名

不指定items的方式

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
apiVersion: v1 # API版本，指定使用的Kubernetes API版本
kind: Pod # 资源类型，声明为Pod对象
metadata: # 元数据，包含资源的名称、命名空间等信息
  name: cm-pod-test004 # Pod的名称
spec: # Pod规格，定义Pod的配置
  containers: # 容器列表
    - name: cm-test4 # 容器名称
      image: tomcat:8 # 容器镜像
      volumeMounts: # 卷挂载配置
        - name: vm-02-2 # 卷名称，与volumes中的name对应
          mountPath: /conf # 挂载路径，容器内的目录路径
  volumes: # 卷定义列表
    - name: vm-02-2 # 卷名称
      configMap: # ConfigMap卷配置
        name: cm-test-file # ConfigMap名称，所有键值对都会被挂载

Secret密文管理 🔒

Secret概述 🔐

  • 概念: Secret对象与ConfigMap对象类似，专门用于存储敏感信息
  • 实现: 主要存储密码、OAuth token和SSH key等敏感数据，比直接存储在Pod定义或Docker镜像中更加安全和灵活

Secret类型 🏷️

1. Opaque类型

  • 特点: 使用base64编码存储信息
  • 安全性: 可以通过base64 --decode解码获得原始数据，安全性相对较弱

2. kubernetes.io/dockerconfigjson类型

  • 用途: 专门用于存储docker registry的认证信息

3. kubernetes.io/service-account-token类型

  • 用途: 用于被serviceaccount引用的服务账号令牌

Secret创建方式 🛠️

1. 从文件中创建Secret

1
2
3
echo -n "admin" > ./username.txt
echo -n "123456" > ./password.txt
kubectl create secret generic db-user-pass --from-file=./username.txt --from-file=./password.txt

2. 使用描述文件创建Secret

首先进行base64编码：

1
2
echo -n 'name' | base64
echo -n '123456' | base64

然后创建secret.yaml文件：

1
2
3
4
5
6
7
8
apiVersion: v1 # API版本，指定使用的Kubernetes API版本
kind: Secret # 资源类型，声明为Secret对象
metadata: # 元数据，包含资源的名称、命名空间等信息
  name: mysecret # Secret的名称
type: Opaque # Secret类型，Opaque表示通用类型
data: # 敏感数据，以base64编码的键值对形式存储
  username: bmFtZQ== # 用户名，base64编码后的值
  password: MTIzNDU2 # 密码，base64编码后的值

Secret注入方式 🚀

1. 将Secret挂载到Volume中

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
apiVersion: v1 # API版本，指定使用的Kubernetes API版本
kind: Pod # 资源类型，声明为Pod对象
metadata: # 元数据，包含资源的名称、命名空间等信息
  name: mypod # Pod的名称
spec: # Pod规格，定义Pod的配置
  containers: # 容器列表
    - name: mypod # 容器名称
      image: redis # 容器镜像
      volumeMounts: # 卷挂载配置
        - name: foo # 卷名称，与volumes中的name对应
          mountPath: "/etc/foo" # 挂载路径，容器内的目录路径
          readOnly: true # 只读挂载，增强安全性
  volumes: # 卷定义列表
    - name: foo # 卷名称
      secret: # Secret卷配置
        secretName: mysecret # Secret名称

2. 将Secret设置为环境变量

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
apiVersion: v1 # API版本，指定使用的Kubernetes API版本
kind: Pod # 资源类型，声明为Pod对象
metadata: # 元数据，包含资源的名称、命名空间等信息
  name: secret-env-pod # Pod的名称
spec: # Pod规格，定义Pod的配置
  containers: # 容器列表
    - name: mycontainer # 容器名称
      image: redis # 容器镜像
      env: # 环境变量配置
        - name: SECRET_USERNAME # 环境变量名称
          valueFrom: # 值来源配置
            secretKeyRef: # Secret键引用
              name: mysecret # Secret名称
              key: username # Secret中的键名
        - name: SECRET_PASSWORD # 环境变量名称
          valueFrom: # 值来源配置
            secretKeyRef: # Secret键引用
              name: mysecret # Secret名称
              key: password # Secret中的键名

ConfigMap热更新机制 🔄

更新特性说明 ⚡

  • Volume挂载方式: 可以感知配置变化（延迟几秒到一分钟左右）
  • 环境变量方式: 不会自动更新，需要重启Pod才能生效

使用建议 💡

  • 频繁变化的配置: 推荐使用Volume挂载方式
  • 固定配置: 可以使用环境变量注入方式

实际应用示例 🎯

MySQL密码注入Pod示例 🗄️

1. 创建Secret

1
kubectl create secret generic test --from-literal=MYSQL_ROOT_PASSWORD=1234567

2. 创建Deployment

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
apiVersion: apps/v1 # API版本，指定使用的Kubernetes API版本
kind: Deployment # 资源类型，声明为Deployment对象
metadata: # 元数据，包含资源的名称、命名空间等信息
  name: myapp-demo # Deployment的名称
  namespace: default # 所属命名空间
spec: # Deployment规格，定义Deployment的配置
  replicas: 1 # 副本数量
  selector: # 选择器，用于匹配Pod
    matchLabels: # 标签匹配规则
      app: myapp # 匹配标签为app=myapp的Pod
  template: # Pod模板，定义Pod的配置
    metadata: # Pod元数据
      labels: # Pod标签
        app: myapp # Pod的标签
    spec: # Pod规格
      containers: # 容器列表
        - name: myapp # 容器名称
          image: ikubernetes/myapp:v1 # 容器镜像
          imagePullPolicy: IfNotPresent # 镜像拉取策略
          ports: # 端口配置
            - name: http # 端口名称
              containerPort: 80 # 容器端口
          volumeMounts: # 卷挂载配置
            - name: mysql # 卷名称，与volumes中的name对应
              mountPath: /test/ # 挂载路径，容器内的目录路径
      volumes: # 卷定义列表
        - name: mysql # 卷名称
          secret: # Secret卷配置
            secretName: test # Secret名称

注意事项 ⚠️

  • 安全性: Secret虽然使用base64编码，但并非真正的加密，敏感信息仍需谨慎处理
  • 性能: ConfigMap和Secret都有大小限制，不宜存储过大的配置文件
  • 更新策略: 根据配置变化频率选择合适的注入方式
  • 权限管理: 合理设置RBAC权限，控制ConfigMap和Secret的访问范围
    通过合理使用ConfigMap和Secret，可以实现Kubernetes应用的配置与镜像分离，提升应用的可维护性和安全性 🚀

发表于 更新于 分类于
系统介绍云计算专业学习路径、方法以及常用学习交流平台

云计算专业学习方法 🚀

一、夯实底层基础 🏗️

云计算构建于 Linux 操作系统与计算机网络之上。需深入掌握 Linux 系统管理、内核机制及网络协议（尤以 TCP/IP、HTTP 为重），此为排查复杂分布式问题之根基。

二、遵循技术演进脉络 📈

学习应顺应技术发展逻辑，按”物理机 → 虚拟化 → 容器 → 容器编排”的路径递进。先理解虚拟化技术原理，再掌握 Docker 容器化，最终深入 Kubernetes 集群编排。

三、坚持实操驱动 💻

云计算重工程实践，忌纸上谈兵。需依托云平台资源，完成架构搭建、压力测试、容灾演练等全链路实验，在真实配置与排错中构建技术能力。

四、对标行业标准 📋

以主流云厂商（如 AWS、阿里云）的解决方案架构师认证考纲为学习路径，强制自身建立完整、符合工业界标准的云架构知识体系。

五、深化架构思维 🧠

跳出单一组件视角，聚焦云计算核心特性。在学习和设计中，始终围绕高可用、弹性伸缩、容灾解耦与资源抽象进行系统性思考。

常用学习交流平台 🌐

一、代码协作与技术问答 💬

  • GitHub：阅读云原生开源项目源码，参与社区协作。
  • Stack Overflow：K8s、Terraform 等云生态工具的报错排查与技术问答首选。

二、行业深度与开发者社区 📚

  • InfoQ (极客邦)：获取云原生深度架构文章与行业技术趋势。
  • 阿里云/腾讯云开发者社区：国内云计算最佳实践、技术图谱与解决方案的核心阵地。
  • 掘金：一线开发者的云技术实战经验分享。

三、云原生专属社区 ☁️

  • CNCF Slack / Kubernetes 官方论坛：云原生计算基金会与 K8s 官方交流阵地，获取一手技术动态。
  • DockOne.io：国内老牌容器与云原生技术社区，专业讨论氛围浓厚。

四、云端实验与沙箱环境 🧪

  • Killercoda：浏览器内直接实操 K8s 与 Linux 环境，免本地配置。
  • Play with K8s / Docker：官方提供的免费临时集群搭建与演练平台。
  • 各大云厂商免费试用专区：AWS Free Tier、阿里云飞天加速计划等，提供真实生产环境练手机会。

注意事项 ⚠️

  • 在实际学习中，要理论与实践相结合，多动手操作。
  • 积极参与社区交流，保持对新技术趋势的敏感度。

发表于 更新于 分类于
详细介绍Docker Compose多容器编排工具的核心概念、配置方法和基本命令

Docker多容器编排详解

Docker Compose概述

Docker Compose是一个用于定义和运行多容器Docker应用程序的工具。它允许您使用一个单独的配置文件(通常是.yml格式)来配置应用程序的所有服务、网络和卷，然后通过一条简单的命令就能创建和启动所有服务。

核心概念

  • 服务：对应一个容器，可以指定使用哪个镜像、暴露哪些端口、挂载哪些卷、设置哪些环境变量、依赖哪些其他服务等
  • 网络：定义容器之间通信的网络
  • 卷：定义持久化数据存储的位置

服务依赖配置示例

1
2
3
4
5
6
7
8
9
10
11
version: "3.7"
services:
  web:
    build: .
    depends_on:
      - db
      - redis
  redis:
    image: redis
  db:
    image: postgres

网络互通机制

  • Docker Compose会自动创建一个默认网络，所有服务都会加入该网络
  • 服务之间可以通过服务名进行DNS解析和通信
  • 可以自定义网络配置，包括网络类型、IP地址分配等

基本命令

  • docker compose up：构建、创建、启动和链接服务相关的容器
  • docker compose down：停止所有容器并删除容器和网络
  • docker compose ps：列出项目中目前的所有容器

应用价值

Docker Compose解决了手动管理多个容器的复杂性，通过一个配置文件描述整个应用栈的架构，实现一键部署和管理多容器应用。

发表于 更新于 分类于
全面介绍Docker容器的生命周期状态、管理命令及最佳实践

Docker容器生命周期管理详解

一、Docker容器生命周期状态

Docker容器具有完整的生命周期状态，从创建到销毁，每个阶段都有其特定的作用和命令支持：

  • Created（已创建）：容器已创建但尚未运行
  • Running（运行中）：容器正在运行，执行进程活跃
  • Paused（暂停）：容器进程被挂起，暂时停止调度
  • Stopped/Exited（已停止/退出）：容器运行完毕或被手动停止
  • Dead（死掉）：异常中止或资源清理失败时的状态

二、Docker容器生命周期管理命令

1. 创建容器

docker create命令：创建容器但不启动

1
docker create --name mycontainer nginx

docker run命令：创建并启动容器

1
docker run -d --name mycontainer nginx

常用参数：

  • -d, --detach：后台运行容器
  • --name：指定容器名称
  • -p：端口映射，格式：主机端口:容器端口
  • -v：挂载卷，格式：主机路径:容器路径
  • -e：设置环境变量
  • -m：限制内存使用
  • --cpus：限制CPU使用
  • --restart：设置重启策略
  • --rm：容器退出时自动删除

2. 启动容器

docker start命令：启动已创建的容器

1
docker start mycontainer

常用参数：

  • -a, --attach：附加STDOUT/STDERR并向前传递信号
  • -i, --interactive：保持STDIN打开

3. 运行容器

docker run命令：创建并启动容器（常用组合）

1
docker run -d --name webserver -p 80:80 nginx

4. 暂停容器

docker pause命令：暂停容器运行

1
docker pause mycontainer

5. 恢复容器

docker unpause命令：恢复暂停的容器

1
docker unpause mycontainer

6. 停止容器

docker stop命令：优雅停止容器

1
docker stop mycontainer

常用参数：

  • -t, --time：停止前等待时间（默认10秒）

7. 强制停止容器

docker kill命令：强制终止容器

1
docker kill mycontainer

常用参数：

  • -s, --signal：发送指定信号（默认SIGKILL）

8. 重启容器

docker restart命令：重启容器

1
docker restart mycontainer

常用参数：

  • -t, --time：停止前等待时间（默认10秒）

9. 删除容器

docker rm命令：删除已停止的容器

1
docker rm mycontainer

常用参数：

  • -f, --force：强制删除运行中的容器
  • -v, --volumes：删除容器关联的卷
  • -l, --link：删除指定的连接

10. 查看容器状态

docker ps命令：查看运行中的容器

1
docker ps

常用参数：

  • -a：显示所有容器（包括已停止的）
  • -q：仅显示容器ID

11. 查看容器日志

docker logs命令：查看容器日志

1
docker logs mycontainer

常用参数：

  • -f：跟踪日志输出
  • --tail：显示最后N行
  • -t：显示时间戳

12. 进入容器

docker exec命令：在运行中的容器执行命令

1
docker exec -it mycontainer /bin/bash

常用参数：

  • -i：保持STDIN打开
  • -t：分配伪终端
    docker attach命令：附加到运行中的容器
1
docker attach mycontainer

13. 查看容器详细信息

docker inspect命令：查看容器详细信息

1
docker inspect mycontainer

14. 查看容器资源使用

docker stats命令：查看容器资源使用情况

1
docker stats mycontainer

15. 查看容器进程

docker top命令：查看容器内运行的进程

1
docker top mycontainer

16. 容器间文件复制

docker cp命令：在容器和主机间复制文件

1
2
docker cp localfile mycontainer:/path/in/container
docker cp mycontainer:/path/in/container localfile

三、常用操作示例

1. 批量操作

批量停止所有运行中的容器：

1
docker stop $(docker ps -q)

批量删除已停止的容器：

1
docker rm $(docker ps -aq -f status=exited)

批量启动所有容器：

1
docker start $(docker ps -aq)

2. 自动重启策略

1
docker run -d --restart unless-stopped nginx

3. 临时容器运行

1
docker run --rm myapp:test ./run_tests.sh

4. 资源限制

1
docker run -d -m 512m --cpus=1.0 nginx

5. 端口映射

1
docker run -d -p 8080:80 nginx

6. 数据卷挂载

1
docker run -d -v /host/path:/container/path nginx

7. 环境变量设置

1
docker run -d -e MYSQL_ROOT_PASSWORD=password mysql

8. 交互式运行

1
docker run -it ubuntu /bin/bash

四、生命周期管理最佳实践

  1. 使用--name参数为容器指定有意义的名称
  2. 合理设置重启策略确保服务可用性
  3. 使用资源限制防止单个容器占用过多资源
  4. 定期清理已停止的容器释放系统资源
  5. 使用docker logs监控容器运行状态
  6. 优雅停止容器使用docker stop而非docker kill
  7. 生产环境建议使用docker-compose或Kubernetes进行管理
  8. 定期备份重要容器的数据卷

发表于 更新于 分类于
深入解析Docker的Volume和Bind Mount两种数据持久化机制，帮助开发者选择合适的持久化方案

Docker数据持久化详解

核心概念

  • Docker数据持久化是容器化应用开发的核心挑战
  • 影响数据安全与应用可靠性
  • 提供Volume和Bind Mount两种主要机制

Volume机制

  • 由Docker管理的持久化数据卷
  • 存储位置：宿主机特定目录（/var/lib/docker/volumes/）
  • 创建命令：docker volume create mydata
  • 使用命令：docker run -d --name webapp -v mydata:/app/data nginx
  • 特点：生命周期独立于容器，适合数据库存储等场景

Bind Mount机制

  • 将宿主机任意目录直接挂载到容器中
  • 开发者对路径有完全控制权
  • 使用命令：docker run -d --name devapp -v $(pwd):/app nginx
  • 特点：适合开发环境，便于代码实时同步

对比分析

  • Volume优势：Docker管理、安全性高、跨平台兼容性好
  • Bind Mount优势：路径可控、适合开发调试
  • Bind Mount劣势：依赖宿主机目录结构

应用场景建议

  • 生产环境：优先使用Volume，提供更安全、易管理的持久化方式
  • 开发环境：Bind Mount更适合代码热重载和实时文件同步

注意事项

  • 确保数据安全保存到宿主机或其他存储位置
  • 避免容器删除导致的数据丢失问题

发表于 更新于 分类于 ，
详细介绍Docker Hub和Harbor私有仓库的推送拉取操作，以及轩辕镜像服务的使用方法和版本差异

Docker镜像仓库详解

Docker Hub推送与拉取操作

登录Docker Hub

1
docker login

输入用户名和密码完成登录
推送镜像到Docker Hub

1
2
docker tag local-image-name username/repository:tag
docker push username/repository:tag

从Docker Hub拉取镜像

1
docker pull username/repository:tag

Harbor私有仓库推送与拉取操作

配置Docker支持私有仓库
在/etc/docker/daemon.json中添加insecure-registries配置，然后重启Docker服务
登录Harbor

1
docker login -u admin -p password harbor地址:port

推送镜像到Harbor

1
2
docker tag 镜像ID harbor地址:port/项目名/镜像名:版本
docker push harbor地址:port/项目名/镜像名:版本

从Harbor拉取镜像

1
docker pull harbor地址:port/项目名/镜像名:版本

轩辕镜像服务

服务概述
轩辕镜像专注公共仓库场景，整合Docker Hub、Google Container Registry、Kubernetes官方仓库等主流镜像源
免费版使用方法

  • 配置registry-mirrors指向docker.xuanyuan.me
  • 或直接使用：docker pull docker.xuanyuan.me/镜像名:tag
  • 仅支持Docker Hub镜像拉取
    专业版功能
  • 提供专属域名拉取方式：docker pull ***.xuanyuan.run/镜像名:tag
  • 支持7+个主流镜像仓库，包括：
    • Docker Hub
    • Google Container Registry (GCR)
    • GitHub Container Registry (GHCR)
    • Kubernetes仓库
    • NVIDIA
    • Quay
    • Microsoft
    • Elastic
      等仓库

发表于 更新于 分类于
详细介绍Docker四种核心网络模式（Bridge、Host、Container、None）及其适用场景，以及端口映射的配置方法和查看技巧

Docker网络模式详解

Docker四种核心网络模式

1、Bridge桥接模式

  • 特性: 默认模式，Docker为容器分配独立虚拟网卡并接入docker0网桥
  • 网络隔离: 容器间通过Docker网络通信，与外部网络隔离
  • 适用场景: 常规应用隔离部署，需端口映射-p暴露服务

2、Host主机模式

  • 特性: 容器直接共享宿主机网络命名空间，无独立网络栈
  • 性能优势: 性能最佳无NAT转换，但会占用宿主机端口可能冲突
  • 适用场景: 网络密集型应用如负载均衡器，需避免端口转发开销

3、Container容器共享模式

  • 特性: 新容器共享指定容器的网络命名空间，如–net=container:容器名
  • 通信方式: 容器间可通过localhost直接通信，无需暴露端口
  • 适用场景: 依赖紧密的容器组，如日志收集器与应用容器

4、None无网络模式

  • 特性: 不配置任何网络接口，容器完全隔离
  • 配置要求: 需手动自定义网络栈，如通过nsenter命令
  • 适用场景: 安全性要求极高的任务或特殊网络调试

端口映射配置方法

基本配置

  • 参数: 使用-p参数指定端口映射
  • 格式: -p host_port:container_port
  • 示例: docker run -p 8080:80 nginx，将本地的8080端口映射到容器的80端口上

其他配置方式

  • 替代参数: 也可以使用–publish参数，格式相同
  • 多端口映射: 如需映射多个端口，可使用多个-p参数
  • 多端口示例: docker run -p 8080:80 -p 3306:3306 nginx

查看端口映射信息

查看命令

  • 命令: 使用docker port命令查看容器的端口映射信息
  • 语法: docker port container_id

发表于 更新于 分类于
全面介绍Docker镜像的获取、管理、构建、导入导出等操作命令，包含实用示例和最佳实践指南

Docker镜像管理详解

Docker 镜像是容器的只读模板，包含应用及其运行环境。本文涵盖常用镜像操作命令、示例和最佳实践。

一、获取镜像

1. docker pull – 拉取镜像

1
docker pull [选项] 镜像名[:标签]
  • 默认标签为 latest
  • 示例：
    docker pull ubuntu:20.04
    docker pull nginx:1.25

2. docker push – 推送镜像

1
docker push 用户名/镜像名:标签
  • 需先登录仓库（docker login）并为镜像打上正确标签
  • 示例：docker push myrepo/hello:v1

二、管理本地镜像

3. docker images (或 docker image ls) – 列出镜像

1
docker images [选项]
  • -a：显示中间层镜像
  • -q：仅显示镜像 ID
  • --digests：显示摘要

4. docker rmi – 删除镜像

1
docker rmi [选项] 镜像名[:标签|镜像ID]
  • -f：强制删除（有容器依赖时）
  • 清理悬挂镜像：docker image prune

5. docker tag – 打标签

1
docker tag 源镜像[:标签] 目标镜像[:标签]
  • 为镜像添加新名称/仓库路径，不复制内容
  • 示例：docker tag nginx:latest myregistry.com/mynginx:v1

三、构建镜像

6. docker build – 通过 Dockerfile 构建

1
docker build [选项] 路径
  • -t 镜像名:标签：指定名称
  • -f Dockerfile：指定文件（默认当前目录下 Dockerfile）
  • --no-cache：忽略缓存
  • 示例：docker build -t myapp:v1 .

7. docker commit – 从容器创建镜像（临时调试，不推荐生产）

1
docker commit 容器名 新镜像名:标签

四、镜像导入/导出与文件系统转换

8. docker save – 保存镜像为 tar 文件（保留层历史）

1
docker save -o 文件名.tar 镜像名:标签

示例：docker save -o ubuntu.tar ubuntu:20.04

9. docker load – 从 tar 文件加载镜像

1
docker load -i 文件名.tar

10. docker export / docker import – 容器快照转为镜像

  • docker export 容器名 > container.tar：导出容器文件系统（丢失历史层）
  • docker import container.tar 新镜像名:标签：导入为镜像（单层）

    save/load 保留完整分层结构，export/import 生成扁平镜像，体积更小但无法追溯构建历史。

五、查看镜像详情

11. docker inspect – 显示镜像元数据（JSON）

1
docker inspect 镜像名:标签

包含架构、环境变量、开放端口、入口点等。

12. docker history – 查看镜像构建历史层

1
docker history 镜像名:标签

每层的创建命令与大小，有助于优化镜像。

六、清理与空间回收

13. docker image prune – 删除未使用的镜像

  • -a：删除所有不被容器引用的镜像
  • -f：跳过确认
    示例：docker image prune -a

14. docker system df – 查看磁盘占用（镜像、容器、卷）

典型工作流示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
# 拉取基础镜像
docker pull node:18-alpine

# 构建自定义镜像
docker build -t mynodeapp:1.0 .

# 标记以便推送到仓库
docker tag mynodeapp:1.0 mydockerhub/mynodeapp:1.0

# 登录并推送
docker login
docker push mydockerhub/mynodeapp:1.0

# 另一台机器拉取并运行
docker pull mydockerhub/mynodeapp:1.0

# 导出离线包
docker save -o app.tar mynodeapp:1.0
# 加载离线包
docker load -i app.tar

安全与最佳实践

  • 避免使用 latest 标签，指定具体版本号
  • 删除镜像前确认没有依赖容器（包括停止的容器），必要时加 -f
  • 生产环境推荐使用 Dockerfile + docker build，而非 docker commit
  • 定期运行 docker image prune 清理无用镜像

发表于 更新于 分类于 ，
深入解析Kubernetes存储抽象体系的核心组件PV、PVC和StorageClass，包括概念解析、配置方法和管理命令

核心概念解析 📚

一、PV（持久卷）💾

PV是集群级别的存储资源，代表实际的存储设备或存储空间，如NFS、Ceph、云硬盘等。

主要特性

  • 独立生命周期: 即使Pod被删除，PV中的数据仍然保留
  • 访问模式支持:
    • ReadWriteOnce（单节点读写）
    • ReadOnlyMany（多节点只读）
    • ReadWriteMany（多节点读写）

静态PV创建示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
apiVersion: v1
kind: PersistentVolume
metadata:
  name: nfs-pv
spec:
  capacity:
    storage: 2Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Recycle
  storageClassName: nfs
  mountOptions:
    - hard
    - nfsvers=4.1
  nfs:
    path: /opt/k8s-pods/data
    server: 192.168.179.102

二、PVC（持久卷声明）📝

PVC是用户对存储资源的请求，定义了所需存储的大小、访问模式等属性。

核心作用

  • 作为存储的”接口”，封装底层存储复杂性
  • 使开发者无需关心具体存储实现
  • 一个PV只能被一个PVC绑定

PVC创建示例

1
2
3
4
5
6
7
8
9
10
11
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: nfs-pvc
spec:
  accessModes:
    - ReadWriteMany
  resources:
    requests:
      storage: 2Gi
  storageClassName: nfs

三、StorageClass（存储类）⚙️

StorageClass是实现动态存储供应的核心组件，定义了如何创建PV的模板。

关键字段

  • provisioner: 存储供应者
  • parameters: 存储参数
  • reclaimPolicy: 回收策略
  • volumeBindingMode: 绑定模式

StorageClass创建示例

1
2
3
4
5
6
7
8
9
10
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: nfs-client-storageclass
provisioner: nfs-storage
parameters:
  archiveOnDelete: "false"
reclaimPolicy: Delete
allowVolumeExpansion: true
volumeBindingMode: Immediate

存储供应模式 🔄

静态供应模式 📦

由管理员预先创建PV，然后PVC进行绑定。

创建命令

1
2
3
kubectl create -f pv.yaml
kubectl create -f pvc.yaml
kubectl create -f storageclass.yaml

动态供应模式 🚀

通过StorageClass自动创建PV，大大简化存储管理。

创建命令

1
2
3
kubectl apply -f pv.yaml
kubectl apply -f pvc.yaml
kubectl apply -f storageclass.yaml

PV生命周期状态 📊

PV的生命周期包括四种状态：

状态 描述
Available 还未与某个PVC绑定
Bound 已与某个PVC绑定
Released 绑定的PVC已经删除，资源已释放，但未被集群回收
Failed 自动资源回收失败

回收策略 ♻️

回收策略决定了PVC删除后PV的处理方式：

策略 描述
Retain PV不会被自动删除，数据依然保留
Delete PV会被自动删除，关联的存储资源也会被清理
Recycle 对卷执行基本清理操作，但已被弃用

完整创建方法 🔧

动态供应完整配置

RBAC权限配置

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
apiVersion: v1
kind: ServiceAccount
metadata:
  name: nfs-client-provisioner
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: nfs-client-provisioner-runner
rules:
  - apiGroups: [""]
    resources: ["persistentvolumes"]
    verbs: ["get", "list", "watch", "create", "delete"]
  - apiGroups: [""]
    resources: ["persistentvolumeclaims"]
    verbs: ["get", "list", "watch", "update"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: run-nfs-client-provisioner
subjects:
  - kind: ServiceAccount
    name: nfs-client-provisioner
roleRef:
  kind: ClusterRole
  name: nfs-client-provisioner-runner
  apiGroup: rbac.authorization.k8s.io

NFS Provisioner部署

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nfs-client-provisioner
spec:
  replicas: 1
  selector:
    matchLabels:
      app: nfs-client-provisioner
  template:
    metadata:
      labels:
        app: nfs-client-provisioner
    spec:
      serviceAccountName: nfs-client-provisioner
      containers:
        - name: nfs-client-provisioner
          image: quay.io/external_storage/nfs-client-provisioner:latest
          volumeMounts:
            - name: nfs-client-root
              mountPath: /persistentvolumes
          env:
            - name: PROVISIONER_NAME
              value: nfs-storage
            - name: NFS_SERVER
              value: 192.168.179.102
            - name: NFS_PATH
              value: /opt/k8s
      volumes:
        - name: nfs-client-root
          nfs:
            server: 192.168.179.102
            path: /opt/k8s

创建动态供应组件

1
2
3
4
kubectl apply -f rbac.yaml
kubectl apply -f nfs-provisioner.yaml
kubectl apply -f storageclass.yaml
kubectl apply -f dynamic-pvc.yaml

Pod使用PVC创建方法 🐳

Pod使用PVC的YAML示例

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
apiVersion: v1
kind: Pod
metadata:
  name: nginx-pv-pod
spec:
  containers:
    - name: nginx
      image: nginx
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - name: nginx-pv-storage
          mountPath: "/usr/share/nginx/html"
  volumes:
    - name: nginx-pv-storage
      persistentVolumeClaim:
        claimName: nfs-pvc

StatefulSet使用PVC模板

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: web
spec:
  serviceName: "nginx"
  replicas: 3
  selector:
    matchLabels:
      app: nginx
  template:
    metadata:
      labels:
        app: nginx
    spec:
      containers:
        - name: nginx
          image: nginx:latest
          ports:
            - containerPort: 80
              name: web
          volumeMounts:
            - name: www
              mountPath: /usr/share/nginx/html
  volumeClaimTemplates:
    - metadata:
        name: www
      spec:
        accessModes: ["ReadWriteOnce"]
        storageClassName: "nfs-client-storageclass"
        resources:
          requests:
            storage: 1Gi

管理命令汇总 🛠️

资源创建命令

1
2
3
kubectl create -f <yaml-file>           # 创建资源
kubectl apply -f <yaml-file>            # 应用配置
kubectl apply -f <directory>            # 应用目录下所有配置

资源查看命令

1
2
3
4
5
kubectl get pv,pvc,sc                   # 查看所有存储资源
kubectl get pv -o wide                  # 查看PV详细信息
kubectl get pvc -o wide                 # 查看PVC详细信息
kubectl describe sc <sc-name>           # 查看StorageClass详情
kubectl get pv --sort-by=.spec.capacity.storage  # 按容量排序PV

资源删除命令

1
2
3
4
5
kubectl delete pv <pv-name>             # 删除PV
kubectl delete pvc <pvc-name>           # 删除PVC
kubectl delete sc <sc-name>             # 删除StorageClass
kubectl delete -f <yaml-file>           # 删除配置文件中的资源
kubectl delete pod,pvc,pv --all        # 删除所有相关资源

故障排查命令

1
2
3
4
5
kubectl describe pvc <pvc-name>         # 查看PVC详细状态
kubectl describe pv <pv-name>           # 查看PV详细状态
kubectl logs <provisioner-pod>          # 查看Provisioner日志
kubectl get events --sort-by=.metadata.creationTimestamp  # 查看事件
kubectl exec -it <pod-name> -- /bin/bash  # 进入容器调试

存储资源扩展命令

1
2
kubectl patch pvc <pvc-name> -p '{"spec":{"resources":{"requests":{"storage":"10Gi"}}}}'  # 扩展PVC容量
kubectl get pv,pvc -o wide              # 查看扩展后的状态

不同存储类型创建示例 💿

本地存储PV创建

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
apiVersion: v1
kind: PersistentVolume
metadata:
  name: local-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  storageClassName: local-storage
  local:
    path: /mnt/disks/ssd1
  nodeAffinity:
    required:
      nodeSelectorTerms:
        - matchExpressions:
            - key: kubernetes.io/hostname
              operator: In
              values:
                - node1

云存储PV创建（AWS EBS示例）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
apiVersion: v1
kind: PersistentVolume
metadata:
  name: aws-ebs-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Delete
  storageClassName: aws-ebs
  awsElasticBlockStore:
    volumeID: vol-0123456789abcdef0
    fsType: ext4

Ceph RBD PV创建

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
apiVersion: v1
kind: PersistentVolume
metadata:
  name: ceph-rbd-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: ceph-rbd
  rbd:
    monitors:
      - "192.168.1.100:6789"
      - "192.168.1.101:6789"
      - "192.168.1.102:6789"
    pool: rbd
    image: foo
    fsType: ext4
    readOnly: false
    user: admin
    secretRef:
      name: ceph-secret

动态供应工作流程 🔄

动态供应机制的工作流程为：

  1. 用户创建PVC并指定StorageClass 📝
  2. Kubernetes根据StorageClass调用对应的provisioner创建PV ⚙️
  3. PV自动绑定到PVC 🔗
  4. Pod通过PVC使用存储资源 🐳

最佳实践建议 ✨

  1. 存储类规划: 根据应用需求创建多个StorageClass，如高性能存储、标准存储、归档存储等
  2. 回收策略选择: 生产环境建议使用Retain策略以避免数据意外丢失
  3. 容量规划: 合理设置PV容量，避免资源浪费或不足
  4. 监控告警: 定期检查PV/PVC状态，设置存储使用率告警
  5. 备份策略: 为重要数据制定定期备份计划
0%