环境介绍当前在100.120 上，有个118.131 可以和它联通，
118.131和122.2 可以联通，但无法直接在100.120上直接联通
如果要ssh 可以【下面这个只要求118.131上有100.120的key】
/bin/ssh -t root@192.168.118.131 "ssh root@192.168.122.2"
scp文件，这里要求122.2上有100.121的key
scp -o ProxyJump=root@192.168.118.131 use_cmd root@192.168.122.2:~
ssh -o ProxyJump=root@192.168.118.131 root@192.168.122.2 "ls -all ~"
在虚拟机上完成上面master安装后，重启系统，关闭了firewall 后，出现错误
# crictl ps|grep kube-apiserver WARN[0000] runtime connect using default endpoints: [unix:///var/run/dockershim.sock unix:///run/containerd/containerd.sock unix:///run/crio/crio.sock unix:///var/run/cri-dockerd.sock]. As the default settings are now deprecated, you should set the endpoint instead. WARN[0000] image connect using default endpoints: [unix:///var/run/dockershim.sock unix:///run/containerd/containerd.sock unix:///run/crio/crio.sock unix:///var/run/cri-dockerd.sock]. As the default settings are now deprecated, you should set the endpoint instead. E0410 14:43:54.969196 2572486 remote_runtime.go:390] "ListContainers with filter from runtime service failed" err="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial unix /var/run/dockershim.sock: connect: no such file or directory\"" filter="&ContainerFilter{Id:,State:&ContainerStateValue{State:CONTAINER_RUNNING,},PodSandboxId:,LabelSelector:map[string]string{},}" FATA[0000] listing containers: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial unix /var/run/dockershim.sock: connect: no such file or directory"
# cat > /etc/crictl.yaml << EOF
> runtime-endpoint: unix:///run/containerd/containerd.sock
> image-endpoint: unix:///run/containerd/containerd.sock
> timeout: 10
> debug: false
> EOF
[root@119-132 ~]# crictl ps
CONTAINER IMAGE CREATED STATE NAME ATTEMPT POD ID POD
[root@119-132 ~]# systemctl restart kubelet
[root@119-132 ~]# crictl ps |grep apiserver
0d0963b6ea4b5 cdcab12b2dd16 21 seconds ago Running kube-apiserver 4 4b240b09343c1 kube-apiserver-119-132
[root@119-132 ~]# kubectl get nodes
NAME STATUS ROLES AGE VERSION
119-132 Ready control-plane 36d v1.28.2
119-134 NotReady <none> 35d v1.28.2
[root@119-132 ~]#
应该是可以了
简单来说：第一次正常，是因为 crictl 侥幸“蒙对了”；重启后不正常，是因为环境变了，它“猜错了”。
以下是详细的技术原因拆解：
1. 第一次为什么正常？（侥幸命中默认列表）
你第一次执行 crictl ps 时，它还没有配置文件，因此会使用内置的默认端点列表按顺序尝试连接：
/var/run/dockershim.sock
/run/containerd/containerd.sock <-- 你的在这里
/run/crio/crio.sock
/var/run/cri-dockerd.sock
关键点： 当时你的环境里，第一个路径（dockershim.sock）不存在，但 crictl 报错后并没有立即退出，而是迅速尝试了第二个路径（containerd.sock），发现能连上，于是正常工作了。这让你产生了“没问题”的错觉。
2. 重启后为什么不行了？（默认行为变了）
重启电脑后，情况发生了微妙但关键的变化：
运行时环境重置：某些系统服务或套接字文件的初始化顺序可能改变。
crictl 的默认逻辑更严格了：在较新版本或某些系统配置下，crictl 在尝试第一个路径并遇到“致命”错误（如权限拒绝或文件不存在） 时，可能不会优雅地继续尝试下一个，而是直接抛出错误并退出。
超时或阻塞：第一次尝试连接一个不存在的 dockershim.sock 可能会遇到更长的超时或更严重的错误，导致整个命令失败，根本没机会试到第二个路径。
结果就是： 它卡在了第一个错误的路径上，根本没去尝试第二个正确的路径，所以你看不到容器。
3. 配置 /etc/crictl.yaml 的本质作用
你创建的配置文件，本质上是跳过了那个“猜”的过程，直接告诉 crictl：
“别费劲试第一个了，直接去 /run/containerd/containerd.sock 找。”
参考:
https://www.php.cn/faq/2063503.html
当出现“这台电脑无法运行 Windows 11”的提示时（或在选择安装类型的界面），按 Shift + F10 打开命令提示符窗口。[popexizhi: 这里可以尝试直接输入Shift + F10]
第三步：通过命令行添加注册表项
reg add HKLM\SYSTEM\Setup\LabConfig /v BypassTPMCheck /t REG_DWORD /d 1 /f reg add HKLM\SYSTEM\Setup\LabConfig /v BypassSecureBootCheck /t REG_DWORD /d 1 /f reg add HKLM\SYSTEM\Setup\LabConfig /v BypassRAMCheck /t REG_DWORD /d 1 /f
其中 BypassRAMCheck 是可选的，用于跳过 4GB 内存检查。
第四步：关闭窗口继续安装
dnf 仓库
dnf repolist #列出启用仓库
def repolist all #列出仓库包含禁用的
#启用/禁用指定仓库
def config-manager --set-enabled epel
def config-manager --set-disabled epel
#添加三方仓库
dnf install epel-release
#缓存
dnf clean all
dnf clean packages #只删除包缓存
dnf clean metadata #只删除元数据
dnf makecache #生成缓存手动刷新用
#dnf与yum不同点
dnf history #可查询dnf的操作历史
dnf history info 12 #12是history中的事务id
dnf history undo 15 #插销第15次操作
dnf history rollback 10 #回滚到第10次之后的状态
#包组
dnf group list
dnf group info "Development Tools" #查看包组详情
def group install "Development Tools" #安装开发工具套件
dnf group rmmove "Development Tools" #卸载开发工具套件包组
#查询
kubectl get pods #查询全部的Pods (默认的命名空间)
kubectl get pods -o wide #查询更多信息:ip,所在节点,重启次数
kubectl get pods --all-namespaces #查询全部的命名空间的pod
#查询 Deployment ,Service,Node,PVC
kubectl get deployments
kubectl get svc
kubectl get nodes
kubectl get pvc
#深入排查
kubectl describe pod <pod名称> #查看pod的详细事件
kubectl describe node <node名称> #查看node的资源压力
get和describe的核心区别是: get -o yaml 看"配置长什么样", describe 看"集群里发生了什么"
#声明配置
kubectl apply -f deployment.yaml #创建或更新资源，可反复执行,幂等
kubectl delete -f deployment.yaml #删除资源
kubectl delete pod <pod名称> #删除指定的pod
kubectl delete deployment <部署名称> #删除deloyment 对应的pod也随着删除
kubectl delete -f deployment.yaml #基于文件删除和apply对应
解释:
为什么用 apply 而不是 create？
create 是命令式，资源已存在时报错；apply 会计算 diff 并更新，与 GitOps 理念一致。
[popexizhi: GitOps理念 :
核心思想：三句话概括
- 整个系统用代码描述：K8s YAML、Terraform 配置、Helm Chart 全部放在 Git。
- Git 是唯一真相源：任何人想改配置，不许登录服务器敲命令，只能提交 Pull Request 改 Git。
- 自动同步：集群里有个“机器人”（如 ArgoCD、Flux）盯着 Git，发现差异就自动应用。
ps:反常识点：kubectl 在生产环境其实是“不推荐”的——因为它绕过了 Git，导致仓库和实际环境不一致。
幂等（Idempotent）最简单的理解是：“一次操作和多次操作，产生的结果是一样的”
]
virsh list
virsh list --all
virsh start <虚拟机名称> #开机
virsh shutdown <虚拟机名称> #关机
virsh destory <虚拟机名称> #强制断电
virsh reboot <虚拟机名称> #重启
virsh suspent <虚拟机名称> #挂起
virsh resume <虚拟机名称> #挂起的恢复
virsh undefine <虚拟机名称> #删除
virsh autostart <虚拟机名称> #随宿主机启动自动重启虚拟机
virsh autostart --disable <虚拟机名称> #随宿主机启动自动重启虚拟机的取消
virsh console <虚拟机名称> #串行控制台接入，无界面方式，但应该是独占模式
虚拟机配置相关
libvirt 的虚拟机配置存储在xml ，more存储为/etc/libvirt/qemu/
virsh dumpxml <虚拟机名称> #查此虚拟机的当前配置
virsh edit <虚拟机名称> #编辑此虚拟机的配置
virsh dumpxml <虚拟机名称> backup.xml #导出配置
查看基本信息
virsh dominfo <虚拟机名称> #查询基本摘要
virsh domiflist <虚拟机名称> #查网卡信息
virsh domblklist <虚拟机名称> #查硬盘信息
virsh vcpulnfo <虚拟机名称> #查vCPU信息
