2-3分钟后，Kubectl Exec停止/关闭
我正在尝试备份在K8S群集（K3S）内运行的MySQL数据库。该集群在Raspberry Pi上本地运行。我已经建立了一个基于Alpine Linux的自定义映像，该映像包含一个脚本以使用mySqlDump：
kubectl exec＆lt; pod_name＆gt; -n＆lt; nesspace_name＆gt; - /usr/bin/mysqldump -u＆lt; db_user＆gt; -password =＆lt; db_password＆gt; - Verbose＆lt; db_name＆gt; ＆gt; ＆lt; file_name＆gt;
当我从数据库吊舱内运行mysqldump命令时，它在10-15秒后成功完成。但是，当此命令从高山吊舱内执行时，它以某种方式需要更长的时间（2M40）。那时，它停止/中止kubectl exec命令（由于超时吗？），并且脚本上传了损坏的SQL文件，因为MySqlDump命令尚未完成备份。
预期的冗长输出：
-- Connecting to localhost...
-- Retrieving table structure for table _prisma_migrations...
-- Sending SELECT query...
-- Retrieving rows...
-- Retrieving table structure for table database...
-- Sending SELECT query...
-- Retrieving rows...
-- Retrieving table structure for table recycleBin...
-- Sending SELECT query...
-- Retrieving rows...
-- Retrieving table structure for table user...
-- Sending SELECT query...
-- Retrieving rows...
-- Disconnecting from localhost...
接收到的冗长输出：
-- Connecting to localhost...
-- Retrieving table structure for table _prisma_migrations...
-- Sending SELECT query...
-- Retrieving rows...
-- Retrieving table structure for table database...
-- Sending SELECT query...
-- Retrieving rows...
-- Retrieving table structure for table recycleBin...
-- Sending SELECT query...
-- Retrieving rows...
我有2个问题：
- 与数据库POD相比，为什么MySqlDump命令在高山吊舱中需要更长的时间？
- 为什么Kubectl Exec命令不等待直到MySqlDump命令完成备份？为什么突然决定是时候断开连接并继续前进？
I'm trying to backup a MySQL database running inside a k8s cluster (k3s). This cluster is running locally on a Raspberry Pi. I've built a custom image based on Alpine Linux that contains a script to create the backup using mysqldump:
kubectl exec <pod_name> -n <namespace_name> -- /usr/bin/mysqldump -u <db_user> --password=<db_password> --verbose <db_name> > <file_name>
When I run the mysqldump command from inside the database pod, it completes successfully after 10-15 seconds. But when this command gets executed from inside the Alpine pod it somehow takes a lot longer (2m40s). At that point it stops/aborts the kubectl exec command (due to a timeout?) and the script uploads a corrupt sql file because the mysqldump command wasn't finished with the backup.
Expected verbose output:
-- Connecting to localhost...
-- Retrieving table structure for table _prisma_migrations...
-- Sending SELECT query...
-- Retrieving rows...
-- Retrieving table structure for table database...
-- Sending SELECT query...
-- Retrieving rows...
-- Retrieving table structure for table recycleBin...
-- Sending SELECT query...
-- Retrieving rows...
-- Retrieving table structure for table user...
-- Sending SELECT query...
-- Retrieving rows...
-- Disconnecting from localhost...
Received verbose output:
-- Connecting to localhost...
-- Retrieving table structure for table _prisma_migrations...
-- Sending SELECT query...
-- Retrieving rows...
-- Retrieving table structure for table database...
-- Sending SELECT query...
-- Retrieving rows...
-- Retrieving table structure for table recycleBin...
-- Sending SELECT query...
-- Retrieving rows...
I have 2 questions:
- Why does the mysqldump command take so much longer in the Alpine pod compared to the database pod?
- Why isn't the kubectl exec command waiting until the mysqldump command has finished taking the backup? Why does it suddenly decide it's time to disconnect and move on?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您可能会断开连接，因为
kubectl认为由于另一侧没有数据，该连接已死。而不是：
kubectl exec＆lt; pod_name＆gt; -n＆lt; nesspace_name＆gt; - /usr/bin/mysqldump -u＆lt; db_user＆gt; -password =＆lt; db_password＆gt; - Verbose＆lt; db_name＆gt; ＆gt; ＆lt; file_name＆gt;尝试：
kubectl exec＆lt; pod_name＆gt; -n＆lt; nesspace_name＆gt; - /usr/bin/mysqldump -u＆lt; db_user＆gt; -password =＆lt; db_password＆gt; - Verbose＆lt; db_name＆gt; | Tee＆lt; file_name＆gt;这将输出到stdout以及发送到文件。这将确保Kubectl会看到数据返回，并且如果这是一个无数据问题，则不会断开您的连接。不利的一面是，您正在将整个SQL数据在STDOUT上泵回您
（以及我个人建议），正在安装
screen> screen>或tmux之类的东西。 /code>或其他终端多路复用器并在其中进行转储，因此您可以与POD断开连接，而不必担心Kubectl断开您的连接。编辑：只是为了澄清，我的意思是在吊舱内安装多路复用器（例如，您用于创建POD的Docker图像中）
It is possible that you're getting disconnected because
kubectlthinks the connection is dead due to no data from the other side.Instead of:
kubectl exec <pod_name> -n <namespace_name> -- /usr/bin/mysqldump -u <db_user> --password=<db_password> --verbose <db_name> > <file_name>Try:
kubectl exec <pod_name> -n <namespace_name> -- /usr/bin/mysqldump -u <db_user> --password=<db_password> --verbose <db_name> | tee <file_name>This will instead output to stdout as well as sending to the file. This will guarantee that kubectl will see data coming back and will not disconnect you if this is a no-data problem. The downside to this is that you are getting the entire SQL data being pumped back to you on stdout
The other alternative (and one I would personally recommend), is installing something like
screenortmuxor another terminal multiplexer and doing the dump in that so you can disconnect from the pod and not worry about kubectl disconnecting you.EDIT: Just to clarify, I meant installing the multiplexer inside the pod (e.g. inside the docker image you use to create the pod)