闽侯网站建设,php免费网站源码,wordpress好还是dz好,经典 网站使用 kubectl exec 执行指令
如果您在 Kubernetes 上运行软件#xff0c;您会想要在某些时候去调试您所部署的软件的一些方面。对于习惯于使用虚拟机 (VMs) 的人来说能自然使用的一种简单的调试方法#xff0c;就是连接到一个正在运行的 pod#xff0c;然后进行解译:
ku…使用 kubectl exec 执行指令
如果您在 Kubernetes 上运行软件您会想要在某些时候去调试您所部署的软件的一些方面。对于习惯于使用虚拟机 (VMs) 的人来说能自然使用的一种简单的调试方法就是连接到一个正在运行的 pod然后进行解译:
kubectl exec -it podname -c containername -- bash这通常行之有效而且非常管用。然而至少有两种 Kubernetes 最佳实践 限制了 exec 的实用性:
不以 root 用户身份运行。容器尽可能以最少的特权运行甚至可能使用随机的用户标识符 (UID) 运行。 最小化镜像。镜像尽可能小你甚至可以将二进制文件写入到 distroless image。
当应用这些最佳实践时使用 kubectl exec连接到您的容器要么不可行要么进入到不适合进行调试的环境。 kubectl exec 指令不允许指定用户标志或能力以启动进程而是会从目标容器的主指令中复制这些设置。 调试容器
在解决运行容器问题时Kubernetes 提供了一种原生化调试策略即使用 kubectl debug。调试指令会在运行中的 pod 中启动一个新的容器。这个新容器能够以不同的用户身份以及从您选择的任何镜像去运行。由于调试容器与目标容器位于同一个 pod 中运行(因此在同一个节点上)两者之间不需要绝对的隔离。调试容器可以与同一 pod 中运行的其他容器共享系统资源。
考虑去检查在 pod postpod中的容器 postcont里运行的 PostgreSQL 数据库的 CPU 使用情况。这个 pod 并不以 root 用户身份运行并且 Postgres 镜像没有安装类似 top 或 htop 的工具也就是说kubectl exec指令几乎没有作用。您可以按照以下的指令去运行:
kubectl debug -it \ --containerdebug-container \ --imagealpine \ --targetpostcont \ postpod您将以 root 身份登录(这是 Alpine 镜像的默认设置)并可以轻松安装您最喜欢的交互式进程查看器 htop (apt add htop)。您与 postcont容器共享同一个进程命名空间可以查看并甚至终止在此运行的所有进程当您退出进程时临时容器也会终止。 如果希望调试容器与 postcont共享相同的进程命名空间即使 postcont是在 postpod中运行的唯一容器指定 --target是不具备选择性的 (non-optional)。 您可以按 CTRLP CTRLD 断开与临时容器/bash 会话 (session) 的连接而无需退出 (终止) 它。再使用 kubectl attach即可重新连接。 kubectl debug提供的功能比这里概述的更多比如使用一个修改后的启动指令复制 pods或通过访问节点文件系统的启动一个 节点 (node) pod。 原理解释
以上的 kubectl debug指令是通过创建临时容器 (ephemeral container) 来实现。这些容器应在现有 pod 中临时运行以支持故障排除等操作。“普通”容器和临时容器之间的区别很小。而查看 Kubernetes 在创立之初所做的基础架构选择最能让我们理解使用临时容器的原因: Pod 应该是一次性的、可替换的并且 Pod 规范也是不可改变的。 当 Kubernetes 主要用于部署无状态工作负载时这一点更加合理——因为此时 pod 本身会被认为是临时的。在这个 Kubernetes 中它可能会受到限制。Pod 规范保持不变但 Kubernetes 会将临时容器作为 Pod 的子资源建模。与“普通”容器不同临时容器不属于 Pod 规范的一部分。 挂载卷 (volumes)
内置指令 kubectl debug非常有用。它允许您在运行的 pod 中添加一个临时容器并可选择与运行中的容器共享进程命名空间。不过如果您希望使用 kubectl debug来检查或修改运行中容器文件系统的某个部分那就不走运了——因为调试 pod 的文件系统与您将其连接到的容器的文件系统是分离的。幸运的是我们可以做的更好。原理很简单:
读取正在运行的目标容器的规范。 将一个临时容器填充到 pod 中。将其配置成与目标容器共享相同的进程命名空间并包含相同的卷挂载。 因为没有用于创建临时容器的 kubectl 命令所以我们需要构建一个 PATCH 请求到 K8s API 来创建它。kubectl proxy指令允许访问 K8s API。这一过程对用户来说并不太友好因此将这一过程封装到脚本或 kubectl 插件中是合理的。您可以在这里找到这样一个脚本实现示例:
https://github.com/JonMerlevede/kubectl-superdebug?sourcepost_page-----2ba160c47ef5------ 需要注意的是这种方法和脚本可以很容易地扩展到从目标容器中复制环境变量的规范。如果您将此脚本保存为 kubectl-superdebug并将其放在您的路径上就可以在任何地方以 kubectl superdebug的形式运行如下所示: 还可以尝试扩展此脚本将目标容器的其他方面复制到调试容器中例如环境变量引用。 至此Kubernetes 本机调试运行中的容器的方法概述就完成了应该能满足大多数人的需求。
非 Kubernetes 原生方法
Kubernetes 不提供以 root 身份连接到正在运行的容器的方法除非主进程以 root 身份运行也不提供从另一个容器访问容器根文件系统的方法。但这并不意味着这些事情不可能做到。毕竟 Kubernetes 只是一个位于容器化引擎之上的容器编排器。如果出于某种原因确实有必要的话您通常可以通过移除抽象层来做任何您想做的事。
如果您使用的是 Docker 引擎并且可以直接从节点或通过节点上运行的特权容器访问您的引擎那么您就可以运行 docker exec --user并以您选择的用户身份执行一个进程。 kubectl ssh和 kubectl exec-user等插件实现了这种方法。但遗憾的是containerd 和 CRI-O 等现代引擎不再提供 --user这样标志功能这意味着这些插件无法在当下的 Kubernetes 安装上运行。
不过即使是这些现代引擎通常也只是与 Linux 命名空间接口。通过输入相应的 Linux 命名空间集您可以在任何您想要的“容器”中运行指令。kpexec 工具实现了这种方法。它在与目标容器相同的节点上启动一个有权限的 pod然后确定要针对哪些 (Linux) 命名空间在这些 (Linux) 命名 空间中执行命令最后将其输出流式传输到您的终端。作为额外的收获它还能在目标容器的文 件系统之上叠加一套用于调试的工具。 与 kubectl exec 不同kpexec 可以使用不同的 uid/gid 运行指令甚至可以使用与容器主进程不同的功能。它与 containerd 和 cri-o 兼容。只是 kpexec 采用的方法有些笨重和脆弱可能与集群的安全配置不兼容。但如果 kubectl (super) 调试无法满足您的需求则值得考虑它。 需要注意kpexec 使用 nsenter 是直接在命名空间中执行指令的。它与无处不在的容器运行时 runc 兼容但与 Kata Containers 等运行时不兼容。 借助 Appilot 对话式诊断 K8s
Appilot 是一款面向 DevOps 场景的开源 AI 助手它可以充分利用 AI 大语言模型的能力让用户直接输入自然语言进一步简化应用部署与管理体验。用户可以根据自身的需求和使用习惯将 Appilot 集成到任意平台进而实现通过输入自然语言即可调用后端平台的能力轻松完成 Kubernetes debug 工作。 Appilot 项目地址 https://github.com/seal-io/appilot
