Kubernetes 临时容器：增强生产集群安全性并简化故障排除

教程

Kubernetes

Kubernetes 中的临时容器是一个强大的功能，允许操作人员通过在同一个 Pod 中创建短暂存在的容器来调试和排查正在运行的 Pod。这对于无法在单独的环境中复制的问题尤为有帮助。通过使用临时容器，您可以将一个容器附加到运行中的 Pod，检查文件系统、网络设置或运行中的进程，然后丢弃容器而不会影响 Pod 的主要容器。

什么是临时容器？

临时容器是特殊容器，不作为应用工作负载的一部分运行，而是添加到现有 Pod 中进行调试。它们与 Pod 中的其他容器共享相同的资源（网络命名空间、卷等），使其成为实时诊断的理想选择。调试完成后，临时容器可以被移除，而无需重新创建整个 Pod。

关键要点

短暂存在：临时容器仅用于调试或故障排除。
非破坏性：它们不会影响 Pod 中现有的应用容器。
资源共享：它们与 Pod 共享资源，如存储卷和网络命名空间，使调试更加强大。

使用临时容器时的安全考虑

短暂容器通过限制对生产 Pods 的长期访问提供了一种更安全的调试方法。您可以强制执行严格的 RBAC 规则，以便只有授权用户可以添加和运行短暂容器，从而最小化潜在威胁的窗口。由于这些容器在调试完成后会消失，因此攻击面减少，从而增强整体集群安全性。

用例

故障排除应用程序崩溃：当您需要检查日志或在崩溃或正在崩溃的容器中运行调试工具时，短暂容器允许您进入运行环境而无需更改主容器的配置。
网络调试：您可以在短暂容器中安装调试工具（例如 tcpdump、netstat）以诊断 Pod 的网络命名空间中的网络问题。
实时文件系统检查：如果您怀疑文件损坏或文件路径不正确，短暂容器允许您实时检查文件系统。

前提条件

Kubernetes 版本：短暂容器需要至少 Kubernetes 1.23 及以上版本，其中短暂容器功能已普遍可用（GA）。在旧版本的 Kubernetes 中，您可能需要启用功能门 EphemeralContainers。
kubectl：确保您的本地 kubectl 客户端版本至少与集群的控制平面相同或更新。
足够的RBAC权限: 您需要具有使用kubectl debug命令以及更新Pods（通过更新Pod规范添加临时容器）的权限。

逐步指南：使用临时容器

以下是一个通用的流程，适用于任何Kubernetes环境，包括EKS（亚马逊弹性Kubernetes服务），AKS（Azure Kubernetes服务），GKE（谷歌Kubernetes引擎）或本地集群。我们将重点介绍kubectl debug命令，这是添加临时容器的主要机制。

验证集群配置

Shell

kubectl version

确保您的服务器版本至少为1.23。
确认您的客户端版本也兼容。

如果您在像EKS或AKS这样的托管环境中，请从您的云提供商的仪表板或CLI中检查集群版本，以确保其为1.23或更高。

识别要调试的Pod

列出特定命名空间中的Pods：

Shell

kubectl get pods -n <your-namespace>

选择您需要排查故障的Pod名称，例如：my-app-pod-abc123。

使用kubectl debug添加临时容器

使用kubectl debug命令添加临时容器。例如，我们将使用一个简单的Ubuntu镜像：

Shell

kubectl debug my-app-pod-abc123 -n <your-namespace> \

  --image=ubuntu \

  --target=my-container \

  --interactive=true \

  --tty=true

以下是标志的详细说明：

my-app-pod-abc123：现有Pod的名称。
–image=ubuntu: 用于临时容器的 Docker 镜像。
–target=my-container:（可选）指定要为命名空间共享目标的 Pod 中的容器。通常，这是 Pod 中的主要容器。
–interactive=true 和 –tty=true: 允许您在临时容器内获取一个 shell 会话。

运行上述命令后，您将在现有 Pod 内的临时容器中获得一个 shell 提示符。现在您可以运行像 ls、ps、netstat 或安装额外软件包等调试命令。

确认临时容器创建

在另一个终端中，或在退出临时容器的 shell 后，运行：

Shell

kubectl get pod my-app-pod-abc123 -n <your-namespace> -o yaml

您应该看到一个新的部分在 spec 或 status 下描述了临时容器。

调试和故障排除

在临时容器内部，您可以：

检查日志或 应用程序配置。
使用像 curl、wget、telnet 这样的调试工具来验证网络连接。
检查 环境变量 以确认应用程序的配置。

Shell

# Examples

curl http://localhost:8080/health

env | grep MY_APP_

ps aux

清理临时容器

短暂容器在 Pod 被销毁或您手动移除它们后会自动被移除。要在不销毁整个 Pod 的情况下从 Pod 中移除短暂容器（在支持的版本上），您可以修补 Pod 规格。然而，通常短暂容器并不打算长时间存在。一旦您删除 Pod 或缩减部署，短暂容器也会被移除。

托管服务的具体说明

亚马逊 EKS

确保您的 EKS 集群运行的是 Kubernetes 1.23 或更高版本。
确认 IAM 权限允许您执行 kubectl debug。
如果您使用的是旧版本的 EKS（1.22 或更早），您需要启用 EphemeralContainers 功能开关。

微软 Azure AKS

如有必要，使用 Azure CLI（az aks update）升级您的 AKS 集群到兼容版本。

确认您的 kubectl 上下文设置为 AKS 集群：

Shell

az aks get-credentials --resource-group <rg-name> --name <cluster-name>

其他托管或本地集群

查看您集群的文档或询问您的服务提供商以确认短暂容器已启用。
大多数现代本地解决方案（如 OpenShift、Rancher 等）在 Kubernetes 1.23 及更高版本中默认启用短暂容器，但如果您使用的是旧版本，则可能需要手动启用该功能开关。

最佳实践

使用最小化镜像：选择轻量级镜像以减少开销（例如，busybox、无发行版调试镜像）。
限制RBAC：限制谁可以创建临时容器，以减少潜在的安全风险。
记录所有调试会话：跟踪临时容器的使用情况，以便审计和合规。
不要依赖临时容器：它们仅用于调试。如果需要永久的侧车或辅助容器，请从一开始就配置在Pod规格中。

结论

临时容器是一种灵活且强大的方式，可以实时排查问题，而不会影响主要应用容器。无论您是在EKS、AKS、内部部署还是其他托管解决方案上运行Kubernetes，理解和使用临时容器都可以显著减少您的平均恢复时间（MTTR）并提高运营效率。

它们补充了传统的故障排除方法，应成为任何平台团队诊断复杂应用问题工具包的一部分。通过遵循上述步骤，您可以自信地在您的环境中部署临时容器，并简化调试流程。

作者的说明：本指南基于现实世界的Kubernetes故障排除，旨在帮助您在生产环境中快速且无干扰地调试Pods。

Source:
https://dzone.com/articles/enhancing-security-troubleshooting-in-production-clusters