# k8s集群命令行工具kubectl之故障排除和调试命令

## 一、describe
显示某个资源或某组资源的详细信息。

用法：

kubectl describe (-f FILENAME | TYPE [NAME_PREFIX | -l label] | TYPE/NAME)
示例：

```
# 显示单个node节点详细信息
kubectl describe nodes k8s-node1
# 显示单个pod详细信息
kubectl describe pods/nginx
# 显示文件描述的资源的详细信息
kubectl describe -f myapp-deployment.yaml
# 显示以k8s开头的节点的详细信息
kubectl describe node k8s
# 显示以myapp-deployment开头的pod的详细信息，pod命名通常与其控制器有关
kubectl describe pods myapp-deployment
# 显示指定label的pod详细信息
kubectl describe po -l name=myapp
```
## 二、logs
输出 pod 中某容器的日志。

用法：

kubectl logs [-f] [-p] (POD | TYPE/NAME) [-c CONTAINER]


示例：
（1）首先：
```
# 运行一个nginx Pod
kubectl run nginx --image=nginx
```
（2）其次：
```
# 获取pod第一个容器的日志
kubectl logs nginx
# 获取pod中所有容器的日志
kubectl logs <podname> --all-containers=true
# 获取labels包含 name=myapp的所有pod下的所有容器日志
kubectl logs -l name=myapp --all-containers=true
# 持续输出pod中某个容器产生的日志，容器名为 myhello
kubectl logs -f -c myhello <podname>
# 持续输出labels包含 name=myapp的所有pod下的所有容器日志，最大并发日志请求数为10
kubectl logs -f -l name=myapp --all-containers=true --max-log-requests=10
# 获取最近几行日志
kubectl logs --tail=5 nginx
# 获取最近一个小时的日志
kubectl logs --since=1h nginx
# 获取pod中第一个容器的日志
kubectl logs pod/<podname>
# 获取指定deployment中，第一个pod的指定容器的日志。默认日志请求并发数为5
kubectl logs deployment/myapp-deployment -c myhello
```
3. 更多示例：

```
# 输出pod web-1中曾经运行过的，但目前已终止的容器ruby的日志
kubectl logs -p -c ruby web-1
```
## 三、attach
连接到一个正在运行的容器。

用法：

kubectl attach (POD | TYPE/NAME) -c CONTAINER


示例：

```
# 连接到指定pod中正在运行的第一个容器
kubectl attach <podname>
# 连接到指定pod中正在运行容器名为 myhello的容器
kubectl attach <podname> -c myhello
# 连接到指定deployments正在运行的第一个容器
kubectl attach deployments/myapp-deployment
```



## 四、exec
在容器中执行相关命令。

用法：

kubectl exec (POD | TYPE/NAME) [-c CONTAINER] [flags] -- COMMAND [args...]


示例：

```
# 在pod nginx 第一个容器中执行date命令
kubectl exec nginx -- date
# 通过-c 指定容器
kubectl exec <podname> -c myhello -- date
# 传入 ls命令和相关参数
kubectl exec <podname> -c myhello -- ls -al ./
# 通过 -it 开启一个虚拟终端
kubectl exec <podname> -c myhello -i -t -- /bin/sh
# deployment/myapp-deployment第一个容器中执行命令
kubectl exec deployments/myapp-deployment -- date
# svc/myapp-svc 第一个容器中执行命令
kubectl exec svc/myapp-svc -- date
```



## 五、port-forward
将一个或者多个本地端口转发到 pod。如果有多个pod符合条件，将自动选择一个pod。当所选pod终止时，转发会话结束，需要重新运行该命令才能恢复转发。



用法：

kubectl port-forward TYPE/NAME [options] [LOCAL_PORT:]REMOTE_PORT [... [LOCAL_PORT_N:]REMOTE_PORT_N]


示例：

```
# 转发本机5000 6000 端口到pod对应端口
kubectl port-forward pod/nginx 5000 6000
# 转发本机 5000 6000 分别到80和81端口
kubectl port-forward pod/nginx 5000:80 6000:81
# 从deployments/myapp-deployment 选择一个pod进行转发操作
kubectl port-forward deployments/myapp-deployment 5000 6000
# 从service中选择第一个pod，并将端口转发到端口名为http的端口上
kubectl port-forward service/myapp-svc 8080:http
# 通过--address指定监听地址
kubectl port-forward --address localhost,192.168.239.142 pod/nginx 8888:80
# 随机一个本地端口，转发到pod的指定端口
kubectl port-forward pod/nginx :80
```



## 六、proxy
在本地主机和Kubernetes API服务器之间创建代理服务器或应用程序级网关。它还允许通过指定的HTTP路径提供静态内容。所有传入数据都通过一个端口进入并转发到远程Kubernetes API服务器端口，但与静态内容路径匹配的路径除外。



用法：

kubectl proxy [--port=PORT] [--www=static-dir] [--www-prefix=prefix] [--apiprefix=prefix]


示例：

```
kubectl proxy --api-prefix=/custom/ --port=8011 --www=$HOME/ --wwwprefix=/static/

# 通过代理访问apiserver接口
curl http://127.0.0.1:8011/custom/api/v1/pods
# 通过代理访问静态内容
curl http://127.0.0.1:8011/static/
```



## 七、cp
将文件和目录拷入/拷出容器。

用法：

kubectl cp <file-spec-src> <file-spec-dest>


示例：

```
# 把pod第一个容器中当前工作目录下的app 复制到宿主机的/tmp/app
kubectl cp <podname>:app /tmp/app
# 把/tmp/app 文件复制到 pod第一个容器当前工作目录下，命名为app1
kubectl cp /tmp/app <podname>:app1
# 把default命名空间下pod中容器myhello中当前工作目录下的app 复制到宿主机的/tmp/app
kubectl cp default/<podname>:app /tmp/app -c myhello
# 查看容器当前工作目录内容
kubectl exec <podname> ls 
```

## 八、debug
创建用于排查工作负载和节点故障的调试会话。

用法：

kubectl debug (POD | TYPE[[.VERSION].GROUP]/NAME) [ -- COMMAND [args...] ]


### 8.1、案例1：共享进程空间

```
# 运行一个nginx pod
kubectl run nginx --image=nginx
# 创建一个新的pod my-debugger 用来调试，
#将原有pod内的容器拷贝到新的pod，并增加一个镜像为ubuntu的容器
# 并且通过进程共享
kubectl debug nginx -it --image=ubuntu --copy-to=my-debugger --share-processes
# 开启另一个终端，可以查看命名空间共享配置
kubectl get pod my-debugger -o yaml | grep shareProcessNamespace   
```

调试容器内，执行ps ax可以看到包括被调试容器在内的所有进程。

![image.png](/static/img/828e0daf49fa24b74842fca636afac08.image.webp)


通过访问/proc/{PID}/root 可访问到其他容器的文件系统，PID为主进程ID。

![image.png](/static/img/db78931e77fc09eb359c947e6ae9a81b.image.webp)



### 8.2、案例2：更改启动命令、容器镜像
    

```
 # 运行一个myhello的pod
kubectl run myhello --image=xlhmzch/hello:1.0.0
# 更改容器启动命令
kubectl debug myhello -it --copy-to=my-debugger1 --container=myhello -- /bin/sh
# 更改容器镜像
kubectl debug myhello -it --copy-to=my-debugger2 --set-image=myhello=xlhmzch/hello:1.0.1
kubectl debug <podname> -it --copy-to=my-debugger3 --set-image=myhello=xlhmzch/hello:1.0.1,myredis=redis:alpine
# 复制并注入临时容器，共享进程空间同时修改myhello容器的镜像
kubectl debug myhello -it --copy-to=my-debugger4 --image=busybox --setimage=myhello=xlhmzch/hello:1.0.1 --share-processes
```


### 8.3、案例3：调试节点
    
```
  # 通过创建Pod来调试节点，Pod将运行在指定的节点上，节点的根文件系统挂载在/host目录下
kubectl debug node/k8s-node1 -it --image=busybox  
```



### 8.4、其他
其他，需要为集群开启临时容器等特性功能，否则无法使用以下操作。

```
 # 直接在指定的pod中创建一个基于busybox的临时容器
kubectl debug <podname> -it --image=busybox
# 直接在指定的pod中创建一个基于自定义镜像的容器，并且为容器指定容器名为debugger
kubectl debug <podname> --image=<cusimage> -c debugger   
```

k8s集群命令行工具kubectl之故障排除和调试命令

# 外网镜像通过github同步到阿里云私有仓库

## 复制代码到你的仓库
![image.png](/static/img/d8e95b961ebdad13f2d35d78008d4213.image.webp)

# 写变量

![image.png](/static/img/9b7986027982d88b1099ed76f22fe724.image.webp)

```
{
    "auth": {
        "registry.cn-hangzhou.aliyuncs.com": {
            "username": "涛涛的存钱罐",
            "password": "DOCKERHUB_PASSWORD"
        }
    },
    "images": {
        "docker.io/nginx:latest": "registry.cn-hangzhou.aliyuncs.com/imagessync/nginx"
    }
}
```
修改username为你的阿里云用户名就可以了

docker镜像通过github同步镜像到阿里云

# 常见问题整理

## 问题1
docker: Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: unable to retrieve OCI runtime error (open /run/containerd/io.containerd.runtime.v2.task/moby/1e12d44e3337debff19c494b8000cc150390136437118052f0d15151b96832f5/log.json: no such file or directory): runc did not terminate successfully: exit status 127: unknown.
![image.png](/static/img/4e37915fe26d2d9184e970c39cf1b14f.image.webp)
### 问题描述为 docker 中缺少runc这个东西

```
[root@yaml ~/kuboard]$ docker version
Client: Docker Engine - Community
 Version:           26.1.4
 API version:       1.45
 Go version:        go1.21.11
 Git commit:        5650f9b
 Built:             Wed Jun  5 11:32:04 2024
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          26.1.4
  API version:      1.45 (minimum version 1.24)
  Go version:       go1.21.11
  Git commit:       de5c9cf
  Built:            Wed Jun  5 11:31:02 2024
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.33
  GitCommit:        d2d58213f83a351ca8f528a95fbd145f5654e957
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
```
###  处理方案重装libseccomp

```
yum reinstall libseccomp
```
### 验证是否成功runc存在

```
[root@yaml ~/kuboard]$ docker version
Client: Docker Engine - Community
 Version:           26.1.4
 API version:       1.45
 Go version:        go1.21.11
 Git commit:        5650f9b
 Built:             Wed Jun  5 11:32:04 2024
 OS/Arch:           linux/amd64
 Context:           default

Server: Docker Engine - Community
 Engine:
  Version:          26.1.4
  API version:      1.45 (minimum version 1.24)
  Go version:       go1.21.11
  Git commit:       de5c9cf
  Built:            Wed Jun  5 11:31:02 2024
  OS/Arch:          linux/amd64
  Experimental:     false
 containerd:
  Version:          1.6.33
  GitCommit:        d2d58213f83a351ca8f528a95fbd145f5654e957
 runc:
  Version:          1.1.12
  GitCommit:        v1.1.12-0-g51d5e94
 docker-init:
  Version:          0.19.0
  GitCommit:        de40ad0
```

整理报错

# ansible脚本

## 检查 s-course-server 和 s-gateway 的句柄数，并保存日志

## hosts

```
[root@ecs-564e ~/cron/ansible_jubing]$ cat hosts 
[servers]
192.168.xx.xx
```
## playbook.yml 第一版随便优化

```
---
- name: 检查 s-course-server 和 s-gateway 的句柄数，并保存日志
  hosts: servers  # 替换为目标主机的组名或 IP 地址
  gather_facts: yes
  tasks:
    - name: 获取 s-course-server 进程的 PID
      shell: "pgrep -f 's-course-server'"
      register: course_pid
      failed_when: false
      changed_when: false

    - name: 输出 s-course-server PID
      debug:
        msg: "s-course-server PID: {{ course_pid.stdout }}"

    - name: 获取 s-course-server 进程的句柄数
      shell: "lsof -p {{ course_pid.stdout }} | wc -l"
      register: course_handles
      when: course_pid.stdout != ""
      failed_when: false
      changed_when: false

    - name: 确保 s-course-server 日志目录存在
      file:
        path: "/home/mydata/s-course-server"
        state: directory
        mode: '0755'

    - name: 查看 s-course-server 的 lsof 输出
      shell: "lsof -p {{ course_pid.stdout }}"
      register: lsof_output_course
      failed_when: false
      changed_when: false

    - name: 输出 s-course-server lsof 输出
      debug:
        msg: "{{ lsof_output_course.stdout }}"

    - name: 保存 s-course-server 进程的 lsof 输出到日志文件
      shell: "lsof -p {{ course_pid.stdout }} > /home/mydata/s-course-server/s-course-server-{{ ansible_date_time.iso8601 | regex_replace('[:\\-]', '') }}.log"
      when: course_pid.stdout != ""
      failed_when: false
      changed_when: false

    - name: 获取 s-gateway 进程的 PID
      shell: "pgrep -f 's-gateway'"
      register: gateway_pid
      failed_when: false
      changed_when: false

    - name: 输出 s-gateway PID
      debug:
        msg: "s-gateway PID: {{ gateway_pid.stdout }}"

    - name: 获取 s-gateway 进程的句柄数
      shell: "lsof -p {{ gateway_pid.stdout }} | wc -l"
      register: gateway_handles
      when: gateway_pid.stdout != ""
      failed_when: false
      changed_when: false

    - name: 确保 s-gateway 日志目录存在
      file:
        path: "/home/mydata/s-gateway"
        state: directory
        mode: '0755'

    - name: 查看 s-gateway 的 lsof 输出
      shell: "lsof -p {{ gateway_pid.stdout }}"
      register: lsof_output_gateway
      failed_when: false
      changed_when: false

    - name: 输出 s-gateway lsof 输出
      debug:
        msg: "{{ lsof_output_gateway.stdout }}"

    - name: 保存 s-gateway 进程的 lsof 输出到日志文件
      shell: "lsof -p {{ gateway_pid.stdout }} > /home/mydata/s-gateway/s-gateway-{{ ansible_date_time.iso8601 | regex_replace('[:\\-]', '') }}.log"
      when: gateway_pid.stdout != ""
      failed_when: false
      changed_when: false

    - name: 检查并发送钉钉通知 - s-course-server
      when: course_handles.stdout | int >= 300
      uri:
        url: "https://oapi.dingtalk.com/robot/send?access_token=xx"
        method: POST
        headers:
          Content-Type: "application/json"
        body: |
          {
            "msgtype": "text",
            "text": {
              "content": "警告：s-course-server 进程的句柄数已达到 {{ course_handles.stdout }}，请注意！机器 IP 地址：{{ inventory_hostname }},日志目录：/home/mydata/s-course-server"
            }
          }
        body_format: json
        status_code: 200

    - name: 检查并发送钉钉通知 - s-gateway
      when: gateway_handles.stdout | int >= 300
      uri:
        url: "https://oapi.dingtalk.com/robot/send?access_token=xxx"
        method: POST
        headers:
          Content-Type: "application/json"
        body: |
          {
            "msgtype": "text",
            "text": {
              "content": "警告：s-gateway 进程的句柄数已达到 {{ gateway_handles.stdout }}，请注意！机器 IP 地址：{{ inventory_hostname }},日志目录：/home/mydata/s-gateway"
            }
          }
        body_format: json
        status_code: 200
```
## 执行命令

```
ansible-playbook -i hosts playbook.yml
```


## 22 端口ping

```
---
- name: 用ping测试连通性
  hosts: servers
  gather_facts: no
  tasks:
    - name: Ping test
      ping:
```

## add hosts

```
[root@ecs-564e ~/cron/ansible_allsshd]$ cat allsshd.yml 
---
- name: 管理 hosts.allow 文件
  hosts: all
  become: yes
  gather_facts: no  # 禁用收集事实
  vars:
    action: "add"
  tasks:
    - name: "使用 shell 命令添加 ALL: ALL"
      shell: echo 'ALL:ALL' >> /etc/hosts.allow
      when: action == "add"

```
## edr脚本

```
[root@ecs-564e ~/ansbile]$ cat edr.yaml 
- name: 下载并执行 agent_setup.sh 并检查进程
  hosts: all
  gather_facts: no
  tasks:
    - name: 检查主机的 22 端口
      ansible.builtin.wait_for:
        port: 22
        timeout: 5
      register: port_check
      ignore_errors: yes

    - name: 下载并执行 agent_setup.sh
      ansible.builtin.shell: >
        wget --no-check-certificate http://192.168.1.245:10571/download/linux/KFDX2023/192.168.1.245_10571/1/agent_setup.sh -O agent_setup.sh && chmod +x agent_setup.sh && ./agent_setup.sh
      when: port_check is succeeded
      register: setup_result
      ignore_errors: yes

    - name: 输出下载和执行的日志
      debug:
        var: setup_result.stdout

    - name: 检查 edr 进程
      ansible.builtin.shell: ps -ef | grep edr
      register: edr_process
      ignore_errors: yes

    - name: 输出 edr 进程状态
      debug:
        var: edr_process.stdout

[root@ecs-564e ~/ansbile]$ 
```

## 日志

```
[root@ecs-564e ~/ansbile]$ cat rizhi.yaml 
- name: 修改 rsyslog 配置并重启服务
  hosts: all
  gather_facts: no
  tasks:
    - name: 检查主机的 22 端口
      ansible.builtin.wait_for:
        port: 22
        timeout: 5
      register: port_check
      ignore_errors: yes

    - name: 检查 /etc/rsyslog.conf 是否包含指定内容
      ansible.builtin.command: cat /etc/rsyslog.conf
      register: check_result
      ignore_errors: yes

    - name: 修改 /etc/rsyslog.conf 配置文件
      ansible.builtin.shell: |
        echo '*.*    @192.168.1.105' >> /etc/rsyslog.conf
      when: port_check is succeeded and "'*.*    @192.168.1.105' not in check_result.stdout"
      register: modify_result
      ignore_errors: yes

    - name: 重启 rsyslog 服务
      ansible.builtin.systemd:
        name: rsyslog
        state: restarted
      when: modify_result is succeeded

    - name: 输出修改结果
      debug:
        var: modify_result.stdout

    - name: 输出检查结果
      debug:
        var: check_result.stdout

[root@ecs-564e ~/ansbile]$ 
```

##  批量ssh认证

```
[root@localhost ansible]# cat hosts_renzheng.ini 
[centos]
10.100.23.121 ansible_ssh_user=root ansible_ssh_pass=密码 ansible_ssh_common_args='-o StrictHostKeyChecking=no'
10.100.23.122 ansible_ssh_user=root ansible_ssh_pass=密码 ansible_ssh_common_args='-o StrictHostKeyChecking=no'
10.100.23.123 ansible_ssh_user=root ansible_ssh_pass=密码 ansible_ssh_common_args='-o StrictHostKeyChecking=no'
10.100.23.124 ansible_ssh_user=root ansible_ssh_pass=密码 ansible_ssh_common_args='-o StrictHostKeyChecking=no'
10.100.23.125 ansible_ssh_user=root ansible_ssh_pass=密码 ansible_ssh_common_args='-o StrictHostKeyChecking=no'
10.100.23.126 ansible_ssh_user=root ansible_ssh_pass=密码 ansible_ssh_common_args='-o StrictHostKeyChecking=no'
10.100.23.127 ansible_ssh_user=root ansible_ssh_pass=密码 ansible_ssh_common_args='-o StrictHostKeyChecking=no'
10.100.23.128 ansible_ssh_user=root ansible_ssh_pass=密码 ansible_ssh_common_args='-o StrictHostKeyChecking=no'
10.100.23.129 ansible_ssh_user=root ansible_ssh_pass=密码 ansible_ssh_common_args='-o StrictHostKeyChecking=no'
10.100.23.130 ansible_ssh_user=root ansible_ssh_pass=密码 ansible_ssh_common_args='-o StrictHostKeyChecking=no'
10.100.23.131 ansible_ssh_user=root ansible_ssh_pass=密码 ansible_ssh_common_args='-o StrictHostKeyChecking=no'
10.100.23.132 ansible_ssh_user=root ansible_ssh_pass=密码 ansible_ssh_common_args='-o StrictHostKeyChecking=no'
10.100.23.133 ansible_ssh_user=root ansible_ssh_pass=密码 ansible_ssh_common_args='-o StrictHostKeyChecking=no'
10.100.23.134 ansible_ssh_user=root ansible_ssh_pass=密码 ansible_ssh_common_args='-o StrictHostKeyChecking=no'
10.100.23.136 ansible_ssh_user=root ansible_ssh_pass=密码 ansible_ssh_common_args='-o StrictHostKeyChecking=no'
```

```
[root@localhost ansible]# cat ssh_copy_id.yml 
---
- name: 批量通过 ssh-copy-id 实现密钥认证
  hosts: centos
  become: yes
  tasks:
    - name: 将控制节点的公钥复制到目标主机
      authorized_key:
        user: "{{ ansible_ssh_user }}"
        state: present
        key: "{{ lookup('file', '/root/.ssh/id_rsa.pub') }}"
```
执行

```
ansible-playbook -i hosts_renzheng.ini ssh_copy_id.yml
```

ansible常用

# K8s 容器运行时从 Docker 切换到 containerd

## 一、引言
在容器化技术的世界里，Kubernetes（K8s）无疑是最具影响力的编排工具之一。而容器运行时作为 K8s 的关键组成部分，对于容器的创建、运行和管理起着至关重要的作用。Docker 曾经是 K8s 中最常用的容器运行时，但随着技术的发展，containerd 逐渐崭露头角，并成为越来越多用户的选择。本文将深入探讨 K8s 容器运行时从 Docker 切换到 containerd 的原因、过程和优势，并详细介绍具体的操作步骤。
## 二、Docker 与 containerd 的简介
### 1. Docker
- Docker 是一个开源的容器化平台，它提供了一种便捷的方式来创建、部署和运行容器。Docker 通过使用镜像来打包应用程序及其依赖项，使得应用程序可以在不同的环境中快速部署和运行。
- Docker 的架构包括 Docker 引擎、Docker 镜像、Docker 容器和 Docker 仓库等组件。Docker 引擎是核心组件，负责创建和管理容器。Docker 镜像则是容器的模板，包含了应用程序及其依赖项。Docker 容器是运行中的实例，由 Docker 引擎根据镜像创建。Docker 仓库用于存储和分发镜像。
### 2. containerd
- containerd 是一个工业级的容器运行时，它专注于容器的运行时管理，提供了高效、可靠的容器运行环境。containerd 被设计为可嵌入到其他系统中，如 Kubernetes，以提供容器运行时的功能。
- containerd 的架构相对简单，主要由 containerd 守护进程和 containerd-shim 进程组成。containerd 守护进程负责管理容器的生命周期，包括创建、启动、停止和删除容器。containerd-shim 进程则负责在容器运行时与容器进行交互，确保容器的隔离性和安全性。


## 三、为什么要从 Docker 切换到 containerd
### 1.更好的性能和资源利用率 
- containerd 被设计为轻量级的容器运行时，相比 Docker 具有更好的性能和资源利用率。containerd 直接与 Linux 内核的容器技术（如 cgroups 和 namespaces）进行交互，减少了中间层的开销，从而提高了容器的启动速度和运行效率。
- 此外，containerd 对资源的管理更加精细，可以更好地控制容器的内存、CPU 和磁盘使用，提高资源的利用率。
### 2. 更紧密的与 Kubernetes 集成
- Kubernetes 从 1.20 版本开始，默认的容器运行时从 Docker 切换到了 containerd。这意味着 Kubernetes 与 containerd 的集成更加紧密，可以更好地利用 containerd 的特性和功能。
- 例如，Kubernetes 可以通过 containerd 的 CRI（Container Runtime Interface）实现对容器的更精细的管理，包括容器的健康检查、资源限制和日志收集等。

### 3. 更好的安全性
- containerd 提供了更强大的安全功能，包括容器的隔离性、访问控制和安全策略等。containerd 通过使用 Linux 内核的安全机制，如 seccomp 和 AppArmor，来限制容器的权限，提高容器的安全性。
- 此外，containerd 还支持多种安全认证方式，如 TLS 和 OAuth2，可以确保容器的通信安全。
### 4. 更好的可扩展性和灵活性
- containerd 是一个可扩展的容器运行时，可以通过插件的方式来扩展其功能。用户可以根据自己的需求，开发和安装自定义的插件，以满足特定的业务需求。
- 同时，containerd 也支持多种容器格式，如 OCI（Open Container Initiative）和 Docker 镜像格式，使得用户可以在不同的容器生态系统中进行选择和切换。
## 四、切换过程
### 1. 评估和准备
- 在进行切换之前，首先需要对当前的环境进行评估，确定切换的可行性和影响。评估的内容包括：
- - 现有应用程序对 Docker 的依赖程度。
- - 容器的数量和规模。
- - 网络和存储配置。
- - 监控和日志系统。
- 根据评估结果，制定切换计划，包括切换的时间、步骤和风险应对措施。同时，还需要准备好切换所需的工具和资源，如 containerd 的安装包、配置文件和文档等。
### 2. 安装和配置 containerd
-  安装 containerd 可以通过多种方式进行，如使用包管理器、二进制安装或容器化安装等。具体的安装方法可以根据不同的操作系统和环境进行选择。以下是在 Ubuntu 系统上使用包管理器安装 containerd 的步骤：
- 更新软件包列表：
```
apt update 
apt install containerd
```
在安装完成后，需要对 containerd 进行配置，以满足特定的业务需求。配置的内容包括：
- 容器存储驱动。containerd 支持多种存储驱动，如 overlay2、aufs 等。可以根据实际情况选择合适的存储驱动。
- 网络配置。可以配置 containerd 使用的网络插件，如 CNI（Container Network Interface）插件。
- 安全认证方式。可以配置 containerd 使用的安全认证方式，如 TLS 和 OAuth2。
- 日志收集和监控配置。可以配置 containerd 的日志收集和监控方式，如使用 Prometheus 和 Grafana 进行监控。

### 1. 迁移容器和镜像
- 在切换过程中，需要将现有的容器和镜像从 Docker 迁移到 containerd。迁移的方法可以根据不同的情况进行选择，如：
- - 对于正在运行的容器，可以使用 Kubernetes 的滚动更新功能，逐步将容器从 Docker 切换到 containerd。具体步骤如下：
- 修改 Kubernetes 集群中节点的 kubelet 配置文件，将容器运行时从 Docker 切换到 containerd。
- 使用 kubectl 命令逐步更新 Deployment、StatefulSet 等资源对象，使容器在更新过程中使用 containerd 运行时。
- 对于离线的容器和镜像，可以使用工具如 skopeo 进行迁移。以下是使用 skopeo 迁移 Docker 镜像到 containerd 的步骤：

```
apt install skopeo   - 查找要迁移的 Docker 镜像的名称和标签：docker images   - 使用 skopeo 命令将 Docker 镜像复制到 containerd 存储库：skopeo copy docker://docker-image-name:tag docker-daemon://containers-storage:containers-storage:tag
```
- 在迁移过程中，需要注意容器和镜像的兼容性问题，确保迁移后的容器可以正常运行。
### 1. 测试和验证

在完成迁移后，需要对新的容器运行时进行测试和验证，确保其功能和性能符合预期。测试的内容包括：
- 容器的创建、启动、停止和删除。
- 容器的网络和存储功能。
- 容器的资源限制和监控功能。
- 应用程序的兼容性和稳定性。
如果发现问题，需要及时进行排查和修复，确保切换的顺利进行。
### 2. 切换和监控
####  在测试和验证通过后，可以正式将容器运行时从 Docker 切换到 containerd。切换的方法可以根据不同的环境进行选择，如：
 - -对于 Kubernetes 集群，可以通过修改 kubelet 的配置文件，将容器运行时从 Docker 切换到 containerd。具体步骤如下：
 - -编辑 kubelet 配置文件，将容器运行时设置为 containerd：
 - 

```
 vi /var/lib/kubelet/config.yaml
```
在文件中找到 containerRuntime 字段，将其值设置为 containerd。 
- 重启 kubelet 服务：

```
sudo systemctl restart kubelet
```
对于独立的容器运行环境，可以直接停止 Docker 服务，启动 containerd 服务。