跳至主要內容
Docker中的一些进程

查看docker里的一些进程

[root@docker1 ~]# ps -aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root           1  0.0  0.5  22344 12972 ?        Ss   10:38   0:01 /usr/lib/systemd/systemd --swi
root           2  0.0  0.0      0     0 ?        S    10:38   0:00 [kthreadd]
root           3  0.0  0.0      0     0 ?        S    10:38   0:00 [pool_workqueue_release]
root           4  0.0  0.0      0     0 ?        I<   10:38   0:00 [kworker/R-rcu_gp]
root           5  0.0  0.0      0     0 ?        I<   10:38   0:00 [kworker/R-sync_wq]
root           6  0.0  0.0      0     0 ?        I<   10:38   0:00 [kworker/R-slub_flushwq]
root           7  0.0  0.0      0     0 ?        I<   10:38   0:00 [kworker/R-netns]
root           9  0.0  0.0      0     0 ?        I<   10:38   0:00 [kworker/0:0H-kblockd]
Kinger2026/7/23大约 10 分钟云原生
docker部署

docker是什么？

Docker 是一款开源的容器化平台，核心作用是将应用程序及其所有依赖（代码、运行环境、库、配置文件等）打包成一个标准化的容器，让应用能在任意支持 Docker 的环境中（Linux/Windows/macOS、物理机 / 虚拟机 / 云服务器）一致、无差异地运行，解决了开发中 “本地运行正常，部署到服务器就出问题” 的环境不一致痛点。

简单来说：Docker 把应用和它的 “运行环境” 一起打包成一个独立的 “容器盒子”，这个盒子能在任何装了 Docker 的机器上直接运行。

Kinger2026/7/23大约 33 分钟云原生
Dashboard

获取YAML文件

wget https://raw.githubusercontent.com/kubernetes/dashboard/v2.7.0/aio/deploy/recommended.yaml
Kinger2026/7/23大约 1 分钟云原生
K8s

简单来说，Kubernetes（通常简称为 K8s，因为 K 和 s 之间有 8 个字母）是一个开源的容器编排平台。

如果把 Docker 容器比作一只只“运货的集装箱”，那么 K8s 就是那台巨大的“自动化起重机”和“港口调度系统”。

部署Kubernetes+docker

1. 为什么需要 K8s？

在只有几个容器时，手动管理很简单。但当你有成百上千个容器在几十台服务器上运行，且需要处理升级、扩容、宕机恢复时，靠人工是不可能的。K8s 解决了以下痛点：

Kinger2026/7/23大约 25 分钟云原生
metrics_server安装

获取官方 components.yaml文件

在master中中执行

wget https://github.com/kubernetes-sigs/metrics-server/releases/download/v0.8.1/components.yaml
Kinger2026/7/23大约 1 分钟云原生
发布服务

一、 服务暴露（以 Nginx 为例）

在 Kubernetes 中，Pod 的 IP 是动态的，必须通过 Service 资源将服务暴露给外部访问。

1. 快速命令行发布 (Imperative)

如果你已经有一个正在运行的 Deployment（例如 nginx-deploy），可以使用 expose 命令快速创建 Service。

# 对应图片中的操作
kubectl expose deployment nginx-deploy --port=80 --target-port=80 --type=NodePort --name=nginx-service
Kinger2026/7/23大约 2 分钟云原生
用containerd拉取镜像的配置问题

这份笔记已经为你系统性地复盘了整个过程。它不仅包含解决办法，还深入到了 Containerd V3 的底层逻辑，是应对现代 Kubernetes 镜像拉取问题的“终极手册”。

​Kubernetes 镜像加速与 Containerd V3 运维笔记

一、 核心注意事项 (Attention)

在 Containerd V3 环境下，以下四点是导致镜像拉取失败的“元凶”：

  1. 版本命名空间陷阱：Containerd version = 3 与旧版不同。插件路径已从 io.containerd.grpc.v1.cri 迁移至 io.containerd.cri.v1.runtime。全集群必须对齐到 Version 3。
  2. 符号杀手 (冒号)：config_path 必须是一个纯净的目录路径（如 "/etc/containerd/certs.d"）。严禁包含冒号（如 certs.d:certs.d），否则会导致路径解析失败，加速器静默失效。
  3. Sandbox (Pause) 阻塞：Pod 启动的“第一跳”是拉取 pause 镜像。如果它指向无法访问的国外源，即使业务镜像配置了加速，Pod 也会卡死在 ContainerCreating。
  4. Cgroup 驱动对齐：Containerd 的 SystemdCgroup 必须为 true，且必须与 Kubelet 配置文件中的 cgroupDriver: systemd 保持一致，否则容器无法正常启动。
Kinger2026/7/23大约 3 分钟云原生