一、用 Kubectl 调试 Kubernetes 节点

1、准备开始

你必须拥有一个 Kubernetes 的集群，同时你必须配置 kubectl 命令行工具与你的集群通信。 建议在至少有两个不作为控制平面主机的节点的集群上运行本教程。 如果你还没有集群，你可以通过 Minikube 构建一个你自己的集群，或者你可以使用下面的 Kubernetes 练习环境之一：

• Killercoda
• 玩转 Kubernetes

你的 Kubernetes 服务器版本必须不低于版本 1.2. 要获知版本信息，请输入kubectl version.

你需要有权限创建 Pod 并将这些新 Pod 分配到任意节点。 你还需要被授权创建能够访问主机上文件系统的 Pod。

2、使用kubectl debug node调试节点

使用 kubectl debug node 命令将 Pod 部署到要排查故障的节点上。 此命令在你无法使用 SSH 连接节点时比较有用。 当 Pod 被创建时，Pod 会在节点上打开一个交互的 Shell。 要在名为 “mynode” 的节点上创建一个交互式 Shell，运行：

kubectl debug node/mynode -it --image=ubuntu

Creating debugging pod node-debugger-mynode-pdx84 with container debugger on node mynode.
If you don't see a command prompt, try pressing enter.
root@mynode:/#

调试命令有助于收集信息和排查问题。 你可能使用的命令包括 ip、ifconfig、nc、ping 和 ps 等等。 你还可以从各种包管理器安装 mtr、tcpdump 和 curl 等其他工具。

说明：

这些调试命令会因调试 Pod 所使用的镜像不同而有些差别，并且这些命令可能需要被安装。

用于调试的 Pod 可以访问节点的根文件系统，该文件系统挂载在 Pod 中的 /host 路径。 如果你在 filesystem 名字空间中运行 kubelet， 则正调试的 Pod 将看到此名字空间的根，而不是整个节点的根。 对于典型的 Linux 节点，你可以查看以下路径找到一些重要的日志：

/host/var/log/kubelet.log

负责在节点上运行容器的 kubelet 所产生的日志。

/host/var/log/kube-proxy.log

负责将流量导向到 Service 端点的 kube-proxy 所产生的日志。

/host/var/log/containerd.log

在节点上运行的 containerd 进程所产生的日志。

/host/var/log/syslog

显示常规消息以及系统相关信息。

/host/var/log/kern.log

显示内核日志。

当在节点上创建一个调试会话时，需谨记：

• kubectl debug 根据节点的名称自动生成新 Pod 的名称。
• 节点的根文件系统将被挂载在 /host。
• 尽管容器运行在主机 IPC、Network 和 PID 名字空间中，但 Pod 没有特权。 这意味着读取某些进程信息可能会失败，这是因为访问这些信息仅限于超级用户 (superuser)。 例如，chroot /host 将失败。如果你需要一个有特权的 Pod，请手动创建。

3、清理现场

当你使用正调试的 Pod 完成时，将其删除：

kubectl get pods

NAME                          READY   STATUS       RESTARTS   AGE
node-debugger-mynode-pdx84    0/1     Completed    0          8m1s

# 相应更改 Pod 名称
kubectl delete pod node-debugger-mynode-pdx84 --now

pod "node-debugger-mynode-pdx84" deleted

说明：

如果节点停机（网络断开或 kubelet 宕机且无法启动等），则 kubectl debug node 命令将不起作用。 这种情况下请检查调试关闭/无法访问的节点。

二、使用 telepresence 在本地开发和调试服务

说明： 本部分链接到提供 Kubernetes 所需功能的第三方项目。Kubernetes 项目作者不负责这些项目。此页面遵循CNCF 网站指南，按字母顺序列出项目。要将项目添加到此列表中，请在提交更改之前阅读内容指南。

Kubernetes 应用程序通常由多个独立的服务组成，每个服务都在自己的容器中运行。 在远端的 Kubernetes 集群上开发和调试这些服务可能很麻烦， 需要在运行的容器上打开 Shell， 以运行调试工具。

telepresence 是一个工具，用于简化本地开发和调试服务的过程，同时可以将服务代理到远程 Kubernetes 集群。 telepresence 允许你使用自定义工具（例如调试器和 IDE）调试本地服务， 并能够让此服务完全访问 ConfigMap、Secret 和远程集群上运行的服务。

本文档描述如何在本地使用 telepresence 开发和调试远程集群上运行的服务。

1、准备开始

• Kubernetes 集群安装完毕
• 配置好 kubectl 与集群交互
• Telepresence 安装完毕

2、从本机连接到远程 Kubernetes 集群

安装 telepresence 后，运行 telepresence connect 来启动它的守护进程并将本地工作站连接到远程 Kubernetes 集群。

$ telepresence connect
Launching Telepresence Daemon
...
Connected to context default (https://<cluster public IP>)

你可以通过 curl 使用 Kubernetes 语法访问服务，例如：curl -ik https://kubernetes.default

3、开发和调试现有的服务

在 Kubernetes 上开发应用程序时，通常对单个服务进行编程或调试。 服务可能需要访问其他服务以进行测试和调试。 一种选择是使用连续部署流水线，但即使最快的部署流水线也会在程序或调试周期中引入延迟。

使用 telepresence intercept $SERVICE_NAME --port $LOCAL_PORT:$REMOTE_PORT 命令创建一个 "拦截器" 用于重新路由远程服务流量。

环境变量：

• $SERVICE_NAME 是本地服务名称
• $LOCAL_PORT 是服务在本地工作站上运行的端口
• $REMOTE_PORT 是服务在集群中侦听的端口

运行此命令会告诉 Telepresence 将远程流量发送到本地服务，而不是远程 Kubernetes 集群中的服务中。 在本地编辑保存服务源代码，并在访问远程应用时查看相应变更会立即生效。 还可以使用调试器或任何其他本地开发工具运行本地服务。

4、Telepresence 是如何工作的？

Telepresence 会在远程集群中运行的现有应用程序容器旁边安装流量代理 Sidecar。 当它捕获进入 Pod 的所有流量请求时，不是将其转发到远程集群中的应用程序， 而是路由所有流量（当创建全局拦截器时） 或流量的一个子集（当创建自定义拦截器时） 到本地开发环境