KVM虚拟机部署K8S重启后/etc/hosts内容丢失

原创 已于 2024-01-01 11:27:06 修改 · 944 阅读 · 9 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#kubernetes #容器 #云原生 #KVM

于 2024-01-01 11:24:28 首次发布
文章讲述了作者在腾讯云上使用KVM部署K8S后，发现/etc/hosts文件内容丢失，导致Pod信息无法获取。问题源于Cloud-Init的初始化操作。作者提供了解决方案，即手动修改Cloud-Init模板，确保/etc/hosts文件在重启后保持自定义配置。

前言

使用KVM开了虚拟机部署K8S，部署完成后重启，节点的pod等信息无法获取到，查看报错初步推测为域名解析失效，查看/etc/hosts后发现安装k8s时添加的内容全部消失

网上搜索一番之后发现了

如果直接修改 /etc/hosts 文件，重启后会还原丢失修改，原因是腾讯云默认使用了 Cloud-Init 进行初始化操作。

官方说明参见：https://cloud.tencent.com/document/product/213/34698

官方描述中说 "2018年9月后使用公共镜像创建的实例不会出现 /etc/hosts 配置在重启后被覆盖的问题"。

然而实际还是会被覆盖。

据我所知腾讯云之类的云服务商大部分都是kvm虚拟化,我推测也可能是采用了 Cloud-Init 进行初始化操作。

所以就手动修改 Cloud-Init 模板：

cd /etc/cloud/templates
ls

会看到很多 hosts.***.tmpl 文件，根据你的Linux发行版进行修改。

为了防止小白问找不到自己发行版，所以这里解释一下：

Ubuntu 是基于 Debian 的衍生版，CentOS7 是 RedHat 源码遵循GPL再编译的版本，CentOS8 以后是 RedHat 的试验田版本。

所以这样就明白了吧。假设你是 CentOS，就修改 "hosts.redhat.tmpl"。

sudo vim hosts.redhat.tmpl

根据你的需要进行修改：

## template:jinja
{#
This file /etc/cloud/templates/hosts.redhat.tmpl is only utilized
if enabled in cloud-config.  Specifically,
最低0.47元/天 解锁文章
云原生之使用minikube快速部署本地k8s集群
jks212454的博客
04-29 1505
云原生之使用minikube快速部署本地k8s集群
3台kvm 使用kubeadm搭建k8s集群
hanguofei的博客
12-03 1171
参考文档（k8s中文社区）：https://www.kubernetes.org.cn/5846.html 一、环境准备 1、3台kvm 3台 2核2G 的 kvm Cent OS 7.6 2、安装后的软件版本为 Kubernetes v1.16.0 calico 3.8.2 nginx-ingress 1.5.5 Docker 18.09.7 二、开始搭建 3台虚拟机里，一台是 master...
k8s动态配置/etc/hosts
weixin_39250340的博客
11-17 1434
k8s动态配置/etc/hosts ###使用命令行修改hosts，完事后保存退出，立即生效 kubectl edit configmap coredns -n kube-system # Please edit the object below. Lines beginning with a '#' will be ignored, # and an empty file will abort the edit. If an error occurs while saving this file
k8s 为pod配置静态DNS解析（相当于/etc/hosts文件）
云原生，DevOps，Kubernetes
05-29 3479
当你的域名不能解析时，相当于需要配置/etc/hosts文件时，可以进行如下配置。注意是修改deploment/daemonset，不是直接修改pod。 $kubectl edit daemonset/deployment database 加入如下hostAliases配置 hostAliases: - ip: "192.168.100.101" hostnames: - "database.ctwifi.cn" containers: - name: ... ...
K8S向pod里的/etc/hosts添加条目
wangmiaoyan的博客
12-31 4644
官方文档地址：https://kubernetes.io/zh/docs/concepts/services-networking/add-entries-to-pod-etc-hosts-with-host-aliases/ 示例，想要pod将bridge4sms解析到对应的ip apiVersion: apps/v1 kind: Deployment metadata: labels: ...
k8s服务发现之使用 HostAliases 向 Pod /etc/hosts 文件添加条目
linus.lin的博客
07-26 2427
某些情况下，DNS 或者其他的域名解析方法可能不太适用，您需要配置 /etc/hosts 文件，在Linux下是比较容易做到的，在 Kubernetes 中，可以通过 Pod 定义中的字段向 Pod 的 /etc/hosts 添加条目。适用其他方法修改 Pod 的 /etc/hosts 文件是不被推荐的，因为 kubelet 可能在重新创建 Pod 时，就会覆盖这些修改。
k8s集群的节点重启后镜像丢失问题的排查过程
SENDFREE的专栏
08-21 2446
在私有环境中搭建了k8s集群(opensuse15.1 + kubernetes 1.18 + cri-o 1.17)，k8s和应用的镜像均在本地通过 podman 导入， 底层 OCI 使用的是 cri-o。 在测试过程中发现每次 node 节点重启后都会有一些镜像丢失，基本上 kube-proxy 和 flannel 每次都会丢失， 有的时候会有更多的镜像丢失。分析这些丢失的镜像很有规律，不是随机丢的，也没有发现其他文件丢失的情况，所以排除文件系统故障，怀疑...
kvm 分布式集群部署
Linux运维老纪的博客
08-22 1722
本章案例主要使用之前章节所学的 KVM 及 GlusterFS 技术，结合起来从而实现 KVM 高 可用。利用 GlusterFS 分布式复制卷，对 KVM 虚拟机文件进行分布存储和冗余。分布式复 制卷主要用于需要冗余的情况下把一个文件存放在两个或两个以上的节点，当其中一个节点 数据丢失或者损坏之后，KVM 仍然能够通过卷组找到另一节点上存储的虚拟机文件，以保 证虚拟机正常运行。当节点修复之后，GlusterFS 会自动同步同一组卷组里面有数据的节点 数据。
kubernetes实战（1）之虚拟机centos搭建k8s集群
thinkers
03-15 977
安装网络插件，否则 node 是 NotReady 状态（主节点跑），这里使用方式2 weave执行。启动 kubelet、docker，并设置开机启动（所有节点）修改 docker 配置（所有节点）把工作节点加入集群（只在工作节点跑）初始化集群（仅在主节点跑），安装所需组件（所有节点）添加安装源（所有节点）
潦草的记录docker 容器修改/etc/hosts文件不生效的问题
qq_37764428的博客
06-28 2928
docker 容器修改/etc/hosts文件不生效
docker/k8s修改容器hosts文件
热门推荐
宫凯宁的博客
06-27 1万+
docker镜像本质上是一个包含了整个操作系统的文件和目录的rootfs，用户制作镜像的每一步操作都会生成一个层，也就是一个增量的rootfs。 docker容器的rootfs由只读层，init层和可读写层。 我们的/etc/hosts和/etc/resolv.conf等只对当前容器生效的信息会保留在init层，进行docker commit时不会提交这一层的信息。 所以Dockerfile中对/...
Docker容器应用中常见问题的解决：自定义hosts重启丢失、停止容器报错、启动后台任务报错、禁用ipv6
本博客记录了从2014年以来在工作学习中遇到的技术问题、解决方法以及部分个人人生经历、经验等内容。
04-09 1659
在docker容器中手动修改了hosts增加了一些域名的解析，但对容器进行重启后hosts全部丢失了。因为容器中的/etc/hosts,、/etc/resolv.conf、/etc/hostname这三个文件并不存在于镜像中，而是存在于宿主机的/var/lib/docker/containers/目录中，在重启docker容器时会通过mount的形式将这些文件挂载到容器内部。因此会覆盖容器中对这些文件的手动修改。
K8s主机IP地址变更集群恢复
qq_43571324的博客
12-11 3026
k8s主机IP变更集群恢复
K8s集群故障(The connection to the server... was refused - did you specify the right host or port)解决
山河已无恙
02-09 2072
过年回家整理集群相关的笔记，发现集群不能用了.简单记录解决办法,其实就是证书过期了，但是提示和之前的不一样。理解不足小伙伴帮忙指正不必太纠结于当下，也不必太忧虑未来，当你经历过一些事情的时候，眼前的风景已经和从前不一样了。——村上春树。
kubernetes（k8s） 知识总结（第1期）
yspg_217的博客
06-10 1016
容器必知必会
重启docker容器后容器里的hosts文件配置消失解决方案
weixin_49070722的博客
05-22 2376
1、进入容器2、追加配置到容器里的hosts文件（不能用vim时）3、重启容器，发现相应的hosts文件新增的配置消失。
k8s配置hosts域名的几种方式
阿甘兄
10-21 3488
k8s配置hosts域名的两种方式
【k8s】数据存储
manyulanlanlu的博客
11-07 611
pod的生命周期可能很短，会被频繁地创建和销毁。那么容器在销毁时，保存在容器中的数据也会被清除。这种结果对用户来说，在某些情况下是不乐意看到的。为了持久化保存容器的数据，kubernetes引入了Volume的概念。Volume是Pod中能够被多个容器访问的共享目录，它被定义在Pod上，然后被一个Pod里的多个容器挂载到具体的文件目录下。kubernetes通过Volume实现同一个Pod中不同容器之间的数据共享以及数据的持久化存储。Volume的生命周期不与Pod中单个容器的生命周期相关，当容器终止或者重
docker容器/etc/hosts文件（xqplatformIp、jhkdata）
Dontla的博客
06-13 6179
例如，如果容器需要访问主机上的某个服务，可以将主机名和IP地址的映射关系写入/etc/hosts文件中，这样容器就可以直接使用IP地址进行访问，而无需通过DNS服务器进行解析。如果需要在容器内永久保存修改后的/etc/hosts文件，可以将其挂载到宿主机上的一个文件中，然后在容器启动时将该文件挂载到容器内的/etc/hosts文件中。注意：如果在容器内修改了/etc/hosts文件，需要手动同步到宿主机上的/etc/hosts.container文件中，否则容器重启后修改将会丢失。
kvm虚拟机重启后进入了 dracut:/#模式
最新发布
06-27
<think>我们正在处理用户关于KVM虚拟机重启后进入dracut紧急模式的问题。根据用户的问题，我们需要分析原因并提供解决方案。首先，我们需要理解dracut紧急模式的含义：当系统启动时无法加载根文件系统（rootfs）时，会进入dracutshell。这通常是由于内核无法找到或挂载根文件系统导致的。可能的原因：1.根文件系统设备在启动时不可用（例如，磁盘设备路径改变、UUID错误等）。2.文件系统损坏。3.驱动缺失（例如，没有加载相应的磁盘控制器驱动）。4.内核启动参数（如root=）设置不正确。5.磁盘设备在initramfs中未被正确识别（可能需要重新生成initramfs）。6.其他硬件问题（如磁盘故障）。解决方案：1.在dracutshell中尝试手动挂载根文件系统，以确定问题。2.检查启动参数（通过/proc/cmdline）和磁盘设备。3.重新生成initramfs（需要进入救援模式）。4.修复文件系统（使用fsck）。5.调整虚拟机配置（例如磁盘控制器类型）或内核参数。具体步骤：步骤1：在dracutshell中获取信息在dracut:/#提示符下，可以执行以下命令：-查看磁盘设备：`lsblk`或`cat/proc/partitions`-查看内核启动参数：`cat/proc/cmdline`-尝试挂载根文件系统：例如，如果根文件系统在/dev/vda1上，则尝试：mkdir/mntmount/dev/vda1/mnt如果挂载失败，注意错误信息（可能是文件系统损坏，需要fsck）。步骤2：如果根文件系统挂载成功，则检查文件系统-检查/etc/fstab文件：确保根文件系统的配置正确（特别是UUID或设备路径）。-检查/boot/grub2/grub.cfg（或类似路径）中的启动参数。步骤3：如果根文件系统挂载失败，则尝试修复-使用fsck修复：例如，`fsck/dev/vda1`（注意：在挂载状态下运行fsck可能会导致数据损坏，所以应该在未挂载时运行。在dracut环境中，文件系统通常没有被挂载，因此可以尝试修复。但如果是根文件系统，可能需要指定类型，如`fsck.ext4/dev/vda1`）步骤4：如果磁盘设备没有被识别-可能是initramfs中缺少驱动。需要重新生成initramfs，但这通常需要进入一个可工作的系统（例如使用LiveCD进入救援模式）。步骤5：进入救援模式-如果虚拟机无法正常启动，可以使用安装ISO进入救援模式（例如，在KVM中，将虚拟机的CDROM设置为安装ISO，并从CDROM启动）。-在救援模式中，挂载根文件系统，然后检查并修复问题：chroot/mnt/sysimage#进入原系统环境#重新生成initramfs（以CentOS为例）dracut--force#检查grub配置（如果需要）grub2-mkconfig-o/boot/grub2/grub.cfg#检查/etc/fstabexitreboot步骤6：检查虚拟机配置-在宿主机上，检查虚拟机的磁盘配置（例如，磁盘控制器类型）。有时，使用virtio磁盘需要特定的驱动，如果initramfs中没有包含，则可能导致启动失败。确保initramfs包含virtio驱动（对于CentOS/RHEL，通常包含virtio驱动，但有时可能被排除）。-可以尝试在虚拟机XML配置中更改磁盘控制器类型（例如，从virtio改为ide），但这不是推荐做法，因为virtio性能更好。如果更改，需要确保系统能够识别ide设备。步骤7：检查内核参数-在grub启动菜单中，可以临时编辑启动参数（在启动时按e键进入编辑模式），检查root=参数是否正确（例如，root=/dev/vda1或root=UUID=...）。如果使用UUID，确保UUID与磁盘的实际UUID一致（可以通过`blkid`命令查看）。步骤8：其他可能的原因-如果虚拟机磁盘是qcow2格式，可能由于磁盘镜像损坏导致。可以尝试在宿主机上检查并修复镜像：`qemu-imgcheck-fqcow2/path/to/image.qcow2`，然后修复（如果支持修复选项）。-如果磁盘空间不足，也可能导致启动失败。在dracutshell中，如果能够挂载根文件系统，检查磁盘空间。根据引用[1]中的内容，我们注意到有关于清理KVM环境的命令，但这与当前问题关系不大。引用[2]中提到虚拟化类型改为kvm，但用户已经使用KVM，所以可能不是虚拟化类型的问题。引用[3]是关于yum仓库的修复，也不直接相关。但是，我们可以参考引用[2]中关于虚拟化类型配置的位置：/etc/nova/nova.conf中的virt_type。如果用户使用的是OpenStack，那么虚拟机的虚拟化类型是kvm，所以驱动问题可能是关键。因此，我们建议的解决方案重点在检查根文件系统、修复文件系统、重新生成initramfs以及检查虚拟机配置（尤其是磁盘驱动）上。生成相关问题：1.如何防止KVM虚拟机启动时进入dracut紧急模式？2.在KVM中如何正确配置磁盘控制器以避免启动问题？3.如何修复损坏的qcow2磁盘镜像？4.在救援模式下如何修复Linux系统启动问题？注意：在回答中，我们不需要直接引用上述引用内容，因为它们与当前问题关联不大。我们主要根据KVM虚拟机和dracut的一般知识来回答。现在，我们将以上分析整理成结构清晰的回答。</think>### KVM虚拟机重启后进入dracut紧急模式的原因及解决方案 #### 问题原因分析 当KVM虚拟机重启后进入`dracut:/#`紧急模式，通常是由于系统无法挂载根文件系统(rootfs)导致。主要原因包括： 1. **根文件系统设备变更** - 虚拟机磁盘设备路径改变（如从`/dev/vda`变为`/dev/vdb`） - 磁盘UUID冲突或变更（克隆虚拟机时常见） - 文件系统标签(label)丢失 2. **文件系统损坏** - 异常关机导致文件系统结构损坏 - 磁盘空间耗尽或inode耗尽 3. **驱动缺失** - initramfs镜像未包含必要的磁盘控制器驱动（如virtio-blk） - 内核升级后驱动不兼容 4. **配置错误** - `/etc/fstab`配置错误或设备标识符失效 - GRUB启动参数`root=`设置错误 - 磁盘控制器类型不匹配（如IDE改为VirtIO） #### 解决方案步骤 ##### 步骤1：在dracut shell中诊断问题 ```bash dracut:/# lsblk # 查看磁盘设备列表 dracut:/# blkid # 检查磁盘UUID和文件系统类型 dracut:/# cat /proc/cmdline # 查看GRUB启动参数中的root设备 ``` - **关键检查项**： - 确认`root=`参数指定的设备（如`root=/dev/vda1`）是否与实际设备一致 - 检查目标磁盘是否被识别（如`vda`、`sda`等） ##### 步骤2：尝试手动挂载根分区 ```bash dracut:/# mkdir /mnt/root dracut:/# mount /dev/vda1 /mnt/root # 替换为实际设备名 ``` - **若挂载失败**： - 文件系统损坏 → 跳转步骤3 - 设备未识别 → 跳转步骤4 ##### 步骤3：修复文件系统 ```bash dracut:/# fsck -y /dev/vda1 # 修复ext4/xfs等文件系统 dracut:/# xfs_repair /dev/vda1 # 针对XFS文件系统 ``` ##### 步骤4：重建initramfs（需救援模式） 1. 挂载系统分区： ```bash dracut:/# mount /dev/vda1 /mnt/root dracut:/# mount /dev/vda2 /mnt/root/boot # 如存在单独boot分区 dracut:/# chroot /mnt/root ``` 2. 重建initramfs： ```bash sh-4.2# dracut -f --add-drivers "virtio_blk virtio_pci" # 强制重建并添加驱动 sh-4.2# grub2-mkconfig -o /boot/grub2/grub.cfg # 更新GRUB配置 ``` ##### 步骤5：检查虚拟机配置 1. **确认磁盘控制器类型**： ```xml <!-- 虚拟机XML配置示例 --> <disk type='file' device='disk'> <driver name='qemu' type='qcow2'/> <target dev='vda' bus='virtio'/> <!-- 确保bus='virtio' --> </disk> ``` - 若原系统使用IDE(`bus='ide'`)，切换为VirtIO需在initramfs中添加驱动 2. **修复磁盘路径**： - 编辑`/etc/fstab`，将设备路径改为UUID： ```bash /dev/vda1 => UUID=5e4e5c8d-1... / xfs defaults 0 0 ``` 使用`blkid`获取实际UUID ##### 步骤6：宿主机操作（可选） - **检查磁盘镜像**： ```bash qemu-img check /var/lib/libvirt/images/vm.qcow2 ``` - **修复磁盘分配**（参考引用[2]）： - 确认宿主机磁盘资源未超配：`CONF.disk_allocation_ratio = 1.0` #### 预防措施 1. 系统克隆后： - 立即修改UUID：`tune2fs -U random /dev/vda1` - 更新GRUB和fstab中的UUID引用 2. 定期维护： ```bash # 清理旧内核和initramfs package-cleanup --oldkernels --count=1 ``` 3. 确保initramfs包含必要驱动： ```bash # 在虚拟机内检查驱动 lsinitrd /boot/initramfs-$(uname -r).img | grep virtio ``` > **注意**：若磁盘控制器类型更改（如IDE转VirtIO），需在更改前在虚拟机内安装`virtio-drivers`： > ```bash > yum install virtio-win-drivers # CentOS/RHEL > ```
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

java-superchen

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值